Seite 2: Weitere Best Practices: CIEM und SCA

Inhaltsverzeichnis

Es gibt noch mehr Maßnahmen, unbefugten Zugriff auf die Cloud-Anwendungen und -Accounts abzuwenden. Hierzu zählen das Cloud Infrastructure Entitlements Management (CIEM) und die Software Composition Analysis (SCA).

Das Zugriffsmanagement ist ein wesentliches Security-Thema und dient dazu, den Zugriff auf Services und Ressourcen zu verwalten. Neben den einzelnen Cloud-Ressourcen wie virtuellen Maschinen (VM), Containern, Serverless-Funktionen, Datenbanken und S3-Buckets, die untereinander kommunizieren, gilt es, Nutzerkonten in der Cloud zu verwalten. Die Zugriffsberechtigungen für einzelne Accounts auf die Ressourcen sind im Sinne des Principle of Least Privilege minimal zu halten. Anderenfalls können Angreifer durch das unbefugte Annehmen einer höher privilegierten Rolle (Privilege Escalation) den Zugriff auf interne Daten erhalten oder tiefer in das System eindringen. Gefährdet sind dabei sensible Unternehmensdaten wie Datenbankinhalte, Kostenabrechnungen der Cloud-Accounts und vieles mehr. Wichtig ist, das Risiko von Insidern im Blick zu behalten, die aus dem Inneren des Unternehmens heraus ihre Rechte missbrauchen (zum Beispiel ehemalige Mitarbeiter).

CIEM-Werkzeuge geben einen Überblick über die Zugriffsberechtigungen innerhalb des Accounts und stellen grafisch dar, wer auf welche Ressourcen und Informationen in der Cloud zugreifen kann. Aus Organisationssicht lassen sich damit die Rechte der einzelnen Nutzer und Ressourcen korrekt verwalten und einschränken.

Qualitäts- und Sicherheitschecks auf der Anwendungsseite

Neben dem oben erwähnten Static Application Security Testing (SAST) gibt es auf der Anwendungsebene einer Cloud-Applikation weitere Qualitäts- und Sicherheitschecks. Hierzu zählt die Software Composition Analysis (SCA), die in einem gut strukturierten Software Development Lifecycle (SDLC) nicht fehlen sollte. Sie untersucht, welche Drittanbieterbibliotheken in einer Applikation enthalten sind. Das ist notwendig, um existierende Sicherheitslücken in den Fremdbibliotheken, besser bekannt als CVEs (Common Vulnerabilities and Exposures), oder auch Lizenzverletzungen zu erkennen. Die Software Composition Analysis ist in den letzten Jahren ein unumgängliches Werkzeug zum Durchsetzen der Anwendungssicherheit geworden. Das liegt vor allem daran, dass Software heutzutage ausgiebig Gebrauch bestehender Features macht, statt das Rad jedes Mal neu zu erfinden. Eine wissenschaftliche Untersuchung der Queen’s University Belfast zum Aufspüren von Schwachstellen in Open-Source-Software stellte bereits 2017 bis zu 80 Prozent Fremdcodeanteile in quelloffenen Anwendungen fest.

Eine solche Analyse der Softwarezusammensetzung untersucht zudem die Applikationsumgebung. Beispielsweise geht es darum, welche Applikationen und Shared Libraries in einer virtuellen Maschine oder einem Docker-Container installiert sind und ob sie bekannte Sicherheitslücken enthalten. Aktuelle Analysen umfassen auch Dockerfiles und bemerken, wenn sich Container mit Root-Rechten ausführen lassen oder wenn bestimmte bei Angreifern beliebte Ports wie der SSH-Port 22 offen sind.

Einige Scanner untersuchen auch die Docker- und VM-Images auf unsichere Konfigurationsdateien, obwohl das nicht zur Kernaufgabe der Software-Composition-Analyse gehört. So lässt sich unter anderem eine unsichere SSH-Konfiguration oder gelegentlich sogar eine SSH-Schlüsseldatei in den Images finden. Fehlkonfigurationen wie die der Apache-Web-Application-Firewall (WAF) beim Capital-One-Hack lassen sich hier unter Umständen von einigen Tools finden, sofern sie die zugehörigen Konfigurationsfiles interpretieren können.

Unzählige Werkzeuge, Unmengen an Warnungen – und fehlender Kontext

Zur Absicherung einer Cloud-Umgebung sind die genannten Werkzeuge (CIEM, CSPM, SAST und SCA) unerlässlich. Fehler in der Cloud-Konfiguration können leicht Türen für Angreifer öffnen, die sich anschließend über drastischere Sicherheitslücken in der Anwendung weiter ausnutzen lassen.

In einer idealen Welt schließen Sicherheitsteams alle gefunden Schwachstellen in vollem Umfang – die Praxis sieht jedoch anders aus. Der Sicherheitsbereich ist den DevOps-Teams hinsichtlich Personal und verfügbare Ressourcen meist deutlich unterbesetzt – auf Dutzende DevOps-Mitarbeiter kommt meistens nur eine Security-Fachkraft, ein klares Missverhältnis. Die Ressourcen der Security-Abteilung sind außerdem beschränkt und stehen einer kontinuierlichen Weiterentwicklung der Cloud-Umgebungen gegenüber, die sich häufig mehrmals in der Woche oder gar täglich aktualisieren. Um dem gewachsen zu sein, müssten die verwendeten Sicherheitswerkzeuge ebenfalls kontinuierlich zum Einsatz kommen.

Allerdings müssen die Security-Teams ihre Ressourcen auf die kritischsten Probleme konzentrieren, um mit der großen Anzahl an Warnungen der verschiedenen Werkzeuge mithalten zu können (hier sammeln sich leicht Tausende von Meldungen an). Häufig wird dabei die Gewichtung (Severity), die die Tools den Warnungen zuordnen, oder die Severity-Definition der Benchmarks übernommen. Die Security-Teams beheben dann nur solche Probleme, die aus Sicht der Werkzeuge am kritischsten sind.

Warnungen um Warnungen: den Wald vor lauter Bäumen nicht sehen

Das Problem dabei ist, dass die Werkzeuge die Cloud-Konstellation der Komponenten vernachlässigen, in denen Sicherheitslücken auftreten, und den eigentlichen Anwendungskontext nicht betrachten. Die Ergebnisse beziehen sich nur auf isolierte Komponenten. Das kann dazu führen, dass Sicherheitsteams ihre begrenzte Zeit mit dem Bearbeiten automatisch erzeugter Warnungen verbringen, die im Kontext der Cloud eigentlich unproblematisch sind, weil beispielsweise die betroffene Komponente von außen gar nicht erreichbar ist oder keinen Zugriff auf schützenswerte Daten hat. Die wirklich kritischen Warnungen gehen im ständigen Rauschen der Alarme unter und die Cloud-Anwendung bleibt angreifbar.

Security-Experten müssen also entscheiden, welche Schwachstelle zuerst anzugehen ist. Sind Anmeldedaten im Klartext in Umgebungsvariablen einer Komponente kritischer als ein offener SSH-Port 22 bei einer virtuellen Maschine? Zum einen benötigt diese Entscheidung Rücksprache mit dem Entwicklungsteam, zum anderen ist sie nicht immer eindeutig. Nimmt man hier die CIS-Benchmark als Grundlage einer Priorisierung, ist der offene Port das kritischere Problem – Klartext-Anmeldedaten hingegen fließen nicht einmal in den CIS-Score mit ein.

Severity als Gradmesser führt zu Fehleinschätzungen

Ausschließlich anhand der vorgeschlagenen Severity der Schwachstelle zu urteilen, würde hier leicht zu einer Fehleinschätzung führen. Bei der betroffenen virtuellen Maschine kann es sich beispielsweise um einen nicht genutzten Testserver handeln, der von außen nicht erreichbar ist und keinen Zugriff auf schützenswerte Daten hat. Somit wäre die Priorität dieser Schwachstelle im Vergleich zu den Klartext-Anmeldedaten niedrig.

Um eine verlässliche Bewertung des Risikos der Warnungen zu erhalten, sind die Warnungen unbedingt im Cloud-Kontext zu betrachten: Ist die betroffene Komponente von außen erreichbar und hat sie Zugriff auf sensible Daten? Diese Bewertung ist nach wie vor manuell durchzuführen.

Sicherheitsteams sollten entsprechend vorsichtig sein bei der Ressourcenplanung und Warnungen im Kontext der Applikation interpretieren, statt einzig auf Severity-Scores oder Guidelines wie den CIS-Benchmark zu vertrauen. Sie müssen sich ein Bild der gesamten Anwendungsstruktur machen und überprüfen, welche Sicherheitslücken akut von außen erreichbar sind und welche Lücken Zugriff auf sensible oder kritische Daten ermöglichen.

Schweregrad im Gesamtbild der Warnungen

Wie der Capital-One-Hack zeigt, beruhen Angriffe in der Cloud fast immer auf dem Zusammentreffen mehrerer Sicherheitslücken in verschiedenen Komponenten. Um diese nach ihrem tatsächlichen Schweregrad zu gewichten, ist es von Bedeutung, welche anderen Schwachstellen im Kontext der Komponente erreichbar und somit gemeinsam ausnutzbar sind.

Für die meisten CSPM- und CIEM-Werkzeuge ist es jedoch unmöglich zu beurteilen, ob eine inkorrekte Cloud-Konfiguration erst im Zusammenhang mit einer weiteren Sicherheitslücke kritisch sein kann. Die unverschlüsselte Datenablage in einem privaten Bereich ist folgenlos, sofern nicht zusätzlich eine Schwachstelle existiert, die den vermeintlich privaten Bereich kompromittiert.

Einzelne Fehlkonfigurationen oder falsche Berechtigungen können für sich genommen zunächst harmlos sein. Erst ihre Kombination ergibt ein mögliches Angriffsszenario. Hier ist es nötig, sich eine Verkettung von Rechten, Datenflüssen und den eigentlichen Auswirkungen im Falle eines Angriffs anzusehen. Daher ist es notwendig, die Warnungen aller genannten Werkzeuge (CSPM, CIEM, SCA und SAST) insgesamt zu betrachten.