SOC w epoce AI. Automatyzacja, outsourcing i granice odpowiedzialności

Alert został wykryty. Co organizacja potrafi zrobić dalej?

Rozważmy hipotetyczną sytuację. SOC wykrywa aktywność wskazującą na możliwość przejęcia serwera obsługującego ważny proces organizacji. Dostępne dane uzasadniają jego izolację, ale odłączenie zasobu może przerwać obsługę klientów, realizację zamówień lub pracę części przedsiębiorstwa. Zwłoka daje napastnikowi więcej czasu. Pochopna reakcja może wywołać zakłócenie, którego organizacja chciała uniknąć.

System wykonał analizę, analityk potwierdził, że zdarzenie wymaga uwagi, powiadomienie dotarło do klienta. Czy to oznacza, że organizacja jest gotowa do skutecznej reakcji? 

Dalszy przebieg zależy od tego, czy wiadomo, kto może podjąć decyzję, czy ta osoba jest dostępna i czy rozumie konsekwencje działania – a także od tego, kto decyzję wykona, sprawdzi jej rezultat i w razie potrzeby przywróci działanie zasobu. Jeśli tego nie uzgodniono wcześniej, organizacja zacznie ustalać własny sposób postępowania dopiero podczas incydentu.

Ten problem łączy trzy zagadnienia z tytułu panelu „SOC przyszłości: człowiek, automatyzacja, outsourcing”, który odbył się 7 października 2026 r. podczas Cyber24 DAYS. Uczestniczyli w nim:

• Mariusz Kujawski, prezes zarządu ComCERT S.A., 
• Mirosław Maj, prezes Fundacji Bezpieczna Cyberprzestrzeń, 
• Krzysztof Smaga, reprezentujący CyberDuckSecurit,
• Wojciech Górecki z Centrum Cyberbezpieczeństwa AGH.

Paneliści różnili się w ocenie, jak daleko może sięgać automatyzacja i jaka będzie przyszła rola analityków. Powracały jednak te same pytania o: 

• kompetencje,
• kontekst biznesowy, 
• granice samodzielnego działania systemów,
• obowiązki organizacji korzystającej z usług zewnętrznych. 

Na tej podstawie można postawić tezę: skuteczny SOC wspierany przez AI wymaga zaprojektowania współpracy ludzi, technologii i organizacji. 

Automatyzacja i outsourcing mają wartość wtedy, gdy wiadomo, jakie zadania wykonują, kto wyznacza ich granice i jak przekładają się na ochronę konkretnych procesów.

Na wstępie warto przytoczyć zastrzeżenie Mirosława Maja, które dobrze oddaje tempo zmian. 

Porównał on dyskusje o AI do okresu hiperinflacji, gdy gość restauracji dowiadywał się o cenie posiłku dopiero przy wyjściu: poglądy wyrażone na panelu są aktualne dziś, ale – jak zauważył – „być może na koniec tego panelu możemy się dowiedzieć o czymś, co zupełnie zmieni perspektywę”. 

Wnioski poniżej dotyczą więc przede wszystkim zasad organizacyjnych, które powinny przetrwać zmianę konkretnych narzędzi.

Pierwsza linia SOC: jakie zadania pozostają człowiekowi?

Szymon Palczewski (moderator) otworzył dyskusję pytaniem, czy SOC bez człowieka na pierwszej linii (L1) to większa skuteczność, czy „tańsza iluzja bezpieczeństwa”. Rozmowa szybko wyszła poza pytanie, czy algorytm potrafi wykonać pracę analityka.

Mariusz Kujawski wskazał przede wszystkim ryzyko luki kompetencyjnej. Analityków L2 i L3 trzeba skądś pozyskać, a ich doświadczenie powstaje właśnie na pierwszej linii:

Najlepiej, żeby mieli jakieś doświadczenie i żeby ten człowiek chociaż raz w życiu widział jakieś logi na oczy. A to doświadczenie najlepiej zdobywa się właśnie na L1.
Mariusz Kujawski, Prezes Zarządu ComCERT S.A.

Jednocześnie zastrzegł, że nie jest przeciwnikiem automatyzacji: nikt dziś nie oczekuje, że analityk będzie ręcznie kopiował adresy IP do serwisów reputacyjnych, a narzędzia w modelu human-in-the-loop są w stanie znacząco wesprzeć analityków pierwszej linii. Całkowitego automatu na L1 jednak by nie wybrał.

Mirosław Maj postawił sprawę odwrotnie. Rozłożył pracę pierwszej linii na dwa podstawowe elementy obsługi incydentów – monitoring oraz alerting – i zauważył, że AI radzi sobie z nimi już dziś sprawniej niż człowiek.

