ATALAIAA maioria das equipas tem requisitos de segurança algures. Vivem numa página da wiki, num PDF de políticas ou numa folha de cálculo escrita uma vez para uma auditoria. Os programadores não os leem enquanto constroem, porque não estão onde o trabalho acontece. O trabalho acontece nos tickets.
A solução é simples e um pouco aborrecida: pôr o abuse case no mesmo ticket que a user story. Se a story diz o que um utilizador legítimo quer, o abuse case diz o que outra pessoa quer da mesma funcionalidade. Ambos são refinados, estimados e testados em conjunto.
O que é um abuse case
Uma user story tem uma forma conhecida: como cliente, quero exportar as minhas faturas, para as poder enviar ao meu contabilista. Um abuse case troca o ator e o objetivo: como outro cliente com sessão iniciada, quero exportar as faturas de outra pessoa, para poder ler os seus dados de faturação.
Não é um threat model. É um único abuso concreto de uma funcionalidade, escrito em linguagem simples, curto o suficiente para caber na descrição do ticket. O threat model é onde se raciocina sobre o sistema inteiro; o abuse case é onde esse raciocínio chega à frente de quem escreve o código.
Os bons abuse cases partilham três características:
- Um ator identificado. Outro tenant, um visitante não autenticado, um agente de suporte, uma integração comprometida. Não "um hacker".
- Um ganho concreto. Ler dados, alterar estado, gastar dinheiro, negar serviço, escalar uma função.
- Um resultado testável. Consegue escrever o teste que prova que não funciona.
Um template que cabe num ticket
Mantenha-o curto o suficiente para que ninguém o salte. Este é o bloco que sugerimos acrescentar ao seu modelo de história:
## Abuse cases
- As [actor], I want to [misuse], so that [gain].
Expected: [what the system does instead]
Test: [unit | integration | QA | manual]
## Security acceptance criteria
- [ ] Object-level access checked on every export request
- [ ] Export is rate-limited per account
- [ ] Export events are logged with actor and object idA linha "Esperado" é a importante. Transforma uma preocupação num requisito. "Alguém podia exportar as faturas de outras pessoas" é uma preocupação. "Pedir um id de fatura que pertence a outra conta devolve 404 e escreve um evento de auditoria" é um requisito que um programador consegue construir e o QA consegue testar.
De onde vêm os abuse cases
Não precisa de um security engineer em cada sessão de refinement. Precisa de uma lista curta de perguntas que a equipa percorre para cada story. Estas cobrem a maioria das funcionalidades:
- De quem são estes dados? Se a story toca num objeto que pertence a um utilizador ou tenant, escreva o abuse case "outro utilizador".
- Quem o pode alterar? Se a story escreve estado, escreva o abuse case "função inferior".
- Quanto nos custa? Se a story envia email, chama uma API paga ou gera ficheiros, escreva o caso "fazer isto dez mil vezes".
- Em que é que confia? Se a story aceita um ficheiro, URL, webhook ou texto livre, escreva o caso "input hostil".
- Quem o vai negar? Se a story movimenta dinheiro ou permissões, escreva o caso "não fui eu", o que normalmente significa logging.
Para os requisitos em si, o OWASP ASVS é um bom menu. Escolha os controlos que correspondem aos abuse cases que escreveu e ligue o item do ASVS nos critérios de aceitação. Copiar a norma inteira para o backlog não ajuda ninguém.
Um exemplo prático
Pegue numa story para uma funcionalidade de convite à equipa: como admin, quero convidar um colega por email, para que ele possa juntar-se ao meu workspace. Correr as perguntas dá:
| Pergunta | Abuse case | Esperado |
|---|---|---|
| Dados de quem | Um membro do workspace A envia um convite para o workspace B | O endpoint de convites verifica que quem chama pertence ao workspace de destino |
| Quem o pode alterar | Um viewer convida alguém como admin | Quem chama não pode atribuir um papel superior ao seu |
| Quanto custa | Um script envia milhares de convites para endereços arbitrários | Rate limit por workspace e por utilizador; os convites expiram |
| Em que confia | O token de convite é adivinhável ou reutilizável | Token de uso único, aleatório, com tempo limitado e associado ao email |
Quatro linhas, talvez dez minutos de conversa. Cada linha passa a ser um critério de aceitação e, idealmente, um teste automatizado. É esse o método todo.
Fazer com que pegue
O método falha em silêncio quando os abuse cases se tornam uma caixa para assinalar. Alguns hábitos ajudam:
- Definition of ready. Uma story que toca em dados, funções ou dinheiro não está pronta sem pelo menos um abuse case.
- Definition of done. O abuse case tem um teste, ou uma nota explícita a explicar porque está coberto noutro sítio.
- Rever o que escapou. Quando um pentest ou um bug report encontra algo, pergunte a que story pertencia e se um abuse case o teria apanhado. Adicione o padrão à página partilhada.
- Alimentar o threat model. Abuse cases que se repetem apontam para uma fraqueza de design. Leve-os de volta à arquitetura e corrija uma vez.
Pense nisto como a ficha de inspeção que acompanha a peça ao longo da linha, em vez de um manual guardado no escritório.
O que fazer na segunda-feira
- Adicione o bloco de abuse case ao seu template de story.
- Imprima as cinco perguntas e use-as na próxima sessão de refinement.
- Escolha as três histórias do sprint atual que mexem em dados de utilizadores e escreva já os seus abuse cases.
- Acorde com QA que cada abuse case tem um teste, mesmo que manual.
- Ao fim de um mês, veja a página partilhada e quais os padrões que se repetem. Essas são as suas próximas conversas de design.
Onde isto fica na linha
Na torre (em desenvolvimento):