ISO 27090: standard cyberbezpieczeństwa dla AI. Zasada „zero trust” i zależność od AI Governance (ISO 42001)

Dwa tygodnie temu pojawiła się nowa norma standaryzacyjna. Nie byle jaka, bo dotycząca zarządzania ryzykami w kontekście systemów AI. Choć sama numeracja wskazuje, że to może być część systemu zarządzania bezpieczeństwem informacji (ISO 27001), to w praktyce jest to także ważny element AI Governance bazującego na ISO 42001. I jak się przekonamy - nie są to tylko puste słowa.

W dzisiejszym felietonie chciałbym przybliżyć Wam czym jest ISO 27090 i jak wpasować jej założenia do naszych istniejących lub tworzących się ram, w tym w kontekście ustawy o krajowym systemie cyberbezpieczeństwa (uKSC). Normę będziemy analizować też w kolejnych felietonach, ale miejcie dla mnie cierpliwość, bo mam obecnie trzy cykle otwarte. Gotowi? No to lecimy.

Zacznijmy od tego, że norma ISO 27090 jest rzecz jasna dobrowolna i nie musimy się do niej stosować, jeżeli mamy na siebie inny plan. Jest ona też komplementarna względem wymagań prawnych, np. wynikających z uKSC czy DORA dla sektora finansowego. Spokojnie możemy ją też stosować wspólnie z dobrymi praktykami, np. ENISA czy OWASP. Na to zresztą wskazuje pkt 5.4 normy.

Dość jednak o otoczeniu. Co tam znajdziemy?

W punkcie 5.2 wskazano, że systemy AI powinny podlegać odpowiednim praktykom w zakresie zarządzania, co obejmuje także bezpieczeństwo, a do tego potrzeba odpowiedniego programu AI Governance obejmującego m.in. posiadanie rejestru / inwentaryzacji systemów AI czy procesów związanych z zarządzaniem ryzykiem.

To zresztą nie powinno nas dziwić, bo bez odpowiedniego „ujęcia” naszego stanu posiadania nie będziemy w stanie zarządzić potencjalnymi podatnościami i wynikającymi z tego ryzykami.

Przykład. Mamy jakieś rozwiązanie w formule SaaS, gdzie istnieje możliwość „odznaczania” konkretnych funkcjonalności oprogramowania. Za decyzje w tym zakresie odpowiada „ktoś z biznesu”, a IT i bezpieczeństwo nie są koniecznie informowane.

Dostawca postanawia udostępnić „funkcjonalność AI”, którą biznes z wielką radością przyjmuje. Biznes nie ma nawet pojęcia, że powinien cokolwiek zgłaszać, a fakt podjęcia takiej decyzji powinien być konsultowany. Nie istnieje rejestr „zasobów AI” (jest rejestr aktywów IT, ale to raczej „dziedzina” IT). Włączenie takiej funkcjonalności otwiera nam kolejny punkt na mapie potencjalnych zagrożeń, który nie podlega kontroli ze strony właściwych służb.

Tak więc, posiadanie rejestru jest tutaj równie istotne, na co wyraźnie wskazuje sama norma. Tworzenie takiego rejestru to wcale niełatwe zadanie, a już w najbliższy piątek będę o tym opowiadał w trakcie webinaru.

Praktyka zero tolerancji, tfu. zero trust

To kolejny wątek, któremu poświęcono wiele miejsca. Generalnie jest tak, że rozwiązania AI, szczególnie te charakteryzujące się choćby częściową autonomicznością i nieprzewidywalnością powinny być traktowane z automatu jako potencjalnie niebezpieczne.