Dlaczego mielibyśmy się tego pozbywać? I stawiać człowieka tylko po to, żeby się wykształcił na drugą, trzecią linię?
Mirosław Maj, Prezes Fundacji Bezpieczna Cyberprzestrzeń

Wojciech Górecki zwrócił uwagę, że spór nie musi dotyczyć tego, czy ludzie na pierwszej linii mają zostać, ale tego, co będą tam robić. 

Nowe narzędzia to nie tylko przyspieszenie dotychczasowej pracy – modele AI mogą wychwytywać wzorce zachowań, których analityk by nie dostrzegł. Rola człowieka się przesuwa: w stronę większej specjalizacji, nadzoru i oceny zdarzeń nowego typu. 

Chodzi przy tym „nie o to, żeby eliminować ludzi”, lecz o zmianę ich roli i kierunków działania. 

Zmieni się zresztą nie tylko L1 – modele językowe działają już także na drugiej i trzeciej linii.

Mariusz Kujawski uzupełnił, że kształcenie kompetencji nie polega na tym, by analityk L1 uczył się dokładnie tego samego, co jego poprzednicy, lecz by z nowych narzędzi korzystał na wyższym poziomie. 

Dodał przy tym cenną uwagę: wszyscy deklarują, że wiedzą, jak korzystać z AI, ale pytanie, czy faktycznie tak jest. 

Krzysztof Smaga przypomniał z kolei, że podobną drogę przeszedł helpdesk – pierwsza linia, która kiedyś tylko odbierała zgłoszenia, zaczęła wykonywać proste zadania administracyjne jeszcze przed upowszechnieniem AI.

Doświadczenie trzeba zdobywać w zmieniającym się środowisku

Obie obawy są uzasadnione: utrata miejsca, w którym początkujący analitycy poznają środowisko i uczą się oceny zdarzeń, oraz utrzymywanie ręcznych czynności tylko dlatego, że dotąd stanowiły etap wejścia do zawodu. 

Rozwiązaniem nie jest zachowanie wszystkich dotychczasowych zadań, lecz ponowne określenie tego, co powinien umieć człowiek nadzorujący wyniki automatyzacji.

Analityk coraz częściej otrzymuje gotowy wynik, którego jakość zależy od danych wejściowych, konfiguracji narzędzi i przyjętych założeń. Jego zadaniem staje się ustalenie, czego brakuje w przedstawionym obrazie. Czy system miał dostęp do właściwych źródeł? Czy uwzględnił zmianę w środowisku? Czy poprawnie rozpoznał znaczenie zasobu? Czy wyjaśnienie odpowiada dostępnym dowodom? 

Kompetencje techniczne pozostają potrzebne, choć wykorzystywane w innych proporcjach.

Ich rozwój można zaprojektować: przez analizę rzeczywistych przypadków, ćwiczenia, odtwarzanie przebiegu incydentów i porównywanie wyników narzędzi z oceną doświadczonych analityków. 

Szczególnie cenne jest badanie błędów – dlaczego zdarzenie zostało pominięte, źle zakwalifikowane albo trafiło do niewłaściwej osoby. Oszczędność czasu na rutynowych zadaniach może stworzyć przestrzeń do nauki, ale sama nie gwarantuje, że zostanie ona wykorzystana. Trzeba to uwzględnić w planie wdrożenia automatyzacji.

Od L0 do L3: nazwy poziomów mają znaczenie pomocnicze

Mirosław Maj zaproponował, by do klasycznego podziału L1–L3 dodać poziom L0, a każdy poziom traktować jako miarę zaangażowania człowieka. Kluczową kompetencją staje się w tym ujęciu nie obsługa narzędzia, lecz ocena ryzyka jego działania.

Zaangażowanie człowieka jest wprost proporcjonalne do wzięcia odpowiedzialności za te decyzje i za wzrost ryzyka związany z nieautoryzowanymi skutkami działania AI.
Mirosław Maj, Prezes Fundacji Bezpieczna Cyberprzestrzeń

Maszyna – argumentował – może zrobić więcej i sprawniej, ale nie zarządza ryzykiem tak jak człowiek, nie rozumie w pełni kontekstu biznesowego i nie weźmie odpowiedzialności za decyzję. 

Propozycja L0 jest użyteczna jako sposób myślenia, ale praktycznie ważniejszy od nazewnictwa jest opis czynności: 

