Yesterday Apple released iOS 7.06, an important security update you have probably seen blasted across many other sites. A couple points:

Apple normally doesn’t issue single-bug out-of-cycle security patches for non-public vulnerabilities. They especially don’t release a patch when the same vulnerability may be present on OS X but there isn’t an OS X patch yet. I hate speculating, especially where Apple is concerned, but Apple has some reason for handling this bug this way. Active exploitation is one possibility, and expectations of a public full disclosure is another.

The bug makes SSL worthless if an attacker is on the same network as you.

OS X appears vulnerable (10.9 for sure). There is no public patch yet. This will very likely be remediated very quickly.

A lot of bad things can be done with this, but it isn’t a remotely exploitable malware kind of bug (yes, you might be able to use it locally to mess with updates – researchers will probably check that before the weekend is out). It is bad for Man in the Middle (MitM) attacks, but it isn’t like someone can push a button and get malware on all our iOS devices.

I have been working on this one quietly for a while. It is a massive update to my previous paper on iOS security.

It turns out Apple made a ton of very significant changes in iOS 7. So many that they have upended how we think of the platform. This paper digs into the philosophy behind Apple’s choices, details the security options, and then provides a detailed spectrum of approaches for managing enterprise data on iOS. It is 30 pages but you can focus on the sections that matter to you.

Normally we publish everything as a blog series, but in this case I had an existing 30-page paper to update and it didn’t make sense to (re-)blog all the content. So you might have noticed me slipping in a few posts on iOS 7 recently with the important changes. I can do another revision if anyone finds major problems.

I am currently polishing off the first draft of my Data Security for iOS 7 paper, and reached one fascinating conclusion during the research which I want to push out early. Apple’ approach is implementing is very different from the way we normally view BYOD. Apple’s focus is on providing a consistent, non-degraded user experience while still allowing enterprise control. Apple enforces this by taking an active role in mediating mobile device management between the user and the enterprise, treating both as equals. We haven’t really seen this before – even when companies like Blackberry handle aspects of security and MDM, they don’t simultaneously treat the device as something the user owns. Enough blather – here you go…

Apple has a very clear vision of the role of iOS devices in the enterprise. There is BYOD, and there are enterprise-owned devices, with nearly completely different models for each. The owner of the device defines the security and management model.

In Apple’s BYOD model users own their devices, enterprises own enterprise data and apps on devices, and the user experience never suffers. No dual personas. No virtual machines. A seamless experience, with data and apps intermingled but sandboxed. The model is far from perfect today, with one major gap, but iOS 7 is the clearest expression of this direction yet, and only the foolish would expect Apple to change any time soon.

Enterprise-owned devices support absolute control by IT, down to the new-device provisioning experience. Organizations can degrade features as much as they want and need, but the devices will, as much as allowed, still provide the complete iOS experience.

In the first case users allow the enterprise space on their device, while the enterprise allows users access to enterprise resources; in the second model the enterprise owns everything. The split is so clear that it is actually difficult for the enterprise to implement supervised mode on an employee-owned device.

We will explain the specifics as we go along, but here are a few examples to highlight the different models.

On employee owned devices:

The enterprise sends a configuration profile that the user can choose to accept or decline.

If the user accepts it, certain minimal security can be required, such as passcode settings.

The user gains access to their corporate email, but cannot move messages to other email accounts without permission.

The enterprise can install managed apps, which can be set to only allow data to flow between them and managed accounts (email). These may be enterprise apps or enterprise licenses for other commercial apps. If the enterprise pays for it, they own it.

The user otherwise controls all their personal accounts, apps, and information on the device.

All this is done without exposing any user data (like the user’s iTunes Store account) to the enterprise.

If the user opts out of enterprise control (which they can do whenever they want) they lose access to all enterprise features, accounts, and apps. The enterprise can also erase their ‘footprint’ remotely whenever they want.

The device is still tied to the user’s iCloud account, including Activation Lock to prevent anyone, even the enterprise, from taking the device and using it without permission.

On enterprise owned devices:

The enterprise controls the entire provisioning process, from before the box is even opened.

When the user first opens the box and starts their assigned device, the entire experience is managed by the enterprise, down to which setup screens display.

The enterprise controls all apps, settings, and features of the device, down to disabling the camera and restricting network settings.

The device can never be associated with a user’s iCloud account for Activation Lock; the enterprise owns it.

This model is quite different from the way security and management were handled on iOS 6, and runs deeper than most people realize. While there are gaps, especially in the BYOD controls, it is safe to assume these will slowly be cleaned up over time following Apple’s usual normal improvement process.

Data protection is now enabled by default for all applications. That means apps’ data stores are encrypted with the user passcode. For strongish passphrases (greater than 8 characters is a decent start) this is very strong security and definitely up to enterprise standards if you are on newer hardware (iPhone 4S or later, for sure). You no longer need to build this into your custom enterprise apps (or app wrappers) unless you don’t enforce passcode requirements.

Share sheets provide the ability to open files in different applications. A new feature allows you, through MDM I assume, to manage what apps email attachments can open in. This is huge because you get far greater control of the flow on the device. Email is already encrypted with data protection and managed through ActiveSync and/or MDM; now that we can restrict which apps files can open in, we have a complete, secure, and managed data flow path.

