• Dana Epp

BSIMM: Maturing the process of Building Security In - Almost 10 years later

Although software security is still in its infancy, there are several methodologies like Microsoft SDL, OWASP CLASP and Cigital Touchpoints that are being adopted by more and more companies as part of their software security initiatives. Many share much of the common ground. A study driven by Gary McGraw, Brian Chess and Sammy Migues almost 10 years ago investigated these common traits across several world leading companies, including Microsoft, Google, Adobe and EMC. Entitled the "Building Security In Maturity Model (BSIMM)", it helped to document a process of understanding and analyzing the real world experiences these companies have had in their software security development lifecycles.

I was privileged enough to get early access to that study and have to say back then I reflected on their skeleton and saw some real merit for using BSIMM in enterprise environments. It dictates a well rounded maturing process that can easily be adopted, even if in stages, to significantly increase the security effectiveness of a company's development process.

I highly recommend to take a look at it. You can check it out here.

If there is one criticism I would have on BSIMM, it is that it has a requirement of scale. In the original study, the median for a software security group (SSG) was 35 to 40 people, which is much too large for a majority of software companies out there. With the adoption of many agile software development paradigms, teams are getting smaller, not bigger, and are becoming isolated from main development teams. Especially if outsourced. And in actuality, it is my belief its these smaller teams that would benefit most from a software security development lifecycle that is better studied, understood and adopted. It's one of the reasons I like the Microsoft SDL process. It works with small teams of 5 or 10 people in the entire team.

However, that is no reason to dismiss BSIMM. From the 113 activities, although some simply don't fit, much does, irregardless of the size of the team. The requirement is that it be bought into... shifting culture and defining attitude. What was interesting to see was the top 10 activities seen through most companies studied back then. They include:

  1. Create evangelism role/internal marketing

  2. Create policy

  3. Provide awareness training

  4. Create/use material specific to company history

  5. Build/publish security features (authentication, role management, key management, audit/log, crypto, protocols)

  6. Have SSG lead review efforts

  7. Use automated tools along with manual review

  8. Integrate black box security tools into the QA process (including protocol fuzzing)

  9. Use external pen testers to find problems

  10. Ensure host/network security basics in place

Sounds like good advice to me.

But 10 years later, its far better structured. The BSIMM Framework consists of 12 practices organized into four domains:

  • Governance - Strategy & Metrics, Compliance & Policy, Training

  • Intelligence - Attack Models, Security Features & Design, Standards & Requirements

  • SSDL TouchPoints - Architecture Analysis, Code Review, Security Testing

  • Deployment - Penetration Testing, Software Environment, Configuration & Vulnerability Management

I'd like to congratulate Gary and his peers on an interesting study that is now almost 10 years old... and still valid. And I hope others in the industry will look up this research and see how they can adopt it to their own development processes. With any luck, we can see adaptations to allow this to work with considerably smaller teams.