• kto zbiera dane, 
• kto je interpretuje, 
• kto sprawdza wynik, 
• kto zatwierdza reakcję, 
• kto ją wykonuje. 

Warto też odróżniać rodzaje rozwiązań – reguła korelacyjna, zautomatyzowany playbook, model językowy przygotowujący opis i agent z dostępem do narzędzi pełnią różne funkcje. Zbiorcza etykieta „AI” utrudnia ocenę, jeśli nie wiadomo, co dany system rzeczywiście robi i jakie ma uprawnienia.

Więcej obsłużonych alertów – jaki rezultat dla bezpieczeństwa?

Mariusz Kujawski zwrócił uwagę na pułapkę statystyk. Automatycznie zamknięte alerty dobrze wyglądają w raporcie, ale „to, że więcej przerabiamy, nie oznacza, że jest to bardziej efektywne”. Warto sprawdzić, ile zdarzeń zamkniętych automatycznie i tak trafiło później na L2 – i co się z nimi stało.

Przepustowość jest więc tylko jednym z elementów oceny. Trzeba wiedzieć, czy istotne zdarzenia zostały prawidłowo rozpoznane, czy eskalacja dotarła do właściwego odbiorcy, czy odbiorca miał wystarczające informacje i czy podjęte działanie przyniosło skutek. 

Równie ważne jest to, co pozostaje poza obserwacją SOC: sprawne przetwarzanie danych z dostępnych źródeł nie daje wiedzy o zasobach, których nie włączono do monitoringu. Podobnie z czasem reakcji – szybkie powiadomienie nie oznacza jeszcze, że zagrożenie zostało ograniczone.

W dyskusji pojawiły się też dwa szersze ostrzeżenia. Pierwsze dotyczyło samej organizacji. 

Jak zauważył Wojciech Górecki, AI jest w pewnym sensie bezwzględna – nie ma wyrozumiałości dla słabości procesów.

Każdy błąd organizacji – czy to w procesach, przepływie informacji, ścieżkach decyzyjnych czy odpowiedzialności – ona to uwidoczni.
Wojciech Górecki, specjalista ds. badań z Centrum Cyberbezpieczeństwa AGH

Wdrożenie automatyzacji w organizacji z niejasnym podziałem ról nie usunie tego problemu, lecz go przyspieszy i powieli. 

Drugie ostrzeżenie sformułował Mariusz Kujawski: z AI korzysta również druga strona i to szybciej. 

Atakujący system może zasypywać nasze narzędzia ogromną liczbą zapytań, by nauczyć je określonego wzorca, a potem wykorzystać go do zupełnie innego działania. Dlatego – jak podkreślił – trzeba rozumieć mechanizm działania tych systemów, bo „może to nie jest popularne stwierdzenie, ale sztuczna inteligencja nie jest inteligencją”.

Czego nie oddamy maszynie?

Szymon Palczewski, moderujący dyskusję, zapytał wprost, czego paneliści nie oddaliby AI, nawet gdyby była skuteczniejsza, szybsza i dokładniejsza od człowieka. 

Krzysztof Smaga przywołał zasadę z materiałów szkoleniowych IBM z 1979 r.: komputer nie może być pociągnięty do odpowiedzialności, więc nie powinien podejmować decyzji zarządczych. 

Mariusz Kujawski doprecyzował, że część decyzji już dziś przekazujemy systemom, ale nie te o skutkach biznesowych.

Wszystkie decyzje, które mają impact biznesowy, które polegają na tym, czy zatrzymamy produkcję w fabryce, które mogą mieć jakikolwiek wpływ na ciągłość biznesową – to są decyzje, których nikt by nie oddał.
Mariusz Kujawski, Prezes Zarządu ComCERT S.A.

Człowiek w procesie nie gwarantuje nadzoru

Mirosław Maj wskazał jednak słabość samej zasady „człowiek decyduje”. 

Zjawiskoautomation bias polega na tym, że decyzja formalnie pozostaje przy człowieku, ale człowiek, przekonany wcześniejszymi trafnymi rekomendacjami systemu, w praktyce tylko klika przycisk. 

Przywołał dwa przykłady spoza AI: w 2003 r. w Iraku systemy Patriot błędnie zidentyfikowały sojusznicze samoloty jako wrogie, a operatorzy zatwierdzili ich zestrzelenie; w 1983 r. Stanisław Pietrow nie zaufał systemowi wczesnego ostrzegania, który uznał odbicia światła słonecznego od chmur za odpalenie amerykańskich rakiet. W obu przypadkach o wyniku zdecydowała jakość ludzkiej oceny, a nie sam fakt obecności człowieka. 

