Interview Teil 2: Incident Response in der OT – lieber kontrollierbare Vorfälle statt Krisen! 

Trotz guter Security-Konzepte werden Cyberkriminelle immer Wege ins Anlagennetz hineinfinden. Supply Chains werden weiter vernetzt, neue Technologien halten Einzug in die Automation und immer mehr Schnittstellen erhöhen die Komplexität. Damit nehmen auch die Angriffsvektoren permanent zu. Für viele Unternehmen stellt sich kaum mehr die Frage, ob die eigene Organisation einmal von einem Security-Vorfall betroffen sein wird, sondern nur wann. Und wie gut man darauf vorbereitet ist: Incident Response in der OT beginnt lange vor einem Vorfall!

Uwe Grams und Vincent Rockenfeld von der RapidResponse GmbH haben mir bei einem Interview Einblicke in die Praxis der Incident Response gewährt. Im ersten Teil unseres Gespräches geht es um die Frage, wie eine professionelle Krisenreaktion abläuft, wenn es zu einem Vorfall gekommen ist.  

Im zweiten Teil steht die Vorbereitung im Fokus. Was sollten Unternehmen im Vorfeld tun, damit sie bestmöglich auf einen Vorfall reagieren können und die Folgen beherrschbar bleiben?

Max Weidele: Was müssen Unternehmen tun, damit es bei Vorfällen bleibt und keine Krisen entstehen? 

Uwe Grams: Eine gute Vorbereitung und Prävention sind entscheidend, um im Ernstfall richtig und schnell reagieren zu können. Bei einem Vorfall versuchst Du, in allen Themen möglichst schnell mit den Dir zur Verfügung stehenden Mitteln arbeitsfähig und effektiv zu werden. Wir müssen schnell die IT-Umgebung und das Ausmaß verstehen, die IT-Forensik zügig vorantreiben. Weiterhin müssen wir verstehen, welche IT-Prozesse und Security-Mechanismen das Unternehmen hatte und welche wir schnell wieder aufbauen können. Dafür ist es wichtig, dass ein Unternehmen vorbereitet ist, vorhandene Pläne mitliefern kann, eine etablierte Kommunikation mit ihren Mitarbeitern oder anderen Standorten nutzen kann. 

Letztendlich geht es bei einem Incident primär um den Faktor Zeit. Es gibt verschiedene Phasen bei der Bewältigung. Wir haben eine Grafik mitgebracht, die zeigt den Verlauf, mit dem ein Unternehmen normalerweise einen Incident bewältigt: 

Ich beschreibe mal den Ablauf: Nehmen wir einen Ransomware-Angriff, das Unternehmen wird verschlüsselt. Bis man das merkt und einen Dienstleister anruft, vergeht normalerweise etwas Zeit. Nach den ersten Abstimmungen und der Anreise kommen wir dann idealerweise im Verlauf des ersten Tages dazu. Im Unternehmen ist in der Regel Chaos. Es gibt erstmal keine Struktur, der Kunde weiß nicht, was genau passiert ist und welcher Schaden angerichtet wurde. Wir müssen einen Stab aufbauen und Struktur in die IT reinbringen. Am Anfang nennt man das klassisch „die Chaosphase“. Bis man sich hier richtig konstituiert hat, dauert diese Phase beispielsweise bei einem Ransomware-Angriff vier bis sechs Tage. Der Kunde braucht in der Regel so lange, weil ein Cyberangriff in dem Umfang nie trainiert wurde.  

Danach kommt die Konstituierungsphase, in der die einzelnen Beteiligten wissen, was sie zu tun haben, wer in welchen Gremien arbeitet, wie in der neuen Arbeitsphase gearbeitet wird und welche Boardmittel im Notbetrieb zur Verfügung stehen. Es gibt zum Beispiel einen Laptop, mit dem man E-Mails schreiben kann, man kann sich gegenseitig erreichen. Diese Phase dauert so lange, bis ein stabiler Notbetrieb erreicht ist, in der Regel drei bis zehn Tage.  

