ClearNet Security: Time for an IDS?

Time for an IDS?

Cory Stoker — Fri, 27 Oct 2006 15:37:00 -0600

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.

"Time for an IDS?" by Marc Andersen

Tue, 07 Nov 2006 07:20:12 -0700

Guess I don’t know how to break lines :)

"Time for an IDS?" by Marc Andersen

Tue, 07 Nov 2006 07:16:57 -0700

I mostly agree with Cory. An IDS does not solve your problems. You cannot just turn on all the rules full blast and claim to be secure or in compliance. You have to know what you are doing.

That being said. Instead of using the time consuming task of determining all the macro things before implementing an IDS, why not use the IDS in tandem with the macro things? Look at your firewall ruleset, count the hits the rules are taking, and at the same time confirm it with your IDS. Do they say the same? Is it actually what I am supposed to see? What did actually trigger the rule?

It sounds risky to look at you firewall ruleset thinking “Oh, well this never gets triggered, I’m not gonna let my IDS look for it then” (just to exaggerate a bit).

Same goes for logging. Look at a days worth of PIX or ASA logs. Sure they can tell you who has been talking to whom on wich ports, but it doesn’t tell you what has been said (or rather if what has been said was benign). An IDS can help you specify that (to a certain degree). A good way to verify which apps are talking through the firewall.

So I think what I am trying to say is that you could use the IDS to speed things up a bit. Implement it for “macro purposes” at first and then later on use it as a true IDS. Maybe even use it to tune your macro things.

Marc

"Time for an IDS?" by Søren Maigaard

Mon, 30 Oct 2006 02:18:26 -0700

IDS always seems to pop up once the “But we have a firewall” statement has been shot down. It is a typical management friendly option - buy the hardware and all is good.

I agree with Cory that very few corporations are actually ready for an IDS. If they really need the IDS, it is probably because they lack some of the fundamentals described. My theory is that if you need it, you need to look elsewhere. Once you are in a situation where you don’t need it, it’s time to get it. You’ll have the information you need about your network, assets and traffic and you probably have the time to fine tune the equipment.

Anyway, it seems it is IDS week. Check out this discussion on Matasano’s blog: http://www.matasano.com/log/570/richard-bejtlich-stick-up-for-ids-i-retaliate/

Søren

"Time for an IDS?" by LonerVamp

Sun, 29 Oct 2006 15:05:14 -0700

Nice post. My current job had me inherit an IDS/IPS device they bought, but were barely using. It was in place and had IDS enabled and that was it. No one really knew what the alerts meant, how to properly tune it, what the environment was really like, or even what the point of it was.

I think if a company’s IT staff does not have a good hold on inventory (hardware, software, and apps on the network, especially network talkers), network diagrams, or a solid foundation in being able to understand TCP/IP (and so on) and how to research attack patterns found in the traffic and logs, they are not even close to being ready for an IDS/IPS in any official sense. Sure, some enterprising young pup can throw in a Snort box for a while just for the heck of it, but to comply with a regulation and/or shell out $20K+ for a device requires the foundations to be there.

If an org has an IDS/IPS installed and all rules turned on, I’d venture questions about whether they alert on ARP storms and other NETBIOS goodies that, if truly enabled and watched, can make heads spin due to the chatty nature of Windows and the protocols. If they can answer those questions intelligently, then maybe they can proceed…