Programmer in a Strange Land

I recently had a discussion with a co-worker regarding physical security. Our two departments share a small building with 9 offices. Each of us has a key to the building, a key to our own office, and a key to a shared storage room nearby. This co-worker was gathering feedback for a proposal he was putting together with the following goals:

• Reduce the number of keys we have to carry.
• Potentially provide access to both the building and the offices with a single key (for each employee).
• Increase access to resources by having more people able to gain access to more spaces.  (For example; getting a book from the office of a co-worker that is on vacation.)

During our conversation, my co-worker requested that I stop being so abstract in my arguments and address more factual, concrete ideas of what could (or might) actually happen. The more I thought about it in the days following our conversation, the more I realized:

This is a common mistake when thinking about security.

It’s natural to want to better understand the threat by thinking in terms of real threats that need to be protected against, but what security researchers now know is that doing so puts us at a significant disadvantage.  If we’re focusing only on concrete, defined scenarios we are limiting ourselves to what is known (or can be guessed). Are you sure you considered every scenario a potential attacker might possibly come up with? Did you take into account every possible new technology/standard/practice? How about every policy change your organization might implement? History has shown us that even if your security measures start out ahead, this approach 1) will eventually be compromised by something you didn’t think of, and 2) quickly becomes reactionary – where you find yourself implementing new security measures in response to new exploits as they are discovered.

Follow established Best Practices.

Rather than relying on a never-ending game of cat-and-mouse (where each side is constantly one-upping the other) modern security efforts attempt to follow established security practices that are known to provide protection by their very design – regardless of the type of attack that might be leveraged against them. With this recent discussion around physical security fresh in my mind, I thought I’d take a moment to talk about a couple of those best practices. This by no means an exhaustive list, and if you’d like to know more I highly recommend the podcast Security Now (which also has transcripts, if you’d rather read than listen).

Security In Depth

The phrase security in depth is a paraphrasing of the NSA‘s defense in depth approach and refers to having layers of security. Frequently, I hear people say things like; “We don’t need to encrypt account information because our servers are behind a firewall”. Relying on a single security measure means you have a single point of failure. If that mechanism ever fails or is compromised – and statistically, the chances are it will be at some point – then all bets are off. Similarly, new attacks could be developed which bypass the firewall by being completely valid network traffic.

Security in depth means wearing a belt and suspenders – if one fails, your pants still stay up. Classic medieval castles are another great example of security in depth:

1. A moat.
2. The wall.
3. Often, the streets inside a castle would be zig-zag so they wouldn’t provide a straight path to the palace at the center.
4. An inner wall.

Somebody, someday will break in eventually – so you want to make it as difficult and time-consuming as possible to get to the valuable stuff. In the case of our offices, this is accomplished by both the building and the offices having doors – each with their own key.

Now, you may be thinking (as my co-worker was) that having two keys for two doors won’t offer any more protection if a thief steals my entire keyring, leaving him with both keys. That’s absolutely a fair point. But recall that it only addresses one scenario where keys might be compromised. What if I’m in an accident, the keys from my ring are strewn across the road, and a bystander surreptitiously picks one of them up? What if I leave my keys sitting out somewhere and a potential attacker makes a quick imprint of one? What about the potential scenarios I haven’t even considered?

Furthermore, there’s the problem that that one key could (potentially) open all of the offices – which brings us to…

Compartmentalization

When things are separated from each other, each in their own compartment, we say that they are compartmentalized. In a security context this typically also means that each compartment is isolated from the others. The benefit here is that if one is compromised the attacker doesn’t automatically gain access to the others. In the building/office scenario above, this means

• A thief would only have access to the building and the office of the employee they stole the key(s) from.
• A disgruntled employee would only have access to their own office.
• The chances of a co-worker entering an office while the occupant is changing, or engaged in a private phone call are greatly minimized.

Certainly, we can scoff at some of these examples – say they’re extreme, not likely to happen, or that we can do other things to prevent them (like knocking on an office door before entering). But the point is; what of the scenarios we haven’t thought of? What about social engineering techniques that would never occur to us?

Modern security best practices shift the focus from trying to anticipate what kinds of attacks we might see to a more holistic approach that seeks to create an environment which naturally resists attacks.