Risk
8/13/2012
05:58 PM
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%
Repost This

NIST: How To Prepare For And Respond To A Certificate Authority Breach

Guidelines could serve as basis for new FISMA rules

The federal government's National Institute for Standards and Technology (NIST) has issued its first-ever guidelines for government agencies and private-sector businesses to protect themselves in the wake of the breach of their digital certificate authorities.

A wave of certificate authority (CA) breaches during the past year-and-a-half -- including the Flame malware's abuse of a Microsoft digital certificate -- has been a wake-up call for many organizations. The reality is that many organizations in both the public and private sector don't have a detailed accounting of their digital certificates, their CAs, or who within their organizations "own" those certs.

NIST's new "Preparing for and Responding to Certification Authority Compromise and Fraudulent Certificate Issuance" guidelines bulletin, which it co-authored with Venafi, was in direct response to concerns about how a CA breach could affect agencies and businesses. "The big thing now is that these attacks are taking place" on CAs, says Paul Turner, vice president of products and strategy at Venafi. "That's why we worked with NIST on this."

Turner says while he can't speak for NIST, the guidelines issued by the agency likely will be put on the path to becoming part of FISMA (Federal Information Security Management Act) regulations. "Right now, this is effectively a guideline," he says. "Next is looking at including it as part of FISMA -- that's the most likely path."

[ Yet another CA is hacked, suspends issuing certificates -- and there likely will be more. See Certificate Authority Uncovers Old Breach. ]

Meantime, NIST recommends that organizations ensure their CA is "secure," whether it's an internal or external authority. That means security best practices and regular third-party audits. And if a CA suffers an "impersonation" attack or one of its Registration Authorities is compromised, it should have clear-cut emergency revocation response in place: "The CA must revoke the certificates and inform the organizations identified as subjects in the fraudulent certificates and all potential relying parties that might rely on those certificates. If a CA system compromise or signing key theft occurs, the CA’s certificate(s) must be revoked by any CAs that have issued certificates to it, all subjects that the compromised CA has issued certificates to must be notified that they will require new certificates, and all possible relying parties must be notified," according to the guidelines published by NIST.

Venafi's Turner says it's not easy to ensure that a CA breach is detected as quickly as possible. The massive breach of now-defunct CA DigiNotar serves as a cautionary tale for any agency or company. "The attack on DigiNotar focused on Iranian citizens, but there was also fallout for the Dutch government, which was the biggest user of DigiNotar [certificates]. The Dutch government had to get up and say, 'Don't trust these sites until we find all the certificates on the front-end and back-end that are relying on them,'" Turner says. "That's the big issue NIST is really focusing on here: You've got to make sure you can respond."

If the breach had been more widespread, affecting bigger CAs such as Entrust or VeriSign, then the damage would have been much more severe, he says. "Most organizations have not done a good job tracking their certificates and who owns them. Most organizations are not even close to prepared," he says.

Among NIST's recommendations: get a detailed inventory of your digital certs and corresponding CAs; have a backup option in place for replacing a certificate or acquiring a new one; and make sure you know the nature of a CA security incident when it occurs, such as whether it was a true breach of their systems or some sort of impersonation attack. The NIST bulletin is available here (PDF).

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Kelly Jackson Higgins is Senior Editor at DarkReading.com. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise Magazine, ... View Full Bio

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-2391
Published: 2014-04-24
The password recovery service in Open-Xchange AppSuite before 7.2.2-rev20, 7.4.1 before 7.4.1-rev11, and 7.4.2 before 7.4.2-rev13 makes an improper decision about the sensitivity of a string representing a previously used but currently invalid password, which allows remote attackers to obtain potent...

CVE-2014-2392
Published: 2014-04-24
The E-Mail autoconfiguration feature in Open-Xchange AppSuite before 7.2.2-rev20, 7.4.1 before 7.4.1-rev11, and 7.4.2 before 7.4.2-rev13 places a password in a GET request, which allows remote attackers to obtain sensitive information by reading (1) web-server access logs, (2) web-server Referer log...

CVE-2014-2393
Published: 2014-04-24
Cross-site scripting (XSS) vulnerability in Open-Xchange AppSuite 7.4.1 before 7.4.1-rev11 and 7.4.2 before 7.4.2-rev13 allows remote attackers to inject arbitrary web script or HTML via a Drive filename that is not properly handled during use of the composer to add an e-mail attachment.

CVE-2011-5279
Published: 2014-04-23
CRLF injection vulnerability in the CGI implementation in Microsoft Internet Information Services (IIS) 4.x and 5.x on Windows NT and Windows 2000 allows remote attackers to modify arbitrary uppercase environment variables via a \n (newline) character in an HTTP header.

CVE-2012-0360
Published: 2014-04-23
Memory leak in Cisco IOS before 15.1(1)SY, when IKEv2 debugging is enabled, allows remote attackers to cause a denial of service (memory consumption) via crafted packets, aka Bug ID CSCtn22376.

Best of the Web