| The Second False Positive | |
|
When I was at Hacker Halted recently, I watched a great talk by Ron Gula of Tenable. He brought up that most of the advice for IDS tuning is wrong. It's something I've been arguing for years, but haven't ever sat down to write out the main process by which I recommend to clients to reduce IDS noise. First, I'm a big believer in the horrible damage caused by false positives. My view on the world was altered irrevocably in the early days of IDS by Stefan Axelsson's paper "The Base Rate Fallacy and its implications for the difficulty of Intrusion Detection". It consistently amazes me how few in our industry have read the paper. For those who aren't going to read the paper (and you really, really should), the message is simple: false negatives are annoying. False positives will quickly undermine the value of the IDS in any environment. This isn't counter-intuitive, as the advice given by most IDS tuning guides is to eliminate the "false positive generating" signatures first. While this is good advice, we don't usually consider what is meant by a false positive. There are two types of false positives. First, the signature that detects good traffic as inappropriate. This is what we're used to tuning out. But these aren't the cause of most of the noise in most environments. In most environments, we spend a lot of time dealing with the second type of false positive: the inappropriate traffic that is legitimately detected that we just don't care about. This corresponds to the risk tolerance of the organization where it comes to security events. In most organizations, that nmap is run is not a risk that the organization cares about. However, we tune these events out of our IDS far too infrequently "just in case it finds something". It's the "just in case it finds something" that causes us to take too much data from our IDS and get overwhelmed with the noise. Ask yourself... where are you allowing your IDS to alert on items that are below your risk tolerance? Why?
Set as favorite
Bookmark
Email This
Hits: 1152 Comments (0)
![]() |






