fotografiche.eu - Fotolia
Einen AWS Incident Response Plan in vier Schritten entwerfen
Trotz aller Security-Vorkehrungen dringen Hacker immer noch in die sichersten AWS-Systeme ein. AWS-Anwender sollten daher einen Incident Response Plan haben.
Trotz aller Bemühungen der IT-Abteilungen finden Hacker immer noch Wege, auch in die sichersten Systeme von Amazon Web Services (AWS) einzudringen. Daher ist es wichtig, einen Incident Response Plan (IRP) zu entwerfen. Mit Incidents sind dabei Vor- oder Störfälle gemeint, die sich bei unangemessenen Reaktionen zu einem Desaster entwickeln können. Incident Response Pläne firmieren gelegentlich auch unter der Bezeichnung Notfall-Management-Pläne.
Eines der schlimmsten Dinge, die ein Unternehmen bei Störfällen tun kann, ist, infizierte Systeme einfach mit einer älteren Version der Anwendung zu aktualisieren, die angeblich sicher ist. Diese unangemessene Reaktion kann das Problem aufrechterhalten, wertvolle Beweise löschen, die Ursache verschleiern und die Hacker alarmieren. Letztere könnten dann Maßnahmen ergreifen, um ihre Spuren zu verbergen.
Ein Incident Response Plan hilft, so etwas zu verhindern. Mit einem Incident Response Plan sollen die betrieblichen und finanziellen Auswirkungen eines möglichen Angriffs minimiert werden. Zudem soll damit gewährleistet sein, dass man die eigentliche Ursache richtig angeht.
Die Umsetzung eines AWS Incident Response Plans sollte – auf einem abstrakten Level – in vier Schritten erfolgen:
- Versuchen Sie, einen möglichen Vorfall gemeinsam zu verstehen.
- Entwickeln Sie einen Prozess zur schnellen und automatischen Erfassung aller Daten, die für den Vorfall relevant sind.
- Nehmen Sie zu einem Sicherheitsforensik-Team Kontakt auf und übergeben Sie diesem alle relevanten Dokumente.
- Führen Sie den Plan testweise aus, um Lücken zu erkennen und Ängste abzubauen, sollte ein echtes Problem auftreten.
Lassen Sie uns jeden dieser Schritte näher betrachten.
1. Sensibilisieren Sie für mögliche Security-Vorfälle
Ein Unternehmen kann auf verschiedene Weise auf einen Sicherheitsvorfall aufmerksam gemacht werden. Es kann eine Warnung von AWS erhalten, seine AWS-Anmeldeinformationen oder andere Daten im Dark Web entdecken oder von einem Partner eine Benachrichtigung über ungewöhnliche Aktivitäten erhalten. Im Idealfall wird Ihr Unternehmen solch subtilen Anomalien genügend Aufmerksamkeit schenken – je nachdem, wie normalerweise eine Anwendung konfiguriert, ausgeführt und auf sie zugegriffen wird. So lassen sich Probleme entdecken, bevor für Sie nachteilige Aktionen stattfinden.
Um solche Anomalien zu erkennen, sollten Sie Amazon CloudWatch Alerts als Frühwarnsystem einrichten. Mit dem Warnsystem können Sie nach Spitzen bei den Nutzungsentgelten suchen. Die Ursache kann, neben schlechten Codierungspraktiken oder einem unvorhergesehenen Anstieg bei den Services, ein Eindringen über kompromittierte Sicherheitsvorkehrungen sein.
Das Identifizieren solcher Anomalien kann bei der Früherkennung eines Vorfalls helfen. Allerdings können diese Ihr Team auch mit Falschmeldungen überschütten, was dazu führt, dass Anzeichen einer echten Bedrohung nicht weiterverfolgt werden. Doch das sollte Sie nicht abhalten: Richten Sie auf jeden Fall einen Prozess ein, um beobachtete Anomalien an ein qualifiziertes Sicherheitsteam weiterzugeben. Dieses kann dann feststellen, ob ein kritischer Vorfall besteht oder nicht.
2. Erfassen Sie alles
Ein AWS Incident Response Plan muss Verfahren beschreiben, um schnell, automatisch, ruhig und sicher alles zu erfassen, was für eine Lösung relevant sein könnte. Erfassen Sie also alle zugehörigen API-Aufrufe, Konfigurationsänderungen, laufenden Anwendungsdaten, nichtflüchtigen Speicher- und TCP-Daten.
Automatisieren Sie diesen Prozess so weit wie möglich, da IT-Profis während einer Krise bei manueller Vorgehensweise häufiger Fehler machen. Gehen Sie möglichst dezent und geräuscharm vor, so dass Hacker nicht versuchen, ihre Spuren zu verwischen. Speichern Sie forensische Daten außerhalb der Kontrolle operativer Zugangsdaten, um Hackern das Ändern oder Löschen zu erschweren.
AWS CloudTrail kann automatisch API-Aufrufdaten von der AWS Management Console, dem Command Line Interface (CLI) oder dem Software Development Kit (SDK) erfassen. Dieses Protokoll hilft forensischen Ermittlern, Angreifer zu verfolgen, nachdem sie Zugang zu einem System erhalten haben. Es kann auch eine gute Idee sein, einen Alarm für unerwartete Steigerungen bei API-Aufrufen einzurichten.
AWS Config kann ein Änderungsprotokoll der AWS-Ressourcenkonfiguration nach einem Vorfall erstellen. Dies kann Ihnen helfen, ein Netzwerkdiagramm anzufertigen, in dem das Anlegen, Löschen und Ändern von Ressourcen angezeigt wird. Zusätzlich kann AWS Config Rules den Status der aktuellen Konfigurationen automatisch mit einer vordefinierten Konfigurationsdatei vergleichen. Sollten Abweichungen auftreten, kann es Warnmeldungen generieren. Mit diesen Alarmen können Sie Lambda-Funktionen auslösen und damit Fehlkonfigurationen automatisch beheben.
Darüber hinaus enthält AWS Identify and Access Management eine Access-Advisor-Funktion, die Dienste protokolliert, auf die ein bestimmtes Konto zugreifen. Das kann nützlich sein, um gefährdete Anmeldeinformationen im Zusammenhang mit einem Vorfall zu identifizieren.
Sie können auch den Befehl create-snapshot verwenden, um einen Snapshot einer laufenden EC2-Instanz zu erstellen. Speichern Sie diesen dann in S3, wo nur andere Zugangsberechtigte ihn löschen können. Ein Snapshot kopiert im Wesentlichen alle Daten, die auf der virtuellen Festplatte einer EC2-Instanz laufen. Wenn die Instanz jedoch von einem S3-Bucket aus läuft, ist es wichtig, auch diese S3-Daten sicher zu duplizieren.
Erfassen Sie außerdem den Speicherinhalt einer EC2-Instanz, die mit einem Vorfall verbunden ist. Der Inhalt würde ansonsten automatisch verschwinden, wenn die Instanz beendet wird. Dies ist für Windows-Instanzen relativ einfach, da die meisten Windows Memory Dump Tools keine Auswirkungen auf laufende Anwendungen haben.
Schwieriger kann es sein, den Speicherinhalt von laufenden Linux-Containern zu erfassen, da die Memory Capture Tools manchmal laufende Anwendungen beschädigen können. Testen Sie diese Tools mit den gleichen Anwendungen in einer Testumgebung, bevor Sie diese auf Live-Systemen verwenden – das heißt, bis Sie einen Weg gefunden haben, den Speicherinhalt sicher zu erfassen.
Ein Protokoll der TCP-Kommunikation zu und von einem EC2-Server kann ebenfalls von unschätzbarem Wert sein. Es ermöglicht Ihnen, zu verstehen, wie ein Angreifer arbeitet. Um Paketdaten zu erfassen, können IT-Mitarbeiter den tcpdump-Paketanalysator, der in Linux integriert ist, ausführen. Unter Windows ist WinDump zuständig.
3. Leiten Sie die Daten weiter an die Forensik
Sobald das IT-Team eine potenzielle Bedrohung erkannt hat, sollte es in der Regel den Prozess der Datenerfassung initiieren. Diese Daten müssen anschließend zur Analyse an Experten weitergereicht werden.
Jeder AWS Incident Response Plan muss deshalb einen Prozess beinhalten, um diese Informationen an ein erfahrenes forensisches Team weiterzugeben. Das Experten-Team analysiert die Daten, identifiziert die Ursache des Problems und schlägt einen Prozess zur Behebung des Schadens vor.
4. Testen und üben Sie
Ihr Team sollte auch die Abwicklung eines AWS Incident Response Plans üben. Dazu sollte auch das Sammeln und Zusammenstellen der Vorfallsdaten für das forensische Team gehören. Dies hilft dem forensischen Team, die Art und Weise, wie diese Daten erfasst werden, zu bewerten und erleichtert die schnelle Analyse der Daten mit bevorzugten Tools und Verfahren.
Folgen Sie SearchDataCenter.de auch auf Twitter, Google+, Xing und Facebook!
