◇ OpenCyber Academy
Engenharia · Capítulo 28 · Português

Capítulo 28 — Inteligência de ameaças e OSINT: implementação I

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Capítulo 28 — Inteligência de ameaças e OSINT: implementação I

Mapa da aula

Aula 28 publicada. Mapa, exemplo, EX082.

flowchart TD
  N0["28.1 Etapa do cliente"]
  N1["28.2 Validação e normalização"]
  N2["28.3 Filas"]
  N3["28.4 Métricas desde o primeiro dia"]
  N4["28.5 Servidor substituto sintético"]
  N5["Configuração dos parceiros"]
  N6["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX082"]

Desenho lógico

flowchart LR
  N0["28.1 Etapa do cliente"]
  N1["28.2 Validação e normalização"]
  N2["28.3 Filas"]
  N3["28.4 Métricas desde o primeiro dia"]
  N4["28.5 Servidor substituto sintético"]
  N5["Configuração dos parceiros"]
  N6["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX082"]

[28.1 Etapa do cliente]
    |
    v
[28.2 Validação e normalização]
    |
    v
[28.3 Filas]
    |
    v
[28.4 Métricas desde o primeiro dia]
    |
    v
[28.5 Servidor substituto sintético]
    |
    v
[Configuração dos parceiros]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX082]

Objetivos de aprendizagem

Você vai (1) implementar uma etapa de cliente TAXII 2.1 contra um servidor substituto sintético; (2) implementar as etapas de validação e normalização; (3) ligar as etapas com filas limitadas; (4) produzir métricas visíveis ao operador desde a primeira versão.

28.1 Etapa do cliente

O cliente descobre a raiz da API, lista as coleções permitidas e pede os objetos acrescentados depois do último ponto de controle salvo. Ele segue a paginação até o fim e só armazena o novo ponto de controle depois que o lote foi gravado com segurança, de modo que uma queda causa uma nova busca, e não uma lacuna. A ordem importa, como mostra o exemplo resolvido. Um ponto de controle salvo antes da gravação marca como recebidos objetos que não foram. Salvar depois da gravação significa que uma queda entre as duas etapas busca alguns objetos duas vezes, o que o armazenamento suporta porque as gravações são indexadas pelo identificador e gravações repetidas não mudam nada.

28.2 Validação e normalização

A validação impõe as propriedades obrigatórias do STIX e o formato do identificador. A normalização aplica as regras documentadas no Capítulo 13. As duas etapas emitem rejeições com motivos. Rodar a validação antes da normalização significa que as regras de formato são verificadas sobre o que o parceiro de fato enviou. Normalizar primeiro poderia esconder um valor malformado, transformando-o em algo que parece válido. Os registros da etapa de Kofi mostram contagens por fonte e por motivo, que viram os relatórios de qualidade dos parceiros. Um registro rejeitado aqui nunca chega ao armazenamento, então nenhum analista vê um valor limpo pela metade.

28.3 Filas

Filas limitadas ligam as etapas. Se o enriquecimento fica lento, a validação enche sua fila de saída e espera; o cliente pausa. Isso protege a memória e torna a lentidão visível. Kofi escolheu os tamanhos das filas a partir do uso de memória medido por objeto e de um limite que deixa espaço para o resto do host. Quando uma fila fica cheia por mais de alguns minutos, um alerta diz ao operador qual etapa está lenta. Filas ilimitadas esconderiam a lentidão até a memória acabar e o coletor inteiro parar de uma vez.

28.4 Métricas desde o primeiro dia

Objetos recebidos, aceitos e rejeitados por fonte; profundidade das filas; idade do ponto de controle; duração da consulta. Métricas são baratas de acrescentar cedo e caras de adaptar depois. Kofi acrescentou esses contadores na primeira semana, antes de qualquer trabalho de desempenho. Em poucos dias eles mostraram que as consultas a um parceiro demoravam muito mais que as demais, o que se revelou um servidor lento do lado do parceiro, e não um problema do Lantern. Sem a métrica de duração da consulta, a equipe poderia ter passado dias analisando o código errado. Cada métrica tem uma descrição curta e um responsável no painel.

28.5 Servidor substituto sintético

O desenvolvimento usa um substituto local que serve pacotes STIX sintéticos no formato TAXII 2.1. Nenhum tráfego de desenvolvimento toca os servidores dos parceiros, o que protege os parceiros e mantém os testes reproduzíveis. O substituto serve pacotes fixos a partir de arquivos, incluindo malformados para testes de erro, e pode ser instruído a responder devagar ou a recusar requisições. Isso permite à equipe testar tempos limite e recuos sem pedir a um parceiro um servidor quebrado. Como os pacotes são fixos, um teste que passa hoje passará amanhã, a menos que o código tenha mudado.

Configuração dos parceiros

Cada entrada de parceiro na configuração indica a raiz da API, as coleções, o intervalo de consulta, a referência da credencial e o contato de dados. Acrescentar um parceiro é uma mudança de configuração revisada, não uma mudança de código, o que mantém genérica a etapa do cliente e torna auditável a própria lista de parceiros. Remover um parceiro segue as etapas de desativação do Capítulo 16.

Exemplo resolvido

Na primeira execução de teste, o cliente salvou o ponto de controle antes de gravar o lote; uma queda forçada então perdeu 200 objetos. Kofi inverte as etapas — gravar, depois salvar o ponto de controle — e acrescenta um teste que provoca uma queda entre elas e verifica que nada se perde.

Caso sintético. O defeito e as contagens são inventados.

Erros e limites

Entrega exatamente uma vez é difícil; projete para pelo menos uma vez com gravações idempotentes. Testar contra servidores reais de parceiros não é aceitável no desenvolvimento.

Exercícios

Síntese

Salve o ponto de controle depois de gravar, valide e normalize com rejeições, limite as filas e entregue métricas com a primeira versão.

Continue estudando — capítulo 28 de 50

← Capítulo 27 (rascunho) · Índice de capítulos do curso · Capítulo 29 (rascunho) →