Automatyczna reakcja na incydenty w Microsoft Sentinel - jak naprawdę działa SOAR w nowoczesnym SOC?

W codziennej pracy SOC największym wyzwaniem nie jest liczba alertów, lecz czas między wykryciem a reakcją. Każda minuta opóźnienia daje atakującemu przestrzeń na eskalację uprawnień, ruch lateralny i utrwalenie dostępu. Dlatego w dojrzałych zespołach coraz częściej mówi się o “time to first action”, a nie tylko o MTTR. I właśnie tu automatyzacja SOAR przestaje być dodatkiem – staje się fundamentem operacyjnego bezpieczeństwa. 

Microsoft Sentinel łączy funkcje SIEM i SOAR w jednym narzędziu. Playbooki oparte o Logic Apps umożliwiają automatyczne przejście od detekcji do reakcji w sposób szybki, kontrolowany i audytowalny. W praktyce playbook nie jest skryptem, ale procesem operacyjnym SOC, który można wersjonować, monitorować i rozwijać wraz z dojrzałością zespołu. 

Co istotne, każde uruchomienie playbooka jest logowane i monitorowane, dzięki czemu SOC może analizować nie tylko incydenty, ale również skuteczność samej automatyzacji oraz jej wpływ na czas reakcji. 

„Automatyzacja nie zastępuje analityka – usuwa z jego pracy wszystko, co powtarzalne i czasochłonne, a zostawia to, co wymaga myślenia”.

Już przy 150 – 200 incydentach miesięcznie ręczna obsługa zaczyna się załamywać. Analitycy wykonują te same czynności: weryfikują użytkowników, sprawdzają IP, uzupełniają zgłoszenia w ITSM, wysyłają powiadomienia. To wszystko jest proste, ale zabiera czas – a właśnie ten czas jest najcenniejszy i to on decyduje o skuteczności reakcji. 

W projekcie SOC, który realizowaliśmy dla jednego z naszych klientów – firmy z branży energetycznej, priorytetem była automatyzacja, jako warunek utrzymania jakości operacyjnej. Środowisko obejmowało: 

• 120 użytkowników, 
• 38 serwerów, 
• 35 urządzeń sieciowych, 
• średnio 225 incydentów miesięcznie, 
• monitoring 24/7 i integrację z ITSM. 

Architektura bezpieczeństwa oparta została tu o Microsoft Sentinel oraz pakiet Microsoft Defender XDR (Endpoint, Identity, Office 365, Apps). 

W środowiskach o podwyższonej krytyczności nie wszystkie incydenty są równe. Niektóre stają się punktem odniesienia dla całej architektury reakcji. W przypadku projektu realizowanego dla klienta z branży energetycznej był nim scenariusz podejrzenia przejęcia konta uprzywilejowanego. 

Dlaczego właśnie on? Ponieważ w środowisku energetycznym błąd w pierwszych minutach reakcji może mieć konsekwencje nie tylko w obszarze IT, ale i operacyjne. Jednocześnie to właśnie konta uprzywilejowane są najczęstszym celem ataków typu lateral movement i persistence. 

Przed automatyzacją reakcja wyglądała klasycznie: analityk analizował alert, sprawdzał konto w Entra ID, historię logowań, reputację IP, tworzył zgłoszenie w ITSM i kontaktował się z administratorem. Nawet przy sprawnym zespole trwało to od kilku do kilkunastu minut. Dla incydentu wysokiego ryzyka – zdecydowanie za długo. 

Aby działać lepiej i szybciej zaprojektowaliśmy playbook według zasady: Automatyzuj wszystko, co powtarzalne – decyzję zostaw człowiekowi. 

Scenariusz został zbudowany w Microsoft Sentinel z wykorzystaniem Logic Apps i integracji z Defender XDR. Każda reakcja była testowana na symulowanych incydentach i wdrażana stopniowo, tak aby uniknąć ryzyka niekontrolowanych blokad w środowisku produkcyjnym. 

1. Detekcja i korelacja
   Alert z Defender for Identity trafia do Sentinel i otrzymuje severity „High” tylko wtedy, gdy spełnione są warunki ryzyka, co pozwala ograniczyć liczbę fałszywych reakcji. 
2. AutomationRule- pierwsza bramka decyzyjna
   Reguła automatyzacji decyduje, czy playbook zostanie uruchomiony, umożliwiając szybkie modyfikowanie logiki reakcji bez ingerencji w sam playbook.

3. Enrichment- pełny kontekst w kilka sekund
   Playbook pobiera dane z Entra ID, Defender XDR i logów, budując kontekst, który wcześniej był zbierany ręcznie przez analityka.

4. Reakcja warunkowa
   Przy wysokim ryzyku konto zostaje tymczasowo zablokowane, reset hasła wymuszony, a sesja oznaczona jako podejrzana. Przy ryzyku średnim incydent trafia do analityka z pełnym kontekstem- bez automatycznej blokady. Automatyzacja przejmuje pierwszą, krytyczną fazę reakcji, ale nie zastępuje pełnej obsługi incydentu.

5. ITSM i komunikacja
   Równolegle tworzony jest incydent w systemie ITSM, a SOC otrzymuje komplet informacji bez ręcznego kopiowania danych. Każdy krok reakcji jestaudytowalny i widoczny w logach platformy. 

Ten jeden scenariusz stał się wzorcem dla kolejnych playbooków (phishing, malware, podejrzane logowania, aktywność lateralna). Efekt był jednoznaczny: 

• czas do pierwszej reakcji skrócił się z minut do sekund, 
• procedury stały się powtarzalne i przewidywalne, 
• analitycy przestali „gasić alerty”, 
• automatyzacja wsparła redukcję ryzyka nawet o 80% w całym środowisku. 

 

„Ten playbook był momentem, w którym SOC przestał reagować, a zaczął działać”.

Nowoczesny SOC nie wygrywa liczbą alertów ani liczbą dashboardów. Wygrywa czasem reakcji, spójnością działania i odpornością operacyjną. 

Microsoft Sentinel daje solidne fundamenty technologiczne, ale dopiero połączenie automatyzacji, procesów i doświadczenia zespołu sprawia, że SOAR działa naprawdę. 

A gdy działa – SOC przestaje być centrum monitoringu. Staje się centrum odporności.