Notfallreaktion - Emergency Response
In der IT-Sicherheit geht es in der Regel darum, Sicherheitsvorfälle zu verhindern. Dies kann leider nicht immer klappen. Wie reagiert man nun auf einen Sicherheitsvorfall? Die Leitfäden verschiedener Organisationen (wie z.B. des NIST [1]) ähnlichen sich alle in ihren Grundzügen. In der Regel wird die Reaktion in Phasen aufgeteilt, die einen Kreislauf darstellen:
Entdeckung
Manchmal ist es offensichtlich, dass ein Sicherheitsvorfall vorliegt. Oft gibt es aber nur Hinweise, die auf ein Problem hinweisen. Ob ein Sicherheitsvorfall vorliegt oder ein technisches Problem, ist dann nicht einfach zu entscheiden: Ein Netzwerkdienst kann ausgefallen sein, weil dieser auf einen seltenen Fehler gestoßen ist. Der Absturz kann aber auch auf einen Angriff zurückzuführen sein.
Es muss herausgefunden werden, ob wirklich ein Angriff vorliegt. Um dabei nicht wichtige Punkte zu vergessen, werden an dieser Stelle oft Checklisten eingesetzt. Diese Checklisten sollten aber nur eine Grundlage darstellen, die dynamisch durch weiterführende Tests ergänzt werden. Beispiele dafür, was konkret untersucht werden sollte gibt das DFN-CERT [2] [3].
Analyse
Im Rahmen der Analyse wird versucht die typischen 'W'-Fragen zu beantworten:
- Wann ist der Angriff erfolgt?
- Wie konnten die Angreifer Zugriff erlangen?
- Was genau ist passiert?
- Wer sind die Angreifer?
- ...
Sobald klar ist, dass es sich um einen Sicherheitsvorfall handelt, sollten auch weitere Parteien informiert werden. Zum einen die eigene Leitung und ggf. auch der Rechtsbeistand oder die Pressestelle.
Bereinigung
Im Anschluss an die Analyse sollte ein kompromittiertes System vom Netzwerk getrennt werden, um dieses der Kontrolle der Angreifer zu entziehen. Bei einem Denial of Service Angriff wird dagegen versucht, die Überlast-Situation zu bereinigen. Wurden potentiell Passwörter kompromittiert so müssen diese nun geändert oder die dazugehörigen Konten gesperrt werden.
Weiterhin sollte an diesem Punkt ggf. Kontakt mit weiteren betroffenen Parteien aufgenommen werden. Dies könnten die Administratoren des angreifenden Systems sein (wahrscheinlich wurde auch das System bereits kompromittiert) oder auch die Polizei sein, wenn eine Anzeige erstattet werden soll.
Wiederherstellung
Hatten die Angreifer im Rahmen des Vorfalls Zugriff auf das System, sollte dieses jetzt von Original-Medien neu installiert werden. Wird an dieser Stelle nur die Malware oder andere vorgefundenen Überbleibsel der Angreifer gelöscht, besteht die Gefahr, dass eine Backdoor übersehen wird. Außerdem sollten Patches eingespielt und Sicherheitslücken beseitigt werden, damit die Angreifer nicht erneut Zugriff erlangen können.
Gelernte Lektion
Nach dem Sicherheitsvorfall sollte mit den beteiligten Personen besprochen werden, welche Maßnahmen gut funktioniert haben und welche nicht. Nur so kann beim nächsten Mal besser reagiert werden.
Vorbereitung
Im Rahmen der Vorbereitung sollten die Erkenntnisse der Nachbesprechung umgesetzt werden. In der Regel ist dies der Zeitpunkt Notfallpläne zu erstellen, den Umgang mit den eingesetzten Werkzeugen zu üben und ggf. eine Schulung zu organisieren.
Es ist nicht einfach auf Sicherheitsvorfälle zu reagieren: Einerseits muss die Reaktion zeitnah erfolgen. Andererseits können ungünstige Entscheidungen dafür sorgen, dass Spuren verloren gehen und eine Aufklärung unmöglich wird. Aus diesem Grund ist Vorbereitung und frühzeitige Beschäftigung mit dem Thema hilfreich, denn: Nach dem Vorfall ist immer auch vor dem Vorfall!
[1] Karen Scarfone, Tim Grace, Kelly Masone: Computer Security Incident Handling Guide, National Institute of Standards and Technology, Special Publication 800-61 Revision 1, März 2008
[2] DFN-CERT: Suche nach Hinweisen auf Kompromittierung am Beispiel von UNIX / Linux
[2] DFN-CERT: Suche nach Hinweisen auf Kompromittierung am Windows-Beispiel