Ein modernes Security Operations Center verarbeitet je nach Unternehmensgröße zwischen 10.000 und 150.000 Sicherheitsmeldungen pro Tag. Die meisten davon sind harmlos. Einige sind relevant. Und wenige davon sind echte Vorfälle, die sofortiges Handeln erfordern. Die Herausforderung liegt darin, diese drei Gruppen zuverlässig auseinanderzuhalten, bevor ein Angreifer tiefer ins Netz eindringt.
Was ein Alert überhaupt ist
Ein Alert ist eine automatisch erzeugte Meldung aus einem Sicherheitssystem, etwa einem SIEM (Security Information and Event Management), einem Intrusion Detection System oder einem Endpoint Protection Tool. Er signalisiert, dass ein definierter Schwellenwert überschritten oder ein bekanntes Muster erkannt wurde. Das kann ein fehlgeschlagener Login-Versuch sein, ein ungewöhnlicher Dateiaufruf oder eine ausgehende Verbindung zu einer als verdächtig bekannten IP-Adresse.
Alerts sind keine Fakten, sondern Hinweise. Sie basieren auf Regeln und Signaturen, die Analysten oder Hersteller vorher definiert haben. Das bedeutet: Sie können falsch liegen. Die sogenannte False-Positive-Rate ist in der Praxis ein ernstes Problem. Wer jeden Alert als echten Angriff behandelt, lähmt seinen Betrieb. Wer zu viele ignoriert, riskiert, dass ein echter Einbruch unbemerkt bleibt.
Triage: Die erste Einordnung
Der erste Schritt nach Eingang eines Alerts ist die Triage. Analysten auf Level 1 prüfen, ob der Alert plausibel ist und ob er zu bekannten Mustern passt. Dabei helfen Kontextinformationen: Wann genau ist das Ereignis aufgetreten? Auf welchem System? Welcher Nutzer war beteiligt? Gab es vergleichbare Ereignisse in den letzten Stunden oder Tagen?
Ein konkretes Beispiel: Ein Alert meldet um 3:14 Uhr morgens fünf fehlgeschlagene SSH-Logins auf einem internen Server, gefolgt von einem erfolgreichen Login. Isoliert betrachtet könnte das ein vergessenes Passwort sein. Im Kontext mit einem unbekannten Quell-IP-Bereich aus Osteuropa und einem Nutzer, der normalerweise nur tagsüber aus Deutschland zugreift, verschiebt sich die Bewertung erheblich.
Die Triage-Phase dauert in der Regel zwei bis zehn Minuten pro Alert. Danach entscheidet der Analyst: schließen (False Positive), beobachten oder eskalieren.
Von der Einzelmeldung zum zusammenhängenden Vorfall
Ein einzelner Alert führt selten direkt zu einem deklarierten Incident. Meist ist es eine Kette von Ereignissen, die erst in der Zusammenschau ein erkennbares Angriffsmuster ergibt. Diesen Prozess nennt man Korrelation. SIEM-Systeme versuchen diese Korrelation automatisiert zu leisten, stoßen aber bei komplexen, mehrstufigen Angriffen an ihre Grenzen.
Hier kommen Level-2-Analysten ins Spiel. Sie untersuchen, ob mehrere Alerts miteinander zusammenhängen, ob ein Angreifer möglicherweise verschiedene Systeme nacheinander angesteuert hat und ob das Verhalten einem bekannten Angriffsmuster entspricht. Als Referenz dient dabei häufig das MITRE ATT&CK Framework, das reale Angriffstaktiken und -techniken systematisch dokumentiert. Ein Lateral-Movement-Muster, bei dem sich ein Angreifer schrittweise durch das Netzwerk bewegt, setzt sich oft aus Dutzenden Einzel-Alerts zusammen, die jeder für sich unverdächtig wirken.
Themen wie diese sind auch Gegenstand der Arbeit von Fachleuten, die sich auf Blue Team und SOC spezialisiert haben und Unternehmen dabei unterstützen, genau diese Erkennungsprozesse aufzubauen und zu strukturieren.
Klassifikation und Schweregrad
Wird ein Alert oder eine Alert-Gruppe als echter Vorfall eingestuft, beginnt die formale Klassifikation. Üblich ist eine Einteilung nach Schweregrad, oft in vier Stufen:
- Kritisch: Aktiver Einbruch, laufende Datenkompromittierung oder Ransomware-Aktivität. Sofortiger Handlungsbedarf rund um die Uhr.
- Hoch: Starke Anzeichen für einen Einbruchsversuch oder kompromittierte Zugangsdaten mit hohem Schadenspotenzial.
- Mittel: Verdächtiges Verhalten ohne direkte Kompromittierung, erfordert weitere Untersuchung innerhalb weniger Stunden.
- Niedrig: Abweichungen, die dokumentiert, aber nicht sofort bearbeitet werden müssen.
Diese Einstufung ist keine rein technische Entscheidung. Sie hängt auch davon ab, welche Systeme betroffen sind. Ein kompromittierter Büro-PC ist anders zu bewerten als ein angegriffener Domain Controller oder ein System, das Produktionsdaten verarbeitet. Der Geschäftskontext spielt also direkt in die Sicherheitsbewertung hinein.
Eskalation und Incident Response
Ab einem bestimmten Schweregrad verlässt der Vorfall das reine SOC-Umfeld und wird an das Incident-Response-Team übergeben. Diese Übergabe muss strukturiert erfolgen: Mit vollständiger Dokumentation aller bisherigen Findings, einer klaren Zeitlinie der Ereignisse und einer ersten Hypothese über den Angriffsweg.
Für Unternehmen, die unter die NIS2-Richtlinie fallen, kommen hier zusätzliche Meldepflichten hinzu. Das Bundesamt für Sicherheit in der Informationstechnik, kurz BSI, gibt vor, dass erhebliche Sicherheitsvorfälle innerhalb von 24 Stunden gemeldet werden müssen. Ein schlecht geführtes SOC, das Incidents zu spät erkennt oder intern nicht sauber dokumentiert, kann diese Fristen nicht einhalten.
Parallel läuft die Eindämmung. Je nach Vorfall werden betroffene Systeme vom Netz getrennt, Benutzerkonten gesperrt oder bestimmte Netzwerksegmente isoliert. Diese Maßnahmen müssen schnell sein, dürfen aber nicht blind erfolgen, weil sie sonst Spuren vernichten, die für die forensische Analyse wichtig wären.
Was gute SOC-Arbeit ausmacht
Die technische Infrastruktur ist nur ein Teil der Gleichung. Mindestens genauso wichtig ist die Qualität der Playbooks, also der vordefinierten Handlungsanweisungen für bestimmte Alert-Typen, und die kontinuierliche Weiterentwicklung der Erkennungsregeln. Ein SOC, das dieselben Regeln seit zwei Jahren unverändert betreibt, erkennt neue Angriffsmethoden nicht zuverlässig.
Auch das Thema Burnout verdient Aufmerksamkeit. Studien aus dem Bereich Informationssicherheit zeigen, dass Alert-Fatigue, also die Abstumpfung durch zu viele Meldungen, eine der häufigsten Ursachen für übersehene Incidents ist. Wer 500 False Positives pro Schicht bearbeitet, reagiert auf den 501. Alert langsamer und weniger sorgfältig. Organisatorische Maßnahmen wie Rotationen, klare Eskalationspfade und regelmäßige Überprüfung der Alert-Volumen sind deshalb kein Komfort, sondern betriebliche Notwendigkeit.
Die akademische Auseinandersetzung mit diesen Prozessen findet unter anderem im Bereich der Informationssicherheit statt, wo Konzepte wie Defense-in-Depth und Zero Trust zunehmend die theoretische Grundlage für moderne SOC-Architekturen liefern.
Am Ende steht immer dieselbe Frage: Wie viel Zeit hat ein Angreifer unbemerkt im Netzwerk verbracht? Die durchschnittliche Verweildauer vor Entdeckung lag laut verschiedenen Branchenberichten noch vor wenigen Jahren bei über 200 Tagen. Gut aufgestellte SOC-Teams kommen heute auf Werte unter 20 Tagen, manchmal unter 24 Stunden. Der Unterschied liegt nicht in der Technik allein, sondern im Prozess dahinter.
