Uma regra de detecção escrita contra o campo bruto de um único produto morre quando a fonte troca de versão ou quando a empresa adiciona um novo fornecedor. O mesmo acontece com dashboards, correlações e políticas de retenção: tudo fica preso ao formato de origem. Este guia mostra como aplicar o Open Cybersecurity Schema Framework (OCSF) para fazer a normalização de logs com OCSF na ingestão, um problema que afeta equipes de SOC, SRE e engenharia de detecção. A ação prioritária é direta: pare de escrever regras contra nomes de campos de fornecedor e passe a escrever contra classes de evento padronizadas.

Por que normalizar antes de detectar

O ponto de partida é reconhecer onde o ruído nasce. Um firewall, um provedor de identidade e um EDR descrevem o mesmo fato — um usuário autenticou, um processo iniciou, uma conexão saiu — com campos, tipos e convenções diferentes. Quando a detecção escreve uma regra por formato, a operação acumula três defeitos: regras duplicadas para a mesma técnica, cobertura aparente que esconde furos e tempo de analista gasto em manutenção em vez de caça à ameaça.

A normalização na ingestão separa a semântica do formato. O evento passa a ter um vocabulário estável no ponto de entrada do pipeline, e as regras passam a apontar para esse vocabulário. É o mesmo princípio que sustenta o uso de regras Sigma no SIEM: desacoplar a lógica de detecção da plataforma que a executa, para que a troca de ferramenta não implique reescrever a biblioteca inteira de detecção.

Como o OCSF organiza os eventos

O OCSF não é um produto, e sim um framework open source com documentação pública mantida por um consórcio de fornecedores. A sua taxonomia se apoia em tipos de dados, classes de evento, categorias, perfis e extensões — os construtos que descrevem qualquer evento de segurança. A documentação também separa responsabilidades em personas: o autor cria ou estende o schema, o produtor emite eventos nativos, o mapper traduz formatos externos e o analista consome os dados em buscas, regras e relatórios. Essa divisão importa na prática: quem mapeia não deveria ser a mesma pessoa que escreve a regra, porque os defeitos de um aparecem como falso positivo do outro.

As classes de evento têm identificadores numéricos estáveis e se agrupam em categorias com funções práticas de partição, busca, relatório e controle de acesso. No domínio de identidade, a classe Authentication recebe o identificador 3002, ao lado de Account Change e User Management na mesma categoria. Identificadores estáveis permitem escrever regras, particionar armazenamento e restringir acesso sem depender de rótulos textuais que variam entre versões, produtos e idiomas.

Dados ausentes e o unknown

Um detalhe do schema resolve um problema clássico de cobertura: quando um atributo obrigatório não pode ser preenchido porque a fonte não gera essa informação, o evento deve carregar o valor unknown em vez de omitir o campo. A ausência fica declarada, e não implícita. Para quem escreve detecção, isso muda o jogo: dá para distinguir a fonte que não informa do campo que chegou vazio, e escrever regras que alertam sobre degradação do pipeline em vez de falhar em silêncio.

Outro sinal de qualidade embutido no schema é o par de atributos de tempo. Uma diferença não trivial entre o momento do registro do evento e o momento do processamento pode indicar problema de sincronismo de relógio na origem — ou um intermediário de coleta sobrecarregado no caminho. Ambos os casos degradam janelas de correlação e a ordenação dos eventos, então vale monitorar essa divergência como métrica de saúde do pipeline, e não como detalhe cosmético do armazenamento.

Regras portáteis entre fontes

A camada de normalização já existe pronta em serviços gerenciados. O Amazon Security Lake, por exemplo, converte os dados ingeridos para Apache Parquet e para o schema aberto OCSF, gravando tudo em um data lake dentro da conta do próprio cliente, que mantém a posse dos dados. As fontes nativas incluem eventos de gestão e de dados do CloudTrail, logs de auditoria do EKS, consultas do resolver do Route 53, VPC Flow Logs e logs do WAFv2, com consumo possível por Athena, Redshift ou ferramentas que leem o catálogo do Glue.

O ganho aparece quando a mesma regra roda sobre qualquer produtor que emita o schema: a troca de SIEM deixa de ser um projeto de reimplementação e a adesão de uma nova fonte passa por um mapeamento, não por uma reescrita. A ressalva é honesta: mapeamento malfeito é a maior fonte de ruído em projetos desse tipo. Atributo perdido na tradução, fuso horário interpretado de forma errada e severidade rebaixada por conveniência produzem regras que disparam para o nada — ou que nunca disparam. A qualidade do mapeamento merece revisão tão rigorosa quanto a da regra, no espírito do que as regras Sigma liberadas pela CISA para casos de exploração ativa já demonstraram: regra boa depende de campo confiável.

Implantação em etapas práticas

O roteiro abaixo ordena o trabalho do que trava a detecção ao que a refina, com resultado verificável em cada linha.

Prioridade Ação Resultado esperado
P1 Inventariar as fontes e escolher as classes-alvo, como Authentication, Process Activity e Network Activity Pipeline com destino único por tipo de evento
P1 Definir um dono para cada mapeamento e validar os eventos contra o servidor de schema público Defeitos de tradução capturados antes das regras
P1 Criar regra de quarentena para eventos que chegam sem classe de evento atribuída Furo de cobertura visível, não silencioso
P2 Medir o percentual de eventos com classe atribuída e com campos obrigatórios presentes Métrica de cobertura e de degradação do pipeline
P2 Monitorar a divergência entre o horário de registro e o de processamento Desvio de sincronismo detectado na origem

Três sinais indicam que a cobertura está falhando depois da implantação. Primeiro, crescimento sustentado de eventos com valor unknown em campos que a fonte deveria informar. Segundo, regras novas que citam nomes de campos de fornecedor, sinal de que o pipeline voltou a vazar formato para a camada de detecção. Terceiro, consultas que quebram após uma atualização de versão da fonte, evidência de acoplamento que a normalização deveria ter eliminado. Cada um desses sinais tem dono e prazo definidos na tabela acima; ignorá-los devolve a operação ao ponto de partida, com regras frágeis e cobertura cheia de pontos cegos.

Fontes