Kenne deine Gegner – so lautet der Titel eines Almanachs über gezielte komplexe Angriffe, den das ‚Institute for Critical Infrastructure Technology‘ im November 2015 veröffentlichte. Das Handbuch verrät Microblogger William Nizzle zufolge „alles, was man zum Thema APT wissen muss“ (Advanced Persistent Threats = gezielte komplexe Angriffe). Die Fibel gibt einen lesenswerten Einblick zu Akteuren, Zielen und Hintergründen der gegenwärtig aktivsten APT-Gruppierungen und der momentan wichtigsten bekannten Angriffsvektoren. Diese Informationen sind sehr nützlich, wenn es darum geht, mögliche Bedrohungsszenarien für das eigene Unternehmen zu entwerfen und auf Validität zu prüfen – die Grundlage jeder wirksamen Incident-Response-Strategie. Allerdings: Wie die individuelle Marschrichtung jeweils ausfallen sollte, kann kein Handbuch der Welt beantworten, sondern nur jede Organisation für sich selbst!

Zweifellos hat die digitale Transformation in den Unternehmen einen Paradigmenwechsel ausgelöst: Aus Gründen wie Effizienz, Agilität und Skalierbarkeit macht es Sinn, nicht mehr alle Prozesse in der eigenen IT selbst zu erbringen, sie aber nach wie vor zu kontrollieren und zu steuern. Dabei sollten Unternehmen jedoch nicht dem Irrtum verfallen, dass mit der Nutzung von Cloud-Services neben Daten oder Prozessen auch die Verantwortung für die Sicherheit ihrer Daten an den Provider übergehen. Die unterschiedlichen Modelle der Cloud-Services beziehungsweise -Architekturen führen vielmehr zum Prinzip der ‚Shared Responsibility‘ zwischen dem Cloud-nutzenden Unternehmen und dem Provider – insbesondere auch, wenn es um die Abwehr gezielter komplexer Cyber-Angriffe in Form einer Incident-Response-Strategie geht.

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 sichersten aufgehoben sind und wo Incident-Response-Aktivitäten in eigener Hoheit erfolgen sollten – oder ob das Cloud-nutzende Unternehmen diesbezüglich auf den Provider vertrauen muss.

Aktiv mit Risiken auseinandersetzen

Der Bereich Incident-Response-Strategie – sprich die strukturierte Reak­tion auf einen Sicherheitsvorfall – zählt zu den reaktiven Maßnahmen der IT-Security, die ebenso relevant sind wie proaktive Maßnahmen (zum Beispiel die Implementierung eines Informationssicherheits-Management­systems – kurz ISMS – oder das Se­curity Architekturdesign). Ziel dabei ist es,

• die Folgen eines Angriffs fokussiert und aktiv zu managen, also mögliche Schäden zu begrenzen,
• die Wiederherstellungszeit für Daten, Prozesse und Systeme so weit wie möglich zu verkürzen und
• die Kosten für den gesamten Ablauf so niedrig wie möglich zu halten.

Grundlage für wirksame Incident Response ist die Definition, was die Organisation unter einem Sicherheitsvorfall versteht und welche Prozessschritte bei der Behandlung des Vorfalls einzuhalten sind. Der zweite Schritt ist die Implementierung einer entsprechenden Strategie. Die Basis hierfür ist das automatisierte Erkennen von Sicherheitsvorfällen – und zwar durch den Einsatz und die Wirkungsweise technischer Tools zum Monitoring, um das „eine wichtige Signal im großen Grundrauschen“ aufzuspüren. Wichtig ist zudem, den Eskalationszeitpunkt zu definieren, zu dem eine gezielte Abwehr – gegebenenfalls auch durch den Einsatz externer Experten – unerlässlich ist.

Unabhängig davon, ob die IT lokal installiert ist, in der Public, Private oder in der Mischform – der Hybrid Cloud – betrieben wird, ist die Kernfrage für eine erfolgreiche Incident Response immer die gleiche: Besteht die Möglichkeit, die Ereignisse in der Infrastruktur aktiv selbst zu überwachen oder muss das Cloud-nutzende Unternehmen dem Provider vertrauen, dass er dies in seinem Sinne übernimmt?

Eine wirksame Incident Response: Der ideale Ablauf

Bei Sicherheitsvorfällen kann es unter Umständen sinnvoll sein, bestimmte Services vorübergehend vom Netz zu nehmen. Deshalb ist es so wichtig, dass das Unternehmen selbst Zugriff auf die Infrastruktur hat – um keine wertvolle Zeit zu verlieren.

© Fotolia, kirill_makarov

Die Anforderungen an gezielte Incident Responses sind komplex. Kurz gesprochen sieht der idealtypische Ablauf wie folgt aus: erkennen, analysieren, qualifizieren, bekämpfen. Ein Unternehmen mit wirksamen Incident-Response-Strukturen sollte in der Lage sein, neue Erkenntnisse zu sammeln und zu Analysezwecken zu verwenden, um innerhalb der dynamischen Bedrohungslage eine lernende Organisation zu sein. So sollte unter anderem ein Zugriff auf internes oder externes Know-how und Ressourcen bestehen, um Meldungen und Daten zeitnah auswerten und qualifizieren zu können:

