[logs] too many false alarms
Marcus J. Ranum
mjr at ranum.com
Thu Jan 24 16:34:31 PST 2008
Jon Stearley wrote:
>what false alarm rate do you tolerate for your current monitoring
>system? is 1 false alarm in 4 ok? 1 in 10? 1 in 100?
Let's make sure we're talking about the same thing, first.
"False positive" is when the sensor/IDS/monitor raises an alert that
is wrong. An example of a false positive would be if your
web site got slashdotted and your IDS altered you to a "SYN
flood attack."
"False alarm" is when the sensor/IDS/monitor raises an alert that is
right, but not interesting to you, either because the event
is accepted by your policy or is you have additional knowledge
that allows you to assess the alarm as insignificant. An example
of a false alarm would be if your IDS alerted you that someone
just tried a Windows/IIS-based buffer overrun against your Sun box
that's running Apache. The diagnosis is correct, but you may not
choose to care.
Given those definitions, my answers would be:
"as many false alarms as it generates" and "any"
The problem is that a lot of the time people are expected to put sensors
or detectors/monitoring systems in place to monitor networks that are,
basically, too permeable. So, of course, there are tons and tons of
alarms. And, the sensor/IDS/monitor gets blamed for being "too noisy"
when in fact the situation is that "the network's security sucks."
A perfect example of this would be one site I worked with back in the IDS
days: they complained bitterly that the IDS generated "too much noise"
but their policy was that port 80 was allowed unimpeded inbound access
through their firewall. OF COURSE the IDS generated a lot of noise - it was
correctly and fairly accurately identifying the approximately 30,000 real
attack attempts that were being launched against machines on the
customer's internal network EVERY DAY. The fun part was when
management didn't like my assessment of their situation and sent their
technical staff to go "get another opinion from a REAL IDS expert."
mjr.
More information about the LogAnalysis
mailing list