Cloud Security Incident Response in der hybriden Cloud

Autor / Redakteur: Hendrik Andreas Reese * / Florian Karlstetter

Die Abwehr gezielter, komplexer ausgeklügelter Angriffe ist schon on premise eine komplexe anspruchsvolle Aufgabe, selbst für Experten. Mit der fortschreitenden Migration in die Cloud, der zunehmenden Verbreitung von Multi-Cloud-Sourcing-Modellen und angesichts der Zunahme gezielter Cyber-Angriffe stellt sich die Frage: Ist die Bearbeitung von Sicherheitsvorfällen in der hybriden Datenwolke möglich?

Firma zum Thema

Monitoring und Detektion von Sicherheitsvorfällen in der Hybrid Cloud.
Monitoring und Detektion von Sicherheitsvorfällen in der Hybrid Cloud.
(© jijomathai - Fotolia.com)

Und wenn ja, wie kann sie konkret aussehen? Hendrik A. Reese, Experte für Cloud Security und -Strategie bei TÜV Rheinland über die realen Zugriffs- und Steuerungsmöglichkeiten für Incident Response in der hybriden Cloud.

Wer glaubt, mit der Nutzung von Cloud Services lagert er nicht nur Daten, sondern auch die Verantwortung für die Sicherheit dieser Daten an den Provider aus, der irrt bekanntermaßen. Unternehmen bleiben für die Absicherung ihrer Daten, Prozesse und Systeme verantwortlich, gleich, wo sich diese Daten befinden. Das bedeutet, sie stehen vor der Herausforderung des systematischen Erkennens und Bearbeiten von Sicherheitsvorfällen, also der Entwicklung einer wirksamen Incident Response-Strategie.

Die Gretchenfrage: Besteht die Möglichkeit, die Ereignisse in der Cloud-Infrastruktur aktiv selbst zu überwachen oder muss das Cloud-nutzende Unternehmen anderen wie dem Provider vertrauen, dies in seinem Sinne zu übernehmen?

Das Prinzip der verteilten Verantwortung

Angesichts unterschiedlicher Modelle der Cloud Services bzw. -Architekturen werden sich Unternehmen wie Provider stärker auf das Prinzip der „Shared Responsibility“ einstellen müssen. Cloud-nutzende Unternehmen müssen verstehen, welche Teile der Infrastruktur von ihnen selbst verantwortet werden. Damit verbunden: Welche Möglichkeiten gibt es innerhalb der eigenen Hoheit und welche alternativen Maßnahmen sind zu ergreifen? Das kann auch bedeuten, dass je nach Cloud Service bestimmte Absprachen oder Vereinbarungen zwischen dem Cloud-nutzenden Unternehmen und dem Provider erforderlich sind oder sich beide Seiten auf eine gemeinsame Strategie verständigen müssen.

Nicht zuletzt deshalb sollten sich IT-Verantwortliche der Zugriffs- und Gestaltungsmöglichkeiten der verschiedenen Arten von Cloud-Services bewusst sein und genau überlegen, welche Daten in welcher Cloud am besten aufgehoben sind und wo Incident-Response-Aktivitäten in komplett eigener Verantwortung erfolgen sollten – oder ob das Cloud-nutzende Unternehmen darin auf den Provider vertrauen will. Die Erkenntnis des faktischen Multi-Cloud-Sourcings in Unternehmen führt sogar dazu, dass Unternehmen eine ganze Bandbreite an Lösungsmöglichkeiten für die Incident Response in der Cloud beherrschen und implementieren müssen.

Idealtypischer Ablauf von Incident Response: erkennen, analysieren, qualifizieren, bekämpfen

Ein Unternehmen mit wirksamen Incident-Response-Strukturen sollte selbst neue Erkenntnisse sammeln und analysieren können und in Bezug auf immer schneller wechselnde Bedrohungsmuster zu einer lernenden Organisation werden. Dafür ist der Zugriff auf Know-how und Ressourcen erforderlich.

Sind die Incidents priorisiert, mit den verfügbaren Datenquellen korreliert und in Bezug auf ihre Kritikalität bewertet, ist zu prüfen, ob angrenzende Systeme betroffen sein können.

Schließlich sind alle betroffenen Sicherheitssysteme entsprechend anzupassen und Workarounds zu erarbeiten, damit die Organisation wieder den herkömmlichen Betriebszustand erreicht. Im Anschluss an Bekämpfung und Analyse der Infektion sind Schwachstellenanalyse der betroffenen Systeme sowie präventive Maßnahmen empfehlenswert, um vergleichbare Angriffsvektoren abzusichern. Incident Response ist entsprechend komplex.

So funktioniert Incident Response innerhalb der verschiedenen Cloud Services

Von zentraler Bedeutung ist, ob Angriffe überhaupt erkannt werden und wer diese komplexe Aufgabe übernimmt. Wesentlich ist auch zu wissen, welche Möglichkeiten das Cloud-nutzende Unternehmen hat, um selbst Gegenmaßnahmen zu ergreifen. Die nachfolgende Übersicht zeigt den jeweiligen Aktionsradius von Cloud-Usern innerhalb der unterschiedlichen Cloud Services auf.

Infrastruktur-as-a-Service (IaaS): Für effektive Incident Response ideal, denn der User behält sowohl private wie public die Hoheit über die eigenen Systeme. Er ist für den Betrieb und das Funktionieren der eingesetzten Systeme selbst verantwortlich – und damit auch für die IT Security von Betriebssystemen, Applikationen und eigenen Services, für die Daten-Verschlüsselung und für die Sicherstellung der Integrität der Systeme bis hin zu Identitäts- und Zugriffskontrollen auf System- und Applikationsebene. Er kann eigeninitiativ über den Sensoren-Einsatz zu den Betriebssystemen entscheiden, selbst, wenn sie in der Public Cloud stehen.

IR-Lösungen für IaaS

Auf Systemebene erfolgt eine Anbindung an das eigene SIEM oder die APT-Sensoren werden in allen virtualisierten Computerhardware-Ressourcen wie Rechnern, Netzen und Speichern platziert, und die Ergebnisse werden zusammengeführt. Der Zugriff auf die Systeminfrastruktur ist die Basis für Gegenmaßnahmen im Sinne des Incident Response, z.B. für die Deaktivierung von Diensten, um weitere Härtungsmaßnahmen zu ergreifen oder auch forensisch aktiv zu werden. Weil das auf Netzwerk-Ebene für das Cloud-nutzende Unternehmen nur eingeschränkt möglich ist, da der Provider in der Regel keinen Zugriff auf seine physische Netzwerkinfrastruktur gestattet, ist eine gemeinsame Response-Strategie des Providers und des Cloud-nutzenden Unternehmens sinnvoll. Das erfordert einen regelmäßigen Austausch der Ereignisse aus dem pyhsikalischen Netzwerkbereich und der Systemüberwachung innerhalb der privaten Cloud zwischen Nutzer und Provider, außerdem abgestimmte Notfallpläne und definierte Eskalationsprozeduren.

Platform-as-a-Service (PaaS): Innerhalb von PaaS entwickeln Nutzer ihre eigenen Software-Anwendungen oder lassen diese innerhalb der Softwareumgebung ausführen, die vom Dienstanbieter (Service Provider) bereitgestellt und unterhalten wird. Da der Nutzer in der von ihm bereitgestellten Applikation die Logik zur Erkennung von Angriffen implementieren oder zumindest wichtige Ereignisdaten sammeln kann, kann er innerhalb des Private-Bereichs in der hybriden Cloud-Struktur alle erforderlichen Gegenmaßnahmen ausrollen.

Verantwortlich für die IT Security der zugrundeliegenden Infrastruktur ist der Provider.

IR-Lösungen für PaaS

Auch hier ist es nicht sinnvoll, verschiedene Systeme zur Zusammenführung der Incident-Informationen zu pflegen. Deshalb stellt sich die unmittelbare Frage der Integration in das unternehmenseigene SIEM. Für PaaS, die in einer hybriden Cloud-Struktur auf eigener Infrastruktur basieren, ergibt sich die volle Bandbreite an Gegenmaßnahmen. Für den Public-Cloud-Anteil ist das ein Problem, weil der Zugriff auf die Systeminfrastruktur fehlt, Informationen über Incidents kommen also in erster Linie aus einer auf dem PaaS betriebenen Applikation. Ein Incident Response basiert hier überwiegend auf der Abstimmung und Abhängigkeit vom Provider.

Software-as-a-Service (SaaS): Der User hat lediglich Zugriff auf die Applikation bspw. über ein Web-Frontend, nicht aber auf die darunterliegenden System- und Netzwerkstrukturen - und damit keine Chance für eine sinnvolle Integration der Überwachung für die Computing-Infrastruktur. Der Provider ist für die IT Security der zugrundeliegenden Infrastruktur verantwortlich. Für das Cloud-nutzende Unternehmen bedeutet das: Keine Implementierung der eigenen Sensoren-Technologie, damit kein Tapping und keine Detektionsmöglichkeiten, und damit nur sehr eingeschränkte eigene Incident Response.

Hendrik Andreas Reese, Experte für Cloud-Beratung und -Strategien beim TÜV Rheinland.
Hendrik Andreas Reese, Experte für Cloud-Beratung und -Strategien beim TÜV Rheinland.
(TÜV Rheinland)

IR-Lösung für SaaS

Der Einsatz von Cloud Access Security Brokers (CASB) zwischen dem Cloud-nutzenden Unternehmen und dem Cloud Service Provider eröffnet die Möglichkeit transparenter Überwachung des Zugriffs auf Cloud Services sowie die Umsetzung von Policies in den Bereichen Malware Prevention, Authentifizierung, Verschlüsselung und DLP (Data Leakage Prevention). Mittels CASB kann der Cloud-Nutzer das Monitoring auf Netzwerkebene sogar auf den SaaS-Service erweitern und in seine eigenen Systeme integrieren. Der CASB erlaubt sinnvolle Gegenmaßnahmen, die Einrichtung von DLP-Mechanismen bzw. Regelverschärfungen. Darüber hinaus bleibt nur die enge Zusammenarbeit mit dem Provider.

Kleine Checkliste für eine gemeinsame IR-Strategie

Eine Zusammenarbeit der beiden Parteien nach dem „Shared Responsability“-Prinzip setzt Vereinbarungen zwischen dem Cloud-nutzenden Unternehmen und dem Provider voraus:

  • Welche Überwachungsmaßnahmen hat der Provider implementiert?
  • Welche Informationen erhält der Cloud-Nutzer zu potenziellen Security Incidents, die für seine Inhouse- Bewertung, -Analyse und -Behandlung erforderlich sind?
  • Abhängig davon, welche Daten der Provider liefert, muss die Incident-Response-Strategie das Monitoring und die technischen Möglichkeiten einbeziehen. Für den Anteil einer hybriden Cloud innerhalb des eigenen Unternehmens kann das Cloud-nutzende Unternehmen Sicherheitsvorfälle eigenständig erfassen und die komplette Bandbreite an Gegenmaßnahmen ausrollen.
  • Je größer der Public-Cloud-Anteil, den das Unternehmen nicht administriert, desto essentieller werden zusätzliche Maßnahmen: Im SaaS ist der Einsatz eines CASB für eine höhere Transparenz quasi obligatorisch.

Das Cloud-nutzende Unternehmen sollte

  • sich bewusst machen, welche zusätzlichen Technologien für Sicherheit und Incident Response in der Cloud essentiell sind (bspw. CASB).
  • alle Informationen in eigenen Incident-Management-Prozeduren erfassen. Dazu gehört auch die sorgfältige Dokumentation von Informationen vom und Vereinbarungen mit dem Provider.
  • im Betrieb der Hybrid Cloud die gleichen Rollen einrichten wie bei der lokalen IT, also im Zweifelsfall sogar einen System-Administrator.
  • zugleich für die ausgelagerten Anteile Vereinbarungen mit dem Provider treffen und sich bewusst sein, dass so eine gewisse Abhängigkeit vom Provider besteht.
  • auch das Supplier Management einbinden, um die Einhaltung der Vereinbarung sowie die Steuerung und Interaktion mit dem Provider systematisch zu überwachen.

* Hendrik Andreas Reese, Cloud-Experte bei TÜV Rheinland

Artikelfiles und Artikellinks

(ID:43869510)