STRIDE foi cunhado pela Microsoft em 1999 (Praerit Garg, Loren Kohnfelder). É o framework mais didático para identificar ameaças sistematicamente: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege. Adam Shostack formalizou no livro Threat Modeling: Designing for Security (Wiley, 2014) — referência canônica. O exercício força considerar ameaças que a intuição esquece; o modelo resultante guia mitigations e auditorias.
Template
# Threat Model — [Nome da feature/sistema]
**Author:** [seu nome / time de security]
**Reviewers:** [security, eng lead, compliance se aplicável]
**Date:** [YYYY-MM-DD]
**Scope:** [O que ESTÁ no escopo desta análise]
**Out of scope:** [O que NÃO está, para evitar análise paralela]
## Sistema sob análise
### Diagrama de fluxo de dados
[Inserir DFD — Data Flow Diagram. Mostra: trust boundaries
(linhas tracejadas), processos (círculos), data stores
(retângulos), atores externos.]
### Trust boundaries
- **Internet → Edge:** request HTTP do usuário ao CDN/LB
- **Edge → Application:** request validada à aplicação
- **Application → Database:** query autenticada ao banco
- [...]
## Análise STRIDE
Para cada componente / fluxo, considerar as 6 categorias:
### Componente: [Endpoint /api/login]
#### S — Spoofing (alguém finge ser outro)
- **Ameaça:** atacante usa credenciais roubadas
- **Mitigação:** rate limiting; alerta de login geográfico anômalo;
MFA opcional/obrigatório
- **Ameaça:** session hijacking via XSS
- **Mitigação:** cookie HttpOnly + SameSite=strict; CSP rigoroso
#### T — Tampering (alteração indevida de dados)
- **Ameaça:** modificação do JWT em trânsito
- **Mitigação:** assinatura HMAC/RSA; HTTPS obrigatório
- **Ameaça:** SQL injection
- **Mitigação:** prepared statements; ORM; input validation
#### R — Repudiation (negar ter feito ação)
- **Ameaça:** usuário nega ter feito uma operação financeira
- **Mitigação:** audit log imutável (append-only) com timestamp,
user_id, IP, action; sign de operações críticas
#### I — Information disclosure (vazamento de dado)
- **Ameaça:** error message expõe stack trace ou dados sensíveis
- **Mitigação:** error handler genérico em produção; logs
estruturados sem PII no nível ERROR
- **Ameaça:** IDOR — acessar /pedidos/123 de outro usuário
- **Mitigação:** authorization baseada em recurso (não só auth)
#### D — Denial of service
- **Ameaça:** flood de login attempts esgota recursos
- **Mitigação:** rate limit por IP e por user; CAPTCHA após N falhas;
Cloudflare/WAF na borda
- **Ameaça:** queries pesadas sem timeout
- **Mitigação:** statement_timeout no banco; circuit breaker
#### E — Elevation of privilege
- **Ameaça:** usuário comum acessa endpoint admin
- **Mitigação:** RBAC em todas as rotas; "deny by default"; auditoria
periódica de permissões
- **Ameaça:** SSRF — server faz request a localhost/metadata IMDS
- **Mitigação:** allowlist de hosts; bloquear IPs internos
[Repetir para cada componente significativo]
## Resumo de riscos
| ID | Categoria | Componente | Severidade | Likelihood | Mitigação | Status |
|----|-----------|-----------|------------|-----------|-----------|--------|
| T-001 | STRIDE-S | /api/login | Alta | Média | Rate limit + MFA | Implementado |
| T-002 | STRIDE-I | /api/me | Crítica | Alta | Auth + Cache-Control: private | Implementado |
| T-003 | STRIDE-D | / (todos) | Alta | Alta | WAF + rate limit | A implementar |
| ... | | | | | | |
### Severidade
- **Crítica:** dados sensíveis vazam, financeiro, RCE
- **Alta:** comprometimento de conta, DoS sustentado
- **Média:** acesso não autorizado limitado
- **Baixa:** informação pública exposta de forma indevida
## Compliance
- [GDPR — quais dados pessoais e como protegidos]
- [LGPD — equivalente brasileiro]
- [PCI DSS — se toca em cartão]
- [SOC 2 / ISO 27001 — se aplicável]
## Plano de revisão
- **Frequência:** trimestral, ou a cada feature security-relevant
- **Owner:** [@security-lead]
- **Próxima revisão:** [data]
STRIDE é exaustivo de propósito. Você vai pensar em coisas que parecem improváveis. Resista à tentação de pular categorias "porque não se aplica" — a categoria que parece não se aplicar é frequentemente onde a vulnerabilidade mora. O exercício custa poucas horas e revela buracos que em produção custam meses.
Referências
- Adam Shostack, Threat Modeling: Designing for Security (Wiley, 2014)
- OWASP — Threat Modeling Process
- Microsoft Threat Modeling Tool
- OWASP Top 10 — categorias de vulnerabilidades comuns