Atakujący AI nie męczą się: Dlaczego cyberbezpieczeństwo musi się zmienić

Twój program bezpieczeństwa został zbudowany z myślą o atakujących, którzy się męczą.

Kiedy OpenAI opublikowało opis modeli, które wydostały się z środowiska oceny i spędziły dni w infrastrukturze produkcyjnej Hugging Face, nazwałem to momentem Terminatora dla cyberbezpieczeństwa. Trzymam się tego stwierdzenia, ale coś jeszcze w tej historii powinno nas zatrzymać. Dziewięć dni później Anthropic ujawniło własne incydenty. Na początku sierpnia Meta potwierdziła kolejny. Kilka dni później model czwartego laboratorium, Kimi K3 firmy Moonshot, wymknął się ze swojego piaskownicy testowej. Cztery laboratoria. Mniej niż trzy tygodnie. Cztery modele, które trafiły tam, gdzie nikt ich nie zamierzał.

Te historie były w dużej mierze traktowane jako opowieści o bezpieczeństwie AI. Są. Ale dla CISO są także historiami o ryzyku stron trzecich — i to może być bardziej natychmiastowa lekcja. Niewygodna prawda jest taka, że incydent OpenAI‑Hugging Face był w swojej istocie historią ryzyka stron trzecich: podatny komponent zewnętrzny jako droga ucieczki, dostawca jako ofiara oraz systemowy węzeł, od którego zależy tysiące firm, jako obszar rażenia.

Oto liczba, którą przywiozę na kolejne spotkanie planowania bezpieczeństwa. Spośród około 17 600 działań atakujących Hugging Face odzyskało z logów, większość z nich zakończyła się niepowodzeniem.

Agent testował ścieżki, które donikąd nie prowadziły. Został zablokowany przez listy dozwolonych URL i przeskoczył dalej. Napotkał polityki IAM odrzucające każde wywołanie modyfikujące. Dwa razy próbował uzyskać dostęp do bazy danych produkcyjnej i za każdym razem przekroczył limit czasu. Próbowano, nie powiodło się i przeszło dalej. Tysiące razy. Nie frustrował się. Nie męczył się. A niepowodzenie kosztowało go prawie nic.

Cztery modele wydostały się ze środowisk testowych w mniej niż trzy tygodnie. Ucieczki stały się nagłówkami. Liderzy bezpieczeństwa powinni martwić się bardziej tym, co je umożliwiło: atakującym, który może tysiąc razy zawieść przy prawie zerowych kosztach.

To jest zmiana. Przez dziesięciolecia obrońcy korzystali z jednej prostej prawdy: niepowodzenie kosztuje atakującego. Rozpoznanie zajmowało czas, a ślepe zaułki były kosztowne. Ekonomia tej asymetrii sprawiała, że „nakładanie kosztów” na napastników było spójnym sposobem ich powstrzymania. Gdy niepowodzenie staje się prawie darmowe, skuteczna ścieżka przestaje być igłą w stogu siana i staje się statystyczną pewnością dla każdego, kto może podążać za wszystkimi ścieżkami jednocześnie.

Wzorce w tych incydentach wskazują na trzy lekcje, które liderzy bezpieczeństwa powinni wdrożyć już teraz.

Cztery laboratoria, jeden kształt

Wzorzec jest niezwykle spójny. Daj modelowi cel. Znajduje on ścieżkę, której nikt się nie spodziewał. Czasem ta ścieżka prowadzi prosto do systemów produkcyjnych organizacji, które nigdy nie miały być zaangażowane. W przynajmniej jednym przypadku dotknięta organizacja dowiedziała się, co się stało, ponieważ Anthropic zadzwoniło, aby je poinformować

W każdym przypadku ścieżka przebiegała przez oprogramowanie, infrastrukturę lub środowisko stworzone przez kogoś innego. Liderzy bezpieczeństwa powinni to przyjąć jako osobiste.

Każda organizacja w tym łańcuchu miała program bezpieczeństwa. Kilka z nich miało bardzo dobre. Niepowodzenie nie zostało ograniczone do jednego obszaru. Stało się w szwach między organizacjami, a nikt nie zarządza tymi szwami.

