DevOps ist in Unternehmen immer stärker im Einsatz. Kürzere Entwicklungszyklen, schnellere Time-to-Market und noch vieles mehr sind die Vorteile dieses Vorgehens. Automatisierte Prozesse sind Voraussetzung dafür. In diesem Zusammenhang geht die Security gerne einmal in Vergessenheit. Die Folge sind Deployments ohne Überprüfung auf Sicherheitsaspekte. Klar, kann durch die kürzeren Entwicklungszyklen auch schneller reagiert werden. Der Schaden ist trotzdem hergestellt. Aus diesem Grund muss die IT-Sicherheit ebenfalls in die DevOps Strategie integriert werden. Dieses Prinzip wird "DevSecOps" genannt. In diesem Beitrag möchte ich DevSecOps vorstellen und dabei verschiedene Arten von Security Tests in Bezug auf die Pipeline erklären.
Was ist DevSecOps?
DevSecOps erweitert die Grundprinzipien von DevOps, indem es zusätzlich die Integration von Sicherheitstests in die vorhandene Toolchain forciert. Dabei kommen spezielle Werkzeuge für das kontinuierliche Testen von Sicherheitsaspekten auf jeder Stage der Deplyoment-Pipeline bis einschließlich der Produktivumgebung zum Einsatz.
Es beschränkt sich dabei nicht nur auf den Aspekt des Testing, sondern auf den gesamten DevOps-Prozess. DevSecOps ist also die Integration von Sicherheit als gemeinsame Verantwortung von Anfang an im Ablauf. Es beinhaltet sowohl ein "Shift Left" - möglichst früh im Softwarelebenszyklus - als auch ein "Shift Right" - auf jeder Stage inklusive Produktion. Ein wichtiger Schritt dazu ist, das Sicherheitsbewusstsein und die damit verbundenen Skills in das Team zu bringen und diese laufend zu verbessern. In diesem Beitrag konzentrieren wir uns auf den Aspekt der Sicherheitstests.
Arten von Sicherheitstests
Klassischerweise bekannt sind Penetrationstests, welche kaum automatisiert und erst nach ausführlicher Informationssammlung durchgeführt werden. Penetrationstests können dadurch auch nicht in der Deployment-Pipeline ausgeführt werden, sondern sind weiterhin ein wichtiger manueller Ausführungsbestandteil für gezielte Angriffssimulationen.
Bei DevSecOps können unterschiedliche Typen von Sicherheitstests zur Anwendung kommen:
- Static Application Security Testing (SAST)
SAST ist eine Art von "white box testing" und bezeichnet die Analyse von Source Code auf Sicherheitslücken. Die Entwickler können dadurch früher allfällige Risiken entdecken und beheben. Nebenbei wird der Code auch bezüglich Coderichtlinien und Standards analysiert, ohne ihn dabei auszuführen. - Dynamic Application Security Testing (DAST)
DAST ist eine Art von "black box testing" und bezeichnet die Analyse von laufenden Applikationen, meist Webapplikationen, auf Sicherheitslücken. Dies geschieht durch absichtliches Abfüllen von bösartigen Eingaben, um Sicherheitslücken wie beispielsweise SQL Injection, zu entdecken. Grundlage dazu sind meist die OWASP Top 10, welche die 10 kritischsten Sicherheitsrisiken für Webanwendungen auflistet. Das bekannteste Open-Source-Tool für DAST ist OWASP ZAP. - Interactive Application Security Testing (IAST)
IAST kombiniert die Vorteile von SAST und DAST. Bei modernen Applikationen werden vielfach Frameworks und Bibliotheken eingesetzt, welche statische Analysen nicht überprüfen können, aber möglicherweise auch Sicherheitslücken aufweisen. Der IAST Agent arbeitet innerhalb der Applikation und kann dabei alles analysieren: Code, Datenfluss, Konfiguration, Request und Responses, usw. Dabei kann der Agent irgendwo im Entwicklungsprozess oder auch in der Produktion eingesetzt werden. - Run-time Application Security Protection (RASP)
RASP ist weniger ein Testingtool, sondern viel mehr ein Sicherheitstool. Es ist an eine Anwendung oder deren Laufzeitumgebung angeschlossen und kann die Ausführung von Anwendungen steuern. RASP kann die Applikation auch dann schützen, wenn sie Sicherheitslücken aufweist, die in der Entwicklung übersehen wurden. Es werden fortlaufende Sicherheitsüberprüfungen durchgeführt und auf Live-Angriffe reagiert, indem die Sitzung des Angreifers beendet und auf den Angriff aufmerksam macht.
Im DevSecOps ist die Integration in die Pipeline wie folgt abgebildet:
Technologien wie IAST und RASP können sich nachteilig auf die Performance der Anwendung auswirken, wenn sie in Produktion eingesetzt werden. Ein besonderes Problem von RASP ist, dass innerhalb eins Teams ein falsches Gefühl von Sicherheit entsteht. Auch wenn RASP ein Fehler feststellt, muss dieser behoben werden und dabei möglicherweise die Applikation offline geschaltet werden.
Auf den gesamten DevOps-Prozess bezogen bietet sich eine Kombination der vorgestellten Typen an. So kann verhindert werden, dass bei einem Schritt "Sicherheit" vergessen geht. Nicht zu vergessen sind dabei die Kosten, welche dadurch reduziert werden können. Je früher eine Schwachstelle entdeckt wird, desto schneller kann reagiert und sie behoben werden. Dafür müssen auch die notwendigen Skills zwingend ins Team gebracht werden. Die Resultate müssen interpretiert und Massnahmen daraus abgeleitet werden können. Sonst sind auch die besten Tools nutzlos.
DevSecOps Foundation
Der DevSecOps Foundation Kurs vermittelt die grundlegenden Konzepte von DevSecOps und wie diese sich von traditionellen Sicherheitsansätzen unterscheiden. Sie lernen wie DevSecOps Strategien definiert und implementiert werden.
Noch Fragen?
Ist DevSecOps dasselbe wie DevOps. Folgender Beitrag klärt auf.
Xebia hat mit der Quality Engineering Toolbox ein kompaktes Nachschlagewerk geschaffen, welches die wichtigsten Konzepte von DevOps bzw. DevOps Testing auf je einer A6 Doppelseite erläutert. Das Thema «DevSecOps» ist dort ebenfalls vertreten.
Unsere Kurse zum Thema:
Site Reliability Engineering (SRE) Foundation
Haben Sie Fragen zu DevSecOps oder allgemein Sicherheitstests? Wissen Sie nicht, wie Sie Sicherheitstests in Ihre Pipeline integrieren sollen? Zögern Sie nicht und nehmen Sie Kontakt mit uns auf. Wir helfen Ihnen sehr gerne weiter!
