O que são security logs e por que normalizá-los

A fonte define log como um registro com timestamp de um evento gerado por um sistema, processo, aplicação ou serviço. Times de engenharia e operações usam logs para depuração e auditoria. Times de segurança usam os mesmos registros como evidência para investigar ameaças. O texto lembra que nem todo log é útil e que alguns eventos esperados nunca geram registro. Sem telemetria, não existe regra de detecção.

O problema aparece quando as fontes têm formatos diferentes: JSON, CSV, Syslog, CEF e Windows Event Log (binário .evtx, renderizado como XML). Para extrair a conta de usuário, por exemplo, o campo é user no CSV, precisa de extração customizada no Syslog, vira TargetUserName dentro de EventData no Windows e é user.email no JSON. A solução descrita é um pipeline ETL (extrair, transformar, carregar): parsear a mensagem bruta, mapear para um campo padrão, converter timestamps para um fuso comum e até ajustar coisas simples como userName para username. Sem isso, surgem regras duplicadas por fonte, dificuldade em detecções compostas (juntar evento de identidade com atividade de endpoint) e sobrecarga de conhecimento para analistas de SOC. O texto é a parte 1 de uma série, e a parte 2 vai tratar da camada de transformação e das armadilhas da normalização.

Para quem opera SIEM, a leitura é direta: normalização não é refinamento, é pré-requisito. Cada fonte nova sem mapeamento de campos tende a multiplicar regras e a abrir pontos cegos. Investir no pipeline antes de escrever detecções parece lento, mas reduz manutenção e torna a correlação confiável.