Why iOS Data Protection is Adequate for Corporate Use (And Why The Siri “Vulnerability” is a Non-issue)

First things first. The so-called Siri "vulnerability" that was widely reported this week is a dumb non-issue created by journalists seeking sensationalist headlines. A simple setting disables the ability to use Siri without unlocking the phone rendering the whole issue moot. What the sensationalists fail to take into account is that the iPhone is a consumer device. Most consumers don't even use a passcode. The obvious default setting for Siri in this case, as one of the attractive new USPs of the iPhone 4S, is to allow use even when the phone is locked - I don't think you can fault Apple for this.

Now on the other hand, things need to change when these consumer devices are allowed in an enterprise. Exchange Active Sync (EAS) or Mobile Device Management (MDM) software should be used to apply minimum security policies, which should always include a complex passcode of more than 4 characters, auto wipe on multiple failed passcode attempts and, of course, disabling Siri without unlock (this latter capability would required MDM, since it is not available in EAS). There are many other security settings that should be addressed too, but the main one is the passcode.

Once the passcode is enabled, Data Protection is turned on. Now, Data Protection is NOT full disk encryption, although encryption IS turned on globally. However, you should assume that it only encrypts data in applications that support the Data Protection APIs (this is an over simplification, but the details are too complex for a blog post and are the subject of an Analysis Brief that will be available shortly to NSS subscribers).

Out of the box, that is the iOS Mail client, for example. Other commercial apps will support Data Protection too, though these are few and far between right now - GoodReader is one of the best known. Others include USB Disk Pro, mobilEcho and the Box.net iOS client. There are several more, but not enough of them given that these capabilities have been available since the pre-release of iOS4, and we are now on iOS5!!! This continues to be a sore point with me as many developers make a big deal out of pushing their apps as business-class, yet spend more time making nice UIs and not enough securing the data that they are supposed to be protecting. Bear in mind that these apps will typically be used to access corporate documents, in many cases storing locally on the device outside the control of corporate IT. That data needs to be encrypted.

With apps that support Data Protection, you have an additional layer of encryption on the iOS device. If you have a passcode set on the iPhone and you turn on Data Protection in GoodReader, all of the docs stored in the GoodReader sandbox will be encrypted in the same way as data stored by the Mail app. You can even have some data in the clear and restrict encryption to certain files or folders.

So far so good, but what about those “researchers” that have written about the fact that jailbreaking an iOS device or connecting one to Ubuntu will provide access to all data on that device? Yes, unfortunately it is possible to jailbreak an iOS device and completely bypass the passcode. There are other ways to bypass the passcode too (such as that issue with Ubuntu). Because of the way iOS implements the Data Protection capability, once the passcode is entered or bypassed, all of the data on the device that is not protected by Data Protection APIs specifically is unencrypted on the fly.

Therefore, if someone jailbreaks my iPhone they will be able to access all of the documents stored in the ReaddleDocs or PDF Expert sandbox because the iPhone will decrypt on the fly as the data is accessed. However, if they try to access my Mail data or anything stored in the GoodReader sandbox, they will only see encrypted data. Same thing goes for items stored in the keychain. Anything stored in the clear will be accessible when a device is jailbroken. Anything written using Data Protection APIs will remain encrypted.

Only by entering the passcode can that encrypted data become available. This is an important distinction that needs to be understood. Jailbreaking/bypassing the passcode DOES NOT BREAK iOS ENCRYPTION - it merely bypasses the basic protection on the device. Anything stored using Data Protection APIs WILL REMAIN ENCRYPTED EVEN FOLLOWING JAILBREAK.

There is no way to brute force the passcode off-device since it is tied to the hardware. If you have auto-wipe turned on, too many attempts to brute force the key on-device will result in a wipe. One nasty problem is that you CAN do brute force attempts on-device without triggering auto-wipe by bypassing the UI APIs that ask for the passcode, so that is why security-conscious folk need to ensure they use a longer, complex, alphanumeric passcode that will resist brute force attempts.

So there you have it. Could Apple’s encryption scheme be better? Yes, of course it could. There are some caveats, and I would have preferred it to be full-device encryption, or at least to have a central document storage area that is always encrypted by default. However, my opinion is that iOS devices are perfectly acceptable and secure enough for corporate use PROVIDING they have a sensible security policy applied, Data Protection is turned on, a complex passcode is used and any sensitive data is ONLY stored within apps that support Data Protection APIs. Corporate users should always ask iOS developers if their app supports Data Protection and avoid those that do not.

The Sophos post and original Fraunhofer research, and any others spouting similar opinions, can be dismissed with a simple analogy, since they appear to assume Data Protection is not being used - if that is really the case, it is like leaving your keys in the ignition and locking the door, then complaining when someone smashes the window and drives off with your car!

