Um modelo de ameaças útil explica o que você protege, quem ou o que pode afetá-lo, onde a confiança muda e como você reduzirá e testará os riscos mais importantes. Comece com o projeto real, em vez de uma lista genérica de ferramentas.
Defina um escopo pequeno o suficiente para 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 você opera e os sistemas externos dos quais depende. Um modelo de ameaças deve tornar as suposições visíveis, não sugerir que todo ataque possível foi resolvido. Mantenha a primeira versão pequena o suficiente para que as pessoas que implantam a aplicação possam explicá-la sem um consultor separado interpretando o diagrama.
Liste os resultados e ativos valiosos. Eles podem incluir dados de clientes, acesso administrativo, 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 quais falhas seriam inconvenientes e quais prejudicariam pessoas ou a organização. Essa distinção ajuda a priorizar controles em vez de tratar todo alerta igualmente.
Desenhe os pontos onde a confiança muda
A orientação de modelagem de ameaças da OWASP usa fluxos de dados e limites de confiança para tornar um design compreensível. Para uma pequena aplicação hospedada, desenhe o navegador, o processo web, o banco de dados, o administrador, o destino de backup e as integrações externas. Marque as informações que se movem entre eles. Uma requisição que cruza de um cliente não confiável para uma operação privilegiada do servidor merece validação e autorização explícitas.
Não presuma que estar dentro da mesma máquina torna todos os componentes igualmente confiáveis. Um processo de upload público não deve ter as mesmas permissões que a administração do banco de dados. Um trabalho de backup pode precisar de acesso de leitura sem a capacidade de modificar registros ativos da aplicação. Separar esses papéis torna o efeito de um componente comprometido mais fácil de conter e as permissões necessárias mais fáceis de revisar.
Escolha cenários de falha concretos
Use alguns eventos plausíveis para desafiar o design. Um atacante rouba uma senha de administrador; um usuário solicita o registro de outro usuário; um upload esgota o disco; uma implantação expõe um arquivo 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 de melhorar a segurança.
Inclua erros e abuso legítimo de fluxo de trabalho, bem como intrusão externa. Uma nova tentativa pode criar duas operações valiosas, ou duas requisições podem competir para alterar o mesmo objeto. A orientação de lógica de negócios da OWASP destaca essas suposições de processo. Verifique quem tem permissão para mover um fluxo de trabalho para seu próximo estado e se repetir ou reordenar uma requisição altera o resultado inesperadamente.
| Cenário | Controle a investigar | Evidência a coletar |
|---|---|---|
| Credencial de administração roubada | Acesso restrito e um segundo fator quando suportado | Um login não autorizado não pode ser concluído |
| Objeto de outro usuário solicitado | Autorização de objeto no lado do servidor | Um teste isolado retorna um resultado negado |
| Disco esgotado por uploads | Controles de tamanho, cota e retenção | Um limite é aplicado antes da falha do serviço |
| Requisição duplicada de fluxo de trabalho | Idempotência e limites de transação | Uma requisição repetida cria um único resultado |
Priorize por impacto e um caminho crível
Para cada cenário, registre seu impacto potencial e as condições necessárias para que ocorra. Evite fingir que uma pontuação numérica estimada é uma probabilidade precisa. Você ainda pode distinguir uma senha 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 uma operação normal. Um campo de conta retido pode criar exposição muito depois de sua finalidade terminar. A revisão de privacidade pode, portanto, remover informações ou encurtar a retenção, enquanto a revisão de segurança restringe o acesso ao que permanece. Ambas as mudanças pertencem ao modelo quando protegem o projeto.
Teste os controles em um ambiente autorizado
Crie um ambiente de homologação com permissões representativas e registros fictícios. Teste acesso negado, limites de requisição, novas tentativas de fluxo de trabalho e recuperação. Não use dados reais de clientes quando dados sintéticos puderem demonstrar o comportamento. O objetivo é verificar o controle, não gerar tráfego de ataque impressionante. Mantenha-se dentro de sistemas que você possui ou está explicitamente autorizado a avaliar.
Registre o que passou, o que falhou e o que permanece desconhecido. O resultado de um scanner pode contribuir como evidência, mas não substitui um teste das regras de negócio da aplicação. Da mesma forma, uma opção de proteção de rede não verifica a autorização de objetos nem o tratamento de arquivos secretos. Anexe os resultados úteis ao cenário para que futuros mantenedores entendam por que um determinado controle existe.
Mantenha o modelo conectado à mudança
Revise as partes relevantes quando você adicionar uma integração, expuser um novo endpoint, alterar um privilégio ou mover dados para outro destino. Você não precisa redesenhar toda a arquitetura para uma pequena edição de texto. O gatilho é uma suposição alterada sobre acesso, informação ou comportamento do sistema. Mantenha o modelo junto à documentação de implantação e recuperação, em vez de deixá-lo como resultado de um workshop pontual.
SwissOctet fornece um catálogo de escolhas de infraestrutura, não um modelo de ameaças de aplicação concluído. Escolha a configuração e as opções que apoiam seus controles e, em seguida, verifique a implantação que você construir. 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 eles abordam.
Sua lista 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 controles e responsáveis aos riscos importantes.
- Teste com dados sintéticos em um ambiente autorizado.
- Revise o modelo quando uma suposição relevante mudar.
Os detalhes que importam.
Preciso de um framework formal para começar?+
Não. Um pequeno diagrama e um conjunto documentado de cenários podem ser úteis. Um framework ajuda a garantir que você revise os riscos de forma consistente.
Um scanner de vulnerabilidades substitui a modelagem de ameaças?+
Não. Os scanners podem encontrar fraquezas técnicas, enquanto um modelo de ameaças também examina suposições de design, permissões e fluxos de trabalho de negócio.
Com que frequência devo atualizar o modelo?+
Atualize as partes afetadas quando fluxos de dados, integrações, privilégios ou funcionalidades expostas mudarem, e revise os riscos não resolvidos regularmente.
Vá à fonte.
Estas referências apoiam os conceitos técnicos deste guia. Siga a documentação atual antes de alterar um sistema em produção.
- OWASP: Folha de referência de modelagem de ameaças cheatsheetseries.owasp.org
- OWASP: Modelagem de ameaças na prática devguide.owasp.org
- OWASP: Segurança de lógica de negócio cheatsheetseries.owasp.org
Orientação editorial da SwissOctet. Os exemplos são ilustrativos. Especificações de serviço, opções disponíveis e condições contratuais devem ser verificadas separadamente.