Guardian360
Rozpocznij bezpłatny okres próbnyZostań partnerem
← Wszystkie wpisy

Opinia

Yellow Teaming: modne hasło czy punkt przełomowy?

Autor Jan Martijn Broekhof ·

Nigdy nie słyszałem terminu “Yellow Team”, dopóki nie przeczytałem niedawnego tekstu w Dark Reading o AI i bezpieczeństwie. Pod koniec drugiego akapitu uświadomiłem sobie coś nieco niewygodnego: Guardian360 od lat po cichu nim jest, a nikt, łącznie ze mną, nigdy nie zadał sobie trudu, żeby to tak nazwać.

Przez długi czas nie miało to większego znaczenia. Budowanie narzędzi, których używają zespoły Red i Blue, było postrzegane jako praca towarowa: konieczna, mało efektowna, rzadko będąca tematem wystąpień konferencyjnych. Atakującym przypadał dramatyzm. Obrońcy zbierali uznanie za utrzymanie linii. Ludzie, którzy budowali platformy leżące u podstaw jednych i drugich, dostawali pozycję w budżecie. AI zmienia ten rachunek i warto zrozumieć dlaczego oraz co to oznacza dla tego, jak Guardian360 współpracuje ze swoimi partnerami.

Czym właściwie są zespoły Red, Blue i Yellow i gdzie w tym mieści się DevSecOps?

Kolorowe słownictwo w cyberbezpieczeństwie jest starsze, niż większość ludzi sądzi. Red Team to ci, którzy symulują ataki: testerzy penetracyjni, etyczni hakerzy, ludzie opłacani za włamanie się, zanim zrobi to ktoś o gorszych zamiarach. Blue Team to obrońcy: analitycy i inżynierowie, którzy wykrywają te ataki, reagują na nie i odbudowują sprawność po nich. Yellow Team leży u podstaw obu. To grupa, która projektuje, buduje i utrzymuje systemy, aplikacje i narzędzia, na których i za pomocą których faktycznie działają Red i Blue.

To rozróżnienie zostało po raz pierwszy zaproponowane na Black Hat w 2017 roku, gdy wprowadzono koło kolorów, aby odwzorować różne funkcje w pracy nad bezpieczeństwem wykraczające poza znajome ujęcie red kontra blue, co badacze bezpieczeństwa z Retest Security od tamtej pory udokumentowali we własnej historii tego frameworka. Yellow zdefiniowano jako budowniczych: architektów, deweloperów i inżynierów odpowiedzialnych za bezpieczne systemy od podstaw, a nie ludzi atakujących je lub broniących ich po fakcie.

DevSecOps nie jest osobnym kolorem na tym kole. To praktyka, której Yellow Teamy używają, aby wykonywać swoją pracę: wplatanie bezpieczeństwa w sam potok wytwarzania oprogramowania, tak aby podatności były wychwytywane w momencie ich powstawania, a nie odkrywane później przez Red czy sprzątane później przez Blue. DevSecOps to metoda. Yellow Team to grupa ludzi, którzy ją stosują.

Czy to tylko DevSecOps w nowym opakowaniu?

Uczciwy sceptyk zatrzymałby mnie w tym miejscu. Jeśli Yellow Team to po prostu ludzie robiący DevSecOps, to co się właściwie zmieniło? Organizacje mają inżynierów bezpiecznego wytwarzania oprogramowania od dekady. Nazwanie ich “żółtymi” nie sprawia, że ta praca staje się nowa.

Ten sceptycyzm zasługuje na uczciwą odpowiedź, a uczciwa odpowiedź brzmi: sama w sobie etykieta rzeczywiście byłaby starym winem w nowej butelce. Tym, co czyni ten moment odmiennym, nie jest nazwa, lecz skala tego, co Yellow Teamy mają teraz budować. Modele frontier AI, takie jak Claude Mythos i GPT-5.5, potrafią znajdować i łączyć w łańcuchy podatności oprogramowania szybciej niż niemal każdy ludzki zespół, a organizacje dopiero zaczynają rozgryzać, jak skierować tę zdolność w użyteczną, a nie chaotyczną stronę. To kierowanie okazuje się być pracą Yellow Teamu i nie przypomina w niczym pisania list kontrolnych do bezpiecznego przeglądu kodu.

Dlaczego AI właśnie zmieniło rachunek dla budowniczych

Według doniesień Dark Reading inżynierowie w firmach takich jak Cisco, Microsoft, Cloudflare i Netskope spędzają teraz czas na budowaniu “harnesses”: konstrukcji programowych, które precyzyjnie definiują, co model AI może robić, jakie ma uprawnienia i jakie zabezpieczenia musi respektować podczas polowania na podatności. Harness brzmi jak coś ograniczającego, ale jest wręcz przeciwnie. Bez niego zespoły Red zostają przytłoczone fałszywymi alarmami i ustaleniami pozbawionymi kontekstu biznesowego; z nim ten sam model AI staje się naprawdę użyteczny zarówno do symulacji ataku, jak i do obrony.

CISO Netskope, James Robinson, opisuje dokładnie ten wzorzec: model oznaczył wewnętrzny endpoint jako nieuwierzytelniony, co było technicznie prawdą, ale przeoczył, że ten endpoint i tak nigdy nie był osiągalny z sieci. Przejście od surowego wyniku AI do czegoś, czemu ludzki analityk mógłby zaufać, wymagało dedykowanego wysiłku inżynierskiego, a nie promptu.

Efektem ubocznym jest to, że Blue i Yellow są przyciągane do siebie bliżej niż kiedykolwiek. Jak ujmuje to Levi Bolourie z Zscaler, zespoły blue, które nie używają AI do analizy, ryzykują przytłoczenie samą ilością sygnałów, jakie generuje dziś wspomagane przez AI red teaming, i obie dyscypliny będą musiały w efekcie zintegrować się znacznie ściślej. Yellow Teamy nie są już funkcją wsparcia stojącą cicho za Red i Blue. Są powodem, dla którego którykolwiek z tych zespołów w ogóle jest w stanie nadążyć.

Od systemu zapisu do systemu działania

Pod tym wszystkim biegnie druga zmiana i dotyczy ona spraw daleko wykraczających poza bezpieczeństwo. Przez dwie dekady większość oprogramowania korporacyjnego była tym, co dziś nazywa się “systemem zapisu” (system of record): miejscem, które przechowuje to, co się wydarzyło. Państwa CRM zapisuje, że klient zadzwonił. Państwa platforma skanująca zapisuje, że istnieje podatność. Użyteczne, konieczne i zupełnie bierne.

“System działania” (system of action) robi coś innego. Zamiast tylko przechowywać to, co się wydarzyło, wykorzystuje tę informację, aby zdecydować, co powinno wydarzyć się dalej, a coraz częściej, aby to zrobić. Własne badania Grammarly nad produktywnością w miejscu pracy wykazały, że 77 procent profesjonalistów czuje się przytłoczonych samą ilością informacji, które muszą przetworzyć, a 83 procent twierdzi, że brakuje im narzędzi, aby faktycznie działać na podstawie tego, co wiedzą. Ta luka między posiadaniem danych a zrobieniem z nimi czegoś użytecznego jest dokładnie tym, co system działania ma zamknąć.

Lubię myśleć o tym jak o różnicy między tradycyjną latarnią morską a taką, która potrafiłaby sama sterować swoim promieniem. Tradycyjna latarnia morska to czysty system zapisu: oznacza stałą, znaną pozycję, a to od kapitana statku zależy odczytanie światła, ocena odległości i wybór kursu. Nie dostosowuje się do statku przed sobą. Wyobraźmy sobie teraz latarnię, która potrafiłaby śledzić zbliżającą się jednostkę i aktywnie przekierować swój promień, aby ostrzec ten konkretny statek, w tym konkretnym momencie, przed najbliższym mu niebezpieczeństwem. Kapitan wciąż prowadzi statek. Ale latarnia przestała być statycznym znakiem, a stała się aktywnym uczestnikiem dbania o bezpieczeństwo tego statku.

Kiedyś wręczaliśmy partnerom mapę. Teraz chcemy prowadzić ich trasą.

Krótka uwaga o pozycjonowaniu, zanim pójdę dalej: Guardian360 jest niezależnym dostawcą oprogramowania. Rozwijamy platformę Lighthouse: ciągłe skanowanie, rekomendacje zgodności, inwentaryzację zasobów, biznesową i techniczną ocenę ryzyka. Nie prowadzimy Security Operations Centre, nie wykonujemy ręcznych testów penetracyjnych ani reagowania na incydenty i nie sprzedajemy bezpośrednio klientom. Ta praca należy do naszych partnerów i tak było zawsze.

Przez lata to, co wręczaliśmy partnerom, było w istocie mapą. Lighthouse pokazywał, gdzie leży ryzyko, co wymaga uwagi i mniej więcej jak pilne to jest. Znalezienie najlepszej trasy od tej informacji do konkretnego środowiska klienta pozostawało całkowicie po stronie partnera. To był właściwy model, gdy to sama mapa była trudną do zbudowania częścią. To bardziej skomplikowany model teraz, gdy AI potrafi pomóc wygenerować nie tylko mapę, ale i naprawdę użyteczny kolejny krok.

W nadchodzących miesiącach chcemy, aby Lighthouse przesunął się dalej od mapy w stronę nawigacji: nie tylko pokazując partnerom, gdzie leży ryzyko, ale proponując najlepszą trasę, aby sobie z nim poradzić, wciąż od nowa, w miarę jak zmieniają się okoliczności. To właśnie w praktyce oznacza dla nas budowanie systemu działania.

Warto być wobec tego szczerym, ponieważ rodzi to oczywiste pytanie dla każdego czytającego to partnera: jeśli platforma zaczyna proponować trasę, co zostaje dla kierowcy? Nasza odpowiedź brzmi: partner pozostaje za kierownicą. Nie budujemy narzędzi, aby wyciąć partnerów z pracy; budujemy je, aby zdjąć im z rąk te części pracy, które nie wymagają ludzkiego osądu, tak aby decyzje, które go wymagają, dostawały więcej ich uwagi, a nie mniej. Partnerzy w istocie stają się Blue Teamem jutra: tymi, którzy decydują, działają i biorą odpowiedzialność za rezultat, wspierani przez Yellow Team, który wreszcie jest proszony o coś więcej niż tylko podtrzymywanie działania świateł.

Więc którym zespołem po cichu Państwo byli?

Guardian360 był Yellow Teamem na długo przed tym, zanim ten termin zaistniał, i podejrzewam, że spora część organizacji czytających te słowa może powiedzieć to samo o przynajmniej jednej części własnej działalności. Pytanie, przy którym warto się zatrzymać, nie brzmi, czy Yellow Teaming to prawdziwa kategoria, czy tylko rebranding. Brzmi ono: który z Państwa zespołów od lat wykonuje tę pracę w tle, nienazwany i niedoceniony, i czy są Państwo gotowi dać mu narzędzia oraz uwagę, których naprawdę wymaga ten moment.

Źródła