PÓS GRADUAÇÃO LATO SENSU EM ENGENHARIA DE

SOFTWARE

ENGENHARIA DE SOFTWARE SEGURO

(Segurança em Desenvolvimento de Software)

Monografia apresentada em cumprimento

às exigências para obtenção de grau no
curso de pós-graduação lato sensu de
especialização em Engenharia de Software.

Por:
Renato Pessanha da Silva

Rio de Janeiro
2005
DEDICATÓRIA

Aos meus pais, por tudo.

Especialmente pela
oportunidade que me deram de
estudar.

ii
AGRADECIMENTOS

Primeiramente a Deus, pelas

condições para realizar esse
trabalho.
A Marcele pelo inestimável
estímulo e ajuda.
A Werther e Mônica pela
fraterna colaboração.
A Celso e Sérgio Lima pelo
apoio em trabalhos.
A Pecegueiro e Lavelle pelo
auxílio no levantamento da
literatura.
A Cátia pela orientação.
Aos demais colegas de turma e
professores pelo ano de
aprendizado.

iii
EPÍGRAFE

Sou um técnico, mas tenho

técnica só dentro da técnica.
Fora disso sou doido, com todo
o direito a sê-lo. Com todo o
direito a sê-lo, ouviram?

Fernando Pessoa

iv
 RESUMO

Informação tornou-se um ativo valioso e estratégico. A

chamada era da informação, caracterizada principalmente pela
inclusão digital e disseminação da Internet, a disponibilizou em um
volume significativo e sem precedente na história. Não tardou para
que a aparição de ameaças à confidencialidade, integridade e
disponibilidade comprometessem a tendência inicial de expansão.
Os processos de melhoria da qualidade não resultaram no
desenvolvimento de produtos mais seguros e duas vertentes
desarmônicas – engenharia de software e segurança da
informação – têm trabalhado de forma suplementar e isolada para
atenuar os danos decorrentes das vulnerabilidades. Esse trabalho
investiga formas para capacitar organizações desenvolvedoras a
unir engenharia de software e segurança da informação para a
produção de software naturalmente seguro.

v
 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
 SUMÁRIO

DEDICATÓRIA ............................................................................................................................................. II

AGRADECIMENTOS ..................................................................................................................................III

RESUMO .........................................................................................................................................................V

ABSTRACT ................................................................................................................................................... VI

SUMÁRIO.....................................................................................................................................................VII

I- INTRODUÇÃO ................................................................................................................................... 7
1.1. MOTIVAÇÃO ............................................................................................................................................ 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. INTRODUÇÃO ..........................................................................................................................................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 Segurança em Metodologias.......................................................................................16
2.4. DIFERENÇA ENTRE SOFTWARE SEGURO E DE QUALIDADE......................................................................20
III - GARANTIA DE SEGURANÇA........................................................................................................21
3.1. INTRODUÇÃO ..........................................................................................................................................21
3.2. AMBIENTE SEGURO DE DESENVOLVIMENTO ...........................................................................................21
3.2.1. Gerência de Configuração .............................................................................................................22
3.2.2. Distribuição....................................................................................................................................22
3.2.3. Desenvolvimento.............................................................................................................................23
3.2.4. Documentação................................................................................................................................23
3.2.5. Suporte ao Ciclo de Vida................................................................................................................24
3.2.6. Testes de Segurança .......................................................................................................................24
3.2.7. Avaliação 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. Visão Geral.....................................................................................................................................33
3.5.3. Fase Requisitos (Requirements) .....................................................................................................34
3.5.4. Fase de Design ...............................................................................................................................35
3.5.5. Fase de Implementação ..................................................................................................................36
3.5.6. Fase de Verificação ........................................................................................................................37
3.5.7. Fase de Liberação ..........................................................................................................................38
3.5.8. Fase de Manutenção (Support and Servicing) ...............................................................................38
IV - REQUISITOS FUNCIONAIS DE SEGURANÇA ..........................................................................40

vii
 4.1. INTRODUÇÃO ..........................................................................................................................................40
4.2. AUDITORIA .............................................................................................................................................41
4.3. COMUNICAÇÃO - REPÚDIO .....................................................................................................................43
4.4. CRIPTOGRAFIA .......................................................................................................................................44
4.5. PROTEÇÃO DE DADOS DO USUÁRIO .........................................................................................................47
4.6. IDENTIFICAÇÃO E AUTENTICAÇÃO .........................................................................................................52
4.7. GERENCIAMENTO DE SEGURANÇA ..........................................................................................................54
4.8. PRIVACIDADE .........................................................................................................................................55
4.9. AUTOPROTEÇÃO .....................................................................................................................................56
4.10. UTILIZAÇÃO DE RECURSOS ...................................................................................................................58
4.11. CONTROLE DE SESSÕES ........................................................................................................................59
4.12. CANAIS SEGUROS .................................................................................................................................60
V- ARQUITETURA DE SOFTWARE SEGURO ................................................................................62
5.1. INTRODUÇÃO ..........................................................................................................................................62
5.2. BOAS PRÁTICAS DE PROGRAMAÇÃO.......................................................................................................64
5.3. PADRÕES DE DESENVOLVIMENTO ...........................................................................................................68
5.4. TESTES DE SEGURANÇA..........................................................................................................................70
VI - GESTÃO DO DESENVOLVIMENTO DE SOFTWARE SEGURO ............................................75
6.1. INTRODUÇÃO ..........................................................................................................................................75
6.2. MÉTRICA DE SEGURANÇA ......................................................................................................................76
6.2.1. Superfície de Ataque.......................................................................................................................76
6.2.2. Outras Métricas..............................................................................................................................79
6.3. MONITORIZAÇÃO DE VULNERABILIDADES .............................................................................................80
6.3.1. Divulgação de Vulnerabilidade ......................................................................................................81
6.3.2. Resposta a incidentes......................................................................................................................82
6.4. COMPORTAMENTO SEGURO ....................................................................................................................84
VII - CONCLUSÃO .......................................................................................................................................87
7.1. INTRODUÇÃO ..........................................................................................................................................87
7.2. CONCLUSÃO E CONTRIBUIÇÃO................................................................................................................87
7.3. PERSPECTIVAS FUTURAS.........................................................................................................................88
VIII - REFERÊNCIAS...................................................................................................................................90

viii
 I - INTRODUÇÃO

1.1. Motivação

A necessidade de adequar a engenharia de software às técnicas 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 contínua dos projetos. A engenharia de software desenvolveu
métodos para a elaboração de sistemas de missão crítica, mas tardou em investigar as
razões pelas quais sistemas sem esse rótulo – os supostamente simples – tornassem-se
alvos ou meios de ataques.

A difusão da Internet facilitou a exploração remota de brechas de segurança muitas

vezes contidas em sistemas considerados inofensivos durante o desenvolvimento. A
preferência não é por acaso e nem dá-se necessariamente pelo valor dos ativos que
manipulam, mas pela conveniente desatenção despertada mesmo se operarem de forma
suspeita ou irregular. Desatenção compartilhada pelos desenvolvedores2, que tendem a não
preocuparem-se com segurança se o sistema não a listar como requisito funcional.
Sistemas insuspeitos são mais propensos a incoporar falhas de design que podem servir
para o seu comprometimento ou de outros.

O distanciamento entre desenvolvedores e profissionais de segurança é percebido

até na questão educacional. Geralmente, desenvolvedores não dominam assuntos
relacionados a segurança da informação, que é majoritariamente constituída de
profissionais oriundos das áreas de infra-estrutura e redes (networking) [TOMELLI 2004].

1
Segurança pode ser decomposta em vários aspectos distintos, porém complementares. Entre os
aspectos mais importantes estão confidencialidade, integridade e disponibilidade.
2
Programador, analista de sistemas, testador, engenheiro e arquiteto de software são termos
usados indistintamente nesse trabalho e o seu conjunto é chamado de desenvolvedor. Porém,
em alguns momentos, desenvolvedor representará programador e analista de sistemas.

7
 A engenharia de software foi eficaz na criação e aperfeiçoamento de metodologias
que permitissem o desenvolvimento de sistemas seguros – sendo segurança um atributo de
qualidade –, porém a prática demonstra que a cultura de segurança não foi assimilada
totalmente ou os processos e arquiteturas não foram aplicados à maioria dos projetos para a
geração de produtos conceitualmente seguros – ou o mais próximo disso, dado que
segurança total é considerada como inalcançável. O êxito dessas metodologias retringem-
se aos sistemas denominados críticos – aqueles que prevêem segurança como um requisito
essencial. Normas específicas para avaliar a segurança foram criadas, mas sua aplicação
também tem, aparentemente, sido restrita a sistema de missão crítica.

A capacitação da engenharia de software não se traduziu em projetos livres de

falhas conceituais. Um exemplo [DEAN 1996] que ilustra a falta de perspicácia – na falta
de termo que melhor defina – dos desenvolvedores, foi o ataque de spoofing [SPYMAN
1998] verificado em versões antigas do Netscape Navigator. Para assegurar que um applet
só se conectasse ao seu servidor de origem, implementou-se uma validação baseada na
checagem de dois endereços: o de origem do applet e o de destino da conexão. Sendo n2a
uma relação 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 interseção entre os
endereços IP, então pode se assumir que X e Y são 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 endereços como parâmetros de origem e destino.
A falha permitia que applets se conectassem a máquinas distintas das suas de origens,
passando-se o parâmetro de destino também como de origem. A correção da Netscape foi
armazenar o endereço IP (i) do servidor de origem, eliminando a primeira verificação, e
mudar a checagem de interseção para associação: i ∈ n2a(Y).

8
 Manifestações sobre a importância da readequação da engenharia de software
aumentam e a comunidade da engenharia de software começa a formular processos que
concebam sistemas naturalmente seguros.

Assim, a engenharia de software precisa precaver-se para não mais suscitar

sistemas inseguros, independente da classificação que lhe é conferida, não importando,
portanto, necessariamente o quão crítico o é, mas assegurando o quão robusto constitui-se.
Nesse sentido, abordar questões 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 repetíveis e técnicas padronizáveis, colaborar com a
elaboração de sistemas menos suscetíveis às vulnerabilidades atuais e futuras. Para isso,
são discutidas técnicas, metodologias, modelos e práticas que podem permitir a elevação
do nível de maturidade para patamares satisfatórios, congregando qualidade e segurança
como fatores essenciais e indissociáveis.

1.3. Metodologia do trabalho

Inicialmente, para a realização desse trabalho, foram identificados na literatura as

técnicas e procedimentos considerados fundamentais para o desenvolvimento de softwares
seguro. Por elas, foi possível estabelecer um conjunto mínimo de requisitos de segurança
que, se não eliminam, visam diminuir as vulnerabilidades e aprimorar a qualidade do
produto.

9
 Em seguida, foram levantadas na literatura as metodologias de qualidade mais
empregadas na engenharia de software. As metodologias englobam, mas não se restringem
a, normas e procedimentos relacionados ao processo de desenvolvimento ou avaliação de
software. Além das metodologias, pesquisou-se a profundidade na qual o tema segurança é
tratado na literatura tradicionalmente acadêmica.

Posteriormente, identificou-se na literatura quais iniciativas existiam que

envolvessem a comunidade da engenharia de software e segurança da informação. Nessa
etapa foi possível identificar iniciativas que investigavam ou implementavam aspectos de
segurança da informação e engenharia de software de forma integrada.

Finalmente, foi formulado um plano de estudo que englobasse três 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 segurança, envolvendo questões como capacitação de pessoal
e ambiental.

1.4. Estrutura do texto

O capítulo I descreve a motivação, objetivos e metodologia do trabalho, além da

organização da monografia. A revisão da literatura sobre engenharia de software com
destaque para segurança da informação é apresentada no capítulo II. As formas para
garantir segurança no processo de desenvolvimento de software e revisão da literatura
pertinente a segurança no desenvolvimento de software são discutidos no capítulo III. O
capítulo IV apresenta uma relação de requisitos funcionais de segurança a serem
considerados nos projetos. O capítulo V apresenta um conjunto de tópicos importantes para
a formulação de um projeto arquitetural de software seguro, incluindo boas práticas de
práticas de programação, padrões de desenvolvimento e testes. Algumas considerações
sobre itens importantes para a gerência e cultura organizacional são apresentadas no
capítulo VI. Em seguida, é apresentada a listagem das referências bibliográficas utilizada.
10
 II - ENGENHARIA DE SOFTWARE SEGURO

2.1. Introdução

O desenvolvimento de software não é 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 número de organizações. Desde a década de 1980, com o avanço da
microeletrônica, os softwares tornaram-se fatores de maiores preocupações na medida em
que seu custo de desenvolvimento superava o do hardware empregado [MENDES 2002].
A dependência em escala crescente deixou ainda mais patente o ambiente caótico que
envolve o desenvolvimento, levando ao fracasso um número significativo de projetos
[YOURDON 1999].

A solução encontrada para melhorar a qualidade e reduzir o custo de produção foi a

introdução da disciplina de desenvolvimento conhecida como engenharia de software. A
engenharia de software reúne metodologias, que por sua vez seguem métodos que se
utilizam de ferramentas automatizadas para englobar as principais atividades do processo
de produção de software [CARVALHO 2001]. Os benefícios das metodologias no
processo de desenvolvimento não aparentam ser motivos de discórdia, porém os métodos
instituídos é objeto freqüente de questionamento [YOURDON 1999], resultando em novas
metodologias cujo aperfeiçoamento, contribui, de alguma forma, para a evolução da
engenharia de software de forma geral.

Antes, porém, de discutir as alternativas para disciplinar o desenvolvimento de

software para que gerasse produtos com qualidade e segurança, faz-se necessário
compreender as motivações que levaram ao surgimento da engenharia de software.

11
 2.2. Crise do software

Nas décadas de 1960 e 1970, o desafio primordial era desenvolver hardware que
reduzisse o custo de processamento e de armazenamento de dados [PRESSMAN 1992]. As
décadas seguintes foram as que tiveram um avanço significativo da microeletrônica
[CARVALHO 2001], tornando o custo do hardware e armazenamento inferior ao do
software. Na década 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 primórdios o desenvolvimento de software era uma atividade
puramente artesanal. Como conseqüência, errava-se constantemente nas estimativas de
custos e tempo, os sistemas desenvolvidos continham muitos erros e, consertá-los
geralmente produziam novos. Esse é o cenário vigente desde a chamada Crise do Software
[BARROS 2002].

A crise do software tem sido agravada pela disseminação do uso de software em

todas as atividades humanas, das industriais, de serviços e até de entretenimento [CÔRTES
2001]. O advento da Internet, o avanço nas telecomunicações e a necessidade de integração
com outros sistemas revelaram novos desafios entre os quais se destaca a necessidade de
garantir a segurança nos softwares atuais e uma plataforma segura para os futuros.

As prioridades dos softwares comerciais têm mudado desde a década de 1990

[GOSLIN 1997]. Houve uma inversão de prioridades nos últimos anos [PEDRYCZ 2001],
que justifica-se a medida que os produtos eletrônicos para o consumidor final tornaram-se
prioritários para a indústria.

Software Comercial Produtos Eletrônicos

Compatibilidade Segurança
Desenvolvimento Processamento em Rede
Portabilidade Portabilidade
Confiabilidade Confiabilidade
Processamento em Rede Desempenho
Multithreading Multithreading
Segurança Compatibilidade

12
 Segurança transformou-se um fator relevante para as organizações
desenvolvedoras, justificado pelo crescente aumento no número de ataques a
vulnerabilidades presentes nos softwares por elas criados.

2.3. Engenharia de Software

O software tornou-se uma tecnologia-chave usada em várias áreas, de aplicações

financeiras e comerciais a aplicações complexas, como controle de usinas de energia e
missões espaciais. Gradualmente, transformou-se na força prevalecente em termos de
inovação tecnológica. Usar princípios 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
conferência 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 reúne metodologias, as quais são compostas por métodos que se utilizam de
ferramentas automatizadas, para viabilizar a produção, da percepção 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 funções cada vez mais sofisticadas nos software tem também
crescido de forma consistente, o que leva a um aumento na complexidade de
desenvolvimento, com conseqüente aumento do custo.

