Esse conhecimento é útil para desenvolvedores, pentesters, bug hunters... Desde segurança ofensiva até defensiva. É útil para todo mundo.

Estou falando de threat modeling (modelagem de ameaça), que é a análise de um sistema com o intuito de fazer ponderações sobre segurança e privacidade no sistema. É por meio de threat modeling que se identifica falhas de segurança na arquitetura de um sistema (falhas de design) e também potenciais falhas de implementação, além de planejar mitigações para essas falhas.

Nota: No Penetration Testing Execution Standard (PTES), threat modeling é a terceira etapa.

Não existe checklist ou passo a passo de como fazer threat modeling, depende do sistema e é encorajável que todo mundo faça threat modeling, do seu jeito, sem medo de "fazer errado" ou não ter conhecimento suficiente. Só faça. Não existe jeito certo, só faça!

O Threat Modeling Manifesto define de maneira abstrata que fazer threat modeling se trata basicamente de fazer as seguintes quatro perguntas chave:

No que estamos trabalhando?
O que pode dar errado?
O que vamos fazer sobre isso?
Nós fizemos um trabalho bom o suficiente?

Ponderando sobre isso, podemos ver que essas perguntas nos levam a analisar quais modificações estão sendo feitas no sistema, definindo um escopo para o threat modeling; como e onde essas modificações podem conter falhas de segurança; pensar em mitigações para essas falhas de segurança e depois fazer revisão e testes para garantir que as mitigações realmente corrigiram a falha de segurança.

Threat modeling não é algo que deve ser feito uma vez só. É algo que deve ser feito sempre que forem feitas alterações no sistema, seja por refatorações, inclusão de novas features, alteração ou adição na arquitetura do sistema etc.

Dicas

Nos materiais complementares no final do post você pode aprender melhor sobre o que é e como fazer threat modeling. Lá vai falar sobre STRIDE model e MITRE ATT&CK, é importante que pesquise no Google e leia sobre esses dois.

Não vou repetir o que já tá nesses materiais ou o que você acha no Google, mas vou dar umas dicas que eu aprendi com a experiência.

Texto ao invés de gráficos (data flows)

Em todo lugar que você ler sobre threat modeling provavelmente vão falar para você fazer um clássico diagrama de fluxo de dados para modelar o sistema. Sinceramente eu acho uma péssima ideia.

Ao invés disso, escreva. Faça um documento descrevendo os componentes. Isso é mais descritivo, menores chances de induzir alguém ao erro, já serve como documentação para ter uma visão do design do sistema e quanto mais descritivo você for sobre como o sistema funciona, maiores as chances de você se tocar que há uma falha de design ali.

Tentar "explicar" como o sistema funciona em um documento já é um processo mental que te ajuda a achar uma falha de segurança. Vai por mim, é muito melhor que fazer um diagrama.

E se ainda não está convencido, vibe coder, então toma essa: Se você fizer um documento você pode usar ele no seu agente.

Planeje testes de segurança

Ao fazer o threat modeling, escreva cenários de testes de segurança descrevendo como um atacante tentaria explorar uma falha de segurança no sistema. Você pode usar MITRE ATT&CK como base para isso, ou não se achar complicado demais (lembra do "só faça"?).

Ao descrever os testes de segurança previamente, você cria uma base de conhecimento para que qualquer um que leia o documento seja capaz de ter a visão de como aquela falha ocorre na prática. Isso educa os desenvolvedores para saberem que erros evitar/mitigar, como escreverem testes automatizados para aquela falha e permite que qualquer pessoa possa testar posteriormente a implementação.

Use CVSS

Se você identificou uma falha de segurança já existente no sistema ao fazer threat modeling, é prudente usar CVSS para classificar a vulnerabilidade. CVSS não é só uma classificação genérica, ela também leva em consideração a realidade do sistema. Inclusive a versão 4.0 enfatiza esse fato mudando algumas nomenclaturas, pois muita gente criticava o CVSS por não refletir corretamente a severidade de uma vulnerabilidade em sistemas reais.

Na verdade CVSS desde sempre leva em consideração o sistema real e não apenas um impacto hipotético. Então sim, vale a pena aprender de verdade como CVSS funciona e classificar suas vulnerabilidades usando o mesmo. Veja também o "CVSS Calculator" no site da First.

Talvez você não entenda a importância disso, mas a questão é que nem todo mundo tem uma visão muito correta de como uma vulnerabilidade impacta o sistema. É bem comum eu ver devs fazendo um alarde sobre uma vulnerabilidade que nem sequer afeta o sistema. É sério. Já vi galera priorizando bugfixes achando que era uma vulnerabilidade grave (porque estava classificada assim no CVE), mas a vulnerabilidade nem sequer afetava o sistema.

Também ocorre o oposto: vulnerabilidades graves sendo ignoradas porque o dev não entende o quão grave ela é.

Se você aprender de verdade sobre CVSS e classificar corretamente o impacto real no sistema, isso vai retirar a carga cognitiva dos outros de entenderem a severidade da vulnerabilidade — a maioria entende errado.

Descentralize o conhecimento

Quanto menos "centralizado" o conhecimento sobre threat modeling, melhor. É importante que todos os envolvidos no desenvolvimento do sistema sejam capazes de fazer threat modeling, mesmo que não seja "formalmente" escrevendo um documento. Mesmo que seja só na mente dele enquanto ele implementa uma funcionalidade.

Então documente de forma amigável sobre o processo de threat modeling que você adotou e pede pra todo mundo ler essa documentação. Deixe todo mundo na equipe ler os documentos de threat models anteriores que você fez e acredita que já é seguro deixar todo mundo ler (as vulns já foram corrigidas? Beleza).

É importante ter o máximo de pontos de vista diferentes possível. A falha que você não achar, talvez o dev responsável por implementar uma tarefa ache.

Materiais complementares

Sugiro ler os seguintes conteúdos: