Alert Fatigue

Hintergrund und normative Einordnung

Der Begriff Alert Fatigue entstand aus der klinischen Forschung zur Alarm-Überflutung in der Intensivmedizin und wurde ab dem frühen 2000er-Jahrzehnt auf Security Operations Centers übertragen, als automatisierte Intrusion Detection Systeme (IDS) und SIEM-Plattformen (Security Information and Event Management) in Unternehmen Einzug hielten. Mit der Einführung dieser Systeme wuchs das tägliche Alert-Volumen in typischen Enterprise-SOCs auf mehrere tausend Meldungen pro Schicht, ohne dass parallel die Anzahl der Analysten in gleichem Maß stieg. ISO/IEC 27035-1:2023 beschreibt im Prozessschritt Detect and Report (Clause 6) die Anforderung, sicherheitsrelevante Ereignisse vollständig und zeitnah zu erfassen sowie eine initiale Klassifikation und Priorisierung vorzunehmen, bevor sie an das zuständige Incident-Response-Team eskaliert werden. Dieser Klassifikationsschritt ist exakt der Punkt, an dem Alert Fatigue wirkt: Wenn Analysten durch Volumen oder Monotonie abstumpfen, sinkt die Erkennungsqualität, und echte Sicherheitsvorfälle werden als Fehlalarm abgehakt oder gar nicht erst geöffnet. ISO/IEC 27002:2022 Clause 8.16 (Monitoring Activities) formuliert als Leitlinie, dass Monitoring-Werkzeuge Anomalien in Echtzeit melden sollen, und zwar mit einem minimalen Anteil an False Positives. Diese normative Anforderung benennt das strukturelle Problem: Systeme, die zu viele Fehlalarme erzeugen, verfehlen ihren Zweck, weil sie die Erkennungskapazität der Analysten erschöpfen, statt sie zu nutzen.

In der deutschen und europäischen Compliance-Landschaft hat Alert Fatigue durch NIS-2 (Richtlinie EU 2022/2555) erhebliche regulatorische Relevanz erhalten. Artikel 21 NIS-2 verpflichtet wesentliche und wichtige Einrichtungen zur Implementierung von Konzepten und Verfahren bezüglich der Risikoanalyse und Sicherheit für Informationssysteme sowie zur Erkennung von Anomalien. Artikel 23 NIS-2 schreibt eine Erstmeldung erheblicher Sicherheitsvorfälle innerhalb von 24 Stunden vor. Diese 24-Stunden-Frist ist nur einzuhalten, wenn die Erkennungs- und Triage-Prozesse im SOC effektiv funktionieren, was bei ausgeprägter Alert Fatigue strukturell gefährdet ist. BSI IT-Grundschutz DER.1 Edition 2023 adressiert den gleichen Sachverhalt auf Baustein-Ebene: Anforderung DER.1.A1 verlangt, dass geeignete Melde- und Alarmierungsverfahren etabliert und dokumentiert werden. DER.1 benennt ausdrücklich das Risiko, dass eine fehlerhafte Alarmierungskonfiguration häufige Fehlalarme erzeugt, sodass echte sicherheitsrelevante Ereignisse nicht zeitnah erkannt werden. NIST SP 800-61 Rev. 3 (April 2025), strukturiert nach dem NIST Cybersecurity Framework 2.0, ordnet die Erkennungs- und Analyseaktivitäten den CSF-Funktionen Detect (DE.CM: Continuous Monitoring) und Respond (RS.AN: Incident Analysis) zu und empfiehlt explizit den Einsatz von SIEM- und SOAR-Systemen, um das Alert-Volumen zu reduzieren und Ressourcen auf echte Bedrohungen zu fokussieren. Für Organisationen, die ihre SOC-Prozesse normkonform strukturieren möchten, bietet SECURAM im Rahmen der ISO 27001 Beratung und Zertifizierung eine strukturierte Begleitung vom Use-Case-Tuning bis zur ISMS-Integration.

Normative Bezüge:

Vorgehen in der Praxis

Die Bekämpfung von Alert Fatigue folgt einem vierstufigen Prozess, der technische Kalibrierung, prozessuale Strukturierung und organisatorische Maßnahmen verbindet. BSI IT-Grundschutz DER.1 und ISO/IEC 27035-1:2023 bilden die normative Grundlage für jeden dieser Schritte.

Abgrenzung zu verwandten Begriffen

Typische Fehler und wie ihr sie vermeidet

