Przebieg triage alertów

Wstępna analiza alertów to proces przeglądania przychodzących alertów, ustalania, które z nich są rzeczywiste i istotne, oraz odpowiedniego kierowania ich dalej. Celem jest szybkie oddzielenie sygnału od szumu.

Każdy alert trafia do jednej z trzech kategorii:

• Prawdziwie dodatni — rzeczywista złośliwa lub ryzykowna aktywność
• Fałszywie dodatni — nieszkodliwa aktywność, która wygląda podejrzanie
• Łagodny prawdziwie dodatni — rzeczywista, ale autoryzowana lub oczekiwana aktywność

Alert przechodzi przez przewidywalny cykl życia. Znajomość każdego etapu pomaga zachować porządek pracy:

• Nowy — właśnie wygenerowany przez SIEM lub EDR
• W toku — analityk prowadzi analizę
• Eskalowany — przekazany do zespołu Tier 2 lub reagowania na incydenty
• Zamknięty — rozwiązany jako fałszywie dodatni, nieszkodliwy lub usunięty

Każde przejście powinno być odzwierciedlone w zgłoszeniu, aby inni mogli od razu zobaczyć jego stan.

Najpierw należy dokładnie ustalić, co zostało uruchomione. Proszę odczytać regułę detekcji oraz leżące u jej podstaw surowe zdarzenie. Należy zadać sobie pytania:

• Jaka reguła została uruchomiona i co właściwie wykrywa?
• Jakie host, użytkownik i proces są zaangażowane?
• Jaki jest znacznik czasu oraz źródłowy adres IP i adres docelowy?

Typowy ładunek alertu zawiera najważniejsze punkty, od których można rozpocząć dalszą analizę:

Surowy alert rzadko przedstawia pełny obraz sytuacji. Wzbogacanie dodaje kontekst pomagający ocenić ważność zdarzenia:

• Kontekst zasobu — czy jest to serwer, laptop programisty czy kontroler domeny?
• Kontekst użytkownika — czy konto ma podwyższone uprawnienia? Czy użytkownik przebywa na urlopie?
• Informacje o zagrożeniach — czy adres IP, domena lub skrót są znane jako złośliwe?
• Historyczny punkt odniesienia — czy ten host robił już coś takiego?

Logowanie z konta administratora systemów to zupełnie inna sytuacja niż takie samo logowanie do bazy danych o krytycznym znaczeniu.

Wskaźniki naruszenia bezpieczeństwa (IOC), takie jak adresy IP, domeny, adresy URL i skróty plików, należy sprawdzać w źródłach reputacyjnych i bazach informacji o zagrożeniach.

Przydatne zapytania podczas wstępnej analizy:

Pojedyncze zdarzenia rzadko potwierdzają incydent. Pivotowanie oznacza podążanie za jednym wskaźnikiem w celu znalezienia powiązanej aktywności.

Od podejrzanego procesu należy przejść do:

• Innych procesów uruchomionych przez ten sam proces nadrzędny
• Połączeń sieciowych wykonanych przez ten host mniej więcej w tym samym czasie
• Innych hostów, które łączyły się z tym samym docelowym adresem IP
• Zdarzeń uwierzytelniania dotyczących zaangażowanego użytkownika

Budowanie tej osi czasu pozwala przekształcić pojedynczy alert w jasny obraz ataku.

Nie wszystkie prawdziwie dodatnie alerty są równie pilne. Priorytety należy ustalać według dwóch osi: wpływu i pewności.

• Duży wpływ + duża pewność — należy natychmiast eskalować, na przykład ransomware na serwerze
• Duży wpływ + mała pewność — należy szybko przeprowadzić analizę w celu potwierdzenia
• Mały wpływ — należy obsłużyć alert zgodnie z kolejnością w kolejce

O wpływie decydują krytyczność zasobu i zakres oddziaływania. Naruszony kontroler domeny ma wyższy priorytet niż alert dotyczący spamu u pojedynczego użytkownika.

Struktura MITRE ATT&CK zawiera katalog taktyk i technik przeciwników. Mapowanie alertu do ATT&CK pomaga ocenić, który etap ataku jest obserwowany i co może nastąpić dalej.

Na przykład zakodowane polecenie PowerShell można zmapować jako:

• Taktyka: Wykonanie
• Technika: T1059.001 (PowerShell)

Jeśli widzą Państwo również techniki Utrzymania dostępu lub Ruchu bocznego, zagrożenie się rozwija, a pilność rośnie.

Większość alertów jest fałszywie dodatnia. Proszę poznać typowe przypadki, aby móc je z przekonaniem odrzucać:

• Narzędzia administratorów IT naśladujące zachowanie atakującego, takie jak PsExec i skrypty
• Skanery podatności wywołujące alerty sieciowe
• Zadania tworzenia kopii zapasowych powodujące duże transfery danych
• Programiści uruchamiający zakodowane lub zaciemnione skrypty testowe

Po potwierdzeniu powtarzającego się fałszywie dodatniego alertu należy zalecić zmianę dostrojenia, aby przestał generować szum.

Niezależnie od tego, czy alert zostanie zamknięty, czy eskalowany, należy dokładnie udokumentować ustalenia. Dobre notatki pozwalają kolejnemu analitykowi natychmiast przejąć pracę i chronią Państwa podczas audytów.

Rzetelna notatka z wstępnej analizy zawiera:

• Informację, czego dotyczył alert i dlaczego został uruchomiony
• Opis przeprowadzonych kontroli oraz dowody, wraz ze znacznikami czasu i IOC
• Wniosek i klasyfikację alertu
• Wszelkie zalecane dalsze działania lub dostrojenie

Niejasne notatki w rodzaju „wygląda dobrze, zamknięto” są bezużyteczne i niebezpieczne.

Należy eskalować alert do zespołu Tier 2 lub reagowania na incydenty, gdy jest on potwierdzonym albo prawdopodobnym prawdziwie dodatnim alertem o rzeczywistym wpływie. Przy wysokiej stawce nie należy ignorować niepewności.

Należy natychmiast eskalować w przypadku:

• Potwierdzonego uruchomienia złośliwego oprogramowania lub aktywnego ruchu C2
• Przejęcia konta z podwyższonymi uprawnieniami
• Oznak ruchu bocznego lub eksfiltracji danych
• Wszelkich zdarzeń dotyczących krytycznego zasobu

W razie wątpliwości dotyczących alertu o dużym wpływie należy go eskalować. Nadmierna eskalacja incydentu SEV1 jest bezpieczniejsza niż przeoczenie takiego incydentu.

Proszę sprawdzić swoje umiejętności ustalania priorytetów podczas wstępnej analizy.

Prześledzili Państwo proces wstępnej analizy alertu:

• Wstępna analiza dzieli alerty na prawdziwie dodatnie, fałszywie dodatnie i łagodne prawdziwie dodatnie
• Należy odczytać alert, a następnie wzbogacić go o kontekst zasobu, użytkownika i informacji o zagrożeniach
• Należy pivotować między danymi, aby zbudować oś czasu i potwierdzić zakres incydentu
• Priorytety należy ustalać według wpływu i pewności, a aktywność mapować do MITRE ATT&CK

Następnie dowiedzą się Państwo, jak playbooki i system zgłoszeń sprawiają, że ten proces można powtarzalnie stosować.