Trabalho GESINF SegurancaNoDesenvolvimentoDeSoftware TiberioLeandroEzequiel

7/31/2019 Trabalho GESINF SegurancaNoDesenvolvimentoDeSoftware TiberioLeandroEzequiel

1/22

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.


2/22

Trabalho realizado comorequisito avaliativo para adisciplina Gesto de Seguranade Informao orientada peloProfessor Ricardo Rubens.

Ezequiel Batista

Leandro Wanderley

Tibrio Padilha

Segurana Relacionada ao Desenvolvimento de Software

Macei, 6 de maio de 2012.


3/22

Sumrio

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

2. Processo Seguro de Desenvolvimento de Software------------------------- 05

2.1. Primeira proposta de um Processo Seguro de Desenvolvimento deSoftware--------------------------------------------------------------------------------------06

2.2. Segunda proposta de um Processo Seguro de Desenvolvimento deSoftware--------------------------------------------------------------------------------------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


4/22

1. INTRODUO

essencial que todos os fornecedores de software abordem as ameaas segurana. A segurana um requisito fundamental para fornecedores de software, eela influenciada pelas presses do mercado, pela necessidade de proteger infra-

estruturas crticas e pela necessidade de criar e preservar uma confiana geral noambiente de computao. Um desafio importante para todos os fornecedores desoftware a criao de software mais seguro, que precise de menos atualizaesatravs de patches e possibilite um gerenciamento de segurana com menosproblemas. Esse trabalho aborda primeiramente o motivo da implementao dessesprocessos pelas organizaes, descreve dois processos seguros de desenvolvimentode softwares e logo aps faz uma analise das vantagens, desvantagens, custo etendncias relacionadas a esses processos.


5/22

2. PROCESSO SEGURO DE DESENVOLVIMENTO DE SOFTWARE

A constante procura por automatizao de processos acabou gerando umaproduo massificada de softwares sem uma preocupao adequada com asegurana 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 qualidaderelacionado segurana, o que exigiu a criao de modelos e normas internacionaisvoltados para qualidade do processo de desenvolvimento e de produtos de software.Esses processos so baseados no somente na aplicao das teorias existentescomo na adoo de um processo de desenvolvimento que considere os requisitos desegurana como parte integral do projeto de construo de software. Neste contexto, autilizao de padres de projeto de segurana e de uma abordagem orientada amodelos 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 asegurana da aplicao foi conseguida aps seu desenvolvimento.

Com a crescente preocupao com a segurana de informao muitosestudiosos voltaram ateno para a segurana em desenvolvimento de software, e comum encontrarmos solues e ferramentas que tentam implementar seguranaaps a concluso do software, as chamadas out of the box. Esses tipos deferramenta dificilmente funcionaro. Para produo de um software seguro necessrio desde o incio do processo se adotar mtodos que garantam a qualidadedurante todas as etapas do desenvolvimento.

Mas para inserir um bom nvel de segurana em seu software precisoanalisar o seu processo de desenvolvimento. Segundo dados analisados, quaseunanime, que existe problemas de segurana e que eles so ocasionados porsoftwares ruins. Isso significa que uma m gesto no processo de desenvolvimento desoftware pode levar a um cdigo mal estruturado e por sua vez a problemas desegurana. Por outro lado, podemos que um software de qualidade desenvolvidocom uma abordagem estruturada e ferramentas de apoio.

Portanto podemos medir se um software ser seguro a partir do seu processode desenvolvimento. Como voc gerencia o seu cdigo fonte? Quais os tipos de testes

usados? Como feita a correo dos bugs? Existe algum processo deacompanhamento para evitar bugs durante a produo? Voc documenta o softwaredesenvolvido e os requisitos mnimos para o seu funcionamento? Como descobrir osrequisitos de segurana da aplicao e especificar as necessidades de segurana docliente? Como mapear os requisitos de segurana em especificaes do sistema?Como projetar e implementar essas especificaes? Como testar validando asegurana do sistema? Essas perguntas podem servir como base para analisar se seusoftware ser ou no desenvolvido com a segurana mnima necessria.

