Na de pentest: bevindingen prioriteren, herstellen en de retest goed benutten

De waarde van een pentest zit niet in het rapport, maar in wat je ermee doet. Toch zien wij regelmatig dat een rapport na oplevering in een la verdwijnt, dat alleen de kritieke bevinding wordt opgelost, of dat een fix wordt doorgevoerd die het symptoom wegneemt maar de oorzaak laat staan. Bij de volgende pentest komen dezelfde categorieën bevindingen dan gewoon terug. In dit artikel lopen we door wat er na de oplevering van een pentestrapport zou moeten gebeuren: het rapport goed lezen, prioriteren met verstand, herstellen aan de bron, en de retest gebruiken als sluitstuk en als bewijs.

Het rapport goed lezen

Een goed pentestrapport bevat per bevinding een risicoclassificatie, een beschrijving van de kwetsbaarheid, reproductiestappen en een hersteladvies. De classificatie is meestal gebaseerd op CVSS, aangevuld met de inschatting van de pentester over de context. Dat laatste is belangrijker dan het getal. Een reflected XSS in een intern beheerportaal met drie gebruikers is een ander risico dan dezelfde bevinding op een publieke inlogpagina. Lees daarom niet alleen de scores, maar ook de toelichting van de tester over exploiteerbaarheid en impact in jouw situatie.

Kijk daarnaast naar de rode draad. Vijf losse bevindingen over ontbrekende autorisatiechecks op verschillende endpoints zijn geen vijf incidenten, maar één structureel probleem: autorisatie wordt per endpoint geregeld in plaats van centraal. Wie alleen de losse bevindingen wegwerkt, mist de belangrijkste conclusie van het rapport.

Prioriteren: verder kijken dan de kleur

De meeste organisaties pakken bevindingen af op volgorde van risiconiveau: eerst kritiek, dan hoog, en de rest als er tijd is. Dat is een redelijk startpunt, met twee kanttekeningen. De eerste: combinaties tellen. Twee middelmatige bevindingen die samen een aanvalspad vormen, bijvoorbeeld een gebruikersenumeratie plus het ontbreken van rate limiting op de inlogpagina, verdienen de prioriteit van dat gezamenlijke pad, niet van de losse onderdelen. Een goede pentester benoemt zulke ketens in het rapport; vraag ernaar als ze ontbreken.

De tweede kanttekening: herstelkosten wegen mee. Een lage bevinding die in een kwartier is opgelost (een ontbrekende security header, een cookie zonder Secure-attribuut) kun je beter meteen meenemen dan agenderen. Bewaar de discussie voor de bevindingen waar herstel echt werk is, en leg voor elk risiconiveau een interne hersteltermijn vast. Auditors vragen daar bij ISO 27001- en SOC 2-audits naar: niet alleen of je pentest, maar ook of je opvolging een afgesproken termijn kent en of je die haalt.

Herstellen aan de bron

Het verschil tussen een symptoomfix en een bronfix bepaalt of de bevinding terugkomt. Drie voorbeelden uit onze eigen retests. Een IDOR-bevinding (een gebruiker kan via een object-ID in de URL gegevens van een ander opvragen) kun je fixen door dat ene endpoint dicht te zetten. De bronfix is een centrale autorisatielaag die bij elke objectaanvraag controleert of de gebruiker eigenaar is. Een XSS-bevinding kun je fixen door dat ene invoerveld te filteren. De bronfix is consistente output-encoding in de templating-laag, met een Content-Security-Policy als vangnet. Een kwetsbare library kun je eenmalig updaten. De bronfix is een proces dat afhankelijkheden periodiek controleert en bijwerkt.

Een symptoomfix is soms een prima eerste stap om het acute risico te verkleinen. Een WAF-regel die een specifieke aanval blokkeert, koopt tijd. Maar behandel zo'n maatregel als mitigatie, niet als afronding: de bevinding blijft open staan totdat de bron is aangepakt. En wees eerlijk in je administratie. Een bevinding op "opgelost" zetten omdat de exploit uit het rapport niet meer werkt, terwijl dezelfde fout drie endpoints verderop nog bestaat, is jezelf voor de gek houden. Vraag je ontwikkelteam daarom bij elke bevinding: waar bestaat dit patroon nog meer?

Risico accepteren mag, maar doe het expliciet

Niet elke bevinding hoeft te worden opgelost. Soms is het risico klein, staat de applicatie op de nominatie voor uitfasering, of wegen de herstelkosten niet op tegen het risico. Risicoacceptatie is dan een legitieme keuze, mits die expliciet wordt gemaakt: door iemand die het mandaat heeft (de risico-eigenaar, niet de ontwikkelaar), met een vastgelegde motivering en een herbeoordelingsdatum. Een stilzwijgend niet-opgepakte bevinding is geen geaccepteerd risico, maar een openstaand risico zonder eigenaar. Bij audits is dat verschil precies waar wij op letten.

De retest: sluitstuk en bewijs

Een retest is een gerichte hertest van de bevindingen uit het oorspronkelijke rapport, na herstel. De pentester probeert per bevinding opnieuw of de kwetsbaarheid nog uitbuitbaar is en rapporteert de status: opgelost, gedeeltelijk opgelost of niet opgelost. De scope is beperkt tot de eerdere bevindingen; het is geen nieuwe volledige pentest, en dat maakt de retest ook aanzienlijk beperkter in omvang dan het oorspronkelijke onderzoek.

De waarde zit in twee dingen. Ten eerste de inhoudelijke controle: gedeeltelijk herstel komt vaker voor dan je zou verwachten. Wij zien met regelmaat dat een fix de gerapporteerde exploit blokkeert, maar met een variant alsnog te omzeilen is, of dat het herstel op één omgeving is doorgevoerd en op een andere niet. Ten tweede het bewijs. Een retestrapport waarin de bevindingen op "opgelost" staan, is voor klanten, toezichthouders en auditors sterker dan de eigen mededeling dat alles is gefixt. In ISO 27001- en SOC 2-trajecten is de combinatie pentestrapport plus retestrapport plus registratie van de tussenliggende opvolging precies de bewijsketen die een auditor wil zien.

Spreek de retest bij voorkeur al af bij de opdrachtverlening van de pentest, inclusief de termijn waarbinnen die kan plaatsvinden. Plan het herstel daarop in en laat in elk geval de kritieke en hoge bevindingen hertesten. Wacht ook niet te lang: hoe verser de bevinding, hoe efficiënter de hertest.

Van rapport naar cyclus

Een pentest is een momentopname. De organisaties die er het meeste uithalen, behandelen de opvolging als vast proces: bevindingen gaan het eigen ticketsysteem in met een eigenaar en een termijn, structurele oorzaken krijgen een eigen verbetertraject, de retest sluit de cyclus, en de lessen schuiven door naar ontwikkelrichtlijnen en de scope van de volgende test. Zo wordt elke pentest een meting van de vooruitgang in plaats van een jaarlijks terugkerende verrassing.