How to handle a digital-certificate fraud incident

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.

MORE: Want security, privacy? Turn off that smartphone, tablet GPS 

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:

Read more about wide area network in Network World's Wide Area Network section.

Join the CSO newsletter!

Error: Please check your email address.
Show Comments

Featured Whitepapers

Editor's Recommendations

Solution Centres

Stories by Ellen Messmer

Latest Videos

  • 150x50

    CSO Webinar: Will your data protection strategy be enough when disaster strikes?

    Speakers: - Paul O’Connor, Engagement leader - Performance Audit Group, Victorian Auditor-General’s Office (VAGO) - Nigel Phair, Managing Director, Centre for Internet Safety - Joshua Stenhouse, Technical Evangelist, Zerto - Anthony Caruana, CSO MC & Moderator

    Play Video

  • 150x50

    CSO Webinar: The Human Factor - Your people are your biggest security weakness

    ​Speakers: David Lacey, Researcher and former CISO Royal Mail David Turner - Global Risk Management Expert Mark Guntrip - Group Manager, Email Protection, Proofpoint

    Play Video

  • 150x50

    CSO Webinar: Current ransomware defences are failing – but machine learning can drive a more proactive solution

    Speakers • Ty Miller, Director, Threat Intelligence • Mark Gregory, Leader, Network Engineering Research Group, RMIT • Jeff Lanza, Retired FBI Agent (USA) • Andy Solterbeck, VP Asia Pacific, Cylance • David Braue, CSO MC/Moderator What to expect: ​Hear from industry experts on the local and global ransomware threat landscape. Explore a new approach to dealing with ransomware using machine-learning techniques and by thinking about the problem in a fundamentally different way. Apply techniques for gathering insight into ransomware behaviour and find out what elements must go into a truly effective ransomware defence. Get a first-hand look at how ransomware actually works in practice, and how machine-learning techniques can pick up on its activities long before your employees do.

    Play Video

  • 150x50

    CSO Webinar: Get real about metadata to avoid a false sense of security

    Speakers: • Anthony Caruana – CSO MC and moderator • Ian Farquhar, Worldwide Virtual Security Team Lead, Gigamon • John Lindsay, Former CTO, iiNet • Skeeve Stevens, Futurist, Future Sumo • David Vaile - Vice chair of APF, Co-Convenor of the Cyberspace Law And Policy Community, UNSW Law Faculty This webinar covers: - A 101 on metadata - what it is and how to use it - Insight into a typical attack, what happens and what we would find when looking into the metadata - How to collect metadata, use this to detect attacks and get greater insight into how you can use this to protect your organisation - Learn how much raw data and metadata to retain and how long for - Get a reality check on how you're using your metadata and if this is enough to secure your organisation

    Play Video

  • 150x50

    CSO Webinar: How banking trojans work and how you can stop them

    CSO Webinar: How banking trojans work and how you can stop them Featuring: • John Baird, Director of Global Technology Production, Deutsche Bank • Samantha Macleod, GM Cyber Security, ME Bank • Sherrod DeGrippo, Director of Emerging Threats, Proofpoint (USA)

    Play Video

More videos

Blog Posts

Market Place