Banner Aktuelle IT-Sicherheit Online-Schulungen Rabatt
Mit <kes>+ lesen

Vulnerability-Management in Zeiten von DevOps

Computerumgebungen sind in den vergangenen Jahren durch die Cloud-Migration und neue Verfahren wie Containerisierung weitaus komplexer geworden – IT- und Sicherheits-Teams müssen eine viel größere Angriffsfläche überwachen als noch vor wenigen Jahren. Zudem können sich Anwendungen und – aufgrund der dynamischen Bereitstellung in der Cloud –sogar Architekturen täglich oder stündlich ändern. Sicherheitsverantwortliche müssen daher auch ihre Strategien zum Schwachstellenmanagement überdenken.

Lesezeit 11 Min.

Von Georgeta Toth, München

Noch vor wenigen Jahren war das Schwachstellenmanagement eine Angelegenheit unterschiedlicher Silos, die kaum oder gar nicht miteinander verbunden waren. In diesem klassischen Ansatz scannt ein Team die Server und Desktops im Unternehmensnetzwerk auf Fehlkonfigurationen und sucht bekannte Schwachstellen in kommerziellen Softwareanwendungen. Werden dabei Probleme entdeckt, werden sie sozusagen über die Mauer geworfen, damit Systemadministratoren und Operations sie beheben können. Anwendungsentwickler wiederum sind für die Überwachung intern entwickelter Anwendungen verantwortlich. Völlig getrennt von dieser technischen Seite operieren, sofern überhaupt vorhanden, Aufklärungsmaßnahmen für Mitarbeiter bezüglich des Social-Engineerings. In solchen Umgebungen ist es ausgesprochen schwierig zu analysieren, wie verschiedene Arten von Schwachstellen zusammenwirken können, um kritische Daten und geistiges Eigentum zu exponieren. Ein derartiges Schwachstellenmanagement ist für moderne Unternehmen ineffizient und teuer.

Vollständige Sichtbarkeit

Eine wesentliche Grundlage für ein effektives Vulnerability-Management ist die vollständige und transparente Sichtbarkeit des gesamten Informations-Ökosystems. Es reicht nicht mehr aus, das Unternehmensnetzwerk vierteljährlich oder monatlich auf Schwachstellen von Servern und Desktops zu scannen. Sicherheitsteams müssen in der Lage sein, die gesamte Angriffsfläche zu überwachen, einschließlich Cloud-Plattformen sowie virtualisierten und containerisierten Umgebungen. Mehr noch: Sie müssen mit der dynamischen Natur dieses Umfelds zurechtkommen, in dem sich neue Instanzen von Anwendungen und Diensten in kürzester Zeit auf virtuellen Maschinen starten lassen.

Auch operative Fragen sind Teil des Bilds: Da Teams mehr Daten auf mehr Arten von Endpunkten und Plattformen zu überwachen haben, müssen sie die Anzahl der Endpunkt-Agenten und Bewertungswerkzeuge minimieren. Wo man für jede Plattform unterschiedliche Tools verwendet, wird es schwierig, Daten gemeinsam zu nutzen, zu korrelieren und eine „Single-Pane-of-Glass“-Sichtbarkeit zu erreichen. Schließlich müssen Organisationen sicherstellen, dass sich einmal entdeckte Schwachstellen schnell beheben lassen, bevor Angreifer sie ausnutzen können.

Scan-Lösungen zur Schwachstellenbewertung müssen heute natürlich mit virtuellen Diensten, wie VMWare, und mit Infrastructure-as-a-Service-(IaaS)-Plattformen, wie AWS und Azure, integriert werden. Nur das ermöglicht es, einen sofortigen Einblick in Risiken zu erhalten, die durch Veränderungen in der Infrastruktur entstehen. Beispielsweise kann man in virtuellen Umgebungen einen Agenten zur Schwachstellenbewertung in die Images der Instanzen einbetten. So lassen sich neue Komponenten eines Dienstes automatisch auf Schwachstellen scannen, sobald sie in Betrieb genommen werden – statt auf den nächsten geplanten Scan warten zu müssen. Eventuell vorhandene Schwachstellen können dann sofort entschärft werden, um eine Exposition des Dienstes zu vermeiden.