Per-app VPNs allow you to require an enterprise app, even one you didn’t build yourself, to use a specific VPN to connect without piping all the user’s network traffic through you. To be honest, this is a core feature of most custom (including wrapped) apps, but allowing you to set it based on policy instead of embedding into apps may be useful in a variety of scenarios.

In summary, some key aspects of iOS we had to work around with custom apps can now be managed on a system-wide level with policies. The extra security on Mail may obviate the need for some organizations to use container apps because it is manageable and encrypted, and data export can be controlled.

Now it all comes down to how well it works in practice.

A couple other security bits are worth mentioning:

It looks like SSO is an on-device option to pass credentials between apps. We need a lot more detail on this one but I suspect it is meant to tie a string of corporate apps together without requiring users to log in every time. So probably not some sort of traditional SAML support, which is what I first thought.

Better MDM policies and easier enrollment, designed to work better with your existing MDM tools once they support the features.

There are probably more but this is all that’s public now. The tighter control over data flow on the device (from email) is unexpected and should be well received. As a reminder, here is my paper on data security options in iOS 6.

The app Simply Find It, a $2 game from Simply Game, seems harmless enough. But if you run Bitdefender Virus Scanner–a free app in the Mac App Store–it will warn you about the presence of a Trojan horse within the app. A reader tipped Macworld off to the presence of the malware, and we confirmed it.

I looked into this for the article, and aside from blowing up my schedule today it was pretty interesting. Bitdefender found a string which calls an iframe pointing to a malicious site in our favorite top-level domain (.cn). The string was embedded in an MP3 file packaged within the app.

The short version is that despite my best attempts I could not get anything to happen, and even when the MP3 file plays in the (really bad) app it never tries to connect to the malicious URL in question. Maybe it is doing something really sneaky, but probably not.

At this point people better at this than me are probably digging into the file, but my best guess is that a cheap developer snagged a free music file from someplace, and the file contained a limited exploit attempt to trick MP3 players into accessing the payload’s URL when they read the ID3 tag. Maybe it targets an in-browser music player. The app developer included this MP3 file but the app’s player code isn’t vulnerable to the MP3’s, so exploit nothing bad happens.

It’s interesting, and could easily slip by Apple’s vetting if there is no way the URL could trigger. Maybe we will hear more when people perform deeper analysis and report back, but I doubt it.

One important point to make is that unlike the previous jailbreakme.com exploits, which could be used against an unwitting victim, jailbreaks that require USB tethering have a lower security impact, and are usually only useful to the phone’s owner. Attackers are less interested because iPhones with a passcode set will refuse to communicate over USB if they are locked, unless they have previously paired with the connecting computer. So your phone is stolen and it’s locked, attackers won’t be able to jailbreak it. Therefore, only malicious code already running on your computer can leverage USB jailbreaks nefariously.

In case you didn’t know, iOS devices that pair with a computer will re-pair with other user accounts on that computer. It is device-based, not user account based.

Update: According to @drscjmm this will not work when a passcode is set, which means we are still in pretty good shape from a security standpoint.

Untethered, which means you still need to plug the device into a computer, but the jailbreak lasts across reboots (this is not remotely executable at this time).

This means all iOS devices are exposed to hands-on forensics, even with a passcode. Data protection still needs to be broken, but an attacker can jailbreak and install a back door to sniff your password if they have physical control of the device for long enough. if you lose your phone and recover it, wipe it and restore from a known unjailbroken backup.

From the jailbreak notes:

Please disable the lock passcode of your iOS device before using evasi0n. It can cause issues.

I can’t test right now, but will be interesting if a passcode prevents the jailbreak, or is sometimes just an obstacle. Please leave comments if you know or find out.

Update: As we said above, a passcode appears to block this jailbreak, which is good.

Only works on the pre-A5 processors, which means the iPhone 4S and iPad 2 and later are safe. The device must be connected to a computer for it to work.

This is a tethered jailbreak which means it goes away when the device is rebooted. But this same technique enables you to forensically dump the phone, and all data is exposed except unless encrypted with Data Protection or another technique (see my Defending Data on iOS paper).

It (and the source articles) suggests that an untethered jailbreak for all devices is coming. I can practically guarantee Apple will patch that pretty much immediately, because it will be a massive security issue allowing any attacker to control any iDevice that visits a malicious web page.

Now that we’ve covered the different data security options for iOS it’s time to focus on building a strategy. In many ways figuring out the technology is the easy part of the problem – the problems start when you need to apply that technology in a dynamic business environment, with users who have already made technology choices.

Factors

Most organizations we talk with – of all sizes and in all verticals – are under intense pressure to support iOS, to expand support of iOS, or to wrangle control over data security on iDevices already deployed and in active use. So developing your strategy depends on where you are starting from as much as on your overall goals. Here are the major factors to consider:

Device ownership

Device ownership is no longer a simple “ours or theirs”. Although some companies are able to maintain strict management of everything that connects to their networks and accesses data, this is becoming the exception more than the rule. Nearly all organizations are being forced to accept at least some level of employee-owned device access to enterprise assets whether that means remote access for a home PC, or access to corporate email on an iPad.

The first question you need to ask yourself is whether you can maintain strict ownership of all devices you support – or if you even want to. The gut instinct of most security professionals is to only allow organization-owned devices, but this is rarely a viable long-term strategy. On the other hand, allowing employee-owned devices doesn’t require you to give up on enterprise ownership completely.

