Device security principles for manufacturers

This guideline applies to all devices. 

It's difficult for organisations to estimate long-term support costs when they don’t know a device’s minimum support period at the time of procurement. This may mean that users continue to use out-of-support devices that are exposed to newly discovered vulnerabilities. Manufacturers can address this by specifying an end date, or by including a support policy that defines the notice period for ending support.

The manufacturer is also expected to state whether any components in the device rely on security updates from a third party, and to provide details of support lifetimes for these components.

Example: The manufacturer has a webpage that lists the end-of-support dates for all their enterprise products.

Example: The manufacturer makes it clear that support for a device is extendable through a support contract for a set number of years.

References: 

• ETSI EN 303 645 5.3-13 & 5.3-14
• NIST SP 800-213A: Software Update − Update Capabilities

This guideline applies to all devices. 

It's essential that an update is only installed if the device proves the update has been issued by a trusted source and not altered or corrupted during transit. If it can’t prove this, an attacker may be able to send a fake or malicious update, or corrupt an update so that it won’t install, or possibly even damage or ‘brick’ the device. Mitigating this risk is particularly important when a device allows for automatic or remote updates. This is best achieved when code is signed with the developer’s private key.

Example:  A device uses cryptographic mechanisms to verify that any updates it receives were issued by a trusted source and not altered during transit, in line with guideline 1.3.

If an update is rejected because it has failed authentication or integrity checks, it's good practice to take action by reporting the incident to an appropriate service or by informing the user. The owner or administrator can then investigate and put in place the required mitigations to prevent an attacker bypassing or misusing updates.

Example: A device minimises the information leaked to a potential attacker by not providing information about update failure to the initiator of the update. Instead the device generates a log entry and delivers a notification to a trusted peer over a secure channel (such as TLS), so that the update failure is known and the owner or administrator can investigate.

References: 

• ETSI EN 303 645 5.3-7 & 5.3-9
• NCSC Zero trust architecture principle 3 and principle 7
• MITRE T1195.002 Compromise Software Supply Chain
• MITRE T1495 Firmware Corruption
• NIST SP 800-213A: Data Protection − Secure Transmission
• NIST SP 800-213A: Software Update − Update Capabilities

This guideline applies to all devices. 

Cryptographic mechanisms are the most effective way to verify that an update has been issued by a trusted source and not altered during transit. Digitally signing updates allows a device or server to verify both of these conditions, but requires a functioning Public Key Infrastructure (PKI) and careful management of digital certificates. Alternative methods may be appropriate when device constraints or issues with implementing a PKI makes verifying signatures unfeasible.

Example: The manufacturer signs software updates with a signing key issued by a trusted Certificate Authority (CA), the certificate for which is stored securely in the device (in line with guideline 3.5). Only the manufacturer has access to the signing key. If an attacker alters the update in transit, or attempts to provide a new update, the device will detect that the signature is invalid and reject the update.

Example: In one case, a PKI can’t be implemented, so an alternative mechanism such as a Message Authentication Code, built using a shared secret key, is used to provide integrity and implicit authentication. But the key must be securely generated, delivered and installed in devices (in line with guideline 3.5) and the manufacturer must consider the risk of key compromise in the design.

If a device receives updates over a secure channel, for example from a server that has verified the update, it's important that the protections of the channel can assure the integrity and authenticity of communications.

Example: A device receives a verified update from a server over a connection protected with TLS, according to NCSC guidance. This protects the confidentiality, integrity and authenticity of traffic, and therefore also of the update.

It is important that the cryptographic mechanisms or protocols are based on standard technologies and have received an independent security review. A number of standards organisations and cyber security organisations, including the NCSC, publish best-practice guidance detailing which algorithms, protocols and technologies are appropriate for different use cases. Recommendations for best-practice cryptographic algorithms are device dependent and may evolve over time. For more detail, see guideline 3.4.

References:

• ETSI EN 303 645 5.3-7, 5.3-9 and 5.3-10
• NIST information on digital signatures
• NIST information on Message Authentication Codes
• NIST SP 800-131A
• NIST FIPS 140-3
• NIST SP 800-213A: Data Protection − Cryptographic Capabilities and Support

This guideline applies to all devices.

When the manufacturer provides updates consistently and clearly communicates expected frequency of updates, software can be well maintained and kept up to date. This provides users with a reliable service and full device functionality, and can also protect systems from emerging security threats that updates help mitigate. It is the device which determines how regularly a device needs to update.

