Model automatyzacji SecureVisio: Jak analiza odbywa się jeszcze przed zaangażowaniem analityka?

Większość zespołów ds. SOC ma ten sam problem – tylko w różnej skali: alerty napływają szybciej, niż analitycy są w stanie je zbadać. Standardową odpowiedzią było dotychczas „zatrudnić więcej ludzi” lub „lepiej dostroić reguły”. Odpowiedź SecureVisio jest strukturalnie inna – analiza zostaje wbudowana w proces reagowania, a nie następuje po nim.

Patrząc na to, jak platforma naprawdę działa od środka, model automatyzacji polega mniej na uruchamianiu skryptów, a bardziej na tym, że kontekst automatycznie przepływa przez każdy etap obsługi incydentu. Ta różnica ma większe znaczenie, niż mogłoby się wydawać.

Problem z podejściem „Alert, potem Analiza”

Klasyczny przepływ pracy SIEM działa sekwencyjnie. Otrzymanie alertu. Analityk go otwiera. Analityk ręcznie przeszukuje logi, sprawdza bazy reputacji, analizuje aktywność użytkownika, mapuje zdarzenie na framework MITRE ATT&CK – a następnie decyduje, co zrobić. Każdy z tych kroków to przekazanie pałeczki, a każde przekazanie to opóźnienie.

SecureVisio działa inaczej: analiza odbywa się podczas triażu, nie po nim. Zanim analityk zobaczy incydent, znaczna część kontekstowych podstaw jest już przygotowana.

AutoTriage: Równoległość zamiast sekwencyjnego przetwarzania

Najlepszym przykładem jest scenariusz AutoTriage. Gdy incydent zostaje utworzony, system natychmiast sprawdza, czy dla tego samego użytkownika (ctx.User) lub tego samego adresu IP (ctx.IP) w tym samym dniu istnieją już powiązane incydenty. Jeśli tak – zostają automatycznie scalone. Żaden analityk nie musi samodzielnie zauważać tego zduplikowanego wzorca.

Jeśli nie – AutoTriage nie rejestruje zdarzenia i nie czeka. Natychmiast uruchamia zestaw równoległych, w pełni zautomatyzowanych kroków analitycznych:

• Analiza ruchu sieciowego pod kątem znanych wskaźników ataków
• Porównanie aktywności użytkownika z wzorcami bazowymi zachowań
• Analiza zachowania encji
• Mapowanie technik MITRE ATT&CK
• Analiza logów i zdarzeń pod kątem anomalii
• Integracja z Threat Intelligence na podstawie danych zdarzenia
• Zapytanie do bazy wiedzy o wcześniejszej aktywności na dotkniętym hoście
• Weryfikacja kont użytkowników pod kątem oznak kompromitacji

Kroki te nie są wykonywane sekwencyjnie – działają jednocześnie. I co kluczowe: żaden z nich nie wymaga zainicjowania przez analityka.

Warto się nad tym zatrzymać. Analityk wykonujący triage ręcznie przechodzi przez te kontrole jedna po drugiej, przełączając się między narzędziami. AutoTriage sprowadza to wszystko do fazy wstępnej analizy. Gdy zgłoszenie trafia na biurko człowieka, ma już dołączoną ocenę wpływu zagrożenia, kontekst behawioralny i mapowania MITRE.

Zadeklarowany cel – wprost zapisany w dokumentacji – polega na tym, by analitycy mogli skupić się na decyzjach wymagających eksperckiej oceny, a nie na powtarzalnych czynnościach zbierania danych.

Playbooki, które naprawdę rozróżniają działania automatyczne od ręcznego

Playbooki nie są binarne. Nie wybiera się między „w pełni zautomatyzowany” a „wymaga udziału człowieka”. Poszczególne kroki, plany lub cały scenariusz można oznaczyć jako automatyczne lub ręczne – na dowolnym poziomie szczegółowości odpowiednim dla danej organizacji.

To bardziej użyteczne, niż się wydaje. Scenariusz może automatycznie zbierać informacje o hoście, automatycznie odpytywać bazy reputacji, automatycznie sprawdzać, czy adres IP jest już na liście blokowania – a następnie zatrzymać się i przedstawić operatorowi decyzję z wypełnionym już odpowiednim kontekstem. Operator wybiera opcję (zablokuj konto, dodaj IP do listy blokowania, nie wymaga działania), dodaje komentarz i scenariusz jest kontynuowany.

System obsługuje również warunkowe postępowanie. Blok condition kroku określa, czy dana akcja w ogóle zostanie wykonana – jeśli warunek nie jest spełniony, krok jest pomijany i scenariusz biegnie dalej. Można też skonfigurować, czy nieodpasowane wyniki w kroku wyszukiwania powodują zatrzymanie scenariusza, czy jego kontynuację.

W praktyce powstaje przepływ pracy, w którym automatyzacja obsługuje części deterministyczne, a ludzie zajmują się niejednoznacznymi – bez konieczności jawnego przełączania się między nimi.

Wyszukiwanie w logach bez potrzeby znajomości języków zapytań

Niedocenianym elementem jest backtracking. Operatorzy mogą przeszukiwać logi bezpośrednio z widoku incydentu, korzystając ze składni zbliżonej do SQL, gdzie autouzupełnianie podpowiada dostępne pola, obiekty i funkcje w miejscu wpisywania.

Przeglądarka logów ma również wyszukiwanie słów kluczowych, które przeszukuje wszystkie pola – wpisanie nazwy użytkownika pokazuje najpierw, w których polach ta nazwa się pojawiła (DstUserName, SrcUserName itp.), a dopiero potem wyświetla dopasowane rekordy. Terminy można łączyć, używając % jako operatora wieloznacznego.

Wyszukiwania te można osadzać bezpośrednio w krokach playbooka. Scenariusz może automatycznie wykonać retrospektywne wyszukiwanie – np. sprawdzić, czy docelowy użytkownik logował się na innych maszynach w oknie czasowym względem zdarzenia – i rozgałęzić się na podstawie liczby wyników. Można sprawdzić, czy DstUserName pojawił się w zdarzeniach logowania na innych systemach od dnia zdarzenia. True, jeśli count > 0, w przeciwnym razie false.

Tym samym „sprawdź, czy ten użytkownik wykonywał lateral movement” staje się krokiem scenariusza – a nie zadaniem analityka.

Integracja PAM: Element, który automatyzacja bezpieczeństwa zazwyczaj psuje

Zautomatyzowane akcje remediacji prawie zawsze mają problem z poświadczeniami. Skrypt musi się uwierzytelnić, żeby coś zrobić – wyłączyć konto AD, zablokować IP, odpytać zewnętrzną usługę. Naiwne podejście osadza poświadczenia w skrypcie lub konfiguracji. To problem bezpieczeństwa w produkcie bezpieczeństwa.

SecureVisio rozwiązuje to przez wbudowaną integrację z PAM (Privileged Access Manager). Gdy akcja systemowa jest skonfigurowana z flagą „Global name” dla parametru, wartość jest pobierana z PAM w momencie wykonania – nie jest przechowywana w konfiguracji scenariusza. Sam scenariusz nigdy nie zawiera poświadczeń.

Przykład z dokumentacji to akcja [ADManager] Disable User, która pobiera token uwierzytelniający, hasło i nazwę użytkownika bezpośrednio z PAM w momencie uruchomienia. Analityk wywołujący tę akcję – lub system wywołujący ją automatycznie – nie widzi tych poświadczeń i nie musi ich obsługiwać.

Ma to znaczenie z dwóch powodów: umożliwia pełną automatyzację akcji wymagających uwierzytelnienia bez ręcznego podawania danych dostępowych, a także eliminuje wrażliwe poświadczenia z konfiguracji scenariuszy, gdzie mógłby je odczytać lub wyeksportować każdy z dostępem do edytora playbooków.

AI jako krok scenariusza – nie tylko okno czatu

SecureVisio posiada interfejs czatu z asystentem AI dla analityków. Ta część jest stosunkowo prosta – otwierasz czat, wybierasz spośród predefiniowanych promptów, otrzymujesz podsumowanie lub klasyfikację incydentu.

Mniej oczywiste jest to, że AI jest również dostępne wewnątrz scenariuszy automatyzacji jako pełnoprawny typ akcji.

Akcja „Asystent AI” w scenariuszu może być skonfigurowana tak, by przekazywać do modelu określone dane kontekstowe: ostatni frame zdarzenia, wyniki poprzednich akcji w scenariuszu, załączone pliki, historię lub skrypt reguły SIEM, który wywołał alert. Odpowiedź modelu może być automatycznie zapisana do schowka lub zachowana do dalszych kroków. Scenariusz nie zatrzymuje się i nie czeka, aż człowiek otworzy czat.

Analiza AI może zatem być częścią zautomatyzowanego potoku triażu – nie jako osobne narzędzie, z którym analityk ręcznie się konsultuje. Architektura traktuje AI tak samo jak każde inne źródło wzbogacania danych: coś, co przyjmuje dane wejściowe i zwraca ustrukturyzowane dane wyjściowe, które scenariusz może dalej wykorzystywać.

System promptów ma również warstwę profili – prompty są zorganizowane w profile, a profile można powiązać z konkretnymi zespołami reagowania i typami scenariuszy. Prompt napisany dla scenariusza włamania do sieci można trzymać oddzielnie od tego dla kompromitacji endpointu i wyświetlać we właściwym kontekście zespołowym.

Co to naprawdę zmienia

Filozofia automatyzacji tutaj nie brzmi „zastąp analityków”. Jest bliższa sformułowaniu: nie każ analitykom robić rzeczy, które system może wykonać z równą lub większą dokładnością.

Sprawdzenie, czy użytkownik logował się na innych maszynach, jest deterministyczne. Sprawdzenie VirusTotal pod kątem hasha jest deterministyczne. Scalanie zduplikowanych incydentów z tego samego IP w tym samym dniu jest deterministyczne. Mapowanie zdarzenia na technikę MITRE na podstawie jego kategorii jest deterministyczne. Wszystko to pochłania czas analityków – i żadna z tych czynności nie wymaga ich oceny.

Elementy wymagające oceny – czy to zachowanie jest rzeczywiście złośliwe w kontekście biznesowym? Jaka jest właściwa reakcja biorąc pod uwagę krytyczność zasobu? – te nadal trafiają do ludzi, lecz z już skompletowanym kontekstem deterministycznym.

Praktyczna konsekwencja jest taka, że czas reagowania na incydenty skraca się nie dlatego, że analitycy pracują szybciej, lecz dlatego, że wchodzą do procesu na późniejszym, lepiej poinformowanym etapie. Powtarzalne prace zbierania danych nie są wykonywane szybciej – są wykonywane zanim ktokolwiek w ogóle zaczyna patrzeć.