Manage Learn to apply best practices and optimize your operations.

Improving software with the Building Security in Maturity Model (BSIMM)

Learn about the Building Security in Maturity Model (BSIMM), a software security framework that emphasizes attack models, software security testing, code review and compliance policies. Also, does your company have a software security group (SSG)?

One problem facing every organization looking to build functional yet secure software is that they don't know what...

the best practice is for every discipline that plays a role in the creation of a robust application. Yes, there are lots of helpful security initiatives, organizations and regulatory guidance, but trying to draw them all together into an efficient well-built application can seem like an overwhelming task. This is partly because a lot of the recommendations are based on theory and ideal scenarios.

Those looking for a framework based on what has been achieved in the real world should take a look at the Building Security In Maturity Model (BSIMM).

Described as a collection of good ideas and activities that are in use today, BSIMM is the work of three software security experts -- Gary McGraw, Brian Chess and Sammy Migues -- who analyzed nine leading software security initiatives from software vendors, technology firms and the financial-services industry. The model utilizes a software security framework (SSF) to organize software security tasks. This helps an organization determine where its own security practices stand in relation to others and how to advance them over time.

The SSF consists of 110 activities across the following 12 practices:

  • Strategy and Metrics -- Transparency of expectations and accountability for results.
  • Attack Models -- Creation of customized knowledge on attacks relevant to the organization, building data classification schemes and identifying likely attackers.
  • Architecture Analysis –- Detection and correction of security flaws, classifying risk and performing design review.
  • Penetration Testing -- Detection and correction of security flaws, providing sanity checks and internal/external tests.
  • Compliance and Policy -- Prescriptive guidance for all stakeholders and auditability of software development lifecycle activities.
  • Security Features and Design -- Creation of customized, proactive guidance and knowledge on security features, frameworks and patterns.
  • Code Review –- Detection and correction of security flaws, enforcing coding standards and using automated as well as manual reviews.
  • Software Environment –- The ability to make authorized changes and to detect unauthorized changes and activity using processes like application behavior monitoring and diagnostics.
  • Training -- Creation of a knowledgeable workforce that corrects errors in processes.
  • Standards and Requirements –- Creation of prescriptive guidance for shareholders and documentation of software security choices.
  • Security Testing –- Detection and correction of security flaws using methods like fuzz testing, enforcing adherence to standards and the reuse of approved security features.
  • Configuration Management and Vulnerability Management –- The ability to track authorized changes to applications and to detect unauthorized changes and activity, with an emphasis on incident response.

Each practice is further divided into three maturity levels so that it's clear which activities are best addressed first and which need prioritizing. Although it's not a complete "how to" guide for software security, it provides plenty of ideas and general guidance. Each activity has a stated objective, a description and a brief example to illustrate how at least one organization made it happen; some are really simple, but are effective. For example, one of the activities in the Training practice is for the software security group (SSG) to have an advertised lab period -- during which developers can drop in and discuss secure development or specific coding issues -- to provide an informal resource to other departments.

More on software security
The importance of secure software development training

Software security threats and employee awareness training

You may ask, what's an SSG? Well, all nine companies that took part in the research agree that the success of their programs hinges on having an internal group devoted to software security -- an SSG. It includes senior executives, system architects, developers and administrators.

As BSIMM is based on what organizations are actually doing; it could be seen as a de facto standard. It certainly gives real and fascinating insight into which activities are commonly practiced and which are not. Also, unlike many official standards, it accepts that not all organizations need to achieve the same security goals. No organization needs to carry out all 110 activities, and the average maturity of the nine organizations varies greatly, as the BSIMM graph data shows. The model does, however, provide a potential benchmark against which organizations can all be measured and demonstrate progress. This is likely to give it widespread appeal.

Over the last few years, there has been recognition that software can't solely rely on perimeter and other defenses to protect it; it needs security to be built in. Microsoft helped greatly by adopting and sharing its Secure Development Lifecycle, a process that emphasizes security and privacy throughout the entire duration of software creation. BSIMM is, in a way, the next step along the path to pooling knowledge of what works and how best to implement it. To this end, BSIMM is free and has been released under the Creative Commons Attribution-Share Alike 3.0 License.

To get started you need to form your own SSG, bringing in stakeholders and those with relevant expertise. The first SSG meeting should review the BSIMM and eliminate those activities that are clearly not relevant to any current projects. The maturity model can then be used to prioritize the remaining activities. Obviously budget constraints will play a part in whether an activity is a "must do" or "good to do" and will no doubt lead to some lively debates. This may take a few iterations to satisfy everyone but you will certainly see a marked improvement in your secure software development processes.

About the author:
Michael Cobb, CISSP-ISSAP is the founder and managing director of Cobweb Applications Ltd., a consultancy that offers IT training and support in data security and analysis. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications. Mike is the guest instructor for several Security Schools and, as a site expert, answers user questions on application security and platform security.
This was last published in February 2010

Dig Deeper on Secure software development