Threat Modeling e controle de risco

1) Princípios

1. Architectural First. Começamos com contextos, limites de confiança e fluxos de dados.
2. Risk ≈ Likelihood × Impact. Medimos, não sentimos.
3. Defense in Depth. Controlaram cada camada, código → protocolo → plataforma → pessoas.
4. Shift Left/Right. Gates iniciais em PR + monitoramento e resposta em venda.
5. Privacy by Design. Não apenas modelamos as ameaças de segurança, mas também os riscos de privacidade.
6. Automate Where Possible. Políticas como código, carros, linhas vermelhas.

2) Inventário: bens, entidades, limites de confiança

Ativos: dados (PII, finanças, segredos), recursos de computação, chaves, acessibilidade, processos de negócios.
Sujeitos: usuários, serviços, adminhas, parceiros, provedores externos.
Limites de confiança: usuários, frente, frente entrada de API, serviços BD/cachês/filas, regiões/nuvens.
Superfície de ataque: pontos de entrada (API, webhooks, UI, redes, CI/CD, suply chain).

mermaid flowchart LR
U[Пользователь] -- TLS --> WAF[WAF/CDN]
WAF --> GW[API Gateway]
GW --> Svc[Service A]
Svc --> DB[(Postgres)]
Svc --> MQ[[Kafka]]
MQ --> SvcB[Service B]
subgraph Trust Boundary
GW; Svc; SvcB end

3) Quadros de ameaças

STRIDE (безопасность): Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.
LINDDUN (приватность): Linkability, Identifiability, Non-repudiation, Detectability, Disclosure, Unawareness, Non-compliance.
PASTA (processo): a partir de objetivos empresariais e acertos de ameaças → detalhes técnicos → cenários de teste.

4) Avaliação de risco

DREAD/OWASP Risk Rating ou CVSS para vulnerabilidades.
Probabilidade (L): motivo/capacidade do ataque, complexidade, exposição da superfície.
Impacto (I): finanças, advogados, interrupções, fugas de PD.
Risco (R = L x I) - Priorização e trituração: Avoid/Reduse/Transfer/Accept.

Impact
Low Med High Critical
Lik Low  L  L  M   H
Med  L  M  H   H
High M  H  High  Crit

Registro de risco (mínimo de campos): 'id, cenário, STRIDE, ativo, L, I, R, proprietários, controladores, status, data de revisão'.

5) Controladores: Prevent/Detect/Respond

• Autenticação/Autorização: OIDC/OAuth2, PoLP, RBAC/ABAC, serviço de crédito de curto prazo.
• Segredos/chaves: KMS/HSM, rotação, princípio «não saber», FPE/criptografia de campos.
• Protocolos seguros: TLS1. 2 +, mTLS, assinaturas de webhooks, idempotidade e anti-replay.
• Validação/saneamento: esquemas (JSON Schema/Proto), limites, normalização.
• Isolamento: network policies, segmentação, sandbox, namespaces, bulkheads.

• Auditorias-logs (não rejeitáveis), corelação em SIEM, alertas em anomalias.
• Monitoramento da assinatura e integridade (exportação de artefatos hasteados, attestation).
• Honeytokens/canários para o primeiro projeto de fuga de chaves.

• Runbook IR: classificação, isolamento, revisão de chaves, alertas, forense.
• Kill-switch/função-flag automático, «lista preta» de tokens.
• Notificações de usuários/reguladores em incidentes de PD.

6) SDL e gates de segurança

Na ideia/design: threat model (RFC/ADR), folha de cheque de controle.
Em desenvolvimento: SAST/secret-scan, scan de dependência (SCA), política de dependências.
Na montagem: SBOM, assinatura de artefatos, política de vulnerabilidade (limiar CVSS).
OPA/Kyverno - Política IaC/Manifestos (securityContext, políticas de rede, protecção de segredos).
Em venda: IDS/WAF, anataly detation, verificações canary, caos-segurança (por exemplo, certificado vencido).

rego package policy.cicd deny[msg] {
some v input.sbom.vulns[v].cvss >= 7.0 msg:= sprintf("High vuln blocked: %s %s", [v.package, v.id])
}
deny[msg] {
input.k8s.pod.spec.securityContext.runAsRoot == true msg:= "RunAsRoot forbidden"
}

7) Suply chain e confiança em artefatos

SBOM para cada imagem/pacote; atualizações de dependências - via bot/política.
SLSA/Provenance: montagens reproduzidas, assinaturas, atestações.
Contêineres: imagens mínimas, rootless, drop capabilities, read-only FS.
IaC-scan: Terraform/Helm - política de criptografia, portas abertas, regras de rede.

8) Privacidade e complacência

Mapa LINDDUN de ameaças de privacidade, data minimization, pseudonimização/anonimato.
Políticas de armazenamento: TTL/Retensivo, «direito de remoção», auditoria de acesso ao PD.
Localização: limitações geo, «dados permanecem na região».
Transparência: registros de processamento, notificação e consentimento.

9) Nuvens e perímetros

Zero Trust: Autenticação de cada solicitação mTLS/OPA entre os serviços.
Segmentação: VPC/Subeti/SG, endpoints privados, controle egress.
Chaves/segredos: KMS, rotation, créditos curtos em CI (OIDC).
Reserva/DR.: bacapes criptografados, chaves separadamente, ensaios de recuperação.

10) Os comandos vermelho/roxo e os exercícios tabletop

Red Team: Verificação de hipóteses de ameaças, engenharia social, exploração de cadeias.
Purple Team: depuração conjunta de detalhes/alertas, melhoria do playbook 'ov IR.
Tabletop: cenários «certificado expirado», «quebra de chaves», «suply-chain comprometimento». Resultado: controladores e métricas atualizados.

11) Métricas de maturidade e controle

Coverage:% dos serviços com o atual threat model e DFD.
MTTD/MTTR segurança, proporção de incidentes capturados pelos controladores.
Policy pass-rate em CI, hora em que as vulnerabilidades são fechadas por criticidade.
Privacidade:% datasets com TTL/ILM, proporção de acessibilidade com justificativa.
Auditoria: Regularidade da revisão do registro de risco (trimestral).

12) Modelos de artefatos

12. 1 Cartão de risco (exemplo)

Risk ID: SEC-API-012
Сценарий: SSRF через изображение в профиле
STRIDE: Tampering/Info Disclosure
Актив: API / файловый прокси
Likelihood: High  Impact: High  Risk: Critical
Контроли: denylist схем, egress-прокси, URL-fetcher в изолированном рантайме,
DNS-resolv только через прокси, время/размер-лимиты, allowlist.
Владелец: team-accounts  Статус: Reduce (в работе)
Дата пересмотра: 2025-12-01

12. 2 Folha de cheque de design

Bens e PII identificados? Os limites da confiança estão marcados?
Os DFD/contornos de dados são compostos e ligados a ADR?
Os STRIDE/LINDDUN foram ultrapassados por cada seta DFD?
É selecionada uma trituração de risco; há proprietários/prazos/doD?
Políticas como o código foi adicionado (OPA/Kyverno/CI-gate)?
O plano de monitoramento/alertas e o IR-runbook foram atualizados?
Privaciy: Minimização, criptografia, TTL/Retensão, localização?

12. 3 Política de webhooks (pseudocode)

python def verify_webhook(req, keys):
ts = int(req.h["X-Timestamp"])
if abs(now_utc()-ts) > 300: return 401 if not hmac_ok(req.body, ts, keys.active_or_prev(), req.h["X-Signature"]):
return 401 if replay_cache.seen(req.h["X-Event-ID"]): return 200
PoLP: в обработчике — только нужные скоупы handle(json.loads(req.body))
replay_cache.mark(req.h["X-Event-ID"])
return 200

13) Anti-pattern

O modelo Threat é «para caixa» sem DFD/invariantes.
Super perímetro sem autenticação interna do serviço.
Segredos de longa vida em variáveis ambiente/repo.
Políticas não incorporadas como código → «esquecido» manual.
Logs com PD sem disfarce e sem retensão/TTL.
Ignorar suply chain (sem SBOM/assinaturas/raias).
Aceitação de risco (Accept) sem dono ou data de revisão.

14) Integração em processos

RFC/ADR: Cada solução significativa contém a seção «Ameaças e controles».
Docs-as-Code: threat model, DFD, minúscula de risco na versão ao lado do código.
Release gates: O lançamento é bloqueado se o SAST/SCA/SBOM falhar ou os controles de alta criticidade faltarem.
Treinamento: playbooks para desenvolvedores (segredos, assinaturas, PoLP), tabletop regular.

Conclusão

Threat Modeling é uma prática de engenharia de gerenciamento de risco, não um documento descartável. Identifique os bens e limites de confiança, aplique o STRIDE/LINDDUN, mede o risco, anote-o no registro e implemente os controles como código, incorporando-os ao CI/CD e operação. Com métricas de maturidade e revisões regulares, você transformará a segurança em uma capacidade arquitetônica previsível - com um preço, um efeito e uma velocidade compreensíveis.