Re: NIPS Vendors explicit answer

[Frank Knobbe <frank () knobbe us>]

Greetings,

I'm gonna resist to quote a lot of what Vik said (mainly product
description) and cut to the chase. I do want to highlight this quote: 

On Fri, 2004-04-23 at 16:36, Vikram Phatak wrote:
> As with firewalls, we believe IPS needs to be more black and white
> regarding the approach taken.  While much of the work being done
> regarding anomalous behavior is cool, it is not practical unless it
> can be used in the "real world" to prevent attacks.  Believing that
> traffic is harmful and knowing it is harmful are two different things.

If you confine your thinking to statistical anomaly detection, then this
may be correct. However, behavioral anomalies can be safely detected and
used to prevent attacks. After all, you know how your network is
supposed to act and can (by cleverly crafting custom rules) detect any
"fishy" activity that should be prevented (or never happen in the first
place).

ipAngel places a great deal of emphasis on correlation of
vulnerabilities to IDS alerts. While I wish you well in this endeavor, I
do question the approach. I'm not harping on ipAngel in particular since
the same applies to other vendors as well. It remains to be seen how
much value that approach actually adds to intrusion Detection.

In my opinion, you are restraining your IDS rules to certain
vulnerabilities for certain systems. This is okay for reducing false
positive, but imho it should not be a driving factor when developing
your IDS rules. After all, if you know what your are vulnerable to, why
not act and remedy the vulnerability? If you know what set of possible
vulnerabilities might apply to you (for example, running IIS), then
sure, use that info to tune the IDS and reduce FP's. But don't just
focus on those vulnerabilities.

IDSes are Intrusion Detection Systems. Why do we need to detect
something that we know exists? In my opinion we should focus our efforts
on detecting the *unknown* events, not the known ones. I argue that you
are looking the wrong way :) 
Statistical anomaly detection is one attempt to do that (and I agree, it
may not be the most foolproof method, but it does provides value as an
added layer). 

Another method of detecting these unknown events is that of (what I
call) descriptive behavioral anomaly detection. Using this approach you
first describe traffic patterns that are normal and expected. You then
get alerted when abnormal traffic patterns are detected.

The simplest example I can condense this to is a single web server. Why
let the IDS run a VA scan to determine of it's patched or not instead of
you applying the patch? While it's fine to determine the system type so
that IDS rules can be tuned, beyond that I don't see much added value.
However, behavioral anomaly detection will. You would expect only
incoming web requests to that web server. If you define that traffic
patterns such that you will be alerted on other traffic, for example the
web server establishing an outbound FTP session or tunnel or shell, you
can safely detect this event and give your IDS much more value.

At Praemunio, we do Intrusion Prevention differently than most other
shops. I'm not gonna toot my horn here, but suffice to say that we use
the behavioral approach combined with Intrusion Prevention, and I can
tell you that it is working extremely well.

I believe there is a market for vendors (like Sourcefire) to come up
with tools to ease the pain in identifying your network and subsequently
crafting customized rules for it (if that is indeed what Sourcefire's
RNA does... Marty, please elaborate if I'm off track here). Instead of 
focusing on vulnerabilities, we should focus on devices/assets, which
traffic flows are normal and which are not, and engage the IDS with
knowledge of the good, known behavior (and have it alert on the bad)
instead of focusing on bad behavior (and ignoring the good).


Regards,
Frank

Attachment: signature.asc
Description: This is a digitally signed message part