Threat modeling: como pensar como um atacante

Threat modeling, ou modelagem de ameaças, é o exercício de olhar para o seu sistema com os olhos de quem quer quebrá-lo. Em vez de esperar um pentest ou, pior, um incidente real, você antecipa onde e como um atacante agiria — e corrige o design antes de escrever uma linha de código vulnerável. Neste guia você vai aprender o método STRIDE, a desenhar diagramas de fluxo de dados e a transformar tudo isso em uma prática contínua.

A grande mudança de mentalidade é esta: segurança não é uma camada que se adiciona no fim, com um firewall e um scanner. As falhas mais graves nascem de decisões de design tomadas semanas antes de qualquer código. Threat modeling é a disciplina que move a segurança para o início — para o momento em que mudar de rumo ainda custa uma conversa, e não um plantão de incidente.

Por que modelar ameaças

A maioria das falhas de segurança não nasce de um bug isolado, mas de uma decisão de arquitetura que ninguém questionou. Um endpoint que confia no cliente, um segredo guardado no lugar errado, uma fronteira de confiança mal desenhada. Encontrar esses problemas em produção custa caro; encontrá-los num diagrama custa uma reunião.

Existe um princípio econômico bem estabelecido por trás disso: quanto mais tarde um defeito é descoberto no ciclo de desenvolvimento, mais caro é corrigi-lo. Uma falha de design pega no quadro branco custa o tempo de redesenhar uma seta; a mesma falha descoberta após um vazamento de dados custa reputação, multas regulatórias e retrabalho de emergência. Threat modeling é, antes de tudo, uma estratégia de redução de custo.

Adam Shostack (2014) resume a essência em quatro perguntas que estruturam qualquer sessão de modelagem:

Essas perguntas são poderosas porque são agnósticas de ferramenta. Você pode respondê-las num quadro branco, num documento ou num diagrama formal. O importante é o hábito de fazê-las cedo e com frequência.

Quando fazer threat modeling

O momento ideal é no início do design de uma feature significativa — antes do código, quando a arquitetura ainda é maleável. Mas há outros gatilhos naturais: quando você adiciona uma nova integração externa, quando muda o modelo de autenticação, quando passa a lidar com uma categoria nova de dado sensível, ou quando um componente cruza uma nova fronteira de rede. A regra prática é: se a mudança move dados através de uma fronteira de confiança, ela merece uma sessão de modelagem.

O que pode dar errado: pensando como atacante

Pensar como atacante significa abandonar a pergunta "como o usuário usa isso?" e adotar "como alguém abusa disso?". Um formulário de upload deixa de ser uma conveniência e passa a ser um canal para enviar arquivos maliciosos. Um campo de busca vira uma porta para injeção. Um token na URL vira um segredo que vaza no log do servidor.

Esse deslocamento mental é o mesmo que guia um teste de invasão. Vale a pena entender como os profissionais estruturam esse raciocínio na metodologia de pentest: muitas das ameaças que você lista no design são exatamente as que um pentester tentará explorar depois. Modelar ameaças é, em essência, fazer o pentest mentalmente antes de o sistema existir.

Um exercício útil para destravar esse pensamento é assumir personas de atacante. Quem tem motivo para atacar este sistema? Pode ser um usuário legítimo tentando ver dados de outro (ameaça interna), um criminoso atrás de dados de cartão, um concorrente querendo derrubar o serviço, ou um script automatizado varrendo a internet por configurações padrão. Cada persona tem capacidades e objetivos diferentes, e isso ajuda a calibrar quais ameaças são realistas para o seu contexto.

STRIDE: um vocabulário para ameaças

STRIDE é um acrônimo criado na Microsoft e popularizado por Shostack (2014) que dá nome a seis categorias de ameaça. Ter esse vocabulário evita que você dependa da inspiração: para cada componente, você percorre as seis letras e pergunta se aquela ameaça se aplica.

Repare que cada categoria tem uma propriedade de segurança correspondente. Spoofing ataca a autenticação; elevação de privilégio ataca a autorização. Por isso é fundamental ter clareza sobre a diferença entre autenticação e autorização: confundir as duas é uma fonte recorrente de falhas de classe S e E.

STRIDE é o oposto das propriedades de segurança

Há uma forma elegante de lembrar do STRIDE: cada letra é a negação de uma propriedade desejável. Autenticidade nega spoofing; integridade nega tampering; não-repúdio nega repudiation; confidencialidade nega information disclosure; disponibilidade nega denial of service; autorização nega elevation of privilege. Quando você define quais propriedades cada componente precisa garantir, as ameaças relevantes aparecem por dedução — não por sorte.

