Wysyłaj Windows Event Log do Sophos XDR i SIEM

Microsoft Windows Event Log można wysyłać obsługiwanym forwarderem w formacie Snare-over-syslog do Sophos XDR Data Collector. Jest to osobna ścieżka obok agenta Sophos Endpoint. Lokalna Event ID ani zielony stan Endpoint nie dowodzą odbioru przez tę integrację.

Należy wdrożyć kolektor, określić zdarzenia i audyt Windows, skierować forwarder z prawidłowym formatem na UDP/514 i potwierdzić konkretne zdarzenie w Sophos.

Określić zakres i licencje przed wdrożeniem

Zależnie od faktycznie przesyłanych zdarzeń integracja może odbierać uwierzytelnianie, zmiany kont/grup, procesy, wykrycia Defender, zmiany administracyjne, audyty katalogu i inne zdarzenia. Schematy to auth, process, antivirus, managementevent, cloudaudit, thirdpartyalert, encrypt i netflow.

Wymóg SIEM dotyczy telemetrii netflow, np. zdarzeń połączeń Windows Filtering Platform, takich jak 5156. Nie czyni wszystkich pozostałych wymienionych zdarzeń wyłącznymi dla SIEM. Tenant XDR/MDR musi jednak mieć wymagane uprawnienia licencyjne integracji i źródła. SIEM oraz przewodnik integracji omawiają sprawdzenie.

Przygotować kolektor, forwarder i ochronę danych

Wymagane są działający XDR Data Collector, zatwierdzona trasa z Windows i oprogramowanie wysyłające Snare-over-syslog. Sophos wymienia Snare Enterprise, NXLog Enterprise, TIBCO Universal Collector, Syslog-ng Agent for Windows i NXLog Community Edition. Nie oznacza to identycznych pól, licencji ani plików konfiguracji.

Runbook kolektora opisuje zasoby, DNS, czas i uplinki. Tutaj dopuszcza się przychodzący UDP/514 tylko z przewidzianych sieci Windows. UDP nie potwierdza każdego komunikatu, dlatego test sieci lub portu nie zastępuje dowodu zdarzenia.

Przed konfiguracją zapisać komputery lub kontrolery domeny, wymagane Event IDs, istniejący audyt, odpowiedzialny zespół i starą trasę. Zdarzenia mogą zawierać użytkowników, ścieżki i argumenty procesów. Zbierać tylko zatwierdzony zakres i nie kopiować surowych logów ani danych dostępowych do publicznych zgłoszeń.

Skonfigurować przekazywanie Windows

1. W prawidłowym tenancie wskazać kolektor pod Security Operations > Integrations > Data Collectors. Użyć IP osiągalnego z Windows, nie regionalnego adresu przesyłania Sophos ani innej appliance.
2. Wdrożyć wybrany forwarder na zatwierdzonym komputerze pilota zgodnie z jego instrukcją. Zachować poprzednią konfigurację i ustalić pozostałe wyjścia przed zmianą wspólnego pliku.
3. Jawnie ustawić Snare-over-syslog. Sophos wymaga tego formatu; dowolny JSON, CEF czy Windows Event XML nie są potwierdzonym zamiennikiem.
4. Wpisać rzeczywiste IP kolektora oraz port UDP 514. Kanały i filtry muszą obejmować potrzebne zdarzenia.
5. Wysyłać czas źródłowy w UTC i sprawdzić synchronizację Windows. Lokalny widok Event Viewer nie dowodzi, jaką strefę przesyła forwarder.
6. Włączyć konfigurację i sprawdzić lokalne błędy. Wykonać poniższe porównanie przed dołączeniem dalszych komputerów.

Dla NXLog CE pobierz udostępniony przez Sophos szablon konfiguracji nxlog_wel.txt. Jest to punkt wyjścia dla udokumentowanego formatu Snare, a nie niezweryfikowany zamiennik każdej istniejącej konfiguracji NXLog. Cel Collectora, wybrane zdarzenia i istniejące wyjścia muszą odpowiadać środowisku.

Aktualnie podlinkowany szablon ustawia define PORT 601 i w bloku MSWINEVENTLOGOUT używa Module om_tcp; bez zmian nie nadaje się zatem do opisanej tu ścieżki UDP/514. Dla tej ścieżki:

1. W define XDR A.B.C.D zastąp tylko symbol zastępczy A.B.C.D rzeczywistym adresem IP Collectora; zachowaj define XDR.
2. Ustaw wiersz portu na define PORT 514.
3. W bloku wyjściowym MSWINEVENTLOGOUT zakomentuj wiersz Module om_tcp i włącz istniejący wiersz Module om_udp. W tym bloku pozostaw aktywny tylko jeden moduł wyjściowy; pozostałe istniejące wyjścia zachowaj osobno.

