RE: When to do something about detected attacks (was Re: how to d o...)

[Russ <Russ.Cooper () rc on ca>]

My favorite television program, "Connections" with James Burke, is
always giving me lots of good examples to apply in every day life.

In this case, its the idea that if you set up a test to prove that the
Sun is moving away from earth, you'll come up with results that validate
your idea. The reason is, when we make a premise, we have to envisage
ways to prove the premise. Then that's what we go and look for.

In this IDS debate, the premise is we're looking for hackers, so we put
up monitoring to look for what we consider to be "hacks".

Marcus' point, strengthened I think by Dan's comments, is that there is
no way to define what "hacks" are.

If I'm going to monitor, and rely on this monitor to tell me something
is not right, then why base this on what I don't know (what's wrong).
Instead, it should all be based on what I do know (what's right).

The problem that has to be overcome here is the age old problem. I can
collect far more information than I can tolerate. I could, for example,
capture every single packet going to every single machine. The burden,
however, on my systems, my network, my users, etc... would simply be too
great for me to handle.

Its like saying that we're looking for the proverbial "needle in the
haystack" by removing everything that is not "hay"!!

Well, if you think about it, that is the only way to find the needle.
Sure, I could put a huge magnet over the haystack and the only thing
that should come out of the stack should be the needle (assuming the
only piece of metal in the stack is the needle, and further assuming
that the needle is made of metal, I don't know either when I put the
magnet above the stack, do I??).

The idea of "anomaly testing", or looking for Bad Things(tm), is based
on the premise that not only do I know what's good, but I can also
filter it out of my measurement. I honestly don't think either are
possible at a network level, and still be effective.

This is why, quite some time ago, Marcus and I ended up in strong
disagreement about the future of security. He wanted to build stronger
borders, and I wanted to set each person adrift in the ocean of the
Internet with a damn secure boat...;-]

If, however, we could delegate security scope, we might be able to get
our filters focused on enough information to make them perform (both
quantifiably and qualitatively).

Task desktop devices with application security, network devices with
network security, and spread policy enforcement defined from a central
authority out to all.

Truly, the problem today lies in the cost of bandwidth versus the ever
increasing volume of data we need to transmit/receive.

The stop-gap measures that most IDS systems (and for that matter,
Firewalls) represent today are the stepping stones necessary to get the
cost of that bandwidth low enough that we can do what we need to. Why is
UDP used in supposed or potential security solutions (e.g. SNMP),
because it performs. Why do we need the performance, because it costs to
much to oversize the network bandwidth.

Shrinking what we need to look at is not the right approach. Its been
the approach we've been taking for eons, and look where it gets us. If
we are truly going to look at all the "hay" to see if its a "needle",
then we have to accept that we need to do a whole lot more than we do
with current IDS/Firewalls, and that's going to cost bandwidth (btw,
bandwidth, in this context, includes the cost of processing power to
drive the transmissions speeds).

That doesn't mean we shouldn't consider optimizations, but as we all
know, that's typically where we end up getting burned. "Oh, I won't do
an alert on that, it'll never happen...", "I'll reuse that buffer to
avoid chewing up more RAM..." and so on.

If we're going to do it, then let's do it right, and if we can't do it
right, then let's accept we need insurance (...my age old call for
computer security insurance...;-])

Cheers,
Russ Cooper
R.C. Consulting, Inc. - NT/Internet Security
Moderator of the NTBugtraq mailing list
http://www.ntbugtraq.com