TSDD - Teste de segurana durante o desenvolvimento

TSDD - Teste de segurana durante o desenvolvimento

Edmar Fernando da Cruz
Euler Divino Rodrigues Teixeira
Leonardo
Maykon Parreira Rodrigues
Ricardo Brando Gomes Mundim

Especializao em Segurana da Informao Junho de 2007

Uniminas Unio Educacional Minas Gerais Uberlndia, MG Brasil

Abstract. Information became a valuable and strategic assets. However it is

necessary to worry with the safety in the development of softwares with
the objective of guaranteeing the integrity and reliability. So that she get to
arrive to the closest of a software without flaw is necessary that tests are
accomplished during his/her implementation phase to verify that doesn't
possess none fails of vulnerability. However only the accomplishment of
tests of verification of flaws is not enough to guarantee the integrity and
reliability of a system, once it can happen human negligence, among
another you fail that might have passed unnoticed in the accomplished
tests. Therefore, it is necessary always this looking for new procedures
and mechanism of safety.
Resumo. Informao tornou-se um ativo valioso e estratgico. Porm
necessrio preocupar-se com a segurana no desenvolvimento de
softwares com o objetivo de garantir a integridade e confiabilidade. Para
que se consiga chegar ao mais prximo de um software sem falha
necessrio que sejam realizados testes durante a sua fase de
implementao para verificar que no possua nenhuma falha
vulnerabilidade. Entretanto, somente a realizao de testes de verificao
de falhas no so suficientes para garantir a integridade e a confiabilidade
de um sistema, uma vez que pode ocorrer negligncia humana, entre
outras falhas que podem ter passadas despercebidas nos testes
realizados. Por isso, necessrio sempre procurar novos procedimentos
e mecanismos de segurana.

1. Introduo

O desenvolvimento de sistemas com menor probabilidade a falhas

e com um nvel maior de segurana est a cada dia sendo mais
necessrio. Com a difuso da Internet possvel que diversas pessoas
possam explorar com maior facilidade e rapidez brechas de segurana

Pgina: 1
TSDD - Teste de segurana durante o desenvolvimento

nos sistemas. Sendo assim, trabalhar com o desenvolvimento orientado a

testes de segurana durante toda a fase de desenvolvimento, ser
possvel desde o incio do trabalho, garantir que o sistema atenda aos
requisitos necessrios de segurana. Neste trabalho sero mostrados
quais so os requisitos mnimos e as prticas de testes de segurana
necessrios para o desenvolvimento de um sistema seguro. Ser
mostrado que os testes exigem um bom planejamento e controle durante
a execuo, para que os mesmos venham a ser bem sucedidos. O
investimento em atividades de testes durante todo o processo garantir
um menor esforo ao final do desenvolvimento para a correo de
possveis falhas.
2 Requisitos de segurana
2.1 Aspectos de Segurana em Metodologias
O desafio de se construir softwares menos suscetveis a falhas de
seguranas um objetivo cada vez mais perseguido pelos
desenvolvedores.
Para apoiar esse cenrio, duas normas da ISO despontaram com
objetivos complementares. So as normas ISO/IEC 17799 (Code of
Practice for Information Security Management) e ISO/IEC 15408
(Evaluation Criteria for Information Technology on Technology Security
Evaluation). A primeira, por seu carter mais abrangente, serve de base
para elaborao e gerncia de uma poltica de segurana. A segunda
uma metodologia mais completa, no que tange ao desenvolvimento de
software, complementar, portanto, ISO/IEC 17799.
A abordagem da ISO/IEC 15408 [5], para a segurana a da
avaliao (ou investigao) do sistema. O Commom Criteria prope, alm
disso, a avaliao com um incremento progressivo na nfase dada ao
escopo, profundidade e ao rigor. Garantir a segurana de uma aplicao
trabalhar com a premissa que no existe segurana absoluta para
qualquer sistema informatizado. preciso identificar e definir as ameaas
segurana da aplicao e poltica de segurana. As ameaas podem
existir nos requisitos, na plataforma escolhida ou no ambiente de
desenvolvimento.[5]
2.2 Boas Prticas de Programao
Alguns cuidados precisam ser levados em considerao para
garantir a segurana de um sistema. As boas prticas de programao,
mesmo sem se considerar a segurana em si, garantem um cdigo mais
robusto, confivel e conseqentemente seguro. Cdigo seguro no
significa necessariamente segurana em cdigo ou cdigo que
implemente alguma funo para segurana, mas cdigo que escrito
para suportar os atacantes maliciosos. O cdigo seguro tambm cdigo
robusto.

Pgina: 2
TSDD - Teste de segurana durante o desenvolvimento

A necessidade de escrever cdigos capazes de resistir