Stąd też w ISO 27090 znajdziemy wyraźne wskazanie, że w ramach naszego holistycznego podejścia do bezpiecznej inżynierii systemów w całym cyklu życia systemu AI powinniśmy rozważyć wprowadzenie zasady „zero trust”. Opis tej zasady znajdziemy m.in. w ISO 27002, ale także w szeregu dobrych praktyk, w tym zakresie agentów AI. Czy ona właściwie jest? Posłużę się tutaj wyjaśnieniem, które przedstawiono w omawianej przez nas normie (przy czym ta zasada świetnie sprawdza się także w „normalnym” cyberbezpieczeństwie):

✅ przyjmujemy założenie, że nasze systemy IT już zostały naruszone (a my o tym nie wiemy),

✅ stosujemy podejście „kochaj, ale kontroluj”, a nie czekaj - „nigdy nie ufaj, zawsze weryfikuj” w zakresie dostępu do naszych systemów,

✅ stosowanie szyfrowania end-to-end (szyfruję u Ciebie, odszyfrowuje wyłącznie u siebie),

✅ traktowanie każdego żądania dostępu (także z wewnątrz organizacji) jako zewnętrznego,

✅ przyjęcie kontroli dostępu bazującej na zasadzie „least privileges”, czyli najmniejszego zestawu uprawnień, także w zakresie interakcji z modelem, który wykorzystujemy,

✅ przyjmujemy, że każdy podmiot składający żądanie (np. wykonania określonego działania), a także każda walidacja wymaga stosownej autoryzacji (potwierdzenia, że dany podmiot to „ten” podmiot z określonymi uprawnieniami).

Ta zasada nabiera szczególne znaczenia w kontekście systemów agentowych, gdzie pojawia się wiele punktów zapalnych, a kontrola dostępu staje się absolutnie fundamentalna, aby uniknąć sytuacji przekroczenia uprawnień czy ich wykorzystania przez podmiot trzeci.

W ISO 27090 zwrócono uwagę, że ta zasad powinna mieć zastosowanie w całym cyklu życia (o czym pisałem między innymi tutaj ) i niezależnie od tego czy mówimy np. o zarządzaniu danymi (o tym traktuje także art. 10 AI Act), wdrażaniu konkretnego modelu lub systemu (perspektywa SDLC), aż po działania agentów i asystentów.

Co fajne w nowej normie to konkretne przykłady, np. przy ochronie danych treningowych (tych, które wykorzystujemy do trenowania modelu, ale także ragowania wiem, że to nie to samo), gdzie zwrócono uwagę, że należy zawsze zakładać, że zbiory danych mogą zawierać tzw. przykłady adwersialne (np. drobne zmiany, które wywołują duże zmiany w modelu) lub dane zatrute. Co musielibyśmy zrobić?

Wprowadzić odpowiednie procesy i procedury weryfikacji czy dane są „czyste”, skąd pochodzą (np. w kontekście agentowego groundingu) oraz czy są integralne, zanim wejdziemy na poziom trenowania. Dodatkowo oznaczać może to wprowadzanie ściślejsze kontroli „golden records”, czyli tych źródeł, które są podstawą dla działania, np. agentów.

To skłaniać będzie nas do jeszcze jednego - aplikowania zasady „ security by default and design ”, czyli prawdziwego skupienia się na bezpieczeństwie naszych rozwiązań.

Taką zasadę wymuszać będzie na nas Rozporządzenie CRA, które w pełni zacznie obowiązywać z końcem 2027 roku i spowoduje, że w procesie produkcji oprogramowania, także „z AI” będziemy uwzględniać stosowne zabezpieczenia.

I tyle dzisiaj ode mnie. Wrócimy do normy, bo ja jestem nią podekscytowany. Zawiera wiele praktycznych wskazówek dotyczących chociażby typów ataków i jak sobie z nimi radzić, więc do rychłego zobaczenia.

A gdybyście chcieli się trochę podszkolić, to oczywiście zapraszam na moje dwa szkolenia:

- „ Zostań AI Governance Officer’em ” w wersji z warsztatem oraz

- norma EN 18286 z ISO 42001 i AI Act’em już w najbliższy piątek.