DAT.5 - Qualidade e Retenção de Dados

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.5 do modelo CIS Controls v8.
Garante que o acervo construído em DAT.1 a DAT.4 seja confiável, rastreável e profundo o bastante para sustentar hunting retroativo e investigação forense.

1. Contexto e Posicionamento no Framework CTH

A qualidade dos dados de telemetria determina diretamente a eficácia de todas as atividades de detecção, hunting e inteligência. Dados de baixa qualidade, com campos ausentes, timestamps incorretos, formatos inconsistentes ou duplicados, geram falsos positivos excessivos, mascaram ameaças reais e tornam as consultas de hunting imprecisas. Um hunter que não pode confiar no horário do evento nem na presença dos campos busca às cegas, e as conclusões perdem força analítica.

A retenção é a outra metade deste controle: sem histórico suficiente, a análise retrospectiva que confirma o alcance de um incidente se torna impossível. Determinar quando o adversário entrou, quais sistemas foram comprometidos e quais dados foram acessados exige logs anteriores à descoberta da intrusão. Incidentes descobertos tardiamente, com dwell time de meses, só podem ser investigados sobre bases com retenção compatível com esse tempo de permanência.

Dentro do Framework CTH, DAT.5 governa o acervo produzido por DAT.1 a DAT.4 e fecha o grupo de coleta com a garantia de confiabilidade. Ele fornece aos grupos DET e TH a certeza de que as consultas operam sobre dados completos e precisos, e fornece ao grupo IR a base probatória das investigações. As práticas aqui definidas também conectam a operação técnica às exigências legais e regulatórias da organização.

2. Dimensões de Qualidade da Telemetria

A qualidade de telemetria deve ser avaliada em cinco dimensões complementares, cada uma com verificação própria. A completude verifica se a fonte envia todos os eventos esperados e se os campos obrigatórios estão preenchidos, pois uma fonte parcialmente coletada cria falsa sensação de visibilidade. A precisão temporal verifica se os timestamps refletem o instante real do evento e se estão em UTC, evitando deslocamentos que quebram linhas do tempo.

A consistência de nomes de campo garante que o mesmo conceito tenha o mesmo nome em todas as fontes, na linha dos modelos de dados discutidos em DAT.4. A latência mede o tempo entre geração e disponibilidade para busca, com meta de até 5 minutos conforme o padrão do Framework CTH. A integridade contra alteração assegura que o log não possa ser modificado ou apagado silenciosamente, protegendo o valor probatório do acervo.

A tabela abaixo resume as dimensões e seus critérios de verificação:

Cada dimensão deve ter dono no time e limiar definido de aceitação. Falhas recorrentes em qualquer dimensão devem gerar plano de correção com prazo, evitando que a degradação silenciosa vire padrão aceito.

3. Sincronização NTP como Pré-Requisito

A sincronização de tempo via NTP é pré-requisito absoluto de toda a cadeia de coleta, porque a correlação entre fontes depende de relógios alinhados. Sem NTP estruturado, um evento de login em um servidor e o fluxo de rede correspondente podem parecer separados por minutos, destruindo a linha do tempo do incidente e a utilidade das regras de correlação. A arquitetura recomendada usa servidores NTP internos hierarquizados, sincronizados com fontes confiáveis, com todos os hosts, equipamentos e sensores apontando para eles.

O monitoramento de desvio de relógio deve ser parte da verificação de qualidade, com alerta quando um host apresentar desvio além do limiar definido. Em ambientes virtualizados, é importante conferir a sincronização do hypervisor e evitar conflitos entre mecanismos de sincronização do hypervisor e o cliente NTP do sistema convidado. Equipamentos de rede e dispositivos de nuvem exigem configuração explícita, pois frequentemente saem de fábrica sem cliente NTP ativo.

Um exemplo de configuração de cliente NTP em Linux ilustra o padrão esperado:

# /etc/chrony.conf
server ntp-1.empresa.local iburst prefer
server ntp-2.empresa.local iburst
driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsync

A verificação de desvio pode ser automatizada com comparação do horário local contra o relógio de referência, registrando o resultado como métrica de qualidade por fonte.

4. Testes Sintéticos de Coleta

O teste sintético é a única forma confiável de validar ponta a ponta que a coleta funciona, porque gera um evento conhecido na fonte e mede quando ele aparece na busca do SIEM. O método consiste em disparar uma ação assinatura, como uma execução de processo com marcador único, uma falha de login com usuário de teste ou uma consulta DNS para um domínio de teste, e depois verificar a chegada do evento com os campos esperados. O tempo medido valida o SLA de latência, e o conteúdo validado confirma parse e normalização.

Um exemplo de teste sintético em Linux e Windows:

# Linux: execução marcada para validar auditd e ingestão
echo "synthetic_test_$(date +%s)" > /tmp/colecao_teste
journalctl --since "1 minute ago" | grep colecao_teste

# Windows: processo marcado para validar Sysmon e ingestão
Start-Process -FilePath "cmd.exe" -ArgumentList "/c echo synthetic_test"

Testes devem rodar de forma agendada por camada crítica de fonte, com resultado registrado como métrica histórica de disponibilidade de coleta. Falha de teste deve abrir incidente interno para o time de engenharia de dados, pois coleta quebrada é lacuna de visibilidade imediata. A rotina de testes também deve cobrir caminhos indiretos, como encaminhamento entre agregadores e restauração da camada fria.

5. Políticas de Retenção por Camada e por Tipo de Dado

A retenção deve ser definida em camadas de custo decrescente, com exemplo prático de 30 dias quentes para busca interativa, 90 a 180 dias mornos para investigação recente e 365 dias ou mais frios para arquivamento. O particionamento por data e fonte descrito em DAT.4 é o que viabiliza aplicar camadas distintas por tipo de dado. Nem todo dado merece a mesma profundidade: logs de autenticação e eventos de aplicação sensíveis pedem retenção máxima, enquanto métricas de disponibilidade se degradam em valor rapidamente.

A tabela abaixo exemplifica políticas por tipo de dado, alinhadas ao PDF de referência:

A política deve ser formalizada em documento aprovado pela governança, com justificativa técnica e legal para cada prazo, e implementada via política de ciclo de vida do SIEM. Mudanças de prazo devem passar por avaliação de impacto investigativo antes da aprovação, pois reduções de retenção são irreversíveis para o passado.

6. Requisitos Legais e Setoriais

A retenção de dados não é decisão puramente técnica: a LGPD impõe minimização e finalidade definida, exigindo equilíbrio entre profundidade investigativa e proteção de dados pessoais, com base legal documentada para cada coleta. Instituições financeiras no Brasil respondem a exigências próprias de conservação de registros e de comunicação de operações, que elevam os prazos mínimos acima da referência geral. Regulações setoriais, padrões de pagamento e contratos com clientes podem acrescentar prazos específicos que devem ser levantados com jurídico e compliance.

O desenho ideal separa a necessidade de busca operacional rápida da obrigação de conservar, usando camadas: dados pessoais sensíveis podem sair da camada quente e permanecer em arquivamento com acesso restrito e criptografia. Prazos de investigação também influenciam, pois notificações de incidente e disputas judiciais podem exigir logs de períodos longos atrás. A revisão da política de retenção deve envolver jurídico, privacidade e segurança de forma periódica, com registro formal das decisões.

7. Dwell Time e a Necessidade de Histórico

O dwell time médio de comprometimentos, frequentemente medido em meses pelas pesquisas de referência do setor, define o parâmetro real da retenção. Se o adversário tipicamente permanece meses antes de ser descoberto, bases com apenas 7 dias de log não permitem responder à pergunta mais importante de uma investigação: quando e como a intrusão começou. Hunting retroativo, no qual uma nova TTP ou IOC é pesquisada sobre o histórico, também exige profundidade compatível com esse tempo de permanência.

