Wednesday, February 21, 2007

Security Assumptions

When doing security analysis and architecture its often good to start with first principles. Sometimes they are design principles, sometimes they are process/procedure principles.

Sometimes its the unspoken assumptions that we rely upon that get us in a lot of trouble. We start to take old attacks for granted, assuming they have been removed, mitigated, etc.

For example, Sun recently had a vulnerability in the telnet implementation that we haven't seen since the mid 1990's. It was a relatively simple vulnerability that we all assumed would never surface again and yet it did. I haven't heard of any disastrous effects, but it sure was scary knowing that sort of vulnerability could creep in 10 years after it was originally discovered or widely known and fixed.

Step back for a second though and its clear that the old saying about those who don't remember history are doomed to repeat it does tend to ring true. The number of simple exploits we find out there that get repeated again and again in every new application, operating system, networking device, etc.

So when I sat down the other day to start working on a network architecture I asked:

  • What threats am I really trying to protect against
  • What threats am I willing to skip on
  • What are the assumptions I'm making about the inherent security of my building blocks for the network, etc.
Do I have to remember every single network based attack and make sure I've specifically designed against it? Things like Syn floods, weird packets such as smurf, ping-of-death, etc? Do I have to worry about spoofing on my network?

How do I condense these types on concerns into concrete first principles and designs that eliminate these vulnerabilities from the network or applications themselves? We have all of those tools available to us, and we have all of those design principles, we just forget to use them 99% of the time when we do architecture and design work.

  • Least Privilege
    • Only let systems connect that need to
  • Simplicity
    • Make networks, firewalls, etc. easy to manage.
  • Automation
    • Get humans out of the equation
Its funny how many of the common vulnerabilities we come across again and again that can be mitigated by some of these relatively simply concepts properly applied. Things like turning off unnecessary services.....

I'm not sure what the point of this piece is except that sometimes its good to surface your assumptions about the world, the security context in which you live, etc. Things like:
  • When I call the police they will generally respond to an incident and not demand a bribe to help me (in most of the US anyway.)
  • Most people can't be corrupted for trivial amounts of money so we can rely on dual-control systems for all but the highest value assets.
  • Most people are honest/good. They have a basic respect for the rule of law, ethics, etc.
Its these assumptions though that underlie most of our psychology about security. Our feelings of safety, etc.

I had to do a threat analysis for a third-world country and it was an interesting exercise in questioning which of my security assumptions I was making at any given time, and whether they were valid. You can look at certain parts of the world and throw out the last group of assumptions I just listed. What is striking to western sensibilities is that these are places where if nothing else the western system of common law isn't quite so entrenched. Property rights are a bit more "fluid." Intellectual property isn't respected. Bribery and corruption are commonplace. How to protect yourself in these sorts of environments is quite a challenge, especially if you actually do subscribe to the assumptions above.....

Not sure what the point of this is except to say that sometimes its good to write down the underlying assumptions you use to make decisions, to evaluate the world, and try to evaluate how true they really are.

1 comment:

Peter said...

In the case of this Solaris vulnerability, I suspect that there have been black hats who have known about and have been using that vulnerability for a while. Assuming that the good guys generally find the vulnerablities first is probably a not a good assumption.

Sadly, unless you are a some kind of kung-fu code auditor with a lot of time on your hands, I suspect you're in the same boat I'm in: you follow the advisories and patch or otherwise mitigate as soon as practical.

In short, you hope your vendor hasn't screwed up and re-added a "classic" vulnerability.

How can be sure that old vulnerabilities haven't slipped back in? We can't; I'm left to hope that our auditing tools are more thorough than our OS vendors :-)

And of course, you are right that we need to remember our principles. This old telnet vulnerability isn't conceptually much different than a new one. It's never unsafe to assume that every service has an exploitable vulnerability.