Sie wissen mittlerweile, was für Cloud Assets Sie besitzen und haben vernünftige Sicherheitsvorkehrungen eingerichtet, um diese zu schützen. Jetzt ist alles gut, oder?
Wenn Sie in einem Krimi zwei Drittel der Seiten gelesen haben und das Rätsel aufgeklärt zu sein scheint, wissen Sie, dass die Geschichte noch nicht vorbei ist. Daher wird es Sie nicht allzu sehr überraschen, dass die Cloud-Sicherheit auch noch nicht abgeschlossen ist, da dieses Buch ja noch nicht zu Ende ist.
All die bisherigen Kapitel haben sich darum gedreht, Ihre Assets zu identifizieren und zu schützen. Leider werden Sie nicht immer erfolgreich sein. Tatsächlich sind in manchen Branchen und Organisationen kleinere Sicherheitsvorfälle an der Tagesordnung! Irgendwann werden Angreifer mit großer Sicherheit versuchen, unautorisierten Zugriff auf Ihre Assets zu erhalten – manchmal erfolgreich. In dem Fall ist es entscheidend, dies so schnell wie möglich zu erkennen, sie herauszuschmeißen und alles Notwendige zu tun, um den Schaden zu begrenzen. Als Teil davon ist es hilfreich, zu verstehen, was bei Angriffen häufig geschieht und wie vorgegangen wird.
Wir haben in den letzten paar Jahren viele Einbrüche erlebt, die Aufmerksamkeit erregt haben. Ein schlechter Einbruch unterscheidet sich von einem sehr schlechten Einbruch – es gibt keine guten Einbrüche – darin, wie lange es dauert, bis er entdeckt wird, und wie effektiv das Opfer reagiert. Eine aktuelle Studie zu mehr als 550 Organisationen (https://oreil.ly/sQIQR) hat gezeigt, dass die mittlere Dauer, bis ein Einbruch entdeckt wurde, bei 277 Tagen lag, und dass Firmen, die einen Einbruch in weniger als 200 Tagen entdeckten, im Vergleich zu denen, die mehr als 200 Tage brauchten, mehr als eine Million US-Dollar eingespart haben. Mit diesen Daten im Hinterkopf wollen wir uns anschauen, was wir tun können, um Probleme zu entdecken und darauf zu reagieren, bevor sie zu Desastern werden.
MITRE ATT&CK und Kill Chains
Es gibt viele Ressourcen, die zu beschreiben versuchen, was ein Angreifer eventuell tut. Aktuell sind die beliebtesten das MITRE ATT&CK Framework (https://oreil.ly/1LnrI) und die Lockheed Martin Cyber Kill Chain (https://oreil.ly/lugUE), aber es gibt auch noch andere, wie zum Beispiel die Unified Kill Chain (https://oreil.ly/kfx0z).
MITRE ATT&CK ist im Allgemeinen detaillierter als die Kill Chains und stellt unterschiedliche Taktiken, Techniken und Prozeduren (TTPs) vor, die bei einem Angriff in seinen unterschiedlichen Phasen und in verschiedenen Computing-Umgebungen genutzt werden könnten.
Die Kill Chains geben eher einen Überblick, sie führen die gebräuchlichsten Schritte in der Reihenfolge auf, in der sie bei einem Angriff zum Einsatz kommen, wie zum Beispiel Erkundung, Bewaffnung, Ausführung, Verwertung, Installation, Command and Control sowie Ausrichtung auf Ziele.
Ich empfehle Ihnen, dass sich Ihr Incident Response Team mindestens ein Kill-Chain-Modell durchliest und nachvollzieht und dazu noch einige der TTPs in der MITRE-ATT&CK-Cloud-Matrix. Zu verstehen, was Angreifer vermutlich tun werden, hilft bei der Reaktion auf einen aktiven Angriff. Wir werden uns weiter unten im Kapitel noch ein Beispiel dazu anschauen.
Schauen Sie sich noch mal in Kapitel 1 das Diagramm mit dem Shared Responsibility Model an (siehe Abbildung 1-8).
In einer klassischen Umgebung mussten Sie sich darüber Gedanken machen, was auf jeder dieser Ebenen geschehen ist. In Cloud-Umgebungen sind Intrusion Detection and Response zum Glück dort Aufgabe des Providers, wo er zuständig ist. Sie werden nur sehr selten von einem Einbruch bei Ihrem Provider betroffen sein, sollten dann aber auch benachrichtigt werden und müssen eventuell reagieren und für Ihren Service Dinge wiederherstellen. Aber in einem Großteil der Fälle werden all Ihre Aktivitäten rund um Erkennen, Reagieren und Wiederherstellen in den Bereichen stattfinden, die mit »Verantwortung Kunde« markiert sind.
Meist erhalten Sie keinerlei Logs für die Bereiche, für die der Provider zuständig ist, auch wenn Sie manchmal Aktivitäten bemerken, die er für Sie angestoßen hat, wie zum Beispiel das Zuweisen neuer Schlüssel. Es gibt aber in einer Cloud-Umgebung eine wichtige neue Quelle für Logs privilegierter User: Sie können Dinge verfolgen, die Ihr Team über die Portale, APIs und die Befehlszeilenschnittstelle des Providers vorgenommen hat.
In einer Cloud-Umgebung werden Sie die physische Hardware nicht anfassen dürfen. Viele Incident Response Teams nutzen einen »Jump Bag« mit forensischen Laptops, Hard-Drive-Duplikatoren und anderer ähnlicher Technologie. Auch wenn Sie vielleicht solche Tools für den Umgang mit Vorfällen bei der Infrastruktur brauchen, die nicht in der Cloud liegt (zum Beispiel Malware-Infektionen auf On-Premises-Servern), werden Sie virtuelle, cloudbasierte Entsprechungen der Jump-Bag-Tools für die Reaktion auf Incidents in der Cloud benötigen. Das bedeutet auch, dass die forensischen Teile der Cloud Incident Response von überall aus durchgeführt werden können, wenngleich es Vorteile haben kann, physisch mit den Personen zusammenzusitzen, die mit daran beteiligt sind.
Jedes System mit einer ernsthaften Größe hat so viele verschiedene Logs und Metriken, dass man leicht unter Daten begraben wird, die aus Sicherheitssicht nicht nützlich sind. Es ist entscheidend, sich das Richtige herauszupicken! Leider ist das abhängig von Ihrer Umgebung und Ihren Anwendungen, daher müssen Sie sich Gedanken über Ihr Threat-Modell machen – was für Assets Sie haben und wer diese am ehesten angreifen wird –, aber auch überlegen, welche Logs aus den Systemen in Ihre Asset Management Pipeline kommen (siehe Kapitel 3).
Haben Sie beispielsweise viele Terabytes an Daten, kann es sehr hilfreich sein, die Metriken zur Menge Ihres Netzwerk-Traffics und der Dauer der Verbindungen im Auge zu behalten, um so erkennen zu können, ob jemand versucht, sie zu stehlen. Diese Metriken werden aber nicht sehr nützlich sein, wenn Sie Software bereitstellen, die jemand mit einer Backdoor kompromittieren könnte. Dabei werden sich die Menge an Daten, das Ziel und die Sitzungslänge nicht ändern – nur die Inhalte werden nicht mehr richtig sein.
Ein anderes Beispiel: Haben Sie für ein bestimmtes Tool bezahlt, beispielsweise eine Antivirensoftware, und sichergestellt, dass all Ihre Cloud-VMs damit laufen, wäre es ziemlich verrückt, sie zu ignorieren, wenn sie lautstark darauf aufmerksam macht, dass sie etwas gefunden hat. Sehen Sie Warnungen dieses Tools, hat es Sie vielleicht erfolgreich vor dem gesamten Angriff bewahrt. Aber es kann auch nur einen Teil der Attacke blockiert oder etwas Seltsames bemerkt, aber nichts blockiert haben. Sie müssen sich anschauen, wie die Malware in das System gelangt ist und ob der Angriff vollständig blockiert wurde oder nicht.
Haben Sie ein Threat-Modell im Kopf und ein gutes Verständnis davon, aus welchen Komponenten Ihr System besteht, finden Sie im folgenden Kasten ein paar gute, allgemeine Ausgangspunkte dazu, worauf Sie achten sollten. Konkretere Beispiele schauen wir uns an, wenn wir am Ende des Kapitels auf die Beispielanwendung eingehen.
Logs, Events, Warnungen und Metriken
Ein Log oder Event (oder Ereignis) ist eine Aufzeichnung einer spezifischen Aktivität, die geschehen ist. So erzeugt Ihre Umgebung vielleicht einen Log-Datensatz, wenn sich jemand authentifiziert, einen Web-Request abschickt, eine Konfiguration ändert oder sonst etwas tut, das in einer komplexen Umgebung so geschehen kann.
Eine Warnung (oder ein Alert) ist ein Event, bei dem die Regeln des Systems angeben, dass es sich lohnt, jemanden darüber zu informieren. Es ist ein Event, wenn die Antivirensoftware sich Updates geholt hat. Es sollte eine Warnung sein, wenn sie tatsächlich Malware gefunden hat!
Metriken sind eine Menge von Zahlen, die Informationen über etwas vermitteln. Sie sind meist zeitabhängig, daher wird vielleicht jede Minute eine Metrik über die Anzahl der authentifizierten Requests, über den verfügbaren Festplattenspeicher oder die Anzahl der Web-Requests erstellt.
Der große Vorteil von Logs ist, dass sie viel mehr Informationen darüber liefern, was geschehen ist – aber die Kosten für das Speichern und Durchsuchen von Logs können schnell steigen, wenn die Aktivitäten zunehmen. Haben Sie doppelt so viele Web-Requests, haben Sie auch doppelt so viele Log-Datensätze! Andererseits werden zwar die durch die Metriken berichteten Zahlen pro Zeiteinheit mit zunehmender Aktivität größer, aber die Kosten für das Speichern und Verarbeiten der Metriken werden nicht zunehmen (weil normalerweise die Kosten für das Speichern der Zahlen 100 und 200 gleich hoch sind). Sowohl Logs als auch Metriken können für das Erkennen von Sicherheitsvorfällen und das Erzeugen von Warnungen nützlich sein, und Metriken sind manchmal eine bessere Wahl für Benachrichtigungen, wenn die Menge an Log-Einträgen zu groß wird.
Für jede der folgenden Arten von Events müssen Sie sicherstellen, dass die Log-Einträge genug Daten enthalten, um nützlich zu sein. Das bedeutet im Allgemeinen mindestens das Wann, das Was und das Wer: Wann ist das Ereignis geschehen, was ist geschehen, und wer hat es ausgelöst? In manchen Fällen kann das Wer ein System oder ein anderes Automatisierungstool sein – wenn zum Beispiel ein System eine hohe CPU-Last meldet.
Sie sollten – mit einer Ausnahme – Passwörter, API-Schlüssel, sensible persönliche Informationen, geschützte Gesundheitsdaten und andere kritische Daten niemals in Logs stecken. In den meisten Fällen hat nicht jede Person mit Zugriff auf die Logs auch die Berechtigung, diese Informationen einsehen zu dürfen. Zudem steigt das Risiko für das unabsichtliche Veröffentlichen von Informationen, wenn diese an mehr Orten lagern, als absolut notwendig ist.
Tatsächlich sollten Sie es aus Gründen des Datenschutzes vermeiden, persönlich identifizierbare Daten direkt zu loggen, sofern das möglich ist. Müssen Sie herausfinden, auf wen sich etwas in Logs bezieht, nutzen Sie nicht direkt identifizierbare eindeutige IDs – zum Beispiel GUIDs –, und halten Sie an anderer Stelle eine Tabelle vor, mit der Sie diese GUIDs auf die tatsächlichen Entitäten abbilden können.
Die eine Ausnahme zu der Regel sind die Session Recordings für das Monitoren privilegierter User. Dabei können gelegentlich API-Schlüssel oder andere kritische Daten mitprotokolliert werden, die an der Befehlszeile eingegeben wurden. In diesem Fall muss der Zugriff auf die Session Records sehr strikt kontrolliert werden, zum Beispiel indem sie an einen Ort geschickt werden, an dem sie nur von einem kleinen Monitoring-Team eingesehen werden können. Die Möglichkeit das Risiko zu reduzieren, indem Sessions privilegierter User auditiert werden können, ist meist deutlich mehr wert als die Tatsache, dass in diesen Aufzeichnungen gelegentlich Secrets zu finden sein können.
So gut wie jeder sollte die Log-ins von privilegierten Usern loggen und zumindest stichprobenartig untersuchen – auf allen Ebenen der Umgebungen. Das kann zu Fragen führen, die dabei helfen, böswillige Aktivitäten zu erkennen, zum Beispiel: »Warum meldet sich diese Person überhaupt an?«, »Hat diese Person nicht die Firma verlassen?« oder »Kennt jemand diesen Account?«
Das Überwachen des Zugriffs privilegierter User bedeutet nicht, dass Sie Ihren Administrationsteams nicht vertrauen. In einer perfekten Welt müssten Sie niemals einem einzelnen Individuum zu 100% vertrauen. Jede Aufgabe mit einem gewissen Risiko müsste von mindestens zwei Personen bestätigt werden, sodass man sich schon geheim absprechen müsste, um solche Aufgaben umzusetzen, ohne erkannt zu werden.1 So viel Sorgfalt ist nicht für alle Aufgaben in allen Organisationen erforderlich, aber Sie sollten sie für Aktionen mit großem Wert bedenken, zum Beispiel das Überweisen von Geld oder den Zugriff auf geheime Data Stores. Wir wollen hier vor allem erkennen, ob eine unautorisierte Person vorgibt, Administrator oder Administratorin zu sein. Da eine der Hauptursachen für Sicherheitsvorfälle verlorene oder gestohlene Credentials sind, ist das Beobachten der Tätigkeit Ihrer Administrationsteams eine gute Möglichkeit, jemanden zu erwischen, der vorgibt, ein Admin zu sein.
Cloud-Provider können gute Logs vorhalten, in denen zu finden ist, wann sich jemand als einer Ihrer Administratoren oder Administratorinnen über die administrativen Schnittstellen der Cloud (Webportal, APIs oder Befehlszeilenschnittstelle) angemeldet hat und was derjenige dort getan hat – zum Beispiel »Instanz erstellt«, »Datenbank erstellt« oder »administrativen User erstellt«. Diese Logs werden eventuell von Cloud-Services gesammelt, zum Beispiel von AWS CloudTrail, Azure Activity Log, Google Cloud’s Operations Suite oder IBM Cloud Activity Tracker – aber in manchen Fällen müssen Sie das Logging-Feature explizit einschalten, angeben, wo und wie lange Logs vorzuhalten sind, und für den Storage bezahlen.
Neben den Logs über privilegierte User, die vom Cloud-Provider erfasst werden, haben Administratorinnen und Administratoren oft auch privilegierten Zugriff auf die Systeme, die in der Cloud-Umgebung erzeugt wurden. So haben Sie vielleicht administrative Accounts auf virtuellen Maschinen, auf Firewall-Appliances oder auf Datenbanken. Der Zugriff darauf kann über ein Protokoll wie syslog dokumentiert werden. Es kann auch andere Systeme geben, wie zum Beispiel einen Passwort-Vault, um gemeinsam genutzte IDs auszuchecken. Im Allgemeinen sollten alle Systeme, die vom Administrationsteam genutzt werden, um privilegierte Aktionen auszuführen, diese Aktionen protokollieren.
Logs mit administrativen Aktivitäten sollten in zwei Arten unterteilt werden, die ich als toxische Logs und als gesäuberte Logs bezeichne.
Toxische Logs können kritische Informationen enthalten, wie zum Beispiel Passwörter oder API-Schlüssel, die bei einem Angriff direkten Zugriff auf das System ermöglichen. Eventuell haben Sie gar keine toxischen Logs in Ihrer Umgebung. Im Allgemeinen sollte auf solche Logs nur bei einem vermuteten Vorfall zugegriffen werden – oder von einem kleinen, überwachten Team, das regelmäßig stichprobenartig administrative Sessions begutachtet. Wird auf toxische Logs zugegriffen, sollte das eine Benachrichtigung auslösen, sodass mindestens zwei Personen davon erfahren. Hier sind ein paar Beispiele für toxische Logs:
Gesäuberte Logs sind so designt, dass sie keine Secrets enthalten. Der größte Teil der Logs sollte in diese Kategorie fallen. Hier ein paar Beispiele für gesäuberte Logs:
Session Recording Tools
Eine der Funktionen von Systemen zum Privileged Access Management oder Privileged Identity Management ist normalerweise das Session Management – die Möglichkeit, privilegierte Sessions aufzuzeichnen, in Echtzeit zu beobachten, was ein privilegierter User tut, und bei verdächtigen Aktionen die Session zu beenden. Das ist besonders in Bereichen wichtig, in denen die zu verwaltenden Systeme hohe Anforderungen an die Vertraulichkeit oder Integrität haben und es für Angreifer lohnenswert wäre, auf die von diesen Systemen gemanagten Daten zuzugreifen oder sie sogar zu verändern.
Session Recording Tools bedienen sich im Allgemeinen einem von zwei Modellen: Entweder laufen alle Sessions über einen zentralen Ort zum Aufzeichnen und Steuern, oder das Session Recording geschieht über Agenten auf den Servern selbst. Wenn alles über einen zentralen Ort laufen muss, kann das ein Single Point of Failure sein. Wird alles von einem lokalen Agenten auf dem Server protokolliert, hat der privilegierte User oft auch die Berechtigung, den Agenten zu deaktivieren. Im Allgemeinen empfehle ich ein zentrales Session Recording mit einem Notfallprozess für einen Zugriff, falls die Infrastruktur zum Session Recording nicht verfügbar ist.
Die privilegierten User für die meisten zu managenden Systeme und die für das Managen der Session Recording Tools sollten im Allgemeinen getrennt voneinander sein. Auch hier sollten Sie ein System aufsetzen, in dem eine Einzelperson (oder ein Angreifer, der vorgibt, diese Person zu sein) keine böswilligen Befehle absetzen und auch das Logging dieser Befehle nicht deaktivieren kann.
Wie schon erwähnt, sind Logs zu Session Recordings »toxisch«, weil sie Passwörter oder andere Secrets enthalten können. Ich empfehle meist, die Session Recording Tools so zu konfigurieren, dass die Logs an eine »Drop Box« geschickt werden. Sie landen so an einer zentralen Stelle, es gibt keine lokale Kopie, und das Tool kann die Logs nach dem Speichern an dieser Stelle auch nicht mehr einsehen oder verändern.
Nutzen Sie Verteidigungstools, wie zum Beispiel Antivirensoftware, Firewalls, Webanwendungs-Firewalls, Intrusion Detection Systems oder Network Monitoring Tools, müssen Sie sich die davon erzeugten Logs anschauen. Sie können nicht davon ausgehen, dass diese Tools beim Abwehren aller Angriffe zum 100% erfolgreich sein werden. In manchen Fällen blockieren die Tools vielleicht den ersten Angriff und lassen dann einen Folgeangriff durch, oder sie protokollieren nur, dass etwas geschehen ist, ohne die Attacke zu blockieren. Sie müssen die Logs aus diesen Services sammeln und analysieren, denn ansonsten geben Sie einen großen Vorteil früher Warnungen auf.
Das Problem ist, dass manche dieser Tools notwendigerweise »laut« sind und einen hohen Anteil falsch-positiver Ergebnisse besitzen. Unterschätzen Sie nicht das Risiko von Falsch-Positiven! Es ist sehr leicht, sich selbst und das Team daran zu gewöhnen, diese Warnungen zu ignorieren, obwohl sie wichtig sein können. Sie benötigen eine Feedback-Schleife, sodass die Personen, die falsch-positive Meldungen sehen, eine Möglichkeit haben, entweder spezifische Logs entsprechend auszufiltern und nicht weiterzuverarbeiten oder das System so anzupassen, dass die Tools nicht so oft falsch-positive Ergebnisse liefern. Das ist natürlich eine Kunst, weil Sie das Risiko eingehen, richtig-positive Meldungen wegzufiltern, aber in den meisten Fällen sollten Sie dabei ein kleines Risiko akzeptieren, um Ihr Team davon abzuhalten, die Warnungen ganz zu ignorieren. So wie Sie mehrere Schutzschichten haben sollten, sollten Sie auch mehrere Erkennungsschichten besitzen, damit Sie nicht nur von einem Tool abhängig sind, wenn es darum geht, böswillige Aktivitäten zu entdecken.
Die Logging-Empfehlungen für die meisten Verteidigungstools entsprechen in Cloud-Umgebungen denen in On-Premises-Umgebungen.
Systeme zum Verteidigen gegen Denial-of-Service-Angriffe sollten so konfiguriert sein, dass sie bei Attacken Warnungen ausgeben. Das sollte im Allgemeinen eine Warnung von hoher Wichtigkeit sein – zum Beispiel durch Verschicken einer SMS –, weil DDoS-Angriffe oft mit der Zeit eskalieren oder ein Erpressungsversuch folgt. Zudem kann ein DDoS-Angriff als Ablenkung dienen, um andere Einbruchsaktivitäten zu verschleiern, auch wenn darüber diskutiert wird, wie oft das wirklich geschieht.
Sowohl verteilte wie auch zentrale WAF-Lösungen können Benachrichtigungen bei Angriffen schicken, die blockiert wurden, oder bei verdächtig aussehenden Requests. Diese Warnungen können nützlich sein, um zu verstehen, wann ein Angriff gegen Ihre Webanwendungen versucht wurde.
WAFs werden oft anstelle von manuellen Code-Reviews für PCI-DSS-Zertifizierungen eingesetzt. Als Teil davon müssen Sie auch zeigen, dass Sie die Logs der WAF-Systeme speichern und auswerten.
Firewalls und IDS, die vom Internet aus erreichbar sind, werden Benachrichtigungen eher zurückhaltend verschicken müssen, weil solche Systeme unter dauerhaften, wenn auch »einfachem« Beschuss stehen (zum Beispiel durch Port-Scans oder das Raten von Passwörtern). Die historischen Daten können aber von Interesse sein, wenn ein Vorfall vermutet wird.
Eine Firewall oder ein IDS innerhalb Ihres Perimeters sollte andererseits ziemlich empfindlich eingestellt sein, weil Warnungen hier eher auf eine Fehlkonfiguration oder einen tatsächlichen Angriff hindeuten können. Neben weiteren Verteidigungstools, die auf der Allowlist stehen sollten, damit sie keine Warnungen auslösen, sollte nichts anderes Ihr internes Netzwerk scannen oder fehlschlagende Verbindungen auslösen.
In diese gleiche allgemeine Kategorie fallen auch Systeme zur Network Traffic Analysis, die meist Traffic-Daten von Routern und Switches aggregieren, um ein Gesamtbild der Datenbewegungen in Ihre Umgebung, aus Ihrer Umgebung heraus und untereinander erstellen zu können. Diese lassen sich auch so konfigurieren, dass Warnungen verschickt werden, wenn eventuell etwas falsch läuft.
Stellen Sie sicher, dass Sie Warnmeldungen erhalten, wenn auf den Systemen in Ihrem Asset-Management-System keine Antivirensoftware installiert ist und wenn Malware gefunden wird.
Wird bei einem Angriff eine Schwachstelle ausgenutzt, um in Ihr System zu gelangen, besteht der erste Schritt meist darin, dort Malware zu hinterlassen. Ist die angreifende Person klug, wird sie sicherstellen, dass die Malware so gut angepasst ist, dass keine bei Ihnen laufende Antivirensoftware auslösen wird. Es gibt für so etwas Services, oder die Angreifer bedienen sich eigener Labs, um ihre Malware durch jegliche verfügbare AV-Software laufen zu lassen, um sicherzustellen, dass sie nicht erkannt wird. Zum Glück sind nicht alle angreifenden Personen so klug, und diese Tools sind trotzdem sehr hilfreich, um die Dummen zu finden. Verwerfen Sie keine Tools, nur weil sie nicht zu 100% effektiv sind!
Beim berüchtigten Target-Einbruch im Jahr 2013 war einer der Fehler, nicht auf die Warnungen der Antivirensoftware zu hören.
Während sich klassische Anti-Malware-Software vor allem darauf konzentriert, böswillige Aktivitäten zu blockieren, geht es bei Software zur Endpoint Detection and Response (EDR) mehr darum, dass Teams Threats untersuchen und auf sie reagieren können, die die erste Verteidigungslinie durchbrochen haben. Wenn Antivirensoftware vergleichbar ist mit schwer entflammbaren Materialien in einer physischen Struktur, ist die EDR-Software eher der Rauchmelder und das Sprinklersystem.
Für EDR werden im Allgemeinen viele Informationen über die laufenden Systeme gesammelt, wie zum Beispiel Hashwerte jeder ausführbaren Datei oder Bibliothek, die auf dem System ausgeführt wurde, oder eine Historie der versuchten Netzwerkverbindungen. Manche dieser Informationen lassen sich zwar über Logs des Betriebssystems oder des Netzwerks erhalten, aber EDR-Software kann sie an einem Ort zusammenführen. Dort lassen sie sich mit Feeds zu Threats verbinden, zum Beispiel über neu entdeckte Command-and-Control-Server oder neu zur Verfügung gestellte Malware-Signaturen. So können aktuelle und vergangene Aktivitäten erkannt werden. Manche EDR-Software kann auch genutzt werden, um Systeme unter Quarantäne zu stellen und zu untersuchen, wenn dort ein Angriff festgestellt wurde.
Diese Möglichkeiten werden oft interaktiv von einem Response-Team genutzt, aber EDR-Lösungen können auch Warnungen verschicken, wenn Threats in Ihrer Umgebung erkannt werden, sodass es eine gewisse Überlappung mit Antivirensoftware gibt.
All diese DRs
Der Markt ist voll mit vielen Arten von Detection and Response Tools – aktuell sind EDR, NDR und XDR die gebräuchlichsten Kategorien. Deren Definitionen sind nicht trennscharf, und es wird auch über sie diskutiert; zudem werden viele Anbieter versuchen, Sie davon zu überzeugen, dass ihr Tool alles kann. Schauen wir uns die Kategorien kurz an.
Endpoint-Detection-and-Response-(DER-)Tools bieten (wie schon beschrieben) drei große Vorteile gegenüber klassischen Antivirentools. Der erste ist der Einsatz vieler weiterer Signale neben Signaturen und Prozessverhalten, um vor verdächtigen Aktivitäten zu warnen. Der zweite ist die Fähigkeit, basierend auf neuen Informationen in der Historie zurückschauen zu können, um zu sehen, wer oder was schon infiziert ist. Drittens kann ein kompromittiertes System schnell unter Quarantäne gestellt werden, anstatt nur eine verdächtige Datei zu isolieren.
Network Detection and Response (NDR) ist ähnlich, nur für den Datenfluss im Netzwerk. NDR-Tools bieten oft neben dem Prüfen von Signaturen auch Verhaltensanalysen an (ähnlich wie Systeme zur Network Traffic Analysis), aber auch die Möglichkeit, Datenflüsse als Reaktion auf einen aktiven Angriff schnell unterbinden und sichern zu können.
Extended Detection and Response (XDR) ist meist eine Kombination verschiedener Sicherheitsprodukte, auch wenn verschiedene Anbieter ebenfalls unterschiedliche Funktionen zusammenfassen und sie alle als XDR bezeichnen.
Unabhängig von der genutzten Technologie müssen Sie sicherstellen, dass Sie die Warnungen der Tools auch zur Kenntnis nehmen und darauf reagieren.
Manche Dateien sollten sich nicht immer wieder ändern, und wenn sie geändert werden, kann das ein Hinweis auf einen Angriff sein. Bearbeitet beispielsweise jemand die Konfiguration des Logging-Systems, ist das verdächtig. Tatsächlich sollten auf einem Linux-System die meisten Änderungen im Verzeichnis /etc mit Misstrauen betrachtet werden.
Software zum File Integrity Monitoring (FIM) kann Sie warnen, wenn bestimmte Dateien verändert werden, und manche Produkte ermöglichen eine Warnung auch, wenn sich bestimmte Windows-Registry-Einträge ändern. Cloud-Provider bieten teilweise FIM-Funktionalität als Teil ihrer IaaS Cloud Management Platform an. Es gibt außerdem freie und kostenpflichtige Versionen von FIM-Produkten, die Sie auf Ihren Systemen deployen können.
File Integrity Monitoring ist für die PCI-DSS-Zertifizierung explizit notwendig, und einige Auditoren erwarten auch, dass davon nicht nur normale Dateien, sondern auch die Windows Registry abgedeckt ist.
Monitoring-Tools der Cloud-Provider, wie zum Beispiel AWS CloudTrail, Azure Monitor oder IBM Cloud Activity Tracker, können wichtige Einblicke darin geben, was die verschiedenen Entitäten in Ihrem Cloud-Account so treiben. Das ist besonders für privilegierte User oder Service-Accounts mit sehr vielen Berechtigungen wichtig.
Diese Tools besitzen im Allgemeinen die Fähigkeit, Logs zu sammeln und Benachrichtigungen zu verschicken für Aktionen, die entweder nie geschehen oder so selten sein sollten, dass es sich lohnt, andere User darüber zu informieren. Beispiele dafür können das Annehmen einer privilegierten Rolle innerhalb des Cloud-Accounts beziehungsweise das Ändern von Sicherheitsparametern des Cloud-Accounts oder von kritischen Services im Account sein.
Neben dem Loggen von Administrationsaktivitäten bieten die meisten Cloud-Provider auch nützliche Logs und Metriken zu ihren Services. Schauen Sie sich die für die von Ihnen genutzten Services angebotenen Logs und Metriken an und denken Sie darüber nach, welche davon bei einem Angriff eskalieren würden und/oder welche dabei helfen können, im Nachhinein herauszufinden, wie schlimm es aussieht. Hier ein paar Beispiele:
CPU-Usage-Metriken
Spitzen bei der CPU-Usage, die nicht durch eine zunehmende Verwendung erklärt werden können, deuten auf eine aktive Ransomware-Verschlüsselung oder ein Cryptomining hin.
Netzwerk-Logs und -Metriken
Nutzen Sie beispielsweise Virtual Private Cloud Subnets, können viele Cloud-Provider Metriken zu den dort ein- und ausgehenden Daten bereitstellen und auch Flow-Logs anbieten, die akzeptierten und abgelehnten Traffic aufzeigen. Abgelehnter Traffic, der von Ihren eigenen Komponenten kommt, deutet entweder auf eine Fehlkonfiguration oder auf eine Attacke hin und sollte untersucht werden. Spitzen im Netzwerk-Traffic können darauf hinweisen, dass ein Denial-of-Service-Angriff beginnt oder dass bei einem Angriff schon aktiv Daten gestohlen werden.
Storage-Input/Output-(I/O-)Metriken
Eine I/O-Spitze, die sich nicht durch eine zunehmende Verwendung erklären lässt, kann auf aktive Ransomware, einen Denial-of-Service-Angriff oder das aktuelle Stehlen von Daten hindeuten.
Metriken zu Requests an Plattformkomponenten, wie zum Beispiel Datenbanken oder Message Queues
Beginnt Ihre Datenbank, sich seltsam zu verhalten, kann das den Verdacht wecken, dass bei einem Angriff große Mengen an Daten gestohlen werden. Beginnt Ihre Message Queue, sich seltsam zu verhalten, befindet sich ein Angreifer vielleicht in einem Teil des Systems und versucht, Nachrichten an andere Komponenten zu schicken.
Enduser-Log-ins und Aktivitäten auf SaaS-Angeboten
Beginnt ein User damit, große Mengen an Daten aus einem Cloud-Storage-Service abzuziehen, kann das ein Hinweis darauf sein, dass der Account kompromittiert wurde. Nutzen Sie einen Cloud Access Security Broker (CASB), um den Zugriff auf einen Cloud-Service zu vermitteln, kann dieser eventuell auch detailliertere Events über User-Aktivitäten erzeugen, die Sie dann monitoren können.
Logs und Metriken zu Plattformservices
Jeder Plattformservice kann Logs und Metriken haben, die sich neben dem Operations Monitoring auch für Detect and Response nutzen lassen. Verwenden Sie beispielsweise eine Orchestrierungsplattform wie Kubernetes, können Sie Auditing aktivieren. Die Kubernetes-Dokumentation (https://oreil.ly/Z6r_x) beschreibt, wie Sie das Audit-Logging einschalten und wie Sie die Logs an einen Collection Point übertragen können. Genauso bieten Object Storage, Datenbanken und andere Cloud-Services servicespezifische Logs und Metriken an.
Betreiben Sie virtuelle Maschinen oder Bare-Metal-Maschinen in der Cloud, liegt die Sicherheit des Betriebssystems im Allgemeinen in Ihrer Verantwortung – dazu gehören auch das Sammeln und Analysieren von Logs. Das ähnelt dem Vorgehen bei einer On-Premises-Infrastruktur:
Betreiben Sie Ihre eigene Datenbank, Ihren eigenen Queue Manager, Anwendungsserver oder andere Middleware, müssen Sie eventuell das Erstellen von Logging- und Metrikdaten erst aktivieren. Neben allen Aktivitäten privilegierter User (siehe den Abschnitt »Zugriff privilegierter User« auf Seite 181) können Sie vielleicht auch Warnungen für jeglichen Zugriff auf kritische Datenbanken oder Tabellen einrichten, der nicht von einer erlaubten Anwendungs-ID oder einem zugelassenen System kommt. Auch für anderen Zugriff auf kritische Daten sind Warnungen sinnvoll.
Betreiben Sie einen Secrets-Server (siehe Kapitel 4), sollten Sie jeden Zugriff auf Secrets protokollieren. Hier ein paar Beispiele für ungewöhnliche Aktivitäten, für die Sie eine Warnung bekommen und die Sie sich genauer anschauen sollten:
Haben Sie eine eigene Anwendung geschrieben oder betreiben Sie eine von dritter Seite, erzeugt diese eventuell ihre eigenen Logs und Metriken, die sowohl für das Operations- wie auch das Sicherheitsteam von Interesse sein können. So protokolliert beispielsweise eine Banking-Applikation vielleicht alle Überweisungen, und sobald diese eine gewisse Schwelle überschreiten, wird auch eine Warnung verschickt.
Täuschungstechniken
Neben anderen Erkennungstechniken sind manche Technologien so entworfen, dass sie einer angreifenden Person das Leben schwerer machen, ohne Ihre normalen User und das Administrationsteam zu nerven. Das bekannteste Beispiel hierfür ist ein Honeypot, ein System, das so tut, als sei es ein funktionaler Teil der Infrastruktur, dessen einziger Zweck es ist, Angreifer abzulenken und ihr Tempo zu verlangsamen und Sie zu warnen, wenn Angreifer im System sind.
Neben Honeypot-Systemen gibt es auch Honey-Token und Honey-IDs. Honey-Token können in nützlich aussehenden Dateien liegen, die aber reine Fakes sind (wie zum Beispiel next-quarter-secret-plans.docx) und bei denen Sie benachrichtigt werden, wenn man sie öffnet. Es kann sich auch um normale, ungenutzte Objekte wie API-Schlüssel handeln, die in Quellcode eingebettet sind und Ihnen bei ihrem Einsatz eine Warnung zukommen lassen. Honey-IDs sind meist ungenutzte IDs ohne Berechtigungen, die für einen Angreifer verlockend aussehen (zum Beispiel »superadmin«) und die sofort eine Warnung auslösen, wenn jemand versucht, sie zu verwenden.
Es ist wichtig, darauf hinzuweisen, dass »Security through Obscurity« im Allgemeinen zwar ineffektiv, Geheimhaltung speziell bei Täuschungstechniken aber von großer Bedeutung ist. Dokumentieren Sie die Existenz von Honeypots, Honey-Token oder Honey-IDs immer nur so sparsam, dass lediglich Ihr Kernsicherheitsteam etwas darüber erfahren kann.
Täuschungstechniken können dabei helfen, beim Verteidigen Ihrer Umgebung Ihren »Heimvorteil« zu verbessern, weil Sie Fallen auslegen können, von denen nur Sie etwas wissen. Aber das ist eine fortgeschrittene Technik. Sorgen Sie erst dafür, dass Logging, Monitoring, Alerting, Response- und Recovery-Pläne funktionieren, bevor Sie mehr Zeit und Aufwand in das Täuschen stecken.
Täuschungstechniken können sowohl in On-Premises-Umgebungen wie auch in der Cloud zum Einsatz kommen. Ein Cloud-Native-Beispiel dafür ist die Microsoft Sentinel Deception (https://oreil.ly/Dh6fA).
Nachdem wir darüber gesprochen haben, was für Events und Metriken Sie in Ihrer Umgebung im Auge behalten sollten, wollen wir uns nun anschauen, wie Sie diese effektiv einsammeln und verwenden, um Einbrüche zu erkennen und auf sie zu reagieren. In Abbildung 7-1 sehen Sie die verschiedenen Schritte dieses Prozesses. Sie können alle durch ein einzelnes Produkt oder einen einzelnen Service abgedeckt werden, wie zum Beispiel ein SIEM, oder es kommen mehrere Produkte und Services zum Einsatz, die zusammenarbeiten.
Abbildung 7-1: Logging- und Alerting-Chain
Stellen Sie sicher, dass die Zeit auf all Ihren Systemen synchron ist – im Allgemeinen durch den Einsatz des Network Time Protocol (NTP). Achten Sie zudem darauf, dass alle Timestamps eine Zeitzoneninformation enthalten oder dass Sie für alle Logs die gleiche Zeitzone (wie GMT) verwenden. Das lässt sich meist sehr einfach einrichten und kann den Albtraum vermeiden, Events aus verschiedenen Log-Quellen miteinander abzugleichen, wenn die Systemuhren oder die Zeitzonen nicht übereinstimmen.
Alle weiter oben beschriebenen Logs müssen irgendwo gespeichert und eine gewisse Mindestzeit aufbewahrt werden. Es ist zwar viel besser, Logs auf verschiedenen Systemen zu sammeln, als gar keine Logs zu haben, aber ideal ist es nicht. Die Festplatten der einzelnen Systeme können volllaufen, den Verlust von Logs und funktionale Probleme verursachen, und ein Angreifer, der in ein System eindringt, kann die Logs löschen, um seine Spuren zu verwischen. Zudem kann es sehr langsam und unpraktisch sein, in Dutzende verschiedene Systeme gehen zu müssen, um Logs zu durchsuchen und sich nach und nach ein Bild davon zu machen, was gerade passiert.
In der Vergangenheit wurden wichtige Logs oft auf Papier ausgedruckt und an einen physisch sicheren Ort geschickt. Das ist zwar ein ziemlich verlässlicher Weg, sie abzusichern und nicht mehr von einem Computer aus erreichbar zu machen, aber Papier hat einige ziemlich große Nachteile – es ist nicht automatisch durchsuchbar, es ist schwer, teuer, und es bildet ein Brandrisiko.
In der Cloud können Sie viele der gleichen Vorteile viel einfacher erhalten, indem Sie Ihren Log-Aggregations-Service in einem eigenen Cloud-Account mit anderen administrativen Credentials unterbringen, sodass die Logs nicht von jemanden mit Zugriff auf die eigentlichen Systeme gelöscht werden können. (Das ist auch für Backups eine gute Idee, wie wir später noch besprechen werden.) Die meisten Cloud-Provider bieten Services zum Aggregieren, Aufbewahren und Durchsuchen von Logs an, sodass Sie die entsprechenden Dienste nicht selbst von Grund auf aufbauen müssen.
Sie sollten die meisten Logs für mindestens ein Jahr aufbewahren. Manchmal können längere Aufbewahrungsfristen hilfreich sein, um Sicherheitsvorfälle zu untersuchen, aber solche längeren Fristen können wiederum mit Richtlinien zum Datenschutz kollidieren. Müssen Sie sich an bestimmte Branchen- oder rechtliche Standards halten, schauen Sie sich die entsprechenden Aufbewahrungsanforderungen für diese Logs an, aber aktuell ist ein Jahr im Allgemeinen eine gute Wahl.
Haben Sie alle Ihre Logs und Warnungen an einer zentralen und sicheren Stelle und sind die passenden Aufbewahrungsfristen konfiguriert, müssen Sie die Probleme angehen, die sich mit dem Durchsuchen dieser Logs ergeben, um bei verdächtigem Verhalten Warnungen zu verschicken und sicherzustellen, dass die Warnungen die richtigen Leute erreichen, dass sie berücksichtigt werden und dass dann auch Nachforschungen angestellt werden.
Sind alle Ihre Logs an einem sicheren Ort aggregiert, können Sie sich gratulieren! Eine zielstrebige Person kann diese Logs durchforsten und Antworten auf wichtige Fragen erhalten, aber das kann eine Weile dauern. Einer der wichtigsten Beweggründe für das Erfinden von Computern war jedoch, Daten viel schneller verarbeiten zu können, als dies Menschen möglich wäre.
Log-Parser holen sich spezifische Informationshappen (Felder) aus den verschiedenen Arten von Events. Hier ein paar Beispiele für die Arbeit von Log-Parsern:
Es gibt leider Tausende von Log-Formaten. Ein paar gebräuchliche machen das Parsen allerdings ein bisschen einfacher. Viele Tools können Logs in diesen Formaten in spezifische Felder parsen, auch wenn das nicht immer bedeutet, dass diese Felder nützlich sind. Hier ein paar Beispiele:
Sind die Logs aggregiert und geparst, können Sie in den geparsten Feldern suchen und Events verschiedener Systeme miteinander in Beziehung setzen. So können Sie beispielsweise nach allen fehlgeschlagenen Anmeldeversuchen in einem bestimmten Zeitraum suchen, alle Fälle finden, in denen für den gleichen User ein erfolgreiches Log-in ohne eine VPN-Verbindung stattfand oder in denen Malware gefunden wurde und danach ein Log-in geschah.
Die Möglichkeit, schnell über mehrere verschiedene Log-Ressourcen und Arten von Logs hinweg zu suchen, kann bei der Reaktion auf Sicherheitsvorfälle unbezahlbar sein. Testen Sie das System aus, indem Sie mehrere parallele, hektische Suchen gleichzeitig durchführen lassen, bevor Sie das Ganze mitten in einem Sicherheitsvorfall ausprobieren müssen!
Viele Systeme setzen auf das Prinzip von Hot Storage und Cold Storage. Hot Storage lässt sich sofort abfragen, während Cold Storage erst eingelesen und geladen werden muss, bevor man ihn durchsuchen kann.
Bemerkt ein automatisiertes System etwas, das sich ein Mensch anschauen sollte, löst es einen Alert oder eine Warnung aus und reagiert manchmal auch automatisch, indem es den Zugriff sperrt oder eine Komponente herunterfährt. Warnungen können auf bestimmten Events basieren, auf dem gemeinsamen Auftreten von Events oder auf bestimmten Schwellenwerten, die erreicht wurden.
Dies ist der kunstfertige Teil der Log-Analyse. Ist das System so empfindlich eingestellt, dass Ihr Sicherheitsteam ständig falsche Alarme bekommt, werden schnell alle Warnungen ignoriert. Bekommen Sie andererseits nicht zumindest gelegentlich eine Warnung, werden Sie wahrscheinlich einige Dinge nicht verfolgen, die Sie besser im Blick behalten sollten. Sie brauchen eine Feedback-Schleife für jede Art von falschem Alarm, um herauszufinden, ob es sinnvoll ist, diese Arten von Events auszufiltern, Schwellenwerte hochzusetzen oder andere Maßnahmen zu ergreifen, um die Anzahl zu reduzieren. Denken Sie über regelmäßige Tests nach, von denen Sie wissen, dass sie Warnungen erzeugen, um sicherzustellen, dass diese nicht ignoriert werden.
Es gibt ein paar Warnungen, denen Sie fast immer nachgehen sollten. Mehrere fehlgeschlagene Anmeldeversuche für privilegierte User, Malware-Funde auf Systemen und andere Warnungen, die Vorboten für Sicherheitsvorfälle sein können, sollten zumindest einen kurzen Check erhalten, auch wenn es meist falsche Alarme sind.
Vergessen Sie nicht, dass Sie auch Warnungen erhalten müssen, wenn Logs plötzlich nicht mehr gefüllt werden. Das ist ebenfalls ein Sicherheitsvorfall! In vielen Fällen bedeutet es nur, dass irgendetwas nicht funktioniert, was Sie davon abhalten könnte, in Zukunft Probleme zu erkennen. In manchen Fällen kann es aber auch ein Hinweis auf eine aktuell stattfindende Attacke sein.
Eine automatische Reaktion klingt im Prinzip großartig, aber sie hat auch das Potenzial, Ihre Geschäftstätigkeit zu unterbrechen. Neben Outages, die durch eine falsche Reaktion oder eine automatische Überreaktion ausgelöst werden, können automatische Reaktionen auch bewusst von Angreifern ausgenutzt werden, um Outages zu verursachen. Es ist nicht schön, zu erkennen, dass Sie ziemlich viel Geld in das Verhindern von Denial-of-Service-Angriffen gesteckt haben, nur um es dann ungewollt einer angreifenden Person zu ermöglichen, solch eine Attacke über einen einfachen Port-Scan oder ein paar fehlschlagende Log-ins fahren zu können. Manche Umgebungen haben durchaus so hohe Sicherheitsanforderungen, dass Sie eher ein Outage akzeptieren, bis sich ein Mensch der Sache angenommen hat, als selbst ein kleines Risiko eines möglichen weiterlaufenden Angriffs in Kauf zu nehmen. Aber in den meisten Fällen müssen die operationalen Risiken und Sicherheitsrisiken sorgfältig gegeneinander abgewogen werden.
Beim Alerting sollte es sich nicht um eine Fire-and-Forget-Aktivität handeln. Oft müssen Sie die beteiligten Personen »durchrotieren«, weil niemand dauerhaft Bereitschaft haben möchte, und Sie brauchen eine Möglichkeit, sicherzustellen, dass eine Warnung innerhalb einer gewissen Zeit zur Kenntnis genommen oder an jemand anderen eskaliert wird. Es gibt für alles cloudbasierte Services, und das Alerting ist da keine Ausnahme. In den meisten Fällen kann das gleiche System sowohl für operative Maßnahmen als auch für Sicherheitsmaßnahmen verwendet werden.
Größere Organisationen werden für ein 24 × 7 Security Operations Center (SOC) entweder selbst ein System aufbauen oder einen Vertrag mit einem Managed Security-Service-Provider (MSSP) abschließen, um Warnungen zu monitoren und darauf zu reagieren. Ein Raum mit vielen Bildschirmen, die wichtig aussehende Grafiken anzeigen, ist optional, beeindruckt aber Ihr oberstes Management und Ihre Kunden und kann durchaus auch in kritischen Situationen dabei helfen, wichtige Informationen zu visualisieren. In vielen Fällen nutzen Organisationen ein hybrides Modell, in dem ein Teil des Monitoring und Alerting auf niedriger Ebene durch einen MSSP durchgeführt wird, während die wichtigeren Warnungen und Eskalationen durch eigene Mitarbeiterinnen und Mitarbeiter behandelt werden.
Moderne Systeme können Milliarden von Log-Events erzeugen. Sie können auf noch mehr Automation zurückgreifen, um diese im Griff zu behalten – hier kommt ein SIEM ins Spiel.
Ein Security Information and Event Manager (SIEM) kann einige oder alle der in den vorherigen Abschnitten beschriebenen Schritte umsetzen. Ihr SIEM kann beispielsweise Logs aggregieren, aber Sie können auch ein separates System zum Aggregieren und Filtern von Logs nutzen und nur eine Untermenge davon an den SIEM übergeben. Weil viele Cloud-Provider Log-Aggregations-Services zu niedrigeren Kosten und mit hohem Verarbeitungsvolumen anbieten und weil Logs häufig neben dem Erkennen von Sicherheitsvorfällen auch für die Fehlerbehebung im Betrieb eingesetzt werden, nutzen viele Organisationen einen Cloud-Log-Aggregator, der sicherheitsrelevante Events an den SIEM übergibt.
SIEM-Regeln können genutzt werden, um potenziell schlechtes Verhalten zu erkennen. Dabei werden manchmal Events von zwei verschiedenen Orten miteinander in Verbindung gebracht oder aktuelle und historische Daten verglichen. Hier ein paar Fragen, die durch einen Security Operator gestellt werden könnten, der Warnungen von einem gut konfigurierten SIEM einsieht:
Ein SIEM kann im Unternehmen selbst, als Cloud-Service oder als Teil eines Vertrags zu Managed Security-Services betrieben werden. Viele Provider von Cloud-Infrastruktur und -Plattformen bieten fertige Services, die zumindest einen Teil der SIEM-Funktionalität besitzen, zudem gibt es diverse Lösungen von dritter Seite. Unabhängig davon, ob Sie sich für den Einsatz eines SIEM entscheiden oder nicht, sollten Sie sicherstellen, dass Sie Ihre Anforderungen für Aggregation und Speicherung, Parsen, Durchsuchen und Korrelieren, Warnen und automatisches Reagieren erfüllen.
SIEM oder nicht SIEM, das ist hier die Frage
Brauchen Sie einen Security Information and Event Manager? Kleinere Organisationen kommen vielleicht mit einem Log-Aggregations-Tool zurecht, das auch einfache Warnungen erzeugt oder in dem das Sicherheitsteam stöbern kann, um Bedrohungen zu finden. Aber es gibt einen Grund, warum dedizierte SIEM-Produkte und -Services existieren. Die Logik und die Regeln, die erforderlich sind, um relevante Daten aus einer Menge unterschiedlicher Log-Formate herausziehen und Logs aus unterschiedlichen Quellen miteinander in Beziehung setzen zu können, zu wissen, wie häufige Angriffe aussehen, und einen Threat Intelligence Feed zu aktuellen Angriffen aus der ganzen Welt zu bekommen – das alles kann sehr kompliziert sein. Dieser Aufwand lässt sich intern nur schwer nachbauen, daher betreiben viele größere Organisationen entweder ein SIEM-Produkt oder einen entsprechenden Service, oder sie bedienen sich eines Managed Security-Service, um den SIEM für sich laufen zu lassen und bei Reaktionen unterstützt zu werden.
Erst wenn Sie die Grundlagen gelegt haben – also sicherheitsrelevante Logs und Metriken einsammeln, parsen und auf von Ihren Systemen generierte Warnungen reagieren –, sollten Sie sich mit dem Threat Hunting befassen.
Threat Hunting ist eine der wenigen Situationen, in denen es in Ordnung ist, »nach Ärger zu suchen«, statt auf spezifische Warnungen zu reagieren. Sie beginnen damit, eine Hypothese zu erstellen, zum Beispiel: »Vielleicht werde ich von Advanced Persistent Threat 12345 bedroht« oder »Eventuell ist jemand den geheimen Plänen zu meinem Raumschiff auf der Spur«. Dann durchforsten Sie die gesammelten Daten und tragen eventuell noch neue, zusätzliche Daten zusammen, um zu zeigen, dass die Hypothese entweder wahr oder falsch ist.
Sie haben die Logs und tun nützliche Dinge mit ihnen, zum Beispiel bekommen Sie Warnungen. Jetzt brauchen Sie einen Plan, was zu tun ist, wenn eine dieser Warnungen auf einen echten Vorfall hinweist. Abhängig von den Risiken in Ihrer Umgebung müssen Ihre Pläne nicht allzu umfassend sein, weil selbst ein kleines bisschen Planung schon enorm hilfreich sein kann.
Die erste Entscheidung, die Sie treffen müssen: Wann holen Sie sich Hilfe von außen? Das hängt stark von den (empfundenen) Risiken für Ihre Organisation, der Ernsthaftigkeit des Zwischenfalls und der Größe Ihres Sicherheitsteams ab. Aber selbst große, gut vorbereitete Organisationen brauchen eventuell Hilfe von außen, wenn es um kritischere Sicherheitsvorfälle geht. Eine kurze Suche wird viele Incident-Response-Firmen liefern, die bei der Reaktion auf Vorfälle helfen, und es ist eine gute Idee, sich ein paar von ihnen schon im Voraus angeschaut zu haben, falls Sie sie einmal brauchen.
Zudem können Sie darüber nachdenken, eine Cybersecurity-Versicherung abzuschließen – insbesondere wenn Sie nur ein kleines Team haben und nur wenig Reaktion von Ihnen selbst kommen kann. In manchen Fällen ist diese Versicherung in allgemeine geschäftliche Versicherungen eingeschlossen, allerdings schließen viele Versicherungen solche Vorfälle auch explizit aus. Wie bei jeder Versicherung müssen Sie sich genau durchlesen, was abgedeckt und was ausgeschlossen ist, da manche Versicherungen verbreitete Angriffsarten, etwa durch Social Engineering, ausschließen oder eine Erstattung von Schäden abgelehnt wird, weil die Sicherheitsanforderungen für den Versicherungsnehmer unklar sind. Aber wenn, können diese Versicherungen für einen Großteil oder alle Ausgaben bezahlen, die mit der Reaktion auf Vorfälle verbunden sind.
Die wichtigste Vorbereitung ist jedoch das weiter oben beschriebene Sammeln und Speichern von Logs, sodass Sie ausreichend aktuelle und historische Daten für Untersuchungen haben. Zudem brauchen Sie ein Team, einen Plan und ein paar Tools.
Das Incident Response Team3 hat die anstrengende Aufgabe, herauszufinden, was während eines Angriffs passiert, und den Vorfall so gut wie möglich einzudämmen. Als Erstes müssen Sie eine technische Incident-Response-Leitung und deren Vertretung finden, weil Aktivitäten zum Reagieren nicht darauf warten können, dass jemand aus dem Urlaub wiederkommt. Diese Personen werden dafür verantwortlich sein, interne Untersuchungen zu leiten und die Hilfe von außen zu koordinieren.
Sie brauchen ebenfalls eine Businessleitung und deren Vertretung, die sofort ansprechbar sind, um Businessentscheidungen zu autorisieren, zum Beispiel Systeme herunterzufahren oder Zahlungen zu tätigen. In kleineren Organisationen können die technische und die Businessleitung die gleichen Personen sein, aber Sie brauchen trotzdem mindestens eine verantwortliche Person und eine Vertretung.
Neben der Teamleitung brauchen Sie auch technische Spezialistinnen und Spezialisten aus den verschiedenen Bereichen, die in Ihrem Threat-Modell am wahrscheinlichsten angegriffen werden. Machen Sie sich beispielsweise Sorgen, dass jemand die Daten Ihrer Kunden aus Ihrer Cloud-Webanwendung abzieht, brauchen Sie Fachleute für das Netzwerk, den Webserver, die Datenbank und solche, die mit dem inneren Design und der Funktionsweise der Anwendung selbst vertraut sind. Sie wollen nicht mitten in einem Vorfall feststellen, dass Sie niemanden von den Leuten erreichen, die eine Komponente verstehen, in der das Problem vermutet wird.
Schließlich brauchen Sie auch noch diese Kontakte (samt ihren Vertretungen):
Alle diese Verantwortlichkeiten können sich auf unterschiedliche Personen verteilen, vielleicht liegen sie auch bei der weiter oben beschriebenen Leitung – entscheidend ist, dass es für jeden Bereich einen Hauptansprechpartner und eine Vertretung gibt.
Egal ob Sie ein Incident Response Team haben, das jederzeit verfügbar ist, oder nicht – Sie sollten auch das Äquivalent einer freiwilligen Feuerwehr haben. Finden Sie in Ihrer Organisation kompetente Personen, die für eine Incident Response trainiert werden können, und holen Sie sich aus dem Management die Genehmigung, diese Personen von der Arbeit abziehen zu können, der sie eigentlich nachgehen, um sich um einen dringenden Vorfall zu kümmern.
Ein paar weitere Anmerkungen zum Aufbauen und Betreuen eines Incident Response Team:
Haben Sie ein Incident Response Team, brauchen Sie ein paar Pläne, denen das Team folgen kann.
Ein Großteil der Empfehlungen im Abschnitt zu den Teams ist nicht cloudspezifisch – Ihre Pläne werden es aber sein. Sie müssen sich ein paar wahrscheinlichste Szenarien in Ihrer Cloud-Umgebung überlegen und Pläne dafür haben, wie Sie damit umgehen wollen.
Als Teil Ihrer Planung müssen Sie verstehen, wozu sich Ihr Cloud-Provider bei einem Sicherheitsvorfall verpflichtet hat. Wird er zusätzliche Logs bereitstellen oder forensische Images erstellen? Liefert er Informationen über Sicherheitsvorfälle? Sie wollen nicht erst mitten in der Reaktion auf einen Vorfall die Dienstleistungsbedingungen durchlesen, um herauszufinden, was Ihr Provider zu tun hat.
In vielen Fällen wird der Cloud-Provider dafür verantwortlich sein, auf Vorfälle zu reagieren, bei denen in dessen Cloud-Services eingebrochen wurde – er ist aber nicht zuständig für Vorfälle, die nur Ihre Anwendung betreffen. Es gibt allerdings ein paar Ausnahmen, wie zum Beispiel DDoS-Angriffe, bei denen der Cloud-Provider vielleicht mit Ihnen zusammenarbeitet, um Ihnen dabei zu helfen, den Angriff abzumildern – oder sogar den gesamten Netzwerkverkehr nach außen abschaltet, um zu verhindern, dass der Angriff andere Kunden des Providers beeinträchtigt! Es ist wichtig, im Voraus zu wissen, was Ihr Provider für Sie tun kann.
Sie brauchen auch zumindest ein kleines, vorab genehmigtes Budget für den Umgang mit Sicherheitsvorfällen. Das Team braucht keinen Blankoscheck, um alles zu kaufen, was es will, aber der Betrag sollte groß genug sein, um sinnvolle Dinge abzudecken, ohne erst einen möglicherweise langwierigen Beschaffungs- und Genehmigungsprozess durchlaufen zu müssen. Wenn es beispielsweise zum Plan gehört, eine Incident-Response-Firma zu kontaktieren, sollten zumindest erste Beratungsleistungen schon vorab genehmigt sein. Wenn laut Plan Menschen einzufliegen sind, müssen die Tickets abgedeckt sein. Versuchen Sie, Budget für Dinge einzuplanen und sich vorab genehmigen zu lassen, die in den ersten paar Stunden eines Vorfalls sehr wahrscheinlich benötigt werden.
Priorisierung ist ebenfalls ein wichtiger Teil der Planung zur Reaktion auf Vorfälle. Sie wollen auf einen versuchten Angriff nicht auf die gleiche Weise reagieren wie auf ein aktives Stehlen Ihrer Daten. Legen Sie zumindest ein paar Dringlichkeitsstufen für Sicherheitsvorfälle fest und erstellen Sie Richtlinien dazu, was im jeweiligen Fall zu tun ist. Es kann zum Beispiel Kategorien für »bestätigte, nicht erfolgreiche Attacken«, »bestätigte erfolgreiche Attacken ohne Datenverlust« und »bestätigte erfolgreiche Attacken mit Datenverlust« geben. Je weiter die Vorfälle auf der Rangliste nach oben rücken, wird sich auch Ihre Reaktion ändern.
Auch sollten Sie organisationsweite Richtlinien für das Melden vermuteter Sicherheitsvorfälle haben. Zudem sollte vorgegeben werden, dass man Untersuchungen nicht behindert. Das kann schon ein einfacher Text im Mitarbeiterhandbuch sein: »Vermuten Sie, dass ein unautorisierter User auf unsere Informationssysteme zugreift, rufen Sie bitte folgende Nummer an, um den Vorfall zu melden. Betroffene, aber nicht essenzielle Systeme dürfen Sie herunterfahren, aber löschen Sie keinerlei Systeme oder Daten und versuchen Sie auch nicht, zurückzuschlagen.«
Hatten Sie bisher keine Möglichkeit, Ihre Pläne zur Reaktion auf Vorfälle zu testen, können Sie über eine Planübung nachdenken. Das kann bei Ihnen in der Organisation geschehen, indem Sie sich ein plausibles Szenario ausdenken und es in einer Testumgebung durchspielen. Es gibt auch Firmen, die solche Szenarien, ausgedachte Nachrichten und andere Elemente bereitstellen und danach bewerten, wie der Plan umgesetzt wurde, um Schwächen darin aufzudecken. Ein mögliches Szenario wäre beispielsweise, dass gerade ein Angriff läuft und Sie in einen Lockdown-Modus gehen müssen. In einer Cloud-Umgebung kann dazu Folgendes gehören:
Zu Ihren Plänen zur Reaktion auf Vorfälle sollte auch gehören, Backups zu haben, die Sie zum Wiederherstellen von Daten und Funktionalität nutzen können. Stellen Sie sicher, dass sich die Backups in einem eigenen Cloud-Account befinden, der auch andere administrative Credentials als die Produktivdaten besitzt. Es gibt dokumentierte Fälle von Angriffen (https://oreil.ly/_AXmF), bei denen nicht nur die Produktivdaten, sondern auch alle Backups gelöscht wurden, die vom Produktiv-Account aus erreichbar waren.
Es ist ebenfalls wichtig, sich darüber im Klaren zu sein, wie lange das Wiederherstellen dauern wird. Manchmal haben Sie eine perfekte und sinnvolle Wiederherstellungsstrategie – nur muss leider die ganze Welt eine Woche angehalten werden. Sie müssen nicht während der Wiederherstellung die gesamte Funktionalität zu 100% anbieten können – es kann in Ordnung sein, Rechnungen später zu verschicken oder Einträge in IT-Systeme erst einmal auf einem Zettel aufzuschreiben. Zentrale Businessfunktionen müssen aber laufen.
Beim Entwerfen Ihrer Pläne zur Reaktion auf Vorfälle werden Sie erkennen, dass Ihr Team ein paar Tools benötigt, um diese Pläne umzusetzen. In einer klassischen Umgebung sind viele Incident Response Tools letztendlich Taschen mit Laptops, Kabeln und ähnlichen Materialien (die weiter oben erwähnten »Jump Bags«). Eine Cloud-Umgebung bietet von einigen dieser Dinge virtuelle Entsprechungen in der Cloud an.
Die erforderlichen Tools hängen davon ab, wie Ihre Umgebung aussieht und was Ihr Cloud-Provider anbietet, aber Ihr Team sollte vermutlich zumindest virtuelle Images mit Tools zur forensischen Analyse sowie einen Cloud-Account zum Erstellen einer forensischen Infrastruktur haben. Cloud-Accounts an sich sind im Allgemeinen kostenlos, wenn nichts in ihnen provisioniert wird, daher sollten Sie einen eigenen Cloud-Account für das Reagieren auf Vorfälle aktiv halten, der sich mit Ihrem Produktiv-Account verbinden kann. Manche Cloud-Provider bieten auch eine Dokumentation über das Durchführen von Untersuchungen und die digitale Forensik in ihren Umgebungen an, die auf spezifische Tools hinweisen.
Erstellen Sie detaillierte und getestete Prozeduren für die häufigsten Aufgaben bei der Reaktion auf Vorfälle. So wäre es beispielsweise sinnvoll, eine Prozedur für das Einsammeln forensischer Informationen aus dem Speicher und von den Festplatten einer kompromittierten virtuellen Linux-Maschine in einer Cloud-Umgebung zu haben. Solch eine Prozedur sollte genau beschreiben, welche Befehle auszuführen sind, wie zum Beispiel das Ausführen von LiME zum Erstellen eines Memors Dumps, das Generieren eines Hashs dieses Dumps, das Überprüfen des Dumps mit Volatility, das harte Abschalten der kompromittierten Maschine, um zu verhindern, dass böswillige Programme vor dem Reboot aufräumen können, und das Erstellen eines Snapshots der Festplatten.
Hier noch ein paar weitere Tools, die hilfreich sein können:
Sie sind jetzt gerade hoffentlich nicht mitten in einem aktiven Sicherheitsvorfall. Aber wenn – und wenn Sie kein Incident Response Team, keinen Plan, keine Tools oder Checklisten haben –, sollte Ihre erste Priorität darin bestehen, den Vorfall so weit wie möglich einzudämmen, ohne Beweise zu vernichten. Das geschieht meist durch eine Kombination aus dem Herunterfahren oder Abschotten von Systemen, dem Ändern von Passwörtern, dem Zurückziehen von Zugriffsberechtigungen und dem Blockieren von Netzwerkverbindungen. Gleichzeitig sollten Sie vermutlich eine Incident-Response-Firma hinzurufen und sich hier und da Notizen machen, um das nächste Mal besser vorbereitet zu sein.
Okay, Sie haben etwas gefunden, das wie ein echter Angriff aussieht. Was nun? Ihre Reaktion wird größtenteils davon abhängen, was die angreifende Person tut und wie Ihr Threat-Modell aussieht, aber es gibt ein paar Empfehlungen, die Ihnen helfen können.
Als Erstes sollte zumindest ein Teil Ihres Incident Response Team eine Triage durchführen. Sie wollen nicht 30 Leute für eine Malware-Infektion aus dem Bett holen, die sich nach ein paar Minuten Untersuchung als komplett gesichert herausstellt. Man reagiert leicht zu viel oder zu wenig, daher können hier vorher definierte Gefahrenstufen samt zugehörigen Reaktionsrichtlinien helfen.
Dann beginnen Sie mit der Umsetzung der Pläne und versuchen mithilfe einer Kill Chain oder einer Attack Chain herauszufinden, welche Ziele der Angriff wahrscheinlich hat.
Wie schon im Kasten zu Beginn des Kapitels erwähnt, ist eine der aktuell verbreitetsten Kill Chains die Lockeed Martin Cyber Kill Chain. Nach diesem Modell durchlaufen Bedrohungen folgende Phasen:
Erkunden
Es wird herauszufinden versucht, worauf man dort zugreifen kann und was für Schwachstellen dabei helfen können. Dazu kann alles Mögliche gehören: Google-Suchen, Stöbern im Müll, Social Engineering oder Port-Scans.
Bewaffnen
Der Angreifer bringt Malware mit, um die Schwachstellen auszunutzen. Bei ausgefeilteren Angriffen wird vielleicht etwas Eigenes geschrieben, aber weniger versierte Angreifer nutzen eventuell vorgefertigte Tools.
Ausliefern
Der Angreifer bringt das Opfer dazu, die Malware auszuführen – entweder per Angriff über das Netzwerk, per Zusenden als E-Mail oder auf anderem Weg.
Ausnutzen
Die Malware läuft und erhält unautorisierten Zugriff.
Installieren
Die Malware kann sich festsetzen, indem sie sich selbst so installiert, dass sie möglichst schlecht zu finden und zu entfernen ist. Häufig lädt das erste Stück Malware dazu einen zweiten Teil herunter und installiert diesen. Manchmal ist diese persistente Malware besser gewartet und aktualisiert als Ihr eigentliches Programm!
Command and Control
Die Malware setzt einen Kommunikationskanal auf, sodass der Angreifer sie aus der Ferne steuern kann – eine Remote Shell, eine ausgehende Webverbindung oder sogar das Lesen von Befehlen aus einem zugelassenen Cloud-Storage-Service. Nun wird der Zugriff auf Ihr System vielleicht zu einem guten Preis auf dem Schwarzmarkt an jemanden verkauft, der sich dafür interessiert.
Ausrichtung auf Ziele
Ein Angreifer (der nicht der gleiche wie die ursprüngliche Person sein muss) tut all das, was er tun will – Ihre Daten stehlen, Ihre Website verunstalten, Ihre Kunden angreifen, Geld erpressen und so weiter.
Andere populäre Ressourcen, wie MITRE ATT&CK, sehen die Aktionen der Angreifer als unterschiedliche Taktiken, die sie zur Erreichung ihrer Ziele einsetzen:
Initialer Angriff
Der Angreifer erhält erstmalig Zugriff – oft durch gestohlene Credentials oder das Ausnutzen einer ungepatchten Schwachstelle.
Ausführen
Der Angreifer führt böswilligen Code auf Ihren Systemen aus.
Persistieren
Der Angreifer installiert Code oder ähnliche Funktionalität, über den/die sie in Zukunft Zugriff erhalten wird.
Berechtigungen erweitern
Der Angreifer nutzt einen bestehenden Zugriff, um mehr Zugriff zu erhalten.
Verteidigung umgehen
Der Angreifer verbirgt sich vor den verteidigenden Teams.
Credentials erhalten
Der Angreifer nutzt Techniken zum Zugriff auf Passwörter oder API-Schlüssel.
Erkunden
Der Angreifer stöbert herum, sucht nach Schwachstellen oder Wegen zum Ziel.
Laterale Bewegung
Der Angreifer bewegt sich von einem Teil der Umgebung in einen anderen.
Einsammeln
Der Angreifer findet Informationen in Ihrer Umgebung.
Ausschleusen
Der Angreifer stiehlt Daten aus Ihrer Umgebung.
Auswirken
Der Angreifer fügt Ihren Systemen Schaden zu.
Die Taktiken von MITRE ATT&CK tendieren dazu, weniger linear und gleichzeitig detaillierter als die Phasen der Lockheed Martin Cyber Kill Chain zu sein, zudem führt das Framework spezifische Techniken auf, die zum Umsetzen dieser taktischen Ziele genutzt werden können. Egal an welcher Ressource Sie sich orientieren – es ist eine gute Idee, mit mindestens einer vertraut zu sein, sodass Sie eine grobe Vorstellung davon haben, was der Angreifer schon getan haben könnte und was er möglicherweise als Nächstes tut.
Sie haben Ihre Pläne, und Sie haben eine Idee vom Vorgehen und den Zielen beim Angriff. Jetzt ist es Zeit, zu reagieren. Ein verbreitetes Konzept bei der Reaktion auf Vorfälle ist die OODA-Schleife – observieren, orientieren, entscheiden (decide) und agieren:
Nach dem Agieren beginnt die Schleife von vorne – observieren, um zu sehen, was der Angreifer als Reaktion auf Ihre Aktivitäten getan hat, orientieren, entscheiden und wieder agieren. Diese Schleifen sollten recht kurz sein und fortlaufen, bis Ihre Beobachtungen ergeben, dass der Vorfall erledigt ist.
Sie werden so gut wie nie ausreichend vorbereitet sein. Jeder Vorfall wird auf seine Weise chaotisch sein, auch wenn Sie sich sehr gut vorbereitet haben. Nehmen Sie sich zwischendurch 15 Sekunden Zeit, um aufzuschreiben, was Sie daraus gelernt haben, weil Sie sich später nicht mehr genau daran erinnern werden.
Haben Sie keine Angst davor, eine Incident-Response-Firma hinzuzuholen, wenn Ihnen die Dinge zu entgleiten drohen oder wenn Sie keine Fortschritte machen. Die meisten angreifenden Personen haben viel mehr Erfahrung mit Angriffen als die verteidigenden Personen.
Cloud-Forensik mag Bilder der Fernsehserie CSI hervorrufen, aber leider ist die Realität etwas weniger spannend. Im Grunde wollen Sie nur eine Kopie von all dem machen, was wichtig sein könnte, und dieses dann mit Tools analysieren.
Es ist entscheidend, die Kopien auf eine dokumentierte und wiederholbare Art und Weise zu erstellen, sodass Sie immer zeigen können, dass Sie eine gute Kopie der Originaldaten haben, die nicht verändert wurde. Dazu gehört im Allgemeinen das Generieren eines Verifikationsstrings (eines kryptografischen Hashs), mit dem sich zeigen lässt, dass Sie eine Kopie der nicht defekten Daten haben. Ein kryptografischer Hash, wie zum Beispiel SHA-256, ist so designt, dass er schnell berechnet werden kann, es aber nahezu unmöglich ist, eine andere Zusammenstellung von Daten zu finden, die den gleichen Hash besitzt. Mit einer Kopie der Daten und dem kryptografischen Hash kann jeder schnell selbst einen Hash erzeugen und ihn mit dem Original vergleichen, um sicherzustellen, dass seine Kopie die gleiche wie die ist, die bei der initialen Untersuchung erstellt wurde. Zudem kann niemand (absichtlich oder unabsichtlich) die Daten ändern, ohne dass dies leicht bemerkt werden kann. Sie könnten auch die Originalkopie auf ein Read-only-Medium schreiben und jedes Mal einen bitweisen Vergleich durchführen, aber das würde deutlich länger dauern!
Die Beispielprozedur in »Tools« auf Seite 200 hat eine Möglichkeit gezeigt, forensische Images für den Speicher und die Festplatten virtueller Maschinen zu erzeugen, aber Sie brauchen für eine Untersuchung eventuell auch andere forensische Artefakte. Vielleicht möchten Sie Snapshots oder Backups von Datenbanken nutzen, um sie zu vergleichen und zu sehen, ob bei dem Angriff Änderungen an den Daten vorgenommen wurden. Auch können Sie sich dokumentierte Netzwerkpakete oder Traffic anschauen wollen, um herauszufinden, was eine angreifende Person oder eine Malware im Netzwerk so treibt.
Das mag wie selbstverständlich klingen, aber es ist oft schwerer, als man denkt, insbesondere wenn ein Angreifer schon eine Weile im System unterwegs war und administrativen Zugriff erhalten hat. Hoffentlich haben Sie sich an die Anweisungen in Kapitel 6 gehalten und eine interne Segmentierung umgesetzt, sodass der Angriff möglicherweise auf einen bestimmten Teil des Netzwerks beschränkt ist.
Häufig wird hier reagiert, indem die Passwörter und API-Schlüssel von jedermann (einschließlich der Automation) zurückgesetzt werden, was für die normalen Abläufe disruptiv sein kann sowie ein- und ausgehenden Netzwerkzugriff unterbinden kann.
Sie sollten vorbereitete Tools und Prozesse zum schnellen und vollständigen Blockieren des Zugriffs haben.
Wenn Sie die Netzwerkkommunikation noch nicht beim Blockieren des unautorisierten Zugriffs heruntergefahren haben, müssen Sie eventuell immer noch ausgehende Kommunikation stoppen, um Verbindungen zu unterbrechen, die Angreifer zu Command-and-Control-Servern aufgesetzt haben oder über die weiterhin Daten abgezogen werden.
Sie haben den Angriff entdeckt und sind der Meinung, ihn auch gestoppt zu haben – jetzt müssen Sie aufräumen und sicherstellen, dass nichts zurückbleibt, mit dem der Angreifer wieder in Ihre Systeme gelangen kann.
Der weitaus einfachste und effektivste Weg zum Wiederherstellen ist aus IT-Sicht das erneute Deployen aller betroffenen Systeme. Auch das ist wieder in der Cloud ein bisschen einfacher, weil Sie keine neue physische Hardware kaufen müssen – Ihr Cloud-Provider wird Kapazitäten besitzen. Jedes kompromittierte Cloud-System sollte neu erstellt und der Produktiv-Traffic sollte zu den neuen Systemen umgelenkt werden. Alle betroffenen Workstations sollten gelöscht und aus bekannt guten Images neu aufgesetzt werden. Um mit den unsterblichen Worten von Ellen Ripley aus Alien zu sprechen: »Ich sage, wir heben ab und zerstören die gesamte Anlage aus dem Orbit – das ist der einzige Weg, um sicher zu sein.«
Wenn das nicht möglich ist, brauchen Sie die Zustimmung von ganz oben, dass Sie ein substanzielles Risiko in Kauf nehmen, weil Sie Systeme weiter betreiben, auf denen ein Angreifer eine Zeit lang Zugriff hatte. Sie können Malware-Scanner laufen lassen, das Netzwerk und die Prozesse besonders genau im Auge behalten, um Anzeichen für eine Kompromittierung zu erkennen, und andere Sicherheitsmaßnahmen umsetzen, aber ein einzelner angepasster Registry-Eintrag kann schon ausreichen, um den Angreifer wieder in Ihr System gelangen zu lassen, und eine einzelne übersehene Malware kann sich eventuell nach außen verbinden und einen einfachen Weg hinein ermöglichen.
Eventuell müssen Sie aus rechtlichen oder vertraglichen Gründen Ihre Kunden informieren oder den Einbruch entsprechenden Behörden melden.
Selbst wenn Sie nicht dazu verpflichtet sind, die Welt zu informieren, werden Sie das vielleicht trotzdem tun wollen, um einen PR-Albtraum zu verhindern, wenn das Ganze doch herauskommt. Aus offensichtlichen Gründen haben wir keine guten Metriken dazu, wie oft sich alles unter der Decke halten lässt, aber es gibt ein paar bekannte Beispiele für nicht erfolgreiche Versuche, zum Beispiel Yahoo!, Cathay Pacific oder Uber.
Sobald alle ausreichend Schlaf bekommen haben, sollten Sie sich anschauen, was für Lehren sich aus dem Vorfall ziehen lassen, und die Zusammenstellung Ihres Teams, die Pläne, Prozeduren, Tools und Checklisten anpassen, damit es nächstes Mal besser läuft. Hoffentlich haben Sie sich während des Vorfalls Notizen gemacht, auf die Sie nun zurückgreifen können.
Das Aufbauen eines vollständigen Incident Response Team und eines zugehörigen Prozesses ist eine ziemlich umfangreiche Aufgabe. Ich habe hier zwar die wichtigsten Punkte für Cloud-Umgebungen behandelt, empfehle aber weitere Lektüre, zum Beispiel AT&Ts Insider’s Guide to Incident Response (https://oreil.ly/w11VM) und NIST SP 800-61 (https://oreil.ly/GkXaN).
Wie bei anderen Geschäftsprozessen gilt auch hier: Wenn Sie keine Metriken zu Ihren Erkennungs-, Reaktions- und Wiederherstellungsaktivitäten vorlegen können, ist es schwierig festzustellen, ob Sie sich verbessern.
Hier ein paar Beispielmetriken, die Sie vielleicht aufzeichnen sollten:
Erkennung
Anzahl der erfassten Events pro Monat, Anzahl der pro Monat ausgelösten Warnungen, Anteil der Warnungen, die bestätigte Vorfälle sind, Anteil der Warnungen, die falsch-positiv sind.
Reaktion
Dauer vom Auslösen einer Warnung bis zu einem Begutachten, Dauer von einer Bestätigung eines Vorfalls bis zu seinem Abschluss.
Wiederherstellung
Dauer, bis betroffene Systeme neu deployt sind.
Gesamt
Geschätzte Kosten jedes Vorfalls, einschließlich Zeit, Ausgaben und Schaden an der Reputation.
Im Folgenden finden Sie eine Liste mit Beispielen für Lösungen im Bereich des Erkennens, Reagierens und Wiederherstellens im Cloud-Umfeld. Wie in Kapitel 5 ist keines dieser Tools besonders empfehlenswert, nur weil ich es hier aufgeführt habe, oder besonders schlecht, weil ich es nicht erwähne. Es sollen lediglich Beispiele für verschiedene Tools sein, die aktuell oft zum Einsatz kommen:
Schauen wir uns ein letztes Mal unsere Beispielanwendung an – jetzt in Bezug auf Erkennung und Reaktion. Unser Threat-Modell beinhaltet in diesem Fall große Mengen an Daten über unsere Kunden in unserer Datenbank und einen möglichen Angreifer, der versucht, diese Daten zu stehlen und im Dark Web zu verkaufen. Beachten Sie, dass unser Schwerpunkt etwas anders liegen würde, wenn wir uns vor allem Sorgen um den Ruf unserer Marke machen würden und es unserer Meinung nach wahrscheinlicher wäre, dass jemand versucht, unsere Webseiten zu verunstalten, um uns schlecht dastehen zu lassen.
In Abbildung 7-2 sehen Sie kritische Systeme, die sicherheitsbezogene Events loggen, und den Umgang des Sicherheitsteams damit.
Abbildung 7-2: Beispielanwendung mit Erkennungsmöglichkeiten
Die blauen Elemente (weißer Text auf dunkelgrauem Hintergrund, wenn Sie das Ganze in Graustufen sehen) stehen für die funktionalen Teile der Anwendung, die orangefarbenen Elemente (gestrichelte Rahmen) sind Cloud-Provider oder Orchestrierungssysteme zum Erstellen der Anwendungsinfrastruktur, und die grünen Elemente (schwarzer Text auf hellgrauem Hintergrund) stehen für unser Auditing-Framework. Zur Erinnerung – das sind unsere Sicherheitsziele für die Anwendung beim Erkennen und Reagieren:
Schauen wir uns zuerst die Logs an, die von unseren Schutzsystemen während der normalen Verwendung des Systems erstellt wurden. Hier erzeugen IDS/IPS-, WAF- und Firewall-Systeme Logs, Warnungen und Metriken, die zeigen, ob das System genutzt oder ausgenutzt wird. Ein paar Beispiele:
Jetzt schauen wir uns die Logs an, die von unserer Anwendung und der Infrastruktur bei normalem Einsatz erzeugt werden. Diese Logs hängen stark davon ab, was die Anwendung tut und welche Komponenten genutzt werden, um sie aufzusetzen. Zu Illustrationszwecken werde ich annehmen, dass viele verschiedene Technologien zum Einsatz kommen, auch wenn das nicht unbedingt ein gutes Design für eine echte Anwendung sein muss. Hier ein paar Beispiele:
Wir müssen auch die Arbeit der Administratoren und Administratorinnen monitoren. Das soll, wie bereits gesagt, nicht unbedingt heißen, dass wir ihnen nicht trauen! Wir erkennen nur an, dass bei einem Angriff auf irgendeine ruchlose Art und Weise gültige Administrations-Credentials entwendet worden sein könnten und wir das erkennen und darauf reagieren können müssen.
Aus pädagogischen Gründen gehen wir von folgenden Annahmen aus:
In Abbildung 7-2 sieht man, dass die toxischen Session-Recording-Logs (also solche, die möglicherweise Secrets enthalten) und die normalen, gesäuberten Logs in getrennten Systemen gespeichert werden. Das dient dazu, den Zugriff auf die toxischen Logs auf so wenige Administratorinnen und Administratoren wie möglich beschränken zu können. Speichern Sie beide Arten von Logs auf demselben System ab, müssen Sie sicherstellen, dass alle Administratoren und Administratorinnen dieses Systems dazu berechtigt sind, die toxischen Logs einzusehen, und dass der Zugriff darauf sorgfältig kontrolliert wird.
Schauen wir uns nun unsere Audit-Infrastruktur an. In dieser Beispielanwendung sind der Log-Aggregator, der Metrik-Aggregator und der SIEM alle als getrennte Systeme dargestellt, aber viele Produkte und Services überlappen sich in einem oder all diesen Bereichen.
Sie haben vielleicht auch zusätzliche Produkte und Services im Einsatz, die Warnungen an den SIEM oder direkt an das Sicherheitspersonal schicken. Eventuell nutzen Sie ja ein Network Traffic Analysis System, das auf ungewöhnliche Muster im Netzwerk-Traffic achtet, oder Endpoint-Agenten zur Erkennung und Reaktion, die Informationen darüber sammeln, was Ihre Server und Workstations so treiben.
Schauen wir uns diese Systeme genauer an:
Der Log-Aggregator sollte administrativ getrennt vom überwachten System sein, sodass bei einem Angriff mit Zugriff auf eines der überwachten Systeme nicht auch noch mit den gleichen Credentials auf den Aggregator zugegriffen und Spuren verwischt werden können. Ich empfehle, die Audit- und Logging-Komponenten für eine bessere Trennung in einem eigenen Auditing-Cloud-Account unterzubringen.
Die Logs können sicherheitsrelevante und nicht sicherheitsrelevante Informationen enthalten, aber im Allgemeinen sollten nur sicherheitsrelevante Logs in den SIEM fließen.
In dieser Beispielanwendung schauen wir uns nun alles an, was unsere Schutztools als Problem markieren oder wo sie ungewöhnlichen Traffic oder ungewöhnliche Aktivitäten in den Anwendungskomponenten beobachten. Wir schauen, was unser Administrationsteam so tut (oder Angreifer, die sich als Mitglieder des Teams ausgeben), und sammeln Beweise für forensische Analysen und Audits. Mit diesen Tools und Prozessen haben wir nun eine gute Chance, einen Angriff zu erkennen.
Auch wenn Sie überall für sinnvollen Schutz gesorgt haben, sind Ihre Sicherheitsmaßnahmen nur dann vollständig, wenn Sie Angriffe erkennen, auf sie schnell und effektiv reagieren und Ihre Umgebung danach auch wiederherstellen können.
Beim Erkennen geht es nicht nur um Logging – Sie können nicht einfach nur jede Log-Quelle aufsaugen und hoffen, dass sie aus Sicherheitsaspekten nützlich ist. Sie müssen sich überlegen, was angesichts Ihres Threat-Modells und Ihrer Umgebung wichtig ist. In so gut wie allen Umgebungen werden Sie auch privilegierte User haben, und es ist ebenso wichtig, deren Aktivitäten im Auge zu behalten. Stellen Sie sich selbst die Frage: »Wenn etwas wahrscheinlich Schlimmes passieren wird – werde ich es erkennen?« Wenn Sie das nicht können, werden Sie vermutlich zusätzliche Informationen erfassen oder sicherstellen müssen, dass die schon eingesammelten Informationen dort landen, wo sie sichtbar sind. Ein ausgezeichneter Indikator für verbesserungswürdige Erkennungsfähigkeiten ist ein Pentest: Wenn Sie nicht bemerken, dass die Pentester Ihre Systeme angreifen, müssen Sie besser werden.
Haben Sie sich überlegt, was wichtig zu beobachten ist, müssen Sie sicherstellen, dass Sie diese Logs und Metriken effektiv einsammeln und durchsuchen. In größeren Umgebungen bedeutet das häufig den Einsatz eines SIEM, der Ihnen dabei hilft, die großen Datenmengen zu durchforsten. Achten Sie darauf, dass Sie die Zeit auf Ihren Systemen synchron halten, und führen Sie simulierte Angriffe durch, um sicherzustellen, dass Sie echte Angriffe bemerken.
Schließlich müssen Sie sich darauf vorbereiten, mit einem erfolgreichen Angriff umzugehen. Stellen Sie rechtzeitig ein Team auf, machen Sie Pläne und bereiten Sie Tools vor. Geschieht ein Angriff, muss Ihr Team wissen, wie Angriffe meist ablaufen, wie sich die Umgebung absperren und danach säubern lässt – und wann der richtige Moment ist, sich Hilfe von außen zu holen.
Stellen Sie Ihre Umgebung wieder her, ist es sehr riskant, zu versuchen, Ihre Systeme zu säubern. Hat jemand einmal administrativen Zugriff erhalten, können Sie nicht sicher sein, ob Sie alles entfernen konnten, weil es für Malware sehr viele Möglichkeiten gibt, sich zu verstecken. Am weitaus sichersten ist es, jedes kompromittierte System zu löschen und aus Backups wiederherzustellen, oder es ganz zu entfernen und ein neues zu provisionieren. Zum Glück ist das in der Cloud einfach! Unterschätzen Sie das Risiko nicht, in einem System aufräumen zu wollen – eine einzelne Zugriffsberechtigung, ein einziger Registry-Eintrag unter Windows oder irgendeine andere, schwer zu findende Hintertür kann dafür sorgen, dass der Angreifer einfach wieder hereinspaziert.
Cloud Computing ist ein wunderbares und innovatives Modell, das es vielen Menschen mit tollen Ideen ermöglicht hat, mit wenig Kapitaleinsatz schnell loszulegen und dann zu wachsen. Wir haben dieses Buch mit dem Vorstellen verschiedener Sicherheitskonzepte begonnen, uns dann die Wege vorgenommen, auf denen sich Daten und Assets in der Cloud schützen lassen und wie wir Schutzmaßnahmen umsetzen (zum Beispiel eine gute Zugriffsverwaltung, Vulnerability Management und Netzwerksicherheit). Schließlich haben wir uns angeschaut, wie wir Sicherheitsvorfälle erkennen und darauf effektiv reagieren können.
Dies ist ein unglaublich umfangreiches und sich schnell veränderndes Gebiet. Mein Ziel war es, so viele nützliche Informationen, verständlich aufbereitet, anzubieten, dass Sie selbst loslegen können und die richtigen Fragen stellen, um mehr zu lernen. Ich hoffe, Sie haben die Lektüre dieses Buchs genossen, und es hat Ihnen dabei geholfen, die Sicherheit Ihrer Cloud-Umgebungen zu verbessern. Viel Glück!
