One of the most interesting debates in IT/infosec circles is around the use of and reliance upon open source security software. Open source security software has its share of fans as well as detractors.
As one of its avid fans, I started fiddling with computers when my father gave me his first Atari 2600 and Commodore 64, followed shortly thereafter by his first IBM PC in 1990. An avid gamer and true hacker, I had more fun “creating” extra ammo, getting more units and constructing different appearances than he did actually playing the games. Very early on, I was hooked on hacking and programming, which led to a passion for computer languages and especially computer security.
Open source has allowed me to not only learn how to use certain products but has been a big influence in learning how to “think”. If you know that something is “supposed” to do this or that and it doesn’t… well, with open source, you have a shot at looking it closely and fixing it. This can range from a simple script/scripted web page to a kernel module for your favourite USB foam rocket launcher.
People can surely relate to this feeling much more with cars or DIY home improvement: imagine that you weren’t allowed to open the bonnet of your car and the most you could do is read out some indicators on the dashboard and/or go by instinct, and in the end call a more or less responsive/unresponsive vendor to help you fix something.
On the other hand, imagine you have a workshop full of tools, a lift for the car, tire alignment machines, etc. This is how I see open source software vs. closed source software. Even if I have no clue on how to fix cars myself, I know that if I buy a petrol engine based car there’s 200 people in my area who can look into it, work with it, fix it. If I buy a Tesla on the other hand, there’s only so much they can do, I’m much more locked into a single vendor.
The benefits of using open source software vs. commercial versions that come to mind include:
Kicking the tyres: Open source software is really easy to try and commit to it. Assuming the software is mature enough.
- Use case flexibility: You can easily modify it to suit it to your specific needs.
- Responsiveness and access to developers: As opposed to closed source software, you have infinitely better two way communication with developers, without the procedural obstacles that vendors may have in place.
- Freedom in implementation: No apparent vendor lock-in; if it doesn’t work for a particular use case, you’re not committed to trying to force fit it in your environment.
The use of open source software in the security industry is extremely extensive. In fact, I’d be surprised to find a place where security is taken seriously where it’s not being used in one form or another. Open source software forms the code base of the entire security products stack.
Some of the best open source tools include:
- NMap - In terms of code quality, excellence and staying power, this is one of the top open source tools. It’s a must-have in any IT operations toolkit.
- OSSEC - It’s amazing how much can be accomplished by one person using this open source HIDS tool. Also, OSSEC is coded with such “cleanliness” of design, it’s truly impressive.
- Netcat & bvi - As network troubleshooting tools, you can’t get more simplicity and power than these two.
- tcpdump - I think I’ve used this packet analyser tool more than any other open source tools, to be honest. There are so many use cases for it, and it’s a great place to start when doing packet inspection and other threat analysis.
- rm - A very powerful removal tool, tremendously useful with certain users :-)
- OpenBSD packet filter - this tool filters TCP/IP traffic and does NAT. This project also demonstrates the power of tenacity, stubbornness and sheer talent can produce in short period of time.
It’s important to point out that many of these tools come built into AlienVault USM and OSSIM. And many of the coders who’ve started these projects serve on the AlienVault Technical Advisory Board.
When considering the disadvantages of using open source security software in a production environment, it’s really important to make a distinction between totally free open source and vendor-backed open source. Using free open source as is, with no warranty or support, requires that you stick your neck out if anything goes wrong. For many people (including me), this is fine if you have the confidence to fix things when they go wrong. And they will go wrong, whether that’s an open source or a closed source product.
If you choose the most expensive closed source solution to suit a particular need in your production environment, you can always hold the vendor responsible when things go wrong. My recommendation is to determine what makes the most sense, depending upon business priorities, budget flexibility and the skill-set of your IT organisation.
One of the hidden costs of open source software is with respect to the (im-)maturity level of the code. If the lack of software maturity results in delayed implementations, or other unknown operational problems, well this can add to overall general frustration and higher costs of management. In the open source community, there’s a tendency to see open source and its potential detached from financial reality. However, I’ve since come to realize how important the right investment in people/hardware/training can push projects forward for the benefit of all.
When talking about the community in open source software, we have to clarify the different types of users that comprise the community. The largest part of the user community - perhaps even 90% - are not open source developers, or contributors, but rather open source consumers. They contribute to the maturity of the code by using it in a variety of scenarios and use cases, they ask good questions. However, they’re essentially relying on the remaining 10% who are fellow developers to point them in the right direction with ideas, answers to tough questions, and the real effort of auditing the code for bugs and potentially even working on code fixes and other contributions.
At one point or another, when the project meets the needs that it was designed for originally, positive user feedback is what keeps it going. A couple of nice words from a user whose work/project/task has been changed by your project give you the motivational fuel for another 6 months of 24/7 coding.
Real world examples include what Daniel Cid did (mostly single-handed) with OSSEC or what Fyodor has done with NMap. Get a list of potential problems you might run into with the software and present it to the developers/user forum. Good signs are “interesting problems, we can help with many of them but some would need extra coding/some changes”, “I’d have to test that out” or “talk to XXXXX, I think he had a similar project 2 years ago”.
I am often asked, are there certain security capabilities that you wouldn’t want to trust to open source? Actually the right way to formulate this question is: “are there certain security capabilities that you would want to trust to closed source software?” What’s great about open source is that you can take a peek at the source code to truly understand what it really does, how it works, how it was designed, whether its design matches its intention, etc. All of this gives you the trust and confidence you need to know what to expect when you use the software.
Posted by Dominique Karg, Chief Hacking Officer and co-founder of AlienVault