Pentest-voorbereiding — wat je moet regelen voordat iemand je netwerk mag hacken

Er is iets fundamenteel grappigs aan het concept penetratietesten. Je betaalt iemand — soms behoorlijk veel geld — om in te breken in je eigen systemen. Het is alsof je een inbreker inhuurt om te controleren of je sloten goed genoeg zijn, behalve dat je hem ook nog een kopje koffie aanbiedt en een parkeerplaats reserveert. Welkom in de wondere wereld van offensieve beveiliging.

Waarom je niet zomaar kunt beginnen

Het allereerste wat je moet begrijpen over pentesting is dat je niet zomaar iemand op je netwerk kunt loslaten met de instructie "doe maar alsof je een hacker bent." Dat zou vergelijkbaar zijn met het testen van de brandveiligheid van je kantoor door het daadwerkelijk in de fik te steken. Technisch gezien krijg je dan wel antwoord op je vraag, maar de bijeffecten zijn onwenselijk.

Een goede pentest begint weken — soms maanden — voordat er ook maar één poort gescand wordt. En dat is geen bureaucratie om de bureaucratie. Het is het verschil tussen een gecontroleerd experiment en een ramp.

Scope: wat mag er getest worden?

De scope is het allerbelangrijkste document van de hele exercitie. Het definieert precies wat er wel en niet getest mag worden. En geloof me, je wilt dit heel precies hebben.

Stel je voor dat je een pentest laat uitvoeren op je webapplicatie, maar de pentester vindt een kwetsbaarheid in je mailserver en besluit die ook maar even mee te nemen. Vervolgens crasht je mailserver, je CEO mist een kritieke e-mail, en jij mag uitleggen waarom je de baas z'n inbox hebt laten hacken terwijl het daar helemaal niet om ging. Scope creep is niet alleen vervelend bij softwareprojecten.

Wat hoort er in de scope?

• IP-ranges en domeinen — welke systemen mogen worden aangevallen
• Applicaties — welke webapplicaties, API's en mobiele apps in scope zijn
• Testmethoden — is social engineering toegestaan? Fysieke toegang? DDoS?
• Tijdvensters — wanneer mag er getest worden (niet op Black Friday, alsjeblieft)
• Uitgesloten systemen — productiesystemen die je écht niet wilt laten crashen
• Contactpersonen — wie bel je als je per ongeluk iets omver gooit

Rules of Engagement: de spelregels

De Rules of Engagement (RoE) zijn de spelregels van je pentest. Ze beschrijven niet alleen wat er getest wordt, maar ook hoe. Dit is het moment waarop je beslist of dit een gentleman's test wordt of een full-contact vechtpartij.

Er zijn grofweg drie smaken:

Black box — de pentester weet niets. Geen documentatie, geen credentials, geen netwerktekeningen. Net als een echte aanvaller. Dit is de meest realistische test, maar ook de duurste, want de pentester besteedt een flink deel van zijn tijd aan het uitzoeken van dingen die jij hem gewoon had kunnen vertellen.

White box — de pentester weet alles. Broncode, architectuurtekeningen, credentials, de naam van je huisdier. Dit is de meest grondige test, want er wordt geen tijd verspild aan verkenning. Het nadeel is dat het minder realistisch is — een echte aanvaller heeft al die informatie niet.

Grey box — ergens ertussenin. De pentester krijgt beperkte informatie, zoals een gebruikersaccount en wat basisdocumentatie. Dit is de populairste optie, en terecht — het combineert realisme met efficiëntie.

Het juridische stuk (ja, dat moet echt)

Hier wordt het serieus. Een penetratietest is technisch gezien een computermisdrijf. Artikel 138ab van het Wetboek van Strafrecht verbiedt het binnendringen in computersystemen, en "maar ik had toestemming" is alleen een geldige verdediging als je die toestemming schriftelijk hebt.

Je hebt minimaal nodig:

• Een getekende opdrachtbevestiging — ondertekend door iemand die daadwerkelijk bevoegd is om toestemming te geven (hint: dat is niet de stagiair)
• Een "get out of jail free" letter — een formele autorisatie die de pentester vrijwaart van strafrechtelijke vervolging
• Een geheimhoudingsverklaring (NDA) — want de pentester gaat mogelijk zeer gevoelige informatie tegenkomen
• Aansprakelijkheidsbeperkingen — wat als er iets stuk gaat? Spoiler: dat gebeurt soms

Als je met cloudproviders werkt, heb je vaak óók hun toestemming nodig. AWS, Azure en Google Cloud hebben allemaal hun eigen procedures voor het aanmelden van pentests. Want als jouw pentester een poort begint te scannen op een AWS IP-adres zonder dit te melden, kan Amazon besluiten dat er een aanval gaande is en je hele omgeving afsluiten. Dat is niet het soort pentest-resultaat dat je wilt rapporteren.

Voorbereiding: de checklist

Voordat de pentester aan de slag gaat, moet je als organisatie een aantal zaken op orde hebben:

1. Backups controleren — zorg dat je recente, werkende backups hebt van alle systemen in scope. Niet "we denken dat er backups zijn." Getest, geverifieerd, werkend.
2. Monitoring aanzetten — dit is een uitgelezen kans om te testen of je SOC de aanval detecteert. Zet je logging op scherp.
3. Stakeholders informeren — de juiste mensen moeten weten dat er een test plaatsvindt. Niet iedereen, want dan verlies je het realisme, maar wel het management en de IT-afdeling.
4. Escalatieprocedure afspreken — wie belt wie als er iets mis gaat? Om twee uur 's nachts? Op een zondag?
5. Succescriteria definiëren — wat wil je leren? "Zijn we veilig?" is geen goed criterium. "Kan een aanvaller met externe toegang binnen 48 uur bij klantgegevens komen?" is dat wel.

Na de test: wat doe je met de resultaten?

Een pentestrapport dat in een la verdwijnt is weggegooid geld. En dat is vaker de realiteit dan je zou denken. Uit onderzoek blijkt dat ongeveer 40% van de bevindingen uit pentests een jaar later nog steeds niet is opgelost.

Het rapport moet leiden tot een concreet actieplan met eigenaren, deadlines en prioriteiten. Kritieke bevindingen moeten binnen dagen worden opgelost, niet binnen kwartalen. En na de fix hoort er een hertest te volgen om te verifiëren dat de kwetsbaarheid daadwerkelijk is verholpen — niet alleen anders is gemaakt.

Een pentest is geen eindpunt. Het is een momentopname. Je beveiliging van vandaag zegt niets over je beveiliging van volgende maand, als er nieuwe code is gedeployd, nieuwe systemen zijn toegevoegd, of nieuwe kwetsbaarheden zijn ontdekt. De beste organisaties testen regelmatig — niet omdat ze onzeker zijn, maar omdat ze weten dat beveiliging een continu proces is.