Jak sztuczna inteligencja zmienia raportowanie SOC w obszarze wykrywania podatności?

Zmieniające się oczekiwania klientów i audytorów wobec raportów SOC

Dostawcy usług funkcjonują dziś w zupełnie innym środowisku zagrożeń. Przekonanie, że oprogramowanie jest odpowiednio zabezpieczone wyłącznie dlatego, że organizacja posiada tradycyjne raporty SOC i nie doświadczyła poważnych incydentów, może nie być już wystarczające. Klienci i regulatorzy coraz częściej zadają pytanie, czy w środowisku nie występują ukryte podatności, które dotychczas pozostały niewykryte. Rady nadzorcze i komitety audytu oczekują od kierownictwa wyjaśnień, w jaki sposób dostawcy usług radzą sobie z zagrożeniami wynikającymi ze zdolności AI do szybkiego identyfikowania i wykorzystywania przeoczonych słabości.

Jak podkreśla Jaime Kipnes: W świecie, w którym AI zmienia sposób wykrywania i wykorzystywania podatności, cyberodporność zależy od skutecznego ładu organizacyjnego, odpowiednich mechanizmów kontrolnych oraz dowodów potwierdzających ich działanie w praktyce.

W trakcie jednego cyklu raportowego dostawcy usług powinni spodziewać się pytań klientów wykraczających poza standardowe procedury due diligence. Klienci będą oczekiwali nie tylko potwierdzenia istnienia programu zarządzania podatnościami, ale również informacji:

• w jaki sposób został on dostosowany do zagrożeń wspieranych przez AI,
• jakie dowody potwierdzają deklaracje kierownictwa,
• oraz jak kwestie te zostały odzwierciedlone w mechanizmach kontrolnych objętych testami w najnowszych raportach SOC.

Podobna presja dotyczy audytorów dostawców usług. Wytyczne i komentarze instytucji ustawiających standardy w obszarze cyberbezpieczeństwa wskazują na potrzebę bardziej szczegółowych procedur, głębszych testów oraz mniejszej tolerancji dla ogólnych opisów kontroli.

Stwierdzenia takie jak „podatności są monitorowane, priorytetyzowane i usuwane zgodnie z poziomem ryzyka” czy „corocznie przeprowadzane są testy penetracyjne, a wykryte nieprawidłowości są eliminowane”, mogą już nie spełniać oczekiwań interesariuszy.

Pięć obszarów kształtujących nowe oczekiwania

Rosnące oczekiwania klientów, audytorów i regulatorów powodują, że coraz większej ocenie podlegają następujące obszary systemu kontroli wewnętrznej organizacji:

1. Zarządzanie podatnościami

Zwiększona skala zagrożeń spowodowana użyciem AI wymagają odejścia od prostych metod identyfikacji i priorytetyzacji podatności wyłącznie na podstawie ich poziomu krytyczności.

Tradycyjne podejście często nie uwzględnia rzeczywistej ekspozycji na zagrożenia, prawdopodobieństwa wykorzystania podatności, które uwzględnia informacje z wywiadu cyberzagrożeń, krytyczności zasobów czy analiz wspieranych przez AI.

Dostawcy usług powinni być w stanie wykazać, jak konkretne podatności są identyfikowane przy wykorzystaniu różnych narzędzi i skanerów, szybko klasyfikowane oraz usuwane w terminach odpowiadających aktualnemu poziomowi zagrożeń. Dotyczy to zarówno aplikacji tworzonych wewnętrznie, jak i zakupionych technologii.

2. Zarządzanie poprawkami (patch management)

W większości organizacji obowiązują formalne standardy zarządzania poprawkami. Znacznie mniej firm jest jednak w stanie przedstawić przekonujące dowody, że standardy te są skutecznie realizowane w całym środowisku IT, obejmującym starsze systemy operacyjne, bazy danych, przejęte aplikacje czy narzędzia pomocnicze lub wspierające, które często nie są właściwie ujęte w rejestrach zasobów.

Cykl wdrażania poprawek liczony w tygodniach lub miesiącach dla krytycznych luk bezpieczeństwa może już nie być akceptowalny. Organizacje powinny dążyć do skrócenia tego czasu do pojedynczych dni oraz posiadać jasne zasady zarządzania wyjątkami w sytuacjach, gdy wdrożenie poprawek nie jest możliwe.

Istotnym priorytetem pozostaje również odpowiednia izolacja systemów krytycznych.

3. Bezpieczne wytwarzanie oprogramowania

Dotychczas zakres raportowania w tym obszarze był zazwyczaj ograniczony do odwołań do stosowanych metodyk, udziału specjalistów ds. bezpieczeństwa oraz wykorzystania narzędzi do analizy kodu w procesie zarządzania zmianą.

Taki poziom szczegółowości prawdopodobnie nie będzie wystarczający wobec kolejnej fali pytań ze strony klientów i regulatorów.

