Cybersecurity & AI. Jak tym zarządzić i czy warto korzystać z NIS, ISO, CRA, AIA i innych zabawnych zbitek literowych

Tym bardziej, że w badaniu PWC „na próbce CEO” wyraźnie widać, że cyberzagrożenia to jedno z głównych wyzwań dla organizacji (akurat tutaj w odniesieniu do generatywnej AI, ale uwaga jest znacznie szersza). Potwierdza to zresztą ostatni raport OWASP TOP 10 LLM 2025, który znajdziecie pod tym linkiem. Naruszenie może zwyczajnie skutkować stratami wizerunkowymi i finansowymi, które przełożą się na wynik, ale i być może dalszą i bliższą przyszłość organizacji. Nie żartuję.

Ale dość straszenia, bo nie po to napisałem ten felieton. Pewnie część z Was (nie wliczam bezpieczników oraz inspektorów ochrony danych) raczej „przelotem” spojrzała na normę ISO 27001 czy wymagania ustawy o krajowym systemie cyberbezpieczeństwa (NIS2), a już z dużą dozą pewności mogę stwierdzić, że niewiele osób widziało na oczy normę ISO 27563:2023 „Security and privacy in artificial intelligence use cases — Best practices”. Są to dokumenty, które stanowią pewien fundament w zakresie bezpieczeństwa (informacji) i których wdrożenie jest jednym z kroków do zapewnienia większej odporności na zagrożenia. Piszę o „jednym z kroków”, bowiem papierowe wdrożenia, które niestety też się zdarzają, nie dają ochrony jakiej byśmy oczekiwali i tym samym stanowią jedynie formalne spełnienie wymogów – czy to przepisów prawa lub oczekiwań regulatora, czy też umów, które zawieramy z kontrahentami oraz klientami.

Na marginesie warto wspomnieć, że art. 15 AI Act (Rozporządzenie w sprawie sztucznej inteligencji) w ust. 1 wskazuje, że:

Systemy AI wysokiego ryzyka projektuje się i rozwija w taki sposób, aby osiągały odpowiedni poziom dokładności, solidności i cyberbezpieczeństwa oraz by działały konsekwentnie pod tymi względami w całym cyklu życia

Mało tego:

Rozwiązania techniczne mające na celu zapewnienie cyberbezpieczeństwa systemów AI wysokiego ryzyka muszą być dostosowane do odpowiednich okoliczności i ryzyka. Rozwiązania techniczne mające na celu eliminowanie słabych punktów charakterystycznych dla AI obejmują, w stosownych przypadkach, środki służące zapobieganiu atakom mającym na celu manipulowanie zbiorem danych treningowych (zatruwanie danych) lub elementami stosowanymi przy trenowaniu, które zostały poddane pretrenowaniu (zatruwanie modelu), wprowadzaniu danych wejściowych, które mają na celu spowodowanie błędu w modelu AI (przykłady kontradyktoryjne lub omijanie modelu), atakom na poufność lub wadom modelu, a także środki w zakresie wykrywania tych zagrożeń, reagowania na nie, ich rozwiązywania i ich kontrolowania.

Jakby tego było za mało jest jeszcze Rozporządzenie (UE) 2024/2847, czyli Cyberresilience Act, który w art. 12 również referuje do art. 15.

Spójrzmy jednak na chwilę na wybrane wymogi ostatniego pr ojektu zmian do ustawy o krajowym cyberbezpieczeństwa, które w art. 8 nakładają wymogi dla podmiotów kluczowych oraz istotnych (jeżeli jesteśmy operatorem usługi kluczowej, to wielkiego zaskoczenia nie będzie). Wybrane, bo jest ich… cóż, dużo. Zastrzegam przy tym, że jest to tylko nawiązanie do wymogów, bo trzeba tam również brać pod uwagę określone zasady i wymagania „dodatkowe”. No i zostawmy na boku kto jest obowiązany do ich stosowania, bo choć katalog jest ograniczony, to ja jednak zachęcam do stosowania choć części wymogów te podmioty, w których sfera cyfrowa i przetwarzanie danych są istotne.

Tak więc, podmiot kluczowy lub podmiot ważny wdraża system zarządzania bezpieczeństwem informacji w systemie informacyjnym wykorzystywanym w procesach wpływających na świadczenie usługi przez ten podmiot, zapewniający:

- prowadzenie systematycznego szacowania ryzyka wystąpienia incydentu oraz zarządzanie tym ryzykiem;

- wdrożenie odpowiednich i proporcjonalnych do oszacowanego ryzyka środków technicznych i organizacyjnych, uwzględniających najnowszy stan wiedzy, koszty wdrożenia, wielkość podmiotu, prawdopodobieństwo wystąpienia incydentów, narażenie podmiotu na ryzyka, skutki społeczne i gospodarcze;

