ATALAIA
Marcar chamada→
  1. Início
  2. Recursos
  3. Blog
  4. Threat modeling, em conjunto
Design · Guia

Threat modeling, em conjunto

Porque é que os melhores threat models acontecem com negócio, programadores e cyber na mesma sala, e como conduzir um numa hora.

3 min de leituraEquipa Atalaia

Threat modelingSTRIDEWorkshops

A maioria dos threat models falha de uma de duas formas. Ou a segurança escreve-os sozinha, e descrevem um sistema que ninguém na equipa reconhece. Ou chegam tarde, e descrevem um sistema que já foi lançado.

A solução não é um template melhor. É uma sala melhor.

Quem está na sala

Produto, porque sabe para que serve a funcionalidade e o que o negócio detestaria perder. O dev lead, porque sabe como é realmente construída. Alguém da segurança, porque sabe como as coisas partem. Security champions, se os houver.

A hora

  1. 10 min · desenharUma funcionalidade, um quadro. Caixas para componentes, setas para dados, linhas tracejadas onde a confiança muda. Feio e rápido.
  2. 30 min · partirPercorrer cada seta e perguntar: quem poderia falsificar isto, alterar isto, ler isto, bloquear isto ou usá-lo para ganhar mais acesso do que devia?
  3. 15 min · ordenarImpacto vezes probabilidade, mais ou menos. O produto decide o que o negócio aguenta; a segurança diz quão difícil é explorar cada um.
  4. 5 min · criar ticketsCada ameaça que fica torna-se um ticket com um responsável. Os abuse cases vão para QA como ideias de testes.

Partir, com o STRIDE como guia

As seis letras STRIDE dão boas perguntas para cada seta: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege. Escreva todas as respostas, mesmo as tontas. As tontas são muitas vezes onde o bug real se esconde.

O que muda

Os developers deixam de ouvir falar de segurança pela primeira vez num relatório de pentest. O produto percebe porque é que um controlo importa. A segurança aprende como o sistema funciona de facto. E o threat model vive no repo, ao lado do código, onde é atualizado.

O que fazer na segunda-feira

  • Escolha a próxima funcionalidade com um novo input externo ou um novo armazenamento de dados.
  • Marque uma hora com produto, o dev lead e segurança.
  • Faça commit da foto do quadro e da lista de ameaças como docs/threat-model.md.

Onde isto fica na linha

Threat ModelingRequisitos de Segurança

Na torre (em desenvolvimento):

Layered Threat Model

Continuar a ler

DesignOpiniãoMantenha o seu threat model em camadas

Um único documento de threat model fica desatualizado na semana a seguir ao workshop. Divida-o em camadas e atualize cada uma quando essa camada mudar.

4 min de leituraDesignAnálise a fundoFronteiras de confiança que cabem numa página

Se o seu diagrama de arquitetura não mostra onde muda a confiança, não lhe pode dizer para onde vão os ataques. Eis como desenhar um que o faça.

4 min de leituraDesignGuiaOs abuse cases pertencem ao lado das user stories

Escreva a misuse story no mesmo ticket que a funcionalidade, e os requisitos de segurança deixam de ser um documento que ninguém abre.

4 min de leitura

Vamos conversar

Uma chamada de 30 minutos. Sem slides, sem tabela de preços, e um próximo passo em qualquer caso.

Marcar uma chamada →Percorra cada estação