Device security principles for manufacturers

This guideline applies to all devices.

It is important that malware, and attackers with physical access to a device can’t modify the system. If a device is updated through an unauthorised mechanism, the integrity of the device is undermined. By restricting the device to only accept authorised updates, it limits the ability of malicious actors to gain persistent access.

Desirable properties in an authorised update mechanism are discussed in principle 1, but the device must also ensure that the applied updates come from an authorised update mechanism. As such, not all devices meeting principle 1 will also meet this guideline.

Example: The operating system image is integrity protected using hash trees to ensure that it's only modifiable through an update process combined with the relevant signature.

References:

• NCSC Zero trust architecture Principles 3 and 6
• MITRE: T1495 Firmware Corruption
• MITRE: T1542.001 System Firmware
• NIST SP 800-213A: Software Update − Update Capabilities
• NIST SP 800-213A: Device Security − Secure Resource Usage

This guideline applies to all devices.

Ensuring that each piece of boot software matches previously known good signatures gives confidence that the device is booting into a good state. This helps mitigate the risk of an attacker corrupting the core operating system image, resulting in security issues which could lead to device exploitation.

Example: Secure boot ensures that the operating system can’t be corrupted or compromised without the bootloader discovering this via TPM register outputs or a similar way, without replacing the built-in hardware keys.

More advanced mechanisms, such as leveraging a Dynamic Root of Trust for Measurement (DRTM) can also be used to give confidence in a device’s pre-boot security, without requiring boot software to match a known good state.

References:

• NCSC Zero trust architecture principle 2
• MITRE: T1542 Pre-OS Boot

This guideline applies to all devices.

Device security is improved when there is a capability that ensures runtime integrity. Building this functionality into the device improves usability for enterprises and end users. In this context, a framework is an extensible functionality that can be used by first and third parties to produce runtime integrity protections, such as anti-malware products.

Example: A vendor implements a set of APIs to allow third parties to query for things like Process Creation, or Writing to a file, to help determine malicious activity.

As well as maintaining the integrity of the device through malware defences such as antivirus, this also applies to making sure data which the device uses keeps integrity during its life.

Making a runtime integrity framework available to third parties doesn’t oblige users to use third-party integrity protections. This means users can choose whether to rely on a third party or to use features native to the OS. Manufacturers may also choose to produce runtime integrity protection solutions that use this framework.

Example: An antivirus and anti-malware capability is built into a device by default. An organisation then deploys the device via their MDM platform. Once provisioned, it's instantly protected as there is no requirement to install third-party software.

References:

• NCSC Zero trust architecture principle 7
• MITRE: T1566 Phishing
• MITRE: T1059 Command and Scripting Interpreter
• NIST SP 800-213A: Cybersecurity State Awareness

- Audit Support and Protection
- State Awareness Support

• NIST SP 800-213A: Device Security − Device Integrity

This guideline applies to all devices.

Exploit mitigations such as ASLR, NX bits and stack canaries all help mitigate common exploits. It's preferable to use capabilities provided by the operating system or capabilities that are hardware based, as they can be used by third-party software, although this may not apply to all devices, such as some lower powered devices. By documenting which exploit mitigations a device provides, developers of that third-party software can then ensure they are used in their product. For more constrained devices, well-documented exploit mitigation is still required so that a user can effectively evaluate the risks associated with using the device.

More advanced mitigations such as CFI, MTE and PAC further mitigate exploitation. Manufacturers are expected to invest in these mitigations as they become available in the hardware components in use.

All system software is expected to have some level of exploit mitigation. The details of these exploit mitigations varies between applications. These mitigations shall be documented.

References:

• MITRE: T1211 Exploitation for Defence Evasion
• NIST SP 800-213A: Device Security

- Secure Execution
- Secure Resource Usage

This guideline applies to all devices.

Confidence in device integrity can be established through attestation of device health data. As such it is important that device health data is not vulnerable to manipulation by an attacker whilst being analysed or stored, as securely retrieving compromised data may give wrongly-placed confidence about device health.

Example: Health data is gathered and checked against hardware-backed registers. This data is then analysed and verified within a secure enclave running in a virtual environment before it is sent to a remote monitoring system. But between gathering and analysing the data, it was stored in a process running in user mode. The memory and storage of this process was therefore accessible to other processes, making it vulnerable to alteration.

Possible protections for device health data include backing by a hardware root of trust, or storage within a secure enclave environment. This helps ensure the integrity of that data and maintain its trust.

Example: Cryptographic mechanisms provided by a secure enclave on the device both store device health data and protect its integrity.

Health data transmitted to a remote health service should adhere to principles 2 and 3 to ensure data integrity is maintained throughout.

References:

• MITRE: T1557 Adversary-in-the-Middle
• MITRE: T1005 Data from Local System
• NIST SP 800-213A: Cybersecurity State Awareness − Audit Support and Protection

This guideline applies to all devices.

If a device is left unattended for a long time, there is a risk an attacker could access it and manipulate it, for example by modifying the hardware. Applying physical security to the devices gives users confidence that it will be obvious if a device is physically altered.

Example: An unattended device outside of an organisation’s office environment may require significant physical hardening such as tamper-evident seals. In contrast, portable devices such as laptops require simpler protection such as security screws to discourage opportunistic attacks.

References:

• MITRE: T1584 Compromise Infrastructure
• NIST SP 800-213A: Device Security − Device Integrity