Zu viele triviale Defekte – (noch) kein Grund zur Panik Überdruss beim Schwachstellen-Management vermeiden

Anbieter zum Thema

OutSystems

Eskenzi PR Limited

SYNOPSYS GmbH

Werden Security-Tools unangemessen oder falsch eingesetzt, führt das potenziell dazu, dass Entwickler mit Software-Defekten überflutet werden. Zu wissen, wann und wie man diese Tools am besten nutzt, macht DevSecOps effektiver.

Sicherheitsexperten weisen schon lange darauf hin: es gibt nicht das magische Software-Testing-Tool oder das eine Verfahren, mit denen sich jeder Fehler und jede Schwachstelle aufdecken lassen. Dazu braucht man unterschiedliche Tools, die zu unterschiedlichen Zeiten im Softwareentwicklungszyklus (Software Development Life Cycle, SDLC) zum Einsatz kommen.

Nutzt man solche Tools aber nicht korrekt und zum falschen Zeitpunkt, identifizieren sie eine überwältigende Zahl potenzieller Schwachstellen. Etliche davon sind für ein konkretes Projekt unter Umständen vergleichsweise unbedeutend oder gar irrelevant. Für Entwicklungsteams ist diese Flut derart frustrierend, dass sie Warnungen oftmals ignorieren oder Tools sogar deaktivieren. Das beeinträchtigt die Sicherheit an just der Stelle, an der sie eigentlich verbessert werden soll.

Genau darin liegt eine der größten Herausforderungen, wenn es um eingebettete DevOps-Sicherheit und eine effektive DevSecOps-Strategie geht. In jeder Phase der Pipeline oder sogar im gesamten SDLC gibt es eine Reihe von Sicherheitskontrollen. Und bei jeder einzelnen wird man vermutlich auf Schwachstellen stoßen. Das führt nicht selten zu einer Überlastung, was die Meldung solcher Defekte anbelangt.

Inzwischen ist die Liste von DevSecOps-Testtools und weiteren Sicherheitsaufgaben Standard. Zu Beginn sollten Sicherheitsteams zusammen mit Produktteams eine Bedrohungs- und Risikoanalyse durchführen. Beide sind abhängig von der Art der Anforderungen, die an eine Anwendung gestellt und der Art von Eingaben, die verarbeitet werden sollen. Eine Webseite, die Benutzereingaben, einschließlich persönlicher und finanzieller Daten verwendet, hat strengere Sicherheitsanforderungen als eine, die lediglich Informationen wie beispielweise zu Unternehmensstandorten bereitstellt.

Während des Codierungs- und Build-Prozesses sind automatisierte Testmittel wie statische, dynamische und interaktive Analysen in der Lage, Fehler und andere Defekte aufzudecken, die potenziell ausgenutzt werden. Mittels Fuzz-Testing überprüft man wie eine Software auf zufällige, fehlerhafte Eingaben reagiert. Mithilfe der Software Composition Analysis (SCA) findet man wiederum Open-Source-Komponenten, die Sicherheitsmängel aufweisen oder bei denen potenzielle Lizenzkonflikte auftreten.

Am Ende des Prozesses dienen Penetrationstests dazu, eine Anwendung so anzugreifen wie es ein Hacker tun würde. Dadurch werden die verbleibenden kritischen Schwachstellen identifiziert bevor die Anwendung in Serie geht.

DevSecOps-Security Tools konfigurieren

Diese Tools und Methoden sind wichtig, will man die Sicherheit einer Anwendung bereits während der Entwicklung verbessern. Die Tools sollten aber so konfiguriert sein, dass sie nur Fehler markieren, die für ein bestimmtes Projekt relevant und ausschlaggebend sind. Sonst führen sie am Ende zu Problemen und Reibungsverlusten, und die verlangsamen die Entwicklung.

Eben dies kann sich allerdings kein DevOps-Entwicklungsteam leisten. Ein gutes Schwachstellen-Management verspricht Abhilfe zu schaffen. Die widersprüchlichen Prioritäten von Geschwindigkeit auf der einen und Sicherheit auf der anderen Seite stellen das Schwachstellen-Management allerdings vor eine Reihe von Herausforderungen.

