Refining Due Diligence for Enterprise Open Source
There are differences in how you evaluate open source applications, and it behooves security organizations to think through those differences and plan accordingly. Why does it matter? Because those differences can sometimes gate or slow down the adoption of a perfectly serviceable tool -- like if you have inflexible corporate software acquisition policies that mandate non-applicable steps.
07/24/12 5:00 AM PT
Most security professionals are probably very comfortable with using open source tools to implement technical security functionality. From nikto to snort to openssh -- there are literally hundreds of well- known, sophisticated, open source tools that perform useful and critical security functions.
There are a number of advantages: Besides the obvious allure of low-cost, highly customizable software, there's a timeliness advantage to open source. Specifically, when we discover a significant security risk to the organization, the time to address that risk is right now: The attackers won't wait for us to get budget, engage legal to review a purchasing contract, haggle with a vendor's salespeople, etc.
There's also, in many cases, a quality advantage: Open source tools can be -- and often are -- not just equivalent to commercial products. Sometimes they're flat-out better.
So we're probably used to thinking about open source software for security, but we're maybe not as used to thinking about the security of open source.
By this, I'm not talking about security advantages of open source vs. closed source at a "philosophical" level -- i.e., more eyes on the code, transparency in auditing, etc. -- I'm speaking more practically. Specifically, I'm talking about the mechanics of predeployment security reviews, or security due diligence, of the open source solutions being deployed by our business and technology partners.
In deploying any application, it's part of the security team's mandate to ensure that applications (COTS and otherwise) don't negatively impact the firm's security posture. While it's true that open source software can have some security advantages -- e.g., greater public scrutiny of the code base -- that doesn't mean we can forego this due diligence. "Security advantages" don't necessarily mean our shop is deploying in a secure way.
For example, OpenBSD is designed to be secure by default -- but if I post the root password of my server to Facebook, that installation ceases to be secure no matter how well the underlying software might be written.
The point is, it's important that organizations think through this specifically to enable them to consider open source alternatives. You'd be surprised how often organizations try to blindly follow processes designed for closed source and find themselves hamstrung when they want to adopt an equally suited -- not to mention lower-cost -- alternative.
What's Different About Open Source?
With that in mind, let's unpack some of the predeployment security evaluation tasks that you might already do for new closed source apps -- e.g., most commercial.
Perhaps you start by doing a review of the vendor's financials to make sure they won't go out of business right after you deploy. Then maybe you review the contract/licensing language to analyze vendor liability, if any.
Perhaps you do a technical architectural review of the system in context: looking at the component architecture, how it interacts with and communicates with other systems, what security features it supports natively (e.g., encryption, authentication, attack resilience), and where and how it will interact with sensitive data or critical business processes.
Obviously, there are a number of other factors that you might evaluate as part of your organization's specific process -- and there are as many ways to do this as there are organizations themselves. But one thing that's probably clear by looking through the -- granted, cherry-picked -- sample steps above is that not all of those steps translate well to an open source context.
The point is, there are differences in how you evaluate open source applications, and it behooves security organizations to think through those differences and plan accordingly. Why does it matter? Because those differences can sometimes gate or slow down the adoption of a perfectly serviceable tool -- like if you have inflexible corporate software acquisition policies that mandate non-applicable steps.
If that happens, you have two choices: Violate policy and open yourself up to possible audit events, or -- assuming your process even allows it -- take on paperwork-heavy exception reporting.
What Might You Consider Instead?
One way to approach this is to create a parallel review process and "translate" existing steps to ones that are more appropriate for open source by considering the intent of each step and selecting something analogous for an open source project.
For example, if you currently do a financial review of the vendor when purchasing a COTS app, you're not doing this out of mere curiosity. Instead, you do it because you want to make sure the product will stay supported over the long haul.
For an open source project, look at something that satisfies the same goal -- for example, the activity level and community supporting it. A project with hundreds of active developers and thousands of active users is likely to have staying power. One that has two developers and hasn't been updated since 2002? Probably less so.
From an architectural standpoint, if you currently grill the vendor on its security model and product architecture, consider instead targeting those same questions to your internal technical teams responsible for the configuration and deployment. Open source projects are generally designed to be flexible and facilitate customization, so detailed questions about what configuration is planned and any customizations made for your deployment are helpful.
Pay special attention to the post-deployment operations tasks as well. If the project in question releases "early and often," make sure that operational processes have some way to accommodate this. Evaluate the knowledge base within your own technical teams to ensure that you have sufficient depth of knowledge to ensure continued support should attrition impact subject matter experts.
Also, think through support options. Depending on the project, there are often firms you can engage that provide support specifically for often-deployed open source projects. So, if support considerations are a make-or-break part of application acquisition, you may still have options available to you.
Granted, none of this is rocket science, and some organizations have already crossed this bridge successfully. But for those organizations that are late in capitalizing on the many advantages afforded by open source software in the enterprise, spending time thinking through these minor complexities now is well worth any extra effort.