Thursday, September 29, 2005

Open Source Security in the Enterprise

This morning I briefed a client on the results of a Network Security Monitoring Assessment I performed for them. I model my NSM Assessment on the NSA-IAM, which uses interviews, observation, and documentation review to assess security postures. My NSM Assessment uses the same techniques to identify problems and provide recommendations for improving intrusion detection and NSM operations.

During one of the briefings the top manager asked for my opinion on using open source security tools. He wanted to know the guidelines I use to determine if an open source tool is appropriate for use in the enterprise. I told him I am more likely to trust open source products that are developed by companies with whom I have a relationship of some sort (like Snort and Sourcefire, Nessus and Tenable, or Argus and Qosient).

I was wondering what sorts of suggestions you might have governing open source security tools. The intent of the manager's question was to assess how I end up "trusting" open source tools. I believe the commercial tools should not be trusted simply because they are commercial, in an age where programming can be outsourced to parties ultimately unknown. What are your thoughts?


Saar Drimer said...

You raise a good point: open source versus unknown [out]source. It must be difficult to bring that point across when talking to a manager trying to find a "trusted" product, isn't it?
Sorry, I answered with a question, but I don't have much more to say :)

Anonymous said...

Richard: It's quite sad to see this mentality still in the marketplace, because management seems to think that if they pay money for a support contract (or buy a proprietary product), they have someone to blame later should the need arise. Last time I checked, the major software vendors (Microsoft comes to mind) don't necessarily jump through hoops to resolve problems for customers, even if they have a paid support contract. So, this could really only apply in some cases (not all) where there is some established relationship.

On a similar topic, could FreeBSD also be considered a security tool? I'm sure Nessus, Snort, and Argus don't run without an operating system :-). Last time I checked, however, there wasn't a 'company' to point your finger at should FreeBSD pose problems of some sort.

I like to help managment understand things in a different way. Apache and Samba COME with Sun Solaris; does that make these products any different because it was bundled and not downloaded? Managers would be better off taking lots of those 'support contract' dollars and 1) Hiring good people who 2) Can attend training. Every time I've been on the phone with a vendor...rarely are they with me at work resolving the issue.

Benjamin Schweizer said...

Assuming that you've no trackbacks enabled, here's my answer:

Anonymous said...

Wouldn't Common Criteria Certification of level 3 or higher of a commercial tool at least provide some validation to you that the toolset have been vetted out at least to a minimal standard?

I agree that you should trust tools you work with and have a relationship with to some degree, but that is based on each individual not necessarily to the tool. What you can do with a hammer and nails and what I may be able to accomplish could be the difference between a tree house and a village.

Tools are simply a means to facilitate an end, it is the process, procedure and talent that take the tools and help build a solution.

Sergio Caltagirone said...

While the common criteria has been a positive step in software security validation, it fails in many respects and many researchers are already searching for a replacement - Win2k is EAL 4 (of course this only applies to software process documentation and not code or operation validation). It provides a false sense of security to managers and is a tool used by marketers if a true security analyst is not brought into the process. I think that relying exclusively on the CC is a mistake - but I agree with the previous poster that it is a starting point (but only if examined in context to the protection profile).

I think that most security professionals understand that choosing which piece of software to run - be it open or closed source - is a holistic process. We (at least I) rely on: the maturity of the software, the userbase, whether the organization or company producing the product has a positive or negative reputation, the "marketingness" of the documentation, searching SecurityFocus and other sites, and recommendations by people I trust. Software security, as of right now, in the end is a human trust relationship and not a scientifically valid process.

It is difficult to get managers to understand this - their job requires metrics - but the software security community is not yet at a point to sufficiently answer this question to the satisfaction of managers. This is why I think most still feel that closed source software is more secure, because there is a human trust relationship with the company. My $.02

John Ward said...

Management typically sees things in project scope, not the overall picture. Management sees proprietary solutions as less costly than having to train the existing IT staff (who they blame for needing the security product in the first place), or hiring an expert on staff for a salary well outside their budget. To them, they pay the one time cost for shiny box security product and get the support of the company behind it.

Also Open Source is unfortunately an easy target these days. Sales forces for proprietary products only need to put certain spin on Open Source to make managers lose all trust in it and feel that the vendor is looking out for their best interest. Example, point out certain notable people in the Open Source community with questionable behavior (ESR comes to mind), or put a spin on incidents such as Tenable changing to pay for plug-in in Nessus and portray it as a bait-an-switch tactic.

I am actually surprised that said manager even asked about trust in Open Source. I believe that Rich gave a good answer in showing trust in the vendors who work to build the product, and show that there are companies out there who do support the Open Source products. Most companies will pay just to have a throat to choke when something goes wrong.