Pentest voor ISO 27001: hoe bepaal je de juiste scope en aanpak?

Veel organisaties komen op hetzelfde punt uit tijdens een ISO 27001-traject.

Er loopt een risicoanalyse. De eerste maatregelen zijn genomen. Een auditor of klant verlangt aantoonbaar bewijs dat de technische beveiliging is getoetst. Vervolgens rijst de vraag:

Moeten we een pentest laten uitvoeren?

Dat is een logische eerste vraag. Maar om te bepalen wát er getest moet worden, is eerst een andere vraag belangrijk:

Welke onderdelen moeten we laten testen, en waarom juist die onderdelen?

Daar gaat het in de praktijk vaak mis. Organisaties besluiten dat er een pentest moet komen, terwijl nog niet duidelijk is welke systemen daadwerkelijk onderzocht moeten worden. Gaat het om de publieke website, een klantportaal, een API, de cloudomgeving, externe toegang of juist het interne netwerk?

Die afbakening maakt veel uit. Een pentest op een marketingwebsite zegt weinig over de beveiliging van een klantportaal. Een externe pentest geeft geen volledig beeld van risico’s binnen het interne netwerk. En een test op één applicatie zegt niet automatisch iets over de inrichting van Microsoft 365, Azure of andere systemen waarin belangrijke bedrijfsinformatie wordt verwerkt.

Daarom begint een pentest voor ISO 27001 met het bepalen van welke systemen relevant zijn voor de informatie die de organisatie wil beschermen. Pas daarna kun je bepalen welke vorm van securityonderzoek daar het beste bij past.

Is een pentest verplicht voor ISO 27001?

ISO 27001 schrijft niet letterlijk voor dat iedere organisatie jaarlijks een pentest moet laten uitvoeren. De norm werkt risicogebaseerd. Een organisatie moet bepalen welke informatiebeveiligingsrisico’s relevant zijn, passende maatregelen treffen en kunnen aantonen dat die maatregelen werken.

Daar past een pentest vaak heel goed bij, maar de norm zegt niet: “test altijd de website” of “voer jaarlijks een interne netwerkpentest uit”. Dat zou ook niet logisch zijn. Een SaaS-bedrijf met een klantportaal heeft andere risico’s dan een productiebedrijf met OT-systemen, een zorgorganisatie met cliëntgegevens of een adviesbureau dat vooral in Microsoft 365 werkt.

In ISO 27001:2022 zijn er wel meerdere controls die raken aan technische kwetsbaarheden en security testing. Denk aan Annex A 8.8 voor het beheren van technische kwetsbaarheden en Annex A 8.29 die zich richt op securitytesten gedurende de ontwikkeling en ingebruikname van informatiesystemen. Annex A 8.29 gaat onder meer over het inrichten van een securitytestproces voor nieuwe of gewijzigde informatiesystemen, zodat er niet pas naar security wordt gekeken als de applicatie al op productie staat.

Dat betekent in gewone taal: als systemen belangrijk zijn voor de organisatie, moet je kunnen uitleggen hoe je technische risico’s daarin ontdekt, beoordeelt en opvolgt. Een vulnerability scan kan daarbij helpen. Code reviews kunnen daarbij helpen. Securitytesten in de ontwikkelstraat kunnen daarbij helpen. En een pentest kan daarbij een sterke vorm van onafhankelijke validatie zijn.

De pentest is dus niet “het vinkje voor ISO 27001”. De pentest is bewijs dat je serieus hebt gekeken naar de technische weerbaarheid van systemen die belangrijk zijn binnen je ISMS.

De verkeerde vraag: “wat moeten we minimaal doen voor de audit?”

Veel organisaties benaderen een pentest vanuit auditdruk. Er is een certificeringstraject gestart, iemand heeft gezegd dat er een pentest nodig is en vervolgens wordt er een offerte aangevraagd.

Dat is begrijpelijk, maar niet de beste manier om naar pentesten te kijken.

Wanneer de vraag vooral is wat minimaal nodig is voor de audit, ontstaat al snel een te smalle scope. Dan wordt bijvoorbeeld alleen de publieke website getest, omdat die zichtbaar is en makkelijk af te bakenen valt. Maar als de echte risico’s zitten in een klantportaal, een interne fileserver, een Azure-omgeving of een slecht gesegmenteerd netwerk, dan zegt zo’n pentest weinig over de belangrijkste risico’s van de organisatie.

Het omgekeerde gebeurt ook. Een organisatie zegt dat “alles” getest moet worden. Denk aan de website, inclusief alle subdomeinen, het netwerk, de cloud, alle locaties en alle (interne) applicaties. Dat klinkt grondig, maar is vaak niet efficiënt. Het maakt de scope groot, duur en moeilijk uitvoerbaar. Bovendien is niet ieder onderdeel even risicovol of even relevant voor ISO 27001.

De juiste vraag is daarom niet:

Wat moeten we minimaal doen voor ISO 27001?

Maar:

Welke technische risico’s moeten we aantoonbaar toetsen om te laten zien dat onze belangrijkste informatie goed beschermd is?

Die vraag leidt tot een veel betere pentestscope.

De scope van de ISO 27001 pentest begint bij de scope van het ISMS

Binnen een ISO 27001-traject wordt eerst bepaald welke onderdelen van de organisatie binnen de scope van het ISMS vallen. Die afbakening vormt een belangrijk uitgangspunt voor de scope van de pentest.

Dat betekent overigens niet dat alles binnen de ISMS-scope automatisch gepentest moet worden. De uiteindelijke scope wordt bepaald op basis van de risico’s. Een internet-facing klantportaal zal bijvoorbeeld vaak eerder in aanmerking komen voor een pentest dan een intern ondersteunend systeem met een beperkt risicoprofiel.

Bij het bepalen van die scope spelen onder meer de volgende vragen een rol:

• Is het systeem vanaf internet bereikbaar?
• Worden er gevoelige of vertrouwelijke gegevens verwerkt?
• Is het systeem bedrijfskritisch?
• Heeft een succesvolle aanval grote impact op de organisatie?
• Zijn er recent grote wijzigingen of migraties uitgevoerd?
• Vormt het systeem een belangrijk toegangspunt tot andere systemen?

Op basis van deze afwegingen ontstaat een logische prioritering. Een publiek klantportaal zal bijvoorbeeld vaak eerder in aanmerking komen voor een pentest dan een interne HR-applicatie met beperkte toegang. Een API die persoonsgegevens verwerkt is meestal interessanter om te testen dan een informatieve website zonder inlogfunctionaliteit. En een verouderde VPN-oplossing kan een groter risico vormen dan een moderne SaaS-applicatie waarvan de leverancier verantwoordelijk is voor de onderliggende infrastructuur.

Het belangrijkste is dat de organisatie deze keuzes goed kan onderbouwen. Waarom is dit systeem wel getest en een ander niet? Welke risico’s lagen daaraan ten grondslag? En hoe sluiten die keuzes aan op de risicoanalyse? Dat is uiteindelijk ook waar een auditor naar zal kijken.

Welke systemen komen doorgaans in aanmerking voor een ISO 27001 pentest?

Welke systemen uiteindelijk getest moeten worden, verschilt per organisatie. Het hangt af van de IT-omgeving, de risico’s en de informatie die beschermd moet worden. Toch zijn er een aantal onderdelen die binnen een ISO 27001-traject regelmatig onderdeel uitmaken van een pentest.

Webapplicaties en klantportalen

Applicaties waarin gebruikers kunnen inloggen of waarin gegevens worden verwerkt, vormen vaak een belangrijk onderdeel van de dienstverlening. Denk aan klantportalen, medewerkersportalen, cliëntportalen, reserveringssystemen of andere bedrijfsapplicaties. Juist in dit soort systemen ontstaan risico’s die een vulnerability scan vaak niet aan het licht brengt, zoals autorisatieproblemen, fouten in businesslogica en onjuiste toegangscontrole.

API’s

Veel organisaties maken gebruik van API’s voor mobiele apps, klantportalen of koppelingen met andere systemen. Omdat via API’s vaak gevoelige gegevens worden uitgewisseld, is het verstandig deze expliciet mee te nemen bij het bepalen van de scope. Een API kan immers andere kwetsbaarheden bevatten dan de webapplicatie waarmee deze samenwerkt.

Cloudomgevingen

Wanneer bedrijfskritische systemen draaien in AWS, Azure of Google Cloud, kan ook de cloudomgeving onderdeel zijn van de pentest. Daarbij wordt niet alleen gekeken naar de applicatie zelf, maar ook naar de inrichting van de cloudomgeving, zoals toegangsbeheer, rechten, netwerkconfiguraties en opslag van gegevens.

Interne netwerken

Niet alle risico’s bevinden zich op internet. Organisaties met een eigen intern netwerk, meerdere vestigingen of gevoelige systemen die alleen intern bereikbaar zijn, kiezen regelmatig ook voor een interne netwerkpentest. Daarmee wordt inzicht verkregen in de risico’s die ontstaan wanneer een aanvaller of onbevoegde gebruiker eenmaal toegang heeft tot het interne netwerk.

Microsoft 365 en identiteitsbeheer

Bij veel organisaties vormt Microsoft 365 inmiddels het hart van de IT-omgeving. E-mail, documenten, gebruikersaccounts en toegang tot andere systemen zijn vaak volledig afhankelijk van Microsoft 365 en Entra ID. In dat geval kan een toetsing van de inrichting van deze omgeving minstens zo waardevol zijn als een traditionele netwerkpentest.

De uiteindelijke scope is altijd afhankelijk van de risico’s binnen de organisatie. Een zorginstelling met cliëntgegevens zal vaak andere keuzes maken dan een softwarebedrijf dat zijn dienstverlening volledig in Azure heeft ondergebracht. Het belangrijkste is dat de gekozen scope aansluit bij de systemen die het meest kritisch zijn voor de organisatie en de informatie die zij wil beschermen.

Wanneer is een vulnerability scan voldoende voor ISO 27001?

Vulnerability scans zijn een belangrijk onderdeel van een risicogebaseerde beveiligingsaanpak, maar dienen een ander doel dan een pentest.

Binnen ISO 27001 kunnen vulnerability scans een waardevolle rol spelen binnen vulnerability management. Ze helpen om bekende kwetsbaarheden, verouderde software en misconfiguraties in kaart te brengen. Dat sluit aan op Annex A 8.8, waarin het identificeren, beoordelen en opvolgen van technische kwetsbaarheden centraal staat.

Een vulnerability scan laat zien welke bekende kwetsbaarheden aanwezig zijn. Tijdens een pentest wordt onderzocht of en hoe een aanvaller deze kwetsbaarheden daadwerkelijk kan misbruiken en welke impact dat heeft op de organisatie.

In de praktijk vullen vulnerability scans en pentesten elkaar daarom goed aan. Vulnerability scans zorgen voor continu inzicht in bekende kwetsbaarheden, terwijl een pentest periodiek de weerbaarheid van kritieke systemen beoordeelt vanuit het perspectief van een aanvaller.

Een vulnerability scan kan voldoende zijn voor systemen met een beperkt risicoprofiel of als periodieke controle tussen pentesten door. Voor bedrijfskritische applicaties, cloudomgevingen of interne systemen waarin gevoelige gegevens worden verwerkt, is een vulnerability scan alleen meestal niet voldoende.

Eén grote pentest of meerdere gerichte onderzoeken?

Wanneer een organisatie aangeeft dat “alles” getest moet worden, klinkt dat grondig. Toch is het in de praktijk lang niet altijd de meest effectieve aanpak om alle systemen en omgevingen in één onderzoek mee te nemen.

Een moderne IT-omgeving bestaat vaak uit verschillende onderdelen met ieder hun eigen risico’s. Denk aan internet-facing systemen, API-koppelingen, cloudomgevingen, identiteits- en toegangsbeheer, interne netwerken of gescheiden netwerksegmenten (VLAN’s). Deze onderdelen vragen vaak om een andere aanpak en specialistische kennis.

Daarom is het vaak verstandiger om de werkzaamheden op te delen in meerdere, gerichte onderzoeken. Een logisch startpunt is meestal de internet-facing omgeving, omdat deze direct vanaf internet bereikbaar is. Afhankelijk van de resultaten en de risico’s kan vervolgens worden gekozen om bijvoorbeeld de cloudomgeving, het interne netwerk of een specifiek bedrijfskritisch systeem nader te onderzoeken.

Dat betekent niet dat alles direct onderzocht hoeft te worden. Welke onderdelen prioriteit krijgen, hangt af van de risico’s, de systemen die binnen de scope van het ISMS vallen en de doelstellingen van de organisatie. Ook budget, planning en beschikbare tijd spelen daarbij een rol.

Een gefaseerde aanpak houdt de scope overzichtelijk, maakt de rapportage duidelijker en helpt bij het prioriteren van verbetermaatregelen. Bovendien is richting een auditor beter uit te leggen waarom bepaalde onderdelen wel en andere (nog) niet zijn onderzocht.

Hoe bepaal je de juiste scope?

Een goede pentestscope ontstaat niet uit een standaard checklist. Die ontstaat door te kijken naar de omgeving, de informatie die wordt verwerkt en de risico’s die daarbij horen.

De belangrijkste vragen zijn:

1. Welke informatie moet beschermd worden?

Denk aan persoonsgegevens, cliëntgegevens, financiële gegevens, intellectueel eigendom, klantdata of andere bedrijfskritische informatie.

2. Welke systemen verwerken of ontsluiten die informatie?

Dat kunnen webapplicaties zijn, maar ook API’s, databases, fileservers, cloudomgevingen of SaaS-oplossingen.

3. Welke systemen zijn vanaf internet bereikbaar?

Internet-facing systemen hebben vaak prioriteit, omdat ze direct bereikbaar zijn voor aanvallers.

4. Welke systemen zijn bedrijfskritisch?

Welke systemen zijn onmisbaar voor de dagelijkse bedrijfsvoering? Of welke systemen zouden de grootste impact hebben als ze worden misbruikt of uitvallen?

5. Zijn er recent grote wijzigingen doorgevoerd?

Nieuwe applicaties, cloudmigraties of ingrijpende wijzigingen in de infrastructuur zijn vaak een goed moment om een pentest uit te voeren.

6. Welke systemen vallen binnen de scope van het ISMS?

Niet omdat alles automatisch getest moet worden, maar omdat de pentest logisch moet aansluiten op het ISO 27001-traject.

7. Zijn er aanvullende eisen vanuit een auditor of klant?

Soms zijn er specifieke auditbevindingen of contractuele eisen die invloed hebben op de uiteindelijke scope.

Met deze vragen ontstaat meestal snel een goed beeld van welke systemen prioriteit verdienen. Dat vormt een solide basis voor een pentest die aansluit bij de risico’s van de organisatie én de doelstellingen van het ISO 27001-traject.

Drie praktijkvoorbeelden

De uiteindelijke scope verschilt per organisatie. Onderstaande voorbeelden laten zien hoe dezelfde uitgangspunten in de praktijk tot een heel andere pentestscope kunnen leiden.

Voorbeeld 1: zorg- of welzijnsorganisatie

Een zorg- of welzijnsorganisatie verwerkt gevoelige cliëntgegevens, werkt vanuit meerdere locaties en maakt gebruik van een extern beheerde IT-omgeving.

In zo’n situatie ligt de focus meestal niet op de publieke website, maar op de systemen waarin cliëntgegevens worden verwerkt, de verbindingen tussen locaties en eventuele interne netwerksegmenten.

Afhankelijk van de omgeving kan de scope bijvoorbeeld bestaan uit:

• een externe pentest op internet-facing systemen;
• een beoordeling van Microsoft 365 en Entra ID;
• een interne netwerkpentest;
• een webapplicatie- of API-pentest wanneer gebruik wordt gemaakt van eigen portalen.

Voorbeeld 2: SaaS-bedrijf

Bij een SaaS-bedrijf ligt de nadruk vaak op de applicatie waarmee klanten werken. Daarnaast spelen API’s en de onderliggende cloudomgeving meestal een belangrijke rol.

Een logische scope bestaat dan vaak uit een combinatie van een webapplicatie pentest, API pentest en – wanneer de organisatie verantwoordelijk is voor de cloudinrichting – een cloud pentest. Daarmee worden zowel de applicatie als de onderliggende infrastructuur beoordeeld.

Voorbeeld 3: voortbouwen op bestaande securityonderzoeken

Steeds meer organisaties besteden hun IT grotendeels uit aan een externe IT-partner. Dat betekent echter niet dat automatisch duidelijk is welke onderdelen nog getest moeten worden.

Een goed startpunt is om eerst in kaart te brengen welke securitymaatregelen en onderzoeken al zijn uitgevoerd. Heeft de IT-partner bijvoorbeeld recent een onafhankelijke pentest laten uitvoeren op de beheerde infrastructuur en zijn er actuele securityrapportages beschikbaar? Dan hoeft dat onderdeel mogelijk niet opnieuw volledig onderzocht te worden.

De pentest kan zich vervolgens richten op de onderdelen waarvoor de organisatie zelf verantwoordelijk is of waarvoor nog onvoldoende zekerheid bestaat. Zo voorkom je dubbel werk en besteed je het beschikbare budget aan de risico’s die nog niet onafhankelijk zijn beoordeeld.

Veelgemaakte fouten bij pentesten voor ISO 27001

Fout 1: alleen de website testen omdat die makkelijk te vinden is

Een website is zichtbaar en eenvoudig te scopen. Maar dat maakt hem niet automatisch het belangrijkste systeem.

Niet ieder internet-facing systeem vertegenwoordigt hetzelfde risico. Een klantportaal of API waarin gevoelige gegevens worden verwerkt, verdient vaak een hogere prioriteit dan een informatieve website.

De website kan onderdeel zijn van de pentest, maar mag niet automatisch de volledige scope bepalen.

Fout 2: een vulnerability scan presenteren als pentest

Een vulnerability-scanrapport ziet er vaak indrukwekkend uit. Veel pagina’s, technische details, CVSS-scores en aanbevelingen. Maar een vulnerability scan is geen pentest.

Een auditor kan een vulnerability scan accepteren als onderdeel van vulnerability management, maar als de organisatie wil aantonen dat een belangrijk systeem daadwerkelijk bestand is tegen een aanval, is meestal meer nodig.

Het verschil zit in de aanpak. Een vulnerability scan brengt bekende kwetsbaarheden in kaart, terwijl een pentester onderzoekt of en hoe deze in de praktijk kunnen worden misbruikt en welke impact dat heeft op de organisatie.

Fout 3: alles in één scope stoppen

“Test alles” klinkt grondig, maar leidt vaak tot een onscherpe opdracht.

Een goede scope maakt duidelijk:

• welke systemen worden getest;
• welke systemen buiten scope vallen;
• vanuit welk perspectief wordt getest;
• welke beperkingen gelden;
• wat het doel van de test is.

Zonder die afbakening wordt een pentest moeilijk uitvoerbaar en zijn de resultaten lastiger te interpreteren.

Fout 4: SaaS-systemen willen pentesten die niet van jou zijn

Veel organisaties gebruiken SaaS-oplossingen voor belangrijke processen. Denk aan HR, CRM, zorgdossiers, boekhouding of documentbeheer.

Als de SaaS-leverancier verantwoordelijk is voor de applicatie en hosting, kun je die omgeving meestal niet zomaar zelf laten pentesten. Daarvoor is toestemming van de leverancier nodig. Vaak beschikt de leverancier bovendien al over een ISO 27001-certificering, een SOC 2-rapport of een recente pentestrapportage.

Dat betekent niet dat een SaaS-oplossing buiten de scope valt. Je test alleen niet de applicatie van de leverancier zelf, maar beoordeelt juist de onderdelen waar de organisatie wél verantwoordelijk voor is. Denk aan de inrichting van de tenant, gebruikers- en beheerdersrechten, SSO- en MFA-instellingen, koppelingen met andere systemen en de beschikbare securitydocumentatie van de leverancier.

Fout 5: de externe IT-partner buiten beschouwing laten

Veel organisaties besteden het beheer van hun IT-omgeving uit. Dat kan heel goed werken, maar maakt het bepalen van de juiste pentestscope soms complexer.

De IT-partner beheert vaak AD, firewalls, werkplekken, servers en back-ups. De organisatie blijft echter verantwoordelijk voor haar eigen informatiebeveiliging.

Daarom is het belangrijk om inzicht te krijgen in:

• welke onderdelen door de IT-partner worden beheerd;
• welke securitymaatregelen al zijn ingericht;
• welke securitytesten of vulnerability scans al zijn uitgevoerd;
• of recente rapportages beschikbaar zijn;
• wie verantwoordelijk is voor het opvolgen van risico’s en bevindingen.

Een onafhankelijke pentest kan juist waardevol zijn omdat deze niet door de beheerpartij zelf wordt uitgevoerd. Tegelijkertijd wil je voorkomen dat onderdelen opnieuw worden getest waarvoor al recente en bruikbare onderzoeksresultaten beschikbaar zijn.

Fout 6: alleen testen en daarna niets doen

Voor ISO 27001 is een pentestrapport niet het eindpunt.

De echte waarde zit in de opvolging:

• bevindingen beoordelen;
• risico’s accepteren of oplossen;
• verbetermaatregelen plannen;
• verantwoordelijkheden toewijzen;
• een hertest uitvoeren waar nodig;
• bewijs vastleggen voor auditdoeleinden.

Juist de opvolging laat zien dat een pentest niet alleen is uitgevoerd, maar ook daadwerkelijk heeft bijgedragen aan het verbeteren van de informatiebeveiliging.

Wat verwacht een auditor van een pentest?

Een auditor verwacht meestal niet dat een pentest iedere denkbare kwetsbaarheid heeft gevonden. Waar het vooral om draait, is dat de organisatie een bewuste en risicogebaseerde keuze heeft gemaakt.

In de praktijk zal een auditor onder andere willen kunnen vaststellen:

• Waarom is de pentest uitgevoerd?
• Hoe is de scope bepaald?
• Sluit de scope aan op de risicoanalyse en de scope van het ISMS?
• Zijn de belangrijkste of meest risicovolle systemen meegenomen?
• Zijn de bevindingen beoordeeld en geprioriteerd?
• Zijn passende maatregelen genomen of zijn restrisico’s bewust geaccepteerd?
• Is een hertest uitgevoerd wanneer dat nodig was?
• Wordt de beveiliging periodiek opnieuw beoordeeld of getest, bijvoorbeeld na grote wijzigingen?

Een goed pentestrapport is daarbij een belangrijk hulpmiddel, maar vormt zelden het volledige bewijs. Minstens zo belangrijk is dat de organisatie kan aantonen wat er met de bevindingen is gebeurd.

Denk bijvoorbeeld aan:

• de vastgestelde scope van de pentest;
• de Rules of Engagement;
• het pentestrapport;
• de beoordeling en prioritering van bevindingen;
• vastgelegde verbetermaatregelen;
• een hertestrapport (indien van toepassing);
• documentatie van geaccepteerde restrisico’s.

Zo laat de organisatie zien dat de pentest niet op zichzelf staat, maar onderdeel is van een continu proces van risicobeheersing en verbetering.

Hoe vaak moet je een pentest uitvoeren voor ISO 27001?

ISO 27001 schrijft niet voor hoe vaak een pentest moet worden uitgevoerd. De juiste frequentie hangt af van de risico’s, de aard van de systemen en de veranderingen binnen de organisatie.

Voor veel organisaties is een jaarlijkse pentest een logisch uitgangspunt, zeker wanneer sprake is van internet-facing systemen of bedrijfskritische applicaties. Een vaste jaarlijkse planning is echter niet altijd voldoende. Grote wijzigingen in de IT-omgeving kunnen aanleiding zijn om eerder opnieuw te testen.

Denk bijvoorbeeld aan:

• een nieuwe of ingrijpend gewijzigde webapplicatie;
• een migratie naar AWS, Azure of Google Cloud;
• belangrijke wijzigingen in identiteits- en toegangsbeheer (IAM);
• de introductie van nieuwe API’s of klantportalen;
• grote wijzigingen in de netwerkinfrastructuur;
• ernstige beveiligingsincidenten of kritieke kwetsbaarheden.

In de praktijk kiezen veel organisaties daarom voor een combinatie van maatregelen:

• periodieke pentesten op basis van het risicoprofiel;
• aanvullende pentesten na belangrijke wijzigingen;
• doorlopende vulnerability scans om bekende kwetsbaarheden tijdig te signaleren;
• continuous penetration testing
• hertesten om vast te stellen dat belangrijke bevindingen daadwerkelijk zijn opgelost.

Deze aanpak sluit goed aan bij de risicogebaseerde werkwijze van ISO 27001. Niet de kalender bepaalt wanneer een pentest nodig is, maar de risico’s en veranderingen binnen de organisatie.

Wat moet er in een pentestrapport staan voor ISO 27001?

Voor ISO 27001 is een pentestrapport meer dan een overzicht van technische kwetsbaarheden. Het rapport moet de organisatie helpen om aan te tonen dat de pentest zorgvuldig is uitgevoerd, aansluit op de risico’s en gebruikt wordt binnen het informatiebeveiligingsproces.

Daarom is een duidelijke beschrijving van de scope essentieel. Een auditor moet kunnen vaststellen welke systemen zijn onderzocht, welke onderdelen buiten scope vielen en waarom deze keuze is gemaakt. Zonder die context zijn de resultaten moeilijk te plaatsen.

Daarnaast moet het rapport voldoende informatie bevatten om de bevindingen te kunnen beoordelen en op te volgen. Denk aan een beschrijving van de gebruikte testmethode, de aangetroffen kwetsbaarheden, de impact, aanbevelingen voor herstel en – wanneer van toepassing – de resultaten van een hertest.

Het rapport zelf is echter slechts een onderdeel van het bewijs. Minstens zo belangrijk is dat de organisatie kan laten zien hoe de bevindingen zijn beoordeeld, welke maatregelen zijn genomen en hoe restrisico’s zijn vastgelegd of geaccepteerd. Juist die opvolging laat zien dat de pentest onderdeel is van het risicomanagementproces waarop ISO 27001 is gebaseerd.

Hoe ziet een pentesttraject voor ISO 27001 eruit?

Een pentest binnen een ISO 27001-traject bestaat uit meer dan alleen het uitvoeren van technische testen. Het doel is niet alleen om kwetsbaarheden te vinden, maar ook om aantoonbaar inzicht te krijgen in de risico’s en de opvolging daarvan.

Een goed pentesttraject bestaat daarom meestal uit de volgende onderdelen:

1. Bepalen van de scope

Op basis van de risicoanalyse en de scope van het ISMS wordt vastgesteld welke systemen onderzocht worden. Daarbij wordt niet gekeken naar zoveel mogelijk systemen, maar naar de systemen die het grootste risico vormen voor de organisatie.

2. Vastleggen van de uitgangspunten

Voordat de pentest start, worden de scope, testmethode, planning en spelregels vastgelegd. Zo is vooraf duidelijk welke systemen worden onderzocht en welke buiten de scope vallen.

3. Uitvoeren van de pentest

Afhankelijk van het doel wordt gekozen voor een black box-, grey box- of white box-pentest. Voor veel ISO 27001-trajecten is bij applicaties en API’s een grey box-pentest een logische keuze, omdat daarmee beveiligingsmaatregelen zoals autorisaties, gebruikersrollen en toegangscontrole gerichter kunnen worden beoordeeld.

4. Rapporteren en prioriteren

De resultaten worden vastgelegd in een pentestrapport. Daarbij gaat het niet alleen om de gevonden kwetsbaarheden, maar ook om de impact, de risico’s en de aanbevolen verbetermaatregelen.

5. Opvolgen van de bevindingen

Na de pentest beoordeelt de organisatie welke maatregelen worden genomen, welke risico’s eventueel worden geaccepteerd en of een hertest nodig is. De resultaten worden verwerkt in risicoregisters, verbeterplannen of auditdossiers.

Zo wordt de pentest geen losstaand technisch onderzoek, maar een aantoonbaar onderdeel van de continue verbetering die centraal staat binnen ISO 27001.

Black box, grey box of white box pentest voor ISO 27001?

De keuze voor een black box-, grey box- of white box-pentest hangt af van het doel van de test en de systemen die worden onderzocht.

Een black box-pentest simuleert een aanvaller zonder voorkennis. Dit geeft een realistisch beeld van wat vanaf internet zichtbaar en toegankelijk is, maar biedt niet altijd voldoende diepgang.

Bij een grey box-pentest beschikt de pentester over beperkte voorkennis, zoals testaccounts, API-documentatie of informatie over de architectuur. Daardoor kan gerichter worden onderzocht hoe autorisaties, rollen en gevoelige functionaliteiten zijn ingericht. Voor veel ISO 27001-trajecten is dit een praktische en evenwichtige aanpak.

Een white box-pentest gaat nog een stap verder. Hierbij krijgt de pentester uitgebreide informatie, zoals toegang tot de broncode, configuraties of architectuurdocumentatie. Deze aanpak is vooral geschikt voor kritieke applicaties of complexe omgevingen waarbij maximale diepgang gewenst is.

ISO 27001 schrijft geen specifieke testvorm voor. De keuze hangt af van de risico’s, de systemen die binnen de scope van het ISMS vallen en het doel van de pentest. In de praktijk blijkt een grey box-pentest voor veel organisaties een goede balans te bieden tussen diepgang, efficiëntie en praktische toepasbaarheid.

Hoe wij organisaties helpen bij een ISO 27001 pentest

Bij Securitytest.nl begint een pentest voor ISO 27001 niet met een offerte, maar met een goed gesprek over de organisatie, de IT-omgeving en de risico’s. Pas als duidelijk is welke systemen belangrijk zijn en welke rol zij spelen binnen het ISMS, kun je bepalen welke vorm van securityonderzoek daadwerkelijk waarde toevoegt.

Daarom starten we niet vanuit een standaardpakket of een vooraf bepaalde testvorm. We kijken eerst naar de omgeving, de bestaande securitymaatregelen, eventuele eerdere onderzoeken en de risico’s die de organisatie wil beheersen. Vervolgens bepalen we samen wat de pentest moet opleveren en welke scope daar het beste bij past.

Het resultaat is geen pentest die zo groot mogelijk is, maar een onderzoek dat antwoord geeft op de vragen die er echt toe doen. Welke technische risico’s zijn aanwezig? Welke impact kunnen die hebben op de organisatie? En welke bevindingen verdienen als eerste opvolging?

Zo wordt een pentest niet alleen een technisch onderzoek, maar een aantoonbare bijdrage aan het beheersen van risico’s en de continue verbetering van de informatiebeveiliging.