Security Maturity Models: CMMI, C2M2, BSIMM und OpenSAMM im Vergleich

Nicht jede Sicherheitsmaßnahme ist für jeden Reifegrad geeignet. Ein Unternehmen ohne funktionierendes Patch-Management braucht kein Red-Team-Programm. Security Maturity Models liefern einen strukturierten Rahmen um den aktuellen Stand zu messen, Prioritäten zu setzen und eine klare Roadmap zur Verbesserung zu entwickeln.

Grundkonzept: Was messen Maturity Models?

Reifegrade - allgemeines Konzept (CMM-basiert):

Level 0 - Nicht vorhanden:
  → Keine Prozesse, keine Verantwortlichkeiten
  → Sicherheit passiert "zufällig" oder gar nicht

Level 1 - Initial (Ad-hoc):
  → Reaktives Vorgehen (erst nach Vorfällen)
  → Keine dokumentierten Prozesse
  → Hängt von Einzelpersonen ab (nicht wiederholbar)

Level 2 - Managed (Wiederholt):
  → Grundprozesse vorhanden, aber inkonsistent
  → Verantwortlichkeiten definiert
  → Ergebnisse nicht vorhersagbar

Level 3 - Defined (Definiert):
  → Standardisierte Prozesse dokumentiert
  → Regelmäßige Reviews + Trainings
  → Organisationsweit konsistent

Level 4 - Quantitatively Managed (Quantitativ gesteuert):
  → Metriken und KPIs für Sicherheitsprozesse
  → Datengetriebene Entscheidungen
  → Proaktive Erkennung von Abweichungen

Level 5 - Optimizing (Kontinuierlich verbessert):
  → Kontinuierliche Prozessverbesserung
  → Innovation und Benchmarking
  → Branchenführer-Niveau

Unterschied: Framework-Fokus
  C2M2:    Operational Technology + IT-Sicherheit (Energie/KRITIS)
  BSIMM:   Software-Sicherheitsprogramme (AppSec)
  OpenSAMM: Software-Assurance für Entwicklungsteams
  CIS Controls: Technical Controls (konkrete Maßnahmen)
  ISO 27001: ISMS-Aufbau (Management-Anforderungen)

C2M2 - Cybersecurity Capability Maturity Model

C2M2 Version 2.1 (US Department of Energy, 2021):

Fokus: Energie- und KRITIS-Sektor, IT + OT
Anwendung: Selbstbewertung (keine externe Zertifizierung)
Kostenlos: verfügbar unter 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: Nicht implementiert
  MIL1: Initial (Praktiken partiell implementiert)
  MIL2: Performed (Praktiken vollständig implementiert)
  MIL3: Managed (Praktiken gemanagt, dokumentiert, regelmäßig bewertet)

Beispiel-Praktiken aus Domain ACCESS (Identity and Access Management):
  MIL1: Benutzeraccounts werden inventarisiert
  MIL1: Passwörter werden verwendet
  MIL2: Privilegierte Accounts werden getrennt verwaltet
  MIL2: MFA für privilegierte Accounts implementiert
  MIL3: Zugriffsrechte werden regelmäßig überprüft (Reviews)
  MIL3: Least-Privilege-Prinzip ist dokumentiert und erzwungen

C2M2 Tooling:
  → Kostenloses Excel-Werkzeug auf energy.gov
  → Self-Assessment-Modus: Workshops mit IT + OT-Teams
  → Empfohlene Vorgehensweise: 2-3 Tage Assessment-Workshop

Eignung:
  ✓ Sehr gut für KRITIS-Betreiber (Energie, Wasser, Transport)
  ✓ NIS2-Readiness-Bewertung (viele Überschneidungen)
  ✓ Kombinierbar mit IEC 62443 (OT-Security)
  ✗ Kein Fokus auf Software-Entwicklung
  ✗ US-zentriert (aber auch in DACH verwendet)

BSIMM - Building Security In Maturity Model

BSIMM 14 (2024):
  → Datengetriebenes Modell: basiert auf realen Beobachtungen in 130+ Firmen
  → Jährlich aktualisiert (Synopsys)
  → Kostenfrei (bsimm.com)
  → Beschreibt WAS getan wird - keine Vorschrift WIE

4 Domains → 12 Practices → 121 Activities:

Domain 1: Governance
  Strategy & Metrics (SM):   Sicherheitsstrategie, Roadmap, Metriken
  Compliance & Policy (CP):  Richtlinien, regulatorische Anforderungen
  Training (T):              Security-Awareness, Entwickler-Schulungen

