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