Jak połączyć SIEM, SOAR i generatywną AI w spójny system reagowania na zagrożenia

Dlaczego samo SIEM i SOAR już nie wystarcza

Lawina alertów i zmęczenie analityków SOC

Średniej wielkości organizacja generuje dziś dziesiątki, a czasem setki tysięcy zdarzeń bezpieczeństwa dziennie. SIEM zbiera je grzecznie w jednym miejscu, normalizuje, koreluje i… wysyła dalej jako alerty. Problem zaczyna się wtedy, gdy tych alertów jest tak dużo, że żaden zespół SOC nie jest w stanie przerobić ich ręcznie. Powstaje typowe alert fatigue – analitycy przestają reagować na wszystko, bo zwyczajnie brakuje im czasu i uwagi.

W praktyce oznacza to, że:

• incydenty o niskiej istotności nigdy nie są zamykane albo wracają jak bumerang,
• prawdziwe, krytyczne ataki giną w szumie powiadomień,
• SOC funkcjonuje w trybie ciągłej reakcji zamiast mieć przestrzeń na analizę przyczynową i doskonalenie reguł.

Generatywna AI jest w tym miejscu naturalnym kandydatem do roli „pierwszej linii czytającej”, która potrafi szybko streścić dziesiątki podobnych alertów, wychwycić wspólne wzorce i przekuć je w kilka zrozumiałych „spraw” (cases). Dzięki temu człowiek widzi nie 100 ostrzeżeń, ale np. 3 scenariusze, którymi warto się zająć.

Sztywność reguł korelacyjnych w klasycznym SIEM

Reguły korelacyjne w SIEM są skuteczne tam, gdzie da się precyzyjnie opisać wzorzec: określona liczba nieudanych logowań, aktywność z podejrzanego kraju, podpis malware w logach EDR. Jednak atakujący rzadko trzymają się scenariuszy z dokumentacji. Modyfikują narzędzia, zmieniają kolejność kroków, mieszają techniki. Sztywna reguła często tego nie wychwyci, bo oczekuje dokładnego dopasowania.

SIEM nie „rozumie” kontekstu biznesowego. Nie widzi, że:

• dziwny ruch na porcie 445 jest o wiele groźniejszy na serwerze finansowym niż na stacji testowej,
• jeden alert na koncie administratora może być poważniejszy niż dziesięć alertów na koncie zwykłego użytkownika,
• ten sam hash pliku w różnych sieciach może mieć inne znaczenie, bo jedna jest środowiskiem testowym, inna produkcją.

Generatywna AI nie zastępuje reguł, ale może połączyć wyniki korelacji z dodatkowymi źródłami kontekstu i „opowiedzieć” historię zdarzeń: kto, co, kiedy, jak bardzo to nietypowe i gdzie są luki w informacji. To właśnie ten brak „opowieści” dokleja potem człowiek, analizując logi ręcznie.

SOAR jako silnik automatyzacji – zalety i ślepe punkty

SOAR świetnie wykonuje powtarzalne czynności: zbiera dodatkowe dane, blokuje adres IP, resetuje hasło, otwiera zgłoszenie w systemie ITSM. Gdy scenariusz jest dobrze opisany, SOAR działa jak precyzyjna maszyna. Problem pojawia się, gdy sytuacja wykracza poza przygotowany schemat – brakuje danych, logi są niespójne albo incydent jest złożony i nie pasuje do żadnego z istniejących playbooków.

Bez „rozumienia” kontekstu SOAR będzie:

• zamykał sprawy zbyt wcześnie, bo brakuje mu odpowiedzi na konkretne pytania,
• eskalował do człowieka niemal wszystko, co odbiega od szablonu,
• podejmował działania nadmiarowe (np. blokada całego zakresu adresów, gdy zagrożenie dotyczy jednego hosta).

Generatywna AI może pełnić rolę brakującej warstwy interpretacji: wyjaśnia, które dane są sprzeczne, wskazuje dziury informacyjne, proponuje kilka możliwych wariantów reakcji wraz z oceną ryzyka. SOAR nadal „klika przyciski”, ale robi to na podstawie bogatszej, bardziej zniuansowanej rekomendacji.

Naturalne miejsce generatywnej AI w krajobrazie SOC

Modele językowe (LLM) świetnie radzą sobie z tekstem, strukturą narracji i łączeniem rozproszonych faktów w spójny opis. To dokładnie to, czego brakuje klasycznym narzędziom bezpieczeństwa: umiejętności zbudowania „obrazka” sytuacji. Integracja SIEM, SOAR i generatywnej AI pozwala zamienić stos alertów w przystępne streszczenia, hipotezy przyczyny, listy zaleceń i konkretne playbooki.

W praktyce generatywna AI może:

• być pierwszą warstwą triage’u tekstowego,
• wzbogacać alerty o podsumowania i priorytety,
• podpowiadać analitykom kroki dochodzenia,
• pisać wstępne raporty, które człowiek tylko koryguje.

