|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: Greg Shipley (gshipley
neohapsis.com)Date: Tue Mar 05 2002 - 15:40:15 CST
On Tue, 5 Mar 2002, Alfred Huger wrote:
> It seems of late that the comparison is being used heavily as a
> competitive differentiator between different NID packages and I am curious
> if anyone knows of any non-bias (at least in the commercial sense) work on
> the subject?
I'm certainly not an authority on the subject, and unfortunately I don't
have any formal (read: scientific) research on this subject area...yet,
but for whatever it's worth:
The two design concepts serve different purposes. The holy war between
"which is better" is IHMO, sort of silly. On one side, you've got
protocol anomaly detection - pre-processors (and other gizmos) that
understand traffic at layer 7. The plus side is that these guys can
actually handle RPC fragmentation, UNICODE shenanigans over HTTP, and
other layer-7 crappola. (that's a technical term, BTW). Another positive
point is that these models can (and have) detected new attack types in the
wild, where the packet greppers are often blind on this front.
BlackICE's "identification" of a few of last year's IIS problems, and
recently, SNMP problems, are good examples of protocol anomaly being a
little more "heads up" with new attacks. HOWEVER, it's important to note
that while the protocol anomaly guys might say "Strange things are afoot
with SNMP!" they aren't going to tell you "Hey, someone's got r00t on your
Cisco boxes by using some SNMP 0-day." I bring this up because while it
*IS* nice to know that "dude, bad sh*t is going down on your network," I
question how useful this is for the novice IDS operators. Discussion for
another time though....
The down side to the protocol anomaly approach is that it can be (note the
use of the word "CAN," before anyone takes my head off) fairly
processor-intensive, and obviously you need a pre-processor thingee for
every protocol it's going to support. And in many cases, you still need
sigs of some sort to pass on useful information to the IDS operators.
On the other side, you've got the string matcher packet grepping folks.
These guys process things at very high speeds, don't always track state,
and are noisy, but fast. Cranking out sigs is often easier, and these
models have proved to be fairly effective at identifying the lowly kiddie.
Much to the chagrin of some IDS vendors, I've compared the two approaches
to the age-old firewall war. (Which is better: application proxies or
stateful packet filters?) There are PROs and CONs to each.
Now, here is where it gets interesting though: if you look at where some
of the packet grepping guys are going (SNORT, Dragon, etc.) you'll see
that pre-processors are being built into the engines. I've heard
rumblings that others are looking at this approach, too. So it wouldn't
surprise me if you found the protocol anomaly folks doing packet grepping
(some do already), and the packet greppers starting to do protocol
analysis. A year from now, the landscape may be a few shades of grey...
So which is more effective at "detection rates?" I guess you'd first have
to define "detection rates," and "effective." :)
-------------------------------------------------------------------
Side note/complaint that has nothing to do with Al's question: this list
tends to spiral down the dark "pie in the sky" academic "anomaly
detection" debates every few months or so. In the interest of
sanity/clarity (and avoiding another one of those SWITCHING HUB threads
from hell), I'd like to propose that people clarify their use of the term
"anomaly detection" when posting. For example, an "anomaly based" IDS
might be:
- a protocol anomaly model, where the IDS says "Hey, that's not what an
HTTP packet is supposed to look like!" or:
- a procedural anomaly model, where the IDS might say "Hey, Greg *NEVER*
logs into the coffee maker at 6am Monday morning. Something just isn't
right here..." or:
- a network/traffic anomaly, where the IDS might say, "Hey, we've never
seen machines from Kazakhstan talk to that time-server before...what's up
with that?"
...and I'm sure there are others. "Anomaly" is too vague of a term these
days. Or at least, according to me, anyway. :)
Hope this helps (someone),
-Greg
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]