March 05, 2009

BSIMM: Maturing the process of Building Security In.

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 new study driven by Gary McGraw, Brian Chess and Sammy Migues investigated these common traits across several world leading companies, including Microsoft, Google, Adobe and EMC. Entitled the "Building Security In Maturity Model (BSIMM)", it helps 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 this study and have to say over the last few weeks I have reflected on their skelton and see 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 download it here.

If there is one criticism I would have on BSIMM, it is that it has a requirement of scale. In the study, the median for a software security group (SSG) is 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 110 activities, although some simply don't fit, much does, irregarless 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. They include:

  • Create evangelism role/internal marketing
  • Create policy
  • Provide awareness training
  • Create/use material specific to company history
  • Build/publish security features (authentication, role management, key management, audit/log, crypto, protocols)
  • Have SSG lead review efforts
  • Use automated tools along with manual review
  • Integrate black box security tools into the QA process (including protocol fuzzing)
  • Use external pen testers to find problems
  • Ensure host/network security basics in place

Sounds like good advice to me.

I'd like to congratulate Gary and his peers on an interesting study. 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.

Posted by SilverStr at March 5, 2009 08:49 PM | TrackBack
Comments