Engenharia de Dados e Pipelines de CTI

Nota 08 do capítulo 09 (Ferramentas e Plataformas), que trata a CTI como problema de engenharia de dados em escala.
Define a arquitetura de pipeline que leva fontes brutas de inteligência até produtos consumíveis por analistas, SIEM e SOAR.
Dialoga com a nota 08 do capítulo 02 (pipeline de coleta e enriquecimento), com a nota 09 do capítulo 02 (normalização) e com os controles COL.5 e AUT do capítulo 15.

1. Contexto e Posicionamento na Biblioteca

As notas de coleta do capítulo 02 mostram o que buscar; esta nota mostra como sustentar a operação quando o volume passa de dezenas de fontes e milhões de indicadores por dia. Engenharia de dados é a disciplina que transforma coleta artesanal de CTI, feita em scripts pontuais e planilhas, em um serviço interno com contratos de schema, metas de latência, custo medido e qualidade auditada. Sem essa disciplina, o time de inteligência passa mais tempo consertando crawlers e feeds corrompidos do que produzindo análise, e o time de hunting desconfia dos dados que consome.

O posicionamento dentro do ciclo de inteligência é preciso: a engenharia de dados habita a etapa de processamento, entre a coleta e a análise. Ela recebe feeds OSINT, licenciados, ISACs e saídas de sandboxes pela nota 08 do capítulo 02, entrega produtos normalizados e enriquecidos ao OpenCTI ou MISP da nota 04 do capítulo 03, e publica datasets para as caças do capítulo 07. O critério de sucesso não é a sofisticação da stack, mas três propriedades: o dado chega rápido, o dado é confiável e o dado tem custo conhecido por camada de retenção.

2. O Papel da Engenharia de Dados no CTI-TH

Três problemas operacionais justificam a existência do papel. Volume e heterogeneidade: uma operação séria consome feeds em STIX, CSV, JSON e texto corrido, com campos homônimos de semântica distinta, e nenhuma análise escala sobre essa sopa sem normalização. Qualidade: feeds de baixa procedência injetam falsos positivos direto no SIEM, e sem pipeline com validação e deduplicação o rateio de falso positivo vira custo do time de detecção. Reversibilidade: quando um feed muda de schema ou um enriquecimento é revogado, só um pipeline com dado bruto imutável armazenado permite reprocessar o histórico sem recoordenar tudo.

O engenheiro de dados de CTI cumpre funções específicas dentro do time de inteligência. Mantém conectores de coleta com agendamento, backoff e alerta de falha; define e evolui o schema canônico de indicadores, com revisão documentada; implementa transformações idempotentes e testadas; opera o enriquecimento com orçamento de API; e publica contratos de saída para os consumidores, SIEM, TIP e notebooks de hunting. É um papel de software com sensibilidade de analista: o produto final é decisão, não apenas dado.

3. Arquitetura de Pipeline: Estágios e Contratos

O pipeline canônico tem cinco estágios, cada um com contrato de entrada e de saída. A coleta extrai das fontes sem transformar, preservando payload bruto e metadados de proveniência (URL, horário, versão do feed). A camada de stream faz parse, validação de sintaxe (IP, domínio, hash, URL), deduplicação por janela e normalização para o schema canônico. O enriquecimento adiciona atributos derivados de forma assíncrona: reputação, geolocalização, WHOIS, passive DNS, com cache e rate limit conforme a nota 09. O armazenamento persiste em lake colunar particionado, e a distribuição publica marts curados para os consumidores.

O diagrama abaixo resume o desenho de referência que os exemplos desta nota implementam:

Fontes de CTI (OSINT, feeds licenciados, ISAC, MISP, TAXII, sandboxes)
   |
   v
[1] Coleta: conectores agendados e webhooks, payload bruto imutável
   |
   v
[2] Topicos Kafka: cti.raw (particionado por fonte)
   |
   v
[3] Stream Flink: parse, validacao, dedup, normalizacao para schema canonico
   |                            \
   v                             v
[4] Enriquecimento assincrono:   [5] Lake S3: Parquet particionado por data e fonte,
reputacao, geo, WHOIS, pDNS      bruto e normalizado, reprocessavel
   |                             |
   v                             v
[6] Marts dbt: iocs_validos, reputacoes, ttps_por_ator
   |
   v
[7] Distribuicao: OpenCTI, SIEM, SOAR, notebooks de hunting

Dois princípios de desenho valem mais que qualquer tecnologia. Primeiro, dado bruto é sagrado: nunca transforme no coletor, porque transformação precoce é irreversível. Segundo, idempotência em todos os estágios: rodar o estágio duas vezes sobre a mesma entrada produz o mesmo resultado, propriedade que permite reprocessar histórico e recuperar de incidentes de pipeline sem duplicar indicadores.

4. Tecnologias de Referência

A escolha deve seguir o tamanho da operação. Um time pequeno roda o pipeline inteiro com Python, SQLite e agendador simples; a stack Kafka e Flink entra quando a coleta passa de dezenas de fontes ativas e o reprocessamento se torna rotina. O antipadrão a evitar é adotar todas as peças de uma vez, gerando complexidade sem consumidores para os dados, e o contrário também vale: times grandes com planilha de IOCs em CSV compartilhado por e-mail têm problema de engenharia, não de ferramenta.

