4 X Security Team

Guest editorial by Roger Thornton

Last week, Fortify published a study on adoption of security best-practices within the Open Source community. Given mounting risk posed by extensive use of Open Source technologies within business and government IT, we were gratified to see the passionate discussions that followed.

Unfortunately, much of that debate was simply a rehash of tired old themes that we must move beyond to make substantive progress in assuring security of Open Source software. These debates reveal the underlying problem: a lack of understanding and collaboration between developers and security experts – today each are talking past each other when it comes to security.

Three all-to-familiar debates have resurfaced:
1. The naïve notion that a software package’s “Open Source” or “Commercial” basis will somehow have an impact on whether it is secure or not.

This week the old “Open Source (or Commercial) software is more secure” feud rose again. The fact is, any development team that accepts security as an engineering objective can deliver it just as they can functional, quality, or performance objectives. Security is a choice not a birthright. It does not come ‘for free’ because of the way you license your product. However, if security objectives are not clear and secure development methodologies are not in place, it’s a pretty safe bet that security problems will result.

Does the Open Source or Commercial software world have an exclusive on building things right? Of course not. Over the last decade,we have worked with hundreds of development organizations establishing, and in many cases, defining, engineering processes that assure application security. Originally limited to the elite world of global banking and military, we now see a broad range of organizations joining these ranks. Ironically, this is an area where the IT development community is ahead of both the Commercial and Open Source, leaving neither bragging rights on which is most secure.

2. The erroneous idea that eliminating security flaws is a distraction and somehow less (or more) important than tackling functional, quality or performance issues.

We have heard the argument that vulnerabilities are just another bug in the code. Emblematic of this viewpoint was Linus Torvald’s recent rant. The fact is, quality and security are not the same; both important, but not the same. Poor quality is obvious to the user who genuinely wants your software to work. Security is an invisible property to all but an expert who is intent on harming your system. QA is a positive testing exercise (ensuring software does what its supposed to do) focusing on the “mainline” placing less emphasis on “corner cases”.

Security Assurance is often a negative testing exercise (ensuring software does not do what it is not supposed to do) where the corner cases are certain to be explored by an attacker. Quality Assurance depends heavily on alpha, beta, and GA users to report problems. Outside of a small group of security researchers, there are few cases of hackers filing bugs on vulnerabilities. I could go on for several pages, but I think the point is clear: quality and security (and performance, and features for that matter) are important and should be represented equally in a sound engineering practice.

3. The reflexive accusations that any security comments on Open Source software is an affront to the entire Open Source movement and similar to “yelling fire in a crowded theatre”.

There are definitely case of bad behavior with security “researchers”, with no intention of fixing problems, pointing out specific vulnerabilities for a taste of short lived fame — what Marcus Ranum calls, “vulnerability pimping.” Developers naturally react negatively to this kind of grandstanding. Unfortunately, we have also reached a state where even the most rational productive discussions around security and Open Source result in a loud cry of foul. The best of these discussions sound like a mother nagging a teenager to clean their room. That must change and become a collaborative inquiry into how we can do better. This starts with development organizations taking responsibility for security and security experts productively helping them achieve their goals.

As the sponsors of Java Open Review, Fortify supports the ongoing security assessment and remediation of over 100 open source projects –without publicly disclosing a single issue. We do this because we have a vested interest in ensuring that 3rd party components used by us and our customers are secure. We use many of these components ourselves in systems with extreme security requirements. Our customers build financial systems that entire economies depend upon, military software with life and death consequences hanging on data integrity, and all build systems that are critical to their organization.

At Fortify, we know the solution is developers and security experts working together to build software right from the start. We are already working with several projects in the report and look forward to proving that security experts and software development teams can work together effectively.

* Roger Thornton is founder and CTO of Fortify Software. Prior to founding Fortify Software in 2002, he led key development efforts at E*TRADE, guided a major architecture redesign effort at eBay, and served as an interim executive and investor to a number of other successful startups.

[Source: zdnet]