O ciclo de vida do desenvolvimento da segurança de computação confiável

Steve Lipner e Michael Howard

Steve Lipner
Michael Howard
Engenharia de segurança e comunicações
Unidade de tecnologia e negócios de segurança
Microsoft Corporation

Março de 2005

Resumo: este artigo aborda o SDL (Security Development Lifecycle - ciclo de vida do desenvolvimento da segurança) de computação confiável, um processo que a Microsoft adotou para o desenvolvimento de softwares que precisem resistir a ataques mal-intencionados. O processo engloba a adição de uma série de atividades e produtos concentrados na segurança em cada fase do processo de desenvolvimento de software da Microsoft. Essas atividades e esses produtos incluem o desenvolvimento de modelos de ameaças durante o design do software, o uso de ferramentas de verificação de código de análise estática durante a implementação e a realização de revisões de código e testes de segurança durante um "esforço de segurança" direcionado. Antes que o software sujeito ao SDL possa ser lançado, ele deve passar por uma Revisão final de segurança feita por uma equipe independente de seu grupo de desenvolvimento. Quando comparado a um software que não foi sujeitado ao SDL, o software que passou pelo SDL apresentou uma taxa significativamente reduzida de descobertas externas de vulnerabilidades de segurança. Este artigo descreve o SDL e aborda a experiência com sua implementação no software da Microsoft. Este artigo também contém links para páginas em inglês (19 páginas impressas).

Observação: este artigo é uma versão atualizada do "The Trustworthy Computing Security Development Lifecycle", que foi originalmente apresentado na 2004 Annual Computer Security Applications Conference co-patrocinada pelo IEEE e realizada em Tucson, Arizona, em dezembro de 2004.

1. Introdução

É essencial que todos os fornecedores de software abordem as ameaças à segurança. A segurança é um requisito fundamental para fornecedores de software, e ela é influenciada pelas pressões do mercado, pela necessidade de proteger infra-estruturas críticas e pela necessidade de criar e preservar uma confiança geral no ambiente de computação. Um desafio importante para todos os fornecedores de software é a criação de software mais seguro, que precise de menos atualizações através de patches e possibilite um gerenciamento de segurança com menos problemas.

Para a indústria de software, a chave para suprir a demanda atual de segurança aprimorada é implementar processos repetitivos que forneçam, de forma confiável, segurança aprimorada mensurável. Assim, os fornecedores de software devem fazer a transição para um processo de desenvolvimento de software mais rigoroso que se concentre, de maneira mais ampla, na segurança. Esse processo tem o objetivo de minimizar o número de vulnerabilidades de segurança existentes no design, na codificação e na documentação, além de detectar e remover essas vulnerabilidades o mais cedo possível durante o ciclo de vida do desenvolvimento. Softwares empresariais e de consumo são os que mais precisam desse processo, pois provavelmente serão usados para processar entradas recebidas da Internet, controlar sistemas críticos que sejam alvos de ataques ou processar informações de identificação pessoal.

Existem três aspectos na criação de software mais seguro: o processo repetitivo, o treinamento de engenheiros e as métricas e responsabilidades. Este documento se concentra no aspecto do processo repetitivo do SDL, apesar de abordar o treinamento de engenheiros e fornecer algumas métricas gerais para mostrar o impacto até a data de aplicação de um subconjunto do SDL.

Se a experiência da Microsoft servir de exemplo, a adoção do SDL por outras organizações não deverá adicionar custos excessivos ao desenvolvimento do software. Na experiência da Microsoft, as vantagens de fornecer software mais seguro (por exemplo, menos patches, clientes mais satisfeitos) superam os custos.

O SDL envolve a modificação dos processos de uma organização de desenvolvimento de software através da integração de medidas que levam a uma segurança de software aprimorada. Este documento resume essas medidas e descreve a maneira como elas se integram em um ciclo de vida típico do desenvolvimento de software. A intenção dessas modificações não é revisar totalmente o processo, mas adicionar pontos de verificação e produtos de segurança bem definidos.

Este documento presume que haja na empresa um grupo central (ou uma organização de desenvolvimento de software) que direcione o desenvolvimento e a evolução dos aprimoramentos do processo e das práticas de segurança recomendadas, sirva como centro de especialização para a organização como um todo e realize uma revisão (FSR [Revisão final de segurança - Final Security Review]) antes do lançamento do software. Na experiência da Microsoft, a existência dessa organização é crítica para a implementação bem-sucedida do SDL, bem como para o aperfeiçoamento da segurança do software. Algumas organizações podem considerar o preenchimento da função de "equipe de segurança central" por um contratado ou consultor. Este artigo descreve a integração de um conjunto de etapas com o objetivo de aperfeiçoar a segurança de software no processo de desenvolvimento tipicamente usado por grandes organizações de desenvolvimento de software. Essas etapas foram criadas e implementadas pela Microsoft como parte de sua Iniciativa de computação confiável. O objetivo desses aprimoramentos do processo é reduzir a quantidade e a gravidade das vulnerabilidades de segurança no software usado pelos clientes. Neste documento, o processo de desenvolvimento de software modificado, que está sendo implementado atualmente pela Microsoft, é chamado de Ciclo de vida do desenvolvimento de software de computação confiável (ou simplesmente SDL, Software Development Cycle).

Na experiência da Microsoft, a equipe de segurança deve estar disponível para interações freqüentes durante o desenvolvimento e a criação do software, e deve ser confiável em relação às informações comerciais e técnicas confidenciais. Por esses motivos, a solução preferencial é criar uma equipe de segurança dentro da organização de desenvolvimento de software (embora talvez seja apropriado contratar consultores para ajudar na criação e no treinamento dos membros da equipe).

1.1 O processo de linha de base

O processo de desenvolvimento de software globalmente aceito na Microsoft segue, em termos gerais, o fluxo mostrado na Figura 1. Em um nível geral, esse processo é típico da prática da indústria.

ms995349.sdl_01_thumb(pt-br,MSDN.10).gif
Figura 1. O processo de desenvolvimento padrão da Microsoft (clique na imagem para ampliá-la)

A Figura 1 mostra cinco marcos e parece sugerir um processo de desenvolvimento em "cascata", mas, na verdade, o processo é uma espiral. Os requisitos e o design são revisitados com freqüência durante a implementação em resposta a alterações das necessidades de mercado e a realidades que aparecem durante a implementação do software. Além disso, o processo de desenvolvimento enfatiza a necessidade de o código em execução estar em quase todos os pontos, de forma que cada marco principal seja, de fato, segmentado com o fornecimento de uma série de compilações que podem ser continuamente testadas e usadas operacionalmente (pela equipe de desenvolvimento).

1.2 Visão geral do ciclo de vida do desenvolvimento da segurança

A experiência com a segurança de software do mundo real levou a um conjunto de princípios de alto nível para a compilação de um software mais seguro. A Microsoft se refere a esses princípios como SD3+C – Seguro por Design, Seguro por Padrão (Default), Seguro na Implantação (Deployment) e Comunicações. As definições resumidas desses princípios são:

  • Seguro por Design: a arquitetura, o design e a implementação do software devem ser executados de forma a protegê-lo e proteger as informações que ele processa, além de resistir a ataques.

  • Seguro por Padrão (Default): na prática, o software não atingirá uma segurança perfeita; portanto, os designers devem considerar a possibilidade de haver falhas de segurança. Para minimizar os danos que ocorrem quando invasores miram nessas falhas restantes, o estado padrão do software deve aumentar a segurança. Por exemplo, o software deve ser executado com o privilégio mínimo necessário, e os serviços e os recursos que não sejam amplamente necessários devem ser desabilitados por padrão ou ficar acessíveis apenas para uma pequena parte dos usuários.

  • Seguro na Implantação (Deployment): o software deve conter ferramentas e orientação que ajudem os usuários finais e/ou administradores a usá-lo com segurança. Além disso, a implantação das atualizações deve ser fácil.

  • Comunicações: os desenvolvedores de software devem estar preparados para a descoberta de vulnerabilidades do produto e devem comunicar-se de maneira aberta e responsável com os usuários finais e/ou com os administradores para ajudá-los a tomar medidas de proteção (como instalar patches ou implantar soluções alternativas).

Todos os elementos do SD3+C impõem requisitos no processo de desenvolvimento, mas os dois primeiros elementos, seguro por design e seguro por padrão, fornecem as maiores vantagens de segurança. Seguro por design determina os processos que têm por objetivo impedir a introdução de vulnerabilidades em primeiro lugar, enquanto seguro por padrão requer que a exposição padrão do software, sua "superfície de ataque", seja minimizada.

A introdução de medidas de segurança com o objetivo de integrar o paradigma SD3+C ao processo de desenvolvimento existente resulta na organização geral do processo mostrada na Figura 2.

ms995349.sdl_02_thumb(pt-br,MSDN.10).gif
Figura 2. Aprimoramentos do SDL para o processo de desenvolvimento da Microsoft (clique na imagem para ampliá-la)

A Seção 2 deste documento descreve os componentes do SDL mais detalhadamente. A Seção 3 apresenta um breve resumo das particularidades da implementação do SDL da Microsoft. A Seção 4 deste documento fornece alguns dados ilustrativos que demonstram que a aplicação precoce do SDL durante o desenvolvimento do Microsoft Windows Server 2003 e de outros softwares resultou em contagens e classificações reduzidas de vulnerabilidades de segurança em comparação a versões anteriores. A Seção 5 fornece algumas observações qualitativas de elementos do processo baseadas na experiência da Microsoft com a aplicação do SDL. Finalmente, a Seção 6 apresenta conclusões gerais.

2. O processo do ciclo de vida do desenvolvimento da segurança

Como observado anteriormente, o treinamento de engenheiros ultrapassa o escopo deste artigo. Mas é importante observar que um programa de treinamento é crítico para o êxito do SDL. Geralmente, os recém-formados em faculdades de computação e outros cursos relacionados não têm o treinamento necessário para começar a trabalhar imediatamente e não são capazes de criar, desenvolver ou testar software seguro. Mesmo os que concluíram o treinamento sobre segurança têm mais probabilidade de ter encontrado algoritmos criptográficos ou modelos de controle de acesso do que saturações de buffer ou falhas de canonização. Em geral, os designers, engenheiros e testadores de software da indústria também não têm as habilidades apropriadas na área de segurança.

Sob essas circunstâncias, uma organização que procura desenvolver software seguro deve se responsabilizar pelo treinamento adequado de sua equipe de engenharia. Os métodos específicos usados para vencer esse desafio variam de acordo com o tamanho da organização e com os recursos disponíveis. Uma organização com uma equipe de engenharia grande pode se comprometer em compilar um programa interno para fornecer treinamento contínuo sobre segurança para seus engenheiros. No entanto, uma organização pequena talvez precise contar com treinamento externo. Na Microsoft, todo o pessoal envolvido no desenvolvimento de software deve passar anualmente por um treinamento de "atualização de segurança".

2.1 Fase de requisitos

A necessidade de considerar a segurança "de baixo para cima" é um princípio fundamental do desenvolvimento de sistemas seguros. Embora vários projetos de desenvolvimento produzam "próximas versões" baseadas nas versões anteriores, a fase de requisitos e o planejamento inicial de uma nova versão oferecem a melhor oportunidade para criar software seguro.

Durante a fase de requisitos, a equipe de produto entra em contato com a equipe de segurança central para solicitar a designação de um supervisor de segurança (chamado de o "cara da segurança" na implementação do SDL na Microsoft) que serve como um ponto de contato, pesquisa e orientação durante o planejamento. O supervisor de segurança ajuda a equipe de produto revisando os planos, fazendo recomendações e garantindo que a equipe de segurança planeje recursos apropriados para dar suporte ao cronograma da equipe de produto. O supervisor de segurança aconselha a equipe de produto sobre os marcos de segurança e os critérios de saída que serão exigidos com base no tamanho, na complexidade e no risco do projeto. O supervisor de segurança continua sendo o ponto de contato da equipe de produto com a equipe de segurança, desde o início do projeto até a conclusão da Revisão final de segurança e o lançamento do software. O supervisor de segurança também serve como ponto de contato entre a equipe de segurança e a gerência da equipe de produto, e aconselha a gerência da equipe quanto ao controle do elemento de segurança de seus projetos, de forma a evitar surpresas relacionadas à segurança posteriormente durante o processo.

A fase de requisitos é a oportunidade para a equipe de produto considerar como a segurança será integrada no processo de desenvolvimento, identificar os objetivos-chave de segurança e maximizar a segurança de software, minimizando a quebra de planos e cronogramas. Como parte desse processo, a equipe precisa considerar como os recursos de segurança e as medidas de controle de seu software serão integrados com outros softwares que provavelmente serão usados com ele. (A interface com outros softwares é uma consideração essencial para atender às necessidades dos usuários de integração de produtos individuais em sistemas seguros.) A perspectiva geral da equipe de produto sobre os objetivos, os desafios e os planos de segurança deve se refletir nos documentos de planejamento produzidos durante a fase de requisitos. Embora os planos estejam sujeitos a alterações conforme o andamento do projeto, a articulação precoce desses planos ajuda a garantir que nenhum requisito seja desconsiderado ou estabelecido na última hora.

Cada equipe de produto deve considerar os requisitos de recursos de segurança como parte dessa fase. Embora alguns requisitos de recursos de segurança sejam identificados em resposta à modelagem de ameaças, é provável que os requisitos do usuário determinem a inclusão de recursos de segurança em resposta às exigências do cliente. Os requisitos dos recursos de segurança também serão definidos de acordo com a necessidade de obedecer aos padrões da indústria e dos processos de certificação, como os Critérios comuns. A equipe de produto deve reconhecer e refletir esses requisitos como parte de seu processo de planejamento normal.

2.2 Fase de design

A fase de design identifica a estrutura e os requisitos gerais do software. Da perspectiva de segurança, os elementos-chave da fase de design são:

  • Definir as diretivas de design e arquitetura de segurança: definir a estrutura geral do software, tendo como ponto de vista a segurança, e identificar os componentes cujo funcionamento correto é essencial para a segurança (a "base de computação confiável"). Identificar técnicas de design, como a organização em camadas, o uso de linguagem com rigidez de tipos, a aplicação de privilégios mínimos e a minimização da superfície de ataque, que se aplicam ao software globalmente. (Organização em camadas se refere à organização do software em componentes bem definidos e estruturados de forma a evitar dependências circulares entre componentes. Esses componentes são organizados em camadas, e uma camada mais alta pode depender dos serviços das camadas inferiores, mas o contrário é proibido.) As particularidades dos elementos individuais da arquitetura serão detalhadas nas especificações individuais de design, mas a arquitetura de segurança identifica uma perspectiva geral no design da segurança.

  • Documentar os elementos da superfície de ataque do software. Como o software não atingirá uma segurança perfeita, é importante que apenas os recursos que serão usados pela grande maioria dos usuários sejam expostos a todos eles por padrão, e que esses recursos sejam instalados com o nível de privilégio mais baixo possível. A medição dos elementos da superfície de ataque fornece à equipe de produto uma métrica constante da segurança padrão e permite que a equipe detecte as instâncias em que o software se torna mais suscetível a ataques. Algumas instâncias com uma maior superfície de ataque podem ser justificadas pela usabilidade ou função de produto avançada, mas é importante detectar e questionar cada uma dessas instâncias durante o design e a implementação, de forma a fornecer software com uma configuração padrão tão segura quanto possível.

  • Realizar a modelagem de ameaças. A equipe de produto realiza a modelagem de ameaças componente por componente. Usando uma metodologia estruturada, a equipe do componente identifica os ativos que o software deve gerenciar e as interfaces pelas quais esses ativos podem ser acessados. O processo de modelagem de ameaças identifica as ameaças que podem danificar cada ativo e a probabilidade de acontecerem danos (uma estimativa de risco). A equipe do componente identifica, então, as contramedidas que atenuam o risco na forma de recursos de segurança, como a criptografia, ou na forma de funcionamento adequado do software que protege os ativos contra danos. Sendo assim, a modelagem de ameaças ajuda a equipe de produto a identificar as necessidades de recursos de segurança, bem como as áreas em que são especialmente necessários testes de segurança e uma revisão cuidadosa do código. O processo de modelagem de ameaças deve ter o suporte de uma ferramenta que capture modelos de ameaças em um formulário legível por máquina para armazenamento e atualização.

  • Definir critérios de fornecimento complementar. Os critérios básicos de fornecimento de segurança devem ser definidos no nível da organização, mas as equipes de produto individuais ou de versões do software podem ter critérios específicos que devem ser atendidos antes do lançamento do software. Por exemplo, uma equipe de produto que desenvolva a versão atualizada de um software fornecido aos clientes e sujeito a ataques extensivos pode solicitar que, por determinado tempo, a nova versão fique livre de vulnerabilidades relatadas externamente antes de ser considerada pronta para o lançamento. (Ou seja, o processo de desenvolvimento deve localizar e remover as vulnerabilidades antes que elas sejam relatadas, em vez de a equipe de produto precisar "corrigi-las" depois de serem relatadas.)

