Je hebt besloten om een pentest te laten uitvoeren. Misschien vraagt een klant erom, staat er een audit voor de deur of wil je zekerheid voordat een nieuw platform live gaat.
Dan begint het lastigere gedeelte: wat vraag je eigenlijk aan?
Stuur je drie pentestbedrijven alleen een URL met de vraag wat een pentest kost, dan is de kans groot dat je drie offertes ontvangt die nauwelijks met elkaar te vergelijken zijn. De ene partij reserveert drie dagen, de andere een volledige week. Bij de ene offerte is een hertest inbegrepen, bij de andere niet. En soms blijkt pas tijdens het onderzoek dat een belangrijk onderdeel helemaal niet binnen de afgesproken scope valt.
Een goede pentest begint daarom al vóór de eerste testdag.
In dit artikel bekijken we een pentest vanuit de kant van de opdrachtgever. Welke informatie geef je mee bij een aanvraag? Welke afspraken wil je vooraf maken? Hoe vergelijk je offertes? En wat moet geregeld zijn voordat de pentester daadwerkelijk begint?
Begin met de reden waarom je de pentest laat uitvoeren
Een pentest aanvragen begint niet met een lijst IP-adressen of domeinnamen.
Begin met de vraag waarop je na afloop antwoord wilt hebben.
Neem bijvoorbeeld een organisatie die binnenkort een nieuw klantportaal in gebruik neemt. Klanten kunnen daar contracten beheren, documenten downloaden en wijzigingen doorgeven. De organisatie wil vóór livegang weten of het portaal voldoende beveiligd is.
Dat vertelt een pentestbedrijf veel meer dan:
“We willen klantportaal.example.nl laten pentesten.”
De aanleiding geeft namelijk richting aan het onderzoek.
Misschien gaat het om een nieuwe applicatie die vóór livegang onafhankelijk moet worden getest. Misschien vraagt een grote klant om een recent pentestrapport. Of een organisatie wil juist weten wat een externe aanvaller vanaf het internet kan bereiken.
Het doel bepaalt mede hoe de opdracht moet worden ingericht.
Beschrijf daarom bij een aanvraag in een paar zinnen waarom je de pentest wilt laten uitvoeren en wat je na afloop wilt weten.
Welke informatie stuur je mee bij een pentestaanvraag?
Je hoeft zelf geen uitgebreid technisch scopedocument te schrijven.
Wel helpt het wanneer een pentestbedrijf bij de eerste aanvraag voldoende informatie krijgt om een realistische inschatting te maken.
Een aanvraag zou er bijvoorbeeld zo uit kunnen zien:
Omgeving: online klantportaal en achterliggende API
Doel: onafhankelijke beveiligingstest vóór livegang
Testomgeving: acceptatieomgeving, functioneel gelijkwaardig aan productie
Gebruikers: klant, medewerker en beheerder
Planning: onderzoek bij voorkeur vóór 15 november
Bijzonderheden: externe betaalprovider valt buiten scope
Gewenste oplevering: pentestrapport, bespreking van de resultaten en hertest
Dat hoeft nog niet definitief te zijn.
Sterker nog: op basis hiervan hoort een pentestbedrijf waarschijnlijk aanvullende vragen te stellen.
Zijn alle drie de rollen beschikbaar als testaccount? Mag de achterliggende API rechtstreeks worden benaderd? Zijn er onderdelen die vanwege mogelijke verstoring niet getest mogen worden? Is de acceptatieomgeving technisch voldoende vergelijkbaar met productie?
Juist die vragen helpen om van een globale aanvraag een duidelijke opdracht te maken.
Een pentestbedrijf mag best veel vragen stellen
Veel vragen vooraf kunnen misschien omslachtig voelen, maar zijn meestal een goed teken.
Wanneer een leverancier voor een complexe omgeving na één e-mail precies weet hoeveel dagen nodig zijn, is het interessant om te vragen waarop die inschatting is gebaseerd.
Een pentester hoeft niet ieder technisch detail vooraf te kennen. Wel moet duidelijk zijn hoeveel er ongeveer onderzocht moet worden en welke bijzonderheden invloed hebben op de benodigde testtijd.
Denk bijvoorbeeld aan een applicatie waarvan aanvankelijk wordt gezegd dat er twee soorten gebruikers zijn. Tijdens de intake blijkt vervolgens dat er zes rollen bestaan, dat bepaalde klanten aanvullende beheerdersrechten hebben en dat een deel van de functionaliteit alleen via een mobiele app beschikbaar is.
Dat kan de omvang van het onderzoek aanzienlijk veranderen.
Een goede intake voorkomt dat dit soort informatie pas op de eerste testdag naar boven komt.
Maak duidelijk wat wel én niet binnen de opdracht valt
Een goede scope vertelt niet alleen wat wordt getest.
Ook uitsluitingen kunnen belangrijk zijn.
Stel dat een applicatie gebruikmaakt van een externe betaaldienst. Het kan prima zijn dat de koppeling vanuit de eigen applicatie wordt meegenomen, terwijl de systemen van de betaalprovider zelf buiten de pentest vallen.
Of misschien mag een productieomgeving worden onderzocht, maar zijn tests die grote hoeveelheden e-mail, sms-berichten of transacties veroorzaken uitgesloten.
Door dergelijke beperkingen vooraf vast te leggen weet de pentester waar de grenzen liggen.
Dat voorkomt twee problemen: onderdelen worden onbedoeld niet onderzocht óf er worden tests uitgevoerd die de opdrachtgever juist niet had bedoeld.
Hoe vergelijk je verschillende pentestoffertes?
Dit is vaak lastiger dan het lijkt.
Stel dat je twee voorstellen ontvangt:
| Offerte A | Offerte B | |
|---|---|---|
| Opdracht | Webapplicatie pentest | Webapplicatie pentest |
| Doorlooptijd | 3 testdagen | 5 testdagen |
| Gebruikersrollen | Niet gespecificeerd | 3 rollen opgenomen |
| Achterliggende API | Niet benoemd | Expliciet binnen scope |
| Rapportage | Inbegrepen | Inbegrepen |
| Bespreking resultaten | Niet benoemd | Inbegrepen |
| Hertest | Optioneel | Inbegrepen |
Welke offerte is beter?
Op basis van deze informatie kun je dat nog steeds niet met zekerheid zeggen.
Misschien heeft partij A tijdens een intake al vastgesteld dat drie dagen ruim voldoende is. Misschien heeft partij B bewust meer tijd opgenomen omdat de API afzonderlijk wordt onderzocht. En misschien gebruikt iedere leverancier een andere manier om rapportage-uren in de prijs te verwerken.
Het verschil zit daarom niet alleen in het bedrag onderaan de offerte.
Je wilt vooral begrijpen wat je voor dat bedrag laat onderzoeken.
Vraag bij onduidelijkheid dus gerust waarom een leverancier een bepaald aantal testdagen adviseert en welke onderdelen daarin worden meegenomen.
Wil je specifiek weten welke bedragen gebruikelijk zijn? In ons artikel over pentest kosten gaan we uitgebreider in op prijsverschillen en realistische bandbreedtes.
Kijk niet alleen naar het aantal testdagen
Ook het aantal dagen kan misleidend zijn.
Bij de ene leverancier betekent vijf dagen dat een pentester vijf dagen technisch onderzoek uitvoert en de rapportage apart wordt begroot. Bij een andere leverancier zijn intake, onderzoek en rapportage allemaal onderdeel van diezelfde vijf dagen.
Vraag daarom wat met een term als testdagen, consultancydagen of pentestdagen wordt bedoeld.
Dat klinkt misschien als een detail, maar het maakt een groot verschil wanneer je offertes naast elkaar legt.
Hetzelfde geldt voor een hertest.
“Inclusief hertest” kan betekenen dat alle gerapporteerde bevindingen binnen een bepaalde periode opnieuw worden gecontroleerd. Maar het kan ook gaan om een beperkt aantal uren of alleen bevindingen vanaf een bepaalde risicocategorie.
Een paar aanvullende vragen vooraf maken een offerte daardoor vaak een stuk duidelijker.
Welke vragen kun je aan een pentestbedrijf stellen?
Je hoeft een pentester niet te ondervragen over ieder commando dat tijdens het onderzoek wordt uitgevoerd.
Voor een opdrachtgever zijn andere vragen meestal veel nuttiger.
Wat valt expliciet niet binnen deze offerte?
Dit is misschien wel een van de nuttigste vragen.
Je weet dan niet alleen wat je koopt, maar ook wat je níét koopt.
Dat is vooral belangrijk wanneer verschillende systemen, omgevingen of leveranciers met elkaar verbonden zijn.
Hoe zijn jullie tot deze testinspanning gekomen?
Een pentestbedrijf moet kunnen uitleggen waarom bijvoorbeeld drie, vijf of acht dagen nodig worden geacht.
Dat hoeft geen urenverantwoording per functionaliteit te zijn. Een globale onderbouwing geeft al veel inzicht.
Wat hebben jullie vóór de eerste testdag van ons nodig?
Denk aan accounts, toegang tot een testomgeving, IP-whitelisting of contactgegevens.
Hoe eerder dat duidelijk is, hoe kleiner de kans dat kostbare testtijd verloren gaat aan praktische problemen.
Hoe worden ernstige bevindingen tijdens het onderzoek gemeld?
Stel dat op de tweede testdag een ernstig probleem wordt ontdekt.
Dan wil je niet wachten tot het definitieve rapport een week later wordt opgeleverd.
Spreek daarom af wie tijdens het onderzoek bereikbaar is en wanneer een bevinding direct wordt geëscaleerd.
Kunnen we na oplevering vragen stellen over bevindingen?
Een ontwikkelaar kan bij het oplossen van een kwetsbaarheid aanvullende technische vragen hebben.
Het is prettig om vooraf te weten of dergelijke vragen onderdeel zijn van de opdracht.
Hoe werkt de hertest?
Vraag binnen welke termijn de hertest moet plaatsvinden, welke bevindingen opnieuw worden onderzocht en of daar aanvullende kosten aan verbonden zijn.
Hoe wordt met onze informatie omgegaan?
Een pentester kan tijdens een onderzoek gevoelige technische informatie tegenkomen.
Vraag daarom hoe testdata, screenshots, exports en andere onderzoeksinformatie worden opgeslagen en wanneer deze worden verwijderd.
Hoe ontvangen we het rapport?
Ook dit wordt makkelijk vergeten.
Een pentestrapport bevat informatie die je juist niet publiek beschikbaar wilt hebben. Het document kan technische details bevatten over kwetsbaarheden, interne systemen en mogelijke aanvalspaden.
Het is daarom redelijk om te vragen hoe het rapport beveiligd wordt aangeleverd en wie er toegang toe krijgt.
Zorg dat de omgeving klaarstaat vóór de test begint
Een pentester die op maandagochtend ontdekt dat zijn testaccount nog moet worden aangevraagd, kan weinig beginnen.
Toch zijn het vaak eenvoudige praktische zaken die bij de start voor vertraging zorgen.
Controleer daarom vooraf of:
- afgesproken testaccounts werken;
- eventuele MFA-toegang is geregeld;
- IP-adressen zijn toegevoegd aan de whitelist;
- de testomgeving bereikbaar is;
- relevante functionaliteit beschikbaar is;
- voldoende representatieve testdata aanwezig is;
- eventuele externe leveranciers zijn geïnformeerd;
- de juiste contactpersonen bereikbaar zijn.
Niet alles is bij iedere pentest van toepassing.
Het belangrijkste is dat randvoorwaarden die wél nodig zijn vóór de afgesproken startdatum zijn geregeld.
Een uur voorbereiding kan voorkomen dat een halve testdag verloren gaat.
Spreek af wat er gebeurt als de omgeving niet beschikbaar is
Een pentest wordt vaak weken van tevoren ingepland.
Wanneer op de eerste testdag blijkt dat de testomgeving niet bereikbaar is, een belangrijke functionaliteit defect is of accounts niet werken, ontstaat een praktisch probleem.
De pentester heeft die tijd immers gereserveerd.
Bespreek daarom vooraf hoe met vertraging aan de kant van de opdrachtgever wordt omgegaan.
Kan de test worden verschoven?
Kan ondertussen een ander onderdeel worden onderzocht?
Wordt niet-benutte tijd opnieuw ingepland?
Hier bestaat geen universeel juiste regeling voor. Het belangrijkste is dat beide partijen vooraf weten wat de afspraken zijn.
Bepaal wie tijdens de pentest bereikbaar is
Tijdens een goed voorbereide pentest hoeft de opdrachtgever niet voortdurend naast de telefoon te zitten.
Wel is het verstandig om minimaal één technisch of functioneel contactpersoon beschikbaar te hebben.
Soms ontstaat tijdens het onderzoek namelijk een vraag die vooraf moeilijk te voorzien was.
Is bepaald gedrag onderdeel van de applicatie of een fout? Mag een specifieke actie veilig worden uitgevoerd? Hoort een gevonden systeem bij de organisatie? Is het toegestaan om een bepaalde koppeling verder te onderzoeken?
Een snel antwoord kan voorkomen dat een pentester een relevant onderzoekspad moet laten liggen.
Daarnaast is het verstandig om een escalatiecontact aan te wijzen voor ernstige bevindingen.
Dat hoeft niet dezelfde persoon te zijn.
Wat als tijdens het onderzoek iets buiten de scope wordt gevonden?
Een pentester kan tijdens een onderzoek iets tegenkomen dat niet letterlijk in de afgesproken scope staat.
Bijvoorbeeld een onverwacht subdomein, een oude omgeving of een koppeling met een ander systeem.
Dat betekent niet automatisch dat de pentester dat systeem verder mag onderzoeken.
Juist daarom is het verstandig om vooraf af te spreken hoe met dergelijke situaties wordt omgegaan.
De pentester kan de ontdekking melden en samen met de opdrachtgever bepalen of verder onderzoek gewenst en toegestaan is.
Zo voorkom je dat een mogelijk relevant risico wordt genegeerd, zonder dat de afgesproken grenzen van het onderzoek zomaar worden overschreden.
Kun je tijdens de pentest al kwetsbaarheden oplossen?
Ja, maar stem dit bij voorkeur af.
Wanneer een ernstig probleem wordt gevonden, kan het logisch zijn om direct maatregelen te nemen.
Bij minder urgente bevindingen kan voortdurend aanpassen van de omgeving het onderzoek juist lastiger maken. De pentester test dan gedurende de week telkens een iets andere versie van het systeem.
Een praktische aanpak is om urgente problemen direct te bespreken en overige wijzigingen waar mogelijk te bundelen tot na de eerste testronde.
Daarna kan tijdens de hertest worden gecontroleerd of de gekozen oplossingen daadwerkelijk effectief zijn.
Het rapport is niet het einde van de opdracht
Na de laatste testdag volgt het rapport.
Daarmee is de technische test afgerond, maar voor de organisatie begint dan juist het belangrijkste deel: bepalen wat met de bevindingen gebeurt.
Niet iedere bevinding hoeft dezelfde prioriteit te krijgen.
Sommige problemen kunnen direct worden opgelost. Andere vragen om een wijziging in architectuur, leverancier of proces. Soms besluit een organisatie bewust een risico tijdelijk te accepteren.
Het helpt daarom om vooraf al duidelijk te hebben wie verantwoordelijk wordt voor de opvolging.
Bij een applicatie kan dat bijvoorbeeld een product owner of developmentteam zijn. Bij infrastructuur kan de verantwoordelijkheid elders liggen.
Een gezamenlijke bespreking van het rapport helpt daarbij. Technische teams kunnen vragen stellen en management kan bepalen welke risico’s als eerste aandacht nodig hebben.
Na het doorvoeren van maatregelen kan een hertest vervolgens vaststellen welke gerapporteerde bevindingen daadwerkelijk zijn verholpen.
Behandel het pentestrapport als vertrouwelijke informatie
Een pentestrapport is geen gewone projectdocumentatie.
Het kan precies beschrijven waar zwakke plekken aanwezig zijn, welke systemen worden gebruikt en onder welke omstandigheden een kwetsbaarheid kan worden misbruikt.
Denk daarom ook na over de verspreiding van het rapport.
Moet iedereen binnen de organisatie het volledige technische rapport ontvangen? Of hebben sommige betrokkenen voldoende aan een managementsamenvatting?
Wanneer een externe klant om bewijs van een uitgevoerde pentest vraagt, hoeft dat bovendien niet automatisch te betekenen dat het volledige rapport moet worden verstrekt.
Afhankelijk van de situatie kan een managementsamenvatting, verklaring of een versie met beperkte technische details voldoende zijn.
Beperk toegang tot het volledige rapport tot mensen die deze informatie daadwerkelijk nodig hebben en gebruik een passende methode voor het delen en bewaren ervan.
Wanneer is de pentest afgerond?
Niet wanneer de PDF in je mailbox verschijnt.
Een logisch traject ziet er eerder zo uit:
opdracht afbakenen → pentest uitvoeren → resultaten bespreken → bevindingen oplossen → hertest uitvoeren → resterende risico’s beoordelen
Pas daarna heb je niet alleen laten onderzoeken waar problemen zitten, maar ook vastgesteld wat ermee is gebeurd.
Dat maakt een pentest veel waardevoller dan een rapport dat uitsluitend wordt opgeslagen omdat een klant of auditor erom vroeg.
Een pentest laten uitvoeren begint met een goede opdracht
Wie een pentest wil laten uitvoeren hoeft vooraf niet alle technische antwoorden te hebben.
Dat is juist een van de redenen om een gespecialiseerde partij in te schakelen.
Wel helpt het enorm wanneer duidelijk is waarom je de pentest laat uitvoeren, welke omgeving centraal staat en wat je na afloop wilt weten.
Een pentestbedrijf kan vervolgens helpen om daar een passende scope en planning van te maken.
Vergelijk offertes daarom niet uitsluitend op het totaalbedrag. Kijk naar wat daadwerkelijk wordt onderzocht, welke afspraken rondom uitvoering en oplevering zijn gemaakt en of duidelijk is wat er van jouw organisatie wordt verwacht.
Een goed voorbereide opdracht voorkomt verrassingen tijdens het onderzoek en zorgt ervoor dat de beschikbare testtijd terechtkomt waar deze het meeste waarde oplevert.
Pentest laten uitvoeren door Securitytest.nl
Wil je een pentest laten uitvoeren en weet je nog niet precies hoe je de opdracht moet afbakenen?
Securitytest.nl voert pentests uit op onder andere webapplicaties, API’s, cloudomgevingen en netwerken. Tijdens een korte intake bespreken we wat je wilt laten onderzoeken en welke aanpak daarbij past.
Je ontvangt vervolgens een voorstel waarin de scope, testinspanning en oplevering duidelijk zijn vastgelegd.
Neem contact op voor een vrijblijvende intake.