Wprowadzenie do problemu / definicja
Archiwa incydentów bezpieczeństwa przez lata pełniły głównie funkcję operacyjną i dowodową. Zawierają historię alertów, decyzji analityków, uzasadnienia zamknięcia zgłoszeń, reguły detekcyjne oraz informacje o fałszywych alarmach. W środowisku narzędzi wspieranych przez sztuczną inteligencję te same zbiory danych zyskują jednak nowe znaczenie, ponieważ mogą być wykorzystywane do walidacji produktów, strojenia modeli oraz rozwoju funkcji AI.
To przesunięcie zmienia tradycyjny model zaufania. Dane, które wcześniej pozostawały w granicach środowiska klienta lub były przetwarzane wyłącznie na potrzeby realizacji usługi, mogą dziś podlegać dodatkowym procesom analitycznym po stronie dostawcy. Z perspektywy cyberbezpieczeństwa oznacza to konieczność ponownej oceny retencji, kontroli dostępu, zgodności regulacyjnej oraz ryzyka ujawnienia wiedzy operacyjnej organizacji.
W skrócie
Wykorzystanie AI w platformach bezpieczeństwa zwiększa efektywność pracy SOC, ale jednocześnie może rozszerzać zakres użycia danych z incydentów poza ich pierwotny cel operacyjny.
- Największym problemem nie jest wyłącznie treść pojedynczego zgłoszenia, lecz wzorce widoczne w całym archiwum.
- Na podstawie historycznych danych można odtworzyć, które alerty są ignorowane, jakie reguły są wyciszane i gdzie organizacja ma luki detekcyjne.
- Jeśli dostawca uzyskuje zgodę na przechwytywanie danych do budowy lub walidacji modeli, archiwum incydentów staje się dodatkowym źródłem wiedzy o postawie obronnej klienta.
- Taki model zwiększa ryzyko związane z prywatnością, poufnością, zgodnością i audytem.
Kontekst / historia
Systemy SIEM, SOAR i platformy XDR od dawna automatyzują obsługę alertów, uruchamiają playbooki i zapisują wyniki działań. Historycznie zapis incydentu był jednak traktowany przede wszystkim jako dokumentacja przebiegu decyzji, potrzebna do rekonstrukcji zdarzeń, rozliczalności i dochodzeń po incydencie.
Rozwój copilotów bezpieczeństwa i asystentów AI w SOC wprowadził nowy wymiar przetwarzania informacji. Dane z promptów, odpowiedzi systemu, treści zgłoszeń, wyników wtyczek, działań agentów oraz zintegrowanych produktów bezpieczeństwa mogą podlegać osobnym ustawieniom współdzielenia danych. W praktyce oznacza to rozdzielenie dwóch decyzji: korzystania z usługi oraz zgody na dalsze wykorzystanie danych do poprawy produktu lub modelu.
To ważna zmiana również z perspektywy dostawców. Dokumentacja Microsoft Security Copilot przewiduje odrębne opcje dotyczące przechwytywania danych do oceny wydajności produktu oraz do budowy i walidacji modeli security AI. Pokazuje to, że wtórne wykorzystanie danych z SOC nie jest już jedynie kwestią techniczną, ale osobnym obszarem wymagającym jawnych ustawień, kontroli i decyzji właścicieli usługi.
Analiza techniczna
Z technicznego punktu widzenia największa wartość dla modeli AI nie musi wynikać z pojedynczego incydentu, lecz z korelacji pomiędzy tysiącami rekordów. Archiwum SOC tworzy bowiem metadataset opisujący zachowanie obrońców i ich sposób reagowania na zagrożenia.
Na podstawie takich danych można wydedukować między innymi:
- które typy alertów są systematycznie zamykane jako benign,
- jakie klasy zdarzeń są wyciszane lub obniżane priorytetowo,
- jakie progi szumu są akceptowane dla PowerShell, logowań, skryptów lub ruchu sieciowego,
- gdzie analitycy ufają automatyzacji, a gdzie ją obchodzą,
- w których obszarach reguły detekcyjne przestają być użyteczne operacyjnie.
Właśnie te wzorce są najbardziej wrażliwym składnikiem archiwum. Nawet bez pełnej ekspozycji treści incydentów sam zbiór decyzji, wyjątków i uzasadnień może odzwierciedlać mapę priorytetów bezpieczeństwa organizacji. Dla modelu AI to wartościowy materiał uczący, natomiast dla podmiotu trzeciego lub potencjalnego przeciwnika byłyby to informacje o taktyce obronnej i tolerancji na ryzyko.
Szczególnego znaczenia nabiera także warstwa audytowa. Organizacja powinna być w stanie jednoznacznie rozróżnić:
- co wiedział analityk na danym etapie,
- jakimi danymi dysponował system,
- jaką rekomendację wygenerował model,
- jaka decyzja została podjęta przez człowieka,
- które elementy rekordu trafiły do dalszego przetwarzania przez dostawcę.
Bez takiego rozdzielenia łatwo utracić rozliczalność. W postępowaniu audytowym lub prawnym może okazać się trudne wykazanie, czy konkretna decyzja była wynikiem świadomej oceny analityka, czy efektem sugestii modelu utrwalonej później w procesie operacyjnym.
Dodatkowo pojawia się klasyczny problem rozszerzenia powierzchni ryzyka. Jeżeli kopia danych lub ich pochodnych opuszcza domenę kontrolowaną przez klienta, rośnie liczba możliwych scenariuszy obejmujących naruszenie po stronie dostawcy, niezamierzony dostęp uprzywilejowany, ujawnienie na podstawie żądania prawnego, konflikt z polityką retencji oraz trudności z pełnym usunięciem danych historycznie przekazanych do walidacji lub ulepszania modeli.
Konsekwencje / ryzyko
Najważniejszą konsekwencją jest utrata wyłącznej kontroli nad wiedzą operacyjną SOC. Archiwum incydentów nie jest jedynie zbiorem logów, lecz również zapisem procesu decyzyjnego. Gdy zostaje wykorzystane wtórnie, organizacja może przestać kontrolować pełny cykl życia tych informacji.
Z perspektywy ryzyka technicznego i biznesowego szczególnie istotne są następujące obszary:
- Ryzyko ujawnienia postawy obronnej – zestaw zamknięć zgłoszeń, wyjątków i decyzji tuningowych może wskazywać, gdzie organizacja ma obniżoną czułość detekcji i jakie techniki ataku generują zbyt dużo szumu, by były eskalowane.
- Ryzyko regulacyjne i kontraktowe – dane z incydentów mogą zawierać informacje osobowe, dane klientów, tajemnice przedsiębiorstwa, wskaźniki kompromitacji, opisy architektury oraz artefakty śledcze.
- Ryzyko audytowe – brak jasnej granicy pomiędzy funkcją dowodową archiwum a funkcją rozwojową po stronie dostawcy utrudnia obronę integralności procesu reagowania.
- Ryzyko operacyjne – domyślne ustawienia współdzielenia danych, różnice we wdrożeniu usługi i niski poziom świadomości właścicieli produktu mogą prowadzić do niezamierzonego udostępniania informacji.
Rekomendacje
Organizacje wdrażające AI do operacji bezpieczeństwa powinny traktować archiwum incydentów jako dane o podwyższonej wrażliwości modelowej, a nie wyłącznie jako klasyczne dane operacyjne.
- Przegląd ustawień współdzielenia danych – należy sprawdzić, czy platforma AI przechwytuje dane do walidacji wydajności produktu, budowy modeli lub innych celów wtórnych, a także zweryfikować ustawienia tenantu i opcje domyślne.
- Rozdzielenie zgody na usługę od zgody na rozwój modelu – korzystanie z asystentów AI nie powinno automatycznie oznaczać akceptacji wykorzystania treści zgłoszeń, reguł, notatek analityków i promptów do poprawy modelu.
- Klasyfikacja danych z SOC pod kątem użycia przez AI – warto wyodrębnić pola szczególnie wrażliwe, takie jak closure notes, rationale, suppression rules, artefakty śledcze, treści promptów czy zapytania analityczne.
- Minimalizacja danych – tam, gdzie to możliwe, należy ograniczyć zakres danych trafiających do komponentów AI poprzez redakcję danych osobowych, pseudonimizację i separację notatek śledczych.
- Wzmocnienie zapisów kontraktowych – umowy z dostawcami powinny jasno definiować cele przetwarzania, okres retencji, zasady usunięcia danych, lokalizację przetwarzania, prawo do audytu i obowiązki notyfikacyjne.
- Pełna ścieżka audytowa – należy utrwalać, które rekomendacje pochodziły od modelu, jakie decyzje podjął analityk oraz czy dane zostały objęte mechanizmem udostępnienia do walidacji lub poprawy modelu.
- Modelowanie zagrożeń dla AI w SOC – analiza ryzyka powinna uwzględniać nie tylko prompt injection czy halucynacje, ale także wtórne wykorzystanie archiwów incydentów i inferencję wzorców operacyjnych.
Podsumowanie
Archiwum incydentów bezpieczeństwa przestaje być wyłącznie repozytorium dowodowym. W środowiskach wspieranych przez AI może stać się również zasobem wykorzystywanym do rozwoju i walidacji modeli. To fundamentalna zmiana, ponieważ wraz z danymi technicznymi organizacja może ujawniać także własną logikę obrony, poziomy tolerancji szumu i sposób podejmowania decyzji.
Dla zespołów SOC, CISO oraz działów prawnych kluczowe staje się dziś nie tylko pytanie, czy narzędzie AI działa skutecznie, ale również co dokładnie dzieje się z danymi po zakończeniu incydentu. W praktyce bezpieczeństwo AI w SOC zaczyna się od kontroli nad wtórnym życiem archiwum incydentów.
Źródła
- https://www.darkreading.com/cyber-risk/ai-gave-your-incident-archive-second-job
- https://learn.microsoft.com/en-us/security-copilot/privacy-data-security
- https://learn.microsoft.com/en-us/copilot/security/owner-settings