Para isso preciso ter um controle da verso do software assim como asmudanas efetuadas em cada etapa do desenvolvimento, adotar prticas que buscam

avaliar o software como todo e tambm em partes dele, manter um registro das falhasque j aconteceram facilitando assim o entendimento de falhas futuras e uma


6/22

documentao clara da arquitetura e cdigo fonte ajuda a aumentar a qualidade dosoftware desenvolvido e de fundamental importncia para que o software possa serexpandido de forma sustentvel e segura. H muitas recomendaes sobre prticaspara melhorar segurana e sobre programao segura. Provavelmente, uma vez quese 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 cadaatributo de segurana. Uma maneira de demonstrar a segurana do sistema para ocliente atravs de testes. Assim, o cliente e demais envolvidos podem acompanharos testes realizados pela equipe interna ou equipe independente, bem como verificarseus resultados.

2.1 Primeira proposta de um Processo Seguro de Desenvolvimento de Software(PSDS)

Atualmente, preocupadas com a segurana dos seus softwares, variasempresas criam ou simplesmente adotam seus processos e/ou modelos que iroajudar na implementao da segurana no desenvolvimento de seus produtos. Paraessa proposta podemos definir 10 pontos chave para o processo seguro dedesenvolvimento 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.

1- Gestores 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 entregestores do negcio e equipe de desenvolvimento. Por isso, uma modificao de


7/22

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 negciocomo um todo e um bom relacionamento com os membros de desenvolvimento egerentes do negcio.

2- Time de Segurana em Desenvolvimento

necessrio estabelecer um time que ir conduzir as atividades de seguranaem desenvolvimento, como: testadores, revisores, responsveis por polticas emtricas e orientadores. importante notar que estes profissionais devem seridentificados no time de desenvolvimento e/ou contratados com estes perfis. Umcomum recorrente a profissionais de reas relacionadas segurana, sem perfil deengenharia de software para ocupar as vagas referentes s necessidades citadas.

3- Cultura e estrutura de segurana

Estudando prticas como as sugeridas pela OWASP (Open Web ApplicationSecurity Project) e estabelecendo uma cultura de segurana na organizao, definametas, desenvolva documentao prescritiva e defina os papis e responsabilidadesdos envolvidos no sistema de desenvolvimento.

4- Treinamento e Capacitao

Com o processo iniciado e apoio da organizao preciso treinar os envolvidose desenvolver materiais e recursos para que os profissionais se mantenhamconscientes sobre a necessidade de segurana e sejam informados sobre fontes depesquisa no tema.

5- Reutilizao de Componentes

Construa e homologue componentes de cdigo e arquitetura que possam vir aser adotados como padro na organizao. Modelos como o ESAPI (EnterpriseSecurity API) da OWASP podem ser adotados evitando que cdigos com problemasde segurana e componentes inseguros sejam adotados.

6- Padres de cdigos seguros e checklits

Defina padres de cdigos seguros, boas prticas de acordo com a linguagemadotada e ambiente definido pela organizao. Crie checklists (passo a passo) paraverificar as principais atividades durante o desenvolvimento e reviso de segurana dosoftware.


8/22

7- Modelo de Avaliao de Riscos

Defina um processo para avaliar os riscos associados aos softwaresdesenvolvidos e como os riscos identificados sero tratados. Este processo deve estarassociado 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 existemproblemas de segurana que ainda no foram avaliados. Os problemas identificadosdevem ser tratados e documentados no processo de Bug Tracking, atravs doprocesso de gesto de vulnerabilidades. Modelos como o OWASP Testing Guide eOWASP Code Review Guide podem ser adotados como referncia.

9- Ferramentas para Teste

