Informativos sobre segurança

Introdução à ferramenta de modelagem de ameaças do SDL

Adam Shostack

Sumário

Iniciando o processo de modelagem de ameaças
Análise de riscos
Tela de ambiente
Controlando os relatórios
O menu de ações
Reuniões para modelagem de risco
Pensando nos ativos

Figura 1 O processo de modelagem de risco

Em novembro de 2008, a Microsoft anunciou o lançamento da ferramenta de modelagem de risco do SDL (ciclo de vida do desenvolvimento da segurança), disponível para download gratuito no MSDN. Esta coluna acompanha uma equipe no processo de contato inicial com a abordagem de modelagem de risco do SDL e mostra como usar essa nova ferramenta para desenvolver ótimos modelos de risco, que serão a base do seu processo de segurança.

Esta não é a primeira coluna sobre a modelagem de risco do SDL. Consulte também o artigo do qual fui coautor, na edição de novembro de 2006 da MSDN Magazine, sobre o uso da abordagem STRIDE, "Modelagem de risco: descoberta de falhas de design de segurança usando a abordagem STRIDE". A Figura 1 apresenta uma rápida visão geral do processo.

Iniciando o processo de modelagem de risco

Ao iniciar a ferramenta de modelagem de risco do SDL, você perceberá que o canto inferior esquerdo se parece um pouco com o Microsoft Office Outlook, contendo quatro telas: diagrama, análise, ambiente e relatórios (veja a Figura 2 para mais detalhes). Observe que essas telas são ligeiramente diferentes da descrição mostrada na Figura 1, pois faz mais sentido avaliar riscos e atenuações em conjunto, por estarem diretamente relacionados.

Nesta seção, acompanharei Deb (uma desenvolvedora), Paul (um gerente de programa) e Tim (um testador) no processo de desenvolvimento do seu primeiro modelo de risco, e também abordarei cada tela da ferramenta.

"Oi, Deb, estou trabalhando naquele diagrama do modelo de risco e queria examiná-lo com você para ter certeza de que todos os detalhes estão certos."

"Claro, Paul! Entre."

Paul apresenta a impressão de um diagrama que ele já fez, usando o relatório "Diagrams only" ("Somente diagramas") da ferramenta de modelo de risco, mostrado na Figura 3.

"Paul, nunca vi esses diagramas. Parece bem simples, mas você poderia explicar o que significam as diferentes formas?"

"O que acontece é que Carl, um personagem representando um cliente normal nosso, está desenhado como uma entidade externa — um retângulo. Ele envia comandos para o nosso servidor Web — o círculo representa qualquer código em execução, e a seta indica o sentido da comunicação. O servidor Web está consultando um banco de dados, que, assim como qualquer outro local onde armazenamos dados, é representado por duas linhas paralelas. O sistema é chamado de DFD (diagrama de fluxo de dados). Há um bom artigo sobre DFDs na Wikipedia. A única parte que não está coberta aqui são essas linhas pontilhadas do limite de confiança, entre os locais onde há pessoas diferentes no controle. Por exemplo, você sabe que os profissionais de TI exigem que usemos seu sistema do Active Directory para informações de logon; portanto, o Active Directory é mostrado como fora do nosso controle."

Figura 3 O diagrama DFD de Paul

Quando a ferramenta é iniciada, a tela de diagrama é exibida. Nela, Paul usou as ferramentas do Visio e o estêncil fornecido para desenhar seu DFD (veja a Figura 4). Embora fosse sua primeira experiência com o sistema, ele se sentiu à vontade, devido aos comentários apresentados pelo validador à esquerda com base em sua experiência no uso da modelagem de risco como parte do SDL. Quando passou a desenhar elementos de maior complexidade, Paul adicionou detalhes clicando com o botão direito do mouse na pasta de contexto, no canto superior direito, o que lhe permitiu criar um diagrama complexo, com várias camadas.

Figura 4 A tela de diagramas

Análise de riscos

Paul sentiu-se um pouco hesitante ao abrir a tela de análise (veja a Figura 5). Havia uma lista extensa de riscos — de onde vieram? A ferramenta os construiu, usando a abordagem do SDL chamada "STRIDE por elemento". A idéia por trás disso é que, em geral, o software é submetido a um conjunto previsível de riscos (mostrados na Figura 5). Alguns especialistas em segurança gostam de perseguir o hacker primeiro, pois a perseguição em si pode ser divertida. Acredito que faz mais sentido começar pela proteção da sua casa, garantindo que cada porta e janela tenha algum tipo de tranca, para depois pensar em um sistema de alarme. Então, comece com o STRIDE por elemento, clicando em qualquer linha da tela de análise.

Figura 5 A tela de análise

Paul começou selecionando o banco de dados na lista de elementos. Ele leu na parte superior da tela que um "banco de dados" é um armazenamento de dados, sujeito a riscos de violação, divulgação de informações confidenciais e negação de serviço. Conforme prosseguiu com a leitura, as perguntas o ajudaram a pensar em como poderiam ocorrer violações de dados. Ele percebeu que ninguém havia especificado quem poderia se conectar ao banco de dados. Um diagrama e algumas regras simples foram suficientes para revelar o primeiro risco! Ponto para a modelagem de risco.

Após alguns minutos debatendo o assunto, eles perceberam que precisavam pensar em controle de acesso e funções. Paul incluiu observações resumidas em dois riscos. A primeira dizia "Sem plano de controle de acesso". Ele também incluiu um item de trabalho no banco de dados do TFS (Team Foundation Server). A segunda observação dizia "O plano de controle de acesso exige uma lista de funções". Então, no TFS, ele criou um segundo bug dependente do primeiro.

Quando passou à divulgação de informações confidenciais, Paul percebeu que o plano de controle de acesso exigiria algumas contas somente leitura para auditoria e geração de relatórios. Ficou em dúvida se esse seria um novo risco, mas decidiu que não, pois a atenuação era a mesma, e editou o bug já criado no TFS. Depois, decidiu verificar se havia alguma outra ocorrência da atenuação desse risco, e escreveu "abordado no bug 235 do TFS". Ele não tinha certeza se estava tudo certo, mas é para isso que serve o recurso de certificação (veja a Figura 6).

Figura 6 Certificação de que os riscos não se aplicam

Ele também refletiu um pouco mais sobre a divulgação de informações confidenciais e percebeu que as fitas de backup precisariam de criptografia, mas isso seria uma tarefa para o setor de operações. Explicarei como ele fez o controle disso em um minuto, depois de abordar um recurso relacionado: a caixa de seleção "auto-generate threats for this element" ("gerar riscos automaticamente para este elemento"), na parte superior da tela.

O recurso de geração automática foi projetado para equipes grandes, que têm vários modelos de risco, e também contam com uma forma de garantir que testadores e gerentes de programa se comuniquem a respeito das informações contidas nos modelos de risco. Nessa situação, Paul pode definir Phil como responsável por vários elementos que ele deseja exibir a título de contexto, e pela forma como interagem com seus recursos. A caixa de geração automática é marcada por padrão, mas Paul pode desmarcá-la e definir o recurso como pertencente a Phil.

Tela de ambiente

Preocupado com a criptografia das fitas de backup, a ser realizada pelo setor de operações, Paul abriu a tela de ambiente e viu uma seção para observações sobre segurança externa (veja a Figura 7). Lá, ele incluiu uma observação informando que o setor de operações estaria encarregado de cuidar do backup em fita. Ele precisaria verificar se o setor de operações já tinha uma cópia da ferramenta.

Figura 7 Observações sobre segurança externa

Ele teve dúvidas sobre a seção de cabeçalho do documento, e ficou aliviado ao descobrir que continha mais texto de orientação, explicando que ali ele identificaria o proprietário do modelo de risco, seu objetivo, e assim por diante. Preencheu a seção e pensou que gostaria de incluir o número de controle de projetos da Contoso.

Movendo-se sistematicamente pelos elementos da árvore, Paul percebeu que havia dependências em relação ao SQL Server e à biblioteca de widgets Fabrikam Foxy Web Widgets 2.3. Ele acrescentou uma observação para que Tim investigasse e verificasse se estavam atualizados, bem como recebendo notificações de segurança da Fabrikam.

Controlando os relatórios

Há cinco relatórios de modelagem de risco disponíveis:

Relatório de análise Esse relatório foi projetado para que um supervisor ou consultor de segurança revise um modelo de risco, embora qualquer profissional possa usá-lo para ver quais os problemas de validação abertos no diagrama, quais os riscos em branco, ainda não preenchidos, quais os riscos sem atenuações e quais os riscos certificados ou marcados como não aplicáveis.

Relatório de modelo de risco Esse relatório contém as informações inseridas no modelo de risco, apresentadas em uma única página.

Somente diagramas Esse relatório foi projetado para facilitar a impressão de diagramas. Algumas pessoas gostam de trabalhar com papel, mas não precisam imprimir o relatório inteiro, quando querem apenas o diagrama.

Relatório de bugs Esse relatório mostra os bugs inseridos a partir do modelo de risco e seus status.

Relatório de fuzzing O relatório de fuzzing usa as informações arquitetônicas fornecidas na etapa de criação de diagrama para oferecer uma lista de prioridades dos destinos de fuzzing. O fuzzing é uma técnica de teste que envolve a geração de entrada aleatória a partir de um programa. Apresenta uma eficiência surpreendente para gerar falhas, e muitas delas podem ser exploradas (consulte Crie um provedor de interface de teste personalizado para o Team System ou O teste de fuzzing na Microsoft e o processo de triagem para obter mais informações sobre testes de fuzzing).

