iOS Hardening Configuration Guide for iPod Touch, iPhone and iPad devices running iOS 9.3 or higher

Download ACSC iOS Hardening Configuration Guide for iPod Touch, iPhone and iPad devices running iOS 9.3 or higher (3.8Mb PDF), August 2016

About this guide

The iOS Hardening Configuration Guide for iPod Touch, iPhone and iPad devices running iOS 9.3 or higher (3.8Mb PDF) 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.

Evaluation status

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:

at NIAP Products in Evaluation.

For more information on the evaluation process, please refer to ASD Evaluation Pathway for Mobile Devices.

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:

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.

Audience

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:

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

What’s changed

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:

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.

Lost Mode

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

Feedback

Advice has been updated throughout the guide based upon the experiences of Australian Government agencies and from industry. If you have feedback, please contact ASD.

Table of contents

  1. Introduction to mobile device security
  2. Security features and capabilities
  3. Encryption in iOS
  4. Deploying iOS devices
  5. Managing apps and data
  6. Suggested policies
  7. Recommended device settings
  8. Mobile device management
  9. Security checklist
  10. Example scenarios
  11. Risk management guide
  12. Firewall rules

Contact

Australian government customers with questions regarding this advice can contact ASD Advice and Assistance.

Australian businesses and other private sector organisations seeking further information should contact CERT Australia.