Ich soll einen Pentest-Report schreiben – was muss rein und welches Format taugt was?

Gehen Sie davon aus, dass Chefs die technischen Details sowieso nicht lesen. Die ersten beiden Seiten müssen so geschrieben sein, dass der Vize-Geschäftsführer es sofort versteht – statt „SQL-Injection gefunden“ lieber „Es besteht das Risiko, dass Kundendaten aus der Bestelldatenbank nach außen abfließen“, das bringt den Ernst der Lage auf den Punkt.

Raten Sie bei den Schwachstellen-Schweregraden nicht einfach ins Blaue hinein, sondern orientieren Sie sich an CVSS. Ob eine Lücke remote ausnutzbar ist oder Rechte erfordert, ändert den Score gewaltig. Vergessen Sie auch nicht, sensible Daten und Session-Keys auf den Screenshots unkenntlich zu machen.

Behalten Sie beim Aufbau am besten diese Reihenfolge bei: 1) Management Summary und Gesamtrisikobewertung, 2) Scope-Grenzen und Testdaten, 3) Schwachstellenliste mit detaillierten Proofs, 4) Priorisierter Behebungsplan, 5) Ablauf des Retests.

Gab es im Vertrag mit dem Kunden konkrete Vorgaben zum Berichtsformat? Manche Großkunden verlangen Vorlagen, die bestimmten Compliance- oder Finanzprüfungsstandards entsprechen. Habt ihr das vorher abgeklärt, um spätere Korrekturschleifen zu vermeiden?

bei meinem ersten Bericht hatte ich damals einfach den 100-Seiten-Export vom Schwachstellenscanner ins Türkische übersetzt und abgegeben – der Kuunde ist völlig ausgerastet. packt da nur verifizierte Lücken rein, die sich live auch wirklich ausnutzen lassen bloß kein überflüssiges Rauschen.

Wenn das eigene Team die selbst entwickelte Software testet und bewertet riecht das für den Kunden schnell nach Befangenheit. Legt die Methodik im Bericht extrem transparent dar, damit die IT-Leute des Kunden nicht auf die Idee kommen, ihr hättet eigene Fehler unter den Teppich gekehrt.

Wir liefern im Schnitt zehn solcher Berichte im Jahr ab. Sobald ein Report mehr als 40 Seiten hat, sinkt die Quote bei den Technikern drastisch, die Dinge auch wirklich anzugehen. Zwischen 15 und 20 Seiten, knackig und auf den Punkt, bringt erfahrungsgemäß viel mehr.

packt neben die findings auch gleich ne grobe schätzung für den fix-aufwand dann ziehen die devs beim kunden viel schneller mit viel erfolg

Ja, die Situation bei pentest report schreiben ist genau so. Wenn die Zwei-Faktor-Authentifizierung aktiv ist, reicht ein gestohlenes Passwort allein nicht aus.

Wenn es jemand anders macht, würde mich das auch interessieren.

gut gemacht.

Beim Lesen dieser Antwort war ich erleichtert, es liegt also nicht nur an mir. Jeder nicht schriftlich festgehaltene Punkt ist einer, an den sich beide Parteien später unterschiedlich erinnern.

Der meiste Zeitverlust entsteht durch Arbeiten, die auf Freigaben warten. Aus Erfahrung weiß ich das.

Absolut. Wenn ich noch etwas hinzufügen darf: Beginnt mit einem kleinen Test, bindet nicht gleich alles fest.

Nur als Notiz könnte nützlich sein.

wenn du so vorgehst kläre das vorher und wenn die Zwei-Faktor-Authentifizierung aktiv ist reicht ein gestohlenes Passwort allin nicht aus.

nur als Notiz, könnte nützlich sein.

Ich möchte kurz warnen. Vergessene Testumgebungen sind häufiger das Einfallstor als das Live-System.

An deiner Stelle würde ich so vorgehen.

Ich würde mich freuen wenn du das Ergebnis postest. übrigens die Zeit die ihr braucht, um ein Problem zu erkennen, bestimmt direkt dessen Kosten.

Ich hoffe das hilft dir weiter.

Ein Thema, das gerade aktuell ist.

Vielen Dank, das hat mir sehr geholfen. Jeder nicht schriftlich festgehaltene Punkt ist einer, an den sich beide Parteien später unterschiedlich erinnern.

Wenn ihr das Ergebnis hier postet hilft es auch anderen.

Ich würde mich freuen, wenn du das Ergebnis postest.