Domain 2: Intelligence
  Attack Models (AM):        Threat Modeling, STRIDE, Kill-Chain-Analyse
  Security Features & Design (SFD): Crypto-Standards, Auth-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, manuelles Code-Review
  Security Testing (ST):         Penetrationstest, DAST, Fuzzing

Domain 4: Deployment
  Penetration Testing (PT):      Externe Pentests, Bug-Bounty
  Software Environment (SE):     Container-Security, OS-Härtung, SBOMs
  Configuration Management & Vulnerability Management (CMVM): Patch-Mgmt

Wie BSIMM funktioniert:
  1. Interview mit Security-Champions + CISO + Dev-Leads
  2. Jede der 121 Aktivitäten: "Tun wir das?" (Ja/Nein)
  3. Ergebnis: Profil mit Aktivitätsdichte pro Domain
  4. Vergleich mit BSIMM-Benchmarks: wo liegt Ihre Branche?

Beispiel-Aktivitäten:
  SM1.1:  Publish data about software security internally
  T1.1:   Provide awareness training → alle Entwickler
  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 Eignung:
  ✓ Ideal für Softwareunternehmen und Produkt-Teams
  ✓ Benchmarking gegen Branche (echte Daten!)
  ✓ Roadmap-Grundlage: "Was machen die Top 25% unserer Branche?"
  ✗ Nicht als Compliance-Checkliste geeignet
  ✗ Assessment erfordert BSIMM-zertifizierten Berater

OpenSAMM - Software Assurance Maturity Model

OpenSAMM 2.1 (OWASP, 2020):
  → Open Source, keine Lizenzkosten
  → Stärker normativ als BSIMM (erklärt WIE)
  → Besonders für kleinere Teams + Agile-Umgebungen geeignet
  → Tools: sammy-CLI, SAMMwise, samm.owasp.org

5 Business Functions → 15 Security Practices:

Governance:
  Strategy & Metrics:    Sicherheitsstrategie, Metriken, ROI
  Policy & Compliance:   Richtlinien, externe Anforderungen
  Education & Guidance:  Security-Training für Entwickler

Design:
  Threat Assessment:     Threat Modeling (STRIDE, Attack Trees)
  Security Requirements: OWASP ASVS, Compliance-Anforderungen
  Security Architecture: Patterns, Crypto-Standards, Trust-Zonen

Implementation:
  Secure Build:          SAST, Dependency-Scanning, Compiler-Flags
  Secure Deployment:     Secrets-Management, Container-Härtung
  Defect Management:     Bug-Tracking, SLAs für Schwachstellen

Verification:
  Architecture Assessment: Threat-Model-Validation, Design-Review
  Requirements-driven Testing: Security-Test-Cases aus Requirements
  Security Testing:      DAST, Penetration Testing, Fuzzing

Operations:
  Incident Management:   IR-Plan, Runbooks, Post-Mortems
  Environment Management: Patch-Management, Configuration-Mgmt
  Operational Management: Dependency-Monitoring, SBOM-Pflege

Maturity-Level pro Praxis:
  Level 0: Kein Prozess vorhanden
  Level 1: Ad-hoc (grundlegendste Aktivitäten)
  Level 2: Standardisiert (dokumentiert, konsistent)
  Level 3: Optimiert (Metriken, kontinuierlich verbessert)

Roadmap-Erstellung mit OpenSAMM:
  1. Self-Assessment: alle 15 Practices bewerten (Level 0-3)
  2. Target-State definieren (realistisch: +1 Level pro Jahr)
  3. Gap-Analyse: fehlende Aktivitäten identifizieren
  4. Quarterly OKRs aus Roadmap ableiten

Beispiel-Roadmap (mittelständisches Softwareunternehmen):
  Quartal 1: Threat Assessment L1 + Secure Build L1 (SAST einführen)
  Quartal 2: Security Testing L1 (erster Pentest), Policy L1
  Quartal 3: Defect Management L1 (SLAs), Security Requirements L1
  Quartal 4: Incident Management L1 (IR-Plan), Jahresmesssung

Praktische Anwendung: Security Maturity Assessment

Vorgehen für ein Security Maturity Assessment:

Schritt 1 - Framework-Auswahl:
  Software-Produkt-Unternehmen:    OpenSAMM oder BSIMM
  KRITIS/Energie/OT:               C2M2
  ISO-27001-orientiert:            ISO/IEC 21827 (SSE-CMM)
  Allgemeines KMU:                 CIS Controls + vereinfachtes C2M2

