CTI.5 - Processamento e Normalização de Dados

Nota do grupo COL (Ciclo de Inteligência: Planejamento e Coleta) da seção 15 - Framework CTH - Controles.
Deriva do Capítulo 9 do PDF de referência (controle CTI.5) e da fase de processamento do ciclo de CTI da seção 2.8.
Converte a coleta bruta de OSINT e fontes técnicas em dados estruturados, enriquecidos e prontos para análise.

1. Contexto e Posicionamento no Framework CTH

O controle CTI.5 fecha o grupo COL e ocupa a posição de ponte entre a coleta (CTI.3 e CTI.4) e a análise do ciclo de inteligência. O Capítulo 9 do Framework CTH descreve o problema com precisão: os dados brutos chegam em formatos inconsistentes, com taxonomias conflitantes e confiabilidade variável, e sem processamento rigoroso não podem ser correlacionados, analisados nem transformados em inteligência acionável. A normalização para formatos padronizados e o enriquecimento com contexto convertem essa massa dispersa em um repositório coeso e consultável.

No ciclo de CTI da seção 2.8, o processamento é a etapa que torna os dados utilizáveis pela análise, incluindo extração de indicadores e padronização de formatos como STIX e TAXII. Sem essa etapa, o programa acumula feeds sem integração, alertas sem contexto e relatórios sem dados, três sintomas que aparecem juntos quando o pipeline não existe. O investimento aqui tem retorno direto: cada melhoria de qualidade de dados se multiplica em todas as detecções, buscas e análises que consumirão o repositório.

2. Etapas do Pipeline de Processamento

O pipeline de processamento organiza-se em seis etapas sequenciais, cada uma com entrada, transformação e saída definidas. A disciplina de separar as etapas facilita a observabilidade e a correção de defeitos, porque permite medir onde o fluxo perde qualidade.

A ordem importa. Deduplicar antes de normalizar compara strings diferentes que são o mesmo objeto; enriquecer antes de deduplicar paga API repetidamente pelo mesmo indicador; classificar depois de armazenar expõe informação antes de rotular. Pipeline bem ordenado é mais barato, mais rápido e mais seguro.

3. Normalização de Indicadores

A normalização define a forma canônica de cada tipo de indicador, condição para que deduplicação, busca e correspondência funcionem. As regras a seguir cobrem os tipos mais comuns e evitam os erros clássicos de comparação.

A questão da URL merece nota técnica: existem duas variantes úteis e ambas devem ser mantidas. A URL completa, com todos os parâmetros, preserva a evidência da campanha; a URL base, com caminho e sem parâmetros, permite comparar infraestrutura e agrupar campanhas que reutilizam o mesmo hospedeiro. Guardar apenas uma das variantes reduz a capacidade analítica do repositório.

O trecho abaixo implementa as regras básicas em Python e pode servir de núcleo para o parser.

import ipaddress
from urllib.parse import urlparse, urlunparse, parse_qsl, urlencode

def normalizar_ip(valor):
    return str(ipaddress.ip_address(valor.strip()))

def normalizar_dominio(valor):
    return valor.strip().rstrip(".").lower()

def normalizar_url(valor, remover_rastreadores=True):
    partes = urlparse(valor.strip())
    pares = parse_qsl(partes.query, keep_blank_values=True)
    if remover_rastreadores:
        pares = [(k, v) for k, v in pares if not k.lower().startswith("utm_")]
    consulta = urlencode(pares)
    return urlunparse((partes.scheme.lower(), partes.netloc.lower(),
                       partes.path, partes.params, consulta, ""))

4. Enriquecimento Típico

O enriquecimento adiciona o contexto que transforma um indicador isolado em informação comparável. Cada tipo de enriquecimento responde uma pergunta específica e tem custo próprio, o que exige cache e priorização para não estourar cota de API.

O enriquecimento também é o ponto onde o pipeline mais custa dinheiro e latência. Cache com tempo de vida definido, por exemplo uma semana para reputação e um mês para idade de registro, reduz drasticamente o volume de consultas, e a fila de prioridade garante que indicadores de alta relevância sejam enriquecidos primeiro.

5. Qualidade no Processamento

A qualidade do processamento se mede pelo efeito a jusante: falsos positivos gerados por parser ruim, indicadores vencidos que poluem buscas e fontes sobrepostas que inflam contagens. O parser ruim é o mais insidioso, porque extrai "domínios" de rodapés de e-mail e IPs de exemplos de documentação; extratores precisam de regras de exclusão e de amostragem humana periódica para calibrar.

A idade do indicador é o segundo fator. Um IOC de C2 tem vida útil curta, e o CTI.5.4 trata o decaimento temporal como componente do score de confiança. A formulação do Framework CTH pondera confiabilidade da fonte com peso de 40 por cento, corroboração por múltiplas fontes com 25 por cento, idade com 20 por cento e validação interna com 15 por cento. O exemplo abaixo mostra o cálculo para dois indicadores.

A sobreposição de fontes é o terceiro fator. Dezenas de agregadores republicam os mesmos IOC de origem, e contar "confirmado em 15 fontes" quando todas derivam de uma só é erro estatístico clássico. O registro de deduplicação deve preservar a linhagem, guardando quais fontes contribuíram e qual a independência real entre elas, insumo que o CTI.5.3 exige e que a gestão de fontes do PLT.4 consome.

