Kontakt


Wir verwenden HubSpot CRM, um Kontakt- und Informationsanfragen zu bearbeiten und zu verwalten. Bitte akzeptiere die "Funktionalen Cookies" und lade die Seite erneut, um das Kontaktformular zu laden.

Insights / Blog / Cybersecurity

IT Daily: Angriffe simulieren für mehr IT-Sicherheit

23. März 2021
Autor:in Bastian IkeBastian IkeTechnical Director Cybersecurity

Komplexe Systemlandschaften und Firmenstrukturen führen zu unklaren Verantwortlichkeiten – das erschwert das spontane und schnelle reagieren auf IT-Sicherheitsvorfälle. Bastian Ike erklärt, wie Unternehmen durch Simulieren von Cyberangriffen das Risiko minimieren und sich so besser auf den Ernstfall vorbereiten können.

Die beste Planung, die durchdachtesten Prozesse und die optimal aufgestellte Organisation helfen nicht, wenn sie nicht einmal ordentlich erprobt wurden. Eine Erfahrung, die schon viele mit Backup-Systemen machen mussten, die zwar „eigentlich“ immer laufen, im Ernstfall aber versagen, weil eben genau dieser Ernstfall nie getestet wurde. Nicht nur Backups, auch IT-Security und Bereitschaft, auf Angriffe zu reagieren sind wichtige Teile von Business-Continuity Planungen. Um im Ernstfall also nicht kopflos und ungeplant zu reagieren, lohnt es sich, regelmäßig die eigene Bereitschaft zu testen, indem reale Angriffsszenarien simuliert werden. Dabei wird nicht nur die Angst der Beteiligten reduziert, im Ernstfall notwendige Entscheidungen zu treffen, es wird auch sichergestellt, dass Meldeketten eingehalten werden und die zu benachrichtigenden Personen auch wirklich benachrichtigt werden.

Angriff simulieren: Erfolgreiche Umsetzung basiert auf guter Planung

In der Umsetzung stellt sich als erstes die Frage, ob ein solcher Angriff auf einem Test- oder einem Produktionssystem simuliert werden sollte. Für das Produktionssystem spricht, dass ein echter Angriff in der Regel auch auf diesem System passieren würde. Aber es birgt natürlich ein gewisses Risiko, ein Produktivsystem zu manipulieren und mögliche Ausfälle zu riskieren. Die Nutzung des Testsystems lässt allerdings den Beteiligten schnell klar werden, dass es sich um ein simuliertes Szenario handelt. Es ist daher klar zu kommunizieren, dass die Simulation trotzdem mit entsprechender Priorität und Professionalität durchzuführen ist.

Einen Angriff zu simulieren, der einem realistischen Szenario möglichst nahekommt, ist nicht einfach und braucht Eingeweihte und Freigaben zur Durchführung. Im besten Fall wird die Runde so klein wie möglich gehalten, um den Ablauf nicht zu stören und dem Realitätsanspruch Genüge zu tun.

Ein Angriff fängt immer irgendwo mit einer kompromittierten Komponente an. Dies kann eine Backdoor im Produktivsystem sein oder ein kompromittierter Mitarbeitendencomputer. Ausgehend davon wird ein Worst-Case-Szenario skizziert und bis zu einem gewissen Maße auf dem Zielsystem angewendet.

Gehen wir beispielsweise von einem kompromittierten Mitarbeitendencomputer aus: Der Computer des Mitarbeitenden, in diesem Fall ein Laptop, der auch im Homeoffice oder bei der Bereitschaft genutzt wird, wird dabei mit einer Remote-Control-Software ausgestattet und eingeschaltet im Büro „vergessen“. Es ist dabei unerheblich, wie dieser initiale Angriff stattgefunden hat, solange das Szenario halbwegs realistisch ist. Und ein gehackter Laptop ist definitiv denkbar, schließlich bieten auch die besten Antiviren-Programme nur begrenzte Sicherheit.

