Simply stated, a false positive is any normal or expected behavior that is identified as anomalous or malicious. This can fall into several categories.
- Some legitimate applications do not strictly follow RFCs. Signatures written to the RFC may trigger when such applications run.
- An application not seen in the training stage of an anomaly detection system will likely trigger an alert when the application attempts to run.
- A signature can be written too broadly and thus include both legitimate and illegitimate traffic.
- Anomalous behavior in one area of an organization may be acceptable while highly suspect in another. As an example NBT traffic is normal in a Windows LAN environment but not generally expected on the Internet.
This is not an exhaustive list but the most common places that IDSes can have false positives.
When you consider all the different things that can go wrong to cause a false positive it is not surprising that false positives are one of the larges problems facing someone implementing an IDS.
The major problem that false positives create is that they can easily drown out legitimate IDS alerts. A single rule causing false positives can easily create thousands of alerts in a short period of time. If the assumption is made that an analyst can review one alert every five minutes, the analyst can review around 100 alerts per day. Reviewing one alert every five minutes is too fast for thorough analysis but we can assume that some alerts will not require thorough analysis lowering the average time for analysis. Looking at these numbers it is obvious that only a small number of false positives can drown out legitimate alerts. The alerts for rules that causing repeated false positives are often ignored or disabled. From this point forward the organization is effectively blind to the attack the problematic rule was looking for.
Almost any rule can create a false positive. The art of IDS management is learning how to minimize false positives without blinding the organization to relevant attacks.