Security and Risk Management Strategies Blog

Will 2010 be "the year of the data?"

I quite often have a déjà vu moment when looking at some new technology or security concern. It sure feels like IT and information security are a cycle – or perhaps a wave – and I think that by applying some creativity we could come up with an IT and information security zodiac. Linking things with astrology actually feels quite fitting for this time of year, given the plethora of Nostradamus-like risk management prophecies that inevitably pop up. It takes no crystal ball or star charts, however, to notice the loss of control associated with the ongoing information explosion and externalization of IT, and I’m left to wonder if 2010 - the year of the Tiger in the Chinese zodiac - will (finally) be "the year of the data" … and whether data-centric security, which we have been discussing for some years now, will have to become a real necessity.

We thought to have gotten a handle on information protection in the Internet age: encryption at the repository and media level alleviates a lot of the exposure associated with sensitive information on systems and mobile devices. Except for that pesky creation and use of information in the business, but for that there’s data loss prevention (DLP) protecting, with varying degrees of effort and success, the potential ingress and egress points of the information perimeter. It works – sometimes effectively, sometimes not so much – in the current enterprise IT model, and although not particularly cheap is much less of an effort than refactoring applications, data, and business processes.

But, if we believe the predictions, change in IT may well accelerate in 2010 through increased adoption of cloud computing – a change that would swiftly erode many a traditional information perimeter. In a CSO Online article, Cyberczar-to-be Howard Schmidt predicts cloud computing to be a security enabler, and states that “[t]he overall net effect will give us a better chance to develop more security in the cloud using […] robust encryption.” Using cryptography of course makes sense – crypto is at one point or another required in many technical controls -  but is the application of this traditional control in the cloud really that simple?

The answer, unfortunately, is no. Using encrypted information – for all practical purposes – requires having the key, and having to have the key at the point of processing (i.e, the cloud) is not exactly secure. Complicating the matter is the current lack of hardware-assisted cryptography potential in the cloud and virtualization (unless you want to sacrifice mobility and elasticity), and the result is a chicken-and-egg situation for protecting cryptographic key material. Sure it’s possible to have a cloud provider encrypt storage and networking for you, but how much of the threat landscape does that really address? The situation will eventually improve, but for now we’re facing some crypto-hurdles.

But then what do we do if we can’t encrypt data, or prevent it from floating around in the now externalized business process automation? Well, if it is absolutely required to be there, then we’ll just have to consider whether externalization is a good choice – it sometimes is, and sometime isn’t. But upon further examination it may be surprising how often sensitive data is in fact not needed, and this is where we can make some headway with business process and data management, and maybe also with some newer technical controls. With security teams focusing on the latter, we should probably consider data masking (de-identification) techniques, including run-time data aliasing (format-preserving encryption and tokenization, which I’ll cover in upcoming research) technologies, to complement data discovery and DLP.

Are these controls a panacea? No. Are they a necessary alternative to ‘regular’ encryption? Probably. No matter how we slice it, with an eroded or non-existent information perimeter, protecting information in a real data-centric manner is no longer optional. With new IT complicating encryption and DLP controls, and with the near inevitable expansion of information protection regulation, I think 2010 should finally be the year when enterprises get real serious about managing their large amounts of data. Sure it may be quite the undertaking (and of course more than just a security effort) but it may prove easier than it used to be, and should surely be very rewarding in the long term.

An Exciting Month for Key Management

Blogger: Ramon Krikken

OK, so maybe 'exciting' isn't the first word that comes to mind when thinking of cryptographic key management, but with the current state of the product market any time I hear 'standardization' I see a glimmer of hope. As I discussed in the "Enterprise Key Management Systems" report (available to our customers) the absence of standardization is a major pain point for customers. Anyone with a variety of encryption products probably has a plethora of associated key management systems - less than ideal, to say the least.

And it's not that vendors aren't working on this; it's just that standards don't develop overnight. There is IEEE P1619.3 targeting storage, OASIS EKMI targeting the application layer, and IETF KeyProv for provisioning keys to mobile devices. The Trusted Computing Group (TCG) just last week announced its finalized specifications dealing with so-called "trusted storage devices" which should clear the way for mass-adoption of self-encrypting storage. All great efforts – and with the TCG specification hopefully about to bring more of the sorely needed storage encryption to endpoints – but still no standardized enterprise key management.

So today a group of seven companies announced the submission of the Key Management Interoperability Protocol (KMIP) to OASIS. The standard was under development by IBM, RSA, HP, and Thales (who acquired nCipher) for the last year, and according to the vendors has passed interoperability testing with their individual reference implementations. Although focusing mainly on the use cases for client-server based distribution of cryptographic materials and associated policies (thus leaving some future room for improvement on key server to key server operations, and avoiding overlap with some existing standards such as PKIX for PKI) the specification is very detailed and complete, and targets a wide spectrum of encryption technologies; it utilizes a compact message format with support for encryption keys, signing keys, symmetric keys, asymmetric keys, X.509/PGP certificates, and so forth. Not necessarily covering all aspects of “people-interactive crypto” such as email encryption and enterprise digital rights management, but certainly targeting long-term keys and certificates for all of the data center. Representing the client side, Seagate, LSI, and Brocade have joined the effort, and I expect broadening interest and support.

So does that mean we can start consolidating key management servers soon? Well, first the specification needs to become a standard, which according to the companies could take another twelve to eighteen months. And even then it's not clear that massive migrations of keys are easily accomplished – remember that server to server operations are a future consideration. But still, this is another step in the right direction for removing some of the hurdles that many organizations face when trying to roll out more and more encryption technologies.