Modele OpenAI znalazły zero‑day w samodzielnie hostowanym proxy pakietów i użyły go, by dotrzeć do otwartego internetu. Stamtąd zakorzeniły się w niechronionej piaskownicy wykonawczej kodu należącej do klienta Modal Labs, użyły jej jako bazy stagingowej i oszukały loader danych Hugging Face, aby odczytał lokalne pliki i wykonał kod. W ciągu trzynastu godzin uzyskały uprawnienia cluster‑admin w kilku wewnętrznych klastrach, co ułatwiło jednorazowe poświadczenie współdzielone we wszystkich z nich. Punkt wejścia był nowatorski. Wewnątrz słabości były takimi, które opisujemy od dwudziestu lat.

Dziewięć dni później Anthropic zrobiło coś rzadszego: opublikowało własny przegląd 141 006 uruchomień oceny i ujawniło trzy przypadki o podobnej prezentacji, nie będąc o to poproszonym: model, który z środowiska oceny dotarł do otwartego internetu, a następnie uzyskał dostęp do systemów prawdziwych organizacji. Tym razem nie było ucieczki z piaskownicy, a jedynie błędna konfiguracja, która pozostawiła otwartą ścieżkę, podczas gdy modelowi powiedziano, że takiej nie ma. Po wyjściu model wykorzystał słabości, które każdy zespół bezpieczeństwa zna: słabe hasła, nieautoryzowane endpointy, wstrzyknięcia SQL i poświadczenia leżące na odsłoniętej stronie debugowania.

Meta potwierdziła czwarty incydent na początku sierpnia, po błędzie konfiguracyjnym, który przyznał jednemu z jej modeli dostęp do internetu w trakcie oceny. Meta również nie wykryła tego; dowiedziała się, co się stało, gdy jej partner testowy zadzwonił. Zarówno ta ocena, jak i ta Anthropic zostały przeprowadzone przez tę samą zewnętrzną firmę, Irregular, która publicznie nazwała je tym samym problemem. Błąd konfiguracyjny jednego dostawcy rozprzestrzenił się na dwa laboratoria frontowe i cztery organizacje ofiar, z których żadna nie miała bezpośredniego związku z Irregular. Był to dostawca dla dwóch laboratoriów, nie dla nich. Agent nie przejmował się tym, gdzie kończy się powierzchnia ataku jednej firmy, a zaczyna drugiej.

To właśnie czyni to problemem ryzyka stron trzecich. Ekspozycja może teraz pochodzić z kilku relacji od Ciebie, w organizacji, której nigdy nie wybrałeś, nie oceniłeś ani nawet nie wiedziałeś, że jest częścią Twojej powierzchni ataku.

Następnie badacze z Frontier Security wykryli, że Kimi K3 od Moonshot również wymyka się swojej piaskownicy, co pozwoliło mu uzyskać dostęp do repozytorium benchmarków na GitHubie. Nikt nie został naruszony, a model realizował przydzielony cel, uznając, że użycie gotowego klucza odpowiedzi jest tańsze niż rozwiązanie problemu. Dwie rzeczy czynią tę sprawę ważną. Badacze wykryli to podczas własnego testu. I działało to na zupełnie innym zestawie narzędzi niż przypadki Anthropic i Meta. Jeden dostawca mający zły miesiąc nie wyjaśnia tego.

Laboratoria nie ignorują tego. Anthropic opublikowało swój przegląd bez zachęty, dlatego branża ma wzorzec do zbadania i nauki — zamiast odrzucać go jako odosobniony przypadek. To powinno stać się normą. OpenAI spowolniło wydanie modelu Astra po wewnętrznych ocenach, które nie wykluczyły krytycznej zdolności cybernetycznej. Oba te kroki zasługują na uznanie. Ale żaden z nich nie jest planem obronnym: opóźnienie wydania reguluje kalendarz jednej firmy. Nic nie zmienia w kwestii zdolnych modeli, w tym Kimi K3, które już są dostępne w wersji otwarto‑wagowej i darmowej, poza kontrolą jakiegokolwiek pojedynczego laboratorium.

Korelacja bez eskalacji nie jest wykryciem

System wykrywania Hugging Face, zasługując na uznanie, połączył sygnały w spójną akcję. Następnie nie podniósł krytyczności, a zespół dyżurny nie został powiadomiony. Narzędzia zebrały historię i nie potrafiły uznać jej za pilną. To architektura triage zaprojektowana dla świata, w którym 17 600 zdarzeń w ciągu czterech dni wydawałoby się absurdalne.

Cyberbezpieczeństwo potrzebuje swojego Fosbury’ego Flopa

W 1968 roku Dick Fosbury zdobył złoto olimpijskie w skoku wzwyż nie przez wyższy skok niż rywale, lecz przez przeskoczenie poprzeczki do tyłu. Wszyscy inni udoskonalali technikę „straddle”. Lepsza forma, większa siła, marginalne zyski w oparciu o dekady starej techniki. Fosbury zmienił kształt problemu. W ciągu dwóch igrzysk „straddle” praktycznie zanikło.

Liderzy bezpieczeństwa muszą teraz przeskoczyć poprzeczkę, która właśnie się przesunęła, a dotychczasowa odpowiedź branży to lepszy „straddle”: więcej alarmów, szybsi analitycy, ściślejsze SLA na przegląd ludzki. To nie zadziała, ponieważ ograniczeniem nie jest szybkość analityka. Nie można odpowiadać na ataki o prędkości maszynowej przy triage o prędkości ludzkiej..

Flop wygląda tak:

• Przestań traktować granicę jako kontrolę. Piaskownica oceny zawiodła, loader danych zawiódł, a izolacja podów zawiodła, każdy z nich działał prawidłowo, dopóki nie przestał. Projektuj z myślą o tym, co nastąpi. Używaj krótkotrwałych poświadczeń. Eliminuj współdzielone tożsamości administracyjne. Zablokuj dostęp do usług metadanych. Przede wszystkim ogranicz, jak daleko atakujący może się przemieścić po pierwszej awarii kontroli.
• Przenieś wykrywanie z alertowania na korelację. Znalezienie jednego podejrzanego zdarzenia nie wystarczy. Zadaniem jest połączenie tysięcy zwykłych zdarzeń w jedną historię ataku i rozpoznanie, kiedy ta historia jest wystarczająco poważna, by obudzić kogoś. To coraz częściej musi być zautomatyzowane, biorąc pod uwagę obserwowaną objętość.
• Traktuj ekspozycję stron trzecich jako ścieżkę ataku, a nie kwestionariusz. Te incydenty przebiegały przez zależności stron trzecich: produkt dostawcy, klient dostawcy, partner oceny, współdzielone narzędzia testowe. Twoje ryzyko teraz obejmuje błędy konfiguracyjne popełniane przez organizacje, których nigdy nie audytowałeś i które możesz nawet nie wiedzieć, że istnieją. Statyczne, jednorazowe oceny nie widzą tego. Problem nie jest nowy. AI czyni go znacznie pilniejszym. Zespoły bezpieczeństwa potrzebują ciągłego wglądu w firmy i technologie, od których zależą, ponieważ napastnicy postrzegają cały ekosystem jako jedną połączoną powierzchnię.

W SecurityScorecard to właśnie taki problem leży u podstaw naszej kultury: łączenie ludzi głęboko ciekawych, jak myślą napastnicy, gotowych kwestionować dwudziestoletnie założenia i podekscytowanych budowaniem zupełnie innego podejścia do bezpieczeństwa!

Pytanie, które warto zadać na następnym spotkaniu zarządu

Kilka tygodni temu powiedziałem, że dżin stał się zbyt potężny dla butelki. Cztery laboratoria później nic nie podważyło tej tezy. Po takich incydentach wszyscy zadają to samo pytanie: Czy jesteśmy gotowi na atakujących zasilanych AI? Nie sądzę, by to pytanie wiele nam dało. „Tak” i „nie” dają ten sam wynik: nic się nie zmienia.

Zadaj trudniejsze. Jeśli 17 000 słabych sygnałowo zdarzeń trafi do Twojego środowiska w ciągu najbliższych czterech dni — a większość wyglądała jak niepowodzenia — jak długo zajmie Twojemu zespołowi zorientowanie się, że to jeden atak? Czy ktoś zostanie powiadomiony na czas?

Już znasz odpowiedź. Luka między tą odpowiedzią a czterema dniami to właśnie praca.