A melhor maneira de desenvolver software seguro incorporar a segurana desde o incio do desenvolvimento de software.

. O desenvolvedor deve conhecer as vulnerabilidades em diferentes artefatos do ciclo de vida do desenvolvimento do software para que estes possam ser removidos assim que possvel. Caso contrrio, a remoo as vulnerabilidades, numa fase posterior ir aumentar o custo significativamente. Vulnerabilidades em software nos afetam quase diariamente, nos foraram a mudar a forma como usamos computadores, alm de ser o centro de algumas das mais espetaculares e caras falhas em computadores. Por exemplo, o custo total do vrus Code Red foi estimado em 2.6 bilhes de dlares, e o vrus Nachi afetou operaes da companhia area do Canad e da CSX ferrovias. Os dois exploraram buffer overflows, uma classe de vulnerabilidades que conhecida desde 1988. Esforos esto comeando a reduzir as vulnerabilidades em software, mas a indstria certamente ainda tem um longo caminho a percorre. O BSI busca alterar o caminho com o qual o software desenvolvido, tendo assim menores vulnerabilidades de ataques atravs da construo de segurana desde inicio do desenvolvimento do projeto. O SSDP est dividido em quatro fases: Engenharia de Requisitos; Design; Implementao; Garantia. Cada uma dessas fases est dividida em uma seqncia de atividades que devem ser seguidas, alm do relacionamento entre as fases. Requisitos A necessidade de considerar a segurana "de baixo para cima" um princpio fundamental do desenvolvimento de sistemas seguros. Embora vrios projetos de desenvolvimento produzam "prximas verses" baseadas nas verses anteriores, a fase de requisitos e o planejamento inicial de uma nova verso oferecem a melhor oportunidade para criar software seguro. Durante a fase de requisitos, a equipe de produto entra em contato com a equipe de segurana central para solicitar a designao de um supervisor de segurana (chamado de o "cara da segurana" na implementao) que serve como um ponto de contato, pesquisa e orientao durante o planejamento. O supervisor de segurana ajuda a equipe de produto revisando os planos, fazendo recomendaes e garantindo que a equipe de segurana planeje recursos apropriados para dar suporte ao cronograma da equipe de produto. O supervisor de segurana aconselha a equipe de produto sobre os marcos de segurana e os critrios de sada que sero exigidos com base no tamanho, na complexidade e no risco do projeto. O supervisor de segurana continua sendo o ponto de contato da equipe de produto com a equipe de segurana, desde o incio do projeto at a concluso da Reviso final de segurana e o lanamento do software. O supervisor de segurana tambm serve como ponto de contato entre a equipe de segurana e a gerncia da equipe de produto, e aconselha a gerncia da equipe quanto ao controle do elemento de segurana de seus projetos, de forma a evitar surpresas relacionadas segurana posteriormente durante o processo. A fase de requisitos a oportunidade para a equipe de produto considerar como a segurana ser integrada no processo de desenvolvimento, identificar os objetivoschave de segurana e maximizar a segurana de software, minimizando a quebra de planos e cronogramas. Como parte desse processo, a equipe precisa considerar como os recursos de segurana e as medidas de controle de seu software sero integrados com outros softwares que provavelmente sero usados com ele. (A interface com outros softwares uma considerao essencial para atender s necessidades dos usurios de integrao de produtosindividuais em sistemas seguros.) A perspectiva

geral da equipe de produto sobre os objetivos, os desafios e os planos de segurana deve se refletir nos documentos de planejamento produzidos durante a fase de requisitos. Embora os planos estejam sujeitos a alteraes conforme o andamento do projeto, a articulao 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 segurana como parte dessa fase. Embora alguns requisitos de recursos de segurana sejam identificados em resposta modelagem de ameaas, provvel que os requisitos do usurio determinem a incluso de recursos de segurana em resposta s exigncias do cliente. Os requisitos dos recursos de segurana tambm sero definidos de acordo com a necessidade de obedecer aos padres da indstria e dos processos de certificao, como os Critrios comuns. A equipe de produto deve reconhecer e refletir esses requisitos como parte de seu processo de planejamento normal. Anlise/ Projetos o estudo dos objetivos do sistema como um todo, dos procedimentos que o envolvem, da sua estrutura, dos fluxos de informao que estabelece o seu desempenho e as suas deficincias. Atividades da Analise do Sistema: Uma vez compreendido como um sistema interage com os outros, o analista deve preocupar-se com o sistema em si. Identificar cada um dos seus componentes, examinandoos com cuidado de forma a levantar todos os detalhes respeitantes sua natureza, funcionamento e relao com outros componentes. Etapas necessrias para identificao: 1. Determinao dos Objetivos: Antes de qualquer anlise necessrio estabelecer uma base para decidir o que se pretende que o sistema faa tendo em conta os objetivos de cada um dos setores da organizao. Com estes objetivos e as relaes entre departamentos, pode-se estabelecer os objetivos do sistema como um todo. 2. Levantamento de informaes sobre os mtodos utilizados: Antes de se tirar concluses sobre os problemas ou deficincias do sistema pr-existente, deve-se compreender e documentar todos os fatos relacionados execuo dos procedimentos, manuteno das informaes e ao processo de tomada de deciso. 3. Anlise das inter-relaes: Os dados encontrados devem agora ser organizados, analisados e comparados com os de sistemas similares, de forma a serem facilmente entendidos. Os fatores crticos para o desempenho da organizao vo ser identificados e passar a merecer toda a ateno. 4. Determinao dos dados necessrios: Determinar a melhor disposio do fluxo de informao. Quem precisa de qual informao? Quem fornece os dados? Quem processa os dados e obtm os resultados? Fazer por qu?

5. Definio dos procedimentos necessrios: So propostas vrias alternativas pelas quais os processos poderiam ser realizados; um ou mais cursos de ao devem ser apresentados. 6. Ferramentas para a Anlise de Sistemas: Para se fazer uma anlise necessria se recorrer utilizao de ferramentas e tcnicas prprias, de forma a garantir a obteno de dados completos e acertados de modo a que se possa chegar aconcluses corretas. Implementao A fase de implementao, a equipe de produto gera o cdigo, testa e integra o software. As etapas seguidas para remover falhas de segurana ou evitar sua insero inicial durante essa fase tm um aproveitamento alto; elas reduzem significativamente a probabilidade de que vulnerabilidades de segurana estejam presentes na verso final do software que lanada para os clientes. Os resultados da modelagem de ameaas fornecem uma orientao particularmente importante durante a fase de implementao. Os desenvolvedores dedicam ateno especial em corrigir o cdigo de modo a atenuarem as ameaas de alta prioridade e os testadores concentram seus testes na garantia de que essas ameaas estejam de fato bloqueadas ou atenuadas. Os elementos do SDL que so aplicados na fase de implementao so: Aplicar padres de codificao e teste. Os padres de codificao ajudam os desenvolvedores a evitar a introduo de falhas que podem levar a vulnerabilidades de segurana. Por exemplo, a utilizao de construes de manipulao de seqncias e de buffer mais consistentes e seguras pode ajudar a evitar a introduo de vulnerabilidades de saturao do buffer. As prticas recomendadas e os padres de testes ajudam a garantir que os testes se concentrem na deteco de possveis vulnerabilidades de segurana e no apenas na operao correta de funes e recursos do software. Aplicar ferramentas de testes de segurana, incluindo ferramentas de difuso. A "difuso" oferece entradas estruturadas, mas invlidas para APIs (interfaces de programao 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 verificao de cdigo de anlise esttica. As ferramentas podem detectar alguns tipos de falhas de cdigo que resultam em vulnerabilidades, incluindo saturaes do buffer, de nmeros inteiros e variveis no inicializadas. Realizar revises de cdigo. As revises de cdigo complementam os testes e as ferramentas automatizadas; para isso, elas aplicam os esforos de desenvolvedores treinados no examine do cdigo-fonte e na deteco e remoo de possveis vulnerabilidades de segurana. Elas so uma etapa essencial no processo de remoo de vulnerabilidades de segurana do software durante o processo de desenvolvimento. Teste O teste tambm conhecido como fase de verificao o ponto em que o software est funcionalmente concludo e entra em testes beta por usurios. Durante essa fase, enquanto o software passa por testes beta, a equipe de produto realiza um "esforo de segurana" que inclui revises do cdigo de segurana alm das concludas na fase de implementao, bem como testes de segurana direcionados.

Houve dois motivos para a introduo do esforo de segurana no processo: O ciclo de vida do software para as verses em questo alcanou a fase de verificao, e essa fase estava em um ponto apropriado para realizar as revises de cdigo e os testes orientados necessrios. Realizar o esforo de segurana durante a fase de verificao garante que a reviso de cdigo e os testes tenham como objetivo a verso final do software, e oferece uma oportunidade para revisar o cdigo desenvolvido ou atualizado durante a fase de implementao e o "cdigo herdado" que no foi modificado. O primeiro desses motivos reflete um acidente histrico: a deciso de iniciar um esforo de segurana ocorreu inicialmente durante a fase de verificao. Onde foi possvel concluir que realizar um esforo de segurana durante a fase de verificao realmente uma prtica recomendada para garantir que o software final preencha os requisitos e permitir uma reviso mais profunda do cdigo herdado que tenha sido transferido de verses anteriores do software. importante notar que as revises de cdigo e os testes do cdigo de alta prioridade (aquele que parte da "superfcie de ataque" do software) so crticos para vrias partes do SDL. Por exemplo, essas revises e esses testes devem ser exigidos na fase de implementao para permitir a correo precoce de quaisquer problemas, alm da identificao e da correo da origem desses problemas. Eles tambm so crticos na fase de verificao, quando o produto est perto de ser concludo. Manuteno Apesar da aplicao do SDL durante o desenvolvimento, as prticas de desenvolvimento mais avanadas ainda no do 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 vulnervel. Assim, as equipes de produto devem se preparar para responder a vulnerabilidades recm-descobertas no software fornecido aos clientes. Parte do processo de resposta envolve a preparao para avaliar relatrios de vulnerabilidades e lanar orientaes e atualizaes de segurana quando apropriado. O outro componente do processo de resposta a conduo de um post-mortem das vulnerabilidades relatadas e a adoo de medidas, conforme necessrio. As medidas em resposta a uma vulnerabilidade variam de emitir uma atualizao para um erro isolado at atualizar as ferramentas de verificao de cdigo e iniciar revises do cdigo dos principais subsistemas. O objetivo durante a fase de resposta aprender a partir dos erros e utilizar as informaes fornecidas em relatrios 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 tambm ajuda a equipe de produto e a equipe de segurana a adaptar processos de forma que erros semelhantes no sejam introduzidos no futuro. O investimento em segurana no desenvolvimento uma viagem obrigatria, com apenas estao de partida, que toda organizao, cujo negcio software, se ainda no entrou, ter que entrar. Essa obrigatoriedade est ligada curva crescente de perdas causadas por explorao de falhas de segurana. Essa viagem est obviamente muito mais avanada nos EUA e pases, cujo rigor com questes de segurana maior. No Brasil, por exemplo, a onde de busca solues de segurana para atender o padro PCI (Payment Card Industry), mais especificamente parece ainda nem ter comeado. Algumas alternativas para segurana de ciclo de desenvolvimento, como anlise esttica de cdigo, firewall de aplicao sairo do status de recomendao PCI para obrigatrio em julho/08.

O mercad americano mostra boas perspectivas acerca dessas mudanas de mentalidade, basta observar os movimentos das empresas, como por exemplo, a integrao entre Sentinel (Scan) da WhiteHar com o Ounce5 (Source Code Analyzer) da Ounce Labs e outros. Obviamente, eles esto prevendo alta demanda caminho. Voltando questo do negcio em si, hoje as organizaes (pelo menos as grandes) j reconhecem a importncia de desenvolver software com segurana desde o princpio, e que o custo dessa alternativa , sem dvida, menor que os custos associdos incerteza sobre o nvel de segurana do produto final. Essa percepo sobre o nvel de segurana diretamente influenciada pelas evidncias de aes de segurana recolhidas ao longo do desenvolvimento. Cita-se, como exemplo, os touch points da Cigital. No h outro elemento mais importante na segurana do que o recurso humano quer seja no desenvolvimento ou na operao. Acontece, que as instituies de ensino em geral, continuam a no dar tanta importncia ao assunto de software seguro. Quem paga a conta est comeando a agir para mitigar esse problema. Como? Solicitando oficialmente s universidades para que ensinem seus alunos como desenvolver com segurana. Para finalizar, fica destacado que a segurana no desenvolvimento no deve ser o objetivo de negcio de nenhuma organizao (exceto quelas onde esse o negcio em si), mas que seu resultado pode suportar ou no os objetivos de negcio dela. Com essa mentalidade, a resistncia a embarcar dessa viagem passa a ser dirigida pela anlise de risco e custo da oportunidade. Estouro de Buffer Estouro de buffer a forma de ataque baseado na explorao do mal uso de funes que manipulam arrays. Esta vulnerabilidade pode estar presente em linguagens que no verificam automaticamente se os limites de memria alocada para uma varivel foram respeitados durante a execuo do programa. Stack-Smashing Protector (SSP) uma das ferramentas mais utilizadas atualmente para impedir ou dificultar a explorao de estouros de buffer para a linguagem C. Sistemas operacionais modernos o utilizam como ferramenta padro para evitar brechas de segurana em programas copilados em seu domnio. Normalmente, o ataque consiste na descoberta de algum parmetro de entrada vulnervel de um sistema que possa ser manipulado de tal forma que permita a injeo de comandos de mquinas maliciosos. Tais comandos, se bem formulados, podem ser usados para comprometer a mquina hospedeira de tal forma que o atacante receba privilgios no antes alcanveis. Em qualquer situao a vulnerabilidade pode ser evitada com boa praticas de programao. O mal uso de funes que trabalham com arrays a principal causadora de brechas na segurana de um sistema. Funes tais que permitam a escrita de um dado em memria alem dos limites estabelecidos pelo o compilador devem ser usadas com um cuidado especial, pois podem estar inserindo vulnerabilidade passiveis de explorao. Aps ter sido tornada pblica a tcnica de buffer overflow por alephone (1998), diversos mtodos surgiram para automaticamente evitar que a explorao fosse executada com sucesso. Solues foram apresentadas tanto para os compiladores como para os sistemas operacionais, visando dificultar ao mximo o uso dessas falhas para maus fins. Porm, no existe atualmente uma tcnica definitiva que evite a explorao dos estouros de buffer sem adicionar overhead significativo ao programa definido. Dentre as tcnicas em compiladores existentes para proteo de cdigo escrito em C, destaca-se o Stack-Smashing Protector (ou SSP, ou ainda Pro Police). Desenvolvido por Hiroaki Etoh, ele uma evoluo do conceito apresentado no Stack Guard por Crispin Cowan. Atualmente, o mtodo padro em diversos sistemas operacionais conhecidos, como Ubuntu e OpensBSD, ele se demonstra muito eficiente em impedir a explorao de buffer overflows.