Instituto Federal de Alagoas - IFAL Curso de Sistemas de Informao Disciplina Gesto de Segurana de Informao

Segurana Relacionada ao Desenvolvimento de Software

Macei, 6 de maio de 2012.

Ezequiel Batista Leandro Wanderley Tibrio Padilha

Segurana Relacionada ao Desenvolvimento de Software

Trabalho realizado como requisito avaliativo para a disciplina Gesto de Segurana de Informao orientada pelo Professor Ricardo Rubens.

Macei, 6 de maio de 2012.

Sumrio

1. Introduo ----------------------------------------------------------------------------- 04

2. Processo Seguro de Desenvolvimento de Software------------------------- 05 2.1. Primeira proposta de um Processo Seguro de Desenvolvimento de Software--------------------------------------------------------------------------------------06 2.2. Segunda proposta de um Processo Seguro de Desenvolvimento de Software--------------------------------------------------------------------------------------08

3. Custo de Softwares Seguros--------------------------------------------------------12

4. Benefcio do Software Seguro------------------------------------------------------13

5. Calculo dos Custos e Benefcios---------------------------------------------------15 6. Calculo dos Custos de Segurana-------------------------------------------------18 7. Desvantagens---------------------------------------------------------------------------18 8. Tendncias-------------------------------------------------------------------------------19

9. Concluso--------------------------------------------------------------------------------21

10. Referencias Bibliogrficas----------------------------------------------------------22

1. INTRODUO essencial que todos os fornecedores de software abordem as ameaas segurana. A segurana um requisito fundamental para fornecedores de software, e ela influenciada pelas presses do mercado, pela necessidade de proteger infraestruturas crticas e pela necessidade de criar e preservar uma confiana geral no ambiente de computao. Um desafio importante para todos os fornecedores de software a criao de software mais seguro, que precise de menos atualizaes atravs de patches e possibilite um gerenciamento de segurana com menos problemas. Esse trabalho aborda primeiramente o motivo da implementao desses processos pelas organizaes, descreve dois processos seguros de desenvolvimento de softwares e logo aps faz uma analise das vantagens, desvantagens, custo e tendncias relacionadas a esses processos.

2. PROCESSO SEGURO DE DESENVOLVIMENTO DE SOFTWARE A constante procura por automatizao de processos acabou gerando uma produo massificada de softwares sem uma preocupao adequada com a segurana da informao, isso gerou inmeros transtornos para as organizaes que tiveram que pensar em alternativas para lidar com essa problemtica. Surgiu ento necessidade do desenvolvimento de produtos de software com maior qualidade relacionado segurana, o que exigiu a criao de modelos e normas internacionais voltados para qualidade do processo de desenvolvimento e de produtos de software. Esses processos so baseados no somente na aplicao das teorias existentes como na adoo de um processo de desenvolvimento que considere os requisitos de segurana como parte integral do projeto de construo de software. Neste contexto, a utilizao de padres de projeto de segurana e de uma abordagem orientada a modelos pode auxiliar arquitetos e projetistas a construir sistemas seguro. As preocupaes bsicas quando se fala de segurana em desenvolvimento de software so: (i) Segurana do sistema a ser desenvolvido; e (ii) Assegurar que a segurana da aplicao foi conseguida aps seu desenvolvimento. Com a crescente preocupao com a segurana de informao muitos estudiosos voltaram ateno para a segurana em desenvolvimento de software, e comum encontrarmos solues e ferramentas que tentam implementar segurana aps a concluso do software, as chamadas out of the box. Esses tipos de ferramenta dificilmente funcionaro. Para produo de um software seguro necessrio desde o incio do processo se adotar mtodos que garantam a qualidade durante todas as etapas do desenvolvimento. Mas para inserir um bom nvel de segurana em seu software preciso analisar o seu processo de desenvolvimento. Segundo dados analisados, quase unanime, que existe problemas de segurana e que eles so ocasionados por softwares ruins. Isso significa que uma m gesto no processo de desenvolvimento de software pode levar a um cdigo mal estruturado e por sua vez a problemas de segurana. Por outro lado, podemos que um software de qualidade desenvolvido com uma abordagem estruturada e ferramentas de apoio. Portanto podemos medir se um software ser seguro a partir do seu processo de desenvolvimento. Como voc gerencia o seu cdigo fonte? Quais os tipos de testes usados? Como feita a correo dos bugs? Existe algum processo de acompanhamento para evitar bugs durante a produo? Voc documenta o software desenvolvido e os requisitos mnimos para o seu funcionamento? Como descobrir os requisitos de segurana da aplicao e especificar as necessidades de segurana do cliente? Como mapear os requisitos de segurana em especificaes do sistema? Como projetar e implementar essas especificaes? Como testar validando a segurana do sistema? Essas perguntas podem servir como base para analisar se seu software ser ou no desenvolvido com a segurana mnima necessria. Para isso preciso ter um controle da verso do software assim como as mudanas efetuadas em cada etapa do desenvolvimento, adotar prticas que buscam avaliar o software como todo e tambm em partes dele, manter um registro das falhas que j aconteceram facilitando assim o entendimento de falhas futuras e uma

documentao clara da arquitetura e cdigo fonte ajuda a aumentar a qualidade do software desenvolvido e de fundamental importncia para que o software possa ser expandido de forma sustentvel e segura. H muitas recomendaes sobre prticas para melhorar segurana e sobre programao segura. Provavelmente, uma vez que se pratiquem tais recomendaes, muitas falhas de segurana nos sistemas podem ser eliminadas. Assegurar a segurana da aplicao no envolve apenas elaborar um sistema mais seguro, mas tambm permitir que os clientes e envolvidos se convenam disto. Portanto, importante a participao do cliente e do usurio na definio de cada atributo de segurana. Uma maneira de demonstrar a segurana do sistema para o cliente atravs de testes. Assim, o cliente e demais envolvidos podem acompanhar os testes realizados pela equipe interna ou equipe independente, bem como verificar seus resultados.

2.1 Primeira proposta de um Processo Seguro de Desenvolvimento de Software (PSDS) Atualmente, preocupadas com a segurana dos seus softwares, varias empresas criam ou simplesmente adotam seus processos e/ou modelos que iro ajudar na implementao da segurana no desenvolvimento de seus produtos. Para essa proposta podemos definir 10 pontos chave para o processo seguro de desenvolvimento em um software, so eles: 01 Gestores de processos de negcio e diretivas de alto nvel; 02 Time de segurana em desenvolvimento; 03 Cultura e estrutura de segurana; 04 Treinamento e capacitao; 05 Reutilizao de componentes; 06 Padres de cdigos seguros e checklits; 07 Modelo de avaliao de riscos 08 Reviso de segurana; 09 Ferramentas para testes; 10 Implementao do software. Vamos entender cada um dos passos em mais detalhes. 1Gestores de processos de negcio e diretivas de alto nvel

A iniciativa de segurana em desenvolvimento ir mudar os processos de desenvolvimento de software e de certa forma travar o modelo j estabelecido entre gestores do negcio e equipe de desenvolvimento. Por isso, uma modificao de

cultura necessria para que esta iniciativa seja aceita pelo alto nvel da organizao. Um processo que deve se conduzido por profissionais que tenham viso do negcio como um todo e um bom relacionamento com os membros de desenvolvimento e gerentes do negcio. 2- Time de Segurana em Desenvolvimento necessrio estabelecer um time que ir conduzir as atividades de segurana em desenvolvimento, como: testadores, revisores, responsveis por polticas e mtricas e orientadores. importante notar que estes profissionais devem ser identificados no time de desenvolvimento e/ou contratados com estes perfis. Um comum recorrente a profissionais de reas relacionadas segurana, sem perfil de engenharia de software para ocupar as vagas referentes s necessidades citadas. 3Cultura e estrutura de segurana

Estudando prticas como as sugeridas pela OWASP (Open Web Application Security Project) e estabelecendo uma cultura de segurana na organizao, defina metas, desenvolva documentao prescritiva e defina os papis e responsabilidades dos envolvidos no sistema de desenvolvimento. 4- Treinamento e Capacitao Com o processo iniciado e apoio da organizao preciso treinar os envolvidos e desenvolver materiais e recursos para que os profissionais se mantenham conscientes sobre a necessidade de segurana e sejam informados sobre fontes de pesquisa no tema. 5Reutilizao de Componentes

Construa e homologue componentes de cdigo e arquitetura que possam vir a ser adotados como padro na organizao. Modelos como o ESAPI (Enterprise Security API) da OWASP podem ser adotados evitando que cdigos com problemas de segurana e componentes inseguros sejam adotados. 6- Padres de cdigos seguros e checklits Defina padres de cdigos seguros, boas prticas de acordo com a linguagem adotada e ambiente definido pela organizao. Crie checklists (passo a passo) para verificar as principais atividades durante o desenvolvimento e reviso de segurana do software.

7-

Modelo de Avaliao de Riscos

Defina um processo para avaliar os riscos associados aos softwares desenvolvidos e como os riscos identificados sero tratados. Este processo deve estar associado a um processo de gesto de vulnerabilidades e resposta a incidentes. 8- Reviso de Segurana Defina processo de reviso de segurana e testes que iro verificar se existem problemas de segurana que ainda no foram avaliados. Os problemas identificados devem ser tratados e documentados no processo de Bug Tracking, atravs do processo de gesto de vulnerabilidades. Modelos como o OWASP Testing Guide e OWASP Code Review Guide podem ser adotados como referncia. 9- Ferramentas para Teste Uma maneira de demonstrar a segurana do sistema para o cliente atravs de testes. Assim, o cliente e demais envolvidos podem acompanhar os testes realizados pela equipe interna ou equipe independente, bem como verificar seus resultados. Adote e/ou crie ferramentas para testar as caractersticas especficas dos softwares desenvolvidos. Essas ferramentas devem evoluir de acordo os as documentaes produzidas pelas revises de segurana. Evite ferramentas que propem modelos baseados em padres conhecidos e no permitem que sejam aprimoradas e orientadas para a organizao. Frameworks como o O2 Platform da OWASP se adaptam e evoluem com a sua equipe de teste medida que o seu software vai sendo desenvolvido. 10- Implantao de Software Aps a adoo de todo o processo necessrio colocar o software em produo. Aps ir para produo, falhas podem aparecer e um processo claro de resposta a incidentes deve estar estabelecido. Eventuais problemas de segurana devem ser tratados sem que causem grandes problemas aos usurios e a organizao. Tcnicas de programao e de engenharia de software mudam e evoluem mais rapidamente do que as tcnicas de segurana de computador.

2.2 Segunda proposta de um Processo Seguro de Desenvolvimento de Software (PSDS) O segundo processo proposto foi dividido em 11 etapas que so elas: 01 Planejamento da Segurana.; 02 Avaliar Vulnerabilidade de Segurana;

03 Modelar Ameaa de Segurana; 04 Avaliar Impacto de Segurana; 05 Avaliar Risco de Segurana; 06 Especificar Necessidades de Segurana; 07 Fornecer Informao de Segurana; 08 Verificar e Validar Segurana; 09 Gerenciar Segurana; 10 Monitorar Comportamento de Segurana; 11- Garantir a Segurana.

Vamos entender cada um dos passos em mais detalhes.

1-

Planejamento da Segurana.

Etapa que tem como objetivo garantir que todas as informaes necessrias para o planejamento da segurana do projeto sejam estabelecidas e registradas no processo seguro para o projeto. Deve-se verificar metas e planos de segurana, definindo os objetivos do processo. Nessa etapa que h a formalizao do grupo de engenharia, definindo sua estrutura e as atribuies de cada membro do projeto. Trs atividades so implementadas nessa etapa que consta em definir objetivos de planejamento de segurana e identificar seus mecanismos; atribuir responsabilidades de segurana no projeto; implementar ambiente de processos; e planejar o gerenciamento de incidentes de segurana. a partir das metas e dos planos de segurana que os engenheiros de segurana e de software planejam as atividades que sero executadas no projeto, eles constroem o cronograma dessas atividades, instanciando o processo seguro para o projeto. So eles tambm que orientam todos os integrantes do projeto a respeito dos padres de qualidade e das praticas de engenharia de software que compem o projeto. 2Avaliar Vulnerabilidade de Segurana

O propsito dessa etapa identificar e caracterizar as vulnerabilidades de segurana do sistema em relao ao ambiente definido, segundo o processo seguro atravs dos objetivos de segurana elencados para o projeto. Os ativos de informao do sistema a ser desenvolvido so essenciais, sendo selecionados os mais crticos para o desempenho do negcio.

Nessa etapa devero ser executados os mtodos de identificao de vulnerabilidades de segurana e a analise das vulnerabilidades de segurana identificadas. 3Modelar Ameaa de Segurana

nessa etapa onde so identificadas e caracterizadas as ameaas de segurana, juntamente com suas propriedades e caractersticas. A partir da lista de vulnerabilidades, que o principal produto resultante da etapa anterior so avaliadas todas as ameaas levantadas, para que o engenheiro de segurana entenda as ameaas relacionadas s vulnerabilidades identificadas, isto , ameaas potenciais que podem aparecer ao colocar o produto em funcionamento. necessrio que sejam identificadas as ameaas de segurana aos ativos crticos e desenvolvidas estratgias que reduzam as ameaas de seguras. 4Avaliar Impacto de Segurana

Tem como proposito de identificar e caracterizar impactos que sejam relevantes com respeito ao sistema e avaliar a possibilidade da ocorrncia desses impactos. Os impactos podem ser tangveis, como prejuzos financeiros, ou intangveis, como perda de reputao. Entende-se impacto como sendo a consequncia de um incidente no desejado, causado tanto deliberado quanto acidentalmente, e que afeta os ativos. As consequncias podem envolver a destruio ou dano destes ativos, ou mesmo perda de confidencialidade, integridade, ou disponibilidade. Nessa etapa devem ser priorizados os processos crticos influenciados pelo sistema, revisados os ativos que se referem a segurana e feito a identificao e descrio dos impactos de segurana. 5Avaliar Risco de Segurana

De posse das informaes de vulnerabilidade, ameaa e impacto da iterao, tem se a necessidade de avaliar os riscos inerentes do prottipo do sistema em desenvolvimento pela identificao da exposio de segurana, o risco dessa exposio, e a priorizao desses riscos. Tendo como foco o descobrimento dos riscos de segurana envolvidos com o sistema em um ambiente definido, baseado em um entendimento estabelecido de como os ativos so vulnerveis s ameaas. Nessa etapa necessrio identificar a exposio, avaliar e priorizar os riscos de segurana. 6Especificar Necessidades de Segurana

O propsito desta etapa especificar as necessidades relacionadas com segurana para o prottipo do sistema, na iterao, entre todos os envolvidos, principalmente o usurio. Envolve definir as bases para segurana no sistema de modo a satisfazer todos os requisitos legais e organizacionais para segurana. Essas

necessidades se baseiam no contexto de segurana operacional do sistema, no atual ambiente de segurana e sistema da organizao. aqui que se deve compreender as necessidades de segurana do cliente, capturar uma viso de alto nvel orientada segurana da operao do sistema, definir requisitos de segurana e obter acordo sobre requisitos de segurana. 7Fornecer Informao de Segurana

