Device security principles for manufacturers

Applies to devices where applications can be installed.

Malware is often designed to access protected files or peripherals such as webcams and microphones. If the operating system requires users to confirm their approval to access these applications, including through hardware-based mechanisms, it will prevent a compromised process obtaining private information.

Example: A phone doesn’t allow apps to use its onboard camera unless user permission is granted. It informs the user of the requested use with justification from the app developer, and prompts the user to accept or decline.

References:

• NCSC Zero trust architecture principles 2 and 5
• MITRE: T1548.002 Bypass User Account Control
• MITRE: T1574.005 Executable Installer File Permissions Weakness
• MITRE: T1078 Valid Accounts
• MITRE: T1222 File and Directory Permissions Modification
• NIST SP 800-213A: Device Security − Secure Resource Usage

This guideline applies to all devices.

Tasks running with minimal permissions will have minimal access to data and other tasks, as well as the operating system. If compromised, a task running with minimal permissions limits the impact of the compromise, unless the attacker can escalate privilege.

For devices that are permitted to install new software, this capability provides a mechanism for the organisation to set appropriate privileges or permissions for that software.

Example: Networking software on a device only has access to the data and functions it requires to operate and doesn’t have administrator permissions. If compromised, the attacker can’t use the device to access privileged data and systems.

References:

NCSC Zero trust architecture principles 1, 2, 3, 4 and 5

MITRE: T1222 File and Directory Permissions Modification

This guideline applies to all devices.

Most operating systems support ‘user’ and ‘admin’ permission models (or similarly ‘root’ and ‘application’). Elevating to admin is often necessary for tasks such as software installation, but gives overly permissive access to a user or application. A granular permissions model allows these activities, without the undue risk that comes with elevating to full administrator level. Implementing the principle of least privilege will ensure that each user level process has just enough permissions to function correctly, and can’t access any further if compromised.

Example: The camera software in an IoT device requires administrator-level access to the camera hardware. It doesn’t require any other administrator privileges and the manufacturer hasn’t granted any. This means that if compromised, the attacker can’t access administrator functionality.

If components in a device have wider access to administrator privileges, an attacker who compromises a component or piece of software would use administrator privileges to more easily compromise the whole system.

References:

• NCSC Zero trust architecture principles 2, 3, 4 and 5
• MITRE: T1134 Access Token Manipulation
• NIST SP 800-213A: Logical Access to Interfaces − Role Support and Management

This guideline applies to all devices.

When software components are running on the same device, they have access to the same resources, and may affect each other. Even if there is proper permissions control, there remains some possibility of interaction between them via shared resources such as memory. Complete compartmentalisation ensures that each component only interacts with the specified resources that it needs to run, making it difficult for an attacker who compromises one component to escalate privilege, or gain control of further components.

Example: The network controller in a device is run in a VM, through which it has access to the networking hardware and can call on the required OS functions. But it has no access to other components running in their own VMs.

Example: Applications are separated by ensuring that each runs within its own virtual sandbox. Each has its own isolated runtime environment preventing access to other applications' resources.

If each software component is separated by virtualisation, with separation enforced by a hypervisor, an attacker who compromises one component would need to break out of the virtualisation to compromise other components.

Other techniques such as Mandatory Access Control (MAC) ensure that only authorised users or processes have access to required resources. This is an alternative approach to virtualisation, ensuring that even if compromised, running processes can only access the intended software, system and files. This is enforced by the OS or kernel which checks that the credential of the process or executable has the correct privilege level to access the resource.

References:

• NCSC Zero trust architecture principles 2, 3 and 5
• MITRE: T1189 Drive-by Compromise
• MITRE: T1190 Exploit Public-Facing Application
• NIST SP 800-213A: Device Security

- Secure Execution
- Secure Resource Usage

This guideline shall apply to all devices.

It's important the device is only distributed with the software or hardware components required for its purpose. It shouldn’t include non-functional code or hardware, which may make the device more vulnerable to attack without offering any value, but simply increasing the attack surface. Commonly, this includes debug tools or hardware that attackers often exploit to gain access to the device, or the data stored on the device.

Example: A device that doesn’t support connection over SSH or Telnet doesn’t have software supporting those protocols, even if not running by default.

Example: Libraries and tools used for debug, or that are no longer needed due to deprecation, are removed from the device.