Een pentestrapport lezen: wat je eerst oplost en waar je mag tegenspreken

TL;DR

• Een pentestrapport is een werkbon, geen rapportcijfer. Het aantal bevindingen zegt weinig. De aanvalspaden zeggen veel.
• Lees eerst de executive summary voor het verhaal en ga dan naar de bevindingen die een aanvaller aan elkaar kan knopen.
• Bij elke bevinding hoort bewijs: wat er gedaan is, vanaf waar, met welk account en waar het toegang toe gaf.
• Een ernstscore beschrijft de zwakte in het algemeen. Jouw prioriteit hangt af van waar ze zit en waar ze naartoe leidt.
• Je mag een bevinding in vraag stellen als niemand geprobeerd heeft ze uit te buiten. Een goede tester vindt die vraag prima.

De meeste teams krijgen een keer per jaar een pentestrapport, openen de pdf, scrollen naar de tabel met rode en oranje rijen en beginnen te tellen. Zo haal je er het minste uit. Het aantal vertelt je hoe druk de volgende sprint wordt. Het zegt niets over hoe dicht iemand bij je data kwam. Heb je net een pentest achter de rug of ga je er een bestellen, dan is dit hoe wij het rapport zouden lezen als we aan jouw kant van de tafel zaten.

Begin bij het verhaal, dan de paden

De executive summary heeft een taak: in gewone taal zeggen wat een aanvaller kon bereiken en hoeveel moeite dat kostte. Lees ze eerst en vraag je af of je het in twee zinnen aan je directie kunt navertellen. Lukt dat niet, laat de tester het dan doen tijdens de debrief.

Zoek daarna naar ketens. Een losse bevinding met ernst medium is zelden het probleem. Een medium die een account met weinig rechten oplevert, naast een tweede die van dat account een beheerder maakt, is dat wel. Een rapport dat bevindingen een voor een opsomt zonder te tonen hoe ze samenhangen, laat het belangrijkste werk aan jou.

Wat een bevinding nodig heeft voor je ze aanvaardt

Met een bruikbare bevinding kun je vier vragen beantwoorden: wat is er precies gedaan, vanaf welke startpositie, met welke rechten, en waar gaf het toegang toe. Screenshots, requests en responses, en stappen die je eigen ontwikkelaar kan herhalen horen in het technische deel. "Verouderde component gevonden" met een versienummer en verder niets is wat een scanner afdrukt. Het vertelt je niet wat een aanvaller ermee kan.

Hier zie je wat menselijke validatie waard is. Een scanner meldt wat er kwetsbaar uitziet. Een tester probeert het en schrijft op wat er gebeurde. Dat verschil lees je in het rapport als bewijs.

Ernst is niet hetzelfde als prioriteit

De meeste rapporten scoren bevindingen met CVSS of een vergelijkbare schaal. Die score beoordeelt de zwakte in het algemeen: hoe makkelijk ze uit te buiten is en wat de technische impact is. Ze weet niet dat op de getroffen server je klantendatabase staat, of dat hij in een testnetwerk hangt dat niemand gebruikt.

Vertaal de score dus naar je eigen omgeving. Vraag bij elke hoge of kritieke bevinding: is ze bereikbaar vanaf het internet of alleen van binnenuit, is er een login nodig, en waar leidt ze bij ons naartoe? Een medium op het systeem dat betalingen verwerkt kan voorgaan op een high op een geïsoleerde machine. Schrijf die redenering op, want een auditor vraagt waarom je in die volgorde hebt opgelost.

Kritieke bevindingen horen niet op de pdf te wachten. Wij melden ze tijdens de test, zodat je team kan ingrijpen terwijl het testen doorloopt.

Bevindingen waar je mag tegenspreken

Niet elke regel in een rapport verdient een ticket. Stel vragen als een bevinding geen bewijs van misbruik bevat, als ze een theoretisch risico beschrijft zonder weg ernaartoe, of als ze een best practice herhaalt die op jouw opzet niet van toepassing is. Vraag gewoon: heb je dit geprobeerd, en wat gebeurde er?

Er bestaan eerlijke antwoorden zonder exploit. Soms zou uitbuiten de productie beschadigen en is de tester bewust gestopt. Dat hoort dan ook zo in het rapport te staan. Wat je niet hoeft te aanvaarden is een lijst van veertig punten waarvan niemand kan zeggen welke drie ertoe doen.

Tegenspreken maakt van jou geen lastige klant. Een debrief wordt beter als de klant in discussie gaat.

Van rapport naar plan

Maak in de eerste week van het rapport een kort plan. Geef elke bevinding een eigenaar en een beslissing: oplossen, beperken, of aanvaarden met een reden. Groepeer per oorzaak, want tien bevindingen komen vaak uit een ontbrekende controle, zoals inputvalidatie of zwakke toegangsregels. Pak je de oorzaak aan, dan sluit je ze alle tien.

Laat de oplossingen daarna controleren. Een patch die in staging werkt en nooit in productie belandt, komt vaak voor. Een retest loopt elke gemelde kwetsbaarheid opnieuw na en levert een rapport dat zegt wat gesloten is. Dat is het document waar auditors, verzekeraars en klanten om vragen.

Veelgestelde vragen

Wat moet er in een pentestrapport staan?

Een executive summary in gewone taal, de scope en de aanpak, en per bevinding een beschrijving, bewijs, een ernstscore en een aanbevolen oplossing. Een goed rapport toont ook hoe bevindingen samen een aanvalspad vormen en wordt toegelicht in een debrief.

Hoe prioriteer ik de bevindingen uit een pentest?

Vertrek van de ernstscore en corrigeer ze voor je eigen omgeving: is het systeem bereikbaar vanaf het internet, is er een login nodig, en tot welke data of rechten geeft het toegang. Bevindingen die samen een keten naar gevoelige data vormen gaan voor, wat hun afzonderlijke score ook is.

Mag ik het oneens zijn met een bevinding in een pentestrapport?

Ja. Vraag wat er getest is, vanaf welke positie en wat het resultaat was. Een bevinding zonder bewijs of zonder realistische weg ernaartoe kan na overleg lager ingeschaald of geschrapt worden. Leg de beslissing en de reden vast, zodat ze bij een audit overeind blijft.

Wat is het verschil tussen een pentestrapport en een scanrapport?

Een scanrapport somt op wat geautomatiseerde tools als mogelijk kwetsbaar aanduiden. Een pentestrapport toont wat een tester met die zwaktes gedaan heeft en hoe ver dat leidde. Bij onze pentest is elke bevinding door een mens gevalideerd en zit het bewijs erbij.

Hoe snel na het rapport moeten we de bevindingen oplossen?

Kritieke bevindingen zodra ze gemeld zijn, en dat kan al tijdens de test zijn. Voor de rest leg je per bevinding een datum vast op basis van prioriteit en plan je de retest zodra de oplossingen live staan. Hoe langer een bekende zwakte open blijft, hoe langer je blootgesteld bent.

Wie moet het pentestrapport lezen?

De directie leest de executive summary, het technische team de bevindingen en het bewijs, en wie compliance opvolgt bewaart het rapport en het retestrapport als bewijs. Alle drie horen bij de debrief.

Gerelateerde diensten en bronnen

Wil je een rapport waar je mee aan de slag kunt, dan combineert onze pentest handmatig testen met een technisch rapport, een executive summary en een debrief. De retest bevestigt dat je oplossingen standhouden. Heb je het rapport nodig als bewijs bij een audit, bekijk dan de auditklare pentest. Zit je nog in de voorbereiding? Pentest Checklist: wat moet je opnemen in een Pentest opdracht? helpt je met de scope, en Penetration Testing versus Vulnerability Scanning legt uit waarom de uitvoer van een scanner geen pentestrapport is.