Virtuelle Brandbekämpfung: Sind Sie gewappnet?

Sich Gedanken über eine Notfallstrategie zu machen, beinhaltet per definitionem, darüber nachzudenken, was passiert wenn Dinge schieflaufen. Das ist für sich genommen schon unangenehm. Man ist gezwungen, sich aus dem eigenen “Wohlfühlbereich” hinaus zu bewegen. Vor allem in kleineren Betrieben herrscht oft die Denkweise “Uns passiert schon nichts”, ebenso wie “Wir sind doch kein interessantes Ziel”. Andererseits sagt ein Sprichwort, dass es nur zwei Arten von Firmen gibt: diejenigen, die wissen, dass sie gehackt worden sind und die, die es nicht wissen. Zwar bringt einen das nicht unbedingt dem Kern der Sache näher, aber man kann zweifelsohne sagen “Es gibt Firmen, die ausreichend vorbereitet sind und es gibt solche, die es nicht sind“.

Im ersten von zwei Teilen dieses Artikels sprechen wir einige strategische Erwägungen rund um das Thema Incident Response und Incident Readiness an.

In der Praxis hat die Arbeit eines Incident Responders viele Parallelen zur Arbeit der Feuerwehr. Diese werden manchmal mit einer minimalen Menge an Informationen (Feuer in der Musterstraße) in einen Einsatz geschickt. Man erwartet von ihr, dass sie in Rekordzeit ankommt, so wenig Schäden wie möglich verursacht, hinterher keine Verletzten bei Bewohnern und in den eigenen Reihen zu beklagen hat – und dann ist da noch ein Feuer, das gelöscht werden muss. Um dieses Ziel zu erreichen sind Informationen das Wichtigste. Jedes Kind lernt, dass es die folgenden Informationen so gut es geht an den Disponenten weitergeben muss, wenn es die Feuerwehr ruft:

• “Was ist passiert?”
• “Wo ist es passiert?” (An diesem Punkt begeben sich die Besatzungen bereits zu ihren Fahrzeugen)
• “Was brennt?” (z. B. Holz, Chemikalien, Kunststoffe, Metalle, etc)
• “Wie viele Verletzte?”
• “Sind noch Menschen im Gebäude?”
• “Wer meldet den Vorfall?” (Dies ist tatsächlich die am wenigsten wichtige Information)

Eine wesentliche Frage, die beantwortet werden muss, ist: Was sieht ein Betrieb als Risiko an und auf welche Arten von Vorfällen versucht man sich daher vorzubereiten? Ebenso wichtig: welche Szenarien würden einen internen oder externen Angreifer in die Lage versetzen, der Firma Schaden zuzufügen?
Wenn man alle erdenklichen Risiken zugleich anzugehen möchte, so wird das Projekt jedoch unter Umständen so gewaltig, dass es entweder nicht komplett umgesetzt wird oder es wird ganz fallen gelassen, da die Kosten plötzlich aus dem Ruder laufen. Ein Extrembeispiel: Wenn ein Betrieb sein Rechenzentrum sowohl gegen alle Naturkatastrophen als auch menschengemachte Schadensereignisse sichern wollen würde, während gleichzeitig Maßnahmen zur Verteidigung gegen interne sowie externe Angreifer getroffen werden sollen, hätte der Betrieb gleich mehrere Projekte zu stemmen. Jedes einzelne von ihnen ist bereit eine Herausforderung, doch in Kombination wird das Vorhaben unter Umständen so komplex, dass es die zur Verfügung stehenden Ressourcen überbeansprucht. Daher sollte das Augenmerk zuerst auf die Risiken gelenkt werden, die eine unmittelbare Gefahr darstellen für die Daten eines Betriebs sowie dessen Fähigkeit, Produkte oder Dienste anbieten zu können. Zugegeben: Ein Meteoriteneinschlag könnte diesen Effekt ebenfalls hervorrufen – aber abhängig von der Region und unter Berücksichtigung historischer Daten kann dies als ein mögliches, aber unwahrscheinliches Szenario betrachtet werden. Gerade wenn man es mit der Wahrscheinlichkeit vergleicht, dass ein Datenleck oder eine andere Kompromittierung auftritt. Andere Faktoren spielen hier ebenfalls eine Rolle – schließlich haben Angreifer verschiedene Zeile im Sinn, wenn sie ein Unternehmen ins Visier nehmen. Was den Großteil der Angriffe betrifft, sind wir längst über den Punkt hinaus, an dem ein System nur aus reiner Neugier kompromittiert wurde. So ist das vornehmliche Ziel in den meisten Fällen, sich einen strategischen, finanziellen oder taktischen Vorteil zu verschaffen. Man muss hier also die „cui bono?“-Frage stellen: Wer würde davon profitieren, wenn das Unternehmen auf eine bestimmte Art und Weise angegriffen wird?

Wird ein neues Gebäude errichtet, muss vielerorts ein Brandsachverständiger das Gebäude in Augenschein nehmen, bevor er es zur Nutzung freigibt. Ein Brandsachverständiger ist im angloamerikanischen Raum oft jemand, der Erfahrung in der Brandbekämpfung hat; ähnlich sieht es in Deutschland aus. Hier verschwendet man keinen Gedanken ob eine Begehung durch einen Experten sinnvoll ist oder nicht – es ist gesetzlich vorgeschrieben und wird auch so durchgeführt. Dennoch sträuben sich viele Betriebe dagegen, Experten von Außerhalb zuzuziehen, wenn es um die Errichtung oder Umstrukturierung eines Netzwerkes geht. Genau so wie die Feuerwehr einen genauen Lageplan eines Gebäudes benötigt, muss ein Notfallplan auch den genauen Aufbau eines Netzwerkes kennen. Ohne diese Informationen ist es schwierig, effektiv Hilfe zu leisten. Ebenso wird eine Eindämmung eines Schadens erschwert.
Daher benötigt auch ein Netzwerk eine sorgältige Dokumentation, die alle Informationen über die Struktur, Querverbindungen, Abhängigkeiten und kritische Komponenten enthält. Im Notfall muss es möglich sein, bestimmte kritische Bereiche zu isolieren, damit die wichtigsten Dienste nicht ausfallen. In Gebäuden erfüllen Feuerschutztüren und spezielle Wandelemente diese Aufgabe – in einem Netzwerk würden hier VLANs und Firewalls zum Einsatz kommen. Ebenso, wie eine gute Brandschutzplanung für ein Gebäude Schäden verhindern oder zumindest einschränken kann, so ist ein gutes Incident Response-Konzept von großem Wert -  vor allem, wenn es von Anfang an vorhanden und darauf optimiert ist im Schadensfall eine schnelle Wiederherstellbarkeit zu leisten und Ausfallzeiten so kurz wie möglich zu halten. So werden auch die Kosten eines Zwischenfalls drastisch reduziert.

Es ist eine feststehende Tatsache, dass externe Ressourcen Geld kosten. Daher ist es zumindest nachvollziehbar, wenn das Management zögert, Geld bereitszustellen, wenn es darum geht, externe Spezialisten zu beauftragen. Andererseits wäre eine Investition an dieser Stelle durchaus angebracht, statt dies erst nach dem Eintreten des Ernstfalls zu tun. Die Gründe hierfür sind rein praktischer und natürlich finanzieller Natur. Es ist einfach am besten jemanden zu fragen, der genau weiß was ein Incident Responder benötigt. Und derjenige, der diese Information am besten bereitstellen kann, ist nun mal ein Incident Responder. Diese können übrigens auch potenzielle Probleme in einer Netzwerkumgebung aufspüren und bei deren Behebung helfen, ohne dass diese bisher als Problem in Erscheinung getreten sind. Für diesen Prozess müssen alle Beteiligten sich an einen Tisch setzen und Entscheidungen treffen.

Wenngleich das Hinzuziehen eines externen Expertenteams sich wie eine große Investition anhört, bei der das Ergebnis nicht fest steht, wird das Unternehmen auf lange Sicht gesehen Geld sparen. Es ist ganz einfach billiger, im Vorfeld einen Spezialisten zu Rate zu ziehen und die benötigten Informationen zu sammeln, als erst inmitten eines aktuellen Zwischenfalls diesen Schritt zu unternehmen und „on the fly“ einen Plan zu entwickeln. Je nach geografischer Region sind auch Zahlen verfügbar, die den durchschnittlichen finanziellen Schaden pro IT-Fall beziffern. In Deutschland liegt dieser Wert bei ca. 41.000 Euro pro Fall für ein mittelständisches Unternehmen. Mit dieser Informationen in der Hinterhand fällt es unter Umständen leichter, Geldmittel bewilligt zu bekommen, um eine Notfallstrategie auf den Weg zu bringen.

Generell tun Entscheider gut daran, sich von dem “ROI”-Konzept in der IT-Sicherheit zu verabschieden. Hier ist in vielen Köpfen noch die Vorstellung verhaftet, dass die IT im Allgemeinen und die IT-Sicherheit im Besonderen in erster Linie eine Kostenstelle ist und keinen Beitrag zum geschäftlichen Erfolg eines Unternehmens leistet.  Viele Unternehmen sind gehalten, bestimmte gesetzliche und branchenabhängige Standards zu erfüllen. Diese Stellen oft zwar einen gute Grundlage dar, sind aber selten allumfassend und erschöpfend. Zahlreiche Unternehmen unterliegen dann der Versuchung, genau dieses Mindestmaß zu erfüllen – aber auch nicht mehr. Damit ist der Betrieb zwar rechtlich auf der sicheren Seite, aber es gibt noch immer eine nutzbaren Angriffsfläche, die dem Betrieb zum Verhängnis werden kann. Dieser Zwiespalt dürfte auch in den Datenlecks der jüngsten Vergangenheit eine Rolle spielen. Zwar hat man gewisse Standards erfüllt, aber Pannen traten dennoch auf. Anscheinend schließen sich erfüllte Anforderungen und das Auftreten von Datenlecks nicht gegenseitig aus. Die Frage sollte also nicht sein "Wie viel Profit bekommen wir aus dieser Investition?", sondern vielmehr „Wie viel Profit büßen wir im Schadensfall ein, wenn wir die Investition nicht tätigen?" Ein Wort der Warnung sei an dieser Stelle angebracht: Es ist wahrscheinlich, dass man unter Beschuss gerät, wenn es um einen Return on Security Investment (ROSI) geht. Es ist sehr schwer, Argumente zu finden. Vielen Firmen wurden jedoch auf sehr unangenehme Weise deutlich gemacht, dass sie ohne ausreichende IT-Sicherheit unter Umständen vollständig handlungsunfähig werden können. Ein IT-Sicherheitsvorfall kann katastrophale Folgen haben – oder auch nicht. Verlässliche ex ante – Einschätzungen zu geben ist überaus schwierig.