Many of the data security options we have discussed work in a variety of scenarios. Here’s how to piece together your options:

Employee owned devices: Your options are either partially managed or unmanaged. With unmanaged you have few viable security options and should focus on sandboxed messaging, encryption, and DRM apps. Even if you use one of these options, it will be more secure if you use even minimal partial management to enable data protection (by enforcing a passcode), enable remote wipe, and installing an enterprise digital certificate. The key is to sell this option to users, as we will detail below.

Organization owned devices: These fall into two categories – general and limited use. Limited use devices are highly restricted and serve a single purpose; such as flight manuals for pilots, mobility apps for health care, or sales/sales engineering support. They are locked down with only necessary apps running. General use devices are issued to employees for a variety of job duties and support a wider range of applications. For data security, focus on the techniques that manage data moving on and off devices – typically managed email and networking, with good app support for what they need to get their jobs done.

If the employee owns the device you need to get their permission for any management of it. Define simple clear policies that include the following points:

It is the employee’s device, but in exchange for access to work resources the employee allows the organization to install a work profile on the device.

The work profile requires a strong passcode to protect the device and the data stored on it.

In the event the device is lost or stolen, you must report it within [time period]. If there is reasonable belief the device is at risk [employer] will remotely wipe the device. This protects both personal and company data. If you use a sandboxed app that only wipes itself, specify that here.

If you use a backhaul network, detail when it is used.

Devices cannot be shared with others, including family.

How the user is allowed to backup the device (or a recommended backup option).

Emphasize that these restrictions protect both personal and organizational data. The user must understand and accept that they are giving up some control of their device in order to gain access to work resources. They must sign the policy, because you are installing something on their personal device, and you need clear evidence they know what that means.

Culture

Financial services companies, defense contractors, healthcare organizations, and tech startups all have very different cultures. Some expect and accept much more tightly restricted access to employer resources, while others assume unrestricted access to consumer technology.

Don’t underestimate culture when defining your strategy – we have presented a variety of options on the data security spectrum, and some may not work with your particular culture. If more freedom is expected look to sandboxed apps. If management is expected, you can support a wider range of work activities, with your tighter device control.

Sensitivity of the data

Not every organization has the same data security needs. There are industries with information that simply shouldn’t be allowed onto a mobile device with any chance of loss. But most organizations have more flexibility.

The more sensitive the data, the more it needs to be isolated (or restricted from being on the device). This ties into both network security options (including DLP to prevent sensitive data from going to the device) and messaging/file access options (such as Exchange ActiveSync and sandboxed apps of all flavors).

Not all data is equal. Assess your risk and then tie it back into an appropriate technology strategy.

Business needs and workflow

If you need to exchange documents with partners, you will use different tools than if you only want to allow access to employee email. If you use cloud storage or care about document-level security, you may need a different tool.

Determine what the business wants to do with devices, then figure out which components you need to support that. And don’t forget to look at what they are already doing, which might surprise you.

Existing infrastructure

If you have backhaul networks or existing encryption tools that may incline you in a particular direction. Document storage and sharing technologies (both internal and cloud) are also likely to influence your decision.

The trick is to follow the workflow. As we mentioned previously, you should map out existing and desired employee workflows. These will show you where they intersect with your infrastructure, which will further feed your strategy requirements.

Compliance

Will the device access any data or applications with compliance ramifications? If so it may need to comply with specific compliance requirements which could include anything from encryption to email archiving. Or even restricting the devices completely.

Make a decision

Here is a suggested process to pull the factors together:

Determine the ownership model to support – personal, employer, or both.

Determine which devices to support (we focused on iOS, but your options may change with additional device types).

Determine data security and compliance requirements for identified data and workflows. These should include how the data needs to be stored (e.g., encrypted), where it can be exchanged (e.g., email to external parties), and where it can be accessed.

Map business workflows first to device (where the data may transfer onto the device) and then to the on-device workflow (which apps are used). Don’t map your security controls yet – for now it is more about figuring out how employees want to use the data on the device.

Identify potential security controls/tools to enforce security requirements at each step of each identified workflow.

Review and determine which tool categories to support.

Identify and select specific tools.

You’ll notice that although we opened with a discussion of information-centric security, at this point we are more concerned with identifying the workflows involved. That’s because we need to bridge the business and security requirements – to protect the data we need to know how it’s used, and how employees want to use it. The best data security in the world is useless if it interferes so much with business process that it kills off what the business wants to do, or users decide they need to work around it.

Conclusion

iPhones, iPads, and cloud computing are the 1-2-3 punch knocking down our traditional expectations for securing enterprise data and managing employee devices and services. Simultaneously, this is creating new opportunities for information-centric security approaches we have long ignored as we fixated on our fantasy of the enterprise perimeter. I am firmly convinced that these new models create more security opportunities than security risks.

But it is a challenge every time we face intense pressure to support new things in a short time frame.

The good news is that iOS is a relatively secure platform that is completely suitable for most organizations. Of course it isn’t perfect, and employee ownership and expectations further complicate the situation. For some organizations, the risks are still simply too great.

For the rest of us who want to embrace iOS, we have tools available to do so securely, with a range of deployment scenarios. We can start with something as simple as filtering out sensitive emails before they hit the iPhone, to something as complex as multi-organization secure document workflows. Hopefully this series has given you some good starting tips, and as new technologies appear we will try to keep it up to date.