Prezes Fundacji podkreślił też – na podstawie doświadczeń zespołu Dyżurnet.pl – że ludzi podejmujących decyzje pod presją trzeba do tego przygotowywać, również z udziałem psychologów.

Jak po prostu zrobimy tak, że to zawsze człowiek naciska przycisk, to czeka nas seria sytuacji, w których według procedur człowiek podjął decyzję – no ale, kurczę, pomylił się.
Mirosław Maj, Prezes Fundacji Bezpieczna Cyberprzestrzeń

Wojciech Górecki dodał do tego obserwację bardziej przyziemną: ludzie szybko się przyzwyczajają. 

Jeśli analityk pięćdziesiąt razy zobaczył tę samą rekomendację i za każdym razem była trafna, przy pięćdziesiątym pierwszym razie najpewniej zatwierdzi ją bez zastanowienia.

Rzeczywisty nadzór wymaga więc warunków, a nie tylko deklaracji. Zatwierdzający musi mieć dostęp do przesłanek, kontekstu i informacji o możliwych konsekwencjach, a także rozumieć, gdzie kończy się zakres analizy narzędzia. 

Sposób prezentacji wyniku powinien wspierać ocenę – wskazywać wykorzystane dane, brakujące elementy i powody proponowanego kroku. 

Potrzebna jest też realna możliwość zakwestionowania wyniku: uprawnienia do odrzucenia rekomendacji lub zatrzymania procesu oraz procedura określająca, co dzieje się dalej i jak dokumentuje się przesłanki decyzji.

Stopniowanie autonomii: od decyzji do opisu sytuacji

Mirosław Maj zaproponował praktyczne stopniowanie. 

Na pierwszej linii agent AI może samodzielnie podejmować decyzje korelacyjne i orientacyjne, bo pomyłki na tym etapie są tanie. Na poziomie analizy – mocne rekomendacje. Natomiast na etapie reakcji, czyli decyzji, co organizacja zrobi w związku z incydentem, Maj nie nazywałby wyniku systemu nawet rekomendacją.

Ja bym to nazwał opisem sytuacyjnym. Ktoś nam pomógł zebrać wszystkie fragmenty tej układanki, ułożył i mówi: tak wygląda ten obrazek. A teraz popatrz i sam pomyśl, co dalej jest do zrobienia.
Mirosław Maj, Prezes Fundacji Bezpieczna Cyberprzestrzeń

To podejście może być szczególnie przydatne tam, gdzie znaczenie mają zależności organizacyjne i kontekst biznesowy. Jego użyteczność zależy jednak od jakości obrazu, kompetencji odbiorcy i dostępnego czasu. A czasu bywa za mało.

Decyzje w czasie krytycznym: odpowiedzialność zaczyna się przed incydentem

Wszystkie rozważania o decyzji człowieka tracą praktyczny sens w systemach czasu krytycznego – gdy chodzi o zestrzelenie obiektu, odcięcie wodociągów po wykryciu skażenia czy wyłączenie elementu infrastruktury energetycznej po jego przejęciu. Na decyzję mogą wtedy zostać ułamki sekundy. 

Jak podkreślił Wojciech Górecki, decyzja nie znika – przenosi się w inne miejsce.

Decyzja musi zapaść już w momencie projektowania systemu. To jest właśnie nasza rozmowa o human in the loop i human on the loop – spojrzenie z góry na cały proces, który jest w jakiś sposób zautomatyzowany.
Wojciech Górecki, specjalista ds. badań z Centrum Cyberbezpieczeństwa AGH

Zagadnienie decyzji w czasie krytycznym ekspert AGH rozwija w książce „Wojna w epoce AI. Decyzja, odpowiedzialność, kontrola” (PWN). 

W kontekście SOC prowadzi ono do praktycznego pytania: które rozstrzygnięcia musimy podjąć przed zdarzeniem, aby podczas jego obsługi system lub dostawca mógł działać w granicach świadomie zaakceptowanych przez organizację? 

Ta granica – jak zaznaczył podczas panelu – będzie się stale przesuwać w stronę automatyzacji.

Nie musi to oznaczać szerokiego upoważnienia do automatycznej reakcji. Zgoda może obejmować konkretną czynność, na określonej grupie zasobów, po spełnieniu wskazanych przesłanek. 

Organizacja może na przykład dopuścić automatyczną izolację części stacji roboczych, a dla serwerów obsługujących procesy krytyczne przewidzieć odrębny tryb. 

