Informativos sobre segurança

O modelo de processo MSF-Agile+SDL para TFS 2010

Bryan Sullivan

Qualquer leitor frequente desta revista estará familiarizado com o Microsoft Team Foundation Server (TFS) e os benefícios de produtividade que as equipes de desenvolvimento podem obter com seu uso. (Caso você não esteja familiarizado com o TFS, leia o artigo de Chris Menegay no nosso Tour Guiado do Visual Studio 2005. Apesar de abordar uma versão mais antiga, ele apresenta uma visão geral muito útil dos tipos de recursos que você pode aproveitar no TFS.)

Se você mesmo utiliza o TFS, provavelmente também está familiarizado com o modelo de processo Microsoft Solutions Framework (MSF) para Agile Software Development, mais conhecido como MSF-Agile, que acompanha o TFS. O tópico da coluna deste mês aborda o novo modelo de processo MSF-Agile + Security Development Lifecycle (SDL). O MSF-Agile+SDL foi desenvolvido com base no modelo MSF-Agile e adiciona recursos de segurança e privacidade do SDL ao processo de desenvolvimento.

Você pode baixar o modelo MSF-Agile+SDL para Visual Studio Team System 2008 ou 2010 do site microsoft.com/sdl. No entanto, antes de fazer o download, provavelmente você vai querer saber o que foi incorporado a ele. Vamos começar.

Tarefas do SDL

A base do SDL é seus requisitos e recomendações de segurança — atividades que as equipes de desenvolvimento devem executar durante todo o ciclo de vida do desenvolvimento para garantir melhor segurança e privacidade no produto final. Esses requisitos incluem atividades de diretiva, como a criação de um plano de resposta a incidentes de segurança, bem como atividades técnicas, como a modelagem de ameaças e a execução da análise de vulnerabilidade estática. Todas essas atividades são representadas no modelo MSF-Agile+SDL como itens de trabalho de tarefa do SDL.

Provavelmente a maior diferença entre as tarefas do SDL e os itens de trabalho padrão que representam tarefas funcionais é que os integrantes da equipe do projeto não devem criar tarefas do SDL diretamente. Algumas tarefas do SDL são criadas automaticamente quando o Projeto da Equipe é criado. São tarefas de segurança relativamente simples, executadas uma única vez, como a identificação do membro da equipe que atuará como o principal contato de segurança. Outras tarefas do SDL são criadas automaticamente pelo modelo de processo em resposta a ações do usuário. (Mais especificamente, elas são criadas de maneira automática pelo serviço Web do controlador SDL-Agile que é implantado na camada de aplicativo do TFS.)

Sempre que um usuário adiciona uma nova iteração ao projeto, o modelo adiciona ao projeto as novas tarefas do SDL que representam as tarefas de segurança a serem executadas durante essa iteração. Um bom exemplo de tarefa do SDL por iteração é a modelagem de ameaças: a equipe deve avaliar as alterações feitas no decorrer da iteração para identificar possíveis novas ameaças e atenuações.

Para finalizar, sempre que um usuário faz check-in de um novo site ou projeto do Visual Studio no repositório Controle do Código-Fonte da Equipe, o modelo adiciona tarefas do SDL para refletir o trabalho de segurança que deve ser feito especificamente para o projeto em questão. Por exemplo, sempre que é adicionado um novo projeto C ou C++, são criadas tarefas do SDL para assegurar o uso de configurações de vinculador e de compilador de defesa de estouro de buffer, como o sinalizador /dynamic­base para randomização de layout de espaço de endereço e o sinalizador /gs para verificação de segurança do buffer.

O modelo é sofisticado o suficiente para reconhecer a diferença entre projetos C/C++ nativos e projetos do Microsoft .NET Framework e não adicionará requisitos inválidos. Os sinalizadores /dynamicbase e /gs são inexpressivos para o código C#, e aquelas tarefas do SDL não serão criadas para projetos C#. Em vez disso, os projetos C# obtêm tarefas de segurança específicas do .NET, como analisar qualquer uso de AllowPartiallyTrustedCallersAttribute. Da mesma forma, o modelo também pode diferenciar aplicativos cliente/servidor e aplicativos de área de trabalho autônomos de sites e serviços Web e só adicionará o conjunto apropriado de tarefas do SDL.