- zbieranie informacji o cyberzagrożeniach i podatnościach na incydenty systemu informacyjnego wykorzystywanego do świadczenia usługi;

- zarządzanie incydentami;

- stosowanie środków zapobiegających i ograniczających wpływ incydentów na bezpieczeństwo systemu informacyjnego wykorzystywanego do świadczenia usługi.

Te wymagania wdrażamy w organizacji poprzez różne działania, które mają charakter nie tylko organizacyjny czy techniczny, ale także kulturowy i w zakresie budowania świadomości oraz zasobów wiedzy. To oczywiście także polityki, procedury, wytyczne oraz instrukcje, a nawet strategie postępowania, których nie unikniemy, jeżeli chcemy, aby wszystko „grało”. Jest to też wymóg ściśle zgodnościowy od którego nie możemy zupełnie abstrahować.

ISO 27001

Specyfika systemów AI, nie skupiamy się przy tym na generatywnej AI, ale w ogóle na takich rozwiązaniach, które wykorzystują uczenie maszynowe czy głębokie, jest nieco inna niż w przypadku tradycyjnych rozwiązań IT, co przekłada się m.in. na architekturę rozwiązań, która może być nieco bardziej rozbudowana i skomplikowana, uwzględniająca więcej podmiotów trzecich dostarczających np. dane. Inaczej może wyglądać przepływ informacji (szczególnie jeżeli wykorzystujemy rozwiązania chmurowe), a tym samym inaczej mogą wyglądać ryzyka dla takich rozwiązań (zarówno systemów, jak i modeli oraz zbiorów danych, które wykorzystujemy). Sytuacja staje się jeszcze bardziej specyficzna, jeżeli dołożymy do tego popularne LLM i dane osobowe, bo wątpliwości w tym zakresie jest całkiem sporo, na co zwraca uwagę nie tylko niedawna opinia Europejskiej Rady Ochrony Danych, ale także dokumenty innych organów ochrony danych.

Nie oznacza to jednak, że sam fundament w zakresie cyberbezpieczeństwa i bezpieczeństwa informacji istotnie nam się zmienia. Nadal musimy identyfikować ryzyka i szacować prawdopodobieństwo ich zmaterializowania się, zarządzać incydentami, szkolić naszych pracowników czy wzmacniać systemy i uzupełniać wiedzę o zagrożeniach. Wprowadzenie do organizacji systemów AI nie zmienia w tym zakresie praktycznie nic. Zmienia się jednak sposób podchodzenia do tych zagrożeń, bowiem nasza matryca ryzyk ulegnie z pewnością znacznemu rozszerzeniu.

Przy okazji polecam książkę D. W. Hubbarda i R. Seiersena „Ryzyko w cyberbezpieczeństwie. Metody modelowania, pomiaru i szacowania ryzyka”, w której autorzy zachęcam do zmiany sposobu zarządzania ryzykiem „cyber” na bardziej ilościowy.

Inaczej będą wyglądały też środki mitygacji ryzyk i środki naprawcze, które będziemy musieli wdrożyć po ewentualnym „wylaniu się mleka”. Być może (raczej z dużym prawdopodobieństwem) większą uwagę będziemy musieli przykładać do naszych relacji kontraktowych z dostawcami, co jest widoczne np. w sektorze finansowym za sprawą Rozporządzenia (UE) 2022/2554 (DORA), które nałożyło na instytucje finansowe pewne obowiązki w zakresie kontraktów z zewnętrznymi dostawcami usług ICT. Również nasze zasoby będziemy musieli odpowiednio zinwentaryzować pod kątem „nowych” ryzyk, a nasze procesy z zakresu zarządzania incydentami oraz przechowywania logów będą musiały być co najmniej odświeżone.

OWASP TOP 10 LLM 2025

Zwróćmy też uwagę na obszary takie jak SDLC czy MLOps i AIOps. Pierwsze odnosi się do procesu wytwarzania oprogramowania, do którego systemy AI również się zaliczają. Uwzględnienie ryzyk AI w tym procesie będzie bardzo istotne, bo będzie determinowało nam to czy jest ono odporne czy nie (to oczywiście nie tylko proces wytwórczy, ale aktualizacje i łatki). Również procesy związane z operacyjnym funkcjonowaniem tych systemów będą musiały być poddane szczególnej uwadze, a ta uwaga będzie tylko wtedy, jeżeli będziemy wiedzieli, gdzie sięgnąć i czy będziemy dysponować odpowiednimi narzędziami, bo przecież takie systemy mogą działać „ciągle” w tym sensie, że np. są dotrenowywane w czasie (near) real-time. Ta specyfika „prawie w czasie rzeczywistym” może być jednym z większych wyzwań również w kontekście security.

Z tego wynika, że w tym wszystkim bardzo istotni będą ludzie, a nie wyłącznie technologia (narzędzia). I o tym jeszcze będę pisał, dzisiaj kończąc, bo żona woła na kawę!