OWASP SAMM is a framework that helps to further enhance software security as part of Software Development Lifecycle.
This post was originally written for Intopalo Digital’s company blog.
This blog entry is about OWASP SAMM, which stands for Software Assurance Maturity Model, and it is intended as an introduction to the framework that can help to further enhance software security as part of Software Development Lifecycle.
SAMM (Software Assurance Maturity Model) is the OWASP framework to help organizations assess, formulate, and implement a strategy for software security, that can be integrated into their existing Software Development Lifecycle (SDL). SAMM is fit for most contexts – whether your organization is mainly developing, outsourcing, or rather, focusing on acquiring software, or whether you are using a waterfall or an agile method – the same model can be applied.SAMM Quick Start Guide
The Software Assurance Maturity Model v1.5 is based around a set of 12 security principles, which are divided into four business functions. However, the upcoming version 2.0 will extend this to 15 security principles in five business functions. The goal is to provide an effective and measurable way to analyze and improve an organization’s software security practices. This covers an entire software development lifecycle while being technology and process agnostic.
SAMM was originally introduced in 2009 as version 1.0 while the current release is version 1.5. At the time of writing this text, it is expected that the 2.0 release will be completed sometime around Q4/2019-Q1/2020.
The SAMM 2.0 is designed to be development paradigm agnostic, which means it can be applied to all kinds of projects ranging from waterfall to agile to DevOps as well as to some yet to be conceived models. As mentioned above, SAMM 2.0 has 15 security principles or practices. Each of these is divided into two “streams”, and each stream has an objective. A stream specific objective can be reached at various levels of maturity:
- Level 0: an implicit starting point with the Practice unfulfilled
- Level 1: an initial understanding and ad hoc implementation of the Practice
- Level 2: structured realization with increased efficiency and effectiveness of the Practice
- Level 3: a comprehensive mastery of the Practice at a scale that comes with an optimized operation.
Among other things, for each level, SAMM defines an objective, a set of activities and describes expected results.
The following two sites are the primary sources for SAMM documentation:
The following chapters provide a brief overview of the five business functions along with each function’s three security practices.
As a business function, Governance is about processes and activities related to how an organization manages its software development activities. This is covered by the following three security practices.
Strategy & Metrics
It is essential to have an overall plan when working on any kind of project. Without an overall plan, it is difficult, if not impossible to keep various project efforts aligned, proportional and ultimately productive. Therefore the goal of this practice is to build an efficient and effective plan for realizing the software security objectives within an organization that is both measurable and aligned with the business risks.
Policy & Compliance
In many ways, security issues are strongly anchored to internal and external laws, standards and regulations. Therefore, it is important to describe an organization’s standards as well as 3rd party obligations (such as laws and regulations) as application requirements in order to ensure that they are taken into account at all stages of application’s lifecycle.
Education & Guidance
While having strategies and metrics as well as policies and rules (not to mention good intentions) is important, it all works even better when people working within the organization are provided the necessary training, knowledge, and resources to design, develop and deploy secure software. This needs to be a systematic, continuous process as it is not enough to simply train a person once and expect him or her to be all-knowing and flawless in the future duties after that. No, it requires a change in the organization’s culture to support its members in their efforts to keep on learning as a continuous process.
As a business function, Design is about processes and activities related to how goals are defined and how software is being created within projects. In other words, this is about product management, requirements specifications, understanding potential threat models, and high-level architecture design from the security perspective.
The need for security flows from the acknowledged existence of threats – this is one of those things where the increase of knowledge also increases pain, and yet it is small compared to the potential pain that tends to follow when a realization of an unknown threat takes us surprised and unprepared. Therefore, it pays to identify risks in applications and to treat them accordingly.
These requirements are considered within the context of secure software. For example, how the service can be protected and how sensitive is the data it contains. From software security’s perspective, it is also important to take a look at the suppliers, especially when outsourcing any of the development work.
Software architecture tends to quickly grow into a complex mesh of in-house code, software components, and 3rd party frameworks and libraries even when there are no external services to be integrated with. The architecture is secure only when security considerations are applied to all the parts that it consists of as well as to the design work itself.
As a business function, Implementation is about processes and activities related to establishing reliable, automated methods for building and deploying applications, dependency management and keeping track of defects. The actual implementation work like design and programming is more related to Software Development Lifecycle (SDL) practices.
It is important to be able to produce consistently repeatable builds, and this is best done by having an automated build environment that is based on reliable software components and services. The less manual work a build requires, the better. An automated build pipeline can perform automated regression and integration tests as well as include static/dynamic application security testing (SAST, DAST) mechanisms.
While it is essential to consider security aspects during the software’s design and implementation, the same work must carry over the deployment as well. This begins by automating the deployment process as much as possible in order to reduce (if not entirely remove) the chances for human errors and to maintain consistently repeated processes with necessary checks and logs. Equally, if not more, importantly the deployment process must protect the foundations for privacy and maintain control over sensitive data such as private keys, passwords, and other tokens as well as the integrity of data storages.
There is no such thing as flawless software that has no bugs; not having any issues should be a cause for concern as opposed to relief as it is all but guaranteed that whatever issues testing might miss, those will be discovered in production. Defects and software go together like a house on fire so it pays to establish a controlled process to collect, record and analyze software (security) defects to enable metrics-based decision making.
As a business function, Verification is about processes and activities related to quality assurance such as organization checks and test artifacts produced throughout the software development. This includes also other review and evaluation activities in addition to typical QA work.
Architecture is reviewed from the security’s point of perspective: identify application and infrastructure architecture components, list all the interfaces and their security-related functionalities as well as having a list of security mechanisms. Both the application and supporting infrastructure architectures need to be validated against known threats and existing security requirements.
Requirements Driven Testing
Security testing includes both positive and negative test cases. At least this should cover the standard security controls as well as using fuzzing to verify the input validations. Come up with misuse and abuse cases for the application to identify the potential attack and exploit scenarios. Use regression testing to verify that squashed bugs stay that way instead of reintroducing them in some later revision. Nothing should be merged nor deployed unless it at the very least passes the existing tests.
Security testing should be a routine part of development and deployment. While automated tests can scan code bases and perform static analysis better than humans, they lack the contextual awareness necessary to understand the business logic and more complex attack vectors. So both automated and manual security testing is required. The main body of this testing work should be based on granular test cases based on the application’s intended functionality and requirements. Additional issues should be reviewed and handled as necessary.
As a business function, Operations is about processes and activities related to release management, deployment, and maintenance. This covers topics such as issue management, hardening the operational environment against discovered vulnerabilities.
It is all but guaranteed that an application will be faced with defects and incidents once it has been deployed into production: the probability is higher with an application that is directly exposed to the Internet and the hordes of users, but no system is truly safe
(unless it is contained within a solid block of concrete at the bottom of the ocean). In this context, a security incident is a breach or threat of an imminent breach of at least one system asset due to malicious or negligent behavior such as a denial of service attack or unauthorized data access. Once a security incident has been identified it is essential to limit the exposure and exercise damage control by acting in an organized and premeditated manner.
In order to maintain a secure production environment, a proactive approach is required: new security features and patches are being continuously released just as new threats and vulnerabilities are being discovered. An organization that adopts reactive practices instead of striving to be proactive makes a conscious choice to do too little too late. It is vitally important to actively keep up with information about new vulnerabilities and to react in a timely fashion.
It is not enough to focus on just the application’s security aspects. Security must also be part of the supporting operational activities such as system administration, database administration, backup administration and so on. It is not possible to maintain application security if the underlying service infrastructure and processes have vulnerabilities.
The best way to get started with SAMM is simply by taking the first step and begin using it without worrying too much about “doing it right”. It is an iterative process so it is quite alright to spend the first cycle or two to just learning the ropes.
A common iterative cycle includes phases:
- Set the target
- Define the plan
- Roll-out (followed by Assess when the next cycle begins)
The OWASP SAMM websites provide plenty of helpful documentation, such as the Quick Start Guide for SAMM 1.5: