Alert nie jest wykonanym zadaniem. Może pojawić się w SIEM-ie, skrzynce albo komunikatorze i nadal nie mieć osoby, która sprawdzi host, zapisze decyzję i wróci z wynikiem.
Dobra automatyzacja nie polega na tym, że bot sam ogłasza incydent. Jej pierwszym celem jest doprowadzenie zdarzenia do właściwej osoby z danymi, które pozwalają zacząć pracę.
Najpierw ustal wejście
Workflow powinien przyjmować mały, stały zestaw pól:
- czas wraz ze strefą czasową
- host, konto albo usługa
- źródło alertu i identyfikator reguły
- krótki surowy fragment zdarzenia
- poziom ważności wraz z powodem
- odnośnik do miejsca, w którym można sprawdzić szczegóły
Przed utworzeniem zadania usuń z fragmentu zdarzenia hasła, tokeny, klucze i zbędne dane osobowe; zadanie musi trafić do miejsca z odpowiednią kontrolą dostępu i retencją.
Jeśli tych danych brakuje, automatyzacja tylko szybciej przeniesie pusty komunikat. Minimalny zapis zdarzenia opisuję też w artykule Pierwsze 15 minut alertu L1.
Reguła kierowania ma być czytelna
Przykład może być prosty:
źródło + typ zdarzenia + host → kolejka → właściciel
Alert dotyczący logowania trafia do osoby odpowiedzialnej za konta. Niedostępna usługa trafia do właściciela tej usługi. Brak dopasowania nie powinien kończyć się ciszą — potrzebna jest kolejka ogólna i informacja, że reguła nie znalazła odbiorcy.
Regułę warto zapisać obok workflow, a nie ukrywać w kilkudziesięciu krokach narzędzia.
Zadanie zamiast kolejnego powiadomienia
Wysłanie wiadomości na Telegram albo Slack jest przydatne, ale samo w sobie nie tworzy odpowiedzialności. Zadanie powinno mieć:
- jednoznaczny tytuł
- właściciela
- czas utworzenia i termin reakcji
- stan, na przykład: nowe, sprawdzane, zamknięte
- miejsce na decyzję i jej uzasadnienie
Powiadomienie prowadzi do zadania. Nie zastępuje go.
Automatyzacja też potrzebuje logu
Trzeba móc odpowiedzieć na kilka pytań: co uruchomiło workflow, jakie dane przyjął, gdzie utworzył zadanie, komu wysłał wiadomość i czy któryś krok się nie udał.
Log nie powinien zawierać haseł, tokenów API ani całych poufnych wiadomości. Powinien za to mieć identyfikator, czas i wynik każdego kroku. Dzięki temu błąd da się odtworzyć bez zgadywania.
Bezpieczna ścieżka błędu
Awaria integracji nie może usuwać zdarzenia. Gdy system zadań albo komunikator nie odpowiada:
- workflow zachowuje wejście w kontrolowanym miejscu,
- zapisuje błąd bez sekretów,
- wysyła powiadomienie zapasowym kanałem albo tworzy wpis w kolejce błędów,
- nie ponawia operacji bez końca.
Ponowienie musi być ograniczone i odporne na duplikaty. W przeciwnym razie jeden alert utworzy kilkadziesiąt takich samych zadań.
Co warto automatyzować
Dobrym początkiem są czynności powtarzalne i odwracalne: uzupełnienie pól, wybór kolejki, utworzenie zadania, dołączenie checklisty i wysłanie informacji do właściciela.
Izolowanie hosta, blokowanie konta albo zamykanie alertu wymaga osobnej decyzji i wyraźnie ustalonego zakresu. Automatyzacja może przygotować przycisk i zebrać fakty. Nie powinna udawać autonomicznego SOC.
Przykłady małych integracji znajdują się w portfolio automatyzacji. Jeśli ten sam krok jest wykonywany ręcznie wiele razy i za każdym razem wygląda trochę inaczej, najpierw warto opisać procedurę, a dopiero potem zamienić ją w workflow.