In der griechischen Mythologie wurde Achilles von einem Pfeil getötet, der seine einzige verwundbare Stelle traf – die Ferse. Ganz klar hätte Achilles einen besseren Vulnerability-Management-Plan gebraucht!1 Anders als Achilles, der nur eine verwundbare Stelle hatte, gibt es in Ihrer Cloud-Umgebung viele verschiedene Bereiche, die Schwachstellen bieten können. Nach dem ordentlichen Aufsetzen einer Zugriffskontrolle ist das Einrichten eines kontinuierlichen Prozesses für das Managen möglicher Schwachstellen im Allgemeinen die beste Investition in Bezug auf Fokus, Zeit und Geld, die Sie zum Verbessern der Sicherheit treffen können.
Es gibt eine deutliche Überlappung zwischen Vulnerability Management und Patch Management. In vielen Organisationen ist der wichtigste Grund für das Installieren von Patches das Beheben von Sicherheitslücken – und nicht das Beheben von funktionalen Bugs oder das Ergänzen von Features. Es gibt auch eine Überlappung zwischen Vulnerability Management und Configuration Management, da falsche Konfigurationen oft zu Sicherheitslücken führen können, selbst wenn Sie sorgfältig alle Sicherheitspatches installiert haben. Es gibt unterschiedliche Tools und Prozesse für das Managen von Schwachstellen, Konfigurationen und Patches, aus Gründen der Praktikabilität werden wir sie alle hier in diesem Kapitel behandeln.
Leider ist Vulnerability Management nur selten so simpel, einfach das automatische Einspielen von Patches zu aktivieren und seiner Wege zu gehen. In Cloud-Umgebungen können Schwachstellen auf vielen verschiedenen Ebenen gefunden werden – auf der des physischen Gebäudes, der Rechenhardware, des Betriebssystems, des von Ihnen geschriebenen Codes und in Bibliotheken, die Sie verwenden. Das Cloud Shared Responsibility Model, das in Kapitel 1 beschrieben wird, kann Ihnen dabei helfen, zu verstehen, wo Ihr Cloud-Provider für Schwachstellen verantwortlich ist, und die Inhalte dieses Kapitels werden Ihnen dabei helfen, Ihre Verantwortlichkeiten zu managen. In den meisten Fällen werden Sie viele verschiedene Tools und Prozesse benötigen, um mit den unterschiedlichen Formen von Schwachstellen umzugehen.
Vulnerability versus Patch Management
Die Begriffe Vulnerability Management und Patch Management werden oft synonym genutzt, aber es gibt Unterschiede. Software-Patches beheben häufig sowohl funktionale Probleme als auch Schwachstellen, und nicht alle Sicherheitslücken werden durch das Anwenden von Patches geschlossen. Vielleicht erkennt Ihr Vulnerability-Management-Prozess eine unsichere Konfiguration, die sich ohne Patches beheben lässt, oder eine Sicherheitslücke wird abgemildert, indem man ein Feature deaktiviert, statt einen Patch einzuspielen.
In Cloud-Umgebungen ist die Änderungsrate oft höher als in On-Premises-Umgebungen, und diese fortlaufenden Änderungen können klassische Prozesse zum Vulnerability Management hilflos im Staub zurücklassen. Wie in Kapitel 3 besprochen, müssen Sie Cloud-APIs zum Inventarisieren nutzen und jedes System bei seiner Erzeugung in Ihre Vulnerability-Management-Tools eintragen, um zu verhindern, dass Sie neue Systeme übersehen.
Neben der Änderungsrate sorgen beliebte und aktuelle Hosting-Modelle wie Container oder Serverless Hosts für die Notwendigkeit eines anderen Vorgehens beim Vulnerability Management, weil sich bestehende Tools entweder nicht nutzen lassen oder nicht effizient genug dafür sind. Haben Sie viele Container, können Sie nicht wie bei virtuellen Maschinen jeden davon mit einem schwergewichtigen Vulnerability-Management-Tool versehen, das jeweils ein paar Prozent Ihrer CPU frisst. Irgendwann hätten Sie Hunderte Kopien des Agenten auf dem System und keine CPU-Leistung mehr für die eigentliche Arbeit übrig!
Hinzu kommt: Obwohl Continuous Integration (CI), Continuous Delivery (CD) und die Microservices-Architektur nichts direkt mit Cloud Computing zu tun haben, werden sie doch oft bei einem Übergang in die Cloud eingeführt. Diese Techniken können aber das Vulnerability Management massiv verändern.
Ein klassischer Prozess zum Vulnerability Management sieht beispielsweise wie folgt aus:
Solch ein Prozess ist darauf ausgelegt, das Risiko eines Sicherheitsvorfalls gegen das Risiko eines Ausfalls der Produktivumgebung durch Updates gegeneinander abzuwägen. Ich erzähle den Leuten immer gern, dass Sicherheit ganz leicht zu erreichen ist – schalten Sie einfach alles ab und bedecken Sie es mit Beton. Das Absichern von Umgebungen, während sie weiterhin laufen und nutzbar sein sollen, ist viel schwieriger.
Aber in unserer schönen neuen Welt des Cloud Computing, der Infrastructure as Code, CI/CD und der Microservices-Architektur haben wir Möglichkeiten, das Risiko eines Ausfalls zu verringern und damit die Balance zu verschieben:
Jedes dieser Elemente bringt die Balance hin zu einer höheren Verfügbarkeit, was bedeutet, dass Sicherheitsupdates proaktiver eingespielt werden können und die Gesamtverfügbarkeit des Systems trotzdem höher ist. Das wiederum reduziert Ihr Gesamtrisiko. Der neue Prozess zum Vulnerability Management sieht wie folgt aus:
Es ist weiterhin ein wenig manuelle Arbeit beim Vulnerability Management in Schritt 4 nötig, aber viel weniger als im Standardprozess. Wie Sie in diesem Kapitel sehen werden, gibt es viele Arten von Schwachstellen, aber dieser High-Level-Prozess wird bei den meisten passen.
Um was für Arten von Schwachstellen müssen Sie sich kümmern? Stellen Sie sich vor, Ihre Anwendung sei Teil eines Stacks aus Komponenten, wobei die Anwendung ganz oben und die physischen Computer und Räumlichkeiten ganz unten stehen. Wir werden oben auf dem Stack beginnen und uns nach unten vorarbeiten. Es gibt viele unterschiedliche Möglichkeiten, die Elemente im Stack zu kategorisieren, aber wir werden das Diagramm des Shared Responsibility Model aus Kapitel 1 nutzen (siehe Abbildung 5-1).
Abbildung 5-1: Cloud Shared Responsibility Model
Verantwortung des Kunden bei IaaS, PaaS und SaaS
Es liegt fast immer in der Verantwortung des Kunden, zu entscheiden, wie in der Cloud Zugriff auf die Daten in der Anwendung oder im Service gewährt wird. Schwachstellen auf der Ebene des Datenzugriffs lassen sich fast immer auf Probleme bei der Zugriffsverwaltung zurückführen, wie zum Beispiel, dass Ressourcen für die Öffentlichkeit erreichbar sind, Zugriff für Individuen möglich ist, die diesen nicht mehr länger brauchen, oder schwache Credentials zum Einsatz kommen. Diese Themen wurden genauer in Kapitel 4 behandelt.
Verantwortung des Kunden bei IaaS und PaaS
Nutzen Sie SaaS, liegt die Sicherheit des Anwendungscodes in der Verantwortung Ihres Providers, aber es kann sicherheitsrelevante Konfigurationselemente geben, für die Sie als Kunde zuständig sind. Nutzen Sie beispielsweise ein Webmailsystem, müssen Sie bestimmte Konfigurationseinstellungen durchdenken und sinnvolle Werte angeben, wie zum Beispiel zur Zwei-Faktor-Authentifikation oder zum Malware-Scanning. Außerdem müssen Sie diese Konfigurationseinstellungen überprüfen und anpassen, wenn sie sich von Ihren Anforderungen entfernen.
Nutzen Sie kein SaaS, schreiben Sie vermutlich selbst Anwendungscode – egal ob er auf virtuellen Maschinen, einem aPaaS oder einem Serverless-Angebot gehostet wird. Unabhängig davon, wie gut Ihr Team ist: Ihr Code wird mit größter Wahrscheinlichkeit Fehler enthalten, und mindestens ein paar davon werden auch die Sicherheit betreffen. Neben Ihrem eigenen Code werden Sie oft Frameworks, Bibliotheken und anderen Code von dritter Seite einsetzen, der ebenfalls Schwachstellen enthalten kann. Sicherheitslücken oder Malware in diesem übernommenen Code werden oft eher bei Angriffen ausgenutzt, weil die gleiche Attacke bei vielen Anwendungen funktionieren wird.
Schwachstellen in beliebten Open-Source-Komponenten, wie zum Beispiel Log4j, Apache Struts oder OpenSSL, haben in vielen Anwendungen zu Sicherheitslücken geführt, die diese Komponenten nutzen. Es ist für Angreifer viel einfacher, diese Problemstellen auszunutzen, als spezifischen Anwendungscode zu analysieren, weshalb die Schwachstellen dort ein höheres Angriffsrisiko darstellen als bei selbst geschriebenem Code!
Das klassische Beispiel einer Anwendungssicherheitslücke ist ein Buffer Overflow. Viele Anwendungen sind allerdings mittlerweile in Sprachen geschrieben, in denen es schwierig ist, einen Buffer Overflow zu erzeugen. Daher geschehen solche Angriffe zwar noch, aber sie stehen nicht mehr ganz oben auf der Liste. Im Folgenden sind ein paar Beispiele für Anwendungsschwachstellen aus der OWASP-Top-10-Liste des Jahres 2021 aufgeführt. Bei jedem dieser Beispiele können Zugriffskontrolle, Firewalls und andere Sicherheitsmaßnahmen das System größtenteils nicht effektiv schützen, wenn diese Schwachstellen im Anwendungscode vorhanden sind:
Kaputte Zugriffskontrolle
Der Abschnitt zum Datenzugriff dreht sich um Fehler beim Gewähren von Zugriff, aber hier geht es um Fehler im Anwendungscode, der diesen Zugriff eigentlich steuert. Ein häufig anzutreffender Fehler bei Webanwendungen ist, dem zu vertrauen, was der Browser Ihnen mitteilt, etwa: »Ich habe überprüft, dass der Parameter in diesem Feld sicher ist«, wenn der Browser völlig unter der Kontrolle der angreifenden Person steht und nicht vertrauenswürdig ist. Cross-Site Scripting ist ein Beispiel für diese Art von Fehlern.
Injection-Angriffe
Hier erhält Ihre Anwendung nicht vertrauenswürdige Daten von einem böswilligen User und interpretiert sie. Ein klassisches Beispiel ist eine SQL Injection, bei der bei einem Angriff Informationen geschickt werden, die die Query dazu bringen, nicht nur das geplante, sondern alles in der Tabelle zurückzugeben.
Angreifbare oder veraltete Komponenten
Nutzen Sie in Ihrer Anwendung eine Komponente und besitzt diese Komponente eine Schwachstelle, wird auch Ihre Anwendung wahrscheinlich eine Schwachstelle haben. Log4j ist das bekannteste Beispiel dafür – eine Sicherheitslücke in einem vermeintlich harmlosen Logging-Paket hat es jedem erlaubt, eine Anwendung zu übernehmen, wenn sie dazu gebracht wurde, einen bestimmten String in das Anwendungs-Log zu schreiben.
Standards und Frameworks für sichere Software
Es kann schwierig sein, zu wissen, ob die Komponenten und Anwendungen, die Sie verwenden, unabsichtliche Schwachstellen besitzen – oder gar Malware, die absichtlich eingefügt wurde. Es gibt in der Branche einige Initiativen, die bei diesem Problem helfen wollen.
Standards wie das NIST Secure Software Development Framework (SSDF, https://oreil.ly/HFyDp) sind vergleichbar mit den Standards für die Lebensmittelsicherheit, nur für Software – sie liefern Anforderungen für das Schaffen sicherer Software. Diese Standards beschreiben üblicherweise, was Sie erfüllen müssen, aber nicht, wie das zu tun ist.
Eine Software Bill of Materials (SBOM) ist wie eine Zutatenliste für Software, und Sie wissen so, was in die Anwendung oder Komponente gegeben wurde. Das kann das automatische Scannen auf Schwachstellen in Ihren Abhängigkeiten genauer machen. Es gibt mittlerweile eine Reihe von Tools, die SBOMs erzeugen und konsumieren können, und zurzeit gibt es zwei verbreitete SBOM-Formate – CycloneDX (https://cyclonedx.org) und SPDX (https://spdx.dev). SBOMs sind bei manchen Standards, zum Beispiel dem NIST SSDF, verpflichtend und werden vermutlich in Zukunft von Organisationen beim Kaufen von Software in den Vertrag geschrieben werden.
Sicherheits-Frameworks wie Supply-Chain Levels for Software Artifacts (SLSA, https://slsa.dev) liefern eine Reihe von Richtlinien dazu, wie Sie Ihre Entwicklungs- und Build-Umgebungen sicher gestalten können und wie Sie Anwendungen und Komponenten signieren. Sie erfahren dort, wie Sie einige der Anforderungen in den Standards erfüllen, und wenn Sie Komponenten konsumieren, kann das SLSA-Level Ihnen eine Idee davon geben, wie ausgereift der Prozess für das Erzeugen jeder Komponente ist.
Angriffe auf Anwendungsebene sind unabhängig von der Art und Weise des Deployments möglich – auf eine virtuelle Maschine, einen aPaaS oder eine Serverless-Plattform. Manche der in Kapitel 6 besprochenen Werkzeuge, wie zum Beispiel Webanwendungs-Firewalls, können als Sicherheitsnetz dienen, wenn es eine Schwachstelle im Anwendungscode gibt. Lassen Sie sich aber nicht täuschen – das schnelle Entdecken und Beheben von Sicherheitslücken im Code und in Abhängigkeiten ist Ihre erste und wichtigste Verteidigungslinie.
Auch wenn Frameworks für Webanwendungen, wie zum Beispiel React, eine Quelle für Sicherheitslücken sein können, die Sie managen müssen, können diese ebenfalls dabei helfen, Schwachstellen in Ihrem eigenen Code zu vermeiden. Viele Frameworks haben einen eingebauten Schutz gegen Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), SQL Injection (SQLi), Clickjacking und andere Arten von Angriffen. Wenn Sie die Schutzmaßnahmen verstehen, die von Ihrem Framework angeboten werden, und diese einsetzen, können Sie manche dieser Probleme leicht vermeiden.
Verantwortung der Kunden bei IaaS und manchmal PaaS
In vielen Fällen nutzt Ihr Anwendungscode Middleware oder Plattformkomponenten wie Datenbanken, Anwendungsserver oder Message Queues. Wie bei den abhängigen Frameworks oder Bibliotheken können hier Schwachstellen zu großen Problemen führen, weil Angriffe darauf attraktiv sind – es lassen sich bei vielen verschiedenen Applikationen die gleichen Sicherheitslücken ausnutzen, oft ohne die Anwendung selbst überhaupt verstehen zu müssen.
Betreiben Sie diese Komponenten selbst, müssen Sie auf Updates achten, sie testen und anwenden. Diese Komponenten laufen entweder direkt in Ihren virtuellen Maschinen oder innerhalb der von Ihnen deployten Container. Beachten Sie, dass Tools, die zum Inventarisieren von Dingen in virtuellen Maschinen genutzt werden, normalerweise in Containern nicht fündig werden.
Werden die Komponenten von Ihrem Cloud-Provider als Service bereitgestellt, hat dieser im Allgemeinen auch die Verantwortung, sie zu patchen. Es gibt aber einen Haken! In manchen Fällen werden die Updates nicht automatisch gepusht, weil sie einen Ausfall verursachen könnten. Dann sind Sie eventuell doch in der Verantwortung, sie zu testen und zu einem passenden Zeitpunkt den Knopf zum Deployen zu drücken.
Neben dem Anwenden von Patches müssen Sie sich auch darum kümmern, wie die Middleware konfiguriert ist – selbst in einer PaaS-Umgebung. Hier ein paar Beispiele für Probleme mit der Konfiguration der Middleware oder der Plattform, die zu einem Sicherheitsvorfall oder einem Einbruch führen können:
Für jede Komponente, die Sie verwenden, müssen Sie sich die verfügbaren Konfigurationseinstellungen anschauen und eine Liste der sicherheitsrelevanten Einstellungen zusammen mit ihren korrekten Werten erstellen. Diese Werte sollten zwingend genutzt werden, wenn die Komponente erstmalig zum Leben erweckt wird, und dann auch später regelmäßig überprüft werden, um sicherzustellen, dass alles weiterhin korrekt eingestellt ist und es nicht zu einer »Konfigurationsdrift« kommt. Diese Art von manuellem Monitoring wird oft als Benchmarking, Health Checking oder einfach Configuration Management bezeichnet.
Sie können natürlich Benchmarks oder Konfigurationsspezifikationen komplett selbst schreiben, aber ich empfehle Ihnen, mit einem Satz an Best Practices zu starten, wie zum Beispiel den CIS-Benchmarks des Center for Internet Security (https://oreil.ly/BNjmr). Diese können Sie an Ihre Organisation und Ihre Deployments anpassen und sogar eigene Änderungen beitragen, wenn Sie ein Problem finden oder eine Verbesserung vorschlagen wollen. Weil die Benchmarks aus einer Community kommen, profitieren Sie eher von aktuellen Konfigurations-Checks, die neue Bedrohungen und neue Versionen von Plattformprodukten und Betriebssystemen berücksichtigen. Eine Reihe verbreiteter Produkte können die CIS-Benchmarks ohne großen Aufwand ausführen.
Verantwortung des Kunden bei IaaS
Die meisten Menschen denken bei Vulnerability Management an Patches für Betriebssysteme. Es ist Patch Tuesday5 – Zeit, die Patches zu testen und auszurollen! Aber während Betriebssystempatches zwar ein wichtiger Teil des Vulnerability Management sind, gibt es da noch mehr.
Wie bei der Middleware/Plattform-Schicht des Stacks müssen Sie sicherstellen, dass neben dem Patchen auch die Konfiguration korrekt ist. Das können Sie durch Benchmarks für die OS-Konfiguration erreichen, die beim Deployen der Betriebssysteminstanz gesetzt und danach regelmäßig überprüft werden.
Zudem tendieren Betriebssysteme dazu, eine Menge unterschiedlicher Komponenten mitzubringen, die in Ihrer Umgebung nicht erforderlich sind. Belassen Sie diese Komponenten in einer laufenden Instanz, kann das eine große Quelle für Schwachstellen sein – entweder durch Bugs oder durch eine Fehlkonfiguration. Daher ist es wichtig, alles abzuschalten, was nicht erforderlich ist. Dies wird oft als Hardening bezeichnet. Ein Vorteil von Containern ist, dass Sie oft mit einem minimalen Container beginnen und dann nur das installieren, was Sie brauchen, damit die Anwendung im Container laufen kann – ein Prozess, der den Container ganz automatisch »härtet«.
Viele Cloud-Provider bieten einen Katalog mit Images virtueller Maschinen, die automatisch aktuell gehalten werden, sodass Sie beim Deployen ein vernünftiges und aktuelles System erhalten. Wendet der Cloud-Provider beim Deployen aber nicht automatisch Patches an, sollten Sie das als Teil Ihres Prozesses tun.
Ein Betriebssystem besteht im Allgemeinen aus einem Kernel, der alle anderen Programme ausführt, und vielen verschiedenen Userspace-Programmen. Viele Container enthalten ebenfalls die Userspace-Anteile des Betriebssystems, weshalb Vulnerability Management und Configuration Management für das Betriebssystem ebenso zur Sicherheit von Containern beitragen.
In den meisten Fällen ist der Cloud-Provider für die Hypervisoren verantwortlich. Sind Sie für irgendwelche Hypervisoren zuständig, gehören sie dennoch ebenfalls zu dieser Kategorie, weil sie letztendlich Betriebssysteme für einen speziellen Zweck sind – dafür entworfen, andere Betriebssysteme zu betreiben. Hypervisoren sind typischerweise schon gehärtet, aber auch für sie gibt es regelmäßig Patches und Konfigurationseinstellungen, die per Benchmarking korrekt für Ihre Umgebung gesetzt werden müssen.
Verantwortung des Kunden bei IaaS
Zum Vulnerability Management auf Netzwerkebene gehören zwei wichtige Aufgaben: das Managen der Netzwerkkomponenten selbst und das Managen, welche Kommunikation im Netzwerk erlaubt ist.
Die Netzwerkkomponenten selbst, wie zum Beispiel Router, Firewalls oder Switches, benötigen meist ein Patch Management und ein Security Configuration Management, das dem für Betriebssysteme ähnelt – allerdings kommen meist andere Tools zum Einsatz.
Das Managen der Sicherheit des Netzwerkverkehrs, der diese Devices durchläuft, wird genauer in Kapitel 6 behandelt.
Verantwortung des Providers
In einer Infrastructure-as-a-Service-Umgebung befindet sich die virtualisierte Infrastruktur (virtuelles Netzwerk, virtuelle Maschinen, Storage) in der Verantwortung Ihres Cloud-Providers. Aber in einer containerbasierten Umgebung sind Sie eventuell für die virtualisierte Infrastruktur oder die Plattform zuständig, die auf die Angebote des Cloud-Providers aufsetzen. So können beispielsweise Schwachstellen durch eine Fehlkonfiguration oder fehlende Patches der Container Runtime (wie Docker) oder der Orchestrierungsschicht (wie Kubernetes) entstehen.
Verantwortung des Providers
In den meisten Fällen liegt die Verantwortung für die physische Infrastruktur bei Ihrem Cloud-Provider. Es gibt allerdings ein paar Situationen, in denen Sie für die Konfiguration oder das Vulnerability Management auf physischer Ebene zuständig sein können. Betreiben Sie eine Private Cloud oder erhalten Sie Bare-Metal-Systeme als Service bereitgestellt, sind Sie vielleicht für Teile der physischen Infrastruktur zuständig. So können beispielsweise Schwachstellen durch fehlende BIOS-/Microcode-Updates oder durch eine schlechte Sicherheitskonfiguration des Baseboard Management Controller verursacht werden, der einen Remote-Zugriff auf die physischen Systeme erlaubt.
Nachdem Sie jetzt wissen, wo sich überall Schwachstellen verstecken können, müssen Sie nun herausfinden, was für Arten von Sicherheitslücken in Ihrer Umgebung am ehesten ein Problem sein können. Wie ich in diesem Buch schon mehrfach beschrieben habe, versuchen Sie zunächst, sich den wichtigsten Bereich für Ihre Organisation vorzunehmen und diesen durchzuarbeiten, bevor Sie sich dem nächsten zuwenden. Ein häufiger Fehler ist, vier oder fünf verschiedene Toolsets und Prozesse zu nutzen, nur damit Sie irgendwo Häkchen auf einer Liste mit Best Practices setzen können, die aber beim Finden und Beheben von Schwachstellen nicht wirklich viel an Wert beitragen.
Wenn Sie sich die Asset Management Pipeline aus Kapitel 3 noch mal ins Gedächtnis rufen, ist dies der Teil, in dem wir unsere schicken Tools in die Pipeline einbauen (siehe Abbildung 5-2), um sicherzustellen, dass wir unsere Risiken kennen und angemessen mit ihnen umgehen.
Abbildung 5-2: Beispiel für eine Asset Management Pipeline
In Kapitel 3 haben wir uns mit der linken Hälfte des Diagramms befasst – Schatten-IT über den Einkauf finden und sicherstellen, dass wir die Assets von all den verschiedenen Cloud-Providern inventarisieren. Jetzt besteht das Ziel darin, die Lecks zu stopfen, die auf der rechten Seite des Diagramms aufgeführt sind. Wir wollen beispielsweise unsere »Tool«-Lecks (die dadurch entstehen, dass wir bekannte Assets nicht schützen), aber auch unser »Erkenntnis«-Lecks minimieren (die entstehen, weil wir mit bekannten Ergebnissen nicht sinnvoll umgehen).
Schauen wir uns zuerst den Bereich mit den Tool-Lecks im Diagramm an. Stellen Sie sich vor, dass die Durchmesser der Rohre in Ihrer Umgebung durch eine Kombination aus der Anzahl an Problemen, die Sie in diesen Bereichen finden, und der Auswirkungen dieser Probleme auf Ihr Business bestimmt werden. Wenn ich das tue, erkenne ich manchmal, dass in einem bestimmten Bereich ziemlich viel Wasser heraussprudelt – entweder weil es kein Tool in diesem Bereich gibt oder weil das Tool viele Assets nicht sieht. Das kann zu vielen unbekannten Risiken führen!
Enthält Ihre Umgebung beispielsweise viele Windows-Systeme mit kritischen Daten, kann das Stopfen von Lecks in Ihrer Antiviren-Pipeline beispielsweise ziemlich weit oben auf Ihrer Liste stehen. Haben Sie andererseits fast nur Webanwendungen, die unter Linux, als aPaaS oder auf einer Serverless-Plattform laufen, werden Sie sich vermutlich eher darauf konzentrieren, sicherzustellen, dass Sie Schwachstellen in der Webanwendung finden und beseitigen, bevor Sie sich zu viele Gedanken über die wenigen Windows-Systeme machen, die nur mit weniger kritischen Daten umgehen.
Als Nächstes werfen Sie im Diagramm einen Blick auf den Bereich mit den Erkenntnislecks. Dieses Mal wird der Durchmesser der Rohre durch die Anzahl an Erkenntnissen bestimmt, die jedes Tool ermittelt, und wie kritisch diese sind. Vielleicht stellen Sie dabei fest, dass Sie Tools haben, bei denen Sie viele wichtige Ergebnisse ignorieren und damit viele unbekannte Risiken erzeugen.
Es gibt viele, viele verschiedene Arten von Tools, die sich bei den Schwachstellen überlappen, nach denen sie suchen. Manche der Tools werden in klassischen Umgebungen schon seit Jahren eingesetzt, andere werden neu für Cloud-Umgebungen geschaffen. Die folgenden Abschnitte stellen die verschiedenen Kategorien an Vulnerability und Configuration Management Tools vor, aber denken Sie daran, dass viele Produkte mehr als eine dieser Kategorien behandeln.
Neben Betriebssystempatches sind Network Vulnerability Scans der andere wichtige Teil des Vulnerability Management. Und das aus gutem Grund – diese Scans sind sehr gut darin, bestimmte Arten von Schwachstellen zu finden – dennoch ist es wichtig, ihre Grenzen zu kennen.
Network Vulnerability Scanner schauen sich keine Softwarekomponenten an. Sie schicken einfach Netzwerk-Requests los, versuchen, herauszufinden, wer darauf lauscht, und prüfen auf angreifbare Versionen von Serveranwendungen oder Konfigurationen mit Schwachstellen. Ein Beispiel: Ein Network Vulnerability Scanner könnte erkennen, dass einer der Services auf einem System unsichere Verbindungen erlaubt, was basierend auf den Informationen in einem SSL/TLS-Handshake einen POODLE-Angriff (https://oreil.ly/DDsB4) erlaubt. Der Scanner kann aber nicht wissen, was die verschiedenen Webanwendungen oder REST-APIs an dieser Netzwerkadresse so treiben, und er kann auch nicht die Komponenten der Bibliotheksversionen innerhalb dieser Systeme erkennen.
Network Vulnerability Scanner können offensichtlich nicht das ganze Internet scannen, ja noch nicht einmal Ihren ganzen Cloud-Provider, und sie wissen auch nicht auf magische Art und Weise, für welche Systeme Sie verantwortlich sind. Also müssen Sie diesen Tools mitteilen, welche Netzwerkadressen zu scannen sind, und wenn Sie Adressen übersehen haben, wird es dort Schwachstellen geben, von denen Sie nichts wissen. Darum ist ein automatisches Inventory Management wie in Kapitel 3 besprochen so wichtig. Viele Cloud-Komponenten sind vom Internet aus erreichbar, und weil bei Angriffen Schwachstellen ausgenutzt werden können, die in verbreiteten Komponenten gefunden wurden, müssen Ihre Zyklen aus Inventarisieren von vom Internet aus erreichbaren Komponenten, Scannen und Reagieren auf Erkenntnisse so kurz wie möglich sein.
Machen Sie zudem nicht den Fehler, zu glauben, dass Network Vulnerability Scans überflüssig seien, nur weil Sie isolierte Komponenten nutzen (siehe Kapitel 6). Es gibt oft Diskussionen zwischen Netzwerkteams und den Teams für das Vulnerability Scanning, ob Löcher in die Firewall gestochen werden können, um den Scanner auch in einem beschränkten Bereich zu nutzen. Ich plädiere dafür, denn das Risiko einer unbekannten Schwachstelle ist viel höher als das Risiko, dass bei einem Angriff diese spezifischen Firewall-Regeln ausgenutzt werden, um in den beschränkten Bereich zu kommen. Daher sollten Vulnerability Scanner jede Komponente scannen können, auch wenn dadurch die Schutzmaßnahmen des Netzwerks an seinen Grenzen ein kleines bisschen aufgeweicht werden müssen. Ich habe schon viele Vorfälle gesehen, bei denen ein Angreifer in den begrenzten Bereich gelangt und dort in ein angreifbares System eingestiegen ist. Im Gegensatz dazu mag es zwar schon einmal vorgekommen sein, dass der Scanner bei einem Angriff übernommen und sein Netzwerkzugriff ausgenutzt wurde, um Systeme anzugreifen, aber ich selbst habe davon noch nichts gehört.
Schwachstellen im Netzwerk, die in einem Segment eines geschützten Netzwerks einer Virtual Private Cloud gefunden werden, haben eine niedrigere Priorität als Sicherheitslücken in einer Komponente, die direkt aus dem Internet erreichbar ist. Trotzdem sollten Sie sie finden lassen und auch beheben. Angreifer haben die sehr unangenehme Eigenschaft, in Teilen des Netzwerks zu landen, in denen sie nicht sein sollten.
Abhängig von der Funktionsweise Ihrer Deployment-Pipeline sollten Sie wenn möglich einen Network Vulnerability Scan der Testumgebung mit in den Deployment-Prozess aufnehmen. Alle Erkenntnisse aus der Testumgebung sollten in einem Bug Tracker erfasst werden, und wenn es keine falsch-positiven Ergebnisse sind, sollten sie idealerweise das Deployment aufhalten.
Es gibt viele cloudbasierte Network Vulnerability Scanner, die Sie als Service kaufen und ausführen können, ohne eine zugehörige Infrastruktur zu benötigen. Aber eventuell müssen Sie Relay-Systeme oder Container in Ihrem Netzwerk erstellen, um Bereiche scannen zu können, die für das Internet nicht offen sind.
Netzwerkbasierte Tools können Schwachstellen finden, ohne zu wissen, mit welchen Prozessen sie reden – sie sehen nur, welcher Prozess bei einer gegebenen IP-Adresse auf den unterschiedlichen TCP/UDP-Ports antwortet. Das kann aber zu falsch-positiven Ergebnissen führen, weil das Tool oft die beschriebene Version einer Komponente nutzt, die entweder nicht stimmt oder aus der nicht hervorgeht, ob schon Sicherheitspatches installiert wurden. Sie brauchen einen gut dokumentierten und effektiven Prozess, um falsch-positive Ergebnisse auszumerzen, denn ansonsten riskieren Sie, dass Teams die gesamten Scan-Ergebnisse ignorieren, weil manche davon nicht korrekt sind.
Während Network Vulnerability Scanner an die Türen und Fenster des Hauses klopfen, kommen agentenlose Scanner und Configuration Management Systems hinein und schnüffeln herum. Agentenlose Scanner verbinden sich ebenfalls über das Netzwerk, nutzen aber Credentials, um in die zu testenden Systeme zu gelangen. Der Begriff »agentenlos« unterscheidet diese Scanner von den im nächsten Abschnitt beschriebenen, bei denen ein »Agent« auf jedem Zielsystem laufen muss. In manchen Fällen kann ein Tool sowohl Netzwerkscans als auch Scans mit oder ohne Agent durchführen.
Beim Einsatz von agentenlosen Scannern sollten Sie an das Least-Privilege-Prinzip denken und dem Scanner so wenige Berechtigungen geben wie zum Ausführen des Scans gerade nötig. Leider brauchen viele Scanner vollständige administrative Berechtigungen, damit sie funktionieren, aber das ändert sich langsam, und manche Scanner haben auch eine Least Privilege-Option.
Agentenlose Scanner können Schwachstellen finden, die Network Vulnerability Scanner nicht finden können. Haben Sie zum Beispiel eine Local Privilege Escalation als Sicherheitslücke, die es einem normalen User erlaubt, das gesamte System zu übernehmen, würde ein Network Vulnerability Scanner nicht die »normalen« Berechtigungen haben, um dieses Problem zu sehen – ein agentenloser Scanner aber schon.
Agentenlose Scanner führen häufig sowohl eine Überprüfung auf fehlende Patches als auch ein Security Configuration Management durch, wie die folgenden Beispiele zeigen:
In manchen Fällen können die Tools Probleme mit Fehlkonfigurationen oder angreifbaren Paketen sogar selbst beheben, statt sie nur zu erkennen. Aber wie schon erwähnt: Solche automatischen Fixes können die Verfügbarkeit stören, wenn sie zu neuen Problemen führen oder nicht zu den Anforderungen Ihrer Umgebung passen. Wenn es möglich ist, sollten Sie lieber ein ganz neues System ausrollen, das die Schwachstelle nicht enthält, statt zu versuchen, ein bestehendes System zu fixen.
Wenn es doch all diese Möglichkeiten gibt – warum brauchen Sie dann sowohl einen agentenlosen Scanner als auch einen Network Vulnerability Scanner? Es gibt zwar vieles an gleichen Funktionalitäten, aber agentenlose Scanner müssen prinzipiell das System verstehen, das sie sich anschauen – sie funktionieren also nicht gut mit Betriebssystemversionen, Software oder anderen Elementen, die sie nicht erkennen. Network Vulnerability Scanner sind »dümmer« und klopfen nur Netzwerkadressen ab. Aber das ist in manchen Situationen durchaus von Vorteil, weil sie Probleme für alle Elemente finden können – selbst bei Devices, die keine Log-ins erlauben, wie Network Appliances, IoT Devices oder Container.
Agentenbasierte Scanner und Configuration Management Systems führen im Allgemeinen die gleiche Art von Checks wie agentenlose Scanner aus. Aber anstatt ein zentrales »Pull«-Modell zu haben, bei dem ein Controller-System jedes System scannen lässt und die Ergebnisse einsammelt, installieren agentenbasierte Scanner eine kleine Komponente auf jedem System – den Agenten –, die die Ergebnisse an den Controller »pusht«.
Es gibt für diesen Ansatz Vor- und Nachteile, die in den folgenden Unterabschnitten beschrieben werden.
Agentenbasierte Scanner eliminieren eine Risikoursache, die agentenlosen Scannern inhärent ist, indem sie es zum Problem der Person oder des Automatismus machen, der die Agenten deployt.
Wie im vorherigen Abschnitt erwähnt, benötigen agentenlose Scanner Credentials – und zwar meist privilegierte Credentials – für alle Systeme, die sie scannen. Auch wenn das Risiko beim Zuteilen dieser Credentials im Allgemeinen viel geringer als das Risiko unerkannter Schwachstellen in Ihrer Umgebung ist, macht es den agentenlosen Scanner zu einem attraktiven Ziel für Angriffe. Im Gegensatz dazu erfordern agentenbasierte Scanner zwar die Berechtigung zum initialen Deployen, die Scanner-Konsole empfängt dann aber nur noch Berichte von den Agenten, und sie besitzt nur noch die Berechtigungen, die die Agenten ihr zugestehen (was trotzdem ein vollständig privilegierter Zugriff sein kann).
Agenten müssen deployt und aktuell gehalten werden, und eine Schwachstelle im Agenten kann Ihre gesamte Infrastruktur in Gefahr bringen. Aber ein gut designter Agent im Read-only-Modus wird die Auswirkungen einer »feindlichen Übernahme« über die Scanner-Konsole klein halten können – die angreifende Person wird zwar immer noch einen Haufen Informationen zu Schwachstellen erhalten, aber vermutlich keinen privilegierten Zugriff auf alle Systeme.
Für agentenlose Scanner müssen Sie keinen Code deployen, aber oft sind die Zielsysteme so zu konfigurieren, dass die Scanner Zugriff erhalten können. So müssen Sie beispielsweise eine User-ID erstellen und dieser eine gewisse Stufe des privilegierten sudo-Zugriffs gewähren.
Agentenlose Scanner benötigen eingehenden Netzwerkzugriff, damit sie arbeiten können. Wie schon erwähnt, kann ein Zulassen dieses Netzwerkzugriffs das Risiko in Ihrer Umgebung erhöhen. Die meisten Tools besitzen auch die Option, ein Relay-System innerhalb Ihres Netzwerks zu deployen, das eine ausgehende Verbindung aufsetzt und eine Steuerung darüber ermöglicht, aber das Relay-System ist ein weiteres System, das betreut werden muss.
Agentenbasierte Systeme benötigen nur ausgehende Verbindungen und müssen keine eingehenden Verbindungen zulassen. Ausgehende Verbindungen haben auch noch ein gewisses Risiko, aber das ist oft geringer als das Risiko, mit dem eingehende Verbindungen behaftet sind.
Bei agentenlosen und agentenbasierten Scannern können Sie sich am Least-Privilege-Prinzip orientieren und der User-ID für den Scanner oder Agenten nur die notwendigen Berechtigungen erteilen. Manche Betriebssysteme bieten aber noch weitere Wege an, die Möglichkeiten laufender Prozesse einzuschränken, wie zum Beispiel SELinux oder AppArmor unter Linux. Solche Systeme lassen sich manchmal nur schwierig effektiv anwenden, aber sie begrenzen die Rechte der Scanner im Allgemeinen besser als extra erstellte Scanner-User.
Manche Tools können die Prüfungen wahlweise mit einem Agentenmodell oder einem agentenlosen Modell durchführen. Welches ist das bessere? Dafür gibt es keine allgemein richtige Antwort, aber es ist wichtig, die Vor- und Nachteile von beiden zu verstehen, wenn Sie eine Entscheidung treffen. Ich bevorzuge meist ein agentenbasiertes Modell, aber es gibt für beide Seiten gute Argumente, und das Wichtigste ist, dass Sie Configuration und Vulnerability Management überhaupt angehen.
Viele Cloud-Provider bieten agentenbasierte Scanner für ihre Cloud-Umgebung an. Diese sind eventuell einfacher automatisch zu deployen, und Sie müssen nicht erst manuell eine Liste mit Assets erstellen und an den Scanner übergeben.
In der Kategorie der Cloud Workload Protection Platforms werden Tools sowohl von Cloud-Providern als auch von Fremdfirmen angeboten. Sie sammeln Informationen zum Configuration und Vulnerability Management meist über Agenten oder agentenlose Methoden, über die Deployment-Pipeline oder ein Tool von dritter Seite ein. Vermarktet werden sie von den Providern gerne als »One-Stop Dashboard« für mehrere Sicherheitsfunktionen, unter anderem das Zugriffsmanagement, das Configuration Management und das Vulnerability Management in den Entwicklungs- und Deployment-Phasen.
Diese Tools bieten zudem die Möglichkeit, Infrastruktur oder Anwendungen zu managen, die nicht bei einem Cloud-Provider gehostet werden – entweder über On-Premise-Lösungen oder bei einem anderen Cloud-Provider – als Belohnung dafür, dass Sie sie für Ihre gesamte Infrastruktur verwenden. Manchmal werden sie auch als Cloud Native Application Protection Platforms (CNAPPs) bezeichnet.
Klassische agentenlose oder agentenbasierte Scanner funktionieren gut für virtuelle Maschinen, aber oft nicht so gut in Containerumgebungen. Container sollen sehr leichtgewichtige Prozesse sein, und das Deployen eines für eine VM-Umgebung gedachten Agenten in jedem Container kann zu schlechterer Performance und Problemen beim Skalieren führen. Und wenn Sie Container korrekt nutzen, erlauben Sie normalerweise kein klassisches Log-in über das Netzwerk, weshalb agentenlose Scanner für virtuelle Maschinen nicht funktionieren werden.
Aktuell sind zwei Vorgehensweisen verbreitet. Bei der ersten nutzen Sie Scanner, die sich die Container-Images anschauen und auf Schwachstellen untersuchen. Wird ein Image als angreifbar bewertet, wissen Sie, dass Sie keine neuen Container daraus erstellen und bestehende Container ersetzen sollten, die auf diesem Image basieren. Dies hat den Vorteil, dass kein Zugriff auf Produktivsysteme erforderlich ist, der Nachteil besteht aber darin, dass Sie nach dem Identifizieren eines angreifbaren Image ausreichend Inventurinformationen über all Ihre laufenden Container haben müssen, um sicherzugehen, dass Sie alle Container mit Schwachstellen ersetzen.
Sind Ihre Container zudem mutabel (können sich also mit der Zeit ändern), können zusätzliche Sicherheitslücken entstanden sein, die durch das Scannen der Images nicht zu entdecken sind. Aus diesem und anderen Gründen empfehle ich den Einsatz immutabler Container, die immer dann durch einen neuen Container ersetzt werden, wenn eine Änderung erforderlich ist. Das regelmäßige Ersetzen von Containern kann zudem dabei helfen, Threat Actors davon abzuhalten, sich in Ihrem Netzwerk einzunisten. Denn selbst wenn sie einen Container kompromittiert haben, wird dieser nach spätestens einer Woche (oder so) wieder verworfen – und der neue Container hat dann hoffentlich schon einen Fix für das Problem, das zur Kompromittierung führte.
Beim zweiten Ansatz konzentrieren Sie sich auf die laufenden Container und haben auf jedem Containerhost einen Agenten, der die Container auf seinem System scannt und berichtet, welche davon angreifbar sind, sodass man sie fixen (oder besser noch ersetzen) kann. Wird der Agent überall deployt, hat das den Vorteil, keine »vergessenen« Container zu haben, die weiterhin ein angreifbares Image nutzen, nachdem Sie schon ein neues mit der Korrektur erstellt haben. Der größte Nachteil ist natürlich, dass Sie auf jedem Host einen Agenten benötigen. Das kann ein Performanceproblem werden und wird eventuell auch nicht von Ihrem Provider unterstützt, wenn Sie ein Container-as-a-Service-Angebot nutzen.
Diese Ansätze schließen sich nicht gegenseitig aus, und manche Tools setzen auch auf beide. Verwenden Sie Container oder planen deren baldigen Einsatz, achten Sie darauf, eine Möglichkeit zu haben, auf Schwachstellen in den Images und/oder laufenden Containern scannen zu können und die Ergebnisse in ein Issue Tracking System einzuspielen.
Network Vulnerability Scanner laufen gegen Netzwerkadressen, aber Dynamic Web Application Vulnerability Scanner rufen spezifische URLs von laufenden Webanwendungen oder REST-APIs auf. Tools zum Dynamic Application Security Testing (DAST) können Probleme wie Cross-Site Scripting oder SQL-Injection-Schwachstellen finden, indem sie die Anwendung oder API wie ein User einsetzen. Diese Scanner benötigen oftmals Credentials.
Manche der Schwachstellen, die dynamische Scanner finden, können auch durch Web Application Firewalls (WAFs) geblockt werden (siehe Kapitel 6). Dadurch können Sie das Beheben dieses Problems vielleicht mit einer geringeren Priorität angehen, aber Sie sollten es trotzdem bald beheben, um Security in Depth zu ermöglichen. Sind die Anwendungssysteme nicht sauber konfiguriert, kann bei einem Angriff die WAF umgangen und die Anwendung direkt angesprochen werden.
Dynamische Scanner können im Allgemeinen automatisch anhand eines Zeitplans aufgerufen werden, sodass sie neue bekannte Schwachstellen markieren können, die entdeckt wurden. Auch lassen sie sich in eine Continuous Deployment Pipeline einbinden, um zu laufen, wenn Änderungen an der Anwendung vorgenommen werden. DAST-Tools sollten ihre Ergebnisse in ein Issue Tracking System einspielen und nicht davon abhängen, dass jemand daran denkt, sich den Bericht anzuschauen.
Während sich dynamische Application-Scanner die laufende Anwendung anschauen, prüfen Tools zum Static Application Security Testing (SAST) direkt den von Ihnen geschriebenen Code. Daher sind sie sehr gute Kandidaten für ein Ausführen als Teil der Deployment-Pipeline, wenn neuer Code eingecheckt wird – so erhalten Sie direktes Feedback. Diese Tools können sicherheitsrelevante Fehler wie zum Beispiel Speicherlecks oder Off-by-one-Fehler finden, die von Menschen nur schlecht zu erkennen sind. Weil der Quellcode analysiert wird, müssen Sie einen Scanner nutzen, der für die von Ihnen verwendete Sprache designt ist. Zum Glück wurden Scanner für eine Vielzahl verbreiteter Sprachen entwickelt, die auch noch als Service ausgeführt werden können. Die Seite mit Source Code Analysis Tools der OWASP (https://oreil.ly/w4vIb) ist eine gute Ressource, um ein Tool zu finden, das für Ihre Anwendung funktionieren wird.
Das größte Problem bei statischen Scannern ist, dass sie dazu tendieren, eine hohe Falsch-positiv-Rate zu habe, was in der Entwicklung zu Security Fatigue führen kann. Deployen Sie das statische Code-Scannen als Teil Ihrer Deployment-Pipeline, sollten Sie sicherstellen, dass es für die von Ihnen genutzten Sprachen funktioniert und dass die Entwicklung schnell und einfach falsch-positive Ergebnisse markieren kann, damit sie nicht bei jedem Scan von einem Berg nutzloser Ergebnisse überwältigt wird.
Tools zur Software Composition Analysis (SCA) sind eigentlich eine Erweiterung der statischen Codescanner. Sie schauen sich aber mehr die von Ihnen genutzten Open-Source-Abhängigkeiten als Ihren Quellcode an. Die meisten Anwendungen nutzen heutzutage viele Open-Source-Komponenten, wie zum Beispiel Frameworks oder Bibliotheken, und dort vorhandene Schwachstellen können zu großen Problemen führen. SCA-Tools erkennen automatisch die von Ihnen verwendeten Open-Source-Komponenten und deren Versionen und verbinden diese dann mit den dafür bekannten Schwachstellen. Sie können Ihnen dabei helfen, hochriskante Sicherheitslücken in Ihren Abhängigkeiten zu entdecken, wie zum Beispiel in Log4j, Apache Struts oder dem Spring Framework. Manche Tools können sogar Codeänderungen vorschlagen, mit denen neuere Versionen genutzt werden.
Neben dem Vulnerability Management können sich manche Produkte auch die Lizenzen der Open-Source-Komponenten anschauen, um sicherzustellen, dass Sie keine Komponenten nutzen, die auf von Ihnen nicht gewollte Lizenzmodelle setzen. Einige der Tools können auch eine Software Bill of Materials für Ihre Anwendung erzeugen – vergleichbar mit einer Zutatenliste für Lebensmittel. Manche Organisationen, unter anderem die US-Bundesbehörden, fordern mittlerweile eine SBOM für jedes Produkt, das sie kaufen. Deren Richtlinie finden Sie im »Software Supply Chain Security Guidance«-Dokument (https://oreil.ly/jjqfF), und es ist wahrscheinlich, dass andere Behörden und große Organisationen in Zukunft ähnliche Richtlinien erarbeiten werden.
Tools zum Interactive Application Security Testing (IAST) machen ein bisschen sowohl vom statischen Scannen wie auch vom dynamischen Scannen. Sie schauen sich an, wie der Code aussieht, und beobachten ihn aus dem Inneren, während er ausgeführt wird. Dazu wird der IAST-Code zusammen mit dem Anwendungscode geladen und beobachtet, während die Anwendung durch funktionale Tests, einen dynamischen Scanner oder echte Benutzer überprüft wird. IAST-Lösungen können oft beim Finden von Problemen und beim Ausmerzen falsch-positiver Ergebnisse effektiver sein als reine SAST- oder DAST-Lösungen.
Wie bei statischen Codescannern müssen die spezifische Sprache und die Runtime, die Sie einsetzen, vom Tool unterstützt werden. Weil es parallel zur Anwendung läuft, kann die Performance in Produktivumgebungen reduziert sein. Bei einer modernen Anwendungsinfrastruktur und entsprechenden Deployments kann diese Sorge im Allgemeinen verringert werden, indem man entweder horizontal skaliert oder indem die Deployment-Pipeline das IAST-Tool in einer Testumgebung ausführt, die einer Produktionsauslastung sehr ähnlich ist.
Tools zur Runtime Application Self-Protection (RASP) mögen ähnlich klingen wie die bisher beschriebenen Scanner, aber bei ihnen handelt es sich nicht um eine Scanning-Technologie. RASP-Lösungen beinhalten wie IAST-Lösungen einen Agenten, der parallel zu Ihrem Anwendungscode deployt wird. RASP-Tools sind jedoch dafür gedacht, Angriffe abzuwehren, statt Schwachstellen nur zu erkennen. (Eine Reihe von Produkten macht beides – sie erkennen Schwachstellen und blockieren Angriffe –, was sie gleichzeitig zu RASP- und IAST-Lösungen macht.) Wie IAST-Tools können RASP-Tools in manchen Fällen negative Auswirkungen auf die Performance haben, weil mehr Code in der Produktivumgebung läuft.
RASP-Lösungen bieten teilweise einen ähnlichen Schutz wie eine verteilte WAF, weil beide Angriffe in Produktivumgebungen abblocken. Daher werden RASP- und WAF-Lösungen in Kapitel 6 behandelt.
Manuelle Code-Reviews können teuer und zeitaufwendig, aber für das Finden vieler Arten von Schwachstellen auch besser als Tools zum Testen von Anwendungen sein. Zudem kann es das Lernen effektiver machen, wenn ein anderer erklärt, warum ein bestimmter Codeabschnitt eine Schwachstelle hat, als wenn man nur versucht, die Ergebnisse automatischer Tools zu verstehen.
Code-Reviews sind in vielen Umgebungen mit hohen Sicherheitsanforderungen Standard. In vielen anderen Situationen werden sie eventuell nur für Codeabschnitte genutzt, die für die Sicherheit besonders wichtig sind, wie zum Beispiel Bereiche, in denen eine Verschlüsselung oder die Zugriffskontrolle implementiert wird.
Ein Penetration Test (Pentest) wird von jemandem in Ihrem Auftrag ausgeführt. Sie bezahlen die Person dafür, dass sie versucht, unautorisierten Zugriff auf Ihre Systeme zu erlangen, und Ihnen dann erklärt, wo die Schwachstellen liegen. Es ist wichtig, darauf hinzuweisen, dass automatisierte Scans der weiter oben besprochenen Arten keine Penetration Tests sind, auch wenn sie von einem Pentester eventuell als Ausgangspunkt genommen werden. Größere Organisationen haben vielleicht selbst Pentester angestellt, viele greifen aber auch auf externe Firmen zurück.
Penetration Tests von einer unabhängigen dritten Seite werden von PCI DSS (https://oreil.ly/r0EtT) und FedRAMP-Standards (moderate und high, https://oreil.ly/o6sL7) gefordert, und sie können auch für andere Zertifizierungen und Bestätigungen erforderlich sein.
Beim Pentesting empfehle ich Ihnen, den Pentester mit Informationen über das Design des Systems zu versorgen, ihm aber keine geheimen Informationen wie Passwörter oder API-Schlüssel zukommen zu lassen. In manchen Fällen entscheiden Sie sich vielleicht auch dazu, ihm mehr als die initialen Zugriffsberechtigungen zuzuteilen (wie sie ein Angreifer von außen hätte) – entweder, damit die Widerstandskraft des Systems gegen böswillige Insider geprüft werden kann, oder um zu sehen, was möglich ist, wenn bei einem Angriff Schwachstellen in der äußeren Verteidigung gefunden werden.
Sie können sich auch dazu entscheiden, dem Pentester die Anwendung einfach so ohne weitere Informationen vorzusetzen oder nur wenige Zusatzhinweise zu geben. Aber es ist im Allgemeinen effektiver und zeiteffizienter, so viele Informationen wie möglich (neben den Credentials) über die Anwendung bereitzustellen, weil dann weniger Zeit für das Erkunden und mehr Zeit für das Finden tatsächlicher Schwachstellen aufgewendet wird. Denken Sie daran – bei einem echten Angriff steht meist mehr Zeit zur Verfügung, in Ihr System einzubrechen, als ein Pentester aufwenden kann!
Seien Sie sich darüber im Klaren, dass ein Pentester meist ein oder zwei Wege in Ihr System finden wird, aber nicht alle. Wird nichts oder nur sehr wenig gefunden, können Sie der Sicherheit Ihres Systems bis zu einem gewissen Grad vertrauen. Wenn aber ein größeres Problem entdeckt wird, das Sie dann beheben, müssen Sie erneut Tests durchführen (lassen), bis Sie akzeptable Ergebnisse erhalten. Pentesting ist im Allgemeinen ein ziemlich teurer Weg, Schwachstellen zu finden – liefern Ihnen die Pentester Ergebnisse, die auch ein automatisierter Scan hätte finden können, ist das meist Geld- und Zeitverschwendung. Pentesting geschieht oft gegen Ende des Release-Zyklus, was auch bedeutet, dass Probleme, die dabei gefunden werden, eher dafür sorgen, dass sich ein Release verzögert.
Automatisiertes Testen findet oft potenzielle Schwachstellen, während Pentesting (bei korrekter Ausführung) das tatsächlich erfolgreiche Ausnutzen von Sicherheitslücken im System zeigt. Daher sollten Sie das Beheben kritischer Pentest-Ergebnisse dem aller anderen Ergebnisse vorziehen – es sei denn, User melden etwas.
Bei den meisten Cloud-Service-Providern müssen Sie eine Genehmigung einholen, bevor Sie Penetration Tests auf Anwendungen loslassen, die auf deren Infrastruktur oder Plattform gehostet werden. Tun Sie das nicht, kann das die Nutzungsbedingungen des Providers verletzen und zu einem Ausfall führen – abhängig davon, wie der Provider auf den Angriff reagiert.
Penetration Testing und Red/Blue Teaming
Ein Penetration Test ist üblicherweise auf ein bestimmtes Ziel beschränkt, wie zum Beispiel auf eine neue Anwendung oder einen neuen Service, und er findet zu einem bestimmten Zeitpunkt statt, beispielsweise vor einem Produktiv-Deployment. Ein Pentester wird oft mit diversen Scanning-Tools beginnen, um potenzielle Schwachstellen zu finden, danach wird er dann versuchen, diese Schwachstellen auszunutzen.
Ein Red Team wird oft viele der Tools von Pentestern nutzen, schaut sich dann aber eher allgemein im gesamten Netzwerk oder in der Organisation um, um Schwachstellen zu finden. Ein Blue Team ist ein Verteidigungsteam, das versucht, das Red Team abzuwehren (und echte Angreifer!). Manche Organisationen stellen auch Purple Teams auf, in denen Red und Blue Teams gemeinsam daran arbeiten, gefundene Probleme zu beheben und für eine bessere Verteidigung zu sorgen.
In einer perfekten Welt würden alle Bugs und Schwachstellen erkannt und behoben werden, bevor sie von einem User gefunden würden. Nachdem Sie sich von Ihrem Lachanfall erholt haben, müssen Sie sich mit Reports zu Sicherheitslücken befassen, die Sie von Ihren Usern oder über Bug-Bounty-Programme erhalten.
Sie benötigen also einen gut definierten und schnellen Prozess, mit dem Sie überprüfen können, ob eine gemeldete Schwachstelle tatsächlich eine ist, um danach einen Fix ausrollen und die User informieren zu können. Bei einem Bug-Bounty-Programm haben Sie vielleicht nur einen begrenzten Zeitraum zur Verfügung, bevor die Sicherheitslücke publik gemacht wird – danach steigt das Risiko für einen böswilligen Angriff stark an.
User Reports überlappen sich teils mit einem Incident Management Process. Manchmal balancieren solche Reports auf dem schmalen Grat zwischen hilfreichem Bericht und Erpressungsversuch! Fühlen sich Ihre Sicherheitsverantwortlichen im Umgang mit Endusern, Public Relations oder juristischen Aspekten nicht wohl, brauchen Sie im Prozess eventuell zusätzlich noch jemanden, der auf Kommunikation spezialisiert ist, und/oder eine Juristin oder einen Juristen, die das Sicherheitsteam darin unterstützen, einen PR- oder juristischen Albtraum durchzustehen. Es gibt oft mehrere Aspekte, die zu entgegengesetzten Vorgehensweisen führen würden – den Wunsch, so wenig wie möglich zu sagen, um nicht rechtlich belangt werden zu können, den Wunsch, so transparent wie möglich zu kommunizieren, um eine PR-Katastrophe zu vermeiden, sowie den Wunsch, möglichst gar nichts zu sagen, um einen Einbruch zu verhindern, während die Schwachstelle noch behoben wird. Es gibt eine Reihe bemerkenswerter Fälle, in denen eine ungeschickte Reaktion auf eine berichtete Schwachstelle oder einen Einbruch mehr Schaden verursacht hat als das initiale Problem!6
Die meisten der in den vorherigen Abschnitten aufgeführten Tools können in Cloud-Umgebungen integriert werden, und die meisten Cloud-Provider haben Partnerschaften mit entsprechenden Herstellern oder besitzen ihre eigenen Vulnerability-Management-Tools.
Weil so viele Tools mehr als einen der Bereiche abdecken, ist es nicht sinnvoll, sie in die oben vorgestellten Kategorien einzugruppieren. Ich habe eine Liste mit repräsentativen Lösungen im Bereich Cloud Vulnerability und Configuration Management zusammengestellt, wobei jedes Tool nur sehr kurz erläutert wird. Manche dieser Tools besitzen auch Features zum Erkennen von Problemen und das Reagieren darauf (Kapitel 7), für die Zugriffsverwaltung (Kapitel 4), das Inventory and Asset Management (Kapitel 3) oder das Data Asset Management (Kapitel 2).
Keines der Tools ist besonders empfehlenswert, nur weil ich es mit in die Liste aufgenommen habe, und fehlende Tools sind nicht deshalb abzulehnen – es sind nur Beispiele, damit Sie nach dem Überwinden des ersten Marketingsturms durch den Anbieter besser erkennen können: »Oh, dieses Tool behauptet, die Bereiche x, y und z abzudecken.« Ich habe Tools mit aufgenommen, die gut in eine einzelne Kategorie passen, andere, die viele verschiedene Kategorien abdecken, und schließlich auch welche, die spezifisch für bekannte Cloud-Provider gedacht sind. Das ist ein Feld, das sehr starken Veränderungen unterworfen ist, und es tauchen immer wieder neue Projekte und neue Anbieter auf, oder es kommen neue Features hinzu.
Dies ist die Liste der Tools in alphabetischer Reihenfolge:
Statistisch gesehen, sind Menschen ganz schlecht in Statistik. Bewerten Sie Marketingaussagen, ist es wichtig, auf Tools zu setzen, die vernünftige falsch-positive und falsch-negative Raten besitzen. Ein extremes Beispiel: Markiert ein Tool alles als ein Problem, wird es auch alle echten Probleme finden (100% richtig-positive Rate), aber die falschpositive Rate wird so hoch sein, dass sie nutzlos ist. Markiert ein Tool umgekehrt nichts als Problem, wird die falsch-positive Rate perfekt sein (0%), aber keinerlei echtes Problem finden. Seien Sie also bei Marketingaussagen vorsichtig, die sich auf nur eine Seite der Gleichung konzentrieren!
Sie sollten nun verstanden haben, wo sich in Ihrer Umgebung die verletzlichsten Bereiche befinden und welche Tools und Prozesse Sie einsetzen können, um Schwachstellen zu finden und zu beheben. Jetzt benötigen Sie ein System, mit dem Sie Schwachstellen priorisieren können, die sich nicht schnell ausmerzen lassen, wobei »schnell« normalerweise in Bezug auf Zeitabschnitte in Ihrer Sicherheitsrichtlinie definiert ist.
Hier kommt ein Risikomanagementprozess ins Spiel – zum Ende der in Abbildung 5-2 gezeigten Pipeline hin. Jede Schwachstelle, die Sie finden und die nicht innerhalb der von Ihnen akzeptierten Richtlinien geschlossen werden kann, muss als Risiko evaluiert werden, sodass Ihnen die Wahrscheinlichkeit klar wird, mit der etwas Schlimmes passieren kann, und was für Auswirkungen das haben kann. In vielen Fällen akzeptieren Sie vielleicht das Risiko, um den Geschäftsbetrieb weiterbetreiben zu können. Aber die Risikobewertung führt eventuell zu zusätzlichen Sicherheitsmaßnahmen (um die Wahrscheinlichkeit zu reduzieren) oder Abschwächungen (um die Auswirkungen zu verringern), wie zum Beispiel zusätzlichen Tools oder Prozessen zum Erkennen oder Verhindern von Einbrüchen. Die Risikobewertung kann auch zu einem Vermeiden führen, indem beispielsweise das System in manchen Fällen abgeschaltet wird.
Ein Leck in der Pipeline bedeutet hier, dass Sie Schwachstellen gefunden haben, sie aber nicht direkt beheben konnten und auch nicht wirklich verstanden haben, wie schlecht sie für Ihr Business sein könnten. Der Einsatz eines bestehenden Frameworks für das Bewerten von Risiken, wie zum Beispiel NIST 800-30 oder ISO 31000, kann viel einfacher sein, als alles ganz von vorne beginnen zu müssen.
Sie brauchen kein total kompliziertes Risikomanagementprogramm, um daraus Gewinn zu ziehen – ein einfaches Risikoregister mit einem vereinbarten Prozess für das Bestimmen der Risikoschwere bringt einen schon sehr weit. Aber Sie haben das Vulnerability Management erst dann abgeschlossen, wenn Sie eine bewusste Entscheidung darüber getroffen haben, was Sie mit jeder nicht gelösten Schwachstelle tun. Diese Entscheidungen müssen regelmäßig neu bewertet werden – zum Beispiel vierteljährlich –, da sich die Umstände ändern könnten.
Können Sie nicht messen, wie gut Sie sich bei Ihrem Vulnerability-Management-Programm schlagen, können Sie im Allgemeinen auch nicht einschätzen, wie nützlich es ist und ob Sie Anpassungen vornehmen sollten. Metriken sind nützlich, aber auch gefährlich – sie helfen dabei, sich kontinuierlich zu verbessern und Probleme aufzudecken, aber sie können auch zu verrückten Entscheidungen führen. Achten Sie darauf, dass zu Ihrem Prozess des Überprüfens der Metriken und Ergebnisse auch eine Plausibilitätskontrolle gehört, die prüft, ob es entweder abschwächende Faktoren für eine Metrik gibt, die sich in die falsche Richtung entwickelt, oder ob die Metriken auf irgendeine Art und Weise manipuliert werden.
Es gibt beim Vulnerability Management viele verschiedene Metriken und viele Tools können diese für Sie berechnen. Metriken können auch von anderen Teams oder Business Units berichtet werden. Manchmal kann ein kleiner, freundlicher Wettbewerb dabei helfen, Teams zu motivieren, aber denken Sie auch daran, dass es manchen Teams selbstverständlich schwerer fällt, das Vulnerability Management im Auge zu behalten als anderen.
Jede Organisation ist anders, aber hier folgen einige Metriken, die ich in der Vergangenheit als nützlich empfunden habe.
Für jedes Tool stellt sich die Frage, welchen Anteil der relevanten Systeme es abdecken kann. So kann man sich zum Beispiel bei einem Dynamic Application Scanner fragen, welchen Anteil Ihrer Webanwendungen er testet, oder bei einem Netzwerkscanner, welcher Anteil Ihrer Cloud-IP-Adressen berücksichtigt wird. Diese Metriken können Ihnen dabei helfen, Lecks in Ihrer Asset and Vulnerability Management Pipeline zu erkennen. Sie sollten im Verlauf der Zeit 100% erreichen, wenn der Umfang der passenden Systeme für jedes Tool sauber definiert wurde.
Haben Sie Tools mit einer sehr niedrigen Coverage-Rate für Systeme oder Anwendungen, die eigentlich abgedeckt sein sollten, können Sie nicht viel damit anfangen. In vielen Fällen sollten Sie entweder ein Projekt aufsetzen, um die Coverage-Rate zu steigern, oder das Tool in den Ruhestand schicken.
Es ist oft nützlich, die Mean Time to Remediate (also die mittlere Zeit, bis ein Problem behoben ist) abhängig von den unterschiedlichen Risikoklassen und Umgebungen zu messen. So können Sie beispielsweise nach Schwere eines Risikos unterscheiden (und schnellere Fixes für »kritische« Probleme als für »weniger kritische« Sicherheitslücken einfordern) und diese nochmals nach Art der Systeme aufteilen (intern oder vom Internet aus erreichbar). Sie können dann entscheiden, ob diese Zeitrahmen in Bezug auf Ihr Threat-Modell ein akzeptables Risiko beinhalten.
Denken Sie daran, dass ein Beseitigen eines Risikos nicht immer das Installieren eines Patchs ist – es könnte auch bedeuten, ein Feature abzuschalten, sodass eine Schwachstelle nicht ausnutzbar ist. Ein Reduzieren des Risikos durch andere Maßnahmen als Patches sollte korrekt erfasst werden.
Diese Metriken können durch externe Faktoren sehr stark beeinflusst werden. Als beispielsweise die Spectre-/Meltdown-Sicherheitslücken bekannt wurden, standen für viele Systeme lange keine Patches zur Verfügung, was die Mean Time to Remediate (MTTR) nach oben trieb. In diesem Fall waren die Verzögerungen nicht auf ein Problem mit dem Vulnerability-Management-Programm zurückzuführen – die Computerwelt insgesamt wurde durch diese ernste Sicherheitslücke beeinträchtigt.
Die Metrik der Systeme/Anwendungen mit offenen Schwachstellen wird oft als Prozentwert ausgedrückt, da die absolute Zahl dazu tendiert, anzuwachsen, wenn zusätzliche Elemente überwacht werden. Diese Metrik wird oft nach unterschiedlichen Klassifikationen von Systemen/Anwendungen aufgeteilt, aber auch nach der Schwere der Schwachstelle und ob es sich um einen fehlenden Patch oder eine falsche Konfiguration handelt.
Beachten Sie, dass die Patch-Management-Komponente dieser Metrik zyklisch sein wird, weil sie steigt, wenn Schwachstellen bekannt werden, und wieder sinkt, wenn sie über normale Patch-Management-Prozesse angegangen werden. Genauso können Änderungen an der Benchmark dazu führen, dass die Configuration-Management-Komponente dieser Metrik temporär anwächst, bis die Systeme so konfiguriert wurden, dass sie der neuen Benchmark entsprechen.
Manche Organisationen messen die absolute Zahl an Schwachstellen statt die Systeme oder Anwendungen, die mindestens eine Schwachstelle besitzen. In den meisten Fällen ist das Messen der Anzahl der angreifbaren Systeme oder Anwendungen sinnvoller als das Messen der absoluten Zahl an Sicherheitslücken. Ein System, das eine kritische Schwachstelle besitzt, sorgt mehr oder weniger für das gleiche Risiko wie ein System mit fünf kritischen Schwachstellen – jede kann schnell ausgenutzt werden. Zudem ist die absolute Zahl an Sicherheitslücken oft kein gutes Indiz für den erforderlichen Aufwand, alle Probleme zu lösen, was zum Priorisieren nützlich wäre. Sie können auf einem Linux-System vielleicht Hunderte von Schwachstellen in wenigen Minuten beseitigen, indem Sie einen Befehl wie yum -y update; shutdown -r now ausführen.
Abwandlungen dieser Metrik lassen sich auch nutzen, um zusätzliche Metriken zu einem Gesamtrisiko und zur Effektivität zu ermitteln. So könnte diese Metrik beispielsweise in »Systeme/Anwendungen mit offenen Schwachstellen, deren Risiko akzeptiert wurde« und »Systeme/Anwendungen mit offenen Schwachstellen, die den Zeitrahmen der Richtlinie überschreiten und bei denen das Risiko nicht akzeptiert wurde« unterteilt werden, um Ihnen einen Hinweis darauf zu liefern, ob Sie zu viele Risiken akzeptieren oder ob Sie schnell genug patchen können.
Eine Metrik mit dem Anteil der Falsch-Positiven kann Ihnen dabei helfen, zu verstehen, wie gut Ihre Tools funktionieren und wie viel administrative Last auf Ihren Teams aufgrund von Problemen liegt. Wie schon erwähnt, sind bei manchen Arten von Tools Falsch-Positive nicht zu vermeiden. Aber ein Tool mit zu vielen Falsch-Positiven ist eher wenig nützlich.
Es kann auch sinnvoll sein, zu erfassen, wie viele Schwachstellen ein gegebenes Tool oder ein Prozess finden sollte, die aber dann auf anderem Weg bekannt wurden. Ein Tool oder Prozess mit zu vielen Falsch-Negativen kann zu einem falschen Gefühl von Sicherheit führen.
Tauchen Schwachstellen wieder auf, nachdem sie eigentlich behoben wurden, kann dahinter ein ernsthaftes Problem bei den Tools oder Prozessen stecken.
Eine Anmerkung zum Vulnerability Scoring
Die Frage, die so gut wie jeder als Erstes bei einer gegebenen Schwachstelle stellt, ist: »Wie schlimm ist sie?« Der verbreitetste Standard für »schlimm« ist das Common Vulnerability Scoring System (CVSS). Dieses System gibt es seit 2005, und im Einsatz sind am häufigsten zwei Hauptversionen (v2 und v3). Beide Versionen haben ihre Befürworter und Kritiker, aber die meisten Sicherheitsexperten stimmen darin überein, dass die Basiszahl, die Sie sowohl aus CVSSv2 wie auch aus CVSSv3 erhalten, für Ihre Umgebung und Ihre Organisation nicht alles aussagt. Es ist wichtig, Methoden zu haben, um CVSS-Scores für die bedrohte Landschaft und Ihre spezifische Umgebung anzupassen – entweder indem Sie CVSS Temporal und Environmental Scores nutzen oder auf eine andere Methode zurückgreifen.
Das kann aber schnell dazu führen, dass Klassifikationen zurechtgebogen werden, damit man keine Fristen verpasst. Metriken sind zwar nützlich, aber es ist wichtig, das eigentliche Ziel nicht aus den Augen zu verlieren – nämlich Sicherheitsvorfälle zu verhindern.
In vielen Fällen müssen wir uns nicht allzu viele Gedanken darüber machen, wie schlimm die Schwachstelle ist. Standardvorgehen in Cloud-Umgebungen sollte sein, automatisch Sicherheitspatches anzuwenden und automatisierte Tests auszuführen, um zu sehen, ob das zu Problemen führt. Nur wenn ein Sicherheitspatch oder eine Konfigurationsänderung nicht zur Verfügung steht, Probleme verursacht oder aus anderen Gründen nicht umgesetzt werden kann, sollten Sie sich die Mühe machen, manuell zu ermitteln, wie groß ein Risiko für Ihre Umgebung ist.
Viele Organisationen besitzen auf die eine oder andere Art und Weise ein Change Management. In seiner einfachsten Form sollte es sicherstellen, dass Änderungen nur dann umgesetzt werden, wenn sie genehmigt wurden, und dass dabei ein Bewertung der Risiken dieser Änderung stattfand.
Change Management kann das Vulnerability Management unterstützen, indem es sicherstellt, dass vorgeschlagene Änderungen keine neuen Sicherheitslücken im System aufreißen. Schlecht gemacht, kann ein Change Management das Vulnerability Management aber auch behindern und das Gesamtrisiko anwachsen lassen, indem die Änderungen ausgebremst werden, die zum Beheben von Schwachstellen erforderlich sind. Wie weiter oben in diesem Kapitel besprochen, können einige der neuen Technologien in Cloud-Umgebungen das Risiko eines vollständigen Ausfalls verringern, sodass weniger manuelles Change Management erforderlich ist, um das gleiche Niveau beim operationalen Risiko zu erreichen. Zu einem Gesamt-Cloud-Vulnerability-Management-Programm kann auch gehören, die Prozesse des Change Management anzupassen.
So kann beispielsweise das Pushen von neuem Code in die Produktivumgebung zusammen mit Sicherheitskorrekturen eine ganz normale Aktivität sein, die automatisch von einem Änderungskontrollgremium genehmigt wird, vorausgesetzt, es gibt einen ausgewiesenen Prozess, um schnell zu einem guten Zustand zurückzukehren.
Dies kann durch ein weiteres Update, ein Rollback zurück auf eine frühere Version oder das Abschalten des Traffic auf die neue Version geschehen, während das Problem behoben wird. Größere Änderungen, wie z. B. Änderungen am Design der Anwendung, müssen möglicherweise immer noch einen manuellen Managementprozess für Änderungen durchlaufen.
Idealerweise sollte mindestens ein erfahrener Sicherheitsexperte am Change-Control-Prozess beteiligt sein – entweder als Change Control Board Member oder in beratender Funktion.
Ein dokumentierter Change-Management-Prozess ist in vielen Branchen und für den Erhalt regulatorischer Zertifizierungen notwendig, zum Beispiel für SOC 2, ISO 27001 oder PCI DSS.
Erinnern Sie sich an die wirklich einfache Three-Tier-Beispielanwendung aus Kapitel 1? Sie sehen sie in Abbildung 5-3.
Abbildung 5-3: Diagramm einer Beispielanwendung
Agieren Sie in einer orchestrierten, containerbasierten Microservices-Umgebung mit Kubernetes-Clustern für die Test- und Produktivlandschaft, sieht Ihre Beispielanwendung vielleicht ein bisschen anders aus. Aber Sie können weiterhin die drei Haupt-Tiers in der Mitte des Diagramms erkennen (siehe Abbildung 5-4).
Aus Gründen der Einfachheit sind die Worker-Knoten, auf denen die Container ausgeführt werden, in diesem Diagramm nicht abgebildet, und es ist nur ein Cluster dargestellt, obwohl es getrennte Test- und Produktiv-Cluster gibt. Schauen wir uns an, wie wir in dieser Umgebung einen Vulnerability-Management-Prozess designen könnten. Zuerst denken wir über die Rollen nach, die ganz oben zu sehen sind:
Abbildung 5-4: Diagramm einer Beispielanwendung aus Microservices
Schauen wir uns nun die Pipeline zum Deployen an (in der Abbildung links):
Als Drittes wollen wir einen Blick auf die Tools zum regelmäßigen Scannen auf der rechten Seite der Abbildung werfen. Sie sind erforderlich, weil sich die Welt weiterdreht und neue Schwachstellen gefunden werden, selbst wenn sich der Code nicht ändert. Immer dann, wenn ein Problem gefunden wird, wird automatisch ein Ticket in einem Tracking Repository eröffnet (hier als Teil des Quellcode-Repository gezeigt), und Probleme durchlaufen den Risikomanagementprozess, wenn sie nicht schnell genug gelöst werden:
Da passiert ganz schön viel! Aber keine Panik. Das hier soll als Lehrbeispiel dienen – viele kleinere Umgebungen werden gar nicht all die hier aufgeführten Tools benötigen. Zudem erfüllen viele Produkte mehrere Funktionen: Ein einzelnes Tool kann beispielsweise statisches Scannen, dynamisches Scannen und IAST/RASP abdecken. In einer perfekten Welt würden alle Schwachstellen an einem Ort gesammelt werden, sodass man sich dort mit ihnen befassen könnte, so wie Probleme in einem Code-Repository. In der realen Welt werden Sie aber mehrere Toolkonsolen aufrufen müssen, um alle Probleme zu finden. Wichtig ist, zu verstehen, was für unterschiedliche Arten von Tools es gibt, und solche zu wählen, die die größten Gefahren für Ihre Anwendung angehen.
Seien wir ehrlich: Einfach nur ein Tool zu kaufen und zu installieren, mag auf Berichten an das Management gut aussehen, aber Sie müssen tatsächlich etwas mit dem tun, was das Tool Ihnen erzählt. Konzentrieren Sie sich darauf, echte Probleme zu finden und eine gute Feedback-Schleife für Ihre Entwicklungs- und Administrationsteams zu schaffen, in der Sie nützliche Metriken einsetzen, bevor Sie ein weiteres Tool hinzunehmen.
Vulnerability Management, Patch Management, Configuration Management und Change Management sind jeweils eigene Disziplinen mit eigenen Tools und Prozessen. In diesem Kapitel habe ich sie zusammengefasst, um die jeweils wichtigsten Aspekte schneller behandeln zu können, aber zu allen sind jeweils ganze Bücher geschrieben worden.
Vulnerability Management ist in Cloud-Umgebungen in vielerlei Hinsicht ähnlich zu dem in On-Premises-Landschaften. Aber beim Cloud Computing dreht es sich oft mehr um einen verstärkten Businessfokus mit einem schnellen Deployen neuer Features. Das führt zu der Notwendigkeit von Vulnerability-Management-Prozessen, die mit der sich schnell ändernden Infrastruktur mithalten können.
Zudem wird in der Cloud oft auf die Idee immutabler Infrastruktur und von Continuous Delivery gesetzt, was das Risiko eines Ausfalls aufgrund von Änderungen deutlich senken kann. Damit verschiebt sich die Balance von operationalen und Sicherheitsrisiken. Weil das Anwenden von Sicherheitsfixes eine Änderung ist und Sie Änderungen sicherer durchführen können, ist es möglich, Sicherheitsfixes schneller auszurollen, ohne das Risiko einzugehen, dass das System nicht mehr nutzbar ist. Das bedeutet, dass Sie in Cloud-Umgebungen im Allgemeinen andere Prozesse zum Vulnerability Management, Patch Management und Change Management umsetzen sollten. Zudem gibt es sowohl Tools, die die Besonderheiten der Cloud berücksichtigen, als auch solche, die spezifisch von den Providern angeboten werden und mit denen das Vulnerability Management einfacher wird als in On-Premises-Umgebungen.
Nach der Zugriffskontrolle ist das Vulnerability Management der wichtigste Prozess, der in Cloud-Umgebungen richtig gemacht werden muss. Durch Angriffe lässt sich auf sehr unterschiedlichen Ebenen Ihres Anwendungs-Stacks unautorisierter Zugriff auf Ihre Systeme erlangen. Sie müssen sich in Ruhe mit den verschiedenen Schichten befassen, sie verstehen und wissen, wofür Ihr Vulnerability Management zuständig ist und wo die vermutlich größten Risiken in Ihrer Umgebung liegen. Dann müssen Sie die unterschiedlichen verfügbaren Arten von Tools für das Vulnerability Management kennenlernen und herausfinden, welche davon die Bereiche angehen, die bei Ihnen das höchste Risiko besitzen.
Jeder Anbieter wird Sie davon überzeugen wollen, dass bei Ihnen durch seine Tools alles abgedeckt ist. Das ist aber nur selten der Fall – meist brauchen Sie zumindest ein paar unterschiedliche Tools, um das Vulnerability Management und das Configuration Management in Ihrer Cloud-Umgebung abzudecken. Konzentrieren Sie sich darauf, aus jedem Tool das Beste herauszuholen, bevor Sie ein weiteres ins Spiel bringen. Sie sollten bei jedem Tool dazu in der Lage sein, genau erklären zu können, was für Arten von Schwachstellen es finden kann. Sie sollten auch eine Pipeline skizzieren können, über die die Tools sinnvolle Eingaben erhalten, wie sie Schwachstellen finden und/oder beheben, wie die Sicherheitslücken zurück an die Teams kommuniziert werden, damit sie dort behoben werden können, und wie Sie die Schwachstellen nachverfolgen, die sich nicht direkt beheben lassen.
Im nächsten Kapitel werde ich schließlich über das sprechen, woran die meisten Menschen zuerst denken, wenn es um Cybersecurity geht: Firewalls und Netzwerkschutzmaßnahmen.
