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
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Security Operations and IT Operations: Finding the Path to Collaboration
A wide gulf has emerged between SOC and NOC teams that's keeping both of them from assuring the confidentiality, integrity, and availability of IT systems. Here's how experts think it should be bridged.
Flash Poll
New Best Practices for Secure App Development
New Best Practices for Secure App Development
The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
Published: 2015-10-15
The Direct Rendering Manager (DRM) subsystem in the Linux kernel through 4.x mishandles requests for Graphics Execution Manager (GEM) objects, which allows context-dependent attackers to cause a denial of service (memory consumption) via an application that processes graphics data, as demonstrated b...

Published: 2015-10-15
netstat in IBM AIX 5.3, 6.1, and 7.1 and VIOS 2.2.x, when a fibre channel adapter is used, allows local users to gain privileges via unspecified vectors.

Published: 2015-10-15
Cross-site request forgery (CSRF) vulnerability in eXtplorer before 2.1.8 allows remote attackers to hijack the authentication of arbitrary users for requests that execute PHP code.

Published: 2015-10-15
Directory traversal vulnerability in QNAP QTS before 4.1.4 build 0910 and 4.2.x before 4.2.0 RC2 build 0910, when AFP is enabled, allows remote attackers to read or write to arbitrary files by leveraging access to an OS X (1) user or (2) guest account.

Published: 2015-10-15
Cisco Application Policy Infrastructure Controller (APIC) 1.1j allows local users to gain privileges via vectors involving addition of an SSH key, aka Bug ID CSCuw46076.

Dark Reading Radio
Archived Dark Reading Radio
In past years, security researchers have discovered ways to hack cars, medical devices, automated teller machines, and many other targets. Dark Reading Executive Editor Kelly Jackson Higgins hosts researcher Samy Kamkar and Levi Gundert, vice president of threat intelligence at Recorded Future, to discuss some of 2016's most unusual and creative hacks by white hats, and what these new vulnerabilities might mean for the coming year.