Free Newsletter
Register for our Free Newsletters
Access Control
Deutsche Zone (German Zone)
Education, Training and Professional Services
Government Programmes
Guarding, Equipment and Enforcement
Industrial Computing Security
IT Security
Physical Security
View All
Other Carouselweb publications
Carousel Web
Defense File
New Materials
Pro Health Zone
Pro Manufacturing Zone
Pro Security Zone
Web Lec
ProSecurityZone Sponsor
ProSecurityZone Sponsor
ProSecurityZone Sponsor
ProSecurityZone Sponsor
ProSecurityZone Sponsor
ProSecurityZone Sponsor

Failure Points In Data Breach Cases

Tufin Technologies : 24 October, 2011  (Technical Article)
Callum MacLeod of Venafi examines the twelve points of failure leading to high profile data breaches
Failure Points In Data Breach Cases
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 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 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 organizationOrganisation 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 - 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 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 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 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.

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 organizationOrganisation.

11 - 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 12 - 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 organizationOrganisation 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 organizationOrganisation avoids all of these 12 classic mistakes, you can eliminate irritating and needless certificate-related downtime. More importantly, your organisation won’t 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.
Bookmark and Share
Home I Editor's Blog I News by Zone I News by Date I News by Category I Special Reports I Directory I Events I Advertise I Submit Your News I About Us I Guides
   © 2012
Netgains Logo