Następnie sprawdź składnię i dostarczanie zdarzeń w pilotażu. Sophos oferuje pomoc best effort; bardziej zaawansowane problemy forwardera należą do jego dostawcy.

Wiersz polecenia procesu w zdarzeniu 4688

Niektóre detekcje wymagają pól, których Windows domyślnie nie zapisuje. Aby do tworzenia procesu, zdarzenia 4688, dołączyć wiersz polecenia, Sophos wskazuje policy Windows:

Administrative Templates > System > Audit Process Creation > Include command line in process creation events

Włączyć tylko dla zatwierdzonego zakresu po ocenie zawartości. Argumenty mogą zawierać dane wrażliwe. Ustawienie nie zastępuje generowania wymaganych zdarzeń audytu procesów ani filtra 4688 forwardera.

Do sprawdzenia uruchomić zatwierdzony nieszkodliwy proces bez sekretów w argumentach. Najpierw potwierdzić oczekiwany wiersz polecenia w Windows 4688, potem porównać znormalizowany process w Sophos. Kolektor nie odtworzy pola, którego nie było u źródła.

Potwierdzić odbiór zdarzeniem źródłowym

Pierwszym testem może być zatwierdzone logowanie na dedykowanym koncie testowym. 4624 i 4625 potwierdzają odpowiednio sukces lub błąd uwierzytelniania. Celowe wywołanie błędu nie może spowodować blokady konta. Używać tylko zdarzeń rzeczywiście powstających w wybranym zakresie audytu i przekazywania.

1. W logu Windows zapisać Event ID, komputer, użytkownika, wynik i czas. W protokole zachować tylko oczyszczone wartości.
2. Sprawdzić, czy forwarder emituje kategorię bez lokalnych błędów formatu, uprawnień lub połączenia.
3. W odpowiednim tenancie Sophos sprawdzić strumień źródła i rekord w oczekiwanym schemacie. Porównać komputer, czas, użytkownika i wynik z Windows. Dla logowania oczekuje się auth, dla 4688 process.
4. Powtórzyć dla innych wymaganych kategorii. Login nie dowodzi odbioru Defender, audytów katalogowych ani netflow.
5. Porównać nowe rekordy przez odpowiedni okres i zapisać zakres, właściciela oraz następny przegląd w odbiorze.

Zdarzenie nie musi tworzyć detection ani case MDR. Dzisiejszy poprawny odbiór nie dowodzi historycznej kompletności ani gwarantowanej retencji wszystkich danych. Licencje i przechowywanie sprawdza się osobno.

Szukać brakujących pól i luk

Brak zdarzenia Windows: najpierw sprawdzić audyt, kanał i rzeczywistą aktywność. Bez zdarzenia źródłowego nie ma czego przesłać.

Źródło ma zdarzenie, Sophos nie pokazuje danych: porównać filtry, Snare-over-syslog, UTC, IP i UDP/514. Następnie sprawdzić kolektor i przepływ we właściwym okresie. Nie dodawać zapobiegawczo drugiego forwardera do tego samego strumienia.

Zdarzenie jest, brak wymaganego pola: porównać oryginał Windows, wyjście forwardera i znormalizowany rekord. Dla argumentów sprawdzić 4688 i zatwierdzoną policy. Nie wymyślać wartości domyślnej.

Brakuje tylko netflow: osobno sprawdzić Windows Filtering Platform, wybór zdarzeń i entitlement SIEM. Działający login nie potwierdza tego dodatkowego zakresu.

Wycofać pilota lub przekazać do eksploatacji

Dla rollbacku zatrzymać tylko nowe wyjście lub filtr pilota i w kontrolowany sposób przywrócić zapisaną konfigurację. Zachować inne wyjścia i wspólne kolektory. Policy audytu cofnąć wyłącznie po porównaniu z udokumentowanym stanem początkowym i zatwierdzeniu; inne wymagania bezpieczeństwa lub dowodowe mogą od niej zależeć.

Następnie potwierdzić działanie starej potrzebnej trasy i brak niezamierzonych duplikatów. Zatrzymanie forwardera nie odzyskuje utraconych zdarzeń UDP ani nie dowodzi usunięcia wysłanej telemetrii. W eksploatacji wskazany zespół odpowiada za zakres, czas, przepływ, zmiany szablonów i aktualizacje forwardera.