Sam podział na stacje i serwery nie wystarczy jednak do oceny ryzyka – stacja robocza może pełnić kluczową funkcję operacyjną, a serwer może mieć sprawdzone zastępstwo. Potrzebna jest wiedza o konkretnym środowisku.

Projektując automatyczną reakcję, warto zacząć od skutków. 

• Jakie szkody spowoduje opóźnienie? 
• Co się stanie, jeśli rozpoznanie okaże się błędne? 
• Czy działanie można odwrócić i jak długo potrwa powrót do normalnej pracy? 

Techniczne cofnięcie blokady bywa proste, ale ponowne włączenie systemu nie przywróci utraconego czasu ani niedokończonych operacji.

Decyzje organizacyjne i techniczne muszą też być spójne: procedura wymagająca zgody osoby niedostępnej poza godzinami pracy nie zapewnia gotowości do całodobowej reakcji, a deklarowane prawo zatrzymania automatyzacji wymaga kogoś, kto ma uprawnienia, wie, kiedy z nich skorzystać, i potrafi to zrobić. 

Przyjęte granice trzeba sprawdzać w ćwiczeniach i przeglądać po każdej istotnej zmianie środowiska lub możliwości narzędzi.

Agenci AI w SOC: zakres uprawnień wyznacza zakres ryzyka

Mirosław Maj przesunął rozmowę o ryzyku AI z poziomu danych na poziom działania. Dziś – zauważył – problemem nie jest już tylko to, że ktoś wrzuci dokument do modelu językowego i informacja wycieknie.

To jest umiejętność oceny, czy zdajemy sobie sprawę, jakie zdolności agentowe posiada ten system do działania w naszej infrastrukturze, które sami mu daliśmy, albo do działania w naszym imieniu na zewnątrz organizacji.
Mirosław Maj, Prezes Fundacji Bezpieczna Cyberprzestrzeń

Przywołał przy tym prompt injection: dane mogą wypłynąć bez jakiejkolwiek intencji ich przekazania, nawet przy twardych regułach, jeśli nie rozumiemy, jak działają agenci. 

Skutkiem może być zatrzymanie systemu biznesowego czy nieprawidłowe raportowanie – a wtedy AI staje się obciążeniem, a nie wsparciem. Im bardziej złożony proces, tym bardziej nie opłaca się używać jej bezkrytycznie.

Wątek ten warto rozwinąć z perspektywy wdrożeniowej, bo wynika z niego kilka praktycznych zasad. 

Po pierwsze, ocenę konkretnego rozwiązania warto zacząć od opisu jego możliwości: jakie dane może odczytać, jakie operacje wykonać, na których zasobach, czy może komunikować się poza organizacją i które kroki wymagają zatwierdzenia. 

Agent czytający logi i przygotowujący raport ma inny zakres oddziaływania niż agent uprawniony do blokowania kont, nawet jeśli oba korzystają z tego samego modelu.

Po drugie, SOC z natury analizuje materiał częściowo kontrolowany przez napastnika – wiadomości, zgłoszenia, strony, dokumenty. 

Podejrzany e-mail może zawierać polecenie, by system zignorował zasady i przesłał dane pod wskazany adres. 

Dla analityka to element badanego materiału; agent nie może potraktować go jako instrukcji. Samo zapisanie zakazu w instrukcji systemowej nie rozwiązuje problemu – dostęp agenta musi być ograniczony tak, by błędna interpretacja nie dawała mu swobody dowolnego działania.

Po trzecie, zgoda na jedno działanie nie oznacza zgody na cały łańcuch. Prawo odczytu danych, przygotowania raportu i wysłania wiadomości tworzą łącznie zdolność wyprowadzenia informacji poza organizację. 

Zatwierdzenie izolacji jednego urządzenia nie może oznaczać zgody na odłączanie kolejnych, które agent uzna za powiązane.

Wreszcie, trzeba móc odtworzyć, co agent faktycznie zrobił – jakie narzędzia wywołał, z jakimi parametrami, kto udzielił zgody – i trzeba móc go zatrzymać, pamiętając, że zatrzymanie nie cofa już wysłanej wiadomości ani zmienionej konfiguracji.

Ma to bezpośrednie znaczenie dla outsourcingu: jeśli dostawca wykorzystuje agentów w obsłudze klienta, klient powinien wiedzieć, jakie zadania wykonują, jakie mają uprawnienia i jak ich działania podlegają kontroli.

Brak ludzi i skala regulacji: automatyzacja i outsourcing są nieuniknione