• Handelt es sich um einen Fehlalarm oder um einen gezielten Angriff?
• Welche Datenquellen stehen zur Verfügung?

Schließlich sind die Vorfälle zu priorisieren, mit den verfügbaren Datenquellen zu korrelieren und mit Blick auf die Infrastruktur zu bewerten. Außerdem ist zu prüfen, ob angrenzende Systeme betroffen sein können. Fragen, die Experten-Know-how und entsprechende technologische Analysesysteme erfordern.

Zur Schadensbekämpfung sind alle betroffenen Sicherheitssysteme entsprechend anzupassen und Workarounds zu erarbeiten, damit die Organisation wieder den Normalzustand erreicht. Gewissermaßen im Hintergrund wird die Infektion nachhaltig untersucht und bekämpft und nachfolgend detailliert analysiert. Im Anschluss daran sind eine Schwachstellenanalyse der betroffenen Systeme zu empfehlen sowie präventive Maßnahmen, um weitere Angriffe mit analogen Angriffsvektoren zu verhindern. Maßnahmen und das kontinuierliche Monitoring sind in der Hybrid Cloud stark davon abhängig, in welcher Infrastruktur sich das Unternehmen bewegt.

Welche Aufgaben die Beteiligten in welchem Umfang übernehmen, richtet sich weniger nach der Zugriffs-Charakteristik der Public-, Private- oder Hybrid-Cloud-Strukturen, sondern nach der Verantwortung in den technologischen Arten von Cloud-Diensten. Denn die Kernfragen für Incident Response lauten: Können Angriffe überhaupt erkannt werden? Wenn ja, wer übernimmt diese komplexe Aufgabe? Und schließlich: Welche Möglichkeiten hat das Cloud-nutzende Unternehmen, um selbst Gegenmaßnahmen zu ergreifen? Nachfolgend ein Überblick über den jeweiligen Aktionsradius innerhalb der unterschiedlichen Cloud Services.

IaaS versus PaaS versus SaaS

Eine wirksame Incident-Response-Strategie sollte die Besonderheiten der einzelnen Cloud-Services berücksichtigen. Nicht überall ist der Aktionsradius für Cloud-nutzende Unternehmen gleich groß.

© Fotolia, fotohansel

Infrastruktur-as-a-Service-Angebote (IaaS) sind für Incident Response die ideale Umgebung, denn der User behält auch im Public-Bereich seiner Cloud die Hoheit über die eigenen Systeme. Er ist für die Auswahl, die Installation, den Betrieb und das Funktionieren der eingesetzten Systeme verantwortlich – und damit auch für die IT-Security von Betriebssystemen, für Applikationen und eigenen Services, für die Daten-Verschlüsselung sowie für die Sicherstellung der Integrität der Systeme bis hin zu Identitäts- und Zugriffskontrollen auf System- und Applikationsebene. Der User kann also Eigeninitiative über den Sensoren-Einsatz zu den Betriebssystemen entscheiden – selbst wenn sie in der Public Cloud stehen.

Auf Systemebene erfolgt eine Anbindung entweder an das eigene ‚Security Information and Event Management‘ (SIEM), oder es werden die Sensoren, die den Netzwerk-Verkehr nachverfolgen, in allen virtualisierten Computerhardware-Ressourcen wie Rechnern, Netzen und Speicher angebracht, so dass sich die Überwachung zusammenführen lässt. Der Zugriff auf die Systeminfrastruktur ist die Basis für Gegenmaßnahmen im Sinne von Incident Response, indem man etwa Dienste deaktiviert oder auch Server aus dem Betrieb nimmt, um weitere Härtungsmaßnahmen zu ergreifen oder auch forensisch aktiv zu werden. Weil dies 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 Netzwerk-Infrastruktur gestattet, empfiehlt es sich, dass Provider und das Cloud-nutzende Unternehmen eine gemeinsame Response-Strategie verfolgen und ihre Erkenntnisse aus dem physikalischen Netzwerk-Bereich und der Systemüberwachung innerhalb der Cloud aktiv teilen. Um eine zeitnahe und effiziente Bearbeitung von Incidents zu gewährleisten, sind hier allerdings abgestimmte Notfallpläne und definierte Eskalationsprozeduren erforderlich.

Platform-as-a-Service – kurz PaaS – stellt Programmier- oder Laufzeit-Umgebungen mit flexiblen, dynamisch anpassbaren Rechen- und Datenkapazitäten bereit. Innerhalb von PaaS entwickelt das Cloud-nutzende Unternehmen seine eigenen Software-Anwendungen oder lässt diese innerhalb einer Software-Umgebung ausführen, die vom Dienstanbieter (Service Provider) bereitgestellt und unterhalten wird. Da das Unternehmen in der vom Provider bereitgestellten Applikation die Logik zur Erkennung von Angriffen implementieren oder zumindest wichtige Ereignisdaten sammeln kann, hätte es somit im Idealfall Zugriff auf wertvolle Information zur Detektion eines Security Incident.

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 überwiegend auf der Abstimmung und Abhängigkeit vom Provider. Daher hat der User ohne Informationen des Providers keine rationale Entscheidungsgrundlage etwa dafür, Services vom Netz zu nehmen.

Bei Software-as-a-Service (SaaS) schließlich hat der User Zugang zu Software-Gruppen beziehungsweise Anwendungsprogrammen. Die Applikationen laufen in den Public-Cloud-Anteilen auf der Infrastruktur des SaaS-Dienste-anbieters. Der User hat lediglich Zugriff auf die Applikation, zum Beispiel über ein Web-Frontend, nicht aber auf die darunterliegenden Netzwerk-Strukturen – und damit keine Chance für eine sinnvolle Integration der Überwachung der Computing-Infrastruktur. Dies wäre jedoch eine wesentliche Voraussetzung, um die Incident-Response-Strategie im Einzelfall anzupassen. Der Fakt, dass bei SaaS der Provider für die IT-Se-curity der zugrundeliegenden Infrastruktur verantwortlich ist, bedeutet für das Cloud-nutzende Unternehmen im Klartext: Keine Implementierung der eigenen Sensoren-Technologie, damit kein Tapping und keine Detektionsmöglichkeiten, und somit nur sehr eingeschränkte eigene Incident Responses.

Im SaaS-Umfeld kommt ein Cloud-Nutzer folglich – sofern er wirksame Incident Response selbst betreiben will – an den Überwachungs- und Sicherheitsmaßnahmen eines ‚Cloud Access Security Brokers‘ (CASB) nicht vorbei. CASB sind lokal installierte oder cloudbasierte Sicherheitslösungen, die zwischen dem Cloud-nutzenden Unternehmen und dem Cloud-Service-Provider platziert werden. CASB ermöglichen die transparente Überwachung des Zugriffs auf Cloud-Services sowie die Einsteuerung technischer Richtlinien in den Bereichen Malware Prevention, Authentifizierung, Verschlüsselung und ‚Data Leakage Prevention‘ (DLP).

Mittels Zugriffs-Überwachung durch den CASB kann der Cloud-Nutzer das Monitoring auf Netzwerk-Ebene auf den SaaS-Service erweitern und in seine eigenen Systeme integrieren. Der CASB ermöglicht sinnvolle Gegenmaßnahmen wie die situative Sperrung von Zugriffen im Incident-Fall, die Einrichtung von DLP-Mechanismen beziehungsweise die Verschärfung von deren Regeln. Darüber hinaus bleibt nur die enge Zusammenarbeit mit dem Provider. Für die Bewertung, welchen Incidents und Bedrohungen das Cloud-nutzende Unternehmen gerade unterliegt, ist es hilfreich, die Informationen aus der Infrastruktur und aus dem CASB in einem eigenen Monitoring-System zusammenzuführen. Sie sind die Grundlage für Analyse und wirksame Gegenmaßnahmen.

Verantwortung verantwortlich teilen

Eine Zusammenarbeit der beiden Parteien nach dem ‚Shared Responsability‘-Prinzip setzt voraus, dass das Cloud-nutzende Unternehmen zuvor mit dem Provider vereinbart, welche Überwachungsmaßnahmen der Provider implementiert und welche Informationen der Cloud-Nutzer zu potenziellen Security Incidents, die für die Bewertung, Analyse und Behandlung erforderlich sind, erhält. Abhängig davon, welche Daten der Provider zu liefern beabsichtigt und bis zu welchem Grad der Cloud-Nutzer darauf vertraut, dass die Daten tatsächlich geliefert werden, 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 höher der Anteil der nicht eigenverantwortlich administrierten Infrastruktur in der Public Cloud, desto essenzieller werden zusätzliche Maßnahmen.

Auf den Punkt gebracht: Der Cloud-Nutzer sollte sich bewusst machen, welche zusätzlichen Technologien für Sicherheit und Incident Response in der Cloud unerlässlich sind (zum Beispiel CASB). Das heißt: Alle Informationen sind in eigenen Incident-Management-Prozeduren zu erfassen. Dazu gehört auch, alle Informationen vom und Vereinbarungen mit dem Provider systematisch zu dokumentieren. Grundsätzlich sind im Betrieb der hybriden Cloud die gleichen Rollen vorzusehen wie bei der lokalen IT. Je nachdem, welcher Zugriff auf die Infrastruktur möglich ist, kann dies bis zum Administrator eines Systems reichen. Zugleich sollte das Cloud-nutzende Unternehmen für die ausgelagerten Anteile stets Vereinbarungen mit dem Provider treffen und sich bewusst sein, dass immer eine gewisse Abhängigkeit vom Provider besteht.

Autor:
Dr. Daniel Hamburg ist Cloud-Experte bei TÜV Rheinland.