Threat modeling para devs: identificando riscos antes de codar

1. O que é Threat Modeling e por que devs devem adotá-lo?

Threat modeling é um processo estruturado para identificar, documentar e mitigar ameaças de segurança no início do ciclo de desenvolvimento. Em vez de esperar que vulnerabilidades apareçam em produção, você as antecipa durante o design do sistema.

A diferença é fundamental: abordagem reativa significa corrigir depois que o código já foi escrito, testado e implantado — o custo de correção pode ser até 30 vezes maior. Já a abordagem proativa, com modelagem antes de codar, reduz drasticamente retrabalho, acelera revisões de segurança e ajuda na conformidade com padrões como OWASP ASVS e ISO 27001.

Para devs, o ganho prático é claro: você entende onde estão os pontos fracos do seu sistema antes de investir horas em implementação. Um modelo de ameaças bem feito orienta decisões de arquitetura, escolha de bibliotecas e configuração de infraestrutura.

2. Metodologias de Threat Modeling mais usadas na prática

Três metodologias dominam o mercado:

STRIDE (Microsoft) — classifica ameaças em seis categorias: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege. Aplicada por componente do sistema, é ideal para devs porque mapeia diretamente para tipos de ataque conhecidos.

DREAD — sistema de pontuação para priorizar riscos: Damage, Reproducibility, Exploitability, Affected Users, Discoverability. Cada ameaça recebe uma nota de 1 a 10, ajudando a decidir o que corrigir primeiro.

PASTA (Process for Attack Simulation and Threat Analysis) — abordagem orientada a ataques com sete etapas que integram análise de negócio, arquitetura e testes. Mais completa, mas exige mais maturidade do time.

Para times iniciantes, recomendo começar com STRIDE combinado com DREAD para priorização.

3. Passo a passo para criar um modelo de ameaças no seu projeto

Passo 1 — Definir escopo

Identifique o sistema, ativos críticos (dados de usuário, chaves de API, tokens), limites de confiança (onde o fluxo cruza fronteiras de rede) e atores envolvidos (usuários, admins, serviços externos).

Passo 2 — Diagramar a arquitetura

Crie um Data Flow Diagram (DFD) com entidades externas, processos, armazenamentos de dados e fluxos. Exemplo para uma API REST com JWT:

[Cliente Web] --(requisição HTTPS)--> [API Gateway] --(valida JWT)--> [Serviço de Autenticação]
                                         |
                                    (consulta)
                                         |
                                    [Banco de Dados]

Passo 3 — Identificar ameaças

Aplique STRIDE em cada elemento do DFD. Perguntas guia:
- O fluxo HTTPS pode ser interceptado? (Spoofing)
- O token JWT pode ser adulterado? (Tampering)
- Quem pode negar ter enviado uma requisição? (Repudiation)
- Logs expõem dados sensíveis? (Information Disclosure)
- O endpoint pode ser sobrecarregado? (Denial of Service)
- Um usuário comum pode acessar rotas de admin? (Elevation of Privilege)

Passo 4 — Documentar e mitigar

Registre em uma matriz:

ID: T-001
Descrição: Spoofing no login via força bruta
Severidade: Alta (DREAD: 8)
Contramedida: Rate limiting + MFA
Responsável: Time de autenticação
Status: Pendente

4. Ferramentas práticas para devs incorporarem no fluxo de trabalho

OWASP Threat Dragon — ferramenta open source para diagramação e modelagem. Suporta STRIDE, exporta para JSON e PDF. Ideal para equipes que querem versionar modelos no Git.

Microsoft Threat Modeling Tool — gratuita, foco em STRIDE, gera relatórios automáticos. Funciona bem no Windows e tem templates para Azure.

Integração com CI/CD — ferramentas como Checkmarx e Snyk oferecem plugins que geram modelos a partir de arquivos de infraestrutura (Terraform, Kubernetes manifests). Útil para detectar ameaças em mudanças de configuração.

Exemplo prático: DFD básico para API REST com JWT e banco de dados:

Entidade Externa: [Cliente Mobile]
  |
  | (HTTPS)
  v
Processo: [API Gateway]
  |
  |---> (valida JWT) ---> Processo: [Serviço de Autenticação]
  |                           |
  |                           v
  |                      Armazenamento: [Tabela de Tokens]
  |
  |---> (consulta dados) ---> Processo: [Serviço de Negócio]
                                |
                                v
                           Armazenamento: [Banco de Dados]

Ameaças identificadas:
- Spoofing: ataque MITM se HTTPS não for obrigatório
- Information Disclosure: token JWT vazado em logs do Gateway
- Elevation of Privilege: usuário com token válido acessa dados de outro usuário

5. Exemplos reais de ameaças identificadas antes de codar

Caso 1 — Autenticação: endpoint de login sem rate limiting. Ameaça de Spoofing por força bruta. Mitigação: implementar bloqueio por IP após 5 tentativas e exigir MFA para logins suspeitos.

Caso 2 — Armazenamento de dados: logs do servidor gravam tokens de sessão em texto puro. Ameaça de Information Disclosure se logs forem acessados por terceiros. Mitigação: logging seletivo com sanitização automática de campos sensíveis.

Caso 3 — Fluxo entre microsserviços: mensagens em fila RabbitMQ não assinadas. Ameaça de Tampering: um atacante injeta mensagens falsas na fila. Mitigação: usar HMAC para assinar mensagens e validar integridade no consumidor.

6. Como integrar threat modeling no dia a dia do time de desenvolvimento

Cerimônias ágeis: inclua sessões leves de modelagem (15-30 minutos) durante o refinamento do backlog e antes de sprints críticos. O objetivo é identificar riscos antes de codar, não criar documentos enormes.

Checklist de segurança por componente: crie perguntas rápidas para revisões de código:
- Esse fluxo expõe dados sensíveis?
- O token é validado em todos os endpoints?
- Há rate limiting nos endpoints de autenticação?
- Logs sanitizam informações pessoais?

Cultura de "shift left": treine devs para pensar como atacantes. Use gamificação: cada sprint, um dev assume o papel de "atacante" e tenta quebrar o modelo do colega. Workshops de modelagem colaborativa com o time todo aceleram o aprendizado.

7. Erros comuns e como evitá-los ao modelar ameaças

Erro 1 — Modelar tarde demais: esperar o sistema estar pronto para começar a modelagem. Solução: comece a modelar a partir do design inicial, antes de qualquer linha de código.

Erro 2 — Documentar e nunca revisar: criar modelos estáticos que viram "papel morto". Solução: versionar modelos junto com o código (no mesmo repositório) e revisar a cada mudança significativa de arquitetura.

Erro 3 — Foco excessivo em ameaças técnicas ignorando o contexto de negócio: listar vulnerabilidades genéricas sem considerar o impacto real para o cliente. Solução: alinhe cada ameaça com ativos críticos do negócio (dados financeiros, informações de saúde, credenciais).

Threat modeling não é uma atividade única — é um hábito. Quanto mais cedo você identificar riscos, menos dor de cabeça terá depois. Comece pequeno: modele um endpoint, um fluxo, um microsserviço. Com o tempo, a prática se torna natural e o código, mais seguro.

Referências