Cloud-Umgebungen stellen auch deshalb eine besondere Herausforderung dar, weil Sicherheits-Teams oft nicht informiert werden, wenn neue Infrastruktur auf IaaS-Plattformen bereitgestellt wird. Um hier Abhilfe zu schaffen, kann man Tools zur Schwachstellenbewertung in AWS-, Azure- und andere Cloud-Plattformen integrieren, die neue Geräte selbsttätig erkennen und automatisch bewerten. Sie können auch sicherstellen, dass „Golden Images“ vor dem Einsatz gehärtet werden. Für zusätzliche Sichtbarkeit lassen sich – wie bei virtuellen Maschinen – Agenten in diese Images einbetten.

Vereinfachte Bewertung

In heutigen Netzen verfügen viele Endpunkte nur über eine limitierte Konnektivität zum Unternehmensnetzwerk. Einige sind außerdem zu sensibel, um mit klassischen Bewertungsmethoden gescannt zu werden, oder erfordern Zugriffsrechte, die man nur einem sehr begrenzten Personenkreis zur Verfügung stellen möchte. Hier benötigt man ebenfalls moderne Agenten, die solche Geräte sicher bewerten und Daten an ein zentrales Tool zur Schwachstellenbewertung zurücksenden können. Ein universeller Agent kann diesen Ansatz noch skalierbarer und nachhaltiger machen, indem er unterschiedlichste Daten von verschiedenen Systemen, Endpunkten und virtuellen Maschinen sammelt und die Ergebnisse an mehrere Lösungen zur Schwachstellenanalyse weitergibt.

Automatisierte Workflows

Der dritte Schlüssel zu einem agilen Vulnerability-Management ist die Festlegung automatisierter Workflows zur Beseitigung von Schwachstellen. Die Integration von Scan-Tools in interne Ticketingsysteme automatisiert die Übergabe von Schwachstellendaten und -aufgaben an die IT-Operations. So erhalten die Operations-Teams schneller Zugriff auf mehr Daten – und die Wahrscheinlichkeit einer Exposition sinkt, weil Systeme zeitnah gepatcht sowie Fehlkonfigurationen schnell und präzise behoben werden können. Im Rahmen von SecOps-Konzepten sollte auch die IT-Security Einblick zumindest in schwachstellenbezogene Probleme im Ticketingsystem haben, um den Fortschritt verfolgen, Verzögerungen bei kritischen Behebungsaufgaben erkennen und dem Operations-Team zusätzliche Unterstützung bieten zu können.

Wenn es sinnvoll ist, kann die Behebung von Schwachstellen noch weiter automatisiert werden, etwa durch Integration der Schwachstellenbewertung in ein Orchestrierungswerkzeug. Dann können Sicherheitsteams in Abstimmung mit Operations schnell Patches erstellen und anwenden. Denkbar ist auch eine Umgebung, in der Sicherheitsteams Systeme selbstständig und automatisiert patchen, wobei sie von Operations überwacht und unterstützt werden. Je stärker man die Schwachstellenbehebung automatisiert, desto kürzer werden Expositionszeiten und desto harmonischer können Security und Operations im Sinne von SecOps zusammenarbeiten.

Evolution der Tools

Die meisten Organisationen sind mit traditionellen Tools zum Dynamic Application-Security-Testing (DAST) vertraut. Diese wurden ursprünglich entwickelt, um Schwachstellen in Webanwendungen zu erkennen, die mit älteren Sprachen wie HTML, PHP und Perl erstellt wurden. Die in vielen Schwachstellenanalyse-Tools integrierten Anwendungsscanner sind ebenfalls für diese Klasse von Anwendungen optimiert.

Diese älteren Tools sind jedoch häufig nicht in der Lage, mit HTML5, dem Action-Message-Format (AMF), Single-Page-Application-(SPA)-Frameworks und -Bibliotheken sowie Toolkits, Diensten und Protokollen wie JSON, REST, GWT, SOAP und XML-RPC erstellte Rich-Web-Anwendungen effektiv zu testen. In der Folge können solche Tools die Backends und APIs dieser Anwendungen in der Regel nicht systematisch bewerten. Sie haben auch Schwierigkeiten, mit benutzerdefinierten Parametern und nicht-traditionellen Authentifizierungsverfahren zurechtzukommen. Auch mehrstufige Workflows, wie etwa Shopping-Cart-Sequenzen, stellen sie vor große Probleme.

