PKI Bootcamp: Are You at Risk?

Certificates and keys play a fundamental role in any organization’s security architecture. With the use of TLS encryption exploding, however, organizations are struggling to effectively manage the associated certificates and private keys. Bad management practices can rapidly turn keys and certificates from an asset to a liability, with increased outages and risk of security breaches.

In order to implement an effective management and security strategy for keys and certificates, it helps to understand the risks associated with them. So, in this blog post, I’ll provide a summary of some of the risks large organizations face.

• Administrative Risk: In most cases, systems administrators are responsible for requesting, installing and maintaining certificates on the systems they manage. While these administrators are generally experts at managing and maintaining their systems (website, application servers, load balancers, etc.), they typically have very little understanding of certificates and best practices for their usage. Certificates are frankly a necessary evil for them. Lack of knowledge and overwhelming workloads make administrators one of the biggest risks to the security and operations associated with certificates and private keys.
   
• Downtime due to Expirations: Certificates contain expiration dates to ensure that they’re changed regularly. If administrators don’t keep track of the certificates they’ve deployed, those certificates can expire in while systems are running and cause outages and downtime of mission-critical systems and applications. Nearly every major organization has experienced some sort of outage due to expired certificates—some of them quite costly.
   
• Private Key Compromise: Every certificate has a corresponding private key, the thing that you need to keep secret. If an attacker can get a copy of a private key, they can impersonate the server or person holding the certificate. Most certificate private keys are stored in files managed directly by system administrators. Mishandling these files can result in a significant risk of compromise for those keys.
   
• Rogue Certificates: Certificate authorities (CAs) issue certificates. If an attacker can get a rogue certificate issued by a CA—either by tricking the CA or compromising the CA outright—they can impersonate another person or system (such as acting like an online banking website so that customers will login and provide their credentials).
   
• Vulnerable Algorithms: The development of cryptographic algorithms that can’t be broken by attackers is an ongoing challenge. Overtime, algorithms which were once considered strong become breakable, either due to increased computing capabilities or improved techniques for breaking the algorithms. SHA-1 is the most recently algorithm that has become vulnerable and required deprecation over the past few years. A “zero day” breakage of an algorithm—requiring rapid replacement of keys and certificates—would send many organizations scrambling to figure out where they have keys and certificates deployed so they could be replaced.
   
• Crypto Library Bugs: Bugs in the cryptographic libraries that create the keys used with certificates, and bugs in the programs that use those keys can put them at risk. If that bug affects the randomness of keys it generates—such as the one discovered in Debian in 2008—it can significantly shorten the time required for an attacker to factor or determine the value of a private key. Bugs in programs that use keys and certificates may open keys to compromise—such as the OpenSSL Heartbleed bug introduced in 2012, which enabled attackers to potentially access website private keys, in addition to passwords and other data.
   
• DevOps Risk: DevOps teams are tasked with streamlining and accelerating the deployment and management of platforms, software, configuration and data, including keys and certificates. These “Fast IT” operations reduce administrative risk, but bugs in DevOps programs, scripts, or frameworks may introduce operational or security risks to keys.
   
• Failed Audits: Certificates and keys (including SSH) have long been overlooked by auditors in their security reviews of organizations. This has started to change recently, as auditors gain a better understanding of the critical role certificates and keys play in organizations. However, many organizations are not prepared to respond to audits of certificates, which may require an inventory of all certificates, sounds management processes, and the like.
   
• Attacks inside TLS Connections: As TLS and its associated protocols (e.g., HTTPS) ensure confidentiality of communications, attackers may cloak their attacks inside encrypted connections because many organizations are not actively monitoring traffic inside of encrypted connections.

Now you know where your organization’s certificates and keys may be at risk. I’ll follow on in future posts with additional details for some of the risks and with best practices for protecting against them.

Read my next blog to learn more about the anatomy of a certificate attack.