Uma vulnerabilidade descoberta em produção exige dois custos simultâneos. O custo técnico de remediação, que em arquitetura estabelecida pode exigir redesign significativo. E o custo de impacto ao usuário, que em sistemas financeiros ou de saúde carrega consequência regulatória. Os dois são evitáveis quando a ameaça é identificada antes de qualquer código ser escrito. A fase de design é quando mudar uma decisão de segurança custa uma conversa, não um sprint de retrabalho.
Subcapability 02 de 04 · Security Engineering
Threat Modeling
STRIDE e attack trees no design que identificam ameaças antes de qualquer código, eliminam o redesign forçado por vulnerabilidade em produção e incorporam risco ao raciocínio arquitetural.
O que está em jogo
O time projetou a integração com parceiro sem mapear o que acontece quando o token é roubado. Descobriu em produção, com cliente afetado e notificação de incidente obrigatória. Cada decisão arquitetural que ignora ameaça potencial adia o custo de segurança para o momento de maior impacto.
O que é, na prática
Como atuamos
STRIDE aplicado no design
Facilitamos análise de ameaças usando o framework STRIDE durante o design de cada feature crítica e de cada integração com sistemas externos. Cada categoria de ameaça, Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service e Elevation of Privilege, é sistematicamente considerada antes de qualquer decisão de implementação.
Data Flow Diagrams com trust boundaries
Construímos diagramas de fluxo de dado com trust boundaries explícitas que tornam visíveis cada ponto onde dado cruza perímetro de confiança. Suposições implícitas sobre quem pode acessar o quê se tornam decisões explícitas com controle associado.
Attack trees para priorização de mitigação
Mapeamos caminhos plausíveis de exploração como attack trees que combinam probabilidade de execução com impacto no negócio. O resultado é uma lista priorizada de mitigações onde o investimento vai para onde o risco real está concentrado, não para onde o time tem mais familiaridade.
MITRE ATT&CK como referência de adversário
Usamos MITRE ATT&CK para fundamentar hipóteses de ameaça em táticas e técnicas observadas em ataques reais contra organizações similares. Ameaças baseadas em evidência de adversário real têm prioridade sobre ameaças teóricas que nunca foram observadas em produção.
Threat model vivo integrado ao SDLC
Estabelecemos processo de revisão de threat model em cada mudança arquitetural relevante, integrando a análise ao ciclo normal de design review em vez de tratá-la como evento separado. O modelo cresce com o sistema, capturando ameaças introduzidas por cada nova funcionalidade.
Ganhos mensuráveis
O que muda no resultado quando essa subcapacidade amadurece.
Issues de segurança identificados antes do início da implementação
Ameaça identificada no design tem custo de mitigação equivalente a ajustar um diagrama ou adicionar um controle ao backlog. A mesma ameaça descoberta em produção exige redesign, remediação emergencial e gestão de impacto ao usuário.
Percentual de sistemas críticos com threat model atualizado
Sistemas com threat model ativo têm superfície de ataque documentada e controles mapeados. Sistemas sem threat model têm superfície de ataque desconhecida. A diferença aparece no tempo de resposta a cada nova ameaça publicada.
Custo de redesign arquitetural forçado por vulnerabilidade em produção
Decisão arquitetural que introduz vulnerabilidade custa, em design, uma conversa de trinta minutos. Em produção estabelecida, custa sprint de redesign, sprint de migração e sprint de teste. Threat modeling elimina a categoria mais cara de decisão de segurança.
Tempo médio entre mudança arquitetural e revisão de ameaças associadas
Com processo integrado ao ciclo de design review, threat model é revisado na mesma semana em que a mudança arquitetural é discutida. Sem processo, a revisão acontece no pentest, meses depois, com custo de remediação máximo.
Perguntas frequentes
Quem deve conduzir o threat modeling: time de segurança ou time de produto?
O threat modeling mais eficaz é conduzido colaborativamente. O time de produto conhece o domínio e os casos de uso. O time de segurança conhece os padrões de ataque. Security Champions nos squads são a ponte que torna esse processo escalável sem depender de um especialista centralizado em cada feature. O resultado da colaboração é um threat model que cobre tanto ameaças técnicas quanto ameaças específicas do contexto de negócio.
Com que frequência o threat model deve ser atualizado?
Cada mudança arquitetural relevante justifica uma revisão: nova integração com sistema externo, novo fluxo de dado pessoal, mudança no modelo de autenticação, novo endpoint público. Sistemas que não mudam podem ter revisão semestral. Sistemas em desenvolvimento ativo devem ter revisão a cada sprint de design significativo. O critério é mudança de superfície de ataque, não calendário.
Como escolher entre STRIDE e PASTA para threat modeling?
STRIDE é mais adequado para times que estão começando com threat modeling: a estrutura de seis categorias é direta e aplicável a qualquer tipo de sistema. PASTA adiciona análise de impacto no negócio e simulação de cenário de ataque, sendo mais adequado para sistemas com exposição direta a risco financeiro ou regulatório alto. Para a maioria dos contextos, STRIDE com MITRE ATT&CK como referência de adversário cobre o espectro necessário.
O que é MITRE ATT&CK e como ajuda no threat modeling?
MITRE ATT&CK é uma base de conhecimento de táticas e técnicas usadas por adversários reais, organizadas por fase de ataque. Em threat modeling, ATT&CK ajuda a fundamentar hipóteses de ameaça em comportamento adversarial observado, em vez de ameaças teóricas genéricas. Para cada sistema, é possível identificar quais técnicas da matriz são relevantes dado o perfil do adversário mais provável, tornando a análise mais precisa e priorizada.
Threat modeling se aplica apenas a sistemas novos ou também a sistemas legados?
Aplica-se aos dois, com abordagem diferente. Para sistemas novos, threat modeling ocorre durante o design. Para sistemas legados, começa com um threat model de estado atual que mapeia a superfície de ataque existente, identifica controles presentes e ausentes, e prioriza remediação por risco. Muitas organizações descobrem, no primeiro threat model de um sistema legado, ameaças que existiam há anos sem controle associado.
Outras subcapabilities desta capability
Shift-Left Security
SAST, DAST e SCA integrados ao pipeline de CI que reduzem custo de correção por ordem de magnitude e eliminam o pentest anual como única linha de defesa.
Compliance as Code
Open Policy Agent e NIST 800-53 como código que transformam controles regulatórios em propriedade verificável continuamente e eliminam a planilha de véspera de auditoria.
Security Champions Program
Rede de Champions estruturada pelo OWASP SAMM que distribui capacidade de segurança pelos squads, elimina o gargalo central e multiplica proteção sem multiplicar headcount.
Quer clareza sobre onde investir primeiro?
Diagnóstico completo de capacidades de tecnologia com roadmap de evolução conectado ao resultado financeiro.