Re: Use of Taps for IDS

From: Stephen P. Berry (spb@meshuggeneh.net)
Date: 03/05/02 

To: SEdwards@toplayer.com
Date: Mon, 04 Mar 2002 16:35:40 -0800
From: "Stephen P. Berry" <spb@meshuggeneh.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

SEdwards@toplayer.com writes:

>As mentioned we also understand that type of application, and can balance on
>that - but where this feature is really cool is that where we DO NOT balance
>the traffic - i.e. with SSL traffic .. it is useless to a nIDS and costs CPU
>cycles in determining that it is useless - so we can simply drop all SSL
>traffic, but still pass legitimate (HTTP) traffic.

Lemme think. Nope, can't think of any. I'm sure it's happened before, but
I can't remember anyone ever claiming a simple and systematic blindspot
as a desirable feature of an NIDS.

Now, I won't go into the whole traffic analysis/statistical intrusion
detection/heuristic rule generation/whatever argument. I'm biased---I
actually spend a fair amount of time figuring out ways to analyse traffic
without looking at data segments[0].

And I won't raise any objection based on the fact that you -can- brute force
SSL traffic---feasibly[1], in most cases, unless there's been some systematic
attempt to force lusers to only use browsers which support meaningful
key lengths.

But the average J. Random Analyst should care about being able to take
a look at -any- traffic that passes through or into networks they are
monitoring. Let me give you a ferinstance. Say you see some (for example)
ICMP traffic directed from some external host foo to one of your hosts bar.
Less than a second later there is an outbound SSL connection initiated by
bar to foo. Even if you can make neither head nor tail of the -content-
of that session, guarandamnteed you've gotten meaningful information that
almost certainly did not get from the ICMP traffic by itself. And, unless
you're handling things way over your pay grade, you -want- to get that
information.

This ain't highbrow stuff, only of concern to the occasional mad scientist
off in some ivory tower, wringing his hands over the latest modified
incremental reduced error pruning algorithm. This is simple, meat 'n
taters analysis. Are we really, as a whole, so dependent on signature
based analysis[2] that we're willing to gerrymander our traffic based
entirely on the limitation of signature based tools?

- -Steve

- -----
0 It is an article of hopeless optimism to expect evildoers to
        continue to communicate in only those ways that we (as security
        professionals) find convienient to monitor. Mothers should be
        optimistic, and cheerleaders. It is not clear that it is in the
        best interests of the industry that information security professionals
        should be, despite the example set by (for example) vendors.
1 Mod a realtime requirement. It's one of the many Great Heresies
        against NIDS dogma to believe that realtime is (in the -huge- majority
        of cases) bunk, but count me a heretic.
2 Which, I'd argue, isn't really analysis at all---it's merely
        categorisation.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.3 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8hBJqG3kIaxeRZl8RAjmYAJwMeaJAIFg/bTlMJSla5Ysf85xDqQCePbZi
0CP+8PoY5D3dd9oaDWVAGfo=
=Y8ms
-----END PGP SIGNATURE-----