Zapytaliśmy specjalistę z firmy Appeal – Grzegorza Szafrańskiego:
Jak podejść do analizy logów Microsoftu, jaką mamy alternatywę dla natywnego audytu?
Taką alternatywą jest autorski mechanizm rejestrowania zmian. Technologia monitorująca logowania użytkowników polegająca na niskopoziomowej integracji bibliotek rozwiązania (agenta instalowanego na serwerze) z procesem lsass.exe odpowiadającym za uwierzytelnianie i wykonywanie zmian na Active Directory. Lsass.exe to skrót od Local Security Authority Service autorstwa Microsoft. Narzędzie to jest odpowiedzialne za politykę bezpieczeństwa i kierowanie innymi mechanizmami odpowiedzialnymi za bezpieczeństwo systemu Windows. Ponadto lsass.exe weryfikuje logowanie użytkownika i tworzy proces odpowiedzialny za potwierdzenie jego tożsamości (narzędzie Winlogon). Proces lsass.exe działa głównie dzięki możliwości tworzenia w systemie tokenów dostępu. Dzięki takiemu sposobowi monitorowania rozwiązanie jest niezależne od audytu Microsoft, może być w pełni zarządzane przez osoby nie posiadające dostępów administracyjnych do AD oraz przechwytywać wszelkiego typu ruch kierowany do domeny Active Directory.
Ten typ monitorowania dostępny jest w rozwiązaniu, które firma Appeal wdraża i kastomizuje pod potrzeby klientów. System ten możemy śmiało przyrównać do Firewalla dla Microsoft Active Directory, ponieważ stanowi on niezależną technologię monitorowania i zabezpieczania Active Directory. Na rynku istnieje kilka rozwiązań, które oferują narzędzia do monitorowania bezpieczeństwa usługi katalogowej Microsoft Active Directory oraz specjalistyczne rozwiązania klasy SIEM. Z większością tych narzędzi mieliśmy do czynienia i sprawdziliśmy ich skuteczność w laboratorium.
Duża część tych rozwiązań bazuje na technologii „parsowania” istniejących w systemie natywnych logów Microsoft (natywna inspekcja). W sytuacji wystąpienia ataków stają się one mało skuteczne, ponieważ̇ bazują na informacji wytworzonych przez system operacyjny.
Jak analizować logi?
W kontekście analizy logów, dobrze, aby system, który je analizuje lub tworzy własne zdarzenia był w stanie:
1. Wykorzystywać w swojej pracy elementy statystyki, czy wręcz uczenia maszynowego. Duża ilość zdarzeń, powiadomień, czy raportów z pewnością przytłaczałaby każdego administratora lub osobę zajmująca się bezpieczeństwem. W swojej pracy często spotykamy się, że skrzynkami takich osób przepełnione tysiącami alarmów które muszą być przeanalizowane, a które tak naprawdę nic nie wnoszą do bezpieczeństwa, lecz tylko zajmują nasz cenny czas. Wydobycie najbardziej istotnych zdarzeń z logów nie jest prostą sprawą, dlatego systemy uczenia się i analityka wspomagają znacznie przyspieszyć wynajdowanie źródła problemu i ograniczają duża ilość niepotrzebnych zdarzeń przy monitoringu (false positives).
2. Posiadał duża granularność w definiowaniu polityk do wykrywania zdarzeń oraz oferował możliwości filtrowania (eliminowania false positive, czyli oczywistych i niegroźnych zdarzeń). To sprawi, że pozbędziemy się milionów niepotrzebnych zdarzeń, tak jak ma to miejsce w przypadku natywnego audytu zdarzeń Microsoft. Wracając do natywnego audytu Microsoft i zdarzeń logowania użytkowników, to jest głównie największą bolączką przy analizie. Wiele zdarzeń, często nieudanych wynika z błędów w konfiguracji usług w środowisku, a także przypadłości audytu systemu Microsoft.
3. Czasami nie potrzebujemy audytować wszystkich operacji na obiektach w infrastrukturze. Wystarczy nam zdefiniowanie konkretnych obiektów czy scenariuszy, aby zrealizować konkretny cel/scenariusz w monitorowaniu bezpieczeństwa.
4. Integrował się z innymi rozwiązaniami do analizy logów lub bezpieczeństwa w firmie np. SIEM oraz był w stanie inteligentnie rozpoznawać zasoby, które audytuje np. wrażliwe pliki, konta administracyjne. Pomoże nam to w wychwyceniu kontekstowości zdarzenia i jego tak zwanego score’ingu.
5. Posiadał możliwości prewencyjnej ochrony przed atakiem/zmianą – w sytuacji, kiedy konkretna aktywność na koncie użytkownika jest przez nas niechciana np. logowanie konta administratora domeny na stację robocze, dostęp do danych wrażliwych lub zmiana polityki GPO, czy krytycznej grupy chcielibyśmy, aby dana operacja była natychmiast zablokowana jeszcze przed możliwością fizycznego wykonania aktywności. Taka ochrona niezależna od mechanizmów skryptów spowoduje, że będziemy bardziej bezpieczni i będziemy w stanie od razu zareagować na złamanie polityki bezpieczeństwa w firmie.
Jaki zatem system jest najbardziej odpowiedni?
Przy wyborze systemu do analizy logów powinniśmy kierować się przede wszystkim możliwościami jakie on oferuje w kontekście rozszerzenia natywnego audytu Microsoft, ponieważ jak się okazuje i potrafimy to udowodnić, natywny audyt potrafi być zawodny i nie zagwarantuje nam kompletności informacji i wymagań jakie potrzebujemy dla Działu Bezpieczeństwa.
Również powinniśmy rozważyć takie kwestie w systemie, aby mógł nam załatwić problem zasady podwójnego zaufania – „Ufaj i kontroluj”, czyli kontrolowanie osób, które mogą wszystko kontrolować, w tym definiować i zmieniać audyt (czyli administratorów). Jeśli nie mamy odpowiednich informacji ze środowiska, to jak będziemy w stanie je poprawnie pilnować?
W naszych wdrożeniach firmy Appeal staramy się pogodzić ze sobą te dwa światy (logów natywnych oraz rozszerzonych) i dostarczyć klientom jedną platformę do ich analizy. Tylko takie połączenie dostarczy nam autentyczność, rozliczalność, niezaprzeczalność i niezawodność, czyli podwaliny bezpieczeństwa informacji.
O słabościach natywnych logów pisaliśmy także w artykułach: DCShadow i o manipulacji logów.