Virtuelle Brandbekämpfung II - Wie sieht Incident Response aus?

Wenn es zum Schlimmsten kommt, dann sollte ein Notfallplan immer so einfach gehalten werden wie möglich. Diese Einfachheit macht die Umsetzung im Ernstfall wesentlich leichter: wenn der Ernstfall eintritt, dann sind alle Beteiligten in der Regel einem erhöhten Stresslevel ausgesetzt. Dieses Stresslevel hat einen direkten Einfluss auf die Fähigkeit der Mitarbeiter, einen kühlen Kopf zu bewahren. Zudem ist der Verfasser eines Planes nicht immer identisch mit der Person, die den Plan in die Tat umsetzen muss.

Unter dieses Umständen ist das Lesen und Umsetzen eines halbseitigen sorgfältig formulierten Textes sehr fehleranfällig. Es gibt aus einer anderen Branche ein Beispiel, wie man es richtig macht: aus der Luftfahrt. Passagierflugzeuge werden mit einem großen grauen Ordner ausgeliefert, dem Quick Reference Handbook, auch "QRH" genannt. Dieser Ordner enthält Checklisten für jede erdenkliche Art von Prozedur, vom Starten der Systeme bis hin zum Versagen eines oder mehrerer Triebwerke. Die Listen sind einfach formuliert und schnell umzusetzen, was auch den Sachzwängen geschuldet ist: Im Ernstfall ist Zeit ein Luxus, den man einfach nicht hat - schnelle Reaktion ist gefragt. Mehrdeutigkeiten oder Interpretationsspielraum darf es an keiner Stelle geben. Zwar ist die Erstellung solcher Checklisten langwierig und kostspielig, aber diese Kosten sind um ein Vielfaches niedriger als die Kosten, die entstehen, wenn man sich komplett unvorbereitet einem Zwischenfall gegenüber sieht. Wenn etwas schiefläuft, dann muss in jedem Fall die Reaktion bereits beim ersten mal "sitzen". Incident-Responder können zwar theoretisch auch ohne all diese Informationen arbeiten, werden aber sehr wahrscheinlich zusätzliches Personal dafür benötigen. Doch selbst für Spezialisten, die mit dieser Tätigkeit ihren Lebensunterhalt bestreiten, kann das Fehlen von Prozeduren auch das Scheitern von Hilfsmaßnahmen bedeuten.

Ein weiterer Faktor, der oft übersehen wird: wenn das Gelände von einerm Sicherheitsdienst bewacht wird, muss dieser ebenfalls über die Ankuft des IR-Teams informiert werden. Auch muss sichergestellt sein, dass die Spezialisten alle erforderlichen Zugänge haben, sobald sie ankommen. Das ist insbesondere dann wichtig, wenn ein Vorfall außerhalb der normalen Bürozeiten stattfindet. Verzögerungen durch fehlende Weitergabe von Informationen an Wachpersonal sind nicht hinnehmbar -  ebenso Verzögerungen durch fehlende Zutrittsberechtigungen, z.B. zu Serverräumen.

Klare Kommunikationswege zu etablieren ist ein wesentlicher Bestandteil eines jeden Notfallplans. Dies schließt sowohl die gesamte Kommunikation während eines Notfalls als auch die Art, in der Zwischenfälle gemeldet werden, ein. Viele Benutzer zögern, jemanden über "irgendetwas Seltsames" zu informieren, oft weil sie entweder Repressalien befürchten oder sich nicht zum Gespött machen wollen. Der beste Weg hier lässt sich mit der Vorgehensweise der US-Heimatschutzbehörde DHS beschreiben: "Wenn Du etwas siehst, dann sage etwas!" ("if you see something, say something!").  Oftmals ist es besser, einmal zu oft den Notfallplan einzuleiten als das eine entscheidende mal zu wenig. Dennoch darf sich niemals "Alarm-Müdigkeit" einstellen.

Während eines Zwischenfalles sollte es festgelegte Ansprechpartner geben, bei denen alle Informationen zusammenlaufen. Es wäre fatal, eine Meldung oder einen Bericht an 25 Leute auf CC zu schicken. Der Grund ist einfach und liegt in der Natur dieser Art der Kommunikation. Sobald jemand eine E-Mail empfängt, die sowohl an ihn selbst als auch an zwei Dutzend weitere Mitarbeiter in Kopie geschickt wurde, ist die Wahrscheinlichkeit hoch, dass keine oder nur eine sehr verzögerte Reaktion erfolgt, da jeder der Adressaten davon ausgeht, "dass irgendjemand sich schon des Problems annehmen wird". Hand aufs Herz: Wann haben Sie das letzte Mal eine langatmige E-Mail gelesen, die sowohl an Sie als auch an 25 andere geschickt wurde, während Sie gerade bis zum Hals in Arbeit steckten? Flache Hierarchien, in denen jeder mit jedem kommuniziert, sind für das Alltagsgeschäft sicher zuträglich, erhöhen aber gerade während eines Notfalles die Wahrscheinlichkeit, dass wichtige Informationen verloren gehen oder nicht an den richtigen Stellen landen. 

Was externe Kommunikation angeht, hängt deren Art und Weise vom jeweligen Zwischenfall ab. Wenn externe Dienste entweder gar nicht oder nur in vernachlässigbarer Weise betroffen sind, sollte ein Betrieb diesen Zwischenfall nicht offensiv nach außen tragen, wenn der Zwischenfall sonst unbeachtet bliebe. Es empfiehlt sich dennoch, einige Basisinformationen für den Fall zusammen zu tragen, dass Nachfragen kommen. Sollte abzusehen sein, dass ein Zwischenfall durch die Presse eine breitere Öffentlichkeit erreicht,  ist es auf alle Fälle besser, Informationen parat zu haben. Wenn man erst mit dem Sammeln von Informationen beginnt, nachdem die ersten Presse-Anfragen das Unternehmen erreichen, verstreicht unnötig Zeit, während der sich einige Medien bereits eine eigene Meinung bilden und schlimmstenfalls unvollständige oder falsche Informationen zu verbreiten. In einem Zwischenfall mit Außenwirkung sollte Kommunikation allerdings kurz gefasst und leicht verständlich sein und auch oft aktualisiert werden. Auf "perfekte" oder "vollständige" Informationen zu warten, ist nicht unbedingt die beste Strategie. Fallabhängig bedeutet jede Stunde, die ohne aktualisierte Informationen für Kunden oder Partner verstreicht, dass Gerüchte die Runde machen, die jeglicher Grundlage entbehren. In diesem Zusammenhang ist es mindestens genau so wichtig, die eigenen Mitarbeiter auf dem aktuellen Stand zu halten. Mitarbeiter sollten auch dazu angehalten werden, in sozialen Netzwerken keinerlei Kommentare oder Details zu verbreiten, da diese zu einem falschen Bild zusammengesetzt werden können, wenn sie aus dem Kontext genommen werden. Dadurch würde auch die öffentliche Kommunikation eines Unternehmens behindert. Sollte ein Ausfall oder Ähnliches einen Dienst betreffen, der öffentlich zugänglich ist, dann sollte auch die PR-Abteilung / die Unternehmenskommunikation in den Notfallplan einbezogen werden.

Aus unserer eigenen Erfahrung mit der G DATA Advanced Analytics wissen wir, dass eine gute Sammlung von Logdateien eines der mächtigsten Werkzeuge in den Händen eines Incident Responders ist. So existieren Firewall-Protokolle zwar meistens, aber es sollten ebenso Protokolldateien von allen Servern, einschließlich der Domain-Controller gepflegt werden. Die Wiederherstellung der Betriebsfähigkeit kann wesentlich effizienter gestaltet werden, wenn auch Client-Logs zur Verfügung stehen. 

Die Aufgabe besteht also darin, zu ermitteln, welche Ereignisse protokolliert und gespeichert werden sollen. Als Faustregel empfehlen wir, Logs immer mindestens ein Jahr lang aufzubewahren. Eine gute Protokoll-Strategie bezieht auch immer das Gleichgewicht zwischen der erforderlichen Detailtiefe und den Kosten der Speicherung mit ein. Spezialisten von G DATA Advanced Analytics unterstützen Kunden regelmäßig bei der Entwicklung dieser Strategien und den vorausgehenden Entscheidungsprozessen.
Gute Protokolle erleichtern die Siche nach bestimmten Indikatoren, die auf eine Kompromittierung hindeuten, unabhängig davon, ob es sich im datei- oder netzwerkbasierte Indikatoren wie die Kommunikation mit bekannten Malware-Kontrollservern handelt. Selbst wenn es auf den ersten Blick widersinnig erscheint, ergibt es beispielsweise Sinn, fehlgeschlagene Login-Versuche zu protokollieren. So kann man beispielsweise erkennen, wenn ein Angreifer versucht, das Passwort zu einem Benutzerkonto zu erraten. Protokolle sollten immer logisch getrennt von der Produktivumgebung gespeichert und verarbeitet werden. Ein Protokollserver, der in einer Produktivumgebung steht, kann selbst kompromittiert werden - und wenn die Gefahr besteht, dass die Protokolle manipuliert wurden, werden diese mit einem Schlag wertlos. Da Eindringlinge sich vielfach monatelang unentdeckt in einem Netzwerk bewegen können, ist es also ratsam, ausreichend historische Daten vorzuhalten. Diese helfen bei der Aufklärung des Ablaufs eines Zwischenfalls und auch bei der Entwicklung von Gegenmaßnahmen.

