PS GRADUAO LATO SENSU EM ENGENHARIA DE SOFTWARE

ENGENHARIA DE SOFTWARE SEGURO (Segurana em Desenvolvimento de Software)

Monografia apresentada em cumprimento s exigncias para obteno de grau no curso de ps-graduao lato sensu de especializao em Engenharia de Software.

Por: Renato Pessanha da Silva

Rio de Janeiro 2005

DEDICATRIA

Aos

meus

pais,

por tudo. pela

Especialmente estudar.

oportunidade que me deram de

ii

AGRADECIMENTOS

Primeiramente a Deus, pelas condies para realizar esse trabalho. A Marcele pelo inestimvel estmulo e ajuda. A Werther e Mnica pela fraterna colaborao. A Celso e Srgio Lima pelo apoio em trabalhos. A Pecegueiro e Lavelle pelo auxlio no levantamento da literatura. A Ctia pela orientao. Aos demais colegas de turma e professores aprendizado. pelo ano de

iii

EPGRAFE

Sou um tcnico, mas tenho tcnica s dentro da tcnica. Fora disso sou doido, com todo o direito a s-lo. Com todo o direito a s-lo, ouviram? Fernando Pessoa

iv

RESUMO
Informao tornou-se um ativo valioso e estratgico. A chamada era da informao, caracterizada principalmente pela incluso digital e disseminao da Internet, a disponibilizou em um volume significativo e sem precedente na histria. No tardou para que a apario de ameaas confidencialidade, integridade e disponibilidade comprometessem a tendncia inicial de expanso. Os processos de melhoria da qualidade no resultaram no desenvolvimento de produtos mais seguros e duas vertentes desarmnicas engenharia de software e segurana da informao tm trabalhado de forma suplementar e isolada para atenuar os danos decorrentes das vulnerabilidades. Esse trabalho investiga formas para capacitar organizaes desenvolvedoras a unir engenharia de software e segurana da informao para a produo de software naturalmente seguro.

ABSTRACT
Information became a valuable and strategic asset. The so called information era, mainly represented by digital inclusion and dissemination of Internet, made available a significant volume of information without precedent in history. It did not take that much to appear threats to confidentiality, integrity and availability to compromise the initial widespread trend. The quality improvement processes have not resulted in the development of safer products and two disharmonic trends software engineering and information security have worked in a supplemental and isolated form to attenuate the damages caused by vulnerabilities. This work investigates forms of enabling software development organizations to join both software engineering and information security to naturally produce secure software.

vi

SUMRIO

DEDICATRIA ............................................................................................................................................. II AGRADECIMENTOS ..................................................................................................................................III RESUMO .........................................................................................................................................................V ABSTRACT ................................................................................................................................................... VI SUMRIO.....................................................................................................................................................VII IINTRODUO ................................................................................................................................... 7 1.1. MOTIVAO ............................................................................................................................................ 7 1.2. OBJETIVO ................................................................................................................................................ 9 1.3. METODOLOGIA DO TRABALHO ................................................................................................................ 9 1.4. ESTRUTURA DO TEXTO ...........................................................................................................................10 II ENGENHARIA DE SOFTWARE SEGURO...................................................................................11 2.1. INTRODUO ..........................................................................................................................................11 2.2. CRISE DO SOFTWARE ..............................................................................................................................12 2.3. ENGENHARIA DE SOFTWARE ..................................................................................................................13 2.3.1. Requisitos .......................................................................................................................................14 2.3.2. Metodologia....................................................................................................................................16 2.3.3. Aspectos de Segurana em Metodologias.......................................................................................16 2.4. DIFERENA ENTRE SOFTWARE SEGURO E DE QUALIDADE......................................................................20 III GARANTIA DE SEGURANA........................................................................................................21 3.1. INTRODUO ..........................................................................................................................................21 3.2. AMBIENTE SEGURO DE DESENVOLVIMENTO ...........................................................................................21 3.2.1. Gerncia de Configurao .............................................................................................................22 3.2.2. Distribuio....................................................................................................................................22 3.2.3. Desenvolvimento.............................................................................................................................23 3.2.4. Documentao................................................................................................................................23 3.2.5. Suporte ao Ciclo de Vida................................................................................................................24 3.2.6. Testes de Segurana .......................................................................................................................24 3.2.7. Avaliao de Vulnerabilidades.......................................................................................................24 3.3. NORMA ISO/IEC 17.799 ........................................................................................................................25 3.4. NORMA ISO/IEC 15.408 ........................................................................................................................27 3.5. CICLO DE VIDA DE DESENVOLVIMENTO SEGURO ...................................................................................30 3.5.1. O Processo .....................................................................................................................................32 3.5.2. Viso Geral.....................................................................................................................................33 3.5.3. Fase Requisitos (Requirements) .....................................................................................................34 3.5.4. Fase de Design ...............................................................................................................................35 3.5.5. Fase de Implementao ..................................................................................................................36 3.5.6. Fase de Verificao ........................................................................................................................37 3.5.7. Fase de Liberao ..........................................................................................................................38 3.5.8. Fase de Manuteno (Support and Servicing) ...............................................................................38 IV REQUISITOS FUNCIONAIS DE SEGURANA ..........................................................................40 vii

4.1. INTRODUO ..........................................................................................................................................40 4.2. AUDITORIA .............................................................................................................................................41 4.3. COMUNICAO - REPDIO .....................................................................................................................43 4.4. CRIPTOGRAFIA .......................................................................................................................................44 4.5. PROTEO DE DADOS DO USURIO .........................................................................................................47 4.6. IDENTIFICAO E AUTENTICAO .........................................................................................................52 4.7. GERENCIAMENTO DE SEGURANA ..........................................................................................................54 4.8. PRIVACIDADE .........................................................................................................................................55 4.9. AUTOPROTEO .....................................................................................................................................56 4.10. UTILIZAO DE RECURSOS ...................................................................................................................58 4.11. CONTROLE DE SESSES ........................................................................................................................59 4.12. CANAIS SEGUROS .................................................................................................................................60 VARQUITETURA DE SOFTWARE SEGURO ................................................................................62 5.1. INTRODUO ..........................................................................................................................................62 5.2. BOAS PRTICAS DE PROGRAMAO.......................................................................................................64 5.3. PADRES DE DESENVOLVIMENTO ...........................................................................................................68 5.4. TESTES DE SEGURANA..........................................................................................................................70 VI GESTO DO DESENVOLVIMENTO DE SOFTWARE SEGURO ............................................75 6.1. INTRODUO ..........................................................................................................................................75 6.2. MTRICA DE SEGURANA ......................................................................................................................76 6.2.1. Superfcie de Ataque.......................................................................................................................76 6.2.2. Outras Mtricas..............................................................................................................................79 6.3. MONITORIZAO DE VULNERABILIDADES .............................................................................................80 6.3.1. Divulgao de Vulnerabilidade ......................................................................................................81 6.3.2. Resposta a incidentes......................................................................................................................82 6.4. COMPORTAMENTO SEGURO ....................................................................................................................84 VII - CONCLUSO .......................................................................................................................................87 7.1. INTRODUO ..........................................................................................................................................87 7.2. CONCLUSO E CONTRIBUIO................................................................................................................87 7.3. PERSPECTIVAS FUTURAS.........................................................................................................................88 VIII - REFERNCIAS...................................................................................................................................90

viii

I - INTRODUO
1.1. Motivao
A necessidade de adequar a engenharia de software s tcnicas e aos processos que facilitem ou viabilizem o desenvolvimento de software seguro1, desponta como uma das formas mais eficazes de reduzir os efeitos das vulnerabilidades, sem prescindir da qualidade e melhoria contnua dos projetos. A engenharia de software desenvolveu mtodos para a elaborao de sistemas de misso crtica, mas tardou em investigar as razes pelas quais sistemas sem esse rtulo os supostamente simples tornassem-se alvos ou meios de ataques. A difuso da Internet facilitou a explorao remota de brechas de segurana muitas vezes contidas em sistemas considerados inofensivos durante o desenvolvimento. A preferncia no por acaso e nem d-se necessariamente pelo valor dos ativos que manipulam, mas pela conveniente desateno despertada mesmo se operarem de forma suspeita ou irregular. Desateno compartilhada pelos desenvolvedores2, que tendem a no preocuparem-se com segurana se o sistema no a listar como requisito funcional. Sistemas insuspeitos so mais propensos a incoporar falhas de design que podem servir para o seu comprometimento ou de outros. O distanciamento entre desenvolvedores e profissionais de segurana percebido at na questo educacional. Geralmente, desenvolvedores no dominam assuntos relacionados a segurana da informao, que majoritariamente constituda de profissionais oriundos das reas de infra-estrutura e redes (networking) [TOMELLI 2004].
1

Segurana pode ser decomposta em vrios aspectos distintos, porm complementares. Entre os aspectos mais importantes esto confidencialidade, integridade e disponibilidade. Programador, analista de sistemas, testador, engenheiro e arquiteto de software so termos usados indistintamente nesse trabalho e o seu conjunto chamado de desenvolvedor. Porm, em alguns momentos, desenvolvedor representar programador e analista de sistemas. 7

A engenharia de software foi eficaz na criao e aperfeioamento de metodologias que permitissem o desenvolvimento de sistemas seguros sendo segurana um atributo de qualidade , porm a prtica demonstra que a cultura de segurana no foi assimilada totalmente ou os processos e arquiteturas no foram aplicados maioria dos projetos para a gerao de produtos conceitualmente seguros ou o mais prximo disso, dado que segurana total considerada como inalcanvel. O xito dessas metodologias retringemse aos sistemas denominados crticos aqueles que prevem segurana como um requisito essencial. Normas especficas para avaliar a segurana foram criadas, mas sua aplicao tambm tem, aparentemente, sido restrita a sistema de misso crtica. A capacitao da engenharia de software no se traduziu em projetos livres de falhas conceituais. Um exemplo [DEAN 1996] que ilustra a falta de perspiccia na falta de termo que melhor defina dos desenvolvedores, foi o ataque de spoofing [SPYMAN 1998] verificado em verses antigas do Netscape Navigator. Para assegurar que um applet s se conectasse ao seu servidor de origem, implementou-se uma validao baseada na checagem de dois endereos: o de origem do applet e o de destino da conexo. Sendo n2a uma relao que mapeia IP (Internet Protocol) para nome, X o nome do servidor de origem do applet e Y o servidor ao qual se deseja conectar; se houver uma interseo entre os endereos IP, ento pode se assumir que X e Y so do mesmo servidor. if n2a(X) n2a(Y) then x n2a(X) y n2a(Y) tal que connect(x, y) O modelo descrito espera por dois endereos como parmetros de origem e destino. A falha permitia que applets se conectassem a mquinas distintas das suas de origens, passando-se o parmetro de destino tambm como de origem. A correo da Netscape foi armazenar o endereo IP (i) do servidor de origem, eliminando a primeira verificao, e mudar a checagem de interseo para associao: i n2a(Y).
8

Manifestaes sobre a importncia da readequao da engenharia de software aumentam e a comunidade da engenharia de software comea a formular processos que concebam sistemas naturalmente seguros. Assim, a engenharia de software precisa precaver-se para no mais suscitar sistemas inseguros, independente da classificao que lhe conferida, no importando, portanto, necessariamente o quo crtico o , mas assegurando o quo robusto constitui-se. Nesse sentido, abordar questes que permitam desenvolver sistemas mais seguros pode incorrer no desenvolvimento de software de melhor qualidade.

1.2. Objetivo
O presente trabalho tem como objetivo apresentar meios que auxiliem no desenvolvimento de sistemas conceitualmente seguros para que a engenharia de software possa, por meio de processos repetveis e tcnicas padronizveis, colaborar com a elaborao de sistemas menos suscetveis s vulnerabilidades atuais e futuras. Para isso, so discutidas tcnicas, metodologias, modelos e prticas que podem permitir a elevao do nvel de maturidade para patamares satisfatrios, congregando qualidade e segurana como fatores essenciais e indissociveis.

1.3. Metodologia do trabalho

Inicialmente, para a realizao desse trabalho, foram identificados na literatura as tcnicas e procedimentos considerados fundamentais para o desenvolvimento de softwares seguro. Por elas, foi possvel estabelecer um conjunto mnimo de requisitos de segurana que, se no eliminam, visam diminuir as vulnerabilidades e aprimorar a qualidade do produto.

Em seguida, foram levantadas na literatura as metodologias de qualidade mais empregadas na engenharia de software. As metodologias englobam, mas no se restringem a, normas e procedimentos relacionados ao processo de desenvolvimento ou avaliao de software. Alm das metodologias, pesquisou-se a profundidade na qual o tema segurana tratado na literatura tradicionalmente acadmica. Posteriormente, identificou-se na literatura quais iniciativas existiam que envolvessem a comunidade da engenharia de software e segurana da informao. Nessa etapa foi possvel identificar iniciativas que investigavam ou implementavam aspectos de segurana da informao e engenharia de software de forma integrada. Finalmente, foi formulado um plano de estudo que englobasse trs fases de um ciclo de vida de software, mais especificamente que abordasse aspectos de requisitos, arquitetura e teste. Paralelamente, pesquisou-se maneiras que pudessem amadurecer a cultura organizacional sobre segurana, envolvendo questes como capacitao de pessoal e ambiental.

1.4. Estrutura do texto

O captulo I descreve a motivao, objetivos e metodologia do trabalho, alm da organizao da monografia. A reviso da literatura sobre engenharia de software com destaque para segurana da informao apresentada no captulo II. As formas para garantir segurana no processo de desenvolvimento de software e reviso da literatura pertinente a segurana no desenvolvimento de software so discutidos no captulo III. O captulo IV apresenta uma relao de requisitos funcionais de segurana a serem considerados nos projetos. O captulo V apresenta um conjunto de tpicos importantes para a formulao de um projeto arquitetural de software seguro, incluindo boas prticas de prticas de programao, padres de desenvolvimento e testes. Algumas consideraes sobre itens importantes para a gerncia e cultura organizacional so apresentadas no captulo VI. Em seguida, apresentada a listagem das referncias bibliogrficas utilizada.
10

II - ENGENHARIA DE SOFTWARE SEGURO

2.1. Introduo
O desenvolvimento de software no uma atividade trivial. O grau de incerteza das partes interessadas alto e a forma artesanal na qual sempre foi tratada ainda persiste em um significativo nmero de organizaes. Desde a dcada de 1980, com o avano da microeletrnica, os softwares tornaram-se fatores de maiores preocupaes na medida em que seu custo de desenvolvimento superava o do hardware empregado [MENDES 2002]. A dependncia em escala crescente deixou ainda mais patente o ambiente catico que envolve o desenvolvimento, levando ao fracasso um nmero significativo de projetos [YOURDON 1999]. A soluo encontrada para melhorar a qualidade e reduzir o custo de produo foi a introduo da disciplina de desenvolvimento conhecida como engenharia de software. A engenharia de software rene metodologias, que por sua vez seguem mtodos que se utilizam de ferramentas automatizadas para englobar as principais atividades do processo de produo de software [CARVALHO 2001]. Os benefcios das metodologias no processo de desenvolvimento no aparentam ser motivos de discrdia, porm os mtodos institudos objeto freqente de questionamento [YOURDON 1999], resultando em novas metodologias cujo aperfeioamento, contribui, de alguma forma, para a evoluo da engenharia de software de forma geral. Antes, porm, de discutir as alternativas para disciplinar o desenvolvimento de software para que gerasse produtos com qualidade e segurana, faz-se necessrio compreender as motivaes que levaram ao surgimento da engenharia de software.

11

2.2. Crise do software

Nas dcadas de 1960 e 1970, o desafio primordial era desenvolver hardware que reduzisse o custo de processamento e de armazenamento de dados [PRESSMAN 1992]. As dcadas seguintes foram as que tiveram um avano significativo da microeletrnica [CARVALHO 2001], tornando o custo do hardware e armazenamento inferior ao do software. Na dcada de 1960, os custos com hardware representavam mais de oitenta por cento do custo total, enquanto, atualmente, estima-se que sejam aproximadamente dez por cento do custo total. Nos primrdios o desenvolvimento de software era uma atividade puramente artesanal. Como conseqncia, errava-se constantemente nas estimativas de custos e tempo, os sistemas desenvolvidos continham muitos erros e, consert-los geralmente produziam novos. Esse o cenrio vigente desde a chamada Crise do Software [BARROS 2002]. A crise do software tem sido agravada pela disseminao do uso de software em todas as atividades humanas, das industriais, de servios e at de entretenimento [CRTES 2001]. O advento da Internet, o avano nas telecomunicaes e a necessidade de integrao com outros sistemas revelaram novos desafios entre os quais se destaca a necessidade de garantir a segurana nos softwares atuais e uma plataforma segura para os futuros. As prioridades dos softwares comerciais tm mudado desde a dcada de 1990 [GOSLIN 1997]. Houve uma inverso de prioridades nos ltimos anos [PEDRYCZ 2001], que justifica-se a medida que os produtos eletrnicos para o consumidor final tornaram-se prioritrios para a indstria. Software Comercial Compatibilidade Desenvolvimento Portabilidade Confiabilidade Processamento em Rede Multithreading Segurana
12

Produtos Eletrnicos Segurana Processamento em Rede Portabilidade Confiabilidade Desempenho Multithreading Compatibilidade

Segurana

transformou-se

um

fator

relevante

para

as

organizaes

desenvolvedoras, justificado pelo crescente aumento no nmero de ataques a vulnerabilidades presentes nos softwares por elas criados.

2.3. Engenharia de Software

O software tornou-se uma tecnologia-chave usada em vrias reas, de aplicaes financeiras e comerciais a aplicaes complexas, como controle de usinas de energia e misses espaciais. Gradualmente, transformou-se na fora prevalecente em termos de inovao tecnolgica. Usar princpios de engenharia no intuito de produzir, a baixo custo, softwares que operem de maneira correta e eficientemente nos equipamentos que forem instalados, levaram ao surgimento da Engenharia de Software, termo cunhado em uma conferncia seminal do NATO em Garmisch, Alemanha, em 1968 [NAUR 1969, MENDES 2002]. Carvalho et al. [CARVALHO 2001] define que "a engenharia de software uma disciplina que rene metodologias, as quais so compostas por mtodos que se utilizam de ferramentas automatizadas, para viabilizar a produo, da percepo do problema at o momento em que o sistema desenvolvido deixa de ser operacional, visando resolver problemas inerentes ao processo de desenvolvimento e ao produto de software, enfrentando os efeitos advindos com o que se denominou crise do software". A demanda por funes cada vez mais sofisticadas nos software tem tambm crescido de forma consistente, o que leva a um aumento na complexidade de desenvolvimento, com conseqente aumento do custo. So muitos os problemas a ser tratados pela engenharia de software, pois tanto o processo quanto o produto possuem vrios atributos que devem ser considerados para que se tenha sucesso, como a complexidade, a visibilidade, a aceitabilidade, a confiabilidade, a
13

manutenibilidade, a segurana etc. Por exemplo, para a especificao de sistemas de controle de trfego areo e ferrovirio, a confiabilidade um atributo fundamental [FARINES 2000]. Vrios princpios podem ser aplicados durante toda a fase de desenvolvimento [GUEZZI 1991]. So princpios que referem-se tanto ao processo como ao produto final e descrevem algumas de suas prioridades. Carvalho et al. [CARVALHO 2001] afirma que "o processo correto ajudar a produzir o produto correto, e o produto almejado tambm afetar a escolha do processo a ser utilizado". A engenharia de software necessita de mecanismos para controlar o processo de desenvolvimento e estabelecer a base para produzir, de forma eficiente, software que satisfaa os requisitos preestabelecidos, que so os paradigmas. Os paradigmas especificam atividades que devem ser executadas, assim como a ordem de execuo [CARVALHO 2001].

2.3.1. Requisitos
A engenharia de software no limita-se aos programas de computador, mas envolve tambm toda a documentao necessria para instalao, uso, desenvolvimento e manuteno do sistema. A necessidade de lidar com softwares cada vez maiores e mais complexos, tornou a tcnica de abstrao um meio eficaz de reconhecer padres, analisar e especificar sistemas. Avaliar a qualidade de um software requer a identificao de requisitos considerados importantes constar em um bem projetado. E a complexidade determinada por seus requisitos funcionais o que ele faz e por requisitos no-funcionais como ele faz [MENDES 2002]. Requisito funcional cada requisito que especifica uma funo que deve ser realizada. So requisitos que definem o comportamento de sistema, isto , o processo ou transformao que componentes de software ou hardware efetuam sobre as entradas para gerar as sadas [THAYLER 1990].

14

Requisito no-funcional descreve no o que o software far, mas como far. Assim, por exemplo, temos requisitos de desempenho, requisitos da interface externa, restries de projeto e requisitos da qualidade. Requisitos no-funcionais so difceis de testar. Portanto, eles geralmente so avaliados de maneira subjetiva [THAYLER 1990].

Os

requisitos

funcionais

no-funcionais

possuem

importncia

no

desenvolvimento de um sistema. Os requisitos no-funcionais tm papel relevante por servir de critrio na seleo e/ou composio de uma arquitetura de software. O termo requisito no-funcional recebe, muitas vezes, denominaes diferentes de autores. tambm chamado de atributos de qualidade [BOEHM 1978, KELLER 1990] e requisitos no-comportamentais [DAVIS 1993]. No consider-los adequadamente reconhecidamente dispendioso e de difcil correo, pois o sistema j estar concludo para que possa-se corrigir [BROOKS 1987]. A arquitetura escolhida para um projeto de software deve atender a um conjunto de requisitos no-funcionais elicitados, considerados essenciais ao sistema. Algumas propostas de classificao dos requisitos no-funcionais surgiram como o caso do padro IEEE-Std 830-19933 [IEEE 1993]. Esse padro lista um conjunto de treze requisitos nofuncionais a serem considerados no documento de especificao de requisitos. Relaciona, entre outros, requisitos de desempenho, confiabilidade, portabilidade e segurana, similarmente proposta de classificao apresentada por Boehm [BOEHM 1976]. Tambm existe e discutida em Roman [ROMAN 1985] uma diversidade de requisitos no-funcionais. Algumas propostas de classificao de requisitos no-funcionais so

complementares. A classificao de Sommerville4, na qual feita a distino entre

3

Reviso da publicao de 1984 (Guide to Software Requirements Specifications). Uma nova reviso foi publicada em 1998 (IEEE Std 830-1998). A classificao apresentada em Sommerville (1996) ainda considera os requisitos de processo e requisitos externos como sendo os requisitos no-funcionais, alm dos requisitos de produtos. 15

requisitos externos, de produto e de processo [SOMMERVILLE 1992]; foi estendida por Mendes [MENDES 2002].

2.3.2. Metodologia
Uma metodologia de desenvolvimento de software detalha as atividades do ciclo de vida, especificando um conjunto nico e coerente de princpios, mtodos, linguagem de representao, normas, procedimentos e documentao, que permite ao desenvolvedor implementar sem ambigidade as especificaes advindas das fases do ciclo de vida. A modelagem de um sistema uma forma econmica de estudar aspectos essenciais antes de constru-lo. Para cobrir as fases diferentes do desenvolvimento, uma metodologia deve valer-se de mtodos e ferramentas de maneira que seja possvel conduzir: A fase de anlise de requisitos, para que a especificao resultante represente um modelo consistente dos requisitos do sistema (modelo do mundo real); A fase de projeto, de modo a produzir o modelo interno; Planejamento do projeto, que objetiva produzir o plano do projeto, no qual sero representadas as alternativas para a soluo do problema, os riscos considerados, as decises tomadas, alm da estimativa de tempo, custo e recursos para o desenvolvimento do sistema.

2.3.3. 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. Aqueles que j dispem de um processo de desenvolvimento bem definido, no necessariamente formal, podem amadurecer ao ponto de desenvolverem um processo no qual segurana seja considerado um fator crtico [ALBUQUERQUE 2002]. No significa que resultados to bons no
16

possam ser alcanados por equipes com nvel de maturidade inferior, necessitando, para isso, que o grau de superviso seja aumentado e seguidos os atributos de garantia de segurana. Algumas normas, procedimento e modelos de maturidade foram propostos e seu uso intensificado medida que percebe-se a necessidade de amadurecer e evoluir o processo de desenvolvimento. As normas mais recentes e comumente empregadas pela indstria de software, incorporam aspectos de segurana em seus tpicos. NBR ISO/IEC 12207 A NBR ISO/IEC 12207 apresenta processos de ciclo de vida para adquirentes, fornecedores, desenvolvedores, operadores e mantenedores de produtos de software. Os processos so divididos em atividades, as quais so, por sua vez, divididas em tarefas. A norma composta de cinco processos fundamentais, oito processos de apoio e quatro processos organizacionais. A NBR ISO/IEC 12207:1998 equivalente ISO/IEC 12207:1995 [NBR ISO/IEC 12207]. A segurana definida como "proteo de informaes e dados de modo que pessoas ou sistemas no autorizados no possam l-los ou modific-los e que pessoas ou sistemas autorizados no tenham acesso negado a eles". A definio cobre os trs aspectos principais da segurana: integridade, confidencialidade e disponibilidade [ALBUQUERQUE 2002]. Dos cinco processos cobertos pela norma, apenas o de operao no faz referncia segurana. A NBR ISO/IEC 12207 orienta seus usurios a proceder com sua aplicao criteriosamente. Nesse sentido, delegar s normas mais especializadas tarefas que lhes so mais apropriadas uma prtica recomendada. Por exemplo, o processo de fornecimento guia o seu planejamento a desenvolver planos de proteo e segurana (5.2.4.5e), ao qual a norma ISO/IEC 15408 [ISO/IEC 15408] pode ser mais apropriada para avali-lo, e a

17

atender ao especificado na poltica de segurana a que se submete o projeto, cuja norma NBR ISO/IEC 17799 [ISO/IEC 17799] pode auxiliar a atingir melhores resultados. O aspecto generalista da NBR ISO/IEC 12207 no negligencia a segurana. A existncia na norma das atividades de codificao e testes de software (5.3.7), que pode ser utilizado no processo de verificao (6.4) ou de validao (6.5), evidencia sua tendncia a abordar o tema com a importncia necessria. Entretanto, a justificativa sobre a implementao de processo de verificao submetida a fatores como o risco potencial que um erro causaria e disponibilidade financeira, demonstrando as restries que a segurana enfrenta para ser integrada aos projetos no considerados crticos. NBR ISO/IEC 9126 A NBR ISO/IEC 9126 cancela e substitui a NBR 13596:1996. Seu objetivo descrever um modelo de qualidade do produto de software. A NBR ISO/IEC 9126 "permite que a qualidade do produto de software seja especificada e avaliada em diferentes perspectivas pelos envolvidos com aquisio, requisitos, desenvolvimento, uso, avaliao, apoio, manuteno, garantia de qualidade e auditoria de software. Ela pode, por exemplo, ser utilizada por desenvolvedores, adquirentes, pessoal de garantia de qualidade e avaliadores independentes..." [NBR ISO/IEC 9126]. Se usada junto com a NBR ISO/IEC 12207, pode fornecer "uma estrutura para definio de requisitos de qualidade de software, nos processos fundamentais do ciclo de vida" alm de apoiar a reviso, verificao e validao. O modelo de qualidade externa e interna dividido em seis caractersticas: funcionalidade, confiabilidade, usabilidade, eficincia, manutenibilidade e produtividade. As caractersticas so subdivididas em subcaractersticas, as quais podem ser medidas por mtricas externas e internas. A trade integridade, confiabilidade e disponibilidade so contempladas nas subcaractersticas. A subcaracterstica segurana de acesso pertencente caracterstica funcionalidade definida como a "capacidade do produto de software de proteger informaes e dados, de forma que, pessoas ou sistemas no autorizados no
18

possam l-los nem modific-los e que no seja negado o acesso s pessoas ou sistemas autorizados". Embora haja a aluso dessa definio ser proveniente da NBR ISO/IEC 12207, ela "no corresponde literalmente traduo da NBR ISO/IEC 12207, nem ao texto original em ingls", conforme destaque na prpria NBR ISO/IEC 9126. A despeito das definies, a NBR ISO/IEC 9126 salienta que a definio se aplica tambm aos dados em transmisso e que "segurana definida como uma caracterstica de qualidade em uso, j que ela no est relacionada somente com o software, mas com o sistema como um todo". A caracterstica confiabilidade pondera que "disponibilidade a capacidade de um programa de software de estar pronto para executar uma funo requisitada num dado momento, sob condies especificadas de uso. Externamente, a disponiblidade pode ser avaliada pela proporo do tempo total durante o qual o produto de software est disponvel. A disponibilidade , portanto, a combinao de maturidade (a qual controla a freqncia de falhas), tolerncia a falhas e recuperabilidade (a qual controla o perodo de tempo inativo aps cada falha). Por esta razo ela no foi includa como uma subcaracterstica distinta". O modelo de qualidade em uso divido em quatro caractersticas: eficcia, produtividade, segurana e satisfao. Segurana definida como a "capacidade do produto de software de apresentar nveis aceitveis de riscos de danos a pessoas, negcios, software, propriedades ou ao ambiente, em um contexto de uso especificado". Uma nota ressalta que "geralmente, os riscos so decorrentes das deficincias na funcionalidade (incluindo segurana de acesso), confiabilidade, usabilidade ou manutenibilidade". O anexo B da NBR ISO/IEC 9126 reproduz a definio de qualidade em uso da NBR ISO/IEC 14598-1, a qual ainda no inclui a nova caracterstica "segurana".

19

2.4. Diferena entre Software Seguro e de Qualidade

Bruce Schneier relata que "programao de computador simples: ficar insistindo no problema at que o computador faa o que deve fazer. (...) Escrever um programa confivel muito mais difcil, porque ele precisa trabalhar mesmo em face de erros e descuidos fortuitos: computador de Murphy5, se preferir. (...) Escrever um programa seguro algo completamente diferente. Segurana envolve assegurar que as coisas funcionam, no apenas em relao a falhas aleatrias, mas em face de um adversrio inteligente e malicioso tentando certificar-se que as coisas falhem da pior forma possvel." [SCHNEIER 2001]. Programar para segurana requer conhecimento especializado e cada mdulo com objetivo de segurana definido deveria ser revisto em par para garantir conformidade [VIEGA 2002]. Diz-se que toda organizao no apenas as comerciais, mas as sem fins lucrativos e tambm instituies governamentais que sobreviver no sculo 21 ter algum envolvimento com e-commerce. Entendendo e-commerce como negociao entre grupos e indivduos em sociedade. O acesso via Internet tem se tornado um requisito para que as organizaes modernas negociem com fornecedores, parceiros e clientes. Assim, toda organizao enfrenta as mesmas ameaas eletrnicas. Desde 11 de setembro de 2001 que segurana de computador considerada no mais um simples problemas de segurana dos negcios, mas de segurana nacional. At um software sem nenhum ativo de valor, se comprometido, pode ser usado como plataforma para ataques a outros sistemas. Ataques podem partir de qualquer parte do mundo, fruto de trabalho individual, empresarial ou de estado [RUFINO 2002].

O autor emprega computador de Murphy numa aluso a um computador supostamente pertencente ao autor das Leis de Murphy para demonstrar a dificuldade de atender aos seus requisitos, visto que a primeira Lei de Murphy afirma que se algo pode falhar, falhar. 20

III - GARANTIA DE SEGURANA

3.1. Introduo
Segundo Albuquerque et al. [ALBUQUERQUE 2002], no possvel desenvolver uma aplicao segura em um ambiente no-seguro. Conforme a anlise do ambiente da aplicao a especificao e o nvel de garantia podem ser necessrios mais ou menos controles. 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) [ISO/IEC 17799] e ISO/IEC 15408 (Evaluation Criteria for Information Technology on Technology Security Evaluation) [ISO/IEC 15408]. 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 no captulo referente ao tpico.

3.2. Ambiente seguro de desenvolvimento

A abordagem da ISO/IEC 15408 [ISO/IEC 15408] 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. Conforme Albuquerque et al. [ALBUQUERQUE 2002], 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. Organizaes que tm os cdigos fonte de seus aplicativos como um ativo de alto valor, necessitam principalmente de um ambiente que, no s apie o desenvolvimento de softwares seguros, mas que, principalmente, no insira vulnerabilidades neles. Usando uma definio mais precisa da ISO, pode-se dizer que garantia a base para a confiana que um
21

sistema atinge os objetivos de segurana para ele definidos. Essa garantia mais facilmente obtida nas vezes em que o ambiente de desenvolvimento adequado, isto , emprega-se as boas prticas de desenvolvimento, a quais, apesar do rigor, no requerem conhecimento especialista substancial, habilidades e outros recursos. Um alto nvel de garantia de segurana permite que um desenvolvedor obtenha o mximo de garantia atravs da engenharia de segurana. Meios de reforar o ambiente de desenvolvimento so apresentados e discutidos nos itens que se seguem.

3.2.1. Gerncia de Configurao

A gerncia de configurao ajuda a garantir que a integridade do sistema est preservada atravs do controle das mudanas feitas no sistema. A gerncia de configurao previne contra mudanas, acrscimos e excluses desautorizadas na documentao do sistema. Alm disso, ajuda a tornar o processo de desenvolvimento menos suscetvel a erros ou negligncia humana. A gerncia pode ser manual ou automatizada e o escopo que delimitar a abrangncia dos itens que sero controlados deve estar claramente especificado.

3.2.2. Distribuio
Deve-se assegurar que a verso disponibilizada para implantao tem os atributos de segurana especificados. As medidas, procedimentos e padres relacionados distribuio, instalao e operao segura devem estar de acordo com as especificaes para no haver comprometimento do sistema na transio entre o desenvolvimento e produo.

22

3.2.3. Desenvolvimento
As funcionalidades de segurana devem ser representadas, nos vrios nveis de abstrao, desde o projeto lgico at a implementao de seus produtos finais. As funcionalidades de segurana devem ser mapeadas, nos vrios nveis de abstraes, estabelecendo uma correspondncia entre objetos da camada de menor abstrao (produto) at os objetos de maior abstrao (contidos na especificao funcional). As estruturas internas das funes tambm podem ser especificadas de forma que aspectos relacionados a modularidade, diviso em camadas e reduo da complexidade fiquem melhor representados. So nveis de abstrao: Especificao funcional Projeto de alto nvel Projeto de baixo nvel Representao da implementao

A idia principal a decomposio das funcionalidades de segurana (descritas na especificao funcional) em subsistemas, da decomposio desses em mdulos, do projeto de implementao desses mdulos e da demonstrao de evidncias da correspondncia entre todas as camadas de decomposio.

3.2.4. Documentao
A documentao de ajuda, destinada a usurios e administradores, um fator importante na segurana da operao do sistema. A documentao de ajuda ao administrador envolve os materiais escritos, no importa o meio, destinados a configurao, manuteno e administrao do sistema de forma correta e segura. A documentao de ajuda ao usurio descreve as funcionalidades de segurana, instrues e guias para uso seguro do sistema.

23

3.2.5. Suporte ao Ciclo de Vida

Visa garantir que aspectos relacionados a segurana sejam tratados adequadamente durante o ciclo de desenvolvimento e manuteno. Dessa forma, o produto final conter as funcionalidades de segurana especificadas. O suporte ao ciclo de vida inclui medidas de segurana fsica, procedural, pessoal e outras necessrias a garantia da segurana do sistema. O modelo de ciclo de vida a ser adotado importante para que os requisitos funcionais de segurana sejam atingidos. A escolha de um modelo inadequado pode comprometer a segurana do produto final. A ISO recomenda modelos aprovados por grupos de especialistas reconhecidos.

3.2.6. Testes de Segurana

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 sero definidos de acordo o grau de exigncia estabelecido, isto , um teste profundo permitir a descoberta de cdigos maliciosos inseridos durante o desenvolvimento.

3.2.7. Avaliao de Vulnerabilidades

Avaliar vulnerabilidades abrange analisar a existncia de ameaas passves de explorao, a possibilidade de um mau uso do sistema ou de sua configurao incorreta, a possibilidade de falha dos mecanismos de segurana se expostos fora e a explorao de quaisquer vulnerabilidades eventualmente introduzidas durante o desenvolvimento ou operao do sistema. Busca-se com a avaliao de vulnerabilidades identificar ameaas que possam afetar fatores como velocidade de processamento, configurao do sistema ou
24

da rede, capacidade de memria e outros. O uso inapropriado do sistema tambm outra preocupao que a avaliao da vulnerabilidade deve identificar. Orientaes erradas ou outros tipos de falhas na documentao de ajuda, tanto do administrador quanto usurio, devem ser identificadas.

3.3. Norma ISO/IEC 17.799

A ISO/IEC 17799 [ISO/IEC 17799] um conjunto de recomendaes para gesto da segurana da informao para uso por aqueles que so responsveis pela introduo, implementao ou manuteno da segurana em suas organizaes. Tem como propsito prover uma base comum para o desenvolvimento de normas de segurana organizacional e das prticas efetivas de gesto da segurana, e prover confiana nos relacionamentos entre as organizaes. A ISO/IEC 17799 atua em segurana da informao considerando tecnologia, processos e pessoas. importante observar que essas recomendaes descritas na norma estejam de acordo com a legislao e regulamentao vigente. Nery et al. [NERY 2005] relata que a ISO/IEC 17799 publicada no Brasil pela ABNT com o cdigo NBR ISO/IEC 17799 e tem sido utilizada por organizaes importantes como o Banco Central, nas recomendaes de segurana do SPB Sistema de Pagamentos Brasileiro, pelo ITI Instituto de Tecnologia da Informao nas normativas do ICP Brasil, pelo CFM Conselho Federal de Medicina para o uso de pronturio eletrnico e diversas outras organizaes. De acordo com Gonalves [GONALVES 2003], a verso final da NBR ISO/IEC 17799, que uma "traduo literal" da norma ISO/IEC 17799:2000, foi homologada em setembro de 2001. E, esta verso da ISO/IEC 17799, vem sendo utilizada por vrios outros pases, como o caso de Portugal e Angola. A ISO/IEC 17799 origina-se de um esforo do governo britnico, que em 1987, atravs do UK DTI (Departamente of Trade Center) criou o CCSC (Comercial Computer Security Centre), cujo objetivo era a criao de critrios para a avaliao da segurana e de
25

um cdigo de segurana para os usurios das informaes, de uma forma geral. No ano de 1989 foi publicada a primeira verso do cdigo de segurana, que na poca foi denominado de PD0003 - Cdigo de Gerenciamento de Segurana da Informao. Esse cdigo foi revisado, ampliado e publicado como uma norma britnica (BS), a BS77991:1995 (Information technology - Code of pratic for information security management). Em 1996, essa norma foi proposta a ISO para homologao, mas foi rejeitada. Neste mesmo perodo uma segunda parte deste documento estava sendo criada, publicada posteriormente como BS7799-2:1998 (Information Security Management Systems). Aps uma reviso, as duas normas (a de 1995 e a de 1998) foram publicadas com o nome de BS7799-1999. Neste mesmo ano a primeira parte deste documento foi submetida ISO para homologao, sobre o mecanismo de "Fast Track". Em maio de 2000 a BSI (British Standard Institute) homologou a primeira parte da norma BS7799. Na reunio do comit da ISO em Tquio, a norma foi votada e aprovada pela maioria dos representantes. Embora sem unanimidade, em primeiro de dezembro de 2000 houve a homologao da "BS" como ISO/IEC 17799:2000. A norma BS7799-2 foi submetida a um processo de reviso em 2001, no intuito de ajust-la com normas internacionais, tais como a ISO 9001 e a ISO 14001, e remover aspectos prprios da lei britnica. Os controles da ISO/IEC 17799 foram adicionados a um anexo desta verso, permitindo uma correspondncia entre a numerao em ambas as normas. A BS 7799-2:2002 foi publicada no dia 5 de setembro de 2002. A NBR ISO/IEC 17799 abrange ao todo 10 domnios, reunidos em 36 grupos que se totalizam em 137 controles, sendo seus domnios, a Poltica de Segurana, a Segurana Organizacional, a Classificao e Controle dos Ativos de Informao, a Segurana de Pessoas, a Segurana Fsica e do Ambiente, o Gerenciamento das Operaes e Comunicaes, o Controle de Acesso, o Desenvolvimento e Manuteno de Sistemas, a Gesto da Continuidade do Negcio e a Conformidade [GONALVES 2003].

26

Segundo a NBR ISO/IEC 17799 [NBR ISO/IEC 17799], a segurana de um ambiente caracterizada pela manuteno de trs fatores primordiais: a confidencialidade, a integridade e a disponibilidade das informaes crticas. Para a NBR, a informao "um ativo que, como qualquer outro ativo importante para os negcios, tem um valor para organizao e conseqentemente necessita ser adequadamente protegido" Um ambiente aderente norma quando o mesmo utiliza os recursos adequados para garantir a disponibilidade, confidencialidade e a integridade de suas informaes. Para isso devem ser aplicados ao ambiente alguns ou todos os controles existentes na norma de segurana. Contudo, a lista dos controles que devem ser aplicados depende de caractersticas do prprio ambiente, como por exemplo: forma e local de armazenamento das informaes, valor das informaes armazenadas, quem pode acess-las, quais servidores esto instalados, que tipo de servios so disponibilizados aos usurios da rede interna e da rede externa e etc.

3.4. Norma ISO/IEC 15.408

De acordo com Albuquerque et al. [ALBUQUERQUE 2002], garantia de segurana no o mesmo que a segurana do sistema. Fornecer garantia compreende fazer mais que a aplicao. necessrio permitir ao cliente se assegurar que o sistema seguro. Uma forma de garantia de segurana para o desenvolvimento de software atravs de teste comprovado pelo cliente. Nessa modalidade de garantia, o cliente tem o direito a verificar resultados de teste e realizar testes com laboratrios independentes para comprovar se a segurana est adequada. Esses so os princpios da ISO/IEC 15.408 [ISO/IEC 15408]: Especificar a segurana de forma clara e objetiva Construir conforme a especificao Testar para verificar o atendimento da especificao original

27

O Common Criteria for Information Technology Security Evaluation (Critrio Comum para Avaliao de Segurana da Tecnologia da Informao) o nome do padro que originou a norma ISO/IEC 15408 [ISO/IEC 15408], muitas vezes chamada apenas de Common Criteria. A norma objetiva fornecer um conjunto de critrios fixos que permitem especificar a segurana de uma aplicao de forma no ambgua a partir de caractersticas do ambiente da aplicao e definir formas de garantir a segurana da aplicao para o cliente final. A histria do Commom Criteria remonta ao TCSEC Trusted Computer Security Evaluation Criteria (Critrio Confivel para Avaliao de Segurana de Computadores). O TCSEC ficou conhecido como Orange Book (Livro Laranja) e foi, segundo Albuquerque et al. [ALBUQUERQUE 2002], o primeiro padro para avaliao de segurana desenvolvido ainda na dcada de 1980. Ainda segundo Albuquerque et al. [ALBUQUERQUE 2002], embora fosse um padro bastante aceito, possuia alguns problemas estruturais: fixava atributos de segurana em nveis estticos, o que dificultava seu uso em uma srie de sistemas que precisassem de mais segurana em alguns atributos que outros. O Livro Laranja [DOD 1985] foi escrito para os rgos do governo dos Estados Unidos, porm tornou-se um padro comercial de uso geral, pois, de um lado os fabricantes comearam a utilizar seus critrios para classificar seus produtos, e do outro, os compradores a dispor de um meio que permitiria uma melhor avaliao da segurana fornecida pelos produtos. Na dcada de 1990 outras tentativas de padronizar a segurana de sistemas surgiram. Um exemplo foi o ITSEC, criado pela comisso europia em 1991, o CTCPEC desenvolvido pelos canadenses em 1993 e o FC (Federal Criteria) elaborado pelos americanos tambm em 1993. Para evitar a criao de vrios padres divergentes, instituiuse um comit internacional do Common Criteria. O Common Criteria uma norma ou padro de indstria criado a partir da unio dos diversos padres anteriores com o objetivo de criar uma norma international sobre o assunto.
28

A primeira verso do Common Criteria foi publicada em janeiro de 1996. Em maio de 1998 foi disponibilizada uma grande reviso denominada Common Criteria 2.0. Em dezembro de 1999, foi finalmente liberada a verso 2.1 do Common Criteria, homologada como a norma internacional ISO/IEC 15408 [ISO/IEC 15408]. Atualmente encontra-se na verso 2.2. O princpio que norteia o Common Criteria que um sistema possa ser desenvolvido, seguindo a norma; testado em um laboratrio credenciado e ser homologado com um selo de certificao que garanta que o sistema atende aos requisitos de segurana. O Common Criteria define que qualquer sistema, para ser considerado seguro, precisa ter seu Security Target (ST) objetivo ou alvo de segurana elaborado. O Security Target a especificao de segurana, isto , indica os aspectos de segurana que foram considerados importantes e os motivos pelos quais foram para aquele sistema em particular. Outra figura importante o Protection Profile (PP) perfil de proteo , que um documento semelhante ao Security Target, mas sem determinar uma aplicao especfica, podendo ser aplicado a toda uma classe de sistemas. O Common Criteria estabelece sete nveis de garantia de segurana. A cada nvel, h um maior nmero de testes e, conseqentemente, maior garantia de que o sistema atende aos requisitos de segurana. Os nveis so denominados EAL (Evaluation Assurance Level Nvel de Garantia de Avaliao) e variam de EAL-1 a EAL-7, conforme o Common Criteria. Na ISO/IEC 15408 [ISO/IEC 15408], os nveis de EAL-5 a EAL-7 so considerados extremamente rgidos e, praticamente, inviveis. Logo, os nveis compreendidos entre EAL-1 e EAL-4 so reconhecidos pela ISO. Assim, essa constitui-se na diferena prtica entre os dois documentos, que so idnticos nos demais pontos. A ISO/IEC 15408 e o Common Criteria recomendam uma rede de laboratrios credenciados a avaliar a segurana das aplicaes nos nveis que cada uma das duas
29

instituies reconhece. No h atualmente no Brasil e nem na Amrica do Sul nenhum laboratrio credenciado. Os mais prximos esto nos Estados Unidos. Para no causar confuso com o emprego do termo sistema, o Common Criteria emprega o termo TOE (Target of Evaluation Alvo da Avaliao). O TOE , ento, o sistema que est se desenvolvendo ou avaliando. O TOE tem funes de segurana que constituem o conjunto de rotinas responsveis por garantir sua conformidade com a poltica de segurana. Em algumas ocasies as funes de segurana so designadas pela sigla TSF (Target Security Functions Funes de Segurana do Sistema Alvo). TSP , portanto, a poltica de segurana do TOE, que so as regras que definem a poltica de acesso e controle dos ativos do sistema. O Common Criteria pode ser usado para desenvolver um sistema seguro ou avaliar a segurana de um j desenvolvido. A exigncia de avaliao por laboratrios internacionais e o grande nmero de detalhes na implantao, como determina o processo estabelecido na norma, torna o processo caro. No existe uma NBR (norma brasileira) correspondente. Porm h iniciativas nesse sentido, sobretudo pela importncia que o tema tem e pelas preocupaes vem despertando nos ltimos anos.

3.5. Ciclo de Vida de Desenvolvimento Seguro

Segurana um requisito fundamental para a indstria de software, guiada pelas foras do mercado, pela necessidade de proteger infra-estruturas e pela importncia de desenvolver e preservar a confiana nos sistemas. Um desafio que a indstria de software enfrenta criar software mais seguro que requeira menos atualizao de correo e gerenciamento de segurana menos oneroso.

30

Para a indstria de software, a forma de satisfazer as demandas atuais de reforar a segurana implementando processos repetveis que resulte em produtos com segurana reforada. Assim, a indstria de software dever fazer a transio para um processo de desenvolvimento de software mais severo que trate adequadamente, em uma forma ampla, a segurana. Tal processo deve reduzir o nmero de vulnerabilidades existentes nas fases de projeto e codificao, alm da elaborao de documentao, permitindo que se identifique e remova tais vulnerabilidades do ciclo de vida de desenvolvimento o mais rpido possvel. O governo americano, atravs do Departamento de Defesa, comeou a exigir na dcada de 1980 que seus projetos de tecnologia da informao passassem por um processo de certificao de segurana (Security Certification and Accreditation SC&A), tambm chamado de Ditscap. Ditscap formado por quatro fases: definio, verificao, validao e certificao [ROSS 2004]. As organizaes tendem a relutar em investir na incorporao da segurana ao ciclo de vida dos projetos. No entanto, a necessidade de atendimento a regulamentaes como a Sarbanes-Oxley Act6 tem mudado essa tendncia, assim como a viso que mudanas tardias so onerosas [PAUL 2005]. Existem trs fatos a serem considerados no desenvolvimento de software mais seguro: processo repetvel, educao e mtrica [LIPNER 2004]. Segundo Lipner et al., importante que se tenha na organizao um grupo responsvel pelo desenvolvimento e evoluo das melhores prticas de segurana; melhorias no processo, que sirva de fonte de conhecimento para a organizao de uma forma geral e que faa a Reviso Final de Segurana (em ingls FSR Final Security Review) antes da liberao da release. Enquanto muitas organizaes preferem ter uma equipe central de segurana, outras optam
6

Legislao americana aprovada em 2001 provavelmente a legislao mais abrangente que afeta as empresa de comrcio pblico dos Estados Unidos desde o Securities Exchange Act de 1934 para restaurar a confiana nos relatrios financeiros de empresas pblicas. Entre outras medidas, responsabiliza pessoalmente os funcionrios pelo fornecimento de informaes financeiras precisas. Foi criada aps os fiascos contbeis da Enron, WorldCom e Global Crossing. 31

por contratar terceiros, a experincia demonstrou na viso de Lipner et al. que a existncia de um grupo interno de segurana um fator vital para o sucesso na implementao de um ciclo de vida de desenvolvimento. A seguir, um conjunto de etapas voltadas para melhorar a segurana do software no processo de desenvolvimento ser apresentado. O objetivo do processo reduzir a quantidade e severidade das vulnerabilidades de segurana nos softwares desenvolvidos. O processo a ser apresentado usado pela Microsoft, batizado de Trustworthy Computing Software Development Lifecycle ou simplesmente SDL.

3.5.1. O Processo
O processo de uma forma geral similar aos praticados pela indstria de software. Seu fluxo mostrado na Figura 1.

Figura 1

Embora a Figura 1 parea um processo de desenvolvimento em cascata, na verdade um espiral. Requisitos (Requirements) e Projeto (Design) so revisados durante a implementao, para responder s necessidades de mudanas que o mercado exige e s circunstncias que envolvem a implementao. Alm disso, o processo de desenvolvimento enfatiza a necessidade de ter cdigo executvel pronto em quase todos os pontos de tal forma que cada marco (milestone) de fato resultante na liberao de uma
32

srie de builds que podem ser testadas e usadas operacionalmente (pela equipe de desenvolvimento) de uma forma contnua.

3.5.2. Viso Geral

A experincia com segurana de software tem demonstrado que um conjunto de princpios de alto nvel para desenvolver software mais seguro precisam ser estabelecidos. A Microsoft refere-se a esses princpios como SD3+C Seguro por Design, Seguro por Default, Seguro na Distribuio e Comunicao. Uma descrio sucinta desses princpios seria: Seguro por Design: Uma arquitetura pode ser desenhada para utilizar criptografia 3DES (triplo DES) para dados sensveis antes de serem armazenados no banco de dados e o uso do protocolo SSL para transportar o dado atravs da Internet. Todo cdigo bastante verificado em busca de vulnerabilidades comuns usando ferramentas manuais e automticas. A modelagem de ameaas criada durante o processo de design do software. Seguro por Default: O software empacotado com medidas de segurana e os componentes potencialmente vulnerveis so desativados. Seguro na Distribuio: Atualizaes de segurana so fceis de serem localizadas e instaladas eventualmente so instaladas automaticamente e ferramentas so disponibilizadas para o levantamento e gerenciamento dos riscos de segurana em toda a organizao. Comunicao os desenvolvedores precisam estar preparados para descobrir vulnerabilidades nos produtos e comunicar aberta e responsavelmente os usurios finais e/ou administradores para ajud-los a tomarem as aes preventivas necessrias.
33

Enquanto cada elemento do SD3+C exige requisitos no processo de desenvolvimento, os dois primeiros elementos Seguro por Design e Seguro por Padro provem os maiores benefcios da segurana. Seguro por Design trata do processo que pretende evitar a incluso de vulnerabilidades em um primeiro momento, enquanto Seguro por Default requer que a exposio por padro do software sua superfcie de ataque [HOWARD 2003a] seja reduzida. Empregar mtricas de segurana destinadas a integrar o paradigma SD3+C no processo de desenvolvimento existente, resulta no processo organizacional mostrado na Figura 2.

Figura 2

3.5.3. Fase Requisitos (Requirements)

A necessidade de considerar a segurana "de baixo para cima" um princpio elementar no desenvolvimento seguro de sistema. Enquanto muitos projetos de desenvolvimento produzem verses posteriores baseadas nas liberaes precedentes, a fase de requisitos e planejamento inicial de uma nova liberao ou verso oferece a melhor oportunidade de construir o software de forma segura. Durante a fase de requisitos, a equipe de projeto deveria contar com o apoio de um conselheiro de segurana, proveniente do grupo de segurana, para servir de intermedirio e assessorar nas questes pertinentes segurana. A funo do conselheiro seria de ajudar
34

a equipe de projeto revisando planos, fazendo recomendao e garantindo que o grupo de segurana planeja os recursos necessrios para oferecer suporte ao cronograma da equipe de projeto. O conselheiro de segurana permanece como intermedirio da equipe de projeto com o grupo de segurana at a Reviso Final de Segurana e liberao do software. O conselheiro de segurana o elo entre a equipe de projeto e o grupo de segurana, nos dois sentidos, pois depois de liberada a verso a equipe de segurana pode necessitar estabelecer contato com a equipe de projeto visando evitar surpresas relacionadas s falhas de segurana. A fase de requisito a oportunidade que a equipe de projeto tem para considerar como a segurana ser integrada no processo de desenvolvimento, identificar objetos chaves de segurana e aumentar a segurana do software enquanto reduz as chances de no cumprimento dos planos e cronograma. Faz parte dessa fase considerar as caractersticas de segurana e assegurar que as medidas do software se integraro com demais softwares com os quais faa interface. A documentao fundamental para acompanhar os objetivos de segurana, pois a medida que o projeto prossegue as mudanas ocorrem e uma manuteno da documentao desde o princpio ajuda a garantir que os requisitos esto registrados para evitar surpresas de ltima hora. Os requisitos caractersticos de segurana deveriam fazer parte dessa fase. Enquanto alguns requisitos de segurana sero identificados posteriormente em resposta s ameaas, os requisitos dos usurios tendem a incluir caractersticas de segurana necessrias a eles. Requisitos de segurana tambm, muitas vezes, precisam se coadunar com padres de mercados e processos de certificaes como o caso do Common Criteria [CC 1999]. A equipe de projeto deve identificar e registrar tais requisitos como parte normal do processo de planejamento.

3.5.4. Fase de Design

A fase de design identifica de forma geral os requisitos e estruturas do software. De uma
35

