Qualidade, Completude e Atualidade dos Dados

Nota do capítulo 02 (Fontes de Dados e Coleta), que fecha o ciclo de feedback sobre tudo o que o pipeline ingere.
Define as dimensões de qualidade aplicáveis a dados de CTI, as métricas por dimensão, o monitoramento de lacunas e o processo de saneamento contínuo.
Consome as regras de normalização da nota 09 e entrega evidência objetiva para decisões de fonte da automação (12) e da governança (13).

1. Contexto e Posicionamento na Biblioteca

Dado de inteligência de baixa qualidade não é apenas inútil: é ativo, e custa caro. Um falso positivo em feed automatizado bloqueia fornecedor, gera falso incidente e corrói a confiança dos times no TIP; um dado atrasado faz o time reagir a campanha encerrada; um dado incompleto impede a correlação que teria revelado a campanha inteira. A qualidade dos dados de coleta é, portanto, condição de operação, e não aprimoramento opcional, e precisa ser medida com as mesmas disciplinas de engenharia aplicadas a qualquer serviço interno: métricas, alvos, alertas e revisão periódica.

Na estrutura do capítulo, esta nota assume a existência do pipeline (08), das chaves canônicas (09) e da camada relacional (10), e transforma tudo isso em instrumentos de medição. Ela materializa a proposta do controle DAT.5 da seção 15 (qualidade e retenção de dados) aplicada especificamente ao fluxo de inteligência, e fornece os números que permitem às notas seguintes decidir com dados: quais fontes manter, quais expirar, quais exigir remediação. A pergunta permanente desta nota é objetiva: como sabemos que o dado que sustenta decisões está bom o suficiente para cada uso previsto.

2. As Cinco Dimensões de Qualidade do Dado de CTI

A qualidade de dados de CTI é multidimensional, e medi-la com um número único esconde exatamente o que interessa corrigir. Cinco dimensões cobrem o essencial na prática de mercado: precisão (o dado reflete a realidade), completude (o dado carrega os campos necessários ao uso), atualidade ou frescor (o dado está suficientemente novo para a decisão), consistência (o dado segue formatos e semântica uniformes entre fontes e ao longo do tempo) e rastreabilidade (é possível reconstruir origem e transformações do dado). A tabela abaixo define cada dimensão, a métrica típica e um alvo operacional de referência.

Duas observações sobre os alvos da tabela evitam mal-entendidos caros. Primeiro, alvo é por uso: um feed de contexto com atraso de três dias pode ser perfeitamente adequado para análise, e inaceitável para detecção automatizada, por isso a métrica deve ser segmentada pelo uso declarado da fonte e não avaliada globalmente. Segundo, precisão de fonte não é propriedade estática: muda com o tempo, com o tipo de indicador e com a mudança de curadoria na origem, motivo pelo qual a medição é contínua e comparada por janelas, e não um número fixado em contrato.

3. Métricas por Dimensão e Implementação da Medição

A medição deve viver junto do dado, em consultas programadas sobre a base de ingestão, e não em planilha avulsa de revisão trimestral. O exemplo abaixo, em SQL, calcula por fonte os três indicadores de maior retorno operacional: completude de campos obrigatórios, atraso médio de ingestão e volume de falso positivo registrado por triagem, em janela móvel de trinta dias:

SELECT
  fonte,
  ROUND(100.0 * SUM(CASE WHEN valor_canonico IS NOT NULL
                          AND confianca IS NOT NULL
                          AND primeiro_visto IS NOT NULL
                       THEN 1 ELSE 0 END) / COUNT(*), 2) AS completude_pct,
  ROUND(AVG(EXTRACT(EPOCH FROM (hora_ingestao - primeiro_visto)) / 3600.0), 2)
      AS atraso_medio_horas,
  SUM(CASE WHEN marcado_falso_positivo THEN 1 ELSE 0 END) AS falsos_positivos,
  COUNT(*) AS total_registros
FROM indicadores_ingestao
WHERE hora_ingestao >= CURRENT_DATE - INTERVAL '30' DAY
GROUP BY fonte
ORDER BY falsos_positivos DESC;

O acompanhamento da taxa de rejeição na ingestão complementa o quadro e costuma ser o primeiro sintoma de problema na fonte: um feed que salta de 1 para 40 por cento de rejeição mudou algo, e a mudança foi percebida antes de contaminar a base. No pipeline da nota 08, o contador de rejeições por motivo (schema inválido, tipo desconhecido, punycode quebrado) já existe na DLQ; aqui ele vira série temporal por fonte, com alerta por desvio relativo, por exemplo, quando a rejeição de uma fonte dobra em relação à mediana dos últimos quatorze dias.

Cada dimensão tem um ponto natural de medição, e forçar todas as medições no mesmo lugar dilui a precisão do instrumento. A tabela abaixo mapeia cada dimensão ao ponto de coleta e ao instrumento recomendado, servindo de guia para implementar as métricas nos lugares certos da plataforma:

Para atualidade, a medição útil é distribuição de idade, e não média, porque caudas longas escondem problemas: um feed pode ter mediana de duas horas e ainda assim carregar 20 por cento dos registros com mais de uma semana. A prática recomendada é acompanhar percentis 50 e 95 por fonte e por classe de indicador, com SLO separado por classe, já que hash de malware tolera idade que um IP de C2 ativo não tolera. A rastreabilidade, por fim, se mede como conformidade binária por registro: ou o registro carrega origem, hash de ingestão e cadeia de estágios, ou não entra em produção, sem porcentagem aceitável abaixo de cem, pois a falta de rastreabilidade invalida auditoria e correção em massa.

4. Monitoramento de Lacunas de Cobertura

Qualidade por fonte não basta: é preciso vigiar as lacunas entre o que o ambiente precisa e o que a coleta entrega, alinhada aos requisitos de inteligência (PIRs) definidos na fase de planejamento. O instrumento central é a matriz de cobertura, que cruza cada PIR com as fontes que o atendem e com o grau de atendimento, revelando células vazias que nenhum painel por fonte revelaria. A matriz abaixo ilustra o formato com um exemplo hipotético de organização monitorando fraude financeira e ransomware:

Cada célula de lacuna deve gerar decisão documentada: integrar fonte nova, ampliar fonte existente ou aceitar formalmente a lacuna com justificativa de risco. Lacuna aceita sem registro é a pior das saídas, porque reaparece em toda discussão futura como surpresa. A revisão da matriz segue a cadência do ciclo de inteligência, mensal na prática da maioria dos times, com atualização extraordinária após incidentes relevantes, quando costuma ficar claro qual dado faltou para antecipar ou acelerar a resposta.

Além da matriz estratégica, o monitoramento operacional de saúde por fonte roda diariamente e verifica três condições simples: a fonte publicou dentro da janela esperada, o volume está dentro da faixa histórica e a taxa de rejeição está sob controle. A configuração declarativa abaixo, um registro por fonte no repositório do time, torna o critério de saúde explícito e auditável, em vez de depender da memória de quem integrou a fonte:

fonte: feed_comercial_infra_c2
tipo_principal: ipv4
janela_publicacao_horas: 24
volume_minimo_dia: 300
volume_maximo_dia: 200000
rejeicao_maxima_pct: 5.0
slo_atualidade_horas: 6
acao_em_violacao: alertar_canal_cti_ingestao
dono: equipe_inteligencia

5. Testes Sintéticos de Ponta a Ponta

As métricas das seções anteriores medem o dado que chega; os testes sintéticos verificam se o caminho completo de coleta funciona quando deveria. A técnica é simples e potente: uma fonte de teste interna publica valores conhecidos em cadência fixa, e jobs verificam o tempo até cada valor aparecer em cada destino declarado (TIP, watchlist do SIEM, visão de consulta do EDR). Diferente das métricas de fila e de saúde por fonte, que avisam sobre componentes individuais, o teste sintético mede a promessa inteira do capítulo: um indicador publicado às 9h está consultável para detecção quando?

A configuração declarativa abaixo ilustra um teste sintético de ingestão com três verificações encadeadas e janelas máximas por destino. Os valores de teste usam faixas reservadas de documentação (como 203.0.113.0/24) e subdomínios internos que nunca resolvem externamente, garantindo que o canário não contamina detecção real nem causa tráfego indesejado:

teste_sintetico:
  id: canario_ingestao_001
  frequencia_horas: 6
  fonte: feed_interno_teste
  observaveis:
    - tipo: domain
      valor: "canario-<uuid>.teste.interno"
    - tipo: ipv4
      valor: "203.0.113.77"
  verificacoes:
    - destino: tip
      janela_max_minutos: 60
    - destino: watchlist_siem
      janela_max_minutos: 90
    - destino: consulta_edr
      janela_max_minutos: 120
  em_falha: alertar_canal_cti_ingestao

Além de medir atualidade de ponta a ponta, o teste sintético cumpre dois papéis de engenharia que as métricas passivas não cobrem. Ele detecta quebra silenciosa de caminho: uma mudança de regra na watchlist do SIEM pode fazer o canário deixar de aparecer mesmo com fila, worker e TIP saudáveis, e é exatamente essa classe de falha que só se revela com dado conhecido atravessando o sistema. E ele valida as mudanças de configuração: todo ajuste de filtro, de parse ou de distribuição deve ser seguido de um ciclo do canário verde antes de considerar a mudança concluída, no mesmo espírito dos testes sintéticos de telemetria aplicados aos coletores de endpoint pela seção 15.

O desenho do canário precisa de três cuidados para não virar ruído. Os valores devem girar a cada execução (UUID no domínio, IPs rotativos dentro da faixa reservada), impedindo que deduplicação e TTL os masquem; o resultado deve virar série temporal por destino, permitindo comparar janelas antes e depois de mudanças; e as janelas máximas devem derivar dos SLO de atualidade definidos para cada classe de uso, e não de números arbitrários. Canário que falha com frequência sem acionar ação correta é removido da lista de confiança operacional, e o alerta dele passa a ser tratado como problema do próprio teste, e não da coleta.

6. Processo de Saneamento e o Ciclo de Feedback

Saneamento é o processo contínuo que corrige, isola em quarentena e expira dados que as métricas denunciaram, e precisa ser desenhado como fluxo regular, e não como campanha esporádica de faxina. O fluxo recomendado tem quatro portas de entrada: rejeição na ingestão (dado malformado nunca entra), quarentena automática (dado que entra com sinal de inconsistência, como confiança ausente ou valor já marcado como falso positivo histórico), denúncia a jusante (analista ou SOAR marca falso positivo no TIP durante triagem) e revisão programada (jobs que revalidam amostras de indicadores contra critérios objetivos, como resolução DNS inexistente ou domínio registrado por provedor legítimo).

Cada porta de entrada converge para ações padronizadas com registro: corrigir (quando o problema é de formato e a correção é determinística), rebaixar confiança (quando o dado parece correto, mas o julgamento é duvidoso), etiquetar com contexto (por exemplo, infraestrutura de provedor compartilhado) ou expirar antecipadamente (quando a evidência de invalidação é forte). Toda ação carrega autor, motivo e referência à evidência, porque o saneamento sem registro destrói a rastreabilidade que a dimensão 5 da seção 2 exige. As listas de exclusão estrutural merecem menção especial: faixas RFC 1918, faixas de documentação, domínios da própria organização e provedores críticos conhecidos são filtrados por política declarada, e não por decisão ad hoc de cada analista.

O fechamento do ciclo é o que transforma qualidade em sistema: os números de falso positivo por fonte alimentam a pontuação de confiança aplicada na deduplicação (09), a matriz de cobertura alimenta o planejamento de fontes da automação (12) e as decisões de expiração alimentam a política de retenção da governança (13). Na prática consolidada dos times maduros, esse ciclo roda com duas cadências: semanal para operacional (saúde de fontes, DLQ, quarentena) e trimestral para estratégico (matriz de cobertura, revisão de pesos e alvos). A tabela abaixo organiza o checklist de auditoria que sustenta as duas cadências, com a evidência que cada item deve produzir:

A cadência mínima viável depende do volume, mas a existência das duas rotinas, com dono e ata de decisão, é o que separa o monitoramento de dados da mera curiosidade estatística. Em times pequenos, o mesmo analista pode executar os dois rituais, desde que os registros fiquem separados e a revisão trimestral não seja absorvida pela rotina semanal. A saída de cada reunião deve ser um delta comprovável, como ajuste de peso, exclusão de fonte, novo SLO ou aceitação formal de lacuna, e o histórico desses deltas é, ao fim do ano, a própria trajetória de maturidade da coleta documentada em atos.

7. Erros Comuns e Pontos de Atenção

O erro mais comum é medir apenas volume, tratando feed produtivo como feed bom; volume sem precisão e sem acionamento é custo disfarçado de cobertura. O segundo é medir qualidade apenas global, sem segmentar por fonte e por classe de indicador, o que esconde a fonte problemática atrás da média da massa. O terceiro é tratar a taxa de falso positivo como número de alerta imediato, punindo a fonte sem investigar se o problema é de uso (indicador de detecção usado em bloqueio) e não de dado, confusão de política mais frequente do que se admite.

No saneamento, os erros clássicos são a faxina esporádica sem registro (que resolve a base e destrói a rastreabilidade), a exclusão silenciosa de registros conflitantes (perdendo a informação de que dois feeds discordam, que é exatamente a informação que a análise precisa) e a ausência de loop de volta para a fonte: falso positivo identificado deve chegar ao feed, quando possível, como feedback formal, e a resposta ou o silêncio dela deve entrar no histórico que orienta a renovação do contrato. Nenhum número desta nota vale algo se não altera decisão de compra, de integração ou de expiração.

Um ponto final de atenção é a fronteira entre qualidade do dado e qualidade do julgamento. Um indicador pode estar tecnicamente perfeito (resolve, está ativo, é o que a fonte diz) e ainda assim ser ruim para o uso, como um IP de scanner de massa usado para bloqueio. Por isso as métricas aqui devem ser lidas junto com as métricas de acionamento e de utilidade do capítulo 11 (indicadores e métricas do programa), que medem o que a detecção fez com o dado. Dado bom para um uso e ruim para outro não é paradoxo: é o estado normal, e o desenho da distribuição precisa refletir isso desde a origem.

8. Integração com o Restante da Biblioteca

Esta nota fecha o loop de feedback do capítulo 02: as métricas aqui definidas orientam a coleta da automação (12), que ajusta fontes, quotas e caches conforme precisão e atualidade medidas, e orientam a governança (13), que decide retenção e descarte com base na utilidade comprovada. A montante, ela consome o contrato de mensagens do pipeline (08) e as chaves canônicas da normalização (09), sem as quais as métricas de duplicação e de rejeição seriam inatingíveis. Com a resolução de entidades (10), o laço é de auditoria: a amostragem de correlações fortes descrita lá usa o mesmo mecanismo de revisão por evidência aqui estabelecido.

Em relação à biblioteca como um todo, a matriz de cobertura por PIR é a ponte direta com o capítulo de planejamento do ciclo de inteligência e com o controle CTI.1 da seção 15 (requisitos de inteligência), garantindo que a coleta responda a necessidades declaradas e não a oportunidade de feed disponível. As métricas por dimensão alimentam os KPIs de fonte do grupo MET da seção 15, e o processo de saneamento apoia diretamente a confiabilidade exigida pelos controles de bloqueio da PRT. A evolução natural, para times maduros, é publicar os painéis de qualidade para as próprias fontes e parceiros de confiança (TLP compatível), transformando transparência de qualidade em moeda de troca nas comunidades de compartilhamento.