Een pentest levert een rapport op, en dan begint het eigenlijke werk pas. Toch is dit precies de fase waar het vaak misgaat: bevindingen blijven liggen, prioriteiten zijn onduidelijk, en zes maanden later blijkt bij een hertest dat de helft nog openstaat. Wat er na een pentest gebeurt, bepaalt uiteindelijk meer over je beveiliging dan de test zelf.
Stap 1: het rapport echt doorgronden, niet alleen lezen
Een goed pentest-rapport bevat een managementsamenvatting voor bestuurders en een technisch deel voor het IT-team, maar beide hebben elkaar nodig. Plan een gezamenlijke bespreking met de tester: niet om het rapport voor te lezen, maar om vragen te stellen over impact, waarschijnlijkheid en samenhang tussen bevindingen. Twee op zichzelf kleine kwetsbaarheden kunnen samen een serieus risico vormen, en dat soort nuance mis je als je alleen de samenvatting leest.
Stap 2: prioriteren op risico, niet op CVSS-score alleen
Een hoge CVSS-score zegt iets over technische ernst, maar niet alles over je eigen context. Een kritieke kwetsbaarheid op een intern testsysteem zonder gevoelige data weegt anders dan een middelmatige kwetsbaarheid op een systeem met klantgegevens dat vanaf het internet bereikbaar is. Stel per bevinding drie vragen: wat is de impact als dit wordt misbruikt, hoe waarschijnlijk is misbruik, en hoeveel moeite kost het om het op te lossen? Dat geeft een realistischere volgorde dan simpelweg van hoog naar laag werken.
Stap 3: een eigenaar en een deadline per bevinding
Bevindingen zonder eigenaar verdwijnen in een backlog en komen er zelden meer uit. Wijs voor elke bevinding iemand aan die verantwoordelijk is voor de oplossing, met een realistische deadline op basis van de prioriteit. Kritieke bevindingen verdienen dagen tot weken, niet maanden. Voor middelgrote en lagere bevindingen is het redelijk om ze mee te nemen in de reguliere ontwikkelcyclus, zolang er wel een concrete datum aan hangt.
Stap 4: structurele oorzaken aanpakken, niet alleen symptomen
Als een pentest drie keer dezelfde soort kwetsbaarheid vindt op verschillende plekken, bijvoorbeeld ontbrekende invoervalidatie, is het patchen van die drie instanties niet genoeg. De onderliggende oorzaak, bijvoorbeeld het ontbreken van een vaste coding-standaard of code review op dit punt, verdient minstens zoveel aandacht als de individuele bevindingen zelf. Dat voorkomt dat dezelfde klasse kwetsbaarheden bij de volgende test weer opduikt.
Stap 5: hertesten
Een fix die “op papier” klaar is, is niet hetzelfde als een fix die daadwerkelijk werkt. Een hertest van de kritieke en hoge bevindingen bevestigt of de oplossing het probleem echt wegneemt, en voorkomt de vervelende verrassing dat een patch onvolledig bleek. Dit hoeft geen volledige nieuwe pentest te zijn; een gerichte hertest van de eerder gevonden punten volstaat meestal.
Een veelvoorkomend patroon dat je wilt voorkomen
Een bekend scenario: een organisatie krijgt een rapport met twintig bevindingen, pakt de drie kritieke punten direct op, en legt de rest “voor later” opzij. Een jaar later, bij de volgende pentest, blijken vijftien van die zeventien overgebleven punten nog steeds open te staan, simpelweg omdat niemand ze ooit formeel heeft toegewezen. Dat is geen uitzondering, het is het meest voorkomende patroon dat we zien bij organisaties zonder een vast remediatieproces. Het verschil tussen organisaties die wél structureel verbeteren en organisaties die ieder jaar een vergelijkbaar rapport krijgen, zit zelden in de kwaliteit van de pentest, en bijna altijd in wat er in de maanden daarna gebeurt.
Hoe MonkeysICT hierbij ondersteunt
We leveren niet alleen een rapport, maar ook een bespreking waarin we prioriteiten samen doornemen en, waar gewenst, meedenken met je ontwikkelteam over de beste aanpak per bevinding. Onze eerdere opdrachten laten zien dat organisaties die dit traject serieus nemen, bij de volgende pentest aantoonbaar minder en minder ernstige bevindingen hebben, en dat is uiteindelijk het enige dat telt.