Ekonomiczne tło dyskusji przedstawił Mirosław Maj. Jednym z najczęściej wskazywanych problemów cyberbezpieczeństwa jest brak ludzi, a po nowelizacji ustawy o krajowym systemie cyberbezpieczeństwa liczba zgłoszonych podmiotów może przekroczyć 100 tysięcy. Obsadzenie ich wszystkich specjalistami, nawet w najmniejszej liczbie, jest niemożliwe. 

Ta automatyzacja – świadoma, połączona z dobrym outsourcingiem – i tak nas czeka.
Mirosław Maj, Prezes Fundacji Bezpieczna Cyberprzestrzeń

W jego ocenie w większości przypadków pierwsza linia stanie się bezosobowa albo będzie ją obsługiwał jeden koordynator agentów, wspierany przez człowieka tam, gdzie rzeczywiście potrzebny jest human-in-the-loop. 

Tym bardziej istotne staje się pytanie, jak korzystać z usług zewnętrznych, nie tracąc kontroli nad własnym bezpieczeństwem.

Zewnętrzny SOC: odpowiedzialności nie da się kupić

Moderator zapytał, jak – przy nowych wymogach wobec kadry kierowniczej i zarządów – nie wpaść w pułapkę fałszywego poczucia, że wraz z outsourcingiem odpowiedzialność za cyberbezpieczeństwo zostaje przeniesiona na podmiot zewnętrzny.

Mariusz Kujawski wskazał, że część ryzyka operacyjnego można przenieść na dostawcę, na przykład przez kary umowne, ale odpowiedzialność reputacyjna i regulacyjna zostaje po stronie organizacji. 

Pokazują to przypadki incydentów w łańcuchu dostaw: w głośnej sprawie wycieku z systemu MyDr dane pacjentów wielu placówek medycznych wykradziono przez lukę po stronie dostawcy, a obowiązki wobec pacjentów i regulatora spoczywały na placówkach korzystających z jego usług. 

„Ryzyka reputacyjnego na swojego dostawcę nie przerzucę” – podsumował. A gdy stanie fabryka, problem i tak będzie po stronie właściciela.

Dalsza część artykułu pod filmem.

#YT[ videoId: GtnfZfchWa0 | description: ] 

Drugim zagrożeniem jest efekt Peltzmana – zjawisko znane z bezpieczeństwa drogowego, gdy kierowca auta naszpikowanego systemami bezpieczeństwa jeździ mniej ostrożnie. W cyberbezpieczeństwie przybiera ono postać myślenia

Nie muszę patchować tak szybko, bo oni to wykryją w razie czego. Albo mogę sobie zostawić furtkę dla serwisu, a shadow IT nie jest już takie straszne.
Mariusz Kujawski, prezes zarządu ComCERT

Krzysztof Smaga zwrócił uwagę na ograniczenie czysto praktyczne: zewnętrzny SOC nie przyjedzie do naszej serwerowni i zwykle nie dostanie dostępu pozwalającego na samodzielne działanie w infrastrukturze. 

Decyzja, czy wyłączyć dany segment, czy go zostawić, zapada po stronie klienta – na podstawie informacji od SOC, ale przez ludzi organizacji. 

SOC to zbiór narzędzi, procedur i procesów. Musimy być częścią tego jako przedsiębiorca. Musimy być częścią procedur, częścią odpowiedzialności, częścią działania. Ktoś musi podjąć decyzję – i nie podejmie jej za nas podmiot zewnętrzny.
Wojciech Górecki, specjalista ds. badań z Centrum Cyberbezpieczeństwa AGH

Organizacja może kupić kontrolę nad procesem albo zarządzanie nim, ale aktywny udział i odpowiedzialność muszą pozostać u niej. 

Dlatego rozmowa z dostawcą powinna mieć charakter partnerski i wymaga świadomości po obu stronach. Oferta polegająca na dostarczeniu „ogromnej ilości narzędzi do monitorowania” jest mniej wartościowa niż taka, która obejmuje szkolenia, procedury i wspólne przygotowanie do reakcji. 

Mirosław Maj dodał analogię z chmurą: przez lata przeniesienie zasobów do chmury uchodziło za synonim bezpieczeństwa, a potem okazywało się, że bywało z tym różnie. Pytanie zawsze brzmi, co dokładnie daje kupowana usługa.

Po stronie klienta musi istnieć zdolność do decyzji

Nie każda organizacja musi utrzymywać rozbudowany zespół bezpieczeństwa. Musi jednak zapewnić zdolność do współpracy: odbioru eskalacji, oceny skutków biznesowych, zatwierdzania działań i ich wykonania. 