Diagramas de fluxo de dados (DFD)

Você não consegue proteger o que não consegue enxergar. O diagrama de fluxo de dados (Data Flow Diagram, DFD) é a ferramenta padrão para tornar o sistema visível. Ele usa quatro elementos:

O elemento mais importante, porém, são as fronteiras de confiança (trust boundaries): linhas tracejadas que marcam onde o nível de confiança muda. A fronteira entre o navegador e o seu servidor é a mais óbvia, mas há outras: entre o seu serviço e o banco, entre dois microsserviços, entre o seu código e uma biblioteca de terceiros.

[Usuário] --(login)--> ( API de Auth ) --(query)--> [Banco de Usuários]
   |                         |
   |  ......... fronteira de confiança .........
   |                         |
internet pública        rede interna

A regra prática: toda seta que cruza uma fronteira de confiança é uma candidata a ameaça. É exatamente ali que você aplica STRIDE com mais atenção, porque é ali que dados não confiáveis encontram código privilegiado.

Quão detalhado deve ser o diagrama

Um erro comum de iniciantes é tentar desenhar o sistema inteiro com todos os detalhes, produzindo um diagrama tão denso que ninguém usa. Comece no nível de contexto (o sistema como uma caixa e seus atores externos) e desça apenas onde há risco real. Para a maioria das sessões, um DFD de "nível 1" — mostrando os principais processos, armazenamentos e as fronteiras entre eles — é detalhe suficiente. O diagrama é um meio para encontrar ameaças, não um fim artístico.

Aplicando STRIDE a um exemplo

Imagine uma API REST simples que recebe pedidos autenticados por token. Vamos percorrer o fluxo "cliente envia requisição → API valida token → API lê o banco" e aplicar STRIDE à seta que cruza a fronteira internet/servidor:

Muitos desses controles são, na prática, os mesmos descritos em segurança de APIs. A modelagem de ameaças não substitui esse conhecimento técnico — ela o organiza, indicando onde aplicar cada controle e por quê.

Observe como a última ameaça (elevation of privilege) é, na verdade, a clássica falha de autorização horizontal: o usuário A acessa o recurso do usuário B trocando um identificador. É um dos defeitos mais comuns e mais perigosos em APIs, justamente porque o caminho feliz funciona perfeitamente nos testes — só o atacante pensa em trocar o id. Modelar essa seta no design força você a perguntar "o servidor verifica que este recurso pertence a quem está pedindo?" antes que o código exista.

Priorizando ameaças: nem tudo merece a mesma atenção

Uma sessão de modelagem honesta gera mais ameaças do que você pode tratar de imediato. Priorizar é parte do método. Uma forma simples é estimar dois eixos para cada ameaça: o impacto (o que se perde se ela for explorada) e a probabilidade (quão fácil e provável é a exploração). Ameaças de alto impacto e alta probabilidade vão para o topo; as de baixo impacto e baixa probabilidade podem ser aceitas e documentadas.

Existem frameworks formais de pontuação, mas para a maioria dos times uma classificação qualitativa (alto/médio/baixo) já direciona bem a conversa. O objetivo não é precisão numérica, e sim evitar dois extremos igualmente ruins: gastar dias mitigando um risco improvável ou ignorar uma ameaça óbvia porque "deu trabalho demais listar tudo".

Da ameaça à mitigação

Para cada ameaça encontrada, você tem quatro respostas possíveis, e nomeá-las explicitamente evita o "vamos resolver depois":

A opção de eliminar é a mais subestimada. Muitas ameaças existem porque a funcionalidade que as cria não era realmente necessária. Aquele endpoint de debug, aquele campo que ninguém usa, aquela permissão "por garantia": removê-los apaga classes inteiras de ameaça de uma vez. A superfície de ataque mais segura é a que não existe.

Boa parte das mitigações cai sobre criptografia: TLS para tampering em trânsito, hashing para integridade, cifragem para vazamento em repouso. Se esses termos ainda soam vagos, vale revisar o que é criptografia, abordando simétrica, assimétrica e hashing, porque a escolha errada de primitiva é, ela mesma, uma vulnerabilidade.

Erros comuns ao modelar ameaças

Conectando com frameworks de segurança