Es ist zwar möglich, ein Tool so zu konfigurieren, dass es nur als kritisch eingestufte Defekte aufdeckt. Jedes Projekt ist allerdings unterschiedlichen Risiken ausgesetzt. Folglich bewertet man unterschiedliche Dinge als kritisch. Zudem erfordert eine kritische Schwachstelle, die bei einem Penetrationstest gefunden wird, eine andere Art von Handlungsbedarf als eine kritische Schwachstelle in der Code-Analyse.

Man braucht qualifizierte Fachkräfte und viel Zeit, um jedes laufende Projekt so zu analysieren und zu konfigurieren, dass es tatsächlich nur noch kritische Schwachstellen aufweist, und man auch den Projektkontext nicht außer Acht lässt.

Was DevSecOps-Security-Tools tun

Kein Tool allein deckt sämtliche Arten von Schwachstellen auf. Statische Analysen (Static Analysis Security Testing, SAST), dynamische Analysen (Dynamic Analysis Security Testing, DAST) und SCA (Software Composition Analysis) identifizieren unterschiedlich gelagerte Probleme. Und es sind nicht nur SAST, DAST und SCA Tools – es gibt weitere mehr, die in den verschiedenen Phasen des SDLC eingesetzt werden.

Eine weitere Herausforderung besteht darin, dass jedes einzelne Tool und jede Aktivität in der Pipeline andere Fähigkeiten, Artefakte und Zeitaufwand verlangen. Eine Bedrohungsanalyse beispielsweise erfordert manuellen Aufwand und qualifizierte Fachkräfte. Dasselbe gilt für die Risikoanalyse. Bei der statischen Analyse hingegen konfiguriert man ein Tool, das den Testprozess automatisiert. Aber selbst dann findet die statische Analyse nicht alle Probleme.

Eine 100-prozentige Abdeckung aller Schwachstellen im Source Code, in den Open Source-Komponenten und innerhalb der gesamten Infrastruktur würde deutlich zu viele Ressourcen verschlingen und zu viele unterschiedliche Erkennungsmethoden erfordern. Für Entwicklungs- und Sicherheitsteams, die in einer DevSecOps-Umgebung zusammenarbeiten, stellt sich eine offensichtliche Frage: Wie können wir das scheinbar Unmögliche schaffen – nämlich einen „digitalen Sack Flöhe“ zu hüten?

Das Risikoprofil einer Anwendung verstehen

Zu Beginn sollte man sich mit dem „Risikoprofil“ einer Anwendung vertraut machen. Eine Anwendung, die Benutzereingaben akzeptiert und verarbeitet, macht strengere Sicherheitsvorkehrungen erforderlich als eine, die weniger sensible Informationen zur Verfügung stellt. Danach ist es wichtig zu verstehen, welche Arten von Schwachstellen die verschiedenen Tools überhaupt finden können.

In der Praxis hat sich gezeigt, dass Entwicklungsteams oftmals nicht genau wissen wie einzelne Tools konzeptuell arbeiten. Die Folge ist nicht selten, dass alle gleichzeitig laufen. Sobald Entwickler aber verstehen, wie die Tools funktionieren, und dass eventuell nicht jedes von ihnen für ein bestimmtes Projekt notwendig ist, lässt sich der „Defect Overload“ beseitigen.

Angenommen, Cross-Site-Scripting (XSS) und SQL-Injection gelten in einer bestimmten Anwendung als kritische Schwachstellen. Dann konfiguriert das Entwicklungsteam ein SAST-Tool so, dass es genau nach diesen Schwachstellen sucht und den Rest ignoriert. Wenn ein SAST-Tool dann eine oder beide Schwachstellen aufdeckt, benutzt man dieses Ergebnis anschließend als Payload für DAST oder ein interaktives Application Security Testing (IAST).

DAST und IAST werden so konfiguriert, dass sie nicht sämtliche Probleme finden, die sie finden können, sondern sie konzentrieren sich auf die beiden als kritisch eingestuften Schwachstellen und nichts sonst. DAST und vor allem IAST finden diese Schwachstellen mit einer ziemlich hohen Wahrscheinlichkeit. Anschließend lässt sich im Defect-Tracking-System des Unternehmens ein Ticket erstellen – z. B. in Jira. Der Prozess wäre ein völlig anderer, wenn die Bedrohungs- und Risikoanalyse einen Designfehler aufdecken, wie z.B. eine fehlerhaft erstellte Anwendung.

Wenn man statt Verschlüsselung Hashing für Passwörter verwendet, wird keine der beschriebenen Testtechniken in der Lage sein, etwas zu finden. Checkt der Entwickler dann seinen Code ein und gibt an, die API korrigiert zu haben, sollte die Pipeline intelligent genug sein, eine Codeüberprüfung vorzuschlagen. Ist das nicht der Fall, muss der Entwickler jemanden wissen lassen, dass hier eine kritische API geändert wurde, die überprüft werden muss.

Automatisierung einsetzen

Mit der richtigen Kombination aus DevSecOps-Tools und anderen Defect-Discovery-Methoden sowie der Automatisierung bestimmter Aktivitäten, lässt sich ein ROI erzielen und Teams entlasten. Aber es gibt auch Beispiele wie man es nicht machen sollte: ein Entwicklungsteam hat eine Back-End-Messaging-API entwickelt, ohne eine Datenbank zu verwenden und ohne ein Frontend. Dennoch testet das Team gegen die Top 10 des Open Web Application Security Project (OWASP).

Dies ist eine bekannte und hilfreiche Zusammenstellung von wichtigen Schwachstellen, aber für dieses spezielle Projekt irrelevant. Es ist wichtig, dass alles, was Entwickler in der Planungsphase tun, auch in alle anderen Testaktivitäten einfließt. Aber wenn es auf dem Backend keine Datenbank gibt, macht es vergleichsweise wenig Sinn, nach einer SQL-Injection zu suchen.

Defektüberlastung vermeiden

Entwickler sind überfordert, wenn unterschiedliche Erkennungsmethoden wie SAST, DAST und Penetrationstests alle die gleichen Fehler melden und für alle Tickets erstellen. Die Frustration kann so weit gehen, dass im Dashboard für die statische Analyse alle Tickets als False-Positive deklariert werden. Einfach, weil ein Team sich von der Vielzahl der Störungen komplett überfordert fühlt. Ein Beispiel aus der Praxis übrigens.

Diese „Problemumgehung“ wurde im konkreten Fall erst aufgedeckt, als gegen Ende des SDLC ein Pen-Testing-Team einige kritische XSS-Schwachstellen auflistete. Schwachstellen, die eine statische Analyse normalerweise aufdeckt. Das für die Softwaresicherheit zuständige Team fragte nach, warum keine statische Analyse durchgeführt wurde; schließlich sei das Tool besonders leistungsfähig darin, XSS-Schwachstellen zu finden.

Bei genauerem Hinsehen stellte sich heraus, dass das Tool die besagten Schwachstellen sehr wohl gefunden hatte, diese aber als False Positives markiert wurden. Das Problem konnte man anschließend mithilfe einer zusätzlichen Methode beheben: In Zukunft würde jede kritische Schwachstalle als solche markiert werden. Und zwar auch dann, wenn sie als False-Positive-Meldung gekennzeichnet wäre.

Diese Situation verdeutlicht, welche Auswirkungen ein Defect Overload haben kann. Wenn Security-Tools nicht ordnungsgemäß konfiguriert werden, überlasten sie die Entwicklungsteams bis zu dem Punkt, an dem sie Warnungen ignorieren oder sogar blockieren. Das verbessert die Sicherheit nicht, es untergräbt sie.

Im Endeffekt geht es darum, Unternehmen dabei zu unterstützen, kritische Defekte zunächst zuverlässig und schnell zu identifizieren und anschließend zu beheben. Auf diese Weise gewährleistet man Sicherheit, ohne die Entwicklung auszubremsen.

* Stanislav Sivak arbeitet bei Synopsys.

(ID:47080879)