Pular para o conteúdo principal
Capítulo Basilar

Este capítulo é considerado basilar no modelo Security by Design - Theory of Everything (SbD-ToE). A sua aplicação é obrigatória para garantir a coerência, rastreabilidade e eficácia das restantes práticas de segurança.

A ausência ou aplicação parcial do Threat Modeling compromete a ligação formal entre risco, arquitetura e requisitos, tornando inviável uma adoção consistente do SbD-ToE.

Capítulo 3 - Threat Modeling

1. 🧭 O que cobre tecnicamente​

O Threat Modeling é a prática que permite antecipar ameaças reais antes da implementação, com base na arquitetura, fluxos de dados e contexto de risco da aplicação. É tratado como um processo decisional estruturado, sujeito a validação humana e produção de evidência verificável.
A ausência de uma ameaça num modelo não constitui prova da sua inexistência, devendo os riscos de omissão e enviesamento ser assumidos e mitigados explicitamente.

No SbD-ToE, o Threat Modeling constitui a origem formal dos requisitos de mitigação, ligando diretamente:

  • a classificação de risco (Cap. 1),
  • os requisitos de segurança (Cap. 2),
  • e as decisões de arquitetura (Cap. 4).

Este capítulo cobre:

  • A integração sistemática do threat modeling no ciclo de desenvolvimento
  • Métodos estruturados de análise de ameaças (STRIDE, LINDDUN, PASTA)
  • Criação e manutenção de modelos de ameaça baseados em arquitetura (DFDs, trust boundaries)
  • Identificação de ameaças técnicas e de negócio relevantes
  • Derivação explícita de requisitos e controlos a partir das ameaças identificadas
  • Rastreabilidade entre ameaça → requisito → mitigação → validação
  • Reutilização controlada de modelos em arquiteturas padronizadas
  • Extensão a sistemas AI/ML — sistemas com componentes de inteligência artificial (LLMs, modelos preditivos, RAG, agentes autónomos) requerem threat modeling estendido com ameaças adversariais específicas (model poisoning, prompt injection, data exfiltration, AI supply chain compromise) catalogadas em MITRE ATLAS e NIST AI 100-2; ver Metodologias — §AI/ML e requisito THR-008

2. 🧪 Prescrição prática: o quê, quem, como, quando, porquê e para quê​

🔐 Threat Modeling como elo entre risco, arquitetura e controlo​

Sem Threat Modeling, os requisitos de segurança perdem contexto
e os controlos aplicados deixam de ter origem justificada.

📌 O que deve ser feito​

  • Realizar threat modeling com base no nível de risco da aplicação
  • Modelar fluxos de dados e limites de confiança com base em artefactos de arquitetura
  • Identificar ameaças relevantes usando modelos reconhecidos
  • Associar cada ameaça a:
    • um ou mais requisitos de mitigação,
    • controlos técnicos ou organizacionais,
    • e critérios de validação
  • Documentar decisões, riscos aceites e ações futuras
  • Validar o modelo de ameaças como parte da revisão de arquitetura

⚙️ Como deve ser feito​

  • Utilizar diagramas claros e versionados (DFDs, context diagrams)
  • Aplicar metodologias como STRIDE, LINDDUN ou PASTA de forma proporcional
  • Integrar o exercício em rituais existentes (design review, refinamento técnico)
  • Criar itens rastreáveis no backlog para cada mitigação relevante
  • Alinhar requisitos derivados com o Catálogo de Requisitos (Cap. 2)
  • Reutilizar modelos apenas quando a arquitetura e o contexto forem equivalentes

Ferramentas especializadas podem suportar o processo,
mas não substituem a análise humana nem a validação técnica.

📆 Quando aplicar​

  • No início de projetos ou épicos relevantes
  • Antes de integrações externas, exposições ou mudanças arquiteturais
  • Sempre que a aplicação seja classificada como L2 ou L3
  • Sempre que ocorram alterações que possam modificar o perfil de ameaça

👥 Quem está envolvido​

Papel/FunçãoResponsabilidades principais
Arquitetos de Software / DevOps / SREFacilitar o processo e manter os modelos atualizados
Equipa de DesenvolvimentoExplicar fluxos, lógica e superfícies de ataque
Segurança / AppSecIdentificar ameaças, vetores e técnicas de ataque relevantes
Product Owner / NegócioValidar impacto, prioridade e aceitabilidade do risco

3. ⚠️ Caveats e limitações​

  • Modelos demasiado abstratos tornam-se inúteis
  • Documentação não versionada perde valor operacional
  • Ferramentas automatizadas não capturam contexto de negócio
  • A ausência de ligação a requisitos e backlog anula o valor do exercício

4. 💡 Exemplos e reutilização​

  • Exemplos de aplicação de STRIDE por tipo de arquitetura
  • Exemplos de threat modeling focado em privacidade (LINDDUN)
  • Exemplos de integração com ferramentas de suporte (ex.: IriusRisk)

5. 🔍 O que pode ser feito mais (e porquê)​

  • Criar bibliotecas internas de ameaças reutilizáveis por tipo de sistema
  • Integrar o threat modeling com pipelines de validação e gates de arquitetura
  • Usar o histórico de incidentes e findings para enriquecer os modelos
  • Formar facilitadores técnicos para sessões iterativas e leves

🧩 Ligações a outros capítulos​

CapítuloRelação técnica
Cap. 1 – Gestão de RiscoDetermina quando o threat modeling é obrigatório
Cap. 2 – Requisitos de SegurançaRecebe requisitos derivados das ameaças
Cap. 4 – Arquitetura SeguraFonte primária dos artefactos modelados
Cap. 7 – CI/CD SeguroSuporta rastreabilidade e validação
Cap. 10 – Testes de SegurançaValida requisitos derivados

📌 Este capítulo é obrigatório para aplicações L2 e L3.
É o mecanismo que garante que os requisitos de segurança respondem a ameaças reais,
e que a arquitetura é avaliada antes de ser explorada em produção.

📜 Políticas Organizacionais Relevantes​

PolíticaObrigatória?AplicaçãoConteúdo mínimo
Política de Threat Modeling✅ Sim (L2–L3)AppSec, ArquiteturaMetodologia obrigatória, âmbito, artefactos mínimos, rastreabilidade e cadência

📎 Ver detalhe das políticas recomendadas para este capítulo
Na versão impressa, consultar o Anexo de Políticas Organizacionais do manual.