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:    Operational Technology + IT Security (Energy/KRITIS)
  BSIMM:   Software Security Programs (AppSec)
  OpenSAMM: Software Assurance for Development Teams
  CIS Controls: Technical Controls (specific measures)
  ISO 27001: ISMS framework (management requirements)

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):
  MIL0: Not implemented
  MIL1: Initial (Practices partially implemented)
  MIL2: Performed (Practices fully implemented)
  MIL3: Managed (Practices managed, documented, and regularly assessed)

Example Practices from the ACCESS Domain (Identity and Access Management):
  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:
  ✓ Very 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
  Strategy & Metrics (SM):   Security strategy, roadmap, metrics
  Compliance & Policy (CP):  Guidelines, regulatory requirements
  Training (T):              Security awareness, developer training

Domain 2: Intelligence
  Attack Models (AM):        Threat Modeling, STRIDE, Kill Chain Analysis
  Security Features & Design (SFD): Crypto Standards, Authentication Library
  Standards & Requirements (SR):   ASVS, Coding Standards

Domain 3: SSDL Touchpoints (Secure Software Development Lifecycle)
  Architecture Analysis (AA):    Threat Modeling, Secure Design Reviews
  Code Review (CR):              SAST, Manual Code Review
  Security Testing (ST):         Penetration Testing, DAST, Fuzzing

Domain 4: Deployment
  Penetration Testing (PT):      External Penetration Tests, Bug Bounty
  Software Environment (SE):     Container Security, OS Hardening, SBOMs
  Configuration Management & Vulnerability Management (CMVM): Patch Management

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 → 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:
  Level 0: No process in place
  Level 1: Ad-hoc (most basic activities)
  Level 2: Standardized (documented, consistent)
  Level 3: Optimized (metrics, continuously improved)

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:
  Software Product Companies:    OpenSAMM or BSIMM
  KRITIS/Energy/OT:               C2M2
  ISO 27001-oriented:            ISO/IEC 21827 (SSE-CMM)
  General SMEs:                 CIS Controls + simplified C2M2

Step 2 - Conducting the Assessment:
  Methods:
  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:
    Domain          | L0 | L1 | L2 | L3
    ─────────────────────────────────────
    Access Mgmt     |    |    | X  |
    Threat Mgmt     |    | X  |    |
    Incident Resp.  | X  |    |    |
    → 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:
  Metric                          Formula/Measurement
  ──────────────────────────────────────────────
  Vulnerability Remediation Rate  % of critical CVEs remediated within <30 days
  Mean Time to Detect (MTTD)      Average time from compromise to detection
  Mean Time to Respond (MTTR)     Average time from detection to containment
  Security Training Coverage      % of employees with up-to-date training
  Critical Asset Coverage (MFA)   % of critical systems with MFA
  Patch Compliance Rate           % of systems with up-to-date patches
  Pen Test Finding Recurrence     % of findings from last test still open

Maturity Models and Compliance

Connection to regulatory requirements:

ISO 27001 ↔ 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:
  - Risk Management → RISK Domain (C2M2)
  - Incident Handling → RESPONSE Domain (C2M2)
  - Business Continuity → RESPONSE Domain (C2M2)
  - Supply Chain Security → THIRD-PARTIES Domain (C2M2)
  - Access Control → ACCESS Domain (C2M2)
  - Cryptography → ARCHITECTURE Domain (C2M2)

  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:
  Domain               Average Level    Largest Gaps
  ──────────────────────────────────────────────────
  Incident Response    0.8        IR plan usually not available
  Threat Intelligence  0.5        Rarely implemented
  Third-Party Risk     0.9        Vendor assessments missing
  Access Management    1.4        MFA usually available for admins
  Patch Management     1.2        Irregular, no SLAs
  Security Training    1.1        Awareness training sporadic