Data Security in der Cloud: Schwachstellen erkennen und bewerten
Sicherheitslücken in Anwendungen gehören zu den ganz großen IT-Risiken. Daher ist es sowohl in der Software-Entwicklung als auch bei der Verwaltung von Systemen unerlässlich, Schwachstellen zu erkennen und zu bewerten. Ständig tauchen neue Sicherheitslücken auf, die eine konstante Wachsamkeit erforderlich machen.
Um diese Risiken zu bewerten und passende Maßnahmen anzustoßen, benötigt man wirksame Methoden. Die guten Nachrichten: Laut einer aktuellen Auswertung nutzen Unternehmen zunehmend häufig entsprechende Werkzeuge. Eine Analyse der erhobenen Daten zeigt zudem, dass der größte Teil der öffentlich identifizierten Schwachstellen eher wenig gefährlich ist. Die schlechten Nachrichten: In den letzten zehn Jahren ist die Zahl der Zero-Day-Angriffe stetig gestiegen. Wachsamkeit und effektive Triage-Methoden sind daher trotz allem wichtiger denn je.
In diesem Beitrag schauen wir uns die Schwachstellen und deren Klassifizierung näher an. Darüber hinaus folgen Praxistipps für eine gründliche Risikobewertung sowie einen effektiven Umgang mit neu auftretenden Schwachstellen und ein Blick auf Nutzen und Unzulänglichkeiten der aktuellen Bewertungsmethoden.
Schwachstellen: Eine Einführung
Im Grunde genommen ist jeder Fehler in einem Computersystem, der die Sicherheit dieses Systems untergräbt, eine potentielle Schwachstelle. Sie entstehen oft durch unsicheren Code, fehlerhafte Konfigurationen sowie die Verwendung ungesicherter APIs und veralteter oder ungepatchter Software. In den letzten Jahren waren sie der Grund für eine Reihe von Cyberangriffen mit teils katastrophalen Folgen für Unternehmen und den öffentlichen Raum. Darunter sind groß angelegte Ransomware-Angriffe wie WannaCry, die REvil-Attacke auf den IT-Dienstleister Kaseya oder die 2021 massiv ausgenutzte Log4Shell-Schwachstelle.
Neu auftretende Schwachstellen werden nach potenziellen Sicherheitsrisiken, Angriffsfläche sowie der öffentlichen Aufmerksamkeit bewertet. Für Sicherheitsexperten hat höchste Priorität, diese neuen Sicherheitslücken schnellstmöglich zu identifizieren und sie zu schließen. Um sie dabei zu unterstützen und eine aktive Überwachung von Schwachstellen zu erleichtern, wurden mehrere Stellen eingerichtet. Dazu gehört zum einen das Common Vulnerabilities and Exposures Programm (CVE, deutsch: "Bekannte Schwachstellen und Anfälligkeiten"), das öffentlich bekannt gewordene Schwachstellen identifiziert und katalogisiert, zum anderen das Common Vulnerability Scoring System (CVSS, deutsch: "Allgemeines Bewertungssystem für Schwachstellen"), ein Industriestandard zur Bewertung des Schweregrads von Schwachstellen.
CVSS ist ein Standard, der es ermöglicht, verschiedene Beschreibungs- und Messsysteme miteinander kompatibel und allgemein verständlich zu machen. Dabei werden unterschiedliche Kriterien verwendet, um den Schweregrad von Schwachstellen auf einer Skala von 0,0 (keine) bis 10,0 (kritisch) zu bewerten. Die Bewertungen erfolgen in drei Kategorien:
- Basiskriterien: Diese sind erforderlich und messen Faktoren, die als konstant angesehen werden. Diese Faktoren lassen sich in zwei Kategorien einteilen – "Ausnutzbarkeit" und "Auswirkungen". Ausnutzbarkeit signalisiert, wie leicht Angreifer eine Schwachstelle ausnutzen können. Auswirkungen misst, wie gravierend die Folgen von Angriffen auf Vertraulichkeit (durch Offenlegung sensibler Daten), Integrität (durch Veränderung oder Zerstörung von Daten) und Verfügbarkeit (durch Beeinträchtigung von Systemen oder Diensten) sein können.
- Zeitliche Kriterien: Diese sind optional und messen den aktuellen Status einer Schwachstelle, z. B. ob es sich nur um eine theoretische oder um eine bereits nachgewiesene Schwachstelle handelt, ob es einen offiziellen Fix gibt und ob die Grundursache eindeutig identifiziert wurde.
- Umgebungskriterien: Auch diese sind optional und messen die Auswirkungen der Schwachstelle auf ein bestimmtes System, z. B. das Netzwerk einer Organisation.
Auftretende Schwachstellen identifizieren und besser bewerten
Die Hauptaufgabe von Security-Teams mit Blick auf Schwachstellen ist, diese so früh wie möglich zu erkennen und zu kategorisieren. Um auf dem Laufenden zu bleiben, ist es wichtig, sowohl die CVE als auch die vom National Institute of Standards and Technology (NIST) bereitgestellte National Vulnerability Database (NVD) kontinuierlich auf neue Schwachstellen zu überwachen. Komponenten zu beobachten, die Unternehmen in ihren Produkten und Dienstleistungen verwenden, ist dabei besonders wichtig. Welche konkreten Auswirkungen eine Schwachstelle auf Systeme und Benutzer hat, ist geschäftskritisch – und einer der Hauptgründe dafür, die CVSS Base Scores weiterzuentwickeln.
Um neuen Schwachstellen immer einen Schritt voraus zu sein, sollte man kontinuierlich die CVE- und CVSS-Daten nutzen – sich gleichzeitig allerdings ihrer Grenzen bewusst sein. Sie sind ein unentbehrliches Werkzeug, aber kein Allheilmittel. Oft wirken Faktoren auf den Schweregrad von Schwachstellen ein, die unterschätzt oder übersehen werden. Diese Faktoren sind nicht nur auf Umgebungskriterien für bestimmte Systeme beschränkt. Genauso entscheidend sind zeitliche Metriken wie die Existenz (oder Nichtexistenz) von Proof-of-Concept-Code. Andere Faktoren können subjektiv oder schwer zu quantifizieren sein, wie z.B. öffentliche Aufmerksamkeit oder Hype. Doch auch diese können einen relevanten Faktor darstellen.
Darüber hinaus sind CVSS-Daten bei der konkreten Bewertung von Schwachstellen limitiert. So können beispielsweise die CVSS-Basiskriterien nicht direkt messen, ob Schwachstellen Remote-Code-Execution-(RCE-)Angriffe ermöglichen. Hierbei können Angreifer über eine Remote-Verbindung beliebigen Code auf anfälligen Komponenten ausführen. Das RCE-Potenzial berücksichtigen zu können, wäre jedoch sinnvoll, da es einen großen Einfluss auf den Schweregrad hat. Ob und inwieweit ein RCE-Angriff aufgrund einer gegebenen Schwachstelle möglich ist, hängt zum einen von der prinzipiellen Natur und Art der Schwachstelle ab, zum anderen von Faktoren wie der Anwendungs- und IT-Architektur.
Angesichts dieser Einschränkungen sind zusätzliche Schritte notwendig: Wie kann man den Kontext, den die Systeme bereitstellen, sinnvoll anreichern, um besser einzuschätzen, wie und mit welcher Dringlichkeit man Schwachstellen behandeln sollte? Das betrachten wir als nächstes.
Schritt 1: Das Ausmaß untersuchen
Hat man eine neue Schwachstelle identifiziert, muss man zunächst deren Basiswert erstellen und das Ausmaß der Angriffsfläche ermitteln – also die Auswirkungen der Schwachstelle innerhalb der eigenen Systeme. Die Basiswerte sind in den CVE-Listen der Schwachstellen zu finden, mit detaillierten Zusammenfassungen der betroffenen Komponenten, der potenziellen Auswirkungen und mehr. Es ist auch möglich, den Wert mit dem CVSS-Rechner zu berechnen. Solange jedoch nicht das gesamte Ausmaß der Angriffsfläche sowie die potenziellen Auswirkungen und alle bestehenden Schutzmaßnahmen ermittelt sind, bleibt dieser Wert rein theoretisch.
Code-Scanning, eine Software Bill of Material (SBOM, Inventarliste für Software-Produkte) und weitere Tools können dabei unterstützen, die Angriffsfläche zu ermitteln. Code-Scanner, wie beispielsweise der von GitHub, analysieren Code und zeigen potenzielle Schwachstellen auf, während SBOMs helfen, den Überblick über die Komponenten der verwendeten Systeme und Dienste zu behalten. Ein Service-Katalog bietet einen zentralen Bezugspunkt für alle Dienste, die ein Unternehmen nutzt. Er zeigt zahlreiche Informationen an, darunter alle bekannten Schwachstellen, die in den verwendeten Bibliotheken entdeckt wurden. Es ist auch wichtig zu prüfen, ob bereits relevante Gegenmaßnahmen vorhanden sind, wie z. B. Bedrohungsmodellierung oder Runbooks. Oft ist es unmöglich, eine eingebundene oder indirekt verwendete Bibliothek, die eine Schwachstelle aufweist, unmittelbar auszutauschen, da das zu Verletzungen von Abhängigkeiten in weiteren Systemen führen kann. Eine gute und vollständige Übersicht über alle verwendeten externen und internen Software-Komponenten ist der Schlüssel, um das Ausmaß einer Schwachstelle und den Einfluß-Perimeter abzuschätzen.
In vielen Fällen ist es außerdem notwendig zu analysieren, wie lange die Schwachstelle bereits in den Software-Systemen besteht und ob in der Vergangenheit bereits versuchte oder erfolgreiche Angriffe auf eine konkrete Schwachstelle erfolgt sind. Die gezielte Auswertung von Anwendungsprotokollen und Zugriffsmustern kann hier einen schnellen Überblick geben.
Schritt 2: Hype bewerten und Proof-of-Concept-Code suchen
Hat man einen Basiswert ermittelt und die Angriffsfläche eingeschätzt, folgt die Analyse des aktuellen Status der Schwachstelle. Eine Analyse in sozialen Medien und GitHub zeigt, wie verbreitet die Schwachstelle ist. Zudem hilft sie, bestehende Ansätze zur Behebung zu entdecken und festzustellen, ob bereits Proof-of-Concept-Code im Umlauf ist.
Der CVSS berücksichtigt nur optional, ob Proof-of-Concept-Code existiert. Das bedeutet, dass CVSS-Scores nicht unbedingt die unmittelbare, reale Gefahr von Exploits widerspiegeln. Proof-of-Concept-Code signalisiert zudem, dass eine Schwachstelle anfällig für ein RCE-Ereignis ist – ein wichtiger Faktor für den Schweregrad. Unklarheit darüber, ob der CVSS diesen Aspekt nun berücksichtigt oder nicht, kann Zweifel an dem Wert wecken und die tatsächliche Gefahr verschleiern.
Was definitiv im CVSS fehlt, ist der Bekanntheitsgrad einer Schwachstelle. Sorgt eine Sicherheitslücke in Security-Kreisen bereits für Aufsehen oder schafft es sogar in die Nachrichten, dann ist diese höchstwahrscheinlich sehr dringlich. Diesen Aspekt zu quantifizieren, ist nicht immer ganz einfach. Es gibt Lösungen, die helfen können, den Status einer Schwachstelle systematisch zu bewerten, sowohl in Bezug auf die Dringlichkeit als auch auf die aktuelle Ausnutzbarkeit. Dabei nutzen sie eine CVE-Nummer oder einen populären Namen (wie "Log4Shell"), um diese mit Treffern bei Twitter, der Infosec-Exchange-Mastodon-Community sowie GitHub abzugleichen. Sie geben die Anzahl der Beiträge pro Tag aus sowie die Anzahl der Repositories, die auf eine Schwachstelle verweisen. Zudem ermitteln sie den Zero-Day-Status und den potenziellen Proof-of-Concept-Code. Workflow-Systeme oder Runbooks können dazu dienen, diese Analysen systematisch und teilweise automatisiert durchzuführen. Wichtig ist es, einen wiederholbaren Abdeckungsgrad sicherzustellen. Diese Abläufe sind individuell auf die Erfordernisse der eigenen Systeme und den Bedrohungsrahmen anzupassen. Zudem sollten sie regelmäßig im Hinblick darauf überprüft werden, ob sie die aktuell sinnvollen Quellen noch ausreichend abbilden.
Schritt 3: Eine genauere Bewertungsgrundlage anlegen
Anhand der Auswertungen von Angriffsfläche, Ausnutzbarkeit und Bekanntheitsgrad sowie der vorhandenen Gegenmaßnahmen ist es möglich, das spezifische Risiko einer Schwachstelle für ein Unternehmen und dessen Mitarbeitende darzustellen. Entsprechende Lösungen ermöglichen es, die Datenerfassung und -zusammenfassung zu automatisieren und drastisch zu beschleunigen. Vorschläge für weitere Schritte können festgelegt werden und der gesamte Prozess wird nachvollziehbar dokumentiert. Auf der Grundlage der genannten Faktoren stellen sie zudem eine erweiterte Bewertungsgrundlage zur Verfügung. Bei einer CVSS-Basisbewertung von 9,0 oder höher wird beispielsweise eine Anfangsbewertung von 2,0 festgelegt, zwei weitere Punkte werden hinzugefügt, wenn ein Proof-of-Concept-Code erkannt wird, weitere zwei, wenn es in der öffentlichen Aufmerksamkeit steht, und so weiter.
Schritt 4: Gegenmaßnahmen einleiten
Nach der Bewertung einer neuen Schwachstelle sollte ein Notfallplan die nächsten Schritte klar umreißen. Stellt die Schwachstelle eine realistische Bedrohung dar, sollten die zuständigen Personen sie als Vorfall markieren und Gegenmaßnahmen anstoßen. Um diese Phase des Prozesses zu beschleunigen, setzen wir beispielsweise auf einen angereicherten Score, bei dem eine Schwachstelle einen festgelegten Schwellenwert erhält. Wird dieser Schwellenwert überschritten, löst das einen Alarm aus. Die zugehörige Meldung enthält alle Informationen über die Schwachstelle aus dem CVE sowie die erforderlichen Maßnahmen.
Manchmal ist es ausgeschlossen, eine Schwachstelle sofort oder zeitnah zu beseitigen.
Der Prozess, um die Sicherheitslücke zu schließen, verläuft in jedem Unternehmen unterschiedlich. Um eine Rund-um-die-Uhr-Abdeckung zu gewährleisten, ernennen viele Unternehmen mehrere "Einsatzleiter". Ein Incident-Management-Tool sowie mobile Apps ermöglichen eine koordinierte Reaktion auf Vorfälle mit Triage, zentralisierten Benachrichtigungen, Delegation von Gegenmaßnahmen und Incident Tracking.
Manchmal ist es ausgeschlossen, eine Schwachstelle sofort oder zeitnah zu beseitigen, etwa durch limitierende Faktoren beim Software-Entwicklungsprozess, zirkuläre Abhängigkeiten sowie Abhängigkeiten von anderen Teams oder externen Dienstleistern. In solchen Fällen kann es sinnvoll sein, die Sicherheitslücke temporär zu schließen. Hierzu kann man ein Feature-Flag-System heranziehen, das betroffene Funktionalitäten schnell und ohne einen vollständigen Softwarerelease deaktivieren kann – sofern diese nicht eine kritische Funktion im IT-System haben. Zudem kann man durch den Einsatz dynamischer Application-Firewalls- bzw. Application-Security-Instrumentierung spezifisch die Ausführung von Requests unterbinden, die zur Ausnutzung dieser Schwachstelle führen können. Diese Sofortmaßnahmen erhöhen jedoch die Komplexität des IT-Systems über Gebühr und sollten als provisorische Maßnahmen verstanden und entsprechend dokumentiert werden. Sobald die erkannte Sicherheitslücke an ihrer Quelle geschlossen werden konnte, kann man die Maßnahmen schließlich zurücknehmen.
Schließlich ist es sinnvoll, die Erkenntnisse aus dem gesamten Prozess zu teilen und Betroffene zu benachrichtigen. Das kann helfen, die Schwachstelle über die eigenen Systeme hinaus schneller auszumerzen. Wir veröffentlichen bei größeren Schwachstellen im letzten Schritt die Ergebnisse zusammen mit neuen, sofort einsatzbereiten Regeln für unsere Kunden.
Neue Schwachstellen sicher erkennen und Einfallstore nachvollziehbar schließen
Die Entwicklung neuer Anwendungen und Technologien nimmt weiter Fahrt auf – und gleichzeitig tobt der Kampf böswilliger Akteure gegen die Abwehrlinien der IT-Sicherheit. Die steigende Komplexität der Anwendungssysteme und die Vielzahl von, teilweise kleinteiligen, Abhängigkeiten moderner Systeme von externen Quellen erhöhen das Risiko und die Angriffsfläche weiter.
Können Unternehmen Risiken frühzeitig erkennen und haben sie bewährte Prozesse etabliert, um Sicherheitslücken schnellstmöglich zu schließen, hilft ihnen das, den Angreifern einen Schritt voraus zu sein. Die notwendigen Prozessschritte werden dabei oftmals arbeitsteilig ausgeführt und enthalten wichtige Informationen für zukünftige Vorgänge. In vielen Fällen werden auch Folgetätigkeiten ausgelöst, die ebenfalls dokumentiert und bewertet werden müssen. Ein robustes Framework, eine Unterstützung in der Vorgangsdokumentation und -automatisierung und der Zugriff auf qualitativ hochwertige Informationen ist daher unabdingbar, um einen professionellen und effizienten Schwachstellenprozess in Cloud-Anwendungen auf- und umzusetzen.