Administratorzy często rozpoczynają zarządzanie logami od wytypowania wszystkich zdarzeń, które ich zdaniem mogą się przydać, określając następnie, które z nich powinny wyzwalać alerty wymagające interwencji. Ogromne ilości danych lądują w centralnym systemie zarządzania zdarzeniami i ... na ogół rzadko ktoś tam zagląda (jeśli w ogóle). Mało kto reaguje też na zbyt częste i niepotrzebne generowane przez system alerty.

Polecamy Bezpieczne biurko

Nadmiar informacji podobny do tego, jakim zasypuje nas przeciętny firewall, zniechęca do zagłębiania się w taki zbiór danych. Mało kto wczytuje się w logi zapory ogniowej - przecież prawie w całości składają się na nie wpisy niewymagające podjęcia żadnej akcji. Logi rejestrują przede wszystkim nieszkodliwy ruch, taki jak np. rozgłoszenia sieci. Znajdują się w nich też pakiety świadczące o skanowaniu portów, ale śledzenie takich przypadków pochłonęłoby zbyt wiele zasobów, by było warte zachodu. Logi mogą jednak zawierać wpisy o krytycznym znaczeniu, które giną w morzu tych mało istotnych. Jeśli nie zaglądamy do logów, bądź nie tworzymy na ich bazie zdarzeń wymagających interwencji, po co w ogóle je gromadzić?

Sposób na logi

Zajmujący się profesjonalnie bezpieczeństwem Roger Grimes radzi byśmy spróbowali pokusić się o system, który będzie zbierał tylko to, co naprawdę istotne. Zacznijmy od gromadzenia tylko tych zdarzeń, które wymagają interwencji administratora. Jeśli reakcja specjalisty na jakieś zdarzenie nie będzie potrzebna, nie generujmy go. W ten sposób pozbędziemy się szumu.

Polecamy Jak ogarnąć logi?

Kluczem do sukcesu jest wytypowanie tych zdarzeń, co do których jesteśmy pewni, że są anomaliami.