TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to
[EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any problems!
----------------------------------------------------------------------------
I really like the idea to draw a line between false positives and false
alarm. Faced with an event, the user has to make a decision: Which event is
benign, which is not.
To do this, he needs information on what caused the IDS to generate the
event. For network based IDSs, it really helps to have a full packet log.
Take for example the "TFN2000" false positives in RS5: Once I had the
packet, It was very clear that it was a benign DNS answer. RS5,
unfortunately, wasn't able to present the packet to me. The documentation
said, there are no false positives for this signature, and the event
parameters I saw in the console gave no hint, either. Tracking down the
packet "by hand" took some minutes which I could have been spent better.
Another example would be the HTTP_IIS_Unicode_Encoding triggered by Code
Red hitting RS6 network sensors: The Event Information contains the request
URL, but it is cut after some 64 (not sure about the exact number)
characters -- which is before the unicode section starts. If you look at
one of those events, you actually see no unicode in the event information,
because it was cut.
The other important piece of information any IDS must provide would be an
good explanation on what would cause the signature to trigger. Robert
Graham's examples show some promise, and the documentation of "benign
triggers" would be a very good idea. My experience with asking vendors,
however, had been less than satisfactory in the past. One request about a
false positive problem ended with tech support telling me "any further
details regarding our decodes beyond what is contained in our help file is
proprietary" (ISS request ID 424723, in case someone from that company
would like to get the whole story).
But what to do if one has found an false positive? I'm sorry to beat upon
the same horse again, but take for example the TFN2000 problem with RS5.
Just shutting down the whole signature was no option for most users, I
guess. Wait for the Vendor to correct the problem? If I recall it correctly
(see the ISS mailing list archives for details), the problem was known
since July 2001. It was even acknowledged by ISS staff to be a false
positive. Nevertheless, it took half a year until there was an Xpress
update (January 2001) for fixing it. And guess what: It fixed TFN2000 but
created another false positive triggering quite often (Stream_DOS). A good
thing would be to have some piece of user supplied code being able to look
at the event and modify (or just drop) it before it hits the user. In the
above example, I would have written a piece which checks every TFN2000 for
"source.tcp.port == 53 && dest.tcp.port == 53 && source.ip == our_DSN_ip &&
dest.ip == forwarder_DNS_ip" and if this check gets a true, just drop the
whole event. Black Ice's "trust.pair" (though the number of possible pairs
is too limited if configured with the console) is a good start. The
IceCap's "Response Rules" (version 3 and up -- if there will be any) are
even better. But the ultimate thing would be a Perl interpreter built into
the "Event Collector/Console" (not the sensor!) being able to access the
whole event and asset database.
One thing which really puzzles me is why the big IDS products don't have a
good incident response functionality (perhaps I know the wrong
products...). RealSecure, in my point of view, is the worst: You can't even
copy&paste an event out of the console -- you have to do an screen dump
(see Stephen Northcutt's book "Network Intrusion Detection", 1st Edition
from July 1999, Page 78 or ask any RS user)!! Better yet: If you have to
close down the console (for whichever reason) you loose all events. Only
way to get to them is with the report function.
What am I expecting? Display of Events and Alerts. Past and present (like
in the IceCap Inspector). Easy cross referencing (what did the attacker do
before? Show all events to the same victim. Show all Events with same
signature) much like IceCap Version 2 (the feature is lost in the Version 3
Alert list for no visible reason).
And -- what is even more important -- a way to work with events. Wouldn't
it be great if I could just click on an event, type "Comment: This is an
false alarm. Reason ...", click on "Dismiss" and it's gone from the alert
view? Wouldn't it be cool if -- in an multi-site setting -- an IDS user to
take an event for analysis by a simple click? The other IDS users would see
that Joe is checking this thing and there would be no need to phone around
"Hi. I've seen this thing. Are you investigating it?" or duplicate work. I
have a hard time believing that ISS is using this tool internally for their
"Managed Security Service".
How about using the same Perl engine (as requested above) to do a mass edit
of events ("We finally found the reason for all this ICMP stuff. Router X
had a problem. I just set all those events to <solved>")?
Life could be fun...
Andreas Prass (formerly known as Andreas Haug)