User-owned device with managed/backhaul network (cloud or enterprise)

This option is an adjunct to our other data security tools, and isn’t sufficient for protecting data on its own. The users own their devices, but agree to route all traffic through an enterprise-managed network. This might be via a VPN back to the corporate network or through a VPN service.

On the data security side, this enables you to monitor all network traffic – possibly including SSL traffic (by installing a special certificate on the device). This is more about malware protection and reducing the likelihood of malicious apps on the devices, but it also supports more complete DLP.

Managed Devices

When it comes to data security on managed devices, life for the security administrator gets a bit easier. With full control of the device we can enforce any policies we want, although users might not be thrilled.

Remember that full control doesn’t necessarily mean the device is in a highly-restricted kiosk mode – you can still allow a range of activities while maintaining security. All our previous data security options are available here, as well as:

MDM managed device with Data Protection

Using a Mobile Device Management tool, the iOS device is completely managed and restricted. The user is unable to install unapproved applications, email is limited to the approved enterprise account, and all security settings are enabled for Data Protection.

Restricting the applications allowed on the device and enforcing security policies makes it much more difficult for users to leak data through unapproved services. Plus you gain full Data Protection, strong passcodes, and remote wiping. Some MDM tools even detect jailbroken devices.

To gain the full benefit of Data Protection, you need to block unapproved apps which could leak data (such as Dropbox and iCloud apps). This isn’t always viable, which is why this option is often combined with a captive network to give users a bit more flexibility.

Managed/backhaul network with DLP, etc.

The device uses an on-demand VPN to route all network traffic, at all times, through an enterprise or cloud portal. We call it an “on-demand” VPN because the device automatically shuts it down when there is no network traffic and brings it up before sending traffic – the VPN ‘coverage’ is comprehensive. “On-demand” here definitely does **not* mean users can bring the VPN up and down as they want.

Combined with full device management, the captive network affords complete control over all data moving onto and off the devices. This is primarily used with DLP to manage sensitive data, but it may also be used for application control or even to allow use of non-enterprise email accounts, which are still monitored.

On the DLP front, while we can manage enterprise email without needing a full captive network, this option enables us to also manage data in web traffic.

Full control of the device and network doesn’t obviate the need for certain other security options. For example, you might still need encryption or DRM, as these allow use of otherwise insecure cloud and sharing services.

Now that we have covered our security options, our next post will look at picking a strategy.

Our last two posts covered iOS data security options on unmanaged devices; now it’s time to discuss partially managed devices.

Our definition is:

Devices that use a configuration profile or Exchange ActiveSync policies to manage certain settings, but the user is otherwise still in control of the device. The device is the user’s, but they agree to some level of corporate management.

This, in turn, enables Data Protection on supporting hardware (including all models currently for sale).

In addition, you can also add the following using iOS configuration profiles – which can also enforce all the previous policies except remote wiping, unless you also use a remote wipe server tool:

On-demand VPN for specific domains (not all traffic, but all enterprise traffic).

Manual VPN for access to corporate resources.

Digital certificates for access to corporate resources (VPN or SSL).

Installation of custom enterprise applications.

Automatic wipe on failed passcode attempts (the number of attempts can be specified, unlike the user setting which is simply ON/OFF for wipe after 10 failures, in the Settings app).

The key differences between partially and a fully managed devices are a) the user can still install arbitrary applications and make settings changes, and b) not all traffic is routed through a mandatory full-time VPN.

One key point to administering managed policies on a user-owned device is to ensure that you obtain the user’s consent and notify them of what will happen. The user should sign a document saying they understand that although they own the device, by accessing corporate resources they are allowing management, which may include remote wiping a lost or stolen device. And that the user is responsible for their own backups of personal data.

Enhanced security for existing options

Most of the previous options we have discussed are significantly enhanced when digital certificate, passcode, and Data Protection policies are enforced. This is especially true of all the sandboxed app options – and, in fact, many vendors in those categories generally don’t support use of their tools without a configuration profile to require at least a passcode.

Managed Exchange ActiveSync (or equivalent)

Microsoft’s ActiveSync protocol, despite its name, is separate from the Exchange mail server and included with alternate products, including some that compete with Exchange. iOS natively supports it, so it is the backbone for managed email on iDevices when a sandboxed messaging app isn’t used.

By setting the policies listed above, all email is encrypted to under user’s passcode using Data Protection. Other content is not protected, but remote wipe is supported.

Custom enterprise sandboxed application

Now that you can install an enterprise digital certificate onto the device and guarantee Data Protection is active, you can also deploy custom enterprise applications that leverage this built-in encryption.

This option allows you to use the built-in iOS document viewer within your application’s sandbox, which enables you to fairly easily deploy a custom application that provides fully sandboxed and encrypted access to enterprise documents. Combine it with an on-demand VPN tied to the domain name of the server or a manual VPN, and you have data encrypted both in transit and in storage.

Today a few vendors provide toolkits to build this sort of application. Some are adding document annotation for PDF files, and based on recent announcements we expect to see full editing capabilities also added for MS Office document formats.