Szybkie powiadomienie przez SOC ma ograniczoną wartość, jeśli po stronie klienta nie ma osoby zdolnej podjąć decyzję ani zespołu, który ją wykona. 

Trzeba wskazać osoby odpowiedzialne, zastępstwa i sposób postępowania poza godzinami pracy, a także ustalić, co dostawca może zrobić, gdy kontakt z klientem jest niemożliwy. Ścieżka eskalacji musi prowadzić do ludzi, którzy znają znaczenie zasobu i mają uprawnienia, by rozstrzygnąć sprawę.

Równie ważny jest opis zakresu usługi. Nazwa „SOC” nie określa jednoznacznie świadczenia. Warto rozdzielić zbieranie danych, monitoring, ocenę alertów, analizę incydentu, powiadamianie, rekomendacje i wykonanie reakcji, a także ustalić ograniczenia: zasoby nieobjęte monitoringiem, niedostępne źródła danych i działania wymagające odrębnego zlecenia. Chroni to obie strony przed sytuacją, w której klient oczekuje ograniczenia zagrożenia, a dostawca zobowiązał się jedynie do przekazania informacji.

SOC za 5 tysięcy miesięcznie – jak nie wejść „na minę"?

Mirosław Maj opisał ofertę SOC, którą można kupić przez stronę internetową, płacąc BLIK-iem 5 tysięcy złotych miesięcznie. Moderator potwierdził, że widział podobne propozycje i zapytał, co mogą zrobić mniejsze podmioty, których nie stać na własny SOC, by nie paść ofiarą usług, które jedynie „udają” SOC.

Mariusz Kujawski przypomniał prostą zależność: „Gdyby na koniec dnia nikt tego nie kupował, to takie oferty by nie istniały”. 

Podobny wysyp usług fasadowych towarzyszył wejściu RODO. Część organizacji chce po prostu „odklepać compliance”, a z klientem bez minimalnej świadomości trudno rozmawiać o rzeczywistej ochronie. 

Mirosław Maj szacował, że 20–30% podmiotów objętych KSC jest wciąż w fazie wyparcia, a kolejna grupa oczekuje wyłącznie formalnego potwierdzenia zgodności. 

Zauważył przy tym, że nawet największe incydenty nie wywołują dziś mobilizacji, jakiej można było oczekiwać kilka lat temu. 

Kiedyś liczono, że publiczna kompromitacja po włamaniu skłoni opornych do działania. Tymczasem wyciek z MyDr, który dotknął ogromnej liczby Polaków, był wielką aferą, a mimo to szybko przycichł – przez długi czas nie można było nawet łatwo sprawdzić, czy dotyczy konkretnej osoby.

Za 5 tysięcy to jakieś papiery można zrobić. Ale nic poza tym. Więc edukacja, edukacja, edukacja – ona jest tutaj podstawą.
Wojciech Górecki, specjalista ds. badań z Centrum Cyberbezpieczeństwa AGH

Rynek z czasem sam się oczyści, ale edukacja – także w formie spotkań takich jak ten panel – może przyspieszyć eliminację nieuczciwych praktyk. 

Mirosław Maj zastrzegł z kolei, że sama cena nie przesądza o jakości; trzeba umieć ocenić, co się za nią kryje. 

Ograniczona usługa może być uzasadniona, jeśli odpowiada rozpoznanej potrzebie i jest rzetelnie opisana. Problem pojawia się wtedy, gdy jej zakres jest węższy niż ochrona, której oczekuje klient.#READ[ articles: 1075302 | showThumbnails: true ]

Wspólny zakup i konsolidacja zamiast silosów

Krzysztof Smaga wskazał rozwiązanie dla podmiotów o ograniczonych budżetach: „Jeśli nas nie stać, to poszukajmy kogoś, kogo też nie stać, i razem będzie nas stać”. 

Tak robią na przykład małe gminy, które zrzeszają się i szukają droższej, ale rzetelnej oferty. 

Mirosław Maj i Mariusz Kujawski zgłosili jednak wątpliwości, czy takie dobrowolne zrzeszanie się działa w praktyce. Wspólny zakup wymaga ustalenia, kto reprezentuje uczestników, jak dzieli się koszty i zakres usług, jak chroni się dane poszczególnych podmiotów – a każdy uczestnik nadal potrzebuje własnej ścieżki decyzyjnej.

Mirosław Maj poszedł dalej: konsolidacja usług i wspólne rozwiązania na poziomie IT, nie tylko bezpieczeństwa, zmniejszają powierzchnię ataku i liczbę ośrodków wymagających ochrony. 

