Thursday, April 30, 2020

OWASP SAMM v2: lessons learned after 9 years of assessment

OWASP SAMM v2 is out!

OWASP SAMM (Software Assurance Maturity Model) is the OWASP framework to help organizations assess, formulate, and implement, through our self-assessment model, a strategy for software security that can be integrated into their existing Software Development Lifecycle (SDLC).

The new OpenSAMM

The original model OpenSAMM 1.0 was written by Pravir Chandra and dates back to 2009. Over the last 10 years, it has proven a widely distributed and effective model for improving secure software practices in different types of organizations. With SAMM v2, further improvements have been made to deal with some of its perceived limitations.

For those organizations using earlier versions of SAMM, it is important to take the time to understand how the framework has evolved in favor of automation and better alignment with development teams.

The new model supports maturity measurements both from coverage and quality perspectives. It added new quality criteria for all the activities. There is an updated scoring SAMM toolbox designed to help assessors and organizations with their software assurance assessments and roadmaps.

What about your development models?

The new SAMM model is development paradigm agnostic. It supports waterfall, iterative, agile, and DevOps development. The model is flexible enough to allow organizations to take a path based on their risk tolerance and the way they build and use software. The model is built upon the core business functions of software development, with security assurance practices.

What’s changed with SAMM v2?

The version 2.0 of the model now supports frequent updates through small incremental changes on specific parts of the model with regular updates to explanations, tooling, and guidance by the community.

The 3 maturity levels remain as they were. Level 1 is initial implementation; level 2, structured realization; and level 3, optimized operation.

This is the updated SAMM version 2 model:

The major changes are the following:

    - From 4 to 5 business functions and from 12 to 15 Security Practices.
    - The 4 business functions of version 1.5 now become 5 core business functions:

    - Governance
    - Design (which used to be Construction)
    - Implementation
    - A redesigned Verification function
    - Operations

    - Implementation, to represent a number of core activities in the build and deploy domains of an organization. It also includes a new security practice that deals with Defect Management or fixing process.
    - New security practices are: Secure Build, Secure Deployment, Defect Management, Architecture Analysis, Requirements-driven Testing.
    - A new concept appears with version 2, called Streams: activities are now presented in logical flows throughout each of the now 15 security practices, divided into two streams, which aligns and links the activities in the practice over the different maturity levels. Each stream has an objective that can be reached in increasing levels of maturity.

    - The model now supports maturity measurements both from a coverage and a quality perspective. There are new quality criteria for all the SAMM activities, and an updated scoring model to help SAMM assessors and organizations with their software assurance.

What we learned in the last 9 years of assessments

Minded Security did many Software Security Assessments based on SAMM v1 and v1.5.  The following diagram shows the results of  the assessments:

We collected SAMM assessment results performed until 2012 (blue line) and then from 2013 to 2015 (orange line) and then from 2016 to 2018 (gray line).

As you can see from the 2012’s results, the first answer of a Company to the software security issues is: testing, testing, testing!

What we learned during these years is that testing is NOT the solution of Software Security. Testing is just a part of your Software Security journey.

The security efforts of software developers are currently being stymied by time constraints, complexity, and deployment frequency.

The timeline for reporting and fixing critical vulnerabilities – up to one month to share, up to six months to fix – remains unacceptably long.

Today we need instant security feedback: key to achieving a fix within hours of discovery are new standards, more automation, and promptly sharing vulnerability information internally.

That’s why you need to improve all the security practices of the SAMM model in order to manage Software Security properly. A SAMM assessment permits you to have a complete vision of the problem: today the SAMM framework has become crucial to build an efficient, solid Software Security Roadmap in the Companies.

No comments :

Post a Comment