It may not be particularly sensitive or sophisticated and is generally associated with life and death battle on the front line – yet the old British Army adage “Proper Planning and Preparation Prevents Piss Poor Performance”, (or the “seven Ps”) could not be more appropriate when battling the growing threat of cyber warfare. As organisations brace themselves for attacks, planning and preparation are everything.
In reality, no matter how good or well protected we think we are, those who are now targeting our organisations are better trained, have unlimited resources, and are extremely capable! Cyber Warfare is a very real threat, and as in any war, weapons do not distinguish between legitimate and innocent targets.
Collateral damage is never avoidable, and management will be held accountable for harm to the organisation regardless of its source. Recently, a number of security specialists demanded an international treaty to halt online weapons. In reality though this sounds a little like a weapons manufacturer asking for a ban on weapons!
The target of choice
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. The target, however, in many cases is the same: SSL certificates. Each of these pieces of malware have been signed by a digital certificate owned, or appearing to be owned, by reputable companies, and issued by trusted authorities such as VeriSign, and Microsoft – or again appearing to be.
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 I have yet to see a better and more secure alternative.
Passwords are certainly not the way to go – they’re being hacked left, right and centre. 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.
Contrary to popular opinion, Microsoft did not invent Excel to be a certificate management or policy enforcement system, although given the extensive use of Excel among PKI departments, they could probably rebadge it and charge a fee! But then 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. Review your private key management processes
The market for stolen SSL certificates is purportedly worth $5 billion, and since most organisations 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 organisations, as a matter of policy, replace private keys that have been directly accessed by administrators when those administrators are reassigned or leave the organisation? 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.
2. Introduce SSL and SSH policies and review them annually
In many organisations, 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.
3. Ensure 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 organisations 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. Have a system-generated inventory of keys and certificates
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 organisations, the management of keys has been so diluted across various groups that most organisations 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 organisations 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!
5. Prepare for a 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!
6. 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 organisation: 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
7. Do a sanity check
Like any IT security measure, its ultimate purpose is to ensure that your business runs safely and smoothly. No one can predict when or where the next breach will occur. Enterprises must prepare to act immediately and implement these steps to ensure control throughout the lifecycle of keys and certificates. If they don’t then the simple result is that they are placing your business at risk. And don’t think you won’t be compromised, because you will.
Effective key and certificate management controls can make or break a business – so take the initiative and prepare your organisation for war by strengthening your defences and closing the doors on your attacker.