IT Security Summit: DevOps ist seit Jahren ein feststehender Begriff, wenn es um moderne Prozesse in der Softwareentwicklung geht. Doch immer häufiger wird dabei auch der Sicherheitsaspekt wichtig. Zusammengefasst wird dies oft gerne unter dem Schlagwort „DevSecOps“. Dev steht dabei für Developer, also den Entwickler, und Ops für die ausführende, die Operations-Seite. Was genau ist mit „Sec“ in deinen Augen gemeint?
Christian Schneider: DevOps an sich bedeutet zu großen Teilen ja auch „Infrastructure as Code“ und die Automatisierung von Build-, Release-, und Testprozessen. Nur hierdurch konnte überhaupt die passende Geschwindigkeit und mögliche Release-Frequenz erreicht werden. Die „klassische“ Security jedoch war damals immer noch stark manuell getrieben: Penetrationstests und Codeanalysen auf Lücken fanden zeitaufwendig statt und waren oftmals Bottleneck, wenn es um schnelle Rolloutfähigkeit ging.
DevSecOps versucht genau dort anzusetzen: Die Integration von Security-Tests in die DevOps-Prozesse zum Bauen und Releasen von Software. Letztendlich kann man sagen, dass DevSecOps die logische Fortführung der Automatisierung im DevOps-Sinne auf Security-Checks bezogen darstellt.
IT Security Summit: Ein Entwicklungsprozess besteht aus vielen Teilen, Schritten und Tools. Die Sicherheit sollte dabei wohl holistisch betrachtet und in jedem einzelnen dieser Teilaspekte eine Rolle spielen. Wo fällt es besonders leicht, wo besonders schwierig, die Sicherheit im Auge zu behalten?
Christian Schneider: Mittlerweile bestehen gute Tools zur Integration von Security-Checks in Build-Pipelines — dies stellt somit eher eine geringere Einführungshürde für das holistische Verankern von Security in einem Projekt dar.
Spannender, weil oft nicht so einfach und auch manchmal sträflich vernachlässigt, sind da die nicht minder wichtigen „weichen“ Aspekte: Hier geht es z.B. um organisatorische Veränderungen in Firmen und Teams. Letztendlich war Agilität und DevOps mit ihren schnellen Prozessen auch nur dann ein Erfolg, wenn die Teams sich von ihrer Developer-Kultur her darauf eingelassen und eingestellt haben. Andernfalls funktionierten diese Methoden nicht. Bei einer ganzheitlichen Integration von Security in ein Team stellt sich genau die gleiche Hürde: Das Team und die Firma und letztendlich auch der Kunde bzw. Product Owner muss die Anwendung der Werkzeuge und Verfahren auch wirklich wollen (was oftmals auch Budget und Zeit kostet), ansonsten wird Security von außen nur „angeflanscht“ was dann aber nicht nachhaltig in einem Projekt bestehen bleibt.
Weiterhin geht es in den nicht so einfach ganzheitlich zu integrierenden Security-Aspekten auch um Themen wie Wissensaufbau: Nur durch auf die Zielgruppen individuell zugeschnittene und kontinuierliche Trainings kann sichergestellt werden, dass die getroffenen Maßnahmen auch ihre Wirkung entfalten können. Zielgruppen hierfür sind z.B. Business Analysten / POs bzgl. Security Requirements, Architekten bzgl. Bedrohungsmodellierung und Härtung auf Ebene von Komponenten und Schnittstellen, Entwickler für weniger Lücken und nachhaltigere Fixes sowie DevOps- und Test-Engineers für den optimalen Einsatz von Security-Tools.
Abschließend sollte auch an die konkrete Vorbereitung auf einen Security-Notfall gedacht werden: Ein Unternehmen sollte die Verfahren zum schnellen Erkennen und Isolieren von Angreifern in den eigenen Systemen geübt haben, quasi die „Cyber-Brandschutzübung“, um im Fall eines erfolgreichen digitalen Einbruchs diesen schnell erkennen zu können und vorbereitet zu sein.
IT Security Summit: Wenn man das ganze Konstrukt eines Anwendungs-Lebenszyklus von außen betrachtet, wo ist dieses besonders anfällig für Sicherheitslücken?
Christian Schneider: Die Anfälligkeit für ein Ausnutzen von Sicherheitslücken ist selbstverständlich am laufenden Produkt am größten, besonders wenn es schlecht gewartet ist, also z.B. wichtige Patches oder Updates in den verwendeten Librarys nicht zeitnah eingespielt wurden.
Wenn man im Anwendungs-Lebenszyklus die Phase der Entwicklung betrachtet, besteht dort das größte Risiko für das ungewollte Einbringen von Sicherheitslücken. Durch Penetrationstests wird vor einem Go-Live dann oftmals ein letzter Check gemacht, in der Hoffnung, mögliche Sicherheitslücken zu finden. Dieser Pentest ist insofern auch wichtig, da es immer Schwachstellen gibt, welche ein Scan durch ein Werkzeug nicht finden kann (z.B. Schwachstellen in der Businesslogik oder auch im Berechtigungssystem).
Trotzdem liegt gerade in der Entwicklungsphase das größte Potenzial, um mittels geschicktem Werkzeugeinsatz zumindest die automatisiert identifizierbaren Problemstellen bereits so früh wie möglich zu erkennen.
IT Security Summit: Gibt es in deinen Augen Best Practices, wenn es um die Sicherheit im DevOps-Kontext geht? Was sollten Entwickler, Operators und Sicherheitsexperten in jedem Fall beachten, auch wenn „DevSecOps“ noch nicht zum Paradigma der Wahl geworden ist?
Christian Schneider: Als Best Practice kann man anführen, dass zumindest ein Code-Scan (Static Application Security Testing) auf Sicherheitslücken mit zum Repertoire gehören sollte. Hierzu gib es auch passende Open-Source-Lösungen, welche sich einfach in die IDEs, Build-Pipelines und Quality-Scanner integrieren lassen.
Um auf den Punkt zurückzukommen, was „auf jeden Fall“ beachtet werden sollte: Hier würde ich ein Prüfen der eingesetztem Librarys auf bekannte Schwachstellen, z.B. mittels OWASP Dependency Check, empfehlen.
Wenn man das Ganze dann in Build-Pipelines integriert, wäre eine Definition von Quality-Gates wichtig, um Builds z.B. beim Einchecken und Bauen von Code mit kritischen Schwachstellen brechen zu lassen.
Die Kür wäre dann der Einsatz von dynamischen Checks am fertigen Produkt (auf einem Integrationssystem). Hierzu ist dann oftmals die Mitbenutzung von UI- oder API-Testautomation notwendig sowie eine tiefere Konfiguration der Werkzeuge.
IT Security Summit: Welche Sicherheitstools existieren, deren Einsatz sich empfiehlt?
Christian Schneider: Hier gibt es eine ganze Bandbreite von Werkzeugen (Open Source und kommerziell). Grundsätzlich kann man diese in die drei folgenden Kategorien unterteilen:
- DAST (Dynamic Application Security Testing): DAST-Werkzeuge betrachten die zu prüfende Webanwendung oder Web-API aus Sicht eines Angreifers von außen, also als „Black Box“. Hierzu werden oftmals die vorhandenen „Eingangskanäle“, also sämtliche Parameter, mit unterschiedlichen Angriffsmustern befüllt.
- SAST (Static Application Security Testing): SAST-Werkzeuge scannen den Quellcode bzw. Bytecode der Anwendung auf Sicherheitslücken. Diese Werkzeuge sind bereits in einer frühen Entwicklungsphase mit noch nicht deploy-fähigem Code verwendbar und eigenen sich daher besonders als erster Schritt in Richtung DevSecOps. Dependency-analysierende Werkzeuge würde ich grob auch der Kategorie der SAST-Werkzeuge zuordnen.
- IAST (Interactive Application Security Testing): Diese im Vergleich neuere Kategorie kann als „dynamische Codeanalyse“ betrachtet werden: Hierbei wird mittels Bytecode-Instrumentierung einer Testumgebung die Anwendung zur Laufzeit einer „White Box“-Analyse unterzogen, während der tatsächlich Datenfluss in der Anwendung von den Werkzeugen beobachtet werden kann. Dies ermöglicht eine recht nahtlose Integration in bestehende, bereits automatisierte Tests.
IT Security Summit: Vom 11. bis 13. November findet das IT Security Camp statt, deren Host du bist. Worum wird es da genau gehen, was erwartet die Teilnehmer?
Christian Schneider: Das werden drei spannende, mit Hands-on-Übungen voll gepackte Tage werden :).
Am ersten Tag werden wir das grundlegende Handwerkszeug üben, um die klassischen Sicherheitslücken in den Trainingsanwendungen aufzuspüren. Am zweiten Tag gehen wir dann stark in die offensive Richtung, werden also fortgeschrittene Wege zum Aufspüren (und auch Ausnutzen) von Sicherheitslücken erlernen, somit eine Art Pentestertraining. Der dritte Tag steht verstärkt im Zeichen von DevSecOps und widmet sich der Automation mit Werkzeugen außerhalb und innerhalb von Build-Pipelines.
IT Security Summit: Welche Erkenntnisse sollten die Teilnehmer am Ende des Camps in jedem Fall mit nach Hause nehmen?
Christian Schneider: Nach dem Workshop verfügen die Teilnehmer über praktische Erfahrungen zur Angriffsdurchführung auf Webanwendungen und Backends, mit dem Ziel, Sicherheitslücken aufspüren zu können. Dies kann zum einen im Rahmen der eigenen Softwareentwicklung eingesetzt werden, um die Sicherheit zu testen, oder dient als gute Grundlage für eine Vertiefung im Bereich Penetrationtesting.
Weiterhin sind durch die DevSecOps-Anteile (besonders am dritten Tag) die praktischen Möglichkeiten zur Automatisierung im Rahmen von Build-Pipelines erlernt, was dem einen oder anderen Projekt danach hoffentlich zu Gute kommen wird.
Autor: Dominik Mohilo
