Device security principles for manufacturers
Principles to guide manufacturers in the design of secure, enterprise-connected devices.
Pages
Page 7 of 12
6. Permit only trusted software
If users can run untrusted software on a device, an organisation is likely to be exposed to malware threats such as ransomware. Depending on the device, both the manufacturer and the organisation need to have the capability to determine which software they trust. This software also includes the operating system and any software to support peripherals such as device drivers.
Mechanisms for determining and defining which software is trusted will often rely on cryptographic methods and by determining an allowed list of apps that users can install within a device management platform. Organisations may require different user roles to establish who is trusted to install and run software at different levels of trust.
Guideline 6.1: It shall be possible to restrict the use of software based on trust
This guideline applies to all devices that support the addition of non-pre-installed software (both first and third party).
The ability to restrict software execution based on trust enables both end users and organisations to have confidence they approve of the software running on their devices. By allowing administrators to define levels of trust in software, the overall trust level is based on a combination of the user and the software. NCSC guidance on Using third-party applications on devices can help an organisation build that trust.
Example: Using an operating system implies trust between the user and manufacturer that the manufacturer will produce secure and trustworthy software. Restricting software to software only produced by the operating system manufacturer will guarantee that the software will run on the device and be supported.
Doing this will prevent untrusted or unknown software that could be malicious from executing on the user's device.
References for this guideline include:
- NCSC Zero trust architecture principles 2, 3, 4, 5, 6 and 7
- MITRE: T1204 User Execution
- NIST SP 800-213A: Logical Access to Interfaces − Limitations on Device Usage
Guideline 6.2: Access to trusted tools shall be configurable per user by the organisation
This guideline applies to all devices that support configurations per user.
Standard users don't require access to administrative tools such as cURL and PowerShell, and access to these tools should be configurable by the enterprise. Many of the administrative tools can be used by attackers to gain access to data and elevate access to a device.
Example: Attacks such as LOLBAS (living-off-the-land binaries and scripts) allow an attacker to use legitimate system tools and utilities to carry out attacks. Restricting access to these tools reduces the attack surface.
Example: Inbuilt scripting tools that are part the operating system are included with the device. Although these scripting platforms are often useful for system administrators, it's unlikely that all users require access.
Example: An embedded devices runs the pre-installed sshd service. The organisation disables this service for any user because it increases the device attack surface.
References:
- NCSC Zero trust architecture principles 2, 3, 4, 5 and 6
- MITRE: T1204 User Execution
- NIST SP 800-213A: Logical Access to Interfaces − Role Support and Management
- NIST SP 800-213A: Logical Access to Interfaces − Limitations on Device Usage
Guideline 6.3: Restrictions on executing software should be configurable based on users or groups
This guideline applies to all devices where users' roles are configurable and where a device has the concept of an assigned user.
This guideline allows administrators (or allows them to permit other users to) run less trusted software, to encourage the idea of role-based security.
Example: An admin can run third-party remote support software to debug a device, but the regular user of device is restricted from running this software.
This will also help reduce the attack surface if a malicious actor has gained access to a device used by role-based restricted users.
Example: A device used by a non-restricted user is compromised and the actor can now run any chosen software, including executables to elevate and propagate. Contrast this when a device used by a role-based restricted user is compromised, where the actor can only execute software to which that user has access. This significantly reduces the actor’s ability to elevate and propagate.
The NCSC provides guidance to organisations on secure system administration which advises that administrators and users have sufficient separation.
Example: Devices assigned to specific users such as mobile phones enforce restrictions on software installation, through the use of private app stores and through an MDM, including on a per user or group basis. This gives an organisation full control of the software used and restricts a malicious actor from running any other applications or encouraging the user to install a malicious app. These devices aren’t expected to meet this guideline, as they provide alternative approaches for managing this.
References:
- NCSC Zero trust architecture principles 2, 3, 4 and 5
- MITRE: T1204 User Execution
- NIST SP 800-213A: Logical Access to Interfaces − Role Support and Management
- NIST SP 800-213A: Logical Access to Interfaces − Limitations on Device Usage