Jak ogarnąć logi?

Wiele systemów i urządzeń tworzy dzienniki zdarzeń, jednak mało kto je analizuje. A logi to kopalnia wiedzy. Jak zarządzać logami, by nie przeoczyć ważnych zdarzeń z punktu widzenia bezpieczeństwa naszej sieci?

Jest wiele komercyjnych programów i platform automatyzujących analizę logów. Test kilku z nich opublikujemy w jednym z kolejnych numerów "Networlda". Tym razem radzimy, jak poradzić sobie z logami, mając na to bardzo mały budżet.

Ignorowanie logów jest częstym błędem, jednak dość łatwo wytłumaczyć, dlaczego się go popełnia. Analiza logów rzadko jest priorytetem kadry zarządzającej, a staje się ważna, gdy wytknie to audyt bezpieczeństwa, bądź już po poważnym incydencie, którego można było uniknąć.

Dzienniki zdarzeń składają się głównie z mało interesujących wpisów. Większość logów zawiera wyłącznie "szum", i poza rzadkimi wyjątkami nie ma w nich nic ciekawego. Niestety, incydenty związane z bezpieczeństwem zdarzają się, a ślady po nich zwykle pojawiają się właśnie w logach. Czasami, dzięki analizie dzienników zdarzeń, możemy dowiedzieć się o problemach z naszą infrastrukturą, które niekoniecznie muszą wynikać z ataków napastników czy złośliwego kodu. Informacje zawarte w logach mogą także pozwolić na usunięcie błędów konfiguracyjnych czy optymalizację systemu.

Gromadzenie logów

Nie da się ukryć, że kluczem do sukcesu będzie automatyzacja procesu analizy logów - doświadczenie uczy, że jeśli coś nie odbywa się automatycznie, to po jakimś czasie nie jest wykonywane wcale. Idealny system zarządzania incydentami bezpieczeństwa (warto tu zapamiętać pojawiające się w anglojęzycznej literaturze skróty SIM, SEM, SIEM) powinien zajmować się: zbieraniem, filtrowaniem i analizą danych, oceną priorytetów i w miarę potrzeby powiadamiać administratora albo wyzwalać zdefiniowane wcześniej przez niego skrypty.

Jak ogarnąć logi?

Logparser Lizard graficzna nakładka na Logparser uprości nieco wydobywanie logów i pozwala na graficzną prezentację statystyk

Wśród codziennych obowiązków administratora trudne może okazać się znalezienie czasu na wpatrywanie się w raport zdarzeń i decydowanie, którymi z nich należy się zająć.

Większość wpisów nie jest istotna i nie wymaga ani powiadomienia administratora, ani tym bardziej podejmowania akcji naprawczej, jednak powinny one być przechowywane na potrzeby ewentualnej analizy po jakimś incydencie. Tu pojawia się pytanie, gdzie przechowywać takie zdarzenia i kiedy je filtrować?

Zgodnie z jedną z teorii wszystkie zdarzenia (bez względu na to, jakie jest ich znaczenie z punktu widzenia bezpieczeństwa sieci) powinny być zebrane w jednym miejscu. Jeśli zajdzie potrzeba przeprowadzenia gruntownego śledztwa, łatwo będzie sięgnąć po wszystkie dane.

Niestety, w dużych sieciach rozmiar dziennych logów sięga gigabajtów. Próba umieszczenia wszystkich danych w jednym miejscu obciąży sieć i zajmowałyby one terabajty przestrzeni dyskowej.

Innym podejściem będzie wstępne filtrowanie nieistotnych zdarzeń i gromadzenie tylko tych o średnim i wysokim znaczeniu, i np. dobieranie tych mniej istotnych dopiero, jeśli zajdzie taka potrzeba.


TOP 200