Fluxo de trabalho de tarefas do SDL e exceções

O estado e o motivo das transições de fluxo de trabalho referentes a tarefas do SDL também são diferentes das tarefas funcionais. Uma tarefa pode ser marcada como fechada por vários motivos diferentes: por ter sido concluída, eliminada do projeto, adiada para uma iteração posterior ou até mesmo obsoleta ou não mais relevante para o projeto. Desses motivos, somente concluída é aplicável a tarefas do SDL.

As equipes que seguem o SDL não podem simplesmente eliminar requisitos de segurança e privacidade de seus projetos. Requisitos funcionais podem ser adicionados e eliminados de projetos por motivos técnicos ou funcionais, mas os requisitos de segurança devem ser mantidos em um padrão superior. Não é impossível ignorar uma tarefa do SDL, mas é preciso seguir um nível superior de processos para que isso aconteça.

Se, por algum motivo, uma equipe não concluir uma tarefa do SDL necessária, deverá solicitar ao supervisor de segurança uma exceção para a tarefa. A equipe ou seu gerente escolhe o supervisor de segurança da equipe quando o projeto é iniciado. Essa pessoa deve ter experiência em segurança e privacidade de aplicativos e idealmente não deve trabalhar diretamente no projeto — não deve ser um dos desenvolvedores, gerentes ou testadores de programa do projeto.

Na Microsoft, há um grupo centralizado de supervisores de segurança que trabalham na divisão Trustworthy Computing Security. Esses supervisores de segurança então trabalham diretamente com as equipes de produtos individuais. Se a sua organização dispõe dos recursos necessários para criar um grupo dedicado de supervisores de segurança, excelente. Do contrário, é melhor selecionar a pessoa com as melhores qualificações em segurança.

Fica a critério do supervisor de segurança da equipe aprovar ou rejeitar qualquer solicitação de exceção relativa a uma tarefa do SDL. A equipe cria uma solicitação de exceção definindo o estado da tarefa do SDL como Exceção Solicitada e preenchendo os campos Justificativa, Plano de Resolução e Período de Resolução. Cada tarefa do SDL também tem um campo somente leitura Classificação de Exceção que representa o risco de segurança subjetivo inerente do não preenchimento do requisito; esse risco varia de 4 (risco mínimo) a 1 (crítico, risco máximo). O supervisor de segurança examina a lógica da equipe com base na classificação de exceção e fecha a tarefa do SDL com o Motivo de Aprovada ou a reativa com o Motivo de Negada.

Todavia, mesmo que a solicitação seja aprovada, a maioria das exceções não é para sempre. É aí que o campo Período de Resolução entra em ação. Normalmente as equipes solicitam exceções para um determinado número de iterações — de modo geral para uma única iteração, mas às vezes para até três. Uma vez decorrido o número específico de iterações, o modelo de processo fará vencer a exceção e reativará a tarefa do SDL.

Bugs de segurança

Depois de garantir que os requisitos de segurança e privacidade foram atendidos, a próxima função mais importante do SDL é assegurar que os produtos não venham com bugs de segurança conhecidos. Rastrear bugs de segurança separadamente dos bugs funcionais é fundamental para garantir a integridade de segurança do seu produto.

Diferentemente das tarefas do SDL, o modelo MSF-Agile+SDL não adiciona um segundo tipo de item de trabalho Bug do SDL para diferenciar bugs de segurança de bugs funcionais. Em vez disso, ele adiciona os campos Causa de Segurança e Efeito de Segurança ao tipo de item de trabalho Bug existente. Sempre que um membro da equipe registra um novo bug, se for o caso de um bug funcional severo sem implicações de segurança, o localizador deixa esses campos com os valores padrão de Não É um Bug de Segurança. Entretanto, se o bug representa uma possível vulnerabilidade de segurança, o localizador define a Causa de Segurança com um dos seguintes valores:

• Erro aritmético
• Estouro/estouro negativo de buffer
• Scripts entre sites
• Deficiência criptográfica
• Passagem de diretório
• Mensagens incorretas/mensagens sem erro
• Conversão em formato canônico sem nome de caminho ou com nome de caminho incorreto
• Ocultação de segredo ineficaz
• Condição de corrida
• Injeção de SQL/script
• Consumo ilimitado de recursos (negação de serviço)
• Autenticação fraca
• Autorização fraca/permissão ou ACL inadequada
• Outro

O localizador também define o campo Efeito de Segurança com um dos valores STRIDE:

• Falsificação
• Violação
• Repúdio
• Divulgação de informações
• Negação de serviço
• Elevação do privilégio

Por fim, o localizador também pode optar por definir o valor do Escopo do bug. Resumidamente, o Escopo define algumas informações subjetivas adicionais sobre o bug que são usadas para determinar a severidade. Os valores permitidos para Escopo variam de acordo com o Efeito de Segurança selecionado. Por exemplo, se você escolher Elevação do Privilégio para o Efeito de Segurança, as opções possíveis para escopo incluirão:

• (Cliente) Usuário remoto tem a capacidade de executar código arbitrário ou de obter mais privilégios do que o pretendido.
• (Cliente) Usuário remoto tem a capacidade de executar código arbitrário com extensiva ação do usuário.
• (Cliente) Usuário local de baixo privilégio pode elevar seus privilégios para outro usuário, administrador ou sistema local.
• (Servidor) Usuário anônimo remoto tem a capacidade de executar código arbitrário ou de obter mais privilégios do que o pretendido.
• (Servidor) Usuário autenticado remoto tem a capacidade de executar código arbitrário ou de obter mais privilégios do que o pretendido.
• (Servidor) Usuário autenticado local tem a capacidade de executar código arbitrário ou de obter mais privilégios do que o pretendido.

Podemos perceber que os eixos de severidade para vulnerabilidades de Elevação do Privilégio (ou seja, quais características tornam uma Elevação do Privilégio pior do que a outra) lidam com condições como o local do ataque (cliente ou servidor) e o nível de autenticação do invasor (anônimo ou autenticado). Contudo, se você escolher outro Efeito de Segurança, como Negação de Serviço, as opções de Escopo mudarão para refletir os eixos de severidade desse efeito específico:

• (Cliente) Negação de serviço que exige reinstalação do sistema e/ou componentes
• (Cliente) Negação de serviço que exige reinicialização ou resulta em tela azul/verificação de bug
• (Cliente) Negação de serviço que exige reinicialização do aplicativo
• (Servidor) Negação de serviço por usuário anônimo com pouco volume de dados
• (Servidor) Negação de serviço por usuário anônimo sem amplificação em instalação padrão/comum
• (Servidor) Negação de serviço por usuário autenticado que exige reinicialização ou reinstalação do sistema
• (Servidor) Negação de serviço por usuário autenticado em instalação padrão/comum

Uma vez inseridos todos os valores de Causa de Segurança, Efeito de Segurança e Escopo, o modelo usa esses dados para calcular uma severidade mínima para o bug. O usuário pode optar por definir a severidade real do bug com um valor mais alto do que o mínimo — por exemplo, definir o bug como “1–Crítica” em vez de “2–Alta” — mas nunca o contrário. Isso pode parecer excessivamente rigoroso, mas evita a tentação de reduzir a severidade do bug para cumprir datas de entrega ou prazos curtos.