Dann kommt die Notbetriebsphase. Dafür eine genaue Zeit anzugeben, ist stark von den jeweiligen Faktoren abhängig. Bei einem mittelständischen Unternehmen mit einer durchschnittlichen IT-Umgebung dauert diese Phase aus unserer Erfahrung bis zu vier Wochen. Dann hat man einen Zustand erreicht, in dem die Auswirkungen des Incidents für den Kunden nicht mehr so spürbar sind. Dies bedeutet nicht, dass alle Prozesse wieder auf ihrer hundertprozentigen Leistungsfähigkeit sind. Da fehlt auch noch vieles, aber es funktioniert. Ich kann als Unternehmen damit leben und auch die anderen Partner und Kunden können damit leben. Um die Krise zu überstehen, muss man in der Regel mit vier bis sechs Wochen rechnen, aber halt schon mit professioneller Begleitung.  

Und dann dauert es, bis das Unternehmen irgendwann zurück in den Normalbetrieb kommt. 

Max Weidele: Das war jetzt der Standardfall, richtig? Gehen wir mal tiefer auf das Thema Vorbereitung ein: Was gehört alles zu einer guten Vorbereitung und wieviel Zeit kann man damit im Ernstfall sparen?

Uwe Grams: Ja, die Grafik zeigt einen Standardfall mit externer Unterstützung. Wir wollen schnell durch einen Incident kommen. Eine gute Vorbereitung beschleunigt die Bewältigung, wir kommen schneller durch die einzelnen Phasen. Gut vorbereitet kann ein Unternehmen es schaffen, in der Chaosphase ein oder zwei Tage zu sparen. Das ist gewaltig! Wenn ich am Anfang viel Zeit spare, die Chaosphase verkürze, dann komme ich vor die Lage. Ich kann vielleicht noch Daten retten, ich mache weniger Dinge falsch, ich habe weniger Ermüdungserscheinungen. Wenn ich gut vorbereitet bin und mein Business Continuity Management im Griff habe, dann komme ich schneller in die Struktur und mein Notbetrieb kann schon nach drei, vier Tagen aufgebaut sein. Das ist ein riesiger Zeitgewinn und spart enorm viel Stress, Geld und Reputation! 

Vincent Rockenfeld: Auch bei der Prävention gibt es wieder die Business-Sicht und die IT-Sicht. Man kann auf der IT-Seite gewisse Vorbereitungen treffen, zum Beispiel eine Datensicherung. Wenn ich meine Daten offline gesichert habe und ein geeignetes und getestetes Wiederanlaufverfahren habe, dann kann mir bei einem Ransomware-Angriff nicht viel passieren. In einem solchen Fall spiele ich die Daten wieder ein und dann bin ich zumindest wieder arbeitsfähig. Auch wenn trotzdem noch ein paar Nacharbeiten im Zuge der IT-Sicherheit erforderlich sind. 

Uwe Grams: Eine gute Vorbereitung im Business-Bereich ist, wenn die Mitglieder eines Notfallstabs schon mal festgelegt und im Unternehmen auch bekannt sind. Diese Personen haben vielleicht die Bewältigungsfähigkeit auch schon einmal geübt. Und die Produktion hat idealerweise schon Workarounds und manuelle Prozesse definiert, für den Fall, dass die Maschinen ausfallen. Wenn an meiner Maschine der Produktionsplan für die laufende und die kommende Woche hängt, habe ich mindestens eine Woche im Forecast. Ich weiß, was ich produzieren muss, und ich weiß, was ich wo in meinem Lager finde. Wenn es mich am Freitagabend trifft, habe ich die nächste Woche vorgedacht. Ich habe eine Woche lang Zeit, um notwendige Dinge zu tun, damit es dann wieder weitergeht. Die Produktion fällt gar nicht auf null.  

Die Kurve der Leistungsfähigkeit bei dem, der sich nicht vorbereitet hat, fällt massiv ab, nahezu auf null. Bei dem, der sich vorbereitet hat, rumpelt das zwar, aber dann läuft das weiter. Und manchmal merkt der Kunde des Unternehmens davon nicht mal etwas. 

Und das gehört halt auch zur Vorbereitung: Ich will nicht im Ernstfall loslaufen und mir den Erstbesten suchen, der mich professionell unterstützt. Idealerweise hat ein betroffenes Unternehmen einen kompetenten Dienstleister, der sich um das gesamte Spektrum der Incident Response kümmert. Dann können Synergieeffekte zwischen Business und IT greifen. Und am besten hat man mit diesem Dienstleister vorher schon mal gesprochen. 

Max Weidele: Wie spielen Krisenmanagement des Unternehmens und Incident-Response-Dienstleister zusammen? Was macht nach Eurer Meinung einen guten Incident Response Dienstleister aus?

Uwe Grams: Wichtig ist das Skill-Level, aber auch, dass die Leute gut zusammenarbeiten. Wenn es beispielsweise um Kommunikationsmeldungen nach außen geht, ist es für den Krisenstab herausfordernd, die IT-forensische Lage korrekt zu verstehen. Und einem IT-Forensiker hilft es, wenn er Elemente einer Visualisierung mit an die Hand bekommt, wenn zum Beispiel Verläufe darzustellen sind. Ein guter Incident-Response-Dienstleister unterstützt und ergänzt auch dabei. 

Vincent Rockenfeld: In der Incident Response unterscheidet sich das Vorgehen je nachdem, um welche Art von Angriff es sich handelt. Bei den Angreifergruppen, die klassischerweise Ransomware & Co einsetzen, gibt es ein Standard-Vorgehen bei der Incident Response: Ich versuche, den Angriff zu mitigieren und das Unternehmen mit einem Notbetriebsprozess schnell wieder zum Laufen zu bringen. Bei staatlichen Angreifern ist das ein komplett anderes Vorgehen. Man muss davon ausgehen, dass der Angreifer schon länger im Netz ist, sich dort gut auskennt und verwurzelt ist. Da muss man sehr vorsichtig vorgehen. Der Angreifer darf nicht mitbekommen, dass ich  Threat Hunting betreibe und versuche, ihn zu beobachten, damit ich zu einem geeigneten Zeitpunkt auf einen Schlag erfolgreich Aussperrmaßnahmen umsetzen kann. Es gibt für solche Angreifer eine ganze Reihe an High Value Targets, zum Beispiel wenn es um Wirtschaftsspionage geht. Oder Targets, an die Angreifer im Rahmen einer Supply-Chain-Attacke rankommen wollen. Da spielen neben den Kritischen Infrastrukturen selbst auch deren Zulieferer und Dienstleister eine Rolle. 

Um einen passenden Incident-Response-Dienstleister für sich zu finden, sollte ein Unternehmen einschätzen, zu welcher Zielgruppe es für Angreifer gehört. Dementsprechende Kompetenzen sollte der Incident-Response-Dienstleister mitbringen. Der nächste Dienstleister um die Ecke hat vielleicht nur Know-how für das Standardvorgehen. Kriterien wie die physische Distanz sollten da nicht entscheidend sein. 

Im Einsatz, also im Schadensfall, ist es grundsätzlich wichtig, dass es vor Ort ein eingespieltes Team gibt, das möglichst schon öfter zusammengearbeitet hat. Es muss ein guter Austausch stattfinden. Man hat keine Zeit, man sollte mit seinem Werkzeug umgehen können und man darf keine Fehler machen. 

Max Weidele: Hilft es, wenn der Incident-Response-Dienstleister, mit dem ich schon zusammenarbeite, zum Beispiel im Rahmen eines Wartungsvertrages, Zugriff auf bestimmte Unterlagen hat? Kann man so im Ernstfall schneller reagieren? 

Vincent Rockenfeld: Damit man als Dienstleister auch die richtigen Empfehlungen für das weitere Vorgehen aussprechen kann, muss man die aktuelle Lage und das Umfeld verstehen. Man spart gerade am Anfang wertvolle Zeit, wenn man seinen Incident-Response-Dienstleister schon kennt, und zwar nicht nur, weil das Unternehmen weiß, wen es anrufen und hoffentlich auch erreichen kann. Der Dienstleister kennt dann nämlich schon die Infrastruktur und die Organisation des Unternehmens und kann zum Beispiel bei Bedarf auch andere Standorte in die Betrachtung einbeziehen.