There are a whole spectrum of options available for securing enterprise data on iOS, depending on how much you want to manage the device and the data. ‘Spectrum’ isn’t quite the right word, though, because these options aren’t on a linear continuum – instead they fall into three major buckets:

Options for unmanaged devices

Options for partially managed devices

Options for fully managed devices

Here’s how we define these categories:

Unmanaged devices are fully in the control of the end user. No enterprise polices are enforced, and the user can install anything and otherwise use the device as they please.

Partially managed devices use a configuration profile or Exchange ActiveSync policies to manage certain settings, but the user is otherwise still in control of the device. The device is the user’s, but they agreed to some level of corporate management. They can install arbitrary applications and change most settings. Typical policies require them to use a strong passcode and enable remote wipe by the enterprise. They may also need to use an on-demand VPN for at least some network traffic (e.g., to the enterprise mail server and intranet web services), but the user’s other traffic goes unmonitored through whatever network connection they are currently using.

Fully managed devices also use a configuration profile, but are effectively enterprise-owned. The enterprise controls what apps can be installed, enforces an always-on VPN that the user can’t disable, and has the ability to monitor and manage all traffic to and from the device.

Some options fall into multiple categories, so we will start with the least protected and work our way up the hierarchy. We will indicate which options carry forward and will work in the higher (tighter) buckets.

Note: This series is focused exclusively on data security. We will not discuss mobile device management in general, or the myriad of other device management options!

With that reminder, let’s start with a brief discussion of your data protection options for the first bucket:

Unmanaged Devices

Unmanaged devices are completely under the user’s control, and the enterprise is unable to enforce any device polices. This means no configuration profiles and no Exchange ActiveSync policies to enforce device settings such as passcode requirements.

User managed security with written policies

Under this model you don’t restrict data or devices in any way, but institute written policies requiring users to protect data on the devices themselves. It isn’t the most secure option, but we are nothing if not comprehensive.

Basic policies should include the following:

Require Passcode: After n minutes

Simple Passcode: OFF

Erase Data: ON

Additionally we highly recommend you enable some form of remote wipe – either the free Find My iPhone, Exchange ActiveSync, or a third-party app.

These settings enable data protection and offer the highest level of device security possible without additional tools, but they aren’t generally sufficient for an enterprise or anything other than the smallest businesses.

We will discuss policies in more detail later, but make sure the user signs a mobile device policy saying they agree to these settings, then help them get the device configured. But, if you are reading this paper, this is not a good option for you.

No access to enterprise data

While it might seem obvious, your first choice is to completely exclude iOS devices. Depending on how your environment is set up, this might actually be difficult. There are a few key areas you need to check, to ensure an iOS device won’t slip through:

Email server: if you support IMAP/POP or even Microsoft Exchange mailboxes, if the user knows the right server settings and you haven’t implemented any preventative controls, they will be able to access email from their iPhone or iPad. There are numerous ways to prevent this (too many to cover in this post), but as a rule of thumb if the device can access the server, and you don’t have per-device restrictions, there is usually nothing to prevent them from getting email on the iDevice.

File servers: like email servers, if you allow the device to connect to the corporate network and have open file shares, the user can access the content. There are plenty of file access clients in the App Store capable of accessing most server types. If you rely on username and password protection (as opposed to network credentials) then the user can fetch content to their device.

Remote access: iOS includes decent support for a variety of VPNs. Unless you use certificate or other device restrictions, and especially if your VPN is based on a standard like IPSec, there is nothing to prevent the end user from configuring the VPN on their device. Don’t assume users won’t figure out how to VPN in, even if you don’t provide direct support.

To put this in perspective, in the Securosis environment we allow extensive use of iOS. We didn’t have to configure anything special to support iOS devices – we simply had to not configure anything to block them.

Email access with server-side data loss prevention (DLP)

With this option you allow users access to their enterprise email, but you enforce content-based restrictions using DLP to filter messages and attachments before they reach the devices.

Most DLP tools filter at the mail gateway (MTA) – not at the mail server (e.g., Exchange). Unless your DLP tool offers explicit support for filtering based on content and device, you won’t be able to use this option.

If your DLP tool is sufficiently flexible, though, you can use the DLP tool to prevent sensitive content from going to the device, while allowing normal communications. You can either build this off existing DLP policies or create completely new device-specific ones.

Sandboxed messaging app / walled garden

One of the more popular options today is to install a sandboxed app for messaging and file access, to isolate and control enterprise data. These apps do not use the iOS mail client, and handle all enterprise emails and attachments internally. They also typically manage calendars and contacts, and some include access to intranet web pages.

The app may use iOS Data Protection, implement its own encryption and hardening, or use both. Some of these apps can be installed without requiring a configuration profile to enforce a passcode, remote wipe, client certificate, and other settings, but in practice these are nearly universally required (placing these apps more in the Partially Managed category). Since you don’t necessarily have to enforce settings, we include these in the Unmanaged Devices category, but they will show up again in the Partially Managed section.

A sandboxed messaging app may support one are all of the following, depending on the product and how you have it configured:

In-app document viewing for common document types (usually using the built-in iOS document viewer, which runs within the sandbox).

Document isolation. Documents can be viewed within the app, but “Open In…” is restricted for all or some document types.

Remote wipe of the app (and data store), the device, or both.

Intranet web site and/or file access.

Detection of jailbroken iOS devices to block use.

