05:05 PM

Real-World Software Security

BSIMM compares your secure development efforts to others' By Gary McGraw

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; the Web Application Security Consortium; 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 box, p. 44). 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 do this, 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 the chart at left.

By creating spider charts like these from the BSIMM data, it's possible to compare and contrast how an industry approaches software security. Not surprisingly, the data shows that financial services companies emphasize compliance and policy activities and the creation of security features and design to a greater extent than ISVs. However, the most striking result is the huge amount of overlap between the two disparate industries. Financial services and software companies generally do the same thing when it comes to software security.

Even more interesting than pooling data from multiple companies is comparing the scores of an individual company with the BSIMM averages. This can give a clear indication of how a company's software security initiative stacks up against that of others.

BSIMM released its original study describing software security in nine companies in March 2009. In May, it released BSIMM2, covering 30 companies and providing statistically significant results. BSIMM plans to add more companies, and it's also been remeasuring current participants to mark the evolution in the maturity of their software security initiatives.

For Adobe, BSIMM provides a useful framework and data repository that lets its Secure Software Engineering Team measure its activities against other companies in the industry, says Brad Arkin, senior director of product security and privacy. He adds that it also helps the security team to answer questions such as "Are there things we don't do now but could or should be doing?" and "Are there things we should be doing differently because a shift in the threat landscape?"

Leveraging BSIMM

How can you leverage the BSIMM model? For starters, examine and organize your security initiatives along the lines of BSIMM's 109 activities. Think about which will work in your culture and which you're already doing. Download the BSIMM2 model (it's free and available at www.bsimm2.com). Compare your data with the BSIMM average and make your own spider charts.

If you want an objective measurement, you can join the project, be scored by the authors of the model, and have your data added to it. A BSIMM score will give you a baseline that you can use to compare your software security initiatives to other companies and show progress as your initiative matures. Bottom line, this data will let you create a software security strategy that's directly informed by what others are doing and what works.

Gary McGraw is CTO at Cigital, a software security and quality consulting company, and the author of the Software Security Library. You can write to us at [email protected]

Role Of The Developer In The New Network Infrastructure developers and architects will be key informationweek.com/1275/ddj/role

Endian Issues With Static Analysis Tools Best practices for enforcing correct programming informationweek.com/1275/ddj/static

Recording, Playing, And Accessing Video How to put the iPhone to work informationweek.com/1275/ddj/iphone

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
8 Ways Hackers Monetize Stolen Data
Steve Zurier, Freelance Writer,  4/17/2018
Securing Social Media: National Safety, Privacy Concerns
Kelly Sheridan, Staff Editor, Dark Reading,  4/19/2018
Firms More Likely to Tempt Security Pros With Big Salaries than Invest in Training
Sara Peters, Senior Editor at Dark Reading,  4/19/2018
Register for Dark Reading Newsletters
White Papers
Current Issue
How to Cope with the IT Security Skills Shortage
Most enterprises don't have all the in-house skills they need to meet the rising threat from online attackers. Here are some tips on ways to beat the shortage.
Flash Poll
[Strategic Security Report] Navigating the Threat Intelligence Maze
[Strategic Security Report] Navigating the Threat Intelligence Maze
Most enterprises are using threat intel services, but many are still figuring out how to use the data they're collecting. In this Dark Reading survey we give you a look at what they're doing today - and where they hope to go.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.