Continuous Security Testing in der Delivery-Pipeline
Stete Prüfung
DevOps erlaubt es Unternehmen, ihre Software schneller auf den Markt zu bringen. Um Sicherheitslücken zu vermeiden, muss ein kontinuierliches Testen in den Entwicklungsprozess integriert werden.
Unternehmen, die DevOps konsequent umsetzen, haben einen Marktvorteil gegenüber den Mitbewerbern, die Software nach einem klassischen Softwareentwicklungslebenszyklus (SDLC) entwickeln. Die erfolgreiche Umsetzung von DevOps ist aber nur durch eine konsequente Testautomatisierung möglich. Doch in den meisten Fällen sind nur die Tests automatisiert, die funktionale Anforderungen testen. Tests von nicht funktionalen Anforderungen werden meistens außen vor gelassen.
Sicherheitsexperten führen Tests noch halbautomatisiert oder manuell durch. Damit wird der DevOps-Ansatz ad absurdum geführt. Denn DevOps konsequent implementiert, bedeutet, dass auch Security-Tests vollautomatisch in der Continuous-Delivery-Pipeline ausgeführt werden. Oder aber sie sollten in die Entwicklungstätigkeit in Form von statischen Analysen von Sicherheitsschwachstellen einfließen. Klassische Penetration-Tests, die von Zeit zu Zeit von externen Sicherheitsexperten durchgeführt werden, sind zu vermeiden. Sie sind aufwendig und wenig zielführend. Nachhaltiger ist es, diese Aufwände einzusetzen, um DevOps mittels Continuous Security Testing zu DevSecOps zu machen, damit der Softwarelebenszyklus vorhersehbarer wird. Mit DevSecOps ist es möglich, Security immer wieder und früh zu testen, um eine schnelle Rückmeldung zu ermöglichen.
Arten von Sicherheitstests
Es gibt funktionale und nicht funktionale Sicherheitstests. Erstere sind automatisierte Regressionstests, die zum Ziel haben, funktionale Sicherheitsmerkmale wie Login, Logout, Password Policy und Credentials-Management zu testen. Tools wie Selenium für das Web, Appium für Mobile-Apps und Postman für Webservices automatisieren sie.
Nicht funktionale Sicherheitstests, auch Penetration-Tests genannt, testen gegen bekannte Schwachstellen der Anwendung und der Laufzeitumgebung. Darunter fallen SQL Injections, fehlende HttpOnly Flags für Sitzungscookies oder die Verwendung bekannter SSL Suites. Die Tests eignen sich für die Automatisierung, da die Schwachstellen vorab bekannt sind (OWASP).
Sie benötigen Zugriff auf die HTTP-Ebene, den Browserautomatisierungstools nicht bereitstellen. Ein hybrider Ansatz schafft Abhilfe: Browserautomatisierung zusammen mit einem Proxyserver zum Prüfen, Eingeben und Ändern von HTTP Requests und HTTP Responses. Tools wie Burp Suite und OWASP ZAP konzentrieren sich auf die HTTP-Schicht und fungieren als Anwendungsscanner. Diese führen auf der HTTP-Ebene Inspektionstests durch, indem sie Angriffsdaten injizieren und die Antwort der Anwendung auswerten.
Tools wie Nessus, Arachni und Gauntlt scannen Infrastruktur und Laufzeitumgebung der Anwendung auf Schwachstellen. Sie prüfen IP-Adressen und Ports auf bekannte Schwachstellen, darunter Abhängigkeiten von Open-Source-Tools und mögliche Schwachstellen in deren Komponenten. InSpec [1] und Kitchen testen die Konfiguration der Laufzeitumgebung.
Bei der Umsetzung nicht funktionaler Sicherheitstests gegen bekannte Schwachstellen von Anwendung und Laufzeitumgebung kommen folgende AST-Verfahren (Application Security Testing) zum Einsatz:
– First-Generation-Ansatz: statische Anwendungssicherheitstests (Static Application Security Testing, SAST) und dynamische Anwendungssicherheitstests (Dynamic Application Security Testing, DAST);
– Second-Generation-Ansatz: interaktive Anwendungssicherheitstests (Interactive Application Security Testing, IAST) und Runtime-Anwendungsselbstschutz (Runtime Application Self-Protection, RASP).
Um potenzielle Schwachstellen frühzeitig zu erkennen, sollten SAST und DAST schon früh in den Softwarelebenszyklus in Form von Continuous Security Testing eingebunden werden. Aber auch zusätzliche Methoden wie IAST und RASP finden immer mehr ihren Einsatz.