19-7
User Guide for Cisco Security MARS Local Controller
78-17020-01
Chapter 19 Incident Investigation and Mitigation
False Positive Confirmation
•
A
legitimate attack
is an actual attempt by an attacker to gain access to or information about a
specific host using a known exploit.
•
A
valid target
is a host that is susceptible to the launched attack. A host can become an
invalid target
if it is properly patched or has some other preventative measure in place, such as a local firewall,
virus scanner, or intrusion prevention software that guards against the attack.
•
Attack detected
refers to whether the monitoring device detected the attack and generated an alarm.
•
A
false positive
is when the monitoring system generates an alarm for a condition that is benign. In
this case, there is no legitimate attack, despite the alarm generation.
•
An
unconfirmed false positive
is one where the monitoring system, based on data not available to
the reporting device, has determined that an alarm is a false positive. Unconfirmed refers to the fact
that the administrator must review and accept or reject the assessment of the false positive.
•
A
false negative
is when the monitoring system fails to detect a legitimate attack.
•
Noise
refers to those alarms that are triggered due to attacks against invalid targets. While they can
represent real attacks, the target cannot be compromised due to preventative measures. Attacks that
fall within the noise category are of secondary importance in terms of investigation and mitigation.
•
Intrusion
identifies a successful attack against the host, where the host is compromised by the
attacker.
•
A
true false negative
identifies an intrusion that remains undetected by the monitoring system.
•
A
true alarm
identifies an intrusion that is detected by the monitoring system.
When a Local Controller receives an event, it is evaluated against the conditions of the defined rules. If
the event satisfies the conditions of a rule, then the incident triggers. When an event triggers an incident,
we refer to that event as a
firing event
. False positive analysis is performed for such firing events to
reduce the number of false alarms.
Using built-in event vulnerability data, learned topology paths, sessionized event data, ACL analysis of
layer 2 and 3 reporting devices, supporting data from 3
rd
-party vulnerability analysis (VA) software
(such as Foundstone and eEye), and information that you provide about hosts, MARS analyzes the firing
events reported to it determine whether the they hold up to a higher-level review.
In the case of MARS, a
system-confirmed false positive
is where, after further analysis, a firing event is
determined to be invalid. Example system-confirmed false positives include:
•
When an IDS device monitoring the network outside of a firewall reports an attack; however, the
firewall drops that session as part of its standard access restrictions. Therefore, the attack never
reaches the target.
•
Cisco Security Agent detects an attack and blocks it.
An
unconfirmed false positive
is where, after further analysis, the firing event is believed to be invalid
primarily due to the attack being against an invalid target. Example unconfirmed false positives include
•
A reporting device reports a valid attack against a host; however, the host is not susceptible to that
attack because it targets a different operating system. You can reduce these types of false positives
by employing OS fingerprinting technologies on the reporting devices.
•
A reporting device reports a valid attack against a host’s application; however, the host is not
susceptible to that attack because it targets a different application.
•
A reporting device reports a valid web attack against TCP port 80, however, dynamic probing
determines that no services on the target host listen to TCP port 80.
For unconfirmed false positives, you must manually investigate the alarm and specify in
Local Controller whether it is an actual false positive. For actual false positives, you should define a drop
rule for the event. Defining a drop rule does not mean that the event is not stored in the database, you
