Modelagem de ameaças é o exercício estruturado de analisar um sistema, uma integração ou um processo antes de construí-lo ou alterá-lo, para identificar o que pode dar errado, quem teria interesse nisso, por onde o ataque viria e o que fazer a respeito. É segurança aplicada no desenho, antes da entrega.
A falha mais barata de corrigir é a que nunca chega a existir. Mudar uma decisão de arquitetura no papel custa uma reunião; depois da produção, custa um projeto.
O prazo para corrigir depois também encolheu. O M-Trends 2026, do Google Cloud, estima que o tempo médio até a exploração de uma vulnerabilidade chegou a cerca de sete dias negativos, ou seja, falhas exploradas antes da publicação da correção.
Quais perguntas a modelagem responde?
Qualquer que seja o método, a modelagem responde a quatro perguntas, como propõe o Threat Modeling Manifesto. O que estamos construindo: componentes, dados, fluxos, acessos e fronteiras de confiança, os pontos em que um dado passa de um ambiente confiável para outro que não é. O que pode dar errado: as ameaças, componente por componente e fluxo por fluxo.
O que vamos fazer: para cada ameaça relevante, mitigar, eliminar, transferir ou aceitar, com justificativa. E se o trabalho foi bem feito: revisão e validação, idealmente com teste depois que o sistema existir.
O método STRIDE
O método mais usado para identificar o que pode dar errado é o STRIDE, que organiza as ameaças em seis categorias:
- Falsificação de identidade: alguém se passa por um usuário ou sistema legítimo.
- Adulteração: alguém altera um dado em trânsito ou armazenado.
- Repúdio: alguém executa uma ação e não há registro que a comprove.
- Divulgação de informação: um dado chega a quem não deveria vê-lo.
- Negação de serviço: alguém tira o sistema do ar ou o torna inutilizável.
- Elevação de privilégio: alguém passa a fazer mais do que deveria poder.
Aplicar as seis categorias a cada componente e fluxo transforma a análise num exercício que não depende da memória de alguém. Métodos mais orientados a risco de negócio, como o PASTA, partem dos objetivos do negócio e do perfil do atacante.
Quem deve participar
O método importa menos do que as pessoas na sala: quem desenhou o sistema, quem vai operá-lo e alguém com visão ofensiva. Sem a perspectiva de quem ataca, o exercício tende a encontrar apenas o óbvio. Para um sistema ou integração, algumas sessões de trabalho costumam ser suficientes.
Exemplo fictício: a integração com acesso excessivo
Uma fintech vai integrar sua plataforma a um parceiro de análise de crédito. O desenho inicial prevê uma chave de API para o parceiro consultar o cadastro dos clientes que pedirem crédito.
Na modelagem, o STRIDE revela que a chave dá acesso ao cadastro inteiro e que não há registro das consultas feitas pelo parceiro. Se a chave vazar, quem a tiver lê todos os clientes, sem rastro. O redesenho limita a consulta ao cliente que autorizou, usa chave com escopo e validade curtos, registra cada consulta e alerta para volume fora do padrão.
Do sistema ao negócio
A mesma lógica vale para a empresa inteira: cruzar os agentes de ameaça com interesse no negócio, os eventos que poderiam provocar e os ativos críticos para chegar a cenários de risco com probabilidade e impacto. A modelagem é indicada antes de construir sistemas com dados sensíveis, antes de integrações com terceiros, antes de mudanças relevantes de arquitetura e antes de colocar em produção sistemas de IA que acessam dados ou executam ações.
A modelagem não substitui o pentest: ela previne falhas de desenho, e o pentest encontra as que passaram, inclusive de implementação.
Modelagem de riscos e ameaças na Vultus
A Vultus usa a modelagem de ameaças para construir o diagnóstico executivo de riscos do plano diretor de segurança e os cenários priorizados dos planos de continuidade. Conheça a modelagem de riscos e ameaças da Vultus.
