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?

Die Reifegrade basieren auf dem CMM-Konzept und verlaufen von Level 0 (keine Prozesse, keine Verantwortlichkeiten, Sicherheit passiert zufällig oder gar nicht) über Level 1 Initial (reaktives Vorgehen nach Vorfällen, keine dokumentierten Prozesse, abhängig von Einzelpersonen) und Level 2 Managed (Grundprozesse vorhanden aber inkonsistent, Verantwortlichkeiten definiert) bis Level 3 Defined (standardisierte Prozesse dokumentiert, regelmäßige Reviews und Trainings, organisationsweit konsistent), Level 4 Quantitatively Managed (Metriken und KPIs, datengetriebene Entscheidungen) und Level 5 Optimizing (kontinuierliche Prozessverbesserung, Innovation und Benchmarking).

Die verschiedenen Frameworks haben unterschiedliche Schwerpunkte: C2M2 fokussiert auf Operational Technology und IT-Sicherheit im Energie- und KRITIS-Bereich, BSIMM auf Software-Sicherheitsprogramme (AppSec), OpenSAMM auf Software-Assurance für Entwicklungsteams, CIS Controls auf konkrete technische Maßnahmen und ISO 27001 auf den ISMS-Aufbau mit Management-Anforderungen.

C2M2 - Cybersecurity Capability Maturity Model

C2M2 Version 2.1 (US Department of Energy, 2021) richtet sich an den Energie- und KRITIS-Sektor mit IT und OT. Es handelt sich um eine Selbstbewertung ohne externe Zertifizierung, die kostenlos unter energy.gov verfügbar ist.

Das Modell umfasst zehn Domains: Asset, Change and Configuration Management (ASSET), Threat and Vulnerability Management (THREAT), Risk Management (RISK), Identity and Access Management (ACCESS), Situational Awareness (SITUATION), Event and Incident Response / Continuity of Operations (RESPONSE), Third-Party Risk Management (THIRD-PARTIES), Workforce Management (WORKFORCE), Cybersecurity Architecture (ARCHITECTURE) und Cybersecurity Program Management (PROGRAM).

Die drei Maturity Indicator Levels (MIL) sind: MIL0 (nicht implementiert), MIL1 Initial (Praktiken partiell implementiert) und MIL2 Performed (Praktiken vollständig implementiert) sowie MIL3 Managed (gemanagt, dokumentiert, regelmäßig bewertet).

Beispielpraktiken aus der Domain ACCESS: MIL1 umfasst die Inventarisierung von Benutzeraccounts und die Nutzung von Passwörtern. MIL2 verlangt getrennte Verwaltung privilegierter Accounts und MFA dafür. MIL3 fordert regelmäßige Zugriffsrechte-Reviews und dokumentiertes Least-Privilege-Prinzip.

C2M2 eignet sich sehr gut für KRITIS-Betreiber (Energie, Wasser, Transport), für NIS2-Readiness-Bewertungen und in Kombination mit IEC 62443 für OT-Security. Es hat keinen Fokus auf Software-Entwicklung und ist US-zentriert, wird aber auch im DACH-Raum eingesetzt.

BSIMM - Building Security In Maturity Model

BSIMM 14 (2024) ist ein datengetriebenes Modell, das auf realen Beobachtungen in über 130 Firmen basiert und jährlich von Synopsys aktualisiert wird. Es beschreibt, was in der Praxis getan wird - keine Vorschrift wie. Verfügbar kostenlos unter bsimm.com.

Das Modell umfasst vier Domains mit zwölf Practices und 121 Activities:

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

Domain 2 Intelligence: Attack Models (Threat Modeling, STRIDE, Kill-Chain-Analyse), Security Features & Design (Crypto-Standards, Auth-Library), Standards & Requirements (ASVS, Coding-Standards).

Domain 3 SSDL Touchpoints: Architecture Analysis (Threat Modeling, Secure Design Reviews), Code Review (SAST, manuelles Code-Review), Security Testing (Penetrationstest, DAST, Fuzzing).

Domain 4 Deployment: Penetration Testing (externe Pentests, Bug-Bounty), Software Environment (Container-Security, OS-Härtung, SBOMs), Configuration Management & Vulnerability Management (Patch-Management).

Die Durchführung besteht aus Interviews mit Security-Champions, CISO und Dev-Leads, bei denen jede der 121 Aktivitäten mit Ja oder Nein bewertet wird. Das Ergebnis ist ein Profil mit Aktivitätsdichte pro Domain, das gegen BSIMM-Benchmarks verglichen werden kann: "Wo liegt unsere Branche?"

BSIMM ist ideal für Softwareunternehmen und Produkt-Teams, bietet echtes Benchmarking gegen Branchendaten und liefert eine Roadmap-Grundlage. Es ist nicht als Compliance-Checkliste geeignet und erfordert für das Assessment einen BSIMM-zertifizierten Berater.

OpenSAMM - Software Assurance Maturity Model

OpenSAMM 2.1 (OWASP, 2020) ist Open Source ohne Lizenzkosten, stärker normativ als BSIMM (erklärt das Wie) und besonders für kleinere Teams und Agile-Umgebungen geeignet. Tools: sammy-CLI, SAMMwise, samm.owasp.org.

Das Modell umfasst fünf Business Functions mit 15 Security Practices:

