Venafi: CAs are not wholly to blame for certificate-based attacks
Venafi: CAs are not wholly to blame for certificate-based attacks

There is an old adage from the British Army known as the ‘seven Ps', and it 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 anybody, but every organisation needs to ask itself if it has planned and is prepared for increasingly likely attacks.

As anyone who has been following the news for the last few months will realise, the SSL certificate has now become a key target in the cyber attack arsenal. Flame, Stuxnet and Duqu 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 by trusted authorities, or are 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 haven't yet seen a better and more secure alternative.

Passwords are certainly not the way to go – they are being hacked and some will argue that one-time password (OTP) token-based solutions do the job, but it's not so long ago that RSA was replacing millions of them. 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 re-certify 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:

Get SSL and SSH policies in place 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 and administrative access to private keys. 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.

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?

Make sure that keys and certificates 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 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.

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 administrator had access to, tied to a certificate issued by any one of 650+ certificate authorities (CAs) from any one of 54 countries, went walkabout?

In the same way that you probably stop your administrator having access to root passwords, the same steps should be taken to control their access to private keys. 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.

Safeguards to prevent migration of non-production keys and certificates to production

In a recent check on a single production server at a global, Fortune-ranked organisation: instead of the five certificates they expected to find, there was in excess of 190.

When systems move from development to test and then on 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 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

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+ CAs that you have to think about, but over 1,400 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.

This assumes that you know where the keys and certificates are, which brings us back to having a system-generated inventory of keys and certificates. There's no point is simply getting new certificates if you don't know who needs them.

Do a sanity check

Like any IT security measure, its ultimate purpose is to ensure that your business is not threatened and runs smoothly. None of us knows where the next breach will occur, or whether it will occur in a week or three months.

Enterprises must ready themselves to respond immediately and implement these steps to ensure control over the lifecycle of keys and certificates. The very serious implication is that if you don't then you are placing your business at risk and don't think that you will not be compromised, because you will.

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 organisation decided to add the ‘C' to your title.

Calum MacLeod is EMEA director of Venafi