Uma maneira de demonstrar a segurana do sistema para o cliente atravsde testes. Assim, o cliente e demais envolvidos podem acompanhar os testesrealizados pela equipe interna ou equipe independente, bem como verificar seusresultados. Adote e/ou crie ferramentas para testar as caractersticas especficas dossoftwares desenvolvidos. Essas ferramentas devem evoluir de acordo os asdocumentaes produzidas pelas revises de segurana. Evite ferramentas quepropem modelos baseados em padres conhecidos e no permitem que sejamaprimoradas e orientadas para a organizao. Frameworks como o O2 Platform daOWASP se adaptam e evoluem com a sua equipe de teste medida que o seusoftware vai sendo desenvolvido.

10- Implantao de Software

Aps a adoo de todo o processo necessrio colocar o software emproduo. Aps ir para produo, falhas podem aparecer e um processo claro deresposta a incidentes deve estar estabelecido. Eventuais problemas de seguranadevem ser tratados sem que causem grandes problemas aos usurios e aorganizao.

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;


9/22

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 necessriaspara o planejamento da segurana do projeto sejam estabelecidas e registradas noprocesso 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 deengenharia, definindo sua estrutura e as atribuies de cada membro do projeto. Trsatividades so implementadas nessa etapa que consta em definir objetivos deplanejamento de segurana e identificar seus mecanismos; atribuir responsabilidadesde segurana no projeto; implementar ambiente de processos; e planejar ogerenciamento de incidentes de segurana.

a partir das metas e dos planos de segurana que os engenheiros desegurana e de software planejam as atividades que sero executadas no projeto, elesconstroem o cronograma dessas atividades, instanciando o processo seguro para oprojeto. 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 oprojeto.

2- Avaliar Vulnerabilidade de Segurana

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


10/22

Nessa etapa devero ser executados os mtodos de identificao devulnerabilidades de segurana e a analise das vulnerabilidades de seguranaidentificadas.

3- Modelar Ameaa de Segurana

nessa etapa onde so identificadas e caracterizadas as ameaas desegurana, juntamente com suas propriedades e caractersticas. A partir da lista devulnerabilidades, que o principal produto resultante da etapa anterior so avaliadastodas as ameaas levantadas, para que o engenheiro de segurana entenda asameaas relacionadas s vulnerabilidades identificadas, isto , ameaas potenciaisque podemaparecer ao colocar o produto em funcionamento.

necessrio que sejam identificadas as ameaas de segurana aos ativoscrticos e desenvolvidas estratgias que reduzam as ameaas de seguras.

4- Avaliar Impacto de Segurana

Tem como proposito de identificar e caracterizar impactos que sejamrelevantes com respeito ao sistema e avaliar a possibilidade da ocorrncia dessesimpactos. Os impactos podem ser tangveis, como prejuzos financeiros, ouintangveis, como perda de reputao. Entende-se impacto como sendo aconsequncia de um incidente no desejado, causado tanto deliberado quantoacidentalmente, e que afeta os ativos. As consequncias podem envolver a destruioou dano destes ativos, ou mesmo perda de confidencialidade, integridade, ou

disponibilidade.Nessa etapa devem ser priorizados os processos crticos influenciados pelosistema, revisados os ativos que se referem a segurana e feito a identificao edescrio dos impactos de segurana.

5- Avaliar 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 emdesenvolvimento pela identificao da exposio de segurana, o risco dessaexposio, e a priorizao desses riscos. Tendo como foco o descobrimento dosriscos de segurana envolvidos com o sistema em um ambiente definido, baseado emum entendimento estabelecido de como os ativos so vulnerveis s ameaas.

Nessa etapa necessrio identificar a exposio, avaliar e priorizar os riscosde segurana.

6- Especificar Necessidades de Segurana

O propsito desta etapa especificar as necessidades relacionadas comsegurana 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


11/22

necessidades se baseiam no contexto de segurana operacional do sistema, no atualambiente 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, definirrequisitos de segurana e obter acordo sobre requisitos de segurana.

7- Fornecer Informao de Segurana

O propsito desta etapa prover aos arquitetos de sistema, projetistas,implementadores, ou usurios a informao de segurana de que necessitam. Essainformao inclui arquitetura segura, projeto, ou alternativas de implementao eorientao de segurana, procurando garantir que todos os problemas do sistema sorevisados em relao a implicaes de segurana e so resolvidos de acordo comobjetivos de segurana; que todos os membros da equipe de projeto compreendemsegurana 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 deinformao de segurana, determinar consideraes e restries de segurana,identificar e analisar alternativas de segurana, fornecer orientao de segurana, eidentificar e revisar requisitos de garantia de segurana.

8- Verificar e Validar Segurana

O propsito desta etapa garantir que as solues sejam verificadas evalidadas 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 necessidadesde segurana do cliente. Assim sendo, as metas dessa atividade incluem que assolues, de fato, implementem de maneira adequada e eficaz os requisitos desegurana, e que as solues satisfaam as necessidades de segurana do cliente.

nessa etapa que se defini a abordagem de verificao e validao desegurana; realiza verificao de segurana; realiza validao de segurana; revisa ecomunica resultados de verificao; e valida segurana.

9- Gerenciar Segurana

O propsito desta etapa tratar das tarefas necessrias para administrar emanter os mecanismos de controle de segurana para o ambiente de desenvolvimentoe um sistema operacional, bem como gerenciar a implantao de controles para novasfuncionalidades, que se integram com os controles existentes. Define tambm comoser o gerenciamento da segurana, envolvendo a definio de treinamentos eprogramas de educao de segurana necessrios.

nessa etapa que so gerenciados e controlados servios e componentesoperacionais de segurana; gerenciados percepo, treinamento e programa deeducao de segurana; e gerenciada a implementao de controles de segurana.


12/22

10- Monitorar Comportamento de Segurana

O propsito desta etapa garantir que a segurana, que foi prevista para oprojeto, 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 internodevem ser monitorados em relao aos fatores que podem ter um impacto nasegurana do sistema. Alm disso, a monitorao deve auxiliar garantir que o nvel desegurana no se deteriore.

nessa etapa que so analisados os registros de evento com impacto nasegurana; 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 sistemapara identificar mudanas necessrias; e realizada auditorias de segurana.

11- Garantir Segurana

O propsito desta etapa definir um conjunto de atividades que podem seraplicadas, para garantir que a segurana do produto seja mantida. A garantia dasegurana deve assegurar que controles de segurana eficazes sejam definidos eimplementados para proteger dados e operaes crticas.

nessa etapa que definida a estratgia de manuteno da garantia desegurana; e conduzida a anlise de impacto de segurana das mudanas.

3.CUSTO DE SOFTWARES SEGUROS

Os principais empecilhos para calcular o custo do desenvolvimento desoftwares seguros incidem na ausncia de dados precisos, falta de acordo comrelao os critrios de medio, e o foco relativamente recente em matria desegurana. Entretanto tem havido um trabalho expressivo sobre a quantificao eestimao do custo de desenvolvimento de softwares. Alguns dos primeiros esforosbasearam-se no modelo chamado de COCOMO (Constructive Cost Model). Estemodelo foi revisto significativamente, e vrios outros modelos para avaliao doesforo 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 engenhariade 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, maistestes, e inspeo, os quais abalam significativamente os custos. Sendo que estesbenefcios so bem maiores que os custos envolvidos. Os custos da melhor qualidadedevem ser divididos baseados na conformidade e no-conformidade. Aconformidade 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).


13/22

B - Eliminar os defeitos atravs da avaliao e auditoria do produto (inspeodo cdigo, testes, software para medio das atividades, etc).

Uma vez seguidos estes passos os pesquisadores podero ento dar valoresao retorno de investimento voltado para a melhoria da qualidade usando dados deempresa e mostrando que este ROI positivo e significativo. Lamentavelmente, a

elaborao e qualquer tipo de execuo de mtricas de custos que visem qualidadede software bastante difcil, pois estas medidas tendem a ser usadas apenas em umou outro produto especfico, ou tecnologia especfica, sendo portanto, difceis degeneralizar. Outros trabalhos relacionados a problemtica mostram que ter pessoalmelhor preparado, utilizao de ferramentas CASE, e mais investimentos frente aconcepo, planejamento, etc tendem a melhorar a qualidade do produto.

Esta mesma demonstrao de quantificao da qualidade de software pode seraplicada para a abordagem de segurana tambm. O que todos estes estudosimplicitamente 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 aqualidade do mesmo, poderemos usar as mtricas propostas anteriormente para mediro custo de segurana.

Entretanto a segurana em potencial incorporada ao processo acaba afetandoo 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 custosadicionais ao design do produto que podem estar acima e alm dos custos deconformidade, como o custo de treinamento, o custo de ferramentas CASE, etc.

4. BENEFICIOS DO SOFTWARE SEGURO

Para compreendermos melhor os benefcios de softwares seguros, precisamosnos ater nos trabalhos que descrevem mtodos e modelos de apoio tomada dedeciso sobre investimentos em segurana da informao a partir da perspectiva dousurio, ou seja, a partir da perspectiva de uma organizao de TI, que desejaproteger-se contra ataque de cibercriminosos. Esta abordagem justificada pelo fatodo desenvolvimento de software seguro ser uma forma de investir em segurana dainformao. A abordagem adotada aqui voltada para o contexto de desenvolvimentode software, aplicada ao problema de avaliar o retorno de investimento em prticas dedesenvolvimento seguro de software.

Em particular, os benefcios so avaliados atravs do valor financeiro deperdas evitado resultante das prticas de desenvolvimento seguro de software. Adiferena em relao aos estudos realizados nesta rea reside na forma como cadaum procura mensurar as perdas evitadas. Alguns destes estudos utilizam os dadosnecessrios para avaliar as perdas com e sem investimentos em segurana (isto incluias prticas de desenvolvimento de software possivelmente seguras) de fontesadministrativas. A questo crucial aqui o calculo da taxa de desvio. A medida da taxade 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 dadosadministrativos sobre intruses observadas ou perdas). A frequncia observada para


14/22

um determinado tipo de evento de perda multiplicado pelo inverso da taxa de desviopara obter a taxa de linha de base para este tipo de evento. Separadamente, dadosadministrativos ou outras fontes (como estimativas dos gestores) so utilizados paraestimar a extenso das perdas, medidos em valores financeiros, sofridas pelaorganizao correspondente ao evento analisado. Outras abordagens medem as

perdas em termos de recursos necessrios para correo, sendo os recursosposteriormente transformados em unidades monetrias. As estimativas de perdamdia e da frequncia de linha de base estimado so combinados para produzir umalinha de base (ao qual recebe o nome de risco base).

Um mtodo semelhante utilizado para calcular a perda esperada aps asmedidas de segurana serem implementadas (o que tambm pode ser chamado derisco residual). O que deve ser notado que as medidas de segurana pode reduzirtanto a frequncia de eventos de perda como o seu impacto (ou seja, as perdasocasionadas pelos eventos). A diferena entre o risco de base e o risco residualproduz o benefcio esperado (em alguns casos tambm chamado de risco evitado).

Outras pesquisas preocupam-se em avaliar os benefcios dos investimentosrelacionados segurana ciberntica. Muitos dos entendimentos sobre a importnciadeste tipo de negcio reconhecem que um dos principais benefcios dodesenvolvimento de software seguro que os usurios do software tero maior riscoevitado em relao linha de base. O valor de um software seguro inclui, portanto, umcomponente que calculado de forma anloga ao investimento em segurana dainformao, alguns detalhes podem ser diferentes dependendo do contexto. J paraas equipes de desenvolvimento interno de software, o beneficio ser incluir a diferenaentre 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 meiode pagamento mais elevado, bnus de negcio ou referncias importantes paranegcios futuros). O benefcio nestes casos deve ser equacionado pelo nmero deutilizadores, 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 obtidospelos fornecedores.

Em contrapartida quando o desenvolvedor pertence a uma organizaodiferente do usurio pouco provvel que o mesmo que tenha acesso a registrosadministrativos para formar estimativas da frequncia de eventos de perda e as perdasassociadas. Da mesma forma, os desenvolvedores podem ser inaptos de obter estasquantidades. Alm disso, os mesmo podem ser incapazes de estimar a frao dosbenefcios que lhe cabem. Este tipo de cenrio pode representar para osfornecedores, perda de reputao e perda de vendas futuras.

Existem outros benefcios em potencial. Um fator importante que o softwareque tem menos vulnerabilidades tambm precisam de menos correes e atualizaesde segurana. Assim, um segundo componente do benefcio do desenvolvimento desoftware seguro seria a reduo dos custos de correo. Embora no exista nenhummtodo publicado para avaliar os custos de correes evitados, pode-se ser feita aadaptao do quadro de risco abordado em pargrafos anteriores para realizar estaestimao. 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 debase, podemos medir o nmero observado de vulnerabilidades por ano por mil linhas


15/22

de cdigo multiplicado pela taxa de descoberta, multiplicado pelo custo mdio decorreo por vulnerabilidades. Neste contexto, a taxa de deteco necessria porque nem todas as vulnerabilidades presentes num sistema so susceptveis de seremdescobertas. Alguns estudos sugerem que em sistemas de grandes dimenses, oritmo em que a vulnerabilidades so descobertas mais ou menos constante ao longo

do tempo , ou seja, mesmo que o nmero de vulnerabilidades restantes em umsistema caia (isto , aqueles que no foram ainda descobertos), a descoberta denovas vulnerabilidades aumenta a taxa proporcionalmente, deixando o nmero total devulnerabilidades descobertas por perodo, constante. Em contrapartida existemestudos 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 projetode software, necessrio reunir a seguinte informao:

Tamanho do programa: o tamanho do programa em nmero de linhasde cdigo fonte.

Frequncia de erro: O nmero de bugs (tanto os relacionados com

segurana como os que no esto relacionados) que aparecem noprograma 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 determinadofacilmente. Estudos apontam que nmero de linhas de cdigo de um programacompilado pode ser determinado com base no tamanho do arquivo.

Frequncia de erros uma combinao do nmero total de erros que nosejam de segurana adicional com o nmero total de erros de segurana que ocorrempor 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 dedicamao trabalho de identificar bugs no cdigo fonte de programas, bem como outros que seenvolvem em revises de cdigos independentes.

Os custo resultantes de um bug so divididos em custos de pr-lanamento epos-lanamento, as informaes abaixo so fundamentais para a determinao docomponente custo:

Pr-lanamento de componenteo A percentagem de erros detectados e corrigidos no pr-

lanamentoo O custo mdio por correo de bug no pr-lanamento

Ps lanamento de componenteo O percentual de bugs de segurana descoberto e explorado por

crackers;


16/22

o Custo de ralaes pblicas;o Custos legais;o Custo de suporte dos clientes em termos de meses;o 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 seguranao A reduo estimada no nmero total de erros (em porcentagem),

que ir ocorrer devido ao aumento das normas de segurana eos controles existentes;

o O aumento estimado da deteco de bug de pr-lanamentodevido ao aumento dos padres de segurana e controle.

Existem duas equaes separadas utilizadas no clculo dos benefcios. A primeiracalcula as perdas esperadas antes da segurana ser adicionada e a segunda calcula

os custos esperados depois da segurana ser adicionada. Abaixo apresentamos taisequaes:

1 - Equao Benefcio (custo esperado na pr-segurana)

Pr - lanamento Componente = Porcentagem de Bugs Descobertos no Pr-Lanamento * Custo Fixo do Pr-Lanamento

