Cyberangriffe bzw. Hacker interessieren sich nicht für geduldiges Papier oder theoretische Compliance. Überspitzt gesagt: Was in der praktischen Umsetzung nicht effizient funktioniert, ist das Papier nicht wert! Es wäre dann lediglich eine „Checkbox-Übung“, um die jeweilige Compliance-KPI auf „Grün“ zu setzen.
Des Weiteren lassen sich Cyberangriffe nicht zu 100 % verhindern. Man kann jedoch die Hürden zur Überwindung von Sicherheitsbarrieren erhöhen, den Aufwand für Angreifer „verteuern“ und Angriffe im Optimalfall wirkungslos machen, sodass diese scheitern oder abgebrochen werden. Dass Hacker z.B. eine Webseite auf Schwachstellen untersuchen, Brute-Force-Angriffe durchführen oder Verzeichnisse nach geheimen Unterpfaden scannen, ist jederzeit möglich. Das Rezept einer effektiven Cyber-Verteidigung besteht daher im Konzept der Resilienz (Widerstandsfähigkeit) und in der „Defense in Depth“ (gestaffelte Verteidigung) – von der Früherkennung eines Angriffs bis zum Disaster Recovery, also der Wiederherstellung von Systemen und Daten, um in den normalen Operationsmodus zurückzukehren.
Wer behauptet, alle Cyberangriffe zu verhindern, bevor sie ihr Ziel treffen, müsste den „Heiligen Gral“ der Cyber-Defense gefunden haben. Genau aus diesem Grund möchte ich mit diesem Beitrag auf Cyber Incident Response und SOC-Übungen eingehen: Es ist der entscheidende Unterschied zwischen theoretischer Compliance und echter operativer Widerstandsfähigkeit.
Um Cyber-Incident-Response-Pläne (Playbooks) und ein eventuell vorhandenes SOC effektiv zu testen, benötigen wir messbare Ergebnisse basierend auf realistischen Szenarien sowie echte Reaktionen aller Beteiligten. Mit theoretischer Compliance meine ich in diesem Kontext reine Table-Top-Übungen. Table-Tops sind für den Einstieg in Ordnung, bleiben aber letztlich moderierte Diskussionen, in denen lediglich auf Playbooks oder Policies verwiesen wird. Es ist keine praxisnahe Übung. Sie helfen zwar, ein Grundverständnis dafür aufzubauen, wie sich jede(r) im Ernstfall verhalten sollte. Doch um die eigene Reife zu steigern und wirklich zu messen, ob ein Playbook in der Praxis das gewünschte Resultat liefert und der Incident-Response-Prozess 1:1 wie definiert funktioniert, benötigt es realistischere Szenarien sowie den Mut zur Selbstreflexion. Jeder Prozessschritt muss in der Praxis wie definiert umsetzbar sein.
Aus meiner Sicht und Erfahrung bedarf es eines „Blackbox“-Szenarios, in das nur ein minimaler Kreis eingeweiht ist. Hierbei bereitet ein kleines Team einen Angriff vor und führt diesen aus, wobei vorab klare Mess- und Erfolgsfaktoren festgelegt werden. Wir wollen jeden Schritt bewerten: Sind die Annahmen im Falle eines echten Angriffs realistisch?
Dazu gehören unter anderem:
-
Reaktionszeiten und Triage: Wie lange dauert es, bis das SOC reagiert? Falls kein SOC vorhanden ist: Wie schnell ist das Incident-Team nach der Meldung einsatzbereit?
-
Interpretation: Wird der Vorfall richtig eingeordnet? Funktioniert die Priorisierung (Triage)? Bewertung der richtigen Einordnung.
-
Krisen-Management-Team Einberufung: Wie viel Zeit vergeht, bis das Krisenteam zusammenkommt und das Management des Incidents übernimmt?
-
Verfügbarkeit: Sind basierend auf dem Szenario alle notwendigen Ressourcen und Stakeholder tatsächlich erreichbar? Wie lange dauert es bis das Team vollständig ist?
-
Playbook-Check: Gibt es für spezifische, wiederkehrende Angriffsmuster überhaupt ein geeignetes Playbook? Ist dieses in der Praxis ausführbar?
-
Experten-Know-how: Sind Experten verfügbar, die den Incident analysieren und isolieren können? Wie lange dauern die einzelnen Response-Phasen?
-
Technische Isolation: Bestehen überhaupt die technischen Möglichkeiten, einen Angriff wirksam zu isolieren?
-
Kommunikation & Meldepflichten: Funktioniert die interne und externe Kommunikation? Können meldepflichtige Vorfälle (z. B. gemäß DSGVO oder NIS2) fristgerecht gemeldet werden? Besteht Zugriff auf die notwendigen Meldeportale und ist geklärt, wer die Analysen für die Behörden zeitnah liefert?
Diese "Blackbox" Übung kann man noch wunderbar auf den von mir definierten "Cross Company Resilience" Ansatz erweitern, indem man mindestens einen weiteren Geschäftspartner mit involviert und so z.b. übergreifend geschäftskritische Prozesse und Cybervorfälle gemeinsam übt.
Siehe auch dazu mein Beitrag in der GIT-Sicherheit.
Am Ende der Übung haben wir Erfolgs- und Messfaktoren und bekommen ein wesentlich klareres Bild wie es sich um den eigenen aktuellen Reifegrad des Cyber Incident Response Prozesses steht. Wird dieser bei einem echten Angriff umsetzbar sein? Schützen wir unser Geschäft erfolgreich?
Messwerte / KPI's:
1. Zeitbasierte Metriken (Speed & Agility)
Diese Faktoren messen, wie schnell die Organisation auf einen Angriff reagiert.
- MTTD (Mean Time to Detect): Wie lange dauert es vom ersten bösartigen Ereignis (dem simulierten Blackbox-Angriff) bis zur Alarmierung im SOC?
- MTTR (Mean Time to Respond/Triage): Wie lange dauert es, bis der Alarm durch einen Analysten bewertet und als echter Incident eingestuft wird?
- Time to Escalate: Zeitspanne bis zur Einberufung des Krisenteams nach der Triage.
- Time to Isolate: Wie viel Zeit vergeht, bis technische Maßnahmen zur Eingrenzung des Schadens (z. B. Segmentierung) erfolgreich durchgeführt wurden.
2. Qualitative & Prozess-Metriken (Quality & Accuracy)
Hierbei geht es darum, ob die definierten Prozesse (Playbooks) in der Praxis funktionieren.
- Playbook Accuracy: Wie hoch ist der Prozentsatz der Schritte im Playbook, die 1:1 wie definiert umsetzbar waren? (Identifikation von "Papierleichen").
- Triage Accuracy: Wurde der Vorfall korrekt klassifiziert (z. B. Ransomware vs. Datenabfluss) oder gab es Fehlinterpretationen?
- Resource Availability Rate: Prozentsatz der im Playbook vorgesehenen Stakeholder und Experten, die zum Zeitpunkt der unangekündigten Übung tatsächlich erreichbar und einsatzbereit waren.
3. Kommunikations- & Compliance-Metriken
Diese Faktoren messen die Fähigkeit, externe Anforderungen unter Druck zu erfüllen.
- Time to Notification (Regulatory): Wäre das Team in der Lage gewesen, die 72-Stunden-Frist der DSGVO oder die Meldefristen von NIS2 einzuhalten?
- Access Readiness: Hatten die zuständigen Personen sofortigen und funktionierenden Zugriff auf die notwendigen Meldeportale (z. B. BSI/NIS2-Portal)?
- Communication Efficiency: Wurden die vordefinierten Kommunikationskanäle genutzt oder gab es riskante Ausweichbewegungen auf private Messenger?
4. Technische Wirksamkeit
- Containment Success Rate: Konnte der Angriff mit den vorhandenen technischen Mitteln gestoppt werden, oder fehlten administrative Berechtigungen/Tools zur Isolation?
- Visibility Gap: Welche Schritte des Angreifers blieben im SOC unsichtbar (Log-Lücken)?