Is ERM a Better Investment for DLP in an Virtualised Future October 8, 2008

Having a look at all the vendors out there doing virtualisation, it seems like the common strategy is to be able to offer central virtualised application (ala Citrix published apps style) or centrally deployed virtual PC images (ala thin client / Sun Ray style). Even Google is in on the act, however, following a different path of making the browser the OS and pushing the apps into the cloud.

I do have a question to all the security architects, or the organisational IT strategists. Do you like the idea of pursuing such a virtualisation strategy, and if so, are security mitigations you are planning on deploying relevant in such an environment. Or more specifically, if you are planning on an organisational wide rollout out of a desktop DLP suite, will it be relevant if you are potentially heading back to a partial thin client model? When you make security strategies are you considering what the IT technology landscape may look like in 18 months? DLP may be a sensible solution today, but is it just a point in time solution. How long is it really going to roll out your DLP solution, compared to what you expected ( you know, before reality gets in the way). You may just be starting to get to the last of the DLP roll out (after probably being through a partial refresh of the product version and configuration) by the time your organisation starts heading down the virtual OS/apps/thin client path.

Maybe a better strategy, if you think you will be heading into the great virtualisation future, is to invest in education and culture change for the end users so that they start classifying (and shock, horror, taking ownership of) their electronic information. Purchase the right tools to make it easy for the end users to undertake the classification process and potentially pilot a ERM solution. Why? Because any classification of information is only going to make the push of virtualisation to the end points that much easier. There would be a good case to give thin clients/virtualised OS’s to those end users that deal with sensitive information (that has been classified, and because its been classified it so much easier to justify) first. Once you have such a configuration, then you can consider if DLP products offer any additional benefits to plug left over information leakage risks.

I think its more logical to try protect the information, at least at the individual file level by encryption, so that if the file leaks it is not a major concern.

PKI – Failure due to Utopian Practices October 7, 2008

I have been considering in the back of my mind for a while now what the best approach would be to deploy an enterprise wide PKI infrastructure. You know the deal, everyone has read the theory. Build your root CA, have a root key signing party, then sign a child CA with the root and then go bury the root CA under 6 meters of concrete so no-one can ever touch it. Then use the secondary CA to sign other certificates or child CA’s in the enterprise. The theory all makes sense, but why has it been so hard for PKI to be successful in the enterprise. Maybe because the “required” policies and procedures are not rooted in the every day realities of IT operations in a business. Sure, there are very good reasons in any number of sensitive situations where the full gamut of best practice PKI policies should be followed, but lets face it, for the average enterprise, who has time or the technically skilled resources in IT operations to support such a solution (or the risk profile to require it).

If I want to implement some sort of technical security strategy, the last thing I want is to have to be supporting it personally for the next X number of years. It can be hard enough to embed a security culture into IT operations to ensure security is a consideration during break-fix/implementation decisions. Who is going to want to support a system that require all these checks and balances, as well as potential documentation requirements which goes direct against the nature of you normal techie. IT operations will resist supporting enterprise wide PKI’’s because of the overheads and the aura of “black magic” in the technology.

So what’s the solution? As is the answer to a lot of problems, make it simpler. What is the risk you are trying to mitigate, or reduce by deploying an enterprise PKI? And what is the risk that you are living with today? Is the cost and the overhead of a best practice PKI really going to be cost justified? Why do you need an enterprise wide single PKI architecture at all. If you can use vendor PKI solutions that are internally built into various systems (i.e. email gateways, authentication servers, proxies…) why not just run them as separate PKI’s. Once its configured, its likely IT operations wont even realise they are managing PKI’s within the solutions due to the vendor making the function transparent. Sometimes a small improvement is better than waiting for the perfect overall solution.

I think the key is to consider what you are already living with today. User authentication via passwords, unencrypted communications on the LAN (and maybe the WAN), clear text emails …. Yes, PKI can help in many ways, but lets face it. For the average enterprise’s PKI requirements, if you are worried about protecting the root certificates, the “keys to the kingdom”, then you have lost already. Because while you spend your time protecting the keys to the kingdom, one of your users will likely leave the front gate open anyway. In a lot of cases, PKI should only be considered to be another way to treat opportunistic security threats (e.g. sniffing on the wire, password cracking …) and more consideration should be given to the operational impact of supporting such a system, and the real benefit to the business by having such functions available.

If you want a good reference book on PKI architectures I would recommended:
“Planning for PKI: Best Practices Guide for Deploying Public Key Infrastructure” by Russ Housley and Tim Polk. ISBN 0471397024