Certificate management explored

REGIONAL PORTALS
Continuity Central currently offers three regional business continuity portals:
North America
United Kingdom
Asia Pacific / Australasia


Use Google? Click the button to add Continuity Central news to your Google home page.

Get immediate news and information updates via our Twitter feed.

SUBMIT YOUR NEWS
To submit news stories to Continuity Central, e-mail the editor.

NEWSFEED
Want an RSS newsfeed for your website? Click here

Certificate management explored

Calum MacLeod highlights twelve classic mistakes which can result in certificate-related downtime and IT security breaches.

The list of companies suffering the public humiliation and expense that go hand-in-hand with IT security breaches is growing rapidly. Many of the companies impacted recently 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: organizations need to exercise better due diligence when it comes to managing encryption keys and certificates.

The following article describes twelve common certificate-related failures which every organization wanting to achieve top-class IT security needs to address:

Failure one : Certificate validity periods that exceed certification authority (CA) Validity Periods
This situation is common when organizations use internal 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 two: 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 aren’t 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 three: Weak key lengths
The US National Institute of Standards (NIST) recommends that organizations 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 organization deemed 1024-bit keys deprecated — meaning condemned — with increasing risk through 2013. Nevertheless, many organizations 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 four: 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 five: 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 six: Decentralized 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 seven: 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 eight: Questionable certificates
Server administrators sometimes deploy certificates on their own without purchasing them from authorized 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 nine: 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 ten: 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 organization.

Failure eleven: Compromised signing algorithms
The Message-Digest 5 (MD5) algorithm is not collision-resistant, making this algorithm deprecated for signing SSL certificates.

Let’s 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 publicized, 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 twelve: Reuse of private keys
Reusing 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 Organization 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.

Conclusion
By systematically ensuring that your organization avoids all of these twelve classic mistakes, you can eliminate irritating and needless certificate-related downtime. More importantly, your organization won’t experience the public humiliation that a major security breach engenders. That is, by exercising better care in managing encryption keys and certificates your organization can avoid damaging and costly data leaks and website failures—and a lot of grief.

Author
Calum MacLeod has over 30 years of expertise in secure networking technologies, and is currently EMEA Director for Venafi a Digital certificate and encryption key management specialist. Before joining Venafi he worked for Tufin and then Cyber-Ark. MacLeod has also served as an independent consultant to corporate and government clients on IT security strategy for various European market segments, including the European Commission. www.venafi.com

•Date: 20th October 2011 • Region: World •Type: Article • Topic: ISM

Sign up for Continuity Briefing, our weekly roundup of business continuity news. For news as it happens, subscribe to Continuity Central on Twitter.

How to advertise on Continuity Central.