Zum Inhalt springen

Services, Wiki-Artikel und Blog-Beiträge durchsuchen

↑↓NavigierenEnterÖffnenESCSchließen

Security Metriken und KPIs: Sicherheit messbar machen

Sicherheitsmetriken sind der Beweis dass Investitionen in IT-Sicherheit wirken. Dieser Artikel erklärt welche KPIs für Operations (MTTD, MTTR, FP-Rate), Vulnerability Management (Patch Compliance, MTTR), Awareness Training (Phishing-Klickrate), Compliance (Audit-Erfüllungsgrad) und strategische Board-Berichte relevant sind - mit konkreten Zielwerten und Messformeln.

Inhaltsverzeichnis (6 Abschnitte)

Kurzerklärung: Security Ratings sind kontinuierliche, automatisierte Bewertungen der Cybersicherheit einer Organisation auf einer Skala (typisch 0-900 oder A-F), basierend auf öffentlich sichtbaren Indikatoren: offene Ports, SSL-Konfiguration, DNS-Records, Dark-Web-Einträge, kompromittierte Systeme. Anbieter wie BitSight, SecurityScorecard und Riskrecon werden für Vendor-Risikobewertungen, Cyber-Versicherungen und Executive-Reporting genutzt.

"You can't manage what you can't measure" gilt besonders für IT-Sicherheit. Ohne Metriken weiß niemand ob das Security-Programm wirkt, ob Investitionen berechtigt sind, oder ob das Risiko steigt oder fällt. Dieser Artikel gibt einen vollständigen KPI-Rahmen für verschiedene Sicherheitsbereiche.

Warum Metriken scheitern (und wie man es besser macht)

Die häufigsten Fehler bei Security-Metriken:

Aktivitäts-Metriken statt Outcome-Metriken: "Wir haben 150 Vulnerabilities gepatcht diesen Monat" sagt nichts. Besser: "Kritische Patch-Compliance stieg von 73% auf 91%."

Zu viele Metriken: 50 KPIs bedeuten, dass niemand versteht was wichtig ist. Die Lösung sind 5-7 strategische KPIs und 15-20 operative Metriken.

Metriken ohne Baseline und Ziel: "MTTD: 48 Stunden" ist bedeutungslos. Aussagekräftig ist: "MTTD: 48h (Baseline: 96h, Ziel: unter 24h, Trend: sinkend)."

Falscher Empfänger: Technische Metriken vor dem Board erzeugen keine Entscheidungen. Board-Metriken sprechen über Risiko, Business Impact und EUR. Ops-Metriken sprechen über MTTD, FP-Rate und Incidents pro Woche.

Ein gutes Metriken-Framework beginnt mit der Definition des Ziels (was soll besser werden?), etabliert eine Baseline (Ausgangszustand), setzt einen Zielwert, legt die Messmethode fest und definiert die Reporting-Cadence (täglich, wöchentlich, monatlich, quartalsweise).

Security Operations KPIs

MTTD (Mean Time to Detect) misst die Zeit von Angriffsbeginn bis Erkennung. Die Formel ist: Summe der Erkennungszeiten minus Angriffsbeginn, dividiert durch Anzahl Incidents. Der IBM DBIR 2024 Benchmark liegt bei 204 Tagen. SOC-Ziel ist unter 24h für kritische Incidents, Best-in-Class unter 1 Stunde. Gemessen wird über SIEM-Timestamps.

MTTR (Mean Time to Respond/Contain) misst die Zeit von Erkennung bis Eindämmung. Der Branchenalltag liegt laut IBM DBIR bei 73 Tagen bis zum Containment. SOC-Ziel ist unter 4h für kritische Incidents.

MTTF (Mean Time to Fully Remediate) misst die Zeit von Erkennung bis vollständiger Behebung. Zielwerte: Kritisch unter 24h, Hoch unter 7 Tage, Mittel unter 30 Tage.

Alert Quality Score misst den Anteil echter Positives an allen Alerts: True Positives / (True Positives + False Positives) × 100. Ziel ist über 70%. Unter 70% entsteht Alert Fatigue - Analysten ignorieren Alerts und das SOC wird blind.

Incident Volume zählt Incidents pro Zeitraum nach Schweregrad. Der Trend ist wichtiger als die absolute Zahl. Kritische Incidents: Ziel unter 5 pro Monat. Ein stark steigendes Medium-Volumen ist ein Warnsignal.

Beispiel SOC-Reporting-Tabelle:

KPIAktuellVormonatZielTrend
MTTD (kritisch)18h24h<12hpositiv
MTTR (kritisch)3,5h4,8h<4hpositiv
Alert Quality68%61%>70%positiv
FP-Rate32%39%<30%positiv
Incidents (Krit.)24<5positiv
SIEM Coverage87%82%>95%positiv

Vulnerability Management KPIs

