+OWASP Software Assurance Maturity Model (SAMM) v2.2.0
---+Governance
------+G-SM Strategy and Metrics
---------+G-SM-A Stream A: Create and Promote
------------+G-SM-1-A Identify the organization's risk appetite
------------+G-SM-2-A Define the security strategy
------------+G-SM-3-A Align security and business strategies
---------+G-SM-B Stream B: Measure and Improve
------------+G-SM-1-B Define basic security metrics
------------+G-SM-2-B Set strategic KPIs
------------+G-SM-3-B Drive the security program through metrics
------+G-PC Policy and Compliance
---------+G-PC-A Stream A: Policy and Standards
------------+G-PC-1-A Define policies and standards
------------+G-PC-2-A Develop test procedures
------------+G-PC-3-A Measure compliance to policies and standards
---------+G-PC-B Stream B: Compliance Management
------------+G-PC-1-B Identify compliance requirements
------------+G-PC-2-B Standardize policy and compliance requirements
------------+G-PC-3-B Measure compliance to external requirements
------+G-EG Education and Guidance
---------+G-EG-A Stream A: Training and Awareness
------------+G-EG-1-A Train all stakeholders for awareness
------------+G-EG-2-A Customize security training
------------+G-EG-3-A Standardize security guidance
---------+G-EG-B Stream B: Organization and Culture
------------+G-EG-1-B Identify security champions
------------+G-EG-2-B Implement centers of excellence
------------+G-EG-3-B Establish a security community
---+Design
------+D-TA Threat Assessment
---------+D-TA-A Stream A: Application Risk Profile
------------+D-TA-1-A Perform application risk assessments
------------+D-TA-2-A Inventory risk profiles
------------+D-TA-3-A Periodic review of risk profiles
---------+D-TA-B Stream B: Threat Modeling
------------+D-TA-1-B Perform basic threat modeling
------------+D-TA-2-B Standardize and scale threat modeling
------------+D-TA-3-B Optimize threat modeling
------+D-SR Security Requirements
---------+D-SR-A Stream A: Software Requirements
------------+D-SR-1-A Identify security requirements
------------+D-SR-2-A Standardize and integrate security requirements
------------+D-SR-3-A Develop a security requirements framework
---------+D-SR-B Stream B: Supplier Security
------------+D-SR-1-B Perform vendor assessments
------------+D-SR-2-B Discuss security responsibilities with suppliers
------------+D-SR-3-B Align security methodology with suppliers
------+D-SA Secure Architecture
---------+D-SA-A Stream A: Architecture Design
------------+D-SA-1-A Adhere to basic security principles
------------+D-SA-2-A Provide preferred security solutions
------------+D-SA-3-A Build reference architectures
---------+D-SA-B Stream B: Technology Management
------------+D-SA-1-B Identify tools and technologies
------------+D-SA-2-B Promote preferred tools and technologies
------------+D-SA-3-B Enforce the use of recommended technologies
---+Implementation
------+I-SB Secure Build
---------+I-SB-A Stream A: Build Process
------------+I-SB-1-A Define a consistent build process
------------+I-SB-2-A Automate the build process
------------+I-SB-3-A Enforce a security baseline during build
---------+I-SB-B Stream B: Software Dependencies
------------+I-SB-1-B Identify application dependencies
------------+I-SB-2-B Review application dependencies for security
------------+I-SB-3-B Test application dependencies
------+I-SD Secure Deployment
---------+I-SD-A Stream A: Deployment Process
------------+I-SD-1-A Use a repeatable deployment process
------------+I-SD-2-A Automate deployment and integrate security checks
------------+I-SD-3-A Verify the integrity of deployment artifacts
---------+I-SD-B Stream B: Secret Management
------------+I-SD-1-B Protect application secrets in configuration and code
------------+I-SD-2-B Include application secrets during deployment
------------+I-SD-3-B Enforce lifecycle management of application secrets
------+I-DM Defect Management
---------+I-DM-A Stream A: Defect Tracking
------------+I-DM-1-A Track security defects centrally
------------+I-DM-2-A Rate and track security defects
------------+I-DM-3-A Enforce an SLA for defect management
---------+I-DM-B Stream B: Metrics and Feedback
------------+I-DM-1-B Define basic defect metrics
------------+I-DM-2-B Define advanced defect metrics
------------+I-DM-3-B Use metrics to improve the security strategy
---+Verification
------+V-AA Architecture Assessment
---------+V-AA-A Stream A: Architecture Validation
------------+V-AA-1-A Assess application architecture
------------+V-AA-2-A Verify the application architecture for security methodically
------------+V-AA-3-A Verify the effectiveness of security components
---------+V-AA-B Stream B: Architecture Mitigation
------------+V-AA-1-B Evaluate architecture for typical threats
------------+V-AA-2-B Structurally verify the architecture for identified threats
------------+V-AA-3-B Feed review results back to improve reference architectures
------+V-RT Requirements-driven Testing
---------+V-RT-A Stream A: Control Verification
------------+V-RT-1-A Test the effectiveness of security controls
------------+V-RT-2-A Define and run security test cases from requirements
------------+V-RT-3-A Automate security requirements testing
---------+V-RT-B Stream B: Misuse/Abuse Testing
------------+V-RT-1-B Perform fuzz testing
------------+V-RT-2-B Define and run security abuse cases from requirements
------------+V-RT-3-B Perform security stress testing
------+V-ST Security Testing
---------+V-ST-A Stream A: Scalable Baseline
------------+V-ST-1-A Perform automated security testing
------------+V-ST-2-A Develop application-specific security test cases
------------+V-ST-3-A Integrate security testing tools in the delivery pipeline
---------+V-ST-B Stream B: Deep Understanding
------------+V-ST-1-B Test high risk application components manually
------------+V-ST-2-B Establish a penetration testing process
------------+V-ST-3-B Establish continuous, scalable security verification
---+Operations
------+O-IM Incident Management
---------+O-IM-A Stream A: Incident Detection
------------+O-IM-1-A Use best-effort incident detection
------------+O-IM-2-A Define an incident detection process
------------+O-IM-3-A Improve the incident detection process
---------+O-IM-B Stream B: Incident Response
------------+O-IM-1-B Create an incident response plan
------------+O-IM-2-B Define an incident response process
------------+O-IM-3-B Establish an incident response team
------+O-EM Environment Management
---------+O-EM-A Stream A: Configuration Hardening
------------+O-EM-1-A Use best-effort hardening
------------+O-EM-2-A Establish hardening baselines
------------+O-EM-3-A Perform continuous configuration monitoring
---------+O-EM-B Stream B: Patching and Updating
------------+O-EM-1-B Practice best-effort patching
------------+O-EM-2-B Formalize patch management
------------+O-EM-3-B Enforce timely patch management
------+O-OM Operational Management
---------+O-OM-A Stream A: Data Protection
------------+O-OM-1-A Organize basic data protections
------------+O-OM-2-A Establish a data catalog
------------+O-OM-3-A Respond to data breaches
---------+O-OM-B Stream B: System Decommissioning / Legacy Management
------------+O-OM-1-B Identify unused applications
------------+O-OM-2-B Formalize decommissioning process
------------+O-OM-3-B Review application lifecycle state regularly
---+SAMM Assessment Questions
------+G-SM-1-A Do you understand the enterprise-wide risk appetite for your applications?
------+G-SM-2-A Do you have a strategic plan for application security and use it to make decisions?
------+G-SM-3-A Do you regularly review and update the Strategic Plan for Application Security?
------+G-SM-1-B Do you use a set of metrics to measure the effectiveness and efficiency of the application security program across applications?
------+G-SM-2-B Have you defined Key Performance Indicators (KPIs) from available application security metrics?
------+G-SM-3-B Do you update the Application Security strategy and roadmap based on application security metrics and KPIs?
------+G-PC-1-A Do you have and apply a common set of policies and standards throughout your organization?
------+G-PC-2-A Do you publish the organization's policies as test scripts or run-books for easy interpretation by development teams?
------+G-PC-3-A Do you regularly report on policy and standard compliance, and use that information to guide compliance improvement efforts?
------+G-PC-1-B Do you have a complete picture of your external compliance obligations?
------+G-PC-2-B Do you have a standard set of security requirements and verification procedures addressing the organization's external compliance obligations?
------+G-PC-3-B Do you regularly report on adherence to external compliance obligations and use that information to guide efforts to close compliance gaps?
------+G-EG-1-A Do you require employees involved with application development to take SDLC training?
------+G-EG-2-A Is training customized for individual roles such as developers, testers, or security champions?
------+G-EG-3-A Have you implemented a Learning Management System or equivalent to track employee training and certification processes?
------+G-EG-1-B Have you identified a Security Champion for each development team?
------+G-EG-2-B Does the organization have a Secure Software Center of Excellence (SSCE)?
------+G-EG-3-B Is there a centralized portal where developers and application security professionals from different teams and business units are able to communicate and share information?
------+D-TA-1-A Do you classify applications according to business risk based on a simple and predefined set of questions?
------+D-TA-2-A Do you use centralized and quantified application risk profiles to evaluate business risk?
------+D-TA-3-A Do you regularly review and update the risk profiles for your applications?
------+D-TA-1-B Do you identify and manage architectural design flaws with threat modeling?
------+D-TA-2-B Do you use a standard methodology, aligned with your application risk levels?
------+D-TA-3-B Do you regularly review and update the threat modeling methodology for your applications?
------+D-SR-1-A Do project teams specify security requirements during development?
------+D-SR-2-A Do you define, structure, and include prioritization in the artifacts of the security requirements gathering process?
------+D-SR-3-A Do you use a standard requirements framework to streamline the elicitation of security requirements?
------+D-SR-1-B Do stakeholders review vendor collaborations for security requirements and methodology?
------+D-SR-2-B Do vendors meet the security responsibilities and quality measures of service level agreements defined by the organization?
------+D-SR-3-B Are vendors aligned with standard security controls and software development tools and processes that the organization utilizes?
------+D-SA-1-A Do teams use security principles during design?
------+D-SA-2-A Do you use shared security services during design?
------+D-SA-3-A Do you base your design on available reference architectures?
------+D-SA-1-B Do you evaluate the security quality of important technologies used for development?
------+D-SA-2-B Do you have a list of recommended technologies for the organization?
------+D-SA-3-B Do you enforce the use of recommended technologies within the organization?
------+I-SB-1-A Is your full build process formally described?
------+I-SB-2-A Is the build process fully automated?
------+I-SB-3-A Do you enforce automated security checks in your build processes?
------+I-SB-1-B Do you have solid knowledge of the dependencies you rely on?
------+I-SB-2-B Do you handle third-party dependency risk through a formal process?
------+I-SB-3-B Do you prevent the build of software if it is affected by vulnerabilities in dependencies?
------+I-SD-1-A Do you use repeatable deployment processes?
------+I-SD-2-A Are deployment processes automated and employing security checks?
------+I-SD-3-A Do you consistently validate the integrity of deployed artifacts?
------+I-SD-1-B Do you limit access to application secrets according to the least privilege principle?
------+I-SD-2-B Do you inject production secrets into configuration files during deployment?
------+I-SD-3-B Do you practice proper lifecycle management for application secrets?
------+I-DM-1-A Do you track all known security defects in accessible locations?
------+I-DM-2-A Do you keep an overview of the state of security defects across the organization?
------+I-DM-3-A Do you enforce SLAs for fixing security defects?
------+I-DM-1-B Do you use basic metrics about recorded security defects to carry out quick-win improvement activities?
------+I-DM-2-B Do you improve your security assurance program upon standardized metrics?
------+I-DM-3-B Do you regularly evaluate the effectiveness of your security metrics so that their input helps drive your security strategy?
------+V-AA-1-A Do you review the application architecture for key security objectives on an ad-hoc basis?
------+V-AA-2-A Do you regularly review the security mechanisms of your architecture?
------+V-AA-3-A Do you regularly review the effectiveness of the security controls?
------+V-AA-1-B Do you review the application architecture for mitigations of typical threats on an ad-hoc basis?
------+V-AA-2-B Do you regularly evaluate the threats to your architecture?
------+V-AA-3-B Do you regularly update your reference architectures based on architecture assessment findings?
------+V-RT-1-A Do you test applications for the correct functioning of standard security controls?
------+V-RT-2-A Do you consistently write and execute test scripts to verify the functionality of security requirements?
------+V-RT-3-A Do you automatically test applications for security regressions?
------+V-RT-1-B Do you test applications using randomization or fuzzing techniques?
------+V-RT-2-B Do you create abuse cases from functional requirements and use them to drive security tests?
------+V-RT-3-B Do you perform denial of service and security stress testing?
------+V-ST-1-A Do you scan applications with automated security testing tools?
------+V-ST-2-A Do you customize the automated security tools to your applications and technology stacks?
------+V-ST-3-A Do you integrate automated security testing into the build and deploy process?
------+V-ST-1-B Do you manually review the security quality of selected high-risk components?
------+V-ST-2-B Do you perform penetration testing for your applications at regular intervals?
------+V-ST-3-B Do you use the results of security testing to improve the development lifecycle?
------+O-IM-1-A Do you analyze log data for security incidents periodically?
------+O-IM-2-A Do you follow a documented process for incident detection?
------+O-IM-3-A Do you review and update the incident detection process regularly?
------+O-IM-1-B Do you respond to detected incidents?
------+O-IM-2-B Do you use a repeatable process for incident handling?
------+O-IM-3-B Do you have a dedicated incident response team available?
------+O-EM-1-A Do you harden configurations for key components of your technology stacks?
------+O-EM-2-A Do you have hardening baselines for your components?
------+O-EM-3-A Do you monitor and enforce conformity with hardening baselines?
------+O-EM-1-B Do you identify and patch vulnerable components?
------+O-EM-2-B Do you follow an established process for updating components of your technology stacks?
------+O-EM-3-B Do you regularly evaluate components and review patch level status?
------+O-OM-1-A Do you protect and handle information according to protection requirements for data stored and processed on each application?
------+O-OM-2-A Do you maintain a data catalog, including types, sensitivity levels, and processing and storage locations?
------+O-OM-3-A Do you regularly review and update the data catalog and your data protection policies and procedures?
------+O-OM-1-B Do you identify and remove systems, applications, application dependencies, or services that are no longer used, have reached end of life, or are no longer actively developed or supported?
------+O-OM-2-B Do you follow an established process for removing all associated resources, as part of decommissioning of unused systems, applications, application dependencies, or services?
------+O-OM-3-B Do you regularly evaluate the lifecycle state and support status of every software asset and underlying infrastructure component, and estimate their end of life?

