Vulnerability Management: Von diesen 5 Schritten profitieren Projekte

Vulnerability Management bei MaibornWolff

Verdeckte Gefahr: Bei der Erstellung von Software-Systemen können Sicherheitsschwachstellen unbewusst in das System eingebaut werden. Über diese ist es Angreifern möglich, Kontrolle über das System zu gewinnen oder Daten aus dem System abzuziehen. Erkennt man diese Schwachstellen möglichst früh im Entwicklungsprozess, profitieren Projekte klar davon:

• Werden mögliche Schwachstellen direkt im Entwicklungszyklus angezeigt, lernen die Entwickler:innen diese zukünftig zu vermeiden. Das macht das System sicherer und spart Geld, da weniger Fehler beseitigt werden müssen.
• Aufwändige Penetrationstests, die sich nicht häufig durchführen lassen, passen nicht zu agilen Vorgehensmodellen mit kurzen Auslieferungszyklen. Verlässt man sich allein auf Penetrationstests, werden vielleicht Schwachstellen in Produktion gebracht, die Angriffspunkte für mögliche Attacken sein können.

MaibornWolff setzt in seinen Entwicklungsprojekten für das Vulnerability Management auf eine Kombination aus Open-Source Vulnerability Scannern und dem Vulnerability Management System SecObserve. Dabei werden die Vulnerability Scanner in die CI/CD Pipelines eingebunden, während SecObserve die gefundenen Vulnerabilities transparent darstellt.

No 1. Vulnerabilities vermeiden ist der erste Schritt des Vulnerability Managements

An erster Stelle steht die Vermeidung von Vulnerabilities. Unsere Entwicklungsteams achten vom Beginn des Projekts darauf, möglichst wenige Vulnerabilities zu erzeugen. Das ist wichtig, da ansonsten die Aufwände für das Vulnerability Management sehr groß werden können und das Entwicklungsteam bei seinen eigentlichen Aufgaben behindert.

Dafür setzen wir direkt beim Start des Projektes verschiedene Maßnahmen um:

Security by Design

Sicherheit fängt früh im Entwicklungsprozess an. Die Anforderungen an Sicherheit müssen klar definiert sein. Um diese zu ermitteln, helfen Schutzbedarfs- und Bedrohungs¬analysen und daraus abgeleitete Risiken. Die Sicherheitsanforderungen werden in den User Stories und der Definition of Done verankert und sind damit Bestandteil der Architektur des Systems.

Automatisiertes Patchmanagement

Werden Libraries und Docker Basis-Images nicht regelmäßig aktuell gehalten, enthalten die eingesetzten Versionen schnell eine Menge an bekannten Schwachstellen. Wir setzen Tools wie den RenovateBot ein, damit die Versionen immer aktuell sind und um die Menge an Meldungen aus den entsprechenden Vulnerability Scannern zu minimieren.

Einsatz von Security Champions und geschulten Mitarbeitenden

Der Security Champion ist ein Teammitglied, das neben seiner oder ihrer Rolle als Entwickler:in dafür sorgt, Cybersecurity tief im Entwicklungsprozess zu integrieren (siehe auch Security Champions: Fürsprecher für Cybersecurity in den Entwicklungsteams).

Viele unserer Entwickler:innen haben außerdem unsere interne Schulung “Sicheres Programmieren” besucht und gelernt, viele Fallstricke in der Cybersecurity zu vermeiden und sicheren Code zu implementieren.

No 2. Kuratierte Liste von Open-Source Vulnerability Scannern

Auf dem Markt für Open-Source bzw. kommerzielle Software existiert eine große Zahl von Werkzeugen. Man kann sie manuell zur Prüfung von Schwachstellen aufrufen, sie lassen sich aber zum größten Teil auch sehr gut automatisieren. Diese Werkzeuge können in fünf Gruppen eingeordnet werden:

• Software Composition Analysis (SCA): Moderne Systeme werden nicht von Grund auf komplett neu geschrieben, stattdessen werden viele Basisfunktionen als Bibliotheken genutzt. Das gilt nicht nur für den Anwendungscode, sondern im Fall von Docker auch für Betriebssystemfunktionen und Programme. Es ist möglich, dass diese Bibliotheken bekannte Schwachstellen haben, die von Angreifern genutzt werden können. Bei der Software Composition Analysis (SCA) werden alle Bibliotheken auf bekannte Schwachstellen geprüft.
  
• Static Application Security Testing (SAST): Programmierer können unbewusst Schwachstellen im Code einbauen. Durch eine manuell gebautes SQL für eine Performanceoptimierung kann schnell eine SQL Injections entstehen. Durch nicht sorgfältig geprüfte Ein- und Ausgaben in Weboberflächen ist ein Cross Site Scripting möglich oder sensitive Daten werden durch falsche Konfiguration der Kryptographie nur schwach verschlüsselt. Mit regelbasierten Suchen lassen sich viele dieser Probleme erkennen. Es existieren Werkzeuge für alle gängigen Programmiersprachen und auch Infrastructure as Code.
  
• Secrets Detection: Geheimnisse wie Passwörter oder API-Keys sind schnell im Code Repository eingecheckt. Beispiele dafür sind Geheimnisse, die im Code hart verdrahtet wurden oder ein versehentlicher Commit einer Konfigurationsdatei. Hat das Code Repository keine sehr strikte Beschränkung, wer darin lesenden zugreifen kann, entstehen womöglich weitreichende Angriffsstellen. Durch diese können etwa Unbefugte direkt auf Datenbanken oder Schnittstellen zugreifen. Es gibt Werkzeuge, die z.B. Git-Repositories über die gesamte Versionshistorie nach solchen Geheimnissen durchsuchen.
  
• Dynamic Application Security Testing (DAST): Diese Klasse sind Black-Box-Sicherheitstests, bei denen die Tests durch Angriffe auf eine Anwendung (typischerweise Web-Anwendungen oder APIs) von außen durchgeführt werden. Die Tests können passiv sein, um nur Auffälligkeiten zu suchen, oder aktive Angriffe auf das System.
  
• Infrastructure Testing: Auch die laufende Infrastruktur wie z.B. die Konfiguration von Cloud-Infrastrukturen oder Kubernetes Clustern lässt sich überprüfen. Sowohl mit Prüfungen, die innerhalb der Infrastruktur laufen als auch Prüfungen von außen auf Schwachstellen.

Aus der großen Menge an verfügbaren Vulnerability Scannern haben wir eine kuratierte Liste von Tools zusammengestellt, die sich in unseren Projekten bewährt haben:

No 3. Vorgefertigte Actions und Templates für CI/CD Pipelines

Die Integration von Vulnerability Scannern in eine CI/CD-Pipeline kann mühsam sein. Jedes Tool ist anders zu installieren und wird mit unterschiedlichen Parametern aufgerufen. Um zu vermeiden, dass jedes unserer Entwicklungsteams diese Aufgabe von neuem lösen muss, haben wir ein Repository mit GitLab CI Templates und GitHub Actions erstellt. Diese machen den Prozess der Integration der Schwachstellen-Scanner sehr einfach, indem sie einheitliche Methoden zum Starten der Tools und einheitliche Parameter zur Verfügung stellen. Die Tools werden in den Repositories regelmäßig aktualisiert, so dass immer die neuesten Funktionen und Bugfixes verfügbar sind.

No 4. Automatisierter Import in unser Vulnerability Management System SecObserve

Die GitHub Actions und GitLab CI Templates sind standardmäßig so konfiguriert, dass sie die Ergebnisse der Vulnerability Scans automatisch in unser Vulnerability Management System SecObserve importieren. Damit muss das Entwicklungsteams nicht Reports in JSON oder anderen Formaten interpretieren, sondern verfügt über eine moderne Benutzeroberfläche.

No 5. Transparenz, Bewertung und Behebung im Vulnerability Management System

In unserem Vulnerability Management System SecObserve (hier geht es zu dem Tool in GitHub) sehen und bewerten die Entwicklungsteams die möglichen Vulnerabilities für ihre Projekte.

Ein Tool mit einer guten User Experience ist wichtig. So kann das Entwicklungsteam die möglichen Vulnerabilities effizient bewerten und muss wenig Aufwand in das Vulnerability Management investieren.

Mit SecObserve bekommt das Entwicklungsteam eine Übersicht der Ergebnisse aller Vulnerability Scans für ihr Projekt. Sie können einfach gefiltert und sortiert werden. In der Detaildarstellung werden die möglichen Vulnerabilities einheitlich mit vielen Informationen dargestellt – egal von welchem Vulnerability Scanner sie erzeugt wurden.

Warum sprechen wir von möglichen Vulnerabilities? Die Vulnerability Scanner erzeugen typischerweise eine große Menge an Ergebnissen, die nicht alle wirklich Vulnerabilities sein müssen. Das Entwicklungsteam führt drei Schritte durch, um mit dieser Menge an Ergebnisse umzugehen:

Ungewünschte Ergebnisse eliminieren

Ungewünschte Ergebnisse können sein:

• False positives sind Ergebnisse, die vom Vulnerability Scanner fälschlich gemeldet wurden. Eine gewisse Menge davon ist leider unvermeidbar, da das Scannen komplexe Interpretationen des Sourcecode erfordert, die nicht immer richtig erkannt werden.
  
• Not affected sind Ergebnisse, bei denen die Interpretation des Scanners zwar richtig ist, die aber nicht in Produktion nicht ausgenutzt werden können. Zum Beispiel: Testcode oder eine Vulnerability in einer Library in einer Funktion, die nicht aufgerufen wird.
  
• Not security sind Ergebnisse, die nicht sicherheitsrelevant sind.

Diese Ergebnisse können eliminiert werden, indem das Entwicklungsteam entweder die Konfiguration des Scanners ändert (Code ausschließen oder Regelsätze anpassen) oder in SecObserve mit Hilfe von Regeln oder manuellen Assessments den Status der Ergebnisse anpasst.

Entscheidungen von Regeln oder manuellen Assessments bleiben stabil, das heißt, wenn bei weiteren Läufen der Pipeline das gleiche Ergebnis neu importiert wird, wird die getroffenen Entscheidung nicht geändert.

Risiken akzeptieren

Im zweiten Schritt wägt das Entwicklungsteam den Risikograd der verbleibenden Ergebnisse ab. Dabei hilft die Schutzbedarfs- und Bedrohungsanalyse, um zu entscheiden, ob das Risiko einer Vulnerability im aktuellen Kontext akzeptiert werden kann. Auch diese Entscheidung wird durch eine Regel oder ein manuelles Assessment in SecObserve dokumentiert.

Vulnerabilities beheben

Jetzt hat das Entwicklungsteam die Liste der verbleibenden Vulnerabilities, die nun behoben werden müssen. Wie das geschieht, hängt von der Art der Vulnerability ab.

• Bei Vulnerabilities in verwendeten Libraries oder Docker Images kann das Team entweder die anfällige Funktion der Komponente im eigenen Code einkapseln. So kann die Schwachstelle nicht mehr von Angreifern genutzt werden. Oder: Das Team muss prüfen ob auf eine andere Library ohne Vulnerabilities umgeschwenkt werden kann.
  
• Bei Vulnerabilities im eigenen Code wird es immer Sinn machen, den Source Code entsprechend zu ändern, um die Vulnerability zu entfernen. Die Ergebnisse der Scans geben dabei häufig Hilfestellung, indem sie Beispiele für eine korrekte Implementierung oder Referenzen mit Hilfestellungen angeben.
  
• Bei Geheimnissen (Secrets) reicht nicht aus, das Geheimnis aus dem Code oder der Konfigurationsdatei zu entfernen und eine neue Version in das Repository einzuchecken. Da die Information weiterhin in den vorherigen Versionen sichtbar ist, müssen die Passwörter oder API-Keys selbst in den entsprechenden Systemen geändert werden.

Beim nächsten Scan werden die nun behobenen Vulnerabilities nicht mehr vom Vulnerability Scanner gemeldet und in SecObserve automatisch auf erledigt gesetzt.

Zusammenfassung: Wie erfolgreiches Vulnerability Management geht

Mit diesen fünf Schritten stellen unsere Entwicklungsteams effizient sicher, dass ihre Projekte keine bekannten Vulnerabilities enthalten:

• Möglichst wenige Vulnerabilities erzeugen
• Mit Open-Source Vulnerability Scannern arbeiten
• Unser Repository mit GitLab CI Templates und GitHub Actions nutzen
• Unser Vulnerability Management System SecObserve nutzen
• Vulnerabilities effizient bewerten und beheben

Indem das Vorgehen beim Start der Projekte initiiert wird, ist die Anzahl der zu behandelten Vulnerabilities klein und die Aufwände für das Vulnerability Management bleiben immer auf einem niedrigen Niveau.

---

Über den Autor

LinkedIn: https://www.linkedin.com/in/stefan-fleckenstein-6a456a30/