Beim Einsatz traditioneller DAST-Tools mit Rich-Web-Anwendungen muss man daher damit rechnen, dass Angreifer Wege in das Backend finden und Zugriff auf die Kronjuwelen in Form persönlicher Informationen oder geistigen Eigentums erhalten können.

Ein modernes Programm zum Schwachstellenmanagement braucht Werkzeuge, die diese Probleme angehen können. Beispielsweise sind fortschrittliche DAST-Lösungen verfügbar, die einen „Universalübersetzer“ einsetzen, um Anwendungen mit ausgefeilten Schnittstellen, APIs und Protokollen zu verstehen und zu testen. Sie können mit benutzerdefinierten Parametern und fortgeschrittenen Authentifizierungsverfahren umgehen und automatisch Schwachstellen in komplexen Anwendungs-Workflows wie Einkaufswagen erkennen.

Risiken von CI/CD

Die IT-Security hat es oft schwer, mit der Änderungsgeschwindigkeit von Produktionsanwendungen Schritt zu halten, die mit Techniken wie agiler Entwicklung, Continuous-Integration (CI), Continuous-Delivery (CD), DevOps und Containern einhergehen. Mit solchen Verfahren können Softwareentwickler viel schneller auf Kunden- und Geschäftsanforderungen reagieren – und neuer Anwendungscode kann so auf wöchentlicher, täglicher, stündlicher oder sogar minütlicher Basis in Produktion gehen. Leider bleibt die Sicherheit dabei oft auf der Strecke.

Wo der Anwendungscode schnell von der Entwicklung über das Deployment in die Produktion gelangt, kann er tage- oder wochenlang für Außenstehende zugänglich sein, ohne auf Schwachstellen und Codierungsfehler gescannt zu werden – das eröffnet Wege für kostspielige Datenlecks. Nicht selten merken die Sicherheitsteams gar nicht einmal, dass modifizierter Code auf Cloud-Plattformen und in containerisierten und virtualisierten Umgebungen bereitgestellt wurde.

DevSecOps als Lösung

Eine Möglichkeit zur Bewältigung dieser Herausforderungen besteht darin, auf einen DevSecOps-Ansatz hinzuarbeiten, also Werkzeuge und Prozesse einzuführen, die es allen beteiligten Teams ermöglichen, zusammenzuarbeiten und die Sicherheit in jede Phase des Softwareentwicklungs-Lebenszyklus (SDLC) zu integrieren. Um dieses Ziel zu erreichen, kann die Schwachstellenanalyse in den SDLC integriert werden, um Entwicklungs-, Test- und Staging-Umgebungen sowie Produktionssysteme abzudecken. Agenten zur Schwachstellenbewertung lassen sich in die Images von Instanzen virtueller Umgebungen einbetten, sodass man jede virtuelle Maschine auf Schwachstellen und Fehlkonfigurationen hin untersuchen kann, sobald sie hochgefahren wird. Werkzeuge zur Schwachstellenbewertung lassen sich in Container-Registries integrieren, sodass Images noch vor ihrer Bereitstellung bewertet werden können.

Darüber hinaus ist Automatisierung auch auf CI- und CD-Prozesse anwendbar: Dafür werden beispielsweise Tools für die kontinuierliche Integration so konfiguriert, dass automatisierte Aufgaben in der Build-Pipeline starten. Das CI-Tool kann dabei die API eines Schwachstellenbewertungs- oder DAST-Produkts aufrufen und es veranlassen, den Anwendungscode bis hinunter auf die Ebene der Container und virtuellen Maschinen auf Schwachstellen zu prüfen.

