Cisco’s IDS

The Reviewmeister is obsessed with security so we tested out a bunch of intrusion detection systems to see which one would do the best job of detecting the bad attacks while at the same time not flooding me with false alarms.

Let’s start with Cisco. In our first test, we took a server that had been cracked and asked the IDS systems to figure out who broke in and how.

Most products distinguished between alerting and forensics. In alerting, IDSs bring recent high-priority events to your attention. In forensics, they let you dig down to find the source of the problem.

Some products were very modal: You’re either working in alert mode or in forensics mode, and there’s a barrier between them. Cisco (with its Cisco Threat Response [CTR] alerting console it picked up through the acquisition of Psionics earlier this year) fell into this category. 

With Cisco’s CTR you’re given views by event, source and target, but you don’t get the ability to easily jump around. You can discover the start time for attacks and then see who was attacking. But doing so requires a lot more GUI navigation than with other products. You can’t trim your view by time (although you can sort by time), and you can’t quickly match up source and target because the pre-programmed views don’t allow for that.

Because CTR only shows alert data, you only have the most recent information at hand, which means that when you want to run forensics queries, you have to jump over into Cisco’s other tool, the IDS Monitoring Center, which is shipped as part of its larger management platform, CiscoWorks. Because the IDS Monitoring Center predates CTR, it also can act as an all-in-one interface, both for handling alerts and for conducting forensics research.

The bottom line is that what was fast using other tools took significantly longer using either or both the tools Cisco provided. What came out, though, was  better because CTR downgraded some of the alerts that other tools thought we should be concerned about. CTR did this when it saw that the attack was not successful. Our shortlist of activities was shorter with Cisco.

When it comes to filtering out false alarms, Cisco’s IDS Management Console offers the capability to filter out particular signatures, but in a complex way. We credit Cisco’s IDS distributed management because it lets you put sensors into groups and then apply settings and configuration changes at the sensor level, group level and network level. At first glance, this is a mature and reasonable way to handle a network of sensors. But Cisco doesn’t let you manage signatures and filters at the group or network level. So if you want to build a filter to drop out certain events, you have to go from sensor to sensor, copying the same information.

If you actually want the data, but want to separate the useless from the useful, Cisco offers a partial interface with its CTR tool. CTR provides a series of policies that are used to upgrade and downgrade alerts. But creating a new policy to say “this alert is not relevant” is difficult.

For the full report, go to:

https://www.nwfusion.com/reviews/2003/1013idsrev.html