Alarmstufe Rot

Sicherheit durch simulierte Angriffe

Auf IT-Sicherheitsvorfälle zu reagieren, fällt vielen Teams schwer, da komplexe Systemlandschaften und Firmenstrukturen zu unklaren Verantwortlichkeiten führen. Um diesem Risiko zu begegnen, bietet es sich an, Cyberangriffe zu simulieren und so zu üben.

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.

Anzeige

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.
 

Fire, Blue Light, Fire Fighting, Car Fire, Fire Fighter

Brände löschen will gelernt sein. Das gilt nicht nur für die Feuerwehr, sondern auch in der IT.

 

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 Mitarbeitercomputer. 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 Mitarbeitercomputer aus: Der Computer des Mitarbeiters, 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 Mitarbeiter 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.
 

Programming, Developing, Startup, Start-Up, Notebooks

Ein Angreifer braucht oft nicht mehr als ein kompromittiertes Endgerät, um schweren Schaden anzurichten.

 

Danach wird der fingierte Angriff gestartet, beispielsweise können weitere Hintertüren installiert werden (entsprechend den Berechtigungen des vermeintlich kompromittierten Mitarbeiters). 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 Mitarbeiters temporär durch HR oder IT deaktiviert wird, bis geklärt ist, wie die Situation ist. Der Rechner des Mitarbeiters 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.

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 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.

 

Bastian

Ike

Technical Director of Cyber Security

AOE

Er ist federführend beteiligt an der Konzeption, Entwicklung und Sicherheitsarchitektur von Enterprise-Projekten wie z. B. für den London Heathrow Airport, die Deutsche Telekom sowie der AOE Marktplatzlösung Omnevo.
Anzeige

Artikel zu diesem Thema

Weitere Artikel

Newsletter
Newsletter Box

Mit Klick auf den Button "Jetzt Anmelden" stimme ich der Datenschutzerklärung zu.