Centralny cel pozostaje ten sam: odciążyć ludzi od najniższej warstwy pracy „czytelniczej” i procesowej, a jednocześnie nie oddawać AI pełnej kontroli nad decyzjami, szczególnie w krytycznych incydentach.

Rola SIEM, SOAR i generatywnej AI w jednym ekosystemie

SIEM jako zmysły systemu bezpieczeństwa

SIEM to oczy i uszy ekosystemu reagowania. Z punktu widzenia integracji z AI kluczowe są trzy funkcje: zbieranie, normalizacja i korelacja. Każdy log z firewalli, serwerów, aplikacji, systemów chmurowych czy EDR trafia do jednego „mózgu analitycznego”, który próbuje je sprowadzić do wspólnego mianownika.

Bez dobrze skonfigurowanego SIEM generatywna AI będzie skazana na chaos: dostanie niekompletne, niespójne dane z różnych źródeł, których nie da się łatwo powiązać z kontem, hostem czy scenariuszem ataku. Dlatego:

• normalizacja pól (źródło, użytkownik, IP, typ zdarzenia) jest absolutną podstawą,
• oznaczanie ważności systemów (np. tagi „krytyczny”, „produkcyjny”) w logach ułatwia później priorytetyzację,
• przemyślana struktura incydentów (cases) w SIEM definiuje, co w ogóle będzie „jednostką analizy” dla AI.

SIEM pozostaje głównym miejscem, w którym powstaje „surowy materiał” dla generatywnej AI: logi, metadane, wyniki korelacji, informacje o źródłach i kierunkach ruchu.

SOAR jako mięśnie i układ nerwowy

SOAR podnosi z ziemi to, co SIEM podświetlił na czerwono. W świecie zintegrowanym z generatywną AI SOAR pełni rolę „mięśni” i „układu nerwowego” – wykonuje akcje, komunikuje się z innymi systemami, aktualizuje zgłoszenia, zamyka pętle zwrotne.

Typowe zadania SOAR przy integracji z AI:

• wywoływanie usługi AI (lokalnej lub chmurowej) z właściwym kontekstem,
• zapisywanie odpowiedzi AI i przekładanie ich na kolejne kroki playbooka,
• wymuszanie punktów decyzyjnych, w których człowiek może zatwierdzić lub odrzucić propozycje modelu,
• rejestrowanie, jakie rekomendacje AI zostały przyjęte, a jakie odrzucone – do późniejszej analizy jakości.

SOAR nie musi być „inteligentny” w ludzkim sensie – ma być przewidywalny i powtarzalny. Inteligencja pojawia się, gdy podłączymy do niego generatywną AI zdolną do tworzenia opisów, wariantów reakcji i streszczeń.

Generatywna AI jako mózg wspomagający analityka SOC

Generatywna AI nie zastępuje analityka, ale działa jak bardzo szybki, niezmęczony współpracownik, który świetnie czyta i streszcza tekst. Przy dobrze zaprojektowanej integracji może pełnić kilka ról naraz:

• Asystent triage’u – grupuje alerty, proponuje priorytety, wskazuje brakujące informacje.
• Konsultant techniczny – na podstawie logów i opisu incydentu sugeruje możliwe przyczyny oraz kolejne kroki dochodzenia.
• Redaktor raportów – tworzy szkice raportów powłamaniowych, komunikatów do biznesu, powiadomień do użytkowników.
• „Żywy FAQ” SOC-u – odpowiada na pytania typu „co zwykle generuje taki alert?” czy „jak w tym środowisku definiujemy krytyczność hosta?”.

Kluczowe jest świadome ograniczenie zakresu decyzji, które AI może podejmować automatycznie. Tam, gdzie efekty są nieodwracalne (np. szerokie blokady, wyłączenia serwisów produkcyjnych), generatywna AI powinna jedynie sugerować, a nie działać samodzielnie.

Przykładowy przepływ incydentu w zintegrowanym systemie

Dobrym sposobem na zrozumienie roli każdego elementu jest prześledzenie uproszczonego scenariusza:

1. SIEM wykrywa nietypowy wzorzec logowań na konto uprzywilejowane (korelacja kilku reguł).
2. Alert trafia do SOAR, który wywołuje usługę generatywnej AI z paczką danych: logi, dane o użytkowniku, krytyczność systemu, wcześniejsze incydenty.
3. Generatywna AI:
   • tworzy streszczenie sytuacji w języku naturalnym,
   • ocenia prawdopodobieństwo kilku scenariuszy (np. przejęcie konta, błąd konfiguracji VPN, podróż użytkownika),
   • proponuje 2–3 warianty reakcji, z opisem plusów i minusów.
4. Playbook SOAR prezentuje to analitykowi w konsoli: opis, rekomendację i przyciski „zatwierdź wariant A/B” lub „eskaluj”.
5. Po wyborze wariantu SOAR automatycznie:
   • blokuje sesję,
   • wysyła powiadomienie do właściciela konta,
   • tworzy zgłoszenie w systemie ITSM z już wypełnionym opisem od AI.

Na koniec cały przebieg jest logowany – łącznie z tym, co zasugerowała AI i co zrobił człowiek – co przydaje się przy ocenie jakości i dalszym trenowaniu modeli.

Warstwa danych: jak przygotować SIEM pod współpracę z generatywną AI

Jakie dane są kluczowe dla generatywnej AI w SOC

Modele generatywne są łakome na kontekst. Im więcej sensownie opisanych informacji dostaną o incydencie, tym lepsze będą ich odpowiedzi. Najważniejsze kategorie danych, które warto „nauczyć się” przekazywać z SIEM:

• Opisy incydentów i alertów – krótkie, zrozumiałe streszczenia zamiast samych sygnatur i kodów.
• Surowe logi w formie tekstu – przynajmniej próbki kluczowych wpisów logów, dobrze oznaczone źródłem i czasem.
• Metadane o użytkownikach – rola w organizacji, dział, typ konta (uprzywilejowane, serwisowe), lokalizacja.
• Informacje o systemach – krytyczność biznesowa, środowisko (prod, test, dev), odpowiedzialny zespół.
• Historia powiązanych incydentów – czy podobne zdarzenia były już obserwowane, jak zostały rozwiązane.

Dobrym wzorcem jest budowanie „karty incydentu” już w SIEM, tak aby AI dostawała nie tylko logi, ale też ich wstępną interpretację: co jest symptomem, co jest środowiskiem, a co wcześniej ustalono jako normalne zachowanie.

Normalizacja i standaryzacja – wspólny język dla AI

Bez ujednoliconego słownictwa SIEM będzie mówił do AI tak, jak pięć różnych działów mówi między sobą: każdy po swojemu. Żeby generatywna AI mogła sensownie łączyć dane z wielu źródeł, warto zadbać o:

• spójne nazewnictwo pól – np. wszędzie „src_ip”, „dst_ip”, „username”, „hostname”,
• jednolity słownik typów zdarzeń – logowanie, zmiana uprawnień, modyfikacja pliku, uruchomienie procesu, itp.,
• tagi i klasyfikacje – np. kategorie MITRE ATT&CK, poziom ryzyka, rodzaj systemu.

Generatywna AI może uczyć się mapowania terminów, ale każda niestandardowa nazwa lub skrót to ryzyko błędnej interpretacji. Lepiej „odrobić lekcję” na poziomie SIEM niż liczyć, że model zgadnie, co oznacza pole „user_nm” w jednym systemie, a „u_name” w innym.

Wzbogacanie danych w SIEM przed przekazaniem ich AI

SIEM coraz częściej potrafi łączyć dane techniczne z biznesowymi: informacje z CMDB, katalogu tożsamości (IdM), systemów HR, bazy serwerów. Generatywna AI bardzo na tym zyskuje. Jeśli do logu logowania dołożymy:

• czy konto należy do pracownika, kontraktora czy usługi,
• czy host jest produkcyjny czy testowy,
• do jakiego działu i strefy sieciowej należy,

model językowy będzie mógł oszacować, na ile incydent dotyka krytycznych zasobów. Dzięki temu AI nie traktuje wszystkich hostów i kont tak samo, tylko rozumie ich wagę w kontekście biznesowym.

Przykładowo, dwa identyczne alerty logowania z nietypowego kraju mogą mieć różną ocenę ryzyka, jeśli dotyczą:

• kontrolera domeny w sieci produkcyjnej,
• stacji testowej w izolowanej podsieci labo.

Ograniczanie kontekstu: ile danych naprawdę potrzebuje model

Naturalny odruch brzmi: „dajmy AI wszystko, co mamy, niech sobie poradzi”. To prosty przepis na szum informacyjny, koszty i błędne wnioski. Model językowy nie musi widzieć całej historii logów z ostatniego roku, żeby dobrze ocenić pojedynczy incydent.

Praktycznym podejściem jest budowanie „paczki kontekstu” dla każdego wywołania AI. Można ją traktować jak dobrze przygotowaną teczkę dla konsultanta: tylko to, co ważne, ale na tyle bogate, by nie zadawał dziesięciu dodatkowych pytań. Typowa paczka zawiera:

• skrótowy opis incydentu z SIEM (tytuł, kategoria, poziom ryzyka),
• najważniejsze logi – np. ostatnie 50–100 wpisów powiązanych z danym hostem lub kontem,
• kluczowe atrybuty biznesowe (krytyczność systemu, typ konta, lokalizacja),
• streszczenie 1–2 podobnych incydentów z przeszłości, jeśli istnieją.

