Blackbox, greybox of whitebox pentest: welke vorm past bij je vraag?

TL;DR

• Het verschil zit in wat de tester vooraf weet: alleen het doelwit (blackbox), beperkte kennis zoals een testaccount en documentatie (greybox), of alles inclusief architectuur en broncode (whitebox).
• Blackbox geeft het meest realistische beeld van een aanvaller van buiten. Het kost ook de meeste tijd aan verkennen.
• Greybox is de gebruikelijke keuze voor webapplicaties en API's met een login: diepgang achter de login zonder alles uit handen te geven.
• Whitebox geeft de hoogste zekerheid en beantwoordt architectuurvragen. Het vraagt de meeste voorbereiding van je team.
• Kies de vorm op basis van de vraag die je beantwoord wilt zien, niet op basis van hoe stoer ze klinkt.

Bij elk pentestvoorstel komt vroeg dezelfde vraag: hoeveel vertellen we de testers vooraf? Het antwoord bepaalt de vorm van de test, en het bepaalt wat het rapport je wel en niet kan vertellen. De drie vormen zijn genoemd naar wat de tester ziet. Blackbox: de tester start met het doelwit en verder niets. Greybox: beperkte kennis, meestal een testaccount en wat documentatie. Whitebox: volledige kennis, met architectuurschema's, broncode en configuratie. Bij een pentest van Sectricity verloopt elke vorm langs dezelfde weg: AI-ondersteunde verkenning, manueel testen door ethische hackers, validatie van elke bevinding en een retest nadat je hebt hersteld. Moet de test dienen voor een audit onder NIS2, ISO 27001, DORA of GDPR, dan voegt de auditklare pentest daar een compliancemapping en een attestatieverklaring aan toe. De vorm van de test verandert daar niets aan. Ze verandert waar de testers beginnen en hoe ver ze komen.

Wat de tester vooraf weet

Blackbox: de tester kent het doelwit. Een domeinnaam, een reeks IP-adressen, een app in de store. Al de rest komt uit verkenning: wat is bereikbaar, welke software draait er, waar zitten de invoervelden. De tester gedraagt zich als een buitenstaander die je op het internet heeft gevonden en tijd heeft.

Greybox: de tester krijgt wat hulp. Meestal een testaccount per gebruikersrol, een korte uitleg van wat de applicatie doet, soms API-documentatie of een netwerkschema. De zwakke plekken moet de tester nog altijd zelf vinden, maar hij verliest geen dagen met raden welk deel van de app ertoe doet.

Whitebox: de tester ziet wat je eigen ontwikkelaars zien. Broncode, architectuur, configuratie van de infrastructuur, soms een testomgeving met debuglogging aan. Verkennen kost dan weinig tijd. Bijna alle uren gaan naar analyse: hoe grijpen de onderdelen in elkaar en waar breekt dat.

De namen komen van de kleur van de doos waar de tester naar kijkt: ondoorzichtig, halfdoorzichtig, volledig doorzichtig. Wat de tester eenmaal binnen mag doen, volgt uit de scope die je afspreekt, los van de kleur.

De drie afwegingen

Tijd voor verkennen tegenover diepgang. Een tester heeft een vast aantal dagen. Bij blackbox gaat een flink deel daarvan naar uitzoeken wat er staat. Bij whitebox is dat deel bijna gratis, dus gaan dezelfde dagen naar diepgang: bedrijfslogica, autorisatie tussen rollen, het stuk code waar sinds de eerste release niemand meer naar keek. Geen van beide is fout. Ze beantwoorden een andere vraag.

Realisme tegenover dekking. Blackbox komt het dichtst bij een echte aanvaller van buiten, en dat is een sterk argument als de directie of een verzekeraar vraagt wat iemand nu echt zou vinden. De prijs is dekking: wat de tester in de beschikbare tijd niet vindt, blijft ongetest, en een rapport kan niet opsommen wat het niet zag. Whitebox draait dat om. De dekking is hoog, het realisme lager, want een echte aanvaller heeft zelden je broncode. Greybox zit ertussen en is daar eerlijk over.

Wat je team aanlevert. Blackbox vraagt bijna niets van jou, buiten een ondertekende toelating en een contactpersoon voor noodgevallen. Greybox vraagt testaccounts, een rondleiding door de applicatie en iemand die tijdens de test vragen beantwoordt. Whitebox vraagt toegang tot code, architectuurdocumenten en tijd van ontwikkelaars. Die voorbereiding beslist in de praktijk vaak de keuze: een team dat geen ontwikkelaar een week kan vrijmaken, is beter af met een goed voorbereide greyboxtest dan met een whiteboxtest die niemand ondersteunt.

Welke vorm past bij welke vraag

Is je vraag "wat ziet een buitenstaander en hoe ver komt hij?", kies dan blackbox. Typisch voor de buitenkant van je netwerk, een publieke website zonder login, of een eerste test van een organisatie die nog nooit getest is. Werkt ook als controle na een grote migratie.

Is je vraag "is onze applicatie veilig voor ingelogde gebruikers en voor de data achter de login?", kies dan greybox. Dat dekt de meeste webapplicaties en API's. Autorisatiefouten tussen gebruikersrollen, onveilige directe verwijzingen naar objecten en logicafouten in flows zoals afrekenen of wachtwoord herstellen komen pas boven als de tester kan inloggen. Een blackboxtest zou zijn dagen voor de deur doorbrengen. Hoe zo'n test er in de praktijk uitziet, beschreven we eerder in onze post over penetratietesten van webapplicaties.

Is je vraag "hoe zeker willen we zijn?" of "klopt deze architectuur?", kies dan whitebox. Typisch voor een productlancering, na een incident, voor software die je aan andere bedrijven verkoopt, of wanneer een auditor bewijs wil dat een specifieke set controles werkt. Ook de juiste vorm als je de code wilt laten bekijken naast de draaiende applicatie.

Onze mening, voor wat ze waard is: de meeste organisaties die voor een eerste test bij ons komen, vragen blackbox omdat dat het meest op een echte aanval lijkt, en vertrekken met een greyboxvoorstel omdat dat hun eigenlijke vraag beantwoordt. Daar is niets mis mee. De aanvaller die er voor een webapplicatie het meest toe doet, heeft meestal al een account.

Vormen combineren in een opdracht

De drie sluiten elkaar niet uit. Een veelgebruikt patroon is een korte blackboxfase voor het beeld van buiten, gevolgd door greybox achter de login. Een ander is greybox op de applicatie plus whitebox op een kritiek onderdeel, zoals de authenticatiemodule. De rest van het scopegesprek staat in onze checklist voor een pentest en in de post over wat een pentest is. Wat niet verandert per vorm: elke bevinding wordt door een mens gevalideerd, kritieke en hoge bevindingen melden we tijdens de test en niet pas in het eindrapport, en de retest na je herstel hoort bij de opdracht.

Veelgestelde vragen

Wat is het verschil tussen een blackbox, greybox en whitebox pentest?

De hoeveelheid kennis die de tester vooraf heeft. Blackbox: alleen het doelwit. Greybox: beperkte kennis, zoals een testaccount en documentatie. Whitebox: volledige kennis, inclusief architectuur en broncode.

Is een blackbox pentest realistischer?

Voor een aanvaller van buiten zonder voorkennis wel. Voor een aanvaller die al een account heeft, of een insider, zit een greyboxtest dichter bij de werkelijkheid. Realisme hangt af van de aanvaller waar je je zorgen over maakt.

Welke pentestvorm past het best bij een webapplicatie of API?

Meestal greybox. Met een testaccount per gebruikersrol kan de tester autorisatie en bedrijfslogica achter de login controleren, en daar zitten de meeste ernstige bevindingen in webapplicaties. Zie onze pentest voor webapplicaties.

Duurt een whitebox pentest langer?

Niet per se. Er gaat minder tijd naar verkennen en meer naar analyse. Wat wel meer vraagt, is de voorbereiding aan jouw kant: toegang tot code, architectuurdocumenten en een ontwikkelaar die vragen beantwoordt.

Welke vorm verwachten auditors voor NIS2 of ISO 27001?

De kaders vragen testen in verhouding tot het risico, geen specifieke vorm. Wat auditors willen zien is een ondertekend rapport met scope, methode, bevindingen en bewijs van herstel. Onze auditklare pentest koppelt de bevindingen aan het kader, welke testvorm je ook kiest.

Wat moeten we klaarzetten voor een greybox pentest?

Testaccounts per gebruikersrol, een korte rondleiding door de applicatie, de API-documentatie die je hebt, en een contactpersoon die tijdens de test vragen kan beantwoorden.

Gerelateerde diensten en bronnen

Begin bij ons aanbod penetratietesten voor de aanpak, en bij de auditklare pentest als het rapport moet dienen voor NIS2, ISO 27001, DORA of GDPR. Voor greyboxwerk op applicaties bekijk je de pentest voor webapplicaties en de API-pentest. Achtergrond lees je in wat een pentest is, de checklist voor een pentest, hoe je een pentestrapport leest en onze vergelijking van een AI-pentest met een menselijke pentest. Wie vaker dan een keer per jaar test, kijkt ook naar RedSOC.