

ISS RealSecure Pushes Past Newer IDS Players
May 17, 1999
Once an attack signature or event is matched, the sensor reports the event to the management console. This is where RealSecure shines: The console interface allows administrators multiple views of the gathered incident data. For example, sifting through the day's events we were able to view attacks by target (destination), source or event type. When someone targeted a single machine, we could switch to the destination view and see the assortment of attacks run against the machine. However, when we were trying to determine the origins of a coordinated attack, we could flip to the sources view, where we were presented with a grid of hostile machines and their offending actions. The quick, easy and accurate portrayal of this type of information is invaluable to anyone trying to react to an incident.
Unfortunately, RealSecure's console has some annoying habits. First, while you can clear the warning boxes that list events based on severity level (low, medium and high), the event matrices are locked. After populating the RealSecure event viewer with a few dozen trivial attacks, we were ready to clean the slate and get medieval. The only way to wipe the plate before the onslaught is to close down the console application. Worse, the advantages of the event viewer are weakened by the fact that if you exit the console to clear those events, there is no way to replot them. If you want to see an overview of excursions you're out of luck if they've been wiped. The only way to retrieve this data is to query the database. Not surprisingly, the text file that is produced isn't nearly as pleasing.
Also painfully lacking is threshold adjustment and customization. Less than a dozen of RealSecure's signatures allow for some amount of threshold adjustment; the vast majority of them do not. And, unlike NetRanger, RealSecure has no capacity to do regular expression searches when it comes to network traffic. The customizable "user-defined" rules are about as useful as basic route filters. Using Cisco ACLs (access control lists) with syslog can accomplish similar tasks, and that combination doesn't carry a hefty price tag.
Finally, in a world of wretched grammar, acquisition chaos, merged product lines and embedded video games, it's nice to see a vendor take the time to thoroughly and professionally document its product. ISS did a first-rate job in an area where so many vendors frequently fail.
Cisco Systems NetRanger
NetRanger was one of the first commercial IDS implementations to ship, and the offering draws upon Cisco's experience in the IDS field. A demon of an intrusion detection solution, NetRanger could give the Energizer Bunny a run for its money. Obviously written by Unix people for Unix people, the product is one hard-core ID implementation that is fairly versatile. Its healthy attack-signature database, the staple of any good IDS, even has some creative signatures you won't find anywhere else. However, NetRanger's dependence on Hewlett-Packard Co.'s OpenView, its lack of clear documentation both in and out of the product, and its failure to provide a clear overview of attacks drop it into second place behind RealSecure.
For our evaluation Cisco shipped us both a "director" unit--a Sun UltraSPARC 10 running the director software--and a turnkey rack-mountable sensor unit, which ran the sensor software on top of Solaris x86. The sensor is essentially a beast-in-a-box: the dual Intel Pentium IIs drive Solaris and the associated services across a 100-Mbps private pipe to the director unit. We found the private link to be a nice touch, as the director is completely shielded from any attacks experienced on the monitored network segments. Building on this architecturally secure model is the fact that the sensor itself is virtually undetectable: The external interface, the one facing the monitored segment, has no IP address bound to it. We were unable to figure out a Layer 3 method of attacking the sensor directly.
Configuring NetRanger wasn't as intuitive as we would have liked. While a Unix-savvy administrator will quickly pick up on the various daemons and startup scripts, Cisco failed to supply any documentation detailing the ins-and-outs of running NetRanger. Cisco's support engineers were able to forward us draft documents that were of great help, but Cisco is obviously not where it needs to be when it comes to clear reference--a lot of information is still folklore.
|