Bij het voorbereiden op een pentest gaat het zelden mis op de techniek. Het gaat mis op de logistiek: accounts die op dag één niet werken, een leverancier die geen toestemming heeft gegeven, een contactpersoon die op vakantie is. Elke dag die daaraan opgaat, is een dag die je wel betaalt en waarin niet wordt getest.
Dat is zonde, want het is met een paar afspraken te voorkomen. Dit artikel is de lijst die ik organisaties meegeef voordat een test begint.
Kort samengevat
- Zorg dat testaccounts werken en getest zijn voordat de eerste dag begint.
- Regel toestemming van je hostingpartij en andere leveranciers, schriftelijk en op tijd.
- Wijs een bereikbare contactpersoon aan, plus een vervanger.
- Spreek af wat er gebeurt bij een kritieke bevinding en bij onbedoelde uitval.
- Plan de opvolging nu al in, inclusief de hertest; anders verdwijnt het rapport in een map.
Waarom loont voorbereiden op een pentest zo sterk?
Omdat je een vast aantal dagen inkoopt. Een tester die op maandagochtend niet kan inloggen, wacht niet af: hij begint aan iets anders, of hij besteedt zijn tijd aan het in kaart brengen van wat jij hem in vijf minuten had kunnen vertellen.
Bij een test van vijf dagen is één verloren dag twintig procent van je budget. En het is niet zomaar twintig procent, want de dagen aan het eind zijn de dagen waarin de tester het diepste graaft. Voorbereiding koopt je precies die dagen terug.
Wat regel je technisch vooraf?
Werkende accounts, per rol
Meestal wil je meerdere accounts: een gewone gebruiker, iemand met verhoogde rechten, en eventueel een beheerder. Log er zelf één keer mee in voordat je ze doorgeeft. Verlopen wachtwoorden en accounts die bij eerste gebruik iets vereisen dat niet lukt, zijn de meest voorkomende vertraging.
Toegang tot de juiste omgeving
Test je vanaf buiten, dan hoeft er weinig. Zit er een interne component in, dan is er netwerktoegang nodig: een VPN-account, een apparaat op locatie, of een virtuele machine in je netwerk. Regel dat vroeg, want het loopt vaak langs een andere afdeling.
Beveiliging die niet in de weg zit
Blokkeert je firewall of webapplicatiefirewall het testverkeer, dan test je vooral dat filter en niet de applicatie erachter. Overleg of het IP-adres van de tester wordt doorgelaten. Wil je juist weten of het filter werkt, doe dat dan als apart onderdeel en niet als bijproduct.
Documentatie
Een architectuurschets, een lijst met endpoints, een overzicht van rollen en rechten. Dit hoeft niet mooi te zijn. Een tekening op een A4 scheelt al een halve dag zoekwerk.
Welke afspraken maak je met mensen?
- Een bereikbare contactpersoon. Iemand die tijdens de testperiode kan schakelen, met een vervanger. Vermijd vakantieperiodes.
- Toestemming van leveranciers. Je hostingpartij, cloudleverancier of de bouwer van je applicatie. Sommige partijen willen vooraf een melding, en zonder die toestemming mag er niet getest worden. Dit is de meest onderschatte vertraging.
- Informeer de beheerorganisatie. Bij een reguliere pentest test je de techniek, niet de alertheid. Als je servicedesk in paniek raakt, verlies je een dag aan opheldering.
- Bepaal wie het rapport krijgt. En in welke vorm. Een technisch rapport voor het team, een samenvatting voor de directie.
Twijfel je nog welke testvorm bij je vraag past, dan hebben we eerder beschreven wat een pentest is, welke types er zijn en wat het kost.
Wat spreek je af voor als het misgaat?
Drie situaties waar je vooraf een antwoord op wilt hebben:
- Een kritieke bevinding. Spreek af dat die direct wordt gemeld en niet tot het rapport wacht. Een actief misbruikbare kwetsbaarheid wil je op dag twee weten, niet drie weken later.
- Onbedoelde uitval. Wie belt wie, en stopt de test dan? Zeldzaam, maar je wilt het niet ter plekke uitzoeken.
- Een echte aanvaller. Het gebeurt dat een tester sporen vindt van iemand anders. Spreek af dat de test dan stopt en dat er wordt opgeschaald naar incidentrespons.
Hoe zorg je dat er iets met het rapport gebeurt?
Dit hoort bij de voorbereiding en niet bij de nazorg, want achteraf is er geen tijd en geen budget meer. Drie afspraken die je nu maakt:
- Plan de bespreking al in. Een sessie waarin de tester zijn bevindingen toelicht, met het team erbij. Een rapport lezen is iets anders dan een aanvalspad uitgelegd krijgen.
- Reserveer capaciteit voor herstel. Als het team volgepland staat, blijven de bevindingen liggen. Houd de weken erna ruimte vrij.
- Zet de hertest in dezelfde opdracht. Met een datum. Zonder hertest weet je alleen dat er iets is opgepakt.
Hoe je van bevindingen naar echte risicoreductie komt, staat in ons artikel over pentestresultaten implementeren. Voor het traject zelf: een pentest laten uitvoeren.
Veelgestelde vragen over de voorbereiding
Hoe lang van tevoren moet ik beginnen?
Reken op twee tot vier weken. Het meeste werk zit in toestemming van leveranciers en het regelen van toegang, en dat loopt langs partijen die hun eigen doorlooptijd hebben.
Moet ik mijn hostingpartij informeren?
Ja, en vaak is voorafgaande toestemming zelfs verplicht. Grote cloudleveranciers hebben hier een eigen procedure voor. Zonder die toestemming kan een test worden geblokkeerd of afgebroken.
Moet ik mijn medewerkers inlichten?
De beheerorganisatie wel, zodat er geen incidentproces wordt opgestart. De rest van de organisatie hoeft het niet te weten, tenzij er social engineering in de scope zit; dan is onwetendheid juist onderdeel van de test.
Wat als de test iets kapotmaakt?
Dat is zeldzaam, en een professionele tester gebruikt geen technieken die uitval veroorzaken zonder overleg. Spreek toch af wie wordt gebeld en of de test dan wordt gepauzeerd. Zorg daarnaast dat je back-up recent en getest is.
Kan ik beter in een testomgeving laten testen?
Dat kan, maar houd er rekening mee dat een testomgeving vaak andere data, andere configuratie en andere rechten heeft. De bevindingen zeggen dan minder over je werkelijke risico.
