Um modelo de ameaças útil explica o que protege, quem ou o que o pode afetar, onde a confiança muda e como vai reduzir e testar os riscos mais importantes. Comece pelo projeto real em vez de uma lista genérica de ferramentas.
Defina um âmbito suficientemente pequeno para poder raciocinar sobre ele
Comece com um serviço em funcionamento: um portal de clientes, um site de publicação ou uma aplicação interna. Anote os componentes que opera e os sistemas externos em que se baseia. Um modelo de ameaças deve tornar visíveis os pressupostos, não sugerir que todos os ataques possíveis foram resolvidos. Mantenha a primeira versão suficientemente pequena para que as pessoas que implementam a aplicação a possam explicar sem um consultor separado a interpretar o diagrama.
Liste os resultados e os ativos valiosos. Estes podem incluir dados de clientes, acesso de administração, estado de pagamento, conteúdo publicado e a capacidade de restaurar o serviço. A disponibilidade pode ser um ativo mesmo quando a informação é pública. Decida que falhas seriam inconvenientes e quais prejudicariam pessoas ou a organização. Essa distinção ajuda a priorizar controlos em vez de tratar todos os avisos da mesma forma.
Desenhe os pontos onde a confiança muda
As orientações de modelação de ameaças da OWASP utilizam fluxos de dados e limites de confiança para tornar um design compreensível. Para uma pequena aplicação alojada, desenhe o navegador, o processo web, a base de dados, o administrador, o destino das cópias de segurança e as integrações externas. Marque a informação que circula entre eles. Um pedido que atravessa de um cliente não fidedigno para uma operação privilegiada do servidor merece validação e autorização explícitas.
Não parta do princípio de que estar dentro da mesma máquina torna todos os componentes igualmente fidedignos. Um processo de carregamento público não deve ter as mesmas permissões que a administração da base de dados. Uma tarefa de cópia de segurança pode precisar de acesso de leitura sem a capacidade de modificar registos da aplicação em produção. Separar esses papéis torna mais fácil conter o efeito de um componente comprometido e rever as permissões necessárias.
Escolha cenários de falha concretos
Utilize alguns eventos plausíveis para desafiar o design. Um atacante rouba uma palavra-passe de administrador; um utilizador pede o registo de outro utilizador; um carregamento enche o disco; uma implementação expõe um ficheiro de configuração; uma cópia de recuperação não pode ser restaurada. Descreva a condição inicial, o componente afetado e a consequência. Um cenário específico é mais fácil de testar do que uma instrução ampla para melhorar a segurança.
Inclua erros e abuso legítimo de fluxos de trabalho, bem como intrusões externas. Uma nova tentativa pode criar duas operações valiosas, ou dois pedidos podem competir para alterar o mesmo objeto. As orientações da OWASP sobre lógica de negócio destacam estes pressupostos de processo. Verifique quem tem permissão para fazer avançar um fluxo de trabalho para o estado seguinte e se repetir ou reordenar um pedido altera o resultado de forma inesperada.
| Cenário | Controlo a investigar | Evidência a recolher |
|---|---|---|
| Credencial de administração roubada | Acesso restrito e um segundo fator quando suportado | Um início de sessão não autorizado não pode ser concluído |
| Objeto de outro utilizador solicitado | Autorização de objetos no lado do servidor | Um teste isolado devolve um resultado negado |
| Disco esgotado por carregamentos | Controlos de tamanho, quota e retenção | É aplicado um limite antes da falha do serviço |
| Pedido de fluxo de trabalho duplicado | Idempotência e limites de transação | Um pedido repetido cria um único resultado |
Priorize pelo impacto e por um percurso credível
Para cada cenário, registe o seu impacto potencial e as condições necessárias para que ocorra. Evite fingir que uma pontuação numérica estimada é uma probabilidade precisa. Ainda pode distinguir uma palavra-passe fraca exposta à internet de um evento local altamente condicional. Atribua um responsável e um próximo passo prático aos riscos importantes, para que o modelo crie trabalho que alguém possa realmente concluir.
Considere o ciclo de vida da informação, bem como o comprometimento da aplicação. Uma exportação de diagnóstico pode divulgar dados desnecessários durante um funcionamento normal. Um campo de conta retido pode criar exposição muito depois de a sua finalidade terminar. A revisão de privacidade pode, por isso, remover informação ou encurtar a retenção, enquanto a revisão de segurança restringe o acesso ao que resta. Ambas as alterações pertencem ao modelo quando protegem o projeto.
Teste os controlos num ambiente autorizado
Crie um ambiente de pré-produção com permissões representativas e registos fabricados. Teste acessos negados, limites de pedidos, novas tentativas de fluxos de trabalho e recuperação. Não utilize dados reais de clientes quando dados sintéticos podem demonstrar o comportamento. O objetivo é verificar o controlo, não gerar tráfego de ataque impressionante. Mantenha-se dentro dos sistemas que possui ou está explicitamente autorizado a avaliar.
Registe o que passou, o que falhou e o que permanece desconhecido. O resultado de um scanner pode contribuir com evidências, mas não substitui um teste às regras de negócio da aplicação. Do mesmo modo, uma opção de proteção de rede não verifica a autorização de objetos nem o tratamento de ficheiros de segredos. Anexe os resultados úteis ao cenário para que os futuros responsáveis pela manutenção compreendam porque existe um determinado controlo.
Mantenha o modelo ligado à mudança
Reveja as partes relevantes quando adicionar uma integração, expuser um novo endpoint, alterar um privilégio ou mover dados para outro destino. Não precisa de redesenhar toda a arquitetura por causa de uma pequena edição de texto. O gatilho é uma alteração de pressupostos sobre acesso, informação ou comportamento do sistema. Mantenha o modelo junto da documentação de implementação e recuperação, em vez de o deixar como o resultado de um workshop pontual.
O SwissOctet fornece um catálogo de opções de infraestrutura, não um modelo de ameaças de aplicação concluído. Escolha a configuração e as opções que suportam os seus controlos e, em seguida, verifique a implementação que constrói. Um modelo pequeno e mantido, com ações testadas, é mais útil do que uma grande coleção de produtos de segurança sem uma explicação clara dos riscos que abordam.
A sua lista de verificação prática.
- Liste os ativos e as consequências da falha.
- Desenhe os fluxos de dados e os limites de confiança.
- Escolha cenários específicos de intrusão, erro e fluxo de trabalho.
- Atribua controlos e responsáveis aos riscos importantes.
- Teste com dados sintéticos num ambiente autorizado.
- Reveja o modelo quando um pressuposto relevante mudar.
Os detalhes que importam.
Preciso de um quadro formal para começar?+
Não. Um pequeno diagrama e um conjunto documentado de cenários podem ser úteis. Um quadro ajuda a garantir que revê os riscos de forma consistente.
Um scanner de vulnerabilidades substitui a modelação de ameaças?+
Não. Os scanners podem encontrar fraquezas técnicas, enquanto um modelo de ameaças também examina pressupostos de design, permissões e fluxos de trabalho de negócio.
Com que frequência devo atualizar o modelo?+
Atualize as partes afetadas quando os fluxos de dados, as integrações, os privilégios ou a funcionalidade exposta mudarem, e reveja regularmente os riscos não resolvidos.
Vá à fonte.
Estas referências sustentam os conceitos técnicos deste guia. Siga a documentação atual antes de alterar um sistema de produção.
- OWASP: Folha de referência de modelação de ameaças cheatsheetseries.owasp.org
- OWASP: Modelação de ameaças na prática devguide.owasp.org
- OWASP: Segurança da lógica de negócio cheatsheetseries.owasp.org
Orientação editorial da SwissOctet. Os exemplos são ilustrativos. As especificações de serviço, as opções disponíveis e as condições contratuais devem ser verificadas separadamente.