Governance: Strategy & Metrics, Policy & Compliance, Education & Guidance
Design: Threat Assessment, Security Requirements, Security Architecture
Implementation: Secure Build (SAST, Dependency-Scanning), Secure Deployment (Secrets-Management, Container-Härtung), Defect Management (Bug-Tracking, SLAs)
Verification: Architecture Assessment, Requirements-driven Testing, Security Testing (DAST, Penetration Testing, Fuzzing)
Operations: Incident Management, Environment Management, Operational Management (SBOM-Pflege)

Jede Praxis hat drei Maturity-Level: Level 1 Ad-hoc (grundlegendste Aktivitäten), Level 2 Standardisiert (dokumentiert und konsistent), Level 3 Optimiert (Metriken, kontinuierlich verbessert).

Eine Roadmap-Erstellung mit OpenSAMM folgt vier Schritten: Self-Assessment aller 15 Practices (Level 0-3), Definition eines realistischen Target-State (+1 Level pro Jahr), Gap-Analyse der fehlenden Aktivitäten und Ableitung von Quarterly OKRs.

Beispiel-Roadmap für ein mittelständisches Softwareunternehmen: Quartal 1 - Threat Assessment L1 und Secure Build L1 (SAST einführen); Quartal 2 - Security Testing L1 (erster Pentest) und Policy L1; Quartal 3 - Defect Management L1 (SLAs) und Security Requirements L1; Quartal 4 - Incident Management L1 (IR-Plan) und Jahresmessung.

Praktische Anwendung: Security Maturity Assessment

Schritt 1 - Framework-Auswahl: Software-Produkt-Unternehmen nutzen OpenSAMM oder BSIMM, KRITIS/Energie/OT nutzen C2M2, ISO-27001-orientierte Unternehmen ISO/IEC 21827 (SSE-CMM), allgemeine KMU CIS Controls kombiniert mit einem vereinfachten C2M2.

Schritt 2 - Assessment-Durchführung: Die zuverlässigste Methode kombiniert Workshop-basierte Interviews (2-3 Tage mit CISO, IT-Leitung, Security-Team) mit Dokumentenprüfung (Richtlinien, Prozesse, Tool-Konfigurationen) und Stichproben-Tests. Dabei gilt: eine ehrliche Selbsteinschätzung ist wichtiger als ein gutes Ergebnis.

Schritt 3 - Scoring und Visualisierung: Ein Radar-Chart (Spider-Diagramm) macht Lücken sofort sichtbar: innen der aktuelle Reifegrad, außen der angestrebte. Eine Heat-Map zeigt den Status pro Domain:

Domain	Aktuell	Bemerkung
Access Management	L2	MFA für Admins vorhanden
Threat Management	L1	Kein proaktives TI-Programm
Incident Response	L0	IR-Plan nicht vorhanden

Schritt 4 - Roadmap-Ableitung: Priorisierungskriterien sind Risikoreduktion, Quick Wins (umsetzbar in 1-3 Monaten), Abhängigkeiten zwischen Practices und verfügbare Ressourcen. Priorität 1 (Sofort, unter 3 Monate): MFA für alle Admins, Patch-Management-Prozess, IR-Grundplan. Priorität 2 (3-6 Monate): SAST in CI/CD, vollständiges Asset-Inventar, Security-Awareness-Training. Priorität 3 (6-12 Monate): Threat-Modeling-Prozess, Vulnerability-Disclosure-Programm, SOC oder MDR-Service.

Schritt 5 - Kontinuierliche Messung: Jährliches Re-Assessment macht Verbesserungen messbar. Ein KPI-Dashboard mit Trend-Analyse (MTTR, Open Findings) und Management-Reporting visualisiert den Fortschritt.

Wichtige KPIs für Security Maturity:

Metrik	Formel / Messung
Vulnerability Remediation Rate	% kritischer CVEs behoben in unter 30 Tagen
Mean Time to Detect (MTTD)	Ø Zeit von Kompromittierung bis Erkennung
Mean Time to Respond (MTTR)	Ø Zeit von Erkennung bis 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 noch offen

Maturity Models und Compliance

ISO 27001 und Maturity Models: ISO 27001 definiert Anforderungen (was vorhanden sein muss), Maturity Models messen den Reifegrad (wie gut implementiert). ISO 27001 Annex A Controls lassen sich mit OpenSAMM/C2M2 mappen. Typischerweise entspricht eine ISO 27001 Zertifizierung etwa Maturity Level 2 in den meisten Domains.

NIS2 und C2M2: Die Anforderungen aus Art. 21 NIS2 lassen sich direkt auf C2M2 Domains mappen: Risikomanagement auf die RISK Domain, Incident Handling und Business Continuity auf die RESPONSE Domain, Supply Chain Security auf THIRD-PARTIES, Access Control auf ACCESS und Kryptographie auf ARCHITECTURE. "Angemessene Sicherheitsmaßnahmen" im Sinne von NIS2 entsprechen mindestens MIL1 bis MIL2 in C2M2.

DSGVO Art. 32: Ein dokumentierter Maturity-Level dient als Nachweis "geeigneter technischer und organisatorischer Maßnahmen" und kann bei einer Datenschutzverletzung die Haftung mindern.

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 Admins vorhanden
Patch Management	1,2	Unregelmäßig, keine SLAs
Security Training	1,1	Awareness-Trainings sporadisch