Kennzahlen (KPI, KRI, KCI) in der Informationssicherheit – Chancen und Nutzen
Alle wichtigen Kennzahlen im Bereich IT-Sicherheit einmal im Überblick
Wie kann sicherstellen, dass die getroffenen Sicherheitsmaßnahmen effektiv und effizient sind? Hierfür kommen dann sogenannte KPIs, KRI und KCI zum Einsatz. Der nun folgende Artikel soll Ihnen daher einmal einen interessanten Überblick über gängige Kennzahlen im Bereich der Informationssicherheit vermitteln.
Arten von Kennzahlen in der Informationssicherheit
Key-Performance-Indikatoren (KPI): KPIs messen die Leistungsfähigkeit des Informationssicherheitsmanagementsystems (ISMS) und zeigen an, wie erfolgreich ein Unternehmen die relevanten Maßnahmen und Prozesse umsetzt. Dies ist ausreichend für die ISO 27001.
Key-Risk-Indikatoren (KRI): KRIs überwachen Risiken und dienen als Früh- oder Spätindikatoren für potenzielle Risikobedingungen. Sie zeigen an, ob Veränderungen im Risikoprofil die definierten Toleranzgrenzen überschreiten und somit die Zielerreichung gefährden.
Key-Control-Indikatoren (KCI): KCIs zeigen an, wie effektiv das gewünschte Ziel innerhalb der Toleranzgrenzen erreicht wurde. Sie bewerten, wie gut die relevanten Maßnahmen und Prozesse umgesetzt werden.
Darstellung von Kennzahlen
Absolute Kennzahlen: Diese Kennzahlen sind durch eine einzelne Zahl zu einem bestimmten Zeitpunkt oder Zeitraum definiert.
Beispiel: Anzahl der Sicherheitsvorfälle in einem Jahr.
Relative Kennzahlen: Diese Kennzahlen stellen zwei oder mehr Zahlen zueinander in Relation, um die benötigte Information zu gewinnen.
Beispiel: Entwicklung der Sicherheitsvorfälle über einen Zeitraum.
Die wichtigsten Kennzahlen im Bereich der Informationssicherheit
Innerhalb der vergangenen Jahre sind weltweit eine Vielzahl von Standards im Bereich IT-Sicherheit entstanden. Dabei handelt es sich um folgende IT-Sicherheitsstandards:
| KPI | Definition | Bedeutung | Beispiel |
|---|---|---|---|
| Risikoorientierte Priorisierung | |||
Patch-Compliance kritischer Systeme |
Prozentsatz der geschäftskritischen Systeme, die innerhalb des definierten SLA mit Sicherheitsupdates versorgt wurden. | Wichtiger als eine Gesamtquote aller Systeme. Zeigt, ob wirklich die Systeme mit dem höchsten Risiko priorisiert werden. | 98 % der produktionskritischen Server wurden innerhalb von 72 Stunden gepatcht, aber nur 82 % aller Systeme insgesamt. |
Überfällige kritische Patches auf Crown-Jewel-Systemen |
Anzahl kritischer, überfälliger Sicherheitsupdates auf besonders schützenswerten Systemen wie Produktions-, ERP-, AD- oder extern erreichbaren Servern. | Diese Kennzahl zeigt sofort, wo das reale Unternehmensrisiko liegt. | 0 überfällige kritische Patches auf ERP- und Produktionsservern, aber 6 auf nachrangigen Nebensystemen. |
Risikogewichtete Schwachstellenlast |
Bewertung offener Schwachstellen unter Einbezug von Kritikalität des Assets, Exponierung, CVSS und Geschäftsrelevanz. | Besser als reine Schwachstellenanzahl, weil nicht jede Lücke gleich wichtig ist. | 3 offene Schwachstellen mit hohem Geschäftsrisiko auf produktionsnahen Systemen wiegen schwerer als 25 mittlere Findings auf Testsystemen. |
Mittleres Alter offener Schwachstellen auf kritischen Assets |
Durchschnittliche Offenzeit kritischer Vulnerabilities auf hochpriorisierten Systemen. | Zeigt, ob Risiko nur dokumentiert oder tatsächlich reduziert wird. | Ø 9 Tage auf Produktionsservern, Ø 28 Tage auf Standard-Clients. |
Anteil priorisierter Assets mit vollständigem Schutzstatus |
Prozentsatz kritischer Assets, für die Inventarisierung, Patchstatus, Backup, Endpoint-Schutz und Monitoring vollständig vorliegen. | Verbindet Asset Management mit Security Controls. | 92 % der Tier-1-Systeme sind vollständig inventarisiert und abgesichert. |
| Asset Management | |||
Asset Coverage |
Prozentsatz aller IT-Assets, die im Inventar erfasst und klassifiziert sind. | Ohne vollständiges Asset Management sind Patching, Monitoring und Risikoanalyse unzuverlässig. | 97 % aller Server, Clients, Netzwerkgeräte und Cloud-Ressourcen sind inventarisiert. |
Klassifizierungsgrad kritischer Assets |
Prozentsatz der Assets, denen eine Schutzbedarfs- oder Kritikalitätsklasse zugewiesen wurde. | Erst dadurch wird Priorisierung möglich. | 100 % der produktionsrelevanten Systeme sind als „hoch“ klassifiziert. |
Anzahl unbekannter oder nicht verwalteter Assets |
Systeme oder Geräte im Netzwerk, die nicht im Asset-Register geführt oder keinem Verantwortlichen zugeordnet sind. | Shadow IT und blinde Flecken erhöhen das Risiko deutlich. | 4 unbekannte Geräte im Produktionsnetz, 0 in der Office-IT. |
Owner-Zuordnung kritischer Systeme |
Prozentsatz kritischer Systeme mit eindeutig benanntem technischem und fachlichem Verantwortlichen. | Erleichtert Eskalation, Patchfreigaben und Risikobehandlung. | 95 % der Tier-1-Systeme haben einen dokumentierten System Owner. |
| Patch- und Schwachstellenmanagement | |||
Time to Patch Critical Vulnerabilities |
Durchschnittliche Zeit zur Behebung kritischer Schwachstellen nach Prioritätsklasse. | Nur sinnvoll, wenn nach Kritikalität des Systems getrennt gemessen wird. | Kritische Lücken auf extern erreichbaren Servern in 24 Stunden, auf Standard-Clients in 5 Tagen. |
Anteil der Systeme im Patch-Prozess |
Prozentsatz der Systeme, die organisatorisch und technisch in den geregelten Patch-Prozess eingebunden sind. | Misst den Abdeckungsgrad des Controls. | 100 % der Server und 96 % der Clients sind in den Patch-Prozess integriert. |
Patch-Erfolgsquote beim ersten Rollout |
Prozentsatz der Systeme, bei denen Updates im ersten geplanten Durchlauf erfolgreich installiert wurden. | Misst Prozessqualität und Betriebsstabilität. | 93 % Erfolgsquote im ersten Wartungsfenster. |
Quote ausnutzbarer Schwachstellen auf exponierten Systemen |
Anteil offener Schwachstellen auf Internet-exponierten oder lateral besonders relevanten Systemen. | Fokussiert auf reale Angriffsfläche statt auf reine Mengen. | 2 % der exponierten Systeme enthalten noch ausnutzbare kritische Findings. |
| Security Operations und Vorfallmanagement | |||
Mean Time to Detect (MTTD) |
Durchschnittliche Zeit bis zur Erkennung eines Sicherheitsvorfalls. | Zeigt die Wirksamkeit von Monitoring und Detection. | Ein unautorisierter Zugriff wird im Mittel nach 12 Minuten erkannt. |
Incident Response Time |
Zeit bis zur ersten qualifizierten Reaktion auf einen Vorfall. | Wichtig für Schadensbegrenzung und Eindämmung. | Das Security-Team isoliert betroffene Endpunkte innerhalb von 30 Minuten. |
Mean Time to Resolve (MTTR) |
Durchschnittliche Zeit bis zur Behebung oder Stabilisierung eines Sicherheitsvorfalls. | Misst operative Reife und Wiederherstellungsfähigkeit. | Ein kompromittierter Account wird innerhalb von 2 Stunden gesperrt, untersucht und zurückgesetzt. |
Anzahl schwerwiegender Vorfälle |
Anzahl der Sicherheitsvorfälle mit hohem Schadenpotenzial in einem definierten Zeitraum. | Top-Level-Indikator für Management und Risikoausschuss. | 2 kritische Vorfälle im Halbjahr statt 5 im Vorjahreszeitraum. |
False-Positive-Rate |
Anteil der Alarme, die sich nach Prüfung nicht als sicherheitsrelevant herausstellen. | Zu hohe Werte belasten Analysten und verschlechtern Reaktionsfähigkeit. | 18 % der High-Priority-Alerts sind Fehlalarme. |
Events-zu-Alerts-zu-Incidents-Verhältnis |
Verhältnis aller Ereignisse zu Warnmeldungen und bestätigten Sicherheitsvorfällen. | Hilft bei der Bewertung der Erkennungsqualität. | 1.000.000 Events → 2.500 Alerts → 18 bestätigte Incidents. |
| Wirksamkeit von Controls | |||
Backup-Erfolgsquote kritischer Systeme |
Prozentsatz erfolgreicher Backups auf priorisierten Systemen. | Entscheidend für Resilienz und Wiederanlauf. | 99,5 % erfolgreiche Backups auf ERP- und Produktionssystemen. |
Restore-Test-Erfolgsquote |
Prozentsatz erfolgreich getesteter Wiederherstellungen. | Ein Backup ohne getesteten Restore ist kein verlässlicher Schutz. | 10 von 10 Restore-Tests auf geschäftskritischen Systemen erfolgreich. |
Endpoint-Schutzabdeckung |
Prozentsatz der Systeme mit aktivem und aktuellem Endpoint-Schutz. | Misst Control-Abdeckung und Aktualität. | 99 % der Clients und 95 % der Server sind aktiv geschützt. |
MFA-Abdeckung kritischer Konten |
Prozentsatz privilegierter oder besonders sensibler Konten mit Mehrfaktor-Authentifizierung. | Wichtiger als eine allgemeine MFA-Quote ohne Kontext. | 100 % der Admin-Konten, aber erst 78 % der externen Dienstleisterkonten mit MFA abgesichert. |
| Awareness und Governance | |||
Teilnahmequote an Security-Awareness-Schulungen |
Prozentsatz der Mitarbeitenden, die die vorgeschriebenen Schulungen absolviert haben. | Misst Abdeckungsgrad der Awareness-Maßnahmen. | 91 % Teilnahmequote im laufenden Jahr. |
Phishing-Fail-Rate in kritischen Bereichen |
Anteil der Mitarbeitenden in besonders sensiblen Bereichen, die auf simulierte Phishing-Mails reagieren. | Risikobasierte Awareness statt pauschaler Gesamtquote. | Finanzbuchhaltung 4 %, Produktion 7 %, Gesamtunternehmen 9 %. |
Compliance-Rate kritischer Controls |
Prozentsatz der priorisierten Sicherheitsmaßnahmen, die norm- und richtlinienkonform umgesetzt sind. | Hilft, Management-Fokus auf die wirklich relevanten Kontrollen zu legen. | 96 % der priorisierten ISO-27001-Controls vollständig umgesetzt. |
Anzahl offener Audit-Feststellungen mit hohem Risiko |
Offene Findings aus Audits oder Assessments, die ein hohes Geschäfts- oder Sicherheitsrisiko darstellen. | Besser als die bloße Gesamtzahl aller Findings. | 2 High-Risk-Findings offen, 11 Low-Risk-Findings in Bearbeitung. |
Anteil des Security-Budgets für kritische Risiken |
Prozentsatz des Sicherheitsbudgets, der auf die Behandlung der priorisierten Top-Risiken entfällt. | Verhindert Fehlsteuerung durch Budgetverteilung nach Sichtbarkeit statt Risiko. | 68 % des Budgets fließen in Produktionssicherheit, Identitätsmanagement und Backup-Härtung. |
Qualität von Kennzahlen
- Objektiv: Kennzahlen sollten objektiv erhoben werden können, um die Gefahr von Beeinflussungen zu minimieren.
- Aussagekräftig: Die Kennzahl sollte nützliche Informationen liefern, die zur Verbesserung der IT-Sicherheit beitragen.
- Einfach: Kennzahlen sollten einfach und schnell zu ermitteln sein, idealerweise automatisiert.
- Vergleichbar: Kennzahlen sollten über die Zeit vergleichbar sein, um Trends zu erkennen.
- Zuverlässig: Die erhobenen Daten müssen fehlerfrei und korrekt sein.
- Wiederholbar: Die Erhebung der Daten sollte regelmäßig wiederholt werden können.
- Konkretisierbar: Kennzahlen sollen an Geschäftsziele und Unternehmensgrößen angepasst werden können.
- Dokumentierbar: Die Ergebnisse und der Berechnungsweg der Kennzahlen sollten dokumentiert werden.
Standards für Security Kennzahlen
ISO 27001 und 27004
ISO 27001 und ISO 27004 sind Teil der ISO 27000-Familie und stellen internationale Sicherheitsstandards gemäß der ISO (oder auch: „International Organization for Standardization“) dar. Speziell die Varianten der Klasse 27000 befassen sich mit Risiken der IT-Sicherheit und überprüfen die Infosec Systeme auf deren Sicherheit und Anfälligkeit. Ein standardisierter und offizieller Messprozess sowie eine regelmäßige Zertifizierung durch anerkannte und unabhängige Prüforgane sorgt für die umfassende Wichtigkeit dieses KPIs.
Cobit
Cobit (oder auch: „Control Objectives for Information and Related Technology“) definiert Kennzahlen auf drei Ebenen: IT-Ziele, Prozessziele und Aktivitätsziele. Es ist komplexer als ISO 27004, da es einen größeren Bereich abdeckt, aber auch weniger geeignet für die Bewertung der IT-Sicherheit.
NIST Special Publication 800-55
Diese Publikation beschreibt die Entwicklung, Auswahl und Implementierung von Kennzahlen in der IT-Sicherheit in sieben Phasen, einschließlich der Identifizierung von Stakeholdern und der Definition von Zielen und Zielvorgaben.
VDA-ISA / TISAX
Dieser Katalog enthält Anforderungen an die Informationssicherheit, basierend auf ISO/IEC 27001, und verwendet ein Reifegradmodell zur Bewertung der Umsetzung von Maßnahmen. Beispiele für KPIs umfassen Schulung zur Informationssicherheit und Schutz vor Schadsoftware.
Mehr Informationen zum Thema Kennzahlen in der IT-Sicherheit finden Sie in unserem Download-Bereich.
Wie kann ein umfassendes Programm für Sicherheitsmetriken entwickelt werden?
Ein individuell konzipiertes Programm für Sicherheitsmetriken, beziehungsweise Kennzahlen im Bereich der IT-Security stützt sich in der Regel auf die Einrichtung der folgenden Schritte:
- Ziel- und Vorgabendefinition aller Kennzahlen
- Entscheidung über die Art der verwendeten Kennzahlen
- Etablierung von Methoden zur Erstellung geeigneter Kennzahlen
- Festlegung von Benchmarks für die IT-Security
- Einführung eines automatisierten Alarmierungs- und Berichtswesens
- Organisation, Konzeption und Umsetzung eines Kennzahlenplans
- Etablierung eines formalen Zyklus zur Aktualisierung des Kennzahlenplans
Doch Vorsicht: Auch wenn Kennzahlen ein wertvolles Steuerungsinstrument sind, gilt – nicht jede Zahl führt automatisch zu mehr Sicherheit. Wer sich zu sehr auf formale KPIs verlässt, riskiert eine gefährliche Scheinsicherheit. Welche Risiken dabei entstehen und warum ein kritischer Blick auf herkömmliche Metriken so wichtig ist, beleuchten wir im Beitrag:
👉 Kritik an KPIs in der Informationssicherheit – Wenn Zahlen trügen
Fazit zum Thema Kennzahlen für IT-Sicherheit
Fakt ist: Kennzahlen im Bereich der Informationssicherheit sind schon längst kein Nebenschauplatz mehr! Sie stellen wichtige Metriken dar, um die individuelle IT-Sicherheit zu gewährleisten und um Privatpersonen, Selbstständige sowie Unternehmen vor großen finanziellen Schäden, beziehungsweise rechtlichen Risiken zu schützen.
Doch entscheidend ist: Kennzahlen müssen sinnvoll gewählt, im richtigen Kontext interpretiert und kontinuierlich überprüft werden. Ein standardisiertes Konzept mit klaren Zielen, validen Metriken und einem funktionierenden Berichtswesen ist dabei unerlässlich – unabhängig von Unternehmensgröße oder Branche.
Zu viel Informationen auf einmal? Wir unterstützen Sie bei Ihrem IT-Sicherheitsmanagement