6. Automação do Pipeline

O CTI.5.5 define o alvo: um pipeline ETL contínuo que executa normalização, enriquecimento, deduplicação e scoring à medida que os dados chegam, com métricas de volume, latência, taxa de erro e qualidade de saída. Na prática, a automação se apoia em três elementos: agendamento declarativo, filas entre etapas e tratamento de erro com reprocessamento. A configuração abaixo ilustra um pipeline descrito em YAML.

pipeline_cti:
  agendamento: "*/30 * * * *"
  etapas:
    - nome: ingestao
      entradas: [taxii_servidor, urlhaus, otx, relatorios_parseados]
      saida: fila.bruto
    - nome: parse_extracao
      regras: [regex_ioc, validador_stix]
      quarentena: "objetos_invalidos"
    - nome: normalizacao
      padrao: "STIX 2.1, tipos ip-addr, domain-name, file.sha256, url"
    - nome: desduplicacao
      chave: "sha256 do objeto canonico"
      preserva: [fontes_contribuintes, primeiro_visto, ultimo_visto]
    - nome: enriquecimento
      servicos: [geoip, rdap, reputacao, dns_passivo]
      cache_ttl_horas: {geoip: 168, rdap: 720, reputacao: 168}
    - nome: tlp_e_scoring
      tlp_default: "AMBER"
      scoring_pesos: {fonte: 0.40, corroboracao: 0.25, idade: 0.20, interna: 0.15}
    - nome: armazenamento
      destinos: [plataforma_compartilhamento, plataforma_cti, tabelas_siem]
  metricas: [volume_entrada, volume_saida, latencia_p95_min, taxa_erro, iocs_por_fonte]
  alerta_erro: "canal-interno-cti"

O tratamento de erro merece atenção especial. Objetos inválidos vão para quarentena com motivo, e não para o lixo; etapas são idempotentes, de modo que reprocessar um lote não duplique registros; e falhas de enriquecimento não bloqueiam o fluxo, apenas deixam o indicador avançar com o contexto disponível e sinalizam pendência. Pipeline sem essas propriedades quebra silenciosamente, exatamente na semana em que a organização mais precisa dele.

7. Saída Pronta para Análise e para as Plataformas

A saída do processamento tem dois consumidores simultâneos. O primeiro é humano: o analista do CTI precisa de objetos completos, com indicador canônico, contexto enriquecido, confiança, TLP e linhagem de fontes, de modo que a análise comece da informação e não da limpeza. O segundo é automatizado: as plataformas (PLT.x) e o SIEM consomem objetos em formatos padronizados, STIX 2.1, atributos de plataforma de compartilhamento e tabelas de referência carregadas no SIEM para correspondência em tempo de busca.

A tabela abaixo resume os destinos e o formato esperado em cada um.

Latência é requisito de desenho, não detalhe. Indicadores de campanha ativa precisam chegar ao SIEM em minutos; enriquecimento profundo pode levar horas sem prejuízo. Separar o caminho rápido, do IOC técnico ao bloqueio e à busca, do caminho completo, do objeto contextualizado à análise, evita que a velocidade exigida pela operação sacrifique a profundidade exigida pela inteligência.

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

O Framework CTH organiza o controle em cinco salvaguardas progressivas, resumidas a seguir.

A implantação pode começar com um único script agendado que normalize e deduplique um feed, evoluir para enriquecimento com cache e, por fim, automatizar o fluxo completo. O marco de qualidade intermediário é simples de verificar: nenhum indicador chega à plataforma sem formato canônico, fonte identificada e score atribuído, e qualquer analista consegue responder de onde veio um registro em menos de um minuto.

9. Erros Comuns e Pontos de Atenção

• Parser permissivo demais: extrair tudo que parece IOC infla o repositório de falsos positivos e queima a confiança dos consumidores de detecção.
• Deduplicação que perde linhagem: consolidar registros descartando fontes impede auditoria, corrompe o score de corroboração e esconde fontes de baixa qualidade.
• Enriquecimento sem cache: cota de API esgotada em dias, latência alta e pipeline parado por custeio são o desfecho típico.
• Ausência de decaimento: indicadores de anos atrás aparecendo com o mesmo peso de campanhas ativas poluem buscas e bloqueios.
• Pipeline sem observabilidade: falhas silenciosas de ingestão passam despercebidas até que um incidente revele a lacuna.
• Marca TLP ausente ou errada: dados coletados como AMBER distribuídos sem marcação vazam para fóruns e quebram a confiança dos parceiros (PLT.5).
• Normalização destrutiva: descartar parâmetros da URL ou histórico de DNS no próprio processo elimina evidência que a análise precisaria depois.

Cada erro tem antídoto barato se corrigido cedo: validação com quarentena no parse, linhagem obrigatória na deduplicação, cache com tempo de vida explícito, decaimento no score, métricas por etapa e marcação TLP desde a ingestão. O custo de não corrigir aparece multiplicado na análise e na detecção.

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

O processamento é o controle que decide se a coleta se torna inteligência ou custo. Quando o pipeline entrega objetos canônicos, enriquecidos, rotulados e rastreáveis, a análise começa adiante da fase de limpeza, o hunting encontra infraestrutura agrupada em vez de listas soltas, e cada real investido em fontes se converte em resposta defensiva mensurável.