Security: The Art of Compromise

“Security is all about protecting the user.” That’s the comment that came up the other week in the twittersphere that kicked off a not-unexpected trail of pro and con tweets.

Being limited to 140 characters makes it rather difficult to have a deep and meaningful discussion on the topic and the micro-blogging apparatus isn’t particularly conducive to the communicating the nuances of a more detailed thought. So I thought I’d address the topic here in blog format instead.

I suppose my first thought is that Internet security isn’t necessarily about protecting the user, in fact I’d go as far as saying that modern security approaches increasingly assume that the user themselves is the threat. In the most optimistic case security is about protecting assets (digital or physical) from harm or theft. Failing that, Internet security is about detecting change to assets that were deemed to merit protection.

As a community we tend to over use safety analogies when we’re trying to communicate the significance of a threat and the value of protection – which is why I believe there’s a prevailing assumption that Internet security is about protecting the user. For example, I’ve often heard (and abused it myself) the car analogy for putting defense in depth in to perspective – i.e. airbags, safety belts, crumple zones, etc. being metaphors for anti-virus, IDS and firewalls.

I think a more appropriate analogy for modern Internet security practices is that of protecting a bicycle. The cyclist is the user, and by protecting the bike itself we’re not actually doing much for the safety of the rider. In fact I’ll argue that over-protecting the bike may end up decreasing the safety of the cyclist – as we too often see in the cyber world (e.g. the lock’s so big & heavy that it affects the cyclists ability to actually ride the bike). By way of problem statement, we can consider the cyclist as a consumer of the technology (i.e. the bicycle) and, for him to be able to ride, he needs to ensure that his bike hasn’t been stolen or damaged.

When it comes to “protecting” the bike, there are a number of factors the would-be cyclist needs to take into account. Likely the most important concern is going to be how to lock-up the bike when not in use – especially when away from home. The most obvious solution is to purchase a dedicated bicycle lock.

Now this is where I think the analogy works better than most for the Internet security world… what are some of the deliberations the cyclist must make in selecting an appropriate protection solution?

• How big a lock do I need? A small lock can be trivially overcome, but is light and easy to carry on longer rides. A big heavy lock will likely be much harder to overcome, but is going to be troublesome to carry.
• How long a chain? A short chain is easier to carry. Meanwhile a longer chain offers me the flexibility to also lock up the wheels and wrap around bigger objects.
• How much do I want to spend? Some top-quality locks are almost as expensive as the bicycle they’re destined to protect. Meanwhile a more expensive lock may be lighter and more proficient at keeping thieves away.

Deciding upon a protection solution is a practice in compromise – comparing the risk likelihood with the inhibitors of the proposed solution. There’s also awareness that no matter how big and badass the lock may be, there’ll always be someone out there with more powerful bolt-cutters or a more imaginative way of subverting the lock. It may be a compromise, but hopefully it is an informed decision. The cyclist opts for a solution, forks out the money, and lives with the decision. If all goes to plan, their bicycle will be present the next time they go to use it.

The same applies to the Internet security world. You can’t protect against all the threats and, even if you could, you’d likely end up making the system you’re trying to protect unusable for the folks that need to use it.

But “protection” is only one side of the security coin. “Detection” is a critical element of modern security. Some may argue that detection is something you aim to do if you can’t protect. I’d have to politely disagree.

Locking up your bike is a realistic security solution if you’re looking to protect it – but ensuring that your bike is locked up somewhere highly visible (good lighting, etc.) and located where a potential thief is likely to be noticed by the cyclist and other passerby’s is a critical “detection” component. The threat of detection becomes part of the security strategy. Even if that deterrent fails, and the protection was also insufficient, the sooner the cyclist knows whether their bicycle has been stolen or tampered with, the quicker they can respond to the threat and take the corresponding actions.

Detection within the Internet security realm is as important as protection. For the last decade or so the emphasis upon security has been protection – despite acknowledging the limits of the compromise situations and product vulnerabilities. Knowing precisely when an asset has become the focus of a would-be thief or eventually succumbing to the threat is critical in how an organization must respond to the incident.
As anyone who has had a bike stolen will tell you, the quicker you notice it’s gone, the higher the probability you have of getting it back.