I am taking a significant number of inquiries from NSS client each week on this subject, proving that it remains confusing for many. I hope this helps a little. In addition, as I mentioned earlier, there are a couple of NSS Labs Analysis Briefs in the works covering iOS Data Protection and other security issues facing corporate users of consumer devices. These will be available to subscribers only. Follow me on Twitter (@bwalder) to keep informed as new research is released.

Can you have too much security?

Where organizations rely on application-aware security policies for their network security devices, or rely on Data Loss Prevention (DLP) products to prevent leakage of sensitive corporate material outside the network perimeter, the use of encrypted traffic means that those devices are suddenly blinded to the content, rendering deep packet inspection to the application level impossible. Cybercriminals are aware of this, and often make use of encrypted channels for covert command and control communications for botnets, as well as data exfiltration from the corporate network.

Given the risk that encrypted channels may be used by malicious entities for botnet command and control or data exfiltration mechanisms, enterprises are faced with an unpalatable choice – leave traffic in the clear or lose visibility into the encrypted data stream. Of course, there are solutions to the problem – there always are! – such as ensuring that network monitoring and security products can handle decryption, inspection and re-encryption of traffic on the fly.

The only issue is, how much of your already straining-at-the-seams security budget can you allocate to add SSL inspection capabilities to your infrastructure?

And while this may seem the obvious solution, on-the-fly SSL inspection can have a number of issues that need to be considered, not least of which privacy and performance. Vendor data sheets usually do not reflect accurately real-world impact on performance, forcing organizations to perform their own testing to ensure network security devices are fit for their intended purpose.

NSS Labs has a group test report in the pipeline covering SSL inspection capabilities of network security devices, and in the mean time, we have published a useful piece of research on What CIOs Need to Know About SSL and its Effect on Network Traffic Inspection Capabilities (subscription required).

Follow me on Twitter (@bwalder) to keep informed as new research is released.

Firesheep: Should CISOs Ban Employees From Using Unsecured Public Wireless Networks?

The release of the Firesheep plug-in for the Firefox browser has made it trivial for even unskilled attackers to intercept and interfere with private data on unsecured public wireless networks.

Since attackers can use the tool to send messages and make posts on behalf of the victim, organizations using social networks for marketing, support or brand enhancement may suffer serious consequences as a result.

Chief information security officers (CISOs) need to make employees aware of the risks and provide them with the necessary tools to counter them, but should they be banning the use of unsecured wireless networks for any company-related communications?

This note (for subscribers only), entitled "What CIOs need to know about SSL and its effect on network traffic inspection capabilities" answers that question and provides action plans for both employees and software developers to combat the threat of session hijacking, in addition to covering how IT departments can balance the need for enhanced security with the need to inspect encrypted traffic on the corporate network.

Don't forget to follow me on Twitter (@bwalder) to be kept informed of new research.

Like Lambs To The Slaughter - What Is Firesheep?

As with Advanced Evasion Techniques (AET), Firesheep has garnered significant publicity recently by rejuvenating interest in an old security problem via the creation of a slick new tool. Unlike AETs, however, the tool at the centre of this publicity storm has been released to the general public, for good or ill.

HTTP session hijacking, or "Sidejacking" as it is sometimes called, is nothing new. Papers exist discussing the technique as far back as 2004. Several applications have also been written in the past (Ferret, Hamster, Cookie Monster and FBcontroller to name a few) to take advantage of the technique. However, Eric Butler, a Seattle-based freelance software developer, has rekindled interest in the issue via the release of a simple-to-use Firefox plugin called Firesheep.

Either on its own on a Mac, or coupled with Winpcap (or Ettercap) on a PC, Firesheep can capture traffic on any unsecured wireless network to which you are connected and extract details from session cookies used by any of the web sites configured within the Firesheep application. These cookies are used by web applications such as Twitter or Facebook to register the fact that you have successfully authenticated to the host site. They do not contain your password details, but they do not need to. By using the cookie to piggyback on your unencrypted communication, the attacker running Firesheep can impersonate you and gain access to the application you are using.

It couldn't be easier to use. The attacker just fires it up, turns on packet capture, and waits for the sidebar to populate with account details it has detected on the network. He clicks on your details, and hey presto - he sees on his screen exactly what that you see on yours. And he can interact directly with the host application. He could post status updates on Twitter or Facebook on your behalf, for example. OK, that might not be too serious for some, but for those whose job it is to represent the public face of a major corporation then the potential for mischief is significant.

Should you stop using all public, unsecured wireless networks? Well, no. That would be overkill.

At the end of the day, the real solution is for providers of web applications like Facebook and Twitter to use secure connections for all their operations. In the mean time, there are a number of precautions you could, and should, take, and these (and other key points) are the subject of a research note I have just completed (subscribers only).

Don't forget to follow me on Twitter (@bwalder) to be kept informed of new research. Just don't do it from an unsecured wireless network - you never know who might be watching!