Tuesday, March 20, 2007

Proactive vs Reactive Security

Whenever I hear someone talk about the merits of "proactive" security vs "reactive" security I will politely nod, but you may notice a tightening of my jaw. I can't stand these sorts of comparisons. When I hear people praise proactive measures they're usually talking about "stopping attacks" rather than "watching them." Since a good portion of my technical life is spent cleaning up the messes left by people who put faith in preventing intrusions, I am a little jaded. Before I go any further, believe me, I would much rather not have intrusions occur at all. I would much rather prevent than detect and respond to intrusions. The fact of the matter is that intrusions still happen and that proactive measures aren't always that great. In fact, sometimes so-called proactive measures are worse than reactive or passive ones. How can that be?

Kelly Jackson Higgins' latest article Grab Fingerprint, Then Attack provides an example. She writes the following:

First you determine if an IDS/IPS is sitting at the perimeter, and then "fingerprint" it to find out the brand of the device, says the hacker also known as Mark Loveless, security architect for Vernier Networks. By probing the devices, "You can extrapolate what brand of IPS is blocking them and use that to plan your attack."

Different IDS/IPS products block different threats, so an attacker can use those characteristics to gather enough intelligence to pinpoint the brand name, he says. And it's not hard to distinguish an IDS from an IPS: If you can access XYZ before the attack, but not after, it's an IPS. And if there are delays in blocking your traffic, it could be an admin reading the IDS logs, Loveless says.


This concept is as old as dirt, dating all the way back to fingerprinting firewalls. However, it illustrates my point very well. A "proactive" device like an IPS would block traffic it deems malicious. An intruder smart enough to want to identify and evade said IPS could do so using test traffic, then launch an attack that sails through the IPS -- which at that point is ignorant and ineffective. The only reason the intruder could accomplish this task is that the "proactive" nature of the IPS revealed its operation, thereby providing intelligence to the intruder. In aggregate security has been degraded by a "proactive" device.

Contrast that scenario with that of the lowly, "reactive," passive network forensics appliance. All it does is record what it sees. It doesn't stop anything. It's so quiet no one knows it is there -- including the intruder. Of course it isn't blocking anything, but it is providing Network Security Monitoring data. Properly configured and used it can act as a sort of intrusion detection system as well. In aggregate security has been improved by a "reactive" or passive device.

I hope this post has challenged the convention wisdom in the same way that my diatribes against mandatory anti-virus installation may have done. I think one way to overcome the problems caused by the active device is to complement it with the passive one, but most organizations emphasize "prevention" over all else and discard detection and response.

5 comments:

Rudy said...

I'm a bit confused by your definition of "proactive". In your example you use an IPS as an example. I think this would still qualify as a reactive solution. It is responding to some external stimulus. I think classically a proactive solution is some sort of technical or procedural control that is put in place prior to an event occuring and is also not dependent in anyway upon such an event occuring. By this definition, if we agree, an IPS is clearly outside the bounds. While I agree that proactive solutions are not the panacea, understanding what they are and what their limits are goes a long way towards effective prevention. The reactive solutions are there when those proactive controls cannot effectively mitigate the remaining risk. Without question many times these controls are poorly implemented. In most cases I would argue that people misunderstood what "prevention" meant. To make a better case in your reactive versus proactive argument it might be prudent to define your terms in a non-ostensive way. Right now I would still favor "real" preventative controls and use reactive controls to mitigate and deal with the remaining and unknown risk. Being clear on how much risk preventative controls mitigate should be the first course of action for determining if what you've implmented is effective or a complete waste of money. Sadly, this rarely gets done.

roodee
http://www.thummy.com/roodee

Joe said...

when i think of proactive security, i think of designing something in a secure way, not bolting on security after the fact, when you/others find flaws and bugs in the design. good read nonetheless.

Richard Bejtlich said...

Rudy and Joe,

Those are good comments. I am approaching the issue from the operational point of view where I hear security folks try to address protecting assets once they are fielded or about to be fielded. Secure software design (if any) is in the past at that point.

PaulM said...

Richard,

While you make an excellent point, if all it takes to hack your Internet-facing server is evading an IPS with fragmentation or Unicode tricks, then you've already lost. Using an IDS instead of an IPS wouldn't make your server any less owned.

So the judgment call that companies have to make is do we put in place something to A) block known and probably automated attacks or B) record everything for purposes of forensic investigation. I think the answer is you do both.

Rob Lewis said...

I agree with Rudy and Joe in their definition of proactive.

I think most of the following conditions (and maybe more) would be necessary for true proactive security:

The system would have to be mathematically complete and closed;

The system would have to be default-deny;

Ideally the system would be user-centric inside the network to make management of data flows intuitive for the purpose of determining proper security policies;

The system would govern data access and audit at the data level, working from a white list;

The system would be able to govern the actions of even the administrators and CSO, and other C level execs;

In order to to that the system would have to offer tamper-proof auditing, and be able to separate root user from system;

The system would require the ability to compartmentalize any application or function;

The system would have to be able to check its own integity, and have a failsafe mechanism in order to ensure that if operators are compromised, the system is not. For example, if the logging function is turned off, the system will not allow access to data.

Any technology that deals with detection and remediation is not proactive.