Enviar Windows Event Log a Sophos XDR y SIEM

Microsoft Windows Event Log puede enviarse mediante un forwarder compatible en formato Snare-over-syslog a un Sophos XDR Data Collector. Es una ruta distinta del agente Sophos Endpoint: una Event ID local o estado Endpoint verde no demuestra que el evento haya entrado por esta integración.

El proceso consiste en desplegar el collector, definir eventos y auditoría Windows, dirigir el forwarder correctamente formateado a UDP/514 y verificar un evento concreto en Sophos.

Confirmar alcance y licencias antes del despliegue

Según eventos realmente reenviados, se pueden recoger autenticaciones, cambios de cuentas/grupos, procesos, hallazgos Defender, cambios administrativos, auditorías de directorio y otros eventos. Los esquemas documentados son auth, process, antivirus, managementevent, cloudaudit, thirdpartyalert, encrypt y netflow.

El requisito SIEM afecta a la telemetría netflow, como conexiones Windows Filtering Platform, por ejemplo 5156. No convierte todos los demás eventos citados en exclusivos de SIEM. El tenant XDR/MDR debe contar igualmente con los derechos de fuente e integración necesarios. La guía SIEM y la guía de integraciones explican la comprobación.

Preparar collector, forwarder y protección de datos

Se necesita XDR Data Collector operativo, ruta de red autorizada desde Windows y software que emita Snare-over-syslog. Sophos cita Snare Enterprise, NXLog Enterprise, TIBCO Universal Collector, Syslog-ng Agent for Windows y NXLog Community Edition. No significa que tengan idénticos campos, licencias o archivos de configuración.

El runbook del collector trata recursos, DNS, hora y uplinks. Aquí se permite UDP/514 entrante solo desde las redes Windows previstas. UDP no confirma cada mensaje; una prueba de red o puerto no sustituye la evidencia del evento.

Antes de configurar, documentar equipos o domain controllers, Event IDs necesarias, auditoría existente, equipo responsable y ruta anterior. Los eventos pueden incluir usuarios, rutas o argumentos. Recoger solo datos autorizados y no copiar logs brutos o credenciales a tickets públicos.

Configurar el reenvío Windows

1. En el tenant correcto, identificar el collector en Security Operations > Integrations > Data Collectors. Usar su IP accesible desde Windows, no una dirección regional de carga Sophos ni otra appliance.
2. Desplegar el forwarder elegido en un piloto aprobado según su documentación. Guardar la configuración previa e identificar otras salidas antes de modificar un archivo compartido.
3. Configurar expresamente Snare-over-syslog. Sophos exige este formato; JSON arbitrario, CEF o XML Windows Event no son sustitutos confirmados para esta ruta.
4. Establecer la IP real del collector y puerto UDP 514. Los canales o filtros deben incluir los eventos requeridos.
5. Emitir horas de origen en UTC y revisar la sincronización Windows. La visualización local de Event Viewer no demuestra qué zona transmite el forwarder.
6. Activar y revisar errores locales. Validar los eventos siguientes antes de extender a más equipos.

Para NXLog CE, descargue la plantilla de configuración nxlog_wel.txt proporcionada por Sophos. Esta plantilla sirve como punto de partida para el formato Snare documentado, no como sustitución sin verificar de cualquier configuración NXLog existente. El destino del Collector, los eventos seleccionados y las salidas existentes deben ajustarse al entorno.

La plantilla enlazada actualmente establece define PORT 601 y, en el bloque MSWINEVENTLOGOUT, usa Module om_tcp; por tanto, no es adecuada sin modificaciones para la vía UDP/514 descrita aquí. Para esta vía:

1. En define XDR A.B.C.D, sustituya únicamente el marcador A.B.C.D por la IP real del Collector; conserve define XDR.
2. Establezca la línea del puerto en define PORT 514.
3. En el bloque de salida MSWINEVENTLOGOUT, comente la línea Module om_tcp y active la línea existente Module om_udp. Deje activo un solo módulo de salida en este bloque; conserve por separado las demás salidas existentes.

Después, compruebe la sintaxis y la entrega de eventos en el piloto. Sophos ofrece asistencia best effort; los problemas más avanzados del forwarder corresponden a su fabricante.

Línea de comandos de proceso en el evento 4688

Algunas detecciones requieren campos que Windows no registra por defecto. Para incluir la línea de comandos en la creación de proceso, evento 4688, Sophos señala esta policy:

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

Activarla solo para el alcance autorizado después de evaluar su contenido. Las líneas de comandos pueden contener información sensible. No sustituye la generación necesaria de eventos de auditoría de proceso ni el filtro 4688 del forwarder.

Para comprobarlo, iniciar un proceso inocuo autorizado sin secretos en los argumentos. Verificar primero la línea esperada en Windows 4688 y después el evento process normalizado en Sophos. El collector no puede reconstruir un campo ausente en origen.

Demostrar la ingesta con un evento de origen

Un login autorizado con cuenta de prueba dedicada sirve para empezar. 4624 y 4625 pueden demostrar autenticación correcta o fallida; provocar un fallo no debe bloquear la cuenta. Utilizar solo eventos realmente generados dentro del alcance de auditoría y reenvío elegido.

1. Registrar Event ID, equipo, usuario, resultado y hora en Windows. Incluir solo valores saneados en el informe de prueba.
2. Confirmar que el forwarder transmite esa categoría sin errores locales de formato, permisos o conexión.
3. En el tenant correcto, examinar el flujo de la fuente y el registro del esquema esperado. Comparar equipo, hora, usuario y resultado con Windows. Para login se espera auth; para 4688, process.
4. Repetir con las demás categorías requeridas. Un login no demuestra ingesta de Defender, auditorías de directorio o netflow.
5. Comparar registros nuevos durante un período adecuado y documentar alcance, responsable y próxima revisión para la aceptación.

El evento no tiene que producir detection ni case MDR. La ingesta correcta hoy tampoco demuestra integridad histórica ni retención garantizada de todos los datos. Verificar por separado licencia y conservación.

Investigar campos ausentes y lagunas

No existe evento Windows: comprobar primero auditoría, canal y actividad real. Sin evento en origen no hay nada que reenviar.

Existe en origen pero no aparece en Sophos: comparar filtros, Snare-over-syslog, UTC, IP y UDP/514. Después revisar collector y flujo en el período correspondiente. No añadir preventivamente otro forwarder al mismo flujo.

Existe el evento pero falta un campo: comparar original Windows, salida del forwarder y registro normalizado. Para argumentos revisar 4688 y policy aprobada. No inventar un valor predeterminado.

Solo falta netflow: comprobar por separado eventos Windows Filtering Platform, selección del forwarder y entitlement SIEM. Un login que funciona no demuestra ese alcance adicional.

Revertir el piloto o transferir la operación

Para rollback detener únicamente la nueva salida o filtro piloto y restaurar de forma controlada la configuración guardada. Conservar otras salidas y collectors compartidos. Revertir una policy de auditoría solo tras comparar su estado inicial documentado y obtener aprobación; otros requisitos de seguridad o evidencia pueden depender de ella.

Después comprobar que la ruta anterior necesaria funciona y no existe duplicación involuntaria. Detener el forwarder no recupera eventos UDP perdidos ni demuestra borrado de datos ya enviados. Durante la operación, el equipo designado sigue siendo responsable de alcance, hora, flujo, plantillas y actualizaciones del forwarder.