Schrödingers Fehlkonfigurationen

Es ist Donnerstagnachmittag und Sie machen sich bereit, etwas früher Feierabend zu machen, weil … Sie es können. Doch dann meldet sich dieser lästige Überbringer von Benachrichtigungen (auch bekannt als Slack) mit einer neuen Nachricht in Ihrem Kanal für Sicherheitswarnungen:

Na so etwas. Jemand hat gerade einen Snapshot eines Speichervolumens öffentlich gemacht. Ist das ein Angriff? Ein Versehen? Jemand, der die Richtlinien schlicht nicht kennt?

Fehlkonfigurationen haben drei Zustände

Das nenne ich mittlerweile Schrödingers Fehlkonfigurationen , da ich die schlechte Angewohnheit habe, Prinzipien der Quantenmechanik zur Erklärung von Informationssicherheit heranzuziehen. Es würde mich sehr wundern, wenn Sie Schrödingers Katze nicht bereits kennen würden – das berühmte Gedankenexperiment, mit dem Erwin Schrödinger Albert Einstein das Paradoxon der Quantensuperposition veranschaulichte. Ganz kurz gefasst: Sperrt man eine Katze mit einem Gift in eine Kiste, das durch radioaktiven Zerfall ausgelöst wird, ist die Katze weder lebendig noch tot und befindet sich somit in einem Zustand, in dem sie lebendig UND tot ist, bis man die Kiste öffnet und nachsieht.

Ja, das ist absurd – und genau das war der Punkt. Insbesondere für diejenigen unter uns mit Katzen, die ES NICHT MÖGEN, IN KISTEN EINGESPERRT ZU WERDEN. Ich könnte zwar eine ganze Blogreihe darüber schreiben, wie Katzen von selbst in Kisten kriechen, aber sehr wütend werden, wenn man sie hineinsetzt, und … ich schweife ab.

Zurück zur Cloud-Sicherheit. Das grundlegende Konzept hinter dem Gedankenexperiment ist, dass sich etwas in mehreren Zuständen gleichzeitig befindet, bis man es beobachtet – und dieser Akt der Beobachtung eine Antwort erzwingt. Ich verzerre und vereinfache das natürlich für meine eigenen Zwecke; diejenigen unter Ihnen mit physikalischem Hintergrund bitte ich daher, mir keine wütenden E-Mails zu schicken.

Die Cloud-Version dieses Konzepts besagt, dass sich jede beliebige Fehlkonfiguration in einem Zustand befindet, in dem sie ein Angriff, ein Versehen oder ein Richtlinienverstoß ist, bis Sie sie untersuchen und die Ursache ermitteln.

Fünf Merkmale der Cloud stützen dieses Konzept:

• Cloud- und Entwicklungsteams haben in der Regel mehr Autonomie, ihre eigene Cloud-Infrastruktur direkt zu verwalten.
• Die Cloud-Managementebene ist über das Internet zugänglich.
• Die häufigste Quelle (heute) von Cloud-Angriffen sind gestohlene Zugangsdaten.
• Viele Fehlkonfigurationen erzeugen Zustände, die mit den Aktionen eines Angreifers identisch sind (z. B. das Öffentlichmachen eines Snapshots).
• Es ist leicht, versehentlich eine Fehlkonfiguration zu erzeugen; manchmal geschieht dies auch absichtlich, um einen Bedarf zu decken, ohne dass die handelnde Person erkennt, dass es sich um ein Sicherheitsproblem handelt.

Dieses Konzept gilt auch in traditioneller Infrastruktur, wenn auch in weit geringerem Maße, da die Teams dort weniger Autonomie haben. Ein Entwickler einer Anwendung hat üblicherweise nicht die Möglichkeit, Firewall-Regeln und Routing-Tabellen direkt zu ändern. In der Cloud ist das durchaus üblich, zumindest in manchen Umgebungen.

Von einem Angriff ausgehen, bis das Gegenteil bewiesen ist

Eines der wichtigeren Prinzipien der Incident Response in der Cloud lautet, dass Sie Fehlkonfigurationen unbedingt als Sicherheitsereignisse behandeln und davon ausgehen müssen, dass es sich um Angriffe handelt, bis das Gegenteil bewiesen ist.

Das erfordert ein Umdenken, denn die Sicherheit ist es gewohnt, in Schwachstellen und Angriffsflächen zu denken – Dinge, nach denen wir in regelmäßigen Abständen scannen und die wir weitgehend als zu behebende Probleme betrachten. Ich schlage vor, dass wir erkannte Fehlkonfigurationen im Cloud Computing auf dieselbe Stufe heben wie eine IDS- oder EDR-Warnung. Sie sind nicht bloß Compliance-Probleme, sie sind potenzielle Kompromittierungsindikatoren.

Und nein, das gilt nicht für jede Fehlkonfiguration in jeder Umgebung. Wir müssen filtern und priorisieren. Besser noch: Wir müssen kommunizieren, denn meist ist der einfachste Weg herauszufinden, ob eine Fehlkonfiguration ein böswilliger Angriff ist, die Person, die die Änderung vorgenommen hat, schlicht zu fragen, ob sie das beabsichtigt hat.

Da ich die Dinge für Schulungen auf das Wesentliche herunterbrechen muss, habe ich drei primäre Datenquellen für Sicherheitstelemetrie definiert:

• Logs
• Ereignisse des Cloud-Anbieters (z. B. Security-Hub-Ereignisse)
• Cloud-Fehlkonfigurationen, die aus Ihrem CSPM-Tool, OSS-Scannern oder Ähnlichem stammen können

Die meisten Fachleute im Bereich Cloud-Sicherheit haben dieses Konzept bereits verinnerlicht, aber wir erklären es nicht immer. Wenn Sie sich einige Cloud-Detection-and-Response-Tools (CDR) ansehen, erzeugen diese bei bestimmten Fehlkonfigurationen Warnungen. Das unterscheidet sich von der standardmäßigen Arbeitsweise von CSPM-Tools, die Findings in Berichten und auf Dashboards erzeugen. Diese sind für Compliance und allgemeine Sicherheitshygiene wichtig, aber da Angreifer unangenehme Dinge tun, etwa Festplatten-Images für andere Konten freigeben oder sich Hintertürzugänge zu IAM-Rollen verschaffen, muss ein Teil der Fehlkonfigurationen tatsächlich so behandelt werden, als wären es Kompromittierungsindikatoren, bis das Gegenteil bewiesen ist.

Intern (und in der DisruptOps-Plattform) lösen wir das mit einer Reihe von Echtzeit-Bedrohungsdetektoren, die anhand identifizierter API-Aufrufe Bewertungen auslösen. Es dauert etwa 15-30 Sekunden, eine Fehlkonfiguration zu identifizieren und sie per Slack (oder Teams) an die Sicherheit und den Projektverantwortlichen zu senden, wie oben zu sehen. Diese Warnungen werden genauso behandelt wie ein GuardDuty-Finding oder jeder andere Kompromittierungsindikator; die Nutzung von ChatOps zur Validierung von Aktivitäten hilft uns zudem, diese sehr schnell zu triagieren, ohne jedes Mal eine tiefgehende Analyse durchführen zu müssen.

Die Kurzfassung der Empfehlung: Behandeln Sie zentrale Cloud-Fehlkonfigurationen nahezu in Echtzeit und betrachten Sie sie als Kompromittierungsindikatoren, bis das Gegenteil bewiesen ist.

Bei der Erstellung dieses Beitrags kamen keine Katzen zu Schaden.