9.2 False Negatives (Missed Alerts)
False negatives—genuine attacks
that aren't noticed—are obviously a problem.
False negatives are hard to quantify—it's
difficult to figure out what you don't
know—but there are steps that an administrator can take to help
keep the incidence of false negatives at a minimum. Sometimes other
components of your defense-in-depth strategy (i.e., syslogs or
weblogs) will show signs of attack that the IDS is not alerting on.
9.2.1 Common Causes of False Negatives
Here are some common causes of false negatives (missed alerts) and
suggestions for remediation:
encryption. As discussed in Chapter 6, the placement of an
is critical. Encrypted traffic does not trigger alerts because the
signature patterns don't match. It may be possible
to address this by placing the sensor on the network behind the
device performing the encryption (SSL Accelerator, VPN Concentrator,
and so on) where the traffic is clear text. There will likely be some
traffic that cannot be monitored.Network
configuration problems. Mistakes in sensor placement or complexities of network
infrastructure may cause some traffic to be missed by the Snort
sensor. If there are multiple paths into a network, the sensor may
not be able to see all inbound and outbound traffic. If a
switch is configured to span
several ports to allow a Snort sensor to monitor the traffic, the
aggregate bandwidth being spanned may exceed the bandwidth capacity
of the port the sensor is plugged into. For example, 6 ports running
at sustained 20 Mbps will have an aggregate bandwidth of 120 Mbps.
This situation clearly exceeds the capacity of a 100 Mbps Fast
Ethernet span port (discussed in Chapter 6).
Multiple sensors or a Gigabit Ethernet port may be called for. Some
of the more extreme measures discussed in Chapter 13 may need to be considered, as
attack. Snort is a signature-based
IDS; if an attack or exploit occurs for which there is no a
signature, it will go undetected. The signatures for Snort are
updated frequently and you should establish for keeping the
signatures as up-to-date as possible (see Chapter 7 for details).
Faulty signatures. It may be that a signature
is written incorrectly (common in user-developed rules that have not
been peer-reviewed) and are not watching for the correct attack
signature. A variant of an attack might not trigger the same rule as
its ancestor. Thorough testing of user-created rules and keeping
up-to-date with signatures is the best way to address this issue (see
Chapter 7 for
change management. Very often there are separate departments in an organization that
handle network administration, server administration, workstation
support, and security. If these departments do not communicate well,
changes that affect the security posture of an environment may go
unnoticed by the security team. There is no replacement for good
communication between information technology subdepartments.
Snort sensor administration
problems.. If, in the course of overzealously tuning the Snort rule set to
control false positives, an administrator eliminates an important
rule, an attack or probe may go unnoticed. Later in this chapter,
we'll discuss strategies that help to establish a
procedure for organizing a reasonable rule set.
It may be possible that the system is under too much load to keep
upwith the packets the sensor is tasked to watch. Careful monitoring
ofthe system is required to ensure that the sensor can keep up. See
Chapter 13 for ways to watch highbandwidth or
particularly demanding network environments.
Later in the chapter, we discuss ways to limit the number of alerts
generated for a particular rule or a particular host. It is also
possible to suppress alerts entirely for a particular rule or host.
However, if you aren't careful, you may miss real
security events or give them less priority than they should have. For
example, an Internet worm-infected host might generate thousands of
alerts in a very short period of time—which should quickly get
an administrator's attention. But if
(or another alert throttling technique) is
enabled, the same host would generate far fewer alerts, attracting
far less attention. Controlling the number of
alerts for a particular event can
dramatically reduce system load and administrative workload, but it
does carry some risk.