Natywny Audyt Microsoftowy, dlaczego nie działa?

Przy włączonym pełnym audycie napotykamy problemy. Szczególnie jeżeli skoncentrujemy się na natywnej inspekcji logów:

1. Najzwyczajniej ciężko z natywnej inspekcji zdarzeń Security w logach Microsoft odczytywać niezbędne informacje, nie ma potrzebnych treści m.in. nie zawiera historii zmiany modyfikowanego atrybutu obiektu.

2. Natywna inspekcja zdarzeń Security jest konfigurowana przez „ADMINISTRATORA” (specjalnie napisane wersalikami, żeby podkreślić ważność roli) to On w większości przypadków zarządza w firmie systemami. Oprócz oczywistego w taki momencie pytania „Kto pilnuje zarządzającego?” pojawiają się inne wątpliwości. Co jeżeli atakujący przejmie konto administratora? Wtedy może sam wyłączyć inspekcję zdarzeń i wymazać po sobie ślady aktywności. Jak to zrobić pokazujemy tutaj.

3. W złożonych organizacjach inspekcja zdarzeń zajmuje bardzo dużo przestrzeni na dyskach (log bezpieczeństwa odkładany na kontrolerach domeny zajmuje 4 GB danych i zawiera logi z ostatnich 2 godzin pracy środowiska. Żeby ją przeanalizować, a nie daj panie Boże przechować trzeba użyć stwierdzając bardzo kolokwialnie „od cholery sprzętu”.

4. W natywnym audycie logów brak jest kontekstowości. Oznacza to tyle, że na podstawie wpisów w logach nie jesteśmy w stanie stwierdzić czy log dotyczy osoby uprzywiejowanej czy zwykłego konta. Nie możemy także swierdzić, pośredniego nadania uprawnień, na przykład poprzez przydzielenie do zagnieżdżonej grupy.

O alternatywie dla analizy audytu Microsoft opowiada Ekspert tutaj.