DAT.4 - Ingestão e Centralização de Logs (SIEM)

Nota do grupo DAT (Coleta de Dados e Telemetria) da seção 15 do Framework CTH.
Deriva do Capítulo 6 do PDF de referência e do controle DAT.4 do modelo CIS Controls v8.
Trata da plataforma central que transforma dados isolados de dezenas de fontes em inteligência acionável para detecção, hunting e resposta.

1. Contexto e Posicionamento no Framework CTH

A centralização de logs em uma plataforma SIEM é o que converte as coletas de DAT.1, DAT.2 e DAT.3 em capacidade operacional real. Sem centralização, a correlação entre eventos de fontes diferentes, como um alerta de IDS combinado com um login suspeito e uma alteração de configuração, é praticamente impossível em escala e prazo. O SIEM habilita busca em tempo real, detecção automatizada por regras, análise histórica para threat hunting e visualização por dashboards, sendo a plataforma sobre a qual detecção, resposta e hunting são construídas.

Dentro do Framework CTH, DAT.4 é o ponto de convergência de todo o grupo DAT e o provedor de dados dos grupos DET, TH e IR. A qualidade do que acontece a jusante depende diretamente das decisões tomadas aqui: escolha de pipelines, modelos de dados, particionamento de índices e camadas de retenção. Um erro de arquitetura nesta etapa, como ingestão sem normalização, contamina todo o ciclo de detecção e encarece a operação.

Este controle exige visão de engenharia e de custos simultaneamente, porque ingestão de SIEM é uma das rubricas mais sensíveis do orçamento de segurança. A meta é maximizar o valor analítico por gigabyte ingerido, garantindo que fontes críticas nunca sejam sacrificadas por má gestão de volume.

2. Por Que Centralizar: Correlação, Retenção Única e Busca em Escala

O primeiro benefício da centralização é a correlação, que amarra eventos de fontes distintas em uma única história do ataque. Um host que gerou evento de processo suspeito, conectou a um domínio recente e depois autenticou em outro servidor conta uma história completa apenas quando os três eventos estão no mesmo repositório e compartilham modelo de dados. Regras analíticas e hipóteses de hunting foram concebidas exatamente para operar sobre esse quadro unificado.

O segundo benefício é a retenção única e governada, que substitui logs espalhados em servidores individuais com prazos inconsistentes por uma política central de ciclo de vida. Logs locais podem ser alterados ou destruídos por um adversário com privilégio no host, enquanto a cópia centralizada, com acesso controlado, preserva a evidência. A terceira vantagem é a busca em escala, que permite interrogar bilhões de eventos em segundos, viabilizando hunting retroativo sobre meses de histórico.

Há também um efeito operacional menos visível: a centralização padroniza o acesso do time, pois analistas aprendem um idioma de consulta único em vez de uma sintaxe por fonte. Isso reduz a dependência de especialistas individuais e acelera a triagem, impactando diretamente o tempo de resposta medido pelo grupo MET.

3. Arquitetura de Ingestão: Agentes, Agregadores, Filas e Transformação

A arquitetura de ingestão segue um padrão em camadas que separa coleta, transporte e processamento. Na ponta, agentes e forwarders instalados nos hosts, como agente de telemetria ou forwarder dedicado, coletam e enviam logs; equipamentos de rede enviam via syslog; serviços de nuvem exportam logs para filas nativas. No meio, agregadores e coletores centralizam o fluxo, aplicam buffering e fazem transformação em trânsito. Na ponta final, o SIEM indexa e disponibiliza os dados para busca.

O buffering é o componente que separa arquiteturas resilientes de arquiteturas frágeis, pois filas persistentes absorvem picos e indisponibilidade do SIEM sem perder dados. Agregadores devem configurar disco de spool e reentrega automática, garantindo que uma manutenção do SIEM não crie lacunas na coleta. A transformação em trânsito, feita nos agregadores, cobre parse de formatos brutos, normalização de campos, filtragem de dados sem valor e mascaramento de dados sensíveis antes da ingestão.

A tabela abaixo resume os papéis de cada componente:

Transformação pesada em trânsito tem custo de manutenção e deve ser balanceada com parse no SIEM, priorizando normalizar campos comuns cedo e deixar análise complexa para a plataforma. Um exemplo de pipeline de agregador com buffering e roteamento:

# Pipeline de agregador: entrada, buffering e saída
[INPUT]
    Name   tail
    Path   /var/log/syslog/*.log
    Parser syslog-rfc5424

[FILTER]
    Name   record_modifier
    Match  *
    Record site producao  ambiente dmz

[OUTPUT]
    Name   es
    Match  *
    Host   siem-interno.empresa.local
    Port   9200
    Retry_Limit  False

Toda transformação deve ser documentada, pois evidência forense precisa de rastreabilidade do dado bruto ao campo final.

4. Modelos de Dados de Normalização: CIM, ECS e OCSF

O valor real da centralização aparece quando todas as fontes escrevem no mesmo campo. Os três modelos de mercado servem a essa função: o CIM oferece um dicionário de campos e tags amplamente usado em ecossistemas de busca comercial; o ECS estrutura eventos em categorias como process, network e authentication com campos como source.ip, user.name e process.command_line; o OCSF surge como esquema aberto e agnóstico de fornecedor, com classes de evento normalizadas e forte adoção por plataformas modernas. Escolher um modelo e aderir a ele com disciplina importa mais do que a escolha em si.

A normalização permite que uma consulta única funcione em todas as fontes, como ilustrado abaixo:

event.category = "authentication" AND event.outcome = "failure"
| stats count, dcount(source.ip) by user.name
| where count > 20

Sem modelo comum, o mesmo evento de falha de login chega como src_ip, clientIP ou SourceAddress, e cada regra precisa de variações que se quebram silenciosamente quando o parse muda. A decisão de modelo deve considerar o ecossistema da plataforma escolhida, a existência de mapeamentos prontos para as fontes do ambiente e a facilidade de treinar o time. Em ambientes híbridos, é viável mapear campos internos para um modelo e exportar para OCSF quando houver integração com parceiros e plataformas de nuvem.

5. Indexação e Custo: Particionamento e Camadas de Dados

A indexação é o maior driver de custo do SIEM, e sua gestão começa pelo particionamento correto. Índices devem ser separados por data e por fonte ou tipo de dado, permitindo políticas de ciclo de vida independentes, busca direcionada que evita varrer dados irrelevantes e exclusão precisa quando prazos vencem. Nomes de índice devem seguir convenção estável, como tipo de fonte e ano-mês, para facilitar automação.

Camadas de dados equilibram desempenho e custo: dados quentes ficam em armazenamento rápido e respondem buscas interativas dos últimos dias; dados mornos migram para armazenamento mais barato com busca aceitável; dados frios ficam em repositório de arquivamento. Consultas de hunting e triagem rodam sobre camadas quentes e mornas, enquanto a camada fria atende investigações retrospectivas raras mas críticas, com restauração sob demanda. A política de re-aquecimento de índices durante uma investigação deve estar documentada e testada antes de ser necessária.

A busca em arquivamento merece atenção específica: repositórios baratos como object storage exigem ferramentas de consulta próprias ou reingestão seletiva, e esse fluxo deve ser exercitado periodicamente. Um exemplo de política de ciclo de vida de índice define a transição entre camadas:

{
  "policy": {
    "phases": {
      "hot": { "actions": { "rollover": { "max_size": "50gb", "max_age": "1d" } } },
      "warm": { "min_age": "30d", "actions": { "allocate": { "require": { "data": "warm" } } } },
      "cold": { "min_age": "90d", "actions": { "searchable_snapshot": { "snapshot_repository": "arquivo_frio" } } },
      "delete": { "min_age": "365d", "actions": {} }
    }
  }
}

O dimensionamento correto das camadas depende do dwell time esperado e das exigências regulatórias tratadas em DAT.5, de modo que as decisões de custo e retenção são inseparáveis.

6. SLA de Ingestão e Latência Ponta a Ponta

A latência ponta a ponta mede o tempo entre a geração do log na fonte e sua disponibilidade para busca no SIEM, e a referência do Framework CTH é que logs cheguem em até 5 minutos. Esse indicador é um SLA operacional porque detecções em tempo real e resposta a incidente dependem dele: um alerta gerado sobre dados atrasados em 40 minutos dá ao adversário uma janela de execução que nenhuma regra compensa. Componentes que somam latência incluem intervalo de envio do agente, filas do agregador, gargalos de parse e picos de indexação.

O monitoramento deve medir a latência por fonte, com percentis em vez de média, pois médias escondem caudas longas de atraso. Gaps de coleta, quando uma fonte ativa fica silenciosa, devem disparar alerta automático, pois costumam indicar agente parado, equipamento sem rede ou adversário interferindo na coleta. A meta de latência deve entrar no SLA do time de engenharia de dados de segurança, com revisão periódica dos gargalos.

7. Validação de Cobertura por Fonte

A cobertura de dados deve ser validada continuamente monitorando volume por sourcetype ou categoria de fonte, comparando o observado com uma linha de base histórica. Quedas súbitas de volume indicam quebra de coleta, e ausências silenciosas, como um servidor que deixa de enviar 4688, podem passar semanas sem ninguém notar se não houver verificação automatizada. Um painel de cobertura deve listar todas as fontes do inventário com status de ingestão nas últimas 24 horas.

Uma consulta exemplificativa de verificação de volume e lacunas:

index=* | stats count, max(_indextime - timestamp) as latencia_s by sourcetype
| where count < baseline_esperado OR latencia_s > 300

A validação também deve checar a qualidade do parse por fonte, medindo a taxa de eventos não estruturados que caem em campos genéricos. Fontes com parse degradado são funcionais em volume, mas pobres em valor analítico, e devem entrar no backlog de correção. O inventário de fontes deve ser reconciliado com o inventário de ativos do grupo CTI.x, garantindo que ativos críticos tenham cobertura completa. A tabela abaixo sugere limiares de gestão por tipo de métrica:

8. Integração do SIEM com TIP, SOAR e EDR

O SIEM não opera sozinho: com a TIP, recebe enriquecimento de indicadores, scoring de confiança e contexto de campanha, elevando a precisão das regras que dependem de IOC. Com o SOAR, o SIEM dispara playbooks de enriquecimento e resposta, fechando o ciclo entre detecção e ação, sempre com critérios claros de quando automatizar. Com o EDR, a integração permite que o SIEM consulte telemetria detalhada do host, dispare isolamento de máquina e traga de volta a árvore de processos para o caso.

Essas integrações devem preservar o modelo de dados comum, já que alertas de EDR e enriquecimentos de TIP também precisam ser consultáveis nos mesmos campos de entidade. É recomendável manter no SIEM apenas o resumo estruturado dos objetos externos, com ponteiro para o detalhe na plataforma de origem, evitando duplicar grandes volumes. O desenho das integrações deve considerar resiliência, pois a TIP ou o SOAR fora do ar não podem bloquear a ingestão de dados.

O papel de cada integração pode ser resumido em perguntas que a plataforma responde: a TIP responde se um indicador é conhecido e em qual contexto de campanha; o EDR responde o que aconteceu no host e executa contenção; o SOAR executa a ação padronizada e registra a trilha de auditoria. O SIEM permanece o ponto de correlação e de memória histórica do programa, e as três integrações devem ser versionadas e testadas junto com as regras de detecção.

9. Implementação Prática e Salvaguardas por Nível

As salvaguardas do controle DAT.4 seguem o padrão de complexidade crescente do Framework CTH:

A implantação deve começar pelas fontes das salvaguardas básicas de DAT.1 a DAT.3, evitando o padrão comum de ingestão aberta sem plano. Cada pipeline deve ter dono, documentação e teste de validação, e cada detecção nova deve ser validada contra histórico antes de ir a produção, medindo verdadeiros positivos, falsos positivos e falsos negativos.

10. Erros Comuns e Pontos de Atenção

O erro mais caro é ingerir dados sem normalização, acumulando texto bruto que consome orçamento e não suporta consultas consistentes. O segundo erro, frequentemente consequência do primeiro, é o custo explodir e forçar a organização a cortar fontes críticas, como logs de autenticação ou telemetria de servidor de identidade, justamente as mais valiosas para detecção e hunting. Cortar fontes por pressão de custo é uma decisão de risco que deve ser tratada como aceitação formal de lacuna de visibilidade, nunca como ajuste silencioso.

Outros erros comuns incluem filtros de ingestão que engolem eventos sem ninguém revisar, falta de monitoração de latência por fonte, dependência de um único analista que conhece os pipelines e ausência de teste de restauração da camada fria. Também é frequente tratar o SIEM como projeto com fim, quando na realidade é plataforma viva que exige gestão contínua de fontes, parse, regras e custo. A ausência de reconciliação com o inventário de ativos deixa ativos novos sem coleta por meses.

11. Integração com Outros Controles do Framework CTH

DAT.4 é o consumidor direto de DAT.1, DAT.2 e DAT.3 e o fornecedor de dados para DAT.5, que governa qualidade e retenção do acervo centralizado. As regras do grupo DET e as hipóteses do grupo TH executam sobre a base aqui construída, e os playbooks do grupo IR dependem do SIEM para triagem e investigação. Com o grupo MET, os indicadores de cobertura e latência alimentam a avaliação da maturidade de dados, e com GOV as decisões de custo e retenção se tornam governança formal, documentada e revisável.