perspectiva de segurana, os elementos principais dessa fase seriam: Definir a arquitetura de segurana e princpios de design: Delinear a estrutura geral do software sob uma perspectiva de segurana, identificando, por exemplo, os componentes a serem confiados. Documentar os elementos da superfcie de ataque do software: Sendo a segurana perfeita algo inatingvel, preciso restringir o uso de recursos desnecessrios e limitar o acesso aqueles crticos. Fazer levantamento de ameaas: A equipe de projeto faz o levantamento de ameaas analisando componente a componente. Por meio de metodologia estruturada, a equipe de projeto levanta os ativos a serem protegidos e as interfaces pelas quais os ataques a eles poderiam ocorrer. Dessa forma, contramedidas podem ser encontradas para mitigar os riscos. Definir critrios suplementares de liberao: Procedimentos de liberao deveriam pertencer ao nvel organizacional, mas equipes de projetos ou equipes de manuteno podem necessitar de critrios especficos para liberao. Por exemplo, a equipe de manuteno pode ser impedida de liberar um release corrigindo alguma falha de segurana devido a equipe de desenvolvimento ter identificado e corrigido uma falha antes da mesma ser reportada. Assim, a correo da verso reportada seria desnecessria.

3.5.5. Fase de Implementao

Durante a fase de implementao a equipe de projeto codifica, testa e integra o software. Medidas para evitar ou remover falhas de segurana nessa fase so muito importantes, pois reduzem significativamente a probalidade que vulnerabilidades estejam presentes na verso final.

36

O levantamento das ameaas guiam a fase de implementao. Desenvolvedores atentam para garantir com exatido que o cdigo mitiga as ameaas mais graves e os testadores investigam se cada ameaa est realmente bloqueada ou abrandada. Os elementos do ciclo de vida seguro que se aplicam a fase de implementao so: Empregar padres de codificao e teste Empregar ferramentas de teste de segurana incluindo fuzzing7 Empregar ferramentas de anlise esttica de cdigo Revisar o cdigo

3.5.6. Fase de Verificao

A fase de verificao aquela em que o software est funcionalmente completo e os beta-testers comeam a testar. Durante essa fase, enquanto o software submetido a fase de beta teste, a equipe de projeto faz uma investida de segurana que inclui a reviso do cdigo de forma mais aprofundada e completa que as revises realizadas na fase anterior. A investida de segurana feita na fase de verificao garante que a reviso e teste do cdigo atenham-se a verso final do software e sirva de oportunidade para a reviso do cdigo que foi desenvolvido/atualizado durante a fase de implementao e o cdigo legado que no foi modificado. O motivo que, fazendo uma segunda investida na fase de verificao, torna-se uma boa prtica para garantir que a verso final atenda aos requisitos e permite uma reviso mais aprofundada no cdigo legado que foi trazido das verses anteriores.

Fornece estruturas de entradas invlidas para a API (Application Programming Interfaces) do software e interface de rede de maneira que se aumente a probabilidade de detectar falhas que possam resultar em vulnerabilidades. 37

3.5.7. Fase de Liberao

Na fase de liberao, o software deveria ser objeto de uma Reviso Final de Segurana (RFS). O objetivo responder a uma questo: Do ponto de vista de segurana, o software est pronto para ser liberado? Dependendo do escopo do projeto, o software pode ser submetido Reviso Final de Segurana dois ou seis meses antes de completado. A RFS uma reviso independente conduzida pelo grupo de segurana da organizao. O conselheiro de segurana comunica ao grupo de projeto sobre o escopo do RFS e fornece uma lista de requisitos antes da reviso. O grupo de projeto fornece os requisitos solicitados e o RFS inicia-se com o preenchimento de um questionrio pelo grupo de projeto, seguido de uma entrevista. Cada RFS necessitar de uma reviso de bugs que foram inicialmente considerados como bugs de segurana, mas que uma anlise posterior determinou que no teria impacto na segurana, para garantir que a anlise foi feita corretamente. Um RFS tambm inclui uma reviso da capacidade do software em resistir a vulnerabilidades recm relatadas em softwares similares. Um RFS mais aprofundado incluir teste de penetrao e, potencialmente, a contratao de terceiros para suplementar a equipe de teste segurana.

3.5.8. Fase de Manuteno (Support and Servicing)

Apesar de todos os esforos feitos nas fases de desenvolvimento, no possvel garantir que o software seja imune a vulnerabilidades e h motivos para acreditar-se que nunca ser. Mesmo que o processo de desenvolvimento elimine todas as vulnerabilidades em um software liberado, novas formas de ataques que comprometam a segurana do software podem ser descobertas. Assim, as equipes do produto devem preparar-se para responder s novas vulnerabilidades descobertas aps a liberao.

38

Parte do processo de resposta a incidentes envolve a necessidade de preparao para avaliar relatrios de vulnerabilidades e liberar notificaes e atualizaes de segurana quando apropriado. O outro componente do processo de resposta conduzindo um post-mortem de vulnerabilidade relatada e tomando as medidas necessrias. As aes em resposta a uma vulnerabilidade variam de emitir uma atualizao em resposta a um erro isolado at a atualizar ferramentas de verificao de cdigo para iniciar revises dos subsistemas principais. O objetivo durante a fase de resposta aprender com os erros e usar a informao fornecida nos relatrios de vulnerabilidades para ajudar a detectar e eliminar vulnerabilidades adicionais, antes que sejam descobertos na prtica. O processo de resposta ajuda tambm a equipe do projeto e a equipe de segurana a adaptar processos para que erros similares no sejam repetidos no futuro.

39

IV - REQUISITOS FUNCIONAIS DE SEGURANA

4.1. Introduo
Os requisitos funcionais de segurana so declaraes que descrevem os controles necessrios para atenuar o risco. O termo "funcional" significativo: os controles devem ser expressos conforme as funes desejadas, em oposio s tecnologias estabelecidas. Solues tcnicas alternativas tambm so possveis e qualquer deciso aceitvel, desde que atenda aos requisitos funcionais de segurana. A equipe de gerenciamento de riscos de segurana responsvel pela definio dos requisitos funcionais, o primeiro produto do processo de anlise de relao de custo/benefcio. Para identificar adequadamente os controles potenciais, deve-se definir como os controles devem se comportar a fim de reduzir o risco aos negcios. Embora a equipe detenha a propriedade, recomendvel que trabalhe em colaborao com o proprietrio da soluo de atenuao [HOWARD 2004]. necessrio definir os requisitos funcionais para cada risco discutido no processo de suporte s decises. O produto resultante poderia ser chamado de definies do requisito funcional. A definio e a propriedade do requisito funcional so muito importantes no processo de anlise de relao de custo/benefcio. O documento definiria o que necessrio para reduzir o risco identificado, mas no especificaria como deveria ser reduzido, nem definiria os controles especficos. Essa distino concede equipe de gerenciamento de riscos de segurana responsabilidade na sua rea de experincia, ao mesmo tempo em que permite ao proprietrio da atenuao, responsvel pela implementao da soluo de atenuao, a propriedade das decises relacionadas operao e ao suporte aos negcios. Assim, poderia-se organizar um documento de especificao da segurana pelos objetos, apontando a estratgia e os atributos utilizados. Certas vezes, os atributos estaro presentes em mais de um objetivo de segurana. Em funo disso, pode-se optar por, ao final da lista de estratgias, montar uma lista com os atributos e os motivos de seu uso. O Common Criteria [CC 1999] e a ISO/IEC 15408 [ISO/IEC 15408] empregam um modelo
40

diferente que listam objetivos e atributos e descreve o porqu de um ser usado com o outro. Essa a parte central dos documentos Protection Profile e Security Target. A diferena, porm, apenas na forma, sendo bastante simples transformar um modelo no outro e seguir risca o que exigido pela norma. Do ponto de vista de Albuquerque et al. [ALBUQUERQUE 2002], a forma usada pelo Common Criteria dificulta o entendimento da estratgia de segurana usada. Ele prefere agrupar as estratgias de forma global e, se for oportuno, acrescentar a tabela de relacionamento ao final. Algumas estratgias de segurana aparecem de forma muito comum, como verdadeiros padres (patterns) de segurana da aplicao. Cada caso deve ser avaliado particularmente, mas alguns requisitos so descritos a seguir para, pelo menos, orientar a especificao da segurana do sistema.

4.2. Auditoria
Auditoria em software consiste, fundamentalmente, na gravao, armazenamento e anlise de informaes relevantes que determinem quais aes relevantes segurana ocorreram e quem as perpetrou [CC 1999]. Aparentemente simples, rotinas de auditoria devem considerar uma srie de fatores que elevam sua complexidade. preciso, por exemplo, determinar quais aes devem ser registradas, como tratar a privacidade, como analisar as trilhas, armazen-las e compatibiliz-las com as trilhas de auditorias do sistema operacional e/ou outras aplicaes [ALBUQUERQUE 2002]. Um dos aspectos importantes a ser considerado pela auditoria em software o que se refere ao espao ocupado e volume de aes registradas. preciso definir quais aes so relevantes para serem gravadas registrar pouco pode ser no-elucidativo para desvendar um problema e registrar muito pode comprometer o sistema e/ou gerar trilhas em volume superior capacidade de anlise. A gravao das trilhas deve considerar a
41

finitude do espao nas mdias adotadas, assim como o tratamento a ser dado aos dados quando o espao se exaurir. necessrio que se saiba se os dados mais antigos sero apagados a medida que os novos so inseridos (permitindo que um atacante gere aes lcitas repetidamente aps um ataque, de forma a eliminar qualquer registro das trilhas), se o melhor parar de registrar (admitindo que o atacante aja incognitamente) ou se travar o sistema at a interveno do administrador para liberar espao atitude mais apropriada (ganhando antipatia dos usurios e tornando-se vulnervel a ataques de negao de servio - Denial of Service). O armazenamento da trilha de auditoria deve ser feito de forma que sua integridade, mesmo em caso de ataque ou falha do sistema, seja garantida. Outro aspecto importante o que trata da privacidade. Alguns sistemas so altamente comprometidos com a privacidade de seus usurios. A auditoria pode violar a privacidade. Nesses casos ser necessrio escolher entre privilegiar a auditoria ou a privacidade. A ISO/IEC 15408 indica gerao de dados para auditoria o registro de cada um dos seguintes eventos: Inicializao e finalizao das funes de auditoria Todos os eventos auditveis para o nvel [seleo: mnimo, bsico, detalhado ou no especificado] [designao: outros eventos de auditoria]

Para cada evento auditado deve-se registrar ao menos as seguintes informaes: Data e hora do evento, tipo de evento, identidade do sujeito (usurio ou sistema) e resultado final (sucesso ou falha) Para cada tipo de evento, baseado na definio do evento na especificao de segurana, incluir [designao: outras informaes necessrias]
42

Os eventos auditveis podem, com o passar do tempo, deixar de ser relevante para registro e outros podem tornar-se. O Common Criteria sugere que permita-se mudanas nos eventos auditveis e que o sistema registre na trilha de auditoria, no nvel mnimo, todas as alteraes na configurao da auditoria, com base nos seguintes critrios: Identidade do objeto e usurio Hora do dia

A anlise de trilha de auditoria manualmente tediosa e apresenta altas chances de erro. Na maioria das vezes, os eventos no representam grandes problemas de segurana [ALBUQUERQUE 2002]. O verdadeiro potencial da auditoria no aproveitado at que os dados sejam transformados em informaes teis [HONEYNET 2002]. Um mecanismo automtico de deteco de problemas desejvel para muitos casos. Alarmes e respostas automticas tentativa de invaso permitem que, detectada uma situao suspeita, o sistema envie um e-mail, apresente uma mensagem no console do administrador, registre na tabela de suspeita de invaso, envie mensagem via pager ao administrador ou encerre o sistema.

4.3. Comunicao - Repdio

Albuquerque et al. [ALBUQUERQUE 2002] diz que "o repdio uma forma de ataque. O agente do ataque executa uma funo no sistema e posteriormente nega t-la efetuado; por exemplo, algum faz uma compra em uma loja eletrnica e, no momento de pagar, alega que no a fez". O Common Criteria, preocupada em garantir a identificao das partes envolvidas em uma troca de dados, emprega duas famlias de classes para garantir a identificao do emissor da informao (prova de origem) e assegurar a identificao do destinatrio (prova de recebimento). Para evitar o no-repdio necessrio autenticar as partes envolvidas e garantir a integridade da mensagem, para que o contedo no seja alterado.
43

As assinaturas eletrnicas so eficazes para garantir o no-repdio de origem. Entretanto, insuficiente para garantir o de recebimento. preciso algum tipo de protocolo em que o destinatrio ou uma terceira parte confivel envie ao emitente, ou armazene em base confivel, uma mensagem comprobatria do recebimento. A mensagem de resposta (prova do recebimento) deve ser tambm assinada eletronicamente. Uma terceira parte confivel arbitrando as trocas de mensagens importante tambm para evitar que a prova de recebimento chegue ao emissor da mensagem original. Nesse caso, o emissor (A) enviaria uma mensagem, o destinatrio (D) acusaria seu recebimento enviando outra em resposta, porm essa prova de recebimento no chega a A. Poderia-se configurar aqui a viso de A que o negcio no foi fechado e D, sim. Uma terceira parte confivel permitiria a ambas as partes consultar um rbitro para saber se o protocolo foi concludo com sucesso. Outra alternativa para esse caso seria o emissor repetir a mensagem, notificando se tratar de uma cpia, a intervalos regulares at a confirmao de recebimento.

4.4. Criptografia
Soares et al. [SOARES 1995] comenta que "a criptografia surgiu da necessidade de se enviar informaes sensveis atravs de meios de comunicao no confiveis, ou seja, em meios onde no possvel garantir que um intruso no ir interceptar o fluxo de dados para leitura (intruso passivo) ou para modific-lo (intruso ativo). A forma de contornar esse problema utilizar um mtodo que modifique o texto original da mensagem a ser transmitida (texto normal), gerando texto criptografado na origem, atravs de um processo de codificao definido por um mtodo de criptografia. O texto (ou a mensagem) criptografado ento transmitido e, no destino, o processo inverso ocorre, isto , o mtodo de criptografia aplicado agora para decodificar o texto criptografado transformando-o no texto normal original".
44

"Existem basicamente dois tipos de criptografia: a simtrica e a assimtrica" [ALBUQUERQUE 2002]. Jlio Csar empregava um mtodo de criptografia que consistia em substituir as letras de uma mensagem pela terceira letra aps sua posio no alfabeto (sendo a sucessor de z) [TANENBAUM 1989]. Esse um exemplo de criptografia simtrica ou baseada em chave secreta, pois a mesma chave ser usada para cifrar e decifrar a mensagem. O problema clssico dessa soluo a dificuldade de entregar a chave de forma segura a quem vai decifrar a mensagem [RUFINO 2002]. Existem diversos algoritmos conhecidos de criptografia simtrica, como DES, IDEA, TRIPLE-DES e BlowFish [ALBUQUERQUE 2002]. O algoritmo DES codifica blocos de 64 bits de texto normal gerando 64 bits de texto criptografado [TANENBAUM 1989]. O conceito de chaves assimtricas baseado na idia que o momento de maior vulnerabilidade da chave quando ela est em trnsito [RUFINO 2002, DISNEI 2002]. Em 1976, Diffie e Hellman [DIFFIE 1976] propuseram um mtodo que revolucionou os sistemas de criptografia. Baseado na utilizao de chaves distintas: uma para codificao (E) e outra para decodificao (D), tal que a derivao de D a partir de E fosse, em termos prticos, seno impossvel, pelo menos muito difcil de ser realizada. Portanto, o que uma cifrasse somente a outra poderia revelar. Dessa maneira, uma poderia ser tornada pblica e trafegar sem necessidade de canais seguros, desde que a outra, privada, permanecesse em local seguro [RUFINO 2002, SOARES 1995]. Entre os algoritmos de criptografia assimtrica ou de chave pblica de uso prtico, os mais comuns so o RSA e as Curvas Elpticas. O RSA, cujo nome deriva das inicias dos autores Rivest, Shamir e Adleman [RIVEST 1978], baseia-se na dificuldade de fatorar nmeros muito grandes. Acreditava-se em 1977 que uma mensagem criptografada pelo RSA-129 levaria milhes de anos para ser quebrada [GARDNER 1977]. Foi quebrada em 1994 usando computao distribuda [LEUTWYLER 1994, LIMA 2002]. "Os mtodos de criptografia assimtricos apresentam dois inconvenientes: o tamanho das chaves e a lentido dos procedimentos de codificao e decodificao" [SOARES 1995]. Os algoritmos simtricos exigem canal separado para distribuio de chaves, tornam o gerenciamento das chaves complexo e permitem repdio [DISNEI 2002].
45

"A garantia da confidencialidade na criptografia deve ser baseada na segurana da chave (...), o ideal usar algoritmo pblico conhecido. O segredo tem que estar na chave, no no algoritmo. Os algoritmos pblicos mais conhecidos so desenvolvidos para evitar criptoanlise e decifrao do texto. Algoritmos feitos em casa so, geralmente, bastantes suscetveis a criptoanlise" [ALBUQUERQUE 2002]. Criptoanlise uma especialidade que busca identificar a chave ou o texto original. preciso atentar que alguns algoritmos so protegidos por copyright em alguns pases do mundo. A troca de chaves em intervalo de tempo regular tambm ajuda a aumentar a segurana. Lima [LIMA 2002] conclui que a "a criptografia de chave pblica no uma panacia. Nenhum sistema criptogrfico alm da 'chave-de-uma-s-vez' incondicionalmente seguro, e preciso que no nos iludamos com argumentos falaciosos que 'comprovam matematicamente' a segurana dos sistemas assimtricos. Talvez seja o caso de fazermos com sistemas assimtricos o que se tem feito com sistemas simtricos, seguindo a sugesto de Shannon [SHANNON 1948] - combinar vrios passos de substituio e de transposio". O Common Criteria recomenda a especificao do uso de criptografia e define dois atributos: operao de criptografia e gerenciamento de chaves criptogrficas. As operaes que envolvem criptografia devem ser realizadas em conformidade com algoritmo especfico e chave de tamanho determinado. O gerenciamento de chaves criptogrficas envolve a gerao, distribuio, acesso e destruio delas. A trilha de auditoria pode conter atributos e informaes sobre as chaves, mas no pode registrar informaes sensveis que violem a confidencialidade das mesmas. Albuquerque et al. [ALBUQUERQUE 2002] exemplifica uma definio para especificao da gerao de chaves de criptografia: "As funes de segurana da aplicao devem gerar chaves de criptografia conforme o algoritmo de gerao de chaves

46

assimtricas RSA, com base em semente gerada pela funo time(), conforme descrito a seguir, com tamanho da chave de 1024, que atendam aos seguintes padres: PKCS#12. Primos gerados randomicamente com semente pela funo time. Chaves privadas geradas e armazenadas localmente no microcomputador do cliente. Chaves pblicas enviadas para o servidor atravs de um canal controlado, com criptografia. Assinatura de chave pblica realizada atravs de smart-card, com emisso de certificado."

4.5. Proteo de dados do usurio

O Common Criteria contm requisitos que especificam funes de segurana e polticas para proteger dados dos usurios. Os requisitos so divididos em quatro grupos: a) Polticas de funes de segurana para proteo dos dados do usurio: - Poltica de controle de acesso; - Poltica de controle de fluxo de informaes. b) Formas de proteo dos dados do usurio: - Funes de controle de acesso; - Funes de controle de fluxo de informaes; - Transferncias internas; - Proteo de informao residual; - Retorno (Rollback); - Integridade de dados armazenados. c) Armazenamento off-line, importao e exportao: - Autenticao de dados;
47

- Exportao de dados para fora do controle do sistema; - Importao de dados de fora do controle do sistema. d) Comunicao interna: - Proteo de confidencialidade de dados do usurio; - Integridade na transferncia de dados. Albuquerque et al. [ALBUQUERQUE 2002] comenta que proteo de dados do usurio basicamente controle de acesso. "A funo de controle de acesso do sistema utilizada para definir se o usurio tem direito a acessar ou alterar determinada informao e para garantir que apenas o usurio com esse direito pode ter acesso a essa informao". preciso tambm resguardar os dados de acessos externos, do sistema operacional ou outras aplicaes, e garantir a privacidade dos que saem. O controle de acesso deve considerar que diferentes usurios tm direitos de acesso distintos. Usurios podem ler, alterar, remover ou criar informaes. A dificuldade existente prevenir que usurios no burlem o controle de acesso, acessar diretamente a informao sem passar pelo sistema, e ao mesmo tempo os meios preventivos no degradem a velocidade do sistema. A maneira mais fcil de evitar o acesso aos dados por outros meios aproximando proteo e informao. Assim, o banco de dados ou o sistema de arquivo (file system) tem sido escolhido como a forma ideal para proteger os dados, em virtude da proximidade da informao. Entre os diversos tipos de controle de acesso, os mais comuns so por nveis universais, por proprietrio e grupo proprietrio; e discriminado (discritionary). O universal classifica as informaes com nveis, por exemplo, secreta, confidencial, restrita e pblica. Os usurios so tambm classificados em funo dos nveis que tero acesso. O usurio ter acesso a seu nvel e os inferiores a este. O controle de acesso por proprietrio e grupo proprietrio comum em sistemas UNIX. Nele, o dono da informao, o grupo a que pertence e os demais usurios podem ter privilgios distintos entre si. No controle de

48

acesso discriminado cada usurio ou grupo tem direito de acesso especfico a uma informao. Outra considerao fundamental se o sistema ser de autorizao, negao ou misto. O sistema de controle por autorizao requer que cada usurio tenha seu acesso autorizado, pois, por padro, no tem direito a nenhum acesso e informao. "No modelo de negao ocorre o inverso: o usurio tem total direito a todos os objetos. Alguns, porm, indicam alguns usurios, negando-lhes explicitamente determinada operao" [ALBUQUERQUE 2002]. O sistema misto funciona de modo que todos tenham um privilgio padro e usurios especficos tenham mais ou menos direitos. Por exemplo, possvel definir um direito padro de leitura a todos os usurios, porm certos usurios podero tambm alterar enquanto outros tm o acesso leitura vetado. O sistema misto requer que regras de soluo de conflitos sejam fixadas. Por exemplo, se um usurio pertencer a dois perfis (A e B) e determinado sistema permitir acesso de leitura ao perfil A e negar leitura ao perfil B, o direito que ter esse usurio dever ser definido por algum critrio. A tendncia que primeiro se considera as permisses e depois as negaes. No exemplo apresentado, o usurio teria acesso de leitura negado. O controle de acesso por contexto pode ser exemplificado como o "o objeto 'projeto' pode ser lido e alterado pelo perfil 'Financeiro' e pelo perfil 'Equipe do Projeto'. Note que o perfil 'Equipe do Projeto' varia de projeto; no um grupo fixo de pessoas. Isso uma caracterstica geralmente necessria em sistemas de controle de acesso e que gera mais custo para implementao [ALBUQUERQUE 2002]. Ainda que o aplicativo, o sistema operacional e o firewall tenham a poltica de acesso obedecida, outros fluxos ilcitos precisam ser controlados. Entre eles, h o acesso por "Cavalo de Tria", micros ligados a modem, roubo de HD e as redes sem fio. De todas as alternativas, difceis de serem levantadas e implementadas na totalidade, "a maneira

49

mais segura de se evitar acessos ilcitos atravs do uso de criptografia das informaes" [ALBUQUERQUE 2002]. Para manter a confidencialidade de dados externos ao sistema, a criptografia para ser bem sucedida dever contar com medidas eficazes de proteo das chaves. Chaves desprotegidas anulam a segurana dos melhores sistemas criptogrficos. A exportao ou importao de dados precisa respeitar as regras estabelecidas na poltica de controle de acesso e fluxo de informaes. Embora bvio, um usurio no autorizado a criar determinada informao, no deve ter oportunidade de cri-la tambm por importao ou exportao. Os cuidados com exportao de dados envolvem questes como backup, garantir que as cpias sejam geradas e restauradas com segurana, mantendo a confidencialidade e a integridade. As comunicaes entre sistemas tambm devem ter os nveis necessrios de segurana proteo das informaes. A poltica de segurana deve tratar das questes pertinentes a relatrios (sada de dado sem segurana), alertando os usurios das suas responsabilidades sobre a confidencialidade dos dados, que no ser mais tarefa do sistema. "Na norma ISO/IEC 15408, importao, exportao, autenticidade e proteo da confidencialidade e da integridade so atributos separados. Isso faz sentido j que, teoricamente, possvel usar um desses atributos e no o outro. Porm (...) geralmente ou usamos apenas os atributos de importao e exportao, sem atributo de segurana, ou usamos o pacote completo, com todos os atributos especificados. Pode haver situaes particulares, mas no so muito comuns" [ALBUQUERQUE 2002]. As transferncias internas aplicaes em locais fsicos diferentes como em um ambiente cliente-servidor necessitam, muitas vezes, de controles especiais que envolvem a criptografia ou a autenticao dos dados em virtude da possibilidade de interceptao da informao. Uma soluo seria, por exemplo, usar uma VPN (Virtual Private Network) ou um protocolo de comunicao segura, como o SSL (Socket Secure Layer).

50

As informaes residuais, aquelas que permanecem armazenadas mesmo depois de excludas, precisam ser tratadas de forma adequada para que pessoas no autorizadas no possam recuper-las. A soluo mais simples escrever zeros sobre os dados apagados. Se a a informao for muito importante, pode-se escrever zero, depois um, depois zero novamente, em seguida dois e repetir o processo 128 vezes para assegurar que uma anlise magntica da superfcie no permita detectar a informao. Outros cuidados envolvem as camadas, especialmente as fornecidas por terceiros, que manipulam as informaes. Um banco de dados l dados do disco rgido e envia para o driver do banco de dados acessado pelo servidor de aplicaes, que, por sua vez, retorna para a funo de leitura e envia camada de apresentao, por exemplo, um navegador. O cache da rede ou navegador pode manter informaes depois de manipul-las. A garantia de integridade dos dados armazenados requer medidas preventivas quanto a problemas de hardware e atomicidade de transaes. Pouco pode-se fazer quanto a problemas como interferncia magntica no desenvolvimento de software, mas pode-se remediar a deficincia com alertas aps detectado problemas que caracterizem falhas no hardware. Outras medidas envolvem escolha de equipamentos redundantes ou com alto MTBF (Mean Time Between Failure). A atomicidade de transaes um problema que envolve o sistema desenvolvido. Albuquerque define transao como o conjunto de operaes realizadas na base de dados do sistema que s faz sentido quando realizadas todas as operaes em conjunto. O exemplo clssico o de transferncia entre contas, a operao s tem importncia se tanto o crdito quanto o dbito tenham sido feitos com segurana. Se apenas um deles for feito, a operao deve ser desfeita. Geralmente a atomicidade de transaes fica sob a responsabilidade do sistema de banco de dados, nas ocasies que so empregados.

51

4.6. Identificao e Autenticao

Segundo Albuquerque et al. [ALBUQUERQUE 2002], autenticao garantir que o usurio de fato quem ele diz ser. Existem trs maneiras de se garantir que um usurio quem ele diz ser: Perguntar algo que s ele saberia responder corretamente Solicitar algo que s ele teria Identific-lo por caractersticas pessoais

Identificao difere de autenticao, porm complementam-se. Identificao, ainda segundo Albuquerque et al., saber quem est operando o sistema. Autenticao trata de garantir que o usurio quem ele diz ser. Pode-se identificar um usurio sem autentic-lo, mas a autenticao pressupe sempre uma identificao. Sempre que houver controle de acesso, uma forma de autenticao ser necessria. A importncia de se solicitar nome e senha justamente para identificar e autenticar o usurio. Albuquerque et al. ressalta que as senhas devem ser armazenadas na forma de hash, uma criptografia especial que atua em um nico sentido, no banco de dados. Destaca que qualquer alternativa seria intil, pois se o administrador do sistema tivesse como saber a senha, no haveria mais como responsabilizar este algum. Os algoritmos de hash recomendados por Albuquerque et al. so MD5 e SHA-1. A escolha foi baseada nas descries de Schneier [SCHNEIER 1995]. Algoritmos de hash deveriam possuir duas propriedades: funcionar em sentido nico (one way), que significa no permitir recriar a mensagem original do hash final; e serem livres de colises, que significa encontrar duas mensagens que gerem o mesmo hash final. Quebrar um algoritmo hash significa que uma ou ambas as propriedades no so verdadeiras. Ron Rivest criou em 1992 o MD5, que um aperfeioamento do MD4. Em 1993 o National Security Agency (NSA) publicou um algoritmo hash similar ao MD5, chamado SHA. Em 1995 fez melhorias no SHA e lanou um novo algoritmo chamado SHA-1. Muitas aplicaes
52

antigas ainda usam MD5. O SHA-1 tornou-se um dos mais populares algoritmos atualmente. Ocorre que em 2004 Eli Biham e Rafi Chen, alm de Antoine Joux, anunciaram resultados criptogrficos impressionantes contra o MD5 e SHA. Colises foram demonstradas em SHA e Schneier declara, sem incutir pnico ou alarme, que " hora de todos migrarem do SHA-1". Entre as alternativas cita o SHA-224, SHA-256, SHA384 e SHA-512 [SCHNEIER 2004]. Em 2005 Schneier publica pela primeira vez, confirmando suas suspeitas, que o SHA-1 foi quebrado, "no uma verso reduzida e nem uma simplificada. O algoritmo completo mesmo". Trs estudantes chineses Xiaoyun Wang, Yiqun Lisa Yin e Hongbo Yu, a maioria da Universidade Shandong8 na China, mostraram que o SHA-1 no livre de coliso. "Eles desenvolveram um algoritmo para procurar colises mais rpido que por fora bruta" [SCHNEIER 2005]. Alm da forma de autenticao, seja por senha, carto, biometria ou qualquer outra forma, aspectos como momento da autenticao, impossibilidade de fraude do sistema, mltiplos mecanismos de autenticao e reautenticao devem ser considerados. As mensagens de erro de autenticao no deveriam dar pistas ao agente de um eventual ataque. Por exemplo, se o sistema exibir mensagens de erro distintas para usurio e senha errada, o agente pode descobrir mais facilmente quais usurios so vlidos no sistema. O emprego de flag para bloqueio de conta, estipulao de prazo de validade em contas e necessidade de troca de senha ou de certificado, so atributos que contribuem para aumentar a segurana do processo de autenticao. Informaes para autenticao comumente usadas pelos sistemas: Identificao do usurio Dados para autenticao Prazo de validade dos dados para autenticao Prazo a partir do qual deve-se alertar o usurio para renovar seus dados de autenticao
8

Um resumo do artigo, a verso completa no est disponvel ainda, pode ser encontrado em http://theory.csail.mit.edu/~yiqun/shanote.pdf 53

Indicador de conta bloqueada (flag) Data e hora para liberao do bloqueio

As senhas, quando empregadas, deveriam atender a critrios que determinem o nmero mnimo de caracteres e se so compostos por letras, nmeros, sinais e se as letras so sensveis ao caso (case sensitive). possvel que o sistema que autenticou o usurio faa acesso a outros sistemas para realizar aes definidas por esse usurio. Se houver controle de acesso nesses outros sistemas, o acesso deveria ter privilgio compatvel com os do usurio autenticado no sistema autenticador. Uma soluo ligar o usurio instncia do sistema a ser acessado por meio de uma nova autenticao, gerando um token assinado eletronicamente pelo autenticador, que seria uma entidade aceita por todos os sistemas. A autenticao nesse caso seria feita em um nico local e uma nica vez, processo conhecido como single sign on.

4.7. Gerenciamento de segurana

O Common Criteria define uma classe para gerenciamento de segurana que envolve atributos, informaes e funes de segurana. Segundo Albuquerque et al. [ALBUQUERQUE 2002], todo gerenciamento de segurana passa por pontos importantes como: Definio e gerncia de papis de segurana, que significa determinar quem possui acesso a determinadas funes ou informaes de segurana. Capacidade de revogao e expirao de atributos de segurana, que a capacidade do sistema revogar um direito imediatamente ou estabelecer um prazo para tal.
54

Depois desses pontos, outros trs tipos de funes compem o gerenciamento: Gerenciamento das funes de segurana, que descreve o acesso e os atributos das funes de segurana. Gerenciamento dos atributos de segurana, que descreve o acesso aos atributos de segurana de outros objetos do sistema, como quem define o proprietrio de um arquivo. Gerenciamento de dados de segurana, o qual, ao contrrio dos atributos, no se liga a um objeto particular.

4.8. Privacidade
Albuquerque et al. [ALBUQUERQUE 2002] explica que "privacidade a capacidade de um usurio realizar aes em um sistema sem que seja identificado. completamente diferente de confidencialidade, que define que apenas usurios autorizados podem ter acesso determinada informao". Um exemplo de sistema que emprega privacidade como atributo essencial o usado pelo processo eleitoral brasileiro, no qual no pode haver forma de ligao entre o eleitor e seu voto. As formas de privacidades destacadas pelo Common Criteria so: Anonimato - garante que um usurio possa usar um recurso ou servio sem ter sua identidade revelada. Pseudnimo - garante que um usurio possa usar um recurso ou servio sem ter sua identidade revelada, porm suas aes so rastreadas e reveladas, geralmente, em situaes especiais. Portanto, permite a responsabilizao e privacidade ao mesmo tempo. Se usado com no-rastreamento, para cada ato deve ser usado um pseudnimo diferente.
55

No-rastreamento - garante que um usurio possa fazer uso de vrios recursos e servios sem que outros possam lig-lo a esses usos. Invisibilidade - garante que um usurio possa usar um recurso ou servio sem que outros, principalmente terceiros, possam saber que o recurso ou servios est sendo usado.

Muito usado na web, um cookie representa um risco maior ao no-rastreamento do que o anonimato do usurio. Por si s, cookies no podem identificar usurios, mas um site pode saber se uma segunda vez que o usurio o acessa, assim como as pginas que navegou.

4.9. Autoproteo
importante notar que h uma distino entre atributos, funes e informaes do sistema, para seu funcionamento especfico, e atributos, funes e informaes de segurana do sistema. O primeiro grupo foca na proteo dos dados do usurio, enquanto o segundo na proteo dos dados da segurana do sistema. Existem trs pontos que podem ser destacados nas funes de segurana do sistema: Camada subjacente (abstract machine), que a plataforma (sistema operacional ou hardware) sob a qual o sistema opera. Uma plataforma comprometida representa um risco para o sistema. Implementao das funes de segurana, que opera sob a camada subjacente e implementa os mecanismos que protegem o sistema. Dados e atributos de segurana, que so o banco de dados administrativo que orientam a proteo do sistema.

56

A implementao de um dos itens acima sem os demais representa um alto risco e pode comprometer a segurana como um todo. importante cuidar dos trs aspectos. O Common Criteria define um grupo de famlias importantes para proteo da segurana: Teste de camada subjacente Falha Segura Disponibilidade de dados exportados pelo sistema Confidencialidade dos dados exportados pelo sistema Integridade dos dados exportados pelo sistema Transferncia interna de dados Proteo fsica do sistema Recuperao segura Deteco de repetio Monitor de referncia Separao de domnios Protocolo de sincronizao de estado Registros de tempo (time stamp) Consistncia de dados entre funes de segurana Consistncia de dados replicados Autoteste

Sistemas que no implementam proteo nas funes de segurana comprometem a segurana dos dados do usurio, pois controles de proteo tornam-se vulnerveis e, dessa forma, comprometem a segurana como um todo. Albuquerque et al. [ALBUQUERQUE 2002] considera essencial a existncia dos seguintes mecanismos:

57

Controle de acesso a dados de segurana a integridade, disponibilidade e confidencialidade devem ser controladas e garantidas pelo sistema. Autoteste todo sistema de segurana precisa ter sua integridade verificada no incio de execuo. Proteo fsica o hardware sob o qual o sistema opera, precisa ter um nvel mnimo de segurana para evitar comprometimento do sistema. Teste da camada subjacente deve-se verificar se a plataforma ou o sistema operacional seguro e no foi comprometido. Falha segura erros no prprio sistema ou na camada subjacentes devem ter seus efeitos atenuados pelo sistema.

Os dados de segurana devem ser protegidos de forma anloga aos dados do usurio. Isto , as medidas (controle de acesso, integridade, disponibilidade, informao residual e outros) que protegem os dados do usurio devem tambm proteger os dados de segurana.

4.10. Utilizao de recursos

O Common Criteria define trs atributos que tratam da disponibilidade dos recursos, como capacidade de processamento e/ou de armazenamento. Os atributos so tolerncia a falhas, prioridade de servios e alocao de recursos. Sistemas que envolvem segurana precisam de uma poltica de utilizao de recursos que garanta espao e prioridade para suas rotinas de segurana. Muitos sistemas operacionais fornecem tais caractersticas, facilitando a implementao dos controles de recursos simples e permitindo a delegao atravs de uma premissa de uso ou de ambiente. O atributo tolerncia a falhas trata das falhas com degradao e limitada. Tolerncia a falhas com degradao indica que o sistema capaz de manter-se em funcionamento de algumas de suas partes no caso de certas falhas. Tolerncia a falhas
58

limitada define que o sistema mantm em funcionamento todas as suas partes no caso de determinadas falhas. O sistema pode ter conjuntos de falhas em grupos diferentes. A prioridade de servios dividida em dois nveis: priorizao de recursos limitada, que define que o sistema garante uma priorizao ao acesso a recursos, para um subconjunto destes; e priorizao total de recursos, que define que todos os recursos so priorizados pelo sistema. A alocao de recursos estabelece limites no uso dos recursos disponveis. Cotas mximas podem ser estabelecidas para que um processo no monopolize os recursos do sistema. O uso de cotas mnimas e mximas, alm de evitar o monoplio, evita que algum processo fique sem nenhum recurso.

4.11. Controle de Sesses

O controle de sesses envolve desde questes como notificar o usurio sobre quais foram seus ltimos acessos, geralmente informando quando e de qual local, at o cancelamento automtico de sesses quando um mesmo usurio estiver simultaneamente conectado em equipamentos distintos. As notificaes a respeito dos ltimos acessos podem englobar informaes dos acessos no s bem-sucedidos como tambm dos malsucedidos, para que o usurio saiba se houve tentativa de acesso atravs de sua identificao. As sesses tambm podem ser restringidas a determinados horrios e dias, como o horrio comercial. Se uma sesso ficar parada sem uso durante muito tempo, regras como o seu cancelamento automtico podem ser estabelecidas [WHEELER 2003]. O acesso ao sistema envolve uma srie de aspectos que podem ser usados para ajudar na estratgia de segurana: Limitao do acesso ao sistema conforme o tipo de acesso (local, via rede, via Internet) e a hora do acesso (hora de trabalho normal,
59

fora do expediente), o usurio pode ser impedido de executar o sistema. Limitao do escopo do sistema conforme o tipo de acesso (local, via rede, via Internet) e a hora do acesso (hora de trabalho normal, fora do expediente), o usurio pode ser limitado a algumas funes do sistema. Limitao do nmero de acessos restringir o nmero mximo de sesses de um usurio. importante considerar que um usurio pode querer acessar, por exemplo, simultaneamente do seu desktop e notebook. Pode ocorrer tambm da sesso ficar congelada devido a alguma falha no processo de encerramento. Mensagem de acesso solicitar que o usurio confirme a leitura de uma mensagem antes de liberar o acesso ao sistema. O objetivo responsabilizar legalmente ou alertar para o caso de algum erro de operao. Histrico de acesso informar ao usurio quando foi o ltimo acesso com sucesso e eventuais falhas na autenticao ou no estabelecimento da sesso. Travamento de sesso meios de o usurio bloquear o console sem encerrar a sesso. Aps um travamento, intencional ou no, a forma de se voltar a ter acesso sesso deve ser por meio de reautenticao do usurio identificado na sesso.

4.12. Canais seguros

Albuquerque et al. [ALBUQUERQUE 2002] define que um canal seguro ou confivel uma camada de comunicao entre o usurio e o sistema ou entre o sistema e outros sistemas e que oferece uma srie de caractersticas:
60

Os dados de segurana so isolados dos dados do usurio Os canais devem ser iniciados de forma especfica, seja pelo sistema, seja pelo usurio O canal prov no-repdio de origem e recebimento, garantindo para cada uma das partes que a outra quem afirma ser

Canal e caminho confivel distinguem-se na medida em que canais confiveis focam a comunicao entre sistemas, geralmente criados atravs da distribuio de chaves pblicas e privadas para os sistemas e usurios envolvidos. O caminho confivel, por sua vez, foca na comunicao entre o usurio e o sistema, buscando garantir que o usurio est efetivamente acessando o sistema desejado, por exemplo, para fazer autenticao. Canais seguros so especialmente recomendados quando existe a necessidade de garantir no-repdio para um grande nmero de aes.

61

V - ARQUITETURA DE SOFTWARE SEGURO

5.1. Introduo
Mendes [MENDES 2002] descreve arquitetura de software como o estudo da organizao global dos sistemas de software bem como do relacionamento entre subsistemas e componentes. A arquitetura de software uma rea relativamente nova na engenharia de software. At a dcada de 1980 o tema no despertava interesse de pesquisadores e profissionais, quando Mary Shaw [SHAW 1989] destacou a necessidade de considerar o nvel organizacional ou arquitetural dos sistemas. Na dcada de 1990 foi publicado o precursor livro sobre arquitetura de software de Mary Shaw e David Garlan [SHAW 1996] que abordou diversas questes da nova rea. A arquitetura de software constitui-se em um fator relevante no projeto de sistemas de software de grande porte. Com base em discusses ocorridas no Software Engineering Institute da Carnegie Mellon University, David Garlan e Dewayne Perry [GARLAN 1995] definiram arquitetura de software como "a estrutura dos componentes de um programa/sistema, seus inter-relacionamentos, princpios e diretrizes guiando o projeto e evoluo ao longo do tempo". Existem muitas definies para arquitetura de software [LARMAN 2002] e em vrios casos autores tratam de estender a definio de forma a aumentar sua completitude, muito em funo de tratar-se de uma disciplina recente [HOHMANN 2002, BASS 1998, LARMAN 2002], embora convirjam na definio que arquitetura de software tem relao com sistemas grandes [HOHMANN 2002]. Algumas definies tornam-se demasiadamente complexas para uma simples compreenso. Booch [BOOCH 1999], por exemplo, define que uma arquitetura o conjunto de decises significativas sobre a organizao de um sistema de software, a seleo dos elementos estruturais e suas interfaces pelas quais o sistema composto, junto com o comportamento especificado na colaborao entre outros elementos, a composio dessas estruturas e os elementos
62

comportamentais nos subsistemas progressivamente maiores e o estilo arquitetural que guia essa organizao esses elementos e suas interfaces, colaboraes e composies. O aumento da complexidade e tamanho dos sistemas faz com que o problema de desenvolvimento ultrapasse o projeto das estruturas de dados e algoritmos. Isto , projetar a estrutura global de um sistema emerge como um problema relativamente novo, ou seja, desenvolvimento de software orientado para arquitetura [MENDES 2002]. O desenvolvimento no nvel arquitetural compreende questes estruturais, dentre as quais pode-se destacar: Seleo de alternativas de projeto; Escalabilidade e desempenho; Organizao e estrutura geral de controle; Protocolos de comunicao, sincronizao; Atribuio de funcionalidade a componentes de projeto.

Projetos de engenharia de software tendem a requerer projeto arquitetural de software. importante ser capaz de reconhecer estruturas comuns utilizadas em sistemas j desenvolvidos que possibilite aos projetistas compreender as relaes existentes entre sistemas e desenvolver novos sistemas com base em variaes de sistemas antigos. Entender as arquiteturas de software existentes permite aos engenheiros de software decidir sobre alternativas de projeto. Uma descrio arquitetural do sistema importante para analisar e descrever propriedades de um sistema complexo. Conhecer notaes formais para descrio de paradigmas arquiteturais permite que engenheiros possam apresentar novos projetos de sistema para outros usurios. A arquitetura de software busca analisar as propriedades do software no nvel de subsistema ou mdulo. Examinando o papel da arquitetura em um contexto mais amplo do gerenciamento de processo de software e da tentativa de ordenar as diversas tcnicas que
63

tm surgido. Mendes [MENDES 2002] aponta alguns possveis benefcios em que a arquitetura pode: Atuar como uma estrutura a fim de atender aos requisitos de sistema; Ser usada como aspecto tcnico para o projeto de sistema bem como suporte na estimativa de custo e na gerncia do processo; Servir de base para a anlise da consistncia e da dependncia; Prover suporte ao reuso.

5.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 [ALBUQUERQUE 2002]. 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 [HOWARD 2002]. Albuquerque et al. [ALBUQUERQUE 2002] considera que o cdigo seguro muita vezes implica em certa perda de desempenho. Entretanto, ressalva que a perda de performance pode ser compensada por um hardware mais rpido, o contrrio, porm, no verdadeiro. A perda de performance pode ser compreendida por sugestes como as de Viega et al. [VIEGA 2003]: assuma que toda entrada de dados culpada at que se prove o contrrio ou quanto mais voc compreende o dado, mais facilmente voc o filtrar. Torres [TORRES 2003] tambm cauteloso ao tratar as entradas de dados, especialmente em uma arquitetura cliente-servidor e, sobretudo, nas solicitaes provenientes de ambientes inseguros ou pouco controlado como o caso da Internet.
64

A necessidade de escrever cdigos capazes de resistir a perspiccia de atacantes sobremaneira importante devido a pouca importncia que o tema desperta mesmo em organizaes que supunham-se fortemente interessadas. Howard [HOWARD 2002] alerta que o verdadeiro problema de muitas empresas desenvolvedoras de software que segurana no vista como uma funo geradora de receita no processo de desenvolvimento. Por isso, ainda segundo Howard, a gerncia no quer gastar dinheiro treinando desenvolvedores para escrever cdigos seguros, mas gasta com tecnolgias de segurana, porm geralmente aps sofre algum tipo de ataque. O professor e autor Ross Anderson, da Universidade de Cambridge, pesquisa, entre outros assuntos, a respeito das implicaes econmicas na segurana da informao (economics of information security). Os estudos investigam, por exemplo, as motivaes econmicas que levam a que muitos sistemas falhem no por razo tcnica, mas por incentivo desarmnico geralmente quem pode protege-los no so as pessoas que sofrem os custos da falha [ANDERSON 2001]. Algumas recomendaes importantes so listadas, mas no se limitam a estas, sobre meios de se melhorar a qualidade do cdigo. Conforme fora dito, as recomendaes, embora importantes para reforar a robustez do cdigo escrito, no devem ser encaradas como definitivas. Outros cuidados devem ser necessrios dependendo da aplicao, arquitetura e plataforma sob a qual opera. Criar funes intrinsecamente seguras Todas as funes devem verificar os dados de entrada para impedir perda de controle do sistema, falhas gerais de proteo ou outros tipos de falhas [ALBUQUERQUE 2002, HOWARD 2002, VIEGAS 2003, TORRES 2003]. A maior preocupao evitar o estouro de buffer (buffer overflow). Usar funes intrinsecamente seguras Uma funo intrinsecamente insegura a strcpy (em C e C++ copia uma string). A funo recebe dois ponteiros como parmetros e copia todo o contedo, de uma para o outro, at encontrar 0. Se chamada com parmetro invlido, pode gerar resultados
65

imprevisveis. Uma alternativa melhor seria a funo strncpy, que permite limitar o tamanho mximo a ser copiado. Linguagens tipadas, como Visual Basic e Delphi, por exemplo; so menos suscetveis a esses problemas, mas no imunes. Algumas funes da API (Application Program Interface) do sistema operacional no so intrinsecamente seguras [ALBUQUERQUE 2002]. Testar o retorno de funes Sempre que se chamar uma funo, seu retorno precisa ser verificado [ALBUQUERQUE 2002]. 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 [VIEGAS 2003]. preciso atentar para a falha segura, isto , encontrar a alternativa com menor impacto, que traga menos risco. Um exemplo:

If ( LogonUser( Usuario, Senha ) == ERRO_SENHA_INVALIDA ) { /* Usurio e/ou senha invlidos */ Return 0; } Return 1;

Embora aparentemente inofensiva, se a funo LogonUser retornar um resultado inesperado, por exemplo em conseqncia de uma falha na conexo com o servidor, e retornar um outro erro. O mais seguro seria:

If ( LogonUser( Usuario, Senha ) == SUCESSO ) { /* Usurio e/ou senha invlidos */ Return 1; }

/* Usurio e/ou senha invlidos */ Return 0; Documentar funes corretamente A correta documentao da funo evita mal-entendidos a respeito da interpretao da mesma.

66

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 [TORRES 2003]. Esse ataque explora caractersticas da linguagem SQL que permite o uso de caracteres com funes especiais, como comentrio. Um exemplo seria:

_sql = SELECT * FROM Login WHERE Login= + txtLogin.Value +

Se for feita a atribuio: txtLogin = OR 0=0 # O comando final ser: SELECT * FROM Login WHERE Login= OR 0=0 #

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. 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. 3. 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. 4. 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. 5. No armazenar senhas e chaves criptogrficas no cdigo Senhas e chaves criptogrficas em cdigos podem ser reveladas atravs de engenharia reversa. O
67

armazenamento de chaves criptogrficas deve ser alvo de anlise criteriosa, assim como os algoritmos empregados. 6. Operar com o privilgio necessrio As aplicaes deveriam rodar com o privelgio requerido para desempenhar suas tarefas. Qualquer falha sria, como estouro de buffer, comprometeriam menos se a aplicao operasse com poucos privilgios [HOWARD 2002].

5.3. Padres de desenvolvimento

Uma das consideraes preliminares sobre padres que embora possa parecer que se resolva problemas completamente diferentes a todo momento, a maioria dos problemas que enfrentamos so gerados pelas ferramentas que usamos e no pelo problema externo que temos [CHRISTOPHER 1970]. Por isso, no se pode esperar encontrar problemas comuns com solues comuns, mesmo com a enorme diversidade de contextos externos de soluo de problemas. Empregar objetos para organizar a computao um dos melhores exemplos de solues para resolver problemas comuns. O grande sucesso dos padres de desenvolvimento a prova, por meio dos que programam a objeto [GAMMA 1995]. Os padres de desenvolvimento, entretanto, no limitam-se fase de design. A fase de manuteno tambm o empregar com uma abordagem um pouco diferente. Pode-se destacar, em especial, tcnicas como a refatorao1 (refactoring) como forma de aplicar os padres de desenvolvimento numa fase posterior de criao [BECK 2002]. Os padres de desenvolvimento visam melhorar a estrutura interna de um programa, garantir maior legibilidade do cdigo, padronizao da codificao, facilidade

Refatorao (Refactoring) o processo de alterao de um sistema de software de modo que seu comportamento externo no mude.

68

na manuteno, maior produtividade, rapidez no desenvolvimento, reduzir a quantidade de cdigo e facilitar a deteco de erros. Fowler [FOWLER 2004] apresenta uma srie de situaes em que os padres de desenvolvimentos poderiam ajudar a melhorar a qualidade do cdigo: Cdigo Duplicado Mtodo Longo Classes Grandes Lista de Parmetros Longa Alterao Divergente Cirurgia com Rifle Inveja dos Dados Grupos de Dados Obsesso Primitiva Comandos Switch / Case Hierarquias Paralelas de Herana Classe Ociosa Generalidade Especulativa Campo Temporrio Cadeia de Mensagens Intermedirio Intimidade Inadequada Classes Alternativas com Interfaces diferentes Biblioteca de classe incompleta Classe de Dados Herana Recusada Comentrios

69

Os padres de desenvolvimento, como fora comentado anteriormente, no se restringem a etapa de criao (codificao inicial). Os padres servem tambm etapa de manuteno e testes. Por exemplo, sempre que houver adio de novas funcionalidades que altere trechos de cdigo, reviso de cdigo e correo de bugs os padres podero ser aplicados.

5.4. Testes de Segurana

Stott et al. [STOTT 2004] argumenta que a maioria dos processos parte do princpio que o design pode ser feito no incio e o software criado ao longo do desenvolvimento. Um padro similar a de linha de produo, que prioriza a uniformidade e simplifica as variaes. A dificuldade em projetar o sistema todo no incio deve-se a prematuridade do conhecimento, ainda ser muito cedo para entender toda a complexidade do projeto. Segundo Beck [BECK 2002], o desenvolvimento dirigido a teste parte do pressuposto que se o cdigo for bem escrito, mais chance ele ter de ser bem-sucedido. O desenvolvimento dirigido a teste ajuda a enfocar o fator correto no momento oportuno, de forma que se possa criar design limpo, aperfeioando-o progressivamente. Ainda conforme Beck, a boa engenharia responsvel por 20% de um projeto bem sucedido. Engenharia ruim pode afundar um projeto, mas engenharia modesta pode permitir o sucesso de um projeto enquanto os 80% permitirem. Nessa perspectiva, o desenvolvimento dirigido a teste permite que se escrevam cdigos com menos defeitos e mais limpo que a mdia normal. Antes de se pensar em testes, algumas perguntas bsicas devem ser feitas [BECK 2002]: O que se deseja com o teste? Quando testar?
70

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

O teste uma pea central na filosofia XP (Extreme Programing) [ASTELS 2002]. Nela, o teste ocorre 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, deve ser testado [JEFFRIES 2001]. Kent Beck e Erick Gamma [BECK 1994] desenvolveram uma estrutura para escrever testes de unidade. A verso inicial foi escrita para Smalltalk e recebeu o nome de sUNIT. Da em diante ele foi portado para outras linguagens [ASTELS 2002]. Wake [WAKE 2002] usa a metfora do semforo de trnsito para ilustra o fluxo no desenvolvimento orientado a testes: Luz amarela escreva e compile o teste. Ele no compilar. Luz vermelha escreva o cdigo requerido para compilar, compile e execute o teste. Ele falhar. Luz verda escreva o cdigo para passar no teste. Execute o teste. Ele passar. Antes da dcada de 1990, a atividade de teste era geralmente realizada no fim do ciclo de desenvolvimento, normalmente pelos prprios analistas de sistemas. A inteno era avaliar se o sistema funcionava e queria-se encontrar erros. No haviam ainda tcnicas e nem metodologias estruturadas de teste. Em 1979, Glenford Myers [MYERS 1979] publicou um livro que destacava que testar era procurar defeitos e no provar que o software estava funcionando. David Gelperin e Bill Hetzel [GELPERIN 1988] descreveram um processo de evoluo dos testes batizando um documento como Plano de Testes, o qual deveria ser escrito a partir dos requisitos do sistema e deveria ajudar a reduzir a quantidade de defeitos dos sistemas, dando aos testadores os objetivos a serem alcanados durante a atividade de teste.

71

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 ser adaptadas para o novo [RIOS 2002]. 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.
72

Validao de Funcionalidade: Garantir que no existam diferenas entre os requisitos funcionais e o comportamento do software. 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.
73

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 [RIOS 2002].

74

VI - GESTO DO DESENVOLVIMENTO DE SOFTWARE SEGURO

6.1. Introduo
Implantar um processo de qualidade um passo significativo para se desenvolver software seguro, embora um no seja pr-requisito e nem o outro conseqncia [ALBUQUERQUE 2002]. Uma vez atingida a maturidade necessria para tornar o processo uma prtica cotidiana, passa-se a enfrentar os desafios provenientes da nova forma de trabalhar: adotar prticas que permitam controlar e melhorar o processo continuamente. No se pode controlar o que no se pode medir [DEMARCO 1989]. O que medido conseguido [KAPLAN 2004]. Segundo DeMarco [DEMARCO 1989], a mtrica um nmero que vincula a uma idia. Mais precisamente, uma indicao dimensvel de algum aspecto quantitativo do sistema. As mtricas recomendadas para um software comum so: escopo, tamanho, custo, risco e tempo empregado. Segurana, como seria de se esperar, talvez pela novidade do tema, no citada. Ainda que fosse, as dvidas sobre as tcnicas usadas e as novas propostas so relativamente obscuras em engenharia de software. Outra questo a ser acompanhada continuamente a ocorrncia de incidentes e divulgao de vulnerabilidades. preciso estar preparado tanto para identificar um incidente, quanto para difundir as correes e alertar aos interessados. Segurana um tema que no se esgota nas boas prticas. preciso acompanhar seu desenvolvimento e educar-se para evitar a criao de vulnerabilidades, sem que se incorra na criao de novas. Alguns dos tpicos comentados a seguir so procedentes da rea de redes (networking) e a incluso visa, seno integr-los aos assuntos pertinentes a desenvolvimento estreitando o relacionamento dos que sofrem os efeitos de softwares
75

vulnerveis com os que projetam , permitir que a engenharia de software possa aprender com a experincia de outras reas.

6.2. Mtrica de Segurana

Dois tipos de mtricas so usadas atualmente para determinar a segurana de um sistema: em nvel de cdigo, contando-se o nmero de bugs encontrados ou consertados de uma verso para outra, e em nvel de sistema, contando-se o nmero de vezes que um sistema citado nos avisos como CERT [CERT], Microsoft Security Bulletins [MICROSOFT], MITRE Common Vulnerabilities and Exposures (CVEs) [MITRE]. Howard et al. [HOWARD 2003a] considera que as medidas em nvel de cdigo, atravs da contagem e anlise de bugs [CHOU 2001, GRAY 1990, LEE 1993, SULLIVAN 1991], no tinham objetivos claros de estabelecer correspondncia entre a contagem de bug com vulnerabilidade de sistemas. Em nvel de sistema, Browne et al. [BROWNE 2001] definiu um modelo analtico que assemelha-se s classificaes nas quais incidentes so reportados para o CERT. Posteriomente, Beattie et al. [BEATTIE 2002] elaborou um modelo matemtico sobre o tempo da aplicao de patches de correes para o funcionamento contnuo condizente, baseado na coleta de registros do CVE [MITRE]. Segundo Howard et al. [HOWARD 2003a], ambos os estudos empricos focaram-se nas vulnerabilidades com respeito as suas descobertas, explorao e forma de remediar ao longo do tempo ao invs de simplesmente coletar pontos de vulnerabilidades em um sistema.

6.2.1. Superfcie de Ataque

Uma nova mtrica foi proposta baseada na idia de superfcie de ataque, considerando que as mtricas prevalecentes, apesar de teis, eram insatisfatrias [MANADHATA 2004]. A superfcie de ataque constitui-se das aes do sistema
76

externamente visveis aos usurios junto com os recursos do sistema acessado ou modificado por cada ao. Quanto mais aes estiverem disponveis a um usurio ou quanto mais recursos forem acessveis por essas aes, mais exposta ser a superfcie de ataque. E, quanto mais exposta estiver, mais suscetvel o sistema estar a ataques com chances de sucesso, portanto mais inseguro ser. A nova mtrica visa reduzir a superfcie de ataque para diminuir a probabilidade de ataque e tornar o sistema mais seguro. Os ataques registrados nos ltimos anos mostraram que certos recursos dos sistemas tm mais tendncia de serem oportunidades de ataque que outros. Por exemplo, servios executados com privilgio de root esto mais sujeitos de virarem alvos de ataques que servios operando sem altos privilgios. Arquivos com controle total (rwxrwxrwx no Unix) so mais provveis de serem atacados que arquivos com privilgios mais restritos. A nova mtrica proposta considera que nem todos os recursos do sistema devem ser tratados de forma igual. A identificao dos recursos do sistema que so oportunidades de ataque feita por um conjunto de propriedades associadas com os recursos e categorizadas em classes de ataque. Tais propriedades referem-se oportunidade de ataque ou "atacabilidade" (attackability) de um tipo de recurso, isto , alguns tipos de recursos so mais vulnerveis a ataques que outros. Com um conjunto de classes de ataque e duas verses de um sistema, possvel medir qual o mais relativamente seguro submetendo-os a uma comparao em relao s classes de ataque. As comparaes podem ser feitas de formas diferentes. Um exemplo seria, para cada verso, deve-se contar o nmero de instncias de cada classe de ataque (nmero de servios rodando como root e a quantidade de sockets abertos) e comparar os nmeros entre cada uma das respectivas verses. Pode-se refinar as contagens determinando pesos maiores para certas classes em relao a outras. Os pesos representariam a probabilidade de ataque. O mtodo dessa nova mtrica mais eficaz para comparar sistemas similares do que dois sistemas completamente diferentes, pois sistemas diferentes podem ter conjuntos de classes de ataque distintos.
77

Michael Howard foi o primeiro a aplicar informalmente a superfcie de ataque como mtrica de segurana para o sistema operacional Windows [HOWARD 2003b]. Howard, Pincus e Wing definiram uma lista de vinte classes de ataque para o sistema operacional e as compararam em sete verses do mesmo sistema operacional [HOWARD 2003a]. Inspirados pelo Quociente da Superfcie Relativa de Ataque (RASQ, em ingls) de Howard [HOWARD 2003b], Pratyusa Manadhata e Jeannette M. Wing empregaram a mtrica na medio das classes de segurana do sistema operacional Linux e comparam com as classes do Windows [MANADHATA 2004]. Howard et al. [HOWARD 2004] ressalta que o princpio da reduo da superfcie de ataque a reduo do uso do cdigo a zero. A reduo seria alcana, por exemplo, pelo emprego da regra como a 80/20, a qual pode ser definida como "se oitenta por cento dos usurios no usam, desligue o recurso, mas permita que possa-se relig-lo". Destaca ainda que combinar a qualidade do cdigo reduo da superfcie de ataque pode levar a produo de software mais seguro, o que inatingvel apenas com cdigo perfeito. Um processo simples para ajudar a reduzir a superfcie de ataque e, conseqentemente, melhorar a segurana do sistema seria: Reduzir a quantidade de cdigo em execuo aplicando a regra 80/20 a todas as reas funcionais, se oitenta por cento dos usurios no a usarem, deve-se considerar a possibilidade de deslig-la. Reduzir o acesso a pontos de entrada para usurios no confiveis restringir o acesso a quem no deveriam, em essncia, usar determinado recurso e fortalecer os princpios de autenticao. Reduzir o privilgio para limitar o potencial de dano reduzir os privilgios sob os quais o cdigo deve ser executado. Caminhos de cdigo annimo analisar o diagrama de fluxo de dados (DFD) ou diagrama de interao da UML (Unified Modeling Language) e
78

identificar os pontos de entrada do sistema. A anlise permitir identificar se h a necessidade de aumentar o nvel de autorizao nesses pontos. Cuidado com protocolos aplicar a regra 80/20 a todos os protocolos. Reduzir a superfcie de ataque preventivamente descrever na fase de projeto como ser a superfcie de ataque, preferencialmente registrando em um documento. Alguns itens a serem considerados so: protocolos de rede, pontos (endpoints) que devem suportar autenticao ou autorizao (ateno redobrada nos endpoints annimos), desligar recursos por default, componentes reutilizveis usados, identidades de processos de todos os cdigos executados e contas de usurios instaladas. Dessa forma, os desenvolvedores conhecero desde o incio como ser a superfcie de ataque. Medir a superfcie de ataque determine a superfcie de ataque mnima no incio e mea-a ao longo do desenvolvimento. Grande superfcie de ataque resulta em grande trabalho de segurana se uma grande superfcie de ataque for inevitvel, o cdigo deveria ser de boa qualidade, conservador e defensivo.

6.2.2. Outras Mtricas

Muito tem-se feito na rea de modelagem quantitativa da segurana de sistemas. Brocklehurst et al. [BROCKLEHURST 1994, LITTLEWOOD 1993] mede a segurana operacional de um sistema estimando o esforo despendido por um atacante para descobrir uma brecha de segurana e o benefcio associado a ela. Alves-Foss et al. [ALVES-FOSS 1995] usa o ndice de Vulnerabilidade do Sistema (System Vulnerability Index) obtido pela avaliao de fatores como as caractersticas do sistema, atos potencialmente negligentes e atos potencialmente malevolentes como uma medida de vulnerabilidade de sistema. Voas et al. [VOAS 1996] props o tempo-mnimo-para-intruso (MTTI, em ingls), mtrica baseada no tempo predito antes que qualquer intruso simulada ocorra. MTTI uma mtrica relativa que permite aos usurios comparar verses diferentes de um
79

mesmo sistema. Ortalo et al. [ORTALO 1999] modela o sistema como um privilgio grfico [DACIER 1994] exibindo suas vulnerabilidades e estimando o esforo consumido pelo atacante para perpetrar um ataque bem-sucedido, explorando tais vulnerabilidades. O esforo estimado a medida da segurana operacional do sistema. Esses trabalhos focam nas vulnerabilidades de um sistema como uma medida de sua segurana, similar idia de atacabilidade de vrios recursos de um sistema como uma medida de sua segurana, discutida no item anterior.

6.3. Monitorizao de Vulnerabilidades

O comportamento anormal de um sistema deve ser examinado para que, ao final de uma anlise, possa ser ou no considerado um incidente de segurana [RUFINO 2002]. A RFC (Request For Comments) 2142 [RFC 2142], no item "Network Operations Mailbox Names", sugere que sejam criados endereos de e-mail "abuse" e "security", respectivamente, para notificaes de uso inadequado dos recursos de rede (SPAM, por exemplo) e problemas de segurana em geral. A engenharia de software pode valer-se dessas prticas para aculturao de suas rotinas de monitoramento de incidentes. Um incidente de segurana definido como um evento relevante no qual a poltica de segurana de um sistema desobedecida ou de alguma forma violada [RFC 2828]. A RFC 3227 [RFC 3227] sugere um guia de princpio para coleta de evidncias. , na verdade, um guia para coleta e arquivamento de evidncias. So exemplos de incidentes de segurana: Tentativas de ganhar acesso no autorizado a sistemas ou dados; Ataques de negao de servio; Uso ou acesso no autorizado a um sistema; Modificaes em um sistema, sem o conhecimento, instrues ou consentimento prvio do dono do sistema;
80

Desrespeito poltica de segurana ou poltica de uso aceitvel de uma empresa.

6.3.1. Divulgao de Vulnerabilidade

Segundo Howard [HOWARD 2004], todo cdigo tem uma probabilidade diferente de zero de conter uma ou mais vulnerabilidades. Algumas delas resultaro em comprometimento do usurio. Logo, no se deve perder o controle dos usurios, pois so eles que precisaro aplicar todas as atualizaes de segurana. Se houver uma falha no cdigo, o usurio precisar corrigir as mquinas que usam o recurso defeituoso. Contar com um modelo de documento que descreva em riqueza de detalhes a vulnerabilidade divulgada, uma prtica recomendada e de interesse mtuo para usurios e fornecedores. As grandes organizaes tm aperfeioado seus boletins de divulgao e conscientizado seus usurios a l-los geralmente atravs do envio de mensagem eletrnica a usurios previamente cadastrados , alm de muitas criarem seus prprios produtos para automatizar o processo de atualizao. Os boletins deveriam ser numerados e titulados de maneira que seu contedo seja facilmente compreendido. Datar e controlar verso a verso so itens importantes, pois possvel que o conserto de uma vulnerabilidade possa levar a criao de outra ou atrapalhar o funcionamento de algum recurso diferente do objeto de reparo [HOWARD 2003a]. importante que tambm exista um resumo que indique quem deve ler o documento, o impacto da vulnerabilidade, a classificao mxima de gravidade, a recomendao aos usurios, se substituio da alguma atualizao de segurana, advertncias, lista de softwares afetados, lista softwares no afetados (de acordo com a poltica de suporte a verses da organizao).

81

A parte central do boletim de divulgao deveria conter uma sinopse, perguntas freqentes relacionadas atualizao, detalhes da vulnerabilidade e informaes adicionais sobre a atualizao divulgada.

6.3.2. Resposta a incidentes

Um Grupo de Resposta a Incidentes de Segurana, ou Computer Security Incident Response Team (CSIRT), um grupo algumas vezes uma organizao responsvel por receber, analisar e responder a notificaes e atividades relacionadas a incidentes de segurana em computadores. Um CSIRT normalmente presta servios para uma comunidade bem definida, que pode ser a entidade que o mantm, como uma empresa, um rgo governamental ou uma organizao acadmica. Um CSIRT tambm pode prestar servios para uma comunidade maior, como um pas, uma rede de pesquisa ou clientes [BROWN 2003]. Um CSIRT pode ser um grupo formal ou um grupo ad hoc. Um grupo formal tem no trabalho de resposta a incidentes a sua principal funo. Um grupo ad hoc reunido quando h um incidente de segurana em andamento ou para responder a um quando necessrio. Um CSIRT mostra-se necessrio quando um incidente de segurana ocorre, pois torna-se crtico para a organizao ter uma maneira eficaz de respond-lo. A rapidez com que a organizao pode reconhecer, analisar e responder a um incidente limitar os danos e diminuir o custo de recuperao. A idia do CSIRT estar perto e apto a conduzir uma resposta rpida para conter o incidente de segurana e para recuperar-se dele. CSIRTs tambm podem estar familiarizados com os sistemas comprometidos e, portanto, melhor preparados para coordenar a recuperao e propor estratgias de erradicao e resposta aos problemas.

82

De acordo com Pricola [PRICOLA 2005], O primeiro grupo de resposta a incidentes de segurana foi criado em 1988, aps o incidente que ficou conhecido como "The Morris Worm Incident". O worm, criado e disseminado da rede do MIT por Robert Morris, um estudante de 23 anos e filho de um diretor de segurana da agncia americana NSA (National Security Agency), foi responsvel por uma das paradas de maior impacto na Internet at ento, atingindo mais de nove mil computadores da rede. O relacionamento entre diversos CSIRTs e organizaes de segurana pode facilitar o compartilhamento de estratgias de resposta e a gerao de alertas para problemas potenciais. Os CSIRTs podem trabalhar em conjunto com outras reas da organizao de maneira pr-ativa, garantindo que novos sistemas sejam desenvolvidos e colocados em produo tendo preocupao com a segurana e em conformidade com as polticas de segurana. Eles podem ajudar a identificar reas vulnerveis da organizao e, em alguns casos, realizar anlise de vulnerabilidades e deteco de incidentes. Podem tambem focar sua ateno em prover treinamentos sobre a necessidade da preocupao com segurana. Os CSIRTs tambm podem usar sua experincia para auxiliar na reduo de futuras ameaas [RFC 2350]. Vrios acrnimos so usados para definir os grupos de resposta a incidentes existentes no mundo. Alguns dos acrnimos mais comuns incluem: CSIRT - Computer Security Incident Response Team CIRC - Computer Incident Response Capability CIRT - Computer Incident Response Team IRC - Incident Response Center or Incident Response Capability IRT - Incident Response Team SERT - Security Emergency Response Team SIRT - Security Incident Response Team

83

6.4. Comportamento seguro

A segurana to forte quanto for o sistema mais fraco [SCHNEIER 2000]. Geralmente o elo mais fraco envolve interao do sistema com humanos. Se o problema com a escolha de boas senhas, interfaces difceis de serem usadas, rotinas de instalao complicadas, procedimentos para gerenciamento de patches confusos ou ataque de engenharia social, o elo humano estar sempre presente [WING 2003a]. A engenharia social uma tcnica que no requer prtica nem to pouco habilidade, basta ter poder de convencimento e um pouco de psicologia comportamental. Quando bem executada bastante eficiente e normalmente no deixa rastros que permitam a identificao do autor [RUFINO 2002]. preciso desenvolver interfaces que faam a segurana ser menos inoportuna e intrusiva [SASSE 2001, WHITTEN 1999]. Conforme os dispositivos de computao tornam-se ubquos, necessrio esconder a segurana dos usurios, porm permitindo-lhes controle nas partes apropriadas. Tambm necessrio um comportamento cientfico para auxiliar cientistas da computao [WING 2003a]. Tecnlogos deveriam desenvolver sistemas menos suscetveis a ataques de engenharia social. medida que o nmero e a natureza dos atacantes mudam com o passar do tempo, preciso entender a psicologia do atacante: de script kiddies1 a adversrios com recursos e motivados politicamente. proporo que a biometria converte-se em um lugar comum, indispensvel entender se e como ela poderia ajudar ou atrapalhar a segurana (talvez com a criao de novas formas de ataque de engenharia social ou ajudar ou atrapalhar a privacidade) [PALLEN 2003]. Os problemas comportamentais acontecem em todos os nveis do sistema: no topo esto os usurios que no dominam computao, mas interagem com eles por diverso ou
10

Iniciantes que no criam suas prprias ferramentas de explorao, mas usam scripts de terceiros para os ataques. [HONEYNET 2002] 84

trabalho; no meio esto os usurios com conhecimento de computao que no tm, ou no deveriam ter, tempo ou interesse para lidar com as configuraes; no nvel mais baixo esto os administradores que tem a tarefa de instalar sempre as mais recentes correes de segurana sem poderem adivinhar as conseqncias decorrentes dessa instalao. preciso possibilitar que seres humanos normais usem sistemas facilmente, mas de maneira segura [WING 2003a]. importante que a mentalidade do atacante e as formas de ameaas sejam reconhecidas por aqueles que lidam com segurana. As ameaas poderiam ser divididas em dois grandes grupos: internas e externas. As ameaas internas so ocasionadas geralmente por pessoas com intenes duvidosas (testar as vulnerabilidades com ou sem ms intenes), pessoas realizando atividades no intencionais (descarregar um vrus ou outro programa nocivo inadvertidamente) e administradores que administram equivocadamente o ambiente (no usar senhas seguras ou configura inadequadamente os recursos). As ameaas externas so praticadas por agentes de fora da organizao, atravs de atividades no necessariamente intencionais, como: concorrncia, inimigos, espies, funcionrios hostis, etc. [WENSTROM 2002] A educao um fator crtico para o sucesso de um ciclo de vida de desenvolvimento seguro [LIPNER 2004]. Segundo Lipner, muitas escolas e universidades no preparam seus alunos adequadamente para que sejam incorporados fora de trabalho em atividades que envolvam o projeto, desenvolvimento ou teste de software seguro. Mesmo quem fez cursos de segurana muito provavelmente estudou algoritmos de criptografia e modelos de controle de acesso, mas no abordou adequadamente questes como buffer overflow. Em geral, desenvolvedores, arquitetos, engenheiros e testadores de software carecem de habilidades apropriadas em relao a segurana. Nessas circunstncias, uma organizao que deseja desenvolver software seguro precisa assumir a responsabilidade de treinar suas equipes apropriadamente no tema. Meio especficos de alcanar tais desafios variam dependendo do tamanho da organizao e recursos disponibilizados. Uma organizao com uma ampla populao envolvida com
85

engenharia de software pode ser capaz de comprometer-se a fornecer um programa de treinamento in-house de educao continuada em segurana, enquanto uma organizao menor pode valer-se de treinamentos externos. O importante que haja envolvimento e vontade para a construo de softwares mais seguros [WING 2003a].

86

VII - CONCLUSO
7.1. Introduo
Este trabalho apresentou meios para o desenvolvimento de software seguro aps ter sido realizada uma reviso da 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. Neste captulo so apresentadas as concluses para o trabalho e as contribuies alcanadas. Tambm so discutidas algumas perspectivas futuras para o trabalho.

7.2. Concluso e contribuio

A crescente importncia dada segurana da informao requer que sejam definidos e implementados mecanismos mais eficientes para apoiar as atividades que envolvam segurana da informao. Neste contexto, o objetivo deste trabalho foi apresentar tcnicas, metodologias, modelos e prticas que apoiem 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;
87

Especificar tcnicas determinantes para a criao de projeto arquitetural seguro; Mostrar particularidades que aperfeioam questes de segurana na conduo do desenvolvimento de software.

7.3. Perspectivas futuras

Como perspectiva mais imediata, a abordagem em engenharia de software seguro apresentada neste trabalho pretende apoiar aqueles que desejam aperfeioar processos de desenvolvimento de software para a obteno de produtos mais seguros. Diversos trabalhos podem ser definidos e desenvolvidos com o propsito de melhorar e estender a proposta apresentada, por exemplo: Estruturao do modelo de ciclo de vida 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; Elaborao de contedo pedaggico para capacitao de recursos humanos (desenvolvedores, arquitetos e engenheiros de software) em segurana da informao;

88

Outros trabalhos tambm podem ser realizados para apoiar as atividades que sucintamente foram mencionadas e outras que no foram abordadas nesse trabalho, por exemplo: Fatores econmicos como meios de viabilizar a integrao da engenharia de software e segurana da informao; O impacto de legislaes como Sarbanes-Oxley Act na engenharia de software; Contribuies que padres como COBIT e ITIL podem oferecer engenharia de software seguro.

89

VIII - REFERNCIAS
ALBUQUERQUE, R; RIBEIRO, B. Segurana no Desenvolvimento de Software, Editora Campus, 2002. ALVES-FOSS, J.; BARBOSA, S. Assessing Computer Security Vulnerability, ACM SIGOPS Operating System Review, 1995. ANDERSON, R. Why Information Security is Hard - An Economic Perspective, Annual Computer Security Applications Conference, Dezembro, 2001. ASTELS, D.; MILLER, G.; NOVAK, M. Extreme Programming Guia Prtico, Editora Campus, 2002. BARROS, ROBERTO SOUTO MAIOR prefcio para Antonio Mendes Arquitetura de Software - Desenvolvimento orientado para arquitetura, Editora Campus, 2002. BASS, L.; CLEMENTS, P.; KAZMAN, R. Software Architecture in Practice, AddisonWesley, 1998. BEATTIE, S.; ARNOLD, S.; COWAN, C.; WAGLE, P.; WRIGHT, C.; SHOSTACK, A. Timing the Application of Security Patches for Optimal Uptime, LISA XVI, Novembro, 2002. BECK, K. Simple Smalltalk Testing, Smalltalk Report, 4(2), Outubro, 1994. BECK, K. Test-Driven Development by Example, Addison Wesley, 2002. BOEHM, B.; BROWN, J. R.; LIPOW, M. Quantitative Evaluation on Software Quality, IEEE Computer Society Press, Outubro, 1976. BOEHM, B. W. et al. Characteristic of Software Quality, Amsterdam: North Holland, 1978. BOOCH, G.; RUMBAUGH, J; JACOBSON, I. The Unified Modeling Language User Guide, Addison-Wesley, 1999.

90

BROCKLEHURST, S.; LITTLEWOOD, B.; OLOVSSON, T.; JOHSSON, E. On Measurement of Operational Security, Proceedings of the 9th Annual Conference on Computer Assurance, 1994. BROOKS JR., J. P. No Silver Bullet: Essence and Accidents of Software Engineering, IEEE Computer, Vol. 20, No. 4, Abril, 1987. BROWN, M. J. W.; STIKVOORT, D.; KOSSAKOWSKI, K. P.; KILLCRECE, G.; RUEFLE, R.; ZAJICEK, M. Handbook for Computer Security Incident Response Teams (CSIRTs), CMU/SEI, Ed. 2, Abril, 2003. BROWNE, H.; MCHUGH, J.; ARBAUGH, W.; FITHEN, W. A Trend Analysis of Exploitations, IEEE Symposium on Security and Privacy, CS-TR-4200, UMIACSTR-2000-76, Maio, 2001. CARVALHO, A. M. B. R.; CHIOSSI, T. C. S. Introduo Engenharia de Software, Editora da UNICAMP, 2001. COMMON CRITERIA MUTUAL RECOGNITION AGREEMENT PARTICIPANTS, Common Criteria Mutual for Information Technology Secutity Evaluation v.2.1, Common Criteria Support Environment, 1999. COMMON CRITERIA MUTUAL RECOGNITION AGREEMENT PARTICIPANTS, Common Evaluation Methodology, Common Criteria Support Environment, 2000. COMMON CRITERIA MUTUAL RECOGNITION AGREEMENT PARTICIPANTS, Common Criteria Introduction, Common Criteria Support Environment, 2002. COMMON CRITERIA MUTUAL RECOGNITION AGREEMENT PARTICIPANTS, Common Criteria User Guide, Common Criteria Support Environment, 2002. COMPUTER EMERGENCY RESPONSE TEAm CERT/CC Advisories,

http:www.cert.org/advisories/ ltimo acesso em 24/04/05. CHOU, A.; YANG, J.; CHELF, B.; HALLEN, S.; ENGLER, D. An Empirical Study of Operation Systems Errors, ACM Symposium on Operating Systems Principles, Outubro, 2001. CHRISTOPHER, A. Notes on the Synthesis of Form, Harvard University Press, 1970.
91

CRTES, M. L.; CHIOSSI, T. C. S. Modelos de Qualidade de Software, Editora da UNICAMP, 2001. DACIER, M.; DESWARTE, Y. Privilege Guide: An Extention to the Typed Access Matrix Model, Proceedings of the Third European Symposium on Research in Computer Security, 1994. DAVIS, A. Softwtare Architecture: Objects, Functions and States, Prentice-Hall, 1993. DEAN, D.; FELTEN, E. W.; WALLACH, DS. Java Security: From HotJava to Netscape and Beyond, IEEE Symp. Security and Privacy, IEEE Press, 1996. DEMARCO, T. Controle de Projetos de Software, Editora Campus, 1989. DIFFIE, W.; HELLMAN, M. E. New Directions in Cryptography, IEEE Trans. on Inform. Theory, Vol IT-22, Novembro, 1976. DISNEI Aplicaes de Curvas Elpticas em Criptografia, III Seminrio de Informtica Segurana da Informao, Instituto Metodista Bennett e Instituto Militar de Engenharia, 2002. USA DEPARTMENT OF DEFENSE, Department of Defense Trusted Computer System Evaluation Criteria, Department of Defense Standard, Dod 5200.28-STD, Dezembro, 1985. FARINES, J.; FRAGA, J. S.; OLIVEIRA, R. S. Sistemas de tempo real, So Paulo: Escola de Computao, jul., 2000. FOWLER, M. Refatorao: Aperfeioando o Projeto de Cdigo Existente, Editora Bookman, 2004. GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J. Design Patterns: Elements of Reusable Object Oriented Software, Addison-Wesley, 1995. GARDNER, M. Mathematical Games: A New Kind of Cipher that Would Take Millions of Years to Break, Scientific American 237, Agosto, 1977. GARLAN, D.; PERRY, D. Introduction to Software Architecture, in Advances in Software Engineering and Knowledge Engineering, Vol. 1, World Scientific Publishing, 1993.
92

GELPERIN, D.; HETZEL, B. The growth of software testing, Communications of the ACM, 1988. GONALVES, L. R. O. O surgimento da Norma Nacional de Segurana de Informao NBR ISO/IEC-1779:2001, Lockabit - Portal de Segurana da Informao, COPPEUFRJ, http://www.lockabit.coppe.ufrj.br/rlab/rlab_textos.php?id=85, 2003. ltimo acesso em 10/04/2005. GOSLIN, J. The feel of Java, IEEE Computer 30, (6):53-58, 1997. GRAY, J. A Census of Tandem System Availaby Between 1985 and 1990, IEEE Transactions on Software Engineering, Vol. 39, No. 4, Outubro, 1990. GUEZZI, C.; JAZAYERI, M. Fundamentals of Software Engineering, Prentice-Hall, 1991. HOHMANN, L. Beyond Software Architecture - Creating and Sustaining Winning Solutions, Addison-Wesley, 2002. THE HONEYNET PROJECT, Conhea seu Inimigo, Makron Books, 2002. HOWARD, M.; LEBLANC, D. Writing Secure Code, Microsoft Press, 2002. HOWARD, M.; PINCUS, J.; WING, J. M. Measuring Relative Attack Surface, Proceeding of Workshop on Advanced Developments in Software and System Security, 2003. HOWARD, M. Fending Off Future Attacks by Reducing Attack Surface, Secure Windows Initiative, Fevereiro, 2003. HOWARD, M. Mitigate Security Risks by Minimizing the Code You Expose to Untrusted Users, MSDN Magazine, Novembro, 2004. SOFTWARE ENGINEERING STANDARDS COMMITTEE IEEE Recommended Practice for Software Requirements Specifications, IEEE Computer Society Press, 1993. ISO JTC 1/SC 27 Commitee ISO/IEC 15408-1:1999 Information Technology - Security Techniques - Evaluation Criteria for IT Security - Part 1: Introduction @ General Model, ISO Online Catalogue, 1999.

93

ISO JTC 1/SC 27 Commitee ISO/IEC 15408-1:1999 Information Technology - Security Techniques - Evaluation Criteria for IT Security - Part 2: Security Functional Requirements, ISO Online Catalogue, 1999. ISO JTC 1/SC 27 Commitee ISO/IEC 15408-1:1999 Information Technology - Security Techniques - Evaluation Criteria for IT Security - Part 3: Security Assurance Requirements, ISO Online Catalogue, 1999. ISO JTC 1 ISO/IEC 17799 Code of Practice for Information Security Management, ISO Online Catalogue, 1999. JEFFRIES, R.; ANDERSON, A; HENDRICKSON, C. Extreme Programming Installed, Addison-Wesley Longman, 2001. KAPLAN, R. S.; NORTON, D. P. Kaplan e Norton na Prtica, Editora Campus, 2004. KELLER, S. E.; KAHN, L. G.; PANARA, R. B. Specifying Software Quality Requirements with Metrics, IEEE Computer Society Press, 1990. LARMAN, C. Applying UML and Patterns - An Introduction to Object-Oriented Analysis and Design and the Unified Process, 2a. Ed., Prentice Hall, 2002. LEE, I.; IYER, R. Faults, Symptoms, and Software Fault Tolerance in the Tandem GUARDIAN Operationg System, Proceeding of the International Symposium on Faut Tolerant Computing, 1993. LEUTWYLER, K. Superhack: Forty Quadrillion Years Early, a 129-Digit Code is Broken, Scientific American 271, 1994. LIMA, A. P. Algoritmos de Chave Pblica: Estado da Arte, III Seminrio de Informtica Segurana da Informao, Instituto Metodista Bennett e Instituto Militar de Engenharia, 2002. LIPNER, S.; HOWARD, M. The Trustworthy Computing Security Development Lifecycle, IEEE Annual Computer Security Applications Conference, 2004. LITTLEWOOD, B; BROCKLEHURST, S.; FENTON, N.; MELLOR, P.; PAGE, S.; WRIGHT, D. Towards Operational Measures of Computer Security, Journal of Computer Security, 1993.
94

MANADHATA, P.; WING, J. M. Measuring a System Attack Surface, USENIX Security Symposium, 2004. MENDES, A. Arquitetura de Software - Desenvolvimento orientado para arquitetura, Editora Campus, 2002. MICROSOFT SECURITY RESPONSE CENTRE SECURITY BULLETINS,

http://www.microsoft.com/technet/security/ ltimo acesso em 24/04/05. MITRE Common Vulnerabilities Exposures, http://www.cve.mitre.org ltimo acesso em 24/04/05. MYERS, G. The Art of Software Testing, John Wiley & Sons, 1979. NAUR, P.; RANDELL, B.; BRUXTON, J. Software Engineering: A Report on a Conference Sponsored by NATO Science Commitee, NATO, 1969. ABNT ISO/IEC, Tecnologia da Informao - Processos de ciclo de vida de software, ABNT, 1998. ABNT ISO/IEC, Engenharia de Software Qualidade de produto. Parte 1: Modelo de qualidade, ABNT, 2003. NERY, F.; PARANHOS, M. Cobit ou ISO 17799? Iniciando a Reflexo, Mdulo Security Magazine Portal, Mdulo Security, http://www.modulo.com.br, 2005. ltimo acesso em 10/04/2005. ORTALO, R.; DESWARTE, Y.; KANICHE, M. Experimenting with Quantitative Evaluation Tools for Monitoring Operational Security, IEEE Transactions on Software Engineering, 1999. PALLEN, L.; DOURISH, P. Unpacking Privacy for a Networked World, Proc. Conf. Human Factors in Computing Systems, ACM Press, 2003. PAUL, L. G. Building Code, CSO Magazine, Fevereiro, 2005. PEDRYCZ, W.; PETERS, J. F. Engenharia de Software - Teoria e prtica, Editora Campus, 2001.

95

PRESSMAN, R. Software engineering: a practitioners approach, 3 ed., Mc-Graw Hill, 1992 PRICOLA, L. Estruturao e operao de um Grupo de Resposta a Incidentes de Segurana, Mdulo Security Magazine Portal, Parte I, http://www.modulo.com.br, 2005. ltimo acesso em 24/04/2005. RFC 2142 CROCKER, D. Mailbox Names For Common Services, Roles And Functions, Request For Comments, Maio, 1997. RFC 2350 BROWNLEE, N.; GUTTMAN, E. Expectations for Computer Security Incident Response, BCP 21, Junho, 1998. RFC 2828 SHIREY, R. Internet Security Glossary, FYI 36, Request For Comments, Maio, 2000. RFC 3227 BREZINSKI, D. Guidelines for Evidence Collection and Archiving, BCP 55, Request For Comments, Fevereiro, 2002. RIOS, E., RODRIGUES, T. Projeto e Engenharia de Software Teste de Software, Editora Alta Books, 2002. RIVEST, R. L., SHAMIR, A.; ADLEMAN, L. On a Method for Obtaining Digital Signature and Public Key Cryptosystems, Commun, ACM, Vol 21, Fevereiro, 1978. ROMAN, G. C. A Taxonomy of Current Issues on Requirements Engineering, IEEE Computer, Vol. 18, No. 4, Abril, 1985. ROSS, R.; SWANSON, M.; STONEBURNER, G.; KATZKE, S.; JOHNSON, A. Guide for the Security Certification and Accreditation of Federal Information Systems, NIST, Maio, 2004. RUFINO, N. M. O. Segurana Nacional - Tcnicas e Ferramentas de Ataque e Defesa de Redes de Computadores, Novatec Editora, 2002. SASSE, M. A.; BROSTOFF, S.; WEIRICH, D. Transforming the weakest link A Humam-Computer Interaction Approach to Usable and Effective Security, BT Technology Journal, Vol. 19, No. 3, 2001.
96

SCHNEIER, B. Applied Cryptography: Protocols, Algorithms, and Source Code in C, John Wiley & Sons, 2a. Edio, 1995. SCHNEIER, B. Secrets and Lies: Digital Security in a Networked World, John Wiley & Sons, 2000. SCHNEIER, BRUCE prefcio para Ross Anderson, Security Engineering: A Guide to Building Dependable Distributed Systems, John Wiley & Sons, 2001. SCHNEIER, B. Crypto-gram - September 15, 2004, Counterpane Internet Security Inc., 2004. SCHNEIER, B. Crypto-gram - March 15, 2005, Counterpane Internet Security Inc., 2005. SHANNON, C. E. A Mathematical Theory of Communications Systems, Bell Syst. Tech. J., Vol 27, Parte I - pg 379-423, Parte II - pg 623-656, 1948. SHAW, M. Larger Scale Systems Require Higher-Level Abstractions, Proc. of the International Workshop Engineering Notes, Vol. 20, No. 1, Janeiro, 1989. SHAW, M.; GARLAN, D. Software Architecture - Prespectives on a Emerging Discipline, Prentice Hall, 1996. SOARES, L. F. G.; LEMOS, G.; COLCHER, S. Redes de Computadores - Das Lans, Mans e Wans s Redes ATM, Editora Campus, 1995. SOMMERVILLE, I. Software Engineering, 4a. Edio, Addison-Wesley, 1992 SPYMAN Manual Completo do Hacker, 2 ed., Book Express, 1998 STOTT, W.; NEWKIRK, J. Improve the Design and Flexibility of Your Project with Extreme Programming Techniques, MSDN Magazine, Vol. 4, No. 4, 2004. SULLIVAN, M.; CHILLARGE, R. Software Defects and Their Impact on System 118 Availability, Proceeding of the International Symposium on Faut Tolerant Computing, June, 1991. TANENBAUM, A. S. Computer Networks, Prentice Hall, 2a. Edio, 1989. THAYLER, R.; DORFMAN, M. System and Software Requirements Engineering, IEEE Computer Society Press, 1990.
97

TOMELLI, Leonardo Segurana no Desenvolvimento de Software, MSDN Magazine, Vol. 1, No. 3, Janeiro, 2004. TORRES, D. Segurana Mxima de Software, Brasport, 2003. VIEGA, J.; MCGRAW, G. Building Secure Software, Addison-Wesley, 2002. VIEGA, J.; MESSIER, M. Secure Programming Cookbook for C and C++, O'Reilly, 2003. VOAS, J.; GHOSH, A.; MCGRAW, G.; CHARRON, F.; MILLER, K. Defining an Adaptive Software Security Metric from a Dynamic Software Failure Tolerance Measure, Proceedings of the 11th Annual Conference on Computer Assurance, 1996. WAKE, W. C. Extreme Programming Explored, Addison Wesley Longman, 2002. WENSTROM, M. J. Managing Cisco Network Security, Editora Alta Books, 2002. WHEELER, D. A. Secure Programming for Linux and Unix HOWTO,

http://www.dwheeler.com/secure-programs, 2003, ltimo acesso em 02/04/2005. WHITTEN, A.; TYGAR, D. Why Johnny Cant Encrypt, Proceeding of 8th Usenix Security Symposium, 1999. WING, J. M. Beyond the Horizon: A Call to Action, IEEE Security and Privacy. Novembro/Dezembro 2003. YOURDON, E. Projetos Virtualmente Impossveis, Makron Books, 1999.

98