Somit ergibt sich eine Hintertür, durch die der (simulierte) Angreifer seine Rechte ausweiten und Zugriff auf Unternehmensdaten bekommen kann. Der Mitarbeitende ist an dem Tag offiziell im Urlaub, kann aber (z. B. von Zuhause oder von einem getrennten Büro aus) als Angreifer fungieren und den simulierten Angriff durchführen.

Wird der Test auf dem Produktivsystem simuliert, muss natürlich auf ausreichenden Datenschutz geachtet werden, damit die Kundendaten geschützt bleiben.

Nach dem Test: Post-Mortem-Analyse

Danach wird der fingierte Angriff gestartet, beispielsweise können weitere Hintertüren installiert werden (entsprechend den Berechtigungen des vermeintlich kompromittierten Mitarbeitenden). Es können zum Beispiel Daten heruntergeladen werden oder Konfigurationen und Dienste manipuliert werden. Wie immer gilt: Bei Daten in Produktivsystemen muss natürlich trotzdem auf ausreichenden Datenschutz geachtet werden, es sollen ja am Ende keine Kundendaten versehentlich abhandenkommen.

Auch Commits in interne Sourcecode-Repositories, Downloads von Daten, o. ä. sind Aktivitäten, die Spuren hinterlassen und bei einem realistischen Angriff stattfinden können. Durch den Informationssicherheitsbeauftragten wird dann die Bereitschaft oder das Operations-Team informiert, dass es „verdächtige Aktivitäten“ gibt, sofern diese nicht bereits selbst aktiv geworden sind. Ab jetzt ist es dem Team überlassen, das Szenario „zu Ende zu führen“ und zu signalisieren, sobald der Angriff blockiert und die Systeme wieder hergestellt werden konnten.

Wichtig ist es danach, mit allen Beteiligten eine gemeinsame Post-Mortem-Analyse durchzuführen, den Angriff detailliert zu beschreiben und getroffene Maßnahmen zu besprechen. Wie bei jedem Post-Mortem gilt es, hier nicht nach Fehlern zu suchen, sondern sowohl den Post-Mortem-Prozess proaktiv zu verbessern als auch gemeinsam die Übung zu reflektieren und an den daraus gewonnenen Erfahrungen als Team zu wachsen. Die getroffenen Maßnahmen werden abgeglichen mit der Liste der Angriffe und es wird gemeinsam besprochen, ob und wie diese Maßnahmen die Bedrohungssituation entschärft haben.

Es kann durchaus erwartet werden, dass im Zuge der Simulation der Account des Mitarbeitenden temporär durch HR oder IT deaktiviert wird, bis geklärt ist, wie die Situation ist. Der Rechner des Mitarbeitenden sollte, um zu prüfen, ob und wie dieser als Einfallstor genutzt wurde, als Beweis gesichert werden. Auf den angegriffenen Zielsystemen müssen alle Hintertüren und Modifikationen gefunden werden.

Beim Post-Mortem geht es nicht um Fehlersuche, sondern darum, den Prozess und die Übung zu reflektieren und proaktiv zu verbessern und an den daraus gewonnenen Erfahrungen als Team zu wachsen.

Das Ergebnis: Bessere Kommunikation, Routine & Aufdecken von Schwachstellen

Ergebnis einer solchen Simulation ist in der Regel ein Maßnahmenkatalog zur Verbesserung der Kommunikation, Herangehensweise und gegebenenfalls auch die Aufdeckung möglicher Sicherheitslücken oder Schwachstellen, die im Rahmen der Simulation aufgetreten sind. Auch führt diese praktische Erfahrung dazu, dass Mitarbeiter:innen nun genau wissen, wie im Ernstfall reagiert werden muss.

Kommunikation und Verantwortlichkeiten werden geklärt und die Hemmschwelle, eine kritische Entscheidung zu treffen, wird gesenkt. Das Ergebnis ist ein weitaus professioneller auftretendes Team, welches gestärkt aus der Übung herausgehen sollte und künftig im Notfall weiß, welche konkreten Maßnahmen zu ergreifen sind.

Dieser Artikel ist zuerst im IT-Management-Magazin "IT-Daily" erschienen. Wir freuen uns über Ihr Feedback und das Teilen des Artikels.

Originalbeitrag auf IT-Daily.net