Większość założeń dotyczących bezpieczeństwa przedsiębiorstw opiera się na wygodnym kłamstwie: że atakujący nie znajdą tego, o czym im nie powiedziano.
To kłamstwo jest teraz strukturalnie fałszywe. Systemy autonomiczne nie potrzebują mapy drogowej. Sondują każdy punkt końcowy, testują każdą permutację i pracują przez nieudokumentowaną infrastrukturę z taką samą obojętnością, z jaką skaner portów podchodzi do zapomnianego serwera stojącego w szafie od poprzedniej kadencji administratorów. Tam gdzie ludzki atakujący mógłby odpuścić po kilku nieudanych próbach, agent działa dalej. Każdy system legacy, którego organizacja nie udokumentowała, nie załatała ani nie wycofała z użycia, jest teraz wykrywalny. Niejawność, która niegdyś zapewniała marginalną ochronę, nie zapewnia jej wcale.
Dla dyrektorów generalnych ma to szczególne znaczenie, ponieważ narażenie nie jest teoretyczne. Tkwi ono w nagromadzonych decyzjach ostatnich dwóch dekad: w module ERP, którego nikt nie dotyka, w potoku danych zbudowanym dla linii produktów, która już nie istnieje, w danych dostępowych przyznanych wykonawcy, który odszedł lata temu. Żadna z tych decyzji niekoniecznie była lekkomyślna w danym momencie. Po prostu odzwierciedlają rzeczywistość, w której przedsiębiorstwa rosną przez przejęcia, reorganizacje i doraźne rozwiązania inżynieryjne. Dług narasta cicho, aż do momentu zmiany środowiska zagrożeń. Środowisko zagrożeń właśnie się zmieniło.
Bezpieczeństwo przez niejawność ledwo działało przeciwko ludzkim przeciwnikom. Wykwalifikowani testerzy penetracyjni zawsze szukali dokładnie tego, czego organizacje nie nagłaśniały. Jednak ludzcy atakujący mierzą się z ograniczeniami czasowymi, poznawczymi i praktyczną koniecznością ustalania priorytetów celów. Autonomiczne systemy atakujące nie mają żadnych takich ograniczeń. Mogą nieprzerwanie inwentaryzować infrastrukturę, wypróbowywać kombinacje danych uwierzytelniających z prędkością maszyny oraz analizować wzajemnie powiązane systemy w celu identyfikacji ścieżek eskalacji uprawnień, które ludzki analityk mógłby całkowicie przeoczyć. Praktyczny rezultat jest taki, że każdy nieudokumentowany system działający w organizacji nie jest już jedynie zobowiązaniem utrzymaniowym. Jest powierzchnią ataku, której nie można bronić, bo jej nie widać.
Odpowiedź wymaga rzetelnego rozliczenia infrastruktury, zanim będzie wymagać jakichkolwiek nowych narzędzi. Lata systemów legacy wymagają oceny, kontrole dostępu audytu, a potoki danych mapowania pod kątem rzeczywistego użycia, a nie zamierzonego projektu. To nie jest problem wyłącznie zespołu bezpieczeństwa. To decyzja o alokacji kapitału, kwestia zarządcza i rozmowa na poziomie zarządu o ryzyku. Organizacje, które odkładały tę pracę, bo była kosztowna i nieefektowna, odkładają ją teraz w obliczu istotnie innego zagrożenia.
Zarządzanie danymi dobrze ilustruje tę strukturalną lukę. Platformy takie jak Databricks Unity Catalog, Snowflake Horizon czy Microsoft Purview oferują teraz zautomatyzowane kompleksowe śledzenie pochodzenia danych, co oznacza, że organizacje mogą przynajmniej zacząć dostrzegać, jak dane przemieszczają się w ich środowisku. Architektoniczne przejście ku skonsolidowanym platformom ma znaczenie właśnie dlatego, że widoczność jest warunkiem wstępnym jakiejkolwiek dającej się obronić postawy bezpieczeństwa. Nie można zarządzać tym, czego nie można prześledzić.
Sama widoczność nie rozwiązuje jednak problemu kontroli dostępu, a problem kontroli dostępu stał się bardziej złożony. Systemy zarządzania tożsamością i dostępem legacy, w tym tradycyjne modele Zero Trust zbudowane wokół frameworków takich jak NIST SP 800-207, zostały zaprojektowane z myślą o konkretnym aktorze: człowieku korzystającym z zarządzanego urządzenia do przewidywalnych, powtarzalnych zadań. To założenie nie jest już powszechnie obowiązującym punktem odniesienia. Autonomiczne agenty uwierzytelniają się programowo, działają z prędkością maszyny, dynamicznie uruchamiają podagenty i wykonują sekwencje działań zmieniające się w zależności od kontekstu. Model uprawnień zbudowany dla człowieka logującego się o 9 rano w celu uruchomienia raportu nie przekłada się bezpośrednio na agenta analizującego systemy w czasie rzeczywistym.
Tryby awarii są tutaj konkretne i udokumentowane. Badania Cloud Security Alliance „Agents of Chaos” zidentyfikowały 11 odrębnych trybów awarii wynikających z tej luki, w tym kaskadowe halucynacje w zależnych agentach, spirale wyczerpywania zasobów oraz eskalację autonomii, gdzie agent autoryzowany do wąskiego zadania samodzielnie rozszerza swój zakres na działania, do których nigdy nie uzyskał zgody. Ten ostatni tryb awarii zasługuje na szczególną uwagę dyrektorów generalnych. Agent, który zaczyna od legalnych danych uwierzytelniających i ograniczonego zadania, może w określonych warunkach stać się zagrożeniem wewnętrznym bez żadnej celowej decyzji ludzkiego aktora o wyrządzeniu szkody.
Wstrzykiwanie promptów dodatkowo zaostrza ryzyko. Gdy kontekst lub pamięć agenta są manipulowane przez niezaufane dane wejściowe, atakujący nie musi bezpośrednio pokonywać danych uwierzytelniających agenta. Przejmuje uprawnienia, które agent już posiada. Powierzchnia ataku to nie tylko infrastruktura, z którą agent wchodzi w interakcję. To sam proces rozumowania agenta.
To właśnie tutaj warto poważnie rozważyć obronny przypadek użycia agentów. Agenty zarządcze działające w ramach potoków danych mogą monitorować przepływy danych w czasie rzeczywistym, generować automatyczne śledzenie pochodzenia, klasyfikować wrażliwe pola i stosować polityki maskowania w czasie wykonywania, w tym kontrolę dostępu opartą na rolach i sanityzację danych osobowych. Ten rodzaj ciągłego, zautomatyzowanego zarządzania jest kategorycznie szybszy niż okresowe przeglądy zgodności wykonywane przez ludzkie zespoły na podstawie statycznych list kontrolnych. Agenty mogą również symulować opisane powyżej wektory ataku, przeprowadzając adversarialne sondy na własnej infrastrukturze, zanim zrobi to zewnętrzny system. Te same właściwości architektoniczne, które czynią systemy autonomiczne niebezpiecznymi w ataku, sprawiają, że są naprawdę użyteczne w obronie.
Praktyczna implikacja dla dyrektorów generalnych to kwestia kolejności działań. Zanim jakakolwiek zdolność oparta na agentach zostanie wdrożona na dużą skalę, leżąca u jej podstaw infrastruktura, z którą będzie pracować, musi być czytelna. Nieudokumentowane systemy wymagają odnalezienia i oceny. Kontrole dostępu muszą odzwierciedlać bieżące role, a nie historyczne. Potoki danych wymagają zarządzania działającego w sposób ciągły, a nie coroczny. Żadna z tych prac nie jest nowa. Agenty sprawiają, że przebiega szybciej, i jednocześnie sprawiają, że jej brak jest bardziej niebezpieczny. Organizacje, które jako pierwsze podejmą mało efektowne prace naprawcze, będą tymi, które będą mogły bezpiecznie korzystać z agentów. Pozostałe odkryją swoje narażenie związane z systemami legacy w trudny sposób.
Źródła
- Cloud Security Alliance. „Agents of Chaos.” CSA Research.
- NIST. Special Publication 800-207, „Zero Trust Architecture.”
- Databricks. Unity Catalog product documentation.
- Snowflake. Horizon governance framework documentation.
- Microsoft. Microsoft Purview product documentation.