perspiccia de atacantes sobremaneira importante devido a pouca
importncia que o tema desperta mesmo em organizaes que
supunham-se fortemente interessadas.[4] .

2.2.1 Testar o retorno de funes Sempre que se chamar uma

funo, seu retorno precisa ser verificado. Se uma parte do dado
for possivelmente suspeita, melhor seria apostar em uma
perspectiva de segurana e a assumir que usar esse dado traria
conseqncias graves. preciso atentar para a falha segura, isto
, encontrar a alternativa com menor impacto, que traga menos
risco.

2.2.2 - Documentar funes corretamente A correta documentao

da funo evita mal-entendido a respeito da interpretao da
mesma.

2.2.3 - Tratar as entradas de dados Todo dado informado, seja pelo

usurio ou outro sistema, deve ser tratado adequadamente,
mesmo que se acredite que todas as funes so intrinsecamente
seguras. Um cuidado a se ter com relao a caracteres
especiais. Identificar caracter malicioso permite, principalmente,
evitar que perpetre-se ataques como, por exemplo, SQL Injection e
Buffer Overflow. O SQL Injection explora caractersticas da
linguagem SQL que permite o uso de caracteres com funes
especiais, como comentrio.Como o cdigo aps # considerado
como comentrio e a condio 0=0 ser sempre verdadeira, o
comando geraria um retorno com todos os dados de todos os
logins.

2.2.4 - Ter uma poltica de verso consistente Uma poltica de

verso consistente, no importa se por uma gerncia de
configurao ou simplesmente backup, facilita a identificao de
problemas e, assim, a melhoria contnua do produto.

2.2.5 - Usar componentes e bibliotecas confiveis Toda segurana

e cuidado includo no cdigo pode ser comprometida com o uso de
bibliotecas ou sistemas auxiliares no-confiveis. Deve-se
assegurar que bibliotecas no comprometem a segurana do
sistema.

2.2.6 - Evitar informaes sensveis em arquivos temporrios Pelo

carter de ser temporrio, provavelmente o arquivo no foi objeto
de cuidados pertinentes segurana. Assim, deve-se evitar que
informaes sigilosas tornem-se vulnerveis restringindo seu uso
em arquivos dessa natureza.

Pgina: 3
TSDD - Teste de segurana durante o desenvolvimento

2.2.7 - No armazenar senhas e chaves criptogrficas no cdigo

Senhas e chaves criptogrficas em cdigos podem ser reveladas
atravs de engenharia reversa. O armazenamento de chaves
criptogrficas deve ser alvo de anlise criteriosa, assim como os
algoritmos empregados.

2.2.8 - Operar com o privilgio necessrio As aplicaes deveriam

rodar com o privilgio requerido para desempenhar suas tarefas.
Qualquer falha sria, como buffer overflow, comprometeriam menos se a
aplicao operasse com poucos privilgios.
3 Testes de segurana
3.1 Introduo
Os testes de segurana tem como finalidade auxiliar a garantir a
integridade e confiabilidade do software contra possveis falhas que
possam surgir durante a sua implementao e posteriormente durante a
sua utilizao. Uma forma de garantia de segurana atravs de testes
realizados e comprovados pelo cliente em laboratrios independentes.
Esses so os princpios da ISO/IEC 15.408 [2]:

Especificar a segurana de forma clara e objetiva;

Construir conforme a especificao;
Testar para verificar o atendimento da especificao original;
Alterao do ambiente;
Acrscimos e/ou excluses desautorizadas;
Negligncia humana;
Entre outras falhas.

A ISO define que testes de segurana visam garantir que o sistema

atende aos requisitos funcionais de segurana. Porm, os testes sozinhos
no so suficientes para garantir que o sistema faz somente aquilo a que
ele se prope, de maneira que comportamentos imprevistos podero
existir. A cobertura dos testes de segurana no pode ser confundida com
teste de cobertura. O objetivo da cobertura dos testes definir se os
testes realizados foram suficientes para demonstrar que o sistema
funciona conforme s especificaes. A profundidade que os testes tero
ser definida de acordo com o grau de exigncia estabelecido, isto , um
teste profundo permitir a descoberta de cdigos maliciosos inseridos
durante o desenvolvimento.

3.2 Avaliao de Vulnerabilidades no desenvolvimento

Avaliar vulnerabilidades abrange analisar a existncia de ameaas

passveis de explorao, a possibilidade de um mau uso do sistema ou de
sua configurao incorreta, a possibilidade de falhas dos mecanismos de

Pgina: 4
TSDD - Teste de segurana durante o desenvolvimento

segurana se expostos a fora e a explorao de quaisquer

vulnerabilidade eventualmente introduzidas durante o desenvolvimento ou
operao do sistema. Busca-se com a avaliao de vulnerabilidades
identificarem ameaas que possam afetar fatores como velocidade de
processamento, configurao do sistema ou da rede, capacidade de
memria e outros.
3.3 Importncia da fase de implementao de um software
Durante a fase de implementao a equipe de projeto codifica,
testa e integra todos os mdulos do software, nesta fase muito
importante ficar atento as falhas de segurana, para evitar possveis
vulnerabilidades. Para garantir uma vida segura para o software
necessrio seguir um ciclo durante a sua implementao, tal ciclo
composto por 4 variveis:

Empregar padres de codificao e teste

Empregar ferramentas de teste de segurana incluindo fuzzing
Empregar ferramentas de anlise esttica de cdigo
Revisar o cdigo

Essas fases devem ser seguidas a fim de manter o software o mais

ntegro e seguro.
3.4 Testes de Segurana
O desenvolvimento dirigido a teste parte do pressuposto que se um
cdigo for bem escrito, haver mais chance dele ser bem-sucedido, ao
contrrio que, se ele for mal escrito, haver mais chance dele ser mal-
sucedido. Uma boa engenharia responsvel por 20% de um projeto bem
sucedido.
Antes de se pensar em testes, algumas perguntas bsicas devem
ser feitas [1]:

O que se deseja com o teste?

Quando testar?
Como definimos qual lgica testar?
Como definimos qual dado testar?

Os testes podem ocorrer em diversos nveis. O primeiro nvel inclui

os testes de unidade, escrito pelos desenvolvedores. Os testes de
unidade so escritos antes do cdigo que os executa. O teste de unidade
avalia se uma pequena parcela da funcionalidade funciona como
esperado. Tudo que possa comprometer o sistema, devem ser testados.
Antes da dcada de 90, as atividades de testes geralmente eram
realizadas no fim do ciclo de desenvolvimento, normalmente pelos
prprios analistas de sistemas. A inteno era avaliar se o sistema

Pgina: 5
TSDD - Teste de segurana durante o desenvolvimento

funcionava e queria-se encontrar erros. No havia ainda tcnicas e nem

metodologias estruturadas de teste.
Com o tempo, a atividade de testar passou a fazer parte de um
processo independente do processo de desenvolvimento de software,
embora continuassem integradas. A criao de um processo
independente de teste demandou algumas necessidades de
metodologias, mtricas e de melhorias, que j existiam no processo
original, mas que precisavam estar adaptadas para o novo.

O modelo de processos para conduo e realizao de testes em

todas as etapas do desenvolvimento de sistema visa garantir padres e
qualidade no produto final. O principal objetivo reduzir erros no processo
de desenvolvimento, atuando das atividades iniciais (requisitos) at a
homologao do produto. Os testes dividem-se basicamente em:

Testes de Verificao
Processo de avaliao de documentos e informaes coletadas em
cada fase do processo de desenvolvimento do software.

Verificao de Requisitos: Garantir a qualidade das informaes

geradas durante o processo de levantamento, anlise e
especificao de requisitos.
Verificao da Modelagem Funcional: Avaliar se todos os
requisitos identificados foram incorporados na modelagem
funcional.
Verificao da Modelagem Interna: Avaliar se os diagramas da
modelagem interna traduzem todos os aspectos da modelagem
funcional, assim como, analisar a estrutura dos dados.
Verificao de Cdigo: Garantir que os cdigos fonte obedecem
as normas e padres determinados pela organizao.

Testes de Validao
Processo de avaliao de um sistema ou seus componentes,
visando garantir a qualidade do produto final.

Validao de Unidade: Garantir que as diversas unidades do

software esto contempladas na totalidade de linhas de cdigo.
Validao de Integrao: Garantir que os diversos componentes
do software no apresentem erros quando integrados.
Validao de Funcionalidade: Garantir que no existam
diferenas entre os requisitos funcionais e o comportamento do
software.

Pgina: 6
TSDD - Teste de segurana durante o desenvolvimento

Validao de Sistemas: Detectar erros de natureza no

funcional, certificando-se que o comportamento est de acordo
com os requisitos especificados. Seu propsito testar os
requisitos tecnolgicos, entre eles:
o Carga e Stress determinar o limite mximo de carga e
stress que o software poder suportar;
o Configurao identificar e testar as configuraes de
software e hardware;
o Segurana identificar formas de quebra de segurana
do software;
o Desempenho (performance) determinar se o
desempenho em situaes normais e de pico esto em
conformidade aos requisitos de desempenho
especificados;
o Confiabilidade e disponibilidade determinar as medidas
de confiabilidade e disponibilidade do software;
o Recuperao avaliar o comportamento do software
aps a ocorrncia de um erro ou outras condies
anormais;
Validao de Usabilidade: Garantir que os requisitos de
usabilidade (acesso, navegao, clareza de informaes e
terminologia adequada) estejam sendo cumpridos e conforme
s especificaes.
Validao de Aceite: Permitir ao cliente executar testes,
validando as categorias de testes aplicadas anteriormente
(funcionalidade, usabilidade e sistemas), reduzindo os riscos na
implantao em produo.

