Security Maturity Models: CMMI, C2M2, BSIMM and OpenSAMM in comparison

Not every security measure is suitable for every maturity level. A company without effective patch management does not need a red team program. Security maturity models provide a structured framework for assessing the current state, setting priorities, and developing a clear roadmap for improvement.

Basic Concept: What Do Maturity Models Measure?

Maturity Levels - General Concept (CMM-based):

Level 0 - Nonexistent:

• No processes, no responsibilities
• Security happens "by chance" or not at all

Level 1 - Initial (Ad-hoc):

• Reactive approach (only after incidents)
• No documented processes
• Depends on individuals (not repeatable)

Level 2 - Managed (Repeatable):

• Basic processes exist, but are inconsistent
• Responsibilities defined
• Results are not predictable

Level 3 - Defined:

• Standardized processes documented
• Regular reviews + training
• Consistent across the organization

Level 4 - Quantitatively Managed:

• Metrics and KPIs for security processes
• Data-driven decisions
• Proactive detection of deviations

Level 5 - Optimizing:

• Continuous process improvement
• Innovation and benchmarking
• Industry leader level

Difference: Framework Focus

C2M2 - Cybersecurity Capability Maturity Model

C2M2 Version 2.1 (U.S. Department of Energy, 2021):

• Focus: Energy and critical infrastructure sectors, IT + OT
• Application: Self-assessment (no external certification)
• Free: available at energy.gov

10 Domains:

1. Asset, Change, and Configuration Management (ASSET)
2. Threat and Vulnerability Management (THREAT)
3. Risk Management (RISK)
4. Identity and Access Management (ACCESS)
5. Situational Awareness (SITUATION)
6. Event and Incident Response, Continuity of Operations (RESPONSE)
7. Third-Party Risk Management (THIRD-PARTIES)
8. Workforce Management (WORKFORCE)
9. Cybersecurity Architecture (ARCHITECTURE)
10. Cybersecurity Program Management (PROGRAM)

Maturity Indicator Level (MIL):

Example Practices from the ACCESS Domain:

• MIL1: User accounts are inventoried
• MIL1: Passwords are used
• MIL2: Privileged accounts are managed separately
• MIL2: MFA implemented for privileged accounts
• MIL3: Access rights are reviewed regularly (Reviews)
• MIL3: The least privilege principle is documented and enforced

C2M2 Tooling:

• Free Excel tool on energy.gov
• Self-assessment mode: Workshops with IT + OT teams
• Recommended approach: 2-3 day assessment workshop

Suitability:

• Good for KRITIS operators (energy, water, transportation)
• NIS2 readiness assessment (many overlaps)
• Can be combined with IEC 62443 (OT security)
• No focus on software development
• US-centric (but also used in DACH)

BSIMM - Building Security In Maturity Model

BSIMM 14 (2024):

• Data-driven model: based on real-world observations in 130+ companies
• Updated annually (Synopsys)
• Free of charge (bsimm.com)
• Describes WHAT is done, no prescription on HOW

4 Domains - 12 Practices - 121 Activities:

Domain 1: Governance

Domain 2: Intelligence

Domain 3: SSDL Touchpoints (Secure Software Development Lifecycle)

Domain 4: Deployment

How BSIMM Works:

1. Interview with Security Champions + CISO + Dev Leads
2. Each of the 121 activities: "Do we do this?" (Yes/No)
3. Result: Profile showing activity density per domain
4. Comparison with BSIMM benchmarks: where does your industry stand?

Sample Activities:

• SM1.1: Publish data about software security internally
• T1.1: Provide awareness training for all developers
• CR1.4: Use automated tools along with manual review
• ST2.1: Share security results with QA
• PT1.1: Use penetration testing to find problems
• SE3.2: Implement software signing (Supply Chain Security)

BSIMM Suitability:

• Ideal for software companies and product teams
• Benchmarking against the industry (real data!)
• Roadmap foundation: "What are the top 25% of our industry doing?"
• Not suitable as a compliance checklist
• Assessment requires a BSIMM-certified consultant

OpenSAMM - Software Assurance Maturity Model

OpenSAMM 2.1 (OWASP, 2020):

• Open source, no licensing costs
• More prescriptive than BSIMM (explains HOW)
• Particularly suitable for smaller teams and Agile environments
• Tools: sammy-CLI, SAMMwise, samm.owasp.org

5 Business Functions - 15 Security Practices:

Governance:

• Strategy & Metrics: Security strategy, metrics, ROI
• Policy & Compliance: Policies, external requirements
• Education & Guidance: Security training for developers

Design:

• Threat Assessment: Threat modeling (STRIDE, attack trees)
• Security Requirements: OWASP ASVS, compliance requirements
• Security Architecture: Patterns, cryptographic standards, trust zones

Implementation:

• Secure Build: SAST, dependency scanning, compiler flags
• Secure Deployment: Secrets management, container hardening
• Defect Management: Bug tracking, SLAs for vulnerabilities

Verification:

• Architecture Assessment: Threat Model Validation, Design Review
• Requirements-driven Testing: Security Test Cases Derived from Requirements
• Security Testing: DAST, Penetration Testing, Fuzzing

Operations:

• Incident Management: IR Plan, Runbooks, Post-Mortems
• Environment Management: Patch Management, Configuration Management
• Operational Management: Dependency Monitoring, SBOM Maintenance

Maturity Level per Practice:

Roadmap Creation with OpenSAMM:

1. Self-Assessment: Evaluate all 15 practices (Levels 0-3)
2. Define target state (realistic: +1 level per year)
3. Gap analysis: Identify missing activities
4. Derive quarterly OKRs from the roadmap

Sample Roadmap (mid-sized software company):

• Quarter 1: Threat Assessment L1 + Secure Build L1 (implement SAST)
• Quarter 2: Security Testing L1 (first penetration test), Policy L1
• Quarter 3: Defect Management L1 (SLAs), Security Requirements L1
• Quarter 4: Incident Management L1 (IR plan), annual assessment

Practical Application: Security Maturity Assessment

Procedure for a Security Maturity Assessment:

Step 1 - Framework Selection:

Step 2 - Conducting the Assessment:

a) Workshop-based (recommended for initial assessment):

• 2-3 days with CISO, IT management, security team
• Structured interviews + document review
• Honest self-assessment is more important than a good result!

b) Document-based:

• Review policies, processes, and tool configurations
• Evidence-based (can I prove it?)

c) Combined (most accurate):

• Interviews + document review + spot checks

Step 3 - Scoring and Visualization:

Radar chart (spider diagram):

• Axes: all domains/practices
• Inner: current maturity level
• Outer: target maturity level
• Visually immediately apparent: where are the biggest gaps?

Heat map:

Red: L0, Yellow: L1, Light Green: L2, Dark Green: L3

Step 4 - Deriving the Roadmap:

Prioritization Criteria:

• a) Risk Reduction: What reduces the greatest risks?
• b) Quick Wins: What can be implemented in 1-3 months?
• c) Dependencies: Some practices require others
• d) Resources: Cost, time, expertise

Example Prioritization:

Priority 1 (Immediate, <3 months):

• Implement MFA for all admins
• Define patch management process
• Create basic IR plan

Priority 2 (Short-term, 3-6 months):

• SAST in CI/CD pipeline
• Complete asset inventory
• Security awareness training

Priority 3 (Medium-term, 6-12 months):

• Threat modeling process
• Vulnerability disclosure program
• SOC or MDR service

Step 5 - Continuous Measurement:

• Annual reassessment (measurable improvement!)
• KPI dashboard: key security metrics
• Trend Analysis: Mean Time to Remediate (MTTR), Open Findings
• Management Reporting: Visualize Progress

KPIs for Security Maturity:

Maturity Models and Compliance

Connection to regulatory requirements:

ISO 27001 and Maturity Models:

• ISO 27001 defines REQUIREMENTS (what must be in place)
• Maturity Models measure MATURITY LEVEL (how well is it implemented)
• ISO 27001 Annex A Controls can be mapped to OpenSAMM/C2M2
• Typically: ISO 27001 certified = Maturity Level 2 in most domains

NIS2 and C2M2:

NIS2 Article 21 Requirements - C2M2 Mapping:

NIS2 "appropriate security measures" = at least MIL1-MIL2 in C2M2. Authorities could accept C2M2 as proof.

GDPR Article 32 and Maturity:

• "appropriate technical and organizational measures"
• Maturity Assessment as proof of current status
• In the event of a data breach: documented maturity level = damage mitigation

Typical maturity distribution among SMEs in the DACH region: