Dieser Leitfaden beschreibt das Mindestvorgehen für Dynamic Application Security Testing (DAST), um ISO-27001 Nachweise zu liefern. Ziel ist es, sicherzustellen, dass produktionsnahe Umgebungen auf Laufzeitschwachstellen überprüft werden.

Ziel & Scope #

• Prüft laufende Anwendungen (Staging/QA) auf Sicherheitslücken wie XSS, SQL Injection, AuthN/AuthZ-Fehler.
• Fokussiert auf kritische Pfade (Login, Transaktionen, Admin-Funktionen).

Minimalvorgehen je Release #

1. Wählt ein Tool:
   • Web/Oberfläche: OWASP ZAP baseline oder ZAP full scan.
   • APIs: zap-api-scan.py oder trivy kubernetes --scan config für Ingress-Kontrollen.
2. Führt den Scan gegen eine freigegebene Staging-URL aus (https://staging.example.com).
3. Speichert das Ergebnis in scan-reports/<datum>/dast.html bzw. .json.
4. Bewertet Findings: HIGH/Critical sofort beheben, Medium/Low dokumentieren und priorisieren.
5. Dokumentiert das Ergebnis im Release-Ticket (SEC-DAST-<nr>) mit Link zum Report und Freigabekommentar.

Beispielbefehle #

# ZAP Baseline Scan
docker run --rm -t owasp/zap2docker-stable zap-baseline.py \
  -t https://staging.example.com \
  -r dast-report.html

# ZAP API Scan (OpenAPI Spec)
docker run --rm -t owasp/zap2docker-stable zap-api-scan.py \
  -t https://staging.example.com/openapi.json \
  -f openapi \
  -r dast-api-report.html

Häufige Stolperfallen #

• Testumgebung muss Fixdaten/Seed-Accounts bereitstellen, sonst erkennt DAST keine geschützten Bereiche.
• Rate Limiting beachten; Scanfenster mit Ops/Betrieb abstimmen.
• Dokumentiert false positives im Corrective Action Log oder Issue Tracker.

Spezielle Szenarien #

• Keine offenen Ports (z. B. Queue-Worker): Führt statische Analysen, Policiescans und Integrationstests mit Security-Fokus durch. Dokumentiert im Release-Ticket, warum DAST nicht anwendbar ist, und verweist auf kompensierende Kontrollen.
• Mobile Apps: Nutzt Mobile-Proxy/Emulator (z. B. OWASP ZAP mit Android-Emulator), um API-Aufrufe zu testen. Ergänzt den Prozess durch MobSF, um APK/IPA-Dateien statisch und dynamisch zu prüfen.
• Bot-Erkennung / Anti-Automation: Konfiguriert Whitelisting oder Test-Tokens, die Captchas/Rate-Limits umgehen. Ohne Freischaltung DAST nicht möglich → Alternative Kontrollen dokumentieren.
• Nicht-HTTP-Protokolle (z. B. SSH, MQTT): DAST nicht geeignet; nutzt Protokoll-spezifische Scanner (ssh-audit, nmap) oder dokumentiert eine manuelle Prüfung mit dem Hardening Review Protokoll. Ergebnis im Corrective Action Log festhalten.