This is less of an issue for anyone who uses IDSes on their perimeter--few organizations come anywhere close to 100 Mbps externally. However, internal networks frequently hit 100 Mbps and beyond. This presents a problem for network-based IDSes, as none can accurately keep up at these speeds. Because of this, and the fact that current deployments are still primarily used at the perimeter, the bulk of our testing was based on a 10-Mbps environment.

Second, most network-centric intrusion detection implementations base the bulk of their usefulness on known attack signatures. As new attacks arise, the IDS may or may not detect the attack. No IDS vendor has any sort of push technology in place to update its signature database. The best we can hope for is a timely software update. But vendors aren't shipping upgrades more then a few times a year. Much like the state of your virus scanner when a new virus hits the street, your IDS will likely miss the cutting-edge attacks.

Finally, and quite frankly, network-based ID systems are rather dumb. They can log short-term trends, identify predefined attacks, and do some basic configuring of perimeter devices, such as routers and firewalls. They do not employ any intelligence when reporting on long-term trends, and they are completely oblivious to user trends.

However, these issues are being addressed, and some of these technologies are not far off. Systems like the U.S. Navy's Shadow package can perform long-term trend analysis and detect packet scans as staggered as two packets per day. Host-based IDSes also solve some of these problems. We will be examining host-based IDS later this year.

ISS RealSecure
Following in the footsteps of ISS's flagship product, Internet Security Scanner, RealSecure is the most polished IDS solution now shipping. Although it doesn't offer the flexibility of NFR or ID-Trak, RealSecure delivers a solid, well-documented and easy-to-use system. Combined with a base of more than 100 network-attack signatures, RealSecure is a welcome addition to the security administrator's tool belt.

RealSecure's architecture uses a sensor (or "network engine," in ISS-speak) to communicate with a management console. Using this model, sensors can be deployed across multiple networks while reporting to multiple consoles. This distribution allows for large-scale coverage and a level of fault tolerance: If a console crashes or is attacked, other consoles can still detect sensor output. Because the actual inspection occurs in the sensor, any console can view the results of any sensor.

We tested RealSecure by installing both the sensor and the console on Windows NT servers. Installation was a snap--we were running and defining policies in less than 10 minutes. RealSecure administrators are given the option of maintaining multiple sensor configurations or "policies," which are particularly useful if you want to locate or isolate a specific type of event. If, for example, you have a highly sensitive yet barely used area of your network, you may wish to enable all attack signatures--or maybe even create some custom ones. However, that same policy, crammed with enabled checks, may send your console into a tailspin if installed on a sensor attached to a saturated Web farm. By using multiple policies, administrators can create policy templates and swap them out at will. In the case of a highly trafficked Web farm, administrators may choose to disable some of the more informational/trivial checks. Removing checks for ActiveX usage warnings, for example, may lower the percentage of false positives.