Capítulo 23 — Inteligência de ameaças e OSINT: análise de ameaças e falhas
Mapa da aula
Aula 23 publicada. Mapa, exemplo, EX067.
flowchart TD
N0["23.1 Ameaças ao Lantern"]
N1["23.2 FMEA"]
N2["23.3 Linhas de exemplo"]
N3["23.4 Agindo a partir da classificação"]
N4["23.5 Acidentes"]
N5["Nota de prática — Casos de abuso"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX067"]
Desenho lógico
flowchart LR
N0["23.1 Ameaças ao Lantern"]
N1["23.2 FMEA"]
N2["23.3 Linhas de exemplo"]
N3["23.4 Agindo a partir da classificação"]
N4["23.5 Acidentes"]
N5["Nota de prática — Casos de abuso"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX067"]
[23.1 Ameaças ao Lantern]
|
v
[23.2 FMEA]
|
v
[23.3 Linhas de exemplo]
|
v
[23.4 Agindo a partir da classificação]
|
v
[23.5 Acidentes]
|
v
[Nota de prática — Casos de abuso]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX067]
Objetivos de aprendizagem
Você vai (1) modelar as ameaças à própria plataforma de CTI; (2) realizar uma análise de modos de falha e efeitos (FMEA); (3) classificar riscos por severidade, ocorrência e detecção; (4) mapear técnicas de adversários contra o Lantern usando IDs do ATT&CK.
23.1 Ameaças ao Lantern
Envenenamento de feeds, roubo de credenciais (T1078 Valid Accounts), comprometimento da cadeia de suprimentos de uma dependência (T1195), exfiltração de relatórios restritos e negação de serviço por feeds superdimensionados. Cada ameaça corresponde a um controle. Kofi escreveu cada ameaça como um cenário curto, com o objetivo do atacante e o caminho que ele seguiria. O envenenamento, por exemplo, poderia vir de um parceiro comprometido ou de uma entrega forjada. Escrever o caminho mostra qual controle o interrompe: verificações de assinatura barram a falsificação, mas não um parceiro comprometido, que exige verificações de anomalia. Os cenários ficam junto ao registro de riscos e são revistos quando um componente muda.
23.2 FMEA
Para cada componente, liste modos de falha, efeitos e causas. Pontue severidade (S), ocorrência (O) e dificuldade de detecção (D) de 1 a 10; o número de prioridade de risco RPN = S × O × D ordena a atenção. As três pontuações vêm do julgamento da equipe, informado pelo histórico de incidentes onde ele existe. Kofi conduz a pontuação com um operador, um engenheiro e um analista na sala, porque cada um enxerga falhas diferentes. O número resultante é útil para ordenar; a discussão que o produz muitas vezes importa mais, pois revela modos de falha que nenhuma pessoa sozinha havia considerado.
23.3 Linhas de exemplo
Coletor para em silêncio: S6, O4, D7 → RPN 168. Bloqueio errado enviado à TI: S8, O3, D4 → 96. Relatório TLP:RED compartilhado indevidamente: S9, O2, D6 → 108. A parada silenciosa do coletor fica em primeiro porque ninguém perceberia por dias. A classificação surpreendeu a equipe, que esperava ver em primeiro o relatório RED compartilhado indevidamente, porque seu dano é o maior. Sua probabilidade é baixa, e o registro de acesso o revelaria com relativa rapidez. A falha do coletor é menos grave, mas nada alerta ninguém, então o dano se acumula em silêncio enquanto os indicadores envelhecem. É esse o caso que o exemplo resolvido trata.
23.4 Agindo a partir da classificação
Pontuações altas de detecção pedem monitoramento: um alerta de pulsação se nenhum objeto chegar de um parceiro por seis horas. Severidade alta pede prevenção e etapas de aprovação. O alerta de pulsação de Kofi compara o histórico de chegadas de cada parceiro com o intervalo atual. Um parceiro que normalmente envia a cada hora dispara o alerta após seis horas de silêncio; um que publica uma vez por dia tem uma janela mais longa. Depois da mudança, a equipe pontuou de novo a linha e registrou o número menor com o motivo, para que o efeito do controle fique visível no registro.
23.5 Acidentes
Nem toda falha é maliciosa. O envio maciço por engano de um parceiro ou um erro de relógio podem causar dano. A análise de falhas cobre os dois. O registro de Kofi dá aos acidentes suas próprias linhas. Certa vez um parceiro enviou por engano um conjunto inteiro de dados de teste, cheio de domínios inofensivos. A verificação de volume reteve a entrega, e o parceiro a retirou no mesmo dia. Um relógio ajustado para o ano errado em um servidor de teste produziu indicadores que pareciam já expirados. Nenhum dos eventos envolveu um adversário, mas ambos poderiam ter perturbado a BEN.
Nota de prática — Casos de abuso
Ao lado dos casos de uso, Kofi escreve casos de abuso: "Uma conta de parceiro envia dez milhões de objetos", "Um analista exporta um relatório RED para o e-mail pessoal". Cada caso de abuso corresponde a um controle e a um teste, o que transforma o modelo de ameaças em trabalho verificável. Os casos de abuso são revistos sempre que um novo parceiro ou uma nova interface entra na plataforma.
Exemplo resolvido
A FMEA de Kofi mostra a parada silenciosa do coletor com RPN 168. Ele acrescenta monitoramento de pulsação por parceiro, reduzindo D para 2 e o RPN para 48, e registra a mudança no registro de riscos.
Caso sintético. As pontuações são inventadas.
Erros e limites
O RPN multiplica escalas ordinais; trate-o como auxílio de ordenação, não como medida precisa. Modelos de ameaças envelhecem; revise-os após mudanças grandes.
Exercícios
- EX067 — Cálculo do RPN. Calcule o RPN para S7, O3, D5. Rubrica: 3 = 105; 2 = método certo; 1 = soma; 0 = nenhuma.
- EX068 — Depois da pulsação. Com D reduzido de 7 para 2, qual é o RPN do coletor? Rubrica: 3 = 48; 2 = método; 1 = errado; 0 = nenhuma.
- EX069 — Ligação com técnica. Qual ID de técnica do ATT&CK cobre um atacante que usa o login roubado de um analista? Rubrica: 3 = T1078 Valid Accounts; 2 = só o nome; 1 = errado; 0 = nenhuma.
Síntese
Modele as ameaças à plataforma, ordene as falhas com FMEA, acrescente detecção onde as falhas são silenciosas e cubra acidentes além de adversários.
Continue estudando — capítulo 23 de 50
← Capítulo 22 (rascunho) · Índice de capítulos do curso · Capítulo 24 (rascunho) →