In dieser Blog-Reihe möchte ich euch mehr über Public-Cloud-Dienste und DevOps erzählen. Ihr erfahrt, wie die Schlagwörter „Public-Cloud“ und „DevOps“ den Blickwinkel der Security-Analysten im Security Operation Center (SOC) in der Vergangenheit beeinflusst haben, welche Veränderungen sie aktuell hervorrufen und wie sie das SOC und die Arbeit im Bereich Cyber Security in Zukunft transformieren werden.
Cloud & DevOps – Status Quo
Zu aller erst sollten wir eine kurze Bestandsaufnahme machen, und zusammenfassen, warum Unternehmen überhaupt auf die Idee kommen die Cloud oder DevOps zu nutzen. Am Anfang steht immer die Überlegung, wie man mit der Geschwindigkeit der digitalen Transformation Schritt halten kann. Denn Hand aufs Herz: Wer das nicht kann, wird früher oder später vom Wettbewerb abgehängt.
Damit es erst gar nicht soweit kommt, müssen sich Unternehmen auf Innovationen und die eigenen Kernkompetenzen fokussieren – eben auf das, was wirklich wichtig ist: heute Ergebnisse sichern und damit den Erfolg von morgen garantieren. Die Auslagerung des IT-Betriebs in die Cloud kann einem deutlich mehr Zeit für Innovationen verschaffen. Unternehmen mit Software-Entwicklung können so mehr als nur eine Hand voll Releases pro Jahr an ihre Kunden ausliefern.
Die Cloud-Migration macht den Anfang
Der erste (und einfachste) Schritt, um mit der Geschwindigkeit der digitalen Transformation und den Umwälzungen des neuen Datenzeitalters mitzuhalten, ist also die die Migration in die Cloud. Lasst uns einfachheitshalber die Cloud-Migration in drei Phasen unterteilen:
- Phase 1: Hierbei geht es um „Lift & Shift“ bzw. „Re-hosting“ – verfügbare Systeme und Applikationen bzw. Virtuelle Maschinen (VMs) werden ohne große Veränderung, quasi 1:1, bit für bit in die Public-Cloud migriert (kopiert). Oft wird dabei Infrastructure-as-a-Service (IaaS) genutzt. VMs und Applikationen sind aber oft nicht optimiert für eine Cloud-native Umgebung. Daher ist die Effizienzsteigerung auch erst einmal moderat.
- Phase 2: Hier werden durch „Re-Architecting“ bzw- „Re-Factoring“ monolithische Applikationen umgebaut und modularisiert, sodass sie Cloud-native Features wie z. B. Containerisierung nutzen können, was Entwicklung (Development bzw. „Dev“) und Betrieb (Operations bzw. „Ops“) näher zusammenbringt und man in eine gute zweistellige Zahl von Releases im Jahr kommen kann. Mit Hilfe eines Container-Cluster-Managements wie Kubernetes kann die gesamte Infrastruktur sehr einfach, bedarfsgerecht und automatisch hoch und runter skaliert werden.
- Phase 3: Applikationen werden nun noch weiter aufgebrochen, sodass Funktionen in viele unabhängige, wiederverwertbare Microservices gepackt werden, welche auch via Serverless Functions zur Verfügung gestellt werden können.
Somit wachsen Development (Dev) und Operations (Ops) unzertrennbar zu DevOps zusammen, um hunderte Releases pro Monat, pro Woche oder sogar pro Tag zu realisieren.
You Build It, You Run It
Nicht nur große sondern auch kleine und mittelständische Unternehmen befinden sich oft mit verschiedenen Projekten in mehreren bzw. sogar allen unten dargestellten drei Phasen gleichzeitig.
Dabei ist alles hochdynamisch und miteinander verbunden, sodass die Komplexität in einem Maße ansteigt, das es den einzelnen Entwicklern nahezu unmöglich macht, einen Überblick zu behalten. Alles was noch zählt sind Funktionalität und hohe Flexibilität. Letztlich resultiert dies in einer unglaublichen Komplexität. Und auch hier gilt: Komplexität ist der größte Feind der Cyber Security. Doch wo soll man nun bei aller Komplexität anfangen das Risiko zu minimieren? Und welche Rolle spielt Automatisierung in diesem Kontext?
Am Anfang sollte immer die Transparenz stehen, denn man kann nicht schützen, was man nicht sehen bzw. überwachen kann.
„Hybrid Cloud Security“ bedeutet vor allem auch „lokal“
Der Ansatz von Splunk ist es, dafür ein Cloud-natives Tool bereitzustellen, also unsere Security Analytics Platform, die in der Lage ist ein vom Cloud-Provider unabhängiges Monitoring bereitzustellen. Wichtig ist zu beachten, dass wir in diesem Kontext von Hybrid, denn egal wie Cloud-first eure Strategie ist, es gibt immer eine lokale Infrastruktur und on premise Dienste, die ihr nicht außer Acht lassen solltet. Grund dafür ist, dass Angreifer sich oft wie Elektrizität verhalten und immer den Weg des geringsten Widerstands finden. Und wenn dieser Weg über ungesicherte lokale Systeme und Applikationen zu finden ist, dann steigt der Angreifer eben dort ein und hangelt sich den Weg weiter zu euren wertvollsten Assets in der Cloud.
Angenommen unser Service ist in den 3 größten Cloud Providern verteilt und unser DevOps nutzt Containerisierung mit Kubernetes als Container-Orchestration-Tool. Es spricht natürlich nichts dagegen die Cloud-eigenen Monitoring-Tools zu nutzen, um angereicherte Audit- und Compliance-Logs zentralisiert in Splunk zu indizieren und zu korrelieren. Extrem wichtig ist es aber auch Transparenz bzw. Visibilität hinsichtlich der Applikation und der Laufzeitumgebung zu gewinnen. Splunk kann mit der App Splunk Connect for Kubernetes, Kubernetes Logs und Metriken einsammeln. Mit Splunk SignalFx können mittels der sogenannten Code-based Instrumentation, ganz ohne Agent, Traces in Echtzeit aus der Applikation und somit dem ganzen Service gezogen und an Splunk gesendet werden.
Wenn man ein solches Monitoring aufgebaut hat, dann hat die Cloud Umgebung sogar einen wesentlichen Vorteil gegenüber der lokalen Umgebung: Man hat zu jedem Zeitpunkt ein komplettes und dynamisches Inventar aller Assets und deren Zustand – Das ist Gold wert für eure Cyber Security!
Der richtige Schutz und das passende Monitoring
Da wir nun die Grundlagen zu Infrastruktur und Transparenz gelegt haben, bewegen wir uns langsam in Richtung Cloud Security Use Cases. Wir widmen uns also der Frage, was genau wir vor was bzw. wem schützen wollen und wie wir diesen Schutz überwachen möchten.
Hierzu bietet es sich an, einen Blick auf die MITRE ATT&CK® Cloud Matrix zu werfen, um gängige Angriffstechniken zu erkunden.
Wir starten mit einer relativ simplen Technik, die Angreifer allzu gerne anwenden, da es hier immer wieder (leider viel zu viele) Opfer gibt: “Data from Cloud Storage Objects” - also unzureichend gesicherter Cloud Speicher mit ggf. sensiblen Daten.
Quelle: https://attack.mitre.org/matrices/enterprise/cloud/#
Quelle: https://attack.mitre.org/techniques/T1530/
Gemäß der oben beschriebenen Multi-Cloud-Monitoring-Strategie würden wir also zuerst die Logs der eingesetzten Cloud-Provider in Splunk indizieren und sie anschließend auf ein gemeinsames Format bringen (Cloud Infrastructure Data Model).
Dann suchen wir in der Splunk Enterprise Security Use Case Library nach dem entsprechenden Content, welcher die MITRE ATT&CK® Taktik T1530 (siehe ID im Screenshot oben) abdeckt. Wir werden hier z. B. mit der Analytic Story „Suspicious AWS S3 Activities“ fündig.
Im Reiter “Detection” sehen wir also Korrelationssuchen (Correlation Searches) wie z.B. „Detect New Open S3 bucket“, welche immer dann triggert, wenn mit einem Unternehmensaccount ein neuer, ungesicherter Cloud Speicher in AWS (S3 bucket) erstellt wurde.
Dies kann im Unternehmen generell verboten sein oder aber auch je nach Prozess und Projekt durchaus gewollt und normal.
Alles in allem ist dies der Startpunkt der Investigation (Triage), in der die Security-Analysten entscheiden müssen, ob es sich um ein valides Verhalten (also ein False-Positive-Alarm) oder um ein ungewolltes, potenziell schadhaftes Verhalten handelt, welches einer (sofortigen) Reaktion bedarf.
Splunk Analytic Story beinhaltet unter dem Punkt „Investigation“ Vorschläge zur Triage, Investigation und Entscheidungsfindung.
Wie dies in ein voll automatisiertes SOAR (Security Orchestration Automation & Response) überführt werden kann, wird im Teil 2 dieser Blog Reihe erläutert. Stay tuned!
