Time for an IDS?
Posted by Cory Stoker Fri, 27 Oct 2006 21:37:00 GMT
Often we run into a scenario where a client wants to improve security by implementing an IDS. Now this is OK but often we find out that they are not exactly "ready". What I mean by this is to effectively deploy an IDS on a network you should first cover your bases with what you already got. Before going IDS wild, are you using your existing infrastructure to get the knowledge you need first?
Of course just throwing out an IDS is a quick hit; it can cover your ass if the regulatory audit kids drop by, but for lots it becomes a security lame duck. Do you know how to really make it a valuable component of your security?
"Yeah we have [insert IDS vendor here] in place off the 6509."
"Sweet, what does your ruleset look like?"
"Well I think we have all rules enabled right now."
"Ok, what networks are you watching?"
"We want to see both ways so we are not restricting the nets."
"Do you know what kind of traffic and how much are you seeing?"
"Well, not really, but we have all the usual suspects: SMTP, HTTP, HTTPS, FTP and even IM."
"Do you know how much activity you’re seeing for each of those?"
"Man, we just threw it out there, its working!"
Yeah, that $20k went far. The point is to get off this copy-cat buy and forget.
First, I am a believer in doing the macro before the micro. You can’t pick whether a rule should be enabled or not until you know what’s going on in your network. Enabling all will protect you is bullshit. In fact, enabling all can make things worse (easier to exhaust resources, get blinded, or rev up the false positive counters). And forget about dealing with IDS evasion techniques.
Take logging, a macro thing. Logging is an enabler. Deducing traffic patterns is a macro enabler. You need to do these things first before considering an IDS. Engineers like to complain how hard it is to watch logs and I can empathize, but it is really not that hard to get some valuable numbers. Which firewall rules are taking hits, which are not? What kind of traffic are you seeing and how much? A couple scripts can get you those numbers.
So before you do the IDS thing, do these things at a minimum:
- Grab your firewall rulesets and the counters for each allow/deny rule. With this you info you can teach your IDS where to look (vitally important both direction so ingress and egress).
- Learn traffic patterns. What protocols are in use, which networks, and in what amounts. High, average, low - all good numbers. Use this to tune the rulesets. Now you can identify something like your top 100 talkers. If some server catapults to #1, check it out.\
- What apps are running. Learn all the things your environment is hosting. When do your backups run, which servers like to talk to which? Again, information vital to getting value from an your infrastructure that will enable you to get even more value from your IDS.
