Organisations like Sony, Lockheed Martin, Nintendo, and Groupon share something unpleasant in common: recent security breaches. They are not alone.
The list of companies suffering the public humiliation and expense that go hand-in-hand with lax IT security procedures goes on and on. I read in a read last week that the global market for stolen identities is now worth a staggering $5 billion a year. Most of these companies had implemented encryption to protect their data and yet their efforts were wasted because they had not followed best practices for managing their encryption assets and deployments.
Whether security breaches involve customers’ personal and financial information (which are identity-theft manna), top-secret data that could affect national security, compromised servers or company intellectual-property, the bottom line is this: organisations need to exercise better due diligence when it comes to managing encryption keys and certificates.
Failure 1: Certificate validity periods that exceed CA validity periods
This situation is common when organisations use internal Certificate Authorities (CAs) because the administrators managing the CA might not understand the proper relationship between a CA certificate and the certificates that it signs. When a CA certificate expires, other devices will no longer trust certificates signed by that CA certificate. Those certificates might be valid in terms of time, but, without providing that vital trust, they will not function correctly. The discrepancy in validity period leads to a dangerous situation because, while administrators may regularly monitor the end-entity certificates under their care, they rarely know the corresponding root CA’s validity period. Hence, its expiration almost always comes as a nasty surprise.
Recommendation: Establish clear policies for certificate validity periods, for both CA and end-entity certificates, and ensure that these policies are followed. The broadly accepted best practice is this: the validity periods for end-entity certificates should never exceed the validity periods for their corresponding root CAs.
Failure 2: Wildcard certificates
Wildcard certificates are convenient but can increase the risk of data and system breaches due to increased probability of private key compromise. Wildcard certificates enable you to use the same certificate and private key on multiple systems that have different host names. This means the private key is stored on multiple systems, which increases the likelihood that someone can compromise it.
Recommendation: Eliminate the use of wildcard certificates altogether – or in circumstances where other alternatives are not feasible – severely restrict their use and admin access. If you must continue to use wildcard certificates, you must also enforce policies and take extreme precautions to ensure the security of their corresponding private keys, by using an HSM to store them or FIPS 140-2 algorithms to secure them, for example.
Failure 3: Weak key lengths
The US National Institute of Standards (NIST) recommends that organisations stop using 1024-bit keys because increased computing power makes them vulnerable to brute-force attacks. NIST’s outside date for replacing 1024-bit keys with more secure 2048-bit keys was 2010, after which the Organisation deemed 1024-bit keys deprecated – meaning condemned – with increasing risk through 2013. Nevertheless, many organisations are still using 1024-bit keys simply because the certificates to which they belong have not yet expired. Excessively long certificate-validity periods further compound the problem, extending the exposure associated with weak-key usage.
Recommendation: Establish an enterprise-wide, proactive plan for replacing all 1024-bit keys.
Failure 4: Key and data compromise
Lengthy certificate-validity periods also increase the risk that reassigned or terminated administrators have copies of private keys that will be valid for 10 and 20 years. Such administrators could maliciously access data long after anyone remembered who they were.
Recommendation: Establish clear policies for certificate validity periods, for both CA and end-entity certificates, and ensure these policies are followed. Accepted practices specify validity periods of one to three years. If possible, use validity periods of one year for end-entity certificates. A proper validity period ensures that private keys are regularly replaced, thus reducing the risk that reassigned or terminated administrators could have access to private keys that will be valid for years to come.
Failure 5: Self-signed certificates
Self-signed certificates are problematic for two reasons. First, administrators often overlook them when monitoring for certificates that are nearing their expiration date (resulting in system downtime when the certificates are not renewed). Second, self-signed certificates are difficult to revoke. If a self-signed certificate’s private key is compromised, the inability to rapidly revoke the key may open the door to malicious attackers.
Recommendation: Replace self-signed certificates on production systems with certificates issued by an established intermediate signing CA as soon as possible.
Failure 6: Decentralised certificate inventories
The lack of a central certificate inventory creates several risks, including: downtime, weak security and the inability to respond effectively to security breaches. For example, if someone were to compromise a company’s CA and the company lacked a central inventory, it would be very difficult for the company to promptly notify all certificate owners and ensure that all existing certificates were replaced.
Recommendation: Establish a central inventory system that maintains a comprehensive catalogue of all certificates and certificate owners. To properly maintain this inventory, strongly consider implementing a set of policy-based, automated management technologies that are capable of performing regular server- and client-side certificate discovery.
Failure 7: Expired certificates
Services with expired certificates can indicate systems that are no longer in use – and, as hackers often correctly assume, no longer properly patched, managed and secured. Such systems provide potential entryways for malicious attacks.
Recommendation: Investigate system services that are using expired certificates. Either remove these services or renew their certificates.
Failure 8: Questionable certificates
Server administrators sometimes deploy certificates on their own without purchasing them from authorised CA vendors or requesting them from the company’s own CA. The practice of deploying questionable certificates indicates that certificates, private keys, and encryption are managed with limited adherence to sound policies and practices. Obviously, this increases the potential for a breach or compromise.
Recommendation: Periodically scan your environment and identify and investigate systems that host services with questionable or unknown certificates. If the applications or services are legitimate, replace the questionable certificates. If they are not, promptly eliminate potential threat vectors by removing them from the system.
Failure 9: Insecure root CA storage
If attackers can gain access to root CA private keys, they can create and issue counterfeit certificates. With these certificates, the attackers can launch some disturbingly powerful attacks, impersonating systems, phishing for employees’ credentials and launching man-in-the-middle attacks – all of which can yield private (and regulation-protected) information to them.
Recommendation: Ensure that the root CA is properly secured. This is a must. Proper security entails dual controls for access to root certificate storage and auditable storage access and use records.
Failure 10: Direct administrator access to private keys
Again, administrators who have access to private keys have the opportunity to make copies of them. This means reassigned or terminated employees could use copied keys to perform malicious acts.
Recommendation: Automate the management of private keys and certificates on systems that require heightened security so that administrators do not require – or have – direct access to the private keys. In cases where you cannot avoid manual key management, require – and enforce – replacement of private keys and certificates when administrators who have access to those encryption assets are reassigned or terminated from your organisation.
Failure 11: Compromised signing algorithms
The Message-Digest 5 (MD5) algorithm is not collision-resistant, making this algorithm deprecated for signing SSL certificates.
Let us examine the problem a bit more closely. When a CA signs a certificate, it hashes the certificate with a signing algorithm and encrypts that hash with its private key. The reason that hackers cannot copy the signature and attach it to their own certificates – essentially forging the CA’s signature – is that the hash is unique to the legitimate certificate. Because a collision means that the hash is not unique, hackers can forge certificates signed by MD5. It is up to CAs to prevent these attacks by always using SHA-1 rather than MD5 to sign certificates – which most now do. As this exploit becomes more publicised, clients might begin to protect themselves by refusing to trust MD5-signed certificates.
Recommendation: Locate and replace all certificates that were created using the MD5-RSA signing algorithm. If you have an internal CA, always use SHA-1 for the signing algorithm.
Failure 12: Re-use of private keys
Re-using private keys increases their compromise potential, especially when administrators have access to them. Once more, with ample opportunity to copy these keys, administrators who have been reassigned or terminated can use the copies to mount attacks.
Recommendation: Replace certificates and private keys for which your organisation has bypassed the new-key-pair generation process. Then communicate and strictly enforce policies and procedures that require new-key-pair generation for all certificate renewals.
By systematically ensuring that your organisation avoids all of these 12 classic mistakes, you can eliminate irritating and needless certificate-related downtime. More importantly, your organisation will not become a Sony, Lockheed Martin or Groupon. That is, by exercising better care in managing encryption keys and certificates your organisation can avoid damaging and costly data leaks and Website failures – and a lot of grief.
© Technews Publishing (Pty) Ltd. | All Rights Reserved.
printer friendly version