New report offers low-down on secure develoment

A trio of security activists have come up with what they claim is the first systematic yardstick' developers can use to assess the quality of in-house software security initiatives.

Slideshow: 10 of the Worst Moments in Network Security History

The Building Security in Maturity Model (BSIMM), authored by Brian Chess of Fortify Software and Gary McGraw and (co-author) Sammy Migues of Cigital draws on detailed analysis of the security assurance programs undertaken by a clutch of leading US ISVs and corporations, including Microsoft, Adobe, EMC, Google, Qualcomm, and Wells Fargo, and Depository Trust & Clearing Corporation (DTCC).

To continue reading, register here and become an Insider. You'll get free access to premium content from CIO, Computerworld, CSO, InfoWorld, and Network World. See more Insider content or sign in.

A trio of security activists have come up with what they claim is the first systematic yardstick' developers can use to assess the quality of in-house software security initiatives.

Slideshow: 10 of the Worst Moments in Network Security History

The Building Security in Maturity Model (BSIMM), authored by Brian Chess of Fortify Software and Gary McGraw and (co-author) Sammy Migues of Cigital draws on detailed analysis of the security assurance programs undertaken by a clutch of leading US ISVs and corporations, including Microsoft, Adobe, EMC, Google, Qualcomm, and Wells Fargo, and Depository Trust & Clearing Corporation (DTCC).

Their report-style guide steers clear of coming up with simple do and don't' recipes, but does note a number of common themes that mark out the most mature security assurance programmes.

The top ISVs and enterprises all had a defined software security group (SSG), whose job it was to look after the security-development cycle, for instance, and all had a security training curriculum' for programmers that emphasised peer mentoring over policing and punishment.

The best designed assurance programs also employed extensive penetration testing using black box' testing tools, in an attempt to replicate how security design might be stressed under real-world conditions.

According to noted assurance expert and BSIMM author Gary McGraw, the tendency in the industry had been to "hide what they do."

"All the religions [assurance methodologies] have their high points and their low points, but they don't have a lot of evidence behind them," he said. "They like to do things in secret. Our objective is to transform software security from alchemy to empiricism."

Using a science-based analysis of the practices they found in the wide range of companies looked at, they had identified 110 separate assurance activities only 10 of which every company was doing.

Both McGraw and Chess advocated companies using the BSIMM as a comparison for their own internal development cycle.

"Virtually every organisation today relies on software to operate, and at the same time the threat to that software is at an all-time high," said Chess in the official release. "Businesses need software that doesn't leak millions of identity records, gin up huge legal liabilities, or allow secrets to fall into the wrong hands."

Security assurance lacks standards or even a common language which companies can use to plot common good practice and share their insights. The overwhelming importance of software security - removing weaknesses before they get baked into release code - has prompted attempts to break the herd silence.

The best-known assurance program is probably Microsoft's Software Development Lifecycle (SDL) in which the company invested considerable effort in the light of the security weaknesses that plagued Windows XP after its launch in 2001. Nevertheless, what holds true for Microsoft and Windows developers is only of so much interest to developers in other areas.