Für Cloud-Detection and -Response (CDR) gilt es – wieder einmal – zunächst zu unterscheiden, um welches Cloud-Service-Modell es geht:
- Infrastructure as a Service (IaaS): Der Cloud-Provider stellt Storage, Networking und Rechenleistung bereit.
- Platform as a Service (PaaS): Der Cloud-Provider stellt zusätzlich auch virtuelle Maschinen, Betriebssystem und Laufzeitumgebung bereit.
- Software as a Service (SaaS): Der Cloud-Provider stellt darüber hinaus auch Applikationen bereit.
Generell gilt in der Cloud allerdings ein Modell der geteilten Verantwortung: Der Cloud-Provider verwaltet die Sicherheit der Cloud, die Nutzer sind für die Sicherheit innerhalb der Cloud verantwortlich. Letztere haben dabei die Kontrolle über ihre Sicherheitsimplementierung – einschließlich des Zugriffs auf verschiedene Tools und Services.
Problemfall Konfiguration
Eine der größten Herausforderungen bei allem, was in die Cloud wandern soll, ist seit jeher die richtige Konfiguration. Das ist bei Cloud-Providern in den letzten Jahren zwar deutlich einfacher geworden, da es automatische Checks und Empfehlungen gibt, die bei den großen Hyperscalern oft über kostenpflichtige Zusatzprodukte wie Guard Duty oder Microsoft Cloud Defender angeboten werden. Dennoch ist die Konfiguration der Zugriffsrechte nach wie vor fehleranfällig: Sie gestaltet sich in der Praxis deutlich komplexer als beispielsweise die einfache Freigabe von AWS S3-Buckets. Das Risiko, hier etwas falsch zu machen, ist durchaus gegeben.
Ähnlich wie bei in eigener Hoheit verwalteten Systemen besteht in der Cloud die Gefahr, dass Angreifer durch eine unstimmige Access-Konfiguration Zugriff erhalten. 100%ige Prävention ist schon durch den Faktor Mensch illusorisch: Auch wenn eine initial sichere Access-Konfiguration die Zugriffsmöglichkeiten korrekt beschränkt, werden die Konfigurationen typischerweise über den Lebenszeitraum der Services hinweg oft angepasst – und dabei entstehen schnell Unstimmigkeiten oder Fehler. Sobald ein Angreifer jedoch an die Identität eines berechtigten Users oder sogar eines Super-Users kommt, stehen die Tore weit offen.
Konsequente Überwachung
Daher gilt es, ähnlich wie bei selbst verwalteten Services, die Log-Dateien des Cloud-Providers konsequent auszuwerten. Zusatzangebote unterstützen bei der Erkennung abnormaler und potenziell maliziöser Aktivitäten, können jedoch die Bewertung, ob eine Aktion wirklich „bösartig“ ist, nicht übernehmen. Wenn beispielsweise eine API aus Indien aufgerufen wird und auf Cloud- Ressourcen zugreift, kann der Cloud-Provider lediglich die Information liefern, dass diese Aktion gerade zum ersten Mal stattfindet – nicht aber entscheiden, ob das problematisch ist. Das bleibt auch künftig Aufgabe des Cloud-Users beziehungsweise der IT-Abteilung seines Unternehmens.
Für die Auswertung der Log-Dateien gibt es zwei Möglichkeiten: ein cloudnatives SIEM-System oder die Übernahme der Cloud-Logs in bereits vorhandene Systeme im eigenen Rechenzentrum (RZ). Egal, welches SIEMModell man nutzt: Bestimmte Konfigurationsregeln und Use-Cases sind darin oft bereits definiert und können auf potenziell maliziöse Aktivitäten hinweisen – aber das Fine- Tuning und die Implementierung einer flächendeckenden Überwachung obliegt dem Cloud-Plattform-User!
Besonders spannend wird das bei hybriden Infrastrukturen (on Premises/Cloud/Multi-Cloud): Für die Auswertung der entsprechenden Alerts braucht es entsprechend geschulte Security-Analysten, die Aktionen ob ihrer Gefährlichkeit bewerten. Incident-Response (IR) erfordert ein Verständnis für die Cloud-Infrastruktur und die dort genutzten Cloud-Services – wie Storages, Databases (DBs), Virtual Machines (VMs), Stateless-Functions, Virtual Networks, Machine-Learning-Models (ML), Hilfsfunktionen wie Speech2Text oder auch ganze Apps und Higher-Level-Services (z. B. Callcenter-Lösungen bei den Hyperscalern).
Schaffen es Angreifer – beispielsweise durch Identitätsdiebstahl – Zugang zu erlangen, ist die Frage: Was ist die „transitive Zugriffshülle“ des Angreifers in der Cloud? Sprich: Was kann oder konnte der Angreifer alles verändern? Oft ist das bei stark verzahnten Services schwer zu bestimmen – Unternehmen ohne ein entsprechendes Security-Team sind gut beraten, hierfür die Dienste von Security-Experten in Anspruch zu nehmen.
Spezialisten für Alarmauswertungen
Das Thema CDR lässt sich auf Wunsch auch komplett outsourcen – allerdings muss der gewählte Partner über ein sehr tiefes Verständnis für die IT-Prozesse des Unternehmens verfügen! Der Aufbau des Wissens über die Prozesse, die in einer Organisation den IT-Normalzustand abbilden, kann durchaus einen längeren Zeitraum beanspruchen. Ohne dieses Wissen und eine Baseline ist es sehr schwer, die Bandbreite möglicher maliziöser Aktivitäten zu erkennen. Das gilt allerdings auch, wenn das Unternehmen den Job selbst erledigt.
Wenn eine Abweichung von der Basislinie auftritt, zum Beispiel durch eine Fehlkonfiguration oder veränderte externe Faktoren, muss die Situation näher untersucht werden. Um dies erfolgreich zu tun, müssen die grundlegenden Konzepte der Reaktion auf Sicherheitsvorfälle in der Cloud-Umgebung und die Anforderungen an die Vorbereitung und Schulung von Cloud-Teams „stehen“, bevor Sicherheitsprobleme auftreten: Es ist wichtig zu wissen, welche Zugriffskontrollen und Funktionen existieren, um auf identifizierte Angreiferaktivitäten schnell und effizient zu reagieren. Viele Response-Aktivitäten lassen sich in Cloud-Infrastrukturen gut automatisieren, sodass sich sehr gute Reaktionsgeschwindigkeiten und -konsistenz erreichen lassen, aber gleichzeitig besteht auch das Risiko, mit automatischen, zu weit gefassten Response- Mechanismen auch unbetroffene Cloud-Ressourcen außer Betrieb zu nehmen.
Darüber hinaus sollten natürlich (auch) bei der Verwendung von Cloud-Services die aktuellen Compliance- Anforderungen und gesetzliche Vorschriften bekannt sein, um ein umfassendes Sicherheitsframework zu entwickeln.
Die Reaktion auf Sicherheitsvorfälle kann komplex sein. Daher ist ein iterativer Ansatz empfehlenswert: Mit den wichtigsten Sicherheitsdiensten beginnen, grundlegende Erkennungs- und Reaktionsfähigkeiten aufbauen und Playbooks entwickeln, um eine erste Bibliothek von Mechanismen zur Reaktion auf Vorfälle zu erstellen, die man dann nach und nach verbessern kann.
CDR in der Praxis
Bevor sich ein Unternehmen mit der Reaktion auf Sicherheitsvorfälle in der Cloud beschäftigt, sollten sich die Verantwortlichen mit den relevanten Standards für die Cloud-Sicherheit vertraut machen – die meisten Cloud-Provider bieten dafür einschlägige Whitepaper an. Wichtigstes Rahmenwerk für die Reaktion auf Vorfälle sind die Standards und Best Practices für die Reaktion auf Sicherheitsvorfälle aus dem „Computer Security Incident Handling Guide“ SP 800-61 r2, der vom National Institute of Standards and Technology (NIST) erstellt wurde (https:// doi.org/10.6028/NIST.SP.800-61r2).
Es ist wichtig zu verstehen, wie sich die Sicherheitsabläufe und die Reaktion auf Vorfälle in der Cloud unterscheiden – um dort eine effektive Response-Fähigkeit aufzubauen, müssen die Abweichungen von der üblichen Reaktion vor Ort und deren Auswirkungen auf das IRProgramm klar sein:
- Vorbereitung: Das CDR-Team ist darauf vorzubereiten, Vorfälle innerhalb der Cloud zu erkennen und darauf zu reagieren. Dafür ist es nötig, die Detection-Controls zu aktivieren und den passenden Zugriff auf die notwendigen Tools und Cloud-Services zu überprüfen. Außerdem müssen erforderliche manuelle und automatisierte Playbooks vorbereitet werden, um angemessene Reaktionen zu gewährleisten.
- Operatives Vorgehen: Sicherheitsereignisse und potenzielle Vorfälle sind gemäß den NIST-Phasen der Vorfalls-Reaktion zu bearbeiten: Erkennen, Analysieren, Eindämmen, Beseitigen und Wiederherstellen.
- Post-Incident-Aktivitäten: Vorfälle und die Reaktionen darauf sollten laufend analysiert werden, um aus den Ergebnissen Verbesserungen für die Zukunft abzuleiten und so präventive und reaktive Maßnahmen in der Cloud zu verbessern.
Cloud-Prinzipien für die Reaktion auf Vorfälle
Während die Kenntnis über die allgemeinen Prozesse und Mechanismen zur Pflicht gehört, ist es sehr empfehlenswert, sich mit einer Reihe weiterer spezifischer Designziele vertraut zu machen:
- Festlegung von Reaktionszielen: Das Ziel der Reaktion auf einen Vorfall ist gemeinsam mit Interessenvertretern, Rechtsberatern und der Unternehmensleitung festzulegen. Zu den allgemeinen Zielen gehören die Eindämmung und Entschärfung des Problems oder der Bedrohung, die Wiederherstellung betroffener Ressourcen, die Sicherung von Daten für die Forensik, die Rückkehr zu bekannten sicheren Abläufen und schließlich das Lernen aus Vorfällen.
- Response über die Cloud: Reaktionsmuster innerhalb der Cloud sind an derjenigen Stelle zu implementieren, wo das Ereignis auftrat und sich die Daten befinden.
- Vorhandene und benötigte Daten: Protokolle, Ressourcen, Snapshots und andere Beweise sind in einem zentralen Cloud-Konto für die Reaktion zu speichern. Dabei sollte man sinnvollerweise Tags, Metadaten und Mechanismen verwenden, die Aufbewahrungsrichtlinien durchsetzen. Zudem muss bekannt sein, welche Dienste genutzt werden, um die Anforderungen für die Untersuchung dieser Dienste zu ermitteln.
- Mechanismen zur Neuverteilung: Wenn eine Sicherheitsanomalie auf eine Fehlkonfiguration zurückzuführen ist, kann die Behebung so einfach sein wie die Beseitigung der Abweichung durch eine Neuverteilung von Ressourcen mit der richtigen Konfiguration.
- Automatisieren, wo möglich: Wenn Probleme auftreten oder sich Vorfälle wiederholen, sind Mechanismen zur programmgesteuerten Sichtung und Reaktion auf häufige Ereignisse zu entwickeln. Stichworte sind hier: „Infrastructure as Code“ (IaC) und Disposable IT-Assets/- Services. Dann lassen sich menschliche Reaktionen für einzigartige, komplexe oder sensible Vorfälle nutzen, bei denen Automatisierungen nicht ausreichen.
- Skalierbare Lösungen wählen: Die Skalierbarkeit des Cloud-Computing-Ansatzes eines Unternehmens sollte man immer berücksichtigen. Dafür sind Erkennungs- und Reaktionsmechanismen zu implementieren, die über die gesamte Unternehmensumgebung hinweg skalierbar sind, um die Zeit zwischen Erkennung und Reaktion zu verkürzen.
- Prozesse optimieren: Lücken in Prozessen, Werkzeugen oder Kenntnissen der Mitarbeiter:innen sind proaktiv zu identifizieren und zu beheben. Simulationen sind eine gute Methode, um dies zu ermöglichen.
Hauptunterschiede
Die Reaktion auf Vorfälle ist ein wesentlicher Bestandteil einer Cybersicherheits-Strategie, sowohl vor Ort als auch in der Cloud. Sicherheitsprinzipien wie „Least Privilege“ und „Defense in Depth“ zielen darauf ab, die Vertraulichkeit, Integrität und Verfügbarkeit von Daten vor Ort sowie in der Cloud zu schützen. Dazu gehören aber auch die Aufbewahrung von Protokollen, die Auswahl von Warnmeldungen auf der Grundlage von Bedrohungsmodellen, das Erarbeiten von Playbooks und die Integration von SIEM. Die Unterschiede beginnen, wenn sich Nutzer mit der Architektur und Entwicklung dieser Muster in der Cloud auseinandersetzen:
Sicherheit als geteilte Verantwortung
Die Verantwortung für Sicherheit und Compliance wird von Cloud-Provider und Nutzer gemeinsam getragen – jeder ist für seinen Teil verantwortlich. Die geteilte Verantwortung entlastet den Kunden, da der Provider den „unteren“ Teil des Technolgie-Stacks – also die Komponenten von Virtualisierungsebene bis hin zur physischen Sicherheit der Einrichtungen – betreibt, verwaltet und kontrolliert. Der Nutzer ist hingegen für den gesamten „oberen“ Teil des Technologie-Stacks – also den genutzten Services – verantwortlich.
In dem Maße, wie sich die gemeinsame Verantwortung in der Cloud verändert, ändern sich auch Nutzer- Optionen für die Reaktion auf Vorfälle: Dabei ist der Nutzer für die Erkennung und Reaktionen typischerweise allein verantwortlich, der Cloud-Provider stellt nur die notwendigen Werkzeuge. Eine konkrete Hilfe des Cloud- Providers bei der Erkennung und Reaktion auf Angriffe in der „eigenen“ IT – gehostet beim Cloud-Provider – ist für gewöhnlich nicht Teil des Leistungsumfangs eines Cloud-Providers.
Neben der Beziehung zum Cloud-Provider gibt es möglicherweise noch andere Einheiten, die Verantwortung tragen – unter anderem Organisationseinheiten, die für bestimmte Aspekte des Betriebs verantwortlich sind. Möglicherweise sind auch weitere Cloud-Technologie- Partner oder sogar mehrere Cloud-Provider zu berücksichtigen.
Cloud-Service-Domäne
Aufgrund der Unterschiede in der Sicherheitsverantwortung bei Cloud-Diensten wurde bei einigen Providern wie beispielsweise AWS eine neue Ebene für Sicherheitsvorfälle eingeführt: die sogenannte Service-Domäne, die unter anderem das Cloud-Konto des Nutzers, IAMBerechtigungen, Ressourcen-Metadaten und Abrechnung umfasst. Sie unterscheidet sich von der Vorfallsdomäne durch die Art der Reaktion: Diese erfolgt innerhalb der Service-Domäne in der Regel durch Prüfung und Ausgabe von API-Aufrufen und nicht durch klassische host- und netzwerkbasierte Reaktionen. In der Servicedomäne gibt es schließlich keine Interaktion mit dem Betriebssystem einer betroffenen Ressource.
APIs für die Bereitstellung von Infrastruktur
Ein weiterer Unterschied ergibt sich aus der Cloud-Eigenschaft des On-Demand-Self-Service: Nutzer interagieren mit der Cloud mithilfe einer RESTful API über öffentliche und private Endpunkte von vielen weltweiten Standorten aus – und können auf diese API mit ihren Cloud-Anmeldeinformationen zugreifen. Im Gegensatz zur Zugriffskontrolle vor Ort sind diese Anmeldeinformationen aber nicht unbedingt an ein Netzwerk oder eine Microsoft-Active-Directory-(AD)-Domäne gebunden, sondern stattdessen mit einem Identity-and-Access-Management-( IAM)-Prinzipal innerhalb eines Cloud-Kontos verknüpft.
Dynamische Natur der Cloud
Die Cloud ist dynamisch – sie ermöglicht es, schnell Ressourcen zu erstellen und zu löschen, durch eine automatische Skalierung können diese je nach Anstieg des Datenverkehrs auf- und abgebaut werden. Bei kurzlebigen Infrastrukturen und schnellen Änderungen kann es vorkommen, dass eine im Rahmen von CDR untersuchte Ressource nicht mehr existiert oder geändert wurde. Das Verständnis der flüchtigen Natur von Cloud- Ressourcen und wie sich deren Erstellung und Löschung nachverfolgen lässt, ist daher wichtig für die Analyse von Vorfällen. Wichtige Schlagwörter sind hier unter anderem „Container“ und „Container-Orchestrierung“.
Datenzugriff
Der Datenzugriff ist in der Cloud ebenfalls anders: Analysten können sich nicht an einen Server „anschließen“, um die Daten zu sammeln, die sie für eine Sicherheitsuntersuchung benötigen – diese Daten müssen vielmehr über die Leitung und durch API-Aufrufe gesammelt werden.
Automatisierung
Damit Nutzer die Vorteile der Cloud-Nutzung voll ausschöpfen können, muss ihre Betriebsstrategie die Automatisierung umfassen. „Infrastructure as Code“ ist ein Muster für hocheffiziente automatisierte Umgebungen, in denen Cloud-Services mithilfe von Code bereitgestellt, konfiguriert, geändert und gelöscht werden. Das führt dazu, dass die Implementierung der IR hochgradig automatisiert ist, was menschliche Fehler vermeidet. In der Cloud ist Automatisierung unerlässlich – dafür aber in der Regel auch einfacher als im eigenen Rechenzentrum.
Provider-Auswahl
Bei der Auswahl eines sicheren Cloud-Providers helfen Ratgeber, wie sie beispielsweise das BSI herausgibt (siehe www.bsi.bund.de/cloud.html) – dabei spielen Datenschutzaspekte eine vorrangige Rolle. Aus diesem Grund bieten die großen Provider an, kritische Services und Daten in europäischen Cloud-Rechenzentren zu verarbeiten und nicht global zu verteilen.
Auch bezüglich weiterer Sicherheitskriterien liefert das BSI in Form des Cloud-Computing-Compliance- Criteria-Catalogue (C5-Kriterien) einschlägige Richtlinien für Cloud-Provider: Um eine C5-Zertifizierung zu erhalten, müssen Anbieter einerseits für einen sicheren Betrieb sorgen und andererseits auch bestimmte Security-Kriterien erfüllen. Die großen Provider haben ein entsprechendes Label – bei spezielleren Cloud-Providern sollten potenzielle Kunden das im Vorfeld checken.
Dr. Sebastian Schmerl ist Director Security Services EMEA bei Arctic Wolf sowie ständiges Mitglied in der „EU/ENISA – Working Group on Security Operation Centres“ und stellvertretender Vorstandssprecher der Fachgruppe SIDAR der Deutschen Gesellschaft für Informatik (GI e.V.).
