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.

Apple Gets Cozier With Enterprises With iOS5

One of the most frequent questions I hear in inquiry calls with our enterprise clients at the moment is “how do we manage and secure iPads on our corporate network?”

Not “tablets” (at least, not yet), but “iPads” specifically.

Whereas the smartphone began the push for consumerization and “bring your own device” (BYOD) in the enterprise, the iPad has consolidated that move. The dynamic has changed because the iPad appeals equally to senior executives and mere mortals, and the IT department finds it much harder to push back when the CEO demands his corporate email on his new iPad. Secure board communications systems (BCS) are also something of a hot topic right now, and the iPad is making a significant impact in that market too, offering, as it does, an attractive alternative to lugging around giant paper-based folders of corporate documents.

With the release of iOS4, Apple introduced a number of features that finally allowed IT departments to consider the iPhone and iPad as “enterprise ready.” Mobile Device Management (MDM) APIs and Data Protection capabilities provided the means for enterprises to manage and secure both the devices themselves and the data stored on them.

Questions remain as how best to secure both device and data, and forthcoming research from NSS Labs on Data Protection and MDM will provide actionable advice to assist our enterprise clients in deploying these devices in corporate networks.

iOS4 still fell short in a couple of key areas when it came to enterprise deployment, however. The lack of secure email support and reliance on iTunes – a consumer-grade software product - for critical processes such as device activation and backup were two major concerns.

As expected, both of these will be addressed in the latest iOS5 release, though it remains to be seen how welcoming enterprise customers will be about certain aspects of Apple’s new baby. Having installed iOS5 on a few devices, I can say that it appears very solid so far for a beta product, though it is still missing some features that were promised in the WWDC keynote.

S/MIME support addresses the secure email concern adequately, and it appears to work well. I tested using both standard commercial and self-signed certificates, and digital signing and encryption functions worked fine for sending and reading messages. Certificates are installed via configuration profiles using the iPhone Configuration Utility (IPCU), following which they need to be selected for signing, encryption or both on a per-mail account basis. This process will need to be streamlined in larger deployments by the use of third-party MDM solutions in order to scale. Grabbing certificates from messages sent to you to store in the address book is a simple, one-click process.

The objection to iTunes has been addressed by the new “PC free” capabilities in iOS5. Apple explained at its developer conference that the aim was to add sufficient features on the device to remove the requirement for users to tether to their desktop. At the consumer end of things this includes features such as on-device photo editing, calendar creation and mailbox creation. For the enterprise, the killer blow comes with on-device activation and over the air (OTA) operating system updates, eliminating the requirement for iTunes in deploying iOS devices. Delta updates are also possible now, meaning that it will no longer be necessary to download the whole OS each time Apple issues a change. Backups will be achieved via the new iCloud service, and it remains to be seen how secure and acceptable this proves to be for enterprises (at this point in time I am unable to test all of the iCloud features.)

So nothing earth shattering, but a steady evolution of the system to make it ever more acceptable to enterprise customers. Apple could, and should, have gone further, however.

Multiple email signatures with per-account defaults is a feature to which users are accustomed on their desktop mail clients. This is still missing from iOS and, while not a major problem, is something I find irksome on a daily basis as a business user.

More serious is the continued omission of support for the iOS Data Protection APIs by Apple’s own “business” apps – Pages, Keynote and Numbers. Apple announced Data Protection with a fanfare with the release of iOS4 and informed us that, although Mail was the only native app to support those APIs back then, others would quickly follow. That appears to be an empty promise, since I am not aware of any other apps in the Apple stable that support the encryption APIs today.

This capability becomes even more important with the announcement of the multi-device synchronization capabilities of iCloud, which could easily see confidential documents created on a Mac desktop pushed out automatically and invisibly to iPhones and iPads, where they will rest unprotected.

Finally, we still do not have the ability to prohibit the creation and use of the escrow keybag when synchronizing to iTunes. This would be a simple feature to implement, and would provide an additional layer of protection for those relying on Data Protection capabilities to protect their data on mobile iOS devices. One other option would be to force permanent “PC free” mode, prohibiting iTunes synchronization at all, though that would require apps to support iCloud natively for file transfer, and is not something we are likely to see in the immediate future.

I have an Analysis Brief in production right now for our subscribers that will address the Data Protection capabilities in iOS4 and iOS5, and how they should be used to protect sensitive corporate data. Follow me on Twitter (@bwalder) to keep informed as new research is released.

[UPDATE]: Some have reported issues with S/MIME in iOS5, and the beta implementation does certainly seem to be a little "quirky" at the moment. I found issues when using certificates issued by public CAs such as Verisign, which I circumvented by installing self-signed certificates that I created using OpenSSL. Naturally, this does not play well in the world outside your test environment, but if you are just looking to test functionality, I found that both sending and receiving signed and encrypted messages worked fine using this solution.