Penetratietest: welke test heeft uw bedrijf nodig?

In een bestek van een Vlaamse overheidsdienst staat “penetratietest”. In de polisvoorwaarden van uw cyberverzekeraar ook. In de vragenlijst van uw grootste klant staat het voluit. Maar zodra u offertes opvraagt, blijkt dat woord tien verschillende dingen te kunnen betekenen.

Dat verschil kost geld. Bedrijven laten geregeld hun externe perimeter testen terwijl hun bedrijfskritieke gegevens in een cloudomgeving of een maatwerkapplicatie staan. De test slaagt, het rapport oogt geruststellend, en het onderzochte deel was niet het deel dat ertoe deed.

In het kort

• Een penetratietest is geen uniform product. De reikwijdte moet aansluiten op waar uw waardevolle gegevens werkelijk staan.
• De keuze wordt in de praktijk bepaald door de aanleiding: een compliance-verplichting, een klantvragenlijst, een verzekeringspolis, een release of een incident.
• Een grey-box aanpak levert voor kmo’s doorgaans het meeste diepgang per besteed dag.
• Een kwetsbaarheidsscan somt bekende fouten op. Een penetratietest toont aan of die fouten werkelijk tot toegang leiden.
• De test telt pas mee wanneer de hertest is afgerond. Een rapport met openstaande bevindingen overhandigen aan een auditor werkt tegen u.

Wat is een penetratietest?

Een penetratietest is een gecontroleerde beveiligingsbeoordeling waarbij ethische hackers met schriftelijke toestemming proberen binnen te dringen in IT-systemen, applicaties of cloudomgevingen. Door kwetsbaarheden werkelijk uit te buiten en aanvalsketens na te bootsen, toont de test hoe diep een aanvaller kan doordringen en welke bedrijfsschade dat oplevert.

Penetratietest of pentest?

Beide woorden slaan op hetzelfde, maar u komt ze in andere documenten tegen. “Penetratietest” staat voluit in bestekken van Belgische overheidsopdrachten, in acceptatievoorwaarden van cyberverzekeraars, in compliance-audits en in de documentatie rond het CyberFundamentals-kader van het CCB. “Pentest” is het vakjargon op IT-afdelingen. Wie de formele term tegenkomt, handelt meestal vanuit governance of een contractonderhandeling. Wie “pentest” zegt, zit al in de uitvoering.

Welke penetratietest past bij uw situatie?

Deze beslisboom leidt in maximaal zes vragen naar het juiste testtype. Begin bij vraag 1.

1. Wat is de aanleiding?

• Formele compliance (NIS2, DORA), een ISO 27001-traject of een vragenlijst van een enterprise-klant: ga naar vraag 2.
• De oplevering of een grote update van een digitaal platform: ga naar vraag 3.
• Algemeen risicobeheer, een recente migratie of een voorwaarde van uw verzekeraar: ga naar vraag 4.
• U wilt weten of uw eigen team een gerichte aanval detecteert en stopt: dan zoekt u geen penetratietest maar een red teaming-traject.

2. Wat valt er onder de audit of de wettelijke verplichting?

• Systemen die kritieke diensten ondersteunen: een gecombineerde test van uw externe infrastructuur en uw cloudomgeving.
• Een applicatie of koppelvlak dat klantgegevens verwerkt: ga naar vraag 3.
• Procesautomatisering, sensoren of machinesturing: een test van uw operationele technologie.

3. Hoe wordt de applicatie aangeboden?

• Via een browser, zoals een klantenportaal of SaaS-dienst: een webapplicatietest, bij voorkeur grey-box.
• Als koppelvlak tussen systemen of als backend voor een mobiele app: een API-test.
• Als app op toestellen van medewerkers of klanten: een test van de mobiele applicatie inclusief de achterliggende koppelingen.

4. Vanaf waar opereert het belangrijkste dreigingsscenario?

• Een aanvaller op het publieke internet: een test van uw externe infrastructuur.
• Iemand die al binnen zit, via een besmette bijlage of een interne actor: een test van uw interne omgeving.
• Verkeerd ingestelde rechten, accounts of opslag in de cloud: een cloudtest.

5. Zijn er industriële besturingssystemen betrokken?

• Ja, productiesystemen communiceren met uw kantooromgeving: een test van uw operationele technologie, met strikte veiligheidsafspraken.
• Nee, uitsluitend administratieve IT en cloud: blijf bij de reguliere infrastructuurtesten.

6. Is manipulatie van medewerkers uw grootste onzekerheid?

• Ja, uw mensen krijgen herhaaldelijk gerichte valse berichten: een social engineering- en phishingsimulatie.
• Nee, de techniek moet eerst aantoonbaar standhouden: begin met een applicatie- of infrastructuurtest.

Hoe u de systemen, adressen en accounts daarna precies afbakent, staat in ons artikel over het bepalen van de scope.

De tien soorten penetratietesten vergeleken

Voor het niveau van voorkennis waarmee de tester start, verwijzen we naar ons artikel over de box-varianten. Voor het onderscheid met een aanvalssimulatie op organisatieniveau is er het artikel over red teaming.

Penetratietest of kwetsbaarheidsscan?

Deze twee worden in het kmo-segment geregeld verward, wat leidt tot teleurstelling bij een audit of tot misplaatste zekerheid.

Een kwetsbaarheidsscan is volledig geautomatiseerd. Het instrument bevraagt systemen op afstand, vergelijkt versienummers met openbare databanken en levert een lijst van bekende fouten en ontbrekende updates. Het toetst niet of die fouten in uw context werkelijk misbruikt kunnen worden, waardoor er zowel valse alarmen als blinde vlekken ontstaan.

Een penetratietest is handmatig werk. Waar de scanner stopt bij het vaststellen van een afwijking, gebruikt de tester vakkennis om filters te omzeilen en om verschillende kleine tekortkomingen aaneen te rijgen tot een werkend aanvalspad. De scan is uw frequente basismeting voor patchbeheer. De test levert het bewijs. De volledige vergelijking staat in ons artikel over scan tegenover pentest.

Welke aanleiding vraagt welke penetratietest?

Vlaamse kmo’s geven zelden opdracht zonder concrete aanleiding. Onderstaande tabel koppelt de gangbare aanleidingen aan wat er in de praktijk gevraagd wordt.

Waaraan u een grondige penetratietest herkent

Voor een zaakvoerder of een IT-verantwoordelijke zonder testervaring is moeilijk in te schatten of een ethische hacker methodisch werkt of wat rondklikt. Internationale standaarden geven daar houvast bij, en ze zijn opvraagbaar zonder dat u technisch hoeft te zijn.

De OWASP Web Security Testing Guide is de norm voor webtoepassingen en API’s. De gids beschrijft tientallen testroutines die systematisch elke laag doorlopen, van authenticatie en sessiebeheer tot logicafouten. Voor u als koper is dat de garantie dat de tester geen elementaire categorie overslaat.

De Penetration Testing Execution Standard structureert het proces in zeven fasen, van intake en verkenning tot exploitatie en rapportering. Die methodiek zorgt ervoor dat de tester niet stopt bij de eerste oppervlakkige fout, maar nagaat hoe ver een aanvaller daarmee komt.

De OSSTMM hanteert een meetbare benadering van operationele veiligheid, gebaseerd op vaststelbare feiten in plaats van subjectieve inschattingen. Dat maakt ze bruikbaar voor auditdossiers. De NIST Special Publication 800-115 beschrijft hoe technische controles gepland, uitgevoerd en gedocumenteerd horen te worden, wat vooral telt wanneer u levert aan internationale klanten.

Rapporteert een partner aantoonbaar volgens deze methodieken, dan hebt u een document dat standhoudt bij auditors, toezichthouders en ketenpartners.

Het natraject: de test telt pas na de hertest

Een penetratietest maakt uw bedrijf niet veiliger. Dat gebeurt in wat erna komt.

Een goed rapport bestaat uit twee gescheiden delen. De managementsamenvatting is voor de zaakvoerder, de verzekeraar en de auditor: geen jargon, maar de vertaling naar bedrijfsrisico’s zoals stilstand, datalekken en aansprakelijkheid. Het technische deel is voor uw IT-beheerder of softwareleverancier: per bevinding een risicoscore, een technische toelichting, reproduceerbare bewijsvoering en een concrete herstelmethode. Hoe u dat leest, staat in ons artikel over het interpreteren van een pentestrapport.

Zodra de aanpassingen doorgevoerd zijn, volgt de hertest. De tester gaat na of de maatregelen het lek effectief dichten en of er geen nieuwe problemen zijn geïntroduceerd. Dat levert een attest van hertest op, en dat is het document dat u wilt voorleggen. Een oorspronkelijk rapport met openstaande bevindingen overhandigen aan een toezichthouder of een veeleisende klant wekt wantrouwen; een schoon hertestattest toont dat u uw risico’s methodisch afsluit.

Vijf fouten bij het kiezen van het testtype

1. Enkel de buitenkant laten testen. Een externe test is eenvoudig af te bakenen, dus veel bedrijven blijven daarbij. Moderne aanvallen starten echter vaak via phishing of een overgenomen account. Wie de interne omgeving niet laat onderzoeken, weet niet hoe snel ransomware zich zou verspreiden.
2. Voor black-box kiezen uit principe. “Een echte hacker weet ook niets” klinkt logisch, maar in de praktijk gaat een substantieel deel van de gecontracteerde dagen op aan publieke verkenning. Grey-box levert kmo’s meer diepgang, omdat de tester meteen achter de inlogpoort kan kijken.
3. Aannemen dat de cloudleverancier alles beveiligt. De provider beveiligt de onderliggende datacenters. Identiteitsbeheer, machtigingen en opslagconfiguratie blijven uw verantwoordelijkheid. Hoe dat misloopt, staat in ons artikel over cloudpentesting.
4. Testen op een niet-representatieve omgeving. Wanneer de authenticatiekoppelingen, rechtenstructuren of databaseversies in uw testomgeving afwijken van productie, blijven de echte risico’s onzichtbaar.
5. De koppelvlakken vergeten. Bedrijven laten een webapplicatie testen maar sluiten de onderliggende API’s uit van de scope. Aanvallers richten zich juist rechtstreeks op die koppelvlakken om de controles van de webinterface te omzeilen.

Twee bezwaren, eerlijk bekeken

“Het is een momentopname, morgen is er een nieuwe kwetsbaarheid”

Op componentniveau klopt dat. Een test die vandaag slaagt, garandeert niet dat een server morgen bestand is tegen een pas ontdekt lek in veelgebruikte software.

Maar een professionele test loopt geen checklist af. Hij beoordeelt de diepteverdediging: ontwerpfouten, autorisatiestructuren en de mogelijkheden om rechten te verhogen. Dat soort fundamentele problemen ontstaat of verdwijnt niet van de ene dag op de andere. En de test toont wat er gebeurt wanneer de buitenste laag wél bezwijkt. Komt een indringer dan meteen bij uw waardevolle gegevens, of stuit hij op strikte rechtenbeperking? Dat antwoord houdt langer stand dan één kwetsbaarheid.

“Een scan is sneller en vindt hetzelfde”

Voor het snel en breed inventariseren van bekende fouten over veel systemen zijn scanners onmisbaar. Voor gewone IT-hygiëne zou u ze moeten draaien.

Ze missen alleen per definitie de contextuele fouten. Een geautomatiseerd instrument begrijpt niet dat een gebruiker het factuurnummer in een webadres kan aanpassen om de financiële gegevens van een andere klant te zien. De server antwoordt correct, de scanner registreert een geslaagde transactie en slaat geen alarm. Daarnaast ontbreekt de creativiteit om ogenschijnlijk onschuldige configuratiefouten te combineren tot een werkend inbraakpad.

Waar begint u?

Met een intakegesprek. Daarin bepaalt u samen met de tester de aanleiding, de doelomgeving en de randvoorwaarden, en legt u de exacte scope vast: welke domeinnamen, adresbereiken of cloudtoepassingen. Dat gesprek bepaalt meer over de waarde van de test dan de keuze van de leverancier.

Weet u nog niet welk type bij uw situatie past, dan lopen we die vraag graag met u door. Wat wij daarin doen en hoe een traject verloopt, staat op onze pagina over penetratietesten.

Veelgestelde vragen

Wat is het verschil tussen een penetratietest en een kwetsbaarheidsscan?

Een kwetsbaarheidsscan is een geautomatiseerde inventarisatie die systemen controleert op bekende softwarefouten en ontbrekende updates. Een penetratietest is handmatig onderzoek waarbij ethische hackers die kwetsbaarheden doelgericht uitbuiten om de werkelijke bedrijfsschade en de ketenrisico’s aan te tonen.

Welke soorten penetratietesten bestaan er?

Testen worden ingedeeld naar doelwit: webapplicaties, API’s, mobiele apps, externe infrastructuur, interne omgevingen, cloud en operationele technologie. Daarnaast verschilt de benadering op basis van voorkennis: black-box zonder voorkennis, grey-box met gebruikersrechten en white-box met volledige toegang en documentatie.

Hoelang duurt een penetratietest voor een kmo?

Dat hangt af van de omvang en de complexiteit van de scope. Een gerichte test van een webapplicatie of API duurt doorgaans drie tot vijf mandagen. Een bredere controle van externe infrastructuur of een cloudomgeving vergt gemiddeld twee tot zes mandagen.

Waarom kiezen de meeste kmo’s voor grey-box?

Grey-box biedt de beste verhouding tussen tijd en diepgang. De tester start met beperkte gebruikersrechten, waardoor er geen kostbare tijd naar blinde verkenning gaat. Dat simuleert bovendien een realistisch scenario waarin een indringer al inloggegevens van een medewerker of klant bemachtigd heeft.

Is een penetratietest verplicht onder NIS2 in België?

De Belgische NIS2-wet verplicht gereguleerde entiteiten om de doeltreffendheid van hun maatregelen systematisch te toetsen. Binnen het CyberFundamentals-kader van het CCB is een formele penetratietest verplicht voor het niveau Essential en is het de aangewezen verificatiemethode voor het niveau Important.

Moet een cloudomgeving zoals Microsoft 365 getest worden?

Ja. De configuratie van cloudomgevingen valt onder uw eigen verantwoordelijkheid, niet onder die van de leverancier. Een cloudtest legt configuratiefouten, te ruime toegangsrechten en risicovolle integraties bloot voordat die tot datadiefstal leiden.

Kan een penetratietest de bedrijfsvoering verstoren?

Een professionele test wordt zo uitgevoerd dat de beschikbaarheid van uw systemen gewaarborgd blijft. Risicovolle technieken worden uitsluitend toegepast na uitdrukkelijke toestemming van uw IT-verantwoordelijke of buiten de kantooruren.

Worden API’s automatisch meegenomen in een webapplicatietest?

Niet vanzelfsprekend. Hoewel webapplicaties achterliggende koppelvlakken gebruiken, vereist een grondige analyse van REST- of GraphQL-interfaces een uitdrukkelijke afbakening in de scope, inclusief de bijhorende technische documentatie.

Is een hertest standaard inbegrepen?

Dat hangt af van het voorstel. Een hertest binnen enkele weken na oplevering geldt wel als industriestandaard, om te verifiëren of de doorgevoerde oplossingen effectief zijn en geen nieuwe risico’s introduceren.

Hoelang blijft een penetratietestrapport geldig?

Binnen compliancekaders zoals ISO 27001, DORA en leveranciersaudits geldt doorgaans maximaal twaalf maanden. Bij substantiële wijzigingen aan uw IT of een herontwerp van uw software vervalt de representativiteit eerder.