I OS8 Hardening Guide

User Manual:

Open the PDF directly: View PDF .
Page Count: 87

iOS Hardening

Conﬁguration Guide

For iPod Touch, iPhone and iPad devices running iOS 8.3 or higher.

!!
1!!!
2!!!
3!!!
4!!!
5!!!
6!!!
7!!!
8!!!
9!!!
10!!!
11!!!
12!!!
i 
iOS Hardening Conﬁguration Guide 
About this Guide 
Introduction to Mobile Device security Architecture 
Security Features and Capabilities 
Encryption in iOS 
Deploying iOS Devices 
Managing Apps and Data 
Suggested Policies 
Recommended Device Proﬁle Settings 
Mobile Device Management 
Security Checklist 
Example Scenarios 
Risk Management Guide 
Firewall Rules 
4 
11 
19 
26 
35 
42 
47 
64 
69 
74 
78 
83 

About this Guide

This guide provides instructions and techniques for Australian

government agencies to harden the security of iOS 8 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

At the time of publication, the latest version of Apple iOS on

iPhone, iPad, and iPod Touch has commenced but not

completed an ASD recognised evaluation.

https://www.niap-ccevs.org/CCEVS_Products/in_eval.cfm

Apple iOS 8 was launched on 17th September 2014. As per

Apple’s usual practice, the previously released version, iOS 7 is

no longer available for download.

For agencies with existing or planned iOS deployments, ASD

advises the following:

PARTNERING FOR A CYBER SECURE AUSTRALIA

a) Upgrade to iOS 8.3 or later. Even though iOS 8 has not

completed an evaluation, this version does provide security

enhancements and addresses a number of software

vulnerabilities. This is consistent with ASD’s advice to install

the latest versions of software and patch operating system

vulnerabilities as communicated in the Australian Government

Information Security Manual and Strategies to Mitigate

Targeted Cyber Intrusions.

b) Implement the interim advice contained in this guide. In

particular, agencies should take note of advice relating to new

features and changed functionality introduced by Apple in

iOS 8. This advice is the result of in-house technical testing

by ASD, experiences shared by other agencies, and in

consultation with the vendor.

Agencies should be made aware that since April 2014, the

Australian Signals Directorate (ASD) has endorsed the Mobile

Device Fundamentals Protection Proﬁle (MDF PP) as a key

component in all new mobile device evaluations. The MDF PP,

as deﬁned by the United States’ National Information Assurance

Partnership (NIAP), outlines the security requirements for a

mobile device for use in an enterprise. The process for

evaluation is described in detail on ASD’s website:

http://www.asd.gov.au/publications/dsdbroadcast/20140410-

evaluation-pathway-for-mobile-devices.htm

As in any case where signiﬁcant updates of a previously

evaluated product are issued by a vendor, agencies should

investigate the changes as part of their risk management

process. Agencies must refer to the Product Security section of

the Australian Government Information Security Manual to

ensure compliance when planning to use an unevaluated

product.

Apple provides detail of the content of security updates. This

information may help agencies quantify the risk posed by not

updating.

https://support.apple.com/en-au/HT1222

iOS and the Australian Government

Information Security Manual

This guide reﬂects policy speciﬁed in the ISM. Currently, not all

ISM requirements can be implemented on iOS 8 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 speciﬁcally to iOS 8, and

takes precedence over the non-platform speciﬁc advice in the

ISM.

About the Australian Signals Directorate

As the Commonwealth authority on the security of information,

the Australian Signals Directorate provides guidance and other

assistance to Australian federal and state agencies on matters

relating to the security and integrity of information.

For more information, go to http://www.asd.gov.au/about/.

PARTNERING FOR A CYBER SECURE AUSTRALIA

Audience

This guide is for users and administrators of iOS 8 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, ﬁrewall 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 speciﬁc 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 clariﬁcation or assistance, Australian government IT

Security Advisors can consult the Australian Signals Directorate

by emailing asd.assist@defence.gov.au or calling the ASD

Cyber Hotline on 1300 CYBER1 (1300 292 371).

What’s Changed

iOS 8 has brought with it many important new features and

improvements. Apple has opened the platform further to app

developers with “app extensions” while simultaneously

reenforcing platform security. Enterprise administrators are

given more control with new conﬁguration proﬁle payloads and

restrictions. While users are given a number of new features,

many will challenge administrators of business only iOS ﬂeets.

Continuity

Continuity is the name given to a group of new features which

enable a user to transition an activity from one device to

another. This includes:

• Allowing a user to move from one device to another, and have

their internet browsing state preserved.

• Allowing a user to take advantage of their iPhone’s cellular

network from another associated device for phone calls,

messaging and network connectivity.

Refer to Security Features and Capabilities for updated advice

on the risks and beneﬁts associated with Continuity.

App Extensions

Third party apps with app extensions can now make available

content and functions to other apps in iOS. For example:

PARTNERING FOR A CYBER SECURE AUSTRALIA

• An app may install a custom keyboard that replaces the

default iOS keyboard

• Custom Actions allows a third party app to provide a service

such as document translation to content in another app.

Refer to Security Features and Capabilities for updated advice

on the risks and beneﬁts associated with App Extensions.

New Conﬁguration Proﬁle Controls

New management and supervisory controls have been made

available to iOS enterprise ﬂeet administrators. Refer to

Recommended Device Proﬁle Settings for our updated advice.

Improved VPN guidance

iOS 8 contains several under-the-hood changes to VPN

behaviour. Refer to the VPN section for detail.

Feedback

Advice has been updated throughout the guide based upon the

experiences of Australian Government agencies and from

industry.

If you have feedback email: asd.assist@defence.gov.au

iii

CHAPTER 1

Introduction

to Mobile

Device

Security

Understand the key technologies that can be

used to secure iOS mobile devices.

Introduction to Mobile

Device Security

This chapter provides the planning steps and architecture

considerations necessary to set up a secure environment for

mobile devices. Much of the content in this chapter is platform

agnostic, but some detail is written to address speciﬁc features

available in iOS. Not all of the options discussed will be

applicable to all environments. Agencies need to take into

account their own environment and consider their acceptable

level of residual risk.

Assumptions

This chapter makes some basic assumptions regarding the

pervasive threat environment:

• at some point, there will be no network connection present

• all radiated communication from the device has the potential to be

monitored

• all conventional location, voice and SMS/MMS communications

are on an insecure channel

• certain infrastructure supporting mobile devices can be trusted

• carrier infrastructure cannot always be trusted as secure in all

countries

PARTNERING FOR A CYBER SECURE AUSTRALIA

• at some point, devices will be lost or stolen

• lost or stolen devices will be in a locked state

• third party apps will leak sensitive data.

Oﬄine Device Security

When a device is ofﬂine, protection of data on the device is

determined by how the device implements data protection

locally. There can be no referral to a server for policy or any

remote wipe command if there is no network present.

When ofﬂine, the security of the device is determined by:

• policy enforced by iOS from Exchange ActiveSync (EAS) or

Conﬁguration Proﬁles

• policy enforced by third party mobility management apps

• the security settings set locally on the device (such as passcode

policy and USB pairing restriction)

• the device’s cryptographic capabilities

• the correct use of ﬁle protection classes and Keychain by apps

• the strength of the device passcode.

Device Security on the Network

The general principle that applies for all data when the device is

on a network is that wherever possible, all network trafﬁc should

be encrypted, noting that all classiﬁed network trafﬁc must be

encrypted as per the Cryptography chapter of the ISM. This is

not merely achieved by turning on a Virtual Private Network

(VPN) for all trafﬁc. Typically this involves using a mixture of:

• TLS to encrypt connections to speciﬁc hosts such as mail servers

or management servers that need to be highly reachable

• TLS for any trafﬁc containing sensitive data

• a VPN for more general intranet access

• WPA2 with EAP-TLS as a minimum for Wi-Fi security

• 802.1X authentication on Wi-Fi networks combined with Network

Access Controls to compartmentalise Wi-Fi access to deﬁned

security domains

• data at rest encryption on mobile devices and transport security.

Some third party mobility management vendors may provide an

operating system integrity check. Though a useful compliance

feature, it cannot be relied upon. Details are available in the

Jailbroken Employee Owned Devices section.

Apple Push Notiﬁcation Service

Many apps and services associated with iOS devices take

advantage of the Apple Push Notiﬁcation Service (APNS). APNS

allows apps to “phone home” to their servers, and be sent small

notiﬁcations, such as updating the badge on an icon, playing an

alert tone, or displaying a short text message.

Apple’s documentation on APNS refers to servers that

communicate with apps as “Providers”.

PARTNERING FOR A CYBER SECURE AUSTRALIA

Example of providers include push email notiﬁcation, Mobile

Device Management (MDM) servers and iOS client-server

applications that are able to execute in the background (such as

VOIP apps, streaming audio apps, or location tracking apps).

Providers send a request to the device to “phone home”, and

the app or agent on the device establishes communication with

and responds to the provider. For example, MDM servers send

an APNS request to the Apple MDM agent on the device. The

Apple MDM agent then “phones home”, establishing a TLS

tunnel directly to the MDM server, and exchanging XML queries

and responses inside this tunnel.

It will be necessary to set appropriate ﬁrewall rules to enable

APNS. Refer to Firewall Rules in Chapter 12 for information on

ports and services.

Data Roaming

Data roaming generally refers to a process by which your

cellular device is able to receive data on mobile networks that

your telecommunications operator doesn’t own.

There are two main risks associated with data roaming:

• When roaming internationally, there are both implied and

actual lower levels of trust with the level of eavesdropping and

trafﬁc analysis occurring on the foreign network. As soon as

trafﬁc goes international, it is no longer subject to the privacy

and consumer protection requirements that apply to purely

domestic communications in the host country. It is incorrect to

assume that the rights protecting individual’s privacy are

uniform internationally.

• If data roaming is switched off for cost management, then the

device is “off the grid” for management and monitoring

consoles such as EAS, MDM, or iCloud’s “Find My iPhone”.

iOS devices may be conﬁgured to disable voice and data

roaming via MDM, but it is possible for users to re-enable

roaming on their devices.

Apps

As outlined in ASD’s Strategies to Mitigate Targeted Cyber

Intrusions, ASD recommends that only applications that are

required should be installed. There are a number of ways to

procure and load applications onto an iOS device.

App Store

The App Store is hosted and curated by Apple, and is focused

on mass-market distribution of paid and free applications. Apps

are loaded to a device:

• Over-The-Air (OTA) from the App Store itself

• OTA via a Mobile Device Management (MDM) solution

• via USB on a paired host running Apple Conﬁgurator

• via USB/network on a paired host computer running iTunes.

Apple maintains discretionary control of curating App Store

content, and can remove applications for a variety of reasons.

ASD recommends that corporately provisioned apps are tested

and approved by the agency prior to use.

PARTNERING FOR A CYBER SECURE AUSTRALIA

Although App Store applications come from a curated

environment, and the runtime environment the apps execute in

is a relatively hardened one, Apple’s app review process is

focused on end user privacy, and does not implement ISM

policy. Agencies should assess the risks associated with

allowing unrestricted user-initiated installation of apps, building

on Apples’ review process. Some additional risks that need to

be considered are:

• the inappropriate use of data protection

• Most App Store apps default to Class C, PROTECTED data

must be stored in Class A or Class B.

• the inappropriate use of transport security

• Ensure that apps use iOS native TLS APIs and mitigate

against man-in-the-middle attacks using certiﬁcate pinning

where possible.

• the inappropriate access of contact list, photos, location

information, and synchronisation of data with cloud services

• the registration of Uniform Type Identiﬁers (UTIs) and URL

handlers.

Agencies can manage these risks through discussions with the

app developer or through conducting professional penetration

testing. Refer to Managing Apps and Data in Chapter 5 for

information on questions to ask app developers.

Note: App Store apps may be automatically updated over

the air using Wi-Fi.

In-House apps

Through the use of an ad-hoc provisioning proﬁle, up to 100

instances of a signed application binary can be installed via

iTunes or Apple Conﬁgurator.

Ad-hoc applications are locked to a speciﬁc set of devices by

the provisioning proﬁle. These are most commonly used for

beta testing of applications, or where very restricted distribution

of a small number of instances of a bespoke application is

appropriate.

Agencies with a Dun and Bradstreet Data Universal Numbering

System (DUNS) number can apply to become Enterprise

developers. This allows the creation and distribution of custom

applications and provisioning proﬁles within an agency for its

own use, where the distribution is limited to employees and

contractors (i.e; not to the general public).

Enterprise In-House apps can be installed using:

• Apple Conﬁgurator (USB only)

• OTA via web site

• OTA via MDM server

• iTunes (USB and Wi-Fi).

In all the above cases, an MDM console allows monitoring of

versions of apps installed on a device. This allows a

management decision as to when updates are required.

PARTNERING FOR A CYBER SECURE AUSTRALIA

Volume Purchase Program (VPP)

The VPP allows businesses to buy app store apps in bulk using

a corporate purchasing card. Agencies with a VPP account may

also use the Business to Business (B2B) portal to request

custom versions of App Store apps directly from app

developers. Agencies may request custom apps that utilise a

stronger use of data protection or transport security APIs, or

request that functionality (such as cloud synchronisation) is

disabled.

Historically, apps purchased through VPP were redeemed by a

user to a particular Apple ID permanently. Recent changes to

VPP now allow apps to be both assigned to and revoked from

users.

For more information on VPP go to http://www.apple.com/au/

business/vpp/

Managed apps

App Store and Enterprise In-house Applications installations

can be triggered via an MDM server; these apps are called

“Managed apps”. Managed apps can be uninstalled by the

