End User Devices Security Guidance: Apple iOS 8

End User Devices Security Guidance: Apple iOS 8
End User Devices Security Guidance:
Apple iOS 8
1. Changes since previous guidance
2. Usage scenario
3. Summary of platform security
4. How the platform can best satisfy the security
5. Network architecture
6. Deployment process
7. Provisioning steps
8. Policy recommendations
9. Enterprise considerations
This guidance is applicable to devices running iOS 8.0. This guidance was developed following testing
performed on iPhone 5S device running iOS 8.0.
1. Changes since previous guidance
This document is an update of the previous iOS 7 guidance to cover iOS 8. Some changes to the
recommended configuration have been made to take account of new features and changed behaviours in the
platform. iOS 8 introduces a number of updates which have particular security considerations. However, these
can be effectively managed using techniques highlighted previously in iOS 7.
Deployments which followed the previous iOS 7 guidance can update the configuration of those devices to
ensure that when the devices are updated to iOS 8, the always­on VPN will automatically connect. It will be
necessary to update the supporting infrastructure to make use of the new IKEv2 always­on VPN. There are
several benefits to adopting the new iOS 8 always­on VPN:
Users cannot disable the device VPN, lowering the risk of data being transmitted outside the VPN.
The VPN does not disconnect when the screen is locked, permitting push notifications for email and
incoming Voice over IP calls to work.
Local Wi­Fi traffic cannot transit outside the VPN (unless explicitly permitted), lowering the risk of
compromise on a hostile Wi­Fi network.
If you have previously decided a carrier­provided Access Point Name (APN) is required to mitigate certain
risks then nearly all of those risks will be mitigated by using the always­on VPN, allowing the APN to be
removed from the architecture.
The previous iOS 7 (and below) approach to the VPN can still be used in iOS 8, though the risks associated
with the previous approach must be considered if this option is taken.
2. Usage scenario
iOS devices will be used remotely over 3G, 4G and non­captive Wi­Fi networks to enable a variety of remote
working approaches such as:
accessing OFFICIAL email
reviewing and commenting on OFFICIAL documents
accessing the OFFICIAL intranet resources, the Internet and other web­resources
To support these scenarios, the following architectural choices are recommended:
All data should be routed over the native IKEv2 always­on enterprise VPN to ensure the Confidentiality and
Integrity of the traffic, and to allow the devices and data on them to be protected by enterprise protective
monitoring solutions.
Arbitrary third­party application installation by users is not permitted on the device. An enterprise application
catalogue should be used to distribute in­house applications and suitable assessed third­party applications.
CESG guidance on third­party application development for iOS can be used to assist with this process.
3. Summary of platform security
This platform has been assessed against each of the twelve security recommendations, and that assessment
is shown in the table below. Explanatory text indicates that there is something related to that recommendation
that the risk owners should be aware of. Rows marked [!] represent a more significant risk. See How the
platform can best satisfy the security recommendations for more details about how each of the security
recommendations is met.
1. Assured data­
The built­in VPN has not been independently assured to Foundation Grade, and no suitable
third­party products exist.
2. Assured data­
at­rest protection
iOS data protection has not been independently assured to Foundation Grade. Only
applications which opt to use the relevant Data Protection APIs on iOS will have their
sensitive information protected when locked (rather than powered off).
3. Authentication
4. Secure boot
5. Platform
integrity and
App groups can be used by developers to allow their applications access to a shared
storage container, shared preferences and shared keychain. 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.
6. Application
Not all classes of application extension respect managed to unmanaged application
restrictions (e.g. a sharing extension may allow PDF documents to be shared from the
managed email app to an unmanaged sharing provider app). Administrators should pay
particular attention to the extensions installed by whitelisted applications, to ensure that
managed documents are not able to be trivially shared outside of managed applications.
7. Malicious code
detection and
8. Security policy
Policy settings applied through Apple Configurator cannot be overridden (when using
recommended security settings). However, MDM profiles can be removed by the user. The MDM APIs offer a limited set of controls. 9. External
Radio interfaces such as Wi­Fi and Bluetooth cannot be controlled by policy.
10. Device update
11. Event
collection for
[!] There is no facility for collecting logs remotely from a device, and collecting forensic log
information from a device is very difficult.
12. Incident
iOS devices can be remotely locked, wiped, and reconfigured by their MDM.
3.1 Significant risks
The following key risks should be read and understood before the platform is deployed.
The VPN has not been independently assured to Foundation Grade. Without assurance in the VPN there is
a risk that data transiting from the device could be compromised.
iOS data protection has not been independently assured to Foundation Grade. However, CESG has
previously determined that the level of protection is commensurate with Foundation Grade 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, including e­mail 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). Developers can then choose whether to
opt­out of this encryption entirely, or opt­in to the highest encryption class (encrypted when locked).
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.
Collection of events for enterprise analysis is limited, meaning protective monitoring and forensic analysis
following any compromise may be much more difficult than on other platforms.
There are no policy controls available to restrict the external interfaces a user can enable, meaning that
external interfaces may be accidentally or deliberately enabled by the end­user. Enabling external interfaces
means increasing the exposed attack surface, and data could be inadvertently or maliciously leaked without
enterprise visibility.
Procedural controls must be used to achieve some of the requirements where no technical controls could be
used, which 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.
4. How the platform can best satisfy the security
This section details the platform security mechanisms which best address each of the security
4.1 Assured data­in­transit protection
iOS 8 provides a new native IKEv2 VPN client which can be configured in an ‘Always On’ mode to guarantee
all traffic is routed through the organisational infrastructure for inspection. The native IKEv2 VPN client should
be used until a Foundation Grade VPN client for this platform becomes available.
4.2 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 can also request this protection class to gain the benefit of the
4.3 Authentication
The user should use a strong 7 character password to authenticate themselves to the device. This password
unlocks a key which encrypts certificates and other credentials, giving access to enterprise services.
4.4 Secure boot
This requirement is met by the platform without additional configuration.
4.5 Platform integrity and application sandboxing
This requirement is met by the platform without additional configuration. A new feature of iOS 8 is that
applications may install extensions. Although extensions allow applications to share data and provide extended
functionality to each other, they are sandboxed in the same manner as other applications.
4.6 Application whitelisting
An enterprise application catalogue can be established to permit users access to an approved list of in­house
applications. If the App Store is enabled, the MDM can be used to monitor which applications a user has
Extensions (a new feature of iOS 8) 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 must be fully 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).
4.7 Malicious code detection and prevention
The enterprise app catalogue should only contain in­house applications and third­party applications which have
been approved by an administrator. Content­based attacks can be filtered by scanning on the email server.
4.8 Security policy enforcement
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. However, this will also remove any data stored as part of accounts configured through
MDM (e.g. e­mail and credentials). When configuring an MDM, it should be configured such that (i) arbitary
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.
It is recommended that email accounts are provisioned via MDM, as only email accounts provisioned via MDM
will operate correctly with restrictions to disallow opening documents in unmanaged applications (Managed
Open In).
4.9 External interface protection
The USB interface is used by Configurator to put the device into supervised mode, and to install configuration
profiles. No technical controls exist to prevent users from enabling Wi­Fi and Bluetooth.
4.10 Device update policy
Users are free to update applications and firmware when they wish, though the enterprise 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.
4.11 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.
4.12 Incident response
iOS devices can be locked, wiped, and configured remotely by their MDM.
5. Network architecture
All remote or mobile working scenarios should use a typical remote access architecture based on the Walled
Garden Architectural Pattern. The following network diagram describes the recommended architecture for this
Recommended network architecture for deployment of iOS 8
A Mobile Device Management server is required. Apple’s OS X Server with Profile Manager is sufficient for
this purpose. Alternatively, third­party products exist which may offer additional functionality over and above
Profile Manager.
6. Deployment process
The steps below should be followed to prepare the enterprise infrastructure for hosting a deployment of these
1. Deploy OS X 10.9.5+ and install iTunes 11.4(18)+ and Apple Configurator 1.6(445)+ onto a dedicated
provisioning terminal.
2. Procure, deploy and configure other network components, including an approved IPsec VPN Gateway.
3. Set up the MDM and create policies for users and groups in accordance with the settings later in this
7. Provisioning steps
The steps below should be followed to provision each end user device onto the enterprise network to prepare it
for distribution to end users:
1. For devices with Touch ID, the feature should be disabled (as MDM only “locks” the setting to its current
value rather than turning it off).
2. Use Configurator to supervise the iOS devices (this is necessary for the “supervised only” restrictions
enforced via the MDM to be effective).
3. Enrol the devices into the MDM deployed earlier and install the predefined configuration profile.
4. Apply any additional required security controls by using the Restrictions menu locally on the device.
8. Policy recommendations
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.
8.1 Configurator settings
These settings should be applied to the device by creating profiles in the Configurator utility.
Configuration Rule
Configuration Setting
General Group
Security (user can remove profile)
Automatically Remove Profile
Allow devices to connect to other Macs
The Global HTTP Proxy settings should also be set to match your particular network configuration for when the
device is connected to the VPN.
8.2 MDM settings
These settings should be applied to the device by creating profiles on the MDM server.
Passcode Group
Allow simple value
Require alphanumeric value
Minimum passcode length
Minimum number of complex characters
Maximum passcode age
90 (days)
Maximum Auto­Lock
5 (minutes)
Passcode history
Maximum grace period for device lock
5 (minutes)
Maximum number of failed attempts
Security & Privacy
Privacy: Allow sending diagnostic and usage data to Apple, and sharing crash data and statistics
with app developers
Restrictions Group
Allow installing apps
Allow screenshots
Allow installing configuration profiles (supervised devices only)
Allow iCloud backup
Allow iCloud documents & data
Allow iCloud keychain
Allow iCloud photo sharing
NEW: Allow backup of enterprise books
NEW: Allow managed apps to store data in iCloud
NEW: Allow Handoff
NEW: Allow notes and highlights sync for enterprise books
Force encrypted backups
Allow users to accept untrusted TLS certificates
Allow Siri whilst device is locked
Allow modifying account settings (supervised devices only)
Allow documents from managed sources in unmanaged destinations
Allow sending diagnostic and usage data to Apple
Allow AirDrop (supervised devices only)
Allow Touch ID to unlock device
Show Control Center in Lock screen
Show Today view in Lock screen
NEW: Allow Internet results in spotlight
Show notification center in lock screen
If you are using Profile Manager, you should ensure that the option to sign configuration profiles is selected.
Other MDMs may have a similar option which should be selected.
8.3 On­device notifications menu
To prevent sensitive data appearing on the lock screen, the following settings should be set on each device.
Configuration Rule
Recommended Setting
Messages ­ Show Previews
Mail ­ Show Previews
8.4 On­device restrictions menu
These settings should be set on each device.
Configuration Rule
Recommended Setting
Contacts ­ Don’t allow changes
Calendars ­ Don’t allow changes
Photos ­ Don’t allow changes
As per organisational policy
Share My Location ­ Don’t allow changes
Bluetooth Sharing ­ Don’t allow changes
Allowing changes to these restrictions will allow 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
having Location Services enabled is not necessary. In these scenarios, the use of the above restrictons
settings is not necessary.
8.5 VPN profile
The deployed VPN solution should be configured to negotiate the following parameters. Not all of these
settings can be configured on the device so the configuration needs to also be enforced from the VPN server.
Module / Algorithm Type
Algorithm Details
AES­128 in CBC
Diffie Hellman Group
14 (2048 bits)
Note that for an iOS device to verify the VPN server certificate, the certificate must have an alternate subject
name entry that matches the common name. Further information on the supported server configurations can be
found at http://help.apple.com/deployment/ios/ 9. Enterprise considerations
The following points are in addition to the common enterprise considerations, and contain specific issues for
iOS deployments.
9.1 App Store applications
The configuration given above prevents users from accessing the App Store to install applications, but an
organisation can still host its own Enterprise App Catalogue to distribute applications to their employees if
9.2 Cloud integration
As with iOS 7 previously, iOS devices do not need to be associated with an Apple ID to operate as required
within an enterprise. For example, it is still possible to receive push notifications, and to install enterprise
applications without associating to an account. However, an Apple ID is required to obtain applications from
the App Store, and to use certain other on­device services.
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 who wish to prevent this should
implement controls to prevent users from enabling unneeded iCloud services on their device, thereby
preventing enterprise data from being synchronised with Apple servers.
9.3 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
9.4 Unmarked email domains
A new feature in 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.
9.5 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. Using Safari, documents downloaded from these domains are then 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.
Legal information
This guidance is issued by CESG, the UK's National Technical Authority on Information Assurance. One of the
roles of CESG is to provide advice to UK government entities and organisations providing services to UK
government. The guidance found here is provided and intended for use by this audience. It is provided 'as­is'
as an example of how specific requirements could be met. It should be used to help inform risk management
decisions on the use of the products described, but it should not be used for procurement decisions; it is not
intended to be exhaustive, it does not act as an endorsement of any particular product or technology, and it is
not tailored to individual needs. It is not a replacement for independent, specialist advice. Users should ensure
that they take appropriate technical and legal advice in using this and other guidance published by CESG. This
guidance is provided without any warranty of any kind, whether express or implied. It is provided without any
representation as to the accuracy, completeness, integrity, content, quality, or fitness for purpose of all or any
part of it. CESG cannot, then, accept any liability whatsoever for any loss or damage suffered or any costs
incurred by any person as a result of, or arising from, either the disclosure of this guidance to you, or your
subsequent use of it. This guidance is UK Crown Copyright. All Rights Reserved.
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF