Are you prepared to deal with a security incident involving digital-certificate fraud? You should be, because if it happens, it might well involve the need to replace thousands of digital certificates used for security by your organization in applications or for other purposes. Here's how to prepare for bad news and be ready to respond when criminals undermine the complex public-key infrastructure (PKI) ecosystem.
Digital certificates play an important part in security for most companies where they're used in myriad ways to establish proof of identity, whether that's for an individual, an organization, a server, software, or in e-commerce transactions. But whether issued by an external certificate authority (CA) or an internal CA operated by a corporation for its own benefit, digital certificates can be undermined by fraud due to compromised systems that could require replacing user and device certificates quickly.
IN THE NEWS: NASA's hot radiation mission
Fraud of all kinds in this regard has already occurred several times in the past few years. And in light of that, the National Institute of Standards and Technology (NIST) has put out a security bulletin with advice about "Preparing and Responding to Certification Authority Compromise and Fraudulent Certificate Issuance."
Here's how bad things happen to good certificates.
- Impersonation. The attacker impersonates someone else at a registration authority (RA), which acts as an intermediary between users and CAs, reviewing and approving certificate requests. The RA issues a certificate with someone else's name on it to the fraudster, who might forge a digital signature, for example.
- RA Compromise. The attacker infiltrates the RA and authorizes and issues fraudulent certificates by the CA.
- CA System Compromise. The CA system is attacked and the attacker can issue fraudulent certificates, also altering logs to try and cover up his tracks.
- CA Signing Key Compromise. Attacker gets hold of a CA signing key, perhaps by simply getting a copy of it, to sign fraudulent certificates and certificate revocation lists (CRLs) at will.
The point NIST makes in its bulletin is that CAs, whether external or an internal corporate CA issuing its own certificates for its own purposes, have to follow well-defined security practices to try and prevent compromise. But they also have to know how to respond to successful attacks.
Fraud prevention measures involve regular third-party audits and reviews, and they need to apply tracking and detection mechanisms to CA systems to detect any compromise as fast as possible. Importantly, they need to be organized to quickly communicate about possible certificate fraud in an appropriate way to all "relying parties."
A "relying party" could be an individual, or electronic systems that interact with the "subject," defined as the "person, organization, system, application, or device to which a certificate is issued and whose identifier is found in the certificate."
The CA has to revoke certificates in the event of an RA compromise that leads to issuance of fraudulent certificates.
If a CA system is compromised or signing-key theft occurs, the CA's certificate has to be revoked, and all subjects that the compromised CA issued certificates to must be notified because they'll require all-new certificates. RAs, of course, should be using effective means to vet certificate requests to prevent an impersonation attack.
Certificate fraud, then, basically represents a quiet crisis of sorts, because without the ability to quickly respond, companies could face network or e-commerce service disruptions because their certificates are no longer considered valid.
To prepare for a "CA Security Incident," as NIST calls it, the following is recommended for those inside and outside of government:
1. Be prepared by having clearly documented the applications and servers that rely on certificates for security. Keep records on what kind of certificate. This might be an "end entity" certificate or it may be accepting public-key certificates from other users or servers, since "for many systems, both conditions will hold."
2. For end-entity certificates, document the system and application owner, with contact information. Identify where the certificate and associated key material are stored. Note what CA issued the certificate, whether internal or external.
3. Identity the "trust anchor," which for commercial CAs is usually a root CA, or if a government CA, might be the Federal PKI's Common Policy Root CA.
4. Document the policies for all this, plus the certificate expiration date, algorithms and key lengths. Document the procedures to replace your system or application's public-key certificate. (NIST points out that in some circumstances the public-key certificate may even be hard-coded into the application, so replacing the certificate would involve updating or replacing the operating system or application.)
NIST advises finding a backup source for whatever you do today for rapid acquisition of new certificates, if trouble occurs.
Responding to a CA Security Incident means understanding what kind of compromise occurred in this public-key infrastructure ecosystem.
If one of the worst things happens, that a CA system or key-compromise occurs that impacts your company because you rely on them, someone in your company will have to ensure that certificates issued to the company's systems or users from the compromised CA are revoked.
If you are responsible for this, that means notifying all those reliant on the affected certificates, and setting up a point of contact or helpdesk to respond to questions. At that point, all certificates from the compromised CA would need to be replaced as quickly as possible with new certificates from a different CA. And that means "relying parties" in the PKI ecosystem have the certificate trust chains to validate certificates from the CA.
"Successful attacks on CAs have made CA compromises a tangible threat to which organizations must be prepared to respond. Because organizations so broadly rely upon TLS and SSL to secure systems and data, a CA compromise may require the replacement of end-entity certificates, trusted root certificates, or both on hundreds or thousands of systems," NIST concludes.
So it might make sense to run a disaster-response test to find out what it would take to deal with a possible certificate-fraud incident.
Ellen Messmer is senior editor at Network World, an IDG publication and website, where she covers news and technology trends related to information security. Twitter: @MessmerE. Email: firstname.lastname@example.org.