Practical steps to improve your corporate security posture
Sony, Lockheed Martin, Nintendo, Groupon – In fact we could go on and on. Financial services, government agencies, health care records – It doesn’t matter. According to a report I read last last week, the global market for stolen identities is now worth a staggering $5 billion a year! And the bottom line is that organizations need to exercise better due diligence on managing encryption keys and certificates.
But in our experience this is rarely the case and listed below are some of the classic failures we’ve come across and in most cases we find all of them in most organizations. If you’re fortunate this is not you, and if unfortunately it is, then hopefully you will find the recommendations relevant and useful.
Certificate validity periods exceed certificate authority validity periods
A common situation when organizations use internal CAs! System outages or downtime occur due to root expirations. Administrators who are monitoring the expiration date of their certificates very often not realize that the CA certificate has expired.
Recommendation: You should establish clear policies for certificate validity periods, for both CA and end entity certificates, and ensure those policies are followed. It is a broadly accepted practice that the validity periods for end entity certificates should never exceed the validity periods for their issuing CA.
Use of 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 the same certificate and private key to be used on multiple systems with different hostnames. The fact that the private key is stored on multiple systems increases the likelihood that it can be compromised.
Recommendation: The use of wildcard certificates should be eliminated or severely restricted to support only those circumstances where alternatives are infeasible. If continued use is required, you must enforce extreme precautions to ensure the security of these certificates corresponding private keys (e.g., HSM creation and storage, FIPS 140-2 algorithms, etc.).
Use of weak key lengths
NIST recommended that 1024-bit keys no longer be used after 2010 due to increased computing power available to perform brute-force attacks but are still found in many organizations simply because the certificates have not expired! 1024-bit keys are currently considered “deprecated” – deprecated means condemned! – with increasing risk through 2013. Combined with the excessively long certificate validity periods, this further extends the exposure associated with the use of weak keys.
Recommendation: Organizations should establish an enterprise-wide, proactive plan for replacing all 1024-bit keys.
Key and data compromise
Reassigned or terminated administrators can have copies of private keys that will not be replaced for 10 and 20 years, enabling them to maliciously access data.
Recommendation: Accepted practices for validity periods are 1-3 years. You should establish clear policies for certificate validity periods, for both CA and end entity certificates, and ensure those policies are followed. If possible, validity periods of one year should be used for end entity certificates to ensure that private keys are replaced regularly to reduce the risk that reassigned or terminated administrators have access to private keys that will be in use for long periods of time.
Self-signed certificates
Self-signed certificates are often overlooked for expiration monitoring, resulting in system downtime. Additionally Self-signed certificates cannot be easily revoked. If the private key is compromised, the inability to rapidly revoke may result in the private key and certificate being used for malicious purposes.
Recommendation: Organizations should review and replace any self-signed certificates used in or on a production system with certificates issued by an established Intermediate Signing CA as soon as possible.
Centralized certificate inventory
The lack of a central inventory creates several risks, including, Downtime, Weak Security, Inability to Respond – for example if a CA is compromised and there is no central inventory, it is very difficult to ensure that all certificate owners are promptly notified and that all existing certificates are replaced.
Recommendation: Organizations should have a central inventory system to maintain a comprehensive catalog of all certificates. In order to keep that inventory up to date, it should strongly consider deploying a set of technologies and processes that enable it to perform regular discoveries for server- and client-side certificates so that a comprehensive inventory is maintained. It should also establish a set of processes for keeping ownership information for certificates.
Expired certificates in use
Services with expired certificates are indicative of systems that very often are not required and should be retired and removed in order to reduce potential attacks.
Recommendation: You should investigate any system service that is using expired certificates and either remove the service or renew its certificate.
Questionable certificates deployed
This provides an indication that certificates, private keys, and encryption are managed with limited adherence to sound policies and practices, increasing the potential for a breach or compromise.
Recommendation: You should periodically scan the environment and identify and investigate systems which host services with questionable or unknown certificates. If the application or service is legitimate then the certificate should be replaced otherwise the service should be removed from the system in order to eliminate potential threat vectors.
Root CA storage security
If an attacker can gain access to the Root CA private key and issue certificates, they can create counterfeit certificates in order to impersonate systems and potentially perform man-in-the-middle attacks.
Recommendation: You must ensure that the Root CA is properly secured and requires dual control for access and auditable records of its access and use.
Direct administrator access to private keys
Because administrators can make copies of private keys, reassigned or terminated employees have the opportunity to perform malicious operations using these keys.
Recommendation: On security-sensitive systems, the management of private keys and certificates should be automated so that administrators do not require direct access to the private keys. In cases, where manual management of keys cannot be avoided, policies should require that private keys and certificates be replaced each time an administrator with access to their certificates and keys is reassigned or terminated from the organization.
Use of compromised signing algorithms
The MD5 Message-Digest Algorithm is not collision resistant but is still widely used, which makes it easier for context-dependent attackers to conduct spoofing attacks, as demonstrated by attacks on the use of MD5 in the signature algorithm of an X.509 certificate. There are numerous sites that provide source code for the exploit.
Recommendation: You should locate and replace all certificates that were created using the MD5-RSA signing algorithm.
Reuse of private keys
Reusing private keys increases the possibility that they can be compromised, especially by administrators who have had access and then are reassigned or terminated. These keys can then be used to mount attacks.
Recommendation: You should replace certificates and private keys that bypassed the new key pair generation process and communicate and strictly enforce policies and procedures that require new key pair generation for all certificate renewals.
Author: Calum MacLeod, Venafi.