Secure Application Development Report Expands Security Framework

A group of security pros offers a framework for comparing your secure application development practices with security initiatives from top companies. This year's report contains information from 30 organizations, including Intel, Bank of America and Microsoft.

A team of security researchers has released a report laying the groundwork for enterprises to compare and assess the security strength of their application development processes.

The report, Building Security in Maturity Model 2, describes 109 activities carried out at organizations such as Intel and Bank of America as part of their secure development life cycle. All told, the report covers software development practices at 30 enterprises, and according to the authors is intended to provide benchmarks for companies concerned about application security.

"The biggest problem for a lot of organizations is simply getting started, or pulling together the small, disparate activities that were going on into a real software security initiative," said Sammy Migues, a principal at Cigital and co-author of the report. "Everyone we talked to said there were a couple of things that really made that happen. One ... was making somebody responsible for the problem."

All 30 of the organizations examined by Migues and co-authors Brian Chess of Fortify Software and Gary McGraw of Cigital had an SSG (software security group), though the size of the teams varied. The teams need to go beyond finding bugs, however, and should include people with good communication skills capable of mentoring, training and working with developers within the organization, the report contends.

"At the highest level of organization, SSGs come in three major flavors: those organized according to technical SDLC [secure development life cycle] duties, those organized by operational duties and those organized according to internal business units," the report said. "Some SSGs are highly distributed across a firm, and others are very centralized and policy-oriented."

"This is a more controversial point in the world than you might guess it is," said Chess, chief scientist at Fortify. "Not everyone agrees that you need to have a dedicated software security team, but everybody we observed in this set has one."

As for the model itself, it covers four domains: governance, intelligence, secure software development life-cycle touchpoints and deployment. Among the activities involved are actions in areas such as code review, creating attack models, developing security metrics and training developers.

"There are three levels of activities that we have observed out there," said McGraw, CTO of Cigital. "Easy stuff, that's level one; stuff that may require level one stuff to be done before you can do it, it's a little bit harder, that's level two; and then rocket science, that's level three."

The activities are spread across the three levels. For example, there are seven activities under the penetration testing banner, with the most basic being the use of pen testing tools, conducting periodic tests and giving testers all the information necessary to do their job effectively.

In addition to the challenge of organizing software security efforts, many companies struggle with the development of security metrics, which they typically come up with on their own, Chess said.

"One of the things that I've discovered over the years is that metrics are kind of like internal organs," McGraw agreed. "Everybody needs a liver, but it's really hard to take my liver and put it in somebody else's body."

The report can be downloaded here.