A modelação de ameaças tem fama de ser pesada, e as metodologias completas merecem-na. Mas o valor concentra-se nos primeiros noventa minutos, e uma equipa pequena pode captar a maior parte dele numa sessão antes de cada funcionalidade relevante.
Quatro perguntas, um quadro
- O que estamos a construir? Desenhe o fluxo de dados, incluindo todas as fronteiras de confiança que atravessa.
- O que pode correr mal? Percorra cada fronteira e pergunte quem a poderia atravessar e com quê.
- O que vamos fazer quanto a isso? Atribua um controlo ou um risco aceite a cada item.
- Fizemos um bom trabalho? Reveja quando o desenho mudar de forma material.
O diagrama importa mais do que a taxonomia. A maioria das descobertas reais vem de alguém reparar que um serviço fala directamente com uma base de dados a que não devia chegar, ou que um endpoint de webhook não tem autenticação porque se assumiu que era interno.
As conclusões precisam de responsáveis e de datas
Um modelo de ameaças que produz um documento não produz nada. Cada risco aceite recebe um responsável designado e uma data de revisão; cada controlo torna-se uma tarefa no mesmo backlog do trabalho de funcionalidades. Itens de segurança que vivem noutro sistema não são feitos.
Priorizar por explorabilidade e raio de impacto
Ordene por quão facilmente um problema pode ser alcançado e por quanto expõe, e não por CVSS isolado. Um endpoint sem autenticação que devolve registos de clientes ultrapassa sempre um ataque teórico de temporização a um serviço interno.
O objectivo de um modelo de ameaças é mudar o desenho. Se nada na arquitectura mudou, a sessão foi uma reunião.