Matt,
>analyst aka a REAL ROI - Time (money) X Incident. For example if you see
>the multitude of attack signatures that indicate Nimda from an IDS, and
Well, I doubt that one needs a rule to ignore Nimda, surely you can just
filter it out especially if you know you are patched against it. Or you
can deploy one of those fancy "anti-CodeRed/Nimda" devices (aka IPS)...
>measured (rate of false positives/actual events) and thusly can have
>impact to system that does Risk or Threat Modeling.
Yes, indeed, but knowing the rate will likely not help the response
procedures, since even knowing that e.g. you have 20% FP rate does not
mean that you know which 20% of incidents you can ignore...
>correct (for the top 20% of uberhackers) IF you're only using a NIDS
This is one curious number! I am wondering how people come up with those.
The author of the article I forwarded thought it was actaully 90% and not
20%, but I do not understand how *either* is justified...
>(and maybe HIDS). My point is that the correlation/anomaly detection
>system would catch most of the 20% if the logs that the system was
>receiving where adequate. For example, any new attacks that the attacker
This is a very interesting point. The evidences might be there, but
piecing together the picture from some diverse logs to catch the attack
that IDS missed (i.e. new or modified attack) - wow, that sounds like a
challenge.
>I'm going to try to address the issue Matt Harris was talking about as
>well. What you need to do is create rules for the known not unknown.
Well, this is the tricky part - at what level of detail do you *know* the
known part? It looks like there is a trade off here (similar to NIDS
case, but potentially worse) - you can either make the system create false
positives (like in the case of firewall connection attempts presented by
the previous poster) or false negatives (like, I suspect, systems that
send "marked" data and then respond if an attacker uses it). It is really
interesting how you would create those rules to be in the middle?
Best,
--
Anton A. Chuvakin, Ph.D., GCIA
http://www.chuvakin.org
http://www.info-secure.org
Received on Dec 12 2002
Intro
