(This blog post is updated and it was originally published on June 18th, 2020.)
“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.” (OWASP SAMM 1.5 Quick Start Guide)
OWASP SAMM 2.0 is a prescriptive model, an open framework which is based around a set of 15 security practices. SAMM is designed to be measurable, actionable and versatile as well as technology, process and organisation agnostic. The goal is to provide an effective and measurable way to analyse and improve an organisation's software security processes throughout the software's lifecycle.
SAMM provides a model for organisations to assess their current level software assurance readiness and capabilities. It is not expected nor is it required that an organisation should achieve the maximum maturity level in each category. Instead organisations are encouraged to determine the target maturity levels for each Security Practice that best fits the organisation's goals, and adapt the SAMM templates accordingly.
Structurally SAMM defines five critical business functions:
Governance
Design
Implementation
Verification
Operations
Each business function has three security practices, each of which has two streams. A stream is an objective by itself, which can be described through three levels of maturity:
Level 0: an implicit starting point with an unfulfilled Security Practice
Level 1: an initial understanding and ad hoc implementation of the Security Practice
Level 2: a structured realisation with increased efficiency and effectiveness of the Security Practice
Level 3: a comprehensive mastery of the Security Practice at the scale that comes with an optimised solution.
For each level, SAMM defines the objective, a set of activities and describes expected results.
How is SAMM utilised in practice? With just four (more or less) easy steps:
1. Assess the organisation's current software security posture
2. Define the organisation's targets for each Security Practice
3. Define the implementation roadmap to achieve the set targets
4. Make it so! Do the necessary work to implement it all.
If you would like to know more about SAMM business functions and security practices, please continue reading.
1 GOVERNANCE
As a business function, Governance is about processes and activities related to how an organisation manages its software development activities.
1.1 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.
| | A: Create & Promote | B: Measure & Improve | |
| ---------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ |
| Maturity Level 1: Identify objectives and means of measuring effectiveness of the security program. | Identify organisation drivers as they relate to the organisation’s risk tolerance. | Define metrics with insight into the effectiveness and efficiency on the Application Security Program. |
| Maturity Level 2: Establish a unified strategic roadmap for software security within the organisation. | Publish a unified strategy for application security. | Set targets and KPI’s for measuring the program effectiveness. |
| Maturity Level 3: Align security efforts with the relevant organisational indicators and asset values. | Align the application security program to support the organisation’s growth. | Influence the strategy based on the metrics and organisational needs. |
1.2 POLICY & COMPLIANCE
In many ways, security issues are strongly anchored to both internal and external requirements. These requirements typically stem from contracts, applicable standards, processes as well as domestic and international laws and regulations, among other things. The goal is to describe organisation's standards and 3rd party obligations as application requirements to enable efficient and automated audits.
| | A: Policy & Standards | B: Compliance Management | |
| ----------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- |
| Maturity Level 1: Identify and document governance and compliance drivers relevant to the organisation. | Determine a security baseline representing organisation’s policies and standards. | Identify 3rd party compliance drivers and requirements and map to existing policies and standards. |
| Maturity Level 2: Establish application-specific security and compliance baseline. | Develop security requirements applicable to all applications. | Publish compliance-specific application requirements and test guidance. |
| Maturity Level 3: Measure adherence to policies, standards, and 3rd-party requirements. | Measure and report on the status of individual application’s adherence to policies and standards. | Measure and report on individual application’s compliance with 3rd party requirements. |
1.3 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 organisation are provided the necessary training, knowledge, and resources to design, develop and deploy secure software. The goal is to provide training for employees and increase their security awareness. 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. In fact, the organisation should consider adopting Security Development Lifecycle (SDL).
| | A:Training & Awareness | B: Organisation & Culture | |
| --------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------ |
| Maturity Level 1: Offer staff access to resources around the topics of secure development and deployment. | Provide security awareness training for all personnel involved in software development. | Identify a “Security Champion” within each development team. |
| Maturity Level 2: Educate all personnel in the software lifecycle with technology and role-specific guidance on secure development. | Offer technology and role-specific guidance, including security nuances of each language and platform. | Develop a secure software centre of excellence promoting thought leadership among developers and architects. |
| Maturity Level 3: Develop in-house training programs facilitated by developers across different teams. | Standardised in-house guidance around the organisation’s secure software development standards. | Build a secure software community including all organisation people involved in software security. |
2 DESIGN
As a business function, Design is about processes and activities related to how goals are defined and how software is being created within projects. This mainly concerns requirements gathering, high-level architecture and detailed design.
2.1 THREAT ASSESSMENT
Threat assessment is one those things where increase of knowledge also increases pain. However, when an unknown threat is unexpectedly realized and you are blind-sided, surprised and unprepared to deal with any of it, then you know what real pain is all about. So, pay attention to threat assessment.
Threat assessment focuses on identifying and understanding project-level risks based on the functionality of the software and the characteristics of the runtime environment.
| | A: Application Risk Profile | B: Threat Modelling | |
| ----------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| Maturity Level 1: Best-effort identification of high-level threats to the organisation and to individual projects. | Basic assessment of the application risk. | Perform best-effort, risk-based thread modelling using brainstorming and existing diagrams with simple threat checklists. |
| Maturity Level 2: Standardization and enterprise-wide analysis of software related threats within the organisation. | Understand the risk for all applications in the organisation by centralising the risk profile inventory for stakeholders. | Standardized threat modelling training, processes, and tools to scale across the organisation. |
| Maturity Level 3: Proactive improvement of threat coverage throughout the organisation. | Periodically review application risk profiles at regular intervals to ensure accuracy and reflect current state. | Continuously optimise and automate your threat modelling methodology. |
2.2 SECURITY REQUIREMENTS
The security requirements are considered within the context of secure software: how to protect the service and the data it contains. It is also important to be mindful of the security considerations related to supplier organisations, especially when outsourcing development work.
| | A: Software Requirements | B: Supplier Security | |
| ---------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| Maturity Level 1: Consider security explicitly during the software requirements process | High-level application security objectives are mapped to functional requirements. | Evaluate the supplier based on organisational security requirements. |
| Maturity Level 2: Increase granularity of security requirements derived from business logic and known risks | Structured security requirements are available and utilised by developer teams. | Build security into supplier agreements in order to ensure compliance with organisational requirements. |
| Maturity Level 3: Mandate security requirements process for all software projects and 3rd party dependencies | Build a requirements framework for product teams to utilise. | Ensure proper security coverage for external suppliers by providing clear objectives. |
2.3 SECURITY ARCHITECTURE
Software is typically a complex mesh of custom code, 3rd party frameworks and libraries, while larger systems consists of various software components and integrated services. The security architecture focuses on security linked to all of these components and technologies: unless security considerations are applied to all parts of a system, the system as a whole remains unsecure.
| | A: Architecture Design | B: Technology Management | |
| ------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- |
| Maturity Level 1: Insert consideration of proactive security guidance into the software design process | Teams are trained on the use of basic security principles during design. | Elicit technologies, frameworks and integrations within the overall solution to identify risk. |
| Maturity Level 2: Direct the software design process toward known secure services and secure-by-default designs | Establish common design patterns and security solutions for adoption. | Standardise technologies and frameworks to be used throughout the different applications |
| Maturity Level 3: Formally control the software design process and validate utilization of secure components. | Reference architectures are utilised and continuously evaluated for adoption and appropriateness. | Impose the use of standard technologies on all software development |
3 IMPLEMENTATION
As a business function, Implementation is about processes and activities related to making builds, deploying software and dealing with related defects. In practice, strive to automate as much as possible.
3.1 SECURE BUILD
It is essential to come up with a solution to build software in a standardised, repeatable manner with secure components. The automated build pipeline should utilise Static/Dynamic Application Security Testing (SAST, DAST) mechanisms along with other automated testing (e.g. regression and integration tests) and quality control processes.
| | A: Build Process | B: Software Dependencies | |
| -------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
| Maturity Level 1: Build process is repeatable and consistent | Create a formal definition of the build process so that it becomes consistent and repeatable. | Create records with Bill of Materials of your applications and opportunistically analyse these. |
| Maturity Level 2: Build process is optimised and fully integrated into the workflow | Automate your build pipeline and secure the used tooling. Add security checks in the build pipeline. | Evaluate used dependencies and ensure timely reaction to situations posing risk to your applications. |
| Maturity Level 3: Build process helps prevent known defects from entering the production environment | Define mandatory security checks in the build process and ensure that building non-compliant artefacts fails. | Analyse used dependencies for security issues in a comparable way to your own code. |
3.2 SECURE DEPLOYMENT
The secure deployment prevents applications from being compromised during deployment by ensuring security and integrity of the deployment process. The first step is automate the deployment process and to use integrated security checks to validate the operation. It is equally (if not more!) important to protect the security and integrity of sensitive data, including passwords, tokens and other secrets.
| | A: Deployment Process | B: Secret Management | |
| ------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- |
| Maturity Level 1: Deployment processes are fully documented | Formalize the deployment process and secure the used tooling and processes. | Introduce basic protection measures to limit access to your production secrets. |
| Maturity Level 2: Deployment processes include security verification milestones | Automate the deployment process over all stages and introduce sensible security verification tests. | Inject secrets dynamically during deployment process from hardened storages and audit all human access to them. |
| Maturity Level 3: Deployment process is fully automated and incorporates automated verification of all critical milestones | Automatically verify integrity of all deployed software, independently on whether it's internally or externally developed. | Improve the lifecycle of application secrets by regularly generating them and ensuring proper use. |
3.3 DEFECT MANAGEMENT
There is no such thing as a flawless software; defects and software go together like a house on fire. Not having any known issues should be a serious cause for concern. Even a long list of known defects can offer a measure of comfort in knowledge that things will get better as developers work their way through the bug list.
Defect management is about collecting, recording and analysing security defects, and enriching them with information to drive metrics-based decisions.
| | A: Defect Tracking | B: Metrics & Feedback | |
| ----------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- |
| Maturity Level 1: All defects are tracked within each project | Introduce a structured tracking of security defects and make knowledgeable decisions based on this information. | Regularly go over previously recorded security defects and derive quick wins from basic metrics. |
| Maturity Level 2: Defect tracking used to influence the deployment process | Rate all security defects over the whole organisation consistently and define SLAs for particular severity classes. | Collect standardised defect management metrics and use these also for prioritisation of centrally driven initiatives. |
| Maturity Level 3: Defect tracking across multiple components is used to help reduce the number of new defects | Enforce the predefined SLAs and integrate your defect management system with other relevant tooling. | Continuously improve your security defect management metrics and correlate it with other sources. |
4 VERIFICATION
As a business function, Verification is about processes and activities related to quality assurance, or how artefacts that are produced throughout software development are reviewed, checked and tested.
4.1 ARCHITECTURE ASSESSMENT
The architecture assessment is about ensuring that all application and infrastructure related security and compliance requirements have been realised. The scope of this work also includes that all identified security threats have been mitigated. Ultimately the goal is to formalise the security architecture review process and maintain it as a continuously repeated cycle.
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.
| | A: Architecture Validation | B: Architecture Compliance | |
| --------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Maturity Level 1: Review the architecture to ensure baseline mitigations are in place for typical risks | Identify application and infrastructure architecture components and review for basic security provisioning. | Ad hoc review of the architecture for unmitigated security threats. |
| Maturity Level 2: Review the complete provision of security mechanisms in the architecture | Validate the architecture security mechanisms | Analyse the architecture for known threats. |
| Maturity Level 3: Review the architecture effectiveness and feedback results to improve the security architecture | Review of the architecture components' effectiveness | Feedback the architecture review results back into the enterprise architecture, organisation design principles & patterns, security solutions and reference architectures. |
4.2 REQUIREMENTS DRIVEN TESTING
The goal of the requirements-driven testing is to ensure that the implemented security controls operate as expected and satisfy the project's stated security requirements. It is important to notice that security testing includes both positive and negative test cases to cover the standard security controls.
Come up with misuse and abuse cases for the application to identify potential attack and exploit scenarios. Use regression testing to verify that previously addressed issues will not be reintroduced in some later revision. Nothing should be merged or deployed unless it at the very least passes all the existing tests.
| | A: Control Verification | B: Misuse / Abuse Testing | |
| ---------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------ | --------------------------------------------------------- |
| Maturity Level 1: Opportunistically find basic vulnerabilities and other security issues | Test for software security controls. | Perform security fuzzing testing. |
| Maturity Level 2: Perform implementation review to discover application specific risks against the security requirements | Derive test cases from known security requirements. | Create and test abuse cases and business logic flaw test. |
| Maturity Level 3: Maintain the application security level after bug fixes, changes or during maintenance | Perform regression testing (with security unit tests). | Denial of service and security stress testing. |
4.3 SECURITY TESTING
Security testing should be a routine part of development and deployment. While automated security tests can perform static and dynamic code analysis better than humans, in-depth exploratory testing is best done on good knowledge of the application and its business logic by an expert of security testing (i.e. white box testing). The best results can be achieved by combining automated and manual security testing.
The goal of security testing is to uncover weaknesses in business logic and in technical implementation, and make them visible to management and stakeholders, irrespective of requirements.
| | A: Scalable Baseline | B: Deep Understanding | |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- | ------------------------------------------------------- |
| Maturity Level 1: Perform security testing (both manual and tool based) to discover security defects | Utilise automated security testing tools | Perform manual security testing of high risk components |
| Maturity Level 2: Make security testing during development more complete and efficient through automation complemented with regular manual security penetration tests | Employ application specific security testing automation | Conduct manual penetration testing |
| Maturity Level 3: Embed security testing as part of the development and deployment processes | Integrate automated security testing into the build and deploy process | Integrate security testing into development process |
5 OPERATIONS
As a business function, Operations is about processes and activities necessary to ensure confidentiality, integrity, and availability throughout the operational lifetime of an application and its data.
5.1 INCIDENT MANAGEMENT
Once the application has been deployed to production, you will face security incidents. Do not think this as a possibility, but consider it a certainty (unless the computer is contained within a solid block of concrete at the bottom of the ocean, and even then someone might dive in with a hammer and chisel.).
SAMM essentially defines a security incident as a breach of at least one security goal of an asset. This may be caused by malicious, intentional action or by negligent behaviour. The incident management focuses on dealing with security incidents with the goal of reducing the time between the breach and the detection of the breach.
| | A: Incident Detection | B: Incident Response | |
| ----------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- |
| Maturity Level 1: Best-effort incident detection and handling | Use available log data to perform best-effort detection of possible security incidents. | Identify roles and responsibilities for incident response. |
| Maturity Level 2: Formal incident management process in place | Follow an established, well-documented process for incident detection, with emphasis on automated log evaluation. | Establish a formal incident response process and ensure staff are properly training in performing their roles. |
| Maturity Level 3: Mature incident management | Use a proactively managed process for detection of incidents. | Employ a dedicated, well-trained incident response team. |
5.2 ENVIRONMENT MANAGEMENT
To maintain secure production environment, a proactive approach is required. New security features and patches are continuously released as new threats and vulnerabilities are being discovered, and there must be a continuous process to have those updates installed for all elements of the organisation's technology stack. Organisations should strive become proactive instead of remaining reactive when facing security threats.
| | A: Configuration Hardening | B: Patching & Updating | |
| ----------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Maturity Level 1: Best-effort patching and hardening | Perform best-effort hardening of configurations, based on readily available information. | Perform best-effort patching of system and application components. |
| Maturity Level 2: Formal process with baselines in place | Perform consistent hardening of configurations, following established baselines and guidance. | Perform regular patching of system and application components, across the full stack. Ensure timely delivery of patches to customers. |
| Maturity Level 3: Conformity with continuously improving process enforced | Actively monitor configurations for non-conformance to baselines, and handle detected occurrences as security defects. | Actively monitor update status and manage missing patches as security defects. Proactively obtain vulnerability and update information for components. |
5.3 OPERATIONAL MANAGEMENT
It is not enough to focus on just the application's security aspect as the security must also be maintained throughout operational support functions. These support functions are not performed directly by an application, but it does rely on them: e.g. system administration, database administration and backups, and so on.
It is not possible to maintain application security if the underlying service infrastructure and processes remain vulnerable.
| | A: Data Protection | B: System Decommissioning / Legacy Management | |
| ---------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Maturity Level 1: Foundational practices | Implement basic data protection practices. | Decommission unused applications and services as identified. Manage customer upgrades / migrations individually. |
| Maturity Level 2: Managed, responsive processes | Develop data catalogue and establish data protection policy. | Develop repeatable decommissioning processes for unused systems / services, and for migration from legacy dependencies. Manage legacy migration roadmaps for customers. |
| Maturity Level 3: Active monitoring and response | Automate detection of policy non-compliance, and audit compliance periodically. Regularly review and update to data catalogue and data protection policy. | Proactively manage migration roadmaps, for both unsupported end-of-life dependencies, and legacy versions of delivered software. |
CONCLUSION
The best way to get started with SAMM is simply by taking the first step and begin using it without too much worrying about “doing it right”. It is an iterative process so it is quite acceptable to consider the first one or two cycles as time well spent learning the ropes.
A common iterative cycle includes phases:
Prepare
Assess
Set the target
Define the plan
Implement
Roll-out (followed by Assess when the next cycle begins)
The primary sources for OWASP SAMM 2.0 documentation are:
You are also more than welcome to contact us to have our professionals to help you get started and to further support your organization in adopting SAMM and Software Development Lifecycle (SDL) methodology in general.
