When people talk about the merits of Open Source software vs closed source/proprietary software, one of the most common advantages listed for open source is “you have the source, you can modify it, you can change it”. This is my worst favorite argument, and I even catch our own sales guys saying it now and then when they’re prepping for a presentation they’re giving. This is a great argument in some instances. But I hear it being used in a lot of situations where it doesn’t apply. For example, without a lot of coding experience and time, a network administrator can’t modify or change something like Snort. So why market Snort to them that way? It doesn’t apply. I’ve got a different opinion of what being “open source” does for the network admin (or security admin, if the company in question makes that distinction), and I recently got a chance to experience exactly this in real life.

Let me start with a bit of background. One of the fundamentals of the security approach we take is based on logs. I won’t get too much into it, but we receive and process upwards of 6 million log messages a day. We recently added a new customer to this mix, who, on their own, more than doubled this number. The system we had was already reaching its technical limits, and we watched as it crumbled to the ground under the weight of their system. So, in the meantime working with them to tune these alerts because there was no need for the quantity of logs, we needed to make a decision: write our own replacement, or find one.

As it stands, there was nothing on the market that did quite what we were looking for, which is why we implemented our own in the first place. And after some investigating, it turned out that this was basically the same this time around. However, writing something like this would be a huge time investment, and while it would be worth it for such a core part of our business, we looked at options for something to use as a starting point for our system. Something we could use some or all of, and write the missing “glue” pieces around. Lo and behold, we found one, and oddly enough it was a tool we’ve been using in other ways for quite some time.

This is where the true spirit of open source comes into play. Open source isn’t great because you can modify it (although, to be honest, we did have to make some changes*, which we promptly contributed back to the community). Open source is great because even if you don’t know enough to change it, it’s almost always easier to wrap your own pieces around open source software and use it in a way the developer may not have intended. In our instance, some of the features we needed most out of the software were after thoughts for the developers, so we had to make them a little bit more robust. But what it comes down to is that with open source, using the program in a new and exciting way isn’t going to get you to “well that’s not a supported configuration” when you call the software company’s tech support. Sure, there’s probably not tech support on the open source software (depending on what we’re talking about… Red Hat and Canonical are two that come to mind right away). But when you go to the developer (which is a totally different argument for using open source), you’re more likely to get an answer like “wow I never thought to use it that way, can you give me more information?” instead of “well it wasn’t designed to work that way, sorry”.

So what it comes down to is this. Instead of a 6-month, multi-developer venture to build a log parsing engine capable of arbitrary alerting, and capable of parsing dozens of log formats, with a simple-to-use system for building tools around it, we spent 2-months of single-developer time (a single developer who worked on other projects too, mind you) making minor changes to an existing open source application, and writing a bunch of wrappers around it to make it work how we needed. And this, friends, is the real spirit of open source, and why we advocate it in nearly every corner of the IT security world.