Patch Compliance Rate misst den Prozentsatz der Systeme mit installiertem Patch innerhalb der SLA: gepatchte Systeme dividiert durch alle betroffenen Systeme. Ziele: Critical über 99%, High über 95%, Medium über 90%. Critical-Patches sind extern innerhalb 24h und intern innerhalb 72h fällig.

Mean Time to Remediate (Vulnerability) ist die durchschnittliche Zeit von der Entdeckung bis zum Patch. Ziele: Critical unter 3 Tage, High unter 14 Tage, Medium unter 45 Tage.

Vulnerability Discovery Rate misst die Zeit von der CVE-Veröffentlichung bis zur Erfassung im eigenen System. Ziel unter 48 Stunden für Critical CVEs, gemessen am NVD-Veröffentlichungsdatum gegenüber dem Scanner-Ergebnis.

Overdue Findings zählt Findings außerhalb der SLA. Ziel: 0 Critical/High außerhalb der SLA. Jede Überschreitung sollte eine automatische CISO-Meldung auslösen.

Attack Surface Trend visualisiert die Entwicklung offener Findings über Zeit als Burn-Down-Chart. Ein steigender Trend bedeutet, dass neue Vulnerabilities schneller entdeckt werden als Behebungen erfolgen. Gleichbleibend ist akzeptabel, sinkend ist optimal.

Scanner Coverage misst den Prozentsatz der bekannten Assets, die gescannt werden. Ziel über 95%. Unter 90% entstehen blinde Flecken im Vulnerability Program.

Beispiel monatliches Dashboard:

SchweregradNeu entdecktBehobenOffenCompliance Rate
Critical1215897% (Ziel: >99%)
High45512393%
Medium18014523488%

Security Awareness Metriken

Klickrate misst den Prozentsatz der Empfänger, die auf Phishing-Links klicken. Branchenschnitt ohne Training: 17-25%. Ziel nach Training: unter 5%. Best-in-Class: unter 2%. Ein Warnsignal ist eine Rate über 15% nach 6 Monaten Training.

Report Rate misst den Prozentsatz der Empfänger, die Phishing korrekt melden. Ziel über 30%. Reporting ist wichtiger als Nicht-Klicken, da gemeldet Phishing sofort für alle abgewehrt werden kann.

Time to Report misst die Zeit von Phishing-Empfang bis Meldung. Ziel unter 30 Minuten, Best-in-Class unter 5 Minuten für Echtzeit-Abwehr.

Repeat Clicker Rate misst den Prozentsatz der User, die mehrfach auf Phishing klicken. Ziel unter 3% nach Training. Repeat Clicker sollten intensiviertes 1:1-Training erhalten.

Pflicht-Training Completion misst den Prozentsatz der Mitarbeiter mit abgeschlossenem Pflichtkurs. Ziel ist 100% als Compliance-Anforderung.

Knowledge Retention misst den Test-Score 30/60/90 Tage nach dem Training durch automatische Follow-up-Quizzes im LMS. Ziel über 80% Retention nach 30 Tagen.

Training Effectiveness berechnet die Klickraten-Reduktion: (Klickrate vorher - Klickrate nachher) / Klickrate vorher × 100. Beispiel: 23% → 7% = 70% Reduktion belegt, dass das Training wirkt.

Compliance und Audit-Metriken

Control Effectiveness Rate misst den Prozentsatz der Kontrollen, die auditkonform implementiert sind. Ziel über 95% für kritische Controls.

Open Audit Findings zählt nicht behobene Audit-Findings nach Schwere. Kritische Findings dürfen nicht länger als 30 Tage offen bleiben. Hohe Findings nicht länger als 90 Tage.

Remediation Rate misst den Prozentsatz der Audit-Findings, die fristgerecht behoben wurden. Ziel über 90%.

Risk Register Health misst den Prozentsatz der Risiken mit aktuellem Review unter 6 Monaten. Ziel 100%, da ISO 27001 regelmäßige Überprüfung fordert.

Policy Exceptions zählt aktive Policy-Ausnahmen. Der Trend sollte sinkend sein. Ausnahmen über 6 Monate alt sollten eskaliert werden.

Management und Board Reporting

Security Risk Rating (Ampel-System): Rot bedeutet kritisches ungepatchtes Risiko oder aktiver Incident. Gelb bedeutet SLA-Überschreitung oder Compliance-Lücke. Grün bedeutet alle KPIs im Zielbereich. Vorstände wollen den Trend sehen, keine technischen Details.

Cyber Insurance Readiness: Welche Anforderungen der Versicherung sind erfüllt? Welche Maßnahmen senken die Prämie? Wo steht das Unternehmen im Branchenvergleich?

Cost of Security vs. Cost of Breach: Sicherheitsbudget 150.000 EUR/Jahr versus durchschnittlicher Breach im Mittelstand 3,5 Mio. EUR (IBM 2024). ROI = (3.500.000 × Wahrscheinlichkeitsreduktion) / 150.000. Das liefert einen konkreten Business Case für Sicherheitsinvestitionen.

Regulatory Compliance Status: Aktueller Umsetzungsstand für NIS2, ISO 27001 (Zertifizierungsstatus, nächstes Audit) und DSGVO (letzte Datenpanne).

Incident Summary in Board-Sprache: "Dieser Monat: 2 Sicherheitsvorfälle. Beide eingedämmt innerhalb 4h. Kein Datenverlust. Kein Kundeneinfluss. Ursache behoben."

Reporting-Cadence: Täglich für Ops (Alert Queue, offene Incidents), wöchentlich für den CISO (Vulnerability-Trend, Patch-SLA), monatlich für die IT-Leitung (KPI-Dashboard, Trend-Charts), quartalsweise für das Board (Risk Rating, Compliance, ROI).

BereichMetrikZiel
Vulnerability PostureOffene kritische Schwachstellen< 5 pro 1.000 Assets
Mean Time to Remediate Critical Vulns< 48h
Patch Compliance Rate> 95% in 30 Tagen
Exposure PostureExposed Management Interfaces (RDP, SSH)0
Ungepatchte CVEs in CISA KEV-Liste0
Identity PostureMFA-aktivierte Accounts100%
Accounts mit veralteten Passwörtern (> 12 Monate)0
Privilegierte Accounts mit Inaktivität (> 90 Tage)sofort sperren
  • CMMC Level 1: Grundlegende Cyber-Hygiene (17 Practices)
  • CMMC Level 2: Advanced (110 Practices aus NIST SP 800-171) - Pflicht für US-Verteidigungsauftragnehmer
  • CMMC Level 3: Expert (NIST SP 800-172 Zusätze)
  • CIS Controls IG1: Basic Cyber Hygiene - 56 Safeguards für alle Unternehmen
  • CIS Controls IG2: +74 Safeguards für mittlere Unternehmen
  • CIS Controls IG3: +23 Safeguards für Enterprise (APT-Schutz)
BereichScoreTrend
Gesamt-Score73/100↑ +5 (30d)
Identity82%
Endpoint61%
Cloud78%
Network70%
Data54%
  1. MESSEN: Automated scanning (Vulnerability Scanner, CSPM, Security Score) + manuelle Prüfung (Penetrationstest jährlich, Audit)
  2. PRIORISIEREN: Kritische + extern erreichbare Schwachstellen sofort; Identity-Schwachstellen (kein MFA) hohe Priorität; Compliance-Gaps nach regulatorischem Zeitplan
  3. BEHEBEN: Jira/ServiceNow-Tickets mit SLA, Ownership pro Team/Person, Patch-Prozess / Konfigurationsänderung / Policy-Update
  4. VALIDIEREN: Re-Scan nach Behebung, Penetrationstest-Verifizierung für kritische Issues
  5. REPORTEN: Monatlicher Posture-Report, Trend-Darstellung (verbessert/verschlechtert?), Business Impact der offenen Issues
Security PostureSecurity AuditPenetrationstest
RhythmusKontinuierlich, automatisiertPunktuell (jährlich, nach Incident)Punktuell (jährlich bis quartalsweise)
MethodeSelbstbewertung + Tool-basiertExterne unabhängige BewertungSimulierter Angriff auf reale Systeme
ZweckInterne Steuerungsgröße, Trend-TrackingZertifizierungs-/Compliance-Nachweis (ISO 27001, SOC 2)Findet was Scanner übersehen (Logikfehler, Kombinationen)

Fragen zu diesem Thema?

Unsere Experten beraten Sie kostenlos und unverbindlich.

Erstberatung

Über den Autor

Oskar Braun
Oskar Braun

Abteilungsleiter Information Security Consulting

E-Mail

Dipl.-Math. (WWU Münster) und Promovend am Promotionskolleg NRW (Hochschule Rhein-Waal) mit Forschungsschwerpunkt Phishing-Awareness, Behavioral Security und Nudging in der IT-Sicherheit. Verantwortet den Aufbau und die Pflege von ISMS, leitet interne Audits nach ISO/IEC 27001:2022 und berät als externer ISB in KRITIS-Branchen. Lehrbeauftragter für Communication Security an der Hochschule Rhein-Waal und NIS2-Schulungsleiter bei der isits AG.

ISO 27001 Lead Auditor (IRCA) ISB (TÜV)
Dieser Artikel wurde zuletzt am 29.03.2026 bearbeitet. Verantwortlich: Oskar Braun, Abteilungsleiter Information Security Consulting bei AWARE7 GmbH. Lizenz: CC BY 4.0 - freie Nutzung mit Namensnennung: „AWARE7 GmbH, https://a7.de