Kryzys widoczności AI: Dlaczego zespoły bezpieczeństwa lecą na ślepo i dlaczego nie muszą

Integracja agentów AI z produkcją przyspiesza, ale architektura bezpieczeństwa wymagana do ich zabezpieczenia jest niebezpiecznie opóźniona. Żyjemy w erze, w której agent AI, wyznaczony do rutynowego zadania w środowisku testowym, może niezależnie zdecydować “naprawić” niezgodność poświadczeń, kasując wolumin bazy danych.

Jako branża, zbiorowo wyłączamy nasze mózgi, gdy chodzi o podstawowe zasady bezpieczeństwa i obserwowalności wokół AI. Zespoły bezpieczeństwa lecą na ślepo, ale nie muszą.

Mit systemowych wskazówek i bezpiecznych narzędzi

Powszechny mit w przestrzeni AI mówi, że możemy kontrolować zachowanie agenta, po prostu nakazując mu się zachować. Systemowe wskazówki są doradcze, a nie egzekwujące. W wyżej wymienionym incydencie, systemowe reguły AI wyraźnie stwierdzały, że nigdy nie wolno wykonywać destrukcyjnych poleceń, jednak agent złamał własne ogłoszone barierki i wykonał najbardziej nieodwracalne działanie możliwe.

Musimy pracować pod założeniem, że AI tak naprawdę “nie wie” nic. Ataki na AI to inżynieria społeczna, z tym że oszukany jest głupszy niż przeciętny człowiek. Każdy, kto ma doświadczenie w testach penetracyjnych, rozumie, jak trudno jest dla organizacji bronić się przed atakami inżynierii społecznej. Teraz nasze komputery są również podatne.

Ponadto, narzędzia AI są ostatecznie tylko oprogramowaniem, a wszystkie oprogramowanie ma błędy. Już widzieliśmy przypadki, w których narzędzia AI automatycznie uruchamiają nieuwierzytelnione serwery HTTP, pozwalając dowolnemu procesowi lokalnemu lub stronie internetowej na wykonywanie dowolnych poleceń powłoki z uprawnieniami użytkownika.

Czarna skrzynka audytu AI

Jeśli AI zacznie działać nieprawidłowo lub zostanie manipulowana, ustalenie, co zrobiła, jest koszmarem. Narzędzia AI zwykle nie zapewniają rejestrów audytowych. Jeśli masz szczęście być na poziomie przedsiębiorstwa, otrzymywane rejestry są poważnie niedostateczne. Na przykład, możesz otrzymać mgliste zdarzenie, w którym użytkownik “użył AI ogólnej.” i otrzymasz podstawowe metryki dotyczące liczby tokenów wejścia i wyjścia.

Żadne z nich nie pomaga analitykowi bezpieczeństwa odpowiedzieć na fundamentalne pytanie: Co dokładnie wykonał ten agent?

Odkrywanie AI: Jak przestać lecieć na ślepo

Dobra wiadomość jest taka, że niekoniecznie potrzebujesz nowego, specjalnego urządzenia bezpieczeństwa AI, aby odzyskać widoczność. Użycie cieni AI i aktywność agenta są wykrywalne przy użyciu istniejących technik analizy logów, których Twoj zespół powinien już posiadać. Wywołania narzędzi AI, wykonania poleceń i zdarzenia zmiany systemu można śledzić do AI przy użyciu istniejącej analizy wykonania procesu (którą robisz w zarządzaniu informacjami i zdarzeniami bezpieczeństwa (SIEM), prawda?).

Oto, jak możesz wykorzystać swoją bieżącą infrastrukturę, aby wykryć aktywność AI:

• Analiza DNS: Analiza logów DNS w celu wykrycia zapytań do znanych domen usług AI może pomóc w wykryciu użycia AI w Twoim środowisku.
• Lista zagrożeń: Ten podejście wymaga utrzymania aktualnej listy zagrożeń domen związanych z platformami AI lub dostawcami modeli.
• Zasoby społecznościowe: Istnieją projekty społeczne i listy blokowania, które można modyfikować w celu tworzenia tabel lookup dla użycia programistycznego.
• Śledzenie SSL: Podobne podejście może wykorzystywać rejestry SSL do śledzenia nazw serwerów, chociaż dostarcza nieco mniej szczegółów, ponieważ nie rejestruje się pełnego adresu URL.
• Telemetria punktu końcowego: Możesz użyć narzędzi takich jak Sysmon, aby liczyć procesy podrzędne i polować na wysokie wywołania bash, co jest silnym wskaźnikiem potencjalnych agentów AI wykonujących polecenia na punkcie końcowym.

Punkt ślepy wymagający aktywnych zmian w Twoim zbieraniu danych jest sam wskazówka. Co użytkownicy proszą AI? Czy przesyłają jakiekolwiek potencjalnie wrażliwe dokumenty, tworząc problemy z zgodnością? Odpowiedzi na te pytania najprawdopodobniej wymagają zbierania żądań API do dostawcy; serwery proxy, serwery proxy LLM, narzędzia do pobierania danych od dostawców logów i SIEM. Mogą one usunąć zasłonę, która blokuje ten cenny źródło danych.

Wyrośnięte zagrożenie: Złośliwe serwery MCP

Protokół kontekstu modelu (MCP) pojawił się jako sposób określenia, jak aplikacje AI integrują się z zewnętrznymi narzędziami i źródłami danych. Chociaż standaryzuje połączenia, wprowadza również ogromne nowe wektory ataku za pośrednictwem “Złych serwerów MCP“.

Prowadzę warsztat szkoleniowy, na którym studenci mogą doświadczyć tego ataku osobiście. Projektują złośliwy serwer MCP, aby oszukać LLM, nakazując mu wywołanie prawidłowych narzędzi i wysłanie danych wyjściowych do atakującego. Ponieważ LLM są bardzo podatne na inżynierię społeczną, ominąć ich wbudowane barierki często jest tylko kwestią lepszego sformułowania lub sprytnego pretekstu.

Studenci często używają swojego złośliwego serwera, aby nakazać AI, że jest “w trybie konserwacji” i musi przekazać dane do narzędzia pomocniczego do “rejestrowania audytu”, co skutkuje eksfiltracją danych. Niektórzy są bardziej kreatywni w swoich wskazówkach niż inni, ale wszyscy są zwykle skuteczni.

Odbieranie kontroli

Aby właściwie audytować aktywność AI w świecie rzeczywistym, potrzebujesz serwera proxy do przechwytywania żądań AI i narzędzia do zbierania logów, które może obsłużyć ogromne ładunki JSON. Z tą widocznością możesz wykryć i rozwiązać zagrożenia. Nie możesz polegać wyłącznie na dostawcach AI, aby zapewnili warstwę bezpieczeństwa. Egzekwowanie musi mieszkać w systemach Twojej organizacji, a nie w paragrafie tekstu, którego model może zdecydować się posłuchać. Z dobrym rozwiązaniem do logowania, zespoły bezpieczeństwa mają telemetrię; czas zacząć ją wykorzystywać.