Capítulo 38 — Inteligência de ameaças e OSINT: validação
Mapa da aula
Aula 38 publicada. Mapa, exemplo, EX112.
flowchart TD
N0["38.1 Perguntas de validação"]
N1["38.2 Cenários de aceitação"]
N2["38.3 Impacto nas decisões"]
N3["38.4 Quando os requisitos estavam errados"]
N4["38.5 Observadores independentes"]
N5["Nota de prática — resultados negativos"]
N6["Laço de retorno"]
N7["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX112"]
Desenho lógico
flowchart LR
N0["38.1 Perguntas de validação"]
N1["38.2 Cenários de aceitação"]
N2["38.3 Impacto nas decisões"]
N3["38.4 Quando os requisitos estavam errados"]
N4["38.5 Observadores independentes"]
N5["Nota de prática — resultados negativos"]
N6["Laço de retorno"]
N7["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX112"]
[38.1 Perguntas de validação]
|
v
[38.2 Cenários de aceitação]
|
v
[38.3 Impacto nas decisões]
|
v
[38.4 Quando os requisitos estavam errados]
|
v
[38.5 Observadores independentes]
|
v
[Nota de prática — resultados negativos]
|
v
[Laço de retorno]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX112]
Objetivos de aprendizagem
Você vai (1) validar o Lantern contra as necessidades reais das partes interessadas; (2) projetar cenários de aceitação com os operadores; (3) medir o impacto nas decisões, e não apenas métricas do sistema; (4) tratar achados de que os requisitos estavam errados.
38.1 Perguntas de validação
O SOC bloqueia as ameaças mais cedo? Os engenheiros de OT recebem alertas sobre fornecedores e agem a partir deles? Os executivos entendem os briefings estratégicos? Essas perguntas tratam de resultados; as métricas do sistema, sozinhas, não conseguem respondê-las. Kofi leva cada pergunta às pessoas envolvidas e pergunta como elas reconheceriam uma resposta. O líder do SOC sugeriu comparar os tempos entre a publicação e a aplicação antes e depois do Lantern. Os engenheiros de OT quiseram contar os alertas sobre fornecedores que levaram a alguma ação. Os executivos foram perguntados diretamente se o briefing estratégico mudou alguma decisão durante o trimestre.
38.2 Cenários de aceitação
Com os operadores, Kofi escreve cenários: "Um parceiro compartilha uma campanha de phishing contra concessionárias às 09:00; até as 09:30 os bloqueios de domínio estão ativos, existe um chamado com contexto do ATT&CK e o analista de plantão procurou contatos anteriores." Os cenários rodam com dados sintéticos em um ambiente de homologação que espelha a produção. O cenário inclui tanto os passos humanos quanto os do sistema, porque um bloqueio que chega a tempo, mas não deixa chamado, ainda falharia com o analista de plantão. Rodá-lo em homologação permite aos operadores ensaiar sem risco para a produção.
38.3 Impacto nas decisões
Meça antes e depois do Lantern: o tempo mediano entre a publicação externa e a aplicação; a porcentagem de incidentes em que havia contexto de inteligência disponível na triagem; as decisões executivas que citaram um briefing estratégico. Algumas medidas são grosseiras; relate-as com seus limites. Kofi reuniu os números anteriores a partir dos chamados e dos registros de e-mail do processo manual, menos precisos que os registros do Lantern. Ele relatou a comparação com essa ressalva. Contar as decisões executivas que citaram um briefing depende das atas das reuniões, que podem não mencionar todas as influências. Medidas grosseiras ainda são melhores que nenhuma, desde que os leitores saibam o quanto são grosseiras.
38.4 Quando os requisitos estavam errados
A validação pode mostrar que um requisito verificado não serve a ninguém — por exemplo, um resumo diário que ninguém lê. Esse é um achado valioso: mude o requisito, não a medição. O exemplo resolvido mostra uma segunda forma da mesma lição: os alertas sobre fornecedores eram entregues conforme exigido, mas em uma caixa de entrada que ninguém acompanhava. O sistema passou em seu teste de verificação e ainda assim falhou com seus usuários. Kofi mudou o requisito para nomear o destino que a equipe de OT de fato usa e depois escreveu um novo procedimento de verificação para ele.
38.5 Observadores independentes
Alguém de fora da equipe de construção observa as execuções dos cenários e entrevista os usuários, reduzindo a tentação de declarar sucesso. Kofi pediu a uma colega da equipe de auditoria interna da BEN que observasse. Ela notou que, em um cenário, um analista executou um passo manual que o projeto não descrevia, o que revelou uma lacuna na interface. Seu relatório foi anexado ao registro de validação sem edições da equipe de construção. Os usuários também falaram com ela mais livremente do que com os engenheiros que construíram o sistema, e duas de suas reclamações viraram itens de backlog.
Nota de prática — resultados negativos
Se um cenário mostra que o Lantern não acrescenta nada a uma decisão, registre isso com clareza. Resultados de validação negativos justificam aposentar funcionalidades e poupam esforço de manutenção.
Laço de retorno
Os achados de validação entram no plano da versão seguinte com responsáveis, e o cenário é executado de novo depois da mudança para confirmar que o resultado melhorou.
Exemplo resolvido
O tempo mediano entre a publicação pelo parceiro e a aplicação no DNS caiu de 9 horas (processo manual) para 25 minutos. Mas os engenheiros de OT relataram que os alertas sobre fornecedores chegavam a uma caixa de entrada que eles raramente consultam. O requisito é mudado para entregar os alertas sobre fornecedores na fila de chamados da equipe de OT.
Caso sintético. Os números são inventados.
Erros e limites
Comparações de antes e depois podem ser confundidas por outras mudanças; anote as mudanças simultâneas. Elogios dos usuários não são medição.
Exercícios
- EX112 — Pergunta de resultado. Escreva uma pergunta de validação sobre o Lantern que uma métrica do sistema não consiga responder sozinha. Rubrica: 3 = pergunta focada em resultado/decisão; 2 = mista; 1 = métrica do sistema; 0 = nenhuma.
- EX113 — Requisito errado. O que deve acontecer com o requisito de entrega dos alertas sobre fornecedores? Rubrica: 3 = mudar para a fila de chamados de OT com base na validação; 2 = mudar, de forma vaga; 1 = manter a caixa de entrada; 0 = nenhuma.
- EX114 — Ganho confundido. Cite uma mudança simultânea que poderia confundir a melhoria de 9 h → 25 min. Rubrica: 3 = mudança simultânea plausível (nova equipe, novo produto de DNS, mudança de política); 2 = vago; 1 = nenhuma possível; 0 = nenhuma.
Síntese
Valide os resultados com os operadores, meça as decisões, aceite que os requisitos podem estar errados e use observadores independentes.
Continue estudando — capítulo 38 de 50
← Capítulo 37 (rascunho) · Índice de capítulos do curso · Capítulo 39 (rascunho) →