Capítulo 39 — Inteligência de ameaças e OSINT: manutenibilidade | Engenharia Inteligência de ameaças e OSINT

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

Mapa da aula

Aula 39 publicada. Mapa, exemplo, EX115.

flowchart TD
  N0["39.1 Carga de manutenção"]
  N1["39.2 Documentação para os sucessores"]
  N2["39.3 Registro de dívida técnica"]
  N3["39.4 Evolução dos padrões"]
  N4["39.5 Simplicidade"]
  N5["Nota de prática — fator ônibus"]
  N6["Política de descontinuação"]
  N7["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX115"]

Desenho lógico

flowchart LR
  N0["39.1 Carga de manutenção"]
  N1["39.2 Documentação para os sucessores"]
  N2["39.3 Registro de dívida técnica"]
  N3["39.4 Evolução dos padrões"]
  N4["39.5 Simplicidade"]
  N5["Nota de prática — fator ônibus"]
  N6["Política de descontinuação"]
  N7["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX115"]

[39.1 Carga de manutenção]
    |
    v
[39.2 Documentação para os sucessores]
    |
    v
[39.3 Registro de dívida técnica]
    |
    v
[39.4 Evolução dos padrões]
    |
    v
[39.5 Simplicidade]
    |
    v
[Nota de prática — fator ônibus]
    |
    v
[Política de descontinuação]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX115]

Objetivos de aprendizagem

Você vai (1) medir e reduzir a carga de manutenção; (2) documentar o Lantern para os sucessores; (3) gerenciar explicitamente a dívida técnica; (4) planejar a evolução dos padrões (versões de STIX/TAXII, versões do ATT&CK).

39.1 Carga de manutenção

Acompanhe as horas gastas com mudanças de formato dos parceiros, atualizações de dependências, correções de incidentes e pedidos dos analistas. Se a manutenção consome a maior parte do tempo da equipe, as novas funcionalidades devem esperar. A equipe de Kofi registra o tempo nessas categorias em seu sistema de chamados. Depois de um trimestre, os números mostraram que as mudanças de formato dos parceiros tomavam mais esforço que o esperado, principalmente porque o analisador de cada parceiro tinha código próprio. Esse achado levou a um analisador compartilhado com configuração por parceiro, o que reduziu o esforço de forma perceptível no trimestre seguinte. As categorias são revistas uma vez por ano.

39.2 Documentação para os sucessores

Visão geral da arquitetura, ADRs, roteiros, guia de configuração de parceiros, dicionário de dados e um guia da "primeira semana". Kofi testa a documentação pedindo a um engenheiro novo que acrescente um parceiro sintético usando apenas os documentos. O engenheiro novo lê os documentos sem ajuda e anota cada pergunta. Essas perguntas mostram onde os documentos supõem um conhecimento que só a equipe atual tem. Kofi mantém os documentos no mesmo repositório do código, para que uma mudança que altere o comportamento também precise atualizar a descrição na mesma revisão.

39.3 Registro de dívida técnica

Cada atalho é registrado com seu custo, seu risco e uma data-alvo: "A integração com o proxy usa consulta periódica em vez da API de envio do fornecedor; risco baixo; rever no 3º trimestre". Dívida escondida em comentários do código é esquecida. Kofi revisa o registro em cada reunião de planejamento. Itens cuja data-alvo passou são agendados, recebem uma nova data com motivo ou são aceitos como permanentes, com o risco registrado. O registro também mostra num relance a dívida total da equipe, o que ajuda a defender tempo para pagar parte dela.

39.4 Evolução dos padrões

O ATT&CK publica novas versões periodicamente, renomeando ou descontinuando técnicas. O Lantern armazena a versão do ATT&CK junto de cada mapeamento e gera um relatório de migração quando surge uma nova versão. As versões de STIX e TAXII são acompanhadas da mesma forma; suportar a 2.1 não garante compatibilidade com uma versão futura. O exemplo resolvido mostra o efeito: catorze mapeamentos precisaram de novos identificadores de técnica, e o relatório de migração encontrou todos em minutos. Os analistas então conferiram cada um à mão, porque uma técnica renomeada às vezes se divide em duas e a escolha certa depende da evidência.

39.5 Simplicidade

O projeto mais simples que atende aos requisitos é o mais fácil de manter. Remova as funcionalidades sem uso encontradas durante a validação. Kofi removeu a funcionalidade de resumo diário depois que a validação mostrou que ninguém o lia, junto com seu modelo, sua tarefa agendada e seus testes. A base de código ficou menor, e a atualização de dependências seguinte tocou menos arquivos. Cada funcionalidade mantida deve ter um usuário que notaria sua remoção. Um projeto que acrescenta opções para possíveis necessidades futuras costuma deixar código que ninguém lembra como mudar com segurança.

Nota de prática — fator ônibus

Se só uma pessoa entende o envio aos firewalls, o Lantern tem fator ônibus igual a um. Trabalho em par e rodízio espalham o conhecimento.

Política de descontinuação

Funcionalidades sem uso por dois trimestres são anunciadas como descontinuadas, recebem uma data de remoção e depois são excluídas, e os parceiros são avisados quando um formato de exportação é afetado.

Exemplo resolvido

O engenheiro novo acrescenta um parceiro sintético em 90 minutos usando o guia e anota dois passos confusos. Kofi corrige o guia. À parte, uma atualização do ATT&CK descontinua uma técnica usada em 14 mapeamentos; o relatório de migração os lista e os analistas os remapeiam em uma tarde.

Caso sintético. Os tempos e as contagens são inventados.

Erros e limites

Documentação que descreve intenções em vez da realidade engana. Fixar as versões do ATT&CK para sempre deixa os mapeamentos desatualizados.

Exercícios

EX115 — Teste da documentação. Como Kofi testou a qualidade da documentação?
Mostrar critérios de avaliação
Rubrica: 3 = engenheiro novo acrescenta parceiro sintético usando só os documentos; lacunas corrigidas; 2 = revisão por um colega; 1 = vago; 0 = nenhuma.
EX116 — Entrada de dívida. Escreva uma entrada do registro de dívida técnica para um intervalo de consulta fixo no código.
Mostrar critérios de avaliação
Rubrica: 3 = descrição, custo/risco, data-alvo; 2 = duas partes; 1 = só um comentário; 0 = nenhuma.
EX117 — Versão do ATT&CK. Por que armazenar a versão do ATT&CK com cada mapeamento?
Mostrar critérios de avaliação
Rubrica: 3 = técnicas mudam/são descontinuadas; permite o relatório de migração; 2 = parcial; 1 = desnecessário; 0 = nenhuma.

Síntese

Meça a manutenção, documente para estranhos, registre a dívida, acompanhe as versões dos padrões e mantenha os projetos simples.

Continue estudando — capítulo 39 de 50

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