MDM server along with any associated data or can be set to

uninstall when the MDM proﬁle is removed.

Web apps

The iOS web browser Mobile Safari has extensive support for

HTML5, CSS3 and JavaScript features for web apps. This is

often a useful mechanism to deploy informational applications

quickly from a central intranet point; however Mobile Safari on

iOS is still subject to the same threats as other browsers.

iTunes

iTunes is no longer a requirement for device management. If

agencies decide to use iTunes as part of their device

management workﬂow it can be locked down for use on

agency Standard Operating Environments (SOE) via registry

keys or XML property lists as detailed here:

http://help.apple.com/iosdeployment-itunes/mac/1.2/

Apple IDs

One of the organisational risks that some users express

concern about is a perceived need to associate a credit card

with every Apple ID. This is actually a misconception, and no

association with a credit card is required. The following

approaches are recommended at the policy and procedural

level.

For a Bring Your Own Device (BYOD) model, there is generally

implied trust that users can continue to install apps on their own

device. Therefore, users may register their existing Apple ID as

part of the process of submitting to the agency Acceptable Use

Policy (AUP). If users then purchase approved apps, using their

own credit card, they can be reimbursed. This provides one

method to control expenditure of agency funds. An MDM

console can be used to monitor what applications have been

installed.

PARTNERING FOR A CYBER SECURE AUSTRALIA

For an agency owned device model, where users are not

allowed to install their own apps, per device Apple IDs are

created that are not linked to a credit card. The process for

doing this is described here:

http://support.apple.com/kb/HT2534 !

Individual app redemption codes, or store credit can then be

gifted to those accounts and installed on the devices from an

agency owned computer using iTunes. Note that the end user

requires the Apple ID password in order to enable application

updates.

Apple IDs can be optionally used to create free iCloud accounts

to facilitate user initiated device location and remote wipe.

Siri

Siri provides voice to text services by transmitting voice data to

remote services for processing. Any dictation performed using

Siri must be considered Unclassiﬁed. By default Siri can be

used from a locked screen to perform actions such as opening

emails and reading calendar entries. This behaviour can be

disabled via Conﬁguration Proﬁle restriction while still allowing

Siri when unlocked.

Lock Screen Services

By default locked iOS devices still provide some limited services

for user convenience. These lock screen services may be

administratively disabled, although in doing so there is a

security versus usability trade off.

Control Centre

The Control Centre panel is accessed at the lock screen with an

upward swipe from the bottom of the screen, and contains the

following:

• airplane mode, Wi-Fi, Bluetooth, Do-Not-Disturb mode,

rotation lock and ﬂashlight on/off switches

• screen brightness

• volume and media playback controls

• AirDrop discoverability control and AirPlay output selection

• access to Stopwatch, Calculator and Camera apps.

Although the new control centre has many useful user

convenience functions, there are risks in enabling it from the

lock screen. Control Centre can be disabled at the lock screen

via Conﬁguration Proﬁle restriction.

Notiﬁcation Centre

Notiﬁcation Centre and Today View are accessed from the lock

screen with a downward swipe from the top of the screen. iOS

displays APNS notiﬁcations at the lock screen such as

messages (iMessage) or invitations/requests (GameCentre).

Although such content must be Unclassiﬁed, revealing

notiﬁcations at the lock screen is not recommended.

Notiﬁcation Centre from lock screen can be disabled via

Conﬁguration Proﬁle restriction.

PARTNERING FOR A CYBER SECURE AUSTRALIA

Today View

Today View gives a summary of information about a user’s day.

Normally this will include the day’s weather, trafﬁc and calendar

entry.

Today view can be disabled via Conﬁguration Proﬁle restriction.

Planning your mobility deployment

Every Australian government agency should have a BYOD

policy, even if that policy is “No employee owned devices are to

be allowed on the agency network”. ASD’s Risk Management of

Enterprise Mobility including Bring Your Own Device (BYOD)

provides advice regarding the risks and beneﬁts of a number of

possible mobility approaches. It comprehensively covers:

• the potential beneﬁts of enterprise mobility

• how to choose an appropriate mobility approach, including:

• corporately owned devices allowing limited personal use

• employee owned “Choose your own device” (CYOD)

• developing mobility policy

• risk management controls.

This document is a thorough guide to planning a mobile

deployment and is available at:

http://www.asd.gov.au/publications/csocprotect/

enterprise_mobility_bring_your_own_device_byod_paper.htm

CHAPTER 2

Security

Features and

Capabilities

Mobile device security features, and the

enabling technologies for implementing those

features under iOS.

Security Features and

Capabilities

This chapter covers mobile device security features, and the

enabling technologies for implementing those features under

iOS and related infrastructure.

Security features in iOS

iOS provides a number of features that include:

• management of credentials and passwords with Keychain

• encryption of data at rest and in transit (using AACA and AACP)

• digital signatures, certiﬁcates and trust services

• randomisation services

• code signed applications.

Enterprise In-House Applications developed for an agency

should generally take advantage of these services, rather than

re-inventing the same capabilities.

PARTNERING FOR A CYBER SECURE AUSTRALIA

Conﬁguration Proﬁles

Conﬁguration Proﬁles are XML formatted plist ﬁles that contain

device settings, security policies and restrictions. An

administrator may use a Conﬁguration Proﬁle to:

• set passcode policy on a device

• set restrictions (such as disabling use of Siri)

• conﬁgure wireless networks

• conﬁgure VPN

• conﬁgure email

• install X.509 certiﬁcates

• set a Mobile Device Management (MDM) server.

These are only a few examples of possible conﬁguration

options. For more information please see the iOS Conﬁguration

Proﬁle Reference:

https://developer.apple.com/library/ios/featuredarticles/

iPhoneConﬁgurationProﬁleRef/

Note: Conﬁguration Proﬁles are not encrypted.

Credentials that are stored in Conﬁguration Proﬁles are available

to anyone who has access to the ﬁles. Passwords may be in

clear text or encoded in base 64, which offers no protection.

Some of the credentials that could be in a Conﬁguration Proﬁle

include:

• Wi-Fi passwords

• VPN Shared secrets

• Email usernames/passwords

• ActiveSync usernames/passwords

• LDAP usernames/passwords

• CalDAV usernames/passwords

• CardDav usernames/password

• Subscribed Calendars usernames/passwords

• SCEP pre-shared secrets.

Note: Take care to ensure that Conﬁguration Proﬁle ﬁles are

stored appropriately and not improperly accessed.

Provisioning Proﬁles

Provisioning proﬁles allow custom applications to be run on iOS

devices. They are often used in the following ways:

• to allow developers to test applications on their devices

• to allow organisations to distribute applications directly to their

employees.

To obtain an enterprise distribution provisioning proﬁle, an

agency must join the Apple Developer Enterprise Program.

More information about the iOS Developer Enterprise Program

can be found at:

PARTNERING FOR A CYBER SECURE AUSTRALIA

http://developer.apple.com/programs/ios/enterprise/

Note: If the enterprise program login is compromised an

adversary could install malicious applications on users’ iOS

devices.

Find My iPhone and Activation Lock

Find my iPhone (FmiP) is an iCloud service which allows users

to locate and remote wipe their Apple devices. On devices

which have not been conﬁgured as supervised, FmiP enables a

feature called “Activation Lock”. This feature ties the Apple ID

used for FmiP to device activation. Following a device wipe or

OS installation, a user must enter their Apple ID credentials.

This is intended to reduce the resale value of stolen devices, as

the device cannot be used without knowledge of the original

user’s Apple ID.

Activation Lock has the potential to deny an organisation

access to its own devices. If Activation Lock is enabled on an

agency owned iOS device with a user’s personal Apple ID, the

user must disable FmiP prior to returning the device for service.

If the device were returned with Activation Lock enabled, the

agency would not be able to re-activate after re-installing iOS,

and may not remove FmiP even if the device passcode was

known.

By default, supervised devices have Activation Lock disabled,

however agencies may choose to re-enable this through the

use of Conﬁguration Proﬁles. Please refer to the Activation Lock

section of the Deploying iOS Devices chapter for further

information.

The link below contains information on how personal users may

take advantage of the service.

http://www.apple.com/au/icloud/ﬁnd-my-iphone.html

Sandboxing

Sandboxing ensures that applications that run on iOS devices

are restricted in terms of the resources that they can access.

This is enforced by the kernel.

For detailed information on the iOS/OS X sandbox see Dion

Blazakis’s paper The Apple Sandbox or Vincenzo Iozzo’s

presentation A Sandbox Odyssey.

Managed Apps and Extensions

When devices are enroled in to MDM, apps and app extensions

obey “Managed Open-In” restrictions. This feature allows

administrators to conﬁgure devices in a way that prevents

documents being exported from “managed” to

“unmanaged” (user) applications. It can also be used to prevent

unmanaged app extensions being accessible from managed

apps. These native features have reduced the need for the use

of managed container applications, however there may be

cases where an agency may seek a third party solution.

In cases where the agency requires greater protection of their

contact and calendar information a third party solution may be

required.

A number of managed container solutions can be used to

provide:

PARTNERING FOR A CYBER SECURE AUSTRALIA

• ﬁner grained control and policy enforcement for data

transmission between apps which support the 3rd party SDK

• “app wrapping” to enhance existing security or add

restrictions to previously developed in-house apps

• a suite of apps which have been designed to enforce a secure

workﬂow.

There are a number of non security related trade-offs which

should also be considered before the use of 3rd party container

solutions:

• 3rd party container solutions often have a lower level of

integration with both apps present in iOS and common App

Store apps

• many 3rd party container solutions rely upon software

encryption which is slower than those which rely upon the

hardware accelerated native data protection offered by iOS

• container solutions which rely upon software encryption may

require an additional passcode separate to the device

passcode, often with an increased complexity requirement.

When used, care must be taken to prevent a situation where

the agency provided container solution is so prohibitive that

users attempt to start working their way around the system.

Information regarding evaluated container solutions is available

on the EPL:

http://www.asd.gov.au/infosec/epl/

Content Filtering

Access to intranet sites and some mail, contact or calendar

data can be achieved via reverse proxies and content ﬁlters.

There are multiple solutions in this space.

EAS ﬁltering products can be used to ensure email sent to EAS

devices have appropriate protective markings for the

classiﬁcation the device is approved to by an agency. This

approach allows mobile devices to only receive email content at

a classiﬁcation appropriate to the device, as well as having

policy and controls applied to the email content.

In this scenario, the agency’s Wide Area Network (WAN)

security domain is not extended out to the mobile device, and

there is no need to lower the classiﬁcation of the agency WAN.

Such solutions can be used to redact speciﬁc content patterns

from emails sent via EAS, for example, to scrub credit card

numbers from all emails synced to mobile devices. This class of

tools can also facilitate correct protective marking of email

coming from mobile devices without direct on-device support

for Australian government marking standards. For further

information see the ISM section on Content Filtering.

Enterprise Single Sign On (SSO)

Enterprise SSO helps to reduce the number of times a user is

required to enter credentials, particularly when switching

between apps. SSO is built on top of kerberos, which is the

industry standard authentication scheme already present in

many corporate networks.

PARTNERING FOR A CYBER SECURE AUSTRALIA

To take advantage of SSO, agencies must create and then

deploy an Enterprise SSO Conﬁguration Proﬁle payload. This

payload contains:

• username (PrincipalName)

• kerberos realm name

• a list of URL preﬁxes where kerberos authentication should be

applied

• a list of app identiﬁers which will be granted access to

kerberos.

Some apps support SSO without modiﬁcation, others may have

to be updated to take advantage of Apple’s higher level

networking APIs.

For detail please refer to the Apple WWDC 2013 presentation:

Extending Your apps for Enterprise and Education Use (Apple

Developer login required):

http://devstreaming.apple.com/videos/wwdc/

2013/301xcx2xzxf8qjdcu3y2k1itm/301/301.pdf

Per App VPN

In deployments which permit limited personal use, Per App VPN

can be used to divide work and personal network trafﬁc.

Typically, this would be conﬁgured so that corporate network

trafﬁc from managed apps traverses a VPN back to the

corporate intranet, while unmanaged personal apps connect to

the internet directly or through a proxy. This VPN enhancement

is intended to increase the privacy of the user by not

transmitting their personal network trafﬁc through corporate

infrastructure while at the same time protecting the corporate

network from trafﬁc generated by unmanaged apps.

Secure Browser

Where Per App VPN is used, a “Secure Browser” may be

mapped to use the conﬁgured Per App VPN for corporate

network trafﬁc exclusively. There are several advantages to

using a separate secure browser:

• a secure browser may be chosen that protects cached data

and credentials in a higher data protection class than Safari

• depending upon MDM solution, a secure browser may have

corporate data wiped when a device is lost/stolen, out of

compliance, or upon other conﬁgurable triggers.

• when the secure browser is mapped to the corporate intranet

Per App VPN, users may be permitted to use Safari for

ordinary internet access. This reduces the risk of sensitive

data transmission from corporate intranet to internet. In this

case, Safari may still be conﬁgured with a web proxy to

protect against web based threats and for acceptable use

policy enforcement.

Global Proxy

Supervised devices may be conﬁgured with a “Global Proxy”

setting. This allows administrators to conﬁgure supervised

devices to use a speciﬁed HTTP(S) proxy on all network

interfaces.

PARTNERING FOR A CYBER SECURE AUSTRALIA

Continuity

Continuity is the name given to a group of iOS and Mac OS X

features which enhance device to device collaboration. For

more information on this feature visit Apple’s website:

https://www.apple.com/au/ios/whats-new/continuity/

Continuity offers some productivity beneﬁts for organisations,

while at the same time creating some new concerns such as:

• A corporate iOS device may handoff a sensitive or classiﬁed

document being worked on to a user’s personal Mac with the

same Apple ID. Handoff may be administratively disabled by

conﬁguration proﬁle restriction.

• For phone calls and messages, the level of protection given to

data on an untrusted Wi-Fi network. Refer to Apple’s iOS

Security Guide for details.

App Extensions

Beginning with iOS 8, 3rd party iOS App developers may create

functionality which may be utilised by other apps on the device.

App Extensions cannot be disabled through conﬁguration

proﬁle restriction. For details regarding features, please refer to

Apple’s documentation:

https://developer.apple.com/app-extensions/

Some organisational concerns may include:

• User installs custom keyboard extension which transmits

keystrokes to a 3rd party.

• User uploads sensitive or classiﬁed data to a 3rd party

document provider.

• User shares sensitive or classiﬁed data using a custom share

extension.

When an app with an extension is installed, both the app and

the extension may be considered “Managed” or “Unmanaged”

depending upon how the App was installed. Additionally, App

Extensions respect Managed Document conﬁguration proﬁle

restrictions.

If the following settings are disabled by conﬁguration proﬁle:

Allow documents from managed apps in unmanaged apps

Extensions installed with MDM deployed managed apps can’t

be activated by user installed App Store apps. For example, a

corporate installed document provider extension can’t be used

by a user’s personal app store app.

Allow documents from unmanaged apps in managed apps

Extensions installed by user App Store apps can’t be activated

by MDM installed managed apps. For example, a user installed

custom keyboard can’t be used by corporate apps.

PARTNERING FOR A CYBER SECURE AUSTRALIA

Capability

Remote Wipe

Proxy

Firewall

Force Device Settings

Multi-factor Authentication

OTA Conﬁguration Proﬁle (pull)

Mobile Device Management

Remote Application Deployment

Home screen

Enablers

MDM, EAS, Apple Push Notiﬁcation Service (APNS),

Find My iPhone

VPN, Global Proxy

VPN to ﬁrewalled corporate network

Apple Conﬁgurator and MDM

TLS CA infrastructure, DNS, RSA or CryptoCard

(VPN Only), Smartcard (Requires third party software

and hardware)

TLS CA infrastructure, DNS, Web Service, Directory

Service

Enterprise Developer Agreement, 3rd Party MDM

appliance, CA infrastructure, DNS, Directory

Services, APNS

Enterprise Developer Agreement, Web Server, 3rd

Party MDM appliance (optional), APNS (optional)

Apple Conﬁgurator / MDM

Table 2.1: Capability enablers

Comment

Remote wipe can be initiated by a user through Find my

iPhone or by an administrator through MDM.

Third party MDM software may offer a separate

“Enterprise Wipe” which is intended to erase data in a

secure container or selected apps.

A proxy can be set on a VPN session.

iOS does not implement a local ﬁrewall. This is

signiﬁcantly mitigated by the hardened runtime

environment.

Apple Conﬁgurator and MDM may be used to generate,

sign and deploy Conﬁguration Proﬁles to iOS devices.

Depending on the agency’s security posture, device

certiﬁcates or soft tokens may be considered as a

second factor of authentication. At the time of writing,

Touch ID can not be used for multi-factor authentication.

Sign proﬁles using enterprise CA infrastructure.

MDM should be tied into CA and Directory Services.

Enterprise and App Store apps can be remotely

deployed. Mac OS X Server Caching Server may help

reduce corporate network internet consumption.

Set Home screen to “If found return to PO BOX XXXX”.

PARTNERING FOR A CYBER SECURE AUSTRALIA

CHAPTER 3

Encryption in

iOS

Keeping data safe when the device is out of

your control.

Encryption in iOS

This chapter is provided to help agencies understand the

underlying encryption architecture employed in iOS 8 to assist

make an informed assessment of the risks to Australian

government information.

Data Protection

Apple has explained that one of the goals of iOS is to 'keep

data safe even when the device is compromised'. However, as

will be explained in this chapter, the onus remains largely on

app developers as to how much or how little data protection is

applied.

For this reason, it is important that an agency wishing to use a

particular application understands the security features of iOS 8

in order to make a more informed decision as to whether the

application meets the security needs of the agency.

It is important to note that if devices are not conﬁgured to use

the Managed Open-In feature, users can still move attachments

to apps that use lower data protection classes. This can

happen if installed apps have registered document types or

URL handlers.

Secrets and Data

Within iOS 8, information stored by apps can be broadly

categorised as either a secret or as data. The term secret can

be understood to mean information by which one may get

PARTNERING FOR A CYBER SECURE AUSTRALIA

access to data; this can include system credentials, keys and

passwords. Data on the other hand, refers to user/application

data such as text, pictures and documents.

Accordingly there are two data stores where a developer should

choose to store information: the Keychain and the File System.

Developers are encouraged to store secrets within the Keychain

and place more general application data within the File System.

Information stored within either of these stores can be

customised to different levels of security, accessibility and

portability. Note that it is entirely up to the developer to

determine the level of protection applied. This choice is made

by the app developer through API calls and the choice of

availability as detailed in Table 3.1.

For included iOS apps, the default ﬁle system protection class

utilised is “...CompleteUntilFirstUserAuthentication”, and most

iOS Keychain items utilise “…AfterFirstUnlock”.

Note: Agencies developing or making use of applications

handling sensitive data should take care to investigate how

data is handled within their application. They must ensure the

appropriate data stores and availability ﬂags (outlined in

Table 3.1) are used to achieve the secure handling of

Australian government information.

Classes of Protection

An application developer has the option of setting the following

availability ﬂags with any File System Element or Keychain entry

they create.

Availability

File system element

Keychain

entry

When

unlocked

...Complete

...WhenUnlock

While locked

...CompleteUnlessOpen

N/A

After ﬁrst

...CompleteUntilFirstUserAuthenti

...AfterFirstUnlo

unlock

cation

Always

...None

...Always

Table 3.1: File system class accessibility

From Table 3.1, it is possible to abstract these settings into four

standard classes of containers with the following behaviour:

Class A: Files and credentials within this class can only be read

or written when the device is unlocked.

Class B: Through the use of public key cryptography, ﬁles

within this class can be written after the device is initially

unlocked, and can be read only when unlocked.

Class C: Files and credentials within this class can be read or

written only after the device is initially unlocked. App Store apps

use this class by default. Powering off or rebooting the device

will render data in this protection class inaccessible.

PARTNERING FOR A CYBER SECURE AUSTRALIA

Class D: The lowest protection class, ﬁles and credentials

within this class can be read or written to in all conditions.

iOS Encryption Architecture

Figure 2.1 illustrates an example where four ﬁles exist, each

assigned a different class:

• File 1 is of type Class A: accessible only when unlocked

• File 2 is of type Class B: can be written to after ﬁrst unlock, but

can only be read when unlocked

• File 3 is of type Class C: accessible after ﬁrst unlock

• File 4 is of type Class D: accessible always.

Note that while ﬁles were used for the purposes of this

example, with the exception of Class B, Keychain entries could

just as easily be used in their place.

Similar to the File System, an application's credentials stored

within the Keychain are encrypted using the appropriate Class

Key found within the System Keybag (refer to the Keybag

Section of this chapter for more information).

However, as illustrated in Table 3.1, the protection offered by

Class B is only available to File System Elements.

In Figure 2.1, irrespective of class, each ﬁle is encrypted with

both a unique File Key and a File System Key.

The File System Key is used to encrypt all data within the

device. As it is stored openly its use does not add to the

cryptographic security of data, but is instead used to facilitate a

remote wipe. Refer to the Remote Wipe section of this chapter

for more information regarding this function.

Figure 3.1: iOS File System Architecture

The File Key is stored within the ﬁle’s metadata, which is itself

encrypted by the ﬁle’s corresponding Class Key. The System

Keybag stores all Class Keys within the device. Refer to the

Keybag section of this chapter for more information on different

types of Keybags used throughout the system.

Upon turning on the device, the Class A, Class B (public and

private) and Class C keys are initially inaccessible as they rely

on the Passcode Key to be unencrypted.

When the device is ﬁrst unlocked by the user, through the use

of their passcode, these keys are unencrypted, stored for use

and the derived Passcode Key promptly forgotten.

The Device Key is stored within, and never divulged from, the

Hardware Security Module (HSM). This acts to encrypt and

decrypt ﬁles at will using the Device Key. Refer to the Hardware

Security Module section of this chapter for more information on

this component.

The Class D Key is encrypted using the Device Key. As this

decryption process is always available, irrespective of the state

of the device, ﬁles protected by this Class Key are accessible

always.

Finally, when the device re-enters a locked state, the Class A

Key and Class B Private Key are forgotten, protecting that data,

leaving the Class C Key and Class B Public Key accessible.

PARTNERING FOR A CYBER SECURE AUSTRALIA

Remote Wipe

Remote Wipe is the ability for a network connected iOS device

to have the data within the device made inaccessible (enacted

by received system command). This is achieved in iOS by

erasing the File System Key, which is used by the device to

encrypt all user data (as shown in Figure 2.1). For this reason,

once this key is removed, no user data on the device is

retrievable.

Hardware Security Module (HSM)

Internal to the device, the HSM is the only means by which iOS

can make use of the Device Key. This Device Key is unique to

the device and is not exportable using any non-invasive

technique.

For this reason (as ﬁles encrypted with the Device Key can only

be decrypted on the device), the iOS architecture makes itself

resistant to off-line attacks. The most signiﬁcant being a brute-

force to exhaust and thus discover the user's Passcode Key. All

such brute force attempts rely upon the HSM, are performed on

device, and are rate limited.

Note: While the HSM has been evaluated under FIPS-140-2

and an ACE, the secure enclave present in the A7 processor

is yet to be evaluated.

PARTNERING FOR A CYBER SECURE AUSTRALIA

Keybags

There are three types of Keybags used in iOS: System, Backup

and Escrow.

All Keybags are responsible for storing the systems Class Keys,

which are in turn used to gain access to individual ﬁles or

Keychain entries (as shown in Figure 2.1).

The System Keybag, shown in Figure 2.1, is used internally

within the device to facilitate the user’s access to the File

System and Keychain.

The Backup Keybag is designed to facilitate backups in a

secure manner. This is done by transferring the encrypted

contents of the File System, and Keychain to a remote system

along with the Backup Keybag.

The user then has the option to password protect this Keybag;

this decision has implications concerning the portability of the

Keybag. If the user speciﬁes a password, the Backup Keybag is

then encrypted with this password.

Given the password, this data can then be restored to an iOS

device (Note: if a developer has speciﬁed data 'ThisDeviceOnly',

such data will not be made portable). If, however, the user

does not set a password, then the Backup Keybag is protected

using the Device Key which never leaves the device.

Consequently, the Backup Keybag can only be restored to the

original device.

The Escrow Keybag is designed to enable a paired device

(normally a computer) to gain full access to the device's ﬁle

system when the device is in a locked state. In this context

pairing refers to connecting the iOS device in an unlocked state

(or within 10 seconds of being in an unlocked state) to the other

device in question.

An exchange then occurs, where the paired device receives a

copy of the iOS device’s Escrow Keybag. This Keybag is

encrypted using the iOS device's Device Key, thus restricting

access when disconnected from the iOS device.

Setting a Passcode

Setting a passcode is required to enable data protection. In

most environments enabling a passcode will form part of

agency policy, and this will be enforced either over EAS, or via a

Conﬁguration Proﬁle installed on the device. For passcode

policies see Suggested Policies in Chapter 6.

Verifying Data Protection is Enabled

There are two main methods of verifying that the ﬁle system of a

device has been conﬁgured to support data protection. An

MDM console can query the data protection status and report

centrally. The user of a device can also validate if data

protection is enabled by navigating to Settings > General >

Passcode Lock and scrolling to the bottom of the screen. If

data protection is enabled, “Data protection is enabled” will be

displayed at the bottom of the screen.

PARTNERING FOR A CYBER SECURE AUSTRALIA

Figure 2.2: Data protection enabled

References and Further Reading

For more information on the encryption used in iOS, please refer

to the following:

iOS Security October 2014: https://www.apple.com/br/privacy/

docs/iOS_Security_Guide_Oct_2014.pdf

"iPhone data protection in depth" by Jean-Baptiste Bedrune

and Jean Sigwald from Sogeti

iOS ﬁlesystem decryption tools and information from Bedrune

and Sigwald: http://code.google.com/p/iphone-dataprotection/

"Apple iOS 4 Security Evaluation" by Dino A. Dai Zovi

Session 709: Protecting Secrets with the Keychain, Apple

Developer WWDC 2013 Presentation

Session 208: Securing iOS Applications, Apple Developer

WWDC 2011 Presentation

PARTNERING FOR A CYBER SECURE AUSTRALIA

CHAPTER 4

Deploying iOS

Devices

Enrol and sanitise iOS devices using Apple

Conﬁgurator.

Deploying iOS Devices

iOS has a number of features that are aimed at helping

administrators manage iOS devices in large organisations. In

most cases, agencies must use a combination of available tools

during deployment.

Apple Conﬁgurator

Apple Conﬁgurator allows administrators to set up and deploy

groups of similarly conﬁgured iOS devices. Apple Conﬁgurator

may be suitable for:

• preparing devices for PROTECTED deployments

• preparing devices for MDM enrolment

• activating and naming groups of new devices

• updating iOS on groups of devices

• installing apps and Conﬁguration Proﬁles on groups of devices

• backing up and restoring devices

• saving and retrieving documents.

It is recommended that administrators use Apple Conﬁgurator

with an MDM for large deployments of iOS devices.

PARTNERING FOR A CYBER SECURE AUSTRALIA

Supervised Mode

A key feature of Apple Conﬁgurator is the ability to place

devices into what is called “supervised” mode. Supervised

mode modiﬁes standard iOS behaviour in a number of ways.

Some of the effects include:

• devices are able to be administered using Conﬁguration Proﬁle

restrictions not normally available

• devices are unable to sync music or media from their

computer running iTunes to their iOS device

• devices are unable to install apps using iTunes

• devices are unable to backup using iTunes

• increased difﬁculty in jailbreaking

• in some cases, users not being notiﬁed when changes are

made to device conﬁguration

• administrative message on lock screen

• Activation Lock disabled for lost or stolen devices

• device data being erased upon initial provisioning.

Though it may not be appropriate to use supervised mode in a

BYOD model, there are reasons why supervised mode is

desirable for agency owned devices:

• Sensitive data on each device is better protected. Users

cannot sync or backup their device contents to their home

computer. iOS forensic recovery utilities may not be able to

recover data from the device without a jailbreak.

• Users cannot easily sidestep restrictions without erasing the

device.

• Supervised mode increases the difﬁculty of a number of

attacks that rely upon the USB host pairing protocol.

Devices not conﬁgured as supervised devices are referred to as

unsupervised devices.

Note: PROTECTED devices must use supervised mode.

Supervisory Host Identity Certiﬁcate

Normally, an unlocked iOS device is able to pair with any host

running iTunes (or supporting the lockdown protocol). When an

iOS device is set to supervised mode, it authenticates with a

host using the “Supervisory Host Identity Certiﬁcate”. If the

“Allow pairing with non-Conﬁgurator hosts” Conﬁguration Proﬁle

restriction is disabled, a device will only pair with a host running

Apple Conﬁgurator with the correct Supervisory Host Identity

Certiﬁcate. Ordinary pairing with iTunes is not possible with any

other hosts. On a Mac host running Apple Conﬁgurator, the

Supervisory Host Identity Certiﬁcate is stored in the login

Keychain.

While supervised devices with this restriction are unable to

establish new trust relationships with iTunes hosts, a trust

relationship will be formed between devices and the Apple

Conﬁgurator host. A record of this trust relationship is stored in

PARTNERING FOR A CYBER SECURE AUSTRALIA

Escrow Keybag ﬁles, which on Mac OS X are located at: /var/

db/lockdown. It is important to ensure that the Apple

Conﬁgurator host is regularly backed up, loss of the Supervisory

Host Identity Certiﬁcate and Escrow Keybag ﬁles will mean that

supervised devices cannot be administered via the USB

interface in the future.

Note: Escrow Keybag ﬁles and exported Supervisory Host

Identity Certiﬁcates should be protected in a similar manner

to private keys.

Activating devices with Apple

Conﬁgurator

Apple Conﬁgurator will attempt to automatically activate all

connected devices after operating system installation. It is

important for administrators to note that iPhones and iPads

require a SIM for activation. If the SIM has a passcode lock,

automatic activation will be unsuccessful.

Installing iOS

A key feature of Apple Conﬁgurator is its ability to install iOS on

many devices concurrently. Additionally, varied device platforms

(iPhone, iPad, iPod) can all be simultaneously connected. Apple

Conﬁgurator will seamlessly download iOS for all supported

device platforms when there is an internet connection available.

A theoretical maximum of 64 devices can be connected

concurrently for installation.

Installing Conﬁguration Proﬁles

Apple Conﬁgurator may be used both to install Conﬁguration

Proﬁles and to create new Conﬁguration Proﬁles. These proﬁles

can be installed on devices in bulk when initially preparing

devices for deployment. As an example, this may be used to

initially roll out a trust proﬁle for an agency MDM server.

Figure 4.1 Installing Conﬁguration Proﬁles with Apple Conﬁgurator

iOS Updates

There are two methods for Apple Conﬁgurator deployed

devices to receive iOS updates. Devices with an internet

connection will prompt users to install Over-The-Air updates.

Alternatively, users can return their devices to their administrator

to have them updated using Apple Conﬁgurator.

PARTNERING FOR A CYBER SECURE AUSTRALIA

References and Further Reading

Refer to the following publication for additional information on

Apple Conﬁgurator:

http://help.apple.com/conﬁgurator/mac/

Device Enrolment Program

Recently made available in Australia, the Device Enrolment

Program (DEP) is a deployment feature which allows

organisations to pre-conﬁgure iOS devices, allowing these

devices to be delivered directly to the user.

Devices can be preset to supervised mode and can be

preconﬁgured for an organisation’s MDM system. There are

numerous beneﬁts for administrators in deploying a ﬂeet using

DEP:

• save time deploying by not having to physically connect

devices to host running Apple Conﬁgurator

• no need to use Apple Conﬁgurator to re-provision device after

device wiped

• lost/stolen devices may be recovered or rendered useless

ASD’s testing of DEP is currently incomplete. Agencies should

make a risk determination on the use of this feature which at

minimum must consider the possibility of an adversary taking

control of the Apple ID used to administer DEP.

Device Sanitisation

Administrators should erase and re-provision devices for the

following reasons:

1. to sanitise a returned iOS device for re-issue

2. to sanitise an employee owned iOS device before

provisioning

3. to sanitise a deployed employee owned iOS device prior to

the employee leaving

4. to break all device-to-host trust relationships and invalidate

old Escrow Keybag ﬁles.

Activation Lock

Activation Lock is a feature which requires Apple ID user

authentication before device activation. Typically Activation Lock

is enabled if a user enables iCloud > Find my iPhone in the

Settings app on an unsupervised device.

If a user has enabled Activation Lock on an iOS device, that

user’s Apple ID will be required to activate the iOS device after

(or during) sanitisation.

Breaking The Device-to-host Trust

Relationship

When an iOS device pairs with a host, a trust relationship is

formed. In many cases an administrator may want to erase an

iOS device and break all the established host trust relationships

that a device has previously created. The most reliable method

PARTNERING FOR A CYBER SECURE AUSTRALIA

to break all established relationships is to restore the iOS device

ﬁrmware using what is commonly known as “Device Firmware

Upgrade” mode (DFU mode).

Note: Restoring a device in this way will also erase all data

and settings on the device.

The DFU mode restoration can be performed from a host that

has no established trust relationship with the device, and the

device passcode is not required.

DFU Mode Restoration

To perform an iOS ﬁrmware restoration follow this procedure:

1. Connect the iOS device to the host PC or Mac running

iTunes

2. If iTunes is unable to pair with the iOS device, please clear

any error dialog boxes

3. Press and hold both the Sleep/Wake and Home buttons on

the iOS device for ten seconds

4. Release the Sleep/Wake button, and continue to hold the

home button

5. Release the home button after iTunes generates the

following dialog box:

Figure 4.2: iTunes detects device in recovery mode.

6. After clicking OK, click the Restore button.

PARTNERING FOR A CYBER SECURE AUSTRALIA

Figure 4.3: Restore iPad.

7. Begin the iOS restoration process by clicking Restore and

Update.

Figure 4.4: Restore and Update.

Sanitising an iOS Device For Re-issue

If an agency owned device is returned for re-issue to another

employee, it should be erased by performing a DFU mode

restoration. One reason that this is important is so that the

previous iOS device owner cannot take advantage of any old

device-host trust relationships to retrieve data from the device.

By performing the DFU mode restoration the old trust

relationships are broken.

Before an iOS device is re-provisioned for enterprise use, it is

recommended to perform a DFU mode restoration. This will

ensure that the device is in a known state.

Sanitising Employee Owned iOS Devices

Employee owned iOS devices are making their way into

government agencies, creating a new set of challenges for

administrators. Some of the challenges being faced include:

• jailbroken devices running untrusted code

• jailbroken devices being able to bypass all security protection

(including 3rd party managed containers)

• unpatched iOS devices that are vulnerable to exploitation

• devices previously conﬁgured with conﬂicting settings and/or

Conﬁguration Proﬁles.

Older Versions of iOS

Each revision of iOS includes many security related ﬁxes. If left

unpatched, iOS devices could be exploited remotely, risking

both employees’ personal information and the security of the

corporate network.

The agency acceptable use policy should require users to install

iOS updates as they become available.

PARTNERING FOR A CYBER SECURE AUSTRALIA

Jailbroken Employee Owned Devices

Jailbroken devices allow users to install applications on their

iOS devices from outside of Apple’s App Store. Though there

are many useful legal purposes for jailbreaking a device,

jailbreaking carries with it a number of negative side effects that

impact the security of the corporate network and the

conﬁdentiality of data stored on a device:

• Jailbreaking usually disables application code signing checks.

These iOS code signing checks help to prevent malware

executing on a device. Removing this makes exploitation

easier.

• Jailbreaking may disable or break important security features

such as Address Space Layout Randomisation (ASLR) and

application sandboxing. ASLR increases the difﬁculty of

successful exploitation of vulnerability. Malware on a jailbroken

device would not be constrained by the application sandbox.

• Jailbroken devices often have serious unpatched operating

system vulnerabilities and are more vulnerable to exploitation.

• Publicly available jailbreaks may contain malware.

• Jailbroken devices should be assumed to be untrusted.

Jailbroken devices are also often able to enrol into market

leading MDM systems without detection. Indeed, there are

applications that have been written with the purpose of evading

MDM agent jailbreak detection. When this occurs,

administrators can not have conﬁdence that Conﬁguration

Proﬁle restrictions and settings are enforced by the operating

system.

Information about a commonly used jailbreak detection bypass

utility is available at:

http://theiphonewiki.com/wiki/XCon

Administrators should not allow employee owned jailbroken iOS

devices to be provisioned on the corporate network.

For all the above reasons it is important to ensure that devices

are sanitised prior to deployment.

Sanitisation Prior To Deployment

When considering how to sanitise employee owned iOS devices

for enterprise deployment, it is important to take into account

the data that employees already have on their devices.

Employees may have expectations about how they will be able

to use their devices and the effect of enterprise deployment on

their device. As an example, an employee might expect their

iPhone’s contact list to be preserved after deployment. If the

device is erased using DFU mode this will not be the case.

If an employee’s personal data is to be preserved, the following

procedure may be performed prior to enterprise deployment:

1. Take a backup of the device

2. Perform DFU mode restore

3. Restore a backup to the device

4. Delete backup from the host

PARTNERING FOR A CYBER SECURE AUSTRALIA

5. Provision and deploy the device as per MDM instructions.

This will clear the existing host trust relationships on the device,

but will preserve the employee’s data. When following this

procedure agencies must consider their legal responsibilities to

protect the privacy of their users’ data.

If there is no need to preserve an employee’s personal data on

a device, agencies should simply perform a DFU mode restore.

Sanitisation For Departing Employees

When an employee departs an agency or no longer requires

iOS device connection to the agency network, it is important to

remove existing host trust relationships from the employee’s iOS

device. On return, agency owned devices should be sanitised

by performing a DFU mode restore as described previously.

Employees should be made aware that agency owned devices

will be sanitised upon return.

In a BYOD model, the following procedure is suggested for

departing employees:

1. Remove MDM proﬁle from the iOS device, which will:

• remove the corporate mail account installed by the MDM

• remove any apps which have been installed by the MDM

which will also remove any associated data

2. Take a backup of the device

3. Perform DFU mode restore

4. Restore backup to the device For more information on this process refer to:

5. Erase backup ﬁles from the host https://support.apple.com/kb/HT5868

6. If the user’s Apple ID is associated with a corporate SIM/

phone number, it is also necessary to de-register iMessage

(https://selfsolve.apple.com/deregister-imessage).

This procedure will also remove any trust relationships

established between the iOS device and any trusted host

computers. If the employee does not return their iOS device

prior to departing, it may be necessary to use the MDM remote

wipe function. Employees should be made aware of this fact in

an agency acceptable use policy.

Removing Trust Relationships

It is possible to remove only the host pairing relationships from a

device without performing a complete device erase. This can be

accomplished by a device user performing the following

procedure:

1. Open the Settings app

2. Select “General” and then “Reset”

3. Select either:

A. “Reset Location & Privacy” which will also restore all

privacy settings to factory default, or

B. “Reset Network Settings” which will also remove Wi-Fi

networks and passwords, Bluetooth pairing records,

VPN settings and APN settings.

PARTNERING FOR A CYBER SECURE AUSTRALIA

CHAPTER 5

Managing

Apps and

Data

Understand and mitigate the risks posed by

installing third party apps.

Managing apps and Data

Installing iOS apps can expand the attack surface of an iOS

device and increase the probability of a leak of sensitive data.

This chapter aims to explain the risks and provide mitigations.

Security Scenarios

Devices running iOS share many of the same security

weaknesses of PCs while at the same time presenting some

new challenges. Presented below are a few common scenarios

that may lead to a leak of sensitive data.

Lost or stolen device

Due to the portable nature of iOS devices, there is always a

chance that a deployed agency device will one day be lost or

stolen.

In many situations remote wipe may not be the most desirable

option, in some situations it will be impossible. In these

situations, adequate data at rest protection is vital. When an

iOS device is conﬁgured following the recommendations given

in this guide, data at rest protection depends upon how third

party app developers have implemented iOS data protection for

ﬁles and if they have made correct use of the Keychain for

credentials.

If we make the following assumptions about a hypothetical

example:

PARTNERING FOR A CYBER SECURE AUSTRALIA

• an iOS device is able to be jailbroken

• has data protection enabled with alphanumeric passcode

• has not been put in to supervised mode

• has 3rd party apps installed

• has been lost or stolen.

If a third party app developer used Class D

(NSFileProtectionNone) data protection class, ﬁles within this

app’s sandbox could be recovered using free or commercial

data recovery tools. As an example, if an instant messaging

client did not utilise data protection appropriately, chat logs and

received ﬁles may be recoverable. If the developer stored

credentials in the ﬁle system rather than using the Keychain, this

could mean that the username and password for this instant

messaging service may also be recoverable.

Even when data protection and the Keychain are used in an

app, they can easily be implemented incorrectly. For example:

• some ﬁles may have an inappropriate data protection class

• existing ﬁles from an older version of the app have not had their

protection class upgraded

• an incorrect Keychain or data protection class may have been

used.

Sensitive information leak

There are a few common ways which apps may leak sensitive

information. Apps may:

• allow a ﬁle to be opened in another app with inappropriate data

protection

• transmit sensitive information over a network with inadequate

encryption

• as part of normal app behaviour, transmit sensitive information

over a network to external servers.

In the ﬁrst case, a good example of an app that shows this

behaviour is the iOS Mail app. Using Mail, it is possible to open

an attachment in another app. For example, an attached PDF

ﬁle may be opened in the iBooks app. If more than one app has

registered a particular ﬁle type, Mail will allow the user to choose

which app they would like to open the ﬁle in. Since the

Dropbox app also registers itself as being able to open PDF

ﬁles, if the user has both iBooks and Dropbox installed mail will

allow a user to open a PDF document in their chosen app, as

shown in Figure 5.1.

Although Mail has been approved by ASD for use up to

PROTECTED, if a user chooses to open an attachment in

another app it may not be subject to adequate data protection.

Additionally, many apps (including iBooks and Dropbox) may

sync ﬁles and metadata to a server on the Internet.

PARTNERING FOR A CYBER SECURE AUSTRALIA

Figure 5.1: Mail app Open-In

Many iOS apps transmit information to other devices on a

network or on the Internet. Often the information transmitted is

not sensitive; however there have been incidents where private

or sensitive data has been transmitted over the Internet without

encryption. For baseline Government systems, the ISM (Control

1162) speciﬁes that: “Agencies must use an encryption product

that implements an AACP if they wish to communicate sensitive

information over public network infrastructure.” For

PROTECTED systems, the ISM (control 0465) speciﬁes that:

“Agencies must use a Common Criteria-evaluated encryption

product that has completed an ACE if they wish to

communicate classiﬁed information over public network

infrastructure.”

Where agencies are utilising On Demand VPN, it is possible that

a user may deliberately or accidentally disable the VPN tunnel.

In this case, your data’s transport security is limited to whatever

scheme the app developer has implemented.

Lastly, there are risks which cannot be mitigated via iOS

technical controls alone:

• copy/pasting sensitive data

• printing sensitive data to the wrong printer

• photographing the screen of the device.

Policy and user education can partially mitigate the case where

any of the above events occur accidentally. Deliberate misuse of

copy/paste and printing can be managed using a combination

of careful custom app development, negotiation with App Store

app developers and in some cases, modiﬁcation of existing

apps using 3rd party add ons.

Copy/paste can be managed through careful app development

using named pasteboards. Likewise, the risk of a user printing

sensitive data to the wrong printer can be managed when

developing custom apps. Some commercial software vendors

offer an “App Wrapping” solution which can be used to alter

copy/paste and print behaviour of existing non App Store apps.

PARTNERING FOR A CYBER SECURE AUSTRALIA

Exploitable Code Errors

Most apps contain software bugs, some of which can be

exploited. Some bugs can be exploited in a way that allows

code execution; others may cause the app to operate in a way

other than it was intended.

Some common types of vulnerabilities that may be exploited in

iOS apps are:

• buffer overﬂows

• uncontrolled format strings

• use after free

• SQL injection.

Apple has implemented a number of anti-exploitation

mitigations in iOS that make successful exploitation of the

above vulnerabilities more difﬁcult. However, it is still important

for in-house app developers to understand the types of coding

errors that can lead to an exploitable vulnerability, and that

operating system generic exploit mitigations do not provide

complete protection for exploitable apps.

Developers should refer to the following resources for more

information:

iOS Security Starting Point

https://developer.apple.com/library/ios/referencelibrary/

GettingStarted/GS_Security_iPhone/index.html

Apple Secure Coding Guide

https://developer.apple.com/library/ios/documentation/Security/

Conceptual/SecureCodingGuide/

iOS Developer Library Security Topic

https://developer.apple.com/library/ios/navigation/

#section=Frameworks&topic=Security

Mitigations

Though it is not possible to fully mitigate all the risks mentioned,

it is possible to substantially reduce their likelihood. This is done

by:

• ensuring apps that handle sensitive data utilise appropriate iOS

data protection classes

• conﬁguring agency devices to disallow host pairing

• restricting Open-In behaviour between managed and unmanaged

apps

• ensuring that agency deployed managed apps are assessed for

weaknesses before deployment.

Though the following guidelines speciﬁcally address apps, they must

equally be applied to app extensions.

Data Protection

If an app is required to write ﬁles containing PROTECTED data

on a locked device from the background, such ﬁles should be

protected using Class B

NSFileProtectionCompleteUnlessOpen, otherwise:

All ﬁles that contain PROTECTED data, created or referenced

by an app must be protected using Class A

NSFileProtectionComplete.

Keychain

If the app requires access to credentials on a locked device

from the background, such credentials should be protected

using the …AfterFirstUnlock or …

AfterFirstUnlockThisDeviceOnly Keychain classes, otherwise:

Credentials must be protected using the …WhenUnlocked or

…WhenUnlockedThisDeviceOnly Keychain classes.

PARTNERING FOR A CYBER SECURE AUSTRALIA

Questions to ask app developers

By asking the following questions, administrators put

themselves in a good position to properly evaluate the risks

associated with installing a particular iOS app:

1. What is the ﬂow of data throughout the application; source,

storage, processing and transmission?

2. Which data protection classes are used to store data?

3. When data is transmitted or received, is it done through a

secure means? Is Secure Transport used? If not why not?

4. What system or user credentials are being stored? Are they

stored using the Keychain Class A? If not why not?

5. Are any URL Schemes or UTIs handled or declared?

6. Is the app compiled as a position independent executable

(PIE)?

7. Is iCloud, or other “Cloud” functionality used?

Note: For further information about iOS app assessment

please refer to the iOS App Assessment Guide published on

OnSecure (https://www.onsecure.gov.au). This guide is also

available on request.

PARTNERING FOR A CYBER SECURE AUSTRALIA

Managed Open-In

Despite best efforts to ensure that agency apps protect data

appropriately, having a single poorly designed app with

registered document types can compromise the security of all

the data on the device.

iOS features a pair of restrictions that help organisations control

this risk:

• “Allow documents from managed sources in unmanaged

destinations”

• “Allow documents from unmanaged sources in managed

destinations”

These restrictions can be used to control Open-In behaviour.

In a deployment where:

• agency apps are deployed by the MDM as Managed apps;

and

• classiﬁed ﬁles are only able to be accessed by the Managed

apps

Disabling the Managed to Unmanaged Open-In behaviour can

be used to mitigate the risk posed by users moving classiﬁed

documents in to their own unmanaged apps.

Important: Agencies may allow unmanaged user app

installation on PROTECTED iOS deployments if the “Allow

documents from managed sources in unmanaged

destinations” restriction is disabled.

Allowing unmanaged user app installation carries with it the

following risks:

1. Improper utilisation of unmanaged apps for sensitive work

This sensitive data may be recoverable if the data was not

stored in an appropriate data protection class if the device

was lost or stolen. There is also the possibility that such

data may be transmitted over the network with or without

transport security to an uncontrolled end point.

2. Device exploitation via hostile App Store app

An App Store app may have hidden functionality designed

to gather and transmit personal or sensitive data to a third

party. It is also possible for an App Store app to

maliciously execute code which is designed to exploit

operating system vulnerabilities. Both risks are signiﬁcantly

mitigated by the relatively hardened iOS runtime

environment, and by a lesser extent, Apple’s App Store

review process.

PARTNERING FOR A CYBER SECURE AUSTRALIA

CHAPTER 6

Suggested

Policies

Our suggested policies for iOS devices used

by Australian government agencies.

Suggested Policies

This chapter lists suggested policies in graduated levels of response, applied to iOS devices at varying security classiﬁcations. The

agency’s Information Technology Security Advisor should be consulted for the speciﬁc usage scenarios for a deployment.

If iOS devices are being considered for use at classiﬁcations above PROTECTED, agencies must undertake a risk assessment

following the guidance in the ISM as well as their own agency security policies and determine mitigation procedures and policy.

Agencies must also obtain appropriate approval for any non-compliance in accordance with the ISM.

PARTNERING FOR A CYBER SECURE AUSTRALIA

Feature

Device selection

BYOD (Bring Your Own Device)

Passcode/TouchID

Apple ID

Home Computer backup

enforcement

iCloud

MDM

Unclassiﬁed

Agency’s decision

Must use passcode or TouchID

Personal or Agency

Stated in agency usage policy

Agencies need to assess the risk in

their own situation

Third party email apps which utilise

native data protection and

transport security may be used.

Recommend use of native mail app

Optional depending on role of

device/scale of deployment

Unclassiﬁed (DLM)

A5 processor or later

May be possible (MDM opt-in for

AUP agreement and enforcement

recommended). See ISM section

on Mobile Devices

Must use passcode or TouchID

Personal or Agency

Stated in agency usage policy

Agencies need to assess the risk in

their own situation

Third party email apps which utilise

iOS native data protection and

transport security may be used.

Recommend use of native mail

app. Exchange with certiﬁcate

authentication

Optional depending on role of

device or scale of deployment,

recommended for BYOD model

Protected

A5 processor or later

May be possible (MDM opt-in for

AUP agreement and enforcement

recommended). See ISM section

on Mobile Devices

Must use passcode

Personal or Agency

Must use Supervised mode and

prevent host pairing

No syncing documents and data,

no Backup, no iCloud Keychain.

iTunes Purchases and iTunes

Match at Agency discretion.

Third party email apps must meet

Chapter 5 data protection/keychain

app requirements.Recommend use

of native mail app. Must use

Exchange with certiﬁcate

authentication and should use TLS

1.2 for transport security

Recommended

Table 6.1: Suggested policies

PARTNERING FOR A CYBER SECURE AUSTRALIA

Feature

Unclassiﬁed

Unclassiﬁed (DLM)

PROTECTED

VPN-on-Demand

Per App VPN

Secure browser

Conﬁguration Proﬁles

User installation of App Store apps

AirDrop

AirPlay

Enterprise SSO

Handoff

Optional depending on role

Recommended

Optional depending on role

Recommended

Optional

Should be cryptographically signed

Agency’s decision, recommend

use of Managed Open-In

Agency’s decision

AirPlay receiver should require

passcode authentication

Agency’s decision

Agency’s Decision

Table 6.1 (continued): Suggested policies

Required, if not using Per App VPN

or VPN “Always-On”

Required, if not using VPN On-

Demand or VPN “Always-On”

Recommended

Must be cryptographically signed

Possible, must use Managed

Open-In restriction to prevent

managed to unmanaged app

document transfer

Agency should disable use of

AirDrop through Conﬁguration

Proﬁle restriction

AirPlay receiver should require

passcode authentication

Recommend use of enterprise

apps which support this feature

Agency should disable Handoff

through Conﬁguration Proﬁle

Restriction

PARTNERING FOR A CYBER SECURE AUSTRALIA

Feature

Extensions

User storage of Home/Health data

on device

iCloud Drive

Managed documents in iCloud

VPN “Always-On”

Touch-ID for in-house App

authentication

Voice and SMS

SIM PIN

Bluetooth

Unclassiﬁed

Agency's decision, recommend

use of Managed Open-In

Stated in agency usage policy

Agencies need to assess the risk in

their own situation

Agency’s decision

Optional depending on role

Recommended in addition to

existing passcode policy

Unclassiﬁed only

Recommended

Disabled, unless required for

speciﬁc business purpose.

Unclassiﬁed (DLM)

Agency's decision, recommend

use of Managed Open-In

Stated in agency usage policy

Agencies need to assess the risk in

their own situation

Agency’s decision

Recommended

Recommended in addition to

existing passcode policy

Unclassiﬁed only

Recommended

Disabled, unless required for

speciﬁc business purpose.

PROTECTED

Possible, must use Managed

Open-In restrictions to maintain

managed/unmanaged container

separation.

Extensions processing

PROTECTED data are required to

comply with the same guidelines

as apps.

Recommend disallowing storage of

personal Home/Health data, stated

in agency usage policy

Disabled

Required if not using VPN On-

Demand or Per-App VPN

Recommended in addition to

existing passcode policy

Unclassiﬁed only

Recommended

Disabled, unless required for

speciﬁc business purpose.

Table 6.1 (continued): Suggested policies

PARTNERING FOR A CYBER SECURE AUSTRALIA

CHAPTER 7

Recommended

Device Proﬁle

Settings

The proﬁle settings that should typically be

used when an iOS device is used on an

Australian government network.

Recommended Device Proﬁle Settings

The following settings are a baseline for use on PROTECTED networks. Agency discretion can be applied to be more restrictive to suit

special requirements, or lowered at lower classiﬁcations in accordance with ISM policy. Where a proﬁle setting is not discussed below,

agencies should examine their own particular technical and policy needs. Apple Conﬁgurator can be used to view the full range of

proﬁle settings that can be deployed.

Proﬁles should be pushed to the device with restrictions and resources bundled. So if the proﬁle is removed by a user, all access to

agency resources is removed.

Pre-loaded Conﬁguration Proﬁles and MDM managed proﬁles can be mixed on devices. In this case the MDM server cannot remove

the pre-loaded proﬁles manually installed on the device.

PARTNERING FOR A CYBER SECURE AUSTRALIA

General Settings

PARTNERING FOR A CYBER SECURE AUSTRALIA

Setting

Security

Automatically

Remove Proﬁle

Recommendation

• Proﬁle Security should be set to “Always” if

setting is for the convenience of users

accessing non-sensitive data (e.g. a subscribed

calendar of Australian public holidays). Opt-In

MDM proﬁles would usually ﬁt into this category

as well.

• Proﬁle security should be set to “With

Authorization” for proﬁles that IT staff can

remove temporarily. Generally users would not

receive the passcode to such proﬁles.

• Most proﬁles that are not MDM managed

should be set to “Never”. The passcode policy

proﬁle, if used, should be set to “Never”.

Conﬁguration Proﬁles can be set for automatic

removal on a speciﬁc date or after a deﬁned

interval.

This function can be used at agency discretion,

typical use cases include:

• Guest user proﬁle

• Temporary proﬁle for overseas travel

(Can be set via EAS or Conﬁguration Proﬁle)

Passcode

Setting

Recommendation

Allow simple value

Disabled

Require alphanumeric value

Enabled

Minimum passcode length

Minimum number of complex

characters

Maximum passcode age

90 days

Auto-lock

5 minutes

Passcode history

Grace period for device lock

None

Maximum number of failed

attempts

* Passcode exponential back off timing begins after 5 attempts.

Allowing 8 attempts will require users wait 21 minutes

cumulatively before forcing a device wipe.

Note: Depending on the EAS version, only some of the above

may be set by the EAS Server and a Conﬁguration Proﬁle

would be required.

PARTNERING FOR A CYBER SECURE AUSTRALIA

Restrictions (Functionality)

PARTNERING FOR A CYBER SECURE AUSTRALIA

Setting

Allow use of camera

Allow FaceTime

Allow screenshots

Allow Airdrop

Allow iMessage

Allow voice dialing

Allow Siri

Allow Siri while device

is locked

Enable Siri profanity

ﬁlter

Show user-generated

content in Siri

Allow iBookstore

Allow installing apps

Recommendation

Up to agency, depending upon acceptable

use policy.

Up to agency. All FaceTime communication

must be Unclassiﬁed.

Disabled

Up to agency. All iMessage communication

must be Unclassiﬁed.

Up to agency

Up to agency. All uses of Siri and Siri

dictation must be treated as Unclassiﬁed.

Disabled

Up to agency. Depending upon acceptable

use policy.

Up to agency. All uses of Siri and Siri

dictation must be treated as Unclassiﬁed.

Up to agency. Depending upon acceptable

use policy.

Up to agency. May be enabled at

PROTECTED when used with “Managed

Open-In” restrictions described below.

Setting

Allow removing apps

Allow In-app purchase

Require iTunes Store

password for all

purchases

Allow iCloud backup

Allow iCloud

documents & data

Allow iCloud keychain

Allow managed apps to

store data in iCloud

Allow backup of

enterprise books

Allow notes and

highlights sync for

enterprise books

Allow iCloud photo

sharing

Recommendation

Up to agency. Disabling may be used to

prevent users from removing business

critical apps.

Up to agency. Depending upon acceptable

use policy.

Enabled

Disabled

Disabled unless managed apps meet ISM

requirements for reducing storage/handling

requirements of the remotely stored data to

Unclassiﬁed.

Up to agency. Recommend disabled when

agency distributes enterprise iBooks

containing sensitive data.

Up to agency. Recommend disabled when

agency distributes enterprise iBooks

containing sensitive data.

Up to agency. If enabled, photos may be

backed up to Apple’s iCloud infrastructure

and distributed to another user’s iOS

devices.

PARTNERING FOR A CYBER SECURE AUSTRALIA

Setting

Allow My Photo Stream

Allow automatic sync

while roaming

Force encrypted

backups

Force limited ad

tracking

Allow Erase All Content

and Settings

Allow users to accept

untrusted TLS

certiﬁcates

Allow automatic

updates to certiﬁcate

trust settings

Allow conﬁguring

restrictions

Allow installing

Conﬁguration Proﬁles

Allow modifying

account settings

Recommendation

Up to agency. If enabled, photos may be

backed up to Apple’s iCloud infrastructure

and distributed to a user’s other iOS

devices.

Enabled

Disabled unless required for users with a

speciﬁc need to erase devices themselves.

Disabled

Enabled

Disabled

Disabled unless required for agency

deployment

Enabled

Setting

Recommendation

Allow modifying cellular

Up to agency.

data app settings

Allow modifying Find

Enabled

my Friends settings

Allow pairing with non-

Disabled

Conﬁgurator hosts

Allow documents from

Disabled. This control helps to prevent

managed source in

documents being opened in unmanaged

unmanaged

user applications.

destinations

Up to agency. If enabled, a user may open

documents from their own unmanaged

Allow documents from

apps into agency managed apps. If

unmanaged sources in

enabled, there is a risk that a managed

managed destinations

app could be exploited by hostile content

from an unmanaged user application.

Recommended disabled at PROTECTED.

Allow Handoff

Disabled

Allow Internet results in

Up to agency. Recommended disabled.

Spotlight

Send diagnostic and

Disabled

usage data to Apple

Allow Touch ID to

Disabled at PROTECTED

unlock device

PARTNERING FOR A CYBER SECURE AUSTRALIA

Setting

Require passcode on

ﬁrst AirPlay pairing

Allow Passbook

notiﬁcations while

locked

Show Control Center in

lock screen

Show Notiﬁcation

Center in lock screen

Show Today view in

lock screen

Recommendation

Enabled

Up to agency. If enabled, passbook items

may be accessible from the lock screen.

Up to agency. If enabled, Wi-Fi and

Bluetooth may be enabled or disabled from

the lock screen.

Disabled

Restrictions (Applications)

PARTNERING FOR A CYBER SECURE AUSTRALIA

Setting

Allow use of YouTube

Allow use of iTunes

Store

Allow use of Podcasts

Allow use of Game

Center

Allow multiplayer

gaming

Allow adding Game

Center friends

Allow use of Safari

Enable AutoFill

Force fraud warning

Enable JavaScript

Block pop-ups

Accept cookies

Recommendation

Up to agency. Depending upon acceptable

use policy.

Up to agency. Depending upon acceptable

use policy.

Up to agency. Depending upon acceptable

use policy.

Up to agency. Depending upon acceptable

use policy.

Up to agency. Depending upon acceptable

use policy.

Up to agency. Depending upon acceptable

use policy.

Enabled

Up to agency. Recommend “From current

website only”

Restrictions (Media Content)

PARTNERING FOR A CYBER SECURE AUSTRALIA

Setting

Ratings Region

Allowed content ratings

(all)

Allow explicit music,

podcasts & iTunes U

Allow explicit sexual

content in iBooks Store

Recommendation

Australia

Up to agency. Depending upon acceptable

use policy.

Up to agency. Depending upon acceptable

use policy.

Up to agency. Depending upon acceptable

use policy.

PARTNERING FOR A CYBER SECURE AUSTRALIA

Wi-Fi

Setting

Service Set Identiﬁer

(SSID)

Hidden Network

Auto Join

Proxy Setup

Security Type

Enterprise Settings

Network Type

Recommendation

As appropriate for agency network

Recommended enabled

As appropriate for agency network

WPA2 Authentication with EAP-TLS and a

pre-shared key as a minimum, per use

RADIUS or 802.1X recommended.

Protocols, authentication and trust to

match network requirements. 802.1X with

device identity certiﬁcate and username/

password is the preferred authentication

mechanism for Unclassiﬁed (DLM) and

higher.

Standard

Global Proxy

PARTNERING FOR A CYBER SECURE AUSTRALIA

Setting

Proxy Type, Server,

Port, Username &

Password

Allow bypassing proxy

to access captive

networks

Recommendation

As appropriate for agency network.

Up to agency. If enabled, the proxy setting

will be bypassed when an iOS device

assesses the connected network to be

“captive” (eg. Paid hotel or airport Wi-Fi).

For most usage scenarios enabling this

defeats the purpose of using global proxy.

Recommended disabled.

Content Filter

The content ﬁlter conﬁguration payload may be used to limit

access to adult websites or to restrict web access to a whitelist

of speciﬁc allowed websites. These restrictions are applied

universally regardless of which network interface is used. Use of

these restrictions is up to the Agency. Some use cases where

these restrictions may be useful:

• where ﬁltering is required and a VPN + proxy conﬁguration is

not feasible

• iOS based information kiosk

PARTNERING FOR A CYBER SECURE AUSTRALIA

Domains

The Domains payload performs two roles; marking external

email addresses in Mail app, and ensuring that Safari treats

downloaded documents as “Managed” while browsing

managed web domains.

Managed Email Domains consists of a whitelist of string

matching expressions for email sufﬁxes. When this payload is

conﬁgured, the iOS Mail app will highlight email addresses

which are not in the whitelist.

Managed Web Domains consists of a list of string matching

expressions for URLs.

A good example of how this may be used with intranet domains

might be to add. “*.intranet.agency.gov.au” which would match:

• https://intranet.agency.gov.au/selfservice

• https://wiki.intranet.agency.gov.au

It would not match the internet facing agency website:

• https://www.agency.gov.au

Note: It is strongly recommended that Managed Web

Domains be conﬁgured to lower the likelihood of

sensitive data breach.

PARTNERING FOR A CYBER SECURE AUSTRALIA

VPN

IPSec and TLS are Approved Cryptographic Protocols, please

refer to the ISM for more information:

http://www.asd.gov.au/infosec/ism/

To help determine the server side settings that iOS supports,

refer to the iOS Deployment Technical reference at:

http://www.apple.com/iphone/business/it/deployment.html

Prior to iOS 7, ASD’s recommended On Demand conﬁguration

was to trigger on a URL whitelist using the

OnDemandMatchDomainAlways Conﬁguration Proﬁle rule. In

iOS 7 this rule has been deprecated and replaced with the new

EvaluateConnection rule set. To create a VPN proﬁle that works

on both iOS 7 and earlier releases, it is necessary to utilise both

EvaluateConnection and OnDemandMatchDomainAlways

together. In such a conﬁguration, iOS 7 and later will use

EvaluateConnection while previous releases will ignore it.

There are several VPN On-Demand conﬁgurations that are

possible at PROTECTED. Examples are:

• Action:Connect on DNSDomainMatch:(array of whitelisted

domains OR wildcard)

• Action:Connect on InterfaceTypeMatch:Cellular,

Action:EvaluateConnection on InterfaceTypeMatch:Wi-Fi

Domains:(whitelist or wildcard)

DomainAction:ConnectIfNeeded RequiredURLStringProbe:

(trusted internal HTTPS server)

PARTNERING FOR A CYBER SECURE AUSTRALIA

Always-on VPN

Always-On VPN is available as a supervised only option for

IKEv2 VPN. Available only on the IKEv2 VPN payload, it ensures

that all network trafﬁc is routed to the VPN. When the VPN can’t

be established, no network trafﬁc is be transmitted.

Always-On VPN may be used in PROTECTED deployments,

and is the simplest VPN conﬁguration solution at this

classiﬁcation.

Setting

Recommendation

Certiﬁcate. Full chain of trust must be

Machine Authentication

included in certiﬁcate (credentials) payload.

As appropriate for agency network. User

PIN is not necessary, certiﬁcate for

Include User PIN

machine authentication is sufﬁcient for

PROTECTED.

iOS 7+: As above, please contact ASD for

assistance at PROTECTED

Enable VPN On

Earlier releases: Enabled with whitelist of

Demand

agency URLs or domains that device is

allowed to access.

Proxy Setup

As appropriate for agency network.

Note: Split tunnel VPN should be disabled (set VPN

concentrator side).

AirPlay Mirroring

The AirPlay mirroring payload may be used to pre-populate a

device with a whitelist of AirPlay devices and AirPlay

passwords. These options can be conﬁgured to assist in

controlling access to AirPlay resources. For AirPlay to AppleTV,

it is recommended that agencies utilise alphanumeric

passcodes to prevent unauthorised use of AirPlay.

Reminder: AirPlay should never be used to transmit video/

audio of a classiﬁcation greater than that of the network the

device is using.

AirPrint

The AirPrint payload may be used to pre-populate a device with

a list of discoverable or undiscoverable AirPrint devices. These

settings are intended for user convenience.

PARTNERING FOR A CYBER SECURE AUSTRALIA

Mail

A Mail payload is not typically needed if EAS (e.g. Exchange

ActiveSync Gateway, Lotus Notes Traveller) is in use. The Mail

payload can co-exist with Exchange. If used, ﬁll with settings

appropriate to agency network.

Setting

Recommendation

Use SSL

Enabled, with authentication.

Allow user to move

messages from this

account

Disabled in deployments where multiple

email accounts of different classiﬁcations

are expected.

Allow Recent Address

syncing

Disabled

Use Only in Mail

Enabling this setting prevents other apps

from sending mail with this account.

Though enabling this option is preferable, it

will break functionality in some third party

apps – including some MDM client apps.

Enable this setting if possible in your

deployment.

Enable S/MIME

Enabled if agency infrastructure supports

S/MIME

Exchange ActiveSync

The EAS server settings should be ﬁlled in as required for the

agency network noting the following consideration:

• Authentication credentials required to control which device

and which users have access to EAS must be added to the

Certiﬁcate/Credentials Payload. The credential required for

authenticating the ActiveSync account can then be selected.

Note: If a proﬁle with an EAS payload is removed, all EAS

synced email and attachments are deleted from the device.

Setting

Recommendation

Use SSL

Enabled, with authentication.

Allow user to move

Disabled in deployments where multiple

messages from this

email accounts of different classiﬁcations

account

are expected.

Allow Recent Address

syncing

Disabled

Enabling this setting prevents other apps

from sending mail with this account.

Though enabling this option is preferable, it

Use Only in Mail

will break functionality in some third party

apps – including some MDM client apps.

Enable this setting if possible in your

deployment.

Enable S/MIME

Enabled if agency infrastructure supports

S/MIME

PARTNERING FOR A CYBER SECURE AUSTRALIA

LDAP

LDAP settings should be ﬁlled in as required for the agency

network. LDAP is not typically needed if Exchange GAL is used,

but can co-exist.

• The “SSL Enabled” option toggles support for TLS. This

should be enabled if supported by agency infrastructure.

Calendar (CalDAV)

CalDAV settings should be ﬁlled in as required for the agency

network. CalDAV may not be needed if Exchange is used, but

can co-exist.

• TLS Enabled if supported by agency infrastructure.

Contacts (CardDAV)

CardDAV settings should be ﬁlled in as required for the agency

network. CardDAV may not be needed if Exchange is used, but

can co-exist.

• TLS Enabled if supported by agency infrastructure.

Subscribed Calendars

Subscribed Calendars settings should be ﬁlled in as required for

the agency network.

• TLS Enabled if supported by agency infrastructure.

Web Clips

Web Clips are “aliases” or links to URLs with a custom icon that

can be installed on a device home screen. Settings should be

ﬁlled in according to the agency’s deployment requirements.

• Typical use would include links to pages for AUP, helpdesk

contact details, telephone URLs, and SCEP re-enrolment

pages. Note that these web pages could use preference

manifest settings in their HTML to work when the site is ofﬂine

or the device is off the network.

• Web clips can also be used to install Enterprise In-House

Applications.

Certiﬁcate (Credentials)

Include SSL chain of trust back to the root CA certiﬁcate,

including intermediates.

SCEP

Simple Certiﬁcate Enrolment Protocol (SCEP) is normally

conﬁgured during Over-The-Air MDM enrolment, however the

Conﬁguration Proﬁle SCEP payload can be used when pre-

conﬁguring SCEP enrolment prior to device issue. Conﬁgure as

necessary for agency deployment.

Advanced/APN

If an APN is used, settings should be ﬁlled in as required for

agency network noting the following considerations:

• Access Point User Name and Password must be used.

PARTNERING FOR A CYBER SECURE AUSTRALIA

• Proxy should be conﬁgured as appropriate.

Details should be discussed with your telecommunications

carrier.

CHAPTER 8

Mobile Device

Management

How to use Mobile Device Management

software to provision, conﬁgure and manage

iOS devices.

Mobile Device

Management

Organisations may use Mobile Device Management (MDM)

software to provision, conﬁgure and manage iOS devices. Basic

MDM functionality can be obtained using Mac OS X Server

Proﬁle Manager. Third party MDM software often features

extended functionality.

Functions

There are four categories of tasks which are implemented under

the Apple MDM protocol: enrolment, device conﬁguration,

device query and device command. Most third party MDM

servers implement the functions which are supported natively

by iOS, some extend the feature set with a client app. This

chapter describes the useful functions which should be

common to most MDM implementations.

Workﬂow Overview

Before a device can be managed it must be enrolled with an

MDM server. There are a variety of ways that this can be

performed. A user may be directed to login to a web portal

where they will be asked to log in and then install an MDM

Conﬁguration Proﬁle.

In other MDM implementations a client app may be installed on

an iOS device. This app may be used to initiate MDM

PARTNERING FOR A CYBER SECURE AUSTRALIA

Conﬁguration Proﬁle installation and device provisioning. Both

methods rely upon Safari to perform the enrolment.

Deployment with Supervision

Though the MDM enrolment process has been designed to

function over the air, at this time device supervision can only be

performed via the USB interface. For PROTECTED

deployments, devices must be put in to supervised mode

before MDM enrolment.

Managing iOS Devices

After devices have been deployed, administrators may need to

change or remove Conﬁguration Proﬁles. Apple’s MDM protocol

allows MDM servers to remove and install proﬁles, but only

under the following conditions:

1. The MDM Payload must have the “Allow installation and

removal of Conﬁguration Proﬁles” access right set.

2. The Conﬁguration Proﬁle in question must have been

installed by the MDM.

In some cases devices may simply need to be reconﬁgured to

support a change in infrastructure or to update certiﬁcates,

however this functionality can also be used to add or remove

more restrictive settings on demand. It should be noted that

some third party MDM vendors provide a geo-fencing function,

which installs or removes Conﬁguration Proﬁles depending

upon location.

If a device is lost or stolen, an MDM administrator can take

several actions to protect agency information. One option

available is to issue a remote wipe command. This action

replaces the ﬁle system key with a new randomly generated

key, permanently rendering all data in the ﬁle system

irrecoverable.

In the event that a user forgets their passcode, the Apple MDM

protocol allows for a remote clear passcode command. Not

only does this command unlock the device, by removing the

passcode it also disables data protection. Consequently, the

issuing of this command immediately modiﬁes the storage and

handling requirements of the device to that of the maximum

classiﬁcation of data stored on the device.

Note: The clear passcode command must not be issued

unless the device owner is in physical possession of the

device. The clear passcode command must never be issued

to a lost or stolen device.

There are a number of methods that are normally used for de-

provisioning iOS devices. These may involve remotely removing

MDM and associated proﬁles or issuing a remote wipe. In

PROTECTED deployments, iOS devices should be returned to

base and de-provisioned using the methods described in

Chapter 4.

Querying Devices

There are a number of query operations supported by Apple’s

MDM protocol, which can be used to ensure that devices

remain in compliance with agency policy. As an example, it is

possible to query a device to ﬁnd out:

PARTNERING FOR A CYBER SECURE AUSTRALIA

• the device’s iOS version

• which Conﬁguration Proﬁles are installed

• the presence/complexity of passcode

• which apps are installed.

Some MDM implementations may allow for predeﬁned or

scripted actions to take place when a device is found to be out

of compliance with policy.

Managed Settings

Though iOS device conﬁguration is almost entirely managed

using Conﬁguration Proﬁles, it is possible for an MDM server to

modify certain speciﬁc options without Conﬁguration Proﬁles.

These managed settings may be modiﬁed at any time and

without user interaction. Managed settings may only be used if

the “Apply Settings” right is set in the MDM payload.

Managed Apps

An MDM server may issue an Install Application command via

the Apple MDM protocol. This command contains either:

• an app’s iTunes store ID for App Store apps

• a URL link to an App’s manifest XML ﬁle for in-house or

custom apps.

Additionally, the command must specify how the app is to be

managed. Namely, whether the app is to be removed when the

MDM proﬁle is removed and whether app data can be backed

up. After receiving a valid Install Application command, an iOS

device will prompt a user to accept the app installation. Apps

that are installed in this way are called Managed apps.

When apps require payment, it is possible for an MDM to

provide a VPP redemption code. In many third party MDM

implementations this function is tightly integrated with an

enterprise app store. It should be noted that App Store apps

cannot be installed if the App Store has been disabled through

Conﬁguration Proﬁle restriction.

Finally, it is possible for an MDM server to issue a Remove

Application command to remotely remove a managed app and

its data. Apps that were not installed as a managed app by the

MDM cannot be removed in this way.

Choosing MDM Software

At the time of writing this guide there are a number of vendors

shipping MDM solutions that have full support for Apple’s MDM

protocol. Some of these MDM solutions focus on the core

functionality provided by Apple’s MDM protocol, others enhance

this by providing additional features via a client app. Many MDM

vendors distribute an MDM solution that can manage multiple

mobile and desktop client platforms. The following information

is provided to help agencies understand functionality commonly

offered by vendors and to describe the advantages and risks of

various deployment options.

Proprietary Functionality

MDM software vendors may have a client app that can interact

with an MDM server. Such apps can interact with a device in

ways beyond that which the Apple MDM protocol allows for.

PARTNERING FOR A CYBER SECURE AUSTRALIA

These MDM client apps do not operate at any elevated level of

privilege, and if installed from the App Store are subject to

normal App Store approval processes.

Email attachment security is a feature that some MDM vendors

provide outside of Apple’s MDM protocol. The purpose of this

function is to prevent the iOS Mail app “Open In” functionality

from opening a sensitive attachment in an untrusted app. One

way that this type of service can work is by an email proxy

transparently encrypting attachments and then having the ﬁle

opened by a client app that has registered the appropriate ﬁle

or data type information with iOS. Typically this allows the ﬁle to

be opened and decrypted by the client app from the iOS Mail

app using “Open In” functionality. Managed Open-In can be

used to achieve a similar outcome.

A valuable proprietary feature that some MDM vendors provide

is an Enterprise App Store. This allows a user to pull the apps

that they require rather than have apps pushed at them. An

Enterprise App Store may exist as a mobile web application or a

native app initially pushed to a device. In both cases this

functionality requires use of native iOS MDM protocol

functionality, but may contain proprietary extensions. Such

Enterprise App Stores often allow administrators to distribute

not only in-house applications but also App Store apps and

Volume Purchase Program (VPP) apps. Such a feature is a

good way for administrators to have some control over which

apps can be installed and to reduce costs by only distributing

paid apps to users that require them.

Frequently MDM vendors also provide a secure container client

app. The purpose of this type of app is to act as a secure

repository for common ﬁle types. Most implementations allow

users to view common ﬁle types while some allow ﬁle editing.

The way in which these types of apps provide security for ﬁles

varies and can include:

• standard iOS data protection

• encryption provided by iOS cryptography libraries

• encryption provided by 3rd party cryptographic software.

Important: Class A data protection in iOS is suﬃcient for

PROTECTED data.

On-premise and MDM Software as a

Service

In addition to on-premise options, several MDM vendors offer

“cloud” MDM Software as a Service (SaaS). The beneﬁt of this

solution is that it frees administrators from having to set up and

maintain a MDM server and often may offer a lower cost of

ownership. In some cases a SaaS MDM solution may have a

tightly integrated client app that improves overall user

experience and reduces administrative burden.

Although there are many advantages to this MDM model, there

are also signiﬁcant risks. At a fundamental level, an MDM server

controls access to agency information and authority over the

conﬁguration of the devices it manages. For example, an MDM

routinely processes or stores:

PARTNERING FOR A CYBER SECURE AUSTRALIA

• key material that can be used to unlock a device that is

passcode protected

• Conﬁguration Proﬁle data for MDM enrolment and credentials

for access to an agency’s network.

Since key material is classiﬁed at the same level of the data it is

protecting, the systems used by the MDM service provider must

be accredited to the same minimum standard as the

sponsoring agency’s systems.

Should the MDM be compromised, an adversary may be able

to perform all tasks an MDM is capable of. This may include:

• using escrow keybag material to unlock passcode protected

devices

• provisioning unauthorised devices

• distributing hostile apps.

Additionally, an adversary may also be able to leverage

information in Conﬁguration Proﬁles to establish VPN or Wi-Fi

connections to agency networks.

To protect against the risk of unauthorised access to data by a

third party, agencies must follow ASD’s Industry Engagement

and Outsourcing guidance in the ISM. Administrators are also

strongly advised to read ASD’s Cloud Computing Security

Considerations before proceeding with a SaaS MDM

deployment, available at:

http://www.asd.gov.au/infosec/cloudsecurity.htm

CHAPTER 9

Security

Checklist

Ensure that all key tasks in securely deploying

iOS devices have been completed.

Before Deploying iOS Devices

Develop agency policy and

procedures, including any

restrictions, for the use of iOS

devices that align with Australian

Government legislation, policies and

standards, and that adhere to

Australian government requirements.

Effective policies and procedures help to

ensure that an agency considers

relevant issues and operates in

accordance with legislation and whole-

of-government guidelines. Documenting

and making these available to users will

help ensure that users are aware of an

agency’s expectations of them when

using mobile devices. On iOS devices,

placing a policy Web Clip on the device

makes it highly accessible to the user.

Implement processes to security

classify, protectively mark, and

control the ﬂow of information that

may be transmitted to/from the iOS

device.

Email ﬁltering solutions can ﬁlter and

mark email based on header metadata

and shorthand notation in the subject

line. Agencies must security classify and

protectively mark all email, and controls

must be implemented at email servers

and gateways to restrict delivery of

inappropriately classiﬁed information to

and from an agency, including to mobile

devices.

Undertake an iOS device pre-

implementation review.

Agencies deploying iOS devices may

consider undertaking a pre-

implementation review. This review

would assess the planned deployment

strategy, mitigation controls, policies and

procedures against the requirements

deﬁned in the relevant policy and

guidance documents. ASD can assist in

ensuring the necessary steps have been

followed.

PARTNERING FOR A CYBER SECURE AUSTRALIA

Manage Use of iOS Devices

Provide users with training on the use

of iOS devices and security

requirements.

In many areas of administration, failure

to follow policies and procedures is not

a result of deliberate actions, but a lack

of awareness of requirements. Training

can assist users to implement policies

and procedures. The existence of

training can also help distinguish

deliberate misuse from incompetent

usage. As part of this training agencies

should also inform users that these

devices are likely to be an attractive

target for thieves, and that the

implications of the information contained

in them being accessed by others could

be detrimental to the Australian

government.

Ensure that users formally

acknowledge their agreement to

adhere to agency speciﬁc Acceptable

Usage Policy and procedures.

Users must be aware of and agree with

the agency’s policy and procedures. The

ramiﬁcations of failing to apply those

policies and procedures must also be

clear to users.

Ensure that users classify and

protectively mark all email with the

highest classiﬁcation of the content

or attachment, in accordance with

Australian government standards.

Users must be conscious of the security

classiﬁcation of information that they are

sending to or from mobile devices.

Agencies must ensure that users

classify and protectively mark all

agency-originated email or attachments

in accordance with the highest

classiﬁcation of the content.

PARTNERING FOR A CYBER SECURE AUSTRALIA

Infrastructure Considerations

Server infrastructure for EAS, MDM,

Web and associated CA

infrastructure that supports an iOS

deployment must be controlled,

either directly or under contract, by

the Australian government.

These servers should be situated in a

controlled environment, and will permit

the implementation of consistent policy

and device settings.

In many cases, SaaS solutions may not

be acceptable for iOS MDM

deployments.

Agencies must ensure that content is

transferred between an iOS device

and an agency’s ICT systems in

accordance with Australian

government policy.

Email protective marking ﬁltering

mechanisms must be implemented to

provide a higher level of security by

automatically preventing information of

an inappropriate classiﬁcation being

sent to a mobile device. These

mechanisms are described in the Email

Protective Marking Standard

Implementation Guide for the Australian

Government, available at:

http://www.ﬁnance.gov.au/ﬁles/

2012/04/email_pmsig.pdf

Ensure that email originating outside

the agency is not sent to the iOS

device unless it is classiﬁed and

labelled appropriately.

Communications originating outside the

agency may also include classiﬁed

information. The policies and standards

applied to external communications

must also be applied to internally

generated information. Emails that do

not have protective markings should not

be transmitted to mobile devices.

Agency policy may deﬁne a subset, e.g.

an agency may only permit Unclassiﬁed

information to be forwarded to a mobile

device. These mechanisms are

described in the Email Protective

Marking Standard Implementation Guide

for the Australian Government.

PARTNERING FOR A CYBER SECURE AUSTRALIA

Review and Audit

Undertake an iOS post implementation review.

Agencies that deploy iOS devices must undertake a post

implementation review. This may assist in identifying policy and

implementation inconsistencies and assess the mitigation

controls for completeness against the Security Risk

Management Plan (SRMP), the System Security Plan (SSP),

Standard Operating Procedures (SOP) and the implementation

of email protective marking controls. This review must be

completed within twelve months of the live production

deployment.

Audit compliance with policies and standards for the use of

iOS devices.

Setting out policy without monitoring compliance is unsound

practice. There should be appropriate internal and – from time

to time – external checks of compliance with policies regarding

the use of mobile devices. There should also be regular reviews

of internal policies, to test their currency and adequacy.

CHAPTER 10

Example

Scenarios

This chapter describes hypothetical scenarios

showing how the various techniques can be

combined.

Unclassiﬁed kiosk

An art gallery wishes to use iPod touches as an interactive tour guide for Unclassiﬁed information at a speciﬁc site. The tour guide

information is largely contained within a single app.

The gallery purchased an Enterprise Developer Agreement, and uses this to code-sign the app they have had developed by a

contractor.

The gallery set up a Wi-Fi network for the site, and uses a provisioning computer with Apple Conﬁgurator to supervise and then “lock

to” their developed app. Devices can be deployed, managed and reset with minimal effort.

Unclassiﬁed (DLM) BYOD

An agency has decided to allow limited corporate network access to employee owned devices. Users are required to enrol their

device in to the agency MDM and agree with an acceptable use policy.

The agency uses a 3rd party MDM server to enforce Conﬁguration Proﬁle restrictions and audit devices for compliance. Non-compliant

devices have their MDM proﬁle and associated managed apps and data revoked immediately. Conﬁguration Proﬁles take advantage of

the Managed Open-In function to prevent movement of documents from agency managed apps and email to user personal apps and

email.

A Wi-Fi network is conﬁgured according to relevant ISM government system (G) controls is deployed on premise, permitting limited

corporate network access via VPN and limited personal use through an authenticated proxy. Email is provided using the native iOS

Mail app using Exchange Active Sync (EAS) over TLS.

PROTECTED with limited personal use

An agency has decided to issue iOS devices for work and limited personal use. The users require access to PROTECTED email and

attachments as well as access to their PROTECTED intranet. The agency permits user installation of App Store apps subject to

agreement with an acceptable use policy. Personal email is permitted using the iOS native mail app.

In this case, the agency uses an MDM server, a VPN concentrator for remote access, Exchange for email, a third party gateway ﬁlter

and Apple Conﬁgurator to place devices in to supervised mode. The iOS devices use a client certiﬁcate for authentication to

Exchange, and a client certiﬁcate is used for On-Demand VPN authentication. Conﬁguration Proﬁles take advantage of the Managed

PARTNERING FOR A CYBER SECURE AUSTRALIA

Open-In function to prevent movement of documents from agency managed apps and email to user personal apps and email. The

third party gateway ﬁlter is conﬁgured to implement protective markings on email sent from devices. A Wi-Fi network conﬁgured

according to relevant ISM government system (G) controls is deployed on premise permitting corporate network access via VPN and

limited personal use through a authenticated proxy.

Figure 10.1: Example network diagram for limited personal use

PARTNERING FOR A CYBER SECURE AUSTRALIA

PROTECTED business only

An agency has decided to issue iOS devices for their mobile ﬂeet. Their users require access to their PROTECTED email and

attachments, as well as access to a PROTECTED intranet.

The IT team will use Apple Conﬁgurator to conﬁgure the devices before they are issued to users. The devices will be conﬁgured as

supervised devices and will be pre-enrolled with the agency’s MDM server.

The devices connect to the agency’s exchange server using a client certiﬁcate for authentication. The IKEv2 VPN is conﬁgured as

“Always On” with certiﬁcate authentication; this forces all trafﬁc over the VPN. Access to internal web resources on the corporate

intranet is allowed through an authenticated proxy.

The agency requires all users to sign an acceptable use policy that requires them to install OTA updates when they are available.

Compliance will be monitored by the IT team using the MDM.

Figure 10.2: Example network diagram for limited personal use

PARTNERING FOR A CYBER SECURE AUSTRALIA

CHAPTER 11

Risk

Management

Guide

This chapter provides a guide to typical risks

associated with mobile devices and

recommended mitigation measures.

Australian Government Information Security Manual (ISM)

This chapter should be read in conjunction with the ISM, available from the ASD website:

http://www.asd.gov.au/infosec/ism/

Currently, not all ISM requirements can be implemented on iOS 8 devices. Risk mitigation measures are provided in this chapter for

such cases.

Mobile Device Risks

Typical risks, the recommended mitigation measures and the pre-conditions for those mitigation measures are covered in the table

below. There are several residual risks in ISM policy that cannot be completely mitigated by technical controls. Agencies will need to

assess, accept and manage any residual risks and develop appropriate policy guidance.

iOS does not have a local ﬁrewall. This is partially mitigated by agency ﬁrewalls, and signiﬁcantly mitigated by the sandboxed runtime

environment in iOS.

iOS allows the user to deliberately connect to an untrusted Wi-Fi network. Note that iOS devices will not auto-connect to any

unknown Wi-Fi network. The only mitigations available at this time are pre-conﬁgured settings, user education and AUP.

iOS allows the user to deliberately enable or disable the radio transceivers (e.g. Wi-Fi, Bluetooth) in the device - there is no method for

a Conﬁguration Proﬁle to force a radio transceiver off. The only mitigations available at this time are user education, AUP or hardware

modiﬁcation (the latter being permanent).

PARTNERING FOR A CYBER SECURE AUSTRALIA

Risk

Mitigation

Implied Preconditions

Device lost, still on network

Device lost, off network

Device lost, casual access attempt

Device lost, forensic access attempt without

passcode knowledge

Jailbreaking

Malicious runtime code

Strong passcode, data protection enabled, local

wipe, remote wipe, Find My iPhone/iPad.

Strong passcode, local wipe, data protection

enabled.

Strong passcode, local wipe, data protection

enabled.

Strong passcode, local wipe, use of supervised

mode, data protection enabled, app usage of

appropriate data protection class.

Strong passcode, data protection enabled, use

of devices with A5 or later processor, use of

MDM console, use of supervised mode, MDM

app or enterprise apps with “canary” code to

detect and report jailbreaking, AUP should

prohibit jailbreaking.

Code signing, memory and ﬁlesystem

sandboxing, no-execute heap, disable user-

added applications, do not jailbreak operational

devices and (for App Store apps) the App Store

review process.

Conﬁguration Proﬁles, EAS or MDM Server in a

network reachable location or iCloud account.

Passcode requirement via conﬁg proﬁle

Passcode requirement via conﬁg proﬁle,

supervised to prevent pairing

Conﬁguration Proﬁles, device running up to

date iOS. Device in supervised mode.

Jailbreaking from host computer when device

passcode is known is still likely to be feasible,

unless supervised mode is used.

In-house application development capability,

CA infrastructure. May mitigate on lower

security levels by “approved” lists and MDM

monitoring as mitigation.

Table 11.1: Risk management guide

PARTNERING FOR A CYBER SECURE AUSTRALIA

Risk

Users cut and paste agency data into a public

email account (e.g. Yahoo or Gmail ) and send

it from the device.

Users cut and paste sensitive data from a

managed app to an unmanaged app.

Untrusted devices connect to agency network.

Mitigation

Disable the creation of separate email

accounts, and restrict access to webmail via

custom APN and agency proxy, disable screen

shots on device via Conﬁguration Proﬁle, ﬁlter

sensitive mail or attachments at the EAS

gateway, use of VDI for sensitive email, contain

agency email to a third party email app

container.

Ensure that managed apps take advantage of

named pasteboards, disable use of copy paste

through third party app wrapping.

Explain risk of accidental disclosure of

classiﬁed information via copy/paste in AUP.

Use of 802.1X NAC, IPSEC or TLS VPN,

encrypted VDI.

Table 11.1 (continued): Risk management guide

Implied Preconditions

Conﬁguration Proﬁles, use of agency proxy.

Note that any data that is displayed on the

screen of any device can be photographed or

video recorded by a camera, and sent via other

means. This kind of leakage by deliberate

action generally cannot be mitigated against for

a mobile device.

Custom apps for named pasteboards/wrapping.

For App Store apps, agencies can engage with

developers directly to procure custom builds.

Use of 802.1X with CA & NAC on Wireless,

VPN on Demand with client certiﬁcates for

agency network access, use of TLS reverse

proxy for low security data.

PARTNERING FOR A CYBER SECURE AUSTRALIA

Risk

Mitigation

Implied Preconditions

Data compromise via host computer backup

Data compromise via Bluetooth

Accidental disclosure of classiﬁed information

via iMessage

SMS message interception by hostile

telecommunications infrastructure

Force encrypted backup proﬁle restriction, user

education, physical security of backup host.

Prevent host pairing with supervised mode.

iOS allows a limited subset of Bluetooth

proﬁles, depending on device, and speciﬁcally

does not include ﬁle transfer related Bluetooth

proﬁles. For included proﬁles see:

http://support.apple.com/kb/HT3647

Educate users of the risk of accidental

disclosure of classiﬁed information via “Open-

In” iMessage in AUP. Disable iMessage via

Conﬁguration Proﬁle restriction.

Allow iMessage use via Conﬁguration Proﬁle.

Table 11.1 (continued): Risk management guide

TLS CA infrastructure to sign and encrypt

proﬁles into agency chain of trust.

Apps that share information via Bluetooth not

approved for use on devices where this vector

is a concern.

That the risk of accidental disclosure of

classiﬁed information via Open-In is greater

than the utility of iMessage.

Contact ASD to discuss particular user travel

circumstances.

PARTNERING FOR A CYBER SECURE AUSTRALIA

CHAPTER 12

Firewall Rules

Allow required iOS functionality while

preserving the security of your network.

Firewall Rules

Several ﬁrewall rules may need to be implemented to allow correct functionality. Depending on what functionality is required from iOS

devices, MDM servers and iTunes, several ﬁrewall rules may need to be implemented.

Firewall Ports

iTunes and iOS devices may need ﬁrewall rules adjusted, depending on the functionality required, or allowed, on an intranet. The main

knowledge base articles describing ports required by Apple devices are given below, with a summary around iOS and iTunes in Table

12.1 (below):

http://support.apple.com/kb/TS1379

http://support.apple.com/kb/TS1629

PARTNERING FOR A CYBER SECURE AUSTRALIA

Destination host name

ocsp.apple.com

crl.apple.com

gateway.push.apple.com

feedback.push.apple.com

phobos.apple.com

itunes.apple.com

deimos.apple.com

deimos3.apple.com

ax.itunes.apple.com

gs.apple.com

albert.apple.com

ax.init.itunes.apple.com

evintl-ocsp.verisign.com

evsecure-ocsp.verisign.com

a1535.phobos.apple.com

Destination IP

17.0.0.0/8

199.7.55.72

17.0.0.0/8

Port

443

2195

2196

80, 443

Table 12.1: Firewall rules.

Reason

Online Certiﬁcate Status for code signing

certiﬁcates

Certiﬁcate Revocation List for

codesigning certiﬁcates

Apple Push Notiﬁcation Service

iTunes Store, Device activation

iTunes U

iTunes Music Store and album cover

media servers.

iTunes Store, Device activation

Device activation

Digital signature veriﬁcation for iTunes

content

Digital signature veriﬁcation for iTunes

content

iTunes Music Store and album cover

media servers.

PARTNERING FOR A CYBER SECURE AUSTRALIA

I OS8 Hardening Guide

Navigation menu

Versions of this User Manual:

Views

Navigation