Threat modeling não vive isolado. O NIST (2024), no Cybersecurity Framework 2.0, organiza a segurança em torno de seis funções — Govern, Identify, Protect, Detect, Respond e Recover. A modelagem de ameaças é uma atividade central da função Identify: é ali que você reconhece quais ativos existem e a que riscos estão expostos. As mitigações que você define alimentam a função Protect, e os logs de auditoria (a resposta ao "R" de STRIDE) sustentam Detect e Respond.

Olhar para o threat modeling sob essa lente ajuda a justificá-lo para o time e a liderança: não é um exercício acadêmico, mas a etapa que conecta o design do produto às práticas de governança que a organização já adota.

STRIDE não é o único, e tudo bem

Embora STRIDE seja o ponto de partida mais didático, conhecer alternativas ajuda a escolher a ferramenta certa para cada situação. Abordagens centradas em ativos começam pelo que você precisa proteger (dados de cartão, segredos, propriedade intelectual) e perguntam quem os quer. Abordagens centradas no atacante partem das personas e capacidades de quem ataca. Há ainda metodologias mais estruturadas para times maduros que querem repetibilidade e rastreabilidade entre risco de negócio e controle técnico. O ponto não é decorar siglas, mas entender que cada lente revela ameaças diferentes — e que combinar perspectivas é o que produz uma cobertura honesta. Para quem está começando, STRIDE oferece estrutura suficiente sem sobrecarga; conforme o time amadurece, vale incorporar outras lentes onde elas agregam.

Documente as decisões, não só as ameaças

Um diagrama com ameaças listadas é metade do trabalho; o que dá longevidade à modelagem é registrar as decisões tomadas. Para cada ameaça relevante, anote qual resposta foi escolhida (mitigar, eliminar, transferir, aceitar) e por quê. Isso evita que a próxima pessoa reabra discussões já fechadas e cria uma trilha de auditoria valiosa: quando um incidente acontece, você consegue distinguir entre "não pensamos nisso" e "pensamos, aceitamos o risco conscientemente e a premissa mudou". Um simples registro versionado junto ao código — algumas linhas por decisão — já cumpre esse papel sem virar burocracia.

Tornando a prática contínua

O erro mais comum é tratar threat modeling como um evento único, feito uma vez e arquivado. Sistemas evoluem; cada nova feature pode mover uma fronteira de confiança. Algumas práticas que mantêm a modelagem viva:

Com o tempo, o vocabulário de STRIDE e o hábito das quatro perguntas deixam de ser uma cerimônia e passam a fazer parte de como o time pensa em qualquer mudança.

Perguntas frequentes

Preciso de uma ferramenta especializada para começar? Não. Um quadro branco (físico ou digital), as seis letras do STRIDE e as quatro perguntas de Shostack entregam a maior parte do valor. Ferramentas dedicadas ajudam a documentar e padronizar em times maiores, mas não são pré-requisito para a primeira sessão.

Quem deve participar da sessão? O ideal é uma mistura de quem conhece a arquitetura (devs, arquitetos) e quem conhece o risco (segurança, produto). Diversidade de perspectiva é o que faz aparecerem ameaças que uma só pessoa não enxergaria. Não precisa ser um especialista em segurança para contribuir — basta saber perguntar "e se alguém abusar disso?".

Threat modeling substitui o pentest? Não, são complementares. A modelagem encontra falhas de design cedo, no papel; o pentest valida, no sistema real e em execução, se as mitigações funcionam e se há falhas que escaparam ao design. Um alimenta o outro.

Quanto tempo leva uma sessão? Para uma feature, de 30 minutos a duas horas costuma bastar. Se está levando dias, o escopo está grande demais — quebre em pedaços menores.

STRIDE é o único método? É o mais popular e didático, mas não o único. Há abordagens centradas em ativos, em atacantes e em ataques. Para quem está começando, STRIDE oferece o melhor equilíbrio entre estrutura e simplicidade.

Conclusão

Modelar ameaças é trocar a reação pela antecipação. Com as quatro perguntas de Shostack, o vocabulário de STRIDE e um bom diagrama de fluxo de dados, você encontra falhas de design enquanto elas ainda são baratas de corrigir. Não é preciso ferramenta sofisticada para começar — um quadro branco, as seis letras e a disciplina de cruzar fronteiras de confiança já entregam a maior parte do valor.

O segredo está em fazer disso um hábito contínuo, e não um ritual anual. Modele a próxima feature que você for construir, priorize as ameaças por impacto e probabilidade, decida conscientemente entre mitigar, eliminar, transferir ou aceitar cada risco, e versione o diagrama junto do código. Com o tempo, pensar como atacante deixa de ser uma cerimônia e passa a fazer parte de como o time projeta qualquer mudança.

Referências