This guidance is applicable to all Apple devices running OS X 10.8. This guidance was developed following testing performed on MacBook Pro and MacBook Air devices running OS X 10.8.3.
1. Usage Scenario
OS X devices will be used remotely over Ethernet and Wi-Fi networks to connect back to the enterprise over a VPN. This enables a variety of remote working approaches such as
- accessing OFFICIAL email;
- creating, editing, reviewing and commenting on OFFICIAL documents;
- accessing OFFICIAL intranet resources, the internet and other web-resources.
To support these scenarios, the following architectural choices are recommended:
- All data should be routed over a secure enterprise VPN to ensure the confidentiality and integrity of the traffic, and to benefit from enterprise protective monitoring solutions.
- User accounts are created locally on the OS X devices and managed remotely using MDM.
- Arbitrary third-party application installation by users is not permitted on the device. Applications which users require should be pre-installed before users are assigned devices, be provisioned as part of the device image, or installed using MDM.
2. Summary of Platform Security
This platform has been assessed against each of the twelve security recommendations, and that assessment is shown in the table below. Explanatory text indicates that there is something related to that recommendation that the risk owners should be aware of. Rows marked [!] represent a more significant risk. See How the Platform Can Best Satisfy the Security Recommendations for more details about how each of the security recommendations is met.
|1. Assured data-in-transit protection||The VPN has not been independently assured to Foundation Grade, and does not support some of the mandatory requirements expected from assured VPNs.|
|2. Assured data-at-rest protection||FileVault 2 has not been independently assured to Foundation Grade.|
|4. Secure boot||Secure boot is not supported on this platform.|
|5. Platform integrity and application sandboxing|
|6. Application whitelisting|
|7. Malicious code detection and prevention|
|8. Security policy enforcement|
|9. External interface protection|
|10. Device update policy||The enterprise cannot force the user to update their device or software.|
|11. Event collection for enterprise analysis|
|12. Incident response|
The VPN has not been independently assured to Foundation Grade, and does not support some of the mandatory requirements expected from assured VPNs. Without assurance in the VPN there is a risk that data transiting from the device could be compromised.
The FileVault 2 full volume encryption product has not been independently assured to Foundation Grade, and does not support some of the mandatory requirements expected from assured full disk encryption products. Without assurance in FileVault 2 there is a risk that data stored on the device could be compromised.
FileVault 2 does not use any dedicated hardware to protect its keys. If an attacker can get physical access to the device, they can extract password hashes and perform an offline brute-force attack to recover the encryption password.
Most OS X devices have external interfaces which permit Direct Memory Access (DMA) from connected peripherals. Whilst the configuration in this section limits DMA to only times when the user is logged in, this still presents an opportunity for a local attacker to extract keys and data.
3. How the Platform Can Best Satisfy the Security Recommendations
This section details the platform security mechanisms which best address each of the security recommendations.
3.1 Assured data-in-transit protection
Use the native IPsec VPN client until a Foundation Grade VPN client for this platform becomes available.
3.2 Assured data-at-rest protection
Use FileVault 2 to provide full volume encryption. CESG recommend the use of a complex password of at least 9 characters in length, or of at least 6 characters in length when used in conjunction with a second factor.
The user implicitly authenticates to the device by decrypting the disk at boot time.
The user then has a secondary password to authenticate themselves to the device at boot and unlock time. This password also derives a key which encrypts certificates and other credentials, giving access to enterprise services.
3.4 Secure boot
An EFI password can make it more difficult for an attacker to modify the boot process. With physical access, the boot process can still be compromised.
3.5 Platform integrity and application sandboxing
These requirements are met implicitly by the platform. Sandbox profiles limit App Store applications’ access to the platform. Other applications can be configured to use sandboxes if required.
3.6 Application whitelisting
The MDM can be used to whitelist default OS X applications. Installation and running of unsigned applications can be prevented with GateKeeper.
3.7 Malicious code detection and prevention
Several third-party anti-malware products exist which attempt to detect malicious code for this platform. An enterprise application catalogue can be used which should only contain vetted apps. Content-based attacks can be filtered by scanning capabilities in the enterprise.
3.8 Security policy enforcement
MDM profiles can be marked as non-removable so the user cannot remove it and alter the configuration.
3.9 External interface protection
USB removable media can be blocked through MDM if required. If an EFI password is set, DMA is only possible when the device is booted and unlocked. Kernel Modules for other interfaces (e.g. Firewire) can be removed if required, but will be re-installed during OS updates.
3.10 Device update policy
MDM can be used to audit which App Store software and OS versions are installed on a device. The enterprise cannot control when the applications or OS software are updated. These updates rely on user interaction.
3.11 Event collection for enterprise analysis
OS X logs can be viewed by a local administrator on device, or viewed remotely using remote administration tools. Third-party software can also be used to automate log collection.
3.12 Incident response
OS X devices can be locked, wiped, and configured remotely by their MDM.
4. Network Architecture
All remote or mobile working scenarios should use a typical remote access architecture based on the Walled Garden Architectural Pattern. The following network diagram describes the recommended architecture for this platform.
An MDM server is required. Apple’s OS X Server Profile Manager is sufficient for this purpose; alternatively, third-party products exist which may offer additional functionality over and above Profile Manager.
5. Deployment Process
The following steps should be followed to prepare the enterprise infrastructure for hosting a deployment of these devices.
Set up Profile Manager on OS X Server. This will require also setting up the Open Directory component.
Ensure all Configuration Profiles are signed to prevent modification in transit or once they are installed
Create policies on Profile Manager for:
VPN (see Policy Settings section)
Passcode Policy (see Policy Settings section)
Exchange/Mail/Calendar Settings as appropriate.
- Ensure ‘Use SSL’ is selected for all server settings
Disable access to the Preference Panes in Restrictions (OS X) for iCloud, Profiles and Network as access to these could be used to disable the VPN or access and remove management profiles.
You can also consider creating policies in other sections of Profile Manager. Some recommendations are:
Whitelisting applications to further reduce the risk of malicious code being executed.
Tightening permissions on USB mass storage and optical devices to help prevent data loss through removable media.
Use Restrictions to blacklist locations users should not run applications from, or whitelist trusted applications that users are allowed to run.
6. Provisioning Steps
The following steps should be followed to provision each end user device onto the enterprise network to prepare it for distribution to end users.
These instructions assume the device is new or the operating system has been wiped and reinstalled.
On first boot, the device will prompt you to take several actions:
Firstly, create a local Administrator account. This will be used to locally manage the device and credentials should not be given to the end user. A strong password should be entered at this stage.
Secondly, skip the Apple ID creation and entry.
Location Services can be enabled if required.
The device can be registered with Apple if required.
Local settings should now be set. A script is provided at the end of this section to automatically provision these settings, but they can also be configured manually.
Disable any non-required services (eg IPv6, infrared);
Enable low-overhead security features (eg firewall, secure trash, updates);
Set user security policies (eg timeouts, screen lock, password hints);
Create a standard user account;
Make the user’s home folder only be accessible to that user;
Create a Disk Encryption user which will have a strong password that can decrypt the disk. Part of this password could be from a password entry token such as a YubiKey. The Disk Encryption password should be at least 9 characters long, or 6 characters plus a longer fixed string from the Password Entry Token (>16 characters recommended).
- Alternatively, increase the password complexity of the primary user to >9 characters so that there is only one password required to decrypt and log in. A 6 character password with 16 characters from a password entry token could be used here instead of the 9 character password.
Enable FileVault 2 and encrypt the disk; only give the Disk Encryption user access to decrypt the disk;
Set FileVault 2 to remove the key on sleep, and set the sleep mode to Hibernate;
To help prevent DMA and cold boot attacks, set a Firmware Password.
The device should now be enrolled with the MDM server and the configuration profiles applied.
At this stage, any additional third-party applications can be installed (e.g. productivity apps)
Distribute the device, disk encryption password and user password separately to the user.
The user should then change their password and skip the Apple ID registration step at the next time they log on.
6.1 Device Imaging
Instead of provisioning each device individually, an alternative option is to produce a master device image which can be deployed onto devices. The recommended approach for creating a standard disk image is to install the OS, create a local admin account and apply local policies, then install any required applications on a client machine.
The client machine is then connected to an imaging server in target disk mode. Apple’s System Image Utility can then be used to create a NetRestore or NetBoot image of the device. The image can then be used to provision other machines. NetBoot images can also be created from OS X installers downloaded from Apple, though care should be taken to ensure that the version downloaded can be deployed on the specific hardware to be used.
Note that enabling FileVault 2 and MDM enrolment must only be done after the device has been imaged. This means that the cryptographic keys involved in these security features are different.
Apple’s website contains a support article that contains details about creating images for device specific versions of OS X. The article can be found at http://support.apple.com/kb/HT5599.
7. Policy Recommendations
This section details important security policy settings which are recommended for an OS X deployment. Other settings (e.g server address etc.) should be chosen according to the relevant network configuration. These settings should be applied through a profile (or combination of profiles) created on the MDM server.
The settings below are named as they appear in Apple Configurator and Profile Manager. Other products may use different names for these settings.
|Security (when can profile be removed)||Never|
|Automatic profile removal||Never|
|Allow simple value||No|
|Require alphanumeric value||Yes|
|Minimum passcode length||7 This is for the login password if using separate passwords for encryption and login. The disk encryption password is managed elsewhere.|
|Minimum number of complex characters||1|
|Maximum passcode age||90 (days)|
|Maximum Auto-Lock||5 (minutes)|
|Maximum number of failed attempts||5|
|Mail/Exchange/Calendar Groups (as appropriate)|
|Allow messages to be moved||No|
|Use Only in Mail||Yes|
|Use SSL (for internal and external host)||Yes|
|Connection Type||IPsec (Cisco)|
|Enable VPN on Demand||Yes Add the 36 wildcard hosts a., b., c., ..., z., 0., 1., 2., ..., 9. with the On Demand action as ‘always’|
|Security & Privacy Group|
|Send diagnostic and usage data to Apple||No|
|Do not allow user to override Gatekeeper setting||Yes|
|Restrict which system preferences are enabled||Yes Network, Profiles, Sharing and iCloud should be disallowed. Other panes may be disabled at the organisation’s discretion.|
|Restrict App Store to software updates only||Yes|
The media access settings can be used to limit user access to removable media such as USB drives and writable optical media.
7.1 VPN Profile
|IKE DH Group||5 (1536-bit)|
|IKE Encryption Algorithm||AES-128|
|IKE Hash Algorithm||SHA-1|
|IKE Authentication Method||RSA X.509|
|SA Lifetime||24 hours|
|VPN On Demand||Always Enter the 36 wildcard domains a., b., c., …, z., 0., 1., … 9. to ensure the VPN triggers for all domains and IP addresses|
Note that for an OS X device to verify the VPN server certificate, the certificate must have an alternate subject name entry that matches the common name.
7.2 Other settings
If not required, Bluetooth and Wi-Fi should be turned off before giving the device to the user. The user will be able to turn Wi-Fi back on if they need it.
Kernel Modules can be removed to prevent access to removable media and network interfaces, but this is unsupported and will be reset during some software updates. Instructions on how to do this can be found on pages 249 onwards of https://ssl.apple.com/support/security/guides/docs/SnowLeopard_Security_Config_v10.6.pdf
8. Enterprise Considerations
The following points are in addition to the common enterprise considerations, and contain specific issues for OS X deployments.
Users must not enable iCloud as this provides device control to Apple and may allow data to leak through iCloud backup and application storage. This can be achieved by not signing into the Apple ID when prompted by the operating system. Other Apple applications such as iTunes can be used with an Apple ID without enabling iCloud integration if this is required.