Ignoring alerts from specific hosts or subnets. For example, a vulnerability-assessment tool will light up a NIP device like a Christmas tree, so it's probably safe to ignore attacks from that host. Network-discovery tools that use ICMP, port scans, NetBIOS and SNMP to enumerate hosts will trigger a high number of alerts as well.
Although both NetScreen's IDP Manager and Network Associates' IntruShield Manager have robust tuning capabilities, they take radically different approaches. It's a Scylla and Charybdis thing: IDP Manager, which uses a rule-based paradigm, is familiar and easy to use but can easily lead to rule overload. IntruShield, on the other hand, relies heavily on policies applied to subinterfaces or virtual IDSs, raising the potential of lots of small, highly customized policies. We prefer a rule-based approach because it's the sea monster we know, but we recognize that rule bases can get complex. Individual policies are simpler conceptually, but changes need to be made multiple times, which adds complexity.
Reducing false negatives is a different matter. Factors contributing to false negatives include timeliness of signature updates, poorly written signatures and nonstateful packet inspection. If a signature doesn't exist for an exploit, it won't be detected, so clearly, it's critical to update signatures as quickly as possible. We'll qualify that statement by saying protocol analysis may spot unknown exploits by detecting, for example, violations in a protocol sending binary data, such as shell code, in an HTTP or SMTP header. But protocol analysis can just as easily raise false positives, so though it's a good early warning system, it's not a reliable method of detecting attacks.
An alternative to rapid updates is custom signatures. Although signature development is complex and best left to experts, a little knowledge of signature writing can let you block fast-moving worms or create custom signatures for your environment. Each product has its own signature-creation method, so there will be a learning curve to negotiate, but we found documentation pretty helpful.
Stateful packet inspection is almost a given in IDSs, and it's no different in NIP systems. Common games that attackers play when trying to evade signature-based systems include fragmenting packets into tiny pieces, splitting the protocol headers or attack into multiple packets, sending packets out of order and sending packets with unusual combinations of options. At the application level, encoding of HTTP URLs is a common way to obfuscate HTTP-based attacks. Packet reassembly and protocol canonicalization strive to present the IDS with the packets that will be seen by the destination system. IDP and IntruShield both perform stateful packet inspection and normalize traffic prior to signature matching, so these tricks were generally thwarted.
Our expectations on detection were straightforward: The attacks we threw at the NIP devices should have been detected properly, even when we used evasion techniques like fragmenting and reordering. We weren't disappointed, exactly. On our test bed, the devices performed flawlessly, detecting all the attacks we threw at them. What we didn't expect were the rather odd false positives that cropped up when we installed the products on our live network.