Dieser SDLC-weite Ansatz stellt sicher, dass sich Schwachstellen erkennen lassen, bevor ein Anwendungs-Build auf die nächste Ebene befördert oder in Produktion genommen wird. Dazu gehören Schwachstellen für Bedrohungen auf Anwendungsebene, wie SQL-Injection, Cross-Site-Scripting (XSS) und Cross-Site-Request-Forgery-Angriffe (CSRF), sowie Schwachstellen in Betriebssystemen, Webservern und Containern. Werden in der Codierungs- oder Testphase des SDLC Probleme entdeckt, können sie zur sofortigen Behebung durch die Entwickler an ein Ticketing-System gesendet werden.

Diese Workflows erfordern möglicherweise einige Investitionen im Vorfeld, aber das langfristige Ergebnis ist die unübertroffene Agilität, die mit DevSecOps einhergeht. Wesentliche Vorteile sind:

  • Reduzierung des Risikos, da Schwachstellen beseitigt werden, bevor neuer Code Angreifern ausgesetzt wird
  • Kostensenkung, da die Fehlerbeseitigung umso teurer wird, je später sie erfolgt
  • Beschleunigung der Freigabe sicherer neuer Funktionen und Anwendungen, da die Sicherheit von einer am Ende zu überwindenden Hürde zu einem integralen Bestandteil des Entwicklungsprozesses wird

Mitarbeiter einbinden

Phishing ist nach wie vor die beliebteste Methode von Angreifern, an Zugangsdaten und letztlich an vertrauliche Informationen zu gelangen. Deshalb müssen moderne Programme zum Schwachstellenmanagement auch Aktivitäten umfassen, welche die Widerstandsfähigkeit gegen Phishing- und andere Social-Engineering-Angriffe erhöhen und es IT-Organisationen ermöglichen, schnell zu reagieren, wenn solche Angriffe gemeldet werden. So kann die Aufklärung der Mitarbeiter über Motive und Methoden die Erfolgsrate von Phishing-E-Mails spürbar verringern; vor allem wenn sie auch Phishing-Simulationen umfasst. Eine solche Aufklärung hilft, Angriffe schneller zu entdecken und zu blockieren, da sie Mitarbeiter in die Lage versetzt, Phishing-Versuche zu erkennen und zu melden.

Phishing-Simulationen liefern Daten, die Sicherheitsteams dabei helfen können, Risiken zu quantifizieren und Schwachstellen zu erkennen und zu beheben. Diese Daten bieten Einblicke in Gruppen und Einzelpersonen (auch im Top-Management), die am anfälligsten für Phishing oder Social-Engineering sind und geben Hinweise auf die Arten von Angriffen, die am wahrscheinlichsten Erfolg haben.

Eine weitere Reduzierung des Risikos ermöglichen Tools zur Analyse des Benutzerverhaltens (User-Behavior-Analytics, UBA) und zur Sicherheitsanalyse: Sie überwachen das Benutzerverhalten und erkennen Anomalien, die auf eine aktive Kompromittierung hindeuten. Wenn diesen Tools der Kontext der Schwachstellen zugeführt wird, können sie Vorfälle gründlicher untersuchen und Prioritäten setzen. Anders herum können Analysewerkzeuge Personen mit kompromittierten Berechtigungen und Gruppen identifizieren, die mit kritischen Assets umgehen, sodass diese bei der Bewertung und Behebung von Schwachstellen Vorrang haben können.

Abwehrmaßnahmen gegen Social-Engineering und Phishing sollte man dabei nicht isoliert von anderen Aspekten des Vulnerability-Managements behandeln! Schließlich sind die meisten Social-Engineering- und Phishing-Versuche lediglich der Auftakt zu mehrstufigen Angriffen, die zusätzliche Aktivitäten umfassen. Dazu gehören oft das Implantieren von Malware auf Endpunkten, die Eskalation von Privilegien, das Auffinden von Zielen im Netzwerk und das Herausschmuggeln von Informationen. Um zu verstehen, welche Schwachstellen am kritischsten sind, wird die Vogelperspektive von SecOps benötigt, um alle Arten von Schwachstellen und ihre Beziehung zueinander zu erkennen.

Abschätzung des Gesamtrisikos