O propsito desta etapa prover aos arquitetos de sistema, projetistas, implementadores, ou usurios a informao de segurana de que necessitam. Essa informao inclui arquitetura segura, projeto, ou alternativas de implementao e orientao de segurana, procurando garantir que todos os problemas do sistema so revisados em relao a implicaes de segurana e so resolvidos de acordo com objetivos de segurana; que todos os membros da equipe de projeto compreendem segurana e, por conseguinte, podem realizar suas funes; e que a soluo reflete a informao de segurana fornecida. Nessa etapa tem-se a necessidade de entender e revisar necessidades de informao de segurana, determinar consideraes e restries de segurana, identificar e analisar alternativas de segurana, fornecer orientao de segurana, e identificar e revisar requisitos de garantia de segurana. 8Verificar e Validar Segurana

O propsito desta etapa garantir que as solues sejam verificadas e validadas com respeito segurana. Procura garantir que: solues sejam verificadas em relao aos requisitos de segurana, arquitetura e projeto, usando observao, demonstrao, anlise e teste; e solues so validadas em relao s necessidades de segurana do cliente. Assim sendo, as metas dessa atividade incluem que as solues, de fato, implementem de maneira adequada e eficaz os requisitos de segurana, e que as solues satisfaam as necessidades de segurana do cliente. nessa etapa que se defini a abordagem de verificao e validao de segurana; realiza verificao de segurana; realiza validao de segurana; revisa e comunica resultados de verificao; e valida segurana. 9Gerenciar Segurana

O propsito desta etapa tratar das tarefas necessrias para administrar e manter os mecanismos de controle de segurana para o ambiente de desenvolvimento e um sistema operacional, bem como gerenciar a implantao de controles para novas funcionalidades, que se integram com os controles existentes. Define tambm como ser o gerenciamento da segurana, envolvendo a definio de treinamentos e programas de educao de segurana necessrios. nessa etapa que so gerenciados e controlados servios e componentes operacionais de segurana; gerenciados percepo, treinamento e programa de educao de segurana; e gerenciada a implementao de controles de segurana.

10- Monitorar Comportamento de Segurana O propsito desta etapa garantir que a segurana, que foi prevista para o projeto, seja conseguida pelo sistema resultante em seu estado operacional. Isso alcanado pela garantia de que as deficincias ou erros que poderiam conduzir a uma brecha de segurana sejam monitorados e, por conseguinte, identificados, reportados e acompanhados at suas correes. Os ambientes externo e interno devem ser monitorados em relao aos fatores que podem ter um impacto na segurana do sistema. Alm disso, a monitorao deve auxiliar garantir que o nvel de segurana no se deteriore. nessa etapa que so analisados os registros de evento com impacto na segurana; preparada a resposta aos incidentes de segurana relevantes; monitoradas mudanas em ameaas, vulnerabilidades, impactos, riscos, no ambiente, e em suas caractersticas; reavaliadas as mudanas em ameaas, vulnerabilidades, impactos, riscos e no ambiente; revisado o comportamento de segurana do sistema para identificar mudanas necessrias; e realizada auditorias de segurana.

11- Garantir Segurana O propsito desta etapa definir um conjunto de atividades que podem ser aplicadas, para garantir que a segurana do produto seja mantida. A garantia da segurana deve assegurar que controles de segurana eficazes sejam definidos e implementados para proteger dados e operaes crticas. nessa etapa que definida a estratgia de manuteno da garantia de segurana; e conduzida a anlise de impacto de segurana das mudanas. 3. CUSTO DE SOFTWARES SEGUROS Os principais empecilhos para calcular o custo do desenvolvimento de softwares seguros incidem na ausncia de dados precisos, falta de acordo com relao os critrios de medio, e o foco relativamente recente em matria de segurana. Entretanto tem havido um trabalho expressivo sobre a quantificao e estimao do custo de desenvolvimento de softwares. Alguns dos primeiros esforos basearam-se no modelo chamado de COCOMO (Constructive Cost Model). Este modelo foi revisto significativamente, e vrios outros modelos para avaliao do esforo e a durao do desenvolvimento de software tm sido sugeridos e executados pelas organizaes. Uma forma de se refletir sobre o custo da segurana pensar segurana em termos de qualidade. Existem alguns achados bibliogrficos relacionados engenharia de software que dedicam-se a estimar o custo da qualidade de software. Geralmente, os benefcios da qualidade de software esto relacionados com o melhor design, mais testes, e inspeo, os quais abalam significativamente os custos. Sendo que estes benefcios so bem maiores que os custos envolvidos. Os custos da melhor qualidade devem ser divididos baseados na conformidade e no-conformidade. A conformidade seria conceituada como a capacidade de atingir a qualidade desejada. Para se alcanar a qualidade desejada necessrio: A Eliminar a fonte que causa defeitos (atravs de melhoria nos treinamentos, reunies para discutir a melhoria da qualidade do projeto, etc).

B - Eliminar os defeitos atravs da avaliao e auditoria do produto (inspeo do cdigo, testes, software para medio das atividades, etc). Uma vez seguidos estes passos os pesquisadores podero ento dar valores ao retorno de investimento voltado para a melhoria da qualidade usando dados de empresa e mostrando que este ROI positivo e significativo. Lamentavelmente, a elaborao e qualquer tipo de execuo de mtricas de custos que visem qualidade de software bastante difcil, pois estas medidas tendem a ser usadas apenas em um ou outro produto especfico, ou tecnologia especfica, sendo portanto, difceis de generalizar. Outros trabalhos relacionados a problemtica mostram que ter pessoal melhor preparado, utilizao de ferramentas CASE, e mais investimentos frente a concepo, planejamento, etc tendem a melhorar a qualidade do produto. Esta mesma demonstrao de quantificao da qualidade de software pode ser aplicada para a abordagem de segurana tambm. O que todos estes estudos implicitamente assumem que mais qualidade meramente reduz o nmero de erros, mas no afeta o tamanho do produto, nem a complexidade do mesmo, ou seja, para se conseguir uma boa qualidade no necessrio acrescentar mais linhas de cdigo. Se considerarmos que a incorporao de mais segurana no produto relacionado a qualidade do mesmo, poderemos usar as mtricas propostas anteriormente para medir o custo de segurana. Entretanto a segurana em potencial incorporada ao processo acaba afetando o design do produto mais efetivamente do que a integrao de qualidade, ou seja, fazendo-se um produto mais seguro pode significar maior complexidade no produto, maior tamanho e mais funcionalidades no produto. Assim pode-se ocorrer custos adicionais ao design do produto que podem estar acima e alm dos custos de conformidade, como o custo de treinamento, o custo de ferramentas CASE, etc. 4. BENEFICIOS DO SOFTWARE SEGURO Para compreendermos melhor os benefcios de softwares seguros, precisamos nos ater nos trabalhos que descrevem mtodos e modelos de apoio tomada de deciso sobre investimentos em segurana da informao a partir da perspectiva do usurio, ou seja, a partir da perspectiva de uma organizao de TI, que deseja proteger-se contra ataque de cibercriminosos. Esta abordagem justificada pelo fato do desenvolvimento de software seguro ser uma forma de investir em segurana da informao. A abordagem adotada aqui voltada para o contexto de desenvolvimento de software, aplicada ao problema de avaliar o retorno de investimento em prticas de desenvolvimento seguro de software. Em particular, os benefcios so avaliados atravs do valor financeiro de perdas evitado resultante das prticas de desenvolvimento seguro de software. A diferena em relao aos estudos realizados nesta rea reside na forma como cada um procura mensurar as perdas evitadas. Alguns destes estudos utilizam os dados necessrios para avaliar as perdas com e sem investimentos em segurana (isto inclui as prticas de desenvolvimento de software possivelmente seguras) de fontes administrativas. A questo crucial aqui o calculo da taxa de desvio. A medida da taxa de desvio feita pela porcentagem de perda de eventos (como invases, ataques, infeces por vrus, e roubo de informao privilegiada) que so interrompidos pelas medidas de segurana existentes (e, portanto, no capturados pelos dados administrativos sobre intruses observadas ou perdas). A frequncia observada para

um determinado tipo de evento de perda multiplicado pelo inverso da taxa de desvio para obter a taxa de linha de base para este tipo de evento. Separadamente, dados administrativos ou outras fontes (como estimativas dos gestores) so utilizados para estimar a extenso das perdas, medidos em valores financeiros, sofridas pela organizao correspondente ao evento analisado. Outras abordagens medem as perdas em termos de recursos necessrios para correo, sendo os recursos posteriormente transformados em unidades monetrias. As estimativas de perda mdia e da frequncia de linha de base estimado so combinados para produzir uma linha de base (ao qual recebe o nome de risco base). Um mtodo semelhante utilizado para calcular a perda esperada aps as medidas de segurana serem implementadas (o que tambm pode ser chamado de risco residual). O que deve ser notado que as medidas de segurana pode reduzir tanto a frequncia de eventos de perda como o seu impacto (ou seja, as perdas ocasionadas pelos eventos). A diferena entre o risco de base e o risco residual produz o benefcio esperado (em alguns casos tambm chamado de risco evitado). Outras pesquisas preocupam-se em avaliar os benefcios dos investimentos relacionados segurana ciberntica. Muitos dos entendimentos sobre a importncia deste tipo de negcio reconhecem que um dos principais benefcios do desenvolvimento de software seguro que os usurios do software tero maior risco evitado em relao linha de base. O valor de um software seguro inclui, portanto, um componente que calculado de forma anloga ao investimento em segurana da informao, alguns detalhes podem ser diferentes dependendo do contexto. J para as equipes de desenvolvimento interno de software, o beneficio ser incluir a diferena entre a base e o risco residual. Para o desenvolvimento de software sob encomenda (onde um fornecedor independente responsvel pelo desenvolvimento), o benefcio ir incluir a parte da diferena de que o fornecedor do produto conquista (seja por meio de pagamento mais elevado, bnus de negcio ou referncias importantes para negcios futuros). O benefcio nestes casos deve ser equacionado pelo nmero de utilizadores, como o caso para um produto desenvolvido para vrios utilizadores. Uma vez que o fornecedor e os utilizadores so, nestes casos organizaes distintas, deve-se estipular os benefcios de modo a exprimir a poro dos benefcios obtidos pelos fornecedores. Em contrapartida quando o desenvolvedor pertence a uma organizao diferente do usurio pouco provvel que o mesmo que tenha acesso a registros administrativos para formar estimativas da frequncia de eventos de perda e as perdas associadas. Da mesma forma, os desenvolvedores podem ser inaptos de obter estas quantidades. Alm disso, os mesmo podem ser incapazes de estimar a frao dos benefcios que lhe cabem. Este tipo de cenrio pode representar para os fornecedores, perda de reputao e perda de vendas futuras. Existem outros benefcios em potencial. Um fator importante que o software que tem menos vulnerabilidades tambm precisam de menos correes e atualizaes de segurana. Assim, um segundo componente do benefcio do desenvolvimento de software seguro seria a reduo dos custos de correo. Embora no exista nenhum mtodo publicado para avaliar os custos de correes evitados, pode-se ser feita a adaptao do quadro de risco abordado em pargrafos anteriores para realizar esta estimao. Desta forma o benefcio seria medido como a diferena entre o custo de correo da linha de base e do custo de correo residual. Para obtermos a linha de base, podemos medir o nmero observado de vulnerabilidades por ano por mil linhas

de cdigo multiplicado pela taxa de descoberta, multiplicado pelo custo mdio de correo por vulnerabilidades. Neste contexto, a taxa de deteco necessria por que nem todas as vulnerabilidades presentes num sistema so susceptveis de serem descobertas. Alguns estudos sugerem que em sistemas de grandes dimenses, o ritmo em que a vulnerabilidades so descobertas mais ou menos constante ao longo do tempo , ou seja, mesmo que o nmero de vulnerabilidades restantes em um sistema caia (isto , aqueles que no foram ainda descobertos), a descoberta de novas vulnerabilidades aumenta a taxa proporcionalmente, deixando o nmero total de vulnerabilidades descobertas por perodo, constante. Em contrapartida existem estudos que rebatem esta afirmao. 5. CALCULO DOS CUSTOS E BENEFICIOS Existem programas que fazem este tipo de clculo disponveis na internet, tanto para o calculo dos benefcios como dos custos. Mas para realizao da estimativa eles utilizam as informaes listadas abaixo: Clculo das prestaes de segurana Para o clculo dos benefcios obtidos com a adio de segurana a um projeto de software, necessrio reunir a seguinte informao: Tamanho do programa: o tamanho do programa em nmero de linhas de cdigo fonte. Frequncia de erro: O nmero de bugs (tanto os relacionados com segurana como os que no esto relacionados) que aparecem no programa por mil linhas de cdigo fonte. Custo de bugs: O custo total por bug.

Com relao ao tamanho de um programa o mesmo pode ser determinado facilmente. Estudos apontam que nmero de linhas de cdigo de um programa compilado pode ser determinado com base no tamanho do arquivo. Frequncia de erros uma combinao do nmero total de erros que no sejam de segurana adicional com o nmero total de erros de segurana que ocorrem por mil linhas de cdigo. Estudos indicam que o nmero de bugs de segurana por cada mil linhas de cdigo varia entre cerca de 1 6. Algumas empresas se dedicam ao trabalho de identificar bugs no cdigo fonte de programas, bem como outros que se envolvem em revises de cdigos independentes. Os custo resultantes de um bug so divididos em custos de pr-lanamento e pos-lanamento, as informaes abaixo so fundamentais para a determinao do componente custo: Pr-lanamento de componente o A percentagem de erros detectados e corrigidos no prlanamento o O custo mdio por correo de bug no pr-lanamento Ps lanamento de componente o O percentual de bugs de segurana descoberto e explorado por crackers;

Custo de ralaes pblicas; Custos legais; Custo de suporte dos clientes em termos de meses; A repercusso nas receitas de vendas perdida no futuro devido a uma falha de segurana; o Custos adicionais incidentes (valor financeiro) o Dentre outros. Ps- componente de segurana o A reduo estimada no nmero total de erros (em porcentagem), que ir ocorrer devido ao aumento das normas de segurana e os controles existentes; o O aumento estimado da deteco de bug de pr-lanamento devido ao aumento dos padres de segurana e controle. Existem duas equaes separadas utilizadas no clculo dos benefcios. A primeira calcula as perdas esperadas antes da segurana ser adicionada e a segunda calcula os custos esperados depois da segurana ser adicionada. Abaixo apresentamos tais equaes: 1 - Equao Benefcio (custo esperado na pr-segurana) Pr - lanamento Componente = Porcentagem de Bugs Descobertos no PrLanamento * Custo Fixo do Pr-Lanamento Componente Explorado = ((( Nmero de Bugs de Segurana / (Nmero de Bugs de Segurana + Nmero de Bugs no Relacionados a Segurana)) * (1 Percentual de Bugs Descobertos no Pr Lanamento)) * (Percentual de Bugs Explorados * Custo Total)) Onde: Custo Total = Custo Total (Pr - lanamento) + Custo Total Legal + Total de Custo de Suporte de Clientes + Lucros Cessantes + Outros Custos Lucros Cessantes = (Percentual de Vendas Perdidas * Receita Total de Vendas) * Margem de Lucro Ps Lanamento de Componente = (1 Percentual Descoberto no Ps-Lanamento) * Total Ps-Lanamento Onde: Total Ps Lanamento = Custo Total Diagnosticado + Custo Total de Correes + Custo Total dos Testes Custo de Pr-Segurana Esperado = (Pr-lanamento Componente + Componente Explorado + Ps-Lanamento Componente) * Nmero de Bugs * Tamanho do Projeto

o o o o

Onde: Nmero de Bugs = Bugs de Segurana + Bugs no relacionados com Segurana Tamanho do Projeto = Numero de Linhas de Codigo /1000 2 - Equao Benefcio (custo esperado ps-segurana) Pr-Lanamento Componente = (Percentual de Bugs Descobertos no Pr-Lanamento * 1 (Percentual de Aumento Descoberto no Pr-Lanamento) * Custo Fixo Pr Lanamento) Componente Explorado = ((( Nmero de Bugs de Segurana / (Nmero de Bugs de Segurana + Nmero de Bugs no Relacionados a Segurana)) * (1 Percentual de Bugs Descobertos no Pr Lanamento)) * (Percentual de Bugs Explorados * Custo Total)) Onde: Custo Total = Custo Total (Pr - lanamento) + Custo Total Legal + Total de Custo de Suporte de Clientes + Lucros Cessantes + Outros Custos Lucros Cessantes = (Percentual de Vendas Perdidas * Receita Total de Vendas) * Margem de Lucro Ps Lanamento de Componente = (1 Percentual Descoberto no Ps-Lanamento) * ( 1 + Percentual de Aumento Descoberto no Pr-Lanamento ) * Total PsLanamento Onde: Total Ps Lanamento = Custo Total Diagnosticado + Custo Total de Correes + Custo Total dos Testes Custo de Ps-Segurana Esperado = (Pr-lanamento Componente + Componente Explorado + Ps-Lanamento Componente) * Nmero de Bugs * Tamanho do Projeto Onde: Nmero de Bugs = Bugs de Segurana + Bugs no relacionados com Segurana Tamanho do Projeto = Numero de Linhas de Codigo /1000 3 Equao Benefcios (Total de Benefcios) Benefcio Total = 1 Equao + 2 Equao

6. CLCULO DOS CUSTOS DE SEGURANA Alguns estudos recentes no desenvolvimento de softwares seguros tentam estender os modelos de estimativa de custos existentes para incorporar recursos de segurana. A idia subjacente a esta abordagem que a incorporao de segurana provavelmente aumenta o esforo necessrio para desenvolver o produto. Assim temos que: E = E (com segurana) - E (sem segurana) Em que E o nvel de esforo em meses por pessoa e E o esforo adicional necessrio para desenvolver um produto seguro A formula para o calcular o nvel de esforo (em meses pessoa) dada por: E (estimada) = a KLOC SF x (EM) onde KLOC linhas de cdigo em milhares e SF um fator de escala. Em particular, SF pode ser definido como SF = 1,01 + SOMA 0,01 (Wi), onde Wi so cinco fatores de escala. EM so multiplicadores de esforo (h 17 deles). Tanto Wi e EM so classificados na escala de muito baixa, baixa, alto, muito alto, e extra. O peso de cada fator foi quantificada com base em calibrao com vrios projetos e continua a evoluir. Abaixo segue algumas equaes relacionadas a Custos: 1 Equao Custo (Custo Esforo) Custo do Esforo = Custo* Esforo da Pessoa por Ms Novo Esforo = Esforo Antigo + Esforo de Mudana

2 Equao Custo (Custo de ferramentas CASE ou hardware / software) Custo de novos hardware e/ou custo do software = Capital para comprar hardware e software adicionais. Assim, se o custo da despesa de capital adicional pode ser dividida em 10 projetos igualmente, em seguida, o custo de capital = Despesa/10. 3 Equao Custo (Custo Total) Custo Total = Custo esforo + Custo de Oportunidades de Treinamento + Custo de ferramentas CASE ou hardware / software +Custo de Atrasos de Mercado 7. DESVANTAGENS Apesar dessas normas ajudarem no desenvolvimento de um processo seguro, as suas implementaes aumentam consideravelmente os custos, cronogramas e demais recursos disponveis para a realizao dos mesmos. Outras desvantagens, podem ser citadas como: o alto custo dos servios de profissionais especializados para o desenvolvimento de sistemas. As dificuldades no relacionamento com o desenvolvedor do sistema quanto sua evoluo e adaptao dinmica da empresa. Neste caso, vale observar a importncia de fazer parcerias com Empresa e Desenvolvedor, no sentido de minimizar estas desvantagens.

