This guidance was developed following testing performed on an iPad Air device running iOS 10.0.2.
It’s important to remember that this guidance has been conceived as a way to satisfy the 12 End User Device Security Principles. As such, it consists of recommendations and should not be seen as a set of mandatory instructions requiring no further thought.
Risk owners and administrators should agree a configuration which balances business requirements, usability and security.
Risk owners’ summary
We recommend the following architectural choices for iOS 10:
- All data should be routed over the native IKEv2 always-on VPN to ensure the confidentiality and integrity of traffic. This also allows the devices and data on them to be protected by your organisation’s protective monitoring solutions.
- Users should not be permitted to install arbitrary third-party applications on the device. Your organisation’s application catalogue should be used to distribute in-house applications and suitable, assessed, third-party applications.
- Unless your organisation decides to use a particular third-party VPN, third-party VPN extensions should not be installed by users. Although VPN extension providers require entitlements to be granted by Apple when developing the extension, it may be possible that a malicious or poorly written VPN extension could be used to capture and log network traffic.
When configured in this way, risk owners should be aware of the following technical risks associated with this platform:
|
Associated security principle |
Explanation of risks |
|
Assured data-in-transit protection |
The built-in VPN client has been assured to Foundation Grade. |
|
Assured data-at-rest protection |
iOS data encryption has Foundation Grade approval for applications that use Data Protection APIs to protect data when the device is locked. Applications can choose classes of data encryption on a per-file basis. By default, only a limited number of files remain encrypted whilst the device is locked. This includes email and attachments (within the mail app), managed books and location data. Files belonging to other applications may not be encrypted when the device is locked, and could be extracted without knowledge of the password, using a vulnerability in the platform. Third-party applications are automatically opted in to the encryption class which protects their data when the device is in a powered-off state (but not when locked). This class protects data from attacks which require a reboot. Developers can then choose whether to opt out of this encryption class into a class which is always available, or opt in to the highest encryption class (encrypted when locked). |
|
Platform integrity and application sandboxing |
Sensitive data generated within one application may potentially be accessible to another if those applications are part of an app group. Application whitelisting can help mitigate this. |
|
Application whitelisting |
Not all classes of application extension respect managed to unmanaged application restrictions (e.g. a sharing extension may allow sensitive data to be shared to a social network). To ensure it’s not trivial to share managed documents outside of managed applications, administrators should pay particular attention to the extensions installed by whitelisted applications. |
|
Security policy enforcement |
Policy settings applied through Apple Configurator cannot be overridden (when using recommended security settings). However, Mobile Device Management (MDM) profiles can be removed by the user (unless DEP is used – see below). Apple’s Device Enrolment Program (DEP) can allow devices to be enrolled over-the-air during the device setup process. DEP can be used to limit the time a device is in a potentially hostile environment or configuration, and prevent removal of the MDM profile. Custom keyboards should not be deployed via MDM. Keyboards deployed via MDM are considered managed and can then be used within other managed applications such as the mail app. If the user allows “full access” to the keyboard extension (which may be required for its correct operation), it is then not restricted from logging and sending keystrokes to external servers. Procedural controls must be used to achieve some of the requirements where technical controls are not possible. This means that users have to be trusted not to alter certain settings on the device, or perform actions which may impact the security of the device. These controls are discussed in later sections. |
|
External interface protection |
Radio interfaces such as Wi-Fi cannot be controlled by policy. A new MDM policy setting (Allow modifying Bluetooth settings) has been added in iOS 10 to restrict Bluetooth modification. This could be set to further reduce the attack surface, but would prevent legitimate functionality. Enabling external interfaces means increasing the exposed attack surface, and data could be inadvertently or maliciously leaked without organisation visibility. Therefore a risk based decision should be made to determine if this control is appropriate. |
|
Event collection for enterprise analysis |
There is no facility for collecting logs remotely from a device, and collecting forensic log information from a device is very difficult. |
|
Incident response |
iOS devices can be remotely locked, wiped, and reconfigured by their MDM. |
Administrators’ deployment guide
Overview
To meet the principles outlined in the End User Devices Security Framework, several recommendations are given in the table below.
|
Security Principle |
Recommendation and Explanation |
|
Assured data-in-transit protection |
iOS 10’s native IKEv2 VPN client can be configured in an ‘Always On’ mode to guarantee all traffic is routed through your organisational infrastructure for inspection. This can protect data-in-transit and quickly switch between cellular and Wi-Fi networks. Alternatively, you also have the option to use a third-party VPN supporting the VPN Extension Point API. These extensions should be installed from a whitelist, if required by your organisation. This minimises the risk of a malicious or poorly-configured VPN extension finding its way onto a device. |
|
Assured data-at-rest protection |
iOS data protection is enabled by default. The Mail application uses Data Protection APIs to encrypt emails and attachments when the device is locked. By default, this level of protection also extends to location data and app launch images. Third-party developers need only request this protection class to gain its benefits. |
|
Authentication |
The user should be required to authenticate to the device in line with your organisation’s authentication policy (see Authentication Policy below). Authenticating to the device unlocks a key which encrypts certificates and other credentials, giving access to the organisation’s services. Touch ID permits biometric unlock of devices but the strength of its security is difficult to measure. In cases where there is a requirement to use biometric authentication, and the risks of using biometrics as the sole authentication mechanism are understood, Touch ID can be enabled. |
|
Secure boot |
No configuration is required. |
|
Platform integrity and application sandboxing |
No configuration is required |
|
Application Whitelisting |
An organisation application catalogue can be established to permit users access to an approved list of applications developed in-house, and an approved list on the App Store. Alternatively, the full App Store can be enabled, and Mobile Device Management (MDM) can be used to monitor which applications a user has installed retrospectively. Extensions are installed along with a containing application, and cannot be installed alone. It is therefore possible to apply application whitelisting rules that target these applications in order to restrict extensions. Administrators should be aware of the extensions installed by their whitelisted applications, to ensure that they do not introduce unexpected methods for sharing data outside of managed applications. It is not currently possible to define granular rules that block extensions, but permit the containing application (beyond implementation of managed/unmanaged application boundaries). |
|
Malicious code detection and prevention |
When configured as per this guidance, iOS will only be able to execute whitelisted applications from the App Store or Enterprise App Catalogue. Apps in the App Store have been scanned by Apple and any malicious content found is removed. Therefore, there is little additional value to be gained from any third-party anti malware products on the platform. |
|
Security policy enforcement |
A combination of either Configurator+MDM or DEP+MDM should be used to configure users’ devices. Settings applied through Apple Configurator can be configured such that they cannot be removed by the user. Policy applied through an MDM can be removed completely by an end user through removal of the Remote Management profile. This can be prevented if a Device Enrolment Program (DEP) is used. However, removing the Remote Management profile will also remove any data stored as part of accounts configured through MDM (e.g. email and credentials). When configuring an MDM, it should be configured such that: (i) arbitrary devices cannot be enrolled, (ii) end users are prevented from re-enrolling. Users should not be allowed to directly re-enrol, as it may be possible for the user to affect the security of the device by: (i) removing the MDM profile, (ii) modifying the on-device configuration options, (iii) re-enrolling the device through a self-service portal. Apple’s Device Enrolment Program should be considered to enable devices to register with the MDM Server during the setup process, decreasing the risk of a compromised device enrolling. Email accounts should be provisioned via MDM too, as only email accounts provisioned via MDM will operate correctly with restrictions to disallow opening documents in unmanaged applications (“Managed Open In”). This also means that if the MDM profile is removed, all credentials and data associated with that profile will also be removed. |
|
External interface protection |
The Configurator should be used to put the device into supervised mode, after which the user is only able to use the USB interface for charging their device. No technical controls exist to prevent users from enabling Wi-Fi. |
|
Device Update Policy |
Users are free to update applications and firmware when they wish, though your organisation can block this at the proxy server if desired. In addition, an MDM can be used to monitor the iOS versions currently installed and access could be revoked if necessary. |
|
Event collection for enterprise analysis |
iOS does not support remote or local historic event collection. Limited information regarding device state can be retrieved from the device. The features may depend on the MDM. |
|
Incident Response |
iOS devices can be locked, wiped, and configured remotely by their MDM. |
Recommended network architecture
All remote or mobile working scenarios should use a typical remote access architecture with a VPN terminating into a DMZ. The following network diagram describes this set up.
A Mobile Device Management server is required. Apple’s OS X Server with Profile Manager is sufficient for this purpose. Alternatively, many third-party products exist which may offer additional functionality over and above Profile Manager.
Preparation for deployment
The steps below should be followed to prepare your organisational infrastructure to host a deployment of these devices:
- Deploy OS X 10.12+ and Apple Configurator 2 onto a dedicated provisioning terminal.
- Procure, deploy and configure other network components, including an approved IPsec VPN Gateway.
- Set up the MDM and create policies for users and groups in accordance with the settings later in this section.
Device provisioning steps
The steps below should be followed to provision each end user device onto your organisation’s network, preparing it for distribution to end users:
- Use Configurator 2 to supervise the iOS devices (this is necessary for the “supervised only” restrictions enforced via the MDM to be effective).
- Enrol the devices into the MDM deployed earlier and install the predefined configuration profile.
- Apply any additional, required security controls by using the Restrictions menu locally on the device.
Alternatively, devices can be purchased through the Device Enrolment Program which means that the devices will be supervised ‘out of the box’, and can be configured to automatically enrol with the MDM server when first activated.
Recommended policies and settings
This section details important security policy settings which are recommended for an iOS deployment. Other settings (e.g. server address) should be chosen according to the relevant network configuration.
Remember, any guidance points given here are recommendations – they are not mandatory. Risk owners and administrators should agree a configuration which balances business requirements, usability and the security of the platform.
Configurator settings
In cases where Device Enrollment Program (DEP) is being used to enrol devices into the MDM server, this step can be omitted. In other cases, these settings should be applied to the device by creating profiles in the Configurator utility:
General Group |
|
|
Security (user can remove profile) |
Never |
|
Automatically Remove Profile |
Never |
|
Supervision |
On |
|
Allow devices to connect to other Macs |
No |
If not using the always-on IKEv2 VPN, the Global HTTP Proxy settings should also be set to match the network configuration for when the device is connected to the VPN.
MDM settings
These settings should be applied to the device by creating profiles on the MDM server:
|
Security & Privacy |
|
|
Privacy: Allow sending diagnostic and usage data to Apple, and sharing crash data and statistics with app developers |
No |
|
Restrictions Group |
|
|
Allow installing apps |
No |
|
Allow screenshots |
No |
|
Allow installing configuration profiles (supervised devices only) |
No |
|
Allow iCloud backup |
No |
|
Allow iCloud documents & data |
No |
|
Allow iCloud keychain |
No |
|
Allow iCloud photo sharing |
No |
|
Allow backup of enterprise books |
No |
|
Allow managed apps to store data in iCloud |
No |
|
Allow Handoff |
No |
|
Allow notes and highlights sync for enterprise books |
No |
|
Force encrypted backups |
Yes |
|
Allow users to accept untrusted TLS certificates |
No |
|
Allow Siri whilst device is locked |
No |
|
Allow modifying account settings (supervised devices only) |
No |
|
Allow documents from managed sources in unmanaged destinations |
No |
|
Allow sending diagnostic and usage data to Apple |
No |
|
Allow pairing with non-Configurator hosts (supervised devices only) |
No |
|
Allow AirDrop (supervised devices only) |
No |
|
Show Control Centre in Lock screen |
No |
|
Show Today view in Lock screen |
No |
|
Show Notification Centre in Lock screen |
No |
|
Allow Internet results in spotlight |
No |
If using Profile Manager, ensure that the option to sign configuration profiles is selected. Other MDMs may have a similar option which should be selected.
On-device notifications menu
To prevent sensitive data appearing on the lock screen, the following settings should be applied on each device:
|
Configuration Rule |
Recommended Setting |
|
Messages – Show Previews |
Disabled |
|
Mail – Show Previews |
Disabled |
These settings should be applied on each device.
|
Configuration Rule |
Recommended Setting |
|
Contacts – Don’t allow changes |
Enabled |
|
Calendars – Don’t allow changes |
Enabled |
|
Photos – Don’t allow changes |
As per organisational policy |
|
Share My Location – Don’t allow changes |
Enabled |
|
Bluetooth Sharing – Don’t allow changes |
Enabled |
Allowing changes to these restrictions will enable applications on the device to request access to the named data store. Any that are not required should be disabled.
To make the provisioning steps less onerous, the risks mitigated by these settings could also be met in other ways. Contacts, Calendars, Photos and Bluetooth permissions are only risky if third-party applications which use these permissions are installed on the device. Some users’ locations may not be sensitive, in which case Location Services may be enabled.
But where the user’s location is sensitive, Location Services should be disabled. In these scenarios, the use of the above restrictions settings are not necessary.
VPN profile
The deployed VPN should be configured according to the PRIME profile for IPSEC.
The recommended IPsec cipher suite profile for protecting information is called PRIME. A non-authoritative summary is provided in the table below:
|
IKEv2 |
Selection |
|
Encryption |
AES-128 in GCM-128 (and optionally CBC) |
|
Pseudo-random function |
HMAC-SHA256 |
|
Diffie-Hellman Group |
256bit random ECP (RFC5903) |
|
Group 19 Authentication |
ECDSA-256 with SHA256 on P-256 curve |
|
ESP |
Selection |
|
Encryption |
AES-128 in GCM-128 |
|
VPN Settings |
Value |
|
Dead peer detection interval |
Medium |
|
Enable perfect forward secrecy |
True |
|
Disable redirects |
False |
|
Disable mobility and multihoming |
True |
|
Enable certificate revocation check |
True |
|
VPN On Demand |
Always |
The deployed VPN solution should be configured to negotiate the parameters below. Not all of these settings can be configured on the device or MDM VPN profile, therefore the configuration also needs to be enforced from the VPN server.
Note that for an iOS device to verify the VPN server certificate, the certificate must have a Subject Alternative Name (SAN) entry that matches the common name. Further information on the supported server configurations can be found at https://help.apple.com/deployment/ios/
Authentication policy
Your organisation should have a consistent authentication policy which applies to all users and devices capable of accessing its data. You can use the published password guidance to help inform any password policy.
An administrator should configure the relevant on-device settings in line with your authentication policy.
For further guidance on authentication policies, see the NCSC EUD Authentication guidance.
To enforce this policy on iOS devices, the following settings are available, and should be set according to the policy:
- Allow simple value
- Require alphanumeric value
- Minimum passcode length
- Minimum number of complex characters
- Maximum Auto-Lock
- Passcode history
- Maximum grace period for device lock
- Maximum number of failed attempts
- Allow Touch ID to unlock device
Hardware strengthening
All devices since the iPhone 5S have a Secure Enclave Processor (SEP) which handles secure storage of cryptographic keys. A successful authentication against the SEP is required to grant access to the device and its data. This prevents offline, brute force attacks against data-at-rest keys. Online brute-force attacks are also prevented by the SEP, which locks after 10 unsuccessful attempts.
Biometrics
iOS 10 devices can use Touch ID for biometric authentication which happens within the Secure Enclave Processor. This means that a physical attack on a locked device should not result in compromise of data.
The fingerprint reader has a 0.002% false acceptance rate for a random fingerprint, but there have been published attacks on the feature using artefacts taken from the device. Using such attacks, a targeted physical attack on a specific user could result in the attacker gaining access to the device. You should consider these limitations when devising an authentication policy which permits the use of biometrics.
Other considerations
The following points are in addition to the common organisation considerations, and contain specific issues for iOS deployments.
Cloud integration
iOS devices do not need to be associated with an Apple ID to operate as required within an organisation. For example, it is still possible to receive push notifications, and to install organisation applications without an associated account. In addition, in iOS 9 Apple has removed the need for an Apple ID when installing applications using the Volume Purchase Program (VPP), further reducing the requirement for each user to have a provisioned Apple ID.
If an Apple ID is used to enable iCloud services on the device, then documents and other sensitive data may be inadvertently synchronised with iCloud. As a mitigation, organisations that wish to prevent this should implement controls to prevent users from enabling unneeded iCloud services on their device, thereby preventing organisation data from being synchronised with iCloud servers.
App groups
Apps and extensions that are produced by the same developer can potentially share content when configured as part of an ‘app group’. Sensitive application data could therefore be made available to another application on the device, potentially being shared from managed to unmanaged applications. Third-party applications should be reviewed to identify membership of an app group, and appropriate whitelisting should be applied where necessary.
Unmarked email domains
As with iOS 8+, “unmarked” email domains can now be configured. When a user is composing an email using the system email client, any email address entered which does not match the configured domains will be highlighted (marked) in red. Administrators should consider using this functionality, to warn users who may be inadvertently attempting to send sensitive information to untrusted email addresses.
Managed Safari web domains
In iOS 8+ a list of domains can now be configured that the device will treat as “managed” in the Safari web browser. When using Safari, documents downloaded from these domains are subject to “Managed Open In” rules and should not be accessible to unmanaged applications. Configuring these domains can help to stop sensitive documents from being trivially shared to other applications.
iOS 10 Lock screen widgets
A widget is an extension which can display content or information provided by an application. On iOS 10 a number of widgets are turned on by default and can expose information to the lock screen. In order to prevent data leakage via the lock screen, it is important that widgets are disabled. This can be enforced via MDM policies. It should be ensured that the “Show Today view in Lock screen” option is unticked to prevent this behaviour.
iOS 10 Universal Clipboard
iOS 10 Universal Clipboard allows sharing clipboard data between multiple devices registered on an iCloud account. Ensuring that handoff is disallowed in the MDM settings prevents the functionality of Universal Clipboard. As noted in the earlier section on iCloud integration, it is recommended that all iCloud settings are reviewed to ensure they are configured to prevent inadvertent synchronisation of data to iCloud.
Source: NCSC
