Der Pentest-Report: Aufbau & Bewertung

Warum ist der Report so wichtig?

Der Pentest-Report ist die Brücke zwischen technischem Testing und geschäftlicher Entscheidung. Ein guter Report ermöglicht es dem Management, Risiken zu verstehen und Budget für Sicherheitsmassnahmen zu allozieren. Er gibt dem IT-Team konkrete, umsetzbare Anweisungen zur Behebung. Und er liefert Auditor und Regulatoren den Nachweis, dass Sicherheitsprüfungen durchgeführt wurden.

Ein schlechter Report hingegen – voller technischer Jargon ohne Kontext, ohne Priorisierung, ohne Behebungsanleitung – wird ignoriert. Die investierten Pentest-Kosten waren dann umsonst.

Aufbau eines professionellen Pentest-Reports

1. Executive Summary

Die Executive Summary richtet sich an Management und Entscheidungsträger, die nicht alle technischen Details benötigen, aber die Gesamtrisikolage verstehen müssen. Sie umfasst typischerweise:

• Gesamtbeurteilung der Sicherheitslage (z.B. «Gut», «Befriedigend», «Kritisch»)
• Anzahl der gefundenen Schwachstellen nach Schweregrad (Kritisch, Hoch, Mittel, Niedrig, Info)
• Wichtigste Erkenntnisse und Empfehlungen in 2-3 Sätzen
• Vergleich mit branchenüblichen Standards (z.B. «Im Vergleich zu ähnlichen Unternehmen liegt die Sicherheitslage unter dem Durchschnitt»)

2. Methodik & Scope

Dieser Abschnitt beschreibt, was getestet wurde und wie. Er dient der Nachvollziehbarkeit und Transparenz. Inhalte: Testzeitraum, getestete Systeme (IP-Ranges, Domains), ausgeschlossene Systeme, verwendete Tools und Frameworks (z.B. PTES, OWASP), Testansatz (Black/Grey/White Box), Einschränkungen (z.B. «DoS-Tests wurden ausgeschlossen»).

3. Detaillierte Findings

Für jede gefundene Schwachstelle wird ein separates «Finding» erstellt. Ein Finding sollte folgende Elemente enthalten:

• Titel: Klare, prägnante Beschreibung (z.B. «SQL Injection im Login-Formular ermöglicht Authentifizierungsumgehung»)
• Schweregrad: CVSS-Score (z.B. 9.8 – Kritisch)
• Beschreibung: Technische Erklärung der Schwachstelle
• Proof of Concept (PoC): Konkreter Nachweis, wie die Schwachstelle ausgenutzt wurde (Screenshots, curl-Commands, Payloads)
• Impact: Was kann ein Angreifer damit erreichen? (Datenleck, Systemübernahme, Lateral Movement)
• Remediation: Schritt-für-Schritt-Anleitung zur Behebung mit Code-Beispielen oder Konfigurationsvorschlägen
• Referenzen: Links zu OWASP, CVE, CWE oder BSI-Empfehlungen

4. Risikobewertung & Priorisierung

Die Risikobewertung basiert typischerweise auf CVSS (Common Vulnerability Scoring System) in Version 3.1 oder 4.0. CVSS bewertet Schwachstellen nach:

• Base Score: Intrinsische Eigenschaften der Schwachstelle (Ausnutzbarkeit, Impact)
• Temporal Score: Zeitabhängige Faktoren (Verfügbarkeit eines Exploits, Verfügbarkeit von Patches)
• Environmental Score: Organisationspezifische Faktoren (Wert des Assets, Sicherheitsanforderungen)

Zusätzlich zum CVSS-Score berücksichtige ich in meinen Reports die business-relevante Risikobewertung: Eine Schwachstelle mit CVSS 7.0 in einem internen Testsystem ist weniger kritisch als eine Schwachstelle mit CVSS 7.0 im öffentlich erreichbaren Kundenportal.

5. Anhänge

Typische Anhänge: Rohdaten der Scans (Nessus-Export, Nmap-Logs), Screenshots der Exploits, Netzwerkdiagramme (falls im Scope), ausführliche Log-Dateien.

Vom Report zur sicheren Infrastruktur

Ein Report allein ändert nichts. Die Remediation ist der entscheidende Schritt. Ich empfehle meinen Kunden folgendes Vorgehen:

1. Priorisierung: Beheben Sie zuerst kritische und hochriskante Schwachstellen (CVSS 9.0-10.0 und 7.0-8.9).
2. Quick Wins: Beseitigen Sie einfach behebbare Schwachstellen sofort (z.B. fehlende Security Headers, Default-Credentials).
3. Planung: Erstellen Sie einen Zeitplan für komplexere Behebungen (z.B. Refactoring von Authentifizierungslogik).
4. Retest: Lassen Sie nach Behebung einen Retest durchführen, um zu verifizieren, dass die Schwachstellen tatsächlich geschlossen sind.