Vieles fällt ja in der stressigen Situation beim Kunden auch mal runter und man erfährt erst im Verlauf von einem zweiten E-Mail-Server oder von einem Standort sonstwo. Hätte man das gleich gewusst, hätte man einen besonderen Fokus auf gewisse Dinge legen können. Wir können effektiver und schneller arbeiten, wenn wir alle relevanten Informationen im Vorhinein haben. Dann wissen wir genau, wer der Kunde ist, was er macht, wir haben vielleicht schon einen Netzplan und Informationen über die Produktion, über Standorte etc. Das macht einen großen Unterschied. 

Aber: Wichtige Unterlagen müssen an einer Stelle liegen, die garantiert nicht von der Krise betroffen ist. Der Dienstleister muss zwar im Schadensfall auf Informationen zugreifen können, und zwar auf möglichst aktuelle, aber es müssen auch Sicherheitsanforderungen berücksichtigt werden. Ich möchte als Dienstleister keinen Sofortzugriff in die Kundenumgebung haben, einfach deswegen, weil auch ich betroffen sein kann! Dieses Risiko haben viele Unternehmen gar nicht auf dem Schirm. Im Schadensfall macht es Sinn, wenn bereits entsprechende Notfall-Accounts innerhalb der Infrastruktur eingerichtet sind. Die Zugangsdaten sind am besten ausgedruckt und liegen zum Beispiel im Tresor beim Kunden und sind im Notfall verfügbar. 

Max Weidele: Zum Schluss würde ich gern wissen, was für Euch die Top 3-Themen sind, die Unternehmen beim Thema Incident Response beachten sollten. 

Uwe Grams: Punkt eins: Man muss jemanden als Incident-Response-Dienstleister haben, dem man vertraut und der möglichst gut abdeckt, was das Unternehmen im Schadensfall braucht. Ein Unternehmen sollte wissen, wen man im Notfall kontaktiert und was der Dienstleister kann. Ein guter Incident Responder muss qualifiziert sein, um die richtigen Erstmaßnahmen zu geben. Er muss gut zuhören und wissen, wie es weitergeht. Das betroffene Unternehmen hat schließlich keine Erfahrung mit der Situation, wie sie im Notfall ist. Und weil man dann in gewisser Weise einem Dienstleister ausgeliefert ist, sollte man sich den gut ausgesucht haben. 

Das zweite Thema ist die Kommunikation zwischen IT-Welt und Business-Welt. Das sind im Grunde unterschiedlich tickende Menschen, die müssen mal miteinander reden! Es geht darum, zu verstehen, und zwar aus beiden Sichten heraus, was der andere wirklich braucht, wo die Grenzen sind und wo es zu einer Überforderung kommt. Wir merken häufig, dass die IT nicht einmal innerhalb der Geschäftsführung verortet ist. Es wird oft versucht, über Druck von oben voranzutreiben. Das funktioniert nicht. Die beiden sollen vorher miteinander reden, auf Augenhöhe und zum Beispiel in einer Übung herausfinden, was funktioniert und was nicht. Das ist ein großer Gamechanger. 

Vincent Rockenfeld: Das dritte Thema kommt aus der Technik heraus und es wird oft mega vernachlässigt. Das ist die Sichtbarkeit, Security Monitoring, innerhalb der IT und der OT. Oft stellt man fest, dass man zeitnah hätte reagieren können, und es nicht zu einer Krise gekommen wäre, wenn man durch Logging und Monitoring Auffälligkeiten mitbekommen hätte. Wenn man sieht, dass komische Dinge passieren, dass sich Angreifer im Netzwerk umschauen, Scans machen, dann kann man darauf reagieren, bevor die Umgebung verschlüsselt wird. Sichtbarkeit ist ein ganz wichtiger Teil der Sicherheit. 

Zur notwendigen Kommunikation von Business und IT, die Uwe schon genannt hat, würde ich noch Folgendes ergänzen: In der Business-Perspektive muss man sich Gedanken um IT-Abhängigkeiten machen. Also konkret: Bei welchen Prozessen im Unternehmen spielt IT eine wichtige Rolle und mit welchen Workarounds könnten diese Prozesse auch ohne IT funktionieren. Man muss die Abhängigkeit des eigenen Business in Bezug auf IT verstehen. Das gehört auch zur IT-Sicherheit. 

Max Weidele: Ein gutes Schlusswort! Vielen Dank an Euch beide für die interessanten Einblicke.