Pentest Rapportage
Pentester zijn is niet altijd leuk. Net zoals elk beroep kent ook de pentester werkzaamheden die absoluut minder leuk zijn. Een significant en misschien wel het belangrijkste onderdeel van een pentest of security check is de rapportage. En dat… lieve lezers vinden de meeste pentesters verschrikkelijk. Rapporteren is nu eenmaal een ander soort “creativiteit” dan het uitvoeren van een pentest of security check. Maar toch, de eindrapportage is het document voor de klant. Deze documentatie kan in een lade gelegd worden of hij kan werkelijk toegepast gaan worden. Uiteindelijk willen we allemaal een veiliger wereld en dus is het maken van een goede pentest rapportage belangrijk. Kunnen mijn rapportages beter? Jazeker! Maar toch hoop ik dat mijn rapportages “hout snijden” en ik heb het idee dat mijn setup duidelijk is. In deze post ga ik je (op veler verzoek) vertellen hoe mijn rapportage eruit ziet.
Het is lastig om te vertellen hoe je de perfecte rapportage maakt! Vaak is het ook afhankelijk van de opdracht. Niet elk onderdeel van een rapportage is altijd aanwezig. En soms moeten bestaande onderdelen anders ingestoken worden om ze duidelijker te maken. We gaan voor het documenteren altijd graag uit van een “template”. En dat kan. Maar een template is niet leidend. In deze post ga ik je vertellen hoe mijn template eruit ziet zodat je hier een idee van krijgt. En jazeker, ook jij mag deze opzet gewoon gebruiken en verbeteren. Wel zou ik het fijn vinden wanneer je goede verbeteringen met me wilt delen. Ik probeer altijd te leren en verbeteren en het zou top zijn als jij me daarbij kunt helpen.
Een goede pentest rapportage bestaat altijd uit een 3-tal zaken:
- Intro
- Management Rapportage
- Technische Rapportage
Je wilt namelijk ervoor zorgdragen dat het management in korte en begrijpbare taal de impact van de rapportage begrijpt en je wilt ook dat de technische afdeling voldoende informatie heeft om mitigerende maatregelen te nemen. Je kunt ervoor kiezen om 2 verschillende rapportages te schrijven maar vaak worden deze gecombineerd in 1 enkele rapportage. Op die manier blijft alle informatie uit de case gebundeld.
Deze 3 “hoofdlijnen” hebben allen een eigen invulling die per type test ontzettend kan afwijken. Een vulnerability scan zal een korter achtergrondverhaal zonder timeline hebben terwijl een onderzoek van een gecompromitteerd netwerk deze wel (en uitgebreider) zal bevatten. Op hoofdlijnen zijn bovenstaande 3 onderwerpen als volgt verdeeld:
Intro
- Vertrouwelijkheid
- Disclaimer
- Contact informatie en betrokken partijen
- Assessment Overview
- Assessment Achtergrond
- Onderdelen van het assessment
- Opbouw van de security ratings
- Timeline van events
- Scopebepaling
Management Rapportage
- Management samenvatting
- Bevindingen en Aanbevelingen
- Vulnerability Overview
Technische Rapportage
- Exploitation step-by-step (per node)
- Finding & Remediation Advice (per node)
- Proof of concept / exploitation (per node)
- Bijlagen
Laten we vooropstellen dat de opmaak van de rapportage netjes en overzichtelijk moet zijn. Gebruik altijd dezelfde fonts en instellingen voor koppen, tekst, code etc. Zorg ook voor een overzichtelijke kop- of voettekst en gebruik afbeeldingen wanneer deze meer duiding geven.

Een afbeelding zegt meer dan 1000 woorden. Ik kies ervoor om mijn rapportages in het Engels te schrijven. Toegegeven, een Nederlandse rapportage is makkelijker en op verzoek altijd mogelijk. Een Engelse rapportage is echter “beter leesbaar” en “altijd te gebruiken”. Daarmee bedoel ik dat een Engelse rapportage door zowel nationale- als internationale partijen gelezen kan worden en dat terminologie vaak al Engelse woorden omvat. Een Nederlandse rapportage ziet er daarom altijd een beetje uit als “half Engels en half Nederlands”. De keuze om primair een Engelse pentest rapportage op te leveren is daarom meestal de meest logische keuze.
Laten we nu de template eens inhoudelijk bekijken:
Intro
Intropage
De intropagina is een “afwijkende” pagina waarin ik de meest basale informatie plaats en in het kort laat zien waar de rapportage over gaat. Denk aan de titel, versie, datum en auteur. Ook plaats ik op de intropagina een TLP indicatie (vertrouwelijkheid) en een korte disclaimer waarin staat hoe deze rapportage verspreid mag worden.

Confidentiality Statement
Na de intropagina volgt de inhoudsopgave en vervolgens een confidentiality statement waarin aangegeven wordt wie de eigenaard van de documentatie is en hoe deze documentatie gedeeld en verspreid mag worden.
Disclaimer
Op dezelfde pagina plaats ik eveneens een korte disclaimer om uit te leggen wat een penetration test is en hoe deze geïnterpreteerd moet worden.
Contact information and Involved Parties
Het is altijd belangrijk om de juiste contactinformatie te noteren van zowel de pentester als de contactpersonen ten tijde van de pentest en de betrokken partijen zoals externe leveranciers.

Assessment Overview
Wanneer er een assessment gedaan wordt is het goed om uit te leggen hoe deze in zijn werk gaat en uit welke fases deze bestond. Deze worden hier beschreven.
Assessment Background
Een assessment wordt altijd uitgevoerd met een specifieke reden. Is het een onderzoek naar een gecompromitteerde machine of een algemeen onderzoek van specifieke software? De reden van het uitvoeren van de assessment wordt hier beschreven.
Assessment Components
Hier beschrijven we het type test dat uitgevoerd is. Is het een white, grey of black box test? En wat betekend dit? Ook beschrijven we hier onze “house cleaning” regels ofwel in welke staat we de onderzochte onderdelen achtergelaten hebben na het onderzoek.
Finding Severity Ratings
Wanneer gedurende de assessment severity scores (gradaties van “ernstigheid”) gegeven worden dan legt deze tabel overzichtelijk uit wat deze scores inhouden.

Timeline of events
Zeker wanneer onderzoek gedaan wordt naar een specifieke compromitatie/hack is een “timeline of events” een goed hulpmiddel om in een kort overzicht weer te geven op welke momenten er bepalende acties uitgevoerd zijn welke de compromitatie hebben mogelijk gemaakt. Dat doe je in dit hoofdstuk.
Scope
Een scopebepaling is belangrijk wanneer je een test gaat uitvoeren. Hierin beschrijf je welke segmenten tot de “te testen” scope behoren en voornamelijk welke onderdelen hierin expliciet uitgesloten zijn.
Management Rapportage
Alle bovenstaande punten geven de lezer een goed overzicht van de aanleiding en het doel van deze rapportage en maken het ook mogelijk om de rapportage juist te interpreteren. Vervolgens schrijf ik de managementrapportage. Zoals al gezegd is het de kunst om deze kort en krachtig te schrijven. Hieruit moet snel duidelijk zijn wat de impact is en wat vervolgens de aanbevelingen zijn. De management rapportage is meestal zeer beknopt en bestaat uit de volgende punten:
Executive Summary
Hierin beschrijven we in het kort nogmaals de informatie welke hierboven beschreven is en ook wat hiervan de uitkomsten zijn. Wat hebben we gedaan, waarom hebben we dat gedaan, wat hebben we (globaal) gevonden en wat zijn hierin (globaal) de aanbevelingen.
Attack Summary and Recommendations
Dit hoofdstuk beschrijft beknopt de aanval (of gevonden issues) met bijbehorende aanbevelingen. Gebruik binnen de management rapportage zoveel mogelijk tabellen en grafieken. Dit leest snel en is overzichtelijk.
Vulnerability Overview
Dit overzicht wordt gebruikt wanneer een vulnerability scan is uitgevoerd. Hierin beschrijven we beknopt (oneliners) welke vulnerabilities gevonden zijn en op welke nodes deze aangetroffen zijn.
Technische Rapportage
De technische rapportage heeft als doel om de technische afdeling te ondersteunen. Hierin gaan we dus uitgebreider op de zaken in. Wat is er gevonden? Hoe hebben we dit exact gevonden? Wat is hiervan de impact en wat moet er gebeuren om dit op te lossen. De oplossing wordt op hoofdlijnen gegeven om een inschatting van de impact te kunnen maken. Vervolgens is het aan de technische afdeling om te bepalen of, en hoe de oplossing uitgevoerd wordt. Ik kies er meestal voor om dit overzicht per node te beschrijven. In de meeste gevallen bundelt dit de bevindingen op een duidelijke manier. We beschrijven dan onderstaande onderdelen voor elke onderzochte node:

Exploitation step-by-step
Allereerst beschrijven we alle stappen die de bevinding(en) mogelijk maken. Wat hebben we inhoudelijk gedaan. We beschrijven dit stap-voor-stap met zoveel mogelijk screenshots en voorbeelden van code. Hierdoor wordt de bevinding reproduceerbaar en dat vergemakkelijkt het testen en dus het oplossen. Zorg ervoor dat dit onderdeel overzichtelijk blijft door netjes een onderverdeling van kopjes te maken. Vaak begin ik deze beschrijving met een samenvatting van de node gevolgd door een aantal “logische fases” zoals enumeratie, gaining access, privilege escalation, persistence.
Finding & Remediation
Nadat de “stap-voor-stap” omschrijving klaar is weten we de vulnerabilities welke gevonden zijn. Deze beschrijven we hier separaat. Wat betekend de vulnerability exact? Hoe ernstig is de gevonden vulnerability en wat is een mogelijke mitigatie voor deze vulnerability. Vernoem indien mogelijk ook duidelijk externe referenties (hyperlinks) om nog meer duiding aan de techniek, vulnerability, exploit of remediation te geven. Meer informatie is altijd handig indien dit voor de lezer gewenst is.

Proof of concept / exploitation (per node)
Soms voegen we een “proof” pagina toe waarin we in een paar screenshots laten zien dat de gevonden vulnerability aanwezig is en wat hiervan de mogelijk impact is. Deze pagina is optioneel omdat deze “proof” screenshots (of video’s) ook aan bod komen tijdens de stap-voor-stap uitleg. Maar toch is dit in sommige gevallen een goed referentiemodel.
Appendix
Eventuele bijlagen worden aan het eind van dit hoofdstuk geplaatst. Dit kunnen b.v. lange code snipets zijn die niet handig te verwerken zijn in de stap-voor-stap uitleg omdat de lezer dan veel “scrollwerk” heeft of het kunnen b.v. terugkerende zaken zijn. Op deze manier kun je het eenmaal beschrijven en steeds in te tekst refereren naar de bijlage. Ook dit om de leesbaarheid te bevorderen.
Mocht je interesse hebben dan mag je hier de template downloaden.
Mocht je nog meer inspiratie willen dan kun je hier een groot aantal verschillende rapportages downloaden.
Zoals je ziet is het maken van een rapportage veel werk. Je probeert diverse doelgroepen te bereiken en om een zo compleet mogelijk beeld te schetsen. Ook probeer je mee te denken met mogelijke oplossingen. Je moet deze eind rapportage zien als het “klapstuk” van je pentest. Hierin laat je zien wat er niet in de haak is en hiermee zorg jij ervoor dat de beveiliging weer naar een hoger niveau getild wordt. Niet altijd leuk, niet altijd makkelijk, maar absoluut onmisbaar en essentieel. En ik hoop dat ik je een klein beetje op weg geholpen heb met de template.
★ Succes…! ★