SOAR może mieć kilka szablonów budowania takiej paczki, zależnie od rodzaju incydentu (logowania, malware, DLP, podejrzenie exfiltracji). Dzięki temu model nie tonie w danych, a jednocześnie nie musi zgadywać, z czym ma do czynienia.

Ciekawy efekt pojawia się, gdy zaczniemy porównywać skuteczność modeli przy bogatym kontra ubogim kontekście. W wielu SOC-ach po pierwszych próbach okazało się, że krótsze, ale lepiej wyselekcjonowane „teczki” dają trafniejsze i bardziej zwięzłe odpowiedzi AI.

Bezpieczeństwo i prywatność danych w integracji z AI

Gdy tylko w grę wchodzą logi użytkowników, treści e-maili czy dane systemów finansowych, pytanie „gdzie to wszystko trafia?” przestaje być teoretyczne. Integracja SIEM/SOAR z generatywną AI wymusza kilka decyzji architektonicznych.

Na początek trzeba rozstrzygnąć, czy model będzie działał:

• lokalnie (on-premise / w prywatnej chmurze) – pełna kontrola nad danymi, większe koszty utrzymania i mniejsza elastyczność skali,
• w usłudze chmurowej – wygoda, aktualne modele, ale wymóg bardzo restrykcyjnego zarządzania tym, co jest wysyłane.

Niezależnie od wyboru, w warstwie SIEM/SOAR dobrze zadziała kilka praktyk „higienicznych”:

• maskowanie wrażliwych danych (np. pełnych numerów PESEL, kart, haseł jednorazowych) przed wysłaniem do modelu,
• anonimizacja identyfikatorów użytkowników tam, gdzie nie jest istotna tożsamość konkretnej osoby, a jedynie rola,
• wyraźne rozdzielenie promptów „produkcyjnych” od testowych – by w testach nie wyciekały realistyczne dane,
• rejestrowanie, jakie pola i do jakiego modelu zostały przekazane – na wypadek audytu lub incydentu związanego z danymi.

W praktyce często kończy się na stworzeniu w SOAR specjalnego modułu „sanityzującego” dane przed wywołaniem AI. To takie wirtualne sitko, które przepuszcza tylko to, co jest niezbędne do analizy bezpieczeństwa, a odrzuca lub maskuje resztę.

Kontrola jakości i „uczenie się” z własnych incydentów

Generatywna AI nie uczy się magicznie z każdego nowego incydentu, jeśli nie damy jej do tego narzędzi. W systemie SIEM/SOAR można zbudować cykl, który przypomina szkolenie nowego analityka na podstawie archiwalnych spraw.

Podstawą jest konsekwentne zbieranie informacji o tym, jak zareagował człowiek na rekomendacje AI:

• czy sugerowana klasyfikacja incydentu była poprawna,
• czy rekomendowany plan działań został przyjęty, częściowo zmodyfikowany czy całkiem odrzucony,
• jak ostatecznie zakończył się incydent (fałszywy alarm, próba bez powodzenia, realne naruszenie).

Te dane można potem wykorzystać na dwa sposoby. Po pierwsze – do „twardych” metryk (np. odsetek trafnych rekomendacji), które wpływają na decyzję, gdzie AI może działać bardziej automatycznie. Po drugie – jako materiał do trenowania wyspecjalizowanych modeli (fine-tuning) lub budowania zestawów przykładów dla promptów.

W praktyce sprawdza się coś na kształt „komisji jakości”, która raz na kwartał przegląda próbkę incydentów z udziałem AI. Nie musi to być formalne ciało – często wystarczą 2–3 osoby z SOC i architekt bezpieczeństwa, którzy przejrzą konkretne case’y i zaktualizują szablony promptów oraz playbooki.

Warstwa operacyjna: jak wpleść AI w codzienną pracę SOC

Projektowanie ról i odpowiedzialności między ludźmi a AI

Kluczowa decyzja nie brzmi „czy używamy AI?”, tylko „do czego dokładnie jej używamy, a do czego nie?”. W zespole SOC można myśleć o AI jak o dodatkowym członku zespołu z jasno zdefiniowaną rolą.

Jedno z praktycznych podejść to podział na trzy poziomy autonomii:

• Poziom 1 – tylko rekomendacje: AI opisuje incydent, proponuje klasyfikację i działania, ale niczego nie wykonuje automatycznie.
• Poziom 2 – działania odwracalne: AI może inicjować akcje, które łatwo cofnąć (np. dodanie reguły monitorującej, wysłanie zapytania do użytkownika, zebranie dodatkowych logów).
• Poziom 3 – działania ingerujące: AI tylko sugeruje, a ostateczną decyzję o blokadach, izolacji hostów czy zmianach w konfiguracji podejmuje człowiek.

Taki model ról można dodatkowo powiązać z poziomami incydentów. Przykładowo: w incydentach niskiego ryzyka (np. powtarzalne skanowania z zewnątrz) AI ma więcej swobody operacyjnej, a w zdarzeniach dotykających systemów krytycznych działa wyłącznie jako doradca.

