An Introduction to the Open Software Assurance Maturity Model (OpenSAMM) 1.0

Information security used to be all about networks and protecting the network perimeter. Today, however, applications are the new battleground for the protection of digital assets. While the concept of software security has been around for a long time, the evolution of mobile technologies and the universal accessibility of applications is requiring organizations to work on improving the maturity of their application security practices. To help with this initiative, many organizations developed their own methodologies. Some of these are too complex and difficult to implement, others are proprietary and expensive. However, there is one framework that stands out among the crowd.

The Open Software Assurance Maturity Model (OpenSAMM) was developed by OWASP back in 2009, and is currently undergoing many updates. Like all OWASP projects, this one is free and has been adopted by many organizations around the world. OpenSAMM is very comprehensive in nature, covers all aspects of application security, and still allows each application to be evaluated in under one hour. On the whole, I would recommend any organization that develops its own software to take a look at OpenSAMM website and try it out.

In order to get started, you need to compile a list of applications and subject-matter experts for each application who can provide answers regarding the way the application was developed. Once compiled, you should review the “Assessment Interview Template” and the “Assessment Worksheet”, both downloads from the Open SAMM’s website. These documents help break down Open SAMM into a series of interview questions, making the process of collecting and normalizing information easier. Once answers have been gathered, OpenSAMM maturity scores can be calculated.

The model breaks application security maturity down to four “business functions”:

  • Governance: The way application security is managed in the organization
  • Construction: The way applications are built
  • Verification: The way security of the application is tested
  • Deployment: How the application is deployed and supported in production

Additionally, each business function breaks down into three “security practices”. For example, “Verification” splits up into:

  • Design Review: Activities such as attack surface analysis
  • Code Review: Activities such as peer and 3rd party code reviews
  • Security Testing: Activities such as penetration testing

Once all the questions have been answered, each “security practice” will receive a score ranging from 0 to 3. This score represents the maturity of each “security practice,” and provides a snapshot of the security practices around each application. Understanding what each metric means to the organization, well that requires additional analysis.

Applications developed in certain high-security industries or environments may require achieving the maximum maturity level at each “security practice,” however this is not necessary for most of the organizations. OpenSAMM provides sample “security profiles” that show suggested maturity ratings for organizations within different industries, but these should be viewed as recommendations only. Each organization should perform its own risk analysis and determine their own acceptable maturity levels in different “security practices” and different applications. In order to better understand different maturity ratings and objectives, Open SAMM provides additional guidance in each area, including suggested security metrics. All of this information should be evaluated collectively, in order to establish the right maturity level objectives for different applications.

The OpenSAMM framework is quick to deploy, provides actionable recommendations for improving application security, and does not dwell in a lot of risk management terminology. I recommend everyone responsible for managing application security to check it out.