Tierney - stock.adobe.com
Tipps für automatische Security-Tests in DevOps-Umgebungen
Es gibt fünf DevOps-Bereiche, die besonders von automatischen Security-Tests profitieren. Sie reichen von Analysen des Codes, über Web-UI-Scans bis zu Vulnerability-Checkern.
Der Schlüssel zu einem erfolgreichen Einstieg in DevOps und DevSecOps ist Automatisierung. Sie sorgt vor allem dafür, dass die durchgeführten Build- und Release-Prozesse wiederholbar sind. Das ist immer dann besonders wichtig, wenn die Zahl der Veröffentlichungen so hoch ist, dass keine manuellen Maßnahmen mehr zwischen den einzelnen Release-Phasen oder zu vorgegebenen Zeiten durchgeführt werden können.
Automatisierung stellt sicher, dass alle notwendigen Schritte auch wirklich jedes Mal erledigt werden, wenn neuer Code bereitsteht. Selbst Schlüsselaufgaben wie Regressions-Tests sind dann nicht mehr abhängig vom menschlichen Gedächtnis.
Automatisierung kann aber auch die IT-Sicherheit stärken, da sie garantiert, dass die festgelegten Richtlinien durchgesetzt werden. Außerdem wird dadurch verhindert, dass Entwickler auf produktiv genutzte Systeme zugreifen. Maßnahmen zur Automatisierung sorgen damit auch dafür, dass die elementare Unterteilung der Aufgaben im Unternehmen auch tatsächlich eingehalten wird.
Für viele Sicherheitsexperten, insbesondere wenn sie nicht aus den Bereichen Anwendungssicherheit oder Softwareentwicklung kommen, mag es jedoch schwierig sein, geeignete Möglichkeiten für automatisierte Security-Tests in der Entwicklungs-Pipeline zu erkennen.
Im Folgenden finden Sie daher fünf Tipps, mit denen Ihre Teams automatisierte Security-Checks in die Entwicklungs-Pipeline einführen können.
1. Code-Qualität mit SAST verbessern
Die meisten Menschen denken vermutlich zuerst an die Qualität des Codes, wenn es um das Thema Software-Sicherheit geht. Dafür gibt es Techniken wie Static Application Security Testing (SAST). Wer das Unix-Tool Lint kennt, das zum Finden von Fehlern in mit der Programmiersprache C geschriebenem Code genutzt wird, der ist bereits mit dem Konzept des statischen Scannens von Code vertraut.
Statische Analyse-Werkzeuge überprüfen den Quellcode oder seltener auch Objektcode auf mögliche Sicherheitsprobleme. Im Rahmen der DevOps-Tool-Chain kann dieser Prozess an mehreren Stellen automatisiert werden:
- So kann die Prüfung etwa stattfinden, wann immer ein Entwickler neuen Code übermittelt, zum Beispiel durch Scannen dieser Daten und der mitgelieferten Inhalte auf hochgradig gefährliche Schwachstellen.
- Die Prüfung kann aber auch erst vor dem Build-Prozess durchgeführt werden.
- Die dritte Möglichkeit ist der Einsatz eines Tools zum Prüfen des Objektcodes im Post-Build-Prozess.
Eine ergänzende Strategie ist zudem das Erstellen eines Schwellenwerts mit einer akzeptierbaren Fehlerquote. Erst wenn dieser Wert überschritten wird, muss sich dann ein Mitarbeiter um das identifizierte Problem kümmern.
Legen Sie einen solchen Wert auf Basis der Zahl der Probleme fest, ihrer Schwere oder auch beidem. Oberhalb des Schwellenwerts sollte ein Entwickler den Code immer erst genau prüfen, bevor er weiter verwendet wird. Eine Alternative dazu ist, das identifizierte Problem zu markieren, so dass es erst später in der Pipeline überprüft wird. Welcher Weg besser passt, ist abhängig von der Häufigkeit der Releases und der Frage, wie bei den Tests mit Falsch Positiven umgegangen werden soll. Letzte Variante hat aber den Vorteil, dass die Abläufe dabei nicht unterbrochen werden.
2. Webanwendungen mit DAST überprüfen
Automatisierung kann auch zu den dynamischen Tests einer Anwendung hinzugefügt werden, nachdem sie zwar erstellt, aber noch nicht für die produktive Nutzung freigegeben wurde.
Tools zum Dynamic Application Security Testing (DAST) prüfen eine Anwendung sozusagen von außen nach innen. Dazu gehört, sich mit der Oberfläche einer Applikation zu beschäftigen, mit ihr zu interagieren und zu beobachten, was sich dadurch für Änderungen ergeben.
Innerhalb der DevOps-Tool-Chain ist die Phase nach dem Build-Vorgang ein besonders guter Platz für diese Analysen, wenn also eh gerade automatisch die Qualität überprüft wird. Wenn die Einführung schnell gehen soll, dann schauen Sie sich den Open-Source-Scanner Zed Attack Proxy genauer an und setzen ihn im Daemon-Modus auf der Kommandozeile ein. Dann kann er parallel zu Ihren anderen Analysen laufen. Mit Zed Attack Proxy lassen sich durch den Einsatz von Parameter Fuzzing auch grafische Elemente in einer Weboberfläche oder REST-APIs (Representational State Transfer - Application Programming Interfaces) prüfen.
3. Scannen von Containern und die Analyse von Abhängigkeiten
In den meisten IT-Umgebungen hängt die Entwicklung neuer Anwendungen heutzutage stark von Container-Lösungen wie Docker oder Rkt ab. Container haben viele Vorteile, weil sie zusammen mit einer Anwendung oder Komponente auch die dafür benötigten Libraries, Middleware und Ressourcen mitbringen und zudem viele weitere Abhängigkeiten erfüllen.
Dieses Feature ist der wichtigste Grund für die Nutzung von Containern. Auf der anderen Seite ist es aber auch aber eines der größten Nachteile, da es immer wieder vorkommt, dass eine der zugrundeliegenden Komponenten eine bekannte und noch nicht geschlossene Schwachstelle hat. Da in einem Container alle Abhängigkeiten bereits erfüllt sind, sorgen sie aus operativer Sicht für deutlich weniger Arbeit. Es besteht dabei allerdings die Gefahr, dass bekannte Schwachstellen wieder vergessen werden oder sogar niemandem bekannt ist, dass sie überhaupt existieren.
Automatische Tools wie Clair oder die Anchore Engine Tools scannen daher Container auf Sicherheitslücken und prüfen ihre internen Abhängigkeiten. Finden sie ein Problem, dann listen sie alle betroffenen Komponenten auf. Damit sich diese Prozesse leichter automatisieren lassen, können die Tools zu jedem Zeitpunkt eingesetzt werden, nachdem ein Container erstellt wurde. Sollten dabei größere Probleme bei den Abhängigkeiten entdeckt werden, wird entweder eine manuelle Überprüfung angestoßen, um die Schwachstellen zu schließen, das Problem zur späteren Bearbeitung vorgemerkt oder eine andere angemessene Reaktion ausgelöst.
4. Zusammensetzung der Software
Es gibt viele gute Gründe für Unternehmen, eine Softwarestückliste zu erstellen, die alle Bestandteile einer Anwendung auflistet. Davon profitieren das Unternehmen selbst, aber auch seine Kunden. Das Schwierige am Erstellen einer solchen Liste ist allerdings, die Aufzeichnungen über die zugrundeliegenden Abhängigkeiten auf Dauer auf einem aktuellen und fehlerfreien Stand zu halten. Die Einführung eines SCA-Tools (Software Composition Analysis) in die Tool-Chain kann eine große Hilfe sein, die Liste aktuell zu halten.
Mit einem SCA-Tool lässt sich zudem herausfinden, wo die Einführung einer Automatisierung am meisten Sinn macht. So kann etwa Software, die auf Basis von Objektdateien oder ausführbaren Images arbeitet, erst im Post-Build-Prozess eingesetzt werden, während eine Lösung, die direkt über die Quellen funktioniert, parallel mit den Commits genutzt werden kann.
5. Automatische Scans nach Schwachstellen
Die oben aufgeführten Werkzeuge decken zwar die meisten Softwarekomponenten ab, aber trotzdem noch nicht alle. Weboberflächen oder REST-APIs können durch DAST-Tools getestet werden, während sich Anwendungen in Containern durch dafür geeignete Scans prüfen lassen. Aber was ist mit Software, die dem nicht entspricht?
Für sie kann es hilfreich sein, auf separate Lösungen zum Scannen nach Schwachstellen zu setzen. Gerade Abteilungen, die virtuelle Maschinen (VMs) in der Cloud oder speziell angepasste Betriebssysteme nutzen, profitieren von Lösungen, die gezielt nach Schwachstellen suchen. Sie finden und markieren potenzielle Sicherheitslücken. Automatisierte Schwachstellenscans passen auch gut zu einem modernen Konfigurationsmanagement. Immer dann, wenn sich die Konfiguration einer genutzten Ressource ändert, wird dann automatisch ein Test durch einen Schwachstellenscanner ausgelöst. Das gilt auch für die immer wichtiger werdenden Skripte aus dem Bereich Infrastructure-as-Code.
