Zum Inhalt springen

Services, Wiki-Artikel, Blog-Beiträge und Glossar-Einträ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)

“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)

Häufige Fehler bei Security-Metriken:

Fehler 1: Aktivitäts-Metriken statt Outcome-Metriken
  Schlecht: "Wir haben 150 Vulnerabilities gepatcht diesen Monat"
  Gut:      "Kritische Patch-Compliance stieg von 73% auf 91%"

Fehler 2: Zu viele Metriken
  → 50 KPIs → niemand versteht, was wichtig ist
  → Lösung: 5-7 strategische KPIs + 15-20 operative Metriken

Fehler 3: Metriken ohne Baseline und Ziel
  Schlecht: "MTTD: 48 Stunden"
  Gut:      "MTTD: 48h (Baseline: 96h, Ziel: <24h, Trend: ↓)"

Fehler 4: Falscher Empfänger
  → Technische Metriken dem Board zeigen → Augen verdrehen
  → Board-Metriken: Risiko, Business Impact, EUR
  → Ops-Metriken: MTTD, FP-Rate, Incidents pro Woche

Gutes Metriken-Framework:
  → Ziel definieren (was soll besser werden?)
  → Baseline etablieren (Ausgangszustand messen)
  → Zielwert setzen (realistisch und ambitioniert)
  → Messmethode festlegen (wie wird gemessen, wer, wie oft?)
  → Reporting-Cadence: täglich/wöchentlich/monatlich/quartalsweise

Security Operations KPIs

Detection & Response Metriken:

MTTD (Mean Time to Detect):
  Definition: Zeit von Angiffsbeginn bis Erkennung
  Formel:     Σ(Erkennungszeit - Angriffsbeginn) / Anzahl Incidents
  Benchmark:  IBM DBIR 2024: 204 Tage (!)
  SOC-Ziel:   < 24h für kritische Incidents
  Best-Class: < 1 Stunde
  Messung:    SIEM Timestamp Incident erkannt vs. forensische Analyse

MTTR (Mean Time to Respond/Contain):
  Definition: Zeit von Erkennung bis Eindämmung (Containment)
  Formel:     Σ(Containment-Zeit - Erkennungszeit) / Anzahl Incidents
  Benchmark:  Branche: 73 Tage bis Containment (IBM DBIR)
  SOC-Ziel:   < 4h für kritische Incidents
  Messung:    Ticketsystem: "Incident erkannt" → "Containment bestätigt"

MTTF (Mean Time to Fully Remediate):
  Definition: Zeit von Erkennung bis vollständige Behebung
  Formel:     Σ(Close-Zeit - Erkennungszeit) / Anzahl Incidents
  Ziel:       Kritisch < 24h, Hoch < 7 Tage, Mittel < 30 Tage

Alert Quality Score:
  Definition: Anteil echter Positives an allen Alerts
  Formel:     True Positives / (True Positives + False Positives) × 100
  Ziel:       > 70% (< 70%: Alert Fatigue!)
  Warum:      Zu viele FPs → Analysten ignorieren Alerts → blind

Incident Volume:
  Definition: Anzahl Incidents pro Zeitraum nach Schweregrad
  Trend wichtiger als absolute Zahl!
  Kritisch: < 5/Monat (Ziel)
  High:     < 20/Monat
  Medium:   Baseline × 1,2 (stark steigend = Problem)

---

Tabelle für SOC-Reporting:

KPI                 Aktuell    Vormonat   Ziel      Trend
MTTD (kritisch)     18h        24h        <12h      ↑ gut
MTTR (kritisch)     3.5h       4.8h       <4h       ↑ gut
Alert Quality       68%        61%        >70%      ↑ gut
FP-Rate             32%        39%        <30%      ↑ gut
Incidents (Krit.)   2          4          <5        ↑ gut
SIEM Coverage       87%        82%        >95%      ↑ gut

Vulnerability Management KPIs

Patch & Vulnerability Metriken:

Patch Compliance Rate:
  Definition: % der Systeme mit installiertem Patch innerhalb SLA
  Formel:     Gepatchte Systeme / Alle betroffenen Systeme × 100
  Ziel:       Critical: >99%, High: >95%, Medium: >90%
  Kritisch:   Critical-Patches: 24h extern, 72h intern
  Messung:    Vulnerability Scanner Post-Scan Vergleich

Mean Time to Remediate (Vulnerability):
  Definition: Durchschnittliche Zeit von Discovery bis Patch
  Formel:     Σ(Patch-Datum - Discovery-Datum) / Patches
  Ziel:       Critical: < 3 Tage, High: < 14 Tage, Medium: < 45 Tage

Vulnerability Discovery Rate:
  Definition: Zeit von CVE-Veröffentlichung bis in eigenem System erfasst
  Ziel:       < 48 Stunden (für Critical CVEs)
  Messen:     NVD-Veröffentlichungsdatum vs. Scanner-Ergebnis

Overdue Findings:
  Definition: Anzahl Findings außerhalb SLA
  Ziel:       0 Critical/High außerhalb SLA
  Eskalation: Jede Überschreitung → automatische CISO-Meldung

Attack Surface Trend:
  Definition: Entwicklung offener Findings über Zeit
  Visualisierung: Burn-Down-Chart pro Schweregrad
  Interpretation:
    Steigend:  Neue Vulnerabilities > Behebungen (besorgniserregend)
    Gleichbleibend: Eingeschwungener Zustand (akzeptabel)
    Sinkend:   Aktive Reduktion (optimal)

