Device security principles for manufacturers
Principles to guide manufacturers in the design of secure, enterprise-connected devices.
Pages
Page 6 of 12
5. Ensure transparency of device health
Along with mechanisms to ensure device integrity, approaches such as zero trust rely on an organisation’s services using a range of measurements to determine the health of a device. These measurements are often referred to as signals in zero trust deployments.
Technologies such as health attestation allow devices to provide these signals, as well as ensuring their cryptographic integrity.
When these signals are accessible to the organisation using the device (via their device management platform or other mechanisms), the organisation can make continuous risk assessments of the device to determine whether it remains in a trusted state.
Guideline 5.1: The manufacturer shall provide documentation of its definition of device health
This guideline applies to all devices.
The manufacturer’s definition of device health is required so that organisations can make informed decisions about whether a device meets the health level required. Different devices may return various levels of health according to the manufacturer. For example, a small IoT device may only return CPU usage, patch level and uptime, which might be suitable for that device. In contrast, a laptop may return all the boot attestation values, as well as runtime monitoring features.
Example: An organisation planning to procure a new device reviews the device documentation to determine what information the device provides in the health report. Reviewing this information before purchase helps the organisation understand whether it meets their needs in a zero trust architecture deployment.
Making this information public will prevent any misunderstanding of what is expected from a device's health report.
Example: An organisation has multiple instances of device A which includes antivirus in its device health reporting. The organisation then purchases device B from the same manufacturer, expecting antivirus to also appear in the report, but it doesn’t. As a result, the organisation misinterprets the health reports for device B and makes inaccurate risk assessments.
References:
- NIST SP 800-213A: Cybersecurity State Awareness − State Awareness Support
Guideline 5.2: During runtime, the health of the device shall be available locally
This guideline applies to all devices.
Allowing users to query the health of their own devices helps keep them up to date with device health. When a device is compromised, it also helps them understand how it happened. When health information is made available at runtime, any changes made by malware or an attacker with a foothold are captured.
Example: A device is behaving strangely, so the user queries the device health and sees that the code integrity of the antivirus service has been altered.
A manufacturer is expected to do this in a way which fits with the UI of the device, such as an error message, or within settings where a user can run a scan.
Example: A VoIP phone displays an error message when it detects that a piece of software has been modified.
An organisation will potentially expect to be able to configure whether details of device health are made available to a user based on the purpose of the device. An API which makes the information available to developers of third-party tooling makes this possible.
References for this guideline include:
- NCSC Zero trust architecture principles 2, 3 and 6
- MITRE: T1070 Indicator Removal on Host
- MITRE: T1543 Create or Modify System Process
- NIST SP 800-213A: Cybersecurity State Awareness
- Audit Support and Protection
- State Awareness Support
- NIST SP 800-213A: Device Security − Device Integrity
Guideline 5.3: During runtime, the health of the device should be available remotely
This guideline applies to all devices.
Ensuring that health information is made available to remote management platforms allows organisations to perform continuous risk assessments of the device’s health and capture changes made by malware or an attacker with a foothold.
Example: An organisation gathers health data from a device and discovers a change to the boot procedure. The organisation then uses this information to implement restrictions to the device’s level of access to corporate data, until the change is investigated.
Devices with minimal networking capability may struggle to meet this guideline, but even devices with basic functionality are expected to have some mechanism to query device health information remotely.
Example: A door sensor with limited data connectivity reports the status of a single tamper-protection fuse which blows when the case is open by sending a single bit of traffic. The user then trusts that the report is accurate.
This capability provides organisations with confidence that a device complies (or not) with their requirements (such as whether the device has been ‘rooted’ or ‘jailbroken’), while also minimising the risk of malware spoofing this information.
Example: A device accurately conveys details of its current operating system and location, as well as which security patches and physical anti-tamper alerts have been applied. The organisation can then be sure that it meets the minimum policy requirements for baseline configuration and usage, and take action if requirements aren’t met.
References for this guideline include:
- NCSC Zero trust architecture principles 2, 3 and 6
- ETSI EN 303 645: Ensure software integrity
- MITRE: T1070 Indicator Removal on Host
- MITRE: T1543 Create or Modify System Process
- MITRE: T1542 Pre-OS Boot
- NIST SP 800-213A: Cybersecurity State Awareness
- Audit Support and Protection
- State Awareness Support
- NIST SP 800-213A: Device Security − Device Integrity
Guideline 5.4: The device should have a boot attestation process
This guideline applies to all devices.
During the boot process, a log should be made of the loaded binaries, drivers and firmware. This data should be used to provide assurance that the boot process is correct. For further information about handling the data processed during the boot, see principle 4: Maintain device integrity.
Example: The hashes of all binaries loaded as part of a boot process are calculated, stored and checked against a signed manifest, along with any key parameters passed. Erroneous activity during boot is made obvious to the user. Evidence of an unsafe boot should also be available remotely to (for example) device management software.
This gives clarity that the device’s boot process hasn’t been interfered with in an attempt to subvert the higher order functions of the device, as subverted devices may be allowed to access corporate data without the data owner’s knowledge.
References:
- NCSC Zero trust architecture principles 2, 3 and 6
- MITRE: T1070 Indicator Removal on Host
- MITRE: T1543 Create or Modify System Process
- NIST SP 800-213A: Cybersecurity State Awareness − State Awareness Support
- NIST SP 800-213A: Device Security − Device Integrity
Guideline 5.5: The device should have a runtime attestation process that provides regular or continuous monitoring
This guideline applies to all devices.
During runtime, monitoring of the core processes, drivers and libraries that are integral to the security and integrity of the device allow comparisons to a known good state. Organisations can expect that the user is made aware of any discrepancies here, and that the information is also available to security tooling, such as mobile device management or other device management or monitoring platforms.
Example: Monitoring the antivirus and anti-malware processes to allow quick notification if malware tries to disable or inject code into the antivirus product to bypass it.
Including the state of key security policies (such as enabled antivirus or patch status) will improve trust in the device.
This helps mitigate the risk that the device has been altered or compromised during runtime, without the data owner’s knowledge.
Example: A VoIP phone has a watchdog process that can assess the health of key processes the device requires. If any tampering is detected, it sends signals to a management platform and restarts the device.
References:
- NCSC Zero trust architecture principles 2, 3 and 6
- MITRE: T1070 Indicator Removal on Host
- MITRE: T1543 Create or Modify System Process
- NIST SP 800-213A: Cybersecurity State Awareness − State Awareness Support
- NIST SP 800-213A: Device Security − Device Integrity