Componente Explorado = ((( Nmero de Bugs de Segurana / (Nmero de Bugs deSegurana + Nmero de Bugs no Relacionados a Segurana)) * (1 Percentual de

Bugs Descobertos no Pr Lanamento)) * (Percentual de Bugs Explorados * CustoTotal))

Onde:

Custo Total = Custo Total (Pr - lanamento) + Custo Total Legal + Total de Custo deSuporte 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 + ComponenteExplorado + Ps-Lanamento Componente) * Nmero de Bugs * Tamanho do Projeto


17/22

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 deSegurana + Nmero de Bugs no Relacionados a Segurana)) * (1 Percentual deBugs Descobertos no Pr Lanamento)) * (Percentual de Bugs Explorados * Custo

Total))

Onde:

Custo Total = Custo Total (Pr - lanamento) + Custo Total Legal + Total de Custo deSuporte de Clientes + Lucros Cessantes + Outros Custos

Lucros Cessantes = (Percentual de Vendas Perdidas * Receita Total de Vendas) *Margem de LucroPs Lanamento de Componente = (1 Percentual Descoberto no Ps-Lanamento)

* ( 1 + Percentual de Aumento Descoberto no Pr-Lanamento ) * Total Ps-Lanamento

Onde:

Total Ps Lanamento = Custo Total Diagnosticado + Custo Total de Correes +Custo Total dos Testes