The app becomes the approved portal to enterprise data, while the user is free to otherwise do whatever they want on the device (albeit often with a few minor security policies enforced).

This post is already a little long so I will cut myself off here. Next post I will cover document (as opposed to messaging) sandboxed apps, DRM, and our last data security options for unmanaged devices.

Continuing our series on iOS data security, we need to take some time to understand how data moves onto and around iOS devices before delving into security and management options.

Data on iOS devices falls into one of a few categories, each with different data protection properties. For this discussion we assume that Data Protection is enabled, because otherwise iOS provides no real data security.

Emails and email attachments.

Calendars, contacts, and other non-email user information.

Application data

When the iOS Mail app downloads mail, message contents and attachments are stored securely and encrypted using Data Protection (under the user’s passphrase). If the user doesn’t set a passcode, the data is stored along with all the rest of user data, and only encrypted with the device key. Reports from forensics firms indicate that Data Protection on an iPad 2 or iPhone 4S (or later, we presume) running iOS 5 cannot currently be cracked, by other than brute force. Data Protection on earlier devices can be cracked.

Assuming the user properly uses Data Protection, mail attachments viewed with the built-in viewer app are also safe. But once a user uses “Open In…”, the document/file is moved into the target application’s storage sandbox, and may thus be exposed. When a user downloads an email and an attachment, and views them in the Mail app, both are encrypted twice (once by the underlying FDE and once by Dat Protection). But when the user opens the document with Pages to edit it, a copy stored in the Pages store, which does not use Data Protection – and the data can be exposed.

This workflow is specific to email – calendars, contacts, photos, and other system-accessible user information is not similarly protected, and is generally recoverable by a reasonably sophisticated attacker who has physical possession of the device. Data in these apps is also available system-wide to any application. It is a special class of iOS data using a shared store, unlike third-party app data.

Other (third party) application data may or may not utilize Data Protection – this is up to the app developer – and is always sandboxed in the application’s private store. Data in each application’s local store is encrypted with the user’s passcode. This data may include whatever the programmer chooses – which means some data may be exposed, although documents are nearly always protected when Data Protection is enabled. The programmer can also restrict what other apps a given document is allowed to open in, although this is generally an all or nothing affair. If Data Protection isn’t enabled, all data is protected only with the device’s default hardware encryption. But sandboxing stil prevents apps from accessing each other’s data.

The only exception is files stored in a shared service like Dropbox. Apps which access dropbox still store their local copies in their own private document stores, but other apps can access the same data from the online service to retrieve their own (private) copies.

So application data (files) may be exposed despite Data Protection if the app supports “Open In…”. Otherwise data in applications is well protected. If a network storage service is used, the data is still protected and isolated within the app, but becomes accessible to other compatible apps once it is stored on a server. This isn’t really a fault of iOS, but this possibility needs to be considered when looking at the big picture. Especially if a document is opened in a Data Protection enabled app (where it’s secure), but then saved to a storage service that allows insecure apps to access it and store unencrypted copies.

Thus iOS provides both protected and unprotected data flows. A protected data flow places content in a Data Protection encrypted container and only allows it to move to other encrypted containers (apps). An unprotected flow allows data to move into unencrypted apps. Some kinds of data (iOS system calendars, contacts, photos, etc.) cannot be protected and are always exposed.

On top of this, some apps use their own internal encryption, which isn’t tied to the device hardware or the user’s passcode. Depending on implementation, this could be more or less secure than using the Data Protection APIs.

The key, from a security perspective, is to understand how enterprise data moves onto the device (what app pulls it in), whether that app uses Data Protection or some other form of encryption, and what other apps that data can move into. If the data ever moves into an app that doesn’t encrypt, it is exposed.

I can already see I will need some diagrams for the paper! But no time for that now – I need to get to work on the next post, where we start digging into data security options…

Before we delve into management options we need time to understand the iOS security and data protection models. These are the controls built into the platform – many utilized in the various enterprise options we will discuss in this series. We are focused on data but will also cover iOS security basics, as they play an important role in data security, and for those of you who aren’t familiar with the specifics.

The short version is that iOS is quite secure – far more secure than a general-purpose computer. The downside is that Apple supports only limited third-party security management options.

Note: We are only discussing iOS 5 or later (as of this writing 5.1 is the current version of the iOS operating system – for iPhone, iPad, and iPod touch). We do not recommend supporting previous versions of the OS.

Device and OS Security

No computing device is ever completely secure, but iOS has an excellent track record. There has never been any widespread remote attack or malware used against (non-jailbroken) iOS devices, although we have seen proof of concept attacks and plenty of reported vulnerabilities. This is thanks to a series of anti-exploitation features built into the OS, some of which are tied to the hardware.

Devices may be vulnerable to local exploitation if the attacker has physical access (using the same techniques as jailbreakers). This is increasingly difficult on newer iOS devices (the iPhone 4S and iPad 2, and later), and basic precautions can protect data even if you lose physical control.

Let’s quickly review the built-in security controls.

Operating System Hardening

Five key features of iOS are designed to minimize the chances of successful exploitation, even if there is an unpatched vulnerability on the device:

Data Execution Protection (DEP): DEP is an operating system security feature that marks memory locations as non-executable, which is then enforced by the CPU itself. This reduces the opportunity for successful memory corruption attacks.

