Modelagem de ameaças: STRIDE e árvores de ataque

1. Introdução à Modelagem de Ameaças para Desenvolvedores

Modelagem de ameaças é o processo sistemático de identificar, documentar e mitigar potenciais riscos de segurança em um sistema. Para desenvolvedores, essa prática não é opcional — é uma etapa crítica no ciclo de vida de desenvolvimento seguro (SDLC).

Antes de avançarmos, é essencial diferenciar três conceitos fundamentais:

  • Vulnerabilidade: uma fraqueza no sistema (ex.: falta de validação de entrada)
  • Ameaça: algo que pode explorar uma vulnerabilidade (ex.: um invasor enviando payloads maliciosos)
  • Risco: a probabilidade de uma ameaça causar dano multiplicada pelo impacto potencial

Duas abordagens se destacam para desenvolvedores: STRIDE, da Microsoft, e árvores de ataque, propostas por Bruce Schneier. STRIDE oferece uma categorização ampla de ameaças, enquanto árvores de ataque permitem explorar caminhos específicos que um atacante pode seguir.

2. Fundamentos do STRIDE

Criado por engenheiros da Microsoft na década de 1990, STRIDE é um acrônimo que representa seis categorias de ameaças:

Letra Significado Propriedade violada Exemplo
S Spoofing Autenticação Falsificar identidade de um usuário
T Tampering Integridade Modificar dados em trânsito
R Repudiation Não-repúdio Usuário negar ter realizado uma ação
I Information Disclosure Confidencialidade Vazar dados sensíveis
D Denial of Service Disponibilidade Sobrecarregar um servidor
E Elevation of Privilege Autorização Obter acesso administrativo

Cada letra mapeia diretamente para componentes de segurança que devemos implementar:

  • Spoofing → Autenticação forte (MFA, certificados)
  • Tampering → Hashing, assinaturas digitais, TLS
  • Repudiation → Logs imutáveis, trilhas de auditoria
  • Information Disclosure → Criptografia, controle de acesso
  • Denial of Service → Rate limiting, balanceamento de carga
  • Elevation of Privilege → Princípio do menor privilégio, RBAC

3. Aplicando STRIDE na Prática

Vamos modelar uma API REST simples de um sistema de blog. Primeiro, identificamos ativos, fluxos de dados e limites de confiança:

Ativos: 
- Banco de dados de usuários
- Banco de dados de posts
- Tokens JWT
- Chave de API de terceiros

Fluxos de dados:
- Cliente → API (requisições HTTP)
- API → Banco de dados (consultas SQL)
- API → Serviço de email (notificações)

Limites de confiança:
- Entre cliente e API (rede pública)
- Entre API e banco de dados (rede interna)

Agora, aplicamos STRIDE a cada fluxo:

| Componente    | Ameaça STRIDE         | Descrição                                      |
|---------------|-----------------------|------------------------------------------------|
| Login endpoint| Spoofing              | Atacante força brute em senhas                 |
| API → DB      | Tampering             | Injeção SQL altera consultas                   |
| Logs de ação  | Repudiation           | Usuário nega ter publicado conteúdo ofensivo   |
| Resposta API  | Information Disclosure| Erro expõe stack trace com caminhos internos   |
| Upload de img | Denial of Service     | Upload de arquivo gigante consome memória      |
| Admin panel   | Elevation of Privilege| Usuário comum acessa rota /admin               |

Documente essas descobertas em uma tabela de ameaças que será revisada com o time:

ID: T-001
Ameaça: Injeção SQL no endpoint GET /posts?author={id}
Categoria STRIDE: Tampering
Impacto: Alto (exposição de dados de todos os usuários)
Probabilidade: Média
Mitigação: Usar ORM parametrizado, input validation
Status: Aberta

4. Construindo Árvores de Ataque

Bruce Schneier introduziu árvores de ataque em 1999 como uma forma de representar graficamente os caminhos que um atacante pode seguir para atingir um objetivo.

Estrutura básica:

  • Raiz: objetivo principal do atacante
  • Nós filhos: sub-objetivos ou ações necessárias
  • Operadores lógicos:
  • AND: todos os filhos devem ser realizados
  • OR: pelo menos um filho deve ser realizado

Exemplo de árvore para "Obter acesso ao banco de dados":

