📋 Voor de boardroom Een TLPT is een traject van negen maanden met een aanzienlijk budget. De kwaliteit van het Red Team is belangrijk, en de strenge kwalificatievereisten in TIBER-EU bestaan om goede reden. Maar in onze ervaring, en op basis van wat we horen uit de industrie, hebben de meest ingrijpende valkuilen te maken met voorbereiding, governance en providerselectie. Deze blog identificeert de meest voorkomende valkuilen in alle drie de fasen van het TIBER-EU proces en legt uit hoe je het goed aanpakt. De beslissingen die in de eerste weken van een TLPT-traject worden genomen, bepalen vaak of de bevindingen strategisch of oppervlakkig zijn.
Introductie
Een TLPT mislukt niet omdat het Red Team niet goed genoeg was. Slechte Red Team kwaliteit is een reëel risico, en de strenge kwalificatievereisten in TIBER-EU bestaan om precies die reden. Maar in onze ervaring zijn de meest voorkomende oorzaken van mislukking organisatorisch: de organisatie was niet klaar, de verkeerde provider werd geselecteerd, het Control Team was overweldigd, of de bevindingen kwamen nooit verder dan de bevdingenoverdracht.
We hebben al deze patronen gezien. Sommige worden openlijk besproken in de industrie. Andere niet, omdat het toegeven ervan slecht zou vallen op de betrokken partijen. Deze blog behandelt beide.
We hebben de valkuilen per fase georganiseerd. Niet omdat ze altijd afzonderlijk voorkomen, maar omdat het begrijpen van waar in het proces dingen misgaan het makkelijker maakt om ze te voorkomen.
Voorbereidingsfase
Valkuil 1: Scope die uitsluit wat er het meest toe doet
De scope van een TLPT wordt gedefinieerd in het Scope Specification Document (SSD), het formele document dat het Control Team opstelt om de Critical or Important Functions (CIFs) van de organisatie te beschrijven, de onderliggende systemen en services die deze ondersteunen, en de vlaggen die het Red Team moet proberen te bereiken. Dit document vormt de basis van de hele test: de TIP gebruikt het om het Targeted Threat Intelligence Report te ontwikkelen, en de RTT gebruikt het om de aanvalsscenario's te bouwen.
Eén versie van deze valkuil is het te conservatief definiëren van de scope. Organisaties sluiten soms systemen uit die ze te gevoelig vinden om te testen, te complex om toe te voegen, of te verstorend om aan te vallen. De Test Manager daagt scopebeslissingen actief uit en zal terugduwen waar kritieke functies zonder goede reden worden uitgesloten. Uiteindelijk heeft de organisatie echter het laatste woord, en dat is waar het risico ligt. Het resultaat van een te smalle scope is een TLPT die niet test wat er werkelijk toe doet.
De tweede, minder zichtbare versie van deze fout is het nalaten om externe leveranciers in de scope op te nemen. Supply chain aanvallen zijn een van de meest ingrijpende aanvalsvectoren in alle sectoren, en de financiële sector is daarop geen uitzondering. Als een kritieke functie gedeeltelijk of volledig is uitbesteed aan een ICT-leverancier, maken de systemen, processen en mensen van die leverancier deel uit van het aanvalsoppervlak. TIBER-EU vereist expliciet de opname van ICT-leveranciers waar ze kritieke functies ondersteunen. Het toevoegen ervan vergroot wel de complexiteit van de test. Maar zoals we in Blog 2 bespraken, bouwt een goed uitgevoerde pre-TLPT strategie precies de relaties en vertrouwdheid met de omgevingen van derde partijen op die dit beheersbaar maakt. Ze weglaten vermindert het risico niet. Het betekent alleen dat het risico verborgen blijft totdat een echte aanvaller het vindt.
De fix: het SSD is grondig, eerlijk over het werkelijke aanvalsoppervlak van de organisatie, en includeert kritieke afhankelijkheden van derde partijen vanaf het begin. Dit kost meer inspanning en meer interne afstemming, maar het is de enige manier om de TLPT betekenisvol te maken.
Valkuil 2: De SSD-voorbereiding onderschatten
Het SSD is geen formulier om in te vullen. Het vereist dat het Control Team een gestructureerde analyse uitvoert van welke functies kritiek zijn, welke systemen die functies ondersteunen, hoe een realistische inbreuk op elk systeem eruitziet, en welke vlaggen het Red Team moet bereiken als bewijs van succesvolle compromittering.
Organisaties onderschatten consequent hoeveel tijd en interne expertise dit vereist. Een Control Team dat operationele IT-kennis mist, zal moeite hebben om een SSD te produceren dat specifiek genoeg is om nuttig te zijn. Als de vlaggen vaag zijn, zal de threat intelligence vaag zijn. Als de threat intelligence vaag is, zullen de scenario's generiek zijn. En een TLPT gebouwd op generieke scenario's vertelt je weinig.
Ons advies: neem iemand met praktische kennis van de kritieke systemen op in het Control Team, niet alleen senior leiderschap. De CISO en het boardlid zijn essentieel voor governance en besluitvorming. Maar de persoon die daadwerkelijk weet hoe de betalingsinfrastructuur of het kernbankingsysteem werkt, is degene die het SSD specifiek genoeg kan maken om ertoe te doen. Een belangrijke kanttekening: iedereen die aan het Control Team wordt toegevoegd vanwege technische expertise moet de vertrouwelijkheidsvereiste volledig begrijpen. Een SME die onbedoeld signaleert aan collega's dat er iets ongewoons op komst is, kan de hele test compromitteren.
De fix: houd het Control Team klein, maar zorg ervoor dat het de juiste expertise bevat. Neem iemand met praktische kennis van de kritieke systemen op vanaf het begin. En zorg ervoor dat elk lid van het Control Team de vertrouwelijkheidsvereiste volledig begrijpt voordat ze worden ingelicht.
Valkuil 3: Leg-ups niet op tijd geregeld
Leg-ups zijn vooraf geregelde condities die het Red Team tijdens de test wanneer nodig ondersteunen: een niet-traceerbare laptop, een standaard gebruikersaccount, vooraf vastgestelde netwerktoegang, of specifieke systeemrechten die de volgende fase van een aanval mogelijk maken. Ze kunnen dienen als startpositie voor een scenario, maar bieden net zo vaak een cruciale tussenstap mid-test, waardoor het Red Team kan doorschakelen naar een meer geavanceerde fase van de kill chain zonder vaart te verliezen.
Wat leg-ups bijzonder uitdagend maakt is de geheimhoudingsvereiste. De mensen die ze moeten regelen, IT-teams, inkoop, facilitaire diensten, kunnen vaak niet worden verteld waarom ze nodig zijn of waarvoor ze worden gebruikt. In goed beveiligde organisaties maken bestaande controlemechanismen en goedkeuringsprocessen het nog moeilijker om leg-ups stilletjes te regelen, wat precies het soort omgeving is dat een TLPT is ontworpen om te testen. Dat vereist zorgvuldige orkestratie door het Control Team, dat manieren moet vinden om realistische toegang en apparaten te regelen zonder te onthullen dat er een test plaatsvindt.
Hoewel sommige leg-ups voorspelbaar genoeg zijn om van tevoren te regelen, kan de definitieve lijst pas worden bevestigd nadat het Targeted Threat Intelligence rapport is opgeleverd. Daarom is voldoende tijd tussen de TI-fase en het begin van de Red Team-fase cruciaal. In de praktijk zijn er meerdere weken nodig om de threat intelligence te vertalen naar een aanvalsplan en de benodigde leg-ups te regelen. Organisaties die agressieve tijdlijnen instellen en vaart willen houden, comprimeren vaak precies dit venster, met voorspelbare gevolgen.
Wanneer leg-ups niet op tijd kunnen worden geregeld, verzoeken organisaties soms om de test te pauzeren. De Test Manager zal dit doorgaans ondersteunen om de kwaliteit van de beoordeling te beschermen. In de praktijk creëert de vertraging echter echte druk op de planning en tijdlijn van het Red Team, en die druk verdwijnt zelden, ze verschuift alleen.
De fix: begin vroeg. Gebruik de pre-TLPT periode om te identificeren welke leg-ups waarschijnlijk nodig zullen zijn, breng in kaart wie ze moet regelen, en bouw de interne processen op om dit discreet te doen. Bouw voldoende tijd in tussen de TI-fase en het begin van de Red Team-fase. Behandel dat venster als vast, niet als ruimte die kan worden gecomprimeerd wanneer tijdlijnen krap worden.
Valkuil 4: Juridische en compliance voorbereiding onderschat
Een TLPT omvat professionele aanvallers die opereren tegen live productiesystemen. Voordat dat gebeurt, moet er een aanzienlijke hoeveelheid juridisch voorwerk zijn gedaan: scopingovereenkomsten, aansprakelijkheidsregelingen, rules of engagement, geheimhoudingsovereenkomsten, en de formele autorisatiedocumenten die het Red Team juridische dekking geven om te opereren. In TIBER-EU termen omvat dit de "get out of jail" documentatie die definieert wat is toegestaan en onder welke omstandigheden.
In onze ervaring onderschatten organisaties consequent hoe lang dit duurt. Juridische teams zijn niet vertrouwd met dit type engagement. Inkoopprocessen zijn er niet voor ontworpen. En elke dag die wordt besteed aan het wachten op juridische goedkeuring is een dag die de test vertraagt, tijdlijnen comprimeert en druk verhoogt op de fasen die volgen.
De fix: juridische voorbereiding start parallel aan providerselectie, niet erna. Betrek het juridische en compliance team vroeg bij het proces. Ze hebben tijd nodig om te begrijpen wat ze autoriseren.
Testfase
Valkuil 5: Het Blue Team begint iets te vermoeden
Het gebeurt tijdens tests. Op een gegeven moment tijdens een traject van negen maanden merkt iemand iets ongewoons op. Een anomalie in het netwerkverkeer. Een ticket dat er niet goed uitziet. Een collega die iets terloops noemt.
De vraag is niet of dit zal gebeuren. De vraag is of het Control Team er een plan voor heeft. Het hebben van het hoofd van het Blue Team in het Control Team helpt hierbij: incidenten lopen van nature via hen, waardoor het veel gemakkelijker is om een geloofwaardige, natuurlijke reactie te geven op elke anomalie die het Blue Team markeert, in plaats van te vertrouwen op iemand met wie het Blue Team zelden contact heeft.
Zonder een voorbereide reactie staat het Control Team voor een onmogelijke keuze in real time: de anomalie erkennen en riskeren de test te compromitteren, of hem negeren en mogelijk toestaan dat het Blue Team een echte detectiemogelijkheid mist. Geen van beide is acceptabel. De juiste reactie, een vooraf afgesproken dekmantel en escalatiepad voor precies deze situatie, moet worden vastgesteld voordat de test begint.
De fix: het Control Team heeft een gedocumenteerd reactieplan voor Blue Team-vermoedens voordat de Red Team-fase begint. Dat plan moet worden beoordeeld door de Test Manager.
Valkuil 6: Escalatieprotocollen die op papier bestaan maar in de praktijk falen
Het Red Team Test Plan (RTTP) is verplicht een duidelijk escalatieprotocol te bevatten: wat er gebeurt als het Red Team toegang krijgt tot een systeem dat werkelijk kritiek is voor de bedrijfscontinuïteit, of als er iets misgaat tijdens de uitvoering. De Test Manager beoordeelt en keurt dit goed voordat de test begint. In onze ervaring krijgen Red Teams tijdens een TLPT regelmatig toegang tot systemen die werkelijk kritiek zijn voor de bedrijfscontinuïteit, dus dit is geen hypothetische situatie.
De valkuil is niet de afwezigheid van een protocol. Het is de kloof tussen wat op papier staat en wat er in de praktijk gebeurt. Zelfs wanneer het escalatiepad duidelijk is gedocumenteerd en afgesproken, heeft de Control Team Lead mogelijk onvoldoende autoriteit om ervoor te zorgen dat het wordt gevolgd wanneer het moment aanbreekt. Dit wordt bijzonder complex wanneer derde partijen betrokken zijn: een beslissing om de test te pauzeren of te stoppen kan coördinatie vereisen over organisatorische grenzen heen die niet volledig van tevoren zijn doordacht.
De fix: escalatiedrempels en beslissingsprotocollen worden gedocumenteerd voordat de test begint. De CTL heeft een directe, beveiligde verbinding met de Test Manager en waar nodig met senior management. De autoriteit van de CTL om real-time beslissingen te nemen, ook over grenzen van derde partijen heen, wordt expliciet afgesproken voordat de test begint. Dagelijkse check-ins tussen het Red Team en het Control Team zijn het operationele mechanisme dat dit ritme gedurende de hele test intact houdt.
Valkuil 7: Te rigide vasthouden aan het aanvalsplan
De aanvalsscenario's ontwikkeld uit de threat intelligence zijn geen script. Ze zijn een startpunt. Echte aanvallers passen zich aan. Ze volgen de weg van de minste weerstand. Ze veranderen van aanpak wanneer een deur gesloten is en vinden een raam.
Een Red Team dat vooraf gedefinieerde scenario's mechanisch uitvoert, zonder zich aan te passen aan wat ze daadwerkelijk in de omgeving vinden, produceert bevindingen die het plan weerspiegelen in plaats van de realiteit. Dat is niet waarvoor een TLPT bedoeld is.
Een aanpassing van het aanvalsplan is legitiem en vaak waardevol, maar vereist goedkeuring van de Test Manager. Scenario's die in elkaar overvloeien omdat het Red Team consequent de weg van de minste weerstand volgt, kunnen de gestructureerde leerwaarde ondermijnen die drie afzonderlijke scenario's zijn ontworpen om te bieden. De beste Red Teams weten wanneer het tijd is om zich aan te passen en wanneer niet. Ze communiceren afwijkingen van het plan direct aan het Control Team via het dagelijkse check-inproces, en zoeken goedkeuring van de Test Manager wanneer de afwijking significant is.
De fix: de rules of engagement staan aanpassing toe binnen de gedefinieerde scope. Het Red Team documenteert elke afwijking duidelijk. Het Control Team wordt in real time geïnformeerd.
Valkuil 8: Slechte operationele logging door het Red Team
Het Red Team Test Report is een van de belangrijkste documenten in het hele TLPT-proces. Het vormt de basis van de Purple Teaming sessies, het Remediation Plan en de attestatie. De Purple Teaming sessies zijn afhankelijk van de kwaliteit van zowel de operationele logs van het Red Team als de eigen detectieregistraties van het Blue Team. Geen van beide vertelt alleen het volledige verhaal.
Elke actie die het Red Team tijdens de test onderneemt, moet worden voorzien van een tijdstempel, gedocumenteerd en traceerbaar zijn. Niet omdat de Test Manager elke regel zal controleren, maar omdat de Purple Teaming sessies ervan afhangen. De eigen detectieregistraties van het Blue Team zijn even belangrijk en kunnen hiaten in de logs van het Red Team aanvullen, maar een ongedocumenteerde actie aan beide kanten is een gemiste leerkans.
De fix: het Red Team houdt gedurende de hele test een gedetailleerd operationeel logboek bij. Dagelijkse check-in rapportage aan het Control Team houdt deze discipline consistent. De logs vloeien direct door naar het Red Team Test Report en de Purple Teaming voorbereiding.
Leer- en afsluitingsfase
Valkuil 9: Bevindingen die niet landen op boardniveau
Het Red Team Test Report is een technisch document. Het beschrijft aanvalspaden, exploitatietechnieken, detectiefouten en behaalde vlaggen. Het is geschreven door beveiligingsprofessionals voor beveiligingsprofessionals.
De board is geen beveiligingspubliek. Ze denken in risico, continuïteit en zakelijke impact. De kloof tussen het rapport en het boardgesprek is een van de meest consequent onderschatte uitdagingen in de afsluitingsfase. Als de CISO de technische bevindingen niet kan vertalen naar zakelijke taal, wordt de boardvergadering een formaliteit. Het leiderschap knikt, het rapport wordt gearchiveerd, en er verandert niets.
De fix: de afsluitingsfase omvat een presentatie op boardniveau die bevindingen vertaalt naar zakelijk risico en investeringstermen. Een nuttige aanpak hierbij is Gold Teaming: een gestructureerde sessie die senior leiderschap bij de bevindingen betrekt op een manier die de impact van de acties van het Red Team tastbaar en geloofwaardig maakt op besluitvormingsniveau. Waar een Purple Team sessie het Blue Team laat zien wat ze hebben gemist, laat een Gold Team sessie de board zien wat het betekent.
Valkuil 10: Purple Teaming als afvinklijst behandeld
We hebben dit zien gebeuren: de Purple Teaming sessies worden gehaast, samengeperst in één dag, en behandeld als formaliteit in plaats van als de meest waardevolle sessies in het hele TLPT-proces.
De Purple Teaming sessies zijn waar het Blue Team eindelijk leert wat er tijdens de test is gebeurd. Het Red Team loopt hun acties door. Het Blue Team brengt in kaart wat ze zagen, wat ze markeerden en wat ze misten. Samen begrijpen ze de detectiehiaten en bouwen ze een gedeeld beeld op van waar de verdediging standhield en waar ze faalde.
Voor een TLPT zijn meerdere sessies doorgaans nodig, niet slechts één. Het Red Team heeft volledige logs nodig. Het Blue Team heeft tijd nodig om de eigen observaties voor te bereiden. Elke sessie heeft een structuur nodig die beide teams in staat stelt diep in te gaan op de meest ingrijpende scenario's.
Goed uitgevoerd sluit Purple Teaming niet alleen de lus op één TLPT. Het vestigt een werkrelatie tussen Red en Blue Teams die verder gaat dan de test. De organisaties die het meeste uit hun TLPT halen, zijn degenen die de afsluitingsfase gebruiken als het begin van een doorlopend Purple Teaming programma, waarbij detectie- en responscapaciteiten elk kwartaal worden getest en systematisch worden verbeterd.
De fix: Purple Teaming wordt gepland vanaf het begin van het traject, niet georganiseerd in de laatste weken. De operationele logs van het Red Team zijn gestructureerd met Purple Teaming in gedachten. De sessies hebben toegewijde tijd, een duidelijke structuur, en output die direct doorvloeit naar het Remediation Plan en een vooruitkijkende testkalender.
Valkuil 11: Geen eigenaarschap over het verbeterplan
Het verbeterplan is een formeel TIBER-EU deliverable. De organisatie documenteert hoe ze de bevindingen uit het Red Team Test Report zal aanpakken. De Test Manager beoordeelt het. Het bewijs van naleving hangt ervan af.
We hebben dit zien gebeuren: het verbeterplan wordt geproduceerd als document maar niet behandeld als commitment. Bevindingen worden opgesomd. Eigenaren worden benoemd. Tijdlijnen worden opgeschreven. En dan verdampt de urgentie, omdat de test voorbij is, de druk weg is, en de bevindingen concurreren met alle andere prioriteiten.
De TLPT komt over drie jaar terug. De vraag is of de organisatie die de volgende onder ogen ziet wezenlijk weerbaarder is dan de organisatie die deze heeft doorstaan. Dat hangt volledig af van of het verbeterplan resulteert in echte werkzaamheden en niet in een gearchiveerd document.
De fix: eigenaarschap over herstel wordt vastgesteld tijdens de afsluitingsfase, niet erna. Voortgang wordt bijgehouden. Het doorlopende Purple Teaming programma creëert een natuurlijk verantwoordingsmechanisme: als een bevinding uit de TLPT nog steeds exploiteerbaar is in het volgende kwartaalscenario, wordt de kloof tussen het plan en de realiteit zichtbaar.
Samenvatting
Niet elk TLPT-traject heeft te maken met al deze valkuilen. In onze ervaring, en op basis van wat we horen uit de industrie, zijn de meest voorkomende praktisch van aard: leg-ups die niet op tijd kunnen worden geregeld, escalatiepaden die in de praktijk niet goed werken en Purple Teaming sessies die niet de tijd en structuur krijgen die ze verdienen. De andere komen minder frequent voor, maar wanneer ze dat doen, zijn ze ingrijpend.
De organisaties die deze uitdagingen goed navigeren, zijn degenen die de TLPT behandelen als een echte weerbaarheidsoefening vanaf de eerste dag van voorbereiding tot de laatste dag van remediatie. Dat begint met het kiezen van de juiste provider: een Red Team dat documenteert wat ze doen, intelligent aanpast aan wat ze vinden, en de afsluitingsfase behandelt als een begin in plaats van een einde.
In Blog 4 lopen we door hoe een goed uitgevoerd TLPT-scenario er van begin tot eind uitziet, aan de hand van een realistisch voorbeeld uit de financiële sector.
Blog 1 of Blog 2 gemist? Begin met begrijpen wat een TLPT is of hoe je een pre-TLPT security testing strategie opbouwt.