False Negative Traffic

Christopher Dobkowski

Hey there guys!

I have a question regarding the IPSs/IDSs...


How to handle False Negative traffic? Any additional appliance exists to detect malicious traffic?


Thanks in advance!

YFZblu

Typically it involves more tuning of the rule. If it's not firing at the appropriate times, look at the traffic and compare it to the rule. Typically you'll find a discrepancy - In my case I recently wrote a SourceFire rule that wasn't firing, turns out there was a sytax error in my rule.

Common appliances used to detect malicious traffic are HIPS, A/V, NIDS, Proxy, and firewall

Christopher Dobkowski

Hmmm, that's interesting

Thanks!

ChooseLife

Defence in depth. What one type of protection/detection does not catch, the others will.

docrice

IDPS appliances require tuning to the environment. Any time you have a security solution which is handling/inspecting traffic at the payload/data level, the chances of false positives and negatives are high unless you take the time to actually understand your environment and tailor the sensor accordingly. Some IDPS systems are better designed for this than others.

In addition, it's more than just about the rules. Sourcefire/Snort, for example, allows you to tune its preprocessors. The frag3 preprocessor allows you to specify destination hosts as either Windows, BSD, Linux, etc.. This matters because the detection engine (rules) must get parsed against the traffic that is reassembled, and different operating systems will handle oddly-fragmented traffic differently, and thus the sensor must reassemble/interpret the traffic the way the target host will. Tune it incorrectly (or not tune it at all), and the chances of a false positive or false negative increase.

An IDPS is only as good as the rules it has and the tuning done by the analyst/engineers of the network it's used in. Malicious traffic comes in many forms and an IDPS is not the catch-all solution for it. Another example is encrypted traffic. If you can't read within the encryption stream (via either a MITM decryption appliance or other out-of-band feed), the sensor will miss it.

There's also the limitation regarding just how far a sensor can work beyond rules and other features like reputation. While Sourcefire has some preprocessors to follow-along certain protocols (RPC and HTTP come to mind), in the end it can't know every application inside-out. This is where WAFs and other app-level proxies come into play. This is not the same as firewalls which identify applications at a high-level (sometimes referred to as "NextGen" firewalls, a term which I despise).

Detecting malware is also false-negative prone if all you're working with is signatures. With so many variants these days, signature-based technologies have their limitations. That's where solutions like FireEye help.

In the end, you need to have defense-in-depth, understand your risk profile, and season to taste.

Christopher Dobkowski

Thanks to both of you!

And thank you for the in depth response docrice! It was helpful a lot! Thank you!