Sich mit dem Thema zu befassen ist auch eine gute Gelegenheit, einen genaueren Blick auf die Netzwerkinfrastruktur und die damit verbundenen Prozesse zu werfen. Vor allem in Netzwerken, die über Jahre „historisch gewachsen“ sind, haben sich unter Umständen Schwachstellen eingeschlichen. Dinge, die einmal als kurzfristige Übergangslösung gedacht waren, werden vielleicht mittlerweile als reguläre Komponenten eingesetzt. Das Worst-Case-Szenario wird hier vielleicht noch nicht einmal durch irgendeinen Angreifer ausgelöst. Ein schneller „Hack“ aus der Vergangenheit kann sich schnell zu einem ausgewachsenen Notfall entwickeln: Man stelle sich vor, ein solcher Fix wurde von jemandem eingebaut, der das Unternehmen bereits vor Jahren verlassen hat. Nun stürzt plötzlich ein kritischer Dienst in unregelmäßigen Abständen ab und niemand weiß, warum. Später stellt sich heraus, dass der damalige Administrator einen Cronjob angelegt hat, der den Dienst einfach wieder gestartet hat, wenn er gerade nicht lief. Das ursächliche Problem wurde also nie behoben, aber um den Betrieb aufrecht zu erhalten, wurde eine schnelle Lösung entwickelt – was auch ganz im Sinne des Unternehmen war. Und plötzlich versagt die Maschine, auf der der Job ihren Dienst geleistet hat. Gelegenheiten wie das Entwicklen eines Notfallplans sollten daher genutzt werden, um solche „quick and dirty“-Lösungen aufzuspüren und zu beseitigen. Dokumentation ist hier das A und O. Stellen Sie sicher, dass, wenn Sie einen solchen alten Hack nicht sofort beseitigen können, er zumindest dokumentiert wird. Falls Testumgebungen oder Datenbanken vorhanden sind, die aus dem Internet zugänglich sind, werfen Sie einen besonders sorgfältigen Blick darauf und  bewerten neu, ob diese Datenbank / dieses Testsystem wirklich exponiert sein muss. Falls ja, stellen Sie sicher, dass alle erforderlichen Sicherungsmaßnahmen getroffen sind. Es wäre nicht das erste Mal, dass eine von außen erreichbare ungesicherte Datenbank für eine Firma der Tropfen war, der das Fass zum Überlaufen brachte. Sollte diese Durchsicht Dinge zutage fördern wie kritische Dienste und vertrauliche Daten, die auf derselben Hardware laufen, die entweder nicht-redundant ist oder gar aus dem Internet erreichbar ist, kann man bereits hier ansetzen und entsprechende Maßnahmen treffen.

Eine andere Frage, die es zu beantworten gilt, dreht sich um das Outsourcen von Teilen des Notfallplans. Hier ein Expertenteam von außen hinzu zu ziehen, ergibt auf mehreren Ebenen Sinn, vor allem in kleinere Betrieben. In solchen Fällen ist es unter Umständen nicht besonders effizient, zusätzliche Kräfte einzustellen, insbesondere wenn es um ausgebiltete Incident Responder handelt. Wenn man darüber nachdenkt dürfte klar sein, warum: Selbst wenn ein ortsansässiger Autohändler sich über Dinge wie einen Notfallplan Gedanken machen muss, käme diese nicht auf die Idee, einen Incident Responder oder einen Malware-Analysten einzustellen, um auf die Eventualität eines Einsatzes zu reagieren. Größere Firmen wiederum brauchen vielleicht aufgrund der Komplexität ein eigenes IR-Team, dem man jedoch auch die Option zugestehen kann, im Bedarfsfalle externe Kräfte hinzu zu ziehen.  

Die Nutzung externer Dienstleister muss in machen Betrieben sehr vorsichtig gehandhabt werden. Werden bestimmte Zuständigkeiten „plötzlich“ nach außen gegeben, kann hier bei den Angestellten der ungerechtfertigte Eindruck entstehen, man wolle die IT gleich ganz auslagern. Daraus kann sich ein gewisser innerer Widerstand oder gar offene Rebellion entwickeln. Es sollte jedoch allen Beteiligten klar sein, dass es bei diesem Projekt nicht darum geht, Leistungen zu bewerten. Es geht vielmehr darum, den Betrieb am Leben zu erhalten, wenn der Ernstfall einmal eintreten sollte. Schließlich werden die Dienste eines Notfallteams nicht täglich gebraucht. Der beste Notfallplan ist und bleibt der Plan, den man nie zur Umsetzung bringen muss. Dennoch sind vielleicht Mitarbeiter versucht, eine „gefilterte“ Version der Realität zu kommunizieren – möglicherweise aus Furcht vor Repressalien aufgrund vermeintlicher Fehlleistungen in der Vergangenheit. Solche „gefilterten“ und unvollständigen Informationen werden jedoch beinahe unausweichlich zum Bumerang.

Der erste Schritt in diesem Gesamtprozess um ein Notfallkonzept kostet nicht die Welt. Sprechen Sie mit anderen und bauen Sie Kontakt zu Experten auf, die mehr Einsicht in das Thema haben, als hausintern vorhanden ist.

