Inviare Windows Event Log a Sophos XDR e SIEM

Microsoft Windows Event Log può essere inviato tramite un forwarder supportato in formato Snare-over-syslog a un Sophos XDR Data Collector. È un percorso distinto dall’agente Sophos Endpoint: né una Event ID locale né lo stato Endpoint verde provano l’acquisizione tramite questa integrazione.

Il percorso consiste nel predisporre il collector, definire eventi e audit Windows, indirizzare il forwarder con formato corretto a UDP/514 e verificare un evento specifico in Sophos.

Chiarire perimetro e licenze prima del deployment

A seconda degli eventi realmente inoltrati, l’integrazione può acquisire autenticazioni, modifiche account/gruppi, processi, rilevamenti Defender, cambiamenti amministrativi, audit directory e altri eventi. Gli schemi documentati sono auth, process, antivirus, managementevent, cloudaudit, thirdpartyalert, encrypt e netflow.

Il requisito SIEM riguarda la telemetria netflow, ad esempio connessioni Windows Filtering Platform come l’evento 5156. Non rende obbligatorio SIEM per tutti gli altri eventi Windows elencati. Devono comunque esistere gli entitlement di sorgente e integrazione richiesti dal tenant XDR/MDR. La guida SIEM e la guida alle integrazioni spiegano questa verifica.

Preparare collector, forwarder e protezione dati

Servono un XDR Data Collector operativo, un percorso autorizzato dalle sorgenti Windows e software che emetta Snare-over-syslog. Sophos cita Snare Enterprise, NXLog Enterprise, TIBCO Universal Collector, Syslog-ng Agent for Windows e NXLog Community Edition. Non significa che condividano campi, licenze e file di configurazione.

Il runbook del collector tratta risorse, DNS, ora e uplink. Qui consentire UDP/514 in ingresso solo dalle reti Windows previste. UDP non conferma ogni messaggio: un test di rete o porta non sostituisce la prova dell’evento.

Prima della configurazione documentare computer o domain controller sorgenti, Event IDs richieste, audit esistente, team responsabile e percorso precedente. Gli eventi possono contenere utenti, percorsi e argomenti di processo. Limitare i dati al perimetro autorizzato e non copiare log grezzi o credenziali in ticket pubblici.

Configurare l’inoltro Windows

1. Nel tenant corretto identificare il collector in Security Operations > Integrations > Data Collectors. Usare l’IP raggiungibile da Windows, non un indirizzo regionale di upload Sophos o quello di un’altra appliance.
2. Installare il forwarder scelto su un computer pilot autorizzato seguendo il suo manuale. Salvare la configurazione esistente e identificare altre uscite prima di cambiare un file condiviso.
3. Selezionare espressamente Snare-over-syslog. Sophos richiede questo formato; JSON arbitrario, CEF o XML Windows Event non sono sostituti confermati per questo percorso.
4. Impostare IP reale del collector e porta UDP 514. Canali e filtri devono includere gli eventi necessari.
5. Emettere i timestamp in UTC e controllare la sincronizzazione Windows. La visualizzazione locale di Event Viewer non prova il fuso effettivamente trasmesso.
6. Attivare la configurazione e controllare errori locali del forwarder. Completare il confronto degli eventi seguente prima di estendere ad altri computer.

Per NXLog CE, scaricare il modello di configurazione nxlog_wel.txt fornito da Sophos. Questo modello è un punto di partenza per il formato Snare documentato, non un sostituto non verificato di qualunque configurazione NXLog esistente. La destinazione del Collector, gli eventi selezionati e le uscite esistenti devono adattarsi all’ambiente.

Il modello attualmente collegato imposta define PORT 601 e, nel blocco MSWINEVENTLOGOUT, usa Module om_tcp; non è quindi adatto senza modifiche al percorso UDP/514 descritto qui. Per questo percorso:

1. In define XDR A.B.C.D, sostituire solo il segnaposto A.B.C.D con l’IP effettivo del Collector; mantenere define XDR.
2. Impostare la riga della porta su define PORT 514.
3. Nel blocco di uscita MSWINEVENTLOGOUT, commentare la riga Module om_tcp e attivare la riga esistente Module om_udp. Lasciare attivo un solo modulo di uscita in questo blocco; conservare separatamente le altre uscite esistenti.

Verificare quindi sintassi e consegna degli eventi nel progetto pilota. Sophos offre assistenza best effort; i problemi più avanzati del forwarder spettano al relativo fornitore.

Command line del processo nell’evento 4688

Alcuni rilevamenti richiedono campi non registrati da Windows per default. Per includere la riga di comando nella creazione del processo, evento 4688, Sophos indica questa policy Windows:

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

Abilitarla solo nel perimetro autorizzato dopo averne valutato i contenuti. La command line può contenere dati sensibili. L’impostazione non sostituisce né la generazione necessaria degli audit di processo né il filtro 4688 del forwarder.

Per il controllo avviare un processo innocuo autorizzato senza segreti negli argomenti. Verificare prima la riga attesa nell’evento Windows 4688, poi confrontare il relativo process normalizzato in Sophos. Il collector non può ricostruire un campo assente all’origine.

Dimostrare l’acquisizione con un evento sorgente

Per iniziare è adatto un login autorizzato con account di test dedicato. Gli eventi 4624 e 4625 possono provare accesso riuscito o fallito; un errore provocato intenzionalmente non deve bloccare l’account. Usare solo un evento realmente generato nel perimetro audit e forwarding scelto.

1. Annotare nel log Windows Event ID, computer, utente, risultato e ora. Registrare solo valori ripuliti nel verbale di prova.
2. Controllare che il forwarder emetta la categoria senza errori locali di formato, permessi o connessione.
3. Nel tenant Sophos corretto controllare il flusso e poi il record nello schema atteso. Confrontare computer, timestamp, utente ed esito con Windows. Per un login è atteso auth, per 4688 process.
4. Ripetere per le altre categorie necessarie. Un login non prova l’acquisizione di Defender, audit directory o netflow.
5. Confrontare record nuovi per un periodo adeguato e documentare scope, responsabile e prossimo controllo nel collaudo.

L’evento non deve necessariamente generare detection o case MDR. L’acquisizione riuscita oggi non prova completezza storica né conservazione garantita per tutti i dati. Licenze e retention vanno verificate separatamente.

Indagare campi mancanti e lacune

Nessun evento Windows: verificare prima audit, canale selezionato e attività reale. Senza un evento sorgente non esiste nulla da inoltrare.

Evento sorgente presente ma nulla in Sophos: confrontare filtri, Snare-over-syslog, UTC, IP e percorso UDP/514. Poi verificare stato collector e flusso nel periodo giusto. Non aggiungere preventivamente un secondo forwarder allo stesso flusso.

Evento presente ma campo necessario assente: confrontare originale Windows, uscita del forwarder e record normalizzato. Per gli argomenti verificare 4688 e policy approvata. Non inventare un valore predefinito.

Manca solo netflow: controllare separatamente eventi Windows Filtering Platform, selezione del forwarder ed entitlement SIEM. Un login funzionante non dimostra questo perimetro aggiuntivo.

Annullare il pilot o consegnare l’esercizio

Per il rollback fermare solo la nuova uscita o il filtro pilot e ripristinare in modo controllato la configurazione salvata. Conservare altre uscite e collector condivisi. Una policy audit va annullata solo dopo confronto con lo stato iniziale documentato e approvazione: potrebbe servire ad altri requisiti di sicurezza o prova.

Verificare poi il funzionamento del precedente percorso necessario e l’assenza di doppie acquisizioni involontarie. Fermare il forwarder non recupera eventi UDP persi e non prova l’eliminazione della telemetria inviata. In esercizio il team designato rimane responsabile di scope, ora, flusso, modifiche ai template e aggiornamenti del forwarder.