Scanner Coverage:
  Definition: % der bekannten Assets die gescannt werden
  Formel:     Gescannte IPs / Gesamt-IPs × 100
  Ziel:       >95%
  Risiko bei <90%: Blinde Flecken im Vulnerability Program

---

Dashboard-Beispiel (monatlich):

Critical Vulnerabilities:
  Neu entdeckt:    12
  Behoben:         15
  Offen:            8 (davon 2 mit Ausnahmegenehmigung)
  Compliance Rate: 97% (Ziel: >99%)

High Vulnerabilities:
  Neu:  45 | Behoben: 51 | Offen: 23 | Compliance: 93%

Medium:
  Neu: 180 | Behoben: 145 | Offen: 234 | Compliance: 88%

Security Awareness Metriken

Phishing-Simulation KPIs:

Klickrate:
  Definition: % der Empfänger die auf Phishing-Link klicken
  Branchenschnitt: 17-25% (ohne Training)
  Ziel nach Training: < 5%
  Best-in-Class: < 2%
  Warnsignal: > 15% nach 6 Monaten Training

Report Rate:
  Definition: % der Empfänger die Phishing korrekt melden
  Ziel: > 30% (erst berichten, dann klicken)
  Warum wichtig: Reporting ist wichtiger als Nicht-Klicken!
  Gut messen: nur echte Meldungen zählen (nicht "was war das?")

Time to Report:
  Definition: Zeit von Phishing-Empfang bis Meldung
  Ziel: < 30 Minuten
  Best-Class: < 5 Minuten (Echtzeit-Abwehr!)

Repeat Clicker Rate:
  Definition: % der User die mehrfach auf Phishing klicken
  Ziel: < 3% nach Training
  Action: Repeat Clicker → intensiviertes Training (1:1)

---

Training Completion Metrics:

Pflicht-Training Completion:
  Definition: % Mitarbeiter die Pflichtkurs abgeschlossen haben
  Ziel: 100% (Compliance-Anforderung!)
  Monatlicher Report an Management

Knowledge Retention:
  Definition: Test-Score 30/60/90 Tage nach Training
  Messung: Follow-up Quiz (automatisch in LMS)
  Ziel: >80% Retention nach 30 Tagen

Training Effectiveness (Phishing):
  Definition: Klickrate vor Training vs. 3 Monate danach
  Berechnung: (Vorher - Nachher) / Vorher × 100
  Beispiel: 23% → 7% = 70% Reduktion → Training wirkt!

Compliance und Audit-Metriken

Compliance KPIs:

Control Effectiveness Rate:
  Definition: % der Kontrollen die auditkonform implementiert sind
  Berechnung: Implementierte Controls / Gesamte Controls × 100
  Ziel: >95% für kritische Controls

Open Audit Findings:
  Definition: Anzahl nicht behobener Audit-Findings nach Schwere
  Kritisch:   0 offen über 30 Tage (Pflicht!)
  Hoch:       0 offen über 90 Tage
  Mittel:     < 10 offen

Remediation Rate:
  Definition: % der Audit-Findings fristgerecht behoben
  Ziel: >90%

Risk Register Health:
  Definition: % der Risiken mit aktuellem Review (< 6 Monate alt)
  Ziel: 100% (ISO 27001 fordert regelmäßige Überprüfung)

Policy Exceptions:
  Definition: Anzahl aktiver Policy-Ausnahmen
  Ziel: Trend sinkend
  Maximum: Ausnahmen > 6 Monate alt → Eskalation

Management und Board Reporting

Board-Level Security Metriken (nicht technisch!):

1. Security Risk Rating (Ampel-System):
   ROT:    Kritisches ungepatchtes Risiko ODER aktiver Incident
   GELB:   SLA-Überschreitung ODER Compliance-Lücke
   GRÜN:   Alle KPIs in Zielbereich
   → Vorstände wollen: Trend, nicht Details

2. Cyber Insurance Readiness:
   → Anforderungen der Versicherung erfüllt?
   → Auswirkung auf Prämie: welche Maßnahmen senken sie?
   → Benchmark: wo stehen wir vs. Branche?

3. Cost of Security vs. Cost of Breach:
   Sicherheitsbudget:   150.000 EUR/Jahr
   Durchschnittlicher Breach im Mittelstand: 3,5 Mio. EUR (IBM 2024)
   ROI = (3.500.000 × Wahrscheinlichkeitsreduktion) / 150.000
   → Konkreter Business Case für Sicherheitsinvestitionen

4. Regulatory Compliance Status:
   NIS2:    In Umsetzung (75% der Anforderungen erfüllt)
   ISO 27001: Zertifiziert, nächstes Audit: Q3 2026
   DSGVO:   Letzte Datenpanne: keine (18 Monate)

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

---

Reporting-Cadence:

Täglich (Ops):      Alert Queue, offene Incidents
Wöchentlich (CISO): Vulnerability-Trend, Patch-SLA
Monatlich (IT-Leitung): KPI-Dashboard, Trend-Charts
Quartalsweise (Board): Risk Rating, Compliance, ROI

Fragen zu diesem Thema?

Unsere Experten beraten Sie kostenlos und unverbindlich.

Erstberatung

Über den Autor

Oskar Braun
Oskar Braun

Abteilungsleiter Information Security Consulting

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.

6 Publikationen
ISO 27001 Lead Auditor (IRCA) ISB (TÜV)
Dieser Artikel wurde zuletzt am 04.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

Cookielose Analyse via Matomo (selbst gehostet, kein Tracking-Cookie). Datenschutzerklärung