Principle
Description
Data-in-transit protection
Data should be protected as it transits from the EUD to any services the EUD 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 organisation’s authentication policy. Further guidance on devising an authentication policy can be found below.
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 whitelisting
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 organisation are robustly implemented across the platform. The organisation 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 organisation 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 organisation. In the case of a lost device, this might entail sending a wipe command to the device and revoking credentials.
Source: NCSC
