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.

Tags , , , , , ,  | 4 comments

Agile vs. Security

Posted by Ian S. Nelson Wed, 25 Oct 2006 18:11:00 GMT

I read this article and was reminded of my own post a couple months back. I generally try to avoid the religion disputes within the community but this is one I'm feeling more inclined to chime in on. I'm going to make an assertion to clarify the debate: basically, the "successful" agile projects seem to pretty much build interfaces. I think a lot of developers may be sensitive to that description but that's pretty much what web programming is.

There are some great concepts in agility, there is an overwhelmingly strong tendency for companies to talk about stuff a lot more than actually doing things and at some point the talking always outweighs the effort of just "getting it done." Most teams need a shot of "agile" somewhere. You know, just a kick in the ass to start doing more and talking about doing less. At the same time, I know of no teams that are building things like compilers or operating systems agilely. I know of no widely used protocols that were constructed with agile. I doubt you'll ever see any agile embedded projects in the near future. Basically anything that is actually hard or where mistakes are costly due to limited debugging that might be available or where the customers are so far detached from the actual technologies that they cannot contribute much to the development beyond the interface ( a lot more people use compilers than have anything to add to conversation when it turns to intermediate representations.) Interface security is much different what is meant by security in a protocol. To be fair, I think the discussion should be scoped around this. Agile seems to be at its best in the interface. Maybe it will eventually move beyond that but I don't see any reason to think that will happen soon.

So agile and security... There are a couple things here. First off, security isn't a requirement from customers until it's too late. This is changing but unless they are coached or somehow lead, I doubt most customers would list it high on the list as a fundamental requirement of a new product. It's both implicit and not and when schedules are tight and there are other features that have been sold already it becomes a lot more like a "nice to have."

There aren't a lot of easy ways to automatically test security, I wish there were. More and more software is getting back to the point where there is an automated test suite that will verify functionality, the best projects are still under 100% coverage. I know of no projects that have test suites that verify security after various refactorings. In fact once you trust that something is secure, it's a huge anchor, it's hard to change it and maintain that level of trust. If something some how is perfectly secure, all you can really do is decrease or maintain that by refactoring it.

I also think that the notion that "working software" is the measured deliverable is faulty when you factor security in. Most software works fairly well and accomplishes the goals of the user to some degree, a lot of it also has known insecurities and vulnerabilities. Security is a benchmark above and beyond "working code." In fact most vulnerabilities go unnoticed by the user. Just today we found a hole in our blog software, Typo, that we haven't known about for quite a while and it was being abused. Everything seemed to work just fine though. When security matters, it's a requirement above and beyond "just working."

So are they contradictory like the article on The Server Side asks? I think so if you take agile in a literal sense. If you look at agile as more of a cultural thing rather than a software engineering methodology (and there are a lot of good reasons to do that) then they start to work together more closely, it's a very agile thing to respond to a vulnerability quickly with code, you have to be "agile" to do that. The other change is that security is becoming less and less of a boutique feature, pure security companies are dying and security is becoming just another expectation when you purchase software.

Tags , , , ,  | 1 comment | no trackbacks

Informative survey from Jeremiah Grossman

Posted by Tate Hansen Tue, 17 Oct 2006 20:59:00 GMT

http://jeremiahgrossman.blogspot.com/2006/10/web-application-security-professionals.html

What caught my eye was #3. 71% responded they never "use a commercial web application vulnerability scanner during security assessments".

That surprised me for a couple of reasons:

1. Clients frequently request the use of a commercial scanner
2. Many of the larger security services firms we deal with (i.e. give us projects) not only have a enterprise type license for one or more commercial tools but also require their use when doing a security assessment on their behalf.

Tags , , ,  | no comments

Is a tool list a competitive advantage?

Posted by Tate Hansen Tue, 10 Oct 2006 02:53:00 GMT

We use lots and lots of open source tools, commercial tools, and some home grown tools to do assessments. We have priorities, flowcharts to guide which tools work under which conditions and ways we like to organize and analyze results.

Is this knowledge IP (Intellectual Property)? What are the pros and cons of being fully transparent? Most, if not all, of the information is already out there -- it is just not neatly packaged.

I tend to want to be more transparent, but I’ve recently noticed several partners asking for explicit details on our processes. They want to see the tool list and learn the “details”.

None of what we do is secret, but at the same time I feel hesitant to divulge everything freely. What is your opinion?

Tags , , , ,  | 3 comments