São muitos os problemas a ser tratados pela engenharia de software, pois tanto o
processo quanto o produto possuem vários atributos que devem ser considerados para que
se tenha sucesso, como a complexidade, a visibilidade, a aceitabilidade, a confiabilidade, a
13
manutenibilidade, a segurança etc. Por exemplo, para a especificação de sistemas de
controle de tráfego aéreo e ferroviário, a confiabilidade é um atributo fundamental
[FARINES 2000].

Vários princípios podem ser aplicados durante toda a fase de desenvolvimento

[GUEZZI 1991]. São princípios 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 também
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 satisfaça os requisitos preestabelecidos, que são
os paradigmas. Os paradigmas especificam atividades que devem ser executadas, assim
como a ordem de execução [CARVALHO 2001].

2.3.1. Requisitos

A engenharia de software não limita-se aos programas de computador, mas envolve

também toda a documentação necessária para instalação, uso, desenvolvimento e
manutenção do sistema. A necessidade de lidar com softwares cada vez maiores e mais
complexos, tornou a técnica de abstração um meio eficaz de reconhecer padrões, analisar e
especificar sistemas. Avaliar a qualidade de um software requer a identificação de
requisitos considerados importantes constar em um bem projetado. E a complexidade é
determinada por seus requisitos funcionais – o que ele faz – e por requisitos não-funcionais
– como ele faz [MENDES 2002].

• Requisito funcional – cada requisito que especifica uma função que deve
ser realizada. São requisitos que definem o comportamento de sistema, isto
é, o processo ou transformação que componentes de software ou hardware
efetuam sobre as entradas para gerar as saídas [THAYLER 1990].

14
 • Requisito não-funcional – descreve não o que o software fará, mas como
fará. Assim, por exemplo, temos requisitos de desempenho, requisitos da
interface externa, restrições de projeto e requisitos da qualidade. Requisitos
não-funcionais são difíceis de testar. Portanto, eles geralmente são avaliados
de maneira subjetiva [THAYLER 1990].

Os requisitos funcionais e não-funcionais possuem importância no

desenvolvimento de um sistema. Os requisitos não-funcionais têm papel relevante por
servir de critério na seleção e/ou composição de uma arquitetura de software. O termo
requisito não-funcional recebe, muitas vezes, denominações diferentes de autores. É
também chamado de atributos de qualidade [BOEHM 1978, KELLER 1990] e requisitos
não-comportamentais [DAVIS 1993]. Não considerá-los adequadamente é
reconhecidamente dispendioso e de difícil correção, pois o sistema já estará concluído para
que possa-se corrigir [BROOKS 1987].

A arquitetura escolhida para um projeto de software deve atender a um conjunto de

requisitos não-funcionais elicitados, considerados essenciais ao sistema. Algumas
propostas de classificação dos requisitos não-funcionais surgiram como é o caso do padrão
IEEE-Std 830-19933 [IEEE 1993]. Esse padrão lista um conjunto de treze requisitos não-
funcionais a serem considerados no documento de especificação de requisitos. Relaciona,
entre outros, requisitos de desempenho, confiabilidade, portabilidade e segurança,
similarmente à proposta de classificação apresentada por Boehm [BOEHM 1976].
Também existe e é discutida em Roman [ROMAN 1985] uma diversidade de requisitos
não-funcionais.

Algumas propostas de classificação de requisitos não-funcionais são

complementares. A classificação de Sommerville4, na qual é feita a distinção entre

3
Revisão da publicação de 1984 (Guide to Software Requirements Specifications). Uma nova
revisão foi publicada em 1998 (IEEE Std 830-1998).
4
A classificação apresentada em Sommerville (1996) ainda considera os requisitos de processo e
requisitos externos como sendo os requisitos não-funcionais, além 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 princípios, métodos, linguagem de
representação, normas, procedimentos e documentação, que permite ao desenvolvedor
implementar sem ambigüidade as especificações advindas das fases do ciclo de vida. A
modelagem de um sistema é uma forma econômica de estudar aspectos essenciais antes de
construí-lo. Para cobrir as fases diferentes do desenvolvimento, uma metodologia deve
valer-se de métodos e ferramentas de maneira que seja possível conduzir:

• A fase de análise de requisitos, para que a especificação 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
serão representadas as alternativas para a solução do problema, os riscos
considerados, as decisões tomadas, além da estimativa de tempo, custo e
recursos para o desenvolvimento do sistema.

2.3.3. Aspectos de Segurança em Metodologias

O desafio de se construir softwares menos suscetíveis a falhas de seguranças é um

objetivo cada vez mais perseguido pelos desenvolvedores. Aqueles que já dispõem de um
processo de desenvolvimento bem definido, não necessariamente formal, podem
amadurecer ao ponto de desenvolverem um processo no qual segurança seja considerado
um fator crítico [ALBUQUERQUE 2002]. Não significa que resultados tão bons não
16
possam ser alcançados por equipes com nível de maturidade inferior, necessitando, para
isso, que o grau de supervisão seja aumentado e seguidos os atributos de garantia de
segurança.

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
indústria de software, incorporam aspectos de segurança em seus tópicos.

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 são divididos em atividades, as quais são, 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 segurança é definida como "proteção de informações e dados de modo que

pessoas ou sistemas não autorizados não possam lê-los ou modificá-los e que pessoas ou
sistemas autorizados não tenham acesso negado a eles". A definição cobre os três aspectos
principais da segurança: integridade, confidencialidade e disponibilidade
[ALBUQUERQUE 2002].

Dos cinco processos cobertos pela norma, apenas o de operação não faz referência
à segurança. A NBR ISO/IEC 12207 orienta seus usuários a proceder com sua aplicação
criteriosamente. Nesse sentido, delegar às normas mais especializadas tarefas que lhes são
mais apropriadas é uma prática recomendada. Por exemplo, o processo de fornecimento
guia o seu planejamento a desenvolver planos de proteção e segurança (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 política de segurança 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 não negligencia a segurança. A

existência na norma das atividades de codificação e testes de software (5.3.7), que pode ser
utilizado no processo de verificação (6.4) ou de validação (6.5), evidencia sua tendência a
abordar o tema com a importância necessária. Entretanto, a justificativa sobre a
implementação de processo de verificação é submetida a fatores como o risco potencial
que um erro causaria e disponibilidade financeira, demonstrando as restrições que a
segurança enfrenta para ser integrada aos projetos não considerados críticos.

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 aquisição, requisitos, desenvolvimento, uso, avaliação,
apoio, manutenção, 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 definição de requisitos de qualidade de software,
nos processos fundamentais do ciclo de vida" além de apoiar a revisão, verificação e
validação.

O modelo de qualidade externa e interna é dividido em seis características:

funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e produtividade.
As características são subdivididas em subcaracterísticas, as quais podem ser medidas por
métricas externas e internas. A tríade integridade, confiabilidade e disponibilidade são
contempladas nas subcaracterísticas. A subcaracterística segurança de acesso – pertencente
à característica funcionalidade – é definida como a "capacidade do produto de software de
proteger informações e dados, de forma que, pessoas ou sistemas não autorizados não
18
possam lê-los nem modificá-los e que não seja negado o acesso às pessoas ou sistemas
autorizados". Embora haja a alusão dessa definição ser proveniente da NBR ISO/IEC
12207, ela "não corresponde literalmente à tradução da NBR ISO/IEC 12207, nem ao texto
original em inglês", conforme destaque na própria NBR ISO/IEC 9126. A despeito das
definições, a NBR ISO/IEC 9126 salienta que a definição se aplica também aos dados em
transmissão e que "segurança é definida como uma característica de qualidade em uso, já
que ela não está relacionada somente com o software, mas com o sistema como um todo".

A característica confiabilidade pondera que "disponibilidade é a capacidade de um

programa de software de estar pronto para executar uma função requisitada num dado
momento, sob condições especificadas de uso. Externamente, a disponiblidade pode ser
avaliada pela proporção do tempo total durante o qual o produto de software está
disponível. A disponibilidade é, portanto, a combinação de maturidade (a qual controla a
freqüência de falhas), tolerância a falhas e recuperabilidade (a qual controla o período de
tempo inativo após cada falha). Por esta razão ela não foi incluída como uma
subcaracterística distinta".

O modelo de qualidade em uso é divido em quatro características: eficácia,

produtividade, segurança e satisfação. Segurança é definida como a "capacidade do
produto de software de apresentar níveis aceitáveis de riscos de danos a pessoas, negócios,
software, propriedades ou ao ambiente, em um contexto de uso especificado". Uma nota
ressalta que "geralmente, os riscos são decorrentes das deficiências na funcionalidade
(incluindo segurança de acesso), confiabilidade, usabilidade ou manutenibilidade".

O anexo B da NBR ISO/IEC 9126 reproduz a definição de qualidade em uso da

NBR ISO/IEC 14598-1, a qual ainda não inclui a nova característica "segurança".

19
 2.4. Diferença entre Software Seguro e de Qualidade

Bruce Schneier relata que "programação de computador é simples: é ficar insistindo

no problema até que o computador faça o que deve fazer. (...) Escrever um programa
confiável é muito mais difícil, porque ele precisa trabalhar mesmo em face de erros e
descuidos fortuitos: computador de Murphy5, se preferir. (...) Escrever um programa
seguro é algo completamente diferente. Segurança envolve assegurar que as coisas
funcionam, não apenas em relação a falhas aleatórias, mas em face de um adversário
inteligente e malicioso tentando certificar-se que as coisas falhem da pior forma possível."
[SCHNEIER 2001]. Programar para segurança requer conhecimento especializado e cada
módulo com objetivo de segurança definido deveria ser revisto em par para garantir
conformidade [VIEGA 2002].

Diz-se que toda organização – não apenas as comerciais, mas as sem fins lucrativos
e também instituições governamentais – que sobreviver no século 21 terá algum
envolvimento com e-commerce. Entendendo e-commerce como negociação entre grupos e
indivíduos em sociedade. O acesso via Internet tem se tornado um requisito para que as
organizações modernas negociem com fornecedores, parceiros e clientes. Assim, toda
organização enfrenta as mesmas ameaças eletrônicas.

Desde 11 de setembro de 2001 que segurança de computador é considerada não

mais um simples problemas de segurança dos negócios, mas de segurança 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].

5
O autor emprega “computador de Murphy” numa alusão 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 SEGURANÇA

3.1. Introdução

Segundo Albuquerque et al. [ALBUQUERQUE 2002], não é possível desenvolver

uma aplicação segura em um ambiente não-seguro. Conforme a análise do ambiente da
aplicação – a especificação e o nível de garantia – podem ser necessários mais ou menos
controles. Para apoiar esse cenário, duas normas da ISO despontaram com objetivos
complementares. São 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
caráter mais abrangente, serve de base para elaboração e gerência de uma política de
segurança. A segunda é uma metodologia mais completa, no que tange ao desenvolvimento
de software, complementar, portanto, à ISO/IEC 17799 no capítulo referente ao tópico.

3.2. Ambiente seguro de desenvolvimento

A abordagem da ISO/IEC 15408 [ISO/IEC 15408] para a segurança é a da

avaliação (ou investigação) do sistema. O Commom Criteria propõe, além disso, a
avaliação com um incremento progressivo na ênfase dada ao escopo, à profundidade e ao
rigor. Conforme Albuquerque et al. [ALBUQUERQUE 2002], garantir a segurança de uma
aplicação é trabalhar com a premissa que não existe segurança absoluta para qualquer
sistema informatizado. É preciso identificar e definir as ameaças à segurança da aplicação
e à política de segurança. As ameaças podem existir nos requisitos, na plataforma
escolhida ou no ambiente de desenvolvimento.

Organizações que têm os códigos fonte de seus aplicativos como um ativo de alto
valor, necessitam principalmente de um ambiente que, não só apóie o desenvolvimento de
softwares seguros, mas que, principalmente, não insira vulnerabilidades neles. Usando uma
definição mais precisa da ISO, pode-se dizer que garantia é a base para a confiança que um
21
sistema atinge os objetivos de segurança para ele definidos. Essa garantia é mais
facilmente obtida nas vezes em que o ambiente de desenvolvimento é adequado, isto é,
emprega-se as boas práticas de desenvolvimento, a quais, apesar do rigor, não requerem
conhecimento especialista substancial, habilidades e outros recursos. Um alto nível de
garantia de segurança permite que um desenvolvedor obtenha o máximo de garantia
através da engenharia de segurança.

Meios de reforçar o ambiente de desenvolvimento são apresentados e discutidos

nos itens que se seguem.

3.2.1. Gerência de Configuração

A gerência de configuração ajuda a garantir que a integridade do sistema está

preservada através do controle das mudanças feitas no sistema. A gerência de configuração
previne contra mudanças, acréscimos e exclusões desautorizadas na documentação do
sistema. Além disso, ajuda a tornar o processo de desenvolvimento menos suscetível a
erros ou negligência humana. A gerência pode ser manual ou automatizada e o escopo que
delimitará a abrangência dos itens que serão controlados deve estar claramente
especificado.

3.2.2. Distribuição

Deve-se assegurar que a versão disponibilizada para implantação tem os atributos

de segurança especificados. As medidas, procedimentos e padrões relacionados à
distribuição, instalação e operação segura devem estar de acordo com as especificações
para não haver comprometimento do sistema na transição entre o desenvolvimento e
produção.

22
 3.2.3. Desenvolvimento

As funcionalidades de segurança devem ser representadas, nos vários níveis de

abstração, desde o projeto lógico até a implementação de seus produtos finais. As
funcionalidades de segurança devem ser mapeadas, nos vários níveis de abstrações,
estabelecendo uma correspondência entre objetos da camada de menor abstração (produto)
até os objetos de maior abstração (contidos na especificação funcional). As estruturas
internas das funções também podem ser especificadas de forma que aspectos relacionados
a modularidade, divisão em camadas e redução da complexidade fiquem melhor
representados. São níveis de abstração:

• Especificação funcional
• Projeto de alto nível
• Projeto de baixo nível
• Representação da implementação

A idéia principal é a decomposição das funcionalidades de segurança (descritas na

especificação funcional) em subsistemas, da decomposição desses em módulos, do projeto
de implementação desses módulos e da demonstração de evidências da correspondência
entre todas as camadas de decomposição.

3.2.4. Documentação

A documentação de ajuda, destinada a usuários e administradores, é um fator

importante na segurança da operação do sistema. A documentação de ajuda ao
administrador envolve os materiais escritos, não importa o meio, destinados a
configuração, manutenção e administração do sistema de forma correta e segura. A
documentação de ajuda ao usuário descreve as funcionalidades de segurança, instruções e
guias para uso seguro do sistema.

23
 3.2.5. Suporte ao Ciclo de Vida

Visa garantir que aspectos relacionados a segurança sejam tratados adequadamente

durante o ciclo de desenvolvimento e manutenção. Dessa forma, o produto final conterá as
funcionalidades de segurança especificadas. O suporte ao ciclo de vida inclui medidas de
segurança física, procedural, pessoal e outras necessárias a garantia da segurança do
sistema. O modelo de ciclo de vida a ser adotado é importante para que os requisitos
funcionais de segurança sejam atingidos. A escolha de um modelo inadequado pode
comprometer a segurança do produto final. A ISO recomenda modelos aprovados por
grupos de especialistas reconhecidos.

3.2.6. Testes de Segurança

A ISO define que testes de segurança visam garantir que o sistema atende aos
requisitos funcionais de segurança. Porém, os testes sozinhos não são suficientes para
garantir que o sistema faz somente aquilo a que ele se propõe, de maneira que
comportamentos imprevistos poderão existir. A cobertura dos testes de segurança não 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
especificações. A profundidade que os testes terão serão definidos de acordo o grau de
exigência estabelecido, isto é, um teste profundo permitirá a descoberta de códigos
maliciosos inseridos durante o desenvolvimento.

3.2.7. Avaliação de Vulnerabilidades

Avaliar vulnerabilidades abrange analisar a existência de ameaças passíves de

exploração, a possibilidade de um mau uso do sistema ou de sua configuração incorreta, a
possibilidade de falha dos mecanismos de segurança se expostos à força e a exploração de
quaisquer vulnerabilidades eventualmente introduzidas durante o desenvolvimento ou
operação do sistema. Busca-se com a avaliação de vulnerabilidades identificar ameaças
que possam afetar fatores como velocidade de processamento, configuração do sistema ou
24
da rede, capacidade de memória e outros. O uso inapropriado do sistema também é outra
preocupação que a avaliação da vulnerabilidade deve identificar. Orientações erradas ou
outros tipos de falhas na documentação de ajuda, tanto do administrador quanto usuário,
devem ser identificadas.

3.3. Norma ISO/IEC 17.799

A ISO/IEC 17799 [ISO/IEC 17799] é um conjunto de recomendações para gestão

da segurança da informação para uso por aqueles que são responsáveis pela introdução,
implementação ou manutenção da segurança em suas organizações. Tem como propósito
prover uma base comum para o desenvolvimento de normas de segurança organizacional e
das práticas efetivas de gestão da segurança, e prover confiança nos relacionamentos entre
as organizações. A ISO/IEC 17799 atua em segurança da informação considerando
tecnologia, processos e pessoas. É importante observar que essas recomendações descritas
na norma estejam de acordo com a legislação e regulamentação vigente. Nery et al.
[NERY 2005] relata que a ISO/IEC 17799 é publicada no Brasil pela ABNT com o código
NBR ISO/IEC 17799 e tem sido utilizada por organizações importantes como o Banco
Central, nas recomendações de segurança do SPB – Sistema de Pagamentos Brasileiro,
pelo ITI – Instituto de Tecnologia da Informação nas normativas do ICP Brasil, pelo CFM
– Conselho Federal de Medicina para o uso de prontuário eletrônico e diversas outras
organizações.

De acordo com Gonçalves [GONÇALVES 2003], a versão final da NBR ISO/IEC

17799, que é uma "tradução literal" da norma ISO/IEC 17799:2000, foi homologada em
setembro de 2001. E, esta versão da ISO/IEC 17799, vem sendo utilizada por vários outros
países, como é o caso de Portugal e Angola.

A ISO/IEC 17799 origina-se de um esforço do governo britânico, que em 1987,

através do UK DTI (Departamente of Trade Center) criou o CCSC (Comercial Computer
Security Centre), cujo objetivo era a criação de critérios para a avaliação da segurança e de
25
um código de segurança para os usuários das informações, de uma forma geral. No ano de
1989 foi publicada a primeira versão do código de segurança, que na época foi
denominado de PD0003 - Código de Gerenciamento de Segurança da Informação. Esse
código foi revisado, ampliado e publicado como uma norma britânica (BS), a BS7799-
1:1995 (Information technology - Code of pratic for information security management).
Em 1996, essa norma foi proposta a ISO para homologação, mas foi rejeitada. Neste
mesmo período uma segunda parte deste documento estava sendo criada, publicada
posteriormente como BS7799-2:1998 (Information Security Management Systems).

Após uma revisão, 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 homologação, sobre o mecanismo de "Fast Track". Em maio de 2000 a BSI
(British Standard Institute) homologou a primeira parte da norma BS7799. Na reunião do
comitê da ISO em Tóquio, a norma foi votada e aprovada pela maioria dos representantes.
Embora sem unanimidade, em primeiro de dezembro de 2000 houve a homologação da
"BS" como ISO/IEC 17799:2000.

A norma BS7799-2 foi submetida a um processo de revisão em 2001, no intuito de

ajustá-la com normas internacionais, tais como a ISO 9001 e a ISO 14001, e remover
aspectos próprios da lei britânica. Os controles da ISO/IEC 17799 foram adicionados a um
anexo desta versão, permitindo uma correspondência entre a numeração 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 domínios, reunidos em 36 grupos que

se totalizam em 137 controles, sendo seus domínios, a Política de Segurança, a Segurança
Organizacional, a Classificação e Controle dos Ativos de Informação, a Segurança de
Pessoas, a Segurança Física e do Ambiente, o Gerenciamento das Operações e
Comunicações, o Controle de Acesso, o Desenvolvimento e Manutenção de Sistemas, a
Gestão da Continuidade do Negócio e a Conformidade [GONÇALVES 2003].

26
 Segundo a NBR ISO/IEC 17799 [NBR ISO/IEC 17799], a segurança de um
ambiente é caracterizada pela manutenção de três fatores primordiais: a confidencialidade,
a integridade e a disponibilidade das informações críticas. Para a NBR, a informação é "um
ativo que, como qualquer outro ativo importante para os negócios, tem um valor para
organização e conseqüentemente 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 informações. Para
isso devem ser aplicados ao ambiente alguns ou todos os controles existentes na norma de
segurança. Contudo, a lista dos controles que devem ser aplicados depende de
características do próprio ambiente, como por exemplo: forma e local de armazenamento
das informações, valor das informações armazenadas, quem pode acessá-las, quais
servidores estão instalados, que tipo de serviços são disponibilizados aos usuários 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

segurança não é o mesmo que a segurança do sistema. Fornecer garantia compreende fazer
mais que a aplicação. É necessário permitir ao cliente se assegurar que o sistema é seguro.
Uma forma de garantia de segurança para o desenvolvimento de software é através de teste
comprovado pelo cliente. Nessa modalidade de garantia, o cliente tem o direito a verificar
resultados de teste e realizar testes com laboratórios independentes para comprovar se a
segurança está adequada. Esses são os princípios da ISO/IEC 15.408 [ISO/IEC 15408]:

• Especificar a segurança de forma clara e objetiva

• Construir conforme a especificação
• Testar para verificar o atendimento da especificação original

27
 O Common Criteria for Information Technology Security Evaluation (Critério
Comum para Avaliação de Segurança da Tecnologia da Informação) é o nome do padrão
que originou a norma ISO/IEC 15408 [ISO/IEC 15408], muitas vezes chamada apenas de
Common Criteria. A norma objetiva fornecer um conjunto de critérios fixos que permitem
especificar a segurança de uma aplicação de forma não ambígua a partir de características
do ambiente da aplicação e definir formas de garantir a segurança da aplicação para o
cliente final.

A história do Commom Criteria remonta ao TCSEC – Trusted Computer Security

Evaluation Criteria (Critério Confiável para Avaliação de Segurança de Computadores). O
TCSEC ficou conhecido como “Orange Book” (Livro Laranja) e foi, segundo Albuquerque
et al. [ALBUQUERQUE 2002], o primeiro padrão para avaliação de segurança
desenvolvido ainda na década de 1980. Ainda segundo Albuquerque et al.
[ALBUQUERQUE 2002], embora fosse um padrão bastante aceito, possuia alguns
problemas estruturais: fixava atributos de segurança em níveis estáticos, o que dificultava
seu uso em uma série de sistemas que precisassem de mais segurança em alguns atributos
que outros.

O Livro Laranja [DOD 1985] foi escrito para os órgãos do governo dos Estados
Unidos, porém tornou-se um padrão comercial de uso geral, pois, de um lado os
fabricantes começaram a utilizar seus critérios para classificar seus produtos, e do outro, os
compradores a dispor de um meio que permitiria uma melhor avaliação da segurança
fornecida pelos produtos.

Na década de 1990 outras tentativas de padronizar a segurança de sistemas

surgiram. Um exemplo foi o ITSEC, criado pela comissão européia em 1991, o CTCPEC
desenvolvido pelos canadenses em 1993 e o FC (Federal Criteria) elaborado pelos
americanos também em 1993. Para evitar a criação de vários padrões divergentes, instituiu-
se um comitê internacional do Common Criteria. O Common Criteria é uma norma ou
padrão de indústria criado a partir da união dos diversos padrões anteriores com o objetivo
de criar uma norma international sobre o assunto.
28
 A primeira versão do Common Criteria foi publicada em janeiro de 1996. Em maio
de 1998 foi disponibilizada uma grande revisão denominada Common Criteria 2.0. Em
dezembro de 1999, foi finalmente liberada a versão 2.1 do Common Criteria, homologada
como a norma internacional ISO/IEC 15408 [ISO/IEC 15408]. Atualmente encontra-se na
versão 2.2.

O princípio que norteia o Common Criteria é que um sistema possa ser

desenvolvido, seguindo a norma; testado em um laboratório credenciado e ser homologado
com um selo de certificação que garanta que o sistema atende aos requisitos de segurança.
O Common Criteria define que qualquer sistema, para ser considerado seguro, precisa ter
seu Security Target (ST) – objetivo ou alvo de segurança – elaborado. O Security Target é
a especificação de segurança, isto é, indica os aspectos de segurança que foram
considerados importantes e os motivos pelos quais foram para aquele sistema em
particular.

Outra figura importante é o Protection Profile (PP) – perfil de proteção –, que é um

documento semelhante ao Security Target, mas sem determinar uma aplicação específica,
podendo ser aplicado a toda uma classe de sistemas.

O Common Criteria estabelece sete níveis de garantia de segurança. A cada nível,

há um maior número de testes e, conseqüentemente, maior garantia de que o sistema
atende aos requisitos de segurança. Os níveis são denominados EAL (Evaluation
Assurance Level – Nível de Garantia de Avaliação) e variam de EAL-1 a EAL-7,
conforme o Common Criteria. Na ISO/IEC 15408 [ISO/IEC 15408], os níveis de EAL-5 a
EAL-7 são considerados extremamente rígidos e, praticamente, inviáveis. Logo, os níveis
compreendidos entre EAL-1 e EAL-4 são reconhecidos pela ISO. Assim, essa constitui-se
na diferença prática entre os dois documentos, que são idênticos nos demais pontos.

A ISO/IEC 15408 e o Common Criteria recomendam uma rede de laboratórios

credenciados a avaliar a segurança das aplicações nos níveis que cada uma das duas
29
instituições reconhece. Não há atualmente no Brasil e nem na América do Sul nenhum
laboratório credenciado. Os mais próximos estão nos Estados Unidos.

Para não causar confusão com o emprego do termo sistema, o Common Criteria
emprega o termo TOE (Target of Evaluation – Alvo da Avaliação). O TOE é, então, o
sistema que está se desenvolvendo ou avaliando. O TOE tem funções de segurança que
constituem o conjunto de rotinas responsáveis por garantir sua conformidade com a
política de segurança. Em algumas ocasiões as funções de segurança são designadas pela
sigla TSF (Target Security Functions – Funções de Segurança do Sistema Alvo). TSP é,
portanto, a política de segurança do TOE, que são as regras que definem a política de
acesso e controle dos ativos do sistema.

O Common Criteria pode ser usado para desenvolver um sistema seguro ou avaliar
a segurança de um já desenvolvido. A exigência de avaliação por laboratórios
internacionais e o grande número de detalhes na implantação, como determina o processo
estabelecido na norma, torna o processo caro.

Não existe uma NBR (norma brasileira) correspondente. Porém há iniciativas nesse
sentido, sobretudo pela importância que o tema tem e pelas preocupações vem despertando
nos últimos anos.

3.5. Ciclo de Vida de Desenvolvimento Seguro

Segurança é um requisito fundamental para a indústria de software, guiada pelas

forças do mercado, pela necessidade de proteger infra-estruturas e pela importância de
desenvolver e preservar a confiança nos sistemas. Um desafio que a indústria de software
enfrenta é criar software mais seguro que requeira menos atualização de correção e
gerenciamento de segurança menos oneroso.

30
 Para a indústria de software, a forma de satisfazer as demandas atuais de reforçar a
segurança é implementando processos repetíveis que resulte em produtos com segurança
reforçada. Assim, a indústria de software deverá fazer a transição para um processo de
desenvolvimento de software mais severo que trate adequadamente, em uma forma ampla,
a segurança. Tal processo deve reduzir o número de vulnerabilidades existentes nas fases
de projeto e codificação, além da elaboração de documentação, permitindo que se
identifique e remova tais vulnerabilidades do ciclo de vida de desenvolvimento o mais
rápido possível.

O governo americano, através do Departamento de Defesa, começou a exigir na

década de 1980 que seus projetos de tecnologia da informação passassem por um processo
de certificação de segurança (Security Certification and Accreditation – SC&A), também
chamado de Ditscap. Ditscap é formado por quatro fases: definição, verificação, validação
e certificação [ROSS 2004].

As organizações tendem a relutar em investir na incorporação da segurança ao ciclo

de vida dos projetos. No entanto, a necessidade de atendimento a regulamentações como a
Sarbanes-Oxley Act6 tem mudado essa tendência, assim como a visão que mudanças
tardias são onerosas [PAUL 2005].

Existem três fatos a serem considerados no desenvolvimento de software mais

seguro: processo repetível, educação e métrica [LIPNER 2004]. Segundo Lipner et al., é
importante que se tenha na organização um grupo responsável pelo desenvolvimento e
evolução das melhores práticas de segurança; melhorias no processo, que sirva de fonte de
conhecimento para a organização de uma forma geral e que faça a Revisão Final de
Segurança (em inglês FSR – Final Security Review) antes da liberação da release.
Enquanto muitas organizações preferem ter uma equipe central de segurança, outras optam

6
Legislação americana aprovada em 2001 – provavelmente a legislação mais abrangente que
afeta as empresa de comércio público dos Estados Unidos desde o Securities Exchange Act
de 1934 – para restaurar a confiança nos relatórios financeiros de empresas públicas. Entre
outras medidas, responsabiliza pessoalmente os funcionários pelo fornecimento de
informações financeiras precisas. Foi criada após os fiascos contábeis da Enron, WorldCom e
Global Crossing.
31
por contratar terceiros, a experiência demonstrou – na visão de Lipner et al. – que a
existência de um grupo interno de segurança é um fator vital para o sucesso na
implementação de um ciclo de vida de desenvolvimento.

A seguir, um conjunto de etapas voltadas para melhorar a segurança do software no

processo de desenvolvimento será apresentado. O objetivo do processo é reduzir a
quantidade e severidade das vulnerabilidades de segurança 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 indústria de software.
Seu fluxo é mostrado na Figura 1.

Figura 1

Embora a Figura 1 pareça um processo de desenvolvimento em cascata, na verdade

é um espiral. Requisitos (Requirements) e Projeto (Design) são revisados durante a
implementação, para responder às necessidades de mudanças que o mercado exige e às
circunstâncias que envolvem a implementação. Além disso, o processo de
desenvolvimento enfatiza a necessidade de ter código executável pronto em quase todos os
pontos de tal forma que cada marco (milestone) é de fato resultante na liberação de uma

32
série de builds que podem ser testadas e usadas operacionalmente (pela equipe de
desenvolvimento) de uma forma contínua.

3.5.2. Visão Geral

A experiência com segurança de software tem demonstrado que um conjunto de

princípios de alto nível para desenvolver software mais seguro precisam ser estabelecidos.
A Microsoft refere-se a esses princípios como SD3+C – Seguro por Design, Seguro por
Default, Seguro na Distribuição e Comunicação. Uma descrição sucinta desses princípios
seria:

• Seguro por Design: Uma arquitetura pode ser desenhada para utilizar
criptografia 3DES (triplo DES) para dados sensíveis antes de serem
armazenados no banco de dados e o uso do protocolo SSL para transportar o
dado através da Internet. Todo código é bastante verificado em busca de
vulnerabilidades comuns usando ferramentas manuais e automáticas. A
modelagem de ameaças é criada durante o processo de design do software.

• Seguro por Default: O software é empacotado com medidas de segurança e os

componentes potencialmente vulneráveis são desativados.

• Seguro na Distribuição: Atualizações de segurança são fáceis de serem

localizadas e instaladas – eventualmente são instaladas automaticamente – e
ferramentas são disponibilizadas para o levantamento e gerenciamento dos
riscos de segurança em toda a organização.

• Comunicação – os desenvolvedores precisam estar preparados para descobrir

vulnerabilidades nos produtos e comunicar aberta e responsavelmente os
usuários finais e/ou administradores para ajudá-los a tomarem as ações
preventivas necessárias.
33
 Enquanto cada elemento do SD3+C exige requisitos no processo de
desenvolvimento, os dois primeiros elementos – Seguro por Design e Seguro por Padrão –
provêem os maiores benefícios da segurança. Seguro por Design trata do processo que
pretende evitar a inclusão de vulnerabilidades em um primeiro momento, enquanto Seguro
por Default requer que a exposição por padrão do software – sua “superfície de ataque”
[HOWARD 2003a] – seja reduzida.

Empregar métricas de segurança 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 segurança "de baixo para cima" é um princípio

elementar no desenvolvimento seguro de sistema. Enquanto muitos projetos de
desenvolvimento produzem versões posteriores baseadas nas liberações precedentes, a fase
de requisitos e planejamento inicial de uma nova liberação ou versão 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 segurança, proveniente do grupo de segurança, para servir de intermediário
e assessorar nas questões pertinentes à segurança. A função do conselheiro seria de ajudar

34
a equipe de projeto revisando planos, fazendo recomendação e garantindo que o grupo de
segurança planeja os recursos necessários para oferecer suporte ao cronograma da equipe
de projeto. O conselheiro de segurança permanece como intermediário da equipe de
projeto com o grupo de segurança até a Revisão Final de Segurança e liberação do
software. O conselheiro de segurança é o elo entre a equipe de projeto e o grupo de
segurança, nos dois sentidos, pois depois de liberada a versão a equipe de segurança pode
necessitar estabelecer contato com a equipe de projeto visando evitar surpresas
relacionadas às falhas de segurança.

A fase de requisito é a oportunidade que a equipe de projeto tem para considerar

como a segurança será integrada no processo de desenvolvimento, identificar objetos
chaves de segurança e aumentar a segurança do software enquanto reduz as chances de não
cumprimento dos planos e cronograma. Faz parte dessa fase considerar as características
de segurança e assegurar que as medidas do software se integrarão com demais softwares
com os quais faça interface. A documentação é fundamental para acompanhar os objetivos
de segurança, pois a medida que o projeto prossegue as mudanças ocorrem e uma
manutenção da documentação desde o princípio ajuda a garantir que os requisitos estão
registrados para evitar surpresas de última hora.

Os requisitos característicos de segurança deveriam fazer parte dessa fase.

Enquanto alguns requisitos de segurança serão identificados posteriormente em resposta às
ameaças, os requisitos dos usuários tendem a incluir características de segurança
necessárias a eles. Requisitos de segurança também, muitas vezes, precisam se coadunar
com padrões de mercados e processos de certificações 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 segurança, os elementos principais dessa fase seriam:

• Definir a arquitetura de segurança e princípios de design: Delinear a estrutura

geral do software sob uma perspectiva de segurança, identificando, por
exemplo, os componentes a serem confiados.
• Documentar os elementos da superfície de ataque do software: Sendo a
segurança perfeita algo inatingível, é preciso restringir o uso de recursos
desnecessários e limitar o acesso aqueles críticos.
• Fazer levantamento de ameaças: A equipe de projeto faz o levantamento de
ameaças 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 critérios suplementares de liberação: Procedimentos de liberação
deveriam pertencer ao nível organizacional, mas equipes de projetos ou equipes
de manutenção podem necessitar de critérios específicos para liberação. Por
exemplo, a equipe de manutenção pode ser impedida de liberar um release
corrigindo alguma falha de segurança devido a equipe de desenvolvimento ter
identificado e corrigido uma falha antes da mesma ser reportada. Assim, a
correção da versão reportada seria desnecessária.

3.5.5. Fase de Implementação

Durante a fase de implementação a equipe de projeto codifica, testa e integra o

software. Medidas para evitar ou remover falhas de segurança nessa fase são muito
importantes, pois reduzem significativamente a probalidade que vulnerabilidades estejam
presentes na versão final.

36
 O levantamento das ameaças guiam a fase de implementação. Desenvolvedores
atentam para garantir com exatidão que o código mitiga as ameaças mais graves e os
testadores investigam se cada ameaça está realmente bloqueada ou abrandada.

Os elementos do ciclo de vida seguro que se aplicam a fase de implementação são:

• Empregar padrões de codificação e teste

• Empregar ferramentas de teste de segurança incluindo fuzzing7
• Empregar ferramentas de análise estática de código
• Revisar o código

3.5.6. Fase de Verificação

A fase de verificação é aquela em que o software está funcionalmente completo e

os beta-testers começam a testar. Durante essa fase, enquanto o software é submetido a
fase de beta teste, a equipe de projeto faz uma “investida de segurança” que inclui a
revisão do código de forma mais aprofundada e completa que as revisões realizadas na fase
anterior.

A investida de segurança feita na fase de verificação garante que a revisão e teste

do código atenham-se a versão final do software e sirva de oportunidade para a revisão do
código que foi desenvolvido/atualizado durante a fase de implementação e o código legado
que não foi modificado. O motivo é que, fazendo uma segunda investida na fase de
verificação, torna-se uma boa prática para garantir que a versão final atenda aos requisitos
e permite uma revisão mais aprofundada no código legado que foi trazido das versões
anteriores.

7
Fornece estruturas de entradas inválidas 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 Liberação

Na fase de liberação, o software deveria ser objeto de uma Revisão Final de

Segurança (RFS). O objetivo é responder a uma questão: Do ponto de vista de segurança, o
software está pronto para ser liberado? Dependendo do escopo do projeto, o software pode
ser submetido à Revisão Final de Segurança dois ou seis meses antes de completado.

A RFS é uma revisão independente conduzida pelo grupo de segurança da

organização. O conselheiro de segurança comunica ao grupo de projeto sobre o escopo do
RFS e fornece uma lista de requisitos antes da revisão. O grupo de projeto fornece os
requisitos solicitados e o RFS inicia-se com o preenchimento de um questionário pelo
grupo de projeto, seguido de uma entrevista. Cada RFS necessitará de uma revisão de bugs
que foram inicialmente considerados como bugs de segurança, mas que uma análise
posterior determinou que não teria impacto na segurança, para garantir que a análise foi
feita corretamente. Um RFS também inclui uma revisão da capacidade do software em
resistir a vulnerabilidades recém relatadas em softwares similares. Um RFS mais
aprofundado incluirá teste de penetração e, potencialmente, a contratação de terceiros para
suplementar a equipe de teste segurança.

3.5.8. Fase de Manutenção (Support and Servicing)

Apesar de todos os esforços feitos nas fases de desenvolvimento, não é possível

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 segurança do
software podem ser descobertas. Assim, as equipes do produto devem preparar-se para
responder às novas vulnerabilidades descobertas após a liberação.

38
 Parte do processo de resposta a incidentes envolve a necessidade de preparação
para avaliar relatórios de vulnerabilidades e liberar notificações e atualizações de
segurança quando apropriado. O outro componente do processo de resposta é conduzindo
um post-mortem de vulnerabilidade relatada e tomando as medidas necessárias. As ações
em resposta a uma vulnerabilidade variam de emitir uma atualização em resposta a um erro
isolado até a atualizar ferramentas de verificação de código para iniciar revisões dos
subsistemas principais. O objetivo durante a fase de resposta é aprender com os erros e
usar a informação fornecida nos relatórios de vulnerabilidades para ajudar a detectar e
eliminar vulnerabilidades adicionais, antes que sejam descobertos na prática. O processo
de resposta ajuda também a equipe do projeto e a equipe de segurança a adaptar processos
para que erros similares não sejam repetidos no futuro.

39
 IV - REQUISITOS FUNCIONAIS DE SEGURANÇA

4.1. Introdução

Os requisitos funcionais de segurança são declarações que descrevem os controles

necessários para atenuar o risco. O termo "funcional" é significativo: os controles devem
ser expressos conforme as funções desejadas, em oposição às tecnologias estabelecidas.
Soluções técnicas alternativas também são possíveis e qualquer decisão é aceitável, desde
que atenda aos requisitos funcionais de segurança. A equipe de gerenciamento de riscos de
segurança é responsável pela definição dos requisitos funcionais, o primeiro produto do
processo de análise de relação de custo/benefício. Para identificar adequadamente os
controles potenciais, deve-se definir como os controles devem se comportar a fim de
reduzir o risco aos negócios. Embora a equipe detenha a propriedade, é recomendável que
trabalhe em colaboração com o proprietário da solução de atenuação [HOWARD 2004].

É necessário definir os requisitos funcionais para cada risco discutido no processo

de suporte às decisões. O produto resultante poderia ser chamado de definições do
requisito funcional. A definição e a propriedade do requisito funcional são muito
importantes no processo de análise de relação de custo/benefício. O documento definiria o
que é necessário para reduzir o risco identificado, mas não especificaria como deveria ser
reduzido, nem definiria os controles específicos. Essa distinção concede à equipe de
gerenciamento de riscos de segurança responsabilidade na sua área de experiência, ao
mesmo tempo em que permite ao proprietário da atenuação, responsável pela
implementação da solução de atenuação, a propriedade das decisões relacionadas à
operação e ao suporte aos negócios.

Assim, poderia-se organizar um documento de especificação da segurança pelos

objetos, apontando a estratégia e os atributos utilizados. Certas vezes, os atributos estarão
presentes em mais de um objetivo de segurança. Em função disso, pode-se optar por, ao
final da lista de estratégias, 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 diferença,
porém, é 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 estratégia de segurança usada. Ele
prefere agrupar as estratégias de forma global e, se for oportuno, acrescentar a tabela de
relacionamento ao final.

Algumas estratégias de segurança aparecem de forma muito comum, como

verdadeiros padrões (patterns) de segurança da aplicação. Cada caso deve ser avaliado
particularmente, mas alguns requisitos são descritos a seguir para, pelo menos, orientar a
especificação da segurança do sistema.

4.2. Auditoria

Auditoria em software consiste, fundamentalmente, na gravação, armazenamento e

análise de informações relevantes que determinem quais ações relevantes à segurança
ocorreram e quem as perpetrou [CC 1999]. Aparentemente simples, rotinas de auditoria
devem considerar uma série de fatores que elevam sua complexidade. É preciso, por
exemplo, determinar quais ações 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 aplicações [ALBUQUERQUE 2002].

Um dos aspectos importantes a ser considerado pela auditoria em software é o que

se refere ao espaço ocupado e volume de ações registradas. É preciso definir quais ações
são relevantes para serem gravadas – registrar pouco pode ser não-elucidativo para
desvendar um problema e registrar muito pode comprometer o sistema e/ou gerar trilhas
em volume superior à capacidade de análise. A gravação das trilhas deve considerar a
41
finitude do espaço nas mídias adotadas, assim como o tratamento a ser dado aos dados
quando o espaço se exaurir. É necessário que se saiba se os dados mais antigos serão
apagados a medida que os novos são inseridos (permitindo que um atacante gere ações
lícitas repetidamente após 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 intervenção do administrador para liberar espaço é atitude mais apropriada
(ganhando antipatia dos usuários e tornando-se vulnerável a ataques de negação de serviço
- 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 são

altamente comprometidos com a privacidade de seus usuários. A auditoria pode violar a
privacidade. Nesses casos será necessário escolher entre privilegiar a auditoria ou a
privacidade.

A ISO/IEC 15408 indica à geração de dados para auditoria o registro de cada um

dos seguintes eventos:

• Inicialização e finalização das funções de auditoria

• Todos os eventos auditáveis para o nível [seleção: mínimo, básico,
detalhado ou não especificado]
• [designação: outros eventos de auditoria]

Para cada evento auditado deve-se registrar ao menos as seguintes informações:

• Data e hora do evento, tipo de evento, identidade do sujeito (usuário

ou sistema) e resultado final (sucesso ou falha)
• Para cada tipo de evento, baseado na definição do evento na
especificação de segurança, incluir [designação: outras informações
necessárias]

42
 Os eventos auditáveis podem, com o passar do tempo, deixar de ser relevante para
registro e outros podem tornar-se. O Common Criteria sugere que permita-se mudanças
nos eventos auditáveis e que o sistema registre na trilha de auditoria, no nível mínimo,
todas as alterações na configuração da auditoria, com base nos seguintes critérios:

• Identidade do objeto e usuário

• Hora do dia

A análise de trilha de auditoria manualmente é tediosa e apresenta altas chances de

erro. Na maioria das vezes, os eventos não representam grandes problemas de segurança
[ALBUQUERQUE 2002]. O verdadeiro potencial da auditoria não é aproveitado até que
os dados sejam transformados em informações úteis [HONEYNET 2002].

Um mecanismo automático de detecção de problemas é desejável para muitos

casos. Alarmes e respostas automáticas à tentativa de invasão permitem que, detectada uma
situação suspeita, o sistema envie um e-mail, apresente uma mensagem no console do
administrador, registre na tabela de suspeita de invasão, envie mensagem via pager ao
administrador ou encerre o sistema.

4.3. Comunicação - Repúdio

Albuquerque et al. [ALBUQUERQUE 2002] diz que "o repúdio é uma forma de
ataque. O agente do ataque executa uma função no sistema e posteriormente nega tê-la
efetuado; por exemplo, alguém faz uma compra em uma loja eletrônica e, no momento de
pagar, alega que não a fez". O Common Criteria, preocupada em garantir a identificação
das partes envolvidas em uma troca de dados, emprega duas famílias de classes para
garantir a identificação do emissor da informação (prova de origem) e assegurar a
identificação do destinatário (prova de recebimento). Para evitar o não-repúdio é
necessário autenticar as partes envolvidas e garantir a integridade da mensagem, para que o
conteúdo não seja alterado.
43
 As assinaturas eletrônicas são eficazes para garantir o não-repúdio de origem.
Entretanto, insuficiente para garantir o de recebimento. É preciso algum tipo de protocolo
em que o destinatário ou uma terceira parte confiável envie ao emitente, ou armazene em
base confiável, uma mensagem comprobatória do recebimento. A mensagem de resposta
(prova do recebimento) deve ser também assinada eletronicamente.

Uma terceira parte confiável arbitrando as trocas de mensagens é importante

também para evitar que a prova de recebimento chegue ao emissor da mensagem original.
Nesse caso, o emissor (A) enviaria uma mensagem, o destinatário (D) acusaria seu
recebimento enviando outra em resposta, porém essa prova de recebimento não chega a A.
Poderia-se configurar aqui a visão de A que o negócio não foi fechado e D, sim. Uma
terceira parte confiável permitiria a ambas as partes consultar um árbitro para saber se o
protocolo foi concluído com sucesso. Outra alternativa para esse caso seria o emissor
repetir a mensagem, notificando se tratar de uma cópia, a intervalos regulares até a
confirmação de recebimento.

4.4. Criptografia

Soares et al. [SOARES 1995] comenta que "a criptografia surgiu da necessidade de
se enviar informações sensíveis através de meios de comunicação não confiáveis, ou seja,
em meios onde não é possível garantir que um intruso não irá interceptar o fluxo de dados
para leitura (intruso passivo) ou para modificá-lo (intruso ativo). A forma de contornar esse
problema é utilizar um método que modifique o texto original da mensagem a ser
transmitida (texto normal), gerando texto criptografado na origem, através de um processo
de codificação definido por um método de criptografia. O texto (ou a mensagem)
criptografado é então transmitido e, no destino, o processo inverso ocorre, isto é, o método
de criptografia é aplicado agora para decodificar o texto criptografado transformando-o no
texto normal original".

44
 "Existem basicamente dois tipos de criptografia: a simétrica e a assimétrica"
[ALBUQUERQUE 2002]. Júlio César empregava um método de criptografia que consistia
em substituir as letras de uma mensagem pela terceira letra após sua posição no alfabeto
(sendo a sucessor de z) [TANENBAUM 1989]. Esse é um exemplo de criptografia
simétrica ou baseada em chave secreta, pois a mesma chave será usada para cifrar e
decifrar a mensagem. O problema clássico dessa solução é a dificuldade de entregar a
chave de forma segura a quem vai decifrar a mensagem [RUFINO 2002]. Existem diversos
algoritmos conhecidos de criptografia simétrica, 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 assimétricas é baseado na idéia que o momento de maior

vulnerabilidade da chave é quando ela está em trânsito [RUFINO 2002, DISNEI 2002].
Em 1976, Diffie e Hellman [DIFFIE 1976] propuseram um método que revolucionou os
sistemas de criptografia. Baseado na utilização de chaves distintas: uma para codificação
(E) e outra para decodificação (D), tal que a derivação de D a partir de E fosse, em termos
práticos, senão impossível, pelo menos muito difícil de ser realizada. Portanto, o que uma
cifrasse somente a outra poderia revelar. Dessa maneira, uma poderia ser tornada pública 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
assimétrica ou de chave pública de uso prático, os mais comuns são o RSA e as Curvas
Elípticas. O RSA, cujo nome deriva das inicias dos autores Rivest, Shamir e Adleman
[RIVEST 1978], baseia-se na dificuldade de fatorar números muito grandes. Acreditava-se
em 1977 que uma mensagem criptografada pelo RSA-129 levaria milhões de anos para ser
quebrada [GARDNER 1977]. Foi quebrada em 1994 usando computação distribuída
[LEUTWYLER 1994, LIMA 2002].

"Os métodos de criptografia assimétricos apresentam dois inconvenientes: o

tamanho das chaves e a lentidão dos procedimentos de codificação e decodificação"
[SOARES 1995]. Os algoritmos simétricos exigem canal separado para distribuição de
chaves, tornam o gerenciamento das chaves complexo e permitem repúdio [DISNEI 2002].
45
 "A garantia da confidencialidade na criptografia deve ser baseada na segurança da
chave (...), o ideal é usar algoritmo público conhecido. O segredo tem que estar na chave,
não no algoritmo. Os algoritmos públicos mais conhecidos são desenvolvidos para evitar
criptoanálise e decifração do texto. Algoritmos feitos em casa são, geralmente, bastantes
suscetíveis a criptoanálise" [ALBUQUERQUE 2002]. Criptoanálise é uma especialidade
que busca identificar a chave ou o texto original. É preciso atentar que alguns algoritmos
são protegidos por copyright em alguns países do mundo. A troca de chaves em intervalo
de tempo regular também ajuda a aumentar a segurança.

Lima [LIMA 2002] conclui que a "a criptografia de chave pública não é uma
panacéia. Nenhum sistema criptográfico além da 'chave-de-uma-só-vez' é
incondicionalmente seguro, e é preciso que não nos iludamos com argumentos falaciosos
que 'comprovam matematicamente' a segurança dos sistemas assimétricos. Talvez seja o
caso de fazermos com sistemas assimétricos o que se tem feito com sistemas simétricos,
seguindo a sugestão de Shannon [SHANNON 1948] - combinar vários passos de
substituição e de transposição".

O Common Criteria recomenda a especificação do uso de criptografia e define dois

atributos: operação de criptografia e gerenciamento de chaves criptográficas. As operações
que envolvem criptografia devem ser realizadas em conformidade com algoritmo
específico e chave de tamanho determinado.

O gerenciamento de chaves criptográficas envolve a geração, distribuição, acesso e

destruição delas. A trilha de auditoria pode conter atributos e informações sobre as chaves,
mas não pode registrar informações sensíveis que violem a confidencialidade das mesmas.

Albuquerque et al. [ALBUQUERQUE 2002] exemplifica uma definição para

especificação da geração de chaves de criptografia: "As funções de segurança da aplicação
devem gerar chaves de criptografia conforme o algoritmo de geração de chaves

46
assimétricas RSA, com base em semente gerada pela função time(), conforme descrito a
seguir, com tamanho da chave de 1024, que atendam aos seguintes padrões: PKCS#12.

• Primos gerados randomicamente com semente pela função time.

• Chaves privadas geradas e armazenadas localmente no
microcomputador do cliente.
• Chaves públicas enviadas para o servidor através de um canal
controlado, com criptografia.
• Assinatura de chave pública realizada através de smart-card, com
emissão de certificado."

4.5. Proteção de dados do usuário

O Common Criteria contém requisitos que especificam funções de segurança e

políticas para proteger dados dos usuários. Os requisitos são divididos em quatro grupos:

a) Políticas de funções de segurança para proteção dos dados do usuário:

- Política de controle de acesso;
- Política de controle de fluxo de informações.

b) Formas de proteção dos dados do usuário:

- Funções de controle de acesso;
- Funções de controle de fluxo de informações;
- Transferências internas;
- Proteção de informação residual;
- Retorno (Rollback);
- Integridade de dados armazenados.

c) Armazenamento off-line, importação e exportação:

- Autenticação de dados;
47
 - Exportação de dados para fora do controle do sistema;
- Importação de dados de fora do controle do sistema.

d) Comunicação interna:
- Proteção de confidencialidade de dados do usuário;
- Integridade na transferência de dados.

Albuquerque et al. [ALBUQUERQUE 2002] comenta que proteção de dados do

usuário é basicamente controle de acesso. "A função de controle de acesso do sistema é
utilizada para definir se o usuário tem direito a acessar ou alterar determinada informação e
para garantir que apenas o usuário com esse direito pode ter acesso a essa informação". É
preciso também resguardar os dados de acessos externos, do sistema operacional ou outras
aplicações, e garantir a privacidade dos que saem.

O controle de acesso deve considerar que diferentes usuários têm direitos de acesso
distintos. Usuários podem ler, alterar, remover ou criar informações. A dificuldade
existente é prevenir que usuários não burlem o controle de acesso, acessar diretamente a
informação sem passar pelo sistema, e ao mesmo tempo os meios preventivos não
degradem a velocidade do sistema. A maneira mais fácil de evitar o acesso aos dados por
outros meios é aproximando proteção e informação. 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 informação.

Entre os diversos tipos de controle de acesso, os mais comuns são por níveis
universais, por proprietário e grupo proprietário; e discriminado (discritionary). O
universal classifica as informações com níveis, por exemplo, secreta, confidencial, restrita
e pública. Os usuários são também classificados em função dos níveis que terão acesso. O
usuário terá acesso a seu nível e os inferiores a este. O controle de acesso por proprietário e
grupo proprietário é comum em sistemas UNIX. Nele, o dono da informação, o grupo a
que pertence e os demais usuários podem ter privilégios distintos entre si. No controle de

48
acesso discriminado cada usuário ou grupo tem direito de acesso específico a uma
informação.

Outra consideração fundamental é se o sistema será de autorização, negação ou

misto. O sistema de controle por autorização requer que cada usuário tenha seu acesso
autorizado, pois, por padrão, não tem direito a nenhum acesso e informação. "No modelo
de negação ocorre o inverso: o usuário tem total direito a todos os objetos. Alguns, porém,
indicam alguns usuários, negando-lhes explicitamente determinada operação"
[ALBUQUERQUE 2002]. O sistema misto funciona de modo que todos tenham um
privilégio padrão e usuários específicos tenham mais ou menos direitos. Por exemplo, é
possível definir um direito padrão de leitura a todos os usuários, porém certos usuários
poderão também alterar enquanto outros têm o acesso à leitura vetado.

O sistema misto requer que regras de solução de conflitos sejam fixadas. Por
exemplo, se um usuário 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 usuário
deverá ser definido por algum critério. A tendência é que primeiro se considera as
permissões e depois as negações. No exemplo apresentado, o usuário 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; não é um grupo fixo de pessoas. Isso
é uma característica geralmente necessária em sistemas de controle de acesso e que gera
mais custo para implementação” [ALBUQUERQUE 2002].

Ainda que o aplicativo, o sistema operacional e o firewall tenham a política de

acesso obedecida, outros fluxos ilícitos precisam ser controlados. Entre eles, há o acesso
por "Cavalo de Tróia", micros ligados a modem, roubo de HD e as redes sem fio. De todas
as alternativas, difíceis de serem levantadas e implementadas na totalidade, "a maneira

49
mais segura de se evitar acessos ilícitos é através do uso de criptografia das informações"
[ALBUQUERQUE 2002].

Para manter a confidencialidade de dados externos ao sistema, a criptografia para

ser bem sucedida deverá contar com medidas eficazes de proteção das chaves. Chaves
desprotegidas anulam a segurança dos melhores sistemas criptográficos.

A exportação ou importação de dados precisa respeitar as regras estabelecidas na

política de controle de acesso e fluxo de informações. Embora óbvio, um usuário não
autorizado a criar determinada informação, não deve ter oportunidade de criá-la também
por importação ou exportação. Os cuidados com exportação de dados envolvem questões
como backup, garantir que as cópias sejam geradas e restauradas com segurança, mantendo
a confidencialidade e a integridade. As comunicações entre sistemas também devem ter os
níveis necessários de segurança à proteção das informações. A política de segurança deve
tratar das questões pertinentes a relatórios (saída de dado sem segurança), alertando os
usuários das suas responsabilidades sobre a confidencialidade dos dados, que não será mais
tarefa do sistema.

"Na norma ISO/IEC 15408, importação, exportação, autenticidade e proteção da

confidencialidade e da integridade são atributos separados. Isso faz sentido já que,
teoricamente, é possível usar um desses atributos e não o outro. Porém (...) geralmente ou
usamos apenas os atributos de importação e exportação, sem atributo de segurança, ou
usamos o pacote completo, com todos os atributos especificados. Pode haver situações
particulares, mas não são muito comuns" [ALBUQUERQUE 2002].

As transferências internas – aplicações em locais físicos diferentes como em um

ambiente cliente-servidor – necessitam, muitas vezes, de controles especiais que envolvem
a criptografia ou a autenticação dos dados em virtude da possibilidade de interceptação da
informação. Uma solução seria, por exemplo, usar uma VPN (Virtual Private Network) ou
um protocolo de comunicação segura, como o SSL (Socket Secure Layer).

50
 As informações residuais, aquelas que permanecem armazenadas mesmo depois de
excluídas, precisam ser tratadas de forma adequada para que pessoas não autorizadas não
possam recuperá-las. A solução mais simples é escrever zeros sobre os dados apagados. Se
a a informação 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 análise
magnética da superfície não permita detectar a informação. Outros cuidados envolvem as
camadas, especialmente as fornecidas por terceiros, que manipulam as informações. Um
banco de dados lê dados do disco rígido e envia para o driver do banco de dados acessado
pelo servidor de aplicações, que, por sua vez, retorna para a função de leitura e envia à
camada de apresentação, por exemplo, um navegador. O cache da rede ou navegador pode
manter informações depois de manipulá-las.

A garantia de integridade dos dados armazenados requer medidas preventivas

quanto a problemas de hardware e atomicidade de transações. Pouco pode-se fazer quanto
a problemas como interferência magnética no desenvolvimento de software, mas pode-se
remediar a deficiência com alertas após 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 transações é um problema que
envolve o sistema desenvolvido. Albuquerque define transação como o conjunto de
operações realizadas na base de dados do sistema que só faz sentido quando realizadas
todas as operações em conjunto. O exemplo clássico é o de transferência entre contas, a
operação só tem importância se tanto o crédito quanto o débito tenham sido feitos com
segurança. Se apenas um deles for feito, a operação deve ser desfeita. Geralmente a
atomicidade de transações fica sob a responsabilidade do sistema de banco de dados, nas
ocasiões que são empregados.

51
 4.6. Identificação e Autenticação

Segundo Albuquerque et al. [ALBUQUERQUE 2002], autenticação é garantir que

o usuário é de fato quem ele diz ser. Existem três maneiras de se garantir que um usuário é
quem ele diz ser:

• Perguntar algo que só ele saberia responder corretamente

• Solicitar algo que só ele teria
• Identificá-lo por características pessoais

Identificação difere de autenticação, porém complementam-se. Identificação, ainda

segundo Albuquerque et al., é saber quem está operando o sistema. Autenticação trata de
garantir que o usuário é quem ele diz ser. Pode-se identificar um usuário sem autenticá-lo,
mas a autenticação pressupõe sempre uma identificação. Sempre que houver controle de
acesso, uma forma de autenticação será necessária.

A importância de se solicitar nome e senha é justamente para identificar e

autenticar o usuário. 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 inútil, pois se o administrador do sistema
tivesse como saber a senha, não haveria mais como responsabilizar este alguém.

Os algoritmos de hash recomendados por Albuquerque et al. são MD5 e SHA-1. A

escolha foi baseada nas descrições de Schneier [SCHNEIER 1995]. Algoritmos de hash
deveriam possuir duas propriedades: funcionar em sentido único (one way), que significa
não permitir recriar a mensagem original do hash final; e serem livres de colisões, que
significa encontrar duas mensagens que gerem o mesmo hash final. Quebrar um algoritmo
hash significa que uma ou ambas as propriedades não são verdadeiras. Ron Rivest criou
em 1992 o MD5, que é um aperfeiçoamento 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 lançou um novo algoritmo chamado SHA-1. Muitas aplicações
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, além de Antoine Joux,
anunciaram resultados criptográficos impressionantes contra o MD5 e SHA. Colisões
foram demonstradas em SHA e Schneier declara, sem incutir pânico ou alarme, que "é
hora de todos migrarem do SHA-1". Entre as alternativas cita o SHA-224, SHA-256, SHA-
384 e SHA-512 [SCHNEIER 2004]. Em 2005 Schneier publica pela primeira vez,
confirmando suas suspeitas, que o SHA-1 foi quebrado, "não uma versão reduzida e nem
uma simplificada. O algoritmo completo mesmo". Três estudantes chineses Xiaoyun
Wang, Yiqun Lisa Yin e Hongbo Yu, a maioria da Universidade Shandong8 na China,
mostraram que o SHA-1 não é livre de colisão. "Eles desenvolveram um algoritmo para
procurar colisões mais rápido que por força bruta" [SCHNEIER 2005].

Além da forma de autenticação, seja por senha, cartão, biometria ou qualquer outra
forma, aspectos como momento da autenticação, impossibilidade de fraude do sistema,
múltiplos mecanismos de autenticação e reautenticação devem ser considerados. As
mensagens de erro de autenticação não deveriam dar pistas ao agente de um eventual
ataque. Por exemplo, se o sistema exibir mensagens de erro distintas para usuário e senha
errada, o agente pode descobrir mais facilmente quais usuários são válidos no sistema.

O emprego de flag para bloqueio de conta, estipulação de prazo de validade em

contas e necessidade de troca de senha ou de certificado, são atributos que contribuem para
aumentar a segurança do processo de autenticação. Informações para autenticação
comumente usadas pelos sistemas:

• Identificação do usuário
• Dados para autenticação
• Prazo de validade dos dados para autenticação
• Prazo a partir do qual deve-se alertar o usuário para renovar seus
dados de autenticação

8
Um resumo do artigo, a versão completa não está disponível ainda, pode ser encontrado em
http://theory.csail.mit.edu/~yiqun/shanote.pdf
53
 • Indicador de conta bloqueada (flag)
• Data e hora para liberação do bloqueio

As senhas, quando empregadas, deveriam atender a critérios que determinem o

número mínimo de caracteres e se são compostos por letras, números, sinais e se as letras
são sensíveis ao caso (case sensitive).

É possível que o sistema que autenticou o usuário faça acesso a outros sistemas
para realizar ações definidas por esse usuário. Se houver controle de acesso nesses outros
sistemas, o acesso deveria ter privilégio compatível com os do usuário autenticado no
sistema autenticador. Uma solução é ligar o usuário à instância do sistema a ser acessado
por meio de uma nova autenticação, gerando um token assinado eletronicamente pelo
autenticador, que seria uma entidade aceita por todos os sistemas. A autenticação nesse
caso seria feita em um único local e uma única vez, processo conhecido como single sign
on.

4.7. Gerenciamento de segurança

O Common Criteria define uma classe para gerenciamento de segurança que

envolve atributos, informações e funções de segurança. Segundo Albuquerque et al.
[ALBUQUERQUE 2002], todo gerenciamento de segurança passa por pontos importantes
como:

• Definição e gerência de papéis de segurança, que significa

determinar quem possui acesso a determinadas funções ou
informações de segurança.
• Capacidade de revogação e expiração de atributos de segurança, que
é a capacidade do sistema revogar um direito imediatamente ou
estabelecer um prazo para tal.

54
 Depois desses pontos, outros três tipos de funções compõem o gerenciamento:

• Gerenciamento das funções de segurança, que descreve o acesso e

os atributos das funções de segurança.
• Gerenciamento dos atributos de segurança, que descreve o acesso
aos atributos de segurança de outros objetos do sistema, como quem
define o proprietário de um arquivo.
• Gerenciamento de dados de segurança, o qual, ao contrário dos
atributos, não se liga a um objeto particular.

4.8. Privacidade

Albuquerque et al. [ALBUQUERQUE 2002] explica que "privacidade é a

capacidade de um usuário realizar ações em um sistema sem que seja identificado. É
completamente diferente de confidencialidade, que define que apenas usuários autorizados
podem ter acesso à determinada informação". Um exemplo de sistema que emprega
privacidade como atributo essencial é o usado pelo processo eleitoral brasileiro, no qual
não pode haver forma de ligação entre o eleitor e seu voto.

As formas de privacidades destacadas pelo Common Criteria são:

• Anonimato - garante que um usuário possa usar um recurso ou

serviço sem ter sua identidade revelada.
• Pseudônimo - garante que um usuário possa usar um recurso ou
serviço sem ter sua identidade revelada, porém suas ações são
rastreadas e reveladas, geralmente, em situações especiais. Portanto,
permite a responsabilização e privacidade ao mesmo tempo. Se
usado com não-rastreamento, para cada ato deve ser usado um
pseudônimo diferente.

55
 • Não-rastreamento - garante que um usuário possa fazer uso de vários
recursos e serviços sem que outros possam ligá-lo a esses usos.
• Invisibilidade - garante que um usuário possa usar um recurso ou
serviço sem que outros, principalmente terceiros, possam saber que
o recurso ou serviços está sendo usado.

Muito usado na web, um cookie representa um risco maior ao não-rastreamento do

que o anonimato do usuário. Por si só, cookies não podem identificar usuários, mas um site
pode saber se é uma segunda vez que o usuário o acessa, assim como as páginas que
navegou.

4.9. Autoproteção

É importante notar que há uma distinção entre atributos, funções e informações do

sistema, para seu funcionamento específico, e atributos, funções e informações de
segurança do sistema. O primeiro grupo foca na proteção dos dados do usuário, enquanto o
segundo na proteção dos dados da segurança do sistema.

Existem três pontos que podem ser destacados nas funções de segurança 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.
• Implementação das funções de segurança, que opera sob a camada
subjacente e implementa os mecanismos que protegem o sistema.
• Dados e atributos de segurança, que são o banco de dados
administrativo que orientam a proteção do sistema.

56
 A implementação de um dos itens acima sem os demais representa um alto risco e
pode comprometer a segurança como um todo. É importante cuidar dos três aspectos.

O Common Criteria define um grupo de famílias importantes para proteção da

segurança:

• Teste de camada subjacente

• Falha Segura
• Disponibilidade de dados exportados pelo sistema
• Confidencialidade dos dados exportados pelo sistema
• Integridade dos dados exportados pelo sistema
• Transferência interna de dados
• Proteção física do sistema
• Recuperação segura
• Detecção de repetição
• Monitor de referência
• Separação de domínios
• Protocolo de sincronização de estado
• Registros de tempo (time stamp)
• Consistência de dados entre funções de segurança
• Consistência de dados replicados
• Autoteste

Sistemas que não implementam proteção nas funções de segurança comprometem a

segurança dos dados do usuário, pois controles de proteção tornam-se vulneráveis e, dessa
forma, comprometem a segurança como um todo.

Albuquerque et al. [ALBUQUERQUE 2002] considera essencial a existência dos

seguintes mecanismos:

57
 • Controle de acesso a dados de segurança – a integridade,
disponibilidade e confidencialidade devem ser controladas e
garantidas pelo sistema.
• Autoteste – todo sistema de segurança precisa ter sua integridade
verificada no início de execução.
• Proteção física – o hardware sob o qual o sistema opera, precisa ter
um nível mínimo de segurança para evitar comprometimento do
sistema.
• Teste da camada subjacente – deve-se verificar se a plataforma ou o
sistema operacional é seguro e não foi comprometido.
• Falha segura – erros no próprio sistema ou na camada subjacentes
devem ter seus efeitos atenuados pelo sistema.

Os dados de segurança devem ser protegidos de forma análoga aos dados do

usuário. Isto é, as medidas (controle de acesso, integridade, disponibilidade, informação
residual e outros) que protegem os dados do usuário devem também proteger os dados de
segurança.

4.10. Utilização de recursos

O Common Criteria define três atributos que tratam da disponibilidade dos

recursos, como capacidade de processamento e/ou de armazenamento. Os atributos são
tolerância a falhas, prioridade de serviços e alocação de recursos. Sistemas que envolvem
segurança precisam de uma política de utilização de recursos que garanta espaço e
prioridade para suas rotinas de segurança. Muitos sistemas operacionais fornecem tais
características, facilitando a implementação dos controles de recursos simples e permitindo
a delegação através de uma premissa de uso ou de ambiente.

O atributo tolerância a falhas trata das falhas com degradação e limitada.

Tolerância a falhas com degradação indica que o sistema é capaz de manter-se em
funcionamento de algumas de suas partes no caso de certas falhas. Tolerância a falhas
58
limitada define que o sistema mantém em funcionamento todas as suas partes no caso de
determinadas falhas. O sistema pode ter conjuntos de falhas em grupos diferentes.

A prioridade de serviços é dividida em dois níveis: priorização de recursos

limitada, que define que o sistema garante uma priorização ao acesso a recursos, para um
subconjunto destes; e priorização total de recursos, que define que todos os recursos são
priorizados pelo sistema.

A alocação de recursos estabelece limites no uso dos recursos disponíveis. Cotas

máximas podem ser estabelecidas para que um processo não monopolize os recursos do
sistema. O uso de cotas mínimas e máximas, além de evitar o monopólio, evita que algum
processo fique sem nenhum recurso.

4.11. Controle de Sessões

O controle de sessões envolve desde questões como notificar o usuário sobre quais
foram seus últimos acessos, geralmente informando quando e de qual local, até o
cancelamento automático de sessões quando um mesmo usuário estiver simultaneamente
conectado em equipamentos distintos. As notificações a respeito dos últimos acessos
podem englobar informações dos acessos não só bem-sucedidos como também dos
malsucedidos, para que o usuário saiba se houve tentativa de acesso através de sua
identificação. As sessões também podem ser restringidas a determinados horários e dias,
como o horário comercial. Se uma sessão ficar parada – sem uso – durante muito tempo,
regras como o seu cancelamento automático podem ser estabelecidas [WHEELER 2003].

O acesso ao sistema envolve uma série de aspectos que podem ser usados para
ajudar na estratégia de segurança:

• Limitação 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 usuário pode ser impedido de executar o
sistema.
• Limitação 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 usuário pode ser limitado a algumas funções
do sistema.
• Limitação do número de acessos – restringir o número máximo de
sessões de um usuário. É importante considerar que um usuário pode
querer acessar, por exemplo, simultaneamente do seu desktop e
notebook. Pode ocorrer também da sessão ficar congelada devido a
alguma falha no processo de encerramento.
• Mensagem de acesso – solicitar que o usuário 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
operação.
• Histórico de acesso – informar ao usuário quando foi o último
acesso com sucesso e eventuais falhas na autenticação ou no
estabelecimento da sessão.
• Travamento de sessão – meios de o usuário bloquear o console sem
encerrar a sessão.

Após um travamento, intencional ou não, a forma de se voltar a ter acesso à sessão

deve ser por meio de reautenticação do usuário identificado na sessão.

4.12. Canais seguros

Albuquerque et al. [ALBUQUERQUE 2002] define que “um canal seguro ou

confiável é uma camada de comunicação entre o usuário e o sistema ou entre o sistema e
outros sistemas e que oferece uma série de características:

60
 • Os dados de segurança são isolados dos dados do usuário
• Os canais devem ser iniciados de forma específica, seja pelo
sistema, seja pelo usuário
• O canal provê não-repúdio de origem e recebimento, garantindo para
cada uma das partes que a outra é quem afirma ser”

Canal e caminho confiável distinguem-se na medida em que canais confiáveis

focam a comunicação entre sistemas, geralmente criados através da distribuição de chaves
públicas e privadas para os sistemas e usuários envolvidos. O caminho confiável, por sua
vez, foca na comunicação entre o usuário e o sistema, buscando garantir que o usuário está
efetivamente acessando o sistema desejado, por exemplo, para fazer autenticação.

Canais seguros são especialmente recomendados quando existe a necessidade de

garantir não-repúdio para um grande número de ações.

61
 V - ARQUITETURA DE SOFTWARE SEGURO

5.1. Introdução

Mendes [MENDES 2002] descreve arquitetura de software como o estudo da

organização 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 década de 1980 o tema não despertava interesse de
pesquisadores e profissionais, quando Mary Shaw [SHAW 1989] destacou a necessidade
de considerar o nível organizacional ou arquitetural dos sistemas. Na década de 1990 foi
publicado o precursor livro sobre arquitetura de software de Mary Shaw e David Garlan
[SHAW 1996] que abordou diversas questões 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 discussões 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, princípios e diretrizes guiando o projeto e
evolução ao longo do tempo".

Existem muitas definições para arquitetura de software [LARMAN 2002] e em

vários casos autores tratam de estender a definição de forma a aumentar sua completitude,
muito em função de tratar-se de uma disciplina recente [HOHMANN 2002, BASS 1998,
LARMAN 2002], embora convirjam na definição que arquitetura de software tem relação
com sistemas grandes [HOHMANN 2002]. Algumas definições tornam-se
demasiadamente complexas para uma simples compreensão. Booch [BOOCH 1999], por
exemplo, define que uma “arquitetura é o conjunto de decisões significativas sobre a
organização de um sistema de software, a seleção dos elementos estruturais e suas
interfaces pelas quais o sistema é composto, junto com o comportamento especificado na
colaboração entre outros elementos, a composição dessas estruturas e os elementos

62
comportamentais nos subsistemas progressivamente maiores e o estilo arquitetural que
guia essa organização – esses elementos e suas interfaces, colaborações e composições”.

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 nível arquitetural compreende questões estruturais, dentre as

quais pode-se destacar:

• Seleção de alternativas de projeto;

• Escalabilidade e desempenho;
• Organização e estrutura geral de controle;
• Protocolos de comunicação, sincronização;
• Atribuição 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 relações existentes entre
sistemas e desenvolver novos sistemas com base em variações de sistemas antigos.
Entender as arquiteturas de software existentes permite aos engenheiros de software
decidir sobre alternativas de projeto. Uma descrição arquitetural do sistema é importante
para analisar e descrever propriedades de um sistema complexo. Conhecer notações
formais para descrição de paradigmas arquiteturais permite que engenheiros possam
apresentar novos projetos de sistema para outros usuários.

A arquitetura de software busca analisar as propriedades do software no nível de

subsistema ou módulo. Examinando o papel da arquitetura em um contexto mais amplo do
gerenciamento de processo de software e da tentativa de ordenar as diversas técnicas que

63
têm surgido. Mendes [MENDES 2002] aponta alguns possíveis benefícios em que a
arquitetura pode:

• Atuar como uma estrutura a fim de atender aos requisitos de

sistema;
• Ser usada como aspecto técnico para o projeto de sistema bem como
suporte na estimativa de custo e na gerência do processo;
• Servir de base para a análise da consistência e da dependência;
• Prover suporte ao reuso.

5.2. Boas Práticas de Programação

Alguns cuidados precisam ser levados em consideração para garantir a segurança

de um sistema. As boas práticas de programação, mesmo sem se considerar a segurança em
si, garantem um código mais robusto, confiável e, conseqüentemente, seguro
[ALBUQUERQUE 2002]. Código seguro não significa necessariamente segurança em
código ou código que implemente alguma função para segurança, mas código que é escrito
para suportar os atacantes maliciosos. O código seguro é também código robusto
[HOWARD 2002].

Albuquerque et al. [ALBUQUERQUE 2002] considera que o código seguro muita

vezes implica em certa perda de desempenho. Entretanto, ressalva que a perda de
performance pode ser compensada por um hardware mais rápido, o contrário, porém, não é
verdadeiro. A perda de performance pode ser compreendida por sugestões como as de
Viega et al. [VIEGA 2003]: “assuma que toda entrada de dados é culpada até que se prove
o contrário” ou “quanto mais você compreende o dado, mais facilmente você o filtrará”.
Torres [TORRES 2003] também é cauteloso ao tratar as entradas de dados, especialmente
em uma arquitetura cliente-servidor e, sobretudo, nas solicitações provenientes de
ambientes inseguros – ou pouco controlado – como é o caso da Internet.

64
 A necessidade de escrever códigos capazes de resistir a perspicácia de atacantes é
sobremaneira importante devido a pouca importância que o tema desperta mesmo em
organizações que supunham-se fortemente interessadas. Howard [HOWARD 2002] alerta
que o verdadeiro problema de muitas empresas desenvolvedoras de software é que
segurança não é vista como uma função geradora de receita no processo de
desenvolvimento. Por isso, ainda segundo Howard, a gerência não quer gastar dinheiro
treinando desenvolvedores para escrever códigos seguros, mas gasta com tecnológias de
segurança, porém geralmente após sofre algum tipo de ataque.

O professor e autor Ross Anderson, da Universidade de Cambridge, pesquisa, entre

outros assuntos, a respeito das implicações econômicas na segurança da informação
(economics of information security). Os estudos investigam, por exemplo, as motivações
econômicas que levam a que “muitos sistemas falhem não por razão técnica, mas por
incentivo desarmônico – geralmente quem pode protege-los não são as pessoas que sofrem
os custos da falha” [ANDERSON 2001].

Algumas recomendações importantes são listadas, mas não se limitam a estas,

sobre meios de se melhorar a qualidade do código. Conforme fora dito, as recomendações,
embora importantes para reforçar a robustez do código escrito, não devem ser encaradas
como definitivas. Outros cuidados devem ser necessários dependendo da aplicação,
arquitetura e plataforma sob a qual opera.

• Criar funções intrinsecamente seguras – Todas as funções devem verificar os

dados de entrada para impedir perda de controle do sistema, falhas gerais de
proteção ou outros tipos de falhas [ALBUQUERQUE 2002, HOWARD 2002,
VIEGAS 2003, TORRES 2003]. A maior preocupação é evitar o estouro de
buffer (buffer overflow).
• Usar funções intrinsecamente seguras – Uma função intrinsecamente
insegura é a strcpy (em C e C++ copia uma string). A função recebe dois
ponteiros como parâmetros e copia todo o conteúdo, de uma para o outro, até
encontrar 0. Se chamada com parâmetro inválido, pode gerar resultados
65
 imprevisíveis. Uma alternativa melhor seria a função strncpy, que permite
limitar o tamanho máximo a ser copiado. Linguagens tipadas, como Visual
Basic e Delphi, por exemplo; são menos suscetíveis a esses problemas, mas não
imunes. Algumas funções da API (Application Program Interface) do sistema
operacional não são intrinsecamente seguras [ALBUQUERQUE 2002].
• Testar o retorno de funções – Sempre que se chamar uma função, seu retorno
precisa ser verificado [ALBUQUERQUE 2002]. Se uma parte do dado for
possivelmente suspeita, melhor seria apostar em uma perspectiva de segurança
e a assumir que usar esse dado traria conseqüências 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 ) {

/* Usuário e/ou senha inválidos */
Return 0;
}
Return 1;

Embora aparentemente inofensiva, se a função LogonUser retornar um resultado

inesperado, por exemplo em conseqüência de uma falha na conexão com o servidor, e
retornar um outro erro. O mais seguro seria:

If ( LogonUser( Usuario, Senha ) == SUCESSO ) {

/* Usuário e/ou senha inválidos */
Return 1;
}
/* Usuário e/ou senha inválidos */
Return 0;

• Documentar funções corretamente – A correta documentação da função evita

mal-entendidos a respeito da interpretação da mesma.

66
 • Tratar as entradas de dados – Todo dado informado, seja pelo usuário ou
outro sistema, deve ser tratado adequadamente, mesmo que se acredite que
todas as funções são intrinsecamente seguras. Um cuidado a se ter é com
relação a caracteres especiais. Identificar caracter malicioso permite,
principalmente, evitar que perpetre-se ataques como, por exemplo, SQL
Injection [TORRES 2003]. Esse ataque explora características da linguagem
SQL que permite o uso de caracteres com funções especiais, como comentário.
Um exemplo seria:

_sql = “SELECT * FROM Login WHERE Login=’” + txtLogin.Value + “’”

Se for feita a atribuição: txtLogin = “ ‘ OR 0=0 # “

O comando final será:
SELECT * FROM Login WHERE Login=’ ‘ OR 0=0 #

Como o código após # é considerado como comentário e a condição 0=0

será sempre verdadeira, o comando geraria um retorno com todos os dados
de todos os logins.
2. Ter uma política de versão consistente – Uma política de versão consistente, não
importa se por uma gerência de configuração ou simplesmente backup, facilita a
identificação de problemas e, assim, a melhoria contínua do produto.
3. Usar componentes e bibliotecas confiáveis – Toda segurança e cuidado incluído
no código pode ser comprometida com o uso de bibliotecas ou sistemas auxiliares
não-confiáveis. Deve-se assegurar que bibliotecas não comprometem a segurança
do sistema.
4. Evitar informações sensíveis em arquivos temporários – Pelo caráter de ser
temporário, provavelmente o arquivo não foi objeto de cuidados pertinentes à
segurança. Assim, deve-se evitar que informações sigilosas tornem-se vulneráveis
restringindo seu uso em arquivos dessa natureza.
5. Não armazenar senhas e chaves criptográficas no código – Senhas e chaves
criptográficas em códigos podem ser reveladas através de engenharia reversa. O

67
 armazenamento de chaves criptográficas deve ser alvo de análise criteriosa, assim
como os algoritmos empregados.
6. Operar com o privilégio necessário – As aplicações deveriam rodar com o
privelégio requerido para desempenhar suas tarefas. Qualquer falha séria, como
estouro de buffer, comprometeriam menos se a aplicação operasse com poucos
privilégios [HOWARD 2002].

5.3. Padrões de desenvolvimento

Uma das considerações preliminares sobre padrões é que embora possa parecer que
se resolva problemas completamente diferentes a todo momento, a maioria dos problemas
que enfrentamos são gerados pelas ferramentas que usamos e não pelo problema externo
que temos [CHRISTOPHER 1970]. Por isso, não se pode esperar encontrar problemas
comuns com soluções comuns, mesmo com a enorme diversidade de contextos externos de
solução de problemas.

Empregar objetos para organizar a computação é um dos melhores exemplos de

soluções para resolver problemas comuns. O grande sucesso dos padrões de
desenvolvimento é a prova, por meio dos que programam a objeto [GAMMA 1995]. Os
padrões de desenvolvimento, entretanto, não limitam-se à fase de design. A fase de
manutenção também o empregará com uma abordagem um pouco diferente. Pode-se
destacar, em especial, técnicas como a refatoração1 (refactoring) como forma de aplicar os
padrões de desenvolvimento numa fase posterior à de criação [BECK 2002].

Os padrões de desenvolvimento visam melhorar a estrutura interna de um

programa, garantir maior legibilidade do código, padronização da codificação, facilidade

9
Refatoração (Refactoring) é o processo de alteração de um sistema de software de modo que
seu comportamento externo não mude.

68
na manutenção, maior produtividade, rapidez no desenvolvimento, reduzir a quantidade de
código e facilitar a detecção de erros.

Fowler [FOWLER 2004] apresenta uma série de situações em que os padrões de

desenvolvimentos poderiam ajudar a melhorar a qualidade do código:

• Código Duplicado
• Método Longo
• Classes Grandes
• Lista de Parâmetros Longa
• Alteração Divergente
• Cirurgia com Rifle
• Inveja dos Dados
• Grupos de Dados
• Obsessão Primitiva
• Comandos Switch / Case
• Hierarquias Paralelas de Herança
• Classe Ociosa
• Generalidade Especulativa
• Campo Temporário
• Cadeia de Mensagens
• Intermediário
• Intimidade Inadequada
• Classes Alternativas com Interfaces diferentes
• Biblioteca de classe incompleta
• Classe de Dados
• Herança Recusada
• Comentários

69
 Os padrões de desenvolvimento, como fora comentado anteriormente, não se
restringem a etapa de criação (codificação inicial). Os padrões servem também à etapa de
manutenção e testes. Por exemplo, sempre que houver adição de novas funcionalidades que
altere trechos de código, revisão de código e correção de bugs os padrões poderão ser
aplicados.

5.4. Testes de Segurança

Stott et al. [STOTT 2004] argumenta que a maioria dos processos parte do
princípio que o design pode ser feito no início e o software criado ao longo do
desenvolvimento. Um padrão similar a de linha de produção, que prioriza a uniformidade e
simplifica as variações. A dificuldade em projetar o sistema todo no início 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 código 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, aperfeiçoando-o progressivamente. Ainda conforme
Beck, a boa engenharia é responsável 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 códigos com menos defeitos e mais limpo que a média
normal.

Antes de se pensar em testes, algumas perguntas básicas devem ser feitas [BECK
2002]:

• O que se deseja com o teste?

• Quando testar?
70
 • Como definimos qual lógica testar?
• Como definimos qual dado testar?

O teste é uma peça central na filosofia XP (Extreme Programing) [ASTELS 2002].

Nela, o teste ocorre em diversos níveis. O primeiro nível inclui os testes de unidade, escrito
pelos desenvolvedores. Os testes de unidade são escritos antes do código 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 versão 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 metáfora
do semáforo de trânsito para ilustra o fluxo no desenvolvimento orientado a testes:

• Luz amarela – escreva e compile o teste. Ele não compilará.

• Luz vermelha – escreva o código requerido para compilar, compile e
execute o teste. Ele falhará.
• Luz verda – escreva o código para passar no teste. Execute o teste.
Ele passará.

Antes da década de 1990, a atividade de teste era geralmente realizada no fim do

ciclo de desenvolvimento, normalmente pelos próprios analistas de sistemas. A intenção
era avaliar se o sistema funcionava e queria-se encontrar erros. Não haviam ainda técnicas
e nem metodologias estruturadas de teste. Em 1979, Glenford Myers [MYERS 1979]
publicou um livro que destacava que testar era procurar defeitos e não provar que o
software estava funcionando. David Gelperin e Bill Hetzel [GELPERIN 1988]
descreveram um processo de evolução 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
alcançados 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 criação de um processo independente de teste demandou algumas
necessidades de metodologias, métricas e de melhorias, que já existiam no processo
original, mas que precisavam ser adaptadas para o novo [RIOS 2002].

O modelo de processos para condução e realização de testes em todas as etapas do

desenvolvimento de sistema visa garantir padrões e qualidade no produto final. O principal
objetivo é reduzir erros no processo de desenvolvimento, atuando das atividades iniciais
(requisitos) até a homologação do produto. Os testes dividem-se basicamente em:

Testes de Verificação
Processo de avaliação de documentos e informações coletadas em cada fase do
processo de desenvolvimento do software.
• Verificação de Requisitos: Garantir a qualidade das informações geradas
durante o processo de levantamento, análise e especificação de requisitos.
• Verificação da Modelagem Funcional: Avaliar se todos os requisitos
identificados foram incorporados na modelagem funcional.
• Verificação da Modelagem Interna: Avaliar se os diagramas da modelagem
interna traduzem todos os aspectos da modelagem funcional, assim como,
analisar a estrutura dos dados.
• Verificação de Código: Garantir que os códigos fonte obedecem as normas
e padrões determinados pela organização.

Testes de Validação
Processo de avaliação de um sistema ou seus componentes, visando garantir a
qualidade do produto final.
• Validação de Unidade: Garantir que as diversas unidades do software estão
contempladas na totalidade de linhas de código.
• Validação de Integração: Garantir que os diversos componentes do software
não apresentem erros quando integrados.
72
 • Validação de Funcionalidade: Garantir que não existam diferenças entre os
requisitos funcionais e o comportamento do software.
• Validação de Sistemas: Detectar erros de natureza não funcional,
certificando-se que o comportamento está de acordo com os requisitos
especificados. Seu propósito é testar os requisitos tecnológicos, entre eles:
o Carga e Stress – determinar o limite máximo de carga e stress que o
software poderá suportar;
o Configuração – identificar e testar as configurações de software e
hardware;
o Segurança – identificar formas de quebra de segurança do software;
o Desempenho (performance) – determinar se o desempenho em
situações normais e de pico estão em conformidade aos requisitos de
desempenho especificados;
o Confiabilidade e disponibilidade – determinar as medidas de
confiabilidade e disponibilidade do software;
o Recuperação – avaliar o comportamento do software após a
ocorrência de um erro ou outras condições anormais;
• Validação de Usabilidade: Garantir que os requisitos de usabilidade (acesso,
navegação, clareza de informações e terminologia adequada) estejam sendo
cumpridos e conforme às especificações.
• Validação de Aceite: Permitir ao cliente executar testes, validando as
categorias de testes aplicadas anteriormente (funcionalidade, usabilidade e
sistemas), reduzindo os riscos na implantação em produção.

Os métodos de testes são basicamente os seguintes:

• Método Caixa-Branca – Técnica utilizada para determinar defeitos nas

estruturas internas dos programas.
• Método Caixa-Preta – Técnica utilizada para garantir que os requisitos de
negócios estão plenamente satisfeitos.

73
 Alguns modelos de avaliação da maturidade do processo de testes foram criados
nos últimos anos. Alguns, como o TPI (Test Process Improvement), são mais usados na
Europa e outros como, o TMM (Teste Maturity Model) e TCMM (Test Capability Maturity
Model), são mais populares nos Estados Unidos. Existem esforços no sentido de integrar
os modelos de maturidade de teste, como o TMM, com os modelos de maturidade da
capacitação para software como o CMMI [RIOS 2002].

74
 VI - GESTÃO DO DESENVOLVIMENTO DE SOFTWARE
SEGURO

6.1. Introdução

Implantar um processo de qualidade é um passo significativo para se desenvolver

software seguro, embora um não seja pré-requisito e nem o outro conseqüência
[ALBUQUERQUE 2002]. Uma vez atingida a maturidade necessária para tornar o
processo uma prática cotidiana, passa-se a enfrentar os desafios provenientes da nova
forma de trabalhar: adotar práticas que permitam controlar e melhorar o processo
continuamente.

Não se pode controlar o que não se pode medir [DEMARCO 1989]. O que é
medido é conseguido [KAPLAN 2004]. Segundo DeMarco [DEMARCO 1989], a métrica
é um número que vincula a uma idéia. Mais precisamente, é uma indicação dimensível de
algum aspecto quantitativo do sistema. As métricas recomendadas para um software
comum são: escopo, tamanho, custo, risco e tempo empregado. Segurança, como seria de
se esperar, talvez pela novidade do tema, não é citada. Ainda que fosse, as dúvidas sobre as
técnicas usadas e as novas propostas são relativamente obscuras em engenharia de
software.

Outra questão a ser acompanhada continuamente é a ocorrência de incidentes e

divulgação de vulnerabilidades. É preciso estar preparado tanto para identificar um
incidente, quanto para difundir as correções e alertar aos interessados. Segurança é um
tema que não se esgota nas boas práticas. É preciso acompanhar seu desenvolvimento e
educar-se para evitar a criação de vulnerabilidades, sem que se incorra na criação de novas.

Alguns dos tópicos comentados a seguir são procedentes da área de redes

(networking) e a inclusão visa, senão integrá-los aos assuntos pertinentes a
desenvolvimento – estreitando o relacionamento dos que sofrem os efeitos de softwares

75
vulneráveis com os que projetam –, permitir que a engenharia de software possa aprender
com a experiência de outras áreas.

6.2. Métrica de Segurança

Dois tipos de métricas são usadas atualmente para determinar a segurança de um

sistema: em nível de código, contando-se o número de bugs encontrados ou consertados de
uma versão para outra, e em nível de sistema, contando-se o número 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 nível de código,

através da contagem e análise de bugs [CHOU 2001, GRAY 1990, LEE 1993, SULLIVAN
1991], não tinham objetivos claros de estabelecer correspondência entre a contagem de bug
com vulnerabilidade de sistemas. Em nível de sistema, Browne et al. [BROWNE 2001]
definiu um modelo analítico que assemelha-se às classificações nas quais incidentes são
reportados para o CERT. Posteriomente, Beattie et al. [BEATTIE 2002] elaborou um
modelo matemático sobre o tempo da aplicação de patches de correções para o
funcionamento contínuo condizente, baseado na coleta de registros do CVE [MITRE].
Segundo Howard et al. [HOWARD 2003a], ambos os estudos empíricos focaram-se nas
vulnerabilidades com respeito as suas descobertas, exploração e forma de remediar ao
longo do tempo ao invés de simplesmente coletar pontos de vulnerabilidades em um
sistema.

6.2.1. Superfície de Ataque

Uma nova métrica foi proposta baseada na idéia de superfície de ataque,

considerando que as métricas prevalecentes, apesar de úteis, eram insatisfatórias
[MANADHATA 2004]. A superfície de ataque constitui-se das ações do sistema
76
externamente visíveis aos usuários junto com os recursos do sistema acessado ou
modificado por cada ação. Quanto mais ações estiverem disponíveis a um usuário ou
quanto mais recursos forem acessíveis por essas ações, mais exposta será a superfície de
ataque. E, quanto mais exposta estiver, mais suscetível o sistema estará a ataques com
chances de sucesso, portanto mais inseguro será. A nova métrica visa reduzir a superfície
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 têm mais tendência de serem oportunidades de ataque que outros. Por exemplo,
serviços executados com privilégio de root estão mais sujeitos de virarem alvos de ataques
que serviços operando sem altos privilégios. Arquivos com controle total (rwxrwxrwx no
Unix) são mais prováveis de serem atacados que arquivos com privilégios mais restritos. A
nova métrica proposta considera que nem todos os recursos do sistema devem ser tratados
de forma igual. A identificação dos recursos do sistema que são 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 são
mais vulneráveis a ataques que outros.

Com um conjunto de classes de ataque e duas versões de um sistema, é possível

medir qual é o mais relativamente seguro submetendo-os a uma comparação em relação às
classes de ataque. As comparações podem ser feitas de formas diferentes. Um exemplo
seria, para cada versão, deve-se contar o número de instâncias de cada classe de ataque
(número de serviços rodando como root e a quantidade de sockets abertos) e comparar os
números entre cada uma das respectivas versões. Pode-se refinar as contagens
determinando pesos maiores para certas classes em relação a outras. Os pesos
representariam a probabilidade de ataque.

O método dessa nova métrica é 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 superfície de ataque
como métrica de segurança 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 versões do mesmo sistema operacional [HOWARD
2003a]. Inspirados pelo Quociente da Superfície Relativa de Ataque (RASQ, em inglês) de
Howard [HOWARD 2003b], Pratyusa Manadhata e Jeannette M. Wing empregaram a
métrica na medição das classes de segurança do sistema operacional Linux e comparam
com as classes do Windows [MANADHATA 2004].

Howard et al. [HOWARD 2004] ressalta que o princípio da redução da superfície

de ataque é a “redução do uso do código a zero”. A redução seria alcança, por exemplo,
pelo emprego da regra como a 80/20, a qual pode ser definida como "se oitenta por cento
dos usuários não usam, desligue o recurso, mas permita que possa-se religá-lo". Destaca
ainda que combinar a qualidade do código à redução da superfície de ataque pode levar a
produção de software mais seguro, o que é inatingível apenas com código perfeito.

Um processo simples para ajudar a reduzir a superfície de ataque e,

conseqüentemente, melhorar a segurança do sistema seria:

• Reduzir a quantidade de código em execução – aplicando a regra 80/20 a

todas as áreas funcionais, se oitenta por cento dos usuários não a usarem,
deve-se considerar a possibilidade de desligá-la.
• Reduzir o acesso a pontos de entrada para usuários não confiáveis –
restringir o acesso a quem não deveriam, em essência, usar determinado
recurso e fortalecer os princípios de autenticação.
• Reduzir o privilégio para limitar o potencial de dano – reduzir os privilégios
sob os quais o código deve ser executado.
• Caminhos de código anônimo – analisar o diagrama de fluxo de dados
(DFD) ou diagrama de interação da UML (Unified Modeling Language) e

78
 identificar os pontos de entrada do sistema. A análise permitirá identificar
se há a necessidade de aumentar o nível de autorização nesses pontos.
• Cuidado com protocolos – aplicar a regra 80/20 a todos os protocolos.
• Reduzir a superfície de ataque preventivamente – descrever na fase de
projeto como será a superfície de ataque, preferencialmente registrando em
um documento. Alguns itens a serem considerados são: protocolos de rede,
pontos (endpoints) que devem suportar autenticação ou autorização (atenção
redobrada nos endpoints anônimos), desligar recursos por default,
componentes reutilizáveis usados, identidades de processos de todos os
códigos executados e contas de usuários instaladas. Dessa forma, os
desenvolvedores conhecerão desde o início como será a superfície de
ataque.
• Medir a superfície de ataque – determine a superfície de ataque mínima no
início e meça-a ao longo do desenvolvimento.
• Grande superfície de ataque resulta em grande trabalho de segurança – se
uma grande superfície de ataque for inevitável, o código deveria ser de boa
qualidade, conservador e defensivo.

6.2.2. Outras Métricas