Address Space Layout Randomization (ASLR): ASLR randomizes the memory locations of system components to make it extremely difficult for an attacker to complete exploitation and run their own code, even if they do find and take advantage of a vulnerability. Randomizing the locations of system components makes it difficult for attackers to know exactly where to hook their code, in order to take over the system.

Code Signing: All applications on iOS must be cryptographically signed. Better yet, they must be signed using an official Apple digital certificate,or an official enterprise certificate installed on the device for custom enterprise applications – more on this later. This prevents unsigned code from running on the device, including exploit code. Apple only signs applications sold through the App Store, minimizing the danger of malicious apps.

Sandboxing: All applications are highly compartmentalized from each other, with no central document/file store. Applications can’t influence each other’s behavior or access shared data unless both applications explicitly allow and support such communication.

The App Store: For consumers, only applications distributed by Apple through the App Store can be installed on iOS. Enterprises can develop and distribute custom applications, but this uses a model similar to the App Store, and such applications only work on devices with the corresponding enterprise digital certificate installed. All App Store apps undergo code review by Apple – this isn’t perfect but dramatically reduces the chance of malicious applications ending up on a device.

There are, of course, techniques to circumvent DEP and ASLR, but it is extremely difficult to circumvent a proper implementation of them working together. Throw in code signing and additional software and hardware security beyond the scope of our discussion, and iOS is very difficult to exploit.

Again, it isn’t impossible, and we have seen exploits (especially local attacks such as tethered jailbreaks), but their rarity, in light of the popularity of these devices, makes clear that these security controls work well enough to thwart widespread attacks. Specifically, we have yet to see any malware spread among un-jailbroken iPhones or iPads.

Security Features

In addition to its inherent security controls, iOS also includes some basic security features that users can either configure themselves or employers can manage through policies:

Device PIN or Passcode: The most basic security for any device, iOS supports either a simple 4-digit PIN or full (longer) alphanumeric passphrases. Either way, they tie into the data protection and device wipe features.

Passcode Wipe: When a PIN or passphrase is set, if the code is entered incorrectly enough many times the device erases all user data (this is tied to encryption features discussed in the next section).

Remote Wipe: iOS supports remote wipe commands via Find My iPhone and through Exchange ActiveSync. Of course the device must be accessible across the Internet to execute the wipe remotely.

Geolocation: The device’s physical location can be tracked using location services, which are part of Find My iPhone and can be incorporated into third-party applications.

VPN and on-demand VPN: Virtual private networks can be activated manually or automatically when the device accesses any network service. (Not all VPNs support on-demand connection and this is VPN-provider specific).

Configuration Profiles: Many of the security features, especially those used in enterprise environments, can be managed using profiles installed on the device. These include options far beyond those available to consumers configuring iOS personally, such as restricting which applications and activities the user can access on the phone or tablet.

These are the core features we will build on as we start discussing enterprise management options. But iOS also includes data protection features that are the cornerstone of most iOS data security strategies.

Data Protection

Although it was nearly impossible to protect data on early iPhones, modern devices use a combination of hardware and software to provide data security:

Hardware Encryption: The iPhone 3GS and later, and all iPads, support built-in hardware encryption. All user data can be automatically encrypted in hardware at all times. This is used primarily for wiping the device, rather than to stop attacks. Rather than slowly erasing the entire flash storage, wiping works by immediately destroying the encryption key, which makes user data inaccessible. Data is encrypted with a device key the OS has full access too, which means even encrypted data is exposed if someone jailbreaks or otherwise accesses the device directly. Hardware encryption is also used to provide some protection against unauthorized physical access.

Data Protection: As noted above, hardware encryption is relatively easy to circumvent because it is primarily designed to wipe the device, not to secure data from attack. To address this need, Apple added a Data Protection option in iOS and made it available to applications with iOS 4. When a user sets a passcode lock their email data (including attachments) is encrypted using thir passcode as the key. Data Protection also applies to applications that leverage the data protection API. With this enabled, even if the device is physically lost and exploited, any data protected with this feature (specifically mail and data for third-party applications which implement the Data Protection API) is encrypted. Attackers may still attempt to brute-force the key.

Backup Encryption: All iOS devices automatically back themselves up to iTunes or iCloud when they connect to and synchronize with a computer. If backup encryption is enabled, all data is encrypted on the device using the designated password before transferring to the computer. Note that if the user sets a weak password this protection might not be worth much; additionally the password may be stored in the iTunes computer’s system keychain. Additionally, the iOS keychain is stored in the backup, encrypted.

This is not as robust as the BlackBerry full device encryption, but it forms the basis for most iOS data security strategies. Prior to the availability of hardware encryption and Data Protection it was nearly impossible to protect data on iOS. Now that those features are available to all application developers, however, Apple has provided an enterprise-class mechanism for securing data even when devices are lost or stolen.

Management Options and Limitations

Overall, iOS includes fewer enterprise management options than organizations are used – particularly compared to general-purpose desktop and laptop computers. Apple does not support full background applications, which means there is no capability to install constantly-running security software like antivirus or DLP on iOS devices.

To us this is a net positive, because all applications are sandboxed and there is no ability for them to run background tasks that can snoop on user activity or otherwise compromise security. Although if an attacker does figure out how to deeply penetrate the device, they would clearly be able to cause more harm than a legitimate application.