OWASP Software Assurance Maturity Model (SAMM) v2.2.0

The OWASP Software Assurance Maturity Model (SAMM) helps organisations analyse and improve their software security posture: five business functions with three security practices each, every practice in two streams of activities on three maturity levels.

Maturity level 1: The first maturity level aims at achieving an ad-hoc, best effort implementation of a particular activity within a stream.

Maturity level 2: The second maturity level aims to establish a consistent, repeatable process that can be relied on.

Maturity level 3: The third maturity level aims to maximize effectiveness through continuous improvement, based on effective and timely feedback.

1. Översikt

Governance

Governance focuses on the processes and activities related to how an organization manages overall software development activities. More specifically, this includes concerns that impact cross-functional groups involved in development, as well as business processes established at the organization level.
Design

Design concerns the processes and activities related to how an organization defines goals and creates software within development projects. In general, this will include requirements gathering, high-level architecture specification and detailed design.
Implementation

Implementation is focused on the processes and activities related to how an organization builds and deploys software components and their related defects.

Activities within the Implementation function have the most impact on the daily life of developers. The joint goal is to ship reliably working software with minimum defects.
Verification

Verification focuses on the processes and activities related to how an organization checks and tests artifacts produced throughout software development. This typically includes quality assurance work such as testing, but it can also include other review and evaluation activities.
Operations

The Operations Business Function encompasses those activities necessary to ensure confidentiality, integrity, and availability are maintained throughout the operational lifetime of an application and its associated data. Increased maturity with regard to this Business Function provides greater assurance that the organization is resilient in the face of operational disruptions, and responsive to changes in the operational landscape.

1.1 Referenser

1.2 Identifierade krav

1.3 Relaterade regleringar

2. Identifierade krav

Krav

3. Relaterade regleringar

Regleringar

Länkade ärenden

Länkar
includes SAMM Assessment Questions
is related to English
is related to Cybersecurity
is related to ICT
  • OWASP -

    EN: Publications of the OWASP Foundation, https://owasp.org/. OWASP® is a registered trademark of the OWASP Foundation, Inc.; GRCA is not affiliated with, nor endorsed by, the OWASP Foundation. Only the versions published by OWASP are authoritative.

    DE: Veröffentlichungen der OWASP Foundation, https://owasp.org/. OWASP® ist eine eingetragene Marke der OWASP Foundation, Inc.; GRCA steht in keiner Verbindung zur OWASP Foundation und wird von ihr nicht unterstützt. Maßgeblich sind allein die von OWASP veröffentlichten Fassungen.