1 november 2026 · 11 min leestijd · Door Michael van Mameren, Lead Penetration Tester (OSCP)
Security testen: het volledige landschap van kwetsbaarhedenscan tot red team, en welke tests uw organisatie nodig heeft
Een security test is geen enkel product. Het is een verzameling van tien disciplines die verschillende vragen beantwoorden, op verschillende diepte en in verschillend tempo. Deze gids definieert ze, zet ze naast elkaar en laat zien hoe ze samen een programma vormen dat met uw volwassenheid meegroeit.
Wat security testen is, en waarom één test nooit het hele antwoord is
Security testen is elke doelbewuste, geautoriseerde poging om zwakke plekken in systemen, software, mensen of processen te vinden voordat een tegenstander dat doet, onder gecontroleerde omstandigheden. Die definitie dekt zowel een wekelijkse geautomatiseerde scan als een zes weken durende heimelijke red-team-opdracht, en daarom zorgt de term voor verwarring bij inkoop. De 'security test' van een leverancier kan een scanrapport zijn; het 'security testen' van een toezichthouder kan een gedocumenteerd programma van meerdere testsoorten betekenen. ISO/IEC 27001:2022 vraagt om technisch kwetsbaarheidsbeheer (maatregel A.8.8) en om beveiligingstesten in ontwikkeling en acceptatie (A.8.29). NIS2 artikel 21, lid 2, onder f, vereist beleid en procedures om de effectiviteit van cyberbeveiligingsmaatregelen te beoordelen. DORA artikel 25 somt de tests op die het programma van een financiële entiteit moet omvatten, van kwetsbaarheidsscans en broncodebeoordelingen tot scenariogebaseerde tests en penetratietesten.
De disciplines verschillen op vijf dimensies: wat zij proberen te vinden, hoe diep zij gaan, hoe vaak zij moeten draaien, wie bevoegd is ze uit te voeren en welk bewijs zij opleveren. Geen van de disciplines vervangt een andere. De fout die inkopers het vaakst maken, is het ene kopen en het als het andere omschrijven: een scan verkocht als pentest, of een red team besteld voordat de basis ooit is getest.
Deze gids behandelt het volledige landschap. Voor de onderverdeling van de penetratietest zelf (per doelwit, positie en kennisniveau) verwijzen wij naar onze aparte gids over alle soorten pentesten. Voor de vergelijking met scannen leest u pentest versus vulnerability scan.
De tien soorten security tests
Elke discipline, de vraag die zij beantwoordt en haar plaats in het programma.
Kwetsbaarhedenscan (vulnerability scanning)
Geautomatiseerde identificatie van bekende zwakheden: ontbrekende patches, verouderde componenten, standaardconfiguraties, blootgestelde diensten. Geauthenticeerde scans zien veel meer dan ongeauthenticeerde. Beantwoordt: welke bekende problemen bestaan er nu in de hele omgeving? Het resultaat is een geprioriteerde lijst die menselijke triage nodig heeft; uitbuitbaarheid wordt niet bewezen.
Penetratietest
Handmatige, gescopete exploitatie van een gedefinieerd doelwit (netwerk, webapplicatie, API, mobiel, cloud) door gekwalificeerde testers volgens PTES, OWASP WSTG en MASTG of NIST SP 800-115. Beantwoordt: wat kan een vaardige aanvaller hier werkelijk, en hoe ver ketenen bevindingen zich? Resultaat: met bewijs onderbouwde, CVSS-gescoorde bevindingen met herstel en een hertest.
Red teaming en adversary simulation
Doelgerichte, meestal heimelijke simulatie van enkele weken van een realistische tegenstander over mensen, processen en technologie, gekoppeld aan MITRE ATT&CK. Beantwoordt: zouden wij een echte inbraak detecteren en stoppen voordat het doel bereikt is? Resultaat: een aanvalsnarratief, detectiegaten en een responstijdlijn in plaats van een kwetsbaarhedenlijst. Threat-led varianten (TIBER-EU, DORA TLPT) worden afgestemd met de toezichthouder.
Purple teaming
Red en blue team werken open samen: aanvallers voeren geselecteerde technieken uit terwijl verdedigers de detectie in realtime bijstellen. Beantwoordt: vangen onze logging, alerting en playbooks de technieken die voor ons relevant zijn? Resultaat: een detectiematrix per techniek en bijgestelde regels.
Secure code review, SAST, DAST en SCA
Fouten in software vinden vóór en tijdens de release: handmatige codereview en statische analyse (SAST) op de broncode, dynamische analyse (DAST) op de draaiende build, software composition analysis (SCA) op afhankelijkheden. Beantwoordt: introduceert onze code kwetsbaarheden, en dragen onze bibliotheken bekende kwetsbaarheden mee? Draait in de pipeline bij elke build, met handmatige review voor kritieke modules.
Configuratie- en cloud posture review
Beoordeling van hoe systemen zijn geconfigureerd ten opzichte van een benchmark: CIS Benchmarks voor besturingssystemen en cloudaccounts, hardeningrichtlijnen van leveranciers, beoordeling van identiteits- en toegangsbeleid. Cloud security posture management (CSPM) doet dit doorlopend voor AWS, Azure en Google Cloud. Beantwoordt: draaien wij wat wij hebben veilig?
Social engineering test
Phishingsimulatie, vishing (telefonisch), smishing, pretexting en USB-drops die meten of mensen en processen manipulatie weerstaan. Beantwoordt: hoeveel mensen klikken, vullen inloggegevens in of verlenen toegang, en meldt iemand het? Resultaat: percentages per campagne en afdeling, meldgedrag, procesgaten.
Fysieke beveiligingstest
Geautoriseerde pogingen om afgesloten ruimtes, apparaten of netwerkaansluitingen te bereiken: meelopen (tailgating), misbruik van badge- en bezoekersprocessen, toegang buiten kantooruren, clean desk. Beantwoordt: kan een buitenstaander fysiek binnenkomen? Gescopet onder een machtigingsbrief met juridische toetsing, en vaak gecombineerd met social engineering en red teaming.
Bug bounty en coordinated vulnerability disclosure
Externe onderzoekers uitnodigen om kwetsbaarheden te melden, via een publiek of privaat bountyprogramma met beloningen of via een coordinated vulnerability disclosure (CVD)-beleid zonder beloning. Beantwoordt: wat vinden veel ogen in de loop van de tijd dat een gescopete test niet vond? Vereist triagecapaciteit en een herstelproces. NIS2 artikel 12 en de CVD-leidraad van het NCSC kaderen de meldkant.
Doorlopend testen: PTaaS en threat exposure management
Pentest as a Service (PTaaS) levert testen in kortere, terugkerende cycli via een platform met live bevindingen. Threat exposure management (TEM, Gartners CTEM) ontdekt doorlopend assets, valideert blootstellingen en prioriteert wat hersteld moet worden. Beantwoordt: wat is er veranderd sinds de laatste test, en wat is vandaag uitbuitbaar? Vult de diepte van een momentopname aan in plaats van die te vervangen.
Security tests vergeleken
Doel, diepte, frequentie, uitvoerder, wat u ontvangt en waar het telt voor compliance.
| Soort | Doel | Diepte | Frequentie | Uitvoerder | Resultaat | Compliance-fit |
|---|---|---|---|---|---|---|
| Kwetsbaarhedenscan | Bekende zwakheden in de hele omgeving vinden | Breed en ondiep; geen exploitatie | Wekelijks tot doorlopend; na wijzigingen | Eigen IT- of securityteam, MSSP, scanplatform | Geprioriteerde lijst met CVSS, triage nodig | PCI DSS 11.3 (kwartaal intern en extern, ASV); ISO 27001 A.8.8; DORA art. 25 |
| Penetratietest | Bewijzen wat een vaardige aanvaller binnen de scope kan | Diep op de gedefinieerde scope; handmatige exploitatie en ketening | Jaarlijks en na grote wijzigingen; per release voor kritieke applicaties | Gecertificeerde externe testers (OSCP, OSWE, CREST) | Onderbouwde bevindingen, aanvalsnarratief, hertest | PCI DSS 11.4; DORA art. 25; ISO 27001 A.8.8 en A.8.29; NIS2 art. 21(2)(f); 23 NYCRR 500.5; GLBA 314.4(d)(2) |
| Red teaming | Detectie en respons testen tegen een realistische tegenstander | Diep en smal: doelgericht, heimelijk | Elke een tot twee jaar zodra pentesten volwassen is | Gespecialiseerd extern red team | Aanvalstijdlijn, detectiegaten, beoordeling van de respons | DORA art. 26 en 27 TLPT (TIBER-EU); CBEST in het VK; elders niet voorgeschreven |
| Purple teaming | Detectiedekking per techniek verbeteren | Op techniekniveau, samenwerkend | Per kwartaal, of na elk red team | Red team plus uw SOC of MDR-aanbieder | ATT&CK-detectiematrix, bijgestelde regels | Ondersteunt NIS2 art. 21(2)(b) incidentbehandeling; geen directe verplichting |
| Codereview, SAST, DAST, SCA | Fouten in code en afhankelijkheden vinden vóór release | Diep op code; geautomatiseerd plus handmatig voor kritieke modules | Elke build (geautomatiseerd); handmatig bij grote releases | Ontwikkel- en applicatiebeveiligingsteams, externe reviewers | Foutenlijst per build, inventaris van afhankelijkheden, SBOM | PCI DSS 6.2.3 en 6.3.2; DORA art. 25 broncodebeoordeling; ISO 27001 A.8.28 en A.8.29; NIST SP 800-218 (SSDF) |
| Configuratie- en cloud posture review | Hardening toetsen aan benchmarks | Breed over accounts en hosts; geen exploitatie | Doorlopend (CSPM) plus jaarlijkse expertreview | Cloud- en platformteams, externe reviewers | Afwijkingen van CIS Benchmarks, IAM-bevindingen | ISO 27001 A.8.9; PCI DSS 2.2; CIS Controls v8 |
| Social engineering test | Weerbaarheid van mensen en processen meten | Gedragsmatig; campagnegebaseerd | Maandelijks tot per kwartaal phishing; jaarlijks meerkanaals | Externe specialisten met akkoord van HR en juridische zaken | Klik-, invul- en meldpercentages; procesgaten | NIS2 art. 21(2)(g) cyberhygiëne en training; PCI DSS 12.6; ISO 27001 A.6.3 |
| Fysieke beveiligingstest | Fysieke toegangscontrole en bezoekersprocessen testen | Locatiespecifiek; scenariogebaseerd | Jaarlijks, of bij wijziging van de locatie | Gespecialiseerd red team onder een machtigingsbrief | Toegangsnarratief, falende maatregelen, fotografisch bewijs | ISO 27001 A.7 fysieke maatregelen; DORA art. 25 fysieke beveiligingsbeoordelingen |
| Bug bounty en CVD | Externe onderzoekers benutten over langere tijd | Onbegrensd in tijd, wisselend in diepte | Altijd actief | Externe onderzoekers; uw triageteam | Meldingen, triagebesluiten, herstelbewijs | NIS2 art. 12 CVD; ISO/IEC 29147 en 30111 |
| Doorlopend testen (PTaaS, TEM) | Blootstelling actueel houden tussen diepe tests | Gemiddeld; terugkerende validatie | Doorlopend, met maandelijkse of kwartaalcycli | Testaanbieder plus platform | Live dashboard met bevindingen, blootstellingstrend | Ondersteunt het DORA art. 24-programma en NIS2 art. 21(2)(f); bewijs van doorlopende beoordeling |
De volwassenheidsladder: welke tests in welke fase
Voeg disciplines toe in de volgorde die elke volgende stap zinvol maakt. Treden overslaan levert dure rapporten op over problemen die een eenvoudigere test had gevonden.
Fase 1, fundament: weet wat u heeft en herstel het bekende
U heeft een asset-inventaris nodig, geauthenticeerd kwetsbaarheidsscannen over die inventaris, een patchritme en een configuratiebasislijn (CIS Benchmarks) voor servers, werkplekken en cloudaccounts. Voeg één penetratietest per jaar toe op de systemen die uw gevoeligste data bevatten: grey box, extern en geauthenticeerd. Het signaal dat deze fase is afgerond: scanresultaten verrassen u niet meer en kritieke patches sluiten binnen uw eigen termijn.
Fase 2, assurance: test wat u bouwt en wat u inkoopt
Verplaats het testen naar de ontwikkelcyclus: SCA en SAST bij elke build, DAST op de stagingomgeving, handmatige codereview voor authenticatie-, betaal- en cryptografiemodules. Breid penetratietesten uit naar elke internet-facing applicatie en API bij elke grote release, en voer jaarlijks een interne assumed-breach-test uit. Begin met social engineering testen via een basisphishingcampagne en een meldkanaal. Doorlopende cloud posture monitoring vervangt de jaarlijkse configuratiereview.
Fase 3, weerbaarheid: test of u het zou merken
Met een SOC of MDR-dienst op zijn plaats voegt u purple teaming toe om de detectie af te stemmen op de technieken die voor uw sector het meest relevant zijn, daarna een red-team-opdracht om de hele keten heimelijk te testen. Publiceer een CVD-beleid en open een privaat bug-bountyprogramma als u de triagecapaciteit heeft. Verplaats terugkerende applicatietests naar een PTaaS-model, zodat bevindingen ook tussen de jaarlijkse cycli binnenkomen. Fysieke tests sluiten aan voor locaties die kritieke systemen huisvesten.
Fase 4, doorlopende validatie: meet blootstelling als kengetal
Threat exposure management verbindt asset-ontdekking, validatie en prioritering in één lus die de blootstelling over de tijd aan het bestuur rapporteert. Door de toezichthouder gecoördineerd threat-led testen (TIBER-EU, DORA TLPT) geldt elke drie jaar voor aangewezen financiële entiteiten. Red teaming wordt periodiek, purple teaming routine, en de penetratietest blijft het diepte-instrument voor elk nieuw systeem en elke grote wijziging.
Een jaarprogramma voor security testen: uitgewerkt voorbeeld
Een middelgrote organisatie met een klantgericht SaaS-platform, een kantoornetwerk van ongeveer 800 gebruikers, twee cloudaccounts en een SOC via een MDR-partner, op weg van fase 2 naar fase 3. Zo zien twaalf maanden eruit.
- Doorlopend: geauthenticeerd kwetsbaarheidsscannen van alle hosts wekelijks, cloud posture monitoring dagelijks, SCA en SAST bij elke build, DAST bij elke stagingdeployment, een gepubliceerd CVD-beleid met een bewaakte mailbox
- Maandelijks: phishingsimulatie met wisselende afdelingen en voorwendsels, waarbij meldpercentages naast klikpercentages worden bijgehouden
- Q1: externe perimeterpentest plus een cloudconfiguratiereview van beide accounts door een externe tester; de bevindingen voeden het herstel- en hertestvenster van Q1
- Q2: grey box penetratietest van het SaaS-platform en zijn API per rol, afgestemd op de grote voorjaarsrelease; handmatige codereview van de authenticatie- en factureringsmodules; verificatiehertest binnen 90 dagen
- Q3: interne assumed-breach-pentest vanaf een standaard werkplek met focus op Active Directory en segmentatie; purple-team-oefening met de MDR-partner op de tien technieken die het vaakst voorkomen in de incidentrapporten van uw sector
- Q4: meerkanaals social engineering test (vishing en fysiek meelopen op de hoofdlocatie) onder een machtigingsbrief; tabletop-oefening met het management op basis van de Q3-bevindingen; programma-evaluatie en het plan voor volgend jaar
- Elk tweede jaar, in plaats van het purple team in Q3: een heimelijke red-team-opdracht met doelen vastgesteld door het bestuur, gevolgd door een purple-team-debrief die de bevindingen omzet in detecties
- Bewijsmap bijgehouden voor auditors: scopeverklaringen, rapporten, hertestbevestigingen en hersteltickets, gekoppeld aan ISO 27001 A.8.8 en A.8.29, NIS2 artikel 21, lid 2, onder f, en de sectorregels die van toepassing zijn
Hoe de soorten elkaar aanvullen, en waar programma's misgaan
De disciplines zijn complementair omdat elke de blinde vlek van een andere dekt. Scannen is breed en doorlopend, maar blind voor logicafouten en geketende aanvallen. Penetratietesten vinden die wel, maar alleen binnen de scope en op een moment in de tijd. Red teaming laat zien of de keten zou worden opgemerkt, maar zegt weinig over de lange staart van kwetsbaarheden. Codereview vindt fouten vóór de uitrol, maar niet de configuratiedrift in productie. Bug bounties vinden het onverwachte in de loop van de tijd, maar laten zich niet inplannen voor een audit. Een programma is de ordening van deze disciplines zodat de gaten niet op één lijn liggen.
Vier faalpatronen keren terug. Ten eerste een scanrapport dat als penetratietest wordt gepresenteerd: geen exploitatie, geen ketening, geen dekking van bedrijfslogica, en een auditor die het afwijst onder PCI DSS Requirement 11.4 of naar de kwalificaties van de tester vraagt. Ten tweede een red team dat wordt besteld voordat er ooit een penetratietest is gedaan: het red team loopt binnen via een fout die een grey box pentest op dag één had gevonden, en de dure les gaat over de basis in plaats van over detectie. Ten derde codereview als vervanging van het testen van het draaiende systeem: de code kan schoon zijn terwijl de loadbalancer, de identity provider of de cloudrol dat niet is. Ten vierde een bug bounty die wordt gelanceerd zonder triagecapaciteit: onderzoekers melden, niemand reageert, en het programma wordt een reputatierisico in plaats van een aanwinst.
De volgorde doet er minder toe dan de vragen. Kunt u niet zeggen wat u heeft, scan dan. Weet u niet wat een aanvaller ermee kan, test dan. Weet u niet of u het zou merken, simuleer dan. Wilt u weten wat er sinds vorig kwartaal is veranderd, test dan doorlopend.
Waar de penetratietest zit, en hoe HackersHub het programma ondersteunt
De penetratietest is het diepte-instrument van het programma: de discipline die een lijst zwakheden omzet in bewijs van impact, en het bewijs waar de meeste kaders bij naam om vragen. HackersHub voert hem uit op netwerk-, webapplicatie-, API-, mobiele, cloud- en hardwaredoelwitten, als black, grey of white box, volgens PTES, OWASP WSTG en MASTG en NIST SP 800-115. Elk rapport bevat een managementsamenvatting, CVSS-gescoorde bevindingen met bewijs, een aanvalsnarratief en geprioriteerd herstel, en een verificatiehertest van bevindingen vanaf medium binnen 90 dagen is inbegrepen.
Rondom de penetratietest leveren wij de disciplines die een offensief team vragen: red teaming en adversary simulation, purple teaming met uw SOC of MDR-partner, social engineering tests (phishing, vishing, fysiek) en threat exposure management voor organisaties die hun blootstelling doorlopend gemeten willen zien. Kwetsbaarheidsscannen leveren wij als managed service. Elke tester heeft minimaal OSCP, en OSWE- en CREST-gecertificeerde testers leiden het applicatie- en red-team-werk. Lead tester Michael van Mameren beoordeelt elke scope. HackersHub levert al meer dan tien jaar offensive security vanuit Amsterdam en wordt beoordeeld met 4,9/5 over 127 reviews.
Veelgestelde vragen
Gerelateerde gidsen en diensten
- Alle soorten pentesten: per doelwit, positie en kennisniveau
- Pentest vs vulnerability scan: het verschil
- Red teaming vs pentest
- Wat is purple teaming?
- Pentest as a Service (PTaaS) uitgelegd
- Black box, grey box of white box pentest
- Wat is een pentest? Betekenis, fases en werkwijze
- Penetratietest laten uitvoeren door HackersHub
Bouwt u aan een programma voor security testen?
Een kort scopinggesprek stelt vast waar u op de ladder staat, aan welke kaders u rapporteert en wat u als eerste moet testen. U ontvangt een schriftelijk jaarplan en een gescopet voorstel voor de penetratietesten daarin. Praat met een expert.