According to a recent Venafi survey, 65% of organizations rely on tools developed by their certificate authorities (CAs) to maintain a minimum standard of security for their keys and certificates. At first glance, this appears to be a smart enough strategy. But this approach quite simply isn’t workable when you’re managing certificates from more than one CA (and almost every large organization does). The failings of this strategy are even more apparent when you’re facing a situation where you need to move certificates from one CA to another.
It goes without saying that you’ve chosen your CAs carefully. After all, their security is your security. But certain events may require you to change CAs, often at a moment’s notice. Even the best CAs can fall victim to human error, invalidating certificates that you may be using. Recent events at Symantec and GlobalSign demonstrate the impact of CA errors. Worse still is a compromise, or even willful disregard for protocols, such as the problems recently detected at WoSign. Or you may find that new CAs have been introduced into your environment without your knowledge or approval.
To ensure the security of your encryption assets, you’ll need the agility to move certificates quickly from one CA to another. Let’s say your CA is compromised by a cyber attack and your certificates from that CA move to an untrusted state. First, you have to be able to locate all impacted certificates. You’ll then need to reissue certificates from another CA. Which CA’s management console will you use to complete this arduous task? Can you expect any CA to provide functionality that helps you move certificates to a competing CA?
Granted, a compromise is probably the worst-case scenario for switching CAs. However, there may be other cases which are less dramatic, but are still as important to address. Let’s say the employees at your CA make an (all too human) mistake such as mis-coding a batch of certificates or accidentally revoking a root certificate. You’re basically left in the same situation; you experience a service outage. You can wait for the CA or browser to resolve the problem which could take weeks or months (see what happened when a Chrome bug affected Symantec certificates), or you could quickly solve the problem yourself by finding and replacing any certificates that were affected.
The impulse to change CAs may also come from inside your organization. Security policies may mandate that you consolidate the number of CAs in your organization to reduce your trust exposure. Or they may dictate that certificates for certain high-value functions, such as global financial transactions, adhere to stricter security attributes that are only available from a particular CA; while those that support lesser functions may be acquired from a less expensive source.
You may also wish to reduce the complexity of your encryption environment to enable tighter control or better operational efficiency. In the process of discovering which certificates you need to migrate, you may discover certificates from a branch or department within your company that originate from a CA you didn’t know your organization was using. These certificates are prime candidates for standardizing with a CA that has been approved by your organization.
The bottom line is that there are many motivations for changing CAs and you need to be prepared to make these changes quickly if the situation requires it. To keep your fingers on the pulse of your encryption environment, you’ll need the agility to dial up or dial down your CA exposure in response to external and internal demands. This agility will also help you fine tune your strategic use of CAs to better meet your business goals
Are you prepared to move quickly if you need to change, add or remove certificate authorities? In the next blog in the CA agility series, we’ll look at the reasons why you need tighter control of your CA environment.