The ISO/IEC 27034-1, "Information technology -- Security techniques -- Application security" standard released in the fall of 2011 until this week mostly had remained in the obscurity of the standards community, when Microsoft announced that its Secure Development Lifecycle (SDL) framework and strategy for secure coding conforms with the ISO standard. SDL was already referenced in the standard as an example of a secure development process that can help software developers conform to ISO/IEC 27034-1.
The ISO standard is a broader specification that includes requirements for secure development and processes, says Tim Rains, director of Trustworthy Computing for Microsoft. "If you're already doing SDL, you are well on your way to ISO certification," Rains says.
"It's the first [standard] of its kind that focuses on processes and frameworks for secure development programs," Rains says. "For businesses that sell software, it's a common language for secure development practices ... For customers purchasing software, we think this single standard language is very positive because it simplifies things" for their procurements, he says.
Microsoft has led the way in promoting secure code development, offering up its framework and some free tools for organizations that want to adopt such a program in-house. Even so, not many enterprises are building security into their software: In new data released by Microsoft this week, only 37 percent of IT professionals and developers are doing so, and 61 percent aren't employing existing attack mitigation technologies, like DEP and ASLR, in their applications.
"It was somewhat surprising to see a very small number of developers leveraging these mitigations. This is concerning," Microsoft's Rains says. "We think criminals continue to flourish in an ecosystem that doesn't prioritize secure coding."
Why the new attention over nearly two-year-old standard for secure software development? Supply-chain concerns are the likely catalyst, says Chris Wysopal, co-founder and CTO of Veracode. "Enterprises and government organizations are waking up to the fact that they have a supply-chain problem with software vulnerabilities. They're starting to say, 'What are we going to do about this? How do we hold the vendors accountable?'" Wysopal says. "Software liability is not going to happen, regulations are not going to happen."
The only way for organizations to hold vendors accountable for their software security is testing and, now, with a global standard. "The traditional way is to assess the software and test it," Wysopal says. "The market is starting to question what vendors are doing to write secure software. And [vendors] are looking for a way to demonstrate it."
[New data shows that the elimination of the infamous SQL injection software flaw has basically plateaued, reflecting the long, hard journey that secure software is still traveling. See The Long Road To Secure Applications.]
Jim Reavis, president of Reavis Consulting Group LLC, says ISO 27034-1 is significant because it's the first vendor-neutral standard spelling out the elements of a secure coding program. It's "a full program approach to secure coding versus a piecemeal focus on specific areas or tools," says Reavis, author of a new ISO 27034-1 whitepaper commissioned by Microsoft.
"Any time you get an international standard like this, it not only raises awareness and provides guidance for practitioners, but most significantly, it becomes an area of due diligence that regulators, auditors, and others will look to enact to assure impacted companies have a defensible security program as it relates to software development," Reavis says. "I think the industry would ignore this standard at their own peril."
Getting a secure coding initiative off the ground requires the blessing of upper-level management, but it has been a Catch-22 of sorts to get C-level executives to better understand and support secure development.
"We need to get management approval to move forward with secure development in many organizations, so we need to help them make the case to management on why secure development is important," Microsoft's Rains says. "This is where we think standardization and compliance can play a role. Standards can help the C-suite and IT decision-makers better see the upside to" secure coding, he says.
Veracode's Wysopal says the ISO standard could definitely be used in-house by enterprises. CSOs could require internal developers and vendors comply with ISO/IEC 27034-1.
And for organizations purchasing software, the ISO standard can be used as a measuring stick. "It gives customers a way to identify suppliers that are committed to secure development practices," Rains says.
Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.