Sure, on our controlled test bed, we didn't find any false positives, but we didn't expect any because the traffic was manufactured to our exacting specifications. When we placed the devices on our live network, however, we initially had numerous false positives, including supposed application-protocol anomalies, such as a TTL of 255 in a RIP packet, various SNMP messages, HTTP header-length messages and apparent Unicode encoding generated from the Mac OS X AOL Instant Messenger client. Tuning reduced the false-positive rate considerably.
We are convinced both of these products will block known malicious traffic, though we did need to carefully choose which alerts to block because of the potential for blocking legitimate traffic.
However, we are not convinced these products are sufficiently accurate at spotting unknown attacks through protocol-anomaly detection. Application vendors don't always write network-protocol stacks that conform to standards, thus causing legitimate traffic to be pegged as anomalous and malicious. We can't stress this enough: You must know what constitutes malicious traffic, then use existing signatures or develop your own signatures to block it.
So should you buy a NIP device? If you're planning to implement a new IDS or replace an existing IDS, we recommend choosing a NIP appliance instead to take advantage of easy deployment, good conformance to stated performance claims and flexible network integration. Plus, you get the option of blocking attacks. But we don't recommend NIP in addition to an existing IDS deployment. Better to spend the cash patching server vulnerabilities--that's something you should be doing anyway. Throwing money in that direction is a more direct way to ensure that your servers are protected because even if attack traffic gets through, patched hosts should be immune. Blocking attacks is not as critical as proper patch management (see "PatchLink Helps Keep Windows Closed,", and "Patching Patch Problems").
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.
To realize the benefits of cloud-native software, an application must actually be cloud-native—designed to run in the cloud, interacting with disaggregated cloud services, fully manageable as code—to deliver the expected benefits.
By combining resources and expertise, the AI-Enabled ICT Workforce Consortium will offer a blueprint for how industries can adapt to an AI-dominated future.
IT leaders should heed the guidance of cybersecurity insurance providers who think businesses should prioritize security education, incident preparedness, regular internal audits, and ongoing vulnerability scanning and patching.
