Re: FW appliance comparison - Seeking input for the forum

[Devdas Bhagat <devdas () dvb homelinux org>]

On 23/01/06 18:30 -0500, Paul D. Robertson wrote:
> 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.  
>
> ;)
<chorus> BOO! </chorus>

> > 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.
I suspect that my terminology has gotten disconnected with the marketing
driven real world again.

To me an IDS is not necessarily something that listens on the network
only. Stuff that looks at the integrity of files on hosts, stuff that
monitors and analyzes logs is part of the IDS too. The IDS is not a
simple, single application, but a set of applications which work
together to show the differences between operational and ideal
implementations.

A NIDS, or a HIDS is a part of the above, but is definitely not sufficient
by itself.

> > > 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 

Violation of operational controls does need to be detected. Poor policy
implementations need to be detected as well.

> 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.
I really don't care about specific signatures. Port 22 scans originating
from a host in my internal network to other hosts within my network? I
sure am interested in learning what failed, and why. This then serves as
input for fixing the process so that the failure does not happen next
time.

> > 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.
And my IDS need not sniff on the wire. A simple Perl script which tail
-f 's the firewall logs and alerts on seeing a hit on the outbound port
25 logging rule is good too.

> 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.

If you do it right, you should never ever know that it exists.

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