There is an old adage from the British Army known as the “seven Ps,” that is frequently used in project planning, or when training for life-or-death situations. “Proper Planning and Preparation Prevents Piss Poor Performance.” My apologies if I have offended anyone’s sensibilities but in view of the growth of Cyber Warfare, every organization needs to ask itself if it has planned, and is prepared, for increasingly likely attacks.
The reality is that no matter how good we think we are, or how well protected, the people and organizations who are now targeting our organizations are better trained, have unlimited resources, and are extremely capable! Cyber Warfare is a reality, and as in any war, weapons do not distinguish between legitimate and innocent targets. Collateral damage is never avoidable, and your management needs to be aware that they will be held accountable for harm to the organization regardless of its source. Now this has led a number of security specialists to demand an international treaty that would halt online weapons which, quite frankly, seems a little bit like a weapons manufacturer asking for a ban on weapons.
SSL Certificates - The Target of Choice
As anyone who has been following the news for the last few months will realize, the SSL certificate has now become a key target in the cyber attack arsenal. Flame, Stuxnet, Duqu, and Mediyes are the high-tech weapons, and are likely only the tip of the iceberg when it comes to what is lurking beneath. Each of these pieces of malware have been signed by a digital certificate owned, or appearing to be owned, by reputable companies, and issued – or, again, appearing to be issued – by trusted authorities such as VeriSign, and Microsoft. 
In spite of all the cries that SSL is not safe, and that there are problems with the trust model, the fact of the matter is that SSL is probably the best we have right now to protect ourselves. No one claims it is perfect, but show me a better and more secure alternative. Passwords are certainly not the way to go – they’re being hacked left, right and center. Some will argue that OTP token-based solutions do the job, but it’s not so long ago that RSA were replacing millions of them because they were hacked!
The biggest problem with SSL certificates is that most organisations have applied no Proper Planning and Preparation for the use of certificates, and as a result are vulnerable to attack.
Seven Point Plan to Avoid Piss Poor Performance
Contrary to popular opinion, Microsoft did not invent Excel to be a certificate management or policy enforcement system. Then again, given the extensive use of Excel among PKI departments, they could probably rebadge it and charge a fee! That said, in most companies, this is the level of sophistication that exists. So here are some guidelines that might be helpful, even if you’re convinced that Excel does it all.
1. Get SSL and SSH policies in place and review them annually In many organizations, a Certificate Practice Statement (CPS) does not even exist, and where it does certificate policies and the certificate practice statement are generally out of date. For example a CPS should cover topics including minimum key lengths, approved cryptographic algorithms, approved trusted root certificates, administrative access to private keys, etc.. There are many other points, but the important thing is that the CPS remains current. Last year’s CPS may already be out of date given developments in the industry. 2. Have a system-generated inventory of keys and certs Relying on manual entry in a spreadsheet does not qualify as an inventory! The general status of most IT departments is that they only have a view of a fraction of the total number of keys and certificates that are deployed. In most organizations, the management of keys has been so diluted across various groups that most organizations don’t even know how many Certificate Authorities they use. 
IT departments should perform network and on-board scans periodically and ensure that details such as the locations for certificates and private keys, owners or contacts are identified, and all relevant attributes of the certificates are collected. It is curious why organizations talk about having the on-going problem of finding the person responsible when a certificate expires. You would think that when this occurred once, action would be taken to stop this re-occurring – or is this just too obvious! 3. Make sure that keys and certs are compliant with policy When you consider how much time is spent on enforcing password policies, you would think that keys and certificates would also benefit from the same TLC. When organizations are still using key lengths less than 2048 and MD5 hashing algorithms, it should not come as a surprise that they are vulnerable. Can you have really even have a policy without the ability to enforce it? Certainly Excel aids nothing there. Deploying wildcard certificates across multiple systems with a long validity periods is not good practice. You might as well use the same admin password on all your systems! If you have policies, then enforce them! 4. Review your private key management processes The market for stolen SSL certificates is purportedly worth $5 billion, and since most organizations do not have system-generated inventory, it’s probably unlikely that you would notice one or two going missing. Also since you have no inventory, would you even know if a private key your admins had access to, tied to a certificate issued by any one of 650 plus CAs, from anyone of 54 countries, went walkabout? In the same way that you probably stop your admins having access to root passwords, the same steps should be taken to control their access to private keys. For example, how many organizations, as a matter of policy, replace private keys that have been directly accessed by administrators when those administrators are reassigned or leave the organization? How often are keystore passwords changed, or do you even have keystore passwords, and is there any separation of duties related to key access. These are just some of the basic steps you should be taking. 5. Safeguards to prevent migration of nonproduction keys and certs to production In a recent check on a single production server at a global, Fortune-ranked organization: instead of the 5 certificates they expected to find, there were in excess of 190! When systems move from development, to test, to production, very often the keys go with them. Not only are the keys being exposed to multiple administrators, but test environments and developers have much less regard for security than, say your average hacker. It is important that test CAs and test certificates should not be trusted on production systems, and certificates, and private keys used in tests do not move into production. 6. Be ready for the certificate authority (CA) compromise Just because Microsoft, VeriSign, and a host of others have been compromised doesn’t mean you will be. But then would you even know, because it’s not just the 650 plus CAs that you have to think about, but the over 1400 root certificates trusted by your systems. And these are only the external ones. Apart from ensuring that you have active contractual relationships with more than one vendor, and don’t end up in a Diginotar scenario where you have to shut down your internet business, you also need to be able to be ready to rapidly replace all certificates issued from each CA currently in use, assuming you know what they are. And of course this assumes you know where they keys and certificates are, which brings us back to having a system-generated inventory of keys and certs. There’s no point is simply getting new certificates if you don’t know who needs them! 7. Do a Sanity Check Like any IT security measure, its ultimate purpose is to ensure that your business is not threatened and runs smoothly. Ultimately the effectiveness of key and certificate management controls can have a major impact on the business, so take the initiative and demonstrate why somebody in your organization decided to add the “C” to your title. Otherwise you may discover that the “C” word when used to refer to you is not “Chief!"