Site Protector from ISS

As part of our continuing test of intrusion detection systems, the Reviewmeister sent Site Protector to figure out how one of my servers was cracked.

ISS doesn’t distinguish between alerts and forensics, but instead offers different views of the same data within Site Protector, ISS’ tool for managing and analyzing information collected from its security tools suite.

One powerful feature is its automatic summarization function. Events are grouped wherever possible to reduce the report size. It was easy to confirm that our server was hacked and when it happened.

To go from the “when did it get cracked” screen to “how did it happen,” copy the IP address with a right-click, paste it into the same screen, and select a different view of the data. Wait 8 seconds, and there’s your answer. Seems simple, but it was a sharp contrast to other products that don’t have as sophisticated an interface for slicing, dicing, sorting and finding data.

SiteProtector now had a short list of events, of which six were listed as high priority. Powerful forensics capabilities let you identify attackers and see what else they might have been doing. More importantly, ISS’ event management tool lets network managers dump the most interesting events into an “incident” folder and quickly generate a short list of research action items for any node. The linkage between events and ISS’ X-Force database, with exact links to explanations and patch locations, gave us a huge head start on tracking down the problem.

We then asked Site Protector to filter out false alerts. With ISS, we found two easy techniques for filtering events. Within the per-sensor policy, a well-hidden tab lets you drop events from ever being sent to the IDS console. Whether this would work for a large network is a tough question. Each combination of event and destination address has to be entered separately, which means that if you manage hundreds of servers, you could spend a long time dropping events. Or, more typically, you’d decide that the event wasn’t important and disable it. But that’s a dangerous approach because new systems popping up on a network might not have all the right patches applied and configuration changes made. Solving this problem the ISS way would be extremely tedious for large networks.

For security analysts who want the data, but don’t want to see it unless they ask for it, ISS has a partial answer. For any view of the event and forensics data, a filter can be added that blocks particular attackers, target IP addresses and events from appearing.

For the full report, go to https://www.nwfusion.com/reviews/2003/1013idsrev.html