zmęczenie alertami

Zmęczenie alertami (alert fatigue) to spadek czujności osób obsługujących monitoring, wywołany nadmiarem alertów, z których większość okazuje się nieistotna albo fałszywa. Skutkiem jest przeoczenie zdarzeń naprawdę ważnych. Podręcznik Google o inżynierii niezawodności opisuje to tak: gdy powiadomienia przychodzą zbyt często, pracownicy je podważają, przeglądają pobieżnie albo ignorują, czasem pomijając także prawdziwy alarm ukryty w szumie ^[1]. Zjawisko dotyczy zarówno dużych zespołów SOC (Security Operations Center), jak i właściciela jednej strony, który dostaje kilkanaście maili dziennie od wtyczki.

Jak działa

Mechanizm jest prosty. Każdy alert wymaga uwagi. Gdy większość z nich nie prowadzi do żadnego działania, odbiorca uczy się, że alerty można pomijać. Autor rozdziału o monitoringu w podręczniku Google pisze, że z poczuciem pilności może zareagować tylko kilka razy dziennie, zanim się zmęczy ^[1].

Schemat poniżej pokazuje, jak nadmiar alertów sam się wzmacnia.

RYS. 1Spirala zmęczenia alertami

Kapitan Hack wiąże to zjawisko z pracą centrów operacji bezpieczeństwa: nadmiar zdarzeń wymagających więcej wysiłku, niż pozwala potencjał operatorów i analityków, prowadzi do zmęczenia i osłabienia czujności ^[4].

Przyczyny

Najczęstsze źródła nadmiaru alertów opisują polskie serwisy branżowe.

Niebezpiecznik, omawiając obronę przed phishingiem w środowisku Microsoftu, zwraca uwagę, że rozpatrywanie kolejnych etapów ataku osobno prowadzi do zduplikowania alertów, a w konsekwencji do tzw. alert fatigue ^[2]. Kapitan Hack pisze z kolei, że alerty generowane przez SIEM mogą z łatwością przytłoczyć zespół bezpieczeństwa, a problemem jest zmęczenie alertami o niskim priorytecie ^[3].

W WordPressie

Właściciel strony na WordPressie rzadko ma zespół SOC, ale zmęczenie alertami dotyka go tak samo. Źródłem są zwykle powiadomienia e-mail z rdzenia i wtyczek.

Maile o aktualizacjach. Rdzeń wysyła wiadomości po automatycznych aktualizacjach w tle. Filtr auto_core_update_send_email decyduje, czy wysłać e-mail po automatycznej aktualizacji rdzenia; typ wyniku może mieć wartość success, fail, critical albo manual ^[5]. Filtr istnieje od wersji 3.7.0 ^[5]. Analogiczny filtr auto_plugin_update_send_email dotyczy automatycznych aktualizacji wtyczek i istnieje od wersji 5.5.0 ^[6]. Pozwala to zostawić tylko wiadomości o błędach, które wymagają reakcji.

// mu-plugin: mail o aktualizacji rdzenia tylko przy błędzie
add_filter( 'auto_core_update_send_email', function ( $send, $type ) {
    return in_array( $type, array( 'fail', 'critical' ), true );
}, 10, 2 );

Powiadomienia wtyczek bezpieczeństwa. Wtyczki bezpieczeństwa potrafią wysyłać wiadomość przy każdej zablokowanej próbie logowania. Podczas ataku siłowego oznacza to dziesiątki maili, które nie wymagają działania, bo limit prób logowania już zadziałał. Bardziej przydatne są powiadomienia o zdarzeniach, które wymagają decyzji człowieka, na przykład o nowym koncie administratora albo zmianie pliku rdzenia.

Wiele stron naraz. Agencja, która obsługuje dziesiątki witryn, dostaje ten sam typ alertu z każdej z nich. Bez grupowania i ustalania priorytetów, czyli triażu, ważny sygnał z jednej strony ginie wśród rutynowych komunikatów z pozostałych.

Zagrożenia i skutki

Najpoważniejszym skutkiem jest przeoczenie prawdziwego ataku. Prawdziwy alarm może zostać zignorowany, bo ginie w szumie ^[1]. Zmęczenie alertami wydłuża więc czas przebywania atakującego w sieci i opóźnia reagowanie na incydenty.

Drugim skutkiem jest wyłączanie alertów w całości. Odbiorca, który ma dość wiadomości, kasuje regułę albo przekierowuje maile do folderu, którego nie czyta. Traci wtedy także te sygnały, które były wartościowe.

Pokrewnym zjawiskiem jest MFA fatigue. Tam napastnik celowo zasypuje ofiarę prośbami o zatwierdzenie logowania, licząc, że w końcu kliknie „zatwierdź”. Mechanizm psychologiczny jest podobny: nadmiar powiadomień obniża uwagę.

Jak ograniczać

Podręcznik Google formułuje kilka zasad dla alertów kierowanych do ludzi.

• Każde powiadomienie powinno prowadzić do działania ^[1].
• Reakcja na powiadomienie powinna wymagać namysłu; jeśli wystarcza reakcja mechaniczna, nie powinno to być powiadomienie ^[1].
• Powiadomienia wymagające rutynowej, algorytmicznej reakcji są sygnałem ostrzegawczym ^[1]; takie reakcje lepiej zautomatyzować, na przykład w SOAR (Security Orchestration, Automation and Response).
• Reguły generujące alerty dla ludzi powinny być proste i opisywać wyraźną awarię ^[1].

Kapitan Hack zaleca, by alert zawierał od razu kontekst potrzebny do oceny: cel reguły, powiązane techniki MITRE ATT&CK, pola logu odpowiadające na pytania kto, co, gdzie, kiedy i jak, reputację adresów i plików oraz odnośnik do playbooka ^[4]. Jeśli jakaś informacja jest potrzebna do rozstrzygnięcia, czy zdarzenie jest złośliwe, powinna być w alercie albo łatwo dostępna ^[4].

Niebezpiecznik wskazuje na korelację: etapy jednego ataku widoczne w różnych źródłach danych warto łączyć w jeden incydent zamiast mnożyć alerty ^[2]. Stałe strojenie reguł, usuwanie tych, które nie dają wartości, i pomiar odsetka fałszywych alarmów to zadania, którymi zajmuje się detection engineering.

W praktyce pomaga też podział alertów na poziomy. Zdarzenia wymagające natychmiastowej reakcji trafiają do osoby dyżurnej, zdarzenia ważne, ale niepilne, do kolejki przeglądanej raz dziennie, a informacje statystyczne do raportu okresowego. Taki podział sprawia, że pilny kanał pozostaje rzadki, a więc wiarygodny. Na małej stronie WordPress może to oznaczać osobny adres e-mail tylko na alerty krytyczne, na przykład o zmianie pliku rdzenia albo nowym koncie administratora, i zbiorczy raport tygodniowy dla całej reszty.