Veel beveiligingsmaatregelen zien er op papier uitstekend uit, maar blijken in de praktijk minder robuust zodra een echte aanvaller ze op de proef stelt. Een firewallconfiguratie kan volledig en zorgvuldig ontworpen lijken, terwijl toch een ogenschijnlijk klein configuratiegat remote toegang mogelijk maakt. Multi-factor authenticatie kan voor vrijwel alle gebruikers zijn ingeschakeld, terwijl verouderde protocollen en uitzonderingen de bescherming ongemerkt omzeilen. Versleuteling kan correct zijn ingericht, maar als sleutelbeheer onvoldoende is geborgd, blijven gevoelige gegevens alsnog kwetsbaar. Zelfs uitgebreide DLP‑beleidinstellingen bieden geen garantie wanneer gegevens via alternatieve kanalen of onvoorziene werkpatronen het netwerk kunnen verlaten.
Offensieve securitytests, zoals penetration testing en red teaming, leveren een empirische toets: deskundige ethische hackers proberen onder gecontroleerde omstandigheden echt binnen te dringen en dezelfde tactieken, technieken en procedures toe te passen als kwaadwillende actoren. Daarmee wordt zichtbaar welke kwetsbaarheden, combinaties van misconfiguraties en procesfouten een aanvaller daadwerkelijk kan misbruiken. Voor Nederlandse overheidsorganisaties is deze aanpak bijzonder relevant. Zij hebben te maken met geavanceerde dreigingen van statelijke actoren, strikte wettelijke verplichtingen onder meer vanuit NIS2, een hoge mate van publieke verantwoording en de mogelijkheid van ernstige gevolgschade bij een geslaagde aanval, bijvoorbeeld wanneer staatsgeheime of zeer gevoelige persoonsgegevens worden gecompromitteerd.
Penetration testing en red teaming zijn beide vormen van offensieve security, maar met een duidelijk verschillend doel en karakter. Een pentest richt zich primair op het ontdekken en aantonen van technische kwetsbaarheden binnen een vooraf afgebakende scope. Een red team‑oefening simuleert daarentegen een volwaardige, vaak langdurige aanvalscampagne waarin niet alleen techniek, maar ook processen, bewustzijn en besluitvorming worden getest. Het goed begrijpen van dit onderscheid is cruciaal om per organisatie‑ en maturiteitsniveau de juiste vorm van test te kiezen en realistische verwachtingen richting bestuurders en securityteams te schetsen.
Deze gids is geschreven voor CISO’s, security officers en compliance‑verantwoordelijken binnen de overheid die offensieve security structureel willen inzetten. U krijgt een helder beeld van het verschil tussen een klassieke pentest en een red‑team‑oefening, hoe u de scope en doelstellingen scherp formuleert, welke eisen u mag stellen aan een leverancier van ethische hackers en welke afspraken noodzakelijk zijn om productie‑omgevingen veilig te houden. Daarnaast wordt toegelicht hoe u testresultaten moet duiden, welke kwetsbaarheden onmiddellijk actie vereisen en welke risico’s acceptabel of overdraagbaar zijn. Ook komt aan bod hoe u kunt aantonen dat remediatie werkelijk is doorgevoerd, hoe offensieve testen helpen bij het voldoen aan de NIS2‑verplichting om de effectiviteit van maatregelen periodiek te beoordelen en hoe u deze activiteiten verankert in een continu verbeterprogramma voor informatiebeveiliging.
Een red‑team‑oefening levert de meeste inzichten op wanneer de operationele security‑organisatie vooraf niet wordt geïnformeerd over het exacte moment en de gekozen aanvalspatronen. Bij een aangekondigde pentest weet het SOC wanneer het moet opletten, worden tijdelijk extra experts ingeroosterd en worden systemen soms vooraf extra aangescherpt. Dat geeft een vertekend beeld van de werkelijke detectie‑ en responskracht. Een grote Nederlandse overheidsorganisatie voerde een onaangekondigde red‑team‑oefening uit waarin een extern team met beperkte randvoorwaarden een geavanceerde dreigingsactor nabootste. Binnen 48 uur wist het team via gerichte phishing en privilege‑escalatie domeinbeheerdersrechten te verkrijgen en in de daaropvolgende dagen kon een grote hoeveelheid gevoelige gegevens ongemerkt worden verzameld en voorbereid voor exfiltratie. Het SOC miste meerdere indicatoren, playbooks bleken onvolledig en de afstemming tussen security‑, juridisch en communicatieteam was onvoldoende. Wanneer de oefening vooraf was aangekondigd, was dit beeld waarschijnlijk veel rooskleuriger geweest. Door te testen onder zo realistisch mogelijke omstandigheden ontstond een eerlijk vertrekpunt voor verbetering. Wel blijft het essentieel om duidelijke veiligheidsafspraken te maken, risico’s voor continuïteit en integriteit van systemen te beperken en het hoogste management vooraf te informeren, terwijl het uitvoerende securityteam de oefening niet ziet aankomen.
Penetration testing‑methodologieën: gestructureerd kwetsbaarheden ontdekken
Een externe netwerk‑pentest bootst een aanvaller na die vanaf het internet, zonder voorkennis of interne toegang, probeert binnen te dringen in de omgeving van een organisatie. De scope bestaat doorgaans uit publiek toegankelijke websites, remote‑access‑voorzieningen zoals VPN‑ en RDP‑gateways, e‑maildiensten en publiek benaderbare cloudresources. De kracht van deze aanpak ligt in de systematische methodiek. De test begint vrijwel altijd met een verkennende fase waarin zoveel mogelijk informatie over de doelorganisatie wordt verzameld zonder direct aan te vallen. Denk aan het in kaart brengen van domeinnamen en subdomeinen, het achterhalen van gebruikte technologieën via publieke bronnen, het analyseren van eerder gelekte inloggegevens en het zoeken naar onbedoeld gepubliceerde documenten of configuratiebestanden. Deze informatie vormt het fundament voor de volgende stappen, omdat een aanvaller pas echt effectief kan zijn wanneer hij begrijpt hoe de digitale infrastructuur is opgebouwd.
Daarna volgt een fase waarin actiever wordt gescand en geanalyseerd welke systemen bereikbaar zijn en welke diensten zij aanbieden. Met behulp van geautomatiseerde tools worden poorten gescand, worden webapplicaties en API’s onderzocht en wordt vastgesteld welke softwareversies in gebruik zijn. Deze resultaten worden vervolgens vergeleken met bekende kwetsbaarheden in openbare databases, waarna een eerste inschatting kan worden gemaakt van de kans dat een aanvaller misbruik kan maken van specifieke zwakheden. Voor overheidsorganisaties is het cruciaal dat deze scans zorgvuldig worden afgestemd met beheerafdelingen, zodat onbedoelde verstoringen worden vermeden en monitoringteams weten hoe zij legitiem testverkeer moeten interpreteren.
De echte kern van een pentest ligt in de daaropvolgende exploitatie‑ en post‑exploitatie‑fase. Hier proberen de testers daadwerkelijk toegang te verkrijgen tot systemen of gegevens door de gevonden kwetsbaarheden gecontroleerd te misbruiken. Een succesvolle exploit levert een eerste voet tussen de deur op, bijvoorbeeld in de vorm van een laag‑geprivilegieerde gebruikerssessie of beperkte toegang tot een server. Vanuit die positie wordt onderzocht in hoeverre de aanvaller zich zijwaarts kan verplaatsen naar andere systemen, privileges kan verhogen en aanvullende informatie kan verzamelen, zoals wachtwoordhashes of sessietokens. In een professionele pentest wordt daarbij zorgvuldig bewaakt dat geen blijvende schade ontstaat: gevoelige gegevens worden niet echt geëxfiltreerd maar slechts aangetoond, en potentieel destructieve acties worden beperkt tot het strikt noodzakelijke bewijsniveau. Dit wordt vooraf vastgelegd in duidelijke rules of engagement die zijn afgestemd met de organisatie.
Waar een pentest zich voornamelijk richt op het aantonen van technische kwetsbaarheden binnen een afgesproken scope, gaat een red‑team‑oefening een flinke stap verder. Daarbij wordt een geavanceerde tegenstander nagebootst die alle beschikbare middelen inzet om een strategisch doel te bereiken, bijvoorbeeld het verkrijgen van toegang tot een specifiek informatiesysteem of het ongemerkt manipuleren van kritieke data. Naast technische aanvallen kan het red team gebruikmaken van social‑engineeringtechnieken zoals phishing, het misbruiken van vertrouwensrelaties in de keten of zelfs fysieke pogingen om toegang te krijgen tot kantoorlocaties. De oefening loopt vaak meerdere weken of maanden door, zodat ook langzame, sluimerende aanvalspatronen kunnen worden nagebootst die kenmerkend zijn voor statelijke actoren.
Het primaire doel van een red‑team‑oefening is niet alleen het vinden van kwetsbaarheden, maar het toetsen van de totale weerbaarheid van de organisatie. Daarbij wordt gekeken of verdachte signalen tijdig worden gedetecteerd, of meldingen op de juiste manier worden geanalyseerd en opgevolgd en of management en crisisteams de juiste beslissingen nemen wanneer een incident wordt vermoed. Het resultaat is geen eenvoudige lijst met technische bevindingen, maar een rijk beeld van waar detectieketens goed werken, waar beslissingsprocessen vertragen en welke organisatorische afhankelijkheden in de praktijk knelpunten blijken. Voor overheidsorganisaties levert dit inzicht dat ver voorbij gaat aan een traditionele auditchecklist en helpt het bestuurders en securityteams om prioriteiten te stellen die zowel technologie, processen als menselijk gedrag omvatten.
Omdat een red‑team‑oefening qua impact en gevoeligheid dicht tegen een echte aanval aanligt, zijn grondige voorbereidingen essentieel. Juridische toestemming, duidelijke afspraken met het hoogste management en een vooraf vastgelegd escalatiemechanisme zijn noodzakelijk om misverstanden met bijvoorbeeld opsporingsdiensten of leveranciers te voorkomen. Vaak wordt met een afgesproken stopwoord gewerkt waarmee de oefening onmiddellijk kan worden onderbroken als de risico’s te groot worden of onverwachte afhankelijkheden aan het licht komen. Door deze combinatie van realisme en beheersing kan red teaming uitgroeien tot een van de meest waardevolle instrumenten om de werkelijke cyberweerbaarheid van de Nederlandse overheid meetbaar te maken.
Offensieve securitytesten via pentesten en red‑team‑oefeningen geven Nederlandse overheidsorganisaties de mogelijkheid om met feiten aan te tonen hoe robuust hun verdediging in de praktijk is. Niet het beleid op papier, maar het gedrag van systemen, processen en mensen onder druk bepaalt uiteindelijk of een aanvaller succesvol is. Door regelmatig te testen wordt zichtbaar welke technische kwetsbaarheden, configuratie‑afwijkingen en procesfouten als eerste moeten worden aangepakt en welke verbeteringen in detectie en respons het meeste effect hebben. Daarmee ontstaat een direct verband tussen geïnvesteerde middelen en aantoonbare risicoreductie, iets waar bestuurders, toezichthouders en de maatschappij terecht om vragen.
De investering in een professionele pentest of red‑team‑oefening verdient zich vaak snel terug. Eén kritieke kwetsbaarheid in een extern systeem, die tijdens een test wordt ontdekt en vervolgens wordt verholpen, kan het verschil betekenen tussen een gecontroleerd verbetertraject en een omvangrijk incident met hoge herstelkosten, reputatieschade en juridische gevolgen. Door offensieve testen planmatig in te bedden, bijvoorbeeld met een jaarlijkse externe pentest voor alle organisaties, periodieke red‑team‑oefeningen voor hoog‑risicodomeinen en continue geautomatiseerde scans als aanvulling, ontstaat een cyclisch proces van toetsen, verbeteren en opnieuw verifiëren. Zo wordt offensive security geen eenmalige exercitie, maar een structureel onderdeel van de weg naar een veilige cloudomgeving volgens de Nederlandse Baseline voor Veilige Cloud.