Interview mit Christian Schneider

DevSecOps: „Die logische Fortführung der Automatisierung auf Security-Checks“

Dominik Mohilo

Sicherheit geht vor! Das gilt auch und vor allem im DevOps-Umfeld. DevSecOps ist das nicht mehr ganz so neue Schlagwort. Wir sprachen mit Christian Schneider, freiberuflicher Whitehat-Hacker, Trainer und Securitycoach, über die Definition von DevSecOps, beliebte Sicherheitslücken und Best Practices, um den Sicherheitsaspekt möglichst holistisch im Entwicklungsprozess abzubilden.

JAXenter: 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?

DevSecOps ist die logische Fortführung der Automatisierung auf Security-Checks.

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.

JAXenter: 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.

DevSecOps Best Practices

JAXenter: Wenn man das ganze Konstrukt eines Anwendungs-Lebenszyklus von außen betrachtet, wo ist dieses besonders anfällig für Sicherheitslücken?

In der  Phase der Entwicklung besteht das größte Risiko für das ungewollte Einbringen von 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.

JAXenter: 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.

JAXenter: 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.

 

JAXenter: Vielen Dank für dieses Interview!

Verwandte Themen:

Geschrieben von
Dominik Mohilo
Dominik Mohilo
Dominik Mohilo studierte Germanistik und Soziologie an der Goethe-Universität in Frankfurt. Seit 2015 ist er Redakteur bei S&S-Media.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: