Processo de desenvolvimento de software seguro atravs da

identificao de nveis de segurana

Rosana Wagner, Josiane Fontoura dos Anjos Brandolt, Fbio Diniz Rossi
Instituto Federal Farroupilha
Campus Alegrete
{rosanawagner, josianefab, fdrossi@al.iffarroupilha.edu.br}

Resumo: As organizaes enfrentam uma srie de dificuldades para atender s

exigncias previstas pelas normas e modelos de segurana de software, alm do
crescimento contnuo das exigncias relacionadas segurana em sistemas. Uma srie
de normas e modelos de segurana esto disponveis na literatura a fim de guiarem o
desenvolvimento de software seguro, porm a aplicao destas normas gera uma srie
de interferncia no desenvolvimento de software, como aumento de custos, cronograma
e demais recursos. Neste sentido, este trabalho visa propor nveis de segurana a serem
aplicados em sistemas, bem como a avaliao de cada empresa e o modelo de
segurana a ser utilizado em cada nvel distinto. A proposta consiste na utilizao de
processos j consagrados na literatura, porm que podem ser utilizados de diversas
formas possibilitando o entendimento de que a segurana precisa ser quantificada de
forma distinta para cada projeto.

1. Introduo
A crescente necessidade de produtos de software que suportam processos de negcios tem
motivado consideravelmente pesquisadores no melhoramento de processos de
desenvolvimento de software.
Da mesma maneira que cada projeto de sistema possui diferentes requisitos de
software, tambm possuir diferentes requisitos de segurana. Requisitos de segurana
da informao so identificados por meio de uma avaliao sistemtica dos riscos de
segurana da informao. Gastos com os controles de segurana precisam ser
balanceados de acordo com os danos causados aos negcios gerados pelas falhas
potenciais na segurana da informao. Os resultados da avaliao de riscos ajudaro a
direcionar e a determinar as aes gerenciais apropriadas e as prioridades para o
gerenciamento dos riscos da segurana da informao [Compagna et al. 2008].
Alm disso, considera-se importante a criao de diferentes nveis de segurana em
projetos. Estes nveis so aplicados em projetos a partir de uma avaliao de diversos
aspectos da empresa e do projeto em desenvolvimento.
Desta forma, este artigo tem como objetivo propor e avaliar nveis de segurana
a serem aplicados em diferentes tipos de projetos. Estes nveis esto baseados em
requisitos e medidas de segurana a serem tomadas pelo responsvel pelo projeto.
O artigo est organizado da seguinte maneira: seo 2 apresenta nveis de
segurana propostos para o desenvolvimento de software. A seo 3 demonstra a
proposta de avaliao do nvel de segurana a ser empregado no projeto. Na quarta
seo apresentada a ferramenta desenvolvida para suportar a proposta deste artigo e a
seo 5 apresenta uma aplicao da proposta. A seo 6 apresenta trabalhos
relacionados a este artigo. Por fim, na seo
7 so apresentadas as concluses e
trabalhos futuros, posteriormente feita referncia a bibliografia utilizada.
2. Critrios de segurana no desenvolvimento de software

A melhor maneira de desenvolver software seguro incorporar a segurana

desde o incio do desenvolvimento de software. Alm disso, 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 [Khan Zulkernine 2008].
Os autores [MEAD MCGRAW 2005] apresentam uma iniciativa de segurana
de software denominada Build Security In (BSI) a qual foi desenvolvida com a colaborao
do US National Institute of Standards and Technology (NIST),
o
International
Organization for Standardization (ISO), e o IEEE em padres de atividades focados
no desenvolvimento de subconjuntos de linguagens crticas e seguras e guias de estilos de
garantia de softwares. 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.
Outro processo de desenvolvimento de segurana em projetos proposto por
[Khan et al. 2009], intitulado SSDP (Secure Software Development Process). O SSDP est
dividido em 4 fases: Engenharia de Requisitos; Design; Implementao; Garantia. Cada uma
dessas fases est dividida em uma sequncia de atividades que devem ser seguidas, alm
do relacionamento entre as fases.

3. Nveis de segurana propostos para processos de desenvolvimento de

software seguro
Atravs dos vrios autores citados anteriormente [MEAD MCGRAW 2005]
[Khan et. al. 2009] [MEAD et. al. 2001], chega-se a um momento onde a reviso da
bibliografia nos permite criar nveis de segurana.
Considera-se ento, trs nveis de critrios que podem ser utilizados: Nvel
Baixo; Nvel Mdio; Nvel Alto.
Nvel Baixo - O nvel baixo considerado para uso em sistemas que no
demandem de maiores preocupaes de segurana. Como exemplo, podemos citar um
sistema de biblioteca que acessado atravs de um nico computador que possui uma nica
conexo a um servidor e no est ligado a Web.
Um sistema com este nvel de segurana pode ser considerado como um sistema
domstico e geralmente no est interligado em vrias estaes de trabalhos, alm de ter baixo
nvel de importncia para a empresa.
Neste trabalho, ser entendido como nvel baixo de segurana a implantao de menos
de 50% dos componentes catalogados no contexto do BSI.
Nvel Mdio - O nvel mdio pode-se considerar sistemas que demandem de
segurana, como sistema de cadastro de alunos, notas, cursos e todas as informaes de
uma grande universidade. Este nvel de segurana considerado mediano, pois envolve
uma srie de requisitos de segurana a serem implantados, como normas, modelos e
treinamento de segurana alm bom senso aos usurios do sistema.
Neste trabalho, ser entendido como nvel mdio de segurana a implantao de
pelo menos 50% dos componentes catalogados no contexto do BSI. Pode tambm ser
considerado um nvel mdio de segurana qualquer abordagem de segurana de alto
nvel que no seja criteriosamente seguida.
Nvel Alto - Como sistemas de nvel alto, pode-se citar como principal clientela
sistemas bancrios, transaes web, transferncia de dados particulares de cliente como
no caso do imposto de renda entre outros sistemas deste gnero. Estes sistemas

necessitam do nvel mais alto de segurana bem como implementao constante de

novas tcnicas desenvolvidas atravs de pesquisas recentes.
Como exemplo de modelos de desenvolvimento de software seguro pode-se citar
Khan e Zulkernine (Khan, Zulkernine 2009) que desenvolveram um modelo de
processo de desenvolvimento de software atravs da exibio de atividades e artefatos,
intitulado de SSDP - secure software development process. No sentido de quantificar a
segurana, prope-se que todo o modelo SSDP deve ser implementado.
A proposta do nvel de segurana a ser empregado no sistema deve dar-se
atravs da avaliao das informaes da empresa e do projeto. Identificar e propor aos
stakeholders os critrios de segurana (baixo, mdio ou alto) que atravs do entendimento
do engenheiro de segurana seja necessrio para garantir a segurana de tal projeto,
explicando claramente ao cliente que se pode alterar o nvel de segurana, porm isso ir
alterar os custos e o cronograma de desenvolvimento do projeto.

4. Ferramenta desenvolvida para validao

A ferramenta desenvolvida permite selecionar as atividades que devero ser
realizadas para que o padro de segurana seja atingido, aps o usurio realizar a
seleo das atividades necessrias, o sistema gera um WebSite que apresenta a
descrio, o responsvel, os artefatos de entrada e os artefatos de sada que devero ser
gerados, inclusive outras informaes para que a equipe possa basear-se no momento de
incluir a segurana no projeto.
Porm, como j descrito anteriormente existem projetos que demandam de
diferentes nveis de segurana, o que resulta tambm em diferentes regras de
associaes entre requisitos e padres de segurana. Para atender a esta especificao o
usurio j deve cadastrar o nvel de segurana que deseja para o projeto, com base nas
definies acima, no momento do cadastro do projeto.

5. Utilizao dos nveis de segurana

Para descrever como devem ser utilizados os nveis de segurana adotado um
sistema de informao para clnica mdica a ser desenvolvido pela empresa
especializada no desenvolvimento de sistemas relacionados sade.
Durante o cadastro dos dados ser necessrio o uso do bom senso e a tica do
profissional, mas uma vez que os dados esto no sistema e a empresa tem acesso a todas as
contas, valores, folha de pagamento e notas fiscais de seus clientes a responsabilidade passa a
ser do sistema da empresa.
Atravs de uma anlise da empresa e do projeto a serem desenvolvidos chegou-se a
concluso (que apoiada pelos conceitos citados por [SBIS 2010] de que o nvel de
segurana demandado pelo projeto alto.
Ento, conforme a proposta deste trabalho, para que este nvel seja atingido
necessria a implementao e verificao das atividades do SSDP. O detalhamento das
atividades a serem implementadas no projeto, para que este tenha um nvel alto de
segurana sero descritas abaixo.
Tabela 1 - Atividades Relacionadas Engenharia de Requisitos
R1 - O ambiente de funcionamento do sistema constitudo apenas de hospitais, postos de sades, e o banco de dados
est alocado junto empresa desenvolvedora do software, a qual tambm responsvel por total segurana de tais dados e
informaes.
R2 - Inspees nas especificaes de requisitos so realizadas durante todo o tempo de desenvolvimento de software e
sempre que novas verses forem criadas.

R3 - Informaes sobre ataques e tentativas de ataques anteriores so estudadas e coletadas, para que se tenha um
conjunto de dados a serem analisados sempre que novos sistemas forem desenvolvidos.
R4 - Priorizao de riscos e ameaas em trabalhos anteriores so realizadas, para utilizao em trabalhos futuros.
R5- Especificao de requisitos de alto nvel de segurana, tais como preservao da confidencialidade, integridade
e disponibilidade so especificadas para atenuar as ameaas identificadas.
R6 - Verificao de mecanismos de segurana que so capazes de cumprir um requisito de segurana.
R7 - Requisitos de segurana de alto nvel so priorizados atravs de uma anlise custo-benefcio. Mecanismo de
segurana com maior prioridade sero implementados primeiramente, caso haja restries oramentrias.
R8 - Inspees so realizadas a fim de identificar erros de segurana em software e requisitos de segurana de baixo
nvel.
R9 - Um limite de segurana aceitvel definido atravs de sua utilizao. Caso um mecanismo fraco de segurana
for selecionado, ento sua fraqueza pode ser tratada como uma vulnerabilidade em relao ao clculo do ndice de
segurana.
R10 - Se o ndice de segurana calculado for inferior ao inicial, ento os requisitos de segurana para remover erros
identificados so especificados.
R11. Requisitos de segurana so priorizados com base em uma anlise custo-benefcio.

Byers et al. (2007) afirma que uma fonte de problemas de segurana a no

considerao de requisitos de segurana no completo desenvolvimento do sistema. Tais
afirmaes justificam o motivo da integrao de requisitos relacionados segurana desde
o incio do projeto. Atravs de 11 atividades o modelo proposto atinge um nvel alto de
segurana nesta fase.
Tabela 2 - Atividades relacionadas ao design
D1 - O design funcional do sistema especificado de forma segura e ao mesmo tempo de fcil manuseio
provendo
ao usurio uma aplicao intuitiva as caractersticas peculiares do ambiente clnico, bem como a diminuio de
navegao em telas do sistema para a obteno de dados especficos, procurando assim diminuir a rejeio
encontrada pelos clnicos na utilizao de tais sistemas. Para que estes requisitos de design sejam atendidos ser
utilizada a linguagem de design UMLsec.
D2- O projetista do design inspeciona regularmente o projeto para identificao de possveis erros de software.
D3 - O modelo de ameaas reforado e corrigido mais uma vez atravs da atividade anterior.
D4 - Anlise das ameaas identificadas realizada a fim de obter dados de sua provenincia e prever futuras
ameaas.
D5 - Ameaas relacionadas a requisitos de segurana so removidas.
D6 - Decises de design seguro para remoo de ameaas so priorizadas com base numa anlise custo/benefcio.
D7 - Erros de segurana de software e decises de design seguro previamente especificados so identificados. Erros
de segurana ou vulnerabilidades relatado no software existente similar podem ser usado como uma lista de
verificao.
D8 - Um nvel inicial de segurana aceitvel deve ser definido utilizando, por exemplo, o ndice de segurana.
D9 - Se o ndice de segurana calculado inferior ao inicial, ento as decises de design seguro para remover os
erros devem ser especificados.
D10 - Decises de design so priorizadas com base numa anlise custo-benefcio.

As decises relacionadas ao design de projetos com alto nvel de segurana

devem ser baseadas nos requisitos de segurana definidos para o projeto inicialmente.
As 10 atividades relacionadas ao design neste modelo so diretamente relacionadas e
demonstram preocupaes em relao a segurana modelada para este sistema.
Tabela 3 - Atividades relacionadas implementao
I1. Utilizao de linguagens de programao de nvel superior em segurana, as quais oferecem perspectivas de cdigo
menos inseguro, como a linguagem Java que tem um alto grau de segurana devido as aplicaes rodarem de forma stand
Box, nenhuma aplicao burla os requisitos de segurana especificados na linguagem Java, pois elas no tem acesso
diretamente ao Sistema Operacional, desta forma elas so obrigadas a pedir que a Maquina Virtual Java aloque recursos
do Sistema Operacional para a aplicao, assim essas requisies da aplicao passam pelas polticas de segurana
especificadas na linguagem. No entanto, s vezes necessria a utilizao de linguagem de baixo nvel para obter acesso
direto ao nvel de hardware.
I2. Padres de cdigos, guias de segurana, normas de codificao e orientaes de segurana so seguidas no
intuito de evitar erros de cdigo-fonte. Padres de desenvolvimento como (i) Facede que atua como uma camada
mediadora entre a regra de negcio da aplicao e a interface grfica, permitindo que caso regras de negcios
mudem em algum determinado momento, isso no impacte na reestruturao de toda a aplicao novamente, (ii)

Data Acess Object (DAO) que permite a separao de cdigo destinado a manipulao de dados do banco de dados
para a aplicao, assim diminuindo a interferncia da estrutura do banco diretamente na aplicao desenvolvida.
I3. Testes de unidade sero realizados com preocupaes com a segurana em mente, Podendo ser utilizado o
firebug para tais testes. Erros de segurana relatados em software similares sero usados como uma referncia.

Em relao implementao da segurana pode-se considerar que todos os

requisitos de segurana e o design especificado sero implementados de maneira
correta, atravs da utilizao de linguagem de programao segura e da utilizao de
padres, guias e normas de codificao.
Tabela 4 - Atividades Relacionadas garantia
A1. Com base em erros anteriormente descobertos, bem como, nos requisitos de segurana do sistema sero
realizadas inspees no cdigo e anlise esttica.
A2. Casos de testes so gerados com base nos requisitos funcionais e requisitos de segurana.
I3. Testes de integrao, penetrao e aceitao so realizados atravs dos requisitos de segurana relatados.

De acordo com as atividades relacionadas garantia, o software em

desenvolvimento pode ser considerado no final de sua implementao que possui um alto
nvel de segurana, bem como uma preocupao continua com os dados
relacionados a este banco de dados.
Todos os nveis descritos acima devem ser aplicados de forma conjunta tendo
um mesmo sincronismo, como, por exemplo, testes devem ser realizados sempre que
novos requisitos forem levantados, testes devem ser aplicados sempre que esses novos
requisitos forem implementados. Este sincronismo entre as partes deve existir para que
no final do processo o produto resultante esteja em conformidade com as regras de
segurana estabelecidas.
Analisando os resultados verifica-se que ao desenvolver o sistema de
Informtica em Sade necessrio considerar as fases de engenharia de requisitos,
design, implementao e garantia, alm de cumprir todas as atividades especificadas em
cada fase de acordo com explicao de cada uma dessas atividades relacionadas ao
sistema de Informtica na Sade. Algumas das atividades explicadas podem ser
consideradas genricas para qualquer sistema de alto nvel segurana e outras atividades so
especificamente explicadas para a rea de Informtica na Sade. A meta principal do
desenvolvimento visa realizar a implementao de um sistema que tenha requisitos de
segurana especificados no inicio do projeto e que cumpra todas as necessidades de
segurana do sistema em desenvolvimento.

6. Concluso
Considera-se o tema do trabalho importante, pois a segurana na qual baseado
o processo de software e consequentemente o desenvolvimento de sistemas tem se
mostrado cada vez mais importante para a organizao, para os desenvolvedores e para
seus usurios.
A elaborao de nveis de segurana atravs de modelos encontrados na
literatura, que j tiveram uma aceitao da sociedade cientfica, alm de terem sido
criados por renomados autores auxilia na compreenso e na validao da eficcia de tais
modelos.
Para a deciso de quais modelos devem ser utilizados em cada empresa e cada
projeto, foi criado um esquema que permite ao gerente de projetos em conjunto com o
engenheiro de segurana uma avaliao de qual nvel deve ser utilizada, alm de dados
concretos que possam demonstrar a usurios de produto final porque um determinado nvel
de segurana foi escolhido.

A abordagem apresentada neste artigo explicada atravs de um estudo de cada

atividade aplicado em uma empresa desenvolvedora de softwares relacionados
informtica mdica, o qual possibilita o entendimento e a forma com que as atividades
relacionadas segurana podem ser implementadas.
Trabalhos futuros representam o projeto de uma dissertao de mestrado que est
em desenvolvimento e objetivam o desenvolvimento de um processo de software para
segurana baseado em requisitos gerais de segurana bem como da atribuio de nveis de
segurana baseados nesses requisitos de segurana.

7. Bibliografia
CARDOSO et al. (2009) Um Modelo de Controle Formal para o gerenciamento de
riscos de processo em fbricas de software. Publicado em: Anais do IX Simpsio
Brasileiro em Segurana da Informao e de Sistemas Computacionais
CERT
(2010),
Coordination
Center
Statics.
Disponvel
em:
www.cert.org/stats/cert_stats.html.
MEAD, NANCY R., LINGER R., MCHUGH J., LIPSON H., Managing Software
Development for Survivable Systems, Annals Software Eng., vol. 11, no. 1, 2001, pp.
45-78. BYERS, DAVID e SHAHMEHRI, NAHID (2007) Design of a Process for
Software Security Second International Conference on Availability, Reliability and
Security (ARES'07).
CAMPOS A., (2007) Sistema de segurana da informao - Controlando os riscos
Santa Catarina: Visual Books.
COMPAGNA L., KHOURY P., KRAUSOV A., MASSACCI F., ZANNONE N.
(2008) How to integrate legal requirements into a requirements engineering
methodology for the development of security and privacy patterns Publicado em:
Springer Science+Business Media
KHAN, Muhammad U. A., Zulkernine, Mohammad. Activity and Artifact Views of a
Secure Software Development Process. International Conference on Computational
Science and Engineering. , 2009, pp. 339- 404.
KHAN Muhammad U. A., Zulkernine, Mohammad. Quantifying Security in Secure
Software Development Phases Annual IEEE International Computer Software and
Applications Conference, 2008, pp. 905-960.
MEAD NANCY R., MCGRAW GARY, A Portal for Software Security, IEEE
SECURITY & PRIVACY, 2005, pp. 75-79.
NBR ISO/IEC 27001; Tecnologia da informao - Sistemas de gesto de segurana da
informao . Rio de Janeiro - RJ (2006)
NUNES, F. J. B. BELCHIOR, A. D., ALBUQUERQUE A. B. (2009) A knowledge
Management Aproach to Support a Secure Software Development Universidade de
Fortaleza - Fortaleza.
SBIS (2010) - Sociedade Brasileira de Informtica na Sade. Disponvel em:
http://www.sbis.org.br/
SOMMERVILLE I. (2007) Engenharia de software So Paulo: Pearson Addison Wesley.