Nowy układ dnia pracy analityka SOC

W zespole, który sensownie wdrożył generatywną AI, dzień pracy wygląda inaczej niż kilka lat temu. Zamiast ręcznego przeklikiwania dziesiątek podobnych alertów analityk częściej patrzy na podsumowania „paczek zdarzeń” i ich ocenę ryzyka.

Typowy rytm może wyglądać tak:

1. AI grupuje przychodzące alerty w wiązki (np. „podejrzenie przejęcia konta X”, „podejrzany ruch lateralny na segmencie Y”).
2. SOAR zleca modelowi streszczenie najważniejszych wiązek w kilku akapitach – analityk widzi listę „spraw dnia” zamiast setek pojedynczych logów.
3. Przy każdej wiązce AI pokazuje sugerowaną klasyfikację (np. „prawdopodobny brute-force bez sukcesu”) oraz 2–3 scenariusze działania.
4. Analityk wybiera ścieżkę: „akceptuj i automatyzuj”, „analiza ręczna”, „eskalacja do L2/L3”.

Przykładowo, w jednym z SOC-ów po wdrożeniu AI juniorzy SOC spędzali mniej czasu na „odklikaniu” alertów o niskim ryzyku, a więcej na analizie ciekawych przypadków, gdzie AI miała wątpliwości. To naturalne „podciąganie” zespołu w górę – mniej pracy mechanicznej, więcej śledztw.

Współpraca z innymi zespołami: IT, DevOps, biznes

SIEM, SOAR i generatywna AI rzadko kończą swoje działanie na ścianie SOC. Efekt końcowy często ląduje w skrzynkach administratorów, zespołów DevOps albo u właścicieli procesów biznesowych. To tam rekomendacje AI muszą być zrozumiałe.

SOAR może wykorzystać AI nie tylko do analizy, lecz także do „tłumaczenia” na język odpowiedni dla odbiorcy. Ten sam incydent można więc przedstawić w kilku wariantach:

• wersja techniczna – dla administratora systemu (komendy, logi, sugestie ścieżek debugowania),
• wersja operacyjna – dla menedżera IT (wpływ na SLA, ryzyka dalszej eksploatacji),
• wersja biznesowa – dla właściciela procesu (czy dane mogły wyciec, czy klienci odczują skutki).

Takie „wielowarstwowe” raportowanie przydaje się chociażby przy incydentach, w których decyzja o przestojach musi być podjęta szybko. Zamiast tłumaczyć telefonicznie, co oznacza „podejrzenie ruchu C2 na serwerze fakturowym”, SOC może wysłać krótki, zrozumiały opis wygenerowany przez AI, a techniczne szczegóły zostawić w załączniku dla zespołu IT.

Warstwa automatyzacji: projektowanie playbooków z AI w roli partnera

Gdzie w playbooku jest miejsce na AI

Playbooki SOAR z AI w tle wyglądają nieco inaczej niż tradycyjne, oparte wyłącznie na twardych regułach. Zamiast długich drzew warunków „jeśli X i Y, to zrób Z”, pojawiają się kroki typu „poproś AI o ocenę” lub „poproś AI o wygenerowanie raportu”.

Typowe punkty, w których można wpiąć generatywną AI w istniejące playbooki, to:

• triage – AI ocenia istotność incydentu na podstawie opisu, logów i metadanych,
• klasyfikacja – przypisanie incydentu do kategorii (np. według MITRE ATT&CK, wewnętrznego katalogu typów zdarzeń),
• dobór działań – wygenerowanie propozycji kroków reagowania, z oznaczeniem tych bezpiecznych do automatyzacji,
• dokumentacja – tworzenie wstępnych opisów incydentu dla systemu ITSM czy narzędzi do zarządzania incydentami.

Strukturalnie można myśleć o AI jako o „czarnym pudełku” między krokami technicznymi. Przykład: „pobierz logi → zleć AI analizę i klasyfikację → na podstawie odpowiedzi wybierz gałąź playbooka”. Dzięki temu logika techniczna pozostaje stabilna, a inteligentna warstwa opisu może się z czasem zmieniać bez przebudowy całego procesu.

Projektowanie promptów jak interfejsów API

Prompt to nowy rodzaj interfejsu. Jeśli jest chaotyczny, model odpowie chaotycznie. W środowisku SIEM/SOAR prompt powinien być traktowany równie poważnie jak definicja API do zewnętrznego systemu.

Dobrą praktyką jest trzymanie promptów jako wersjonowanych artefaktów, np. w repozytorium Git. Każdy prompt powinien:

• mieć jasny cel (np. „klasyfikacja incydentu według katalogu X”),
• otrzymywać z góry zdefiniowany zestaw danych wejściowych (np. incident_summary, logs_sample, asset_criticality),
• zwracać odpowiedź w formacie zrozumiałym dla SOAR (np. JSON z polami risk_level, mitre_techniques, actions).

Przykładowy fragment promptu dla klasyfikacji mógłby wyglądać tak (w uproszczeniu):

Cel: sklasyfikuj incydent bezpieczeństwa na podstawie dostarczonych danych.

Dostaniesz:
1. Podsumowanie incydentu (tekst).
2. Próbkę logów (tekst).
3. Atrybuty zasobów (JSON).

Zwróć JSON o strukturze:
{
  "risk_level": "low|medium|high|critical",
  "likely_scenario": "tekst",
  "mitre_techniques": ["Txxxx", "..."],
  "recommended_actions": ["...", "..."]
}

SOAR po otrzymaniu takiej odpowiedzi może ją wprost zmapować na kolejne kroki playbooka, zamiast analizować luźny tekst. To oszczędza czas i zmniejsza ryzyko niejednoznacznych interpretacji.

Fallbacki i plany awaryjne

Model AI, tak jak każdy zewnętrzny komponent, może zawieść: będzie niedostępny, zbyt wolny albo zwróci odpowiedź, z której nie da się wyciągnąć sensownych wniosków. Playbooki muszą uwzględniać te sytuacje.

Prosty, ale skuteczny schemat to:

• limit czasowy na odpowiedź AI (np. 5–10 sekund),
• walidacja formatu odpowiedzi (czy JSON jest poprawny, czy pola nie są puste),
• ścieżka awaryjna w playbooku (np. przejście na zestaw klasycznych reguł lub eskalacja do analityka bez rekomendacji AI).

W jednym z zespołów SOC świetnie zadziałało logowanie „dziwnych” odpowiedzi modeli, które nie przeszły walidacji. Raz na jakiś czas analityk przeglądał je, poprawiał prompty albo dodawał nowe instrukcje typu „nie używaj języka naturalnego tam, gdzie oczekujemy kodów błędów”. System nie staje wtedy w miejscu – powoli się doszlifowuje.

Warstwa techniczna: architektura integracji SIEM, SOAR i generatywnej AI

Modele wdrożeń: centralny broker AI czy bezpośrednie połączenia

SIEM i SOAR mogą kontaktować się z AI na różne sposoby. Najprostsze wydaje się wpięcie modelu bezpośrednio w SOAR – jako kolejnego „konektora”. W większych organizacjach więcej sensu ma jednak centralna warstwa pośrednicząca, swoisty „broker AI”.

Broker AI to usługa, która:

• przyjmuje zapytania z różnych systemów (SIEM, SOAR, narzędzia analityczne),
• normalizuje je do wspólnego formatu,

Bezpieczeństwo i zgodność: gdzie lądują dane z SOC

Połączenie SIEM, SOAR i generatywnej AI podnosi czułość systemu, ale równocześnie odsłania go na nowe wektory ryzyka – głównie związane z danymi. To, co do tej pory było „zamknięte” w logach i wewnętrznych raportach, nagle zaczyna krążyć przez modele językowe, często hostowane poza organizacją.

Najważniejsze decyzje dotyczą dwóch obszarów: jakie dane wysyłasz do modelu oraz gdzie ten model działa. Z tych dwóch elementów rodzi się cała strategia bezpieczeństwa.

Przy projektowaniu integracji dobrze jest rozłożyć dane na kategorie wrażliwości. W praktyce przydaje się prosty podział:

• dane anonimowe lub zagregowane – np. liczba błędnych logowań, rozkład typów incydentów,
• dane pseudonimizowane – identyfikatory użytkowników zamienione na aliasy, IP zmaskowane w części,
• dane pełne – logi z adresami, nazwami kont, fragmentami treści e-maili.

Generatywną AI można „karmić” głównie danymi z dwóch pierwszych kategorii, a pełne logi zostawiać dla modeli działających wewnątrz organizacji lub w wydzielonym środowisku o podwyższonym poziomie ochrony. Dla SOC-u praktycznie sprowadza się to do dwóch ścieżek w playbooku: „wyślij do modelu chmurowego wersję zanonimizowaną” albo „wyślij do modelu on-prem pełne dane”.

Anonimizacja i minimalizacja danych przed wysłaniem do modelu

Zanim jakiekolwiek dane opuszczą środowisko SIEM/SOAR, powinny przejść przez warstwę przekształceń bezpieczeństwa. Zamiast rozbudowanych procesów ręcznych, lepiej zbudować kilka prostych, powtarzalnych reguł.

Typowy pipeline może wyglądać tak:

1. SOAR zbiera dane z SIEM i innych źródeł (logi, CMDB, EDR).
2. Broker AI lub dedykowany moduł anonimizujący usuwa lub zamienia pola wrażliwe (np. nazwiska, e-maile, pełne IP, numery biletów z systemu ITSM).
3. Dopiero zanonimizowany pakiet trafia do modelu generatywnego.

