Device security principles for manufacturers

• Introduction
• What do we mean by enterprise-connected devices?
• The device security principles
• Interpreting the principles and guidelines
• Producing and publishing a response

These device security principles − produced by the National Cyber Security Centre and in conjunction with the Department for Science, Innovation and Technology (DSIT) − help organisations gain confidence that enterprise connected devices are protected against common cyber security threats and risks.

The primary audience for this guidance is manufacturers of enterprise-connected devices, although manufacturers of distinct consumer connectable products, and public sector and private organisations using and/or procuring devices may also find it useful.

Manufacturers can use the principles to identify which security mitigations should be included in their products. Organisations can use the principles as a framework to assist in the procurement of secure, enterprise-connected devices. We encourage manufacturers to publish their own transparency report, which will formally document how their products meet (or don’t meet) each of the device security principles.

Some of these principles are not solely the responsibility of the device manufacturer, and in certain situations will depend on the implementation approach taken by a device management platform provider and the endpoint software they provide. Manufacturers are invited to share these principles with their supply chains, in order to identify the security mitigations that need to be included. The NCSC has separate guidance that deals directly with supply chain security.

Note that these principles do not provide organisations with a panacea for device security. Rather, they will help organisations looking to procure enterprise-connected devices to make well-informed choices, and gain confidence in devices (or device platforms) that can mitigate the risks they are likely to face. Organisations should take a holistic view of the device design; securing individual components does not guarantee the security of the overall system architecture.

Related documents
 

• If you are a manufacturer of consumer connectable devices (that is, consumer ‘IoT’ devices that are connected to the internet or home network), the UK government will be producing guidance to support the Product Security and Telecommunications Infrastructure Act in due course. For the moment, ETSI EN 303 645 lays out baseline requirements for these products.
• If you’re responsible for managing and procuring devices within your enterprise, please refer to the NCSC’s Device Security Guidance.
• If you're a product developer, adhering to the NCSC’s Product Development Principles gives us a measure of how competently you can build secure technologies.

These principles cover devices that interact with, process or hold an organisation's data. This includes:

• laptops
• smartphones
• enterprise printers
• video conferencing systems
• VoIP phones
• network attached storage (NAS) devices
• room booking displays
• connected devices used in an enterprise environment ( this therefore can include consumer connectable products where such products are used in this manner)

Networking equipment

Also within scope is networking equipment, where managed via external services (such as cloud services), and where it’s not intended for deployment within a core or radio access network of a telecommunications provider. Examples of networking equipment within scope includes:

• SOHO (small office/home office) networking devices
• network components that can be remotely managed via a ‘single pane of glass’ interface

Networking equipment intended purely for use within core or mobile telecommunications networks is out of scope. Manufacturers of these devices should refer to the Telecommunications (Security) Act and Vendor Security Assessment that sets out the security requirements for such products.

Sensor data and industrial processes

Devices where the primary security concerns relate to safety or integrity and availability of either sensor data or industrial processes are out of scope. This includes settings (such as factories, warehouses, medical environments) where an organisation will prioritise safety and data reliability over the security of those devices for regulatory reasons. Such settings therefore require separate treatment, but the device security principles may provide a useful starting point. For devices used in a ‘connected places’ (i.e. smart city) environment, the NCSC has produced principles on best practices for organisations operating a connected place.

1. Provide updates, securely
2. Support appropriate authentication
3. Protect data at rest and in transit
4. Maintain device integrity
5. Ensure transparency of device health
6. Permit only trusted software
7. Minimise the privilege and reach of applications
8. Constrain the use of all device interfaces
9. Allow robust device management
10. Provide security logging, alerting and monitoring capabilities
11. Enable recovery to a known good state
     

By publishing a public response to the device security principles, you help organisations that are looking to use or procure your device gain confidence in how your device (or platform) mitigates risks. This section describes what an effective response should include (organisations who have previously published a response to the NCSC's cloud security principles will be familiar with much of this).

Responses should be published in an appropriate area on your website − for example, within a compliance section. Note that neither the NCSC nor DSIT formally validates the answers provided in these responses. However, your customers may gain confidence in your response if it:

• contains evidence from independent audits, which may be carried out as part of a certification activity
• is assessed against international standards that maps to a principle or the guidelines
• is formally endorsed by a member of the manufacturer’s board, or a named delegate with security responsibility for security

When writing a response to the principles, we recommend the following:

1. Focus on the guidelines. The most important outcome for a customer is that they gain confidence in your ability to meet the guideline for each principle. As a result, organisations will expect your responses to focus on the guidelines, and not just the high-level purpose of the principle
2. Be clear, simple, and specific. Make sure the language you use in your response is clear, concise, and unlikely to be misinterpreted. Where you rely on particular technologies or protocols, be as specific as you can about your implementation. If the NCSC has guidance on the topic linked from the device security principles (or the device security guidance where applicable), we recommend that you compare your implementation directly with that guidance.
3. Back up assertions with evidence. This may be from audits, or from achieving certification against international standards. It's easier for your customers to trust evidence that you are able to present in a transparent way on your public website. If good supporting evidence is available under an NDA, the response needs to declare this, but the response will be expected to stand by itself.
4. Refer to existing publications. Provide the key statements that respond to each principle's guidelines and refer to documentation and evidence that you publish elsewhere (rather than repeating the detail within the response).
5. Refer to the supply chain. Where a product involves third party software and hardware components, you may wish to encourage corresponding manufacturers to publish their own responses to the principles. This will allow organisations using the responses to have higher confidence in the whole product stack. Where relevant, you should also be clear about how you make use of a third party underlying platform or component. For example, if your device uses a TPM state how it is used to meet that guideline, not just that it's in the device.
6. Keep the response up to date. Device platforms constantly evolve, so you should check periodically that your response to the principles still reflect your service. Linking to documentation elsewhere and keeping the response document concise should help to make this easier.

Content recommendations for transparency reports

While it's not defined how a manufacturer response should be formatted, one form of response is a transparency report. Recommendations for their content are below.

1. The transparency report should clearly state to what extent the manufacturer meets each of the Product Development Principles.
The Product Development Principles explain the NCSC’s expectations and recommendations for how developers and manufacturers build products. It's important that organisations understand whether you have processes in place to ensure that cyber security is considered from the design phase, through development, and into long term support. Without these in place, it's more likely that vulnerabilities may cause harm.

2. The transparency report should contain a description of how a security vulnerability in the device or device platform can be reported to the manufacturer as part of a disclosure policy.
It's vital that when security vulnerabilities in any product or system are found, they can be easily reported to the responsible organisation, and a fix identified and released. The transparency report should include details of how such vulnerability disclosure processes works. For organisations who do not yet have a process for vulnerabilities to be reported, there are a range of sources that can help you set this up:

• The NCSC provides a Vulnerability Disclosure Toolkit that guides organisation through this process.
• International standards such as ETSI EN 303 645 (5.2), ETSI TR 103 838, and ISO 29147 all contain requirements for vulnerability disclosure processes. In addition, ISO 30111 contains requirements on how organisations handle vulnerabilities that have been reported to them.

3. The transparency report should clearly state which guidelines are met (and which are not).
By including a table (or other mechanism) in your response, organisations procuring devices should quickly be able to determine which guidelines are met so they can make informed, security-based, decisions between products.

4. Where required, the transparency report should direct the reader to guidance on how to configure the device to meet a specific guideline if it isn't enabled by default.
If your device or platform supports a capability covered in a guideline that’s not enabled by default (or you don't provide guidance on how it can be used), a manufacturer runs the risk that organisations may not make use of that capability. You should:

• refer to existing documentation to ensure that organisations know how to mitigate risks
• provide tooling and example configurations to assist with compliance checks

5. If a guideline isn't met by the device or device platform, the manufacturer can state how they have aimed to mitigate the stated risk through other technical means.
The NCSC recognises that there may be alternative approaches to mitigate risks other than the guidelines outlined in these principles. Where your product doesn't meet a guideline, it’s acceptable to explain how you mitigate the associated risks by other means. You will, however, have responsibility for making it clear to the reader how you do this. This includes where a particular guideline would be met by third-party tooling or a management platform into which the device can be integrated. For example, cryptographic mechanisms that are secure and well-implemented in isolation are occasionally not secure when combined.