We gebruiken cookies om te begrijpen hoe de site wordt gebruikt en om uw ervaring te verbeteren. Privacybeleid

    Skip to main content

    31 oktober 2026 · 10 min leestijd · Door Michael van Mameren, Lead Penetration Tester (OSCP)

    Purple teaming: wat een purple team oefening is, hoe zij verloopt en wanneer zij een red team of penetratietest overtreft

    Een red team vertelt u of een aanvaller het doel kan bereiken. Een purple team vertelt u, techniek voor techniek, of uw SOC die poging had gezien, en dicht de gaten terwijl de aanvallers nog in de kamer zitten. Deze gids legt uit hoe een purple team oefening is opgebouwd, wat zij vereist, wat zij oplevert en waar zij staat naast red teaming, penetratietesten en de threat-led testcyclus van DORA.

    Plan een purple team oefening

    Wat purple teaming is

    Purple teaming is een gezamenlijke beveiligingsoefening waarin een aanvallend team (red) specifieke aanvalstechnieken uitvoert in de omgeving van een organisatie, terwijl het verdedigende team (blue, meestal het SOC of een MDR-aanbieder) in realtime meekijkt of de techniek is gelogd, gedetecteerd, gealarmeerd en opgevolgd. Waar het red team een gat vindt, stemmen beide teams samen de telemetrie of detectielogica af en wordt de techniek opnieuw uitgevoerd tot zij wordt gevangen. De kleur is de kern: red en blue in dezelfde ruimte, op dezelfde tijdlijn, tegen dezelfde lijst technieken.

    Dat onderscheidt purple teaming van een red-team-opdracht, waarin het aanvallende team wekenlang verborgen werkt aan een bedrijfsdoel en de verdedigers niet zijn ingelicht, en van een penetratietest, die zoekt naar kwetsbaarheden in plaats van naar detectiegaten. Een purple team oefening probeert niet te winnen. Zij probeert de dekking van detectie en respons te meten en te verbeteren tegen de technieken die een voor u relevante tegenstander daadwerkelijk zou gebruiken, en het SOC aan het einde van de week achter te laten met afgestemde regels en een gedocumenteerde dekkingskaart in plaats van een rapport dat een maand later wordt gelezen.

    Het gemeenschappelijke referentiekader is MITRE ATT&CK. Elke techniek in de oefening wordt aangeduid met haar ATT&CK-ID (T1003.001 voor het dumpen van inloggegevens uit LSASS-geheugen, T1021.002 voor laterale beweging via SMB-beheershares, T1059.001 voor PowerShell-uitvoering, T1486 voor gegevensversleuteling als impact), wat red, blue en management één vocabulaire geeft voor wat is getest, wat is gedetecteerd en wat nog niet. Onze uitleg over red teaming beschrijft het verborgen alternatief; deze pagina gaat over het gezamenlijke.

    Hoe een purple team oefening verloopt

    Een gebruikelijke opdracht bestaat uit een tot twee weken gezamenlijke sessies, voorafgegaan door een week voorbereiding. De onderstaande lus draait voor elke techniek binnen de scope.

    1. Bepaal de dreiging en selecteer technieken

    Vertrek vanuit de tegenstanders die voor u tellen: de ransomwaregroepen die actief zijn in uw sector, de actoren die uw threat-intelligence-aanbieder signaleert, of de technieken uit een recent incident. Koppel hun gedrag aan ATT&CK en selecteer 25 tot 60 technieken over initial access, execution, persistence, privilege escalation, credential access, lateral movement, collection, exfiltration en impact. Prioriteer op waarschijnlijkheid en op wat uw maatregelen beweren te dekken.

    2. Bouw de testgevallen

    Voor elke techniek bereidt het red team een of meer concrete procedures voor: het exacte commando, de tool of payload, de host waarop het draait, het account dat wordt gebruikt, de verwachte artefacten en de verwachte detectie. Open testbibliotheken zoals Atomic Red Team en MITRE CALDERA bieden een basis; de waardevolle procedures zijn die welke zijn aangepast aan uw omgeving en aan hoe de gekozen tegenstander werkelijk opereert.

    3. Voer uit, met het blue team dat meekijkt

    Het red team voert elke procedure uit en kondigt haar aan. Het blue team controleert in volgorde: heeft de endpoint- of netwerksensor telemetrie gegenereerd, heeft die telemetrie de SIEM of XDR bereikt, is een detectieregel afgegaan, heeft een alarm een analist bereikt, en zou het draaiboek van de analist tot de juiste respons hebben geleid. Elke stap wordt met tijdstempels als geslaagd of mislukt vastgelegd.

    4. Stem af en herstel

    Een mislukking in een van de stappen wordt ter plekke een gezamenlijke taak: het ontbrekende auditbeleid of Sysmon-event inschakelen, de logdoorsturing herstellen, de detectieregel schrijven of aanpassen (vaak als Sigma, daarna vertaald naar de taal van de SIEM), de ernst van het alarm verhogen of het draaiboek bijwerken. Detection engineering gebeurt tijdens de oefening, niet in een backlog achteraf.

    5. Voer opnieuw uit en leg vast

    Het red team voert de procedure opnieuw uit. Wordt zij nu van begin tot eind gedetecteerd, dan wordt de techniek met bewijs als gedekt gemarkeerd; zo niet, dan loopt de lus door of wordt het gat vastgelegd met een eigenaar en een datum. De gemiddelde tijd tot detectie en tot respons worden voor elke techniek vóór en na afstemming gemeten, wat het management een voor-en-na-cijfer geeft in plaats van een lijst aanbevelingen.

    6. Rapporteer de dekking, niet alleen de bevindingen

    De oplevering is een detectiedekkingskaart over de ATT&CK-matrix (doorgaans in ATT&CK Navigator-formaat), de lijst van aangemaakte of afgestemde regels, de telemetriegaten met hersteleigenaren, de MTTD en MTTR per techniek vóór en na, en een geprioriteerd plan voor de technieken die ongedekt blijven.

    Wat een purple team oefening van u vraagt

    Purple teaming versterkt een detectiecapaciteit. Zij kan er geen uit het niets scheppen. Dit zijn de voorwaarden die wij bij de scoping controleren.

    • Een detectie- en responsfunctie: een intern SOC, een MDR-aanbieder of een MSSP met een detectiemandaat, met analisten die aan de sessies kunnen deelnemen
    • Endpoint-telemetrie (EDR of XDR, of minimaal Sysmon en Windows event forwarding) op de hosts binnen de scope, en een SIEM of dataplatform dat het blue team tijdens de oefening kan bevragen
    • Identiteits- en netwerktelemetrie: auditlogs van domeincontrollers, authenticatielogs van de identity provider, DNS- en proxylogs, en firewall- of NDR-gegevens waar laterale beweging wordt getest
    • De mogelijkheid om tijdens de week zaken te wijzigen: auditbeleid, logdoorsturing, detectieregels en alarmroutering, met wijzigingsbeheer dat dit toestaat
    • Een representatieve omgeving: productie, of een testsegment dat de productietelemetrie spiegelt, met testaccounts en -hosts die het red team mag gebruiken
    • Threat-intelligence-input, van uw aanbieder of van ons, om de techniekselectie te verankeren in de tegenstanders die voor uw sector relevant zijn
    • Juridische en operationele goedkeuring, een lijst van wat buiten bereik blijft, en een bestuurlijk sponsor die handelt op de dekkingsgaten die de oefening vastlegt

    Wat u aan het einde heeft

    De uitkomsten zijn operationeel, niet adviserend. De meeste staan in productie voordat de oefening is afgelopen.

    Detectiedekkingskaart

    Een ATT&CK-matrix ingekleurd per techniek: van begin tot eind gedetecteerd, telemetrie aanwezig maar geen detectie, geen telemetrie. De eerste eerlijke kaart die de meeste organisaties hebben van wat hun maatregelen werkelijk zien.

    Afgestemde en nieuwe detectieregels

    Regels die tijdens de oefening zijn geschreven of aangepast, gedocumenteerd met de techniek die zij dekken, de testprocedure die ze valideert en de uitgevoerde beoordeling op valse positieven.

    MTTD en MTTR per techniek

    Gemiddelde tijd tot detectie en tot respons, gemeten vóór en na afstemming, zodat de verbetering in minuten wordt getoond in plaats van in proza beweerd.

    Register van telemetriegaten

    Elke host, logbron of sensor die het bewijs dat zij had moeten leveren niet produceerde of doorstuurde, met de vereiste configuratiewijziging en een eigenaar.

    Bijgewerkte draaiboeken

    Analistenrunbooks herzien waar de oefening liet zien dat het alarm wel afging, maar de respons verkeerd, traag of onvolledig zou zijn geweest.

    Een herhaalbare testbibliotheek

    De gebruikte procedures, verpakt zodat uw team of uw MDR-aanbieder ze opnieuw kan uitvoeren na elke significante wijziging in de omgeving of de detectiestack.

    Purple team versus red team versus penetratietest

    Drie oefeningen, drie vragen. Volwassen programma's draaien alle drie in verschillende cycli.

    AspectPenetratietestRed teamPurple team
    Beantwoorde vraagWelke kwetsbaarheden bestaan in deze scope en hoe ernstig zijn zeKan een realistische tegenstander een bedrijfsdoel bereiken zonder te worden gestoptWelke aanvalstechnieken detecteert en beantwoordt ons SOC, en hoe dichten we de gaten
    Verdedigers ingelichtDoorgaans welNiet; verborgenVolledig betrokken; gezamenlijk
    ScopeVastgestelde systemen en applicatiesDoelgericht, hele organisatieVastgestelde lijst ATT&CK-technieken tegen vastgestelde hosts en logbronnen
    DuurDagen tot enkele wekenVier tot twaalf weken inclusief threat intelligenceEen tot twee weken gezamenlijke sessies plus voorbereiding
    Belangrijkste resultaatKwetsbaarheidsbevindingen en herstelAanvalsverhaal, beoordeling van detectie en responsDekkingskaart, afgestemde regels, MTTD/MTTR-verschillen, telemetriegaten
    Vereiste volwassenheidGeenEen detectiecapaciteit die het verborgen testen waard isEen SOC of MDR met telemetrie en de mogelijkheid regels te wijzigen
    Beste momentJaarlijks en na wijzigingen, voor elke organisatieElke een tot twee jaar zodra detectie bestaatNa een red team of incident, na SIEM- of EDR-wijzigingen, en vóór een TLPT

    Wanneer u een purple team oefening uitvoert

    De duidelijkste aanleiding is een red-team-rapport dat laat zien dat de tegenstander onopgemerkt is binnengewandeld. Een red team bewijst dat het gat bestaat; een purple team dicht het, techniek voor techniek, samen met de mensen die het SOC beheren. De tweede aanleiding is een wijziging in de detectiestack: een nieuwe EDR, een SIEM-migratie, een nieuwe MDR-aanbieder of een overstap naar een nieuw identiteitsplatform zetten de detectiedekking alle terug op nul, en een purple-oefening is hoe u ontdekt wat de nieuwe stack ziet voordat een aanvaller dat doet. De derde is een incident: de technieken van de aanvaller opnieuw afspelen tegen de afgestemde omgeving is de meest directe manier om de raad van bestuur te laten zien dat dezelfde inbraak nu zou worden gevangen.

    Purple teaming is niet de eerste oefening die een organisatie moet inkopen. Zonder SOC, zonder MDR en zonder telemetrie legt de week dat feit uitgebreid vast en verbetert zij niets; een penetratietest en een managed detection and response-dienst komen eerst. Onze vergelijking van MSSP-, MDR- en SOC-modellen beschrijft de opties voor organisaties die die capaciteit opbouwen.

    Purple teaming in DORA threat-led penetration testing en TIBER-EU

    Purple teaming is voor financiële entiteiten verschoven van goede praktijk naar toezichtsverwachting. Het TIBER-EU-raamwerk, dat de Europese Centrale Bank in 2025 heeft bijgewerkt om aan te sluiten op DORA, deelt een threat-led penetration test in een voorbereidingsfase, een testfase (threat intelligence gevolgd door een verborgen red team) en een afsluitfase. De afsluitfase omvat een replay van de aanval met het blue team en een purple-teaming-oefening, waarin het red team en de verdedigers van de entiteit de gebruikte technieken doorlopen, bevestigen wat wel en niet is gedetecteerd en verbeteringen uitwerken voordat het eindrapport en het herstelplan met de autoriteit worden vastgesteld. De technische reguleringsnormen van DORA voor TLPT beschrijven dezelfde purple teaming in de afsluitfase voor financiële entiteiten die onder artikel 26 voor TLPT zijn aangewezen. In Nederland loopt het proces als TIBER-NL onder De Nederlandsche Bank.

    Voor aangewezen entiteiten betekent dit dat de purple-teaming-component vanaf het begin van de TLPT-cyclus wordt gepland, met de deelname van het SOC of de MDR-aanbieder vastgelegd in de scope. Voor financiële entiteiten die niet voor TLPT zijn aangewezen, en voor organisaties in andere NIS2-sectoren, levert een zelfstandige purple team oefening dezelfde verbetering van detectie zonder het toezichtsproces eromheen. Onze DORA-pentestgids legt de verplichtingen van artikel 24 tot 27 volledig uit.

    Hoe HackersHub purple team oefeningen uitvoert

    Onze purple team opdrachten worden geleid door dezelfde OSCP- en OSEP-gecertificeerde operators die onze verborgen red-team-opdrachten uitvoeren, en dat telt, omdat de procedures moeten lijken op echt aanvallersvakmanschap en niet op de standaardinstellingen van een testtool. Wij werken met uw interne SOC of met uw MDR- of MSSP-aanbieder als volwaardige deelnemer: hun analisten zitten in de sessies, zien de technieken terwijl ze worden uitgevoerd en zijn eigenaar van de regelwijzigingen. Gebruikt u onze managed detection and response-dienst, dan is de purple-oefening de manier waarop wij onze eigen dekking van uw omgeving toetsen aan uw dreigingsprofiel. De techniekselectie is verankerd in threat intelligence voor uw sector, elke procedure is gekoppeld aan ATT&CK, en de opleveringen zijn de dekkingskaart, de afgestemde regels, het register van telemetriegaten en de MTTD en MTTR per techniek vóór en na.

    Voor financiële entiteiten leveren wij de purple-teaming-component van de TIBER-EU-afsluitfase naast de red-team-fase, met dezelfde operators, zodat niets verloren gaat tussen de verborgen test en de gezamenlijke replay. Scope en inspanning worden na een scopinggesprek schriftelijk vastgelegd; wij publiceren geen prijzen. Michael van Mameren leidt de offensieve praktijk en wordt in elk rapport bij naam genoemd.

    Veelgestelde vragen

    Ontdek wat uw SOC werkelijk ziet

    Een scopinggesprek van 30 minuten brengt uw dreigingsprofiel en detectiestack in kaart en stelt vast of uw SOC of MDR-aanbieder klaar is voor een purple team oefening. U ontvangt een schriftelijke scope met operators bij naam en de te testen technieken. Praat met een expert.