Muito tem-se feito na área de modelagem quantitativa da segurança de sistemas.

Brocklehurst et al. [BROCKLEHURST 1994, LITTLEWOOD 1993] mede a segurança
operacional de um sistema estimando o esforço despendido por um atacante para descobrir
uma brecha de segurança e o benefício associado a ela. Alves-Foss et al. [ALVES-FOSS
1995] usa o Índice de Vulnerabilidade do Sistema (System Vulnerability Index) – obtido
pela avaliação de fatores como as características do sistema, atos potencialmente
negligentes e atos potencialmente malevolentes – como uma medida de vulnerabilidade de
sistema. Voas et al. [VOAS 1996] propôs o tempo-mínimo-para-intrusão (MTTI, em
inglês), métrica baseada no tempo predito antes que qualquer intrusão simulada ocorra.
MTTI é uma métrica relativa que permite aos usuários comparar versões diferentes de um
79
mesmo sistema. Ortalo et al. [ORTALO 1999] modela o sistema como um privilégio
gráfico [DACIER 1994] exibindo suas vulnerabilidades e estimando o esforço consumido
pelo atacante para perpetrar um ataque bem-sucedido, explorando tais vulnerabilidades. O
esforço estimado é a medida da segurança operacional do sistema. Esses trabalhos focam
nas vulnerabilidades de um sistema como uma medida de sua segurança, similar à idéia de
atacabilidade de vários recursos de um sistema como uma medida de sua segurança,
discutida no item anterior.

6.3. Monitorização de Vulnerabilidades

O comportamento anormal de um sistema deve ser examinado para que, ao final de

uma análise, possa ser ou não considerado um incidente de segurança [RUFINO 2002]. A
RFC (Request For Comments) 2142 [RFC 2142], no item "Network Operations Mailbox
Names", sugere que sejam criados endereços de e-mail "abuse" e "security",
respectivamente, para notificações de uso inadequado dos recursos de rede (SPAM, por
exemplo) e problemas de segurança em geral. A engenharia de software pode valer-se
dessas práticas para aculturação de suas rotinas de monitoramento de incidentes.

Um incidente de segurança é definido como um evento relevante no qual a política

de segurança de um sistema é desobedecida ou de alguma forma violada [RFC 2828]. A
RFC 3227 [RFC 3227] sugere um guia de princípio para coleta de evidências. É, na
verdade, um guia para coleta e arquivamento de evidências.

São exemplos de incidentes de segurança:

• Tentativas de ganhar acesso não autorizado a sistemas ou dados;

• Ataques de negação de serviço;
• Uso ou acesso não autorizado a um sistema;
• Modificações em um sistema, sem o conhecimento, instruções ou
consentimento prévio do dono do sistema;
80
 • Desrespeito à política de segurança ou à política de uso aceitável de uma
empresa.

6.3.1. Divulgação de Vulnerabilidade

Segundo Howard [HOWARD 2004], todo código tem uma probabilidade diferente
de zero de conter uma ou mais vulnerabilidades. Algumas delas resultarão em
comprometimento do usuário. Logo, não se deve perder o controle dos usuários, pois são
eles que precisarão aplicar todas as atualizações de segurança. Se houver uma falha no
código, o usuário precisará corrigir as máquinas que usam o recurso defeituoso.

Contar com um modelo de documento que descreva em riqueza de detalhes a

vulnerabilidade divulgada, é uma prática recomendada e de interesse mútuo para usuários e
fornecedores. As grandes organizações têm aperfeiçoado seus boletins de divulgação e
conscientizado seus usuários a lê-los – geralmente através do envio de mensagem
eletrônica a usuários previamente cadastrados –, além de muitas criarem seus próprios
produtos para automatizar o processo de atualização.

Os boletins deveriam ser numerados e titulados de maneira que seu conteúdo seja
facilmente compreendido. Datar e controlar versão a versão são itens importantes, pois é
possível que o conserto de uma vulnerabilidade possa levar a criação de outra ou atrapalhar
o funcionamento de algum recurso diferente do objeto de reparo [HOWARD 2003a].

É importante que também exista um resumo que indique quem deve ler o
documento, o impacto da vulnerabilidade, a classificação máxima de gravidade, a
recomendação aos usuários, se é substituição da alguma atualização de segurança,
advertências, lista de softwares afetados, lista softwares não afetados (de acordo com a
política de suporte a versões da organização).

81
 A parte central do boletim de divulgação deveria conter uma sinopse, perguntas
freqüentes relacionadas à atualização, detalhes da vulnerabilidade e informações adicionais
sobre a atualização divulgada.

6.3.2. Resposta a incidentes

Um Grupo de Resposta a Incidentes de Segurança, ou Computer Security Incident

Response Team (CSIRT), é um grupo – algumas vezes uma organização – responsável por
receber, analisar e responder a notificações e atividades relacionadas a incidentes de
segurança em computadores. Um CSIRT normalmente presta serviços para uma
comunidade bem definida, que pode ser a entidade que o mantém, como uma empresa, um
órgão governamental ou uma organização acadêmica. Um CSIRT também pode prestar
serviços para uma comunidade maior, como um país, 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 função. Um grupo ad hoc é reunido
quando há um incidente de segurança em andamento ou para responder a um quando
necessário.

Um CSIRT mostra-se necessário quando um incidente de segurança ocorre, pois

torna-se crítico para a organização ter uma maneira eficaz de respondê-lo. A rapidez com
que a organização pode reconhecer, analisar e responder a um incidente limitará os danos e
diminuirá o custo de recuperação. A idéia do CSIRT é estar perto e apto a conduzir uma
resposta rápida para conter o incidente de segurança e para recuperar-se dele. CSIRTs
também podem estar familiarizados com os sistemas comprometidos e, portanto, melhor
preparados para coordenar a recuperação e propor estratégias de erradicação e resposta aos
problemas.

82
 De acordo com Pricola [PRICOLA 2005], O primeiro grupo de resposta a
incidentes de segurança foi criado em 1988, após 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 segurança da agência americana
NSA (National Security Agency), foi responsável por uma das paradas de maior impacto
na Internet até então, atingindo mais de nove mil computadores da rede.

O relacionamento entre diversos CSIRTs e organizações de segurança pode facilitar

o compartilhamento de estratégias de resposta e a geração de alertas para problemas
potenciais. Os CSIRTs podem trabalhar em conjunto com outras áreas da organização de
maneira pró-ativa, garantindo que novos sistemas sejam desenvolvidos e colocados em
produção tendo preocupação com a segurança e em conformidade com as políticas de
segurança. Eles podem ajudar a identificar áreas vulneráveis da organização e, em alguns
casos, realizar análise de vulnerabilidades e detecção de incidentes.

Podem tambem focar sua atenção em prover treinamentos sobre a necessidade da

preocupação com segurança. Os CSIRTs também podem usar sua experiência para auxiliar
na redução de futuras ameaças [RFC 2350].

Vários acrônimos são usados para definir os grupos de resposta a incidentes

existentes no mundo. Alguns dos acrônimos 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 segurança é tão forte quanto for o sistema mais fraco [SCHNEIER 2000].
Geralmente o elo mais fraco envolve interação do sistema com humanos. Se o problema é
com a escolha de boas senhas, interfaces difíceis de serem usadas, rotinas de instalação
complicadas, procedimentos para gerenciamento de patches confusos ou ataque de
engenharia social, o elo humano estará sempre presente [WING 2003a].

A engenharia social é uma técnica que não requer “prática nem tão pouco
habilidade”, basta ter poder de convencimento e um pouco de psicologia comportamental.
Quando bem executada é bastante eficiente e normalmente não deixa rastros que permitam
a identificação do autor [RUFINO 2002].

É preciso desenvolver interfaces que façam a segurança ser menos inoportuna e

intrusiva [SASSE 2001, WHITTEN 1999]. Conforme os dispositivos de computação
tornam-se ubíquos, é necessário esconder a segurança dos usuários, porém permitindo-lhes
controle nas partes apropriadas.

Também é necessário um comportamento científico para auxiliar cientistas da

computação [WING 2003a]. Tecnólogos deveriam desenvolver sistemas menos suscetíveis
a ataques de engenharia social. À medida que o número e a natureza dos atacantes mudam
com o passar do tempo, é preciso entender a psicologia do atacante: de script kiddies1 a
adversários com recursos e motivados politicamente. À proporção que a biometria
converte-se em um lugar comum, é indispensável entender se e como ela poderia ajudar ou
atrapalhar a segurança (talvez com a criação de novas formas de ataque de engenharia
social ou ajudar ou atrapalhar a privacidade) [PALLEN 2003].

Os problemas comportamentais acontecem em todos os níveis do sistema: no topo estão

os usuários que não dominam computação, mas interagem com eles por diversão ou

10
Iniciantes que não criam suas próprias ferramentas de exploração, mas usam scripts de
terceiros para os ataques. [HONEYNET 2002]
84
trabalho; no meio estão os usuários com conhecimento de computação que não têm, ou não
deveriam ter, tempo ou interesse para lidar com as configurações; no nível mais baixo
estão os administradores que tem a tarefa de instalar sempre as mais recentes correções de
segurança sem poderem adivinhar as conseqüências decorrentes dessa instalação. “É
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 ameaças sejam

reconhecidas por aqueles que lidam com segurança. As ameaças poderiam ser divididas em
dois grandes grupos: internas e externas. As ameaças internas são ocasionadas geralmente
por pessoas com intenções duvidosas (testar as vulnerabilidades com ou sem más
intenções), pessoas realizando atividades não intencionais (descarregar um vírus ou outro
programa nocivo inadvertidamente) e administradores que administram equivocadamente o
ambiente (não usar senhas seguras ou configura inadequadamente os recursos). As
ameaças externas são praticadas por agentes de fora da organização, através de atividades
não necessariamente intencionais, como: concorrência, inimigos, espiões, funcionários
hostis, etc. [WENSTROM 2002]

A educação é um fator crítico para o sucesso de um ciclo de vida de

desenvolvimento seguro [LIPNER 2004]. Segundo Lipner, muitas escolas e universidades
não preparam seus alunos adequadamente para que sejam incorporados à força de trabalho
em atividades que envolvam o projeto, desenvolvimento ou teste de software seguro.
Mesmo quem fez cursos de segurança muito provavelmente estudou algoritmos de
criptografia e modelos de controle de acesso, mas não abordou adequadamente questões
como buffer overflow. Em geral, desenvolvedores, arquitetos, engenheiros e testadores de
software carecem de habilidades apropriadas em relação a segurança.

Nessas circunstâncias, uma organização que deseja desenvolver software seguro

precisa assumir a responsabilidade de treinar suas equipes apropriadamente no tema. Meio
específicos de alcançar tais desafios variam dependendo do tamanho da organização e
recursos disponibilizados. Uma organização com uma ampla população envolvida com
85
engenharia de software pode ser capaz de comprometer-se a fornecer um programa de
treinamento in-house de educação continuada em segurança, enquanto uma organização
menor pode valer-se de treinamentos externos. O importante é que haja envolvimento e
vontade para a construção de softwares mais seguros [WING 2003a].

86
 VII - CONCLUSÃO

7.1. Introdução

Este trabalho apresentou meios para o desenvolvimento de software seguro após ter
sido realizada uma revisão da literatura nas áreas de engenharia de software e segurança da
informação. Os meios consistem-se na adequação dos processos de melhoria da qualidade
aos requisitos de segurança, à criação de projetos arquiteturais genuinamente seguros e
aculturação organizacional de práticas de gerência voltadas à segurança.

Neste capítulo são apresentadas as conclusões para o trabalho e as contribuições

alcançadas. Também são discutidas algumas perspectivas futuras para o trabalho.

7.2. Conclusão e contribuição

A crescente importância dada à segurança da informação requer que sejam

definidos e implementados mecanismos mais eficientes para apoiar as atividades que
envolvam segurança da informação. Neste contexto, o objetivo deste trabalho foi
apresentar técnicas, metodologias, modelos e práticas que apoiem o desenvolvimento de
software seguro. As contribuições dessa abordagem são:

• Destacar aspectos de segurança em metodologias tradicionais de melhoria

da qualidade;
• Salientar a diferença entre segurança e qualidade;
• Apresentar fatores importantes para constituírem ambientes de
desenvolvimento seguro;
• Discorrer sobre metodologias dirigidas à segurança da informação;
• Relacionar requisitos de segurança fundamentais;

87
 • Especificar técnicas determinantes para a criação de projeto arquitetural
seguro;
• Mostrar particularidades que aperfeiçoam questões de segurança na
condução 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 aperfeiçoar processos de
desenvolvimento de software para a obtenção de produtos mais seguros.

Diversos trabalhos podem ser definidos e desenvolvidos com o propósito de

melhorar e estender a proposta apresentada, por exemplo:

• Estruturação do modelo de ciclo de vida para desenvolvimento de software

seguro apresentado através da formulação de documentação (artefatos) para
as fases especificadas e comparação desse modelo com outros;
• Proposição de um novo modelo de ciclo de vida para desenvolvimento de
software seguro;
• Criação de um framework para apoiar a aplicação dos requisitos funcionais
de segurança;
• Formulação de padrões de desenvolvimento que suportem, se não todos,
alguns dos requisitos funcionais de segurança citados;
• Desenvolvimento de ferramentas de gerência para desenvolvimento de
softwares aderentes à norma ISO/IEC 15408;
• Elaboração de conteúdo pedagógico para capacitação de recursos humanos
(desenvolvedores, arquitetos e engenheiros de software) em segurança da
informação;

88
 Outros trabalhos também podem ser realizados para apoiar as atividades que
sucintamente foram mencionadas e outras que não foram abordadas nesse trabalho, por
exemplo:

• Fatores econômicos como meios de viabilizar a integração da engenharia de

software e segurança da informação;
• O impacto de legislações como Sarbanes-Oxley Act na engenharia de
software;
• Contribuições que padrões como COBIT e ITIL podem oferecer à
engenharia de software seguro.

89
 VIII - REFERÊNCIAS

ALBUQUERQUE, R; RIBEIRO, B. Segurança 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 Prático, Editora
Campus, 2002.

BARROS, ROBERTO SOUTO MAIOR prefácio para Antonio Mendes Arquitetura de

Software - Desenvolvimento orientado para arquitetura, Editora Campus, 2002.

BASS, L.; CLEMENTS, P.; KAZMAN, R. Software Architecture in Practice, Addison-

Wesley, 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, UMIACS-
TR-2000-76, Maio, 2001.

CARVALHO, A. M. B. R.; CHIOSSI, T. C. S. Introdução à 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
CÔRTES, 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 Aplicações de Curvas Elípticas em Criptografia, III Seminário de Informática -

Segurança da Informação, 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, São Paulo: Escola
de Computação, jul., 2000.

FOWLER, M. Refatoração: Aperfeiçoando o Projeto de Código 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.

GONÇALVES, L. R. O. O surgimento da Norma Nacional de Segurança de Informação

NBR ISO/IEC-1779:2001, Lockabit - Portal de Segurança da Informação, COPPE-
UFRJ, 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, Conheça 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 Prática, 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 Pública: Estado da Arte, III Seminário de Informática -

Segurança da Informação, 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 Informação - 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 Reflexão, Módulo Security
Magazine Portal, Módulo Security, http://www.modulo.com.br, 2005. Último
acesso em 10/04/2005.

ORTALO, R.; DESWARTE, Y.; KAÂNICHE, 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 prática, Editora

Campus, 2001.

95
PRESSMAN, R. Software engineering: a practitioner´s approach, 3ª ed., Mc-Graw Hill,
1992

PRICOLA, L. Estruturação e operação de um Grupo de Resposta a Incidentes de

Segurança, Módulo 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. Segurança Nacional - Técnicas 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. Edição, 1995.

SCHNEIER, B. Secrets and Lies: Digital Security in a Networked World, John Wiley &
Sons, 2000.

SCHNEIER, BRUCE prefácio 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. Edição, 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. Edição, 1989.

THAYLER, R.; DORFMAN, M. System and Software Requirements Engineering, IEEE

Computer Society Press, 1990.
97
TOMELLI, Leonardo Segurança no Desenvolvimento de Software, MSDN Magazine, Vol.
1, No. 3, Janeiro, 2004.

TORRES, D. Segurança Máxima 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 Can’t 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 Impossíveis, Makron Books, 1999.

98