Cybersecurity-Vorfälle gehören inzwischen leider zum Alltag und müssen heute schlicht als Teil der Normalität betrachtet werden. Auch grosse, technisch fortgeschrittene und kapitalkräftige Unternehmen sind nicht immer in der Lage, der Anzahl und Komplexität der Angriffe angemessen zu begegnen. Es ist deshalb in Fachkreisen längst als Tatsache anerkannt, dass ein erfolgreicher Cyberangriff für die allermeisten Organisationen nur eine Frage der Zeit ist.

Wenn ein Vorfall eintritt, ist es zu spät, die nötigen Abläufe, Hilfsmittel und Kommunikationsstrategien für eine erfolgreiche Incident Response zu etablieren. Ohne einen geeigneten Plan könnten Angriffe vielleicht gar nicht entdeckt werden oder die Reaktion darauf bedient sich nicht der geeigneten Mittel und Wege, mit dem Resultat eines viel grösseren Schadensausmasses, als es bei einer gründlichen Vorbereitung der Fall gewesen wäre. Vor diesem Hintergrund ist es einleuchtend, dass neben einem soliden Grundschutz und effektiven Detektionsfähigkeiten auch die sorgfältige Vorbereitung auf mögliche Vorfälle zu einer guten Sicherheitsstrategie gehören muss.

Was sind Incident Response Playbooks?

Bezüglich Incident Response und Recovery lässt sich zwischen allgemeinen, häufig für die gesamte Organisation geltenden Gesichtspunkten und spezifischen, auf bestimmte Situationen zugeschnittenen Verfahren unterscheiden. Der Incident Response Prozess selbst wird in der Regel übergeordnet festgelegt, während Incident Response Playbooks vorgefertigte Ablaufdefinitionen sind, die das detaillierte Vorgehen beim Auftreten bestimmter Vorfälle oder Probleme beschreiben. Typische Themen für Playbooks sind etwa der Umgang mit einem Malware-Befall, das Vorgehen beim Empfang von Phishing-Mails oder die Massnahmen, die bei einem DDoS-Angriff ergriffen werden. Incident Response Playbooks sind demnach themenspezifische Praxisanleitungen, die das praktische Vorgehen zur Incident Response auf vordefinierte Angriffe bzw. Vorfälle festlegen.

Incident Response Playbooks sollen es erleichtern, bei einem Vorfall möglichst rasch effektive und sinnvolle Aktionen ausführen zu können, um die negativen Auswirkungen von Cybersecurity-Vorfällen so klein wie möglich zu halten. Sie haben damit den Charakter von Notfallplänen und müssen sehr praxisbezogen sein. Wie bei anderen kritischen Vorfällen auch, müssen die Abläufe, Verantwortungen, Kommunikationswege und eingesetzten Werkzeuge im Voraus festgelegt werden, denn während der heissen Phase eines Cybersecurity Incidents kann man es sich nicht leisten, Grundsatzentscheide zu diskutieren oder etwa wertvolle Zeit mit dem Suchen von Telefonnummern oder Passwörtern zu verlieren.

Incident Response Playbooks werden durch einen auslösenden Umstand (vermuteter oder festgestellter Vorfall) aktiviert, beinhalten entsprechende Prozessschritte und definieren einen Endzustand. Sie sollten folgende Merkmale aufweisen:

• Bezug auf einen klar definierten Vorfall (Scope-Definition)
• Enthalten detaillierte, vollständig dokumentierte und standardisierte Abläufe
• Fokus auf den Umgang mit den Konsequenzen eines Vorfalls, nicht auf dessen Ursache
• Das Dokument und die verwendete Sprache sind auch unter Druck einfach verständlich
• Die praktische Anwendbarkeit steht im Vordergrund
• Erleichterung und Regelung schwieriger Entscheidungen und konkurrierender Ziele, beispielsweise ob ein System so schnell wie möglich wieder in Betrieb genommen werden muss oder zuerst Untersuchungen gemacht und Beweise gesammelt werden sollen
• Definition von Regeln für den Beizug externer Stellen wie externe Expertise, Versicherungen, Forensik, Behörden, usw.
• Festlegen von Regeln für die externe Kommunikation (Öffentlichkeit, Kunden, Geschäftspartner)
• Unterliegen einer regelmässigen Pflege und Aktualisierung

Struktur und Inhalt von Playbooks

Bei der Reaktion auf einen Cybersecurity Incident gibt es oft eine Asymmetrie zwischen Angreifer und Verteidiger: Der Verteidiger kennt die Motivation und die Ziele des Angreifers (noch) nicht, das Ausmass der Kompromittierung ist nicht bekannt, die Auswirkungen können noch nicht abgeschätzt werden und so weiter. Es handelt sich also um eine sehr akute, aber reaktive Situation. Man muss wissen, welche Mittel nun zur Verfügung stehen, zu welchen Entscheidungen man autorisiert ist und was deren Auswirkungen sein können. All dies sollte soweit wie möglich schon vor einem Incident definiert und geübt sein.

Playbooks müssen in erster Linie praxistauglich sein. Freiheit bei der Wahl des Aufbaus und Inhalts gemäss den Gegebenheiten des Anwendungsbereichs ist deshalb sinnvoll. Eine Struktur angelehnt am Vorgehen für das Incident Handling gemäss dem SANS Institut hat sich bewährt:

1. Vorbereitung (Preparation)
2. Detektion (Identification, Detection)
3. Analyse (Analysis)
4. Eindämmung (Containment)
5. Behebung (Eradication, Remediation)
6. Wiederherstellung (Recovery)
7. Erfahrungen und Verbesserungen (Lessons Learned)

Diese Aufteilung der Inhalte ist als bewährte Praxis zu betrachten und kann situativ natürlich auch vereinfacht oder in weniger Phasen untergebracht werden.

1. Vorbereitung

Die Vorbereitungen dienen der Bereitstellung aller Mittel und Abläufe, die zur Bewältigung von Cybersecurity Incidents notwendig sind. Deshalb sind viele der Vorbereitungsarbeiten allgemeiner Natur mit Resultaten, die für alle Arten von Cybersecurity Incidents Gültigkeit haben, wie etwa Ablaufdefinitionen, Aufbau des Incident Response Teams, zentrale Anlaufstellen, Detektions- und Alarmierungswege usw. Solche relevanten, aber allgemeingültigen Informationen werden sinnvollerweise zentral verwaltet.

Dieser Abschnitt der Playbooks sollte deshalb nur diejenigen Informationen über die getroffenen Vorbereitungen beinhalten, die spezifisch für das jeweilige Playbook-Thema relevant sind. Ein Playbook für einen DDOS-Angriff würde hier unter anderem detaillierte Angaben über die vorbereiteten Mitigationsmassnahmen enthalten und mit dem Provider vereinbarte Services benennen, während ein Malware-Playbook Informationen über den eingesetzten Malware-Schutz und Detektions- und Analysemöglichkeiten enthält.

2. Detektion

Die Detektion eines Incidents oder eines dringlichen Hinweises darauf ist der Auslöser für das Playbook. In diesem Abschnitt des Playbooks werden die vorhandenen Detektionsmechanismen und Meldewege gemäss Playbook-Thema beschrieben. Meistens sind dies Alarme von einem Monitoring- oder Alarmierungssystem wie einem IDS oder SIEM, es sollten aber auch Meldungen von Benutzern oder externen Stellen in Betracht gezogen werden.

Je spezifischer und genauer die Detektion eines Vorfalls ausfällt, desto zielgerichteter und effizienter kann darauf reagiert werden. In der Praxis ist oft die Korrelation vieler Indizien notwendig, um zu einer genauen Detektion zu gelangen und der Übergang zwischen Detektion und nachfolgender Analyse ist oft fliessend.

3. Analyse

Die Analyse verfolgt das Ziel, die tatsächlichen und noch möglichen Auswirkungen des Vorfalls zu bestimmen. Es wird also nicht so sehr auf die Ursache fokussiert, als vielmehr auf die Konsequenzen, denn diese bestimmen die weiteren Schritte innerhalb des Playbooks.

Der vielleicht wichtigste Schritt in dieser Phase ist die Bestimmung der Kritikalität und der geschäftlichen Auswirkungen (Business Impact) des Vorfalls, da diese Einfluss auf das weitere Vorgehen haben. Üblicherweise geschieht dies anhand einfacher Kriterien mit Hilfe einer Tabelle oder eines Entscheidungsbaums, der die Kritikalität (in der Regel drei oder vier Stufen) mit bestimmten Umständen, Systemen oder Prozessen in Bezug setzt. Typische Fragestellungen sind hier etwa, ob Kundendaten betroffen sind, ein Abfluss vertraulicher Daten stattgefunden hat oder geschäftliche Kernprozesse beeinträchtigt sind. Ausserdem sollte in dieser Phase auch über das Sammeln von Beweismaterial entschieden werden und ob es gerichtlich verwendbar sein muss.

4. Eindämmung

Die Eindämmung bezweckt ein möglichst rasches und wirkungsvolles Unterbinden der schädlichen Vorgänge und ihrer Auswirkungen sowie das Verhindern weiterer Ausbreitung. Dieser Teil eines Playbooks besteht aus der Auflistung der zu ergreifenden technischen und organisatorischen Massnahmen. Diese haben oft den Charakter einer Sofortlösung; die dauerhafte Lösung des Problems wird in der Regel später, nach eingehender Planung und zusammen mit anderen Teams in Angriff genommen.

Beim Beispiel eines Malware-Playbooks könnte dies das Vorgehen zum Scannen und Isolieren betroffener Systeme vom Netzwerk sein oder bei einem Phishing-Angriff eine flächendeckende Vorwarnung der möglichen Empfänger.

5. Behebung

Mit der Behebung soll einerseits der schadenverursachende Umstand vollständig entfernt werden, nachdem er in der vorgängigen Phase unschädlich gemacht wurde. Andererseits soll das zugrunde liegende Problem eliminiert werden, das den erfolgreichen Angriff überhaupt ermöglichte, häufig indem die Sofortlösung in eine permanente und betrieblich vertretbare Lösung überführt wird. Die Behebung ist meistens keine einfache Aufgabe und kann eine oder eine ganze Reihe von Massnahmen umfassen, deren Effektivität über die Zeit gemessen werden muss. Die spezifischen Schritte sind stark vom Thema des Playbooks und der Problemursache abhängig und können vom Einspielen von Patches bis zum vollständig neuen Aufsetzen ganzer Infrastrukturen reichen.

6. Wiederherstellung

Hier geht es darum die Systeme und Infrastrukturkomponenten wieder in den regulären Betrieb zu überführen. Dabei sollte auch die Überwachung (Logging, Monitoring, Alarmierung) anhand der gemachten Erkenntnisse angepasst werden, um einerseits sicher zu stellen, dass die Eindämmung und Behebung tatsächlich erfolgreich waren und andererseits um Indizien für erneute Incidents frühzeitig zu erkennen.

Die Rückkehr zum Normalbetrieb nach einem Incident nimmt Zeit in Anspruch. Die Verwendung dieser Zeit im Voraus zu planen erlaubt eine rasche und zielgerichtete Wiederherstellung. Dabei ist es enorm wichtig, die Aktivitäten in dieser Phase genau zu überwachen und zu protokollieren, um einen Erfahrungswert für die zur Wiederherstellung erforderliche Zeit zu gewinnen. Schliesslich wird mit diesen Informationen eine Verbesserung der Recovery-Phase hinsichtlich Effektivität und Effizienz ermöglicht.

7. Erfahrungen und Verbesserungen (Lessons Learned)

Nicht selten wird dieser letzte Schritt vernachlässigt, sei es aus Erleichterung über den überstandenen Vorfall oder aus daraus folgendem Zeitmangel. Dennoch: Jeder Vorfall ist ein Lehrbeispiel und es ist sehr wichtig, dieser Phase die nötige Priorität zuzuweisen, zurück zu schauen und die gemachten Erfahrungen zu dokumentieren. Einen detaillierten Rapport zu erstellen mit allen Beobachtungen und Massnahmen ist eine gute Vorbereitung auf künftige Ereignisse. Wichtige Fragen, die man sich hierbei stellen sollte:

• Wie ist es zum Vorfall gekommen und warum konnte er entstehen?
• Was könnte ihn verhindert haben?
• Welche technischen und organisatorischen Sicherheitsmassnahmen müssen angepasst oder verstärkt werden?
• Wurden bei der Incident Response Fehler gemacht und wie könnten diese künftig vermieden werden?
• Sind Schwächen im Prozess oder in der Organisation festgestellt worden?
• Hat die Kommunikation während des Incidents funktioniert?
• Welche Erfahrungswerte lohnt es, einem breiteren Publikum zugänglich zu machen?

Schliesslich ist es sehr lohnend, diese gesammelten Erkenntnisse in einen kontinuierlichen Verbesserungsprozess einfliessen zu lassen und dabei nicht nur das Playbook, sondern den gesamten Incident Response Prozess zu berücksichtigen.

Welche Playbooks braucht es?

Jede Organisation ist spezifischen Risiken ausgesetzt und besitzt ihre eigenen Prozesse und organisatorischen Gegebenheiten. Playbooks sind konkret und praxisbezogen und damit notwendigerweise individuell, die Themen und Inhalte der Playbooks müssen also auf die jeweilige Organisation zugeschnitten sein. Dennoch lassen sich einige grundsätzliche Themen identifizieren, die als Ausgangspunkte für einen eigenen Playbook-Katalog dienen können:

• Ausbruch von Schadsoftware
• Befall mit Ransomware
• Umgang mit Phishing
• Umgang mit Datenpannen
• Vorgehen bei DoS-Angriffen
• Vorgehen in Erpressungsfällen
• Ablauf bei unbefugtem Zutritt
• Missbrauch von Berechtigungen, Anwendungen und Systemen (Insider-Vorfälle)

Fazit

Jede Organisation wird sich früher oder später mit einem Cybersecurity-Vorfall auseinandersetzen müssen. Neben einem guten Grundschutz und geeigneten Detektionsmechanismen kann eine sorgfältige Vorbereitung auf Sicherheitsvorfälle den entscheidenden Unterschied zwischen optimaler Schadensbegrenzung und existenzbedrohenden Konsequenzen ausmachen. Incident Response Playbooks definieren die konkreten praktischen Abläufe zur Reaktion auf Cybersecurity-Incidents und sind damit ein essentieller Bestandteil des Incident Response und Recovery Prozesses.

Weiterführende Informationen

• NIST Guide for Cybersecurity Event Recovery
• NIST Computer Security Incident Handling Guide
• Playbooks from the Incident Response Consortium
• NIST Cybersecurity Framework

Über den Autor

Tomaso Vasella hat seinen Master in Organic Chemistry an der ETH Zürich abgeschlossen und ist seit 1999 im Bereich Cybersecurity aktiv. Positionen als Berater, Engineer, Auditor und Business Developer zählen zu seinen Erfahrungen. (ORCID 0000-0002-0216-1268)

Links

• https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final
• https://www.incidentresponse.com/playbooks
• https://www.nist.gov/cyberframework
• https://www.nist.gov/publications/guide-cybersecurity-event-recovery
• https://www.sans.org/course/hacker-techniques-exploits-incident-handling