Os mtodos de testes so basicamente os seguintes:

Mtodo Caixa-Branca Tcnica utilizada para determinar

defeitos nas estruturas internas dos programas.
Mtodo Caixa-Preta Tcnica utilizada para garantir que os
requisitos de negcios esto plenamente satisfeitos.

Alguns modelos de avaliao da maturidade do processo de testes

foram criados nos ltimos anos. Alguns, como o TPI (Test Process
Improvement), so mais usados na Europa e outros como, o TMM (Teste
Maturity Model) e TCMM (Test Capability Maturity Model), so mais
populares nos Estados Unidos. Existem esforos no sentido de integrar os
modelos de maturidade de teste, como o TMM, com os modelos de
maturidade da capacitao para software como o CMMI.
3.5 Concluso
A segurana em desenvolvimento no apenas mais uma fase do
sistema, e sim uma parte importante do sistema, pois a integridade e

Pgina: 7
TSDD - Teste de segurana durante o desenvolvimento

confiabilidade, no depende s do processo de desenvolvimento, mas

como de todo o sistema em um s conjunto. Contudo, necessrio
lembrar que um ambiente seguro e estvel sempre pode ser alvo de falha,
por isso no podemos deixar de lado a segurana.
4 Concluso
4.1 Introduo
Este artigo apresentou meios para o desenvolvimento de software
seguro aps ter sido revisado a literatura nas reas de engenharia de
software e segurana da informao. Os meios consistem-se na
adequao dos processos de melhoria da qualidade aos requisitos de
segurana, criao de projetos arquiteturais genuinamente seguros e
aculturao organizacional de prticas de gerncia voltadas segurana.
4.2. Concluso e contribuio
O aumento significativo da importncia dada segurana da
informao requer que sejam definidos e implementados mecanismos
mais eficientes para apoiar as atividades que envolvam segurana da
informao. Com isso, o objetivo deste trabalho foi apresentar tcnicas,
metodologias, modelos e prticas que apoiassem o desenvolvimento de
software seguro. As contribuies dessa abordagem so:

Destacar aspectos de segurana em metodologias tradicionais de

melhoria da qualidade;

Salientar a diferena entre segurana e qualidade;

Apresentar fatores importantes para constiturem ambientes de

desenvolvimento seguro;
Discorrer sobre metodologias dirigidas segurana da informao;

Relacionar requisitos de segurana fundamentais;

Especificar tcnicas determinantes para a criao de projeto

arquitetural seguro;

Mostrar particularidades que aperfeioam questes de segurana na

conduo do desenvolvimento de software.

4.3 Perspectivas futuras

Como perspectiva a engenharia de software seguro apresentada
neste artigo pretende apoiar todos que desejam aperfeioar os processos
de desenvolvimento de software para a obteno de produtos mais
seguros.

Pgina: 8
TSDD - Teste de segurana durante o desenvolvimento

Com o propsito de melhorar e estender a proposta apresentada,

diversos trabalhos podem ser definidos e desenvolvidos , tais como:

Planejamento das etapas para desenvolvimento de software seguro

apresentado atravs da formulao de documentao (artefatos)
para as fases especificadas e comparao desse modelo com
outros;

Proposio de um novo modelo de ciclo de vida para

desenvolvimento de software seguro;

Criao de um framework para apoiar a aplicao dos requisitos

funcionais de segurana;

Formulao de padres de desenvolvimento que suportem, se no

todos, alguns dos requisitos funcionais de segurana citados;

Desenvolvimento de ferramentas de gerncia para desenvolvimento

de softwares aderentes norma ISO/IEC 15408;

Elaborar contedo pedaggico para capacitao de recursos

humanos (desenvolvedores, arquitetos e engenheiros de software)
em segurana da informao;

5 Referncia

[1] BECK, K. Test-Driven Development by Example, Addison Wesley,

2002.

[2] ISO/IEC 15408-1:1999 Information Technology Security Techniques -

Evaluation Criteria for IT Security - Part 2: Security Functional
Requirements, ISO Online Catalogue, 1999.

[3] https://www.technetbrasil.com.br (Norma 17799). ltimo acesso em

19/06/2007.

[4] Magazine Portal, Mdulo Security, http://www.modulo.com.br, 2005.

ltimo acesso em 18/06/2007.

[5] ISO/IEC 15408-1:1999 Information Technology Security Techniques -

Evaluation Criteria for IT Security Part 3: Security Assurance
Requirements, ISO Online Catalogue, 1999.

Pgina: 9