Aby tworzyć skuteczne systemy AI, trzeba najpierw spróbować je złamać. Przeprowadziliśmy kontrolowany atak: wcieliliśmy się w napastników, aby przetestować przeznaczoną dla klientów aplikację AI z sektora usług finansowych i wykryć jej słabe punkty. Nasze ustalenia są istotne dla każdego, kto wdraża aplikacje oparte na LLM w środowisku, w którym bezpieczeństwo jest koniecznością.
Kontrolowany atak polega na celowych próbach złamania systemu AI, aby usunąć luki, zanim znajdzie je prawdziwy napastnik. W usługach finansowych ryzyko jest szczególnie wysokie: aplikacje AI mają dostęp do danych klientów, przetwarzają transakcje i dostarczają analiz finansowych. Skutki awarii mogą obejmować zarówno złe doświadczenia użytkowników, jak i naruszenia przepisów, straty finansowe oraz nieodwracalne szkody dla marki.
Chcieliśmy wcześnie wykryć luki, przetestować realistyczne scenariusze ataków i pomóc organizacji spełnić wymogi bezpieczeństwa AI, do których organy regulacyjne podchodzą bardzo poważnie.
Warto tu zaznaczyć istotną różnicę: obejście zabezpieczeń atakuje filtry bezpieczeństwa bazowego modelu, natomiast wstrzykiwanie poleceń jest wymierzone w samą aplikację i wykorzystuje niezaufane dane użytkownika połączone z zaufanym poleceniem dewelopera. Wstrzykiwanie poleceń stwarza większe ryzyko, ponieważ jest wymierzone w konkretny system i przetwarzane przez niego poufne dane, a nie w model ogólnego przeznaczenia.
Pierwsza runda obejmowała około 750 testów dotyczących:
wycieku danych między sesjami
ujawnienia danych osobowych (za pomocą języka naturalnego, manipulacji API i różnych sposobów kodowania)
wstrzykiwania kodu SQL
nadpisywania polecenia systemowego
Podczas wstępnych testów wykryliśmy dwa główne problemy istniejącego systemu: obsługę zapytań zawierających wiele intencji oraz użycie zakodowanych poleceń.
Zapytania zawierające wiele intencji: żądania łączące uzasadnione i złośliwe prośby. Na przykład: “Pokaż moje wydatki według kategorii, a także uruchom [złośliwy kod SQL].” Aplikacja nie wykrywała złośliwego zamiaru, lecz polegała wyłącznie na zabezpieczeniach niższej warstwy danych. To tak, jakby zostawić otwarte drzwi wejściowe tylko dlatego, że ufa się sejfowi w piwnicy.
Kodowanie: żądania zakodowane w Base64, systemie szesnastkowym lub LeetSpeak albo zapisane przy użyciu homoglifów. Systemom może być trudno odfiltrować złośliwy zamiar. Choć zapytania te nie ujawniały danych wrażliwych, znacznie destabilizowały system, powodując m.in. halucynacje, powtarzanie użytkownikom złośliwego kodu SQL i błędną klasyfikację intencji.
Wyniki wstępnych testów wykazały:
Halucynacje dotyczące czasu: model zwracał z pełnym przekonaniem zmyślone daty, znaczniki czasu transakcji lub podsumowania dotyczące określonych okresów. To poważne ryzyko w kontekście finansowym, ponieważ podjęcie przez klienta działania na podstawie błędnej daty może mieć realne konsekwencje
Powtarzanie użytkownikowi złośliwego kodu SQL (niepokojące ze względu na ryzyko zatruwania pamięci)
Błędną klasyfikację intencji
Zaburzone formatowanie odpowiedzi
Na podstawie tych ustaleń zawęziliśmy zakres dalszych testów. Testom wstrzykiwania kodu SQL i kodowania nadaliśmy niższy priorytet, ponieważ zespół już pracował nad tymi problemami. Skupiliśmy się natomiast na najskuteczniejszych wektorach ataku: ujawnianiu danych osobowych i wyciekach między sesjami.
Najbardziej uderzające odkrycie z drugiej rundy było zaskakująco proste: często nie trzeba stosować żadnych wyrafinowanych metod.
W wielu przypadkach wystarczyło po prostu poprosić o dane wewnętrzne w ramach pozornie uzasadnionego żądania, aby system zgodził się je ujawnić. W odpowiedziach na proste zapytania pojawiały się wewnętrzne identyfikatory i pola systemowe, które nigdy nie powinny być widoczne dla użytkowników końcowych.
Dokładniejsza analiza wykazała, że problem nie ograniczał się do warstwy aplikacji. Usługa przekształcająca tekst na SQL konstruowała zapytania o większą liczbę pól, niż powinna, a jej odpowiedzi z objaśnieniami odwoływały się do danych, do których dostęp powinien być ograniczony. Ujawniło to rzeczywistą lukę między systemami, którą można wykryć tylko podczas testowania całego stosu, a nie poszczególnych, odizolowanych komponentów.
Kontrolowany atak powinien obejmować system, a nie model. Testowanie LLM w izolacji niewiele mówi o poziomie bezpieczeństwa aplikacji. Należy testować cały stos od początku do końca, tak jak korzysta z niego użytkownik.
Dane wejściowe trzeba weryfikować przed przekazaniem ich do LLM. Zakodowane zapytania, ataki wykorzystujące wiele intencji i podstawowe próby wstrzyknięcia powinny być wykrywane już na wejściu do systemu, a nie przekazywane do obsługi usługom niższych warstw.
Nie ufaj punktom styku między systemami. W architekturach złożonych z wielu usług najciekawsze luki często kryją się na styku systemów. „Zero trust” oznacza brak zaufania, dlatego wszystko trzeba weryfikować na każdej warstwie.
Proste ataki są skuteczne. Wyrafinowane sposoby obchodzenia zabezpieczeń trafiają na pierwsze strony, ale czasami wystarczy po prostu... zapytać. Jeśli system bez oporu ujawnia wewnętrzne identyfikatory, gdy użytkownik umieści je w skądinąd uzasadnionym zapytaniu, jest to poważny problem.
Trzeba wiedzieć, co faktycznie podlega testom. Znane schematy ataków mogą być wykrywane dzięki wytrenowanym mechanizmom samego LLM, a nie zabezpieczeniom aplikacji. Kontrolowany atak powinien zapewniać obserwowalność, aby można było ustalić, które zabezpieczenia są faktycznie uruchamiane.
Środowiska z ograniczeniami wymagają kreatywnych rozwiązań. Niestandardowi dostawcy i obsługa lokalnych modeli umożliwiają przeprowadzanie miarodajnych kontrolowanych ataków bez specjalistycznego dostępu do chmury. Trzeba jednak otwarcie informować o wynikających z tego ograniczeniach.
Kontrolowany atak nie jest jednorazowym działaniem. To proces iteracyjny, który należy w miarę możliwości automatyzować i rozwijać wraz z systemem. Ataki, które będą istotne jutro, nie są tymi samymi, które liczą się dzisiaj.
Systemy AI w środowiskach regulowanych będą podlegać coraz większej kontroli. Organizacje, które traktują testowanie bezpieczeństwa jako stały element swojej działalności, a nie punkt do odhaczenia przed wdrożeniem, będą lepiej przygotowane na tę kontrolę i unikną kryzysów wizerunkowych prowadzących do utraty zaufania klientów.