O menu de ações

Há alguns recursos úteis no menu Actions (Ações): exibição de miniaturas, configurações de controle de bugs e modo de liderança de equipe. A exibição de miniaturas permite o acesso fácil aos diagramas a partir de outras telas. Isso é útil quando você tem um diagrama complexo e quer vê-lo na tela enquanto analisa seu modelo. O recurso dimensiona a miniatura automaticamente para ocupar a maior parte da janela, mantendo todo o diagrama à vista conforme você o redimensiona.

Se você tentar incluir um bug sem nenhuma informação, a caixa de diálogo de controle de bugs aparecerá, mas você pode exibi-la a qualquer momento usando o menu Actions. Você pode usar um arquivo XML muito simples para definir os campos a serem preenchidos, ou simplesmente editar os campos, desde que a caixa "use template" ("usar modelo") não esteja marcada. Os bugs recebem automaticamente o título "TM: [risco] affects [elemento]", e o conteúdo já vem preenchido com as informações de risco e atenuação. É possível excluir campos selecionando-os e pressionando a tecla Delete.

O modo de liderança de equipe exibe uma nova seção na tela de descrição de ambiente, chamada Template Settings (Configurações de Modelo). Isso permite que um líder de equipe altere as perguntas de orientação e defina um local padrão para salvar os modelos de risco. O líder de equipe também pode editar os campos nas informações do cabeçalho do documento, adicionando ou removendo elementos de forma adequada ao ambiente.

Como desejava, Paul incluiu um novo campo para o número de controle de projetos da Contoso. Qualquer modelo de risco salvo no modo de liderança de equipe pode ser usado como modelo (na verdade, qualquer modelo de risco pode ser usado como modelo para tarefas adicionais).

Para alterar as perguntas de orientação, é preciso editar um arquivo XML encontrado na pasta \Data da ferramenta de modelagem de risco do SDL. O formato é bem fácil de acompanhar.

Reuniões para modelagem de risco

Quando Paul distribuiu seu modelo de risco, Tim, o testador, não ficou nada impressionado. Ele percebeu problemas de vários tipos e perguntou a Paul: "Vocês, gerentes de programa, sempre supõem que tudo vai funcionar, não é?"

Talvez você se surpreenda em saber que o ceticismo dos testadores pode funcionar como um ótimo complemento aos modelos de risco. Por isso, muitas equipes pedem a seus testadores para liderar o processo de modelagem de risco. Nesse cenário, depois de assumir o modelo de risco, Tim convocou duas reuniões para modelagem de risco: uma para sincronizar o processo e analisar os diagramas, e outra para revisão de risco e aprovação.

Na primeira reunião, Tim levou 10 minutos descrevendo o processo de modelagem de risco do SDL para todos. Depois, apresentou o diagrama do modelo de risco e começou a explicá-lo em detalhes. Em cinco minutos, um componente ausente importante já havia sido identificado.

Alguns minutos depois, Tim e Paul iniciaram uma longa discussão sobre a constituição do servidor Web. Não era a forma ideal de prosseguir com a reunião, mas todos concordaram que descobrir a discrepância em um estágio inicial economizaria muito tempo nas etapas posteriores.

Na segunda reunião, a equipe analisou os riscos, discutiu algumas formas de lidar com eles e aprovou o modelo de risco. Colocaram o documento em controle de origem e continuaram o desenvolvimento.

Pensando nos ativos

Alguns leitores que já fizeram modelos de risco talvez percebam que simplesmente não falamos sobre ativos. Descobrimos que muitos engenheiros de software entendem melhor seu software do que o conceito de ativos, e em que ativos um invasor poderia estar interessado.

Se você fizer o modelo de risco da sua casa, poderá começar pensando na sua família, em fotos ou obras de arte insubstituíveis. Talvez comece pensando em possíveis invasores e no sistema de segurança atual. Você pode também começar levando em conta as características físicas, como a piscina ou a entrada principal. Isso é o mesmo que pensar em ativos, invasores ou design de software. Qualquer uma dessas abordagens funcionará.

A abordagem da modelagem de risco que apresentamos aqui é muito mais simples do que a adotada pela Microsoft no passado. A equipe de SDL da Microsoft descobriu que a abordagem baseada no design de software funciona bem para muitas equipes. Esperamos que a sua seja uma delas.

Envie dúvidas e comentários para briefs@microsoft.com.

Adam Shostack é gerente de programa da equipe de SDL (ciclo de vida do desenvolvimento da segurança) da Microsoft. Ele é responsável pelo componente de modelagem de risco do SDL.