12 Security Principles for Securing Devices

There are 12 principles for securing devices from The EUD Security Framework ¹, published in 2013, all of which must be considered when deploying a particular solution. These principles provide the basis for guidance for securing devices.

Data-in-transit protection

Data should be protected as it transits from the end user device to any services the end user device uses. IPsec VPNs provide the most standards-compliant way of doing this, but TLS VPNs or per-app TLS connections can also be used.

Formal assurance of this function to Foundation Grade against the appropriate Security Characteristic is strongly recommended.

Data-at-rest protection

Data stored on the device should be satisfactorily encrypted when the device is in its “rest” state. For always-on devices like smartphones, this is when the device is locked.

Formal assurance of this function to Foundation Grade against the appropriate Security Characteristic is strongly recommended.

Authentication

Each of the three types of authentication described here should be considered:

• User to device: the user is only granted access to the device after successfully authenticating to the device.
• User to service: The user is only able to access enterprise services after successfully authenticating to the service, via their device.
• Device to service: Only devices which can authenticate to the enterprise are granted access.

Each stage of the authentication process should be designed to complement the others, as part of your organization’s authentication policy.

Secure boot

An unauthorised entity should not be able to modify the boot process of a device, and any attempt to do so should be detected.

Platform integrity and application sandboxing

The device can continue to operate securely despite potential compromise of an application or component within the platform, and you have the ability to restrict the capabilities of applications on the device.

Application allow list

The enterprise can define which applications are able to execute on the device, and these policies are robustly enforced on the device.

Malicious code detection and prevention

The device can detect, isolate and defeat malicious code which is present on the device.

Security policy enforcement

Security policies set by your organization are robustly implemented across the platform. The organization can technically enforce a minimal set of security-critical policies on the device. These cannot be overridden by the user.

External interface protection

The device is able to constrain the set of ports (physical and logical) and services exposed to untrusted networks and devices. Any software exposed in this way is robust to malicious attack.

Device update policy

You are able to issue security updates and can remotely validate the patch level of your entire device estate.

Event collection for enterprise analysis

The device reports security-critical events to your audit and monitoring service. The user is prevented from tampering with this reporting.

Incident response

Your organization has a plan in place to respond to and understand the impact of security incidents. This should be supported by appropriate functionality within the devices and your organization. In the case of a lost device, this might entail sending a wipe command to the device and revoking credentials.

References

• End user device strategy: security framework and controls
• NCSC: Device Security Guidance