Open source software is a unique risk

Businesses today are built and operated by software that houses intellectual property, business processes and trade secrets that are vital to the health of an enterprise. Organisations must address potential weaknesses in their everyday operations before they become exploitable.



It's the ultimate irony: The versatile software you depend on to run your business also puts it at risk. Your business applications hold the business processes and the data that form the lifeblood of your company. Yet, even as they open your business up to more customers and partners, the security holes your software contains leave you vulnerable to attack. Relentless and destructive data predators are ready to pounce. Today's hackers, organised crime cartels and enemy nations are highly adept at quickly turning security flaws into stolen data and cash. I'm not in the habit of finger pointing over flaws in packages – let's face it we all know that application bugs exist, the only real question is why?



Open source development introduces risk to your business in unique ways. The inexpensive and readily available nature of open source makes it easy to adopt. But at what cost to enterprise security?



A Fortify-sponsored open source security study published in July, completed by leading application security consultant Larry Suto, examined 11 of the most common Java open source packages. It confirmed that the most widely-used open source software packages for the enterprise are exposing users to significant and unnecessary business risk. The study validates that open source software (OSS) development communities have yet to adopt a secure development process and often leave dangerous vulnerabilities unaddressed. Additionally, it found that nearly all OSS communities fail to provide users access to security expertise to help remediate these vulnerabilities and security risks. The study sparked debate on a number of topics related to OSS that anyone in IT or enterprise security should understand. The response to the report set off some familiar refrains, which miss the point and don't get us any closer towards the goal of a secure enterprise.



What's more secure: open source or proprietary?



Improving the engineering process of building more secure code applies to every software project, whether it is open source or 'closed". It's not important who writes the code, but how. Any competent engineering team will be able to generate secure code if security is made a part of the design, just as they are able to bring a low cost solution to market, or a high performance solution.



From our vantage point, we see literally thousands of development teams, mostly within IT organisations for financial and other highly regulated industries, that have a very sophisticated process in place for application security. In the current open source model, yes, those of us who care about security can feed vulnerabilities back into the machine, or fix them ourselves, but it will never be as sound as building it securely in the first place.



Security and quality are the same



Recently, the icon of OSS development, Linus Torvalds emailed the Linux development team, weighing in on the quality vs. security debate. In his email, Torvalds argued that "In fact, all the boring normal bugs are WAY more important, just because there's a lot more of them." Although it is true to say that quality and security are both important, I strongly disagree with Torvalds for several reasons:



•Quality is cumulative whilst security is absolute.

•Quality is about making the main path of operation work, and accepting issues in the corner cases, whereas security must cover everything

•Quality is a closed problem however security is open. There is no list of known bugs you can go to and accept for security as criminals compile these lists and they don't share them. Quality is reinforced by customers in the open market.



Where is the path out of this forest? A Managed Risk Approach



Traditionally, companies have largely depended on "perimeter-based" approaches like network security to prevent data predators and criminals from gaining access to corporate information. However, the demands of today's open business environment weaken the protection provided by firewalls and other perimeter security efforts, leaving a corporation's applications easily accessible and vulnerable to hackers.



In order to mitigate the business risk created by insecure applications, it is imperative that companies adopt a process that allows them to assess, remediate and prevent security vulnerabilities in all of their business software, whatever the source. Business Software Assurance (BSA) is a growing industry trend that refers to technologies and techniques that enable you to maximise the flexibility, enhanced capabilities and easy availability of enterprise software without exposing your operations to attacks that can threaten your business. In short BSA answers the question "How do you know your business is secure?" By identifying and resolving your most critical application vulnerabilities you can enhance software assurance.



What next?



Ultimately, the solution is developers and security experts working together to build secure software right from the start. Fortify is already in discussions with open source providers with whom it is working to improve processes and I invite any open source group who would like to get involved in these conversations, and make security a part of the development process, to get in touch.



Our call-to-action for organisations that rely on open source software



Government and commercial organisations that leverage open source should use open source applications with great caution. Risk analysis and code review should be performed on any open source code running in business-critical applications, and these processes should be repeated before new versions of open source components are approved for use. Organisations considering open source software must thoroughly evaluate open source security practices. We recommend using the standards we recommend below to open source communities as a checklist. In addition, enterprises should:



*Raise security awareness within open source development communities and emphasise the importance of preventing vulnerabilities upstream. Enterprise security teams should articulate their security requirements to open source maintainers to accelerate the adoption of secure development lifecycles.

*Perform assessments to understand where your open source deployments and components stand from a security perspective.

*Remediate vulnerabilities internally or leverage resources which provide audited versions of several open source packages.



Open source projects should adopt robust security practices from their commercial counterparts. Open source development can benefit from private industry practices - notably those created by financial services organisations and larger ISVs. Open source communities can then advertise and substantiate effective security practices that blend process and technology. Best practices to consider include:



*People : Appointment of a security expert with the power to veto releases from getting into production - known as a gate model. Develop the expertise to conduct security activities and get security right.

*Process : Build security in by mandating processes that integrate security proactively throughout the software development lifecycle. Include relevant non-coding activities, such as threat modeling and the development of abuse cases.

*Technologies : Leverage technologies to get security right, which include static analysis in development and dynamic analysis during security testing in quality assurance.





Article written and provided by Richard Kirk, European Director of Fortify Software , which specialises in protection from security flaws in business-critical software applications.