Re: FW appliance comparison - Seeking input for the forum

["Paul D. Robertson" <paul () compuwar net>]

On Sun, 22 Jan 2006, Devdas Bhagat wrote:

> Isn't auditing against a policy exactly what an IDS is supposed to do?

Not that I've ever seen.  Everything I've seen says they look for 
known-bad-stuff and produce alerts and false positives.  

;)

> It also verifies that your security policy has been implemented
> correctly at the firewall(s).

As I said, in an ideal world, sure- however I've yet to see an IDS that 
really and truly knows how to even express policy, let alone check against 
it (unless your policy is "no bad stuff the IDS can find!")  Heck, I've 
yet to see real policy<->firewall rule mapping done in an effective way 
without a human.

> > Again, this assumes that your policy implementation allows attacks to 
> > traverse your infrastructure *or* that you're wasting the organization's 
> > time passing around reports about how many times NIMDA tried to attack 
> > your Solaris box.  
> Things change. IDS help detect unexpected changes. Again, IMHO, an IDS

Really?  Care to elaborate on some unexpected changes IDS's routinely 
detect that aren't a matter of poor policy implementation or poor 
operational controls?  Just like AV, I can see a small just-after-zero-day 
window where you could trumpet them- but like AV it's about twice a year 
and IMNSHO not worth the effort of upkeep compared to working on things 
that will change your vulnerability surface...

> also has a host based component which looks at (ab)normal statistics for
> host traffic. A sudden increase in traffic or decrease can be
> interesting events.

Sure, they can be interesting, but normally (at least in my experience) 
they're due to a failure in process that needs fixing a lot more than IDS 
signatures need updating.

> For instance, seeing traffic destined to port 25 from an unexpected host
> is a good event to trigger IDS events. Even when your firewall blocks
> this traffic, the log analysis of firewall logs and DHCP logs should
> catch potential malicious traffic and possible further investigation.

If you mean "unexpected internal host" then again, I'll say that there's 
likey been a larger policy or implementation failure.  It doesn't take 
on-the-wire sniffing to see something new trying to relay through the 
relay host on my network.

If you mean "unexpected external host" then I've yet to see an IDS that 
knows the difference between "new business" and "one-off social 
engineering attack."

> This was discussed in a thread on the loganalysis mailing list by MJR.
>
> > This is one reason why people with sub-standard security don't get fired 
> > when there's an event they clearly should have created "the IDS signature 
> > didn't detect it" is becomming a bail-out when people really aren't 
> > implementing good security policies.
> Which is _not_ the fault of the tools. Done right, a good firewall and
> IDS combination should not need to be updated very often.

That's certainly a different line than most IDS vendors or IDS proponents 
use.  Normally I see "the new IDS signature can detect that!" bandied 
about.

To me, IDS is like a left-handed screwdriver, you can send someone around 
and waste their time with it, but when it comes to fixing something, it's 
not there.  If you need IDS, it's because of a failure elsewhere, and if 
you're done everything right, the value is negligable.

[PE]Don't believe the hype.[/PE]

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
paul () compuwar net       which may have no basis whatsoever in fact."
http://fora.compuwar.net      Infosec discussion boards 

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards