Are You Prepared for Certificate Authority Breaches?

By Nate Couper

In the last few years, security breaches of signed SSL certificates, as well as a number of certificate authorities (CA’s) themselves, have illustrated gaps in the foundations of online security.

  • Diginotar
  • Comodo
  • Verisign
  • others

It is no longer safe to assume that CA’s, large or small, have sufficient stake in their reputation to invest in security that is 100% effective.  In other words, it’s time to start assuming that CA’s can and will be breached again.

Fortunately for the white hats out there, NIST has just released a bulletin on responding to CA breaches.  Find it on NIST’s website at http://csrc.nist.gov/publications/nistbul/july-2012_itl-bulletin.pdf.

The NIST document has great recommendations for responding to CA breaches, including:

  • Document what certificates and CA’s your organization uses.
  • Document logistics and information required to respond to CA compromises.
  • Review and understand CA’s in active use in your organization.
  • Understand “trust anchors” in your organization.
  • Develop policies for application development and procurement, and implement them.
  • Understand and react appropriately to CA breaches.

Let’s dive into these:

1. Document the certificates and CA’s that your organization uses

Any compliance wonk will tell you that inventory is your first and best control.  Does your organization have an inventory?

Let’s count certificates.  There’s http://www.example.com, www2.example.com, admin.example.com, backend.example.com, and there’s mail.example.com.  There may also be VPN.example.com, ftps.example.com, ssh.example.com.  These are the obvious ones.

Practically every embedded device from the cheapest WIFI router to the lights-out management interface on your big iron systems these days comes with an SSL interface.  Count each of those.  Every router, switch, firewall, every blade server enclosure, every SAN array.  Take a closer look at your desktops.  Windows has a certificate database, Firefox carries its own, Java has its own, and multiple instances of Java on a single system can have multiple CA databases.  Now your servers—every major OS ships with SSL capabilities, Windows, Linux (OpenSSL), Unix.  Look at your applications – chances are every piece of J2EE and .NET middleware has a CA database associated with it.  Every application your organization bought or wrote that uses SSL probably has a CA database.  Every database, every load balancer, every IDS / IPS.  Every temperature sensor, scanner, printer, and badging system that supports SSL probably has a list of CA’s somewhere.

All your mobile devices.  All your cloud providers and all the services they backend to.

If your organization is like most, you probably have an excel spreadsheet with a list of AD servers, or maybe you query a domain controller when you need a list of systems.  Forget about software and component inventory.  Don’t even think about printers, switches, or cameras.

If you’re lucky enough to have a configuration management database (CMDB), what is its scope?  When was the last time you checked it for accuracy?  In-scope accuracy rates of 75% are “good”, if some of my clients are any measure.  And CMDB scope rarely exceeded production servers.

Each one of these devices may have several SSL certificates, and may trust hundreds of CA’s for no reason other than it shipped that way.

Using my laptop as an example, I’ve got several hundred “trusted” CA’s loaded by default into Java, Firefox, IE and OpenSSL.  Times five or so to account for the virtual machines I frequent.  Of those thousands of CA’s, my system probably uses a dozen or so per day.

2. Document logistics and information required to respond to CA breaches

How exactly do you manage the list of trusted CA’s on your iPad anyway?  Your load balancer?  Who is responsible for these devices, and who depends on them? If you found out that Thawte was compromised tomorrow, would you be able to marshal all the people who manage these systems in less than a day?  In a week?

What would it take to replace certificates, to tweak the list of CA’s across the enterprise?  It will definitely take longer if you’re trying to figure it out as you go.

3. Review and understand CA’s in active use in your organization

Of all the dozens of CA’s on my laptop, I actually use no more than a dozen or so each day.  In fact, it would be noteworthy if more than a handful got used at all.  I could disable hundreds of them and never notice.  After all, I don’t spend a lot of time on Romanian or Singaporean sites, and CA’s from those regions probably don’t see a lot of foreign use.

Most organizations are savvy enough to source their certificates from at most a handful of trusted CA’s.  A server might only need one trusted CA.  Ask your network and application administrators – which CA’s do we trust and which do we need to trust?  It might make sense to preemptively strike some or all the CA’s you’re not actually using, if only in the name of reducing attack surface.

4. Understand “trust anchors” within your organization.

Trust Anchors are the major agents in a PKI – the CA’s.  Trust anchors provide rules and services to govern the roles of others such as the intermediates, the registrars, and the users of certificates.  Go back through your inventory (you made one of those, right?) and document the configuration.  What do the trust anchors allow and disallow with your certificates?  Will revoked certificates get handled correctly?  How do you configure it?

Does your organization deploy internal CA’s?  Which parts of the organization control the internal CA’s, and what other parts of the business depend on them?  What internal SLA’s / SLO’s are afforded?  What metrics measure them?

5. Develop policies for application development and procurement.

How many RSA SecurID customers really understood that RSA was holding on to secret information that could contribute to attacks against RSA’s customers?  Did your organization ask RIM if trusted CA’s on your Blackberries could be replaced?  Do you use external CA’s for purely internal applications, knowing full well the potential implications of an external breach?

Does your purchase and service contract language oblige your vendor even to tell you if they do have a breach, or will you have to wait till it turns up on CNN?  Do they make claims about their security, and are their claims verifiable?  Do they coast on vague marketing language, or ride on the coattails of once-hip internet celebrities and gobbled-up startups?

6. Understand CA breaches and react appropriately.

Does your incident response program understand CA breaches?  Can you mobilize your organization to do what it needs to when the time comes, and within operational parameters?

CA breaches have happened before and will happen again.  NIST has again delivered a world-class roadmap for achieving enterprise security objectives.  Is your organization equipped?

Articulating the Value of Security (or, Security is not the point)

It’s an uphill battle to convince the decision-makers in any business that they need to invest in security. Why? Because deep down, most people think security is an annoying layer of cost and inconvenience.  If you walk in and tell them, “We need more security,” they hear, “We need a more annoying layer of cost and inconvenience.”

Getting Buy-In

Getting executive buy-in for security products and services today means understanding what drives your company’s security purchase decisions. Fear, uncertainty and doubt are not the cleverest tools to use anymore. Businesses want something that sometimes seems like a foreign concept to the security profession: value.  If you don’t adapt and start answering the questions your business is really interested in, you’ll never get the green light on new projects and upgrades.  Remember, nobody wants security; they want the benefits of security. Your family members don’t want the finest deadbolt on the front door because of the excellence of its engineering or its impact resistance. They want a comfortable, happy place to live.

Achieve Objectives

Businesses also want something other than security. If a bank manager has a mandate to reduce expenses related to bank tellers, she has a couple of options. She could fire all the tellers and lock up all the bank branches, but then the bank would have no interface with its customers. Or she could take all the money, put it in piles on the street corner under a clipboard that says, “Take what you want, but write it down so we may balance your account.” That wouldn’t work either.  The best solution for reducing teller expenses is to take the money, put in on the street corner locked in a box with a computer attached, and give customers a low-cost plastic card for authentication and auditing.  Security was never the point of creating the automated teller machine. The bank had a business objective and achieved it by using some security.

A Tool in Your Toolbox

That is precisely how we all should think of security: as a way of helping companies achieve the goals or value they seek.  Business managers, especially executives at the highest levels of an organization, have a very simple, indirect view of security. They don’t think of it as security, exactly. They think of it as a tool in the corporate toolbox for enabling business. For example, the manager responsible for a critical business application wants a few things: He wants to know who is using his website; he wants to ensure that everyone can do everything on that site they need to do; he has a lot of users doing a lot of things, so he needs an easy way to manage it; and at the end of the day or the end of the quarter, he needs a report telling him what has happened so that he can improve customer satisfaction, reduce errors and increase profits.  In that example we have all four fundamental categories of security—authentication, authorization, administration and audit—but the manager doesn’t think of security once! That’s because security is not the point.

Focus on Value 

Whenever possible, security professionals should purge the word “security” from their vocabulary. Instead, answer the questions inside your bossyou’re your customer’s head, and don’t simply spout the ways security keeps bad things from happening.  Upper management thinks in terms of money, not security. What people will be needed? What headcount can we reduce? How much will it cost? How much will we save? What new revenue can we earn as a result of this investment? And they think not in terms of security risks, but in terms of credit risk, market risks and operational risks. That’s where security professionals can shine.  For any business problem, you should be prepared to help your management identify the ways that the authentication, authorization, administration or audit solutions you’re proposing will solve their problem or help customers.  Remember, it is not our job to secure the network. It’s our job to secure the business.

– Steve Hunt

Michael Rasmussen Blogs on the topic of GRC

Gregg LaRoche, VP Product Management, Neohapsis

I recently spotted an interesting posting on Mr. Rasmussen’s Blog – GRC Pundit entitled “The Forrester GRC ‘Ripple’ (OOOPS . . . I Mean, ‘Wave’)”. In addition to some very candid observations regarding industry analysts’ well-known graphical reports, Neohapsis is mentioned as one of the significant GRC vendors ‘missed’ in this year’s GRC Wave report. As you may know, the Wave criterion includes product deployment metrics to ensure new or Beta products are omitted. Certus GRC is in Beta stage and as such was not eligible for inclusion in the report. Why is Neohapsis’ Certus GRC offering significant although not included? Certus GRC is a ground breaking product that I have no doubt the analyst community will find compelling and will challenge many prior perceptions they have held about the GRC technology space and how Certus GRC can be used to manage highly complex, interrelated GRC relationships in ways that make sense for business stakeholders and employees.

I was particularly interested in Mr. Rasmussen’s perspective on the dangers of relying on the major analyst firms’ industry graphic to make critical technology selection decisions. Enterprise technology decisions are important not only in terms of investment and return, but also can dictate employee and partner experiences and limitations for years to come. Graphical summaries are useful to compare and contrast the largest, most established products at a high level. They can tell us who within that group is investing in technology over time and can also gauge some interesting peer enterprise viewpoints. But what does that tell your enterprise about the performance of that investment, the overall fit, or the user experience for your unique environment and set of business challenges? Rasmussen makes the astute observation that in this particular case, the report has focused on the IT buyer and has missed the essential business buyer. GRC is a discipline and a solution set that spans the enterprise when fully realized, and requires cross functional cooperation and C-level visibility to be truly successful.

I happen to agree with Mr. Rasmussen’s well-informed pros and cons on this topic and also respect and find good value in the analyst firms I work with, including the highly regarded author of the Wave report and others. But like most good things, analyst opinions do need to be measured in the fullness of our own judgment, unique experiences, and those of our customers and stakeholders.

Check out Michael Rasmussen’s post at http://corp-integrity.blogspot.com/2009/07/forrester-grc-ripple-ooops-i-mean-wave.html