Threat Modeling

Passo 1Escolher a funcionalidade

Uma funcionalidade ou serviço que importa neste trimestre, não o parque inteiro.

PRODUTOEste trimestre é a troca em parceiros: os utilizadores gastam pontos em lojas parceiras.

ATALAIAEntão é essa. Há dinheiro a circular e um parceiro envolvido. Só esse fluxo, hoje.

DEV LEADToca no ledger, na API do parceiro e no ecrã de troca.

Sai da salaFuncionalidade: trocar pontos em lojas parceiras

Passo 2Desenhar em conjunto

Fluxos de dados e fronteiras de confiança num só quadro, com produto, devs e cyber na sala.

DEV LEADA app chama o redeem, debitamos o ledger e depois pedimos um voucher ao parceiro.

ATALAIADesenhem uma linha tracejada onde começa a rede do parceiro. É uma fronteira de confiança.

DEVELOPERE o parceiro chama-nos de volta para confirmar. Esse webhook é público.

Sai da salaQuadro: 6 fluxos, 2 fronteiras de confiança

Passo 3Encontrar as ameaças

Perguntas ao estilo STRIDE, histórias de atacantes e as perguntas que ninguém fez ainda.

ATALAIAE se alguém enviar o redeem duas vezes, no mesmo instante?

DEVELOPERDois débitos em corrida. Podiam gastar os mesmos pontos duas vezes.

CHAMPIONE um webhook falso podia confirmar vouchers que ninguém pagou.

PRODUTOO gasto duplo é o que o negócio não pode aceitar. Fica em primeiro.

Sai da sala4 ameaças encontradas, 2 classificadas como altas

Passo 4Transformá-las em tickets

Cada ameaça sai como um ticket, um responsável e um teste.

DEV LEADChave de idempotência no redeem. Esse ticket é meu, neste sprint.

ATALAIAWebhooks assinados com a chave do parceiro. A QA fica com a corrida como teste.

PRODUTOE o modelo vai para o repo. Fazemos o próximo sem vocês.

Sai da sala4 tickets, 3 testes de abuso