Dzienniki zdarzeń zawierają zwykle informację o incydencie na długo przed jego skutkami. Problem w tym, że nikt ich nie czyta — bo jest ich za dużo.
Co warto zbierać
- logowania, zwłaszcza nieudane i z nietypowych miejsc,
- zmiany uprawnień i tworzenie kont,
- dostęp do danych wrażliwych,
- zdarzenia z systemów bezpieczeństwa,
- błędy aplikacji krytycznych.
Reszta zdarzeń może zostać na maszynach źródłowych. Zbieranie wszystkiego centralnie kosztuje miejsce i czas przeszukiwania, a rzadko zmienia wynik. Lepiej zebrać pięć rodzajów zdarzeń przez rok niż wszystkie przez dwa tygodnie.
Wzorce warte zgłoszenia
Seria nieudanych logowań zakończona udanym. Logowanie z dwóch odległych miejsc w krótkim czasie. Aktywność konta poza godzinami pracy. Masowe pobieranie plików. Nowe konto z wysokimi uprawnieniami.
Do tej listy warto dopisać kilka zdarzeń typowych dla przejęcia skrzynki: założenie reguły przekierowującej pocztę na zewnątrz, wyłączenie drugiego składnika uwierzytelnienia, dodanie nowego urządzenia do konta, zmiana adresu odzyskiwania. To są czynności, które napastnik wykonuje zaraz po wejściu, żeby utrzymać dostęp również po zmianie hasła.
Punkt odniesienia
Anomalia jest odchyleniem od normy, więc normę trzeba najpierw poznać. Reguły ustawione bez okresu obserwacji generują fałszywe alarmy, które szybko uczą wszystkich ignorowania.
W praktyce oznacza to kilka tygodni zbierania danych bez włączonych powiadomień i przejrzenie tego, co się w nich pojawia. Handlowiec logujący się z hotelu, księgowa pracująca wieczorami przy zamknięciu miesiąca i serwis dostawcy wchodzący zdalnie raz w miesiącu to zachowania normalne w tej firmie, choć w regułach domyślnych wyglądają na incydent.
Ile przechowywać
Incydenty bywają wykrywane po tygodniach. Dzienniki kasowane po kilku dniach uniemożliwiają ustalenie, co się stało — a to zwykle ważniejsze od samego wykrycia.
Rozsądny kompromis to krótszy okres dla wszystkiego i znacznie dłuższy dla zdarzeń związanych z logowaniem i uprawnieniami. Retencję warto ustawić świadomie, bo dzienniki zawierają dane osobowe i trzymanie ich bezterminowo też jest decyzją, tylko podjętą przez zaniechanie.
Ochrona dzienników
Logi trzymane wyłącznie na maszynie, której dotyczą, zostaną skasowane razem z nią. Kopia w osobnym miejscu jest warunkiem ich użyteczności.
Miejsce docelowe powinno przyjmować zapisy, ale nie pozwalać ich zmieniać ani usuwać z konta, które je wysyła. Czyszczenie dzienników jest jedną z pierwszych czynności po włamaniu, więc dziennik dostępny do skasowania z zaatakowanego serwera nie jest dowodem niczego.
Co zrobić z tym, co się znajdzie
Sam alert nie kończy sprawy. Do każdego wzorca warto z góry przypisać pierwszy krok: zablokować konto, potwierdzić telefonicznie u użytkownika, sprawdzić reguły skrzynki. Kolejnym krokiem jest zwykle wymiana danych dostępowych zgodnie z procedurą przyjętą przy zarządzaniu hasłami i sprawdzenie, czy przy okazji nie zmieniły się uprawnienia kont.
Kiedy nie warto budować własnego rozwiązania
Przy kilku usługach w chmurze i jednym serwerze osobna platforma do analizy dzienników bywa nadmiarem — sama wymaga utrzymania i miejsca. Panele administracyjne usług mają wbudowane raporty logowań i alerty, które wystarczy włączyć i skierować do właściwej osoby. Własne rozwiązanie zaczyna być potrzebne tam, gdzie zdarzenia trzeba zestawiać z kilku źródeł naraz.
