[Cyberbezpieczeństwo] Każdego można złamać, to tylko kwestia czasu. A jak jest z systemami i modelami AI?

Z artykułu dowiesz się m.in.:

🦾 dlaczego modele i systemy AI to nie (tylko) te zagrożenia co w przypadku "tradycyjnych" rozwiązań IT

⚖️ na czym budować bezpieczeństwo AI w organizacji (to w części drugiej!)

🎯 jakie praktyczne kwestie wziąć pod uwagę projektując "nowy" system bezpieczeństwa informacji (to w części trzeciej!)

Nie wiem czy każdego można rzeczywiście złamać (naszła mnie taka myśl po obejrzeniu dość "postrzelonego" i "fikcyjnego" filmu Sisu), ale jedno wiem - nie ma zabezpieczeń, których nie da się przełamać, jeżeli jest motywacja i odpowiednie narzędzia (a czasem korzystny zbieg okoliczności). Dzisiaj wraz z coraz większym upowszechnieniem systemów AI rośnie liczba potencjalnych zagrożeń, które mogą się nam zmaterializować i przynieść konkretną "przykrość". Jednocześnie nadal spora część osób odpowiedzialnych za (cyber)bezpieczeństwo nie decyduje się na danie "okejki" dla fantastycznych projektów biznesowych z użyciem np. dużych modeli językowych (LLM). Czy słusznie?

Jako ciekawostkę napiszę, że Sisu (fiński) oznacza - wytrzymałość, determinacje, silną wolę i upór. Czy to wystarczy, żeby przeciwstawić się wyzwaniom świata cyfrowego, czy może jednak trzeba czegoś więcej, żeby powiedzieć zarządowi - bierzemy ryzyko na klatę i lecimy z projektem dalej? Jedno jest pewne - nie będzie to łatwa i przyjemna podróż, bo czeka na nas wiele niewiadomych, dużo nauki i "przepychania" się w organizacji, żeby uzyskać wspomnianą "okejkę".

Kadr z filmu Sisu

Dlaczego w ogóle wyodrębniamy od tradycyjnego cyberbezpieczeństwa kwestię systemów AI? Przecież i jedno, i drugie to połączenie oprogramowania oraz infrastruktury, więc ryzyka powinny być zasadniczo zbieżne. Otóż powodów jest kilka:

systemy AI opierają się o dane, które są wszechobecne w całym cyklu życia, od przygotowania danych do trenowania, poprzez testowanie, walidację, aż do operacyjnego działania na produkcji - dane są "nowym złotem", na które niektórzy mogą mieć zwyczajnie ochotę dane mogą być dostarczane w trybie ciągłym i w czasie rzeczywistym, a wiele ataków poprzez manipulację danymi może doprowadzić do znacznie większych szkód systemy AI zazwyczaj mają dość rozbudowany i niekiedy skomplikowany łańcuch wartości (outsourcingowy), który powoduje, że powierzchnia potencjalnego ataku jest znacznie większa ataki na systemy AI są słabo rozpoznane, a metody im przeciwdziałania nie dość przetestowane, a przez to nie gwarantujące, że będziemy w stanie się przed nimi uchronić tradycyjne mechanizmy kontrolne mogą być niewystarczające, jak chociażby podejście do tworzenia i rozwijania oprogramowania (dzisiaj nikogo już nie dziwi security Software Development Life Cycle - sSDLC czy DevSecOps).

Istnieje jeszcze jeden powód - jeżeli organizacja chce realnie "wejść" na ścieżkę AI & Data, to musi przynajmniej pomyśleć o jakimś bardziej zorganizowanym podejściu do tych inicjatyw, także z perspektywy bezpieczeństwa i "pożenić" to z takimi zagadnieniami jak zarządzanie ryzykiem czy ochrona danych osobowych, ale także data governance. Specjalistów obszarze bezpieczeństwa AI jest (jeszcze) niewielu, więc takie wyodrębnienie funkcji może być też zwyczajnie korzystne.

Pinterest

Robiłem ostatnie na potrzeby jednego klienta zestawienie podatności i zagrożeń w obszarze modeli i systemów AI, które miało uwzględniać także specyfikę ataków na LLM, które coraz częściej są wykorzystywane zarówno przez pracowników (nierzadko w ramach "shadow IT", czyli trochę poza zgodą bezpieczeństwa) oraz same organizacje. W tym ostatnim przypadku widać zwiększone zapotrzebowanie na produkcyjne zastosowanie a nie wyłącznie eksperymentowanie. Z takiego zestawienia wyszło mi ok. 20 "podstawowych typów podatności" i kilkadziesiąt bardziej szczegółowych technik, które mają swoje wady ( wykrywalność) i zalety ( konkretną korzyść dla adwersarza ). A mówimy tutaj tylko o tych obszarach, które są specyficzne dla systemów AI.

