Veränderungen des Incident Response Prozesses in der Cloud?
Die Einführung von Cloud-Technologien bringt Unternehmen nicht nur erhebliche Vorteile, sondern fordert auch Anpassungen der IT-Sicherheitsprinzipien und Prozesse. Die zunehmende Flexibilität, die breitere Netzwerkanbindung und die Nutzung von Ressourcen durch den Einsatz der (Public-)Cloud eröffnen neue Angriffspfade und erfordern eine Überarbeitung der IT-Sicherheitsstrategie. Ein wichtiger Aspekt hierbei ist die Anpassung der Reaktionsmaßnahmen auf Cyberangriffe (Incident Response). Wie verändert sich also der Incident Response Prozess in der Cloud?
Inwieweit sich der Incident Response Prozess verändert, hängt von dem gewählten Cloud-Servicemodell ab. Im Fokus stehen hierbei hauptsächlich die Infrastructure-as-a-Service-Modelle in Public Clouds. Im Vergleich dazu eröffnen Platform-as-a-Service und Software-as-a-Service weniger Konfigurationsmöglichkeiten und limitieren somit die Möglichkeiten für eigene Incident Response Maßnahmen.
Für den Incident Response Prozess bleibt vorweg festzuhalten, dass die Schritte weiterhin dieselben bleiben: Preparation, Detection, Analysis, Containment, Eradiction, Recovery & Post Incident Aktivität.
Preparation
In der Vorbereitungsphase des Incident Response Prozesses ist es wichtig, die Verantwortungsbereiche im Hinblick auf die Cloud genau abzugrenzen (Shared-Responsibility-Modell). Hierbei ist es von entscheidender Bedeutung, die Services des Cloud-Anbieters im Falle eines Incidents zu kennen und zu verstehen, wie man ihn erreicht. Dazu gehören insbesondere die von ihm bereitgestellten Tools und Quellen zur Erhebung von Beweisen (Log-Collection, Imaging, Sammlung von Metadaten). Es ist wichtig, diese im Vorfeld auf ihre Effektivität und Aussagekraft zu testen und gegebenenfalls anzupassen. Ein weiterer wichtiger Schritt ist die Einrichtung von sogenannten Breaking-Glass-Accounts, die Super-Admin-Rechte besitzen und dazu dienen, schnell und effektiv Sicherungsmaßnahmen durchzuführen. Diese Accounts sollten durch eine starke Überwachung und Anmeldeprozedur geschützt werden, um sicherzustellen, dass sie nicht bereits vor dem Incident kompromittiert wurden. Nach diesen Schritten wissen Sie nun, mit welchen Accounts Sie auf welche Beweisquellen zurückgreifen können, wo sich diese befinden und welche Tools Ihnen dabei helfen können.
Detection/Analysis
Der erste Schritt in diesen beiden Phasen eines Incidents in der Cloud besteht darin, sicherzustellen, dass das Management-Interface nicht von Angreifern kompromittiert wurde. Dazu gehört die Überprüfung von Accounts mit privilegierten Zugriffsrechten und gegebenenfalls deren Zurücksetzung. Im Gegensatz zur Analyse von Incidents in On-Premise-Umgebungen unterscheiden sich die Datenquellen in der Cloud erheblich. Hier spielen Logs eine zentrale Rolle, da der Zugriff auf die Infrastruktur zur Durchführung von Sicherungsmaßnahmen von gesamten Images in SaaS-/PaaS-Modellen beschränkt sein kann. Es ist wichtig, Netzwerk-, System-, User- und Adminlogs zu untersuchen, um sich einen ersten Überblick zu verschaffen. Wenn man Zugriff auf die Compute-Instanzen (VMs oder Container) hat, kann es von Vorteil sein, sowohl Memory- als auch Festplatten-Images zu erstellen und zu analysieren. Dies ist jedoch im Gegensatz zu der Analyse von On-Prem-Umgebungen nicht immer der Fall.
Eine Herausforderung bei IR-Maßnahmen in der Cloud ist die Chain-of-Custody für die erhobenen Daten. Durch die Virtualisierung ist es manchmal schwierig zu ermitteln, auf welcher Hardware die Daten tatsächlich gespeichert wurden. Doch das darf Unternehmen nicht davon abhalten, die Analyse-Phase des Incident Response Prozesses durchzuführen. Es gilt schnell zu handeln, indem die Netzwerklogs und Firewallregeln gesichert, die Config-Dateien der Instanzen untersucht werden, um benachbarte betroffene Maschinen zu finden, die die gleiche Config aufweisen und Datenzugriffslogs zu sichern und analysieren. Sobald es Hinweise auf betroffene Accounts gibt, können wir die User-Activity-Logs heranziehen, um genau zu verstehen, was passiert ist. Bei Identifikation der die betroffenen Instanzen, kann in den nächsten Schritt übergegangen werden.
Containment, Eradiction und Recovery
In diesen Schritten verändert sich die Vorgehensweise beim IR grundsätzlich und die Schwächen in punkto Chain-of-Custody werden ausgemerzt. Der zuvor ermittelte Impact des Angriffs, ermöglicht die Abschätzung des Containment-Umfangs. Es kann jetzt begonnen werden alle betroffenen VM-/Container-Instanzen über Firewall-Regeln intern vom restlichen Netz trennen. Dies gelingt durch Software-Defined-Infrastructures und Template-Instanzen fast ohne merkbare Einbußen. Mit wenigen Klicks werden die Instanzen und das bestehende Netzwerk anhand der Templates in sauberem Zustand neu ausgerollt.
Die infizierten Maschinen müssen folglich nicht gelöscht werden, sondern stehen nun zur vollständigen forensischen Analyse bereit. Die dynamische Verlagerung der Arbeitslasten auf die neuen cleanen Instanzen ermöglicht im besten Fall eine kontinuierliche und unterbrechungslose Business Continuity. Und: sie verschafft den Forensikern zudem die Möglichkeit ohne Zeitdruck zu analysieren.
Sofern bei der Analyse Schwächen in der Konfiguration von Compute-Instanzen oder Netzwerk festgestellt werden, sind diese natürlich möglichst zeitnah zu mitigieren, um einen identischen Angriff zu verhindern.
In der letzten Phase des IR-Prozesses (Post-Incident-Activity) sind die durchgeführten Maßnahmen kritisch zu hinterfragen, wodurch festgestellte Schwächen direkt in Änderungen münden können.