2011: The Year of the Certificate Authority Compromise

October 21st, 2011 - Posted by: Jeff Hudson

2011 is the year of the “CA compromise”. We have seen 5 compromises/attacks in the last year that have targeted third-party trust providers and/or have compromised the trust they provide to their customers. Stuxnet, Comodo, StartSSL, Diginotar and now DuQu.

DuQu, the so-called “Son of Stuxnet” malware, is a direct, high-priority wakeup call to IT security. According to current analysis of the virus, a rogue SSL certificate was again used to authenticate itself within the environment—to sign driver files—allowing the malware to act as a trusted application that could communicate with other systems and applications. This is the second reported incident of a digital certificate being deployed in this type of attack, and must be viewed as an ominous sign of things to come.

Organizations often don’t know where their digital certificates—commonly issued for securing communications, protecting sensitive data and/or for mutual authentication between devices—have been deployed and are in use. This represents a security vulnerability that is so obvious and at the same time so prevalent. Here’s a parallel analogy in the world of physical security: imagine a large bank that did not keep track of the people that came into the building….no one knew who was in the building, and if they were authorized to be there or not. This is an unacceptable situation to anyone who takes building security seriously. Allowing unknown and undiscovered certificates to be installed and exist in a closed IT environment represents unquantified risk. A failure to manage this kind of risk creates a big vulnerability.

Symantec and MacAfee have different opinions on the nature of the DuQu compromise. Symantec maintains that a private key was compromised. MacAfee reports that the CAs(Certificate Authority – one of which is VeriSign/Symantec) were the targets. In either case the mandate from DuQu, the fifth compromise of this class in a year is twofold:

Manage your keys across the enterprise
Be ready to swap out any certificate from any CA if there is a compromise of that CA

Manage your keys

Separation of duties is a well-known concept that forms the essence of managing private keys. You must establish policies and practices that separate access to private keys from access to public keys. Certificates use private and public keys, SSH keys control access to a large number of systems, and symmetric keys are used in many encryption schemes. You must know when the keys were issued, their strength, when last rotated, and who has accessed them. Further you must control access to the keys and have automatic reporting capabilities in place.

Be agile if there is a compromise

Most companies use a number of different Certificate Authoririties. The reasons most often cited by customers for using multiple CAs are 1) to have alternatives fostering competition which leads to lower costs and 2) to have multiple suppliers so that in case one is compromised, the compromised CA’s certificates can be swapped out for the alternative noncompromised CA. Further, the management of certificates must not be provided by any specific CA so that vendor lock in does not occur. Most CAs will offer a management solution which is by its very nature bias toward that CA. Use an open, vendor neutral management system. If you don’t your agility and separation of duties will not meet minimum acceptable best practices.

None of us knows where the next attack will occur or whether it will occur in a week or three months. But it will happen. If after 5 (6 if you count RSA) third-party trust provider compromises, you still believe that this is not a credible imminent threat, then you are in denial. Enterprises must ready themselves to respond immediately in the case of either a private key or CA compromise.