Blog
Wie Sie einen Penetrationstest-Bericht (VAPT) lesen: ein verständlicher Leitfaden für Teams
· 8 Min. Lesezeit
Kurzfassung
- Ein Pentest-Bericht ist eine Erzählung, keine Tabelle: Er erläutert, was getestet wurde, was gefunden wurde, wie schwerwiegend jedes Problem ist und wie genau es zu beheben ist.
- Jeder gute Befund trägt eine Schwere, einen CVSS-Score, Nachweise, eine realistische Auswirkung, Schritte zur Reproduktion und einen Behebungsweg, sodass Engineers handeln können, ohne zu raten.
- Der Abschnitt zu Umfang und Rules of Engagement beschreibt die Grenzen des Tests, was ebenso wichtig ist wie die Befunde selbst.
- Ein Nachtest und ein Attestation Letter (Bestätigungsschreiben) belegen, dass die Korrekturen tatsächlich gewirkt haben, und genau das möchten Prüfer und Kunden üblicherweise sehen.
- Ein manueller Bericht liest sich völlig anders als ein Scanner-Auszug, weil ein Mensch jedes Problem validiert, Fehlalarme entfernt und die geschäftliche Auswirkung erläutert hat.
Wenn Ihr Unternehmen gerade seinen ersten Penetrationstest in Auftrag gegeben hat, kann der Bericht, der in Ihrem Postfach landet, einschüchternd wirken. Er ist oft lang, voller Sicherheitsjargon und kommt mit einem Farbcode für die Schwere, den niemand erklärt hat. Die gute Nachricht ist, dass diese Berichte einer vorhersehbaren Struktur folgen, und sobald Sie wissen, wofür jeder Teil da ist, lässt sich das gesamte Dokument viel leichter lesen und in Handeln umsetzen.
Dieser Leitfaden führt von vorne bis hinten durch einen typischen Bericht eines Vulnerability Assessment and Penetration Test (VAPT). Er ist für Gründerinnen und Gründer, Engineers und interne Security-Teams geschrieben, die diesem Format zum ersten Mal begegnen, nicht für professionelle Prüfer. Am Ende sollten Sie in der Lage sein, einen Bericht zu öffnen, die für Sie wichtigen Teile zu finden und sie in einen konkreten Arbeitsplan zu überführen.
Die Zusammenfassung für die Geschäftsleitung: die eine Seite, die die Führung liest
Die Zusammenfassung für die Geschäftsleitung (Executive Summary) steht nicht ohne Grund am Anfang. Sie ist für Menschen geschrieben, die die technischen Details nie lesen werden, etwa Ihre Geschäftsführung, Ihren Vorstand oder das Einkaufsteam eines potenziellen Kunden. Sie sollte die Geschichte des Einsatzes in verständlicher Sprache erzählen: was getestet wurde, wie gesund die gesamte Sicherheitslage wirkte und welche die schwerwiegendsten Probleme waren.
Eine gute Zusammenfassung für die Geschäftsleitung vermeidet tiefen Fachjargon und beantwortet stattdessen die Fragen, die die Führung tatsächlich stellt. Haben die Tester etwas gefunden, das zu einer Datenpanne führen könnte? Sind Kundendaten gefährdet? Gibt es etwas, das vor dem nächsten Release behoben werden muss? Üblicherweise enthält sie eine einfache Zählung der Befunde nach Schwere, sodass Sie auf einen Blick sehen, ob Sie es mit einem kritischen Problem oder zwanzig geringfügigen zu tun haben.
Behandeln Sie diesen Abschnitt als die Zusammenfassung, die Sie im Unternehmen breiter teilen können. Die detaillierten Befunde weiter hinten im Bericht sind für Ihre Engineers; die Zusammenfassung für die Geschäftsleitung ist die Fassung, die nicht-technischen Stakeholdern hilft zu verstehen, warum die Arbeit wichtig ist und worauf die Aufmerksamkeit zu richten ist.
Umfang und Rules of Engagement: die Grenzen des Tests
Bevor ein Befund überhaupt etwas bedeutet, müssen Sie wissen, was tatsächlich getestet wurde. Der Abschnitt zum Umfang listet die genauen beteiligten Assets auf: bestimmte Webanwendungen, APIs, IP-Bereiche, mobile Apps oder Cloud-Umgebungen. Alles, was hier nicht aufgeführt ist, wurde nicht getestet, was enorm wichtig ist, wenn Sie einem Kunden später mitteilen, dass Ihr Produkt geprüft wurde.
Die Rules of Engagement (Regeln des Einsatzes) beschreiben, wie der Test durchgeführt wurde. Dazu gehören das Testfenster, ob gegen eine Produktions- oder eine Staging-Umgebung getestet wurde, ob die Tester über Zugangsdaten und Dokumentation verfügten (ein Grey-Box- oder White-Box-Test) oder mit nichts begannen (ein Black-Box-Test), sowie alle Systeme, die ausdrücklich ausgeschlossen waren.
Lesen Sie diesen Abschnitt sorgfältig, denn er legt die Grenzen dessen fest, was der Bericht ehrlicherweise behaupten kann. Ein sauberer Bericht gegen einen engen Umfang ist nicht dasselbe wie ein unbedenkliches Zeugnis für Ihre gesamte Plattform. Wenn ein wichtiges System ausgeschlossen wurde, weil es nicht rechtzeitig bereit war, gehört diese Lücke auf Ihren Radar und nicht versteckt in eine Fußnote.
Methodik: wie die Tester vorgegangen sind
Der Abschnitt zur Methodik erläutert den Ansatz und die Standards, denen die Tester gefolgt sind. Die meisten seriösen Tests orientieren sich an anerkannten Frameworks wie dem OWASP Testing Guide für Webanwendungen, den OWASP API Security Top 10 für APIs oder dem Penetration Testing Execution Standard für umfassendere Einsätze. Die Nennung dieser Frameworks zeigt Ihnen, dass die Arbeit einem etablierten, wiederholbaren Prozess folgte und nicht jemandem, der planlos herumstocherte.
Dieser Teil beschreibt üblicherweise die Phasen des Tests: Reconnaissance und das Kartieren der Angriffsfläche, das Identifizieren von Schwachstellen, der Versuch, sie gefahrlos auszunutzen, und anschließend die Dokumentation des Gefundenen. Er kann auch die eingesetzten Werkzeuge auflisten, von automatisierten Scannern bis hin zu manuellen Proxy-Werkzeugen, neben den manuellen Techniken, die die Tester von Hand anwandten.
Sie müssen nicht jede hier genannte Technik verstehen. Was Sie bestätigen möchten, ist, dass der Einsatz automatisierte Werkzeuge mit echten manuellen Tests kombinierte, denn genau diese Kombination unterscheidet eine gründliche Prüfung von einem schnellen Scan.
Die Befunde: wo die eigentlichen Details stecken
Die Befunde sind das Herzstück des Berichts, und jeder einzelne ist üblicherweise nach einer einheitlichen Vorlage verfasst, sodass Ihre Engineers genau wissen, wo sie nachsehen müssen. Das Verständnis der Standardfelder macht den gesamten Abschnitt weit weniger abschreckend.
Severity (Schwere) ist eine Bewertung in verständlicher Sprache, üblicherweise von kritisch über hoch, mittel und niedrig bis informativ. Sie sagt Ihnen, wie dringend etwas Aufmerksamkeit erfordert.
Der CVSS-Score ist eine standardisierte Zahl von 0.0 bis 10.0 aus dem Common Vulnerability Scoring System. Er zerlegt die Merkmale einer Schwachstelle, etwa wie leicht sie auszunutzen ist und wie viel Schaden sie anrichten könnte, in einen einheitlichen Wert, sodass sich Probleme über Berichte hinweg vergleichen lassen.
Evidence (Nachweis) ist der Beleg. Hier sehen Sie Screenshots, aufgezeichnete Anfragen und Antworten oder extrahierte Daten, die zeigen, dass das Problem real und nicht theoretisch ist.
Impact (Auswirkung) erläutert, was ein Angreifer tatsächlich erreichen könnte, in geschäftlichen Begriffen. Könnte er die Daten anderer Kunden lesen, ein Konto übernehmen oder Befehle auf Ihrem Server ausführen? Dies ist der Teil, der einen technischen Fehler mit einer realen Konsequenz verbindet.
Reproduktionsschritte sind eine nummerierte Anleitung, mit der Ihre Entwickler das Problem selbst auslösen können. Einen Fehler reproduzieren zu können, ist üblicherweise der schnellste Weg, ihn zu verstehen und zu beheben.
Remediation (Behebung) ist die empfohlene Korrektur, idealerweise konkret genug, um danach zu handeln, etwa eine Konfigurationsänderung, ein zu übernehmendes Code-Muster oder eine zu aktualisierende Bibliothek, statt einer vagen Anweisung, sicherer zu sein.
Der Behebungsplan und der Nachtest
Über die einzelnen Korrekturen hinaus hilft Ihnen ein starker Bericht beim Priorisieren. Ein Behebungsplan gruppiert die Befunde in eine sinnvolle Reihenfolge der Arbeit, üblicherweise getrieben von der Schwere und davon, wie leicht sich jede Korrektur ausrollen lässt. Das Ziel ist, Sie davon abzuhalten, einen kosmetischen informativen Hinweis mit derselben Dringlichkeit zu behandeln wie einen kritischen Fehler, der Kundendaten offenlegt.
Sobald Ihr Team die Probleme behoben hat, schließt der Nachtest den Kreis. Die Tester prüfen jeden Befund erneut, der behoben sein sollte, und halten dessen neuen Status fest: behoben, teilweise behoben oder noch offen. Ein Nachtest ist das, was aus einer Liste von Problemen einen Nachweis macht, dass Sie sich tatsächlich darum gekümmert haben.
Nach einem erfolgreichen Nachtest kann die Testfirma einen Attestation Letter (Bestätigungsschreiben) ausstellen. Dies ist ein kurzes, teilbares Dokument, das bestätigt, dass eine Prüfung stattgefunden hat, über welchen Umfang, und dass die identifizierten Probleme behoben wurden. Es ist wichtig, klar zu sein, worum es sich handelt: Ein Attestation von einem Anbieter von Penetrationstests ist eine Aussage über die durchgeführte Testarbeit. Es ist keine Zertifizierung und kein Prüfungsurteil. Formale Zertifikate und Prüfungsbescheinigungen kommen ausschließlich von unabhängigen akkreditierten Stellen oder lizenzierten CPA-Firmen, was ein vom Pentest selbst getrennter Prozess ist.
Wie Prüfer und Kunden den Bericht tatsächlich nutzen
Sobald Sie den Bericht haben, möchten üblicherweise zwei Zielgruppen außerhalb Ihres Engineering-Teams Teile davon sehen. Die erste sind Kunden, insbesondere größere, die während ihrer Vendor-Security-Prüfung einen Nachweis über die Tests verlangen, bevor sie einen Vertrag unterzeichnen. In den meisten Fällen teilen Sie die Zusammenfassung für die Geschäftsleitung und den Attestation Letter statt der vollständigen technischen Befunde, da der detaillierte Bericht eine Landkarte Ihrer Schwachstellen ist und sorgsam behandelt werden sollte.
Die zweite Zielgruppe sind Prüfer, die auf Frameworks wie SOC 2 oder ISO 27001 hinarbeiten. Für sie ist der Pentest ein Nachweis dafür, dass Sie ein glaubwürdiges Vulnerability-Management-Programm betreiben. Sie möchten sehen, dass die Tests in einem sinnvollen Rhythmus stattfanden, dass Befunde nachverfolgt wurden und dass sie behoben und nachgetestet statt offengelassen wurden. Der Nachtest-Status und der Behebungsplan sind für einen Prüfer oft interessanter als die Schwachstellen selbst, da sie einen funktionierenden Prozess belegen.
Denken Sie in beiden Fällen daran, wer was zertifiziert. Eine Testfirma berichtet, was sie gefunden hat, und bestätigt, was behoben wurde. Das Zertifikat oder der Prüfungsbericht wird getrennt davon von der akkreditierten Zertifizierungsstelle oder der CPA-Firma erteilt, die dieses Programm betreibt.
Warum ein manueller Bericht kein Scanner-Auszug ist
Automatisierte Scanner sind nützlich und schnell, aber ihre Rohausgabe unterscheidet sich stark von einem ordentlichen Penetrationstest-Bericht. Ein Scanner erzeugt eine lange Liste potenzieller Probleme auf Basis von Mustererkennung, und er kann nicht sagen, welche davon in Ihrer spezifischen Umgebung wirklich ausnutzbar sind. Diese Liste ist üblicherweise voller Fehlalarme und Duplikate und erläutert nur selten die geschäftliche Auswirkung.
Ein manueller Bericht spiegelt einen Menschen wider, der jedes Problem validiert, das Rauschen verworfen und Probleme verkettet hat, die ein Scanner isoliert melden würde. Ein Tester könnte ein geringfügiges Informationsleck mit einer schwachen Passwortrichtlinie kombinieren, um eine vollständige Kontoübernahme zu demonstrieren, etwas, das kein einzelner Scanner-Befund offenbaren würde. Genau diese Überlegung, wie Fehler zusammenwirken, ist das, was automatisierten Werkzeugen entgeht.
Der praktische Unterschied zeigt sich in der Formulierung. Ein Scanner-Auszug sagt, dass eine Schwachstelle existiert. Ein manueller Bericht zeigt Ihnen den Nachweis, erläutert, was ein Angreifer in Ihrem Kontext damit anstellen könnte, gibt Ihren Entwicklern Reproduktionsschritte und empfiehlt eine gezielte Korrektur. Wenn ein Kunde oder Prüfer einen Penetrationstest verlangt, ist dieser validierte, von einem Menschen verfasste Bericht das, was sie erwarten, und kein exportierter Scan.
Häufig gestellte Fragen
- Was ist der Unterschied zwischen einem Vulnerability Assessment und einem Penetrationstest?
- Ein Vulnerability Assessment identifiziert und listet potenzielle Schwachstellen auf, oft unter starkem Einsatz automatisierter Scans. Ein Penetrationstest geht weiter, indem ein Mensch gefahrlos versucht, diese Schwachstellen auszunutzen, um zu beweisen, was ein Angreifer tatsächlich erreichen könnte. Ein VAPT-Bericht kombiniert beides: die Breite eines Assessments mit der validierten Tiefe eines manuellen Tests.
- Was bedeutet der CVSS-Score in einem Bericht?
- CVSS, das Common Vulnerability Scoring System, erzeugt eine standardisierte Zahl von 0.0 bis 10.0, die widerspiegelt, wie schwerwiegend eine Schwachstelle ist, basierend auf Faktoren wie der Leichtigkeit der Ausnutzung und dem möglichen Schaden. Sie erlaubt es Ihnen, die Schwere von Problemen über verschiedene Befunde und Berichte hinweg einheitlich zu vergleichen.
- Darf ich meinen Penetrationstest-Bericht mit Kunden teilen?
- Das dürfen Sie, aber seien Sie wählerisch. Die Zusammenfassung für die Geschäftsleitung und ein Attestation Letter sind üblicherweise geeignet, um sie während einer Vendor-Security-Prüfung zu teilen. Der vollständige Bericht enthält detaillierte Reproduktionsschritte für Ihre Schwachstellen, daher teilen ihn die meisten Teams nur unter einer Geheimhaltungsvereinbarung oder gar nicht und verlassen sich stattdessen auf die Zusammenfassung und das Attestation.
- Ist ein Penetrationstest dasselbe wie zertifiziert oder geprüft zu sein?
- Nein. Ein Penetrationstest sagt Ihnen, welche Sicherheitsprobleme bestehen, und bestätigt, wann sie behoben sind. Eine Zertifizierung gegen einen Standard wie ISO 27001 oder ein SOC-2-Prüfungsbericht wird getrennt davon von einer unabhängigen akkreditierten Zertifizierungsstelle oder einer lizenzierten CPA-Firma ausgestellt. Eine Testfirma kann ein Attestation über die von ihr durchgeführten Tests liefern, ist aber niemals die Zertifizierungs- oder Prüfungsstelle.
- Was ist ein Nachtest und warum ist er wichtig?
- Ein Nachtest ist, wenn die Tester die Befunde erneut prüfen, nachdem Ihr Team sie behoben hat, um zu bestätigen, dass jedes Problem wirklich gelöst und nicht nur teilweise angegangen ist. Er ist wichtig, weil eine Liste von Korrekturen, die Sie vorgenommen zu haben glauben, nicht dasselbe ist wie eine unabhängige Bestätigung, dass sie gewirkt haben, und Prüfer sowie Kunden möchten diese Bestätigung in der Regel sehen.
- Warum kostet ein manueller Bericht mehr als ein Scanner-Bericht?
- Weil ein Mensch Zeit darauf verwendet, jedes Problem zu validieren, Fehlalarme zu entfernen, Schwachstellen zu verketten, um die reale Auswirkung zu zeigen, und klare Reproduktionsschritte sowie maßgeschneiderte Behebungen zu schreiben. Diese menschliche Analyse ist das, was den Bericht vertrauenswürdig und umsetzbar macht, und genau das kann ein schneller automatisierter Scan nicht liefern.
Engagements haben nach Vereinbarung festen Umfang und Festpreis. Wenn Sie unsicher sind, welcher Service passt, ob Zertifizierungs-Readiness, GRC-Beratung oder ein Penetrationstest, beschreiben Sie Ihre Situation und wir empfehlen einen Umfang, einschließlich der ehrlichen Auskunft, falls Sie uns noch nicht brauchen.
