TheWhiteCode

Der Bericht kam als PDF, vierzig Seiten, mit einem Deckblatt in der Farbe, die Agenturen für Vertrauen halten. Auf Seite sechs stand der Satz, der die nächsten drei Monate bestimmt hat: kritische Schwachstelle, sofortiger Handlungsbedarf. Auf Seite sieben stand, dass die Schwachstelle Administratorrechte voraussetzt. Der Administrator war der einzige Benutzer der Anwendung.

So beginnt fast jeder Pentest-Bericht, den ich gelesen habe: mit einer Zeile, die korrekt ist, und einer Zeile, die den Kontext liefert, und niemand liest die zweite. Ich habe drei Jahre lang Berichte geschrieben, bevor ich sie gelesen habe. Das ist keine Empfehlung, das ist eine Beichte.

Vierzig Seiten, dreißig davon Methodik

Ein Pentest-Bericht ist drei Dokumente in einem: ein Verkaufsdokument für den Einkauf, ein Haftungsdokument für die Agentur und ein technisches Dokument für die Leute, die es reparieren sollen. Diese Reihenfolge ist der Grund, warum die technisch relevanten Sätze auf Seite 31 stehen und die Zusammenfassung auf Seite 4 Dinge behauptet, die auf Seite 32 relativiert werden.

Die Methodik-Kapitel sind nicht nutzlos, sie sind für einen anderen Leser geschrieben. Nur: Sie beantworten nicht die Frage, die dein Team hat. Die lautet nicht „wurde nach Standard X geprüft“, sondern „was kann jemand mit einem Browser und einem Konto tun“. Diese Frage steht selten im Bericht und fast nie in der Zusammenfassung.

Ich lese Berichte deshalb von hinten. Anhang, Screenshots, Requests. Da steht, was tatsächlich passiert ist. Die Prosa davor ist eine Zusammenfassung der Screenshots, gelegentlich mit anderen Worten.

Was fehlt, ist die eine Seite, die ein Team wirklich braucht: der Angriff in fünf Schritten, der Beweis, der Fix. Diese Seite schreibt niemand, weil sie nicht ins Template passt und weil sie den Bericht angreifbar macht. Ein Screenshot kann man wegdiskutieren, einen nachvollziehbaren Angriffspfad nicht.

Schweregrad ist eine Meinung mit Zahl

Ein Basis-Score bewertet eine Schwachstelle, nicht dein System. Er kennt dein Netz nicht, deine Rollen nicht, deine Daten nicht und nicht die Frage, ob der betroffene Dienst überhaupt von außen erreichbar ist. Zwei Findings mit demselben Score können bei dir einen Unterschied von zwei Größenordnungen im Risiko haben.

Die Zahl im Bericht ist der Anfang einer Diskussion, nicht ihr Ende. Ich gebe den Score nie ohne die drei Sätze weiter, weil sonst genau das passiert, was ich zwanzigmal gesehen habe: Jemand kauft ein Tool für das Finding mit der 9, und die Lücke mit der 6 bleibt offen, weil sie langweilig aussieht und keinen guten Slide abgibt.

Ich übersetze jeden Schweregrad in drei Sätze: Was kann ein Angreifer tun, der das ausnutzt? Was braucht er dafür? Was kostet es uns, wenn es passiert? Wenn einer der drei Sätze mit „kommt drauf an“ endet, ist der Score noch nicht bewertet, sondern nur berechnet. Ein hoher Score in einem internen Tool mit einem Benutzer ist kein hohes Risiko. Es ist eine Zeile, die im nächsten Bericht wieder auftaucht, weil niemand sie geschlossen hat.

Drei Konsequenzen, nicht vierzig Findings

Die Tabelle ist das einzige Artefakt, das ich aus einem Bericht behalte. Vier Spalten, eine Zeile pro Finding, das war es. Was nicht in die Tabelle passt, ist entweder kein Finding oder kein Risiko. Und die Spalte „Wer entscheidet“ ist die wichtigste, weil sie verhindert, dass ein Ticket an ein Team geht, das die Anwendung nicht kennt.

„Niemand“ ist übrigens eine gültige Antwort in dieser Spalte, solange sie in der Spalte „Frist“ eine Begründung hat. Was nicht funktioniert, ist eine leere Zelle mit dem Kommentar „später“. Später ist kein Termin, später ist eine Stimmung.

Der Retest ist der Vertrag

Ein Finding ohne Retest ist eine Behauptung. Ein Ticket zu schließen, weil der Entwickler den Code geändert hat, ist eine andere Aussage als ein Finding zu schließen, weil jemand es erneut versucht hat und gescheitert ist. Der Unterschied ist der Unterschied zwischen Hoffnung und Nachweis, und er kostet einen halben Tag.

Deshalb steht im Vertrag bei uns ein Retest, bevor die Schlussrechnung bezahlt wird. Nicht weil ich der Agentur misstraue, sondern weil ich meinem eigenen Team misstraue, wenn es „behoben“ schreibt. Ich war dieses Team. Ich habe Dinge behoben, die nicht behoben waren, mit gutem Gewissen und schlechtem Test.

Fazit

Die Kosten eines gelesenen Berichts sind ein Nachmittag: Tabelle bauen, drei Konsequenzen benennen, Fristen setzen, Retest terminieren. Die Kosten eines ungelesenen Berichts sind ein Ordner, der aussieht wie Compliance und funktioniert wie ein Placebo, plus die Überraschung im nächsten Jahr, wenn dasselbe Finding mit neuer Nummer wiederkommt.

Nimm den letzten Bericht, den du bekommen hast, und such die Seite mit den Screenshots. Wenn du dort etwas findest, das du nicht kanntest, hast du deinen Nachmittag. Wenn nicht, hast du einen guten Bericht bekommen. Beides ist ein Ergebnis.

Welche vier Zeilen stehen bei euch heute im Ticket, und wer unterschreibt den Retest, bevor der Bericht im Ordner verschwindet?