Przeszkodą jest jednak kultura organizacyjna, w której „każdy chce mieć swoje” – co Krzysztof Smaga wskazał jako szczególnie widoczne na dużych uczelniach, a Mariusz Kujawski zilustrował podziałem między IT i OT wewnątrz jednej firmy. 

Wojciech Górecki przyznał, że problem silosów, które „trzymają swoje własne królestwa feudalne”, jest na uczelniach bardzo wyraźny, choć nie dotyczy wyłącznie ich. 

Przywołał przy tym doświadczenia zakończonego projektu SOCCER, którego liderem była AGH. Jego efektem jest SOC4Academia Toolbox – opracowanie pokazujące, jak wybrać model SOC (własny, federacyjny lub zewnętrzny), które można przełożyć także na organizacje spoza sektora akademickiego. 

Jak podkreślił, najważniejsze są w nim jednak nie same metody wyboru, lecz rozważania o tym, co jest organizacji rzeczywiście potrzebne. Punktem wyjścia powinna być edukacja i rzetelna diagnoza: w którym miejscu jesteśmy i dlaczego w ogóle musimy się tym zajmować – bo wymaga tego KSC, bo ktoś nas zaatakował, czy z innego powodu.

Pytania, które warto zadać przed podpisaniem umowy

Z argumentów przedstawionych podczas panelu można wyprowadzić zestaw pytań do oceny oferty i przygotowania współpracy:

1. Jakie zasoby, źródła danych i scenariusze obejmuje usługa – i czego nie obejmuje?
2. Które czynności są realizowane całodobowo i co dokładnie oznaczają deklarowane czasy obsługi?
3. Czy dostawca tylko powiadamia, czy również wspiera i wykonuje reakcję?
4. Kto po naszej stronie zatwierdza działania o konsekwencjach biznesowych i kto go zastępuje?
5. Co się dzieje, gdy nie odpowiadamy na eskalację?
6. Jakie uprawnienia mają analitycy, automatyzacja i agenci AI dostawcy – i jak je kontrolujemy?
7. Jak otrzymujemy dowody analizy i wykonanych operacji?
8. Jak raporty pokazują luki w widoczności, a nie tylko liczbę obsłużonych alertów?
9. Jak sprawdzamy współpracę w ćwiczeniu i kto usuwa ujawnione braki?
10. Jakie szkolenia, procedury i wsparcie organizacyjne obejmuje oferta poza samymi narzędziami?

Jaki SOC przyszłości?

Na zakończenie moderator poprosił panelistów o krótką odpowiedź, jakiego SOC chcieliby w przyszłości. 

Mirosław Maj wrócił do restauracyjnej analogii z początku: chciałby SOC takiego, jaki opisali paneliści, ale obawia się, że za trzy miesiące ta dyskusja będzie nieaktualna – pół roku temu nikt nie rozmawiałby o agentach w SOC, a dziś wracały one co chwilę. 

Mariusz Kujawski podkreślił, że technologia, liczba analityków i agentów będą się zmieniać w tempie trudnym do zaplanowania, ale cel pozostaje ten sam: SOC ma być skuteczny. 

Wojciech Górecki odpowiedział, że chciałby SOC skutecznego jako cała organizacja – nie jako wydzielony zespół czy usługa, lecz jako zdolność obejmująca wszystkie jej elementy.

Krzysztof Smaga ujął to w dwóch słowach:„Odpowiedzialny i współpracujący”.

Odpowiedzialny, czyli taki, który faktycznie bierze odpowiedzialność za to, co nam dostarcza. I współpracujący, czyli taki, który niczego nie zataja, nie czeka 40 dni, zanim nam o czymś powie, tylko reaguje natychmiast.
Krzysztof Smaga, reprezentujący CyberDuckSecurit

Mirosław Maj dodał życzenie, by za jakiś czas nie trzeba było dyskutować o tym, jakie decyzje AI podejmuje bez naszej wiedzy – bo doświadczenia z badań nad zachowaniem agentów pokazują, że takie ryzyko jest realne.

Te odpowiedzi prowadzą do wspólnego wniosku. Wybór między własnym zespołem, automatyzacją i outsourcingiem nie jest wyborem technologii, lecz sposobu budowania zdolności bezpieczeństwa. 

Organizacja powinna wiedzieć, co zapewnia sama, co otrzymuje od dostawcy, jakie decyzje powierzyła systemom – i jak sprawdzi, czy całość działa. Narzędzia będą się zmieniać szybciej, niż zdąży się o nich rozmawiać na kolejnych konferencjach. Odpowiedzialność za decyzje pozostanie tam, gdzie była.