Blog/Artigos · Segurança
As quatro perguntas, STRIDE, árvores de ataque e MITRE ATT&CK, modelando ameaça no desenho e não depois do incidente.
O Talmud pergunta quem é sábio e responde: quem enxerga o que está por nascer. Segurança de software vive ou morre por essa capacidade. Corrigir uma falha depois que ela virou incidente em produção custa caro, expõe cliente e queima confiança; prevê-la no desenho, antes da primeira linha de código, custa uma reunião. Threat modeling é o exercício disciplinado de olhar um sistema e enxergar o dano antes de ele nascer, pensando como o atacante enquanto ainda dá tempo de mudar a planta.
Adam Shostack, autor da referência do tema, reduziu threat modeling a quatro perguntas que qualquer time consegue responder. O que estamos construindo? O que pode dar errado? O que vamos fazer a respeito? Fizemos um bom trabalho? A primeira desenha o sistema, geralmente como um diagrama de fluxo de dados; a segunda levanta as ameaças; a terceira decide a mitigação; a quarta valida. Simples de enunciar, transformador de aplicar.
A primeira pergunta é a que mais gente pula, e é a que sustenta as outras. Sem um diagrama de fluxo de dados que mostre onde o dado entra, onde é armazenado, quem confia em quem e onde estão as fronteiras de confiança, o levantamento de ameaças vira chute. O desenho é barato e é o que revela a fronteira esquecida, aquele ponto onde o sistema confia em algo que não deveria.
A pergunta o que pode dar errado trava quando o time olha a tela em branco. STRIDE, criado por Loren Kohnfelder e Praerit Garg na Microsoft, dá o vocabulário: seis categorias de ameaça que você aplica a cada elemento do diagrama. Spoofing (falsificar identidade), Tampering (adulterar dado), Repudiation (negar ter feito), Information disclosure (vazar), Denial of service (derrubar) e Elevation of privilege (escalar poder).
A força do STRIDE é ser sistemático: para cada fluxo e cada armazenamento, você pergunta as seis, e a categoria que não tem mitigação vira item de trabalho. Cada categoria também mapeia para uma propriedade de segurança que ela viola, o que conecta a ameaça à defesa: spoofing pede autenticação, tampering pede integridade, repudiation pede trilha, e assim por diante. O vocabulário transforma um brainstorm vago em uma varredura completa.
| Categoria | Propriedade violada | Defesa típica |
|---|---|---|
| Spoofing | autenticidade | MFA, mútua TLS, assinatura |
| Tampering | integridade | hash, assinatura, validação de entrada |
| Repudiation | não repúdio | trilha de auditoria assinada |
| Information disclosure | confidencialidade | criptografia, menor privilégio |
| Denial of service | disponibilidade | rate limit, cota, resiliência |
| Elevation of privilege | autorização | RBAC, ABAC, validação de escopo |
STRIDE é ótimo para varrer, mas para entender um ataque específico a fundo, as árvores de ataque de Bruce Schneier são insuperáveis. A raiz é o objetivo do atacante, roubar o dado do cliente, e os galhos são os caminhos para chegar lá, cada um decomposto até ações concretas. A árvore mostra o caminho mais barato para o atacante, que é onde a defesa rende mais, e deixa explícito quando fechar uma folha fecha vários caminhos.
Há outros métodos para outros contextos. PASTA é orientado a risco de negócio e bom para priorizar por impacto. LINDDUN foca privacidade, essencial sob LGPD. E o MITRE ATT&CK, embora seja base de conhecimento de técnicas reais e não um método de modelagem, ancora o exercício na realidade: as ameaças que você levanta são as táticas que adversários de fato usam, não fantasias. Ferramentas como o OWASP Threat Dragon dão o diagrama; o método é escolha sua.
O maior erro é fazer threat modeling uma vez, num documento que ninguém reabre, ou tratá-lo como cerimônia pesada que só cabe em projeto grande. O valor está em ser contínuo e proporcional: uma sessão leve a cada mudança relevante de arquitetura, focada no que mudou, com o resultado virando itens rastreáveis no backlog, não um PDF arquivado. Ameaça levantada que não vira trabalho priorizado é medo desperdiçado.
Threat modeling também é a etapa de desenho do SSDLC: ele decide o que os testes de segurança precisam cobrir depois. A ameaça de injeção que o modelo levantou vira a regra de SAST que a pipeline aplica; a de escalonamento vira o teste de autorização. Modelar cedo e barato é o que torna o resto do ciclo de segurança dirigido por risco real, e não por checklist genérico.
A cada nova mudança de arquitetura, o ciclo recomeça sobre o que mudou. Modelo vivo, não PDF arquivado.
Threat modeling é a sabedoria de enxergar o dano antes de ele nascer: desenhe o sistema, pergunte o que pode dar errado com STRIDE, aprofunde com árvores de ataque, priorize com PASTA e ancore no MITRE ATT&CK. Feito cedo, barato e contínuo, ele dirige o resto do ciclo de segurança por risco real. As quatro perguntas de Shostack cabem em qualquer time. A IA rascunha o diagrama, varre com STRIDE e mantém o modelo vivo, mas decidir o que aceitar e o que mitigar continua sendo julgamento de quem responde pelo sistema.
Gerente de Operações, Tecnologia e Infraestrutura (SRE) numa central de registros. Trabalho com tecnologia desde 2009 e com cibersegurança em tempo integral desde 2015, em infraestrutura crítica, fintech e banking. Escrevo sobre o que eu opero: confiabilidade, segurança, governança e IA que passa por gate antes de chegar em produção.
Segurançaלַלֵּבָב
A rede interna parou de ser segura no dia em que o dado saiu dela. Zero Trust troca a confiança por endereço pela verificação de cada requisição, com o modelo do NIST e a experiência do BeyondCorp.
Segurançaשְׁעָרֶיךָ
Como o acesso por atributo julga cada requisição pelo contexto, o modelo de ponto de decisão e de aplicação, política declarativa testável e por que ABAC e RBAC andam juntos.