Se você deseja saber mais sobre a lógica para configurar uma metodologia de barra de bugs mais objetiva a fim de fazer a triagem dos bugs, leia a coluna Informativos sobre segurança de março de 2010, “Adicione uma barra de bugs de segurança ao Microsoft Team Foundation Server 2010” (msdn.microsoft.com/magazine/ee336031). O processo para adicionar uma barra de bugs ao TFS que detalhei nesse artigo já foi incorporado ao modelo MSF-Agile+SDL.

Para finalizar, há mais um campo opcional no item de trabalho de bug. Você pode usar o campo Origem para especificar o nome da ferramenta de segurança automatizada que originalmente encontrou o bug (se houver) ou pode deixar o campo com o valor padrão de “Usuário” caso um usuário tenha encontrado o bug ao revisar ou testar o código manualmente.

Com o passar do tempo, você coletará dados suficientes para determinar quais das suas ferramentas de teste estão propiciando o melhor custo-benefício. Para facilitar ainda mais essa determinação, o modelo MSF-Agile+SDL inclui um relatório em Excel chamado Bugs por Origem que exibe um gráfico de barras das vulnerabilidades reveladas pelo campo Origem.

É possível personalizar esse relatório para filtrar os dados com base em Severidade, Causa de Segurança ou Efeito de Segurança. Se você quiser saber quais ferramentas são mais eficientes para localizar vulnerabilidades de scripts entre sites ou quais encontraram os bugs de Elevação do Privilégio com severidade mais crítica, é fácil.

Fluxo de trabalho do bug

Assim como não é possível adiar tarefas do SDL, é igualmente impossível adiar qualquer bug com implicações de segurança (isto é, qualquer bug cujo Efeito de Segurança esteja definido como um valor diferente de Não É um Bug de Segurança). A equipe deve solicitar uma exceção para adiar a correção de qualquer bug de segurança com Severidade de “3 – Moderada” ou superior.

O processo é idêntico ao processo de solicitação de exceção para tarefas do SDL: um membro da equipe define o status como Exceção Solicitada e insere detalhes nos campos Justificativa, Resolução de Exceção e Período de Resolução. O supervisor de segurança da equipe examina a solicitação de exceção e a aprova (definindo o Estado como Fechada com um Motivo de Aprovada) ou a nega (definindo o Estado como Ativa com o Motivo de Negada).

Consultas de segurança e o Painel de Segurança

O modelo MSF-Agile+SDL também inclui várias novas consultas de equipe que visam simplificar o acompanhamento do processo. Essas novas consultas aparecem na pasta Consultas de Segurança do Team Explorer e incluem o seguinte:

• Bugs de Segurança Ativos
• Meus Bugs de Segurança
• Bugs de Segurança Resolvidos
• Tarefas do SDL Abertas
• Minhas Tarefas do SDL
• Exceções Abertas (inclui tanto tarefas como bugs, sendo especialmente útil para supervisores de segurança)
• Exceções Aprovadas
• Critérios de Saída de Segurança

A maioria dessas consultas são autoexplicativas, mas a consulta Critérios de Saída de Segurança precisa de uma explicação um pouco mais detalhada. Para cumprir o compromisso do SDL referente a uma certa iteração, a equipe deve concluir todas as seguintes atividades:

• Todos os requisitos de tarefas do SDL recorrentes de todos os sprints relativos à iteração devem ser atendidos ou devem ter uma exceção aprovada pelo supervisor de segurança da equipe
• Não devem haver requisitos de tarefas do SDL de bucket ou únicos expirados
• Todos os bugs com implicações de segurança de Severidade “3 – Moderada” ou superior devem ser fechados ou devem ter uma exceção aprovada pelo supervisor de segurança da equipe

Neste contexto, os termos “de todos os sprints”, “único” e “de bucket” referem-se ao conceito do SDL-Agile de organizar requisitos com base na frequência com que eles devem ser preenchidos. Requisitos de todos os sprints são requisitos recorrentes e devem ser preenchidos em cada iteração. Requisitos únicos não são recorrentes e só precisam ser preenchidos uma vez. Requisitos de bucket são requisitos recorrentes, mas só precisam ser preenchidos uma vez a cada seis meses.

