Priorizar mitigações por risco

Um bom modelo de ameaças costuma gerar mais ameaças do que a equipe consegue tratar de uma vez. A SEC01-BP07 é explícita: o objetivo de uma abordagem sistemática é priorizar as mitigações para que os recursos limitados da organização tenham o maior impacto possível na postura de segurança. Priorizar não é ignorar o resto; é decidir a ordem e registrar o porquê.

A forma mais usada de comparar ameaças é estimar duas coisas para cada uma:

• Probabilidade: quão provável é a ameaça se concretizar. Pense em exposição (está na internet?), facilidade de exploração, controles já existentes e interesse de atacantes.
• Impacto: o dano se acontecer. Pense em dados afetados e sua classificação, indisponibilidade, multas, reputação e quantas contas ou clientes seriam atingidos (o blast radius).

O risco é a combinação das duas. Uma escala simples de 1 a 3 (baixo, médio, alto) em cada eixo já basta para começar; o importante é que todos na equipe usem os mesmos critérios.

Multiplicando os dois eixos, você obtém uma matriz como esta:

Probabilidade ↓ / Impacto →	Baixo (1)	Médio (2)	Alto (3)
Alta (3)	3 — médio	6 — alto	9 — crítico
Média (2)	2 — baixo	4 — médio	6 — alto
Baixa (1)	1 — baixo	2 — baixo	3 — médio

Exemplo com ameaças de uma API pública:

• Bucket de uploads sem S3 Block Public Access, com dados pessoais: probabilidade 2, impacto 3 → 6, alto.
• Inundação de requisições na API sem limite de taxa: probabilidade 3, impacto 2 → 6, alto.
• Ausência de logs de acesso no ambiente de desenvolvimento, sem dados reais: probabilidade 2, impacto 1 → 2, baixo.

Para cada ameaça priorizada, a gestão de riscos costuma oferecer quatro caminhos:

Resposta	O que significa	Exemplo
Mitigar	Reduzir probabilidade ou impacto com controles.	Ativar Block Public Access e criptografia com KMS no bucket.
Evitar	Eliminar a atividade que gera o risco.	Não armazenar o dado sensível: guardar só um token ou não coletar.
Transferir	Passar parte do risco a outro.	Usar um serviço gerenciado (a AWS assume camadas), um provedor especializado ou seguro.
Aceitar	Conviver com o risco de forma consciente.	Risco baixo em ambiente de testes, com aceite formal e prazo de revisão.

Transferir nunca é total: no modelo de responsabilidade compartilhada, sempre sobra uma parte para o cliente. E aceitar é uma decisão de quem tem autoridade sobre o risco, não de quem está com pressa.

Entre ameaças de mesma prioridade, comece pelas mitigações que reduzem mais risco por unidade de esforço. Muitas vezes um controle barato e amplo vale mais que um sofisticado e pontual: um guardrail aplicado na organização inteira (por exemplo, uma SCP ou o bloqueio de acesso público no nível da conta) cobre dezenas de workloads de uma vez.

Lembre que mitigar pode ser prevenir, detectar ou responder, como diz a SEC01-BP07. Se a prevenção completa é cara, um controle detectivo com resposta automatizada pode baixar o impacto o suficiente enquanto a solução definitiva não chega.

Cada ameaça do registro deve ter, no mínimo:

• a nota de probabilidade e impacto e o raciocínio por trás dela;
• a resposta escolhida (mitigar, evitar, transferir, aceitar) e quem decidiu;
• o risco residual: o que sobra depois da mitigação, reavaliado com as mesmas escalas;
• um dono, um status e uma data de revisão.

O registro é revisitado quando a arquitetura muda, quando surge ameaça nova (lição 10) e quando um aceite de risco vence. Use o template de modelagem de ameaças como ponto de partida.

Priorize ameaças por probabilidade × impacto, com critérios comuns e uma matriz simples. Escolha entre mitigar, evitar, transferir e aceitar, compare custo com redução de risco, registre a decisão e o risco residual e marque quando revisitar. Na próxima lição, como incorporar serviços e recursos novos.

SEC01-BP07 Identify threats and prioritize mitigations using a threat model

• How to approach threat modeling — AWS Security Blog
• Threat Composer — GitHub (awslabs)
• Blocking public access to your Amazon S3 storage