Although we don’t feel this is a serious security risk – despite the cries of antivirus vendors as they watch the hot new market slip through their grasp – it could be a compliance issue if you are required to run such software on all devices due to satisfy someone’s checklist mentality.

In terms of managing iOS devices, the inability to run background tasks also means device management is restricted to the features Apple exposes through configuration profiles. These include application and feature restrictions, as well as the ability to manage VPNs, digital certificates, passcodes, and other features. No matter what mobile device management tool you use, they all tie back to these profiles.

This should help you understand the key security features of iOS – next we will review the range of options for protecting enterprise data, after which we will conclude with a framework for deciding which is best for your organization.

The numbers alone don’t tell the story. In 2011 Apple sold 315 million iOS devices (62 million in the fourth quarter alone). There are over 100 million iCloud users – using a service less than a year old. And these numbers are for Apple alone – never mind all the other mobile devices. Apple calls this the dawn of the “post-PC era”, and with numbers like those it’s hard to argue. Even Microsoft is in the midst of what is shaping up to be the largest change in their platform strategy since Windows, in an attempt to address this market.

These devices aren’t confined to the home. Survey after survey shows growing enterprise adoption of iOS, including major migrations off RIM BlackBerry and other business-centric smartphones – even aside from the tidal wave called iPad. The phrase “the consumerization of IT” appeared before the release of the iPhone, but no other vendor is doing as much to drive the adoption of consumer technologies into the enterprise as Apple.

In years past we in IT security served as the gatekeepers of new technologies in the enterprise. As much as we like to say we’re the last to find out about new tools and toys, mobility is one area where we have held tight control by limiting access to the network. But in the post-PC consumerization world we are losing our ability to stop the adoption of consumer technologies, even when they don’t support all our enterprise needs.

In a recent session at the RSA Security Conference I asked a group of 150 operational security professionals how many were under pressure to support non-BlackBerry devices. Nearly every hand in the room went up, almost universally to support iOS, and only a relatively small percentage had technical capabilities or policies in place to manage this transition.

And while there was some concern about the impact of these devices on the network, the universal concern was the safety of data.

The question is no longer if or when to allow these devices, but how to support non-PC computing platforms while safely protecting enterprise data.

To stay focused, this series will lay out options for protecting enterprise data on iOS, rather than talking about the myriad of other issues around mobile device management.

Why iOS and Not Android

Of course Apple isn’t single-handedly driving the consumerization of IT concept, but the numbers above (and a quick glance around the office) show that the company from Cupertino is clearly a major force. They have done more to alter the landscape of the smartphone and tablet markets than any other single provider. And, not coincidentally, we are asked more about securing iOS for the enterprise than any other platform.

Until recently BlackBerry was the dominant platform – largely because it was designed specifically to address enterprise needs. As a result most organizations are comfortable securing these tools. Some organizations also supported Microsoft and perhaps Palm, but one of those companies no longer exists and the other completely tossed out its platform to start fresh.

The real activity is with iOS and Google’s Android. But for a variety of reasons enterprises face more pressure to support iOS. Android-based tablets are not yet competitive or in wide use, and the fractured nature of Android phones and software versions makes it far easier to justify restricting those devices.

From a security perspective, iOS is also a stronger platform. While nothing is invulnerable, there is essentially no iOS malware and few known security breaches. The software ties strongly to the hardware and current versions are very difficult to hack. Android, by its more open nature, represents a greater security risk – as demonstrated by ongoing malware issues (still lower than PC levels, but much higher than iOS).

The main problem is that Apple provides limited tools for enterprise management of iOS. There is no ability to run background security applications, so we need to rely on policy management and a spectrum of security architectures.

We will focus on iOS because:

You already know how to manage BlackBerry.

Android isn’t mature or safe enough for us to endorse for enterprise use, and the fractured operating system levels make strategic management difficult.

Windows Mobile is not in widespread use and the Metro tablet platform is still in development.

Clients tell us they are under pressure to support iOS more than other platforms – especially the iPad.

Most of the options we will discuss also apply to other platforms – especially the latest version of Android (Ice Cream Sandwich, which isn’t widely available).

Information-Centric Security

We are focusing on data for this series, so we will take an information-centric approach. We won’t talk about network management or device restrictions that aren’t relevant to protecting data. But we will discuss managing the data even before it hits the device.

Information must be protected as it moves from structured to unstructured, in and out of applications, and changing business contexts.

Policies must work consistently through the different defensive layers and technologies we implement.

These sound a bit like the usual analyst mumbo-jumbo, but we do actually have the technologies to implement much of this today. In terms of managing data for mobility and iOS we can hit every one of those points except movement between structured and unstructured data.

Through the rest of this series we will show how to manage what data ends up on devices, how to protect it once it’s there, and how to build and manage policies to enable users without violating risk tolerances. To do this we will present a spectrum of options designed to satisfy different organizational needs; all of which are supported by existing products (some of which you probably already have).

Before we dig into the management options we need to spend a little time understanding how iOS works… which will be the next post.

And yes, this is the opening to a new blog series that will be converted into a white paper. In accordance with our Totally Transparent Research policy, this one is being sponsored by Watchdox but they don’t get to influence the content other than submitting public comments here on the blog like everyone else. Thanks to folks like them, taking the risk that I might write something bad about them, which enables us to give this away content free.