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
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
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
Recommendation: Establish an enterprise-wide, proactive plan for replacing all 1024-bit keys.
Failure four: Key and data compromise
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
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
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
Recommendation: Investigate system services that are using expired certificates. Either remove these services or renew their certificates.
Failure eight: Questionable certificates
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
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
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
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
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.
•Date: 20th October 2011 • Region: World •Type: Article • Topic: ISM