Re: NIPS Vendors explicit answer
From: Ron Gula (rgula_at_tenablesecurity.com)
Date: 04/27/04
- Previous message: Vikram Phatak: "Re: NIPS Vendors explicit answer"
- In reply to: Frank Knobbe: "Re: NIPS Vendors explicit answer"
- Next in thread: Drexx Laggui: "Re: IDSes and known attacks (was: NIPS Vendors explicit answer)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Tue, 27 Apr 2004 11:31:19 -0400 To: focus-ids@securityfocus.com
I disagree with several of the comments here ...
--------
Frank said:
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).
--------
I disagree that you know how your network is supposed to act. I find it
extremely difficult to predict the network actions of just a handful of
employees here at Tenable, and most of our enterprise customers with
10-50,000 users are surprised every day by new applications, new protocols
and new network behaviors.
---------------
Frank said:
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.
-----------------
The value to IDS (regardless if its ipAngle, RNA/Snort, NeVO/some other
IDS, ISS Scanner/RealSecure, .etc) is that when you get a correlated event,
you know you are more likely that the event is serious. You can also share
this event with a non-IDS network administrator. Its much easier to send
a well qualified event to a NOC operator than it is to send a generic
IDS event.
-------
Frank said:
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.
-------
Even in the simplest scenario, such as a single Apache web server, you
still get much more complex behavior. The web server probably does DNS
lookups. The web server needs to be maintained. Content needs to be
uploaded. Maybe even someone SSHes into the server and downloads a new
version of Apache. In a more complex scenario, something like an IIS
server may be configured to do virus updates, communicate with a database,
retrieve application hot-fixes from Microsoft, do backups, .etc. Multiply
this by 100s of web servers and 100s of administrators and you have some
unpredictable results.
I really think the traffic/connection anomaly technology is great for
finding worms, but does not do that well when finding something like
one remote user running Meta-Sploit successfully against a slightly
out of date Apache web server.
Ron Gula, CTO
Tenable Network Security
---------------------------------------------------------------------------
---------------------------------------------------------------------------
- Previous message: Vikram Phatak: "Re: NIPS Vendors explicit answer"
- In reply to: Frank Knobbe: "Re: NIPS Vendors explicit answer"
- Next in thread: Drexx Laggui: "Re: IDSes and known attacks (was: NIPS Vendors explicit answer)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
