Guardian360
Kostenlos testenPartner werden
← Alle Beiträge

Meinung

Yellow Teaming: Buzzword oder Wendepunkt?

Von Jan Martijn Broekhof ·

Ich hatte den Begriff “Yellow Team” noch nie gehört, bis ich vor Kurzem einen Artikel in Dark Reading über KI und Sicherheit las. Am Ende des zweiten Absatzes wurde mir etwas leicht Unangenehmes bewusst: Guardian360 ist seit Jahren still und leise eines, und niemand, mich eingeschlossen, hat sich je die Mühe gemacht, es so zu nennen.

Lange Zeit spielte das kaum eine Rolle. Der Bau der Werkzeuge, die Red- und Blue-Teams verwenden, galt als Commodity-Arbeit: notwendig, wenig glanzvoll, selten Gegenstand eines Konferenzvortrags. Die Angreifer bekamen das Drama. Die Verteidiger bekamen die Anerkennung dafür, die Stellung zu halten. Die Menschen, die die Plattformen unter beiden bauten, bekamen eine Zeile im Budget. KI verändert diese Rechnung, und es lohnt sich zu verstehen, warum, und was das für die Zusammenarbeit von Guardian360 mit seinen Partnern bedeutet.

Was genau sind Red-, Blue- und Yellow-Teams, und wo passt DevSecOps hinein?

Das Farbvokabular in der Cybersicherheit ist älter, als die meisten annehmen. Red Team bezeichnet die Menschen, die Angriffe simulieren: Penetrationstester, ethische Hacker, jene, die dafür bezahlt werden einzudringen, bevor es jemand mit schlechteren Absichten tut. Blue Team bezeichnet die Verteidiger: die Analysten und Ingenieure, die diese Angriffe erkennen, darauf reagieren und sich davon erholen. Das Yellow Team sitzt unter beiden. Es ist die Gruppe, die die Systeme, Anwendungen und Werkzeuge entwirft, baut und pflegt, auf und mit denen Red und Blue tatsächlich arbeiten.

Diese Unterscheidung wurde erstmals 2017 auf der Black Hat vorgeschlagen, als ein Farbrad eingeführt wurde, um die verschiedenen Funktionen innerhalb der Sicherheitsarbeit über das vertraute Rot-gegen-Blau-Schema hinaus abzubilden, wie Sicherheitsforscher bei Retest Security seither in ihrer eigenen Geschichte des Frameworks dokumentiert haben. Gelb wurde als die Erbauer definiert: Architekten, Entwickler und Ingenieure, die für sichere Systeme von Grund auf verantwortlich sind, statt für die Menschen, die sie im Nachhinein angreifen oder verteidigen.

DevSecOps ist keine eigene Farbe auf diesem Rad. Es ist die Praxis, mit der Yellow-Teams ihre Arbeit verrichten: Sicherheit in die Entwicklungspipeline selbst einzuflechten, sodass Schwachstellen im Moment ihrer Entstehung erkannt werden, statt später von Red entdeckt oder später von Blue bereinigt zu werden. DevSecOps ist die Methode. Das Yellow Team ist die Gruppe von Menschen, die sie anwendet.

Nur DevSecOps mit neuem Anstrich?

Ein berechtigter Skeptiker würde mich hier unterbrechen. Wenn ein Yellow Team einfach die Menschen sind, die DevSecOps betreiben, was hat sich dann wirklich geändert? Organisationen haben seit einem Jahrzehnt Ingenieure für sichere Entwicklung. Sie “gelb” zu nennen macht die Arbeit nicht neu.

Diese Skepsis verdient eine ehrliche Antwort, und die ehrliche Antwort lautet: für sich genommen wäre das Etikett tatsächlich alter Wein in neuen Schläuchen. Was diesen Moment anders macht, ist nicht der Name, sondern das Ausmaß dessen, wofür Yellow-Teams nun bauen sollen. Frontier-KI-Modelle wie Claude Mythos und GPT-5.5 können Softwareschwachstellen schneller finden und aneinanderreihen als nahezu jedes menschliche Team, und Organisationen beginnen erst zu ergründen, wie sie diese Fähigkeit in eine nützliche statt in eine chaotische Richtung lenken. Dieses Lenken, so zeigt sich, ist Yellow-Team-Arbeit, und es sieht ganz anders aus als das Schreiben von Checklisten für sichere Code-Reviews.

Warum KI die Rechnung für Erbauer soeben verändert hat

Laut der Berichterstattung von Dark Reading verbringen Ingenieure bei Unternehmen wie Cisco, Microsoft, Cloudflare und Netskope ihre Zeit nun damit, “harnesses” zu bauen: Softwarekonstrukte, die genau festlegen, was ein KI-Modell tun darf, welche Berechtigungen es hat und welche Leitplanken es bei der Suche nach Schwachstellen beachten muss. Ein “harness” klingt einschränkend, ist aber das Gegenteil. Ohne ein solches werden Red-Teams von False Positives und von Befunden ohne Geschäftskontext überflutet; mit einem solchen wird dasselbe KI-Modell für Angriffssimulation und Verteidigung wirklich nützlich.

Netskopes CISO James Robinson beschreibt genau dieses Muster: Das Modell markierte einen internen Endpunkt als nicht authentifiziert, technisch zutreffend, übersah aber, dass der Endpunkt ohnehin nie aus dem Web erreichbar war. Von der rohen KI-Ausgabe zu etwas zu gelangen, dem ein menschlicher Analyst vertrauen würde, erforderte eine eigene Ingenieursleistung, keinen Prompt.

Die Folge ist, dass Blue und Yellow enger zusammengezogen werden als je zuvor. Wie Zscalers Levi Bolourie es formuliert: Blue-Teams, die KI nicht zur Analyse einsetzen, laufen Gefahr, von der schieren Menge an Signalen überflutet zu werden, die KI-gestütztes Red Teaming nun erzeugt, und die beiden Disziplinen werden sich dadurch weit enger integrieren müssen. Yellow-Teams sind nicht länger eine unterstützende Funktion, die still hinter Red und Blue steht. Sie sind der Grund, weshalb beide Teams überhaupt mithalten können.

Von einem system of record zu einem system of action

Unter all dem verläuft eine zweite Verschiebung, und sie reicht weit über die Sicherheit hinaus. Zwei Jahrzehnte lang war die meiste Unternehmenssoftware das, was man heute ein “system of record” nennt: ein Ort, der speichert, was geschehen ist. Ihr CRM verzeichnet, dass ein Kunde angerufen hat. Ihre Scanplattform verzeichnet, dass eine Schwachstelle besteht. Nützlich, notwendig und völlig passiv.

Ein “system of action” tut etwas anderes. Statt nur zu speichern, was geschehen ist, nutzt es diese Informationen, um zu entscheiden, was als Nächstes geschehen sollte, und zunehmend, um es auch zu tun. Grammarlys eigene Untersuchung zur Produktivität am Arbeitsplatz ergab, dass sich 77 Prozent der Fachkräfte von der schieren Menge an Informationen überfordert fühlen, die sie verarbeiten müssen, und 83 Prozent geben an, dass ihnen die Werkzeuge fehlen, um tatsächlich nach dem zu handeln, was sie wissen. Genau diese Lücke zwischen dem Verfügen über Daten und dem sinnvollen Handeln damit soll ein “system of action” schließen.

Ich stelle es mir gern als den Unterschied zwischen einem herkömmlichen Leuchtturm und einem vor, der seinen eigenen Strahl lenken könnte. Ein herkömmlicher Leuchtturm ist ein reines “system of record”: Er markiert eine feste, bekannte Position, und es ist Sache des Kapitäns, das Licht zu deuten, die Entfernung einzuschätzen und den Kurs zu wählen. Er passt sich dem Schiff vor ihm nicht an. Stellen Sie sich nun einen Leuchtturm vor, der ein herannahendes Schiff verfolgen und seinen Strahl aktiv umlenken könnte, um genau dieses Schiff in genau diesem Moment vor der Gefahr zu warnen, die ihm am nächsten ist. Der Kapitän steuert das Schiff weiterhin selbst. Aber der Leuchtturm ist kein statisches Zeichen mehr, sondern ein aktiver Teilnehmer daran geworden, dieses Schiff sicher zu halten.

Früher gaben wir Partnern eine Karte. Jetzt wollen wir die Route weisen.

Eine kurze Anmerkung zur Positionierung, bevor ich fortfahre: Guardian360 ist ein unabhängiger Softwareanbieter. Wir entwickeln die Lighthouse-Plattform: kontinuierliches Scanning, Compliance-Empfehlungen, Asset-Inventarisierung, geschäftliches und technisches Risiko-Scoring. Wir betreiben kein Security Operations Centre, wir führen keine manuellen Penetrationstests oder Incident Response durch, und wir verkaufen nicht direkt an Kunden. Diese Arbeit liegt bei unseren Partnern, und das war schon immer so.

Was wir Partnern jahrelang reichten, war im Grunde eine Karte. Lighthouse zeigte, wo das Risiko lag, was Aufmerksamkeit brauchte und ungefähr wie dringend es war. Die beste Route von diesen Informationen zu einer bestimmten Kundenumgebung zu finden, blieb ganz dem Partner überlassen. Das war das richtige Modell, als die Karte selbst der schwierige Teil war. Es ist ein komplizierteres Modell, jetzt da KI helfen kann, nicht nur die Karte zu erstellen, sondern auch einen wirklich nützlichen nächsten Schritt.

In den kommenden Monaten möchten wir, dass Lighthouse sich weiter von der Karte hin zur Navigation bewegt: Partnern nicht nur zeigen, wo das Risiko sitzt, sondern die beste Route vorschlagen, um damit umzugehen, immer wieder, während sich die Umstände ändern. Das ist es, was der Aufbau eines “system of action” in der Praxis für uns bedeutet.

Darüber sollte man ehrlich sein, denn es wirft eine naheliegende Frage für jeden Partner auf, der dies liest: Wenn die Plattform die Route vorschlägt, was bleibt dann für den Fahrer? Unsere Antwort ist, dass der Partner die Kontrolle über das Auto behält. Wir bauen keine Werkzeuge, um Partner aus der Arbeit herauszuschneiden; wir bauen sie, um jene Teile der Arbeit, die keine menschliche Ermessensentscheidung erfordern, aus ihren Händen zu nehmen, damit die Ermessensentscheidungen, die einen Menschen brauchen, mehr Aufmerksamkeit erhalten, nicht weniger. Partner werden gewissermaßen zum Blue Team von morgen: diejenigen, die entscheiden, handeln und Verantwortung für das Ergebnis übernehmen, unterstützt von einem Yellow Team, das endlich gebeten wird, mehr zu tun, als den Betrieb am Laufen zu halten.

Also, welches Team waren Sie still und leise schon?

Guardian360 war ein Yellow Team, lange bevor es den Begriff gab, und ich vermute, dass eine ganze Reihe von Organisationen, die dies lesen, dasselbe über mindestens einen Teil ihres eigenen Betriebs sagen können. Die Frage, bei der es sich zu verweilen lohnt, ist nicht, ob Yellow Teaming eine echte Kategorie oder nur ein Rebranding ist. Es ist, welches Ihrer Teams diese Arbeit seit Jahren im Hintergrund verrichtet, ungenannt und unterbewertet, und ob Sie bereit sind, ihm die Werkzeuge und die Aufmerksamkeit zu geben, die dieser Moment wirklich erfordert.

Sources