Was ein Penetrationstest-Bericht Ihnen wirklich sagen sollte

Meist sieht man es in zehn Minuten. Öffnen Sie den Bericht, gehen Sie zu einem Finding und stellen Sie eine Frage: Könnte mein Engineer das am Montag beheben, allein mit dem, was hier steht? Lautet die Antwort nein, haben Sie keinen Penetrationstest gekauft. Sie haben eine Scanner-Lizenz mit dem Briefkopf eines Beraters gekauft.

Das Erkennungszeichen: Schweregrad ohne Geschichte

Ein Scanner produziert eine Liste. Vierzig Findings, jedes mit CVSS-Score, jedes für sich zutreffend, und keines mit dem anderen verbunden. Ein Tester produziert eine Erzählung: diese vergessene Subdomain legte ein Staging-Login offen, Staging teilte ein Passwort mit der Produktion, und die Produktion hatte keine MFA auf Administratorkonten. Einzeln sind das Mittel, Mittel und Niedrig. Verkettet ist das der Weg, auf dem jemand Ihre Umgebung vor der Mittagspause besitzt.

Enthält Ihr Bericht keine Kette — keinen Satz, der mit „durch Kombination der Findings 12, 19 und 27“ beginnt — hat Sie niemand wirklich getestet. Man hat ein Werkzeug auf Sie gerichtet.

Vierzig nach Score sortierte Findings sagen Ihnen, was ein Scanner bemerkt hat. Neun danach sortierte Findings, was ein Angreifer damit täte, sagen Ihnen, was zu beheben ist.

Was jedes Finding braucht

• Reproduktionsschritte, denen Ihr Engineer folgen kann, ohne den Tester anzurufen. Der exakte Request, der exakte Parameter, die exakte Voraussetzung.
• Belege. Ein Screenshot oder eine aufgezeichnete Antwort, die zeigt, dass das Problem real und nicht theoretisch ist.
• Auswirkung in Ihren Worten. Nicht „Information Disclosure“ — sondern „ein nicht authentifizierter Nutzer kann jede Kunden-E-Mail-Adresse auslesen“.
• Ein Fix, der die Sache benennt. Die Datei, den Konfigurationsschlüssel, den Header. Nicht „Eingabevalidierung implementieren“.
• Ein ehrlicher Schweregrad, angepasst an Ihre Umgebung. Eine RCE auf einer isolierten Box ohne Daten ist kein Critical, was auch immer der Scanner sagt.

Die Teile, die die meisten Berichte auslassen

Ein guter Bericht sagt Ihnen auch, was nicht getestet wurde und warum. Scope-Grenzen, ausgenommene Systeme, Zugangsdaten, die nie ankamen, die Umgebung, die zwei Tage des Fensters down war. Diese Lücken sind Risiko, das Sie weiterhin tragen, und sie zu verschweigen lässt den Bericht besser aussehen und Sie weniger sicher sein.

Er sollte auch sagen, was gehalten hat. Wenn Ihre WAF die Injection-Versuche blockte und Ihr EDR die Payload beendete, gehört das schriftlich fest. Sie haben dafür bezahlt; Sie sollten belegen können, dass es funktioniert.

Der Retest gehört zur Arbeit

Ein Finding ist nicht geschlossen, weil ein Ticket geschlossen wurde. Es ist geschlossen, weil jemand den Exploit erneut versucht hat und er fehlschlug. Eine Firma, die die Prüfung ihrer eigenen Findings gesondert berechnet, hat einen Anreiz, den Sie in der Beziehung nicht wollen. Der Retest sollte enthalten sein, und der neu ausgestellte Bericht sollte das Finding durchgestrichen mit dem Datum der Verifikation zeigen.

Eine kurze Checkliste

• Gibt es mindestens einen verketteten Angriffspfad, als Erzählung geschrieben?
• Kann ein Engineer das wichtigste Finding ohne Rückfrage reproduzieren?
• Benennt jeder Fix eine Datei, eine Einstellung oder einen Header?
• Gibt es einen Abschnitt darüber, was außerhalb des Scopes lag oder ungetestet blieb?
• Ist ein Retest enthalten, und bis wann?
• Wurden kritische Findings während des Tests gemeldet und nicht für die Abschlussbesprechung aufgehoben?

Der letzte Punkt wiegt schwerer als alle übrigen zusammen. Findet ein Tester am zweiten Tag eine aktive Kompromittierung oder ein internetseitiges Critical, sollten Sie es binnen einer Stunde erfahren. Es drei Wochen später aus einem PDF zu erfahren, ist kein Reporting-Stil. Es ist Fahrlässigkeit.