Do anonimizacji można użyć prostych wzorców (regexy na e-maile, IP, numery telefonów) oraz słowników z CMDB (mapowanie nazw hostów na aliasy). Istotne, by transformacja była odwracalna wewnątrz SOC: AI widzi user_1234, ale analityk na podstawie mapy w CMDB może ustalić, że to faktycznie login kluczowego administratora.

Przy okazji wprowadza się naturalną zasadę minimalizacji: do modelu wysyłasz tylko te logi i pola, które są potrzebne do odpowiedzi na konkretne pytanie promptu. Nie trzeba wysyłać pełnej transkrypcji HTTP, jeśli AI ma tylko ocenić trend nieudanych logowań.

Modele on-prem vs usługi chmurowe w środowisku SOC

Dylemat „chmura czy on-prem” w kontekście AI nabiera nowego wymiaru, gdy w grę wchodzą incydenty bezpieczeństwa. Jedna organizacja będzie spokojnie korzystać z komercyjnego API, inna – z powodu regulacji – nie może wynieść żadnego logu poza własny DC.

Praktyczny kompromis to architektura hybrydowa:

• modele chmurowe – do zadań analityczno-opisowych, gdzie dane można zanonimizować (streszczenia incydentów, generowanie raportów dla biznesu, tłumaczenia między językami),
• modele on-prem – do operacji na pełnych logach, kontekstach użytkowników, danych z systemów finansowych i medycznych,
• specjalizowane modele mniejsze (np. wektorowe, klasyfikatory) – do powtarzalnych zadań, takich jak klasyfikacja znanych wzorców incydentów.

W jednym z banków, z którym pracował doświadczony architekt SOC, raporty dla biznesu generował model w chmurze, natomiast wszelkie decyzje związane z blokowaniem kont lub analizą transakcji przechodziły wyłącznie przez model utrzymywany w segmencie o najwyższej klasie bezpieczeństwa. Z punktu widzenia analityka interfejs wyglądał jednolicie – różnica polegała tylko na tym, który „silnik” odpowiadał na pytania.

Zarządzanie tajemnicą przedsiębiorstwa i danymi klientów

Logi zawierają znacznie więcej niż tylko adresy IP – często pojawiają się tam wewnętrzne identyfikatory systemów, nazwy projektów, a nawet fragmenty komunikacji z klientem. Dla modelu AI to po prostu tekst, ale dla konkurencji – złoto.

Dlatego obok klasycznej anonimizacji przydaje się jeszcze kategoryzacja wrażliwości kontekstu. Niektóre informacje są do zaakceptowania w modelu chmurowym po zanonimizowaniu (np. „system fakturowy klasy ERP”), inne nie powinny się tam pojawić w ogóle (wewnętrzne nazwy produktów, numery kont klientów, opisy podatności zero-day w środowisku). Taką politykę można utrwalić w postaci prostych reguł:

• Każdy prompt zawiera tag poziomu wrażliwości – np. sens_low, sens_high.
• Broker AI na podstawie taga decyduje, do którego modelu trafi zapytanie (chmura/on-prem) lub czy w ogóle je odrzuci.
• SOAR wymusza ustawienie taga już na poziomie playbooka – autor playbooka decyduje, czy dany krok może pracować na logach wrażliwych.

Taki mechanizm wymusza refleksję: „czy faktycznie potrzebuję pełnych danych klienta, żeby uzyskać odpowiedź od modelu?”. W wielu scenariuszach wystarczy prosty opis typu: „klient z sektora medycznego, system obsługujący wrażliwe dane osobowe”.

Monitoring samej AI: obserwowalność i logowanie decyzji

Skoro SOC monitoruje wszystkie istotne systemy organizacji, logicznym krokiem jest objęcie tym monitoringiem również samej warstwy AI. Modele i prompty stają się nowym „komponentem”, który trzeba obserwować, mierzyć i okresowo audytować.

Przydają się zwłaszcza trzy rodzaje metryk:

• metryki techniczne – czas odpowiedzi, liczba błędów, dostępność modelu,
• metryki jakościowe – procent odpowiedzi wymagających poprawy przez analityka, liczba błędnych klasyfikacji, częstość korzystania ze ścieżki awaryjnej bez AI,
• metryki operacyjne – oszczędność czasu w triage, liczba automatycznie zamkniętych incydentów bez regresji jakości, skrócenie średniego czasu reakcji.

Te metryki warto zbierać tak samo jak logi z innych systemów – trafiają do SIEM, gdzie da się na nich zbudować dashboardy czy alerty. Jeśli model nagle zaczyna odpowiadać wolniej lub liczba „nieużywalnych” odpowiedzi rośnie, SOC dostaje sygnał równie czytelny jak przy problemach z firewallami.

