Device security principles for manufacturers

This guideline applies to all devices.

If an attacker accesses the device when it's powered off, there is a risk that unencrypted stored data may be read. It's likely that organisations will require that sensitive data at rest is encrypted, and manufacturers will need to consider to what extent their device supports this requirement.

Example: A laptop uses full volume encryption to ensure that all user data, including sensitive user files, is encrypted at rest.

This risk can be alternatively mitigated by physical security features which make it more difficult for an attacker to gain physical access.

Example: An IoT device is stored inside a reinforced housing that is welded shut. As the internal storage isn’t accessible through any external interfaces, accessing data at rest would require significant physical force.

References:

• NCSC Zero trust architecture principle 3
• MITRE: T1083 - File and Directory Discovery
• NIST SP 800-213A: Data Protection − Cryptography Capabilities and Support
• NIST SP 800-213A: Data Protection − Secure Storage

This guideline applies to all end user devices.

File encryption allows for the encryption of sensitive files while the device is in use, decrypting sensitive data only when necessary.

Example: File and folder encryption allows for the encryption of sensitive information while the device is in use.

References:

• MITRE: T1565.001 Stored Data Manipulation
• NIST SP 800-213A: Data Protection − Cryptography Capabilities and Support
• NIST SP 800-213A: Data Protection − Secure Storage

This guideline applies to all devices.

Attackers may be able to gain visibility of messages transmitted to or from the device. If a compromise could impact the end user, some traffic might be considered sensitive. An attacker might be able to view confidential or personal data, or tamper with messages sent to a managed device from the management platform, including DNS records for private domains.

The level of security required to protect data in transit is proportional to the impact that the loss of confidentiality or integrity could have on the organisation. Security-critical information used by system applications, such as digital certificates, cryptographic keys and system configuration information will require strong protection. If the device makes such information available to third-party applications, the device must also support the use of these protections.

Example: An IPsec always-on-VPN is used to capture all traffic to and from a device.

Example: An organisation uses the device’s capabilities to use TLS or DTLS to protect data in transit.

Example: An IoT device uses a low-power wireless protocol, with limited security from the network, instead relying on security implemented at the application layer.

It may also be necessary to detect and disregard data that has been retransmitted or received at an unexpected time. Mechanisms to defend against replay attacks include sequence numbers, timestamps or counters on data packets. They must be properly authenticated and integrity-protected so that attackers can’t interfere with them.

References:

• Using TLS to protect data
• Using IPsec to protect data
• NCSC Zero trust architecture principles 2, 3, 5 and 7
• MITRE: T1565.002 Transmitted Data Manipulation, T1020.001 Traffic Duplication, T1557 Adversary-in-the-Middle, T1040 Network Sniffing
• NIST SP 800-213A: Data Protection – Secure Transmission
• NIST SP 800-213A: Device Security – Secure Communication

This guideline applies to all devices.

Cryptography is commonly used to protect data in transit or at rest. But poorly chosen mechanisms or weak or poorly implemented algorithms often result in little or no security gains and may provide a false sense of security. It is therefore important that a device uses algorithms and protocols based on standard technologies and is independently reviewed for security.

A number of standards-developing organisations and cyber security organisations, including the NCSC, publish best-practice guidance advising which algorithms, protocols and technologies are appropriate for different use cases. It's important that implementations of cryptographic mechanisms are from a standard and well-reviewed library. Custom implementations are less likely to have undergone an appropriate security review.

Example: A device uses TLS in line with NCSC guidance.

Example: An IoT device communicates using a secure lightweight cryptographic protocol that meets the requirements in Section 5.5 of ETSI EN 303 645.

Recommendations for best-practice cryptography are device dependent, and will change over time. For example, as quantum computing attacks emerge, there may be a future requirement to upgrade cryptographic algorithms. It's therefore beneficial to design devices so that algorithms can be changed when necessary. If this isn’t possible, the expected support lifetime of the device should not exceed the recommended usage lifetime of the algorithms and key sizes it uses, as per guidance in NIST SP 800-131A.

References:

• Using TLS to protect data
• Preparing for Quantum-Safe Cryptography
• NIST SP 800-56A, NIST SP 800-56B and NIST SP 800-56C
• NIST information on digital signatures
• NIST information on Message Authentication Codes
• NIST SP 800-131A
• NIST FIPS 140-3
• NCSC Zero trust architecture principle 7
• NIST SP 800-213A: Data Protection – Cryptography Capabilities and Support

This guideline applies to all devices.

Cryptographic mechanisms for protecting data at rest and in transit make use of secret key information. If these cryptographic secret keys are compromised, an attacker will be able to access the stored data or intercept and/or modify any transmissions. It's therefore crucial that secret keys are generated and stored securely.

Storing cryptographic roots of trust in a secure component, such as a TPM (trusted platform module, at least version 2.0) or a trusted execution environment with hardware-enforced isolation, can protect cryptographic secret keys from an attacker by ensuring they remain encrypted until required by an authorised entity with the proper authentication.

Example: Keys required for disk encryption are stored using a secure enclave, and can’t be accessed unless the correct PIN is provided.

This prevents an attacker with physical access to the device from accessing these secrets, and using them to compromise the protected data, or inserting additional secret keys to enable future malicious communications.

In addition, where cryptographic secrets are generated on the device, using a trusted and secure source of entropy, such as one conforming to NIST recommendations, prevents an attacker from exploiting poor entropy to obtain cryptographic secret keys.

Example: Keys required for disk encryption are generated using a TPM 2.0 cryptoprocessor.

References:

• NIST SP 800-90A, SP 800-90B and SP 800-90C
• NCSC’s Zero trust architecture principles 2, 3 and 4
• NIST SP 800-213A: Data Protection − Cryptographic Key Management
• NIST SP 800-213A: Data Protection − Secure Storage

This guideline applies to devices that are designed to store sensitive data.

Sensitive data won’t always be required for the entire lifespan of the device that holds it, and it's important that an administrator or the data owner can delete this data when it's no longer required. This data may include user data, details about other individuals or security-relevant data. Deleting data that is no longer needed is often a requirement of data protection regulation.

In addition, different types of data may need different levels of control: user-owned data may be deleted by its owner or an administrator, but only an administrator should be able to delete more sensitive data such as audit logs.

Example: On a corporate laptop, the user can delete files that they own. The administrator may also wipe the device remotely through a device management system, if required.

The risks of storing data when it's not needed are considerable. If an organisation is storing personal data that is no longer needed, it may be a breach of its legal data-handling requirements. If an attacker then compromises a system where unnecessary data is stored, they may gain access to this data, which may still be sensitive.

Data left on a device may also represent a risk to an organisation’s security controls. Passwords left on a device which is disposed of might be recovered, and used to gain access to the organisation’s network or data.

If a device is lost or stolen, having the capability to delete the data remotely may help protect sensitive data.

References:

• NCSC Zero trust architecture principles 2, 3 and 6
• MITRE: T1565.001 Stored Data Manipulation
• NIST SP 800-213A: Data Protection – Secure Storage

This guideline applies to all devices.

Failure to compartmentalise data creates a risk that an attacker may be able to access sensitive data through a compromised account, system or application on a device where there is no need to access the data. When data is compartmentalised and tiered access control is implemented, accounts and systems can only access the data they require.

In cases where data compartmentalisation isn’t possible, it's important that organisations carry out access logging and set up alerts for suspicious activity. Not allowing multi-user access of devices can also help mitigate this threat.

References:

• NCSC Zero trust architecture principles 4 and 6
• MITRE: T1559 Inter-Process Communication