Example: A corporate laptop receives monthly operating system updates.

References:

• MITRE: T1588 Obtain Capabilities
• NCSC Zero trust architecture principle 3

This guideline applies to all devices.

When critical vulnerabilities affecting the device are detected, it's important to provide updates quickly to prevent actors exploiting devices in use. A vulnerability may need to be fixed outside of the standard cycle update, while a less critical vulnerability could wait until the next regular scheduled update.

Sometimes details of a new vulnerability are made public before a fix is available, for example when a security researcher publishes details of a recent discovery, or when a threat actor exploits a previously unknown issue and attacks are observed in the wild.

Once the details of a vulnerability are known, it can lead to widespread compromise, particularly if different threat actors exploit it. The longer it takes for a vendor to release a patch, the more compromises there will be, so a vendor may need to issue a patch quickly, and potentially outside of the standard update cycle.

Example: A vulnerability is discovered in a device operating system that allows a malicious attacker to escalate privilege. The vendor should provide an update to patch this vulnerability as soon as possible.

References:

• NCSC Zero trust architecture principle 3
• Vulnerability management

This guideline applies to all devices.

An organisation must be able to easily manage updates across a fleet of devices that can contain a large number of individual units. This is particularly important when devices are critical to business operation and there are many devices on a network.

Updates are important for security, but in operational environments, they can cause problems for users and administrators if they start to affect business performance. They may then be turned off, or made manual only, which relies on administrators to push them out. In cases when updates require administrator or user interaction, this is ideally a simple process, for example requiring a single click. When devices don’t install updates automatically, they may be more vulnerable to attack.

Example: Centralised patching such as Windows Update for Business or through an MDM platform.

Example: An IoT device is business-critical in an organisation and will cause significant issues if it's offline during working hours. It would be best to schedule updates outside of standard working hours. At another organisation, the same device isn’t business critical, and is set to update as soon as a patch is released.

Example: A corporate laptop is used as an employee’s primary work device. The employee can schedule the update for a time when she isn’t working, so it doesn’t disrupt the day.

The same device can be used in different ways, and in different network setups, it may have a completely different function, availability requirement and risk profile to another device. Automatic updates are helpful in some circumstances, but it's important that the enterprise can prevent automatic updates from installing to avoid impacting business operations. For example, the enterprise might schedule the update to happen outside of working hours.

For devices belonging to individuals, it may be sensible to allow users to control when updates are installed, within parameters defined by their organisation. If the device doesn’t support automatic updates, there is a risk that some devices will never update even when one is available, and devices may be unpatched for longer. Mobile Device Management or other management tools that provide ‘single pane of glass’ interfaces are a common way for devices to support configuration of update policies.

References:

• NCSC Zero trust architecture principle 3 and principle 4
• NIST SP 800-213A: Device Configuration – Device Configuration Control
• NIST SP 800-213A: Software Update – Update Capabilities
• NIST SP 800-213A: Software Update – Update Application Support
• NCSC Device Security Guidance – Mobile Device Management

This guidance shall apply to all devices.

When vendors make information on updates publicly available, administrators know which vulnerabilities they are patching and can determine how urgent an update is for the specific use case. Administrators are more likely to patch when they know an update is critical to security, which makes sharing this information crucial. Differentiating between security updates and feature updates makes it more likely that security updates will be installed.

Example: Vendors may achieve this by highlighting which vulnerabilities have been patched when an update is released. Administrators can then determine whether it is essential to make sure their fleet of devices are updated to the most recent patch.

This also helps administrators understand which vulnerabilities have been patched or not, and to apply other mitigations if necessary. Information can be provided in changelogs, detailing which modifications have been made and giving details on patched vulnerabilities, for example, with CVEs. Ideally this data is provided in both human and machine-readable formats, so administrators can analyse themselves, or feed it into security analysis tools. Current mechanisms to do this include both SBOMs (software bill of materials) and VEX (Vulnerability Exploitability eXchange).

Example: A vendor might supply an updated SBOM alongside a patch or update. This new SBOM details any changes in underlying components, as well as vulnerability information relating to those components.

References:

• NCSC Zero trust architecture principle 7 and principle 8
• NCSC Blog post: Improving government, one bit at a time 
• NTIA: Software bill of materials (SBOM)
• NCSC Blog post: SBOMs and the importance of inventory