2.3 Fase de implementação

Durante a fase de implementação, a equipe de produto gera o código, testa e integra o software. As etapas seguidas para remover falhas de segurança ou evitar sua inserção inicial durante essa fase têm um aproveitamento alto; elas reduzem significativamente a probabilidade de que vulnerabilidades de segurança estejam presentes na versão final do software que é lançada para os clientes.

Os resultados da modelagem de ameaças fornecem uma orientação particularmente importante durante a fase de implementação. Os desenvolvedores dedicam atenção especial em corrigir o código de modo a atenuarem as ameaças de alta prioridade e os testadores concentram seus testes na garantia de que essas ameaças estejam de fato bloqueadas ou atenuadas.

Os elementos do SDL que são aplicados na fase de implementação são:

  • Aplicar padrões de codificação e teste. Os padrões de codificação ajudam os desenvolvedores a evitar a introdução de falhas que podem levar a vulnerabilidades de segurança. Por exemplo, a utilização de construções de manipulação de seqüências e de buffer mais consistentes e seguras pode ajudar a evitar a introdução de vulnerabilidades de saturação do buffer. As práticas recomendadas e os padrões de testes ajudam a garantir que os testes se concentrem na detecção de possíveis vulnerabilidades de segurança e não apenas na operação correta de funções e recursos do software.

  • Aplicar ferramentas de testes de segurança, incluindo ferramentas de difusão. A "difusão" oferece entradas estruturadas mas inválidas para APIs (interfaces de programação de aplicativo) de software e interfaces de rede, de forma a maximizar a probabilidade de detectar erros que podem levar a vulnerabilidades de software.

  • Aplicar ferramentas de verificação de código de análise estática. As ferramentas podem detectar alguns tipos de falhas de código que resultam em vulnerabilidades, incluindo saturações do buffer, de números inteiros e variáveis não inicializadas. A Microsoft fez um investimento importante no desenvolvimento dessas ferramentas (as duas que têm sido mais usadas são conhecidas como PREfix e PREfast) e as aperfeiçoa continuamente conforme novos tipos de falhas de código e vulnerabilidades de software são descobertos.

  • Realizar revisões de código. As revisões de código complementam os testes e as ferramentas automatizadas; para isso, elas aplicam os esforços de desenvolvedores treinados no examine do código-fonte e na detecção e remoção de possíveis vulnerabilidades de segurança. Elas são uma etapa essencial no processo de remoção de vulnerabilidades de segurança do software durante o processo de desenvolvimento.

2.4 Fase de verificação

A fase de verificação é o ponto em que o software está funcionalmente concluído e entra em testes beta por usuários. Durante essa fase, enquanto o software passa por testes beta, a equipe de produto realiza um "esforço de segurança" que inclui revisões do código de segurança além das concluídas na fase de implementação, bem como testes de segurança direcionados.

A Microsoft introduziu o esforço de segurança durante a fase de verificação do Windows Server 2003 e várias outras versões de software no início de 2002. Houve dois motivos para a introdução do esforço de segurança no processo:

  • O ciclo de vida do software para as versões em questão alcançou a fase de verificação, e essa fase estava em um ponto apropriado para realizar as revisões de código e os testes orientados necessários.

  • Realizar o esforço de segurança durante a fase de verificação garante que a revisão de código e os testes tenham como objetivo a versão final do software, e oferece uma oportunidade para revisar o código desenvolvido ou atualizado durante a fase de implementação e o "código herdado" que não foi modificado.

O primeiro desses motivos reflete um acidente histórico: a decisão de iniciar um esforço de segurança ocorreu inicialmente durante a fase de verificação. Mas a Microsoft concluiu que realizar um esforço de segurança durante a fase de verificação é realmente uma prática recomendada para garantir que o software final preencha os requisitos e permitir uma revisão mais profunda do código herdado que tenha sido transferido de versões anteriores do software.

É importante notar que as revisões de código e os testes do código de alta prioridade (aquele que é parte da "superfície de ataque" do software) são críticos para várias partes do SDL. Por exemplo, essas revisões e esses testes devem ser exigidos na fase de implementação para permitir a correção precoce de quaisquer problemas, além da identificação e da correção da origem desses problemas. Eles também são críticos na fase de verificação, quando o produto está perto de ser concluído.

2.6 Fase de suporte e manutenção

Apesar da aplicação do SDL durante o desenvolvimento, as práticas de desenvolvimento mais avançadas ainda não dão suporte ao fornecimento de software completamente livre de vulnerabilidades, e há bons motivos para acreditarmos que isso nunca acontecerá. Mesmo que o processo de desenvolvimento pudesse eliminar todas as vulnerabilidades do software fornecido, novos ataques seriam descobertos e o software que era "seguro" estaria vulnerável. Assim, as equipes de produto devem se preparar para responder a vulnerabilidades recém-descobertas no software fornecido aos clientes.

Parte do processo de resposta envolve a preparação para avaliar relatórios de vulnerabilidades e lançar orientações e atualizações de segurança quando apropriado. O outro componente do processo de resposta é a condução de um post-mortem das vulnerabilidades relatadas e a adoção de medidas, conforme necessário. As medidas em resposta a uma vulnerabilidade variam de emitir uma atualização para um erro isolado até atualizar as ferramentas de verificação de código e iniciar revisões do código dos principais subsistemas. O objetivo durante a fase de resposta é aprender a partir dos erros e utilizar as informações fornecidas em relatórios de vulnerabilidade para ajudar a detectar e eliminar mais vulnerabilidades antes que sejam descobertas no campo e utilizadas para colocar os clientes em risco. O processo de resposta também ajuda a equipe de produto e a equipe de segurança a adaptar processos de forma que erros semelhantes não sejam introduzidos no futuro.

3. Implementando o ciclo de vida do desenvolvimento da segurança na Microsoft

A implementação do SDL da Microsoft evoluiu desde os "esforços de segurança" do início de 2002. Para iniciar o processo e impactar os produtos em desenvolvimento, os esforços de segurança compactavam atividades que deveriam ter sido distribuídas em várias fases do SDL em um período relativamente curto. Os esforços de segurança tiveram um impacto significativo nos planos, recursos e cronogramas das equipes de produto, e teriam sido muito mais difíceis de realizar sem o suporte ativo da gerência da Microsoft. Os esforços de segurança se concentraram na modelagem de ameaças, em revisões do código e em testes de segurança (incluindo testes de penetração). A Revisão final de segurança ("FSR") foi introduzida no final de 2002 e início de 2003, antes do lançamento do Windows Server 2003, e teve um impacto significativo na configuração padrão do Windows Server 2003 fornecido.

Depois dos esforços de segurança e FSRs iniciais, a Microsoft começou um projeto para formalizar o processo de SDL. Quatro resultados específicos deste projeto merecem ser mencionados:

  • Diretiva para a implementação da aplicação obrigatória do SDL

  • Treinamento obrigatório para o pessoal de engenharia

  • Métricas para equipes de produto

  • A função da equipe de segurança central

As seções a seguir abordam cada uma dessas áreas

3.1 Aplicação obrigatória do SDL

Dadas as vantagens demonstradas do SDL (consulte a Seção 5), a Microsoft tomou a decisão de formalizar uma exigência da aplicação do SDL em uma ampla variedade de softwares. No momento da elaboração deste documento, o SDL está se tornando obrigatório para todo software que:

  • Seja usado para processar informações pessoais ou confidenciais

  • Seja usado em uma empresa ou outra organização (incluindo as acadêmicas, governamentais ou sem fins lucrativos)

  • Esteja conectado à Internet ou seja usado em um ambiente em rede

Os softwares aos quais a obrigação não se aplica incluem aplicativos autônomos que não preenchem os critérios acima (por exemplo, jogos para crianças pequenas, como a série "The Magic School Bus"). O SDL impede de maneira significativa que esses softwares interfiram com a segurança da plataforma (sistema operacional ou outro software) na qual o software opera.

3.2 Treinamento obrigatório

Um aspecto importante dos esforços de segurança do início de 2002 foi o treinamento de toda a equipe do grupo de produtos: todos os desenvolvedores, testadores, gerentes de programa e pessoal de documentação. A Microsoft formalizou um requisito de treinamento anual em segurança para engenheiros em organizações cujos softwares estão sujeitos ao SDL. A necessidade de uma atualização anual se baseia no fato de a segurança não ser um domínio estático: as ameaças, os ataques e as defesas evoluem. Como resultado, mesmo os engenheiros totalmente competentes e qualificados nos aspectos da segurança que afetam seu software devem ter um treinamento adicional, conforme o cenário das ameaças muda. Por exemplo, a importância das vulnerabilidades de saturação de inteiros aumentou significativamente nos últimos quatro anos, e demonstrou-se recentemente que alguns algoritmos criptográficos têm vulnerabilidades não reconhecidas anteriormente.

A Microsoft desenvolveu uma introdução e uma atualização comuns sobre segurança que são apresentadas aos engenheiros nas formas de "treinamento ao vivo" e mídia digital. A Microsoft usou este curso como base para o treinamento especializado por tecnologia de software e por função de engenheiro. A Microsoft está no processo de elaboração de um currículo de treinamento em segurança que apresentará mais especializações por tecnologia, função e nível da experiência do aluno.

Vários parceiros e clientes da Microsoft perguntaram sobre a disponibilidade dos processos e treinamentos em segurança da Microsoft. A Microsoft Press publicou livros baseados nas práticas internas da Microsoft sobre design seguro, codificação e modelagem de ameaças, e a Microsoft Learning oferece cursos baseados nas práticas internas da Microsoft.

3.3 Métricas para equipes de produtos

Como uma empresa, a Microsoft é direcionada pelo ditado "não é possível gerenciar o que não se pode medir". Apesar de ser muito difícil criar formas de se medir, com precisão, a segurança do software, há métricas que representam claramente essa segurança. Essas métricas variam da cobertura de treinamento para a equipe de engenharia (no início do ciclo de vida do desenvolvimento) à taxa de vulnerabilidades descobertas no software que foi lançado para os clientes.

A Microsoft criou um conjunto de métricas de segurança que as equipes de produto podem usar para monitorar o êxito da implementação do SDL. Essas métricas englobam a implementação da equipe do SDL desde a modelagem de ameaças, a revisão do código e os testes de segurança até a segurança do software apresentado para a FSR. Como essas métricas são implementadas ao longo do tempo, elas devem permitir que as equipes acompanhem seu próprio desempenho (melhorando, nivelado ou piorando), bem como o seu desempenho em comparação com outras equipes. As métricas agregadas serão relatadas regularmente à gerência sênior da equipe de produto e aos executivos da Microsoft.

3.4 A equipe de segurança central

Antes dos esforços de segurança de 2002, a Microsoft estabeleceu a equipe SWI (Secure Windows Iniciative - Iniciativa do Windows seguro), com a função de aprimorar a segurança do software e reduzir vulnerabilidades no Windows, além de fornecer suporte de segurança a equipes de produto além daquelas que desenvolvem o Windows. A equipe SWI teve uma função central na organização e no gerenciamento do esforço de segurança do Windows Server 2003, e forneceu suporte de consultoria e treinamento para todos os esforços de segurança realizados no início de 2002. A equipe SWI também executou a FSR do Windows Server 2003, sendo pioneira no processo de FSR.

Com a distribuição formal do SDL, a equipe SWI ficou com a função de equipe de segurança central da Microsoft. As responsabilidades da equipe SWI incluem:

  • Desenvolver, manter e aprimorar o SDL, incluindo definir aspectos obrigatórios do processo.

  • Desenvolver, aprimorar e fornecer treinamento a engenheiros.

  • Fornecer "supervisores de segurança" que direcionam as equipes de produto durante o processo, realizam revisões para as equipes de produto e garantem que as perguntas da equipe de produto recebam respostas oportunas, precisas e autorizadas.

  • Servir como especialistas no assunto em uma ampla variedade de tópicos de segurança, garantindo que as perguntas direcionadas aos supervisores de segurança recebam respostas oportunas e precisas.

  • Executar as Revisões finais de segurança antes que o software seja lançado.

  • Fazer a investigação técnica de vulnerabilidades relatadas em software que foi lançado para os clientes, para garantir que as causas de origem sejam compreendidas e que o nível de resposta apropriado seja iniciado.

A disponibilidade e a eficiência da equipe SWI são fatores-chave na implementação do SDL na Microsoft. A Microsoft pretende ter um processo escalonável para desenvolver software mais seguro, e esse objetivo implica na necessidade de ter uma competência em segurança distribuída amplamente por todas as equipes de produto. Entretanto, ter uma equipe de segurança centralizada e altamente qualificada é essencial para criar equipes de produto rapidamente em ambientes empresariais e para fornecer suporte a elas durante a criação de software mais seguro. Isso também garante que alguém fora da equipe de produto realize a FSR.

4. Resultados da implementação do ciclo de vida do desenvolvimento da segurança na Microsoft

É prematuro para a Microsoft fazer declarações conclusivas de que o SDL melhora a segurança do software Microsoft, mas os resultados até o momento são animadores.

O Windows Server 2003 foi o primeiro lançamento de sistema operacional na Microsoft que implementou grandes partes do SDL. A Figura 3 mostra o número de boletins de segurança emitidos no ano após o lançamento dos dois mais recentes sistemas operacionais de servidor da Microsoft: o Windows 2000 e o Windows Server 2003. (Quando o Windows 2000 foi lançado, a Microsoft não tinha um sistema de classificação de gravidade formal dos boletins de segurança. A Microsoft avaliou cada boletim de segurança que se aplica ao Windows 2000 em relação ao seu sistema atual de classificação de gravidade.) Conforme abordado anteriormente neste artigo, o Windows Server 2003 foi desenvolvido com a maioria (mas não todos) dos processos do SDL; o Windows 2000 não foi desenvolvido com esses processos.

ms995349.sdl_03(pt-br,MSDN.10).gif
Figura 3. O Windows antes e depois dos boletins de segurança importantes e críticos do SDL

As classes de gravidade estão definidas em http://www.microsoft.com/technet/security/bulletin/rating.mspx.

Outros lançamentos de software Microsoft também aplicaram elementos do SDL. As equipes de produto do SQL Server e do Exchange Server realizaram esforços de segurança (incluindo modelagem de ameaças, revisões de código e testes de segurança) antes de lançar um service pack (um lançamento de software que agrega correções para vulnerabilidades de segurança e outros problemas). Os resultados do esforço de segurança do SQL Server foram incorporados ao SQL Server 2000 Service Pack 3, e os resultados do esforço de segurança do Exchange Server foram incorporados ao Exchange 2000 Server Service Pack 3. As Figuras 4 e 5 mostram os números dos boletins de segurança lançados em períodos iguais antes de depois do lançamento do respectivo service pack (um período de 24 meses para o SQL Server 2000 e de 18 meses para o Exchange 2000 Server).

ms995349.sdl_04(pt-br,MSDN.10).gif
Figura 4. O SQL Server 2000 antes de depois dos boletins de segurança do SDL

ms995349.sdl_05(pt-br,MSDN.10).gif
Figura 5. O Exchange Server 2000 antes de depois dos boletins de segurança do SDL

Outro exemplo animador é o componente Internet Information Server do Windows Server 2003 (IIS 6); nos dois anos posteriores ao seu lançamento, a Microsoft emitiu um boletim de segurança que afetava o servidor Web, e ele estava em um componente (WebDAV) que não era instalado por padrão.

Enquanto os exemplos de vulnerabilidades de segurança ainda são pequenos e os períodos são limitados, esses resultados fornecem evidências de que o SDL é eficiente. A Microsoft continuará monitorando as taxas de vulnerabilidades no Windows Server 2003 e nos service packs do Exchange Server e do SQL Server para ver se as tendências iniciais persistem. A Microsoft também analisará outros softwares Microsoft conforme novas versões forem fornecidas após a implementação total do SDL para determinar se as taxas de gravidade e os números de vulnerabilidades de segurança continuam caindo.

5. Observações sobre a aplicação do ciclo de vida do desenvolvimento da segurança

Os dados apresentados na seção anterior fornecem uma visão geral "do que" se espera que o SDL realize. Esta seção tenta responder algumas perguntas sobre "como" funciona o processo. Enquanto a seção anterior se baseia em números — a Microsoft controla os relatórios de vulnerabilidade e os boletins de segurança rigorosamente —, esta seção se baseia em dados indicativos na forma de observações e opiniões de pessoas da equipe SWI.

5.1 Eficiência dos elementos do SDL

O SDL é composto de um grande número de subprocessos do componente que são distribuídos por todo o ciclo de vida do desenvolvimento de software. Foi solicitado à equipe do SDL que priorizasse esses subprocessos em termos de efetividade (de acordo com aqueles que tivessem o melhor resultado), do que foi tentado e do que foi considerado menos efetivo.

O consenso na equipe SWI é que a modelagem de ameaças é o componente do SDL de maior prioridade. Obviamente, a modelagem de ameaças não é aplicada isoladamente: ela direciona o design, a revisão do código e os testes, e um processo que implementasse apenas a modelagem de ameaças sem responder aos modelos (falhando, por exemplo, em testar a eficiência das atenuações) não seria eficiente. As estatísticas na forma de contagens de bugs tendem a subestimar a função da modelagem de ameaças porque muito da contribuição da modelagem de ameaças é garantir que os bugs que levariam a vulnerabilidades de segurança nunca sejam criados. Entretanto, a função da modelagem de ameaças de se concentrar no processo de desenvolvimento de software seguro é tão crítica que fica obviamente no topo da lista.

O SDL ainda é um processo relativamente novo na Microsoft, e ainda não houve situações em que um componente do processo tenha sido removido. No entanto, não haverá surpresa para os pesquisadores de longa data em segurança se descobrirem que os testes de penetração não são um caminho para a segurança. Os testes de penetração são um elemento da FSR para uma versão principal do software, mas as atividades da equipe de produto durante todo o ciclo de vida se concentram na modelagem de ameaças, em revisões do código, na utilização de ferramentas automatizadas e em testes difusos em vez de testes de penetração. As últimas medidas são muito mais completas em prevenir ou remover bugs de segurança do que os clássicos testes de penetração ad hoc. O elemento de teste de penetração da FSR ajuda a determinar se o software está pronto para o lançamento em vez de ser uma maneira de localizar e corrigir bugs de segurança. Se o teste de penetração da FSR for altamente produtivo em relação a bugs de segurança, é porque as fases anteriores não foram suficientemente efetivas, e a resposta correta é revisitar as atividades que deveriam ter sido concluídas nessas fases em vez de apenas corrigir os bugs do teste de penetração e lançar o software.

5.2 Ferramentas, testes e revisões de código

Ferramentas de análise estática, testes difusos e revisão de código são complementares. A Microsoft investiu pesado nas ferramentas de verificação de código de análise estática, e a utilização dessas ferramentas é parte integral do SDL. As ferramentas são efetivas na localização de vários erros de código que podem levar a vulnerabilidades de segurança, especialmente saturações do buffer. Contudo, as ferramentas atuais mais avançadas não localizam todos os erros. Revisões manuais do código ainda são exigidas pelo SDL, tanto para detectar erros que as ferramentas não detectam quanto para identificar oportunidades de aperfeiçoamento nas ferramentas. O artigo do MSDN (Microsoft Developer Network) escrito por Michael Howard citado nas referências forneceu uma visão geral da abordagem à condução de revisões de segurança do código que a Microsoft ensina a seus engenheiros.

A ênfase pesada nos testes difusos é uma adição relativamente recente ao SDL, mas os resultados até o momento são bastante animadores. Ao contrário das ferramentas de verificação de código estático, as ferramentas de testes difusos devem ser compiladas (ou pelo menos configuradas) para cada formato de arquivo e/ou protocolo de rede a serem testados; por causa disso, freqüentemente elas são capazes de localizar erros que outras ferramentas de análise estática não conseguem. Os modelos de ameaças ajudam as equipes de produto a priorizar interfaces e formatos para testes. Os resultados dos testes difusos não são totalmente determinísticos (as ferramentas são executadas por um número finito de ciclos e não têm a garantia de localizar todos os bugs), mas a experiência mostra que um nível aceitável de testes difusos provavelmente localizará bugs "interessantes" que poderiam ser explorados como vulnerabilidades de segurança.

5.3 Investimentos

O treinamento obrigatório em segurança constitui um investimento significativo para uma empresa com o tamanho da equipe de engenharia da Microsoft. O treinamento é fornecido por uma combinação de material online e aulas ao vivo (dadas por instrutores). O material online tem um valor especial como veículo para fornecer treinamento para pequenas equipes de engenharia em locais remotos dos escritórios da Microsoft. O treinamento ao vivo se mostrou especialmente eficiente quando fornecido para equipes grandes que estão se preparando para esforços de segurança ou outras atividades-chave; nesses casos, a experiência da Microsoft sugere que o treinamento da equipe seja resultado não apenas de treinamento em sala de aula, mas também da condução do esforço de segurança. O treinamento em segurança (que normalmente leva meio período) é amplificado pelo fato de todos no grupo de trabalho estarem concentrados na segurança.

A equipe de segurança central (a equipe SWI) cresceu significativamente nos últimos anos, conforme cresceu a ênfase da Microsoft na segurança. Pelo design, a equipe é pequena em relação à equipe total de engenharia da Microsoft e enfatiza abordagens que são "escalonadas" para garantir que a responsabilidade e os recursos para produzir software mais seguro continuem com as equipes de produto. Algumas táticas que refletem esse foco na escala incluem a ênfase em treinamento e ferramentas, o fornecimento de supervisores de segurança que ajudam a equipe de produto a resolver seus próprios problemas (em vez de resolver os problemas da equipe) e a utilização de revisões (incluindo a FSR) para fornecer à equipe de produto comentários sobre a prontidão do software para o lançamento.

5.4 Resultados

O teste final do SDL mede o quanto ele é capaz de remover e atenuar as vulnerabilidades do software Microsoft. A experiência, resumida na Seção 4, demonstra que o SDL passa nesse teste. A Microsoft também avalia as vulnerabilidades relatadas externamente com relação ao seu efeito sobre versões do software em desenvolvimento. A experiência recente mostrou que medidas de segurança planejadas para ou implementadas em novas versões bloqueiam ataques que seriam efetivos em versões mais antigas em um número cada vez maior de casos. O recém-lançado Windows XP Service Pack 2 foi revisado dessa maneira, e as alterações de segurança que foram planejadas mas ainda não foram implementadas ou abordadas publicamente eliminaram um número significativo de vulnerabilidades relatadas em versões anteriores do Windows por pesquisadores de segurança externos à Microsoft.

6. Conclusões

A experiência da Microsoft indica que o SDL é eficiente na redução da incidência de vulnerabilidades de segurança. A implementação inicial do SDL (no Windows Server 2003, no SQL Server 2000 Service Pack 3 e no Exchange 2000 Server Service Pack 3) resultou em aprimoramentos significativos na segurança do software, e as versões subseqüentes, que refletem os aperfeiçoamentos do SDL, aparentemente estão mostrando ainda mais avanços de segurança.

A implementação incremental dos elementos que compreendem o SDL gerou aprimoramentos incrementais, que vemos como um sinal de um processo efetivo. O processo não é perfeito e ainda está evoluindo; e provavelmente não alcançará a perfeição nem parará de evoluir em um futuro próximo.

O desenvolvimento e a implementação do Ciclo de vida do desenvolvimento da segurança representa um investimento importante para a Microsoft e uma mudança essencial na forma como o software é criado, desenvolvido e testado. A importância crescente do software para a sociedade enfatiza a necessidade de a Microsoft e a indústria como um todo continuarem aperfeiçoando a segurança do software; assim, tanto este artigo sobre o SDL e livros sobre técnicas específicas (consulte as referências) foram publicados em um esforço para compartilhar a experiência da Microsoft com a indústria de software.

7. Agradecimentos

O desenvolvimento inicial deste artigo começou no final de 2002 como um esforço conjunto dos autores atuais. Os rascunhos foram atualizados conforme o SDL evoluiu, e a versão atual foi preparada no primeiro semestre de 2004. Os autores gostariam de agradecer as contribuições de Matt Thomlinson, Matt Lyons, Jamil Villani e Eric Bidstrup (todos da equipe SWI da Microsoft) quanto à definição e ao refinamento do SDL. Além dos colaboradores mencionados, Scott Charney e Phil Reitinger da Microsoft e Jeannette Wing da Carnegie Mellon University forneceram comentários especialmente úteis sobre os rascunhos. Os autores também desejam agradecer a Martin Abadi, Virgil Gligor, Dick Kemmerer, Chris Mitchell, Fred Schneider, Neeraj Suri e James Whittaker pelos comentários e sugestões sobre este artigo.

8. Referências

Mundie, Craig, Trustworthy Computing White Paper (em inglês)

Howard, Michael, Attack Surface: Mitigate Security Risks by Minimizing the Code You Expose to Untrusted Users (em inglês), MSDN Magazine, novembro de 2004

Howard, Michael, Expert Tips for Finding Security Defects in Your Code (em inglês), MSDN Magazine, novembro de 2003

Howard, Michael e David LeBlanc, Writing Secure Code (em inglês), segunda edição, Microsoft Press, Redmond, Washington, 2003

Swiderski, Frank e Window Snyder, Threat Modeling (em inglês), Microsoft Press, Redmond, Washington, 2004

9. Avisos

As informações contidas neste documento representam a visão atual da Microsoft Corporation sobre as questões abordadas até a data de publicação. Como a Microsoft deve responder a condições de mercado que sofrem modificações, esse artigo não deve ser interpretado como um compromisso por parte da Microsoft, e a Microsoft não pode garantir a precisão de qualquer informação apresentada após a data da publicação.

Este white paper destina-se apenas a fins de informação. A MICROSOFT NÃO OFERECE GARANTIAS, EXPRESSAS, IMPLÍCITAS OU ESTATUTÁRIAS, COM RELAÇÃO ÀS INFORMAÇÕES CONTIDAS NESTE DOCUMENTO.

O cumprimento de todas as leis de direitos autorais aplicáveis é responsabilidade do usuário. Sem limitar os direitos sob as leis de direitos autorais, nenhuma parte deste documento pode ser reproduzida, armazenada ou introduzida em um sistema de recuperação, transmitida de nenhuma forma, por nenhum meio (eletrônico, mecânico, fotocópia, gravação ou outros) ou por qualquer finalidade, sem a permissão expressa por escrito da Microsoft Corporation.

A Microsoft pode ter patentes, solicitações de patentes, marcas registradas, direitos autorais ou outros direitos de propriedade intelectual sobre o assunto deste documento. Exceto conforme expressamente declarado em contrato de licença por escrito da Microsoft, o fornecimento deste documento não concede a você nenhuma licença dessas patentes, marcas registradas, copyrights ou outra propriedade intelectual.

© 2005 Microsoft Corporation. Todos os direitos reservados. Partes deste white paper são da © 2004 Institute of Electrical and Electronics Engineers, Incorporated. Todos os direitos reservados.

Microsoft, MSDN, Windows e Windows Server são marcas comerciais registradas ou marcas registradas da Microsoft Corporation nos Estados Unidos e/ou em outros países.

© .