Risk
8/5/2010
05:05 PM
50%
50%

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 iweekletters@techweb.com.

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
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2015-4692
Published: 2015-07-27
The kvm_apic_has_events function in arch/x86/kvm/lapic.h in the Linux kernel through 4.1.3 allows local users to cause a denial of service (NULL pointer dereference and system crash) or possibly have unspecified other impact by leveraging /dev/kvm access for an ioctl call.

CVE-2015-1840
Published: 2015-07-26
jquery_ujs.js in jquery-rails before 3.1.3 and 4.x before 4.0.4 and rails.js in jquery-ujs before 1.0.4, as used with Ruby on Rails 3.x and 4.x, allow remote attackers to bypass the Same Origin Policy, and trigger transmission of a CSRF token to a different-domain web server, via a leading space cha...

CVE-2015-1872
Published: 2015-07-26
The ff_mjpeg_decode_sof function in libavcodec/mjpegdec.c in FFmpeg before 2.5.4 does not validate the number of components in a JPEG-LS Start Of Frame segment, which allows remote attackers to cause a denial of service (out-of-bounds array access) or possibly have unspecified other impact via craft...

CVE-2015-2847
Published: 2015-07-26
Honeywell Tuxedo Touch before 5.2.19.0_VA relies on client-side authentication involving JavaScript, which allows remote attackers to bypass intended access restrictions by removing USERACCT requests from the client-server data stream.

CVE-2015-2848
Published: 2015-07-26
Cross-site request forgery (CSRF) vulnerability in Honeywell Tuxedo Touch before 5.2.19.0_VA allows remote attackers to hijack the authentication of arbitrary users for requests associated with home-automation commands, as demonstrated by a door-unlock command.

Dark Reading Radio
Archived Dark Reading Radio
What’s the future of the venerable firewall? We’ve invited two security industry leaders to make their case: Join us and bring your questions and opinions!