This publication provides guidance on how to securely configure iPod Touch, iPhone and iPad devices running iOS 9.3.5 or higher.
First published for iOS 4 in 2011; updated for iOS 9 in August 2016
About this guide
This guide provides instructions and techniques for Australian government agencies to harden the security of iOS 9 devices.
Implementing the techniques and settings found in this document can affect system functionality, and may not be appropriate for every user or environment.
In these cases, agencies should seek approval for non-compliance from their accreditation authority to allow for the formal acceptance of the risks involved. Refer to System Accreditation and Product Selection chapters of the Australian Government Information Security Manual (ISM) for more information.
ASD has completed an ASD Cryptographic Evaluation (ACE) of Apple iOS 9 scoped to review the data-at-rest and data-in-transit functionality and, when configured appropriately, has been found to be suitable for downgrading the handling requirements for data-at-rest and data-in-transit of PROTECTED information to that of UNCLASSIFIED.
Please refer to the consumer guide for further details on the scope and findings of the ACE. When completed, the consumer guide will be posted on the ASD Evaluated Products List (EPL).
This document is based on the findings of the ACE and provides policy advice that must be enforced for PROTECTED iOS device deployments. Guidance in this document will also assist agencies to comply with existing policies when deploying iOS devices at lower classifications.
Additionally, the latest version of Apple iOS on iPhone, iPad and iPod Touch has completed evaluation of the:
- Common Criteria Mobile Device Fundamentals Protection Profile, version 2.0
- Mobile Device VPN Client Protection Profile, version 2.0, and the
- Mobile Device Management Client Protection Profile, version 2.0
Future versions of iOS
ASD expects a new major version of Apple iOS to be released in the near future. As usual, iOS 9 will no longer be available for download from Apple as a result. When the new iOS version is released, ASD will assess the security implications and provide additional guidance if required.
In the interim, ASD advises the following:
- Upgrade to the latest version of iOS. Even though new versions were not the target of the evaluation, this version does provide security enhancements and addresses known vulnerabilities. This is consistent with ASD’s advice to install the latest versions of software and patch operating system vulnerabilities as communicated in the ISM and Strategies to Mitigate Cyber Security Incidents.
- Implement the current iOS Hardening Configuration Guide. The existing guide is applicable to new versions of iOS and updated guidance will contain additions in response to new features, rather than wholesale changes to the existing advice.
As in any case where significant updates of a previously released version of iOS, Apple provides detail of the content of security updates. This information may help agencies quantify the risk posed by not updating.
iOS and the Australian Government Information Security Manual
This guide reflects policy specified in the Australian Government Information Security Manual (ISM). Currently, not all ISM requirements can be implemented on iOS 9 devices. In these cases, risk mitigation measures are provided in the Risk Management Guide at Chapter 11.
Chapter 6 provides recommended passcode settings for iOS devices. This advice has been developed based on an assessment of security risks related specifically to iOS 9, and takes precedence over the non-platform specific advice in the ISM.
This guide is for users and administrators of iOS 9 or later devices. These devices include the iPod Touch, iPhone and iPad.
To use this guide, readers should be:
- familiar with basic networking concepts
- an experienced systems administrator.
Parts of this guide refer to features that require the engagement of the technical resources of agency telecommunications carriers, firewall vendors or Mobile Device Management (MDM) vendors. While every effort has been made to ensure content involving these third-party products is correct at the time of writing, agencies should always check with these vendors when planning an implementation.
Mention of third-party products is not a specific endorsement of that vendor over another; they are mentioned as illustrative examples only.
Some instructions in this guide are complex and, if implemented incorrectly, could reduce the security of the device, the network and the agency’s security posture. These instructions should only be used by experienced administrators, and should be used in conjunction with thorough testing.
For further clarification or assistance, Australian government IT security advisors can contact ACSC.
iOS 9 has brought with it several important new features and improvements that are relevant to deployment in government and enterprises.
Device Enrolment Program
Although Device Enrolment Program (DEP) is not strictly an iOS 9 feature, as it became available in Australia during the time of iOS 8, it was not widely available from carriers and Apple resellers supplying government purchasing panels until late 2015. Frequently, but not always, devices purchased after 2 March 2011, but prior to availability of DEP, can be retrospectively enrolled by the reseller. Whilst DEP is a free service from Apple, resellers can (but rarely do) charge a fee. A fee for DEP enrolment is most common when devices purchased earlier are retrospectively enrolled.
DEP is of significance for multiple reasons:
- it gives a level of supply chain assurance from factory to the end customer agency
- the setup assistant can be customised to only display selected screens, and users can enrol in Mobile Device Management (MDM) inside the Setup Assistant, without needing an app from the MDM vendor
- it can assign devices automatically to an MDM, without use of Apple Configurator 2
- it can ensure devices are placed in supervised mode, over the air, without use of Apple Configurator 2. Supervision enables additional policy controls, and management of capabilities such as Lost Mode and Activation Lock
- it is the only way to make MDM enrolment mandatory and non-removable (even following a device wipe, the device is forced to re-enrol in MDM, whilst still inside the setup assistant).
Device-based app assignment
Mobile Device Management servers and Apple Configurator can assign institutionally-licensed apps purchased under the Volume Purchase Program directly to devices, without needing an AppleID on the device. An AppleID may be needed if other Apple services are used e.g. iMessage, personally-installed apps from the App Store or iCloud. Coupled with DEP and MDM, this significantly simplifies institutionally-owned device deployment workflows.
Enterprise Developer verification
The trust model of enterprise in-house apps has changed from iOS 8. Under iOS 9, apps installed as the result of an MDM command lead to the associated Enterprise Developer code-signing certificate being implicitly trusted. If users manually install enterprise-signed apps, they now need to navigate to the settings and explicitly trust the signing certificate. There is no longer a dialogue at app launch that lets users trust the certificate. Devices also periodically check a list of revoked Enterprise Developer code-signing certificates available at ppq.apple.com. These changes are designed to make it more difficult for users to be socially-engineered to install enterprise apps from non-trusted sources. This means that even with deployments relying solely on enterprise apps, devices MUST be able to reach ppq.apple.com, or devices need to be periodically re-imaged from Apple Configurator 2 (as the enterprise apps will eventually fail to launch if they repeatedly can’t reach ppq.apple.com).
App Transport Security
In iOS 7 and 8, Apple transitioned the default data protection class of all apps to “ProtectionCompleteUntilFirstUserAuthentication”, which is semantically similar to full disk encryption. This assists in mitigating the security risk of a jailbreak being used to access app data. Developers can opt in to more restrictive data protection classes e.g. ProtectionComplete, which is only accessible when the device is currently unlocked. This data protection class MUST be used for data classified PROTECTED, and is available as a toggle in Xcode for the developer at compile time. If an app is required to write PROTECTED data while in a locked state, such files must be protected using Class B NSFileProtectionCompleteUnlessOpen.
In iOS 9 and Xcode 7, Apple has attempted to address the data-in-transit issue, and introduced App Transport Security (ATS). ATS forces the default transport security for any app using the SecureTransport APIs (typically NSURLSession) to use TLS 1.2 with forward secrecy ciphers. These are both ASD Approved Cryptographic Algorithms (AACA) and ASD Approved Cryptographic Protocols (AACP). Until 31 December 2016, developers have the ability to explicitly downgrade the transport security of an app. This is documented explicitly in the app’s “exception.plist”. App developers MUST NOT disable ATS for PROTECTED data. After 1 January 2017, all apps submitted to the App Store must use ATS. If a developer does not use Secure Transport or ATS, the app’s method for securing data-in-transit must comply with the relevant ISM controls.
New configuration profile controls
New management and supervisory controls have been made available to iOS enterprise fleet administrators. Refer to Recommended Device Profile Settings for our updated advice.
Improved VPN functionality
iOS 9 contains several under-the-hood changes to VPN behaviour with the new Network Extension framework. The most significant change for this guide is that the built-in IPSec IKEv2 VPN agent is now available for use in a per-app VPN configuration, in addition to Always On VPN configuration. The IPSec IKEv2 VPN client is evaluated and is the preferred VPN transport. Refer to the VPN section for detail.
Exchange ActiveSync version 16
iOS 9 supports Exchange ActiveSync version 16 (EAS 16), which includes a significant re-write of the calendaring protocol.
EAS 16 is currently available though Microsoft’s Office 365 service, and is expected to become available for on-premises deployments in an update to Windows Server some time in 2016. On iOS, EAS 16 brings Exchange calendaring up to feature parity with CalDAV, and for the first time allows for attachments to calendars to be synced to a mobile device. This is significant, because whilst the native Mail app in iOS is suitable for holding attachments with PROTECTED content, at the time of writing, the native Calendar app is only suitable up to FOUO or UNCLASSIFIED with DLM. Agencies should consider the residual security risk and mitigation measures when upgrading servers to an Exchange version that supports EAS 16.
iOS 9.3 enables a supervised device to be placed in 'Lost Mode'. This mode turns on Location Services (even if it has been disabled) and reports the device location to the MDM server. The device lock screen displays that the device is in Lost Mode. MDM can also disable Lost Mode. Once the device is unlocked by the user, they are presented with a modal dialog that states that the device was placed in Lost Mode at a specific date and time. Location Services is returned to its previous state when the device exits from Lost Mode. No Apple ID is required for this functionality, just supervision and MDM (noting that it is similar to Lost Mode controlled at a user level provided by the Find My iPhone capability in iCloud).
Advice has been updated throughout the guide based upon the experiences of Australian Government agencies and from industry. If you have feedback, please contact ACSC.
Table of contents
- Introduction to mobile device security
- Security features and capabilities
- Encryption in iOS
- Deploying iOS devices
- Managing apps and data
- Suggested policies
- Recommended device settings
- Mobile device management
- Security checklist
- Example scenarios
- Risk management guide
- Firewall rules
Organisations or individuals with questions regarding this advice can contact the ACSC by emailing firstname.lastname@example.org or calling 1300 CYBER1 (1300 292 371).