Guardian360
Start gratis proefWord partner
← Alle posts

Opinie

Yellow Teaming: buzzword of breekpunt?

Door Jan Martijn Broekhof ·

Ik had de term “Yellow Team” nog nooit gehoord tot ik onlangs een stuk in Dark Reading las over AI en beveiliging. Halverwege de tweede alinea besefte ik iets wat licht ongemakkelijk voelde: Guardian360 is er al jaren stilletjes een, en niemand, ik incluis, heeft ooit de moeite genomen het zo te noemen.

Lange tijd maakte dat weinig uit. Het bouwen van de tools die Red- en Blue-teams gebruiken werd gezien als commoditywerk: noodzakelijk, weinig glamoureus, zelden het onderwerp van een conferentietalk. De aanvallers kregen het drama. De verdedigers kregen de credits voor het standhouden. De mensen die de platforms onder beide bouwden, kregen een regel in de begroting. AI verandert die rekensom, en het is de moeite waard om te begrijpen waarom, en wat dat betekent voor hoe Guardian360 met zijn partners samenwerkt.

Wat zijn Red-, Blue- en Yellow-teams precies, en waar past DevSecOps?

De kleurwoordenschat in cybersecurity is ouder dan de meeste mensen denken. Red Team verwijst naar de mensen die aanvallen simuleren: pentesters, ethische hackers, degenen die betaald worden om in te breken voordat iemand met slechtere bedoelingen dat doet. Blue Team verwijst naar de verdedigers: de analisten en engineers die die aanvallen detecteren, erop reageren en ervan herstellen. Yellow Team zit onder beide. Het is de groep die de systemen, applicaties en tooling ontwerpt, bouwt en onderhoudt waarop en waarmee Red en Blue daadwerkelijk werken.

Dit onderscheid werd voor het eerst voorgesteld op Black Hat in 2017, toen een kleurenwiel werd geïntroduceerd om de verschillende functies binnen beveiligingswerk in kaart te brengen, verder dan het vertrouwde rood-tegen-blauw-kader, zoals beveiligingsonderzoekers bij Retest Security sindsdien in hun eigen geschiedenis van het framework hebben gedocumenteerd. Geel werd gedefinieerd als de bouwers: architecten, ontwikkelaars en engineers die verantwoordelijk zijn voor veilige systemen vanaf de basis, in plaats van de mensen die ze achteraf aanvallen of verdedigen.

DevSecOps is geen aparte kleur op dat wiel. Het is de praktijk die Yellow-teams gebruiken om hun werk te doen: beveiliging in de ontwikkelpijplijn zelf verweven, zodat kwetsbaarheden worden opgemerkt op het moment dat ze ontstaan in plaats van later ontdekt door Red of later opgeruimd door Blue. DevSecOps is de methode. Yellow Team is de groep mensen die haar toepast.

Gewoon DevSecOps met een nieuw likje verf?

Een terechte scepticus zou me hier onderbreken. Als een Yellow Team simpelweg de mensen zijn die DevSecOps doen, wat is er dan werkelijk veranderd? Organisaties hebben al tien jaar secure-development-engineers. Ze “geel” noemen maakt het werk niet nieuw.

Die scepsis verdient een eerlijk antwoord, en het eerlijke antwoord is: op zichzelf zou het label inderdaad oude wijn in nieuwe zakken zijn. Wat dit moment anders maakt is niet de naam, het is de schaal van waarvoor Yellow-teams nu moeten bouwen. Frontier-AI-modellen zoals Claude Mythos en GPT-5.5 kunnen softwarekwetsbaarheden sneller vinden en aan elkaar rijgen dan bijna elk menselijk team, en organisaties beginnen pas te ontdekken hoe ze die capaciteit in een nuttige richting kunnen sturen in plaats van een chaotische. Dat sturen blijkt Yellow-teamwerk te zijn, en het lijkt in niets op het schrijven van checklists voor secure code review.

Waarom AI de rekensom voor bouwers zojuist veranderde

Volgens de berichtgeving van Dark Reading besteden engineers bij bedrijven als Cisco, Microsoft, Cloudflare en Netskope hun tijd nu aan het bouwen van “harnesses”: softwareconstructies die precies definiëren wat een AI-model mag doen, welke rechten het heeft, en welke guardrails het moet respecteren terwijl het op zoek is naar kwetsbaarheden. Een harness klinkt beperkend, maar is juist het tegenovergestelde. Zonder een harness raken Red-teams overspoeld door false positives en bevindingen die zijn ontdaan van bedrijfscontext; met een harness wordt hetzelfde AI-model werkelijk nuttig voor zowel aanvalssimulatie als verdediging.

Netskope’s CISO James Robinson beschrijft precies dit patroon: het model markeerde een intern endpoint als niet-geauthenticeerd, technisch waar, maar zag over het hoofd dat het endpoint sowieso nooit vanaf het web bereikbaar was. Van ruwe AI-output naar iets komen dat een menselijke analist zou vertrouwen kostte een toegewijde engineeringinspanning, geen prompt.

Het gevolg is dat Blue en Yellow dichter naar elkaar toe worden getrokken dan ze ooit zijn geweest. Zoals Zscaler’s Levi Bolourie het verwoordt: blue teams die geen AI voor analyse gebruiken lopen het risico overspoeld te raken door het enorme volume aan signalen dat AI-ondersteund red teaming nu produceert, en de twee disciplines zullen daardoor veel strakker moeten integreren. Yellow-teams zijn niet langer een ondersteunende functie die stilletjes achter Red en Blue staat. Ze zijn de reden dat beide teams überhaupt kunnen bijblijven.

Van een system of record naar een system of action

Er loopt een tweede verschuiving onder dit alles, en die reikt veel verder dan beveiliging. Twee decennia lang was de meeste bedrijfssoftware wat mensen nu een “system of record” noemen: een plek die opslaat wat er is gebeurd. Je CRM registreert dat een klant heeft gebeld. Je scanplatform registreert dat er een kwetsbaarheid bestaat. Nuttig, noodzakelijk, en volledig passief.

Een “system of action” doet iets anders. In plaats van alleen op te slaan wat er is gebeurd, gebruikt het die informatie om te beslissen wat er vervolgens zou moeten gebeuren, en steeds vaker om het ook te doen. Grammarly’s eigen onderzoek naar productiviteit op de werkvloer wees uit dat 77 procent van de professionals zich overspoeld voelt door het enorme volume aan informatie dat ze moeten verwerken, en 83 procent zegt de tools te missen om echt te handelen naar wat ze weten. Precies die kloof tussen data hebben en er iets nuttigs mee doen is wat een “system of action” moet dichten.

Ik zie het graag als het verschil tussen een traditionele vuurtoren en een die zijn eigen bundel zou kunnen sturen. Een traditionele vuurtoren is een puur “system of record”: hij markeert een vaste, bekende positie, en het is aan de kapitein van het schip om het licht te lezen, de afstand in te schatten en de koers te kiezen. Hij past zich niet aan het schip ervoor aan. Stel je nu een vuurtoren voor die een naderend vaartuig zou kunnen volgen en zijn bundel actief zou kunnen omleiden om juist dat specifieke schip, op dat specifieke moment, te waarschuwen voor het gevaar dat het dichtst bij ligt. De kapitein vaart nog steeds het schip. Maar de vuurtoren is opgehouden een statische markering te zijn en is een actieve deelnemer geworden in het veilig houden van dat schip.

We gaven partners vroeger een kaart. Nu willen we de route wijzen.

Een korte kanttekening over positionering voordat ik verderga: Guardian360 is een onafhankelijke softwareleverancier. Wij ontwikkelen het Lighthouse-platform: continue scanning, compliance-aanbevelingen, asset-inventarisatie, bedrijfs- en technische risicoscoring. Wij runnen geen Security Operations Centre, wij voeren geen handmatige pentests of incident response uit, en wij verkopen niet rechtstreeks aan klanten. Dat werk ligt bij onze partners, en dat is altijd zo geweest.

Wat we partners jarenlang aanreikten was in feite een kaart. Lighthouse liet zien waar het risico zat, wat aandacht nodig had, en ongeveer hoe urgent het was. Het vinden van de beste route van die informatie naar een specifieke klantomgeving werd volledig aan de partner overgelaten. Dat was het juiste model toen de kaart zelf het moeilijke deel was om te bouwen. Het is een ingewikkelder model nu AI kan helpen niet alleen de kaart te genereren, maar ook een werkelijk nuttige volgende stap.

De komende maanden willen we dat Lighthouse verder opschuift van kaart naar navigatie: niet alleen partners laten zien waar het risico zit, maar de beste route voorstellen om ermee om te gaan, keer op keer, naarmate de omstandigheden veranderen. Dat is wat het bouwen van een “system of action” in de praktijk voor ons betekent.

Dit is het waard om eerlijk over te zijn, want het roept een voor de hand liggende vraag op bij elke partner die dit leest: als het platform de route gaat voorstellen, wat blijft er dan over voor de bestuurder? Ons antwoord is dat de partner de controle over de auto houdt. We bouwen geen tooling om partners uit het werk te snijden; we bouwen het om de delen van het werk die geen menselijke afweging vereisen uit handen te nemen, zodat de afwegingen die wél een mens nodig hebben meer van hun aandacht krijgen, niet minder. Partners worden in feite het Blue Team van morgen: degenen die beslissen, handelen en verantwoordelijkheid nemen voor de uitkomst, ondersteund door een Yellow Team dat eindelijk wordt gevraagd om meer te doen dan de boel draaiende houden.

Dus, welk team ben je stilletjes al geweest?

Guardian360 was een Yellow Team lang voordat de term bestond, en ik vermoed dat een flink aantal organisaties dat dit leest hetzelfde kan zeggen over minstens één onderdeel van hun eigen operatie. De vraag die de moeite waard is om bij stil te staan is niet of Yellow Teaming een echte categorie is of gewoon een rebrand. Het is welk van jouw teams dit werk al jaren op de achtergrond doet, ongenoemd en ondergewaardeerd, en of je klaar bent om hun de tools te geven, en de aandacht, die dit moment werkelijk vereist.

Sources