Certificates exactly like the ones compromised as part of the Flame malware, are used everywhere in organizations worldwide today and are vulnerable to the exact same compromise. If organizations do not have an automated certificate management system in place, the likelihood of a catastrophic event is very high. Also, when the event occurs, recovery and remediation will take a very long time. Just like you need to manage and keep software up to date, you need to do the same thing with certificates.
We have seen a steady stream of third-party trust providers and the instruments they provide being compromised for nefarious purposes; RSA, Comodo, StartSSL, DigiNotar, Verisign, and now with FLAME, Microsoft. Major takeaways, NO ONE is too big to be compromised. If you hear someone talk about how they know what they are doing and have taken precautions so that they won’t be compromised, run the other way. They are in denial or worse. These trust providers are very high value targets and the compromises will continue. I chuckle when I think back on how so many said that the RSA compromise was an isolated incident.
Weaponized malware (remember when that terms was first used to describe Stuxnet?) is a trend, a progression, a continuing fact of life. Stuxnet, DUQU, and now FLAME. This is not the end, it is the beginning. It was called “weaponized” because it translated to physical damage and / or because it was apparently (95% confidence) developed by nation state(s) to engage in cyber warfare. The interesting thing about nation-state developed weapons is that once developed and deployed, they find their way into the hands of non-nation state actors. Night vision goggles, shoulder launched surface to air missiles, and Kevlar vests, for example, were developed by nation states for military use and are now in the hands of criminals and worse. The attack vectors brought to you by weaponized malware are, with certainty, going to be employed by criminals to steal money, intellectual property, and anything else of value.
What can be done to reduce susceptibility to these attacks and to remediate once the attack has occurred? A long time ago CIOs, among others, questioned the need to diligently detect down-rev and unpatched software and the importance of keeping the software at the latest revisions. This is now a well-known best practice that reduces vulnerability to many kinds of attacks.
The same diligence is required to make sure that down-rev and nonconforming-to-policy certificates are detected and updated to the latest levels. From the many conversations I have with CIOs and CISOs in the industry, their understanding of this issue and their commitment to actually fixing this problem is similar to their thinking on software updates and patches a long time ago. The attitude can be characterized as poor understanding, non committal to act, ambivalence, and from one perspective, dereliction of an important duty.
We work hard to educate organizations about their vulnerabilities. Once this particular vulnerability (ie, poorly managed certificates) is understood, it is easily addressed.
This is not a problem that anyone is going to fix for you. Microsoft just patched a majority of their software products to remove the compromised intermediate root certificates. If this was a cross-platform attack/compromise, who does the patching and updating? You do. Certificates are a cross-platform, cross-application, cross-device instrument. You must keep track of where they are installed and make sure that if there is a compromise, you can act fast. One of our customers has approximately 10,000 certificates in numerous locations (Interestingly, they thought they had about one half that number before we started the project). Before they installed an automatic certificate management system it would have taken them many months to replace the certs if there was a compromise. Now with automated certificate management the replacement can be performed in hours.
I often wonder why something so fundamental as knowing which certificates are active on the network, understanding the attributes, and managing the keys associated with the certificates is not a top priority, especially when managing these instruments radically reduces the vulnerability. This isn’t hypothetical, the compromise and threat has happened time and again. Maybe because managing things like certificates isn’t nearly as sexy as having the latest APT detection and amazing firewalls?