Software Development Below the Security Poverty Line

[steven36]

A product manager approaches the security architect. “Please,” the product manager says, “I only have one or two more releases of this product before the program is cancelled. Won’t you please sign off on shipping without your security requirements so that we can afford to implement a few more features?”

 

 

They are operating below the security poverty line.

 

Wendy Nather coined the term “security poverty line” to describe how organizations operate when they have insufficient investment in IT security. The phrase stuck a chord with me immediately because it vividly describes the frustration of a how it feels to be a security person in an organization operating below the security poverty line like this. It applies equally to software development organizations as the anecdote above demonstrates. Wendy Nather and Andy Ellis expanded on what it means for an IT department to live below the security poverty line in their 2013 talk at RSA. In this article, we will explore the parallel path for a hypothetical software development organization.

 

Development teams living below the security poverty line are either unfamiliar with secure coding standards or haven’t taken the time to train other members of the development team. They don’t use dynamic and static analysis tools. They don’t have SDLC processes in place or if they do, the organization ignores them. Every vulnerability notification is an emergency. Basic security hygiene activities get deprioritized in favor of features that have a positive ROI.

 

A recent NTIA survey reports that 45% of U.S. Internet users are refraining from spending time and money on the Internet due to security and privacy concerns. This is a very logical response to a growing problem. Gartner reports that cybersecurity spending reached $75.4 billion in 2015, but in a recent survey by Barkly, 50% of the IT Security professionals surveyed expressed serious concerns about their ability to keep their systems secure. IT Security teams cannot keep infrastructure secure if they are tasked with deploying commercial software which ships with Heartbleed eighteen months after Heartbleed was found and fixed, as the recent Black Duck audit report shows is happening in 10% of the proprietary code that they analyzed.

 

Here is what it feels like to work on a team that is living below the security poverty line:

 

● An ambitious summer intern fuzzes the code and opens issues for the problems identified. These linger as technical debt since they are too low priority to actually fix until something bad happens

● The security team (if there is one) writes up beautiful SDLC documents and vulnerability handling processes but struggles to get them adopted (or even reviewed).

● The security team vets static analysis tools and picks one to adopt, but money and time are never allocated to acquire the tool, because as Bruce Schneier says, if there is no commitment to fix issues that are found, it is safer not to document the issues

● The security team has to proactively chase down technical specifications because the developers avoid talking to the security team because when they do, they hear a lot of negativity and it slows everything down.

● Developers pull in dependencies on open source to speed up time to delivery, but fail to adequately document and track the dependency, so they fail to update the product when vulnerabilities are found in the open source dependency.

● The security team identifies a vulnerability only to be told that the vulnerability will not be fixed because it is much easier to break the software in another way that has never been fixed. The organization accepted the risk for the second vulnerability so they will now accept the risk for the newly identified vulnerability.

● The security team secretly hopes that the legal team will shut everything down before things go wrong and they get blamed and fired.

These are the stories that security people tell each other like scary bedtime stories about the security Armageddon that is just about to happen, painting the picture of a development organization in need.

So how do we improve? In the RSA presentation, Nather and Ellis picked a $2000 price point for proposing potential IT Security improvements. When you apply that same concept to development organizations, here is what $2000 will get you:

● A substantial development desktop on which you can run open source tools such as OWASP ZAP, OWASP Dependency Check, PMD, or one of any number of linters and other security tools relevant to the language that you are using.

● Five subscriptions to Safari Books Online.

● Five licenses for Burp Suite Professional Edition.

● Three exam passes for the CSSLP with some money left over to buy books.

● Project management time to analyze your processes against the a relevant secure development maturity model such as OWASP SAMM, BSIMM, or the CII Best Practices Badge

● Developer time to attend free training in secure software life-cycle (6 hours) or secure development for web applications (10 hours) at Cybrary.

 

It is time for development teams to embrace the message that Nather and Ellis delivered to the IT Security teams: “Engage the business.” Ensure that basic security hygiene needs are being identified and dealt with and we can help the IT Security teams make progress securing the Internet.

 

The Source