Device security principles for manufacturers

This guideline applies to all devices.

When a device is first set up, any running services that aren’t essential will increase the attack surface of the device. In this context, services of interfaces include functionality such as: transfer of power and data over Thunderbolt, connection to a terminal via a Serial port, or IPv6 over Wi-Fi. Being able to easily identify which services are running on a device and are exposed over an interface allows organisations to lock down device interfaces more effectively.

Example: An organisation wants its devices to be managed only by a device management platform. A settings menu or interface on the devices shows that SSH and Telnet are both enabled on the devices when they ship from the factory, therefore an administrator knows to remove or disable those services on all devices.

Reducing the services in operation also reduces the attack surface. Knowing which of the services running over an interface can be disabled will facilitate more accurate risk management when using the device in specific environments.

If an organisation understands the resources and expected behaviours of its connected devices, it provides a baseline of what ‘standard' looks like across its network. This information can then be used to alert if new and unexpected protocols are used by a device's network interface, generally a physical interface, to assess whether the activity may be malicious.

An emerging approach for this includes the device providing a MUD (Manufacturer Usage Description) file URL, through a mechanism such as DHCP. This allows an organisation to apply the principal of least privilege to firewall rules by understanding which services a device needs to connect to.

Example: A manufacturer provides documentation stating which protocols a device uses for communication over networks. When a device is using unsecure protocols, it's checked against the documentation to see if the protocol is being used intentionally or not. If not used intentionally, the administrator can be alerted to a potential compromise.

References for this guideline include:

• NCSC Zero trust architecture principles 2, 3 and 6
• ETSI EN 303 645: Communicate securely
• MITRE: T1048 Exfiltration over Alternative Protocol
• IETF RFC 8520 Manufacturer Usage Description Specification
• NIST SP 800-213A: Device Identification − Identifier Management Support
• NIST SP 800-213A: Device Identification − Actions Based on Device Identity

This guideline applies to all devices.

Disabling the services reduces the attack surface and helps organisations meet a level of risk they are acceptable with.

Example: An organisation doesn’t want to use IPv6, so they disable it on ethernet and Wi-Fi interfaces.

Example: To prevent data loss, an organisation wishes to prevent data transfer over USB. The organisation therefore disables the ability to transfer files to USB devices.

References:

• MITRE: T1052 Exfiltration over physical Medium
• MITRE: T1200 Hardware Additions
• NIST SP 800-213A: Device Configuration − Interface Configuration
• NIST SP 800-213A: Logical Access to Interfaces − Interface Control
• NIST SP 800-213A: Device Security − Secure Device Operation

This guideline applies to all devices.

It’s important that an organisation is clear about any network ports exposed by a device and the purpose of any network service, as well as the endpoints they communicate with. This helps configuration of wider network security controls, such as host-based firewalls, and helps build a legitimate traffic profile for the device. Administrators will then be able to detect if there is communication with unknown services, which might indicate compromise. This then allows them to revoke access to sensitive corporate data if compromise has taken place.

Example: A malicious actor attempts to exfiltrate data from a compromised device. This unusual network traffic is blocked by the network firewall, and the administrator is alerted to this event. This helps the administrator identify the compromise and begin remediation.

Example: A malicious actor gains access to a device with limited functionality. The actor manages to hide SSH traffic by using a publicly documented port to hide in traffic which already exists. The organisation uses a command ‘show running services’-like command which shows that SSH is running. This isn’t expected and so the organisation can then block further malicious traffic from leaving the network.

References for this guideline include:

• MITRE: T1011 Exfiltration over Other Network Medium
• MITRE: T1040 Network Sniffing
• MITRE: T1567 Exfiltration over Web Service

This guideline applies to all devices.

Organisations deploying devices need to understand which mitigations are available to protect physical, logical and network interfaces on a device from misuse. This helps protect the device from some physical attacks such as Direct Memory Attacks (DMA).

Example: A device is left unattended and an attacker takes the opportunity to physically attack the device to gain access. The device is using an IOMMU which prevents an unsophisticated actor from successfully conducting a Direct Memory Access attack.

Less sophisticated physical interfaces such as USB may require simpler protections, such as preventing data transfer over the interface (power transfer only) and blocking device IDs. Other mitigations like firewalls will help protect interfaces which are network accessible.

Example: A firewall has been configured on a device to block unsolicited inbound connections to the device, helping prevent an outside attacker from directly connecting to the device.

References:

• NCSC: Device Security Guidance − Using peripherals securely
• MITRE: T1571 Non-Standard Port
• MITRE: T1091 Replication Through Removable Media
• MITRE: T1200 Hardware Additions
• NIST SP 800-213A: Device Configuration − Interface Configuration
• NIST SP 800-213A: Logical Access to Interfaces − Interface Control

This guideline applies to all devices.

Enabling mitigations against interface misuse by default minimises the burden on organisations to understand and implement security controls. Some mitigations such as firewalls should be provided with an appropriate sample configuration, while other mitigations such as IOMMUs will require no configuration beyond enabling.

Example: An untrusted Thunderbolt connection is made to a device. The device uses Thunderbolt 4 which enforces DMA remapping and use of an IOMMU. The device is protected against misuse of the Thunderbolt interface without configuration by the end user.

References:

• NCSC: Device Security Guidance − Using peripherals securely
• MITRE: T1571 Non-Standard Port
• MITRE: T1091 Replication Through Removable Media
• MITRE: T1200 Hardware Additions

This guideline applies to all devices.

If organisations and users can disable interfaces on a device, it will help keep track of what is connected to a device and will help protect data that could be exposed, via a camera, microphone or radio for example. Appropriate controls help mitigate the risk of uncontrolled devices being connected without knowledge, prevent the use of cameras and microphones, and any form of radio communication. Devices should support the ability to disable interfaces physically with hardware, for example by disabling an upstream data port or removing power from a chipset.

Example: An organisation doesn’t want users to be able to connect Thunderbolt-based peripherals because of concerns over Direct Memory Access (DMA) attacks in high-threat locations.

References:

• MITRE: T1011 Exfiltration over Other Network Medium
• NIST SP 800-213A: Device Configuration − Interface Configuration
• NIST SP 800-213A: Logical Access to Interfaces − Interface Control
• NIST SP 800-213A: Device Security − Secure Device Operation