Device security principles for manufacturers
Principles to guide manufacturers in the design of secure, enterprise-connected devices.
Pages
Page 11 of 12
10. Provide security logging, alerting and monitoring capabilities
It's important that devices can be monitored so administrators can identify potential security incidents, remove devices from the network (if necessary), or attempt to remediate any compromise.
The wide-ranging nature of cyber attacks means there is no single metric that can be used to identify a compromise in commodity attacks. Using antivirus techniques to identify known compromises will protect against some attacks for certain device types, but other data is necessary to identify novel attacks or misuse. This makes it important for a range of data to be made available through logging and monitoring systems, and for an alert system can warn administrators of unusual behaviour on the device.
Guideline 10.1: The organisation shall be able to view security events related to the device, either locally or remotely
This guideline applies to all devices in scope.
The ability to view a device's events is critical to help prevent and remediate attacks. Events may include: details of who has logged in or attempted to log in to the device, as well as when, where and what activity has taken place. The level of detail provided should be proportionate to the role of the viewer: ie administrators can have full visibility of all aspects of a resource that they manage, whereas device users may have a limited visibility of events.
Example: A device communicates with a device management service providing details that allow an administrator to investigate when, where and who has implemented changes that mean it’s no longer in a known healthy state.
Example: A device alerts and provides information to an end user when changes have occurred or will occur that may: alter the device’s compliance with an organisation’s policy, change the way the user interacts with that device, such as a change to log-in credentials, or disrupt how the device functions.
References:
- ETSI EN 303 645: Examine system telemetry data
- NCSC Zero trust architecture principles 3, 6
- NIST SP 800-213A: Cybersecurity State Awareness
- Access to Event Information
- Event Identification and Monitoring
- Support for Reliable Time
- Audit Support and Protection
Guideline 10.2: The device shall allow the organisation to apply indicators of compromise to network traffic
This guideline applies to all devices.
Indicators of compromise (IoCs) are used to identify the presence of malware, or a compromised device, in a network. If the device doesn’t support the organisation in detecting IoCs in network traffic, compromise is likely to go unnoticed. Some of the common examples where this applies is DNS traffic or SNMP.
If an organisation can’t configure the use of a chosen DNS resolver, it reduces the view of IoCs. Some devices have facilities in place to keep DNS traffic private, but if these facilities prevent an organisation choosing the configuration or override their choice of setting (i.e. through a device management tool or DHCP), an organisation is not as well equipped to detect and respond to incidents.
A device that support SNMP means administrators can monitor network performance, maintain records of change and gather real-time information on the status of a device, providing further IoCs.
Example: An organisation configures a device to persistently use a chosen DNS resolver such as PDNS (whether using encrypted DNS or otherwise). This benefits the organisation’s security in several ways: by increasing their visibility of potential compromise and enabling content filtering.
References:
- MITRE: T1071.004 DNS
- NCSC Zero trust architecture principles 2, 3, 7
- NIST SP 800-213A: Device Security − Secure Communication
- Indicators of Compromise (IoCs) and Their Role in Attack Defence
Guideline 10.3: The device shall support the capability to securely forward and export logs
This guideline applies to any devices capable of logging. This excludes constrained devices.
The capability to support the secure forwarding and exporting of logs (while adhering to principle 3 - Protect data at rest and in transit) and over a recognised documented format is essential for an enterprise to investigate security events. Not all logged events will be relevant to the enterprise and so the forwarding and exporting of logs needs to be configurable to investigate information as required.
Example: A manufacturer provides functionality and documentation to export and forward logs from a device using Common Event Format (CEF) over Syslog configured to use TLS. This allows ease of visibility of events that have occurred on that device by the organisation and facilitates any investigation into potential security incidents.
References:
- MITRE: T1562 Impair Defences
- NCSC Zero trust architecture principle 6
- NIST SP 800-213A: Cybersecurity State Awareness
- Event Identification and Monitoring
- Logging Capture and Trigger Support
- Support of Required Data Logging
- Audit Log Storage and Retention
- Support for Reliable Time
- Audit Support and Protection
Guideline 10.4: The device shall use reliable time sources to enable accurate security logging and investigation
This guideline applies to all devices.
Security logging, alerting and monitoring information is often accompanied by a form of time-based information. A device providing a method to assure that the time information conveyed with its logs is accurate and verifiable will help direct an organisation's investigations into security events. Without reliable time information, an organisation may not be able to correlate the cause of security events and could lead to false conclusions of the source.
Example: A device synchronises its time with a verified source defined by the organisation such as Network Time Protocol (NTP) or Network Time Security (NTS). This time information is converted into a format they use (such as Coordinated Universal Time (UTC)) and allows them to accurately investigate other events that have occurred on their network at the same time as a security event on the device.
References:
- ETSI EN 303 645: Examine system telemetry data
- NCSC Zero trust architecture principle 6
- NIST SP 800-213A: Cybersecurity State Awareness - Support for Reliable Time
Guideline 10.5: The manufacturer shall provide documentation of formats for logs and events produced by the device
This guideline applies to any devices capable of logging. This excludes constrained devices.
By providing the format that logs and events, organisations using those devices will be better able to examine a device where compromise is suspected. It will also enable development of tools for conducting analysis of logs and events, to further help in incident response.
If a device is part of a system where it’s tightly coupled to a management device, it’s acceptable for the events from the device to the manager to be sent in a proprietary format, providing they are then exportable from the manager in a standard format.
Example: An IP phone is tightly coupled with a call processing system and sends logs to this call processing system in a proprietary format. Logs and events from the device are exportable in a standard format documented by the manufacturer from the management device and able to be examined by the organisation where compromise is suspected.
References:
- MITRE: T1562 Impair Defences
- NCSC Zero trust architecture principle 6
- NIST SP 800-213A: Cybersecurity State Awareness
- Event Identification and Monitoring
- Logging Capture and Trigger Support
- Support of Required Data Logging
Guideline 10.6: Logging network connections enables an organisation to identify indicators of compromise.
- End user devices shall provide capabilities to log all network connections
- All other devices can provide capabilities to log all network connections
A device’s capability to provide logs of all the connections it makes over a network provides traceability in the event of an attack and helps to provide assurance that a device hasn’t connected to an IP address or other host included in shared IoCs. Depending on the device types in use, an organisation may look to do this at a network level rather than the endpoint itself to identify IoCs.
Example: A manufacturer ensures the device logs all its external connections to and from networks using NetFlow or another technology. These logs would then be accessible by an IT administrator using a device management platform to be able to catalogue these events.
References:
- MITRE: T1041 Exfiltration over C2 Channel
- MITRE: T1048 Exfiltration over Alternative Protocol
- NCSC Zero trust architecture principles 2, 6, 7
- NIST SP 800-213A: Cybersecurity State Awareness - Event Identification and Monitoring
Guideline 10.7: The device shall have the ability to alert the owner or administrator to significant changes in state
This guideline applies to all devices.
If any action is taken against a device that could be a cause of concern (such as a new login, changes to security rules or passwords and similar), the owner and administrator of the device should be alerted of these changes. Manufacturers need to clearly state what will be flagged, and the level of detail about these changes provided should be proportionate to the party viewing the event. This means for example that administrators should have full visibility of events, whereas users may have a limited visibility. Guidelines on device state are included in principle 11 and build off in principles 4 and 5.
Example: A manufacturer ensures that the device has the ability to log any key security events (eg changing a password, factory reset, change of SIM card) can be recorded. These logs are accessible by an organisation within a Mobile Device Management system to be able to act as desired on these events.
References:
- ETSI EN 303 645: Examine system telemetry data
- MITRE: T1068: Exploitation for Privilege Escalation
- NCSC Zero trust architecture principles 3, 6
- NIST SP 800-213A: Cybersecurity State Awareness - Event Response