A properly tuned policy will reduce false positives, but tuning a detection policy means customizing the detection-signature set to suit your environment. Examples of tuning include:
Enabling signatures that pertain to your servers. If Apache isn't installed on your network, do you really want to see Apache-specific alerts? We think not.
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.
REPORTS
Analyize In-Line NAC strategies and products.
ANALYTICS Plan and design your enterprise blade server deployments
InformationWeek U.S. IT Salary Survey 2008
Salaries for business technology professionals are falling. Here's what you need to know in order to make good hiring decisions and personal career choices. Download Today