Je nach Art eines Zwischenfalls ist es besser, ein Problem nicht "quick and dirty" zu beheben, nur um den Normalbetrieb wieder aufzunehmen. Auch das klingt erst einmal widersinnig, aber es gibt Fälle, in denen zunächst Beweise gesichert werden sollten, um diese im Nachgang zu analysieren um die dem Zwischenfall zugrunde liegende Ursache zu finden. Eine mit Schadsoftware infizierte Maschine zu löschen und neu zu installieren kann jedoch genau diese Beweise zerstören, mit deren Hilfe zukünftige Strategien hätten entwickelt werden können. Die Maschine selbst kann dann zwar wieder in den Normalbetrieb überführt werden, aber der Beantwortung der Frage, wie es zu dem Zwischenfall überhaupt erst kommen konnte, ist man keinen Schritt näher. Und nicht nur das: is ist auch einfach nicht ausreichend, sich auf einzelne Rechner zu konzentrieren. Incident Response bezieht immer die Gesamtheit des Netzwerkes in seine Überlegungen ein. Ohne ein ausreichendes Verständnis, wie es zu einem Vorfall wie einer Infektion kommen konnte, ist das Risiko hoch, dass das gleiche wieder passiert. Das gilt selbst für Fälle, in denen kein gezielter Angriff stattgefunden hat, wie bei vielen Industriezweigen, die von einer Ransomware-Infektion betroffen sind oder waren.

Stellt sich heraus, dass ein Angreifer sich lateral im Netzwerk bewegt, dann ist der erste Impuls oft, ihn so schnell wie möglich des Netzwerks zu verweisen und zeitnah los zu werden. Werden Hinweise auf strafrechtlich relevante Aktivitäten entdeckt, dann müssen entsprechende Beweise auf eine Art gesichert werden, die dem Angreifer keinen Hinweis darauf gibt, dass man ihm auf die Schliche gekommen ist. Schließlich kann man nicht vorhersehen, wie er im Entdeckungsfall reagiert. Schlimmstenfalls versucht er auf dem Weg nach draußen so viel Schaden anzurichten wie möglich. In einem Ziel mit ausreichend hohem Wert ist es auch denkbar, dass der Angreifer versucht, Gegenmaßnahmen aktiv zu sabotieren, was effektive Gegenmaßnahmen verteuert. Einen Eindringling einzukreisen ist daher oft die bessere Strategie.  Incident Responder sind auch geschult in forensischer Beweissicherung. Gerade, wenn Incident Response von einem Ermittlungsverfahren mit Erfolgsaussicht begleitet wird (oder solche auf die Incident Response folgen soll), ist korrekte Beweissicherung von besonderer Wichtigkeit. 

Man kann die Zeit, die ein IR-Dienstleister benötigt, deutlich verkürzen, indem man Recovery- und Failover-Strategien hat und auchgut dokumentierte Assets und Netzwerke. Ist all dies Vorhanden, muss der Dienstleister vielleicht nur eine Person für einen Tag einsetzen, um alles wieder ins Lot zu bringen. Die schlechte Nachricht an dieser Stelle ist, dass kein Notfallplan jemans wirklich "fertig" ist, im Sinne von "Muss nicht mehr verändert werden". Eine Notfallstrategie ist in einem dauerhaften Entwicklungsprozess begriffen und folgt einem regelmäßigen Zyklus aus Neubewertung, Tests und Einbringung von gemachten Erfahrungen.  Das ist keinesfalls eine leichte Aufgabe, wenn man sich die in vielen mittelständischen Unternehmen zur Verfügung stehende Ressourcen vor Augen führt, aber in jedem  Fall "alternativlos", wenn der zu entwickelnde Plan Wirkung zeigen soll.

Zwar ist es bis zu einem gewissen Grad möglich, auch nach oder sogar während eines Zwischenfalls Informationen zu sammeln, allerdings können diese unvollständig oder ungenau sein - in jedem Fall nimmt das Sammeln von Informationen in diesem Kontext Zeit in Anspruch, die effektiver genutzt werden könnte. Daraus ergeben sich wiederum sehr hohe Kosten - die gängigen Preise belaufen sich überlicherweise auf mehrere Tausend Euro pro Manntag. Diese Ausgaben sind verhinderbar, wenn eine wirksame Notfallstrategie besteht. Das Outsourcing von Incident Response ist gerade für kleinere Betriebe sinnvoll, die nicht die Möglichkeiten haben, ein eigenes IR-Team aufzustellen und zu unterhalten. Um die Kosten pro Vorfall gering zu halten, wäre die sinnvollere Alternative,  sich hierfür mit einem auf Incident Response spezialisierten Dienstleister zusammen zu setzen. G DATA bietet über die Advanced Analytics herstellerunabhängige Incident Response-Dienstleistungen an - unabhängig von derzeit eingesetzten Sicherheitslösungen.