• Datenquellen ohne definierten Use Case aktivieren: Viele Organisationen onboarden neue Datenquellen (z.B. Cloud-Workloads, IoT-Sensoren, neue SaaS-Produkte) in die SIEM-Plattform, ohne validierte Erkennungsregeln zu erstellen. Das Ergebnis ist ein rohes Event-Volumen ohne Kontext. ISO/IEC 27002:2022 Clause 8.16 fordert, zunächst eine Baseline normaler Aktivität zu definieren, bevor Anomalien erkannt werden können. Ohne diese Baseline erzeugt jede neue Datenquelle primär Rauschen und erhöht die kognitive Last der Analysten, ohne den Erkennungswert proportional zu steigern.
• SOC ohne strukturierte Schichtrotation und Pausenplanung betreiben: Kognitive Ermüdung ist die psychologische Grundlage von Alert Fatigue. Analysten, die ohne verbindliche Rotationsregeln am gleichen Monitor-Arbeitsplatz verbleiben, entwickeln Desensibilisierungseffekte gegenüber Alarmen, die statistisch meist keine echten Vorfälle darstellen. BSI IT-Grundschutz DER.2.1 Edition 2023 fordert ein funktionsfähiges Incident-Management mit klaren Rollen und Verantwortlichkeiten; implizit darin enthalten ist die organisatorische Verpflichtung, die Handlungsfähigkeit des Incident-Response-Teams dauerhaft sicherzustellen. Schichtpläne ohne Pausenregelung verletzen diese Anforderung strukturell.
• Alert-Volumina nicht messen und dokumentieren: Wer Alert Fatigue nicht misst, kann sie nicht beheben. Ohne kontinuierliche Erfassung von Alert-Volumen, FPR je Use Case und Eskalationsquote fehlt die Grundlage jeder Tuning-Entscheidung. ISO/IEC 27002:2022 Clause 8.16 und NIST SP 800-92 (Log Management) setzen beide voraus, dass Organisationen ihre Monitoring-Infrastruktur kennen und steuern. BSI DER.1 Edition 2023 verlangt dokumentierte Alarmierungsverfahren, was implizit die regelmäßige Auswertung von Alarmierungsereignissen einschließt. Ohne Messbarkeit ist jede Aussage über den Zustand der Erkennungsfähigkeit eine Annahme, keine Tatsache.
• Eskalations-SLAs ohne Prüfbarkeit definieren: Viele SOC-Prozessdokumentationen enthalten Reaktionszeitfristen ohne technisches Tracking. NIS-2 Artikel 23 schreibt eine Erstmeldung erheblicher Sicherheitsvorfälle binnen 24 Stunden vor. Diese Frist ist rechtlich verbindlich und setzt voraus, dass die Eskalationskette vom ersten Alert bis zur Vorfallsbestätigung funktioniert und dokumentiert ist. Eskalations-SLAs, die nicht im Ticketing-System hinterlegt und regelmäßig ausgewertet werden, sind regulatorisch wertlos und geben dem SOC-Management ein falsches Sicherheitsgefühl.

Relevanz im regulatorischen Kontext

Alert Fatigue ist kein rein operatives, sondern ein regulatorisch adressiertes Thema. NIS-2 (Richtlinie EU 2022/2555) verpflichtet wesentliche und wichtige Einrichtungen in Artikel 21 Absatz 2 zur Implementierung von Cybersicherheitsmaßnahmen zur Erkennung von Anomalien und in Artikel 23 zur Meldung erheblicher Sicherheitsvorfälle in einem dreistufigen Prozess: Erstmeldung innerhalb von 24 Stunden, Folgemeldung innerhalb von 72 Stunden, Abschlussbericht innerhalb eines Monats. Diese Fristen sind nur einzuhalten, wenn die Triage-Prozesse und Eskalationswege im SOC keine durch Alert Fatigue bedingten Verzögerungen aufweisen. BSI IT-Grundschutz DER.1 Edition 2023, Anforderung DER.1.A1, verlangt dokumentierte Alarmierungsverfahren und benennt fehlerhaft konfigurierte Alarmierung als konkretes Risiko, das die Erkennungsfähigkeit untergräbt.

ISO/IEC 27001:2022 Clause 9.1 (Monitoring, Measurement, Analysis and Evaluation) verpflichtet ISMS-zertifizierte Organisationen, die Wirksamkeit ihrer Sicherheitsmaßnahmen regelmäßig zu messen und zu bewerten. Die Erkennungsfähigkeit des SOC, ausgedrückt in Metriken wie FPR, Alert-Volumen und MTTD, ist eine zentrale Leistungskennzahl des ISMS. ISO/IEC 27002:2022 Clause 5.24 beschreibt Incident Management Planning als ganzheitlichen Ansatz, der Monitoring, Detection, Classification, Analysis und Reporting umfasst, und macht damit deutlich, dass eine isolierte Betrachtung technischer Systeme ohne Prozess- und Personalebene dem Norm-Anspruch nicht genügt. Organisationen, die eine ISO-27001-Zertifizierung anstreben oder aufrechterhalten, müssen die Handlungsfähigkeit ihres SOC inklusive Alert-Management-Kapazität als messbares ISMS-Ziel verankern.

Häufige Fragen