Secure development lifecycles sound good: processes to ensure that developers create software more securely from the start. But doing so does increase the cost of the software and the time to complete development projects. Let’s catch up on its progress: Who’s using it, and why?
Secure Development Lifecycles (SDLs) are development lifecycle methodologies to address security vulnerabilities, designed to carefully write, test, and fix code from creation through end-of-life. Nearly a decade ago, vendors started developing methods for insinuating security into their software development lifecycles to confront increasing security threats. Since then, vendors and organizations developing SDLs have continued to release their methodologies to the development community.
Three years ago, I wrote an article, Are Companies Actually Using Secure Development Lifecycles?” reporting on the progress of SDLs in the development marketplace. The short answer to the title question was that while some companies were using these SDLs, most were not. While there have been changes in three years, none are earth-shattering metamorphoses.
According to Adrian Lane, CTO of information security research and advisory firm Securosis, most SDL adoption is in large enterprise computing where businesses have more to lose and where the businesses do more of their own software development.
Smaller and mid-market enterprises do not pay as much attention to SDL. First, Securosis found, it isn’t always relevant. Some small to mid-sized organizations primarily rely on commercial off-the-shelf software and do little custom development. Other small to mid-sized organizations that do software development have few resources to work with. They release new software “features” instead of doing any secure coding. “That’s why the majority of the SDL discussions we have are at the enterprise level: because they’re the ones that have the infrastructure that [Advanced Persistent Threats (APTs)] are targeting,” says Lane.
In some markets, the assumption is that money doesn’t need to be invested in secure coding efforts because APTs are not motivated to funnel money out of the businesses. Supervisory control and data acquisition (SCADA) systems are a good example. “There is no revenue gain for an attacker to go after with SCADA,” Lane explains. Without money rewarding an attacker, he says, there is no reason for the operators of those systems to rewrite software to make it secure.
In general, things change only when something with a high-enough impact happens to force the change.
“Looking at changes to security over the last 15 years. We’ve seen things like the Melissa virus and the Slammer worms; both of those were high enough impact and high enough visibility that they forced every single organization to buy [anti-virus software],” says Lane.
The second highest growth factor in security technology adoption is caused by compliance requirements. PCI is still a driver of some SDL adoption, but mostly impacts Web application firewall (WAF) sales and adoption. This is still the trend for many companies when they find bad code after the fact: Use a WAF to protect the application rather than re-code the software. As a result, Securosis found, most of the software testing and SDL development is happening in the Web application market, which has the largest threat of vulnerability and attack.
PCI changed how organizations secure their data. “That caused a pretty big shift in the market, a six to ten percent a year buying uptick in certain [security] product categories,” says Lane. But even PCI requirements gave organizations options: either do secure software development or put in a web application firewall. “I think the intention was for us to do both, but most organizations simply bolted on a WAF because it got them compliant quickly without the cost of SDL,” says Lane.
And the SDL Winner is…
The industry making the most headway in secure software development is finance. “The finance vertical is way ahead. They do far better on not only identifying issues but their time to fix is also far less than, let’s say, the retail vertical,” Lane says.
Microsoft’s Steve Lipner agrees. Lipner, Partner Director of Program Management for Microsoft Trustworthy Computing, says, “The Financial Services Roundtable, of which BITS is a sub-group, represents 100 of the largest integrated financial services companies providing banking, insurance, and investment products and services to the American consumer. They recently announced that The BITS Software Assurance Framework has successfully incorporated many of the key elements contained in Microsoft’s SDL.”
That’s not to say SDL is being ignored in other market segments, or that security isn’t considered during the development process. It’s just difficult to measure. Some software testing is going on in the architecture phase, which is harder to see and harder to quantify, says Lane. “You’re talking about design level changes, you’re talking about threat analysis during the design or architecture phases of the software development.” Securosis sees a lot of dynamic applications and security testing / dash testing; WAF usage is about as high as it was three years ago but has leveled off.
Also, a lot of companies consider WAF as part of their development process, since SDL does not accommodate every security bug, says Lane. These organizations put out a known signature or do some sort of a virtual patch with the WAF or maybe even with the database security product to take care of the threat until it is coded in. “In many cases it is never coded in,” Lane concludes.
Counting SDL Costs
Critics say that the costs of coding software securely from the start raise development costs, slow delivery dates, and raise the software’s price. Others take the view that the rise in costs is only temporary. “If you have more requirements, meaning security, and then you’re going to write tests to make sure that you are fulfilling those security requirements and you’re going to perform tests on an ongoing basis, what you end up seeing is a burst of cost,” says Lane.
These developers need to identify these requirements, implement them, write the unit tests and the regression tests, and make sure that they’re passing or meeting the security requirements. There will be some additional costs from all this, as well as time investments. “You’re altering document flows. You’re altering your process,” says Lane. “You’re buying tools to track with and you are implementing Agile in some cases. All of these things are a disruption of the status quo.”
But at some point it simply becomes another task. “It’s not like suddenly your development costs are going to go up by 50%. And at some point you start amortizing those costs over the lifespan of the software,” Lane adds.
SDL implementation does require an upfront investment in training and new processes. “The return on investment once completed is not only more secure software,” says Microsoft’s Lipner, “but potentially upwards of a 20% improvement in programmer productivity, as reported by organizations whose results are detailed in case studies we’ve done.”
Companies can find ways to afford the changes in training and processes. “Managing vulnerabilities at the right stage of the software development lifecycle can save dramatically on total development time,” says Lipner.
Current and near term drivers are pointing to increasing SDL adoption. “The growing acceptance that security has to be integrated rather than bolted on is probably the biggest factor driving the use of better security practices,” says Lipner. That’s in addition to the increasing cost of software breaches and evidence showing that software security is ultimately a good long term business strategy.
Importantly, customers are refining their tastes in what is acceptable software. “We are also seeing increasing demands from customers for more secure software. The only way to conclusively demonstrate a commitment to building more secure applications is through a transparent process like the SDL,” says Lipner.
About the author
David Geer is a computer technician turned technology writer who has covered coding for the IEEE. You can follow David on Twitter.