Custo de Ps-Segurana Esperado = (Pr-lanamento Componente + ComponenteExplorado + 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


18/22

6. CLCULO DOS CUSTOS DE SEGURANA

Alguns estudos recentes no desenvolvimento de softwares seguros tentamestender os modelos de estimativa de custos existentes para incorporar recursos desegurana. A idia subjacente a esta abordagem que a incorporao de segurana

provavelmente aumenta o esforo necessrio para desenvolver o produto. Assimtemos 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 seguroA formula para o calcular o nvel de esforo (em meses pessoa) dada por:E (estimada) = a KLOCSFx (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 soclassificados na escala de muito baixa, baixa, alto, muito alto, e extra. O peso de cadafator 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 MsNovo 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 comprarhardware e software adicionais. Assim, se o custo da despesa de capital adicionalpode 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 deferramentas 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 edemais recursos disponveis para a realizao dos mesmos. Outras desvantagens,podem ser citadas como: o alto custo dos servios de profissionais especializadospara o desenvolvimento de sistemas. As dificuldades no relacionamento com odesenvolvedor do sistema quanto sua evoluo e adaptao dinmica daempresa. Neste caso, vale observar a importncia de fazer parcerias com Empresa eDesenvolvedor, no sentido de minimizar estas desvantagens.


19/22

8. TENDENCIAS

Tendo em mente que a administrao do meio empresarial visando ogerenciamento de riscos o inicio para a diminuio dos problemas relacionados aogerenciamento de projetos em ambientes de desenvolvimento de software que

devemos entender o real sentido da gerncia de risco. A mesma no deve sercompreendida e nem utilizada sob um ponto de vista desfavorvel, que estipula quegerencia de risco serve apenas para estimar e solucionar ameaas adversas, masdeve-se enxergar as ocasies que se apresentam na forma de ganho estratgico ediferencial para a disputa com as concorrentes atravs da realizao de aespreventivas. As organizaes devem tomar a iniciativa de aes, e acompanhar osriscos de seus projetos com o intuito de acumular valor e de almejar novas chancesno s de comercio, mas de conhecimento conquistado.

Para que este cenrio seja possvel s empresas devem focar seus esforosnos aspectos relacionados diretamente com sua rea de comrcio, o que acaba

gerando um verdadeiro estrondo na terceirizao de servios, rea que se tornou umforte aliado para os gestores organizacionais. Desta rea a contribuio que semdvida nenhuma a maior, foi a Fbrica de Software que devido a seus processos denegocio produz sistemas fundamentais para o andamento dos processos de negocioda organizao. S que existem pontos negativos nesta abordagem, no mesmo passoque auxilia a organizao pode-se gerar grandes problemas com relao segurana.

Com relao ao foco organizacional, existe uma tendncia de as mesmasinvestirem pesado na garantia de segurana de seus processos internos, seja atravsda 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 tornouum problema, pois preciso passar esta cultura para as pessoas e processosinseridos numa fbrica de software contratada, pois caso esta cultura no estejainserida em tais colaboradores, podem ocorrer longo prazo descontentamentos e atmesmo a perda de clientes.

Se a demanda aumenta a melhor soluo sem duvida a terceirizao daproduo. Mas sem um controle prximo, dificilmente a organizao ir ter asegurana de que o processo ocorreu segundo as suas especificaes, e isso parauma empresa que se utiliza de servios de uma Fabrica de Software, pode gerarproblemas como a perda da credibilidade, de informaes significativas ou a adesode uma aplicao estratgica que est sujeita a falhas ou ataques. E evitar que estetipo de problema, que pode ser desastroso para uma organizao o papel de umaFbrica de Segurana de Software.

Em servios terceirizados existem inerentes a eles uma rotina que determinauma serie de critrios que prezam pelo atendimento das regras do negcio, mas emnenhum destes critrios a segurana examinada, isto perfeitamente entendido poistorna-se extremamente difcil reproduzir os mecanismos de controle existentes caso osoftware fosse produzido internamente. Neste ponto que entra a figura da Fbrica deSegurana de Software responsvel por determinar elementos que permitam aosdesenvolvedores executarem as suas atribuies de forma padronizada e segundo aspoliticas de segurana da organizao. De uma forma resumida uma Fabrica de

Segurana de Software opera em todo ciclo de desenvolvimento, na fase deconcepo, consultores especializados ficam responsveis por indicar melhores


20/22

procedimentos e controles de segurana. J na fase de construo, a Fbrica fornececomponentes de segurana, como autenticao, criptografia, monitoramento, controlede acesso, dentre outros. Na de teste a fbrica prove um exame das vulnerabilidadese fornece o apoio necessrio para correo das falhas, na ultima etapa acontece umaauditoria para se assegurar de que os mecanismos de segurana foram efetivamente

adotados. Um fato que merece destaque em todo este processo que quanto maiscedo segurana for implantada no processo menor sero os custos nodesenvolvimento.

A questo que aqui se coloca que apenas uma empresa voltada para asegurana pode garantir a integridade de um projeto executado por uma organizaoque tenha seu foco no desenvolvimento.


21/22

9. CONCLUSO

A proposta de um processo seguro de desenvolvimento de software (PSDS)objetiva auxiliar na construo de software mais seguro, que proteja aconfidencialidade, 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) ressaltara importncia de se planejar a segurana no desenvolvimento de software; (ii)incentivar a realizao de anlises de vulnerabilidade, de ameaas, de impacto e derisco; (iii) promover a elicitao de requisitos de segurana; e (iv) expressar anecessidade de se realizar testes para validar e verificar a segurana inserida nosistema.


22/22

10. REFERENCIAS BIBLIOGRFICAS

Elias, Wagner. Implementando um processo de segurana em desenvolvimento.Disponvel em: Acesso em: 03/05/2012

Open Web Application Security Project. Disponvel em: Acesso em: 05/05/2012

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-seguranca-de-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
https://www.conviso.com.br/implementando-um-processo-de-seguranca-em-desenvolvimento/https://www.conviso.com.br/implementando-um-processo-de-seguranca-em-desenvolvimento/https://www.conviso.com.br/implementando-um-processo-de-seguranca-em-desenvolvimento/https://www.owasp.org/index.php/Brazilianhttps://www.owasp.org/index.php/Brazilianhttps://www.conviso.com.br/implementando-um-processo-de-seguranca-em-desenvolvimento/https://www.conviso.com.br/implementando-um-processo-de-seguranca-em-desenvolvimento/

Documents

Trabalho GESINF SegurancaNoDesenvolvimentoDeSoftware TiberioLeandroEzequiel