Kluczowym elementem jest logowanie kontekstu decyzji AI. Dla każdej rekomendacji dobrze jest zachować:

• skrócony prompt (bez pełnych danych wrażliwych, ale z informacją o scenariuszu),
• wersję odpowiedzi modelu,
• kontekst, w którym decyzja została użyta (numer incydentu, ID playbooka, poziom autonomii).

Takie logi przydają się przy przeglądach jakości, ale również w razie sporów – np. gdy trzeba wykazać, dlaczego określony incydent został sklasyfikowany jako niski priorytet. Można wtedy cofnąć się do konkretnej rekomendacji modelu i ocenić, czy błąd był po stronie danych, promptu, czy samego modelu.

Cykl życia modeli i promptów w SOC

Modele i prompty nie są „instalowane raz na zawsze”. Incydenty się zmieniają, techniki ataków ewoluują, a oczekiwania wobec SOC rosną. Bez świadomego zarządzania cyklem życia AI system po roku będzie już zupełnie nieadekwatny do rzeczywistości.

Można podejść do tego podobnie jak do zarządzania regułami korelacji w SIEM:

• okresowe przeglądy – np. raz na kwartał zespół przegląda najczęściej używane prompty i ocenia, gdzie generują zbędne szumy lub pomijają ważne konteksty,
• testy A/B – dwie wersje promptu (lub dwa modele) analizują ten sam podzbiór incydentów, a SOC porównuje skuteczność,
• proces „pull request” dla zmian – każda istotna zmiana promptu lub konfiguracji modelu przechodzi przegląd koleżeńki, jak zmiana w kodzie.

W praktyce świetnie działa proste workflow: analityk widzi, że model notorycznie myli określony typ zdarzeń (np. skanowania z zewnątrz z realnymi próbami brute-force). Zgłasza to jako „issue” w repozytorium promptów, proponuje zmianę i razem z bardziej doświadczonym kolegą testuje nową wersję na wycinku danych historycznych. Dopiero po takim mini-audytu aktualizacja trafia na produkcję.

Szkolenie zespołu SOC do pracy z AI

Technologia to tylko połowa układanki. Druga połowa to ludzie, którzy z niej korzystają. Analityk, który nie ufa rekomendacjom modelu albo nie rozumie jego ograniczeń, będzie cały czas „wyłączał automatykę” i wracał do ręcznej pracy.

Dobry program wdrożenia AI w SOC obejmuje kilka bloków szkoleniowych:

• podstawy działania modeli językowych – bez formułek akademickich, ale z omówieniem, czym jest halucynacja, dlaczego model nie „wie” niczego poza danymi wejściowymi i jak prompty wpływają na odpowiedzi,
• praktyka pracy z promptami – wspólne pisanie i poprawianie promptów dla konkretnych incydentów, testowanie różnych sformułowań, wyciąganie wniosków,
• scenariusze „co może pójść źle” – ćwiczenia na błędnych rekomendacjach, które uczą zdrowego sceptycyzmu i tego, kiedy konieczna jest ręczna weryfikacja.

W jednym z SOC-ów zorganizowano krótkie „sesje retro” raz w tygodniu: zespół przeglądał trzy incydenty, w których AI szczególnie pomogła, oraz trzy, w których się pomyliła. Takie realistyczne przykłady budują intuicję znacznie lepiej niż dokumentacja. Po kilku tygodniach analitycy zaczynają lepiej wyczuwać, w jakich przypadkach model jest wiarygodny, a w jakich wymaga dodatkowego sprawdzenia.

Zmiana roli SOC w organizacji dzięki AI

Kiedy SIEM, SOAR i generatywna AI zaczynają współgrać, SOC powoli przestaje być wyłącznie „centrum gaszenia pożarów”. Coraz częściej staje się źródłem wiedzy o tym, jak w praktyce funkcjonują procesy biznesowe, gdzie są słabe punkty i które obszary wymagają inwestycji.

Generatywna AI pomaga zamienić surowe logi w klarowne historie: „dlaczego w tym miesiącu mieliśmy wzrost prób phishingu wobec działu sprzedaży”, „gdzie użytkownicy najczęściej popełniają błędy w MFA”, „które systemy są nieproporcjonalnie obciążone alertami”. Wcześniej takie wnioski wymagały dni analizy; teraz da się je wstępnie wygenerować w ciągu godzin, a nawet minut.

To z kolei zmienia dynamikę rozmowy z biznesem. SOC przestaje przychodzić wyłącznie z komunikatem „tu jest incydent, potrzebujemy downtime’u”, a częściej pojawia się z konkretną propozycją zmian: uproszczenie procesu logowania, lepsze szkolenia użytkowników, zmianę konfiguracji API. SIEM zapewnia dane, SOAR wykonanie, a AI pomaga nadać temu zrozumiałą, spójną narrację – taką, która przekonuje nie tylko inżynierów, ale też zarząd.