Penetration testing is geen vinkje voor compliance, maar een geautoriseerde, gesimuleerde aanval die laat zien hoe een aanvaller echt binnenkomt. Dat is relevant, omdat 68% van de organisaties die vorig jaar slachtoffer werden van een breach, geen pentest had uitgevoerd volgens recent pentest-onderzoek DeepStrike. Voor datagedreven teams betekent dat iets heel concreets, als je API's, cloudkoppelingen en klantportalen bouwt, wil je weten waar een aanvalspad begint voordat iemand anders dat doet.
In Nederland raakt dit vooral banken, gemeenten, verzekeraars, hypotheekverstrekkers en softwareleveranciers die met gevoelige gegevens en ketens werken. Penetration testing is daar niet alleen een technische check, maar een manier om governance, risico en herstelbaarheid aantoonbaar te maken. De basis is eenvoudig, je laat een specialist zoeken naar zwakheden, combinaties van zwakheden en privileges die samen tot impact leiden. De vraag voor opdrachtgevers is dus niet alleen of je een pentest doet, maar ook hoe vaak, met welke scope en wat een pentest juist níet oplost.
Wat penetration testing is en waarom het nu relevant is
Penetration testing is een gecontroleerde aanval op systemen, applicaties of netwerken om te laten zien of kwetsbaarheden echt misbruikt kunnen worden. De NIST-glossary omschrijft het als een test die vaak zoekt naar combinaties van kwetsbaarheden op één of meerdere systemen om meer toegang te krijgen dan één fout alleen zou geven NIST. Dat maakt het fundamenteel anders dan een scan. Een scan vindt signalen, een pentest probeert daadwerkelijk door de deur te komen.
Waarom dit voor datagedreven teams telt
Voor teams die met API's werken, zit het risico vaak niet in één grote fout, maar in de samenloop van kleine fouten. Een zwakke configuratie, een te ruim token en een endpoint dat input te soepel accepteert, kunnen samen een aanvalspad vormen. Precies daarom hoort pentesting bij een platform met woningdata, waarderingslogica en externe koppelingen niet als losse security-activiteit te worden gezien, maar als onderdeel van de producthygiëne.
Een goede mentale check is eenvoudig. Als een aanvaller met beperkte rechten meer kan zien, ophalen of wijzigen dan bedoeld was, dan is dat geen abstract securityprobleem maar een concreet productrisico.
In Nederland past dat ook bij de bestuurlijke realiteit. Voor publieke organisaties is de BIO sinds 1 januari 2020 het verplichte beveiligingskader, en dat sluit aan op de ISO 27001-benadering van periodieke controle van beveiligingsmaatregelen. In dezelfde lijn beschrijft Digit FYI hoe pentesting steeds vaker wordt gebruikt als onderdeel van governance, risicobeoordeling en assurance. Daarmee hoort een pentest niet alleen thuis in het securityteam, maar ook in besluitvorming over risico en verantwoordelijkheid.
De juiste vervolgvraag is niet alleen wat de test oplevert, maar ook wat hij niet kan beloven. Je krijgt bewijs van aantoonbare aanvalspaden, prioriteit in herstel en een beter beeld van bedrijfsimpact. Je krijgt geen garantie dat monitoring, incidentrespons of risico's in de keten ook goed staan, want dat ligt buiten de testscope NCSC. Dat onderscheid wordt belangrijker nu pentesting in veel organisaties verschuift van compliance-checkbox naar gerichte risicovalidatie.
Voor wie de stap van test naar beleid wil maken, staat ook meer over security en compliance bij Altum AI uitgewerkt in de bredere context.
De drie aanpakken die een pentest starten
Black box, grey box en white box beschrijven hoeveel voorkennis de tester krijgt voordat het werk begint. Zie het als drie verschillende manieren om een huis binnen te proberen te komen. Bij black box weet de tester alleen dat het huis bestaat. Bij grey box krijgt die een sleutel tot de hal of een gebruikersaccount. Bij white box krijgt die ook de bouwtekeningen, zodat verborgen routes, fout in ontwerp en logische zwaktes zichtbaar worden.
Wanneer kies je welke aanpak
Black box past goed als je wilt weten hoe het systeem eruitziet voor een buitenstaander. Dat geeft realistische ruis, maar ook minder context, waardoor sommige kwetsbaarheden pas laat of helemaal niet zichtbaar worden. White box geeft meer diepgang, maar brengt vaak meer afstemming met ontwikkel- en beheerteams mee, juist omdat de tester gevoeliger materiaal kan zien en meer van de productieketen begrijpt.
Grey box zit ertussenin en is voor veel API- en dataplatforms de meest efficiënte keuze. Een read-only API-token of beperkte gebruikersrol laat de tester de interface gebruiken zonder alles weg te geven. Dat is vaak precies genoeg om authenticatie, autorisatie en foutafhandeling goed te toetsen zonder onnodige productierisico's.
| Methode | Informatie vooraf | Diepgang | Productierisico | Typisch doel |
|---|---|---|---|---|
| Black box | Geen of minimale kennis | Realistisch, maar minder context | Lager in voorbereiding, hoger in onduidelijkheid | Externe aanvaller simuleren |
| Grey box | Beperkte toegang of rol | Goed evenwicht tussen realisme en diepte | Gematigd | API's, portals en ketenkoppelingen testen |
| White box | Bouwtekeningen, code of volledige context | Hoogste analyse-diepte | Meer afstemming nodig | Logica, codepaden en verborgen fouten vinden |
De keuze hangt af van wat je wilt bewijzen. Wil je weten hoe een buitenstaander binnenkomt, dan kies je black box. Wil je vooral zeker weten dat productieteams en ontwikkelaars de echte aanvalspaden zien, dan is grey box vaak logischer. Wil je architecturale zwaktes en codegrenzen doorlichten, dan past white box beter. De inkoopvraag is dus niet alleen “doen jullie pentests?”, maar “welke voorkennis krijgt de tester en waarom?”
Hoe een pentesttraject in vijf stappen verloopt
Een pentesttraject is een project, geen scan. De literatuur deelt het meestal op in vijf stappen, van verkenning tot nazorg: intelligence gathering, vulnerability scanning, vulnerability exploitation, privilege escalation en post-exploitation arXiv. Die volgorde helpt je als opdrachtgever om te begrijpen wanneer je iets moet aanleveren, wanneer je een testvenster afspreekt en wanneer je risico op tijdelijke verstoring het grootst is.
Van verkennen naar toegang
In de eerste stap verzamelt de tester informatie over systemen, interfaces en zichtbare aanvalsoppervlakken. Voor een Nederlands API-platform betekent dat meestal het in kaart brengen van endpoints, domeinen, authenticatieflows en publieke metadata. Daarna volgt het systematisch scannen van zwakke plekken, waarna de tester probeert te bewijzen of een fout ook echt te benutten is.
Daarna komt het belangrijke verschil tussen “kwetsbaarheid gevonden” en “aanvalspad bevestigd”. Bij privilege escalation kijkt de tester of beperkte rechten kunnen uitgroeien tot bredere toegang. In een API-context kan dat bijvoorbeeld beginnen met een configuratiefout op een zoekendpoint en eindigen met toegang tot data buiten de bedoelde scope.
De waarde zit niet in één fout, maar in de keten. Een losse bevinding klinkt klein, een samengestelde route naar gevoelige data is dat niet.
Wat je per stap mag verwachten
- Intelligence gathering: een inventaris van wat zichtbaar is, plus afbakening van doelen en testaanpak.
- Vulnerability scanning: een lijst van vermoedelijke zwakke plekken, vaak met eerste prioriteit.
- Vulnerability exploitation: bewijs dat een kwetsbaarheid echt bruikbaar is.
- Privilege escalation: demonstratie dat beperkte toegang meer impact kan krijgen.
- Post-exploitation: bewijs van mogelijke vervolgimpact, zoals bredere toegang of datatoegang binnen scope.
Voor opdrachtgevers is de les helder. Je koopt geen lijstje met bugs, je koopt een gecontroleerde aanval met bewijs, prioriteit en hersteladvies. Als een leverancier alleen over scanning praat en niet over exploitatie, privilege escalation en retest, dan is de kans groot dat je geen echte pentest maar een beperkte security-check krijgt.
Welke systemen je kunt laten testen
Niet elk systeem vraagt om dezelfde pentest. Webapplicaties, API's, netwerken en cloudomgevingen hebben elk een ander aanvalspatroon, andere validatiepunten en andere rapportageverwachtingen. Voor een woningdata-platform of hypotheekapplicatie is het dus te simpel om alleen “een webtest” te bestellen. Een API die data beschikbaar stelt, verdient een API-pentest met aandacht voor authenticatie, autorisatie, inputvalidatie en rate limiting.
Systeemtype bepaalt de vraag
Een webapplicatiepentest kijkt vaak naar sessiebeheer, formulieren, toegangscontrole en logische fouten in de gebruikersflow. Een API-pentest kijkt dieper naar de machine-naar-machine laag, waar tokens, rollen en endpoints elkaar raken. Bij netwerken ligt de nadruk meer op segmentatie, interne verplaatsing en laterale beweging. Cloud- en IoT-omgevingen voegen configuratie, afhankelijkheden en soms firmware of fysieke interfaces toe.
| Systeemtype | Waar de tester op let | Typische scopevraag | Passende uitkomst |
|---|---|---|---|
| Webapplicatie | Authenticatie, sessies, input en toegangscontrole | Welke gebruikersflows zijn kritisch? | Aanvalspaden in de front-end en backend |
| API | Autorisatie, endpoints, rate limiting, data-exposure | Welke endpoints zijn extern of intern beschikbaar? | Misbruik van machine-naar-machine koppelingen |
| Netwerk | Segmentatie, serviceblootstelling, interne verplaatsing | Welke segmenten mogen getest worden? | Inzicht in laterale beweging en toegangspaden |
| Cloud of IoT | Configuratie, permissies, firmware of interfaces | Welke accounts, tenants of devices vallen binnen scope? | Keten- en configuratierisico's |
Welke vraag je vooraf moet stellen
De beste inkoopvraag is niet “doen jullie ook cloud?” maar “welk aanvalsoppervlak staat centraal en waarom?”. Als je een API beheert, moet de scope expliciet zeggen welke endpoints, welke rollen en welke omgevingen getest worden. Anders eindig je met een rapport dat wel over een website gaat, maar niets zegt over je echte integratielaag.
Voor een dataplatform is dat extra belangrijk, omdat de risico's vaak verschuiven tussen UI, API en cloudconfiguratie. Een goede pentest benoemt dat verschil expliciet in rapportage, zodat je weet welk deel van het product werkelijk is beoordeeld en welk deel nog ongetest blijft.
Methodologieën en compliance voor de Nederlandse markt
Pentesting in Nederland zit tussen techniek en governance in. Aan de technische kant kom je methodologieën tegen zoals OWASP, PTES, NIST SP 800-115 en CREST. Aan de andere kant liggen kaders als BIO, ISO 27001, AVG/GDPR en voor financiële organisaties ook DORA. Samen bepalen ze niet alleen hoe je test, maar ook waarom je test, hoe vaak dat nodig is, welke bewijslast je verwacht en wie waarvoor verantwoordelijk is.
Wat de kaders van je vragen
OWASP helpt vooral bij applicatierisico's, bijvoorbeeld rondom toegangscontrole en inputvalidatie. PTES en NIST SP 800-115 geven een gestructureerde aanpak voor scope, uitvoering en rapportage. CREST legt in de praktijk veel nadruk op professionele uitvoering, heldere afspraken en controleerbare verslaglegging. Dat is belangrijk, omdat een pentest zonder strakke scope al snel te breed wordt of juist te oppervlakkig blijft.
De compliance-kant werkt anders, maar is net zo bepalend. De BIO maakt pentesting voor Nederlandse overheden onderdeel van een verplicht beveiligingskader. ISO 27001 vraagt om periodieke evaluatie van beveiligingsmaatregelen, waardoor pentestresultaten meer worden dan een los document. Ze dienen als bewijs dat een beheersmaatregel niet alleen op papier staat, maar ook echt is getoetst. AVG/GDPR en DORA leggen dezelfde logica op een andere manier neer. Je moet niet alleen beschermen, maar ook kunnen uitleggen wat je hebt getest, wat je hebt hersteld en wat nog openstaat. Zie ook meer over DORA en operationele weerbaarheid als je wilt begrijpen waarom dat voor financiële organisaties steeds zwaarder weegt.
Belangrijke nuance: compliance bepaalt vaak de minimale eisen, maar niet automatisch de juiste testdiepte. Je risicoprofiel doet dat wel.
In de praktijk betekent dit dat scope, onafhankelijke uitvoering, rapportage en retest geen extra's zijn. Ze horen bij de bewijsvoering zelf. Voor een organisatie met gevoelige woningdata, klantdossiers of ketenkoppelingen is dat precies de brug tussen technische bevinding en aantoonbare beheersmaatregel. Als je dit scherp wilt krijgen, is de vervolgvraag niet alleen of een pentest “gehad moet worden”, maar welke norm je ermee wilt aantonen en welke onderdelen van je omgeving daarbij echt in beeld moeten komen.
Praktische checklist voor opdrachtgevers
De beste pentest begint voordat de tester start. Als scope, omgeving en verwachte uitkomst niet scherp zijn, krijg je een rapport dat lastig te gebruiken is. Daarom hoort een inkoopgesprek te draaien om afbakening, testniveau, rapportage-eisen en opvolging, niet alleen om prijs.
Waar je op moet letten
- Scope afbakenen: benoem expliciet welke systemen, omgevingen en endpoints getest worden, en wat buiten scope valt.
- Testniveau kiezen: leg vast of je black, grey of white box wilt en waarom dat past bij het product.
- Regels voor escalatie afspreken: maak duidelijk wanneer de tester mag doorgaan, pauzeren of contact moet opnemen.
- Rapportage eisen stellen: vraag om executive summary, reproduceerbaar bewijs, risicobeoordeling en retest-advies.
- Databehandeling vastleggen: spreek anonimisering, logging en bewaartermijnen af, zeker als persoonsgegevens of productiedata in beeld komen.
Een eenmalige API-pentest begint vaak rond ongeveer €5.000, terwijl een doorlopend programma duidelijk hoger uitvalt. Dat is geen tariefadvies, maar een signaal dat scope en diepgang direct doorwerken in de inzet van specialisten. Ook de doorlooptijd hangt sterk af van omvang en responssnelheid, niet alleen van de test zelf.
| Vraag tijdens selectie | Waarom die vraag telt |
|---|---|
| Welke ervaring hebben jullie met API's en ketenkoppelingen? | Je wilt geen webtest op een API-probleem |
| Hoe ziet een voorbeeldrapport eruit? | Je checkt of bevindingen reproduceerbaar zijn |
| Hoe gaan jullie om met retest? | Zonder retest blijft herstel onbevestigd |
| Welke veilige data-opslag gebruiken jullie tijdens het traject? | Je verlaagt risico op onbedoelde blootstelling |
Bekijk ook Lees meer over veilige data-opslag als je wilt weten hoe je testdata en bevindingen tijdens een traject beheerst bewaart.
Als een leverancier geen duidelijk antwoord geeft op scope, bewijs en retest, koop je vooral onzekerheid in. Vraag daarom niet alleen naar certificeringen, maar ook naar de manier waarop zij werken met bewijs, change logs en nazorg. De vervolgvraag is dan eenvoudig. Kun je na de pentest ook laten zien wat er echt is aangepast?
Geanonimiseerde casus van een woningdata API
Een grijs-geautoriseerde API-test laat vaak beter zien waar het echte risico zit dan een losse websitecheck. In een geanonimiseerde casus van een woningdata-platform kreeg de tester een beperkt account en toegang tot enkele zoekfuncties. De pentest liet zien dat een zoekendpoint te weinig inputvalidatie toepaste, terwijl het API-token meer rechten had dan nodig was.
Hoe het aanvalspad zichtbaar werd
De tester begon met normaal gebruik van de API en ontdekte dat foutafhandeling details prijsgaf die in productie niet zichtbaar hadden mogen zijn. Daarna bleek dat een combinatie van een specifieke invoer en een te ruim token toegang gaf tot data buiten de bedoelde scope. Dat was geen enkelvoudige fout, maar een aanvalspad dat pas duidelijk werd toen twee kleine zwaktes samenkwamen.
Het rapport bevatte concreet bewijs, inclusief request- en responsefragmenten, prioriteit per bevinding en een helder hersteladvies. Het ontwikkelteam voerde binnen twee weken een fix door, eerst door inputvalidatie aan te scherpen, daarna door de tokenrechten strakker te begrenzen. Bij de retest kon het oorspronkelijke pad niet meer worden herhaald.
Les uit de casus: een pentest is pas echt waardevol als je remediation en retest als vast onderdeel behandelt, niet als losse opvolging.
Voor teams die met woningdata, taxatie-informatie of energiedata werken, is de les herkenbaar. Je wilt niet alleen weten dát een endpoint kwetsbaar is, maar ook of de fout zich laat combineren met rechten, caching of logging. Juist daarom zijn scope-afspraken en gestructureerd bewijs zo belangrijk. Zonder dat blijft een rapport een momentopname. Met dat bewijs wordt het een gecontroleerde sluiting van risico.
Vervolgstappen na rapportage en veelgestelde vragen
Na het rapport begint het echte werk. De eerste stap is triage, dus snel bepalen welke bevindingen direct aandacht vragen en welke in de normale backlog kunnen. Daarna zet je een remediation-tracker op, plan je retest in en koppel je de lessons learned terug naar product, development en beheer. Zo voorkom je dat hetzelfde aanvalspad in een volgende release terugkomt.
FAQ
Hoe vaak heb je een pentest nodig voor een API-platform?
Er bestaat geen universeel ritme, maar de vuistregel is dat de frequentie moet passen bij veranderingssnelheid en risico. In publieke bronnen zie je bijvoorbeeld dat CMS pentests gebruikt met een ritme van eens per 3 jaar of bij een significante systeemwijziging CMS. Voor een snel veranderend API-platform is dat vaak te traag, dus koppel de frequentie aan releases, integraties en wijzigingsimpact.
Hoe kies je een geschikte testleverancier?
Kijk naar aantoonbare ervaring met jouw type systeem, bijvoorbeeld API's, cloud of ketenkoppelingen. Vraag om een voorbeeld van een rapport, hoe ze omgaan met retest en hoe ze scope en escalatie bewaken. Certificeringen helpen, maar het echte verschil zit in reproduceerbaar bewijs en heldere opvolging.
Welke risico's dekt een pentest niet af?
Een pentest is geen totaalbeoordeling van monitoring, incidentrespons of alle mogelijke fraudepaden. Het NCSC benadrukt dat het een middel is om technische risico's te beoordelen, maar geen allesomvattende garantie NCSC. Alles wat buiten scope valt, blijft dus buiten beeld.
Als je direct met woningdata, waarderingslogica of energiekoppelingen wilt werken, vraag dan een gratis Altum AI-account aan en test de API in de sandbox. Je krijgt daarmee een praktische manier om datakoppelingen, validatie en integratievragen vroeg in het traject te verkennen. Ga naar Altum AI als je wilt zien hoe een transparante API-laag voor woningdata in een productteam gebruikt kan worden.