SOAR (Security Orchestration, Automation and Response)

SOAR (Security Orchestration, Automation and Response) to klasa oprogramowania, które pozwala zespołom bezpieczeństwa łączyć i koordynować osobne narzędzia oraz automatyzować powtarzalne kroki obsługi zdarzeń ^[1]. SOAR wykonuje zapisany wcześniej playbook, czyli ustaloną sekwencję czynności uruchamianą przez alert. Według CISA technologia ta pozwala usprawnić reagowanie na incydenty przez automatyczne wykonywanie zdefiniowanych działań w odpowiedzi na wykryte anomalie ^[3]. Termin SOAR wprowadził w 2015 roku Gartner ^[1].

Jak działa

Nazwa opisuje trzy warstwy. Kapitan Hack wymienia je następująco ^[1]:

Źródłem alertów jest zwykle SIEM (Security Information and Event Management) albo narzędzia klasy EDR (Endpoint Detection and Response) i XDR (Extended Detection and Response). SOAR odbiera alert, uzupełnia go o kontekst, na przykład o dane z threat intelligence o adresie IP, i wykonuje kolejne kroki playbooka. Playbooki mogą być w pełni automatyczne, w pełni ręczne albo mieszane ^[1]. Typowy przebieg pokazuje schemat poniżej.

RYS. 1Obsługa alertu przez playbook SOAR

NIST w wytycznych SP 800-61 Rev. 3 z kwietnia 2025 roku wymienia narzędzia SIEM i SOAR jako środki do ciągłego monitorowania logów pod kątem znanej złośliwej aktywności oraz do korelowania danych z wielu źródeł ^[2]. Ten sam dokument zaleca rozważenie automatycznego zakładania i przypisywania zgłoszeń w systemie obsługi, gdy pojawiają się określone typy alertów ^[2]. NIST wymienia SIEM i SOAR także jako automatyczny sposób szacowania skutków i zasięgu niepożądanych zdarzeń, obok oceny ręcznej, z zaleceniem, by te szacunki przeglądać i poprawiać ^[2].

Playbooki i standardy

Playbook w SOAR jest zapisem procedury, który maszyna może wykonać. Żeby takie procedury dało się przenosić między narzędziami i organizacjami, konsorcjum OASIS opracowało specyfikację CACAO. Wersja 2.0 została opublikowana 27 listopada 2023 roku jako Committee Specification 01 ^[4]. CACAO definiuje schemat i taksonomię playbooków oraz opisuje, jak je tworzyć, dokumentować i udostępniać w ustrukturyzowany sposób ^[4]. Playbook może być uruchamiany doraźnie, okresowo albo w reakcji na zdarzenie automatyczne lub ręczne ^[4].

Dobry playbook zawiera warunek wejścia, listę kroków, punkty decyzji człowieka i sposób wycofania akcji. Ostatni element jest ważny, bo automatyczna blokada, która trafi w fałszywy alarm, odcina prawdziwych użytkowników.

W WordPressie

Pojedyncza strona na WordPressie rzadko ma własny SOAR. Te same mechanizmy działają jednak w mniejszej skali na serwerze, na którym strona stoi. Przykładem jest moduł Active Response w otwartym systemie Wazuh. Uruchamia on skrypty na monitorowanych maszynach, gdy pojawi się alert o określonym identyfikatorze reguły, poziomie albo grupie ^[5]. Wbudowane skrypty potrafią między innymi blokować złośliwy ruch sieciowy i usuwać złośliwe pliki ^[5]. Odpowiedź może być bezstanowa, czyli jednorazowa, albo stanowa, cofana automatycznie po określonym czasie ^[5].

Źródłem zdarzeń z samego WordPressa może być na przykład hak wp_login_failed, który rdzeń wywołuje po nieudanym logowaniu, przekazując nazwę użytkownika albo adres e-mail ^[7]. Wpis w logu, który z niego powstaje, może odczytać agent monitorujący serwer.

add_action( 'wp_login_failed', function ( $username ) {
    error_log( 'wp_login_failed user=' . sanitize_user( $username ) );
} );

Seria takich wpisów z jednego adresu to sygnał ataku siłowego (brute-force). Playbook może wtedy czasowo zablokować adres na zaporze sieciowej, co uzupełnia limit prób logowania ustawiony we wtyczce. Sekurak, opisując Wazuh w kontekście NIS2, określa automatyczny skrypt firewall-drop i izolację agenta jako dokładną realizację wymogu natychmiastowego reagowania ^[6].

Znaczenie

SOAR ma rozwiązywać problem skali. Zespół SOC (Security Operations Center) otrzymuje więcej alertów, niż jest w stanie ręcznie przejrzeć, co prowadzi do zmęczenia alertami (alert fatigue). Automatyczny triaż (triage) i wzbogacanie alertów skracają czas, jaki analityk poświęca na jedno zdarzenie. Automatyczne akcje przybliżają też moment opanowania incydentu.

Automatyzacja ma jednak granice. NIST zaleca regularny ręczny przegląd logów z technologii, których nie da się wystarczająco monitorować automatycznie ^[2]. Kapitan Hack zaznacza, że SOAR ma cechy wspólne z SIEM i XDR, ale ich funkcje się nie pokrywają ^[1]. SOAR nie wykrywa zagrożeń sam z siebie: wykonuje to, co zapisano w playbooku, na podstawie alertów z innych systemów.

Dobre praktyki

• Zaczynać od automatyzacji kroków bez ryzyka: wzbogacania alertów o wskaźniki kompromitacji (IoC), zakładania zgłoszeń, powiadomień.
• Akcje blokujące ustawiać jako czasowe, z automatycznym wycofaniem, tak jak stanowe odpowiedzi w Wazuh ^[5].
• Zostawić analitykowi możliwość ręcznego wyboru i wykonania działań obok automatycznych; NIST zaleca taką możliwość przy opanowywaniu incydentów ^[2].
• Wersjonować playbooki i testować je na środowisku testowym, zanim zaczną działać na produkcji.
• Przeglądać skuteczność playbooków po każdym poważniejszym incydencie.

Organizacje, które nie utrzymują własnego zespołu, korzystają często z usług zewnętrznych, na przykład MDR (Managed Detection and Response), w których dostawca sam utrzymuje narzędzia automatyzacji.

Historia

Kapitan Hack podaje, że SOAR połączył trzy wcześniejsze kategorie narzędzi: platformy reagowania na incydenty, platformy orkiestracji i automatyzacji bezpieczeństwa oraz platformy analizy zagrożeń ^[1]. W maju 2025 roku CISA wraz z australijskim ACSC i innymi partnerami opublikowała zestaw wytycznych o wdrażaniu SIEM i SOAR: dokument dla kadry kierowniczej, dokument dla praktyków oraz listę priorytetowych logów do zasilania SIEM ^[3].