Automatyzacja zabezpieczeń polega na wykonywaniu powtarzalnych działań związanych z cyberbezpieczeństwem przez oprogramowanie na podstawie określonych zdarzeń, reguł i procedur. Może obejmować wykrywanie i wzbogacanie alertów, klasyfikację incydentów, skanowanie podatności, blokowanie określonych zagrożeń, zarządzanie dostępem czy uruchamianie procedur reagowania.
Celem nie jest całkowite wyeliminowanie analityka bezpieczeństwa. Automatyzacja powinna przede wszystkim przejmować działania, które są częste, przewidywalne i możliwe do jednoznacznego opisania, aby specjaliści mogli skoncentrować się na analizie nietypowych incydentów i decyzjach wymagających kontekstu.
W praktyce automatyzacja procesów bezpieczeństwa jest szczególnie istotna w SOC, gdzie liczba alertów może przekraczać możliwości ich ręcznej obsługi. Microsoft opisuje automatyzację SOAR jako sposób na przejęcie powtarzalnego wzbogacania danych, obsługi incydentów i działań naprawczych, pozostawiając zespołowi więcej czasu na głębsze dochodzenia.
Co to jest automatyzacja zabezpieczeń?
Automatyzacja zabezpieczeń to zastosowanie workflow, reguł, integracji i narzędzi bezpieczeństwa do wykonywania określonych działań bez konieczności ręcznego uruchamiania każdego kroku.
Przykład:
system wykrywa podejrzane logowanie → pobiera informacje o koncie i adresie IP → sprawdza wcześniejsze alerty → zwiększa priorytet incydentu → tworzy ticket → powiadamia analityka
W bardziej kontrolowanym scenariuszu system może pójść dalej:
podejrzane logowanie → analiza → wysoki poziom ryzyka → czasowe zablokowanie konta → powiadomienie SOC → dalsza weryfikacja
Automatyzacja nie musi więc oznaczać autonomicznego reagowania. Może ograniczać się do przygotowania informacji i kolejnych kroków dla analityka.
To często najlepszy punkt startowy.
Automatyzacja procesów bezpieczeństwa a zwykła automatyzacja IT
W obu przypadkach wykorzystywane są podobne mechanizmy:
- trigger,
- warunki,
- akcje,
- integracje API,
- skrypty,
- workflow,
- monitoring wykonania.
Różnica leży przede wszystkim w celu i ryzyku.
Automatyzacja IT może np. utworzyć konto, wdrożyć konfigurację albo uruchomić kopię zapasową.
Automatyzacja bezpieczeństwa może natomiast:
- zablokować konto,
- odizolować urządzenie,
- zmodyfikować regułę firewalla,
- oznaczyć plik jako złośliwy,
- uruchomić proces reagowania na incydent.
CISA zwraca uwagę, że workflow bezpieczeństwa często odwzorowuje logikę analityka wybierającego odpowiednią reakcję, podczas gdy klasyczna automatyzacja IT częściej wykonuje serię technicznych czynności potrzebnych do realizacji wcześniej wybranej decyzji.
To rozróżnienie jest ważne, ponieważ błąd w automatyzacji bezpieczeństwa może sam spowodować incydent.
Gdzie automatyzacja zabezpieczeń daje największą wartość?
Najlepszymi kandydatami są procesy o dużej częstotliwości, wymagające wykonywania podobnych czynności w wielu systemach.
Wzbogacanie alertów
Analityk otrzymuje alert zawierający adres IP.
Bez automatyzacji musi ręcznie sprawdzić:
- reputację adresu,
- wcześniejsze zdarzenia,
- użytkownika,
- hosta,
- historię logowań,
- powiązane incydenty.
Automatyzacja może zebrać te dane jeszcze przed rozpoczęciem analizy.
Microsoft wskazuje enrichment, czyli automatyczne wzbogacanie incydentu o dodatkowe informacje, jako jeden z podstawowych przypadków wykorzystania playbooków w Microsoft Sentinel.
Dzięki temu analityk nie zaczyna od zbierania danych, lecz od ich interpretacji.
Klasyfikacja i routing incydentów
System może automatycznie:
- przypisać kategorię,
- ustawić właściciela,
- zmienić status,
- dodać tag,
- podnieść priorytet,
- przesłać sprawę do właściwego zespołu.
Microsoft Sentinel umożliwia wykonywanie takich działań bez uruchamiania rozbudowanego playbooka, bezpośrednio poprzez reguły automatyzacji.
Jest to dobry przykład automatyzacji niskiego ryzyka: system porządkuje pracę, ale nie wykonuje jeszcze nieodwracalnej reakcji na infrastrukturze.
Automatyczne reagowanie na incydenty
Kolejny poziom to automatyczna reakcja.
Przykładowe działania:
- zablokowanie podejrzanego adresu IP,
- wyłączenie konta,
- wymuszenie resetu hasła,
- odizolowanie urządzenia,
- cofnięcie sesji,
- przesłanie pliku do analizy,
- uruchomienie skanowania,
- utworzenie zgłoszenia w systemie ITSM.
Microsoft pokazuje przykładowy playbook, w którym incydent dotyczący potencjalnie przejętego użytkownika może prowadzić do utworzenia ticketu, powiadomienia zespołu, a następnie — po decyzji administratora — zablokowania konta i adresu IP.
To dobry model, ponieważ łączy automatyzację z human-in-the-loop.
System przygotowuje i wykonuje procedurę, ale istotna decyzja pozostaje po stronie człowieka.
SOAR – czym jest w automatyzacji bezpieczeństwa?
SOAR oznacza Security Orchestration, Automation and Response.
W praktyce jest to podejście i klasa narzędzi umożliwiających łączenie wielu systemów bezpieczeństwa oraz wykonywanie zdefiniowanych procedur reagowania.
NIST wymienia SOAR jako „security orchestration, automation, and response” w swojej aktualnej terminologii bezpieczeństwa.
Typowy SOAR może integrować:
SIEM → EDR/XDR → threat intelligence → firewall → IAM → ticketing → komunikator
Zamiast wykonywać każdą czynność osobno, analityk uruchamia lub automatycznie aktywuje playbook.
Przykład:
alert phishingowy → pobranie wiadomości → analiza załącznika → sprawdzenie domeny → wyszukanie innych odbiorców → usunięcie wiadomości → zablokowanie domeny → utworzenie incydentu
Google Security Operations opisuje playbook SOAR jako połączenie triggera, działań oraz warunkowego przepływu sterującego kolejnymi krokami reakcji.
SIEM a SOAR – jaka jest różnica?
Pojęcia często występują razem, ale pełnią inne funkcje.
SIEM koncentruje się przede wszystkim na zbieraniu i analizowaniu zdarzeń bezpieczeństwa oraz generowaniu alertów.
SOAR koordynuje to, co powinno wydarzyć się po wykryciu określonej sytuacji.
W uproszczeniu:
SIEM: co się wydarzyło?
SOAR: co mamy teraz zrobić?
Współczesne platformy coraz częściej łączą oba mechanizmy. Przykładowo Microsoft Sentinel działa jako SIEM, ale posiada jednocześnie funkcje SOAR w postaci automation rules i playbooków.
Automatyzacja zarządzania podatnościami
Automatyzacja procesów bezpieczeństwa nie ogranicza się do incydent response.
Może również wspierać vulnerability management.
Przykładowy proces:
skan → wykryta podatność → określenie zasobu → sprawdzenie krytyczności → nadanie priorytetu → utworzenie zadania → przypisanie właściciela → kontrola naprawy
Automatycznie można:
- importować wyniki skanerów,
- łączyć podatność z konkretnym zasobem,
- tworzyć zgłoszenia,
- przypominać o terminach,
- eskalować krytyczne podatności,
- sprawdzać, czy poprawka została wdrożona.
Najważniejsza jest jednak dobra priorytetyzacja.
Nie każda podatność o wysokim wyniku technicznym musi mieć identyczne znaczenie biznesowe. Liczy się również:
- ekspozycja zasobu,
- jego krytyczność,
- dostępne zabezpieczenia,
- możliwość wykorzystania podatności,
- znaczenie systemu dla organizacji.
Automatyzacja może przygotować dane i workflow, ale nie powinna redukować risk management do jednej liczby ze skanera.
Automatyzacja aktualizacji i patch management
Proces aktualizacji jest kolejnym dobrym kandydatem do automatyzacji:
wykrycie dostępnej poprawki → ocena → test → wdrożenie → weryfikacja
W prostych środowiskach część aktualizacji może być wykonywana automatycznie.
W systemach krytycznych trzeba jednak uwzględnić:
- kompatybilność,
- okno serwisowe,
- możliwość rollbacku,
- wpływ na działanie usługi,
- wcześniejsze testy.
Nie powinno się więc utożsamiać bezpieczeństwa z regułą:
każdy patch instaluj natychmiast na produkcji.
Automatyzacja powinna skracać i standaryzować proces, ale zachowywać poziom kontroli adekwatny do ryzyka.
Automatyzacja zarządzania tożsamością i dostępem
IAM jest jednym z obszarów, gdzie automatyzacja może przynieść dużą wartość.
Przykłady:
- automatyczne tworzenie kont,
- usuwanie dostępów po odejściu pracownika,
- zmiana uprawnień po zmianie stanowiska,
- wykrywanie nieaktywnych kont,
- wygaszanie tymczasowych uprawnień,
- automatyczna reakcja na ryzykowne logowanie.
Przykładowy proces offboardingu:
HR oznacza zakończenie zatrudnienia → konto zostaje zablokowane → aktywne sesje wygaszone → dostępy do aplikacji usunięte → właściciele zasobów powiadomieni → proces zapisany w logach
To dużo bezpieczniejsze niż lista systemów przesyłana mailem do kilku administratorów.
Jednocześnie automatyzacja IAM musi być dokładnie kontrolowana. Błędna reguła może odebrać dostęp dużej grupie pracowników albo — co groźniejsze — pozostawić niepotrzebne uprawnienia.
Automatyzacja monitoringu i wykrywania zagrożeń
NIST Cybersecurity Framework 2.0 dzieli zarządzanie ryzykiem cyberbezpieczeństwa na sześć funkcji:
Govern, Identify, Protect, Detect, Respond, Recover.
Automatyzacja może wspierać praktycznie wszystkie z nich.
Govern
Można automatyzować:
- zbieranie danych do raportowania,
- kontrolę zgodności konfiguracji,
- przypomnienia dotyczące przeglądów,
- monitoring realizacji określonych polityk.
Nie należy automatycznie przekazywać systemowi odpowiedzialności za akceptację ryzyka.
Identify
Automatyzacja może wspierać:
- wykrywanie zasobów,
- aktualizację inventory,
- korelację informacji o podatnościach,
- klasyfikację urządzeń i usług.
Protect
Tutaj pojawiają się:
- polityki dostępu,
- automatyczne aktualizacje,
- konfiguracja zabezpieczeń,
- zarządzanie tożsamością.
Detect
To obszar:
- monitoringu,
- korelacji zdarzeń,
- wykrywania anomalii,
- alertowania.
Respond
Najbardziej naturalny obszar SOAR:
- triage,
- enrichment,
- containment,
- powiadomienia,
- eskalacja,
- działania naprawcze.
Recover
Automatyzacja może wspierać:
- odtwarzanie konfiguracji,
- uruchamianie procedur recovery,
- weryfikację usług,
- powiadomienia po incydencie.
NIST podkreśla, że funkcje CSF powinny być traktowane łącznie, a reagowanie na incydenty jest częścią szerszego zarządzania ryzykiem, nie osobnym procesem uruchamianym dopiero po ataku.
Które procesy bezpieczeństwa warto automatyzować?
Dobry kandydat zazwyczaj spełnia kilka warunków:
| Cecha | Dlaczego pomaga? |
|---|---|
| Duża częstotliwość | Ręczna obsługa zużywa dużo czasu |
| Jasne reguły | Można przewidzieć właściwą reakcję |
| Powtarzalność | Ten sam proces występuje regularnie |
| Duża liczba systemów | Automatyzacja ogranicza ręczne przełączanie narzędzi |
| Potrzeba szybkiej reakcji | Opóźnienie zwiększa ryzyko |
| Niewielki koszt błędnej automatycznej akcji | Można zwiększyć poziom autonomii |
| Dobra jakość danych | System posiada wystarczające informacje do podjęcia działania |
Przed automatyzacją trzeba dokładnie przeanalizować również wyjątki.
Proces obsługujący 1000 alertów dziennie może wydawać się idealnym kandydatem, ale jeżeli większość przypadków wymaga indywidualnej analizy, agresywna automatyzacja reakcji może być niebezpieczna.
Czego nie automatyzować bez kontroli człowieka?
Im bardziej nieodwracalna i ryzykowna akcja, tym większy powinien być poziom kontroli.
Przykładowo:
| Działanie | Sensowny model |
| Dodanie tagu do incydentu | Automatycznie |
| Pobranie danych o IP | Automatycznie |
| Utworzenie ticketu | Automatycznie |
| Powiadomienie SOC | Automatycznie |
| Zablokowanie znanego złośliwego hasha | Zależnie od polityki |
| Odizolowanie krytycznego serwera | Najczęściej po dodatkowej walidacji |
| Wyłączenie konta uprzywilejowanego | Kontrolowana procedura |
| Usunięcie danych | Silna kontrola człowieka |
Nie chodzi o to, że określonej czynności nigdy nie można zautomatyzować.
Trzeba ustalić konsekwencję błędu.
Automatyczne odizolowanie laptopa użytkownika może być akceptowalne. Automatyczne odłączenie systemu sterującego kluczową produkcją wymaga zupełnie innego modelu.
Największe ryzyko: automatyzacja może skalować błąd
Często mówi się, że automatyzacja zmniejsza liczbę błędów ludzkich.
To tylko część prawdy.
Automatyzacja ogranicza ręczne pomyłki w powtarzalnych czynnościach, ale błędna reguła może wykonać tę samą nieprawidłową operację setki razy.
Przykład:
źle zdefiniowana reguła wykrywa legalne logowanie jako atak i automatycznie blokuje każdego użytkownika spełniającego warunek.
Błąd człowieka mógłby dotknąć jednej operacji.
Błąd w automatyzacji może zostać natychmiast powielony na całe środowisko.
Dlatego bezpieczeństwo automatyzacji powinno obejmować:
- testowanie,
- ograniczenie zakresu działania,
- mechanizmy approval,
- rollback,
- monitoring,
- logowanie,
- możliwość natychmiastowego wyłączenia workflow.
Uprawnienia automatyzacji są krytycznym elementem bezpieczeństwa
Playbook potrzebujący możliwości blokowania kont nie powinien jednocześnie otrzymywać administratora do całej infrastruktury.
Stosuj zasadę least privilege.
Każda automatyzacja powinna posiadać tylko takie uprawnienia, jakie są potrzebne do wykonania konkretnego zadania.
Microsoft Sentinel wykorzystuje osobne role do zarządzania i wykonywania playbooków, w tym dedykowane uprawnienia dla mechanizmu automatyzacji.
Warto również kontrolować:
- konta serwisowe,
- tokeny API,
- sekrety,
- certyfikaty,
- zakres integracji,
- możliwość wywoływania workflow z zewnątrz.
Kompromitacja systemu automatyzacji posiadającego szerokie uprawnienia może dać atakującemu gotowy mechanizm wykonywania działań w wielu systemach.
Jak wdrożyć automatyzację procesów bezpieczeństwa?
Nie zaczynaj od zakupu platformy SOAR.
1. Wybierz powtarzalny proces
Przykład:
analitycy ręcznie sprawdzają reputację każdego adresu IP występującego w alercie.
To konkretny problem.
Znacznie gorszy cel:
chcemy wdrożyć SOAR.
2. Rozpisz obecny przebieg
Sprawdź:
alert → analiza → dodatkowe dane → decyzja → akcja → zamknięcie
Następnie określ, które kroki są mechaniczne, a które wymagają interpretacji.
3. Usuń zbędne działania
Jeżeli analityk kopiuje tę samą informację do trzech systemów, być może nie trzeba automatyzować wszystkich trzech operacji.
Można najpierw zmienić architekturę procesu.
4. Zacznij od automatyzacji niskiego ryzyka
Dobrym pierwszym etapem jest:
- enrichment,
- routing,
- tagowanie,
- tworzenie zgłoszeń,
- powiadomienia.
Dopiero po potwierdzeniu stabilności warto przechodzić do automatycznych działań naprawczych.
5. Dodaj warunki bezpieczeństwa
Workflow powinien zawierać:
- warunki wejściowe,
- limity,
- wyjątki,
- approval,
- fallback,
- logowanie.
6. Testuj również błędne scenariusze
Nie wystarczy sprawdzić, czy playbook działa wtedy, gdy dane są idealne.
Sprawdź:
- błędny alert,
- niedostępne API,
- brak uprawnień,
- timeout,
- duplikat incydentu,
- niekompletne dane,
- częściowo wykonany workflow.
7. Monitoruj automatyzację
Automatyzacja bezpieczeństwa sama powinna być monitorowana.
Trzeba wiedzieć:
- ile razy się uruchomiła,
- które akcje wykonała,
- ile procesów zakończyło się błędem,
- ile razy potrzebna była ręczna interwencja,
- czy system nie generuje niepożądanych efektów.
Jak mierzyć efekty automatyzacji zabezpieczeń?
Nie mierz sukcesu liczbą utworzonych playbooków.
Lepiej analizować wpływ na proces.
Przydatne mogą być:
- czas od wykrycia do rozpoczęcia reakcji,
- czas obsługi incydentu,
- liczba ręcznych kroków,
- liczba alertów wymagających interwencji,
- liczba automatycznie wzbogaconych incydentów,
- odsetek playbooków zakończonych poprawnie,
- liczba błędnych automatycznych reakcji,
- czas analityków przeznaczany na rutynową obsługę,
- udział incydentów wymagających eskalacji.
NIST SP 800-61 Rev. 3 z kwietnia 2025 r. podkreśla poprawę skuteczności wykrywania, reagowania i odzyskiwania jako część dojrzałego zarządzania incydentami.
Najważniejszym pytaniem pozostaje:
czy automatyzacja skróciła właściwy proces bez wprowadzania dodatkowego ryzyka?
AI w automatyzacji bezpieczeństwa
AI może rozszerzyć klasyczną automatyzację tam, gdzie problem wymaga interpretacji dużej liczby informacji.
Może pomagać w:
- streszczaniu incydentów,
- analizowaniu logów,
- grupowaniu powiązanych alertów,
- klasyfikowaniu zgłoszeń,
- wyszukiwaniu podobnych incydentów,
- przygotowywaniu propozycji kolejnych działań.
Nie oznacza to jednak, że model AI powinien otrzymać nieograniczone uprawnienia do wykonywania operacji.
Dobry model:
AI analizuje → reguły sprawdzają → człowiek zatwierdza działanie wysokiego ryzyka → automatyzacja wykonuje
jest zwykle bezpieczniejszy niż:
AI decyduje → wykonuje wszystko autonomicznie.
W obszarze cyberbezpieczeństwa możliwość działania musi być zawsze powiązana z poziomem ryzyka i zakresem uprawnień.
Automatyzacja zabezpieczeń nie zastępuje programu bezpieczeństwa
SOAR, playbooki i automatyczne reguły są tylko mechanizmami wykonawczymi.
Nie zastąpią:
- zarządzania ryzykiem,
- polityk bezpieczeństwa,
- poprawnej architektury,
- zarządzania dostępem,
- przygotowania na incydenty,
- kopii zapasowych,
- kompetencji zespołu.
NIST CSF 2.0 podkreśla, że zarządzanie cyberbezpieczeństwem obejmuje równocześnie governance, identyfikację ryzyka, ochronę, wykrywanie, reagowanie i odzyskiwanie.
Automatyzacja pomaga wykonywać niektóre działania szybciej i bardziej konsekwentnie.
Nie określa jednak sama, które ryzyka organizacja powinna zaakceptować, a których nie.
Od czego zacząć automatyzację bezpieczeństwa?
Najlepiej od jednego powtarzalnego procesu, który dziś zabiera analitykom dużo czasu, ale nie wymaga za każdym razem wyjątkowej wiedzy.
Dobrym kandydatem może być:
nowy alert → automatyczne wzbogacenie danych → utworzenie incydentu → klasyfikacja → przypisanie → powiadomienie analityka
Po ustabilizowaniu procesu można dodać kolejne działania:
→ zebranie dowodów → automatyczne ograniczenie zagrożenia niskiego ryzyka → kontrolowana reakcja na przypadki poważniejsze
W ten sposób organizacja zwiększa autonomię stopniowo.
Najpierw należy uporządkować proces bezpieczeństwa, następnie zautomatyzować powtarzalne działania, a dopiero później rozszerzać automatyzację na reakcje mające realny wpływ na użytkowników, systemy i ciągłość biznesową.
