Device security principles for manufacturers
Principles to guide manufacturers in the design of secure, enterprise-connected devices.
Pages
Page 12 of 12
11. Enable recovery to a known good state
Many devices will be compromised or infected at some point but some users or organisations might be reluctant to dispose of an affected device, particularly if there is uncertainty about whether a compromise has definitely occurred.
It’s important that a device can be recovered into a known good state through a factory reset or another method to wipe all potentially harmful data from the device. Organisations won’t then have to choose between using a potentially infected device and purchasing new devices in the event of a possible compromise.
Guideline 11.1: The device shall be capable of being reset into a ‘known state’
This guideline applies to all devices.
If an organisation resets a device, it’s important that previously patched vulnerabilities aren't reintroduced. A good ‘known state’ is one where the organisation has confidence that a build is stable and only uses versions of the operating system or system software that are still trusted (through mechanisms such as signatures) by the manufacturer. The organisation can then isolate the device or provide it with limited network access to update, or be reconfigured.
This guideline includes the firmware and the operating system. If a patch for any software component is the source of a security flaw which means the device has to be reset, the flaw can’t be reintroduced when the device is recovered.
Example: An organisation resets a laptop to a build and stable version in which it has confidence. During this process, the organisation can prevent deploying versions of the operating system which they deem no longer compliant with their device policy and no longer supported. This prevents the reintroduction of critical vulnerabilities that undermine their definition of a good known state.
Example: To restore it to a known good state, a video conferencing system can be reset to factory settings, either physically or remotely, through a device’s management system.
References:
- ETSI EN 303 645: Ensure software integrity
- MITRE: T1211 Exploitation for Defence Evasion
- NCSC Zero trust architecture principles:
- NIST SP 800-213A: Data Protection − Secure Storage
- NIST SP 800-213A: Cybersecurity State Awareness − Event Response
Guideline 11.2: It should be possible to remotely wipe the device
This guideline applies to all devices.
If a device is compromised, it won’t necessarily happen in an office environment, or with easy access to an organisation’s IT team. If it can’t be reset by the organisation remotely, the organisation loses control of the device and its data. But by remotely wiping the device, an attacker can no longer exploit the data or device.
If it’s not possible for a device to meet this guideline, an organisation will need to take other actions to restrict access to corporate resources, if the device is known to be compromised.
Example: If an organisation decides that a device is known to be compromised and can’t be reset, it uses a MDM platform to purge the device, removing its ability to access corporate resources completely.
References:
- ETSI EN 303 645: Make installation and maintenance of devices easy
- MITRE: T1068: Exploitation for Privilege Escalation
- MITRE: T1053 Scheduled Task/Job
- MITRE: T1547 Boot or Logon Autostart Execution
- NCSC Zero trust architecture principles:
- NIST SP 800-213A: Data Protection − Secure Storage
- NIST SP 800-213A: Cybersecurity State Awareness − Event Response
Guideline 11.3: It should be possible to lock the device remotely through device management platforms
This guideline applies to all end user devices.
It’s not uncommon that employees will lose or have their organisation-owned devices stolen. If a device can’t be remotely locked, a potentially hostile individual may be able to gather data from the devices with minimal intrusive physical attacks.
Example: A user in an organisation loses a smartphone while working overseas and notifies the security team. The organisation can remotely lock the device (which is connected to the internet via its mobile data connection), reducing the likelihood that the device will leak or display sensitive information.
References:
- MITRE: T1592 Gather Victim Host Information
- ETSI EN 303 645: Make installation and maintenance of devices easy
- NCSC Zero trust architecture principles:
- NIST SP 800-213A: Data Protection − Secure Storage
- NIST SP 800-213A: Cybersecurity State Awareness − Event Response
Guideline 11.4: Linking data stored on the device with enterprise data repositories enables the backup and sync of data
- Laptops, desktops and mobile devices shall have a mechanism for linking on-device user data storage with enterprise data repositories
- All other device types can have a mechanism for linking on-device user data storage with enterprise data repositories
When a device is compromised, any data stored on it may be lost during the recovery process. This means that if user data is only located on the device, it will be lost by the organisation. Being able to link a device natively to corporate data repositories reduces friction for users to store data appropriately. There are many data repositories on the market, and an organisation will want to be able to choose their preferred option.
Example: A smartphone allows integration with cloud storage providers in its file picker menus.
Example: An organisation picks its preferred cloud storage provider and expects that it will integrate natively.
References:
- MITRE: T1565 Data Manipulation
- MITRE: T1485 Data Destruction
- NCSC Zero trust architecture principles:
- NIST SP 800-213A: Data Protection − Secure Storage