This approach to security is fundamentally broken.

As an industry, we've been playing the chase-the-vulnerability game for 15 years now. And you know what, the game hasn't really changed. The trigger events are the same now as they were when the Morris worm tore through the net (vulnerability announcement, exploit release, and patch release). In 15 years we haven't been able to move a single one of these key events under our control. Instead, we have functionally zero control over the primary security trigger events.

It is time to actually focus on techniques that are able to keep systems secure in-spite of the no doubt vulnerable software those systems run. As long as humans are designing, writing, or installing software, there will be software vulnerabilities. The current practice of making system security dependent on zero vulnerabilities is naive.

When a vulnerability in a program is exploited, the behavior of the exploited program changes. That's the point of the exploit. This is a detectable event, if you are looking for it. Programs also tend have access to sensitive files that they don't actually use (thanks to their user or group ID) -- when they access those files, you should know about it. Ideally, attempted access to those files should fail. If you can respond immediately to exploits and keep programs from touching files that they shouldn't, what is the security relevance of the vulnerabilities in an application? Sure, the vulnerabilities introduce reliability problems, but the reliability downside is small enough relative to security that it's basically been ignored in the past. (Of course named dies when it execs into a shell -- that shell tends to be more important than the fact that named isn't answering queries anymore.)


The natural objection to this approach is that the behavior of your applications changes for a variety of reasons other than attackers. Stop and ask yourself if the legitimate events that cause the behavior of your programs to change are within your organization's control. Most likely, they are: you know when you are going to deploy new software, upgrade software, roll out a new service, extend a service, or instruct your users use your service in a new way. If you aren't aware of these events, most likely somebody in your organization is. Hopefully you will have more success with internal communication than you will getting hackers to tell you in advance of their latest exploit development efforts. I would be willing to bet you can apply more pressure to them than you can on your vendor to hurry up with the patch -- oh and make sure to test it too.

In this approach, the key security events are within your control. This is a game you can win.

These approaches work best for server programs. They may not be entirely applicable to security breaches on the desktop. Even so, getting your server security out of the chase-the-vulnerability cycle seems like a pretty decent step forward.

Scott Wimer, CTO
Cylant
www.cylant.com
scottw@cylant.com


[ reply ]

Link to this comment: http://www.securityfocus.com/comments/columns/74/11902#11902