Während dieses Prozesses tauchen gerade in der Anfangsphase sehr viele Faktoren auf, die definiert werden wollen: Darunter sind Dinge wie eine Maximal tolerierbare Ausfallzeit (engl. MTD, maximum tolerable downtime) für bestimmte Dienste. Dieses Konzept hat seine Wurzeln im Risikomanagement. Die resultierenden Zahlen haben einen direkten Einfluss auf weitere Schritte innerhalb eines Notfallplans. So ist beispielsiwese in einem Krankenhaus die MTD für das an die Notaufnahme angeschlossene Labor annähernd Null, da hier die Ergebnisse gegebenenfalls innerhalb weniger Minuten vorliegen müssen. Dieser Dienst hat also eine hohe Priorität. Ein Diagnoselabor, das eine onkologische Abteilung bedient, kann dagegen vielleicht mehrere Tage Ausfall verschmerzen. Abteilungen für bildgebende Verfahren können wiederum vielleicht nur wenige Stunden oder ein paar Tage ausfallen, bevor es kritisch wird. Eine solche MTD wird auch von anderen Faktoren beeinflusst: Wie lange kann ein Dienst ausfallen, bevor Verkaufszahlen darunter leiden? Das wiederum hängt davon ab, in welchem Bereich ein Betrieb aktiv ist. So ist es vielleicht kein Problem, wenn ein Webshop-System an einem Dienstag im Juli ausfällt - das kann allerdings in der Vorweihnachtszeit schon wieder ganz anders aussehen. Basierend auf diesen Kriterien kann eine Strategie entwickelt werden. Ebenso wichtig wie das Festlegen von MTDs ist es, wichtige Aktivposten sowie die Infrastruktur des Netzes zu kennen. In dieser Phase tauchen also naturgemäßt sehr viele Fragen auf - Fragen, die eventuell unbequem sind und den Eindruck vermitteln können, die IT-Abteilung sei nachlässig gewesen, was aber in Wirklichkeit nicht den Tatsachen entspricht. Ohne dieses Wissen um kritische Dienste und Infrastrukturen ist jedoch jeder Plan, der auf unvollständigen Informationen basiert, zum Scheitern verurteilt. 
Eine Ransomware-Infektion sorgt im Alltagsbetrieb für eine Menge Chaos und Verwirrung. In vielen modernen Umgebungen existieren kaum noch Ausweichstrategien,  die nicht auf IT-Systemen basieren. Einige Abteilungen haben hingegen vielleicht die Möglichkeit, kurzzeitig auf Papier und Stift zurückzugreifen, damit kritische Dienste zumindest nicht vollends zum Erliegen kommen. Genau dies ist im US-Bundesstaat Ohio geschehen, als eine Ransomware die Systeme einer Notrufzentrale außer Gefecht setzte. Praktisch über Nacht wurden alle Abläufe 25 Jahre in die Vergangenheit katapultiert. In einigen Fällen mögen Papier und Stift eine Option sein, in anderen Fällen jedoch nicht, wie zum Beispiel in einem Warenlager mit chaotischem Lagerungsplan. Die Entwicklung von Ausweichstrategien gehört auf jeden Fall mit dazu, wenn es um die Entwicklung eines Notfallplans geht.

• Identifizieren Sie die Szenarien, auf die der Betrieb sich vorbereiten soll
• Stellen Sie sicher, dass das Management hinter dem Plan steht. Die Chancen dafür sind normalerweise höher, wenn es in jüngster Vergangenheit einen Zwischenfall gab
• Prüfen Sie, ob es ein aktuelles Konzept gibt und ob dieses gegebenenfalls eingegliedert werden kann
  Falls existierende Systeme in die neue Planung einbezogen werden können, dann kann dies Kosten sparen. "Flickschusterei" um der Kosten Willen ist jedoch auch lange Sicht nicht empfehlenswert.
• Bewerten Sie die Daten kritisch, die Sie erhalten. Falls nötig, machen Sie allen klar, dass das Projekt nichts mit der Leistung oder der bisherigen Arbeit der IT zu tun hat
• Holen Sie Angebote mehrerer Anbieter ein, die sich auf Incident Response spezialisiert habe (wie die Tochterfirma G DATA Advanced Analytics). Bauen Sie eine Beziehung zu diesem Dienstleister auf - das spart langfristig sehr viel Zeit.