How you handle your signatures

[kutukutu9]

What are you doing with your signatures which fire and are false positives? Are you using event action filters or are you disabling the signature? In some cases I see where disabling that signature would be fine. Like if you have a DNS box which is patched and not susceptible to a exploit being noticed by IPS - Since your system is patched and no other boxes are susceptible to the exploit then it seems only logical to disable the signature, yes? But event action filters come into place for signatures like sig-3030 which, in most cases, should only fire when the source is from outside your network. Just want to make sure Im on the right track. Anyone know of a good site which discusses IPS best practice, administration and policy?

Also how many of ya'll monitor your internal network?

Thanks

[attmidsteam]

First you need some sort of event monitoring system where you can track & store events long term - this will allow you to spot long term trends and note if a certain event is triggering over and over. Second, detailed knowledge of the network you are protecting allows you to create filters to disable alerting on obvious false positives (aka an IIS signature against an Apache server). If there are certain products you don't run at all (like CUCM) feel free to disable them. Also, some signatures are just terrible in general and should be disabled immediately. Sig-3030 is a generic sweep signature and does not care about direction.. if your SEM supports real-time correlation this is a great way to find internal worm traffic that may not be triggering a specific pattern signature. There are many dozens of books about IDS/IPS systems; go browse your local B&N or Borders.

[clausonna · Accepted solution]

When I'm troubleshooting a new alert I usually enable 'log pair packets' so I can put more context around the alert itself. Although they get correlated in MARS I use CSM to tune the sensors and signatures. I'll cross-launch to IDM to pull down the packet captures, saving them with somewhat descriptive names in case I need to revisit them later. I also use a great netflow reporting engine (mazu networks) to see where else the suspect PC has been going, and then use online tools like dnsstuff.com, spamhaus DROP lists, Dshield, to see if the IP address is on any block lists. This tool (as well as Arbor Networks, Lancope, etc) also do their own non-signature-based network behavior analysis, and sometimes (not always) something with correlate here too.

After I get enough information I try to tune the actions on the sensor itself. Sometimes you have to fall back on a MARS drop rule, just to screen out false positives or handle special cases, but I think its better to keep the alert from occuring in the first place. Having too many filters gets ugly fast.

You should also be leveraging Cisco's Intellishield service ; each IPS sig subscription gives you (free) access to detailed information on the IPS sigs and the vulnerabilities that prompted the sig in the first place. Great service. I've been able to disable a bunch of sigs using this alone.

Good luck.