Most security professionals are probably very comfortable with using open source tools to implementtechnical 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 atimeliness advantage to open source. Specifically, when we discover a significant security risk to theorganization, 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 equivalentto 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 asused to thinking about the security of open source.
Practical Security
By this, I’m not talking about security advantagesof open source vs. closed source at a “philosophical” level — i.e., more eyes on the code, transparencyin 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 byour business and technology partners.
In deploying any application, it’s part of the security team’s mandate to ensure that applications (COTSand otherwise) don’t negatively impact the firm’s security posture. While it’s true that open sourcesoftware can have some security advantages — e.g., greater public scrutiny of the code base — that doesn’tmean we can forego this due diligence. “Security advantages” don’t necessarily mean our shopis deploying in a secure way.
For example, OpenBSD is designed to be secure by default — but if I postthe root password of my server to Facebook, that installation ceases to be secure no matter how wellthe underlying software might be written.
The point is, it’s important that organizations think through this specifically to enable them to consideropen source alternatives. You’d be surprised how often organizations try to blindly follow processesdesigned for closed source and find themselves hamstrung when they want to adopt an equally suited — not tomention 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 mightalready do for new closed source apps — e.g., most commercial.
Perhaps you start by doing a reviewof the vendor’s financials to make sure they won’t go out of business right after you deploy. Thenmaybe 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, howit 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 orcritical business processes.
Obviously, there are a number of other factors that you might evaluate as part of your organization’sspecific process — and there are as many ways to do this as there are organizations themselves. But onething that’s probably clear by looking through the — granted, cherry-picked — sample steps above is thatnot 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 behoovessecurity 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 toones that are more appropriate for open source by considering the intent of each step and selectingsomething analogous for an open source project.
For example, if you currently do a financial review ofthe vendor when purchasing a COTS app, you’re not doing this out of mere curiosity. Instead, you do itbecause you want to make sure the product will stay supported over the long haul.
For an open sourceproject, look at something that satisfies the same goal — for example, the activity level and communitysupporting it. A project with hundreds of active developers and thousands of active users is likely tohave staying power. One that has two developers and hasn’t been updated since 2002? Probably lessso.
From an architectural standpoint, if you currently grill the vendor on its security model andproduct architecture, consider instead targeting those same questions to your internal technical teamsresponsible for the configuration and deployment. Open source projects are generally designed to beflexible and facilitate customization, so detailed questions about what configuration is planned and anycustomizations made for your deployment are helpful.
Pay special attention to the post-deployment operations tasks as well. If the project in questionreleases “early and often,” make sure that operational processes have some way to accommodatethis. Evaluate the knowledge base within your own technical teams to ensure that you have sufficientdepth 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 thatprovide support specifically for often-deployed open source projects. So, if support considerations area 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 bridgesuccessfully. But for those organizations that are late in capitalizing on the many advantages affordedby open source software in the enterprise, spending time thinking through these minor complexitiesnow is well worth any extra effort.
Loading ...
