Gary McGraw is CTO at Cigital, a software security and quality consulting company, and the author of the Software Security Library. He can be contacted at http://www.cigital.com/gem/.
Building secure software isn't as simple as adding cryptography and authentication. Nor is it a matter of plunking down a firewall in front of your Web apps. It's about adjusting the software development life cycle, teaching developers about security, choosing the right tools and techniques for writing code, and adapting the development culture to care about security. Each of these activities is made easier and more doable with not just careful planning but also objective measurement.
Many companies have large-scale software security initiatives. I know of 75 such efforts from my research alone. They cover a broad spectrum of industries, from financial services and independent software vendors to healthcare and energy providers. Any company that develops software or relies on it needs a software security initiative and metrics to measure its effectiveness.
Over the last decade, a number of software security methodologies have evolved, including Microsoft's Secure Development Lifecycle; the Comprehensive, Lightweight Application Security Process, part of the Open Web Application Security Project; and the Seven Touchpoints for Software Security. All are grounded in good software engineering and require attention to security throughout software's life cycle. Companies must understand common risks, design for security, and subject all software artifacts to thorough, objective risk analyses and testing.
What's Really Happening
That's what companies ought to be doing anyway. For a look at what they're actually doing, BSIMM -- short for Building Security In Maturity Model and pronounced "bee-sim" -- is an extensive research effort under way to analyze software security activities of companies such as Adobe, Bank of America, Capital One, EMC, Google, Intel, Microsoft, Symantec, VMware, and Wells Fargo. I'm one of the researchers.
BSIMM currently describes the work of 635 people in 30 companies who together have 130 years of experience working on software security. The success of these companies' programs hinges on having an internal group devoted to software security. The average size of these groups at BSIMM participants is 22 people, helped by about 40 others -- developers, architects, and people directly engaged in and promoting software security. These companies have an average of 5,061 developers -- so around 1% of the development team is directly promoting security.
BSIMM delineates 109 activities, such as getting upper management buy-in when it comes to compliance and privacy, and protecting the integrity of software by using code signing. These activities are organized in 12 categories such as compliance and policy, code review, and security testing. The 12 practices are divided into four groups -- governance, intelligence, touchpoints, and deployment; see Table 1. For BSIMM's most recent study, researchers counted each time they observed one of the 109 activities.
The greatest value of BSIMM is in measuring and comparing software security initiatives among companies in different industries. To give you some idea of analysis capabilities provided by the BSIMM, Figures 1 and 2 show the average maturity level over some number of organizations for the 12 practices.
Figure 1 shows data from all 30 BSIMM firms, while Figure 2 shows data from the top 10 firms (as determined by recursive mean score). In Figure 3, we calculated the level of activity in each of 12 practices for a company, then we average those scores for companies in the same industry. We've done this for financial services companies and ISVs in Figure 3.