It's always when you least expect it and when you least need it. That accident waiting to happen. Friday evening after a long week, and you're heading home for a relaxing weekend. Suddenly a truck comes out of nowhere on the motorway and the next thing you know you're standing at the side of the road, your 'pride and joy' looking rather dejected and you standing next to it as a million motorists slow down to view the latest car wreck and thank their lucky stars it wasn't them. I've been one of them on many an occasion but I guess every one of us is just a moment away from that accident waiting to happen.
And life is like that, especially in IT security. Weekly we read about breaches, failures, increased snooping and you'd think we'd learn but generally we seem to think it's always the other guy who gets it, and one of the areas which seem to generate the greatest risk is - the expired certificate.
In cryptography, a public key certificate (also known as a digital certificate or identity certificate) is an electronic document that uses a digital signature to bind together a public key with an identity -- information such as the name of a person or an organization, their address, and so on ...
Digital certificates are used to establish and validate an identity on the Internet. Digital certificates, issued and managed CA's (certificate authorities), can address a number of security concerns. For example, they can verify the identity and privileges of an individual, a server, an application, a device, a database, an organization on the Internet, provide non-repudiation and authorise transactions such as payments. Most of us seem blissfully unaware that they're there. But the reality is that today there are hundreds and in many cases thousands of them distributed throughout our infrastructures. Our VPN concentrators use them for authentication, load balancers use them to secure connections, and virtually every application to application process uses them to ensure authentication and secure communication. And all it takes is just one failure or expiry, and bang goes your weekend.
What You Don't Know Can Hurt You
The problem with accidents is that you could always avoid them if you knew when and where they would happen. Had I somehow been able to have an early warning that a certain truck with a certain registration was going to change lanes at the exact moment I had passed him, then I could have taken preventative measures. And the same goes with certificates.
If you knew ahead of time where the certificates were and when they would expire, and who was responsible for them, you'd be able to take pre-emptive action. The problem is that most organizations simply do not know. If you happen to use certificates signed by a trusted third party (TTP), they will notify you when renewal is due-after all, you're paying for them year on year.
But then there are the certificates that have been created using your own Certificate Authority (CA), which are usually managed using a spreadsheet or some other archaic method. And then there's the nightmare 'self signed' certificates, which have been created on some application or device with no need to get any external validation.
Regardless of who or what is supplying your certificates, none of these systems by themselves are going to take care of the actual task of renewing the certificate on the actual application and device. It wouldn't have done me much good if I hadn't taken action six months ago to renew my insurance when I received the letter reminding me that a renewal was required! Fortunately, my valid insurance document was sitting in the 'glove box!'
An expiry, or failure, of any of these certificates will always lead to chaotic finger pointing throughout the organization, with everybody blaming somebody and nobody taking responsibility. Just imagine if I'd had to face my wife with the news that not only had my car been mugged but that I'd also forgot to renew the insurance. That would be tame compared to the hysterical reaction you get when a certificate brings a trading floor to a grinding halt in the middle of the afternoon, or causes the production line of a global manufacturer to stop working for eight hours!
Crisis Management Is Not Making It Up as You Go Along
When my truck driver 'friend' stepped down from his magnificent 'chariot,' I quickly discovered he didn't speak my first, second or third language-not that I really understand my own third language - but fortunately having a mobile phone with the police emergency numbers, and the 'what happens when you hit a truck in a foreign country' number from my insurance company, it was relatively simple to set procedures in motion.
Most organizations I meet with are not able to tell you who owns or is responsible for certificates on systems and applications. There is no verification process to check if certificates are installed correctly, and in the event of a crisis, everyone suddenly looks at the Infosec group and expects them to simply fix it.
Counting the Cost
Ultimately, my altercation has come with a price, whether it's the neighbor who seems intent on telling the whole street that I have a damaged car as if in some way I've just been responsible for a 50 percent drop in the value of the properties around me, the loss of productivity from having to spend a day chasing insurance companies and getting repair estimates, and just the sheer inconvenience of having to remove a lifetime's personal belongings from my car before sending it off to be repaired.
So loss of productivity, dented ego, and financial loss all because I was in the wrong place at the right time. Of course, you console yourself with the thought that it could have been worse, and sure in many cases things are just simply unavoidable, but when it comes to your certificates there is no reason why an accident should happen.
Get Some Insurance!
The first step in managing encryption is to determine where keys and encryption certificates are deployed within the enterprise environment, and assess where imminent risks exist, such as which systems are using weak key strengths, which certificates and keys are about to expire, where rogue certificate authorities are in use, etc. Five simple questions:
What has actually been deployed, and on how many systems?
Which certificates are still in use?
Certificates that have been issued by any all CAs?
Status of root and intermediary roots are in use on those systems?
Whether or not those certificates are within policy?
And if you don't know the answers to this list of questions, then that 'truck' may just be around the next bend!