Guidance

End User Devices Security Guidance: General Security Recommendations

Updated 14 October 2013

1. Philosophy of the approach

This guidance builds upon the strategic goals described in the End User Device Strategy: Security Framework & Controls document, which are to:

  • make optimum use of native security functions, avoiding third-party products wherever possible

  • make better use of controls around the data and services where they can often be more effective, rather than adding additional complexity to devices

  • allow greater user responsibility to reduce security complexity, maintaining user experience for the majority of responsible users

  • logging and audit preferred over prevention and control, to maintain user experience and flexibility for the majority of responsible users

  • develop a single and sufficient specification for accessing OFFICIAL, including OFFICIAL SENSITIVE, recognising many of the controls will be at the service side

  • enable transparency and clarity to widen a correct understanding of the security recommendations, widening the market of potential suppliers, and driving down over­-specification of security

  • enable informed risk management and justification of security controls through traceability between threats, their methods of attack and suggested mitigations

  • enable greater interoperability of IT systems through a more common and consistent approach to securing OFFICIAL information

Each platform in this guidance has been considered as part of an enterprise deployment to see how effectively it is able to protect OFFICIAL information as part of an enterprise managed network. The guidance is holistic - it is not simply about applying settings to a device, but is also about making informed network architecture decisions; providing appropriate guidance and training for users; and performing operational maintenance, monitoring and defence of the network.

2. End User Devices: Generic Security Recommendations

The EUD Security Framework describes the following twelve areas for security controls for devices, each of these areas must be considered when deploying a particular solution. The areas comprise:

2.1 Assured data-in-transit protection

An IPsec client which is assured to Foundation Grade against the IPsec VPN for Remote Working ­Software Client Security Characteristic, configured in accordance with the PSN end-state­ IPsec profile or PSN interim IPsec profile.

2.2 Assured data-at-rest protection

Data stored on the device is satisfactorily encrypted when the device is in its “rest” state. For always-­on devices, this is when the device is locked. Formal assurance of this function to Foundation Grade against the appropriate Security Characteristic is strongly recommended.

2.3 Authentication

Three types of authentication are recommended:

  • 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.

2.4 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.

2.5 Platform integrity and application sandboxing

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

2.6 Application whitelisting

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

2.7 Malicious code detection and prevention

The device can detect, isolate and defeat malicious code which has somehow become present on the device.

2.8 Security policy enforcement

Security policies set by the enterprise are robustly implemented across the platform. The enterprise can technically enforce a minimal set of security­ critical policies on the device and these security­ critical policies cannot be overridden by the user.

2.9 External interface protection

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

2.10 Device update policy

Security updates can be issued by the enterprise and the enterprise can remotely validate the patch level of the device estate.

2.11 Event collection for enterprise analysis

The device reports security ­critical events to an enterprise audit and monitoring service. The user is prevented from tampering with the reporting of events from the device.

2.12 Incident response

The enterprise has a plan in place to respond to and understand the impact of security incidents, such as the loss of a device. This should be supported by appropriate functionality within the devices and the enterprise, such as sending a wipe command to the device and revoking credentials.