8. TENDENCIAS Tendo em mente que a administrao do meio empresarial visando o gerenciamento de riscos o inicio para a diminuio dos problemas relacionados ao gerenciamento de projetos em ambientes de desenvolvimento de software que devemos entender o real sentido da gerncia de risco. A mesma no deve ser compreendida e nem utilizada sob um ponto de vista desfavorvel, que estipula que gerencia de risco serve apenas para estimar e solucionar ameaas adversas, mas deve-se enxergar as ocasies que se apresentam na forma de ganho estratgico e diferencial para a disputa com as concorrentes atravs da realizao de aes preventivas. As organizaes devem tomar a iniciativa de aes, e acompanhar os riscos de seus projetos com o intuito de acumular valor e de almejar novas chances no s de comercio, mas de conhecimento conquistado. Para que este cenrio seja possvel s empresas devem focar seus esforos nos aspectos relacionados diretamente com sua rea de comrcio, o que acaba gerando um verdadeiro estrondo na terceirizao de servios, rea que se tornou um forte aliado para os gestores organizacionais. Desta rea a contribuio que sem dvida nenhuma a maior, foi a Fbrica de Software que devido a seus processos de negocio produz sistemas fundamentais para o andamento dos processos de negocio da organizao. S que existem pontos negativos nesta abordagem, no mesmo passo que auxilia a organizao pode-se gerar grandes problemas com relao segurana. Com relao ao foco organizacional, existe uma tendncia de as mesmas investirem pesado na garantia de segurana de seus processos internos, seja atravs da implantao de boas prticas ou na aquisio de maquinrio lgico ou fsico (software ou hardware), isso acaba de certa forma fazendo parte da cultura das organizaes que esto em constante colaborao com a empresa. O que se tornou um problema, pois preciso passar esta cultura para as pessoas e processos inseridos numa fbrica de software contratada, pois caso esta cultura no esteja inserida em tais colaboradores, podem ocorrer longo prazo descontentamentos e at mesmo a perda de clientes. Se a demanda aumenta a melhor soluo sem duvida a terceirizao da produo. Mas sem um controle prximo, dificilmente a organizao ir ter a segurana de que o processo ocorreu segundo as suas especificaes, e isso para uma empresa que se utiliza de servios de uma Fabrica de Software, pode gerar problemas como a perda da credibilidade, de informaes significativas ou a adeso de uma aplicao estratgica que est sujeita a falhas ou ataques. E evitar que este tipo de problema, que pode ser desastroso para uma organizao o papel de uma Fbrica de Segurana de Software. Em servios terceirizados existem inerentes a eles uma rotina que determina uma serie de critrios que prezam pelo atendimento das regras do negcio, mas em nenhum destes critrios a segurana examinada, isto perfeitamente entendido pois torna-se extremamente difcil reproduzir os mecanismos de controle existentes caso o software fosse produzido internamente. Neste ponto que entra a figura da Fbrica de Segurana de Software responsvel por determinar elementos que permitam aos desenvolvedores executarem as suas atribuies de forma padronizada e segundo as politicas de segurana da organizao. De uma forma resumida uma Fabrica de Segurana de Software opera em todo ciclo de desenvolvimento, na fase de concepo, consultores especializados ficam responsveis por indicar melhores

procedimentos e controles de segurana. J na fase de construo, a Fbrica fornece componentes de segurana, como autenticao, criptografia, monitoramento, controle de acesso, dentre outros. Na de teste a fbrica prove um exame das vulnerabilidades e fornece o apoio necessrio para correo das falhas, na ultima etapa acontece uma auditoria para se assegurar de que os mecanismos de segurana foram efetivamente adotados. Um fato que merece destaque em todo este processo que quanto mais cedo segurana for implantada no processo menor sero os custos no desenvolvimento. A questo que aqui se coloca que apenas uma empresa voltada para a segurana pode garantir a integridade de um projeto executado por uma organizao que tenha seu foco no desenvolvimento.

9. CONCLUSO A proposta de um processo seguro de desenvolvimento de software (PSDS) objetiva auxiliar na construo de software mais seguro, que proteja a confidencialidade, a integridade, e a disponibilidade das informaes processadas e armazenadas, satisfazendo a crescente exigncia dos clientes por produtos seguros. Como pontos relevantes do processo seguro proposto, pode-se destacar: (i) ressaltar a importncia de se planejar a segurana no desenvolvimento de software; (ii) incentivar a realizao de anlises de vulnerabilidade, de ameaas, de impacto e de risco; (iii) promover a elicitao de requisitos de segurana; e (iv) expressar a necessidade de se realizar testes para validar e verificar a segurana inserida no sistema.

10. REFERENCIAS BIBLIOGRFICAS Elias, Wagner. Implementando um processo de segurana em desenvolvimento. Disponvel em: <https://www.conviso.com.br/implementando-um-processo-deseguranca-em-desenvolvimento/ > Acesso em: 03/05/2012 Open Web Application Security Project. Disponvel <https://www.owasp.org/index.php/Brazilian> Acesso em: 05/05/2012 em:

Nunes, Francisco J. B., PASS - Processo de apoio segurana de software. Universidade de Fortaleza, 2007. http://www.baguete.com.br/artigos/593/rafael-lucyk/30/03/2009/fabrica-de-segurancade-software-e-tendencia https://buildsecurityin.us-cert.gov/bsi/articles/knowledge/business/267-BSI.html http://www.techoje.com.br/site/techoje/categoria/impressao_artigo/342 http://msdn.microsoft.com/pt-br/library/ms995349.aspx