Trzymanie LLMa na krótkiej smyczy: Podsumowanie zabezpieczeń przed atakami Prompt Injection

Jakiś czas temu nasz zespół przeprowadził szczegółowy test penetracyjny aplikacji wykorzystującej duży model językowy (LLM – Large Language Model). Na tym etapie testów posłużyliśmy się OWASP Top 10 dla LLM, o którym pisałem w innym artykule.

Kilka wykrytych podatności było związanych z wykorzystaniem sztucznej inteligencji, a najgroźniejszymi z nich były Prompt Injection. Uruchomiło to intensywną wewnętrzną dyskusję na temat tego, jakie rekomendacje powinniśmy przygotować w celu naprawienia tych problemów.

Wyniki tej dyskusji stały się punktem wyjścia do napisania tego artykułu.

Podatności

Oprócz typowych podatności aplikacji webowych, testowana przez nas aplikacja zawierała również specyficzne zagrożenia związane z używaniem LLM. Przykładem może być to, że aplikacja nie ograniczała modelu SI do angażowania się wyłącznie w tematy związane z jej biznesowym przeznaczeniem. Zdecydowanie najpoważniejszymi podatnościami były jednak bezpośrednie i pośrednie ataki typu Prompt Injection.

Sytuacja była szczególnie poważna, ponieważ umożliwiała wpływanie na odpowiedzi modelu LLM dla innych użytkowników aplikacji.

Rekomendacje

Ważną częścią naszej pracy jako testerów penetracyjnych jest formułowanie zaleceń dotyczących naprawy wykrytych podatności. Zazwyczaj jest to dość proste. Jeśli znajdziemy XSS, rozwiązaniem jest prawidłowe kodowanie danych w zależności od kontekstu. Jeśli wykryjemy podatność SQL Injection, należy zastosować parametryzację danych wejściowych.
Jednak w przypadku LLM – a zwłaszcza podatności typu Prompt Injection – sprawa jest bardziej skomplikowana. Nie istnieje obecnie rozwiązanie gwarantujące 100% bezpieczeństwa poza całkowitym zaprzestaniem korzystania z LLM. Opracowanie skutecznych zaleceń opisujących zabezpieczenia przed Prompt Injection wymaga więc dostosowania ich do konkretnego przypadku biznesowego.

Krajobraz metod zabezpieczania przed atakami Prompt Injection jest rozległy i dynamiczny. Istnieje wiele różnych podejść, z których każde ma jeszcze swoje subwarianty. Obecnie główne metody mitygacji tej podatności lub zmniejszania jej ryzyka obejmują:

• Input pre-processing
• Guardrails
• Wzorce projektowe
• Mixture of Experts
• Prompt Engineering
• Finetuning
• Redukcję impactu

Brzmi to jak koszmarnie dużo różnych strategii dla tylko jednej podatności, prawda? Ma to jednak pewne zalety, ponieważ daje nam to większą elastyczność w wyborze odpowiednich środków zabezpieczających.

W kolejnych artykułach zagłębię się w te metody, a na razie omówię je tylko pokrótce.

Input pre-processing

Metoda ta polega na modyfikowaniu danych wejściowych użytkownika w celu utrudnienia tworzenia szkodliwych promptów. Główne techniki obejmują parafrazowanie i retokenizację. Oznacza to na przykład przepisywanie zapytań użytkownika przez inny model językowy w zwięźlejszej lub inaczej zmodyfikowanej formie, podmianę losowych znaków lub słów czy dzielenie tokenów LLM na mniejsze fragmenty.

Celem tych działań jest zachowanie poprawnych instrukcji, jednocześnie zakłócając szkodliwe polecenia.

Guardrails

Guardrails to zestaw metod monitorujących dane wejściowe i wyjściowe modelu LLM w celu wykrywania ataków Prompt Injection lub ich skutków. Mogą być one tak proste jak zastosowanie wyrażeń regularnych lub znacznie bardziej zaawansowane jak na przykład wykorzystanie innego modelu LLM do oceny szkodliwości wprowadzanego tekstu.

To obecnie najbardziej rozbudowana i najszerzej wykorzystywana metoda zabezpieczania przez Prompt Injection.

Wzorce projektowe

Metoda ta opiera się na użyciu wielu modeli o różnych poziomach uprawnień, zorganizowanych według określonych wzorców projektowych. Dane są przekazywane w sztywno zdefiniowanej i ustrukturyzowanej formie, co pozwala odizolować model z dostępem do krytycznych funkcji od niezaufanego wejścia.

W mojej opinii ta metoda ma potencjał, by stać się ogólnym rozwiązaniem dla podatności typu Prompt Injection.

Mixture of Experts

Ta technika polega na wykorzystaniu wielu różnych modeli lub kilku instancji tego samego modelu. Mogą one generować wiele wyników i łączyć je albo głosować nad poprawnością pojedynczego wyjścia.

W ten sposób atakujący musi oszukać większość z modeli jednocześnie, a nie tylko jeden co utrudnia przeprowadzenie ataku.

Prompt Engineering

Zestaw technik manipulujących promptami modelu. Może obejmować strukturyzowanie promptów systemowych w określony sposób lub włączanie zapytań użytkownika w ramy systemowych instrukcji. Inną interesującą metodą jest hierarchizacja instrukcji, gdzie polecenia systemowe mają najwyższy priorytet.

Dzięki temu rozwiązaniu model pozostaje skupiony na swoim zadaniu i jest mniej podatny na ataki Prompt Injection.

Finetuning

Dodatkowa faza uczenia modelu mająca na celu utrudnienie odciągnięcia go od zamierzonego zastosowania. Proces ten zazwyczaj jest specyficzny dla danej aplikacji przez co zwiększa prawdopodobieństwo, że model będzie się trzymał swojego konkretnego zadania.

Podejście to wymaga przygotowania zestawu danych uczących oraz dodatkowego narzutu obliczeniowego na naukę przez co może wygenerować znaczące koszty.

Ograniczenie impactu

Ta metoda nie zapobiega atakom Prompt Injection, ale ogranicza ich skutki. Działania te są specyficzne dla aplikacji, ale ogólnie mówiąc obejmują: izolowanie modelu LLM od prywatnych danych, analizę i sanityzację danych przed ich wykorzystaniem w innych systemach oraz oddzielenie LLM od funkcji wysokiego ryzyka.

Niestety, na ten moment koniecznie jest traktowanie danych wyjściowych LLMa jako potencjalnie złośliwych – tak samo, jak traktuje się dane wejściowe użytkownika. Z tego powodu jest to obecnie najważniejsza metoda zabezpieczania przed Prompt Injection.

Problemy

Każda z tych metod ma istotną wadę – nie zapewniają pełnej ochrony. Jak trafnie zauważył Simon Willison – 99 procentowa skuteczność w bezpieczeństwie aplikacji daje w wyniku i tak ocenę niedostateczną. Nie oznacza to, że nie powinniśmy w ogóle używać LLMów. Oznacza to jednak, że nie każde zastosowanie jest obecnie możliwe do zaimplementowania patrząc pod kątem bezpieczeństwa. W szczególności funkcje wysokiego ryzyka, takie jak transakcje finansowe, zmiany danych czy umawianie wizyt, są obecnie zbyt niebezpieczne.

Mówiąc inaczej, można tolerować ryzyko wystąpienia 1 fałszywej odpowiedzi na 100 pytań, ale nie da się tolerować takiego samego ryzyka dokonania przez atakującego fałszywego zakupu lub zmiany hasła użytkownika w aplikacji.

Wnioski

Przygotowanie jasnych, skutecznych i praktycznych zaleceń dotyczących wykrytych podatności jest jednym z najtrudniejszych aspektów pracy testerów penetracyjnych. W przypadku testów bezpieczeństwa SI wyzwanie to jest jeszcze większe. Dziedzina ta rozwija się w zawrotnym tempie, a wiele problemów pozostaje nierozwiązanych. Pozostanie na bieżąco z aktualnymi najlepszymi praktykami w tym zakresie to trudne zadanie, jednak będę regularnie analizować nowe rozwiązania, aby Ci w tym pomóc.

Do zobaczenia w kolejnym artykule, w którym dokładniej omówię jedną z metod ochrony przed atakami Prompt Injection.