O processo SDL - Trustworthy Computing Security Development Lifecycle
Steve Lipner
Michael Howard
Security Engineering and Communications
Security Business and Technology Unit
Microsoft Corporation
A Microsoft vem adotando um processo de desenvolvimento de softwares que visa combater ataques maliciosos. As atividades e resultados voltados para a segurança são agora partes integrantes de cada etapa do desenvolvimento.
Geral:
Este artigo trata sobre o Trustworthy Computing Security Development Lifecycle (ou SDL), um processo adotado pela Microsoft para o desenvolvimento de programas, que impede ataques maliciosos. O processo envolve a inclusão de uma série de medidas centradas na segurança a cada uma das fases do processo de desenvolvimento de softwares da Microsoft. Entre essas medidas, incluem-se o desenvolvimento de simulações de ameaça durante a fase de projeto de 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 exames de código e testes de segurança durante a chamada "verificação extra de segurança". Para que o software sob o processo SDL possa ser lançado, ele deve ser primeiro submetido a uma Análise Final de Segurança, realizada por uma equipe independente do grupo de desenvolvimento. Os programas submetidos ao processo SDL, quando comparados aos que não foram submetidos a esse processo, mostraram uma redução significativa de ataques externos à segurança. Este artigo descreve o SDL e mostra as experiências feitas com sua implementação em programas da Microsoft.
Observação:
Este artigo é uma versão atualizada do "The Trustworthy Computing Security Development Lifecycle", apresentado originariamente no 2004 Annual Computer Security Applications Conference (Congresso Anual sobre Aplicativos para Segurança na Informática), patrocinado pelo IEEE e realizado em Tucson, Arizona, em dezembro de 2004.
Nesta página
1. Introdução
É imperativo que todos os fornecedores de software defendam-se de ameaças à segurança. Segurança é um requisito fundamental para os fornecedores de software, impulsionado pela pressão do mercado, pela necessidade de proteger infra-estruturas vitais e pela necessidade de instaurar e difundir segurança na informática. Um dos maiores desafios para todos os fornecedores de software é o de criar programas mais seguros, que exijam menos atualizações por meio de "patches" e reduzam o fardo que é o gerenciamento da segurança.
Para a indústria da informática, a chave para atender à demanda atual por melhorias na segurança está em implementar processos repetidos que ofereçam, com confiança, melhorias visíveis na segurança. Portanto, os fornecedores de software devem fazer a transição para um processo mais direcionado de desenvolvimento de software, que concentre-se, em grande parte, na segurança. Tal processo visa reduzir o número de "brechas" na segurança existentes na fase de projeto, codificação e documentação, bem como detectar e remover essas brechas o quanto antes dentro do ciclo de duração do desenvolvimento. A necessidade de um processo como esse é vital no caso de programas (de empresas ou indivíduos) que devam ser usados para processar informações recebidas pela Internet, controlar sistemas vitais propensos a ataques ou processar dados de identificação pessoal.
A criação de um software mais seguro tem três facetas: repetição do processo, treinamento de engenheiros e métrica/contabilidade. Este documento focaliza o aspecto da repetição do processo SDL, embora aborde também o treinamento de engenheiros e forneça uma métrica geral que mostra o impacto de um aplicativo subjacente ao SDL.
Pela experiência da Microsoft, pode-se afirmar que a adoção do SDL por outras organizações não deverá aumentar o custo do desenvolvimento de softwares. Na opinião da Microsoft, os benefícios obtidos com o oferecimento de softwares mais seguros (por exemplo, menos patches, clientes mais satisfeitos) compensam os custos.
O processo SDL implica modificar os processos de organização do desenvolvimento de softwares por meio da integração de medidas que gerem mais segurança no software. Este documento fornece um resumo dessas medidas e descreve o modo como elas são integradas ao ciclo de duração de um desenvolvimento de software comum. A intenção dessas modificações não é refazer o processo inteiro, mas sim incluir pontos bem-definidos para verificação da segurança e mostrar resultados.
Este documento parte do pressuposto de que há um grupo central dentro da empresa (ou da organização de desenvolvimento de software) que conduz o desenvolvimento e a evolução das melhores práticas de segurança e melhorias no processo, atua como fonte de experiência para a empresa como um todo e realiza uma revisão (a chamada Análise Final de Segurança ou FSR) antes do lançamento do software. Pela experiência da Microsoft, pode-se afirmar que a existência de uma organização desse tipo é vital para o sucesso na implementação do SDL, bem como para a melhoria na segurança dos programas em geral. No entanto, algumas organizações preferem que a função da "equipe central de segurança" seja desempenhada por um consultor ou pessoal contratado. Este artigo descreve a integração de uma série de etapas que visam melhorar a segurança dos softwares dentro do processo de desenvolvimento de softwares, que são geralmente usadas por grandes empresas de desenvolvimento de programas. Essas etapas foram projetadas e implementadas pela Microsoft como parte da sua iniciativa para computação confiável. O objetivo dessas melhorias no processo é reduzir a quantidade e a gravidade das brechas na segurança dos programas usados pelos clientes. Neste documento, o processo modificado de desenvolvimento de softwares, que está sendo atualmente implementado na Microsoft, está sendo chamado de Trustworthy Computing Software Development Lifecycle (literalmente, Ciclo de duração do desenvolvimento de programas para computação confiável) ou simplesmente SDL.
A Microsoft acredita que a equipe de segurança deve estar disponível para interações freqüentes durante a fase de projeto e desenvolvimento do software, bem como deve centralizar todas as informações confidenciais técnicas e empresariais. Por esses motivos, a solução preferida é criar uma equipe de segurança dentro da organização de desenvolvimento de software (embora talvez seja bom contratar consultores para ajudar a montar e treinar os membros da equipe).
1.1 A base do processo
O processo de desenvolvimento de softwares geralmente adotado na Microsoft segue, aproximadamente, o fluxograma mostrado na Figura 1. De um modo geral, esse processo é comumente usado nesse mercado.
Figura 1. Processo de desenvolvimento padrão da Microsoft
Clique aqui para ver uma versão ampliada.
Embora a Figura 1 mostre cinco metas e represente o processo de desenvolvimento de forma linear, o processo ocorre, na verdade, em espiral. As etapas de requisitos e projeto são freqüentemente reavaliadas durante a implementação, de forma a refletir as mudanças nas necessidades do mercado e outros fatores que possam surgir durante a implementação do software. Além disso, o processo de desenvolvimento enfatiza a necessidade de se ter um código em execução em praticamente todos os pontos; por isso, cada meta principal é desmembrada em uma série de builds que podem ser testados e colocados em operação (pela equipe de desenvolvimento) em ritmo progressive.
1.2 Visão geral do SD
A experiência com a segurança dos softwares do mundo real levou à definição de uma série de princípios gerais para a criação de programas mais seguros. A Microsoft classifica esses princípios como S3+C: segurança no projeto, segurança por padrão, segurança na implantação e comunicação. Vejamos uma breve definição de cada um desses princípios:
| • | Segurança no projeto: o software deve ser esboçado, projetado e implementado de modo a proteger a si mesmo e às informações que ele processa, bem como resistir a ataques. |
| • | Segurança por padrão: no mundo real, nenhum software pode ser perfeitamente seguro, portanto os projetistas devem prever a presença de falhas na segurança. Para diminuir os danos causados quando invasores detectam essas falhas remanescentes, o estado padrão do software deve promover a segurança. Por exemplo, o software deve operar com o mínimo necessário de privilégios, e todos os serviços e recursos que não sejam amplamente necessários devem vir desativados por padrão ou ser acessíveis somente a um pequeno grupo de usuários. |
| • | Segurança na implantação: O software deve vir acompanhado de ferramentas e guias para ajudar os usuários finais e/ou administradores a usá-lo com segurança. Além disso, as atualizações devem ser fáceis de serem implantadas. |
| • | Comunicação: os desenvolvedores de software devem estar preparados para a descoberta de falhas na segurança do produto e devem se comunicar de forma aberta e responsável com os usuários finais e/ou administradores para ajudá-los a tomar medidas preventivas (tais como a instalação de patches ou o uso de medidas paliativas). |
Embora cada elemento da formula S3+C imponha requisitos ao processo de desenvolvimento, os primeiros dois elementos — segurança no projeto e segurança por padrão — oferecem os maiores benefícios. A segurança no projeto comanda os processos de modo a impedir falhas na segurança em primeiro lugar, enquanto a segurança por padrão exige que a exposição padrão do software — sua "área vulnerável" — seja reduzida.
A introdução de medidas de segurança que visam integrar o paradigma da fórmula S3+C ao processo de desenvolvimento existente resulta na organização processual mostrada na Figura 2.
Figura 2. Melhorias no SDL para o processo de desenvolvimento da Microsoft
Clique aqui para ver uma versão ampliada.
A Seção 2 deste documento descreve os componentes do SDL de um modo geral. A Seção 3 apresenta um breve resumo dos aspectos específicos da implementação do SDL pela Microsoft. A Seção 4 fornece alguns dados ilustrativos que mostram que a aplicação do SDL no estágio inicial do desenvolvimento do Microsoft Windows Server 2003 e de outros programas resultou em menos falhas na segurança e menor gravidade nas falhas existentes, em comparação com versões anteriores do software. A Seção 5 faz algumas observações qualitativas sobre elementos do processo, com base na experiência da Microsoft na aplicação do SDL. Por fim, a Seção 6 apresenta as conclusões finais.
2. O processo SDL
Conforme informado anteriormente, o treinamento de engenheiros está além do escopo deste artigo. Contudo, é importante observar que um programa de treinamento é fundamental para o sucesso do SDL. Os universitários recém-formados em Informática e disciplinas afins geralmente não tiveram o treinamento necessário para começar a trabalhar normalmente no projeto, desenvolvimento ou teste de softwares seguros. Até mesmo os que já realizaram trabalhos na área de segurança provavelmente encontraram problemas com algoritmos criptográficos ou modelos de controle de acesso, e não com saturação de buffer ou canonização. De um modo geral, nem os projetistas de software, engenheiros e testers da área têm o conhecimento necessário sobre segurança.
Nessas circunstâncias, uma organização que planeje desenvolver softwares seguros deve responsabilizar-se pelo treinamento adequado de toda a sua equipe de engenheiros. Para vencer esse desafio, há métodos específicos que variam de acordo com o tamanho da organização e com os recursos disponíveis. Uma organização com uma grande equipe de engenheiros pode se comprometer a criar um programa interno de treinamento em segurança para engenheiros; já para uma organização de menor porte talvez seja necessário realizar o treinamento externamente. Na Microsoft, todo o pessoal envolvido no desenvolvimento de softwares deve realizar um curso anual de "atualização das técnicas de segurança".
2.1 Fase de requisitos
A necessidade de pensar na segurança desde o primeiro estágio é um princípio fundamental para o desenvolvimento de um sistema seguro. Embora vários projetos de desenvolvimento produzam versões subseqüentes criadas com base nas versões anteriores, é na fase de requisitos e planejamento inicial de uma nova versão a melhor hora para se criar um software seguro.
Durante a fase de requisitos, a equipe de produto entra em contato com a equipe central de segurança para solicitar a nomeação de um consultor de segurança, que deve atuar como ponto de contato, recurso e guia durante o curso do planejamento. O consultor de segurança deve ajudar a equipe de produto, revendo os planos, fazendo recomendações e garantindo que a equipe de segurança planeje adotar os recursos apropriados para oferecer suporte à equipe de produto. O consultor de segurança mostra à equipe de produto como atingir as metas de segurança e como estabelecer os critérios de saída que serão necessários, com base no tamanho, complexidade e risco do projeto. O consultor de segurança permanecerá como ponto de contato entre a equipe de produto e a equipe de segurança, atuando desde o começo do projeto e atravessando a Análise Final de Segurança até o lançamento do software. O consultor de segurança também deve atuar como contato entre a gerência das equipes de segurança e de produto, mostrando às gerencias se o elemento segurança de seus projetos está ou não mantendo o nível esperado, de modo a evitar surpresas em uma fase posterior do processo.
É na fase de requisitos que a equipe de produto tem a oportunidade de considerar como a segurança será integrada ao processo de desenvolvimento, identificar os objetivos principais no campo da segurança e oferecer máxima segurança nos programas com o mínimo de obstáculos para os planos e prazos. Como parte desse processo, a equipe precisa levar em conta o modo como os aspectos da segurança e medidas de garantia do software em questão irão se integrar com outros softwares que possam vir a ser usados com esse. (A integração com outros softwares é um fator crucial a ser considerado para satisfazer as necessidades dos usuários de integrar produtos individuais em sistemas de segurança.) Todas as perspectivas da equipe de produto no que diz respeito a metas de segurança, desafios e planos devem ser consideradas durante o planejamento de documentos produzidos durante a fase de requisitos. Embora os planos possam vir a mudar durante o andamento do projeto, o conhecimento desses planos no estágio inicial ajuda a assegurar que nenhum requisito foi ignorado ou surgiu como imprevisto.
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 venham a ser identificados na simulação de ameaças, nos requisitos do usuário irá provavelmente constar a inclusão de recursos de segurança de acordo com as demandas do cliente. Os requisitos de recursos de segurança também serão estabelecidos de acordo com a necessidade de adequar-se aos padrões do mercado e com processos de certificação, como o Common Criteria. A equipe de produto deve reconhecer e avaliar esses requisitos como parte do processo normal de planejamento.
2.2 Fase de projeto
A fase de projeto identifica os requisitos gerais e a estrutura para o software. Do ponto de vista da segurança, os principais elementos da fase de projeto são:
| • | Definir diretrizes para arquitetura e projeto de segurança. Isso consiste em definir a estrutura geral do software pela perspectiva da segurança e identificar os componentes cujo funcionamento correto seja essencial à segurança (a chamada "base em computação confiável"). Identificar técnicas de projeto (tais como organização em camadas, uso de linguagem altamente confiável, aplicação de um mínimo de privilégios e redução da área vulnerável) que se aplicam ao software de forma global. (Por organização em camadas entende-se a organização do software em componentes bem definidos, estruturado de modo a evitar dependências em círculo entre eles — os componentes são organizados em camadas de modo que uma camada de nível superior possa depender dos serviços de camadas inferiores, mas nunca camadas inferiores dependam das superiores.) Os aspectos específicos de elementos isolados da arquitetura serão detalhados em especificações de projeto individuais, mas a arquitetura da segurança identifica uma perspectiva geral do projeto de segurança. |
| • | Documentar os elementos da área vulnerável do software. Admitindo-se que o software nunca será perfeitamente seguro, é importante que somente os recursos que serão usados pela vasta maioria dos usuários fiquem expostos a todos os usuários por padrão, e que esses recursos sejam instalados com o mínimo possível de privilégios. A medição dos elementos da área vulnerável oferece à equipe de produto uma base progressiva para estabelecer a segurança por padrão, bem como permite-lhe detectar pontos onde o software está mais suscetível a ataques. Apesar de ser justificável a expansão de certas áreas vulneráveis, devido à expansão das funções ou aplicações do produto, é importante detectar e questionar cada uma dessas áreas durante o projeto e a implementação, de modo que o software possa ser lançado com uma configuração padrão mais segura possível. |
| • | Realizar simulação de ameaças. A equipe de produto deve realizar simulação de ameaças em cada um dos componentes. Através de uma metodologia estruturada, a equipe responsável pelos componentes identifica as funções que o software deve dominar e a interface pela qual essas funções podem ser acessadas. O processo de simulação de ameaças identifica ameaças potencialmente prejudiciais a cada função, bem como a probabilidade de danos (estimativa de risco). A equipe responsável pelos componentes, então, identifica medidas de combate que reduzam os riscos — seja na forma de recursos de segurança (como criptografia) ou na forma de recurso de proteção contra danos do próprio software. Portanto, a simulação de ameaças ajuda a equipe de produto a identificar a necessidade de recursos de segurança, bem como áreas onde deve-se redobrar os cuidados na análise de código e teste de segurança. O processo de simulação de ameaças deve ser associado a uma ferramenta que captura simulações de ameaças em formato legível pelo computador para armazenamento e atualização. |
| • | Definir critérios complementares de lançamento. Embora os critérios básicos de lançamento devam ser definidos no nível da organização, as equipes responsáveis por produtos individuais ou versões de software talvez tenham estabelecido critérios específicos que devam ser atendidos para que o software possa ser lançado. Por exemplo, uma equipe de produto desenvolvendo a versão atualizada de um software prestes a ser lançada e que está sujeita a vários tipos de ataques pode optar por exigir que, somente se nenhuma falha na segurança for relatada externamente durante um certo período, essa nova versão seja considerada pronta para ser lançada. (Isto é, as falhas deverão ter sido encontradas e removidas no processo de desenvolvimento antes de serem relatadas, em vez de deixar para a equipe de produto a tarefa de corrigir a falha após ser informada.) |
2.3 Fase de implementação
Durante a fase de implementação, a equipe de produto codifica, testa e integra o software. As etapas para remover qualquer brecha na segurança ou impedir o aparecimento delas nesta fase são altamente reforçadas — elas reduzem de forma significativa a probabilidade de que falhas na segurança venham a surgir na versão final do software que será lançada para os clientes.
Os resultados da simulação de ameaças são particularmente importantes durante a fase de implementação. Os desenvolvedores concentram-se principalmente em garantir a exatidão do código que reduz as ameaças de alta prioridade, e os testers procuram garantir que tais ameaças sejam bloqueadas ou enfraquecidas.
Os elementos do SDL que se aplicam à 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 falhas que possam gerar brechas na segurança. Por exemplo, o uso de métodos mais seguros e coerentes para a manipulação de strings e buffer pode ajudar a evitar a introdução de falhas por saturação do buffer. A definição de padrões de teste e práticas recomendadas ajudam a garantir que o teste concentre-se em detectar brechas em potencial na segurança, em vez de concentrar-se somente em corrigir defeitos operacionais nas funções e recursos do software. |
| • | Aplicar ferramentas para testar a segurança, incluindo ferramentas de simulação de dados. A simulação de dados (ou "fuzzing") fornece entradas estruturadas, porém inválidas, nas interfaces de programação (APIs) do software e nas interfaces de rede, de modo a aumentar a probabilidade de detecção de erros que possam levar a brechas na segurança do software. |
| • | Aplicar ferramentas de verificação de código de análise estática. Essas ferramentas conseguem detectar certos tipos de falhas na codificação que podem gerar brechas na segurança, incluindo saturações de buffer, saturações de inteiros e variáveis não inicializadas. A Microsoft investiu muito no desenvolvimento dessas ferramentas (as duas que vêm sendo usadas há mais tempo são conhecidas como PREfix e PREfast) e está sempre aperfeiçoando-as, à medida que são descobertos novos tipos de falhas de codificação e brechas na segurança do software. |
| • | Realizar revisões de código. As revisões de código complementam as ferramentas automatizadas e testes, na medida em que aplicam o esforço de desenvolvedores treinados para examinar códigos-fonte e detectar e remover falhas em potencial na segurança. Elas são uma etapa crucial no processo de remoção de brechas na segurança do software durante o processo de desenvolvimento. |
2.4 Fase de verificação
A fase de verificação é o ponto onde o software está funcionalmente completo e onde são iniciados os testes da versão beta pelo usuário. Durante essa fase, enquanto o software está sendo submetido ao teste de beta, a equipe de produto realiza uma "verificação extra de segurança", que inclui análises do código de segurança além das já realizadas na fase de implementação, bem como testes de segurança focalizados.
A Microsoft apresentou a verificação extra de segurança durante a fase de verificação do Windows Server 2003 e de várias outras versões de softwares, no início de 2002. Havia duas razões para a incorporação da verificação extra de segurança ao processo:
| • | O ciclo de duração do software nas versões em questão chegou à fase de verificação, e essa fase era um ponto adequado para realizarem-se as análises de código e testes focalizados necessários. |
| • | A realização da verificação extra de segurança durante a fase de verificação normal assegura que a análise de código e o teste irão focalizar a versão final do software, e oferece a oportunidade de rever tanto o código que foi desenvolvido ou atualizado durante a fase de implementação quanto o "código herdado", que não foi modificado. |
A primeira dessas razões é o reflexo de um acidente histórico: a decisão de executar uma verificação extra de segurança ocorreu, inicialmente, durante a fase de verificação. Contudo, a Microsoft chegou à conclusão que realizar uma verificação extra de segurança durante a fase de verificação é, na verdade, uma boa idéia, tanto para assegurar que o software final atende aos requisitos quanto para permitir uma revisão mais profunda de todo código herdado que tenha sido trazido de versões anteriores do software.
É importante observar que as análises de código e testes de códigos de alta prioridade (códigos que são parte da "área vulnerável" do software) são vitais para diversas partes do SDL. Por exemplo, essas análises e testes devem ser exigidos na fase de implementação para permitir que as correções de todo e qualquer problema, bem como a identificação e correção da origem de tais problemas, sejam feitas em um estágio inicial. Eles também são essenciais na fase de verificação, quando o produto está prestes a ser concluído.
2.5 Fase de lançamento
Durante a fase de lançamento, o software deve estar sujeito a uma Análise Final de Segurança ("FSR"). O objetivo da FSR é responder a uma pergunta. "Do ponto de vista da segurança, este software está pronto para ser lançado no mercado?" A FSR é realizada de dois a seis meses antes da conclusão do software, dependendo do escopo do software. O software deve estar em um estado estável antes da FSR, sendo esperadas apenas alterações mínimas não relativas à segurança antes do lançamento.
A FSR é uma análise independente do software, realizada pela equipe central de segurança da organização. O consultor da equipe de segurança apresenta à equipe de produto o escopo da FSR exigida pelo software e oferece à equipe de produto uma lista de requisitos de recursos antes da FSR. A equipe de produto fornece à equipe de segurança os recursos e informações necessárias à conclusão da FSR. A FSR começa com o preenchimento de um questionário pela equipe de produto e uma entrevista com um membro da equipe de segurança atribuído à FSR. Toda FSR irá requerer uma revisão dos bugs que tiverem sido inicialmente identificados como bugs na segurança, mas que, em uma análise posterior, tenham sido classificados como não causadores de impacto na segurança, para garantir que a análise foi feita corretamente. A FSR também deverá incluir uma revisão da capacidade do software de resistir a brechas na segurança recém-informadas e que afetam programas semelhantes. Uma FSR em uma versão importante de um software irá requerer testes de invasão e, potencialmente, o uso de pessoal contratado para a análise de segurança para complementar a equipe de segurança.
A FSR não é simplesmente uma prova para aprovar ou reprovar, nem é seu objetivo encontrar todas as brechas na segurança ainda restantes no software; isso seria claramente inviável. Na verdade, o que a FSR faz é oferecer à equipe de produto e à diretoria da organização um quadro geral da situação da segurança do software, mostrando a probabilidade de que este consiga resistir a ataques após ser lançado no mercado. Se a FSR encontrar um padrão de pontos vulneráveis ainda restantes, a melhor atitude é não apenas corrigir as falhas na segurança encontradas, mas também voltar à fase anterior e tomar certas medidas para eliminar o problema pela raiz (por exemplo, aperfeiçoar o treinamento, melhorar as ferramentas).
2.6 Fase de manutenção e suporte
Apesar da aplicação do SDL durante o desenvolvimento, nem mesmo as práticas de desenvolvimento mais modernas conseguem oferecer um software sem absolutamente nenhuma falha na segurança — e há bons motivos para acreditar-se que isso nunca acontecerá. Mesmo que o processo de desenvolvimento pudesse eliminar todas as brechas na segurança do software até a hora de seu lançamento no mercado, logo seriam descobertas novas frentes de ataque e o software, antes "seguro", se tornaria vulnerável. Portanto, as equipes de produto devem estar preparadas para lidar com brechas na segurança recém-descobertas no software que está sendo lançado no mercado.
Parte dos procedimentos para lidar com essas novas brechas é preparar-se para avaliar relatórios de falhas na segurança e oferecer aconselhamento e lançar atualizações, quando apropriado. A outra parte dos procedimentos é realizar um post-mortem das falhas na segurança informadas e tomar as medidas necessárias. As medidas de combate à falha vão desde o lançamento de uma atualização (como resposta a um erro isolado) à atualização das ferramentas de verificação de código e introdução de análises de código em subsistemas de grande importância. O objetivo durante a fase de resposta/combate é aprender com os erros e usar as informações fornecidas nos relatórios de falhas na segurança para ajudar a detectar e eliminar falhas posteriores, antes de serem descobertas em campo e usadas para colocar os clientes em risco. O processo de resposta/combate também ajuda a equipe de produto e a equipe de segurança a adaptarem os processos para que não ocorram erros semelhantes no futuro.
3. Implementação do SDL na Microsoft
A implementação do SDL na Microsoft vem evoluindo desde as "verificações extras de segurança" do início de 2002. A fim de iniciar o processo e de afetar os produtos em um estágio adiantado do desenvolvimento, as verificações extras de segurança eram alocadas em períodos relativamente curtos de atividades que deveriam ter sido distribuídas ao longo de várias fases do SDL. As verificações extras de segurança tiveram um impacto significativo nos planos, recursos e prazos da equipe de produtos, e teriam sido muito mais difíceis de serem realizadas se não tivessem tido o apoio da diretoria da Microsoft. As verificações extras de segurança concentravam-se na simulação de ameaças, análises de código e testes de segurança (inclusive testes de invasão). A Análise Final de Segurança ("FSR") foi introduzida no fim 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 lançado no mercado.
Após as verificações extras de segurança e FSRs iniciais, a Microsoft deu início a um projeto para formalizar o processo SDL. Quatro resultados específicos desse projeto merecem destaque:
| • | Política para implementação da aplicação obrigatória do SDL |
| • | Treinamento obrigatório da engenharia |
| • | Métrica para a equipe de produtos |
| • | O papel da equipe central de segurança |
As próximas seções abordam cada uma dessas áreas.
3.1 Aplicação obrigatória do SDL
Em vista dos benefícios demonstrados do SDL (consulte a Seção 5), a Microsoft tomou a decisão de formalizar o requisito da aplicação do SDL em vários softwares. No momento da elaboração deste documento, o SDL acaba de se tornar obrigatório para todos os programas que:
| • | devam ser usados para processar dados pessoais ou confidenciais; |
| • | devam ser usados em uma empresa ou outra organização (inclusive acadêmica, governamental ou filantrópica); |
| • | devam ser conectados à Internet ou usados em um ambiente de rede. |
Entre os programas em que a obrigatoriedade não se aplica estão os aplicativos independentes que não se adequam aos critérios acima (por exemplo, jogos para crianças pequenas, como os da série "The Magic School Bus"). O SDL proíbe, de maneira significativa, tais softwares de interferirem na segurança da plataforma (sejam sistemas operacionais ou outro tipo de software) em que o software opera.
3.2 Treinamento obrigatório
Um dos aspectos principais das verificações extras de segurança do início de 2002 foi o treinamento, em nível de equipes de produto, para todos os desenvolvedores, testers, gerentes de programa e pessoal de documentação. A Microsoft formalizou um requisito de haver treinamento anual em segurança para os engenheiros atuantes nas organizações cujos programas estejam sujeitos ao SDL. A necessidade de uma atualização anual é regida pelo fato de a segurança não ser um domínio estático: as ameaças, ataques e defesas evoluem. Por isso, até mesmo os engenheiros considerados altamente competentes e qualificados nos aspectos da segurança que afetam seus programas devem ter treinamento adicional, à medida que o horizonte de ameaças muda. Por exemplo, a gravidade das falhas na segurança de "estouro" de inteiros aumentou drasticamente nos últimos quatro anos, tendo sido demonstrado recentemente que alguns algoritmos criptográficos não reconheceram essas falhas em situações anteriores.
A Microsoft desenvolveu um modelo de apresentação e atualização da segurança, que é apresentado aos engenheiros tanto na forma de "treinamento ao vivo" quanto em mídia digital. A Microsoft usa esse curso como base para um treinamento mais especializado, de acordo com a tecnologia do software e com a função do engenheiro. No momento, a Microsoft está no processo de elaboração de um programa de treinamento em segurança, onde haverá especialização posterior com base na tecnologia, função e nível de experiência do aluno.
Vários parceiros e clientes da Microsoft se mostraram interessados na disponibilidade dos processos e treinamentos em segurança da Microsoft. A Microsoft Press publicou livros baseados nas práticas internas da Microsoft em segurança no projeto, codificação e simulação de ameaças, e a Microsoft Learning oferece cursos elaborados com base nas práticas internas da Microsoft.
3.3 Métrica para as equipes de produto
Na condição de empresa, a Microsoft tem como lema "não se pode controlar o que não se pode medir". Embora seja muito difícil estabelecer métricas que determinem com precisão a segurança de um software, com certeza há métricas para as medidas que colaboram para a segurança de softwares. Essas métricas vão de treinamentos para os engenheiros (no início do ciclo de duração do desenvolvimento) até a taxa de falhas descobertas na segurança de um software já lançado no mercado.
A Microsoft estabeleceu um conjunto de métricas de segurança que as equipes de produto podem usar para monitorar seu êxito na implementação do SDL. Essas métricas lidam com a implementação de equipes no SDL, começando na simulação de ameaças, passando pela análise de código e testes de segurança e terminando na segurança do software apresentado para FSR. Por serem implementadas ao longo do tempo, essas métricas devem permitir que as equipes monitorem seu próprio desempenho (vejam se estão melhorando, se estão estabilizadas ou piorando), bem como seu desempenho em comparação ao de outras equipes. As métricas agregadas serão informadas à gerência da equipe de produto líder e aos Executivos da Microsoft regularmente.
3.4 A equipe central de segurança
Muito antes das verificações extras de segurança de 2002, a Microsoft já havia estabelecido a equipe de SWI (iniciativa para segurança do Windows), com a função de melhorar a segurança e reduzir os pontos vulneráveis do Windows, além de oferecer suporte de segurança às outras equipes de produto além das que desenvolveram o Windows. A equipe de SWI desempenhou o papel principal na organização e gerenciamento da verificação extra de segurança do Windows Server 2003, bem como ofereceu treinamento e consultoria a todos os envolvidos na verificação extra de segurança realizada no início de 2002. Além disso, a equipe de SWI também realizou a análise FSR no Windows Server 2003, tornando-se a pioneira no processo FSR.
Com o desenvolvimento formal do SDL, a SWI assumiu a função de equipe central de segurança na Microsoft. Entre as responsabilidades da SWI, incluem-se:
| • | Desenvolvimento, manutenção e aprimoramento do SDL, incluindo a definição de aspectos obrigatórios do processo. |
| • | Desenvolvimento, aprimoramento e realização de treinamento de engenheiros. |
| • | Nomeação de "consultores de segurança", que guiam as equipes de produto ao longo do processo, realizam análises para as equipes de produto e garantem que as dúvidas da equipe de produto sejam respondidas com rapidez, precisão e confiança. |
| • | Conhecimento de uma vasta quantidade de tópicos de segurança, garantindo que as dúvidas dirigidas aos ou pelos consultores de segurança recebam respostas rápidas e precisas. |
| • | Execução de Análises Finais de Segurança antes do lançamento do software no mercado. |
| • | Investigação técnica de falhas reportadas na segurança de programas já lançados no mercado, a fim de garantir que a raiz do problema seja detectada para que seja usada a medida de combate apropriada. |
A disponibilidade e eficiência da equipe de SWI provaram ser fatores fundamentais na implementação do SDL na Microsoft. A Microsoft vem trabalhando para oferecer um processo mensurável para o desenvolvimento de softwares mais seguros, e esse trabalho implica a necessidade de que a competência em questões de segurança esteja presente em todas as equipes de produto. Contudo, ter uma equipe de segurança centralizada e altamente qualificada é a chave para acelerar o trabalho das equipes de produto de toda a empresa e apoiá-las, enquanto trabalham para oferecer softwares mais seguros, além de assegurar que alguém fora da equipe de produto irá realizar a FSR.
4. Resultados da implementação do SDL na Microsoft
Ainda é cedo para a Microsoft afirmar que o SDL melhora a segurança dos programas da Microsoft, mas os resultados até agora são animadores.
O Windows Server 2003 foi o primeiro sistema operacional lançado pela Microsoft que implementou um grande montante de SDL. A Figura 3 mostra o número de boletins de segurança publicados durante o ano após o lançamento dos dois mais recentes sistemas operacionais de servidor da Microsoft: Windows 2000 e Windows Server 2003. (Quando o Windows 2000 foi lançado, a Microsoft não tinha um sistema formal de avaliação da gravidade em boletins de segurança. A Microsoft comparou cada boletim de segurança referente ao Windows 2000 com seu respectivo sistema de avaliação da gravidade atual.) Conforme tratado anteriormente neste artigo, o Windows Server 2003 foi desenvolvido com a maioria dos processos SDL (porém não todos); o Windows 2000 não foi desenvolvido com esses processos.
Figura 3. Boletins de segurança do Windows antes e depois do SDL
As classes de gravidade encontram-se definidas em http://www.microsoft.com/technet/security/bulletin/rating.mspx (site em inglês).
Outros programas lançados pela Microsoft também aplicaram elementos do SDL. Cada uma das equipes de produto do SQL Server e Exchange Server realizou uma verificação extra de segurança (incluindo simulação de ameaças, análises de código e testes de segurança) antes do lançamento de um service pack — um complemento do software que soluciona tanto problemas de segurança quanto outros. Os resultados da verificação extra de segurança do SQL Server foram incorporados ao SQL Server 2000 Service Pack 3, e os resultados da verificação extra de segurança do Exchange Server foram incorporados ao Exchange 2000 Server Service Pack 3. As Figuras 4 e 5 mostram o número de boletins de segurança publicados em períodos iguais antes e 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).
Figura 4. Boletins de segurança do SQL Server 2000 antes e depois do SDL
Figura 5. Boletins de segurança do Exchange Server 2000 antes e depois do SDL
Um outro exemplo encorajador é o componente Internet Information Server (IIS 6) do Windows Server 2003. Nesses dois anos desde o seu lançamento, a Microsoft publicou 1 boletim de segurança referente ao servidor da Web -- e isso foi em um componente (WebDAV) que não vem instalado por padrão.
Apesar de os exemplos de brechas na segurança ainda serem poucos e os períodos serem limitados, esses resultados comprovam que o SDL é eficaz. A Microsoft vai continuar monitorando as taxas de falhas na segurança do Windows Server 2003 e dos service packs do Exchange Server e SQL Server para assegurar-se de que essa tendência irá continuar. Além disso, a Microsoft também irá analisar outros de seus programas, à medida em que novas versões vão sendo lançadas após a total implementação do SDL, para determinar se os números e taxas de gravidade das falhas na segurança continuam diminuendo.
5. Observações sobre a aplicação do SDL
Os dados apresentados na seção anterior forneceram uma visão geral sobre "o que" espera-se do SDL. Esta seção tenta esclarecer algumas dúvidas sobre "como" o processo funciona. Enquanto a seção anterior baseia-se em estatísticas numéricas — a Microsoft controla rigorosamente os relatórios de falhas na segurança e os boletins de segurança — esta seção baseia-se em relatos apresentados na forma de observações e opiniões de membros da equipe da SWI.
5.1 Eficácia de elementos do SDL
O SDL é composto por um grande número de subprocessos de componentes, distribuídos pelo ciclo de duração do desenvolvimento do software. A equipe do SDL foi solicitada a priorizar esses subprocessos no que diz respeito à eficácia — quais produzem o melhor resultado e o que foi tentado e considerado menos eficiente.
O consenso entre a equipe de SWI é que a simulação de ameaças é o componente de maior prioridade do SDL. É claro que a simulação de ameaças não é aplicada isoladamente: ela associa-se ao projeto, à análise de código e ao teste; um processo que implementasse somente a simulação de ameaças e depois não tomasse nenhuma medida de combate às ameaças resultantes (não testando a eficácia das medidas atenuantes, por exemplo) não seria eficiente. As estatísticas na forma de número de bugs tendem a enfraquecer a função da simulação de ameaças, pois grande parte da contribuição da simulação de ameaças é garantir que jamais sejam criados bugs que possam gerar brechas na segurança. Contudo, o papel da simulação de ameaças voltado para o processo de desenvolvimento de softwares seguros é tão importante que é, sem dúvida, o primeiro tópico da lista.
O SDL é ainda um processo relativamente novo na Microsoft, por isso ainda não houve casos de remoção de algum componente do processo. Contudo, uma descoberta não será surpresa para os pesquisadores antigos da área de segurança: os testes de invasão não são a maneira de se obter a segurança. O teste de invasão é um elemento da Análise Final de Segurança (FSR) para o lançamento de um software importante, mas as atividades da equipe de produto durante todo o ciclo de duração concentram-se na simulação de ameaças, análises de código, uso de ferramentas automatizadas e teste com dados simulados (em vez de teste de invasão). Estas medidas são muito mais eficazes na prevenção ou remoção de bugs na segurança do que o clássico teste de invasão direcionado. O elemento teste de invasão na FSR serve para ajudar a determinar se o software está pronto para ser lançado, não para encontrar e consertar bugs na segurança. Se o teste de invasão realizado durante a FSR mostrar um grande número de bugs na segurança, isso significa que as fases anteriores não foram eficazes o suficiente; a atitude correta neste caso é rever as atividades que deveriam ter sido completadas nessas fases, e não simplesmente corrigir os bugs e lançar o software.
5.2 Ferramentas, testes e análises de código
As ferramentas de análise estática, testes com dados simulados e análises de código são medidas complementares. A Microsoft vem investindo muito em ferramentas de verificação de código de análise estática, e o uso dessas ferramentas é parte integrante do SDL. Essas ferramentas são eficazes na localização de vários erros de código que poderiam causar brechas na segurança — principalmente saturações de buffer. Contudo, nem mesmo as mais modernas e atuais ferramentas conseguem encontrar todos os erros. Ainda é necessário realizar análises manuais de código no SDL, tanto para detectar erros ignorados pelas ferramentas como para identificar oportunidades de melhorias nas mesmas. O artigo Microsoft Developer Network (MSDN), por Michael Howard, citado nas referências bibliográficas, fornece uma visão geral do método de análise da segurança de código que a Microsoft ensina a seus engenheiros.
A forte ênfase nos testes com dados simulados é uma tendência relativamente recente do SDL, porém os resultados até agora têm sido animadores. Ao contrário das ferramentas de verificação de código de análise estática, as ferramentas de testes com dados simulados devem ser criadas (ou ao menos configuradas) para cada formato de arquivo e/ou protocolo de rede a ser testado; por esse motivo, elas são geralmente capazes de encontrar erros ignorados pelas ferramentas de análise estática. As simulações de ameaças ajudam a equipe de produtos a estabelecer prioridades para as interfaces e formatos a serem testados. Os resultados do teste com dados simulados não são totalmente categóricos (as ferramentas são executadas em um número finito de ciclos e não garantem encontrar todos os bugs), mas a experiência tem mostrado que aplicando-se um nível razoável de testes com dados simulados há a probabilidade de encontrarem-se bugs "interessantes", que devem vir a ser explorados como possíveis causadores de falhas na segurança.
5.3 Investimentos
O treinamento obrigatório em segurança constitui um investimento significativo para uma empresa com o número de engenheiros tão grande quanto o da Microsoft. O treinamento é realizado por meio de uma combinação de aulas "ao vivo" (ministradas por um instrutor) e material online. O material online é particularmente valioso como um veículo de divulgação do treinamento para pequenas equipes de engenheiros, em locais distantes da sede da Microsoft. O treinamento ao vivo mostrou-se particularmente eficaz quando ministrado a equipes que estavam se preparando para realizar verificações extras de segurança ou outras atividades de grande importância — nesses casos, a Microsoft acredita que o treinamento da equipe ocorre não apenas com o treinamento em classe, como também com a realização da verificação extra de segurança. O treinamento em segurança (que, em geral, dura meio dia) é estendido devido ao fato de todos estarem focalizados na segurança.
A equipe central de segurança (equipe de SWI) cresceu significativamente nos últimos anos, à medida que vem crescendo a ênfase da Microsoft em segurança. Por definição, a equipe é pequena, em relação ao número total de engenheiros da Microsoft, e enfatiza métodos "evolutivos" para garantir que a responsabilidade e os recursos para a produção de softwares mais seguros permaneçam com as equipes de produto. Algumas das táticas que refletem essa tendência em usar métodos evolutivos são a ênfase em treinamento e ferramentas, a nomeação de consultores de segurança que ajudam a equipe de produto a resolver seus próprios problemas (ao invés de resolver os problemas por ela) e o uso de análises (incluindo a FSR) para oferecer à equipe de produto o feedback sobre a adequação do software para o lançamento.
5.4 Resultados
O derradeiro teste do SDL é comprovar até que ponto ele remove e atenua brechas na segurança de softwares da Microsoft. A experiência — resumida na Seção 4 — demonstra que o SDL vem sendo até agora aprovado nesse teste. A Microsoft também avalia falhas na segurança relatadas externamente para constatar seus efeitos em versões de software em desenvolvimento. Alguns experimentos recentes têm mostrado que as medidas de segurança planejadas para novas versões ou implementadas nelas bloqueiam ataques que, em vários casos, se mostraram destrutivos em versões mais antigas. O recém-lançado Windows XP Service Pack 2 foi revisado dessa maneira, e as alterações de segurança que haviam sido planejadas, porém não ainda implementadas ou discutidas publicamente, provaram eliminar um número significativo de falhas na segurança em comparação com versões anteriores do Windows informadas por pesquisadores da área de segurança não pertencentes à Microsoft.
6. Conclusões
A Microsoft, por sua experiência, afirma que o SDL é eficaz na redução da incidência de falhas na segurança. A implementação inicial do SDL (no Windows Server 2003, SQL Server 2000 Service Pack 3 e Exchange 2000 Server Service Pack 3) resultou em melhorias significativas na segurança de softwares, e as versões subseqüentes desses softwares, como conseqüência dos aprimoramentos do SDL, mostram ainda mais melhorias na segurança.
A implementação gradativa dos elementos que compõem o SDL gerou melhorias gradativas, que são vistas como um indício de que o processo é eficaz. O processo não é perfeito e continua evoluindo — e não há previsões de que atingirá a perfeição ou deixará de evoluir em um futuro previsível.
O desenvolvimento e a implementação do Security Development Lifecycle representam um investimento de peso para a Microsoft e uma grande mudança no modo como os softwares são projetados, desenvolvidos e testados. A crescente importância de componentes de software para a sociedade enfatiza a necessidade de que a Microsoft e a indústria de informática como um todo continuem a melhorar a segurança de softwares; portanto, além deste artigo sobre o SDL, foram publicados livros sobre técnicas específicas (consulte as referências bibliográficas) com a intenção de dividir a experiência da Microsoft com toda a indústria de informática.
7. Agradecimentos
O desenvolvimento inicial deste artigo começou no fim de 2002, num esforço conjunto dos autores. Os rascunhos foram sendo atualizados à medida que o SDL evoluía, e a presente versão foi preparada ao longo da segunda metade de 2004. Os autores gostariam de agradecer a contribuição de Matt Thomlinson, Matt Lyons, Jamil Villani e Eric Bidstrup (todos membros da equipe de SWI, ou iniciativa para segurança do Windows, da Microsoft) na definição e ajuste final do SDL. Além destes, Scott Charney e Phil Reitinger (da Microsoft) e Jeannette Wing (da Carnegie Mellon University) forneceram comentários de grande utilidade nos rascunhos. Os autores também gostariam de agradecer a Martin Abadi, Virgil Gligor, Dick Kemmerer, Chris Mitchell, Fred Schneider, Neeraj Suri e James Whittaker pelos comentários e sugestões neste artigo.
8. Referências bibliográficas
Mundie, Craig,
Trustworthy Computing White Paper
Howard, Michael,
Attack Surface: Mitigate Security Risks by Minimizing the Code You Expose to Untrusted Users, MSDN Magazine, November 2004
Howard, Michael,
Expert Tips for Finding Security Defects in Your Code, MSDN Magazine, November 2003
Howard, Michael e David LeBlanc, Writing Secure Code, Second Edition, Microsoft Press, Redmond, Washington, 2003
Swiderski, Frank e Window Snyder, Threat Modeling, Microsoft Press, Redmond Washington, 2004
9. Avisos
As informações contidas neste documento representam o ponto de vista atual da Microsoft Corporation em relação aos temas abordados até a data da publicação. Como a Microsoft deve acompanhar as mudanças nas condições do mercado, isso não deve ser interpretado como um compromisso por parte da Microsoft, e a Microsoft não garante a veracidade de nenhuma informação apresentada após a data da publicação.
Este documento serve apenas para fins informativos. A MICROSOFT NÃO OFERECE QUALQUER GARANTIA, SEJA EXPRESSA, IMPLÍCITA OU LEGAL, QUANTO ÀS INFORMAÇÕES DESTE DOCUMENTO.
É responsabilidade do usuário obedecer a todas as normas de direitos autorais aplicáveis. Sem limitar os direitos protegidos sobre a lei de direitos autorais, nenhuma parte deste documento pode ser reproduzida, armazenada ou introduzida em um sistema de recuperação, ou transmitida sob qualquer forma ou meio (seja eletrônico, mecânico, por fotocópia, gravação ou outro) ou para qualquer objetivo sem a permissão expressa por escrito da Microsoft Corporation.
A Microsoft se reserva o direito de ter patentes, aplicativos patenteados, marcas comerciais, direitos autorais ou outros direitos de propriedade intelectual protegendo algum assunto tratado neste documento. Exceto se determinado expressamente em algum acordo de licença escrito pela Microsoft, o fornecimento deste documento não concede nenhuma licença sobre essas patentes, marcas comerciais, direitos autorais ou outra propriedade intelectual.
© 2005 Microsoft Corporation. Todos os direitos reservados. Algumas partes deste artigo foram extraídas do © 2004 Institute of Electrical and Electronics Engineers, Incorporated. Todos os direitos reservados.
Microsoft, MSDN, Windows e Windows Server são marcas registradas ou marcas comerciais da Microsoft Corporation nos Estados Unidos e/ou em outros países.