Enviar Windows Event Log ao Sophos XDR e SIEM

Microsoft Windows Event Log pode ser enviado por um forwarder suportado em Snare-over-syslog para um Sophos XDR Data Collector. É um percurso separado do agente Sophos Endpoint: uma Event ID local ou estado Endpoint verde não demonstra ingestão por esta integração.

O processo consiste em implementar o collector, definir eventos e auditoria Windows, direcionar o forwarder no formato correto para UDP/514 e verificar um evento específico na Sophos.

Confirmar âmbito e licenças antes do deployment

Consoante os eventos realmente encaminhados, podem ser recolhidas autenticações, alterações de contas/grupos, processos, findings Defender, mudanças administrativas, auditorias de diretório e outros eventos. Os esquemas são auth, process, antivirus, managementevent, cloudaudit, thirdpartyalert, encrypt e netflow.

O requisito SIEM aplica-se à telemetria netflow, como ligações Windows Filtering Platform, por exemplo 5156. Não torna todos os restantes eventos Windows referidos exclusivos de SIEM. O tenant XDR/MDR precisa, ainda assim, dos direitos de origem e integração necessários. SIEM e o guia de integrações explicam a verificação.

Preparar collector, forwarder e proteção de dados

São necessários XDR Data Collector operacional, percurso de rede aprovado desde Windows e software que emita Snare-over-syslog. A Sophos refere Snare Enterprise, NXLog Enterprise, TIBCO Universal Collector, Syslog-ng Agent for Windows e NXLog Community Edition. Não significa que tenham campos, licenças e ficheiros de configuração idênticos.

O runbook do collector trata recursos, DNS, hora e uplinks. Aqui, permitir UDP/514 de entrada apenas das redes Windows previstas. UDP não confirma cada mensagem; um teste de rede ou porta não substitui prova do evento.

Antes de configurar, documentar computadores ou domain controllers, Event IDs necessárias, auditoria existente, equipa responsável e percurso anterior. Os eventos podem incluir utilizadores, caminhos ou argumentos de processos. Recolher apenas conteúdo aprovado e não copiar logs brutos ou credenciais para tickets públicos.

Configurar o encaminhamento Windows

1. No tenant certo, identificar o collector em Security Operations > Integrations > Data Collectors. Usar o IP alcançável desde Windows, não um endereço regional de upload Sophos nem outra appliance.
2. Implementar o forwarder escolhido num piloto aprovado segundo a sua documentação. Guardar a configuração anterior e identificar outras saídas antes de alterar um ficheiro partilhado.
3. Configurar explicitamente Snare-over-syslog. A Sophos exige este formato; JSON arbitrário, CEF ou XML Windows Event não são substitutos confirmados para este caminho.
4. Definir IP real do collector e porta UDP 514. Canais ou filtros têm de incluir os eventos necessários.
5. Emitir horas de origem em UTC e verificar sincronização Windows. A apresentação local no Event Viewer não prova o fuso enviado pelo forwarder.
6. Ativar e verificar erros locais. Concluir a comparação de eventos abaixo antes de adicionar mais computadores.

Para NXLog CE, descarregue o modelo de configuração nxlog_wel.txt fornecido pela Sophos. Este modelo é um ponto de partida para o formato Snare documentado, não uma substituição não verificada de qualquer configuração NXLog existente. O destino do Collector, os eventos selecionados e as saídas existentes têm de corresponder ao ambiente.

O modelo atualmente associado define define PORT 601 e, no bloco MSWINEVENTLOGOUT, usa Module om_tcp; por isso, não é adequado sem alterações ao percurso UDP/514 aqui descrito. Para este percurso:

1. Em define XDR A.B.C.D, substitua apenas o marcador A.B.C.D pelo IP real do Collector; mantenha define XDR.
2. Defina a linha da porta como define PORT 514.
3. No bloco de saída MSWINEVENTLOGOUT, comente a linha Module om_tcp e ative a linha existente Module om_udp. Deixe apenas um módulo de saída ativo neste bloco; preserve separadamente as outras saídas existentes.

Depois, verifique a sintaxe e a entrega de eventos no piloto. A Sophos oferece assistência best effort; os problemas mais avançados do forwarder cabem ao respetivo fornecedor.

Linha de comandos do processo no evento 4688

Algumas deteções exigem campos que Windows não regista por predefinição. Para incluir a linha de comandos na criação de processo, evento 4688, a Sophos indica esta policy:

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

Ativar apenas no âmbito autorizado após avaliar o conteúdo. As linhas de comandos podem conter dados sensíveis. A definição não substitui a criação necessária de eventos de auditoria de processo nem o filtro 4688 do forwarder.

Para verificar, iniciar um processo inofensivo autorizado sem segredos nos argumentos. Confirmar primeiro a linha esperada no Windows 4688 e depois comparar o evento process normalizado na Sophos. O collector não reconstrói um campo ausente na origem.

Demonstrar ingestão com um evento de origem

Um login autorizado com conta de teste dedicada serve para começar. 4624 e 4625 podem provar autenticação bem-sucedida ou falhada; provocar uma falha não deve bloquear a conta. Usar apenas eventos realmente gerados no âmbito de auditoria e encaminhamento escolhido.

1. Registar Event ID, computador, utilizador, resultado e hora no Windows. Incluir apenas valores limpos no relatório de teste.
2. Confirmar que o forwarder envia essa categoria sem erros locais de formato, permissões ou ligação.
3. No tenant certo, verificar o fluxo da origem e o registo no esquema esperado. Comparar computador, hora, utilizador e resultado com Windows. Para login espera-se auth; para 4688, process.
4. Repetir para outras categorias necessárias. Um login não prova ingestão de Defender, auditorias de diretório ou netflow.
5. Comparar registos novos durante um período adequado e documentar âmbito, responsável e próxima revisão na aceitação.

O evento não tem de produzir detection ou case MDR. Ingestão correta hoje também não prova integridade histórica ou retenção garantida para todos os dados. Verificar licença e conservação separadamente.

Investigar campos ausentes e lacunas

Não existe evento Windows: verificar primeiro auditoria, canal e atividade real. Sem evento na origem não há nada para encaminhar.

Existe na origem, mas não na Sophos: comparar filtros, Snare-over-syslog, UTC, IP e UDP/514. Verificar depois collector e fluxo no período correspondente. Não adicionar preventivamente outro forwarder ao mesmo fluxo.

Evento existe, falta um campo: comparar original Windows, saída do forwarder e registo normalizado. Para argumentos, verificar 4688 e policy aprovada. Não inventar um valor predefinido.

Só falta netflow: verificar separadamente Windows Filtering Platform, seleção e entitlement SIEM. Um login funcional não prova esse âmbito adicional.

Reverter o piloto ou entregar a operação

Para rollback, parar apenas a nova saída ou filtro piloto e restaurar de forma controlada a configuração guardada. Manter outras saídas e collectors partilhados. Reverter uma policy de auditoria apenas após comparar o estado inicial documentado e obter aprovação; outros requisitos de segurança ou prova podem depender dela.

Depois confirmar que o percurso anterior necessário funciona e que não existe duplicação involuntária. Parar o forwarder não recupera eventos UDP perdidos nem prova a eliminação de dados enviados. Em operação, a equipa designada continua responsável por âmbito, hora, fluxo, modelos e atualizações do forwarder.