According to a recent survey, security and quality are two of the top reasons enterprises leverage open source...
software in the workplace. Yet, after the events of Heartbleed, many organizations are looking at open source software with a wary eye.
Certainly the discovery of the Heartbleed flaw has reignited the highly emotive debate on the security of open source versus closed source or proprietary software (CSS). The main argument given for open source software being the more secure approach is Linus's Law, which states, "Given enough eyeballs, all bugs are shallow." Put another way, with a sizable developer base, almost every problem and fix should be obvious to someone. The open source Linux operating system, for example, benefits from improvements and fixes as developers from around the world contribute changes at a rate of nine per hour.
However, the problem with OpenSSL, the open source software that was at the heart of the Heartbleed flaw, is that while it may be widely deployed, it turns out it hasn't been widely supported.
The Heartbleed flaw didn't occur because OpenSSL is open source, it happened because the project wasn't given the support it needed.
In this tip, I'll discuss the truth about open source software security, what all enterprises can learn about open source safety from the Heartbleed flaw, and tips for deploying open source software securely in your organization.
Open source software security risks explained
Just because a program's source code is publicly available doesn't mean that there are enough dedicated people who truly understand it, and who can regularly review and test it. Despite OpenSSL being used by an estimated two-thirds of the world's Web servers, clearly no one (until recently) thought to review the code to see if it really was still safe -- hence the Heartbleed flaw went unnoticed for a couple of years. Even so, many would argue that the open source model worked because the flaw was found and fixed, and that this type of review and remediation is not possible with closed source code.
Running unsupported software breaches many regulations and standards, yet thousands of major enterprises have been happy to deploy critical security software from the OpenSSL project, even though it only receives around $2,000 a year in donations and only has one full-time employee. These resources are nowhere near enough to properly sustain the manpower levels needed to support such a complex software product. Other open source projects, such as Linux or OpenStack, typically have full-time staff from some of the enterprises that use the software and who are dedicated to working on the project in some way, as well as sharing code across the entire community.
It's important to note that the Heartbleed flaw didn't occur because OpenSSL is open source -- it happened because the project wasn't given the support it needed. For that reason, the OpenSSL Software Foundation is now asking for money to help fund its efforts to regularly review its code and document changes, reduce complexity and maintain better communication with its community. In particular, it's asking for help from commercial companies and governments that use the critical security library extensively and have long taken it for granted. It will cost millions of dollars to fix the Heartbleed flaw, when only a few thousand dollars to support its development may well have avoided the problem. Thankfully, industry leaders -- including Facebook, Google, IBM and Microsoft -- have joined forces with the Linux Foundation to form the Core Infrastructure Initiative, which aims to improve the funding and development of core open source technologies, including OpenSSL. While this funding will invariably help the open source model, enterprises must rely on testing -- not faith -- when leveraging it in their organizations, and that goes for any type of software, whether it be open or closed source.
Open source software security best practices
The key lesson enterprises should learn from Heartbleed is that they should never rely on someone else's assurance that software is in fact secure. Enterprise security teams must conduct their own risk assessments, testing to ensure that the code or component is secure against the most common and pertinent threats their infrastructure faces. These teams should also document all assumptions so others can validate them. Part of any assessment should include an analysis of how quickly patches are issued once vulnerabilities become known, and how the patches are given. With open source software in particular, there needs to be a mature community with a clear policy about how contributions are evaluated and included, as well as a reliable regime in place to handle errors or problems. Case studies of trouble-free, real-world deployments are of more value than claims of how many times software has been downloaded.
Software issues are not only associated with open source software. When it comes to closed source commercial software, enterprises should look for evidence of some form of secure development lifecycle framework being used. Query vendors about the software development lifecycles and ask for documentation. Those with sound, security-focused development processes won't be afraid to share details, or at least refer enterprises to development managers who can attest to the product's integrity.
Whether enterprises leverage open or closed source software, it is critical that they also build their infrastructures assuming that at any given time a component could fail or suddenly become a weak point. This means also understanding the dependencies between components so they can be swapped out should the need arise.
Building to survive failure will minimize the threat of future software flaws -- open or closed -- that are putting enterprises and their data at risk.
About the author:
Michael Cobb, CISSP-ISSAP, is a renowned security author with over 20 years of experience in the IT industry. He has a passion for making IT security best practices easier to understand and achievable. His website http://www.hairyitdog.com offers free security posters to raise employee awareness of the importance of safeguarding company and client data and of following good practices. He co-authored the book IIS Security and has written many technical articles for leading IT publications. Mike has also been a Microsoft Certified Database Manager and registered consultant with the CESG Listed Advisor Scheme (CLAS).
Review the fundamentals of a secure software development lifecycle model.
Learn how to develop software securely from expert Gary McGraw.
Michael Cobb, Application Security asks:
Has your view of open source software security changed in the wake of Heartbleed? How so?
0 ResponsesJoin the Discussion