Een pentest voorbereiden: checklist voor uw team

Waarom voorbereiding testtijd bespaart

Een pentest wordt ingekocht in testdagen. Elk uur dat de tester wacht op een account, een VPN-toegang of een antwoord, gaat af van de tijd waarin er echt getest wordt. Bij een meerdaagse test is dat vervelend. Bij een test van één of twee dagen kan het een flink deel van de dekking kosten.

Voorbereiding bepaalt ook hoe diep de test gaat. Een tester met maar één account kan niet controleren of gebruiker A bij de gegevens van gebruiker B kan komen. En juist dat soort autorisatiefouten staat al jaren bovenaan de OWASP Top 10. Wie de toegang goed regelt, krijgt een test die verder komt dan de voordeur.

Zo verloopt een pentest, vanaf het eerste contact

Voor elke meerdaagse penetratietest is het traject hetzelfde. De Launch Check boekt u direct online en heeft een eigen, kortere route.

1. Reactie binnen één werkdag

   U neemt contact op

   Via het contactformulier, per e-mail of door direct een intake in te plannen. Een paar zinnen over uw applicatie en de aanleiding zijn genoeg. Heeft u een deadline, zoals een audit of een klant die op een rapport wacht, noem die dan meteen. Dat bepaalt de planning.

2. Dag 1

   Gratis intake van 30 minuten

   We bespreken wat er getest moet worden, waarom, en wat buiten scope blijft. Denk aan: welke applicaties en omgevingen, welke gebruikersrollen er zijn, hoe inloggen werkt en voor wie het rapport bedoeld is. Na de intake weet u of en hoe ik u kan helpen, ook als het antwoord is dat u op dit moment geen pentest nodig heeft.

3. Dag 2–3

   Offerte met vaste prijs

   U ontvangt een offerte met de scope, de planning en een vaste prijs, met de hertest inbegrepen. Voordat er technische details worden gedeeld, tekenen we een NDA.

4. Tussen akkoord en start

   Voorbereiding

   Na akkoord plannen we de start, meestal binnen één tot twee weken. In die tijd regelt uw team de punten uit de checklist hieronder: scope, toegang, testaccounts, toestemming en afspraken.

5. Week 1–2

   De test

   Ik test handmatig, binnen de afgesproken scope en testvensters. U heeft in die periode direct contact met mij, zonder accountmanager ertussen. Vind ik iets kritieks, zoals een lek waardoor klantgegevens voor buitenstaanders op te vragen zijn, dan meld ik dat direct en niet pas in het rapport.

6. Einde week 2

   Het rapport

   U ontvangt een rapport met een managementsamenvatting en technische bevindingen met reproductiestappen, geprioriteerd op impact en uitbuitbaarheid. Het rapport is digitaal ondertekend, zodat u, een klant of een auditor zelf kan controleren of het echt is. Vragen over een bevinding stelt u rechtstreeks aan de tester. Benieuwd hoe zo'n rapport eruitziet? Bekijk het voorbeeld-pentestrapport.

7. Na patching

   Herstel en hertest

   Uw team lost de bevindingen op. Daarna test ik opnieuw of dat gelukt is, en sluit u af met een hertestverklaring die u kunt gebruiken richting klanten, bestuur of toezichthouder. De hertest zit in de prijs.

Van intake tot rapport duurt een meerdaagse pentest doorgaans één tot drie weken, afhankelijk van de scope. Voor grote of complexe omgevingen loopt dat op naar vier à vijf weken. Na de intake ontvangt u een exacte planning.

De checklist voor uw team

Onderstaande punten regelt u tussen akkoord en start. Niet alles is op elke test van toepassing. Twijfelt u over een punt, dan bespreken we het in de intake.

1. Scope en doel

• Welke systemen precies. URL's, API's, IP-adressen of IP-ranges. "Onze webapplicatie" is te vaag. "app.voorbeeld.nl en de API op api.voorbeeld.nl" is een scope.
• Wat buiten scope valt. Denk aan systemen van derden, zoals een betaalprovider, een e-maildienst of een extern klantportaal. Die test ik niet zonder toestemming van de eigenaar.
• De aanleiding. Een audit, een klant, een release of een incident. De aanleiding bepaalt waar de nadruk ligt en voor wie het rapport geschreven wordt.
• Documentatie die er al is. Een OpenAPI- of Swagger-specificatie, een Postman-collectie of een korte uitleg van de rollen. U hoeft niets speciaal te schrijven: wat er is, helpt al.

2. Toegang en testaccounts

• Minstens twee accounts per rol. Met twee accounts van dezelfde rol test ik of gebruikers bij elkaars gegevens kunnen. Met één account kan dat niet.
• Accounts bij twee tenants bij multi-tenant software. Het grootste risico van een SaaS-platform is dat klant A de data van klant B ziet. Dat is alleen te testen met accounts bij twee verschillende klantomgevingen.
• Accounts die werken op dag 1. Log de dag ervoor zelf in met elk testaccount. Een verlopen wachtwoord of een account dat nog geactiveerd moet worden, kost al snel een halve testdag.
• MFA zoals in productie. Laat multifactor-authenticatie aan staan zoals uw echte gebruikers die hebben, en spreek af hoe ik de codes ontvang. Staat MFA uit op de testaccounts, dan test ik een situatie die in het echt niet bestaat.
• Wachtwoorden veilig delen. Niet in dezelfde e-mail als de gebruikersnaam en niet in een ticket. We spreken in de intake een veilige route af.
• VPN, IP-filter of WAF. Staat de applicatie achter een VPN of een IP-filter, regel dan vooraf toegang voor mijn test-IP-adres. Bij een WAF maakt u een bewuste keuze: wilt u weten hoe de applicatie zelf reageert, zet het test-IP dan op de allowlist. Wilt u weten wat de WAF tegenhoudt, laat hem dan aan.

3. De omgeving: productie of acceptatie?

Beide kunnen, maar het is een keuze die u vooraf maakt en niet tijdens de test.

Test u op acceptatie, zorg dan dat daar geen echte persoonsgegevens in staan. Dat is onder de AVG sowieso verstandig. Test u op productie, maak dan vooraf een back-up en spreek af welke acties niet mogen, zoals e-mails versturen naar echte klanten of echte bestellingen plaatsen.

4. Toestemming en afspraken

• Schriftelijke toestemming. Binnendringen in systemen zonder toestemming van de eigenaar is computervredebreuk, ook als het goed bedoeld is. Leg daarom schriftelijk vast wat getest mag worden, door wie en wanneer. Wordt uw applicatie gehost of beheerd door een externe partij, dan heeft u mogelijk ook hún toestemming nodig.
• Cloudplatforms. Bij AWS, Microsoft Azure en Google Cloud is voor de meeste diensten geen voorafgaande toestemming nodig, maar er gelden wel testregels. Bij een beheerde hostingpartij ligt dat vaak anders. Vraag het na.
• Testvensters. Mag er overdag getest worden, of alleen buiten kantoortijden? Zijn er momenten waarop het echt niet uitkomt, zoals een release of een piek in gebruik?
• Wat niet mag. Denial-of-service hoort niet bij een reguliere pentest. Spreek daarnaast af of er data gewijzigd of verwijderd mag worden, en hoe er wordt omgegaan met functies die e-mails, sms'jes of betalingen in gang zetten.

5. Mensen en communicatie

• Eén aanspreekpunt. Iemand die vragen snel kan beantwoorden of doorzetten, en die tijdens de testdagen bereikbaar is.
• Een technisch contact. Een ontwikkelaar of beheerder die weet hoe de applicatie in elkaar zit. Vijf minuten uitleg bespaart soms uren zoeken.
• Informeer uw beheer, SOC of hostingpartij. Anders ziet een pentest eruit als een echte aanval, met een geblokkeerd IP-adres of een incidentmelding als gevolg. Wilt u juist testen of uw detectie werkt, dan is dat een bewuste keuze die we vooraf afspreken.
• Een telefoonnummer voor noodgevallen. Voor het zeldzame geval dat er iets misgaat, of dat er een kritieke bevinding is die niet kan wachten.

6. Na de test

• Plan capaciteit voor herstel. Een rapport zonder tijd om te patchen blijft liggen. Reserveer ontwikkeltijd in de weken na oplevering.
• Bepaal wie het rapport leest. De managementsamenvatting is voor bestuur en klanten, de technische bevindingen zijn voor het team dat gaat patchen.
• Plan de hertest. Hoe eerder u herstelt, hoe eerder u een hertestverklaring heeft voor de klant of auditor die erom vraagt.

Wat u níet hoeft te doen

Voorbereiding is geen project op zich. Een paar dingen die u gerust kunt laten:

• Eerst alles oplossen. Een pentest is geen examen waarvoor u moet slagen. Bekende problemen kunt u vooraf melden. Dan gaat de testtijd naar wat u nog niet weet.
• Zelf eerst een scanner draaien. Het mag, maar het is geen voorwaarde. De handmatige test richt zich op wat een scanner niet vindt: logica, autorisatie en combinaties van kleine zwaktes.
• Documentatie schrijven. Wat er al is, is genoeg. Ontbreekt er iets, dan vraag ik het in een kort gesprek.
• De planning van uw team omgooien. Afgezien van een aanspreekpunt en een technisch contact merkt uw team weinig van de test.

Conclusie

Een goede pentest begint met een goede voorbereiding, en die is minder werk dan het lijkt. Een heldere scope, werkende testaccounts voor elke rol, een bewuste keuze voor de omgeving, schriftelijke toestemming en één aanspreekpunt: daarmee is het grootste deel geregeld. Het resultaat is een test waarin elke dag een testdag is, en een rapport dat dieper gaat dan de voordeur. Twijfelt u over een van de punten? In een gratis intake lopen we ze samen door.