Obter acesso ao BD
├── OR
│   ├── AND
│   │   ├── Explorar injeção SQL
│   │   └── Contornar WAF
│   ├── AND
│   │   ├── Roubar credenciais de admin
│   │   └── Conectar via VPN interna
│   └── Explorar vulnerabilidade no SGBD

5. Integrando Árvores de Ataque com STRIDE

A combinação das duas abordagens é poderosa: use STRIDE para identificar ameaças de alto nível e depois construa árvores de ataque para explorar cada uma em detalhes.

Exemplo: Árvore de ataque para "Elevação de Privilégio" (categoria E do STRIDE)

Cenário: sistema web com roles "user" e "admin"

Elevar privilégio para admin
├── OR
│   ├── AND
│   │   ├── Explorar IDOR em /api/users/{id}/role
│   │   └── Bypass de validação de role no frontend
│   ├── AND
│   │   ├── Roubar cookie de sessão de admin
│   │   └── Session hijacking via XSS
│   ├── SQL injection para modificar tabela de roles
│   └── AND
│       ├── Explorar Race Condition em upgrade de plano
│       └── Manipular parâmetro "is_admin" no request

Para quantificar risco, conte o número de nós e a profundidade:

Profundidade máxima: 3 níveis
Nós folha: 5
Nós AND: 3
Nós OR: 2
Risco estimado: Alto (múltiplos caminhos viáveis)

6. Ferramentas e Boas Práticas para Devs

Ferramentas open source

  • OWASP Threat Dragon: editor gráfico de diagramas de fluxo de dados e ameaças. Gera relatórios em Markdown e JSON.
  • Microsoft Threat Modeling Tool: ferramenta da Microsoft com templates STRIDE integrados e geração automática de ameaças.

Versionamento de modelos de ameaças

Trate modelos de ameaças como código. Exemplo de arquivo YAML:

# threat-model.yaml
version: "1.0"
application: "Blog API"
date: "2024-01-15"
threats:
  - id: "T-001"
    category: "Tampering"
    description: "SQL injection in author filter"
    mitigation: "Use parameterized queries"
    status: "mitigated"

Dicas para times ágeis

  1. Sessões curtas: 30-45 minutos por sprint, focando em novas features
  2. Incremental: modele apenas o que mudou desde a última revisão
  3. Documentação viva: atualize o modelo junto com o código no PR
  4. Papéis rotativos: cada sprint um dev diferente lidera a sessão

7. Exemplo Completo: Aplicação de E-commerce

Cenário: Carrinho de compras com autenticação JWT e gateway de pagamento Stripe.

Aplicação de STRIDE

| Componente          | Ameaça STRIDE         | Descrição                                      |
|---------------------|-----------------------|------------------------------------------------|
| Login com Google    | Spoofing              | Atacante usa token OAuth falsificado           |
| Carrinho → API      | Tampering             | Modificar quantidade de itens no request       |
| Log de transações   | Repudiation           | Cliente nega compra após receber produto       |
| Resposta de preço   | Information Disclosure| Vazar preço de custo no JSON                   |
| Checkout            | Denial of Service     | Múltiplos checkouts simultâneos sem pagamento  |
| Admin → API         | Elevation of Privilege| Usuário comum acessa endpoint de reembolso     |

Árvore de ataque para "Roubo de dados de cartão de crédito"

Roubar dados de cartão de crédito
├── OR
│   ├── AND
│   │   ├── Interceptar tráfego HTTPS (MITM)
│   │   └── Certificado SSL inválido ou expirado
│   ├── AND
│   │   ├── Explorar XSS no formulário de pagamento
│   │   └── Keylogger JavaScript captura input
│   ├── Acessar logs do servidor com dados de pagamento
│   └── AND
│       ├── SQL injection na tabela de transações
│       └── Dados de cartão armazenados sem criptografia

Mitigações sugeridas e priorização

Prioridade 1 (Crítica):
- Implementar HSTS e Certificate Pinning
- Nunca armazenar dados de cartão (usar tokenização do Stripe)
- Sanitizar todos os inputs (XSS e SQLi)

Prioridade 2 (Alta):
- Rate limiting no endpoint de checkout
- Logs sem dados sensíveis (apenas últimos 4 dígitos)
- Auditoria de acesso a logs do servidor

Prioridade 3 (Média):
- Content Security Policy para bloquear scripts inline
- Validação de integridade de payloads com HMAC
- Monitoramento de anomalias em transações

Referências