Less Is More
Great post today over on SecureThinking about a customer who used a very limited signature set for their IDS.
Truth of the matter was that our customer knew exactly what he was doing. He only wanted to see a handful of signatures that were generic and could indicate that “something” was amiss that REALLY needed to be looked at. Not that something was a quasi attack or could be successful if only that OS was running this configuration of application X — just the nuts and bolts fundamentals of good ‘ole fashion network monitoring. His SNORT’s ran fast, faster than any other IDS of the same hardware investment, because pattern matching was reduced to a handful of rules.
I’m a huge fan of this sort of setup and something that I’ve promoted within the companies I’ve worked with. Why bother looking for something you know you aren’t vulnerable to either because you’ve patched it, configured around it or don’t have that issue at all? Furthermore, if you have signatures installed that you don’t care about, you are just creating noise that is hiding the stuff you really care about.
This does assume that you have a certain level of maturity and actually have the asset, patch and configuration management issues more or less under control. If you don’t, then this like many other problems remain intractable.
If you have a disciplined mature organization, you can largely, if not completely (depends on how complex your company is) move to only uses signatures to tell you when something out of the ordinary is going on and it doesn’t take a complex piece of software, such as Cisco Mars or Maltego to warn you. Instead, you configure just signatures for things like too many of certain classes of events coming from a certain machine:
Error 404: A client has requested something from my webserver that it does not have, or does not have at the location some client was looking for. When a high number of distinct web servers report 404 to a single client host, that host is not up to any good.
Or use of IP space you should never see on your internal network:
DARKNET: There was some IP traffic (ICMP/TCP/UDP doesn’t matter) from an RFC1918 (private) host that we didn’t allocate, or just don’t know about. This is the equivalent of the Police “running” a license plate, and the response coming back “not in system.” How many police would consider that a routine false positive and let the driver go without further questioning?
Alternately, you can look for events such as machines serving up DHCP who shouldn’t be or the sudden appearance of web servers on subnets that didn’t have them in the past.
I like to call this sort of configuration, “Signature Based Anomaly Detection.” It’s not fancy and it’s not complex, but it will tell you when something weird is going on. It may turn out to be a security issue, a misconfigured machine or someone violating change control, but regardless, it’s a great way to actually make your IDS useful and not just something you have to do because an auditor says you have to.
The best IDS configuration I ever ran was the SHADOW package that Northcutt’s team put together way back when. All it was was a bunch of tcpdump filters that you could define for profile of normal traffic, and it would alert you to anything not matching the pattern.
Web server making outbound connections of any sort.
Connects to hosts on ports you weren’t expecting
etc.
The only useful IDS package I ever used.
I suppose this is another way of saying “know your business” or “know your network”.
In our DBIR, this would fall into this bucket: “Define “suspicious” and “anomalous” (then look for whatever “it” is):”