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:

• Traffic encryption. As discussed in Chapter 6, the placement of an IDS sensor 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 well.Day zero 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 details).

• Poor 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 thresholding (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.