5. Exemplos Práticos de Configuração

A configuração de tópicos abaixo materializa o contrato de desacoplamento: o bruto fica disponível por 72 horas para reprocessamento rápido, o normalizado por uma semana para consumidores online, e tudo é persistido em Parquet por outro caminho:

topicos:
  - nome: cti.raw.feeds
    particoes: 12
    fator_replicacao: 3
    retencao_horas: 72
  - nome: cti.norm.indicadores
    particoes: 12
    fator_replicacao: 3
    retencao_horas: 168
  - nome: cti.enriquecido
    particoes: 6
    fator_replicacao: 3
    retencao_horas: 168

O modelo dbt abaixo publica o mart iocs_validos, com deduplicação por valor e tipo, filtro de confiança mínima e janela de validade, contrato que o SIEM e os notebooks de hunting consomem como tabela única e estável:

-- models/marts/iocs_validos.sql
WITH dedup AS (
  SELECT
    LOWER(TRIM(valor)) AS ioc,
    tipo,
    fonte,
    primeiro_visto,
    ultimo_visto,
    confianca,
    tlp,
    ROW_NUMBER() OVER (
      PARTITION BY LOWER(TRIM(valor)), tipo
      ORDER BY confianca DESC, ultimo_visto DESC
    ) AS posicao
  FROM {{ ref('stg_indicadores_brutos') }}
  WHERE tipo IN ('ip', 'dominio', 'url', 'sha256')
    AND confianca >= 60
    AND ultimo_visto >= DATE_SUB(CURRENT_DATE(), 90)
)
SELECT * FROM dedup WHERE posicao = 1

O teste de qualidade em dbt fecha o ciclo de confiabilidade, e cada falha dispara alerta para o time antes que o dado corrompido chegue ao consumidor:

models:
  - name: iocs_validos
    columns:
      - name: ioc
        tests: [not_null, unique]
      - name: tipo
        tests:
          - accepted_values: {values: [ip, dominio, url, sha256]}
      - name: confianca
        tests:
          - dbt_utils.accepted_range: {min_value: 0, max_value: 100}

6. Custo, Retenção em Camadas e SLOs

Custo em pipeline de CTI concentra-se em três rubricas: processamento de stream, armazenamento do lake e quota de APIs de enriquecimento. A disciplina de camadas resolve a maior parte do armazenamento: índices quentes no SIEM são caros e não devem reter inteligência bruta por anos; o Parquet comprime indicadores em proporções altas e custa ordens de magnitude menos por terabyte. O ciclo de vida do bucket (lifecycle) automatiza a transição, e a recompressão periódica de arquivos pequenos em arquivos maiores corta o custo de leitura do Athena ou do Trino.

SLOs transformam o pipeline em serviço com responsabilidade mensurável. As metas abaixo são um ponto de partida realista para uma operação de tamanho médio, e cada violação deve gerar revisão documentada, não apenas correção silenciosa:

7. Erros Comuns e Pontos de Atenção

O erro estrutural mais comum é transformar no coletor, quebrando a reversibilidade e amarrando o histórico ao schema do dia da coleta; o segundo é deduplicar cedo demais com chaves incompletas, o que funde indicadores distintos, como o mesmo domínio observado em campanhas diferentes. Times também tratam enriquecimento como etapa síncrona obrigatória, e uma API lenta então trava todo o stream; o desenho da nota 09 resolve isso com assincronia e cache. Outro erro recorrente é medir o pipeline por volume ingerido, que incentiva feeds baratos e sujos, em vez de medir por SLO de latência e taxa de erro, que medem serviço.

Na governança, atenção a dois riscos silenciosos. Schema drift de feeds quebra parse em silêncio e o pipeline continua rodando com menos dados; a defesa é teste de contrato por fonte com alerta imediato. E retenção indefinida sem base legal vira passivo, porque indicadores carregam contexto de investigação; o ciclo de vida da nota 13 do capítulo 02 deve ser aplicado ao lake com o mesmo rigor aplicado ao SIEM.

8. Integração com o Restante da Biblioteca

Esta nota é a infraestrutura que as notas conceituais assumem existir. A coleta do capítulo 02 fornece as fontes; a normalização da nota 09 do capítulo 02 vira estágio Flink aqui; a pontuação e priorização da nota 05 do capítulo 05 vira regra no mart dbt; o hunting do capítulo 07 consome os marts nos notebooks; e o ciclo AUT do capítulo 15 orquestra execuções e alertas. A nota 09 deste capítulo detalha o estágio de enriquecimento que aqui apareceu como caixa preta, com cache, rate limit e riscos de OPSEC.

O leitor deve sair desta nota com o desenho de cinco estágios memorizado, a disciplina de dado bruto imutável internalizada e o hábito de expressar compromissos de pipeline como SLO. A métrica de sucesso final é dupla: o analista confia no dado que consome sem validar manualmente, e o custo por terabyte por mês é conhecido no dashboard, não na fatura surpresa.