Ein Schlüsselmerkmal für ein erfolgreiches Vulnerability-Management ist die Fähigkeit, Schwachstellen richtig zu priorisieren, sodass sich die Abhilfemaßnahmen auf die risikoreichsten Probleme konzentrieren können. Dies ist heutzutage besonders wichtig, da die hohe Zahl der entdeckten Schwachstellen überwältigend sein kann (und oft auch ist).

Ratings nach dem Common Vulnerability Scoring-System (CVSS) können in manchen Kontexten nützlich sein, aber sie sind im Wesentlichen Verallgemeinerungen des potenziellen Schweregrades für eine Vielzahl von Branchen und Unternehmenstypen – und berücksichtigen nicht den geschäftlichen Kontext in einzelnen Branchen, geschweige denn einzelnen Unternehmen.

Ein modernes Vulnerability-Management sollte die Bewertungssysteme Dritter wie CVSS daher durch zwei Techniken ergänzen:

  • Ein Risikobewertungssystem, das auf den Geschäftskontext des spezifischen Unternehmens zugeschnitten ist sowie
  • Penetrationstests zur Validierung der Risikobewertungen auf der Grundlage realer Bedingungen und bestehender Kontrollen.

Zu den fortgeschrittenen Werkzeugen zur Bewertung von Schwachstellen gehört die Fähigkeit, deren tatsächliches Risiko auf der Grundlage einer Vielzahl von Faktoren zu modellieren, die mit den potenziellen Auswirkungen einer Schwachstelle auf ein bestimmtes Unternehmen und der Wahrscheinlichkeit ihrer Ausnutzung zusammenhängen.

Die potenziellen Auswirkungen hängen von Faktoren wie der Häufigkeit der Schwachstelle im Unternehmen, dem Wert der zu schützenden Informationen, Ressourcen und Systeme sowie den potenziellen Auswirkungen eines unterbrochenen Dienstes auf den Geschäftsbetrieb ab.

Die Wahrscheinlichkeit, dass eine Schwachstelle ausgenutzt wird, hängt von Faktoren wie der Zugänglichkeit der Schwachstelle für Angreifer, der Verfügbarkeit von auf die Schwachstelle zugeschnittenen Exploit-Modulen und Malware-Kits sowie der für die Ausnutzung der Schwachstelle erforderlichen Fähigkeiten ab.

Diese Faktoren können abgewogen und kombiniert werden, um Bewertungen zu erstellen, die das tatsächliche Risiko jeder Schwachstelle für ein bestimmtes Unternehmen viel genauer widerspiegeln als generische Bewertungssysteme.

Koordinierte Ergänzung durch Penetrationstests

Penetrationstests werden oft als eine eigenständige Aktivität behandelt, die eine Gruppe von Spezialisten durchführt, welche nicht mit dem Rest der IT-Organisation interagieren muss. Es gibt jedoch ein starkes Argument dafür, dass Penetrationstests mit anderen Elementen eines modernen Schwachstellen-Management-Programms koordiniert werden sollten.

Pen-Tests können Schwachstellen aufdecken, die schwerwiegend erscheinen, aber ein relativ geringes Risiko für die Organisation darstellen. Sie können andere Schwachstellen aufdecken, die für sich allein genommen harmlos erscheinen mögen, die aber nacheinander ausgenutzt werden können, um die Ziele eines Angreifers zu verwirklichen.

Daher sollte man Pen-Tests als ein Kernstück des modernen Schwachstellenmanagements behandeln! Informationen aus Netzwerk-Scans, Anwendungstests, Phishing-Simulationen und anderen Informationsquellen zu Schwachstellen sollten an Tester weitergegeben werden, die diese Informationen dann dazu verwenden können, Tests durchzuführen, die das tatsächliche Risiko für die Organisation bewerten, das von jedweder Art Schwachstelle ausgeht.

Außerdem müssen die Ergebnisse der Pen-Tests analysiert und denjenigen Teams zur Verfügung gestellt werden, die Schwachstellen kurzfristig priorisieren und beheben. Manager, die Entscheidungen darüber treffen, wie die Cybersicherheitsabwehr langfristig zu stärken ist, sollten diese Ergebnisse ebenfalls kennen.

Georgeta Toth ist Regional Director Central Europe bei Rapid7.

Diesen Beitrag teilen: