Agile Analyse-Methoden für die Sicherheit von Webanwendungen

AST - Application Security Testing

Der gängige AST-Security-Prozess in DevOps- oder NoOps-Umgebungen wird in dem nachfolgenden Schaubild beschrieben. Der Security-Berater implementiert initial den Security-Prozess in die CI/CD Pipeline, danach ist er nur noch beratend tätig. Er unterstützt die Entwickler mit dem Tooling und bei komplexen Vorfällen.

SAST - Static Application Security Testing

SAST analysiert den Quellcode, Bytecode oder Binärcode einer Anwendung auf Sicherheitsschwachstellen, typischerweise in der Programmier- und/oder Testphase des Software-Lebenszyklus (SLC). Diese Methodik kann auch nur Programmteile testen, somit müssen die Anwendungen im Testfall nicht lauffähig sein oder komplett getestet werden. Daher versteht SAST keinen Ausführungskontext und kennt nicht den Zustand einer Variable, weswegen nicht alle Schwachstellen aus der OWASP Top Ten untersucht werden können. Dies bietet aber den Vorteil, dass der Prozess früh im Software Development Life Cycle (SDLC) eingesetzt werden kann. Auch das Testen von externen Libraries kann problematisch sein, da diese oft nicht in gewünschter Form vorliegen und obfuskiert sein können.

DAST - Dynamic Application Security Testing

DAST analysiert Anwendungen in ihrem dynamischen und laufenden Zustand während der Test- oder Betriebsphase. Es simuliert Angriffe auf eine Anwendung, analysiert die Reaktionen der Anwendung und bestimmt so, ob sie anfällig ist. Diese Art der Überprüfung deckt die OWASP Top Ten vollständig und funktioniert gut gegen gängige Frameworks wie Wordpress, Joomla oder Drupal. Auch die serverseitigen Sprachen sind abgedeckt und gefundene Schwachstellen sind einfacher auf False Positives zu prüfen. Dennoch wird hier mehr manuelle Konfiguration benötigt, da die Authentifizierung und eine lauffähige Anwendung erzeugt werden müssen.

IAST - Interactive Application Security Testing

IAST kombiniert Elemente von SAST und DAST gleichzeitig. Es wird typischerweise als Agent innerhalb der Testlaufzeit-Umgebung implementiert, der Operationen oder Angriffe beobachtet und Schwachstellen identifiziert. Auf diese Weise kann der dynamische Test viel "intelligenter" gemacht werden. IAST kann nicht analysieren, wie alle Teile einer Anwendung zusammenwirken und zur Laufzeit arbeiten, sodass Schwachstellen in den laufenden Anwendungen erkannt werden können, die Angreifer ausnutzen können.

In dieser Methodik wird ein IAST-Agent in die Software implementiert, der zur Laufzeit die Software automatisiert testet und Schwachstellen an den IAST Management Server reported. Eine WAF (Web Application Firewall) funktioniert nach dem gleichen Schema.

IAST-Lösungen werden in 2 Kategorien unterteilt. Beim Passive IAST sind keine spezifizierten Security-Tests erforderlich. Der Security-Test wird automatisch mit den Software-Tests ausgeführt.

Beim Active IAST wird die Qualität von DAST-Scannern erhöht, da die Requests die im Backend anliegen, besser analysiert werden können. Die zentralen Probleme von DAST-Scannern werden jedoch nicht gelöst. Dennoch bieten die DAST-Ergebnisse dann eine Anleitung auf Code-Ebene, wo sich Software-Schwachstellen befinden, was es für Entwickler leichter macht, identifizierte Schwachstellen zu beheben.

Eine IAST-Implementierung deckt nicht Broken Authentication, Broken Access Control und Insufficient Logging & Monitoring aus der OWASP Top Ten ab.

Ausblick Gartner

Gartner erwartet bis 2022 für den AST-Markt eine durchschnittliche jährliche Wachstumsrate (CAGR) von 10%. Dies ist nach wie vor ein schnell wachsendes Segment im Bereich der Informationssicherheit, das seinerseits mit einer fünfjährigen CAGR von 9% wachsen soll. Das AST-Marktvolumen wird bis Ende 2019 auf 1,15 Milliarden US-Dollar geschätzt.

Unser Ausblick

Alle vorgestellten Methoden haben spezifische Vor- und Nachteile, deswegen muss evaluiert werden, welche Techniken in dem Softwareentwicklungs-Prozess am sinnvollsten sind. IAST kann als sinnvolle Ergänzung für SAST und DAST benutzt werden, jedoch werden diese damit nicht vollständig ergänzt. Wir empfehlen immer den SDL von Sicherheitsexperten zu bewerten, um eine effiziente Lösung zu finden.

Die vorgestellten Methoden können nicht die folgenden Punkte ersetzen:

• Sichere Architektur
• Secure Defaults
• Threat Modeling in Teams
• Peer Code Reviews in Teams
• Pentests
• Secure Coding Know-how
• Security Culture

Quellen

Gartner - Application Security Testing

Continuous Security Testing mit IAST, Matthias Rohr, Oktober 2019