STOP.LI · Berichte · Nachweis
Pentest-
Bericht.
Der Bericht über einen Penetrationstest aus Sicht des Auftraggebers: woran ein belastbarer Bericht zu erkennen ist und wie Befunde im eigenen Umfeld richtig eingeordnet werden.
Auf einen
Blick.
AdressatCISO, IT-Leitung, Revision, EinkaufDer Bericht geht an den Auftraggeber. Er entscheidet, was zuerst behoben wird, und muss den Bericht abnehmen.
RhythmusNach jedem Test und RetestMindestens jährlich für kritische Systeme und nach wesentlichen Änderungen; dazu der Retest-Bericht nach der Behebung.
ZweckAusnutzbarkeit belegen, Prioritäten setzenDer Tester belegt, was sich im festgelegten Umfang ausnutzen lässt. Die Priorität entsteht erst mit dem Kontext des Auftraggebers.
Aufbau
des Berichts.
| Abschnitt | Inhalt | Leitfrage |
|---|---|---|
| Rahmen | Auftrag, Zeitraum, Umfang und Ausschlüsse, Rules of Engagement, Testart (Black, Grey oder White Box), eingesetzte Personen und ihre Qualifikation. | Was wurde unter welchen Bedingungen geprüft? |
| Management Summary | Gesamtbild in Geschäftssprache, die kritischen Angriffswege, Vergleich mit dem letzten Test. | Wie verwundbar sind wir, und wo zuerst handeln? |
| Angriffsketten | Wie sich einzelne Befunde zu einem Weg auf ein schützenswertes Ziel verbinden. | Wie weit käme ein Angreifer? |
| Befunde | Je Befund: ID, betroffene Systeme, technische Schwere mit vollständigem CVSS-Vektor, Priorität im Kontext mit Begründung, Nachweis der Ausnutzbarkeit, Auswirkung, Empfehlung, Owner und Frist. | Was genau, wie schwer, wie dringend? |
| Positive Feststellungen und Einschränkungen | Welche Kontrollen gehalten haben; was nicht oder nur teilweise geprüft werden konnte und warum. | Was wissen wir sicher, was nicht? |
| Retest | Status je Befund mit Datum: behoben, teilweise behoben, offen, Risiko akzeptiert. | Wirkt die Behebung? |
| Umgang mit Daten | Vertraulichkeitsstufe, Verteiler, Ablage, Löschung von Testdaten, Zugangsdaten und Nachweisen. | Wer darf den Bericht sehen, und was wird gelöscht? |
Befunde richtig
bewerten.
Der häufigste inhaltliche Mangel in Pentest-Berichten ist eine falsche Einordnung: Die technische Schwere wird als Risiko ausgegeben. Der Basiswert des Common Vulnerability Scoring System (CVSS) beschreibt die Eigenschaften einer Schwachstelle unabhängig von der Umgebung. Erst Bedrohungs- und Umgebungswerte liefern laut FIRST (Forum of Incident Response and Security Teams, Herausgeber von CVSS) einen umfassenderen Input für die Risikobewertung der eigenen Organisation. Ein belastbarer Bericht trennt deshalb zwei Ebenen.
| Ebene | Frage | Wer bewertet |
|---|---|---|
| Technische Schwere | Wie schwer wiegt die Schwachstelle an sich? CVSS 4.0 mit vollständigem Vektor und Kennzeichnung der verwendeten Metriken (CVSS-B, CVSS-BT, CVSS-BE oder CVSS-BTE). | Tester |
| Priorität im eigenen Umfeld | Wie dringend ist die Behebung hier und jetzt? Bewertet nach den vier Kontextfaktoren unten, mit Begründung je Befund. | Tester und Auftraggeber gemeinsam; der Schutzbedarf kommt vom Auftraggeber |
KontextExposureIst das System aus dem Internet erreichbar, nur mit Einschränkungen im Netz oder stark abgeschottet? SSVC unterscheidet dafür «small», «controlled» und «open».
KontextSchutzbedarfWelchen Schutzbedarf haben Vertraulichkeit, Integrität und Verfügbarkeit der betroffenen Daten und Prozesse? In CVSS 4.0 fliesst er über die Umgebungswerte CR, IR und AR ein.
KontextAusnutzungWurde die Ausnutzung im Test nachgewiesen? Wird die Schwachstelle real ausgenutzt (CISA-Katalog KEV) oder ist eine Ausnutzung wahrscheinlich (EPSS)?
KontextRolle in einer AngriffsketteÖffnet das System einen Weg zu einem schützenswerten Ziel, etwa über gemeinsame Admin-Konten, dieselbe Domäne oder fehlende Segmentierung?
Ein Beispiel: Ein fehlender Sicherheitspatch auf einem isolierten Testserver ohne Verbindung zur Produktion hat eine niedrige Priorität, auch bei hohem CVSS-Basiswert. Derselbe Befund auf einem Testserver, der dasselbe lokale Administratorkonto wie die Produktionsserver nutzt, ist der Einstieg in eine Angriffskette und gehört nach oben. Bewertet wird deshalb nicht das System allein, sondern der Weg, den es öffnet.
Herabstufen ist zulässig und oft richtig. Es braucht aber eine Begründung im Bericht und eine verantwortliche Person, die das verbleibende Risiko akzeptiert. Damit der Tester im Kontext bewerten kann, übergibt der Auftraggeber Schutzbedarf und Exposure der Ziele schon bei der Beauftragung.
Deutschland
und Schweiz.
Gemeinsamer Aufbau für beide Rechtsräume. Die Tabelle zeigt, was die jeweilige Grundlage vom Bericht als Nachweis erwartet.
| Rechtsraum | Grundlage | Bedeutung für den Bericht | Fundstelle |
|---|---|---|---|
| EU und Deutschland | Wesentliche und wichtige Einrichtungen brauchen Konzepte und Verfahren, um die Wirksamkeit ihrer Risikomanagementmassnahmen zu bewerten. | Pentest-Berichte mit Retest-Status belegen diese Bewertung. | Art. 21 Abs. 2 Bst. f NIS2; § 30 Abs. 2 Nr. 6 BSIG ↗ |
| FinanzD | Das Testprogramm für die digitale operationale Resilienz umfasst Penetrationstests; ausgewählte Finanzunternehmen führen bedrohungsorientierte Penetrationstests (TLPT) durch. | Umfang, Methode und Ergebnisse dokumentieren; TLPT folgt dem Rahmen TIBER-EU mit eigenen Berichtspflichten. | Art. 24–26 DORA ↗, TIBER-EU ↗ |
| FinanzCH | Die Geschäftsleitung lässt regelmässig Verwundbarkeitsanalysen und Penetrationstests durch qualifiziertes Personal durchführen; dazu kommen szenariobezogene Cyber-Übungen. | Qualifikation der Tester und Regelmässigkeit im Bericht ausweisen. | FINMA-RS 2023/1 ↗ |
| Kartenzahlungen | Interne und externe Penetrationstests mindestens alle zwölf Monate und nach wesentlichen Änderungen, nach einer dokumentierten Methodik. | Methodik, Umfang und Behebung mit Retest belegen. | PCI DSS v4.0.1, Anforderung 11.4 ↗ |
| Methode | Leitfaden für technische Sicherheitstests mit Planung, Durchführung und Bericht; Umgang mit Schwachstellen nach ISO/IEC 27001:2022 Annex A 8.8. | Methode und Bewertungsmodell im Bericht benennen. | NIST SP 800-115 ↗ |
Checkliste für
Auftraggeber.
Zum Abhaken vor dem Test und bei der Abnahme. Die Liste ersetzt kein Vertragsmuster; Haftung und Rules of Engagement regelt der Auftrag.
| Phase | Prüfpunkt |
|---|---|
| Beauftragung | Umfang, Ziele und Ausschlüsse sind schriftlich festgelegt. |
| Beauftragung | Schutzbedarf und Exposure je Ziel sind dem Tester übergeben. |
| Beauftragung | Rules of Engagement mit Zeitfenstern, Abbruchkriterien und Notfallkontakt sind vereinbart. |
| Beauftragung | Testart (Black, Grey oder White Box) und bereitgestellte Zugänge sind festgelegt. |
| Beauftragung | Qualifikation der eingesetzten Personen ist benannt. |
| Beauftragung | Bewertungsmodell (CVSS-Version, Priorisierung im Kontext) ist vorab vereinbart. |
| Beauftragung | Umgang mit Daten, Ablage und Löschung ist geregelt. |
| Beauftragung | Retest ist im Angebot enthalten, mit Umfang und Frist. |
| Abnahme | Der geprüfte Umfang entspricht dem Auftrag; Abweichungen sind begründet. |
| Abnahme | Einschränkungen und nicht geprüfte Bereiche sind benannt. |
| Abnahme | Die Management Summary ist für die Geschäftsleitung ohne Fachwissen verständlich. |
| Abnahme | Angriffsketten sind dargestellt, nicht nur Einzelbefunde. |
| Abnahme | Jeder Befund hat einen vollständigen CVSS-Vektor mit Version und Kennzeichnung der Metriken. |
| Abnahme | Die Priorität im Kontext ist je Befund begründet (Exposure, Schutzbedarf, Ausnutzung, Angriffskette). |
| Abnahme | Bestätigte Befunde haben einen nachvollziehbaren Nachweis der Ausnutzbarkeit. |
| Abnahme | Ungeprüfte Scanner-Befunde sind als solche gekennzeichnet. |
| Abnahme | Gleichartige Befunde sind zusammengefasst, nicht pro System wiederholt. |
| Abnahme | Jede Empfehlung ist konkret umsetzbar. |
| Abnahme | Owner und Frist sind je Befund zugeordnet oder zur Zuordnung vorbereitet. |
| Abnahme | Positive Feststellungen sind dokumentiert. |
| Abnahme | Herabstufungen sind begründet und mit einer verantwortlichen Person versehen. |
| Abnahme | Intern und extern erreichbare Ziele sind getrennt ausgewiesen. |
| Abnahme | Der Retest-Status je Befund ist mit Datum ausgewiesen oder der Retest-Termin festgelegt. |
| Abnahme | Vertraulichkeitsstufe, Verteiler, Version und Berichtsdatum sind angegeben. |
| Abnahme | Die Löschung von Testdaten und Zugangsdaten ist bestätigt. |
Häufige
Fehler.
FehlerSchwere als Risiko ausgegebenDer Schweregrad des Scanners oder der CVSS-Basiswert wird unverändert als Priorität übernommen.
FehlerCVSS ohne VektorEine Zahl ohne Vektor und Version lässt sich weder prüfen noch an die eigene Umgebung anpassen.
FehlerKleinigkeiten als kritischFehlende HTTP-Header oder veraltete Versionsangaben stehen neben echten Angriffswegen auf derselben Stufe.
Fehler200 Einzelbefunde statt 5 effektiv möglicher AngriffskettenLange Listen ohne Angriffsketten verdecken, was ein Angreifer tatsächlich erreicht.
FehlerKontext fehltOhne Schutzbedarf und Exposure vom Auftraggeber kann der Tester nur technisch bewerten.
FehlerHerabstufung ohne SpurBefunde werden still zurückgestuft, ohne Begründung und ohne verantwortliche Person.
FehlerKein RetestDer Bericht endet mit Empfehlungen; ob die Behebung wirkt, bleibt offen.
FehlerTestdaten bleiben liegenZugangsdaten, Konten und Nachweise aus dem Test werden nicht gelöscht.
Passende
Werkzeuge.
Diese Werkzeugklassen liefern Daten oder Nachweise für den Bericht. Einordnung und Produktvergleich stehen auf den verlinkten Seiten.
WerkzeugPenetration Testing und Automated PentestingPlattformen, Pentest as a Service und Werkzeuge für Fachleute im Vergleich.WerkzeugBreach and Attack Simulation und Control ValidationPrüft laufend, ob Kontrollen bekannte Angriffstechniken erkennen und stoppen.WerkzeugVulnerability ManagementFührt Befunde aus Scans und Tests zusammen und steuert die Behebung.WerkzeugRed Teaming, Purple Teaming und EmulationPrüft Erkennung und Reaktion mit realistischen Angriffsszenarien.