Dostawcy usług powinni rozwijać lub wzmacniać mechanizmy kontrolne zaimplementowane w trybie ciągłym bezpieczeństwa w procesie wytwarzania oprogramowania, zamiast opierać się wyłącznie na sprawdzaniu na moment przeglądu.

Modelowanie zagrożeń powinno być odpowiednio udokumentowane i poparte dowodami, a nie jedynie deklarowane jako element metodyki. Stateczna i dynamiczna analiza kodu.

powinna być powiązana z konkretnymi mechanizmami kontrolnymi. Natomiast zidentyfikowane słabości czy nieefektywności, decyzje dotyczące zarządzania nimi oraz harmonogramy działań naprawczych powinny być odpowiednio udokumentowane.

4. Zarządzanie ryzykiem dostawców

Większość dostawców usług budowała programy zarządzania ryzykiem dostawców w oparciu o kategorie uznawane za najważniejsze pięć lub więcej lat temu: centra danych, dostawców infrastruktury chmurowej, dostawców tzw. managed services oraz podmioty przetwarzające dane klientów.

Dostawcy aplikacji chmurowych i narzędzi programistycznych, takich jak systemy zgłoszeniowe (ticketowe), narzędzia zarządzania dostępem czy rozwiązania wspierające proces wdrożeń, często byli klasyfikowani jako podmioty o niskim lub średnim poziomie ryzyka, a tym samym objęci mniej rygorystycznym nadzorem.

Takie podejście przestaje być wystarczające. Naruszenie bezpieczeństwa powszechnie wykorzystywanego oprogramowania może prowadzić do naruszenia bezpieczeństwa wszystkich technologii z nim powiązanych.

Dostawcy usług powinni ponownie przeanalizować rejestry swoich dostawców, koncentrując się szczególnie na dostawcach oprogramowania oraz poddać ich ocenie z taką samą dokładnością, jaka była dotychczas zarezerwowana dla dostawców najwyższego ryzyka. Istotne jest zrozumienie, w jaki sposób dostawcy ci radzą sobie z zagrożeniami których ilość wzrasta w związku z używaniem AI.

5. Testy penetracyjne

Tradycyjny model obejmujący coroczny test zewnętrzny, czasami uzupełniony mniej rozbudowanymi testami wewnętrznymi, został zaprojektowany dla rzeczywistości, w której zaawansowane zdolności ofensywne były rzadkie, kosztowne i czasochłonne.

Aktualnie warunki te szybko się zmieniają.

Najnowsze rekomendacje mówią o wdrażaniu wielowarstwowych programów testowania obejmujących:

• ciągłą, zautomatyzowaną walidację zabezpieczeń systemów krytycznych dostępnych z zewnątrz,
• okresowe, pogłębione testy penetracyjne realizowane przez doświadczonych ekspertów, najlepiej korzystających również z narzędzi wspieranych przez AI,
• ćwiczenia typu red team weryfikujące zdolność organizacji do wykrywania i reagowania na ataki,
• ukierunkowane oceny bezpieczeństwa nowych lub istotnie zmodyfikowanych systemów przed ich wdrożeniem produkcyjnym.

Następna generacja raportów SOC

Przyszłe raporty SOC będą w coraz większym stopniu odzwierciedlać ciągłą walidację mechanizmów kontrolnych, bardziej szczegółowe testowanie oraz precyzyjny opis sposobu identyfikowania, priorytetyzowania i usuwania podatności.

Zmiana ta prawdopodobnie przesunie raportowanie z modelu opartego na okresowym zapewnieniu do bardziej dynamicznego podejścia bazującego na dowodach.

Jak podkreśla Cathy Cobey:

„Zaufanie do technologii opiera się na mechanizmach kontrolnych, które można jasno opisać, udokumentować i zweryfikować. Raportowanie SOC pomaga interesariuszom zrozumieć, w jaki sposób kontrole te odpowiadają na nowe ryzyka związane z AI.”

Raporty, które nie będą ewoluować wraz z oczekiwaniami rynku, mogą skutkować zwiększoną liczbą dodatkowych pytań oraz koniecznością przeprowadzania uzupełniających testów przez interesariuszy poszukujących większego poziomu pewności niż ten zapewniany przez tradycyjne raporty SOC.

Jak odpowiadać na nowe oczekiwania dotyczące raportowania SOC?

Osoby podejmujące strategiczne decyzje po stronie dostawców usług powinny skoncentrować się na trzech kluczowych działaniach:

1. Ocena systemu kontroli wewnętrznej w kontekście nowych oczekiwań
   Należy zweryfikować, czy istniejące kontrole są skuteczne wobec scenariuszy zagrożeń wykorzystujących AI, a nie wyłącznie wobec historycznych punktów odniesienia.
2. Wzmocnienie opisów systemów (System Description) i dokumentacji dowodowej
   Kluczowe znaczenie mają przejrzystość, szczegółowość i możliwość przetestowania prezentowanych kontroli.
3. Zapewnienie spójnej komunikacji z interesariuszami
   Sposób prezentowania kontroli i ryzyk powinien być jednolity wobec klientów, audytorów oraz innych grup odbiorców.