Security KPIs, die nicht lügen - Meine CISO-Shortlist für echte Steuerung

In fast jeder Security-Organisation, die ich gesehen habe, gibt es irgendwann „das Dashboard“. Es ist gut gemeint: Transparenz schaffen, Fortschritt zeigen, Sicherheit messbar machen. In der Praxis passiert aber oft etwas anderes: Man misst, was leicht zu messen ist – und nicht das, was wirklich steuert.

Das Ergebnis sind grüne Ampeln, steigende Prozentwerte und trotzdem dieses ungute Bauchgefühl: Werden wir wirklich besser – oder berichten wir nur schöner?

Über die Zeit habe ich mir eine KPI-Shortlist angewöhnt, die manchmal unbequem ist. Genau deshalb ist sie nützlich: Diese Kennzahlen „lügen“ deutlich seltener, weil sie direkt an Wirksamkeit hängen – nicht an Aktivität. Sie zwingen zu Entscheidungen: Was ändern wir nächste Woche? Was priorisieren wir? Wo ist ein echtes Risiko?

Was „ehrliche“ Security-KPIs ausmacht

Bevor wir in die Kennzahlen gehen, zwei Grundsätze, die bei mir den Unterschied machen:

1) Tier-0/1 statt „Gesamtunternehmen“

Viele KPIs sehen gut aus, weil sie über alles gemittelt werden. 95% Patch-Compliance sagt wenig, wenn die fehlenden 5% genau dort liegen, wo es kritisch ist.

Darum messe ich bevorzugt auf:

• Tier 0: Identität, Schlüssel, Admin-Systeme, zentrale Management-Plane (IdP, PKI, PAM, AD, etc.)

• Tier 1: Crown-Jewel-Workloads, sensitive Datenflüsse, Kernprozesse (ERP, Produktionssteuerung, Payment, Patientendaten, …)

  
  

2) Steuerungs-KPIs statt Reporting-KPIs

Ein KPI ist für mich nur dann gut, wenn er eine klare Aktion auslösen kann:

• Wer ist Owner?

• Welche Schwelle ist „nicht akzeptabel“?

• Was ist der konkrete Fix/Plan?

Wenn die Antwort auf Abweichungen „Wir nehmen es in die Roadmap“ ist, ist es meistens ein Reporting-KPI – kein Steuerungsinstrument.

Die CISO-Shortlist: 7 KPIs, die wirklich steuern

1) 🔧 Patch-Tempo auf Tier-0/1

Was ich messe:

• Anteil kritischer Tier-0/1 Assets mit kritischen Patches innerhalb von X Tagen

• Optional getrennt nach Plattform (Windows/Linux/Network/Appliance) und nach Exposition (Internet-facing vs. intern)

Warum das nicht lügt:„Patch-Compliance“ als Gesamtwert ist leicht zu gamen: Man patcht viel „einfaches“ Zeug und bleibt bei den harten Fällen liegen (Legacy, Appliance, produktionskritische Systeme).

Praktische Umsetzung:

• Definiere, was „kritisch“ ist (CVSS allein reicht oft nicht; Kontext zählt: Exploitability, exposure, asset criticality)

• Setze klare SLOs, z. B.:

  • Tier 0: Kritisch ≤ 7 Tage

  • Tier 1: Kritisch ≤ 14 Tage

• Tracke nicht nur „gepatcht“, sondern auch „geblockt“ (Assets, die dauerhaft nicht patchbar sind) – die müssen in einen Exception-Prozess.

Typische Stolperfalle:„Wir patchen, wenn Wartungsfenster da sind“ ist kein Plan. Für Tier 0 braucht es eine höhere Priorität als „irgendwann im Quartal“.

2) 🔐 Phishing-resistente MFA für privilegierte Identitäten

Was ich messe:

• Anteil Admin-/PAM-Identitäten mit phishing-resistenter MFA (FIDO2/Passkeys, Smartcard, Zertifikatsbasiert – je nach Umfeld)

• Anteil privilegierter Zugriffe, die durch Conditional Access / Risk-based Policies laufen