Jeder Notfallplan sollte geprobt werden. Diese Probeläufe offenbaren Schwachpunkte und Engpässe, die es im derzeitigen Plan gibt und stärken gleichzeitig das Vertrauen in die Notfallstrategie. Oberstes Ziel ist, von den Erfahrungen aus den Probeläufen zu profitieren und die Dokumentationen entsprechend anzupassen. Um einen Status Quo zu bekommen,  können diese Übungen anfangs auch als reine Planspiele am Schreibtisch stattfinden. Mit fortschreitender Entwicklung kann man diese Pläne dann allmählich auf die Produktivumgebung verlagern, allerdings ohne einen "echten" Angriff. Oft sind Mitarbeiter informiert, dass eine Übung stattfindet und stehen daher "Gewehr bei Fuß". In vielen Fällen finden solche Übungen außerhalb der regulären Bürozeiten statt, sodass niemand im Weg ist und man auf unvohergesehene Vorkommnisse reagieren kann, ohne das Tagesgeschäft zu beeinträchtigen. Die finale Herausforderung, gleichsam die "Feuertaufe" wäre, eine Red-Team-Übung abzuhalten, während der ein "echter" Angriff stattindet. Hier kann sich die geplante Strategie in der Praxis beweisen.
Hierbei sollte man allerdings einige Dinge im Hinterkopf behalten: es sollten so wenig Leute wie möglich über die Übung eingeweiht sein. Und auch, wenn es sich sehr authentisch anfühlt, kann ein Red Team niemals so operieren, wie ein echter Angreifer es würde. Mitglieder des Red Teams sind an ein strenges Regelwerk sowie gesetzliche Vorgaben gebunden. Ein echter Angreifer muss sich hingegen an diese Regeln nicht halten.

Jeder kennt "Murphy's Gesetz". Nach diesem Gesetz tritt ein Notfall immer genau dann ein, wenn es einem gerade an wenigsten passt. Das könnte der Zeitpunkt sein, an dem der Primärkontakt im Betrieb gerade im Urlaub ist, sein Stellvertreter sich krankgemeldet hat und der Dritte in der Hierarchie gerade mit Wartungsarbeiten beschäftigt ist, die weder unterbrochen noch aufgeschoben werden können. Daher sollte für jede Eventualität ein Ausweichplan bestehen. Diese Pläne sollte auch solche Komponenten beinhalten, in denen die reguläre "Befehlskette" umgangen wird, falls ein Glied der Kette einmal fehlen sollte. Den Notfallplan in Gang zu setzen sollte für alle Mitarbeiter der IT möglich sein, ohne dass die Mitarbeiter Repressalien befürchten müssen (ausgenommen natürlich bei vorsätzlichem Missbrauch). Das gilt insbesondere dann, wenn die Alternative darin besteht, gar nichts zu unternehmen.

Ist ein sicherheitsrelevanter Zwischenfall eingetreten und wurde entsprechend behandelt, ist es von entscheidender Bedeutung, sich mit allen Beteiligten hinterher an einen Tisch zu setzen. Das sollte immer geschehen, selbst wenn alles zu 100% nach Plan lief. Die Gelegenheit kann zum Beispiel genutzt  werden, um Mitarbeitern positives Feedback zu geben. Man kann die Wichtigkeit positiven Feedbacks für die Motivation der Mitarbeiter kaum überschätzen. Im Zuge der Nachbereitung sollten auch die Punkte explizit angesprochen werden, die künftig anders gehandhabt werden sollten. Hat der Zwischenfall Schwachstellen im Plan aufgezeigt, dann ist jetzt die Gelegenheit, diese zu erörtern und Änderungen auf den Weg zu bringen. Der Schlüssel ist hier wiederum, aus der Erfahrung zu lernen. Geht jeder nach einem Zwischenfall direkt wieder zur Tagesordnung über, ist das Risiko hoch, dass eine Lektion nicht gelernt und ein eventueller Fehler in der Zukunft wiederholt wird.

• Gestalten Sie den Plan so, dass er so einfach wie möglich umzusetzen ist.
• Jeder im IT-Team sollte die Autoriät haben, den Notfallplan in Gang zu setzen
• Erstellen Sie Ausweich- und Alternativpläne
• Entwicklen Sie eine gute Logging-Strategie
• Behalten Sie immer "das große Ganze" im Blick - selbst etwas vermeintlich unwichtiges kann auf ein größeres Problem hinweisen
• Halten Sie die Notfall-Kommunikationspfade sauber
• Führen Sie Probeläufe durch
• Lernen Sie von jedem Zwischenfall oder Übung und verbessern daraufhin Ihre Strategie
• Arbeiten Sie mit einem auf Incident Response spezialisierten Partner zusammen