Uma análise detalhada desse sistema de classificação está além do escopo deste artigo, mas se você deseja conhecer mais sobre ele, leia o artigo da MSDN Magazine “Agile SDL: Simplifique as práticas de segurança para desenvolvimento com Agile”, disponível na edição de novembro de 2008.

A intenção da consulta Critérios de Saída de Segurança é oferecer aos membros da equipe uma maneira fácil de verificar quanto eles ainda precisam trabalhar para cumprir o compromisso do SDL. Se você configurar um site do SharePoint para seu projeto de equipe MSF-Agile+SDL quando criá-lo (normalmente isso é feito automaticamente), também verá os resultados da consulta Critérios de Saída de Segurança no Painel de Segurança do projeto da equipe.

O novo Painel de Segurança está disponível somente para projetos MSF-Agile+SDL (veja a Figura 1). Por padrão, ele inclui as consultas Critérios de Saída de Segurança, Tarefas do SDL Abertas, Exceções Abertas e Bugs de Segurança, mas, se quiser, você pode personalizá-las. O Painel de Segurança também é definido como a página padrão do portal de projeto de todos os projetos MSF-Agile+SDL, mas, se você quiser mudar para outro painel padrão, basta abrir a biblioteca de documentos Painéis, selecionar o painel desejado e escolher a opção “Definir como Página Padrão”.

Figura 1 Painel de Segurança do MSF-Agile+SDL

Por padrão, ele inclui as consultas Critérios de Saída de Segurança, Tarefas do SDL Abertas, Exceções Abertas e Bugs de Segurança, mas, se quiser, você pode personalizá-las. O Painel de Segurança também é definido como a página padrão do portal de projeto de todos os projetos MSF-Agile+SDL, mas, se você quiser mudar para outro painel padrão, basta abrir a biblioteca de documentos Painéis, selecionar o painel desejado e escolher a opção “Definir como Página Padrão”.

Diretivas de check-in

O último recurso do modelo de processo MSF-Agile+SDL é o conjunto de diretivas de check-in do SDL. Essas diretivas ajudam a impedir que os desenvolvedores façam check-in de códigos que violem certos requisitos do SDL e, portanto, podem causar vulnerabilidades de segurança. As diretivas de check-in do SDL disponíveis podem ser vistas na Figura 2.

Figura 2 Diretivas de check-in do MSF-Agile+SDL

É fácil habilitar uma ou todas as diretivas de check-in do SDL. No Team Explorer, clique com o botão direito do mouse em um Projeto da Equipe e selecione a opção Controle do Código-Fonte no menu de contexto. Selecione a guia Diretiva de Check-in e adicione as diretivas do SDL que você deseja impor (veja a Figura 3). É importante observar que a imposição de diretivas de check-in é feita no computador cliente e não no servidor TFS, por isso você terá de instalar as diretivas de check-in do SDL no computador de cada desenvolvedor.

Figura 3 Adicionando diretivas de check-in

Conclusão

Para ser eficiente, toda metodologia de desenvolvimento seguro deve ser fácil de automatizar e gerenciar. O modelo de processo MSF-Agile+SDL ajuda consideravelmente a atender esses dois requisitos. Se você já está usando o modelo de processo MSF-Agile que acompanha o TFS, já sabe como utilizar o modelo MSF-Agile+SDL — trata-se de um superconjunto rigoroso do modelo MSF-Agile com o qual você já está familiarizado. Faça o download em microsoft.com/sdl e comece hoje mesmo a criar produtos mais seguros e com mais privacidade.

Bryan Sullivan é gerente de programas de segurança da equipe do Microsoft Security Development Lifecycle, onde atua como especialista em problemas de segurança de aplicativos Web e do .NET. É autor do livro “Ajax Security” (Addison-Wesley, 2007).

Agradecemos ao seguinte especialista técnico pela revisão deste artigo: Michael Howard