Warum das nicht lügt:Identity ist die Abkürzung in fast jeden Security-Vorfall. Wenn privilegierte Identitäten sauber abgesichert sind, sinkt dein Risiko spürbar – unabhängig von den restlichen „nice to haves“.

Praktische Umsetzung:

• Zuerst Tier 0: Admins, Break-Glass, Service Accounts (wo möglich)

• Dann Admin Workstations (PAW/SAW) + Access-Path härten

• Metrik immer mit „Ausnahmen“ koppeln: Jede Ausnahme braucht Owner, Grund und Enddatum.

Typische Stolperfalle:„MFA ist ausgerollt“ – ja, aber auf allen privilegierten Pfaden? Inklusive Legacy-Protokollen, Dritt-Tools, API-Access, Notfall-Accounts?

3) 🧩 EDR „healthy“ + Tamper Protection (nicht nur installiert)

Was ich messe:

• Anteil Tier-0/1 Systeme mit EDR-Agent aktiv, aktuell, nicht ausgenommen

• Tamper Protection / Self-Protection eingeschaltet

• Optional: Anteil Systeme mit funktionierender Telemetrie (Heartbeat)

Warum das nicht lügt:Installationszahlen sind ein Klassiker: 99% Coverage – und die 1% sind Domain Controller, Jump Hosts oder kritische Server, weil „da macht der Agent Probleme“.

Praktische Umsetzung:

• „Healthy“ klar definieren: Agent alive, policy applied, telemetry received, no broad exclusions

• Monitoring auf Abweichungen: wenn ein Sensor offline geht, ist das ein Event wie „Host down“ – nicht „irgendwann mal prüfen“.

Typische Stolperfalle:Zu großzügige Ausnahmen („ganzer Prozessbaum“, „ganzer Ordner“) – das sind faktisch blinde Flecken.

4) 📜 Logging, das wirklich ankommt (Coverage + Qualität)

Was ich messe:

• Anteil kritischer Logquellen, die im SIEM/Log-Backend ankommen

• Drop Rate / Parsing Errors / Schema-Fehler

• Latenz: wie schnell sind Logs verfügbar (für Detection/Response relevant)

Warum das nicht lügt:„Wir haben ein SIEM“ ist kein Sicherheitszustand. Ein SIEM ohne verlässliche Daten ist nur teurer Storage.

Praktische Umsetzung:

• Definiere eine „Minimum Viable Logging List“ (Tier 0/1):IdP, PAM, AD, EDR, VPN/ZTNA, DNS, Proxy, E-Mail, Cloud Control Plane, kritische Applikationen

• Messe Qualität: Wenn Parser brechen oder Events nicht gemappt sind, sind deine Detection-Regeln wertlos.

Typische Stolperfalle:Man zählt Datenquellen, aber nicht den Nutzwert. „Quelle angebunden“ ≠ „für Use Cases nutzbar“.

5) ⏱️ MTTC: Mean Time To Contain (Detection → Containment)

Was ich messe:

• Zeit von erster Detection (oder „first seen“) bis Containment

• Idealerweise getrennt nach Incident-Typ (Credential theft, malware, lateral movement, SaaS compromise, …)

Warum das nicht lügt:Viele Teams optimieren Tickets (MTTR), aber nicht den Schaden. In echten Incidents ist Containment der Punkt, an dem du die Ausbreitung stoppst – und Kosten explodieren oder eben nicht.

Praktische Umsetzung:

• Definiere „Containment“ eindeutig: Account disabled? Host isolated? Token revoked? Conditional access enforced?

• Tracke pro Incident: Was hat Containment verzögert (fehlende Rechte, fehlende Telemetrie, Prozess, Abstimmung)?

Typische Stolperfalle:Containment scheitert an Zuständigkeiten („Wer darf isolieren?“). Das ist kein Technikproblem, sondern Operating Model.

6) 🧯 Restore-Fähigkeit (Restore-Tests ≤ 90 Tage + Restore-Zeit)

Was ich messe:

• Anteil Tier-0/1 Systeme mit erfolgreichem Restore-Test in den letzten 90 Tagen

• Median Restore-Zeit (oder RTO-Realität)

• Optional: Erfolgsquote „Restore + Applikation funktionsfähig“ (nicht nur „Dateien zurückkopiert“)

Warum das nicht lügt:Backups zu haben ist leicht. Restores zuverlässig durchführen zu können – unter Stress, mit Prioritäten, mit Abhängigkeiten – ist etwas anderes.

Praktische Umsetzung:

• Restore-Tests als Routine, nicht als Projekt

• Priorisieren: erst Tier 0/1, dann der Rest

• Abhängigkeiten dokumentieren (Identity, DNS, PKI, Secrets, Config)

Typische Stolperfalle:Restore-Test ohne realistische Randbedingungen (z. B. nur im Lab, ohne Auth, ohne echte Datenmengen).

7) 📌 Exceptions mit Ablaufdatum (Owner + Mitigation)

Was ich messe:

• Anzahl Security-Exceptions ohne Enddatum

• Anteil Exceptions mit Owner, Risikoakzeptanz, Mitigation, Review-Termin

• Optional: „Exception-Age“ (wie alt sind die Dinger?)

Warum das nicht lügt:In jeder Organisation gibt es Ausnahmen. Der Unterschied zwischen „kontrolliert“ und „gefährlich“ ist, ob sie gesteuert werden oder verwahrlosen.

Praktische Umsetzung:

• Standardisiertes Exception-Template: Scope, Risiko, Mitigation, Owner, Enddatum

• Reviews in klarer Kadenz (monatlich/quarterly)

• Alles ohne Enddatum ist automatisch rot.

Typische Stolperfalle:Exceptions werden „vergessen“, weil niemand unangenehm sein will. Genau dafür braucht es eine Metrik.

Security KPIs, die nicht lügen

Wie du daraus ein wirklich steuerndes KPI-Set machst

Schritt 1: Begrenze dich radikal

Ich empfehle: 8–10 KPIs max.Mehr führt fast immer zu Reporting-Show statt Steuerung.

Schritt 2: Gib jedem KPI einen Owner und einen Trigger

Für jeden KPI:

• Owner (eine Person/Team, nicht „Security“)

• Schwellenwerte (grün/gelb/rot, aber mit Bedeutung)

• Trigger-Aktion („Wenn rot → welche Maßnahme bis wann?“)

  
  

Schritt 3: Zeige Trends, nicht nur Punktwerte

Ein KPI ist selten „in einem Monat erledigt“. Entscheidend ist Richtung + Geschwindigkeit:

• wird es besser?

• wie schnell?

• wo sind Rückschritte (Control Drift)?

Schritt 4: Verknüpfe KPIs mit Entscheidungen

Ein KPI-Review ist kein Meeting, um Zahlen zu lesen. Es ist ein Meeting, um Entscheidungen zu treffen:

• Was stoppen wir?

• Was priorisieren wir?

• Welche Ausnahme wird beendet?

• Welche Control wird gehärtet?

Was ich bewusst NICHT als „Top KPI“ nutze (obwohl es beliebt ist)

• Anzahl geschlossener Findings (kann reine Fleißarbeit abbilden)

• Awareness-Completion-Rate (sagt wenig über Verhalten)

• „Anzahl abgewehrter Angriffe“ (abhängig vom Messsystem, oft Marketing)

• Vulnerability Count ohne Kontext (führt zu Lärm, nicht zu Risiko-Reduktion)

Das heißt nicht, dass diese Daten nutzlos sind – aber als CISO-Steuerungsgröße sind sie oft zu indirekt.

Fazit

Wenn du nur eine Sache mitnimmst: Miss zuerst dort, wo es richtig weh tut (Tier 0/1) und miss Wirksamkeit, nicht Aktivität.

Diese 7 KPIs haben mir in der Praxis geholfen, Diskussionen von „wir fühlen“ zu „wir entscheiden“ zu drehen.