Introdução à Ferramenta de Modelagem de Ameaças
A Microsoft Threat Modeling Tool 2018 foi lançada como GA em setembro de 2018 como um clique para download gratuito. A mudança no mecanismo de entrega nos permite enviar as últimas melhorias e correções de bugs para os clientes cada vez que eles abrem a ferramenta, tornando-a mais fácil de manter e usar. Este artigo apresenta o processo de introdução à abordagem de modelagem de ameaças SDL da Microsoft e mostra como usar a ferramenta para desenvolver ótimos modelos de ameaças como espinha dorsal do seu processo de segurança.
Este artigo baseia-se no conhecimento existente da abordagem de modelagem de ameaças SDL. Para obter uma revisão rápida, consulte Threat Modeling Web Applications e uma versão arquivada do artigo Uncover Security Flaws Using the STRIDE Approach MSDN publicado em 2006.
Para resumir rapidamente, a abordagem envolve a criação de um diagrama, a identificação de ameaças, a sua mitigação e a validação de cada atenuação. Aqui está um diagrama que destaca esse processo:
Iniciando o processo de modelagem de ameaças
Ao iniciar a Ferramenta de Modelagem de Ameaças, você notará algumas coisas, como visto na imagem:
Secção Modelo de ameaça
Componente | Detalhes |
---|---|
Botão Feedback, Sugestões e Problemas | Leva você ao Fórum MSDN para todas as coisas SDL. Dá-lhe a oportunidade de ler o que outros utilizadores estão a fazer, juntamente com soluções alternativas e recomendações. Se ainda não conseguir encontrar o que procura, envie um e-mail tmtextsupport@microsoft.com para a nossa equipa de suporte para o ajudar |
Criar um modelo | Abre uma tela em branco para você desenhar seu diagrama. Certifique-se de selecionar qual modelo você gostaria de usar para seu modelo |
Modelo para novos modelos | Você deve selecionar qual modelo usar antes de criar um modelo. Nosso modelo principal é o Modelo de Ameaça do Azure, que contém estênceis, ameaças e mitigações específicas do Azure. Para modelos genéricos, selecione a Base de Conhecimento SDL TM no menu suspenso. Quer criar seu próprio modelo ou enviar um novo para todos os usuários? Confira nossa página GitHub do repositório de modelos para saber mais |
Abrir um modelo | Abre modelos de ameaças salvos anteriormente. O recurso Modelos abertos recentemente é ótimo se você precisar abrir seus arquivos mais recentes. Ao passar o mouse sobre a seleção, você encontrará 2 maneiras de abrir modelos:
|
Guia de Introdução | Abre a página principal da Microsoft Threat Modeling Tool |
Secção Modelo
Componente | Detalhes |
---|---|
Criar novo modelo | Abre um modelo em branco para você construir. A menos que você tenha amplo conhecimento na criação de modelos a partir do zero, recomendamos que você construa a partir dos existentes |
Abrir modelo | Abre modelos existentes para você fazer alterações |
A equipe da Threat Modeling Tool está constantemente trabalhando para melhorar a funcionalidade e a experiência da ferramenta. Algumas pequenas mudanças podem ocorrer ao longo do ano, mas todas as grandes mudanças exigem reescritas no guia. Consulte-o com frequência para garantir que recebe os anúncios mais recentes.
Construindo um modelo
Nesta seção, seguemos:
- Cristina (uma desenvolvedora)
- Ricardo (gestor de programa) e
- Ashish (um testador)
Estão a desenvolver o seu primeiro modelo de ameaça.
Ricardo: Olá Cristina, eu trabalhei no diagrama do modelo de ameaça e queria ter certeza de que acertamos os detalhes. Podem ajudar-me a examiná-lo? Cristina: Com certeza. Vamos dar uma vista de olhos. Ricardo abre a ferramenta e partilha o ecrã com Cristina.
Cristina: Ok, parece simples, mas você pode me guiar através disso? Ricardo: Claro! Eis a desagregação:
- Nosso usuário humano é desenhado como uma entidade externa – um quadrado
- Eles estão enviando comandos para o nosso servidor Web — o círculo
- O servidor Web está consultando um banco de dados (duas linhas paralelas)
O que Ricardo acabou de mostrar a Cristina é um DFD, abreviação de Data Flow Diagram. A Ferramenta de Modelagem de Ameaças permite que os usuários especifiquem limites de confiança, indicados pelas linhas pontilhadas vermelhas, para mostrar onde diferentes entidades estão no controle. Por exemplo, os administradores de TI exigem um sistema Ative Directory para fins de autenticação, portanto, o Ative Directory está fora de seu controle.
Cristina: Parece-me bem. E as ameaças? Ricardo: Deixe-me mostrar-lhe.
Análise de ameaças
Uma vez que ele clica na visualização de análise a partir da seleção do menu de ícones (arquivo com lupa), ele é levado para uma lista de ameaças geradas que a Ferramenta de Modelagem de Ameaças encontrou com base no modelo padrão, que usa a abordagem SDL chamada STRIDE (Spoofing, Tampering, Repudiation, Info Disclosure, Denial of Service and Elevation of Privilege). A ideia é que o software esteja sob um conjunto previsível de ameaças, que podem ser encontradas usando essas 6 categorias.
Esta abordagem é como proteger a sua casa, garantindo que cada porta e janela tem um mecanismo de bloqueio no lugar antes de adicionar um sistema de alarme ou perseguir o ladrão.
Ricardo começa por selecionar o primeiro item da lista. Veja o que acontece:
Primeiro, a interação entre os dois estênceis é reforçada
Em segundo lugar, informações adicionais sobre a ameaça aparecem na janela Propriedades da ameaça
A ameaça gerada ajuda-o a compreender potenciais falhas de design. A categorização STRIDE dá-lhe uma ideia sobre potenciais vetores de ataque, enquanto a descrição adicional lhe diz exatamente o que está errado, juntamente com possíveis maneiras de mitigá-lo. Ele pode usar campos editáveis para escrever anotações nos detalhes da justificação ou alterar as classificações de prioridade, dependendo da barra de bugs de sua organização.
Os modelos do Azure têm detalhes adicionais para ajudar os usuários a entender não apenas o que está errado, mas também como corrigi-lo adicionando descrições, exemplos e hiperlinks à documentação específica do Azure.
A descrição fez com que ele percebesse a importância de adicionar um mecanismo de autenticação para evitar que os usuários fossem falsificados, revelando a primeira ameaça a ser trabalhada. Alguns minutos depois da discussão com Cristina, eles entenderam a importância de implementar o controle de acesso e funções. Ricardo preencheu algumas notas rápidas para se certificar de que estas foram implementadas.
Quando Ricardo entrou nas ameaças sob Divulgação de Informações, ele percebeu que o plano de controle de acesso exigia algumas contas somente leitura para auditoria e geração de relatórios. Ele se perguntou se esta deveria ser uma nova ameaça, mas as mitigações eram as mesmas, então ele observou a ameaça de acordo. Ele também pensou um pouco mais na divulgação de informações e percebeu que as fitas de backup precisariam de criptografia, um trabalho para a equipe de operações.
As ameaças não aplicáveis ao projeto devido a mitigações ou garantias de segurança existentes podem ser alteradas para "Não aplicável" na lista suspensa Status. Há três outras opções: Não iniciado – seleção padrão, Investigação de necessidades – usado para acompanhar itens e Mitigado – uma vez que esteja totalmente trabalhado.
Relatórios e compartilhamento
Uma vez que Ricardo passa pela lista com Cristina e adiciona notas importantes, mitigações/justificativas, mudanças de prioridade e status, ele seleciona Relatórios - Criar Relatório Completo ->> Salvar Relatório, que imprime um bom relatório para ele passar com os colegas para garantir que o trabalho de segurança adequado seja implementado.
Se Ricardo quiser compartilhar o arquivo, ele pode facilmente fazê-lo salvando na conta do OneDrive de sua organização. Depois de fazer isso, ele pode copiar o link do documento e compartilhá-lo com seus colegas.
Reuniões de modelagem de ameaças
Quando Ricardo enviou seu modelo de ameaça para seu colega usando o OneDrive, Ashish, o testador, ficou impressionado. Parecia que Ricardo e Cristina erraram alguns casos de escanteio importantes, que poderiam ser facilmente comprometidos. Seu ceticismo é um complemento aos modelos de ameaça.
Nesse cenário, depois que Ashish assumiu o modelo de ameaça, ele pediu duas reuniões de modelagem de ameaças: uma reunião para sincronizar o processo e percorrer os diagramas e, em seguida, uma segunda reunião para revisão e aprovação de ameaças.
Na primeira reunião, Ashish passou 10 minutos orientando todos pelo processo de modelagem de ameaças SDL. Ele então puxou o diagrama do modelo de ameaça e começou a explicá-lo em detalhes. Em cinco minutos, um importante componente ausente foi identificado.
Alguns minutos depois, Ashish e Ricardo entraram em uma longa discussão sobre como o servidor Web foi construído. Não era a maneira ideal de uma reunião prosseguir, mas todos acabaram concordando que descobrir a discrepância cedo lhes pouparia tempo no futuro.
Na segunda reunião, a equipe analisou as ameaças, discutiu algumas maneiras de enfrentá-las e aprovou o modelo de ameaça. Eles verificaram o documento no controle do código-fonte e continuaram com o desenvolvimento.
Pensando nos ativos
Alguns leitores que têm a ameaça modelada podem notar que não falamos sobre ativos. Descobrimos que muitos engenheiros de software entendem seu software melhor do que entendem o conceito de ativos e em quais ativos um invasor pode estar interessado.
Se você vai ameaçar modelar uma casa, você pode começar pensando em sua família, fotos insubstituíveis ou obras de arte valiosas. Talvez você possa começar pensando em quem pode invadir e no sistema de segurança atual. Ou você pode começar considerando as características físicas, como a piscina ou a varanda da frente. Estes são análogos a pensar em ativos, atacantes ou design de software. Qualquer uma destas três abordagens funciona.
A abordagem à modelagem de ameaças que apresentamos aqui é substancialmente mais simples do que a Microsoft fez no passado. Descobrimos que a abordagem de design de software funciona bem para muitas equipes. Esperamos que inclua o seu.
Passos Seguintes
Envie suas perguntas, comentários e preocupações para tmtextsupport@microsoft.com. Faça o download da Ferramenta de modelagem de ameaças para começar.