A consequência prática é que a retenção fria de 365 dias não é luxo, é requisito funcional de um programa maduro de CTI e Threat Hunting. Quando cada indicador novo chega pela inteligência, o valor do acervo é testado com consultas retrospectivas, e esse teste só produz resultados sobre profundidade histórica adequada. Organizações com retenção curta devem tratar a expansão como risco priorizado, começando pelas fontes de autenticação e endpoint, que ancoram a linha do tempo de qualquer incidente.

A tabela abaixo conecta faixas de dwell time observado com exigência prática de retenção:

8. Métricas de Qualidade e Revisão Periódica

A qualidade deve ser medida continuamente com métricas explícitas: eventos por segundo por fonte, latência percentil 95 de ingestão, taxa de erros de parse, percentual de campos obrigatórios preenchidos, lacunas de coleta por janela de tempo e volume de dados ingeridos contra orçamento. Um painel de qualidade de dados no SIEM deve exibir essas métricas em tempo real, com alertas automáticos quando limiares forem ultrapassados. Métricas sem dono e sem limiar não geram ação, por isso cada indicador deve ter responsável e procedimento de resposta.

A tabela abaixo consolida as métricas com limiares de referência:

A revisão periódica, de preferência trimestral, deve confrontar as métricas com as hipóteses de hunting em uso, verificando se as fontes necessárias continuam saudáveis e se novas fontes precisam entrar. O ciclo de revisão deve incluir teste de restauração da camada fria, validação de duplicidade e auditoria de integridade do acervo. Resultados das revisões alimentam o grupo MET e a governança GOV, transformando qualidade de dados em indicador gerencial.

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

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

A implantação deve começar pelo inventário de tipos de dado e prazos atuais, corrigindo primeiro os desvios de autenticação e endpoint. Cada salvaguarda deve ter teste de validação, incluindo provocação deliberada de falha para confirmar que o alerta dispara e chega ao responsável certo.

A transição entre camadas de retenção deve ser automatizada por política de ciclo de vida, sem depender de intervenção manual, e cada mudança de prazo precisa de registro formal com data, autor e justificativa. Esse rastro protege a organização quando a exclusão de dados for questionada em auditoria ou em disputa legal, pois demonstra decisão documentada e não perda acidental.

10. Erros Comuns e Pontos de Atenção

O erro mais comum é definir retenção por conveniência de armazenamento, sem considerar dwell time nem exigências legais, resultando em acervos inúteis para investigação retroativa. Outro erro frequente é medir qualidade apenas por volume ingerido, como se mais gigabytes significassem melhor telemetria, quando o correto é medir completude, precisão e latência por fonte. Ignorar fusos horários e horário de verão corrompe linhas do tempo, e a solução estrutural é UTC em toda a cadeia.

Também são recorrentes a ausência de testes sintéticos, que deixa coletas quebradas por semanas sem detecção, e a falta de imutabilidade, que permite ao adversário com privilégio apagar evidência centralizada. Duplicatas sem controle inflam custo e distorcem estatísticas. Por fim, políticas de retenção documentadas e nunca revisadas envelhecem mal, pois novas fontes e novas exigências legais surgem continuamente.

Um critério prático de sucesso para o controle é conseguir responder, sem exceção, a três perguntas em qualquer investigação: a fonte X está coletando agora, o dado chega em até 5 minutos e o histórico necessário existe em alguma camada com busca viável. Quando as três respostas são sim de forma consistente, a qualidade e a retenção de dados cumprem o papel que o Framework CTH atribui a este controle.

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

DAT.5 governa o acervo que DAT.1 a DAT.4 produzem e assegura que as regras do grupo DET e as hipóteses do grupo TH executem sobre dados confiáveis e profundos. Para o grupo IR, este controle garante a base probatória da investigação e a capacidade de determinar escopo real de comprometimento. Com o grupo MET, as métricas de qualidade se tornam indicadores do programa, e com GOV as políticas de retenção e as decisões de risco associadas a lacunas ganham rastreabilidade formal. O ciclo se fecha com CTI, na medida em que histórico profundo permite testar indicadores e TTPs novos contra o passado da própria organização.