A few years ago, a keynote speaker from the Navy shared some wisdom at the RSA conference. He mentioned that their engineers design ships with the assumption that water can leak past the hull. And sure, that seems obvious, right? It’s better to maintain a low level of trust and plan ahead for failure. If only everyone remembered to apply this philosophy.
I recently heard about several high speed CT teams that were instructed to use the Tor Browser for their offensive research. The training around it had offered it as an all-in-one solution for protecting their identity. Just open it up and you’re safe! Doesn’t that sound great?
But wait… what happens if something goes wrong? Perhaps like this, or this, or maybe this, to name just a few of the vulnerabilities that we know about. A leaked IP address for these teams could be bad, as in deadly-bad. Admittedly, some of these groups run Tor on top of their own anonymization infrastructure, but for the others, the lesson here remains.
While Tor (The Onion Router) gets its name for having a layered approach to security, its users often forget to use that same methodology. They trust that it will always work as intended to keep them safe, ignoring its history.
It’s worth mentioning that the problem here isn’t with Tor specifically. To their credit, the Tor development team is better than most software providers when it comes to addressing known security flaws. The larger issue comes in the belief that any single solution is fail-proof, especially when it comes to your OPSEC. There should always be an assumption that components can fail, followed by a plan to address that concern.
Whether you call it contingency planning or redundancy, this idea is pretty simple. Two is one and one is none. The real world often operates by Murphy’s law, and it’s better to prepare for likely points of failure than to be blindsided by catastrophe.