The recent incidents with the Heartbleed OpenSSL vulnerability, along with the strange turn of events involving TrueCrypt shine a light on a big issue for security practitioners. Both of these situations rattled our confidence in specific technologies, but the implications are much broader.
In hindsight, a lot of the specifics for Heartbleed and TrueCrypt sound like risky behavior. Let’s take TrueCrypt for example – many organizations and individuals were relying on a product they weren’t paying for, had no SLA’s in place to maintain, had no vendor contract to fall back on, and which was developed by unknown, anonymous developers. That feels like risky or naïve behavior when you think about it, but it happens all the time.
As a result of the tendency toward blind trust in technology, a lot of organizations I’ve spoken with were left scrambling to figure out how to respond once their trust in TrueCrypt was shaken. Most of them had no readily available “plan B”.
What can we learn from these events? Here are some activities to consider:
1. Identify the elements of your technology and service stack(s) upon which you rely, and determine their relative importance. This includes looking not only at applications and modules like OpenSSL, but also scrutinizing third-party services, data processors, and even service providers and their personnel. In other words, determine the “must haves” for delivering your business’s core capabilities, and then ask yourself how painful would it be if they were to disappear or become untrusted over night?
I often use what I call “the magic wand test” for this: if I waved a magic wand and a specific [element, component, provider, etc.] ceased to exist, how much would it hurt and what would you need to do to fix it?
2. Determine the basis for your trust in each component. Think about each of the elements you identified in the first step – what gives you confidence or assurance that they are reliable, maintainable, and secure? Have you done your own testing? Are there any third-party evaluations you can turn to that will increase your confidence? If you identified an element as “vital” in the first step, you might consider pushing for more tangible and comprehensive data.
For example, just before the discontinuation of TrueCrypt, an independent effort to audit its source code had already begun, and the word on the street is that the audit will continue. That means that once the audit is completed we’ll have credible third party evidence about the appropriate level of trust for the last version of TrueCrypt. Of course it should be mentioned that TrueCrypt’s source was publicly available, but that is not the same as an Open Source license, and the developers haven’t turned the source code over to the Open Source community yet.
3. Identify viable alternatives for each of the key elements in your business’ core technology and service stack. If one of your technologies or providers were to disappear for some reason, or you determined that there was too much risk to your business to continue using them, how would you recover? What alternatives exist for you that could be swapped out for a specific component. Could you switch to a new provider?
This is an area where a standards-based approach can help, if one is available. Theoretically, you should be able to move to another provider that supports the same standards as your original provider. Remember, standards can apply to interfaces, data formats, reporting criteria, and other aspects of a service.
4. Pursue protective measures to reduce your risk. If one of your providers became untrusted overnight, how would you get your data out of a service, for example? If there are no viable alternatives for a product or it’s too deeply embedded in your business process to replace, do you have a source code escrow provision in your contract so you can get access to the source code if the provider fails? Do you even have a contract with the provider? Do you have backups of your data?
The bottom line is you’ll benefit from a deliberate examination of how much you rely on a particular element of your service delivery stack, determining the risk in losing a portion of that stack or suddenly finding you can’t trust it, and identifying the measures you can take to reduce these specific risks. After all, someone else’s bad day shouldn’t wreck your business.