Schritt 2 - Assessment-Durchführung:
  Methoden:
  a) Workshop-basiert (empfohlen für erste Bewertung):
     → 2-3 Tage mit CISO, IT-Leitung, Security-Team
     → Strukturierte Interviews + Dokumentenprüfung
     → Ehrliche Selbsteinschätzung wichtiger als gutes Ergebnis!

  b) Dokumentenbasiert:
     → Richtlinien, Prozesse, Tool-Konfigurationen prüfen
     → Evidence-basiert (kann ich es nachweisen?)

  c) Kombiniert (am genauesten):
     → Interviews + Dokumentenprüfung + Stichproben-Tests

Schritt 3 - Scoring und Visualisierung:
  Radar-Chart (Spider-Diagramm):
    → Achsen: alle Domains/Practices
    → Innen: aktueller Reifegrad
    → Außen: angestrebter Reifegrad
    → Visuell sofort sichtbar: wo sind die größten Lücken?

  Heat-Map:
    Domain          | L0 | L1 | L2 | L3
    ─────────────────────────────────────
    Access Mgmt     |    |    | X  |
    Threat Mgmt     |    | X  |    |
    Incident Resp.  | X  |    |    |
    → Rot: L0, Gelb: L1, Hellgrün: L2, Dunkelgrün: L3

Schritt 4 - Roadmap-Ableitung:
  Priorisierungskriterien:
  a) Risikoreduktion: was reduziert die größten Risiken?
  b) Quick Wins: was ist in 1-3 Monaten umsetzbar?
  c) Abhängigkeiten: manche Practices setzen andere voraus
  d) Ressourcen: Kosten, Zeit, Expertise

  Beispiel-Priorisierung:
  Priorität 1 (Sofort, <3 Monate):
    → MFA für alle Admins einführen
    → Patch-Management-Prozess definieren
    → IR-Grundplan erstellen

  Priorität 2 (Kurzfristig, 3-6 Monate):
    → SAST in CI/CD-Pipeline
    → Asset-Inventar vollständig
    → Security-Awareness-Training

  Priorität 3 (Mittelfristig, 6-12 Monate):
    → Threat-Modeling-Prozess
    → Vulnerability-Disclosure-Programm
    → SOC oder MDR-Service

Schritt 5 - Kontinuierliche Messung:
  □ Jährliches Re-Assessment (Verbesserung messbar!)
  □ KPI-Dashboard: wichtige Sicherheitsmetriken
  □ Trend-Analyse: Mean Time to Remediate (MTTR), Open Findings
  □ Management-Reporting: Fortschritt visualisieren

KPIs für Security Maturity:
  Metric                          Formel/Messung
  ──────────────────────────────────────────────
  Vulnerability Remediation Rate  % kritischer CVEs behoben <30 Tage
  Mean Time to Detect (MTTD)      Ø Zeit Kompromittierung → Erkennung
  Mean Time to Respond (MTTR)     Ø Zeit Erkennung → Eindämmung
  Security Training Coverage      % Mitarbeiter mit aktuellem Training
  Critical Asset Coverage (MFA)   % kritische Systeme mit MFA
  Patch Compliance Rate           % Systeme mit aktuellen Patches
  Pen Test Finding Recurrence     % Findings aus letztem Test offen

Maturity Models und Compliance

Verbindung zu regulatorischen Anforderungen:

ISO 27001 ↔ Maturity Models:
  → ISO 27001 definiert ANFORDERUNGEN (was muss vorhanden sein)
  → Maturity Models messen REIFEGRAD (wie gut ist es implementiert)
  → ISO 27001 Annex A Controls lassen sich mit OpenSAMM/C2M2 mappen
  → Typisch: ISO 27001 zertifiziert = Maturity Level 2 in den meisten Domains

NIS2 und C2M2:
  NIS2 Artikel 21 Anforderungen → C2M2 Mapping:
  - Risikomanagement → 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)
  - Kryptographie → ARCHITECTURE Domain (C2M2)

  NIS2 "angemessene Sicherheitsmaßnahmen" = mindestens MIL1-MIL2 in C2M2!
  → Behörden könnten C2M2 als Nachweis akzeptieren

DSGVO Artikel 32 und Maturity:
  → "geeignete technische und organisatorische Maßnahmen"
  → Maturity Assessment als Nachweis des aktuellen Stands
  → Bei Datenschutzverletzung: dokumentierter Maturity-Level = Schadensminimierung

Typische Reifegradverteilung im DACH-Mittelstand:
  Domain               Ø Level    Größte Lücken
  ──────────────────────────────────────────────────
  Incident Response    0.8        IR-Plan meist nicht vorhanden
  Threat Intelligence  0.5        Kaum implementiert
  Third-Party Risk     0.9        Vendor-Assessments fehlen
  Access Management    1.4        MFA meist für Admin vorhanden
  Patch Management     1.2        Unregelmäßig, keine SLAs
  Security Training    1.1        Awareness-Trainings sporadisch