Bardzo przy tym pomocne jest opracowanie OWASP, które pokazuje nie tylko czym dany atak jest, ale także jakie metody obrony możemy przyjąć oraz ISO 27563:2023 Security and privacy in artificial intelligence use cases — Best practices, które daje nam z kolei wzorce do oceny bezpieczeństwa i ryzyk w kontekście systemów AI. Warto zajrzeć, żeby mieć chociaż ogólne pojęcie.

Ataki (i odpowiadające im podatności) AI można podzielić na kilka kategorii, ale ja wybrałem te, które dla mnie są najbardziej "trafne" i przydatne. Ja dzielę je na:

ataki na dane (np. dane treningowe, które możemy "wyciągnąć" konstruując odpowiednie dane wejściowe czy zastosować "tradycyjne" ataki) oraz ataki na model, które zmierzają np. do zmiany parametrów lub jego "wykradnięcia" ataki ze względu na fazę - rozwijania modelu (ataki głównie na dane treningowe) oraz fazę powdrożeniową (ataki mające na celu wymusić określone zachowanie modelu, np. poprzez drobne zmiany w danych wejściowych i "zmylenie" klasyfikatora) ataki na generatywną sztuczną inteligencję (przykładowo ataki wykorzystujące inżynierię zapytań - promptów) oraz na " tradycyjną" AI - takie podejście widać też w kontekście zarządzania ryzykami AI (np. framework NIST) i ułatwia to "przypisywanie" konkretnych strategii obrony ataki na łańcuch wartości AI - jest to o tyle specyficzna grupa ataków, że łączy zarówno tradycyjne bezpieczeństwo, ryzyka i podatności z obszaru outsourcingu oraz specyfikę systemów AI; jest to też ta kategoria, która często jest wyodrębniania w organizacja w ramach systemów zarządzania ryzykiem, jako wymagająca nieco innego podejścia (podobnie będzie w kontekście bezpieczeństwa) ataki na prywatność, które ze względu na potencjalną "wyższą" i specyficzną (dane osobowe) odpowiedzialność powinny podlegać szczególnemu zainteresowaniu, jakkolwiek (prawie) każdy atak może przyczynić się i do materializacji ryzyk z grupy "prywatność".

//pl.pinterest.com/pin/4503668372798160/":

Rzecz jasna ataki i podatności można dzielić na jeszcze mniejsze grupy, ale ten podział jest dla mnie wystarczający. Ułatwia on przypisanie także ról i odpowiedzialności oraz zastosowanie odpowiednich polityk, procedur czy instrukcji. Jest to też jedno z wyzwań przed którymi będziemy stali w kontekście bezpieczeństwa tych systemów. Do tej kwestii wrócimy jednak innym razem.

Jednym z pytań na które powinniśmy sobie odpowiedzieć jest to czy wyodrębniamy obszar bezpieczeństwa AI jak odrębną "dziedzinę" w ramach systemu zarządzania bezpieczeństwem oraz jak poradzimy sobie z wymianą informacji na potrzeby chociażby zarządzania incydentami. Jeżeli przykładowo mamy do czynienia z atakiem na model, który spowodował, że obniżyła się jego dokładność lub wyniki klasyfikacji są błędne (np. system rozpoznawania twarzy "przepuszcza" nie te osoby co trzeba), to ktoś musi odpowiadać za ocenę działania modelu (w ramach praktyki AI/MLOps), zbierać informacje o ewentualnych odchyleniach i przekazywać je działu bezpieczeństwa. Dział bezpieczeństwa musi ocenić czy to rzeczywiście potencjalne naruszenie bezpieczeństwa, czy wynik wadliwego działania modelu. Jeżeli dopatrzy się naruszenia, to kto powinien odpowiadać za weryfikację i usunięcie np. "niechciacianego" kodu i zastosowanie działań naprawczych?

Zarządzanie podatnościami w kontekście systemów i modeli AI może wymagać też nieco innego podejścia w ramach całego systemu bezpieczeństwa i większej interakcji z obszarami ryzyka oraz jednostkami "merytorycznymi", których rola też będzie w tym przypadku znacząca. Oczywiście nie zachęcam od razu do rewolucji i tworzenia nowych dokumentów czy wyodrębniania jednostek - daleki jestem od tego. Bardziej zwracam uwagę na specyfikę tego obszaru i potrzebę "specjalizacji" oraz podnoszenia kompetencji. To akurat jest konieczne już dzisiaj, szczególnie jeżeli chcemy realnie zacząć inwestować w tę technologię.

//pl.pinterest.com/pin/2814818511285736/":

Jeżeli "po drugiej stronie" nie zapewnimy sobie osób, które nie tylko rozumieją zagrożenia, ale wiedzą jak im przeciwdziałać i tym samym umożliwiają podejmowanie nowych inicjatyw, to rodzić to będzie tylko frustrację. Ciekawe pomysły biznesowe będą "utykały" na poziomie "security", a przecież nie tak tworzy się innowację.

W jednym z kolejnych odcinków więcej o normatywach i fundamentach dla systemu bezpieczeństwa AI, który wcale nie jest daleki od tego co wiele organizacji ma już dzisiaj.