métricas de segurança de softwarelivros01.livrosgratis.com.br/cp040026.pdf · métricas de...

CARLOS FREUD ALVES BATISTA

Métricas de Segurança de Software

DISSERTAÇÃO DE MESTRADO

DEPARTAMENTO DE INFORMÁTICA

Programa de Pós-Graduação em Informática

Rio de Janeiro

Abril de 2007

DBD

PUC-Rio - Certificação Digital Nº 0410821/CA

Livros Grátis

http://www.livrosgratis.com.br

Milhares de livros grátis para download.

Carlos Freud Alves Batista


Dissertação de Mestrado

Dissertação apresentada como requisito parcial para

obtenção do grau de Mestre pelo Programa de Pós-

graduação em Informática do Departamento de

Informática da PUC-Rio.

Orientador: Prof. Arndt von Staa

Rio de Janeiro

Abril de 2007

DBD




Dissertação apresentada como requisito parcial para

obtenção do grau de mestre pelo programa de pós-

graduação em Informática do Departamento de

Informática da PUC-Rio. Aprovada pela Comissão

Examinadora abaixo assinada.

Prof. Arndt von Staa

Orientador

Departamento de Informática – PUC-Rio

Prof. Julio Cesar Sampaio do Prado Leite


Profa. Karin Koogan Breitman


Prof. José Eugenio Leal

Coordenador Setorial do CentroTécnico e Científico – PUC-Rio

Rio de Janeiro, 16 de abril de 2007

DBD


Todos os direitos reservados. É proibida a reprodução total ou parcial do trabalho sem autorização da universidade, do autor e do orientador.


Graduou-se em Bacharelado em Informática pela Universidade Federal do Rio de Janeiro em agosto de 1996. Atualmente é analista de sistemas da Tecnologia da Informação da Petróleo Brasileiro S/A (PETROBRAS). Sua área de concentração é a implantação e a melhoria de processos de desenvolvimento de software.

Ficha Catalográfica

CDD: 004

Batista, Carlos Freud Alves

Métricas de segurança de software / Carlos Freud Alves

Batista ; orientador: Arndt Von Staa. – 2007.

102 f. : il. ; 30 cm

Dissertação (Mestrado em Informática)–Pontifícia

Universidade Católica do Rio de Janeiro, Rio de Janeiro,

2007.

Inclui bibliografia

1. Informática – Teses. 2. Medição. 3. Métricas. 4.

Segurança. 5. Segurança de software. I. Staa, Arndt Von. II.

Pontifícia Universidade Católica do Rio de Janeiro.

Departamento de Informática. III. Título.

DBD


A Deus por tudo o que tem feito e por

tudo que vai fazer. Por suas promessas e

por tudo que É.

Este trabalho é dedicado a minha esposa

Roseane e ao meu filho Davi Lucas que

em todos os momentos me cercaram de

amor, incentivo, compreensão e carinho.

DBD


Agradecimentos

Ao meu orientador, professor Arndt von Staa, pelo apoio, estímulo, paciência, parceria e tempo despendido neste trabalho. Sua orientação e comentários preciosos foram fundamentais para o desenvolvimento deste trabalho.

Aos professores Julio Cesar Sampaio do Prado Leite, Karin Koogan Breitman e Simone Diniz Junqueira Barbosa por participarem da Comissão Examinadora.

Aos meu pais, pela educação, atenção e carinho de todas as horas.

Aos amigos da Petrobras pelas valiosas colaborações para a realização deste trabalho.

A todos os irmãos da Comunidade Shamah pelos momentos de oração.

DBD


Resumo

Batista, Carlos Freud A.; Staa, Arndt v. . Métricas de Segurança de Software. Rio de Janeiro, 2007. 102p. Dissertação de Mestrado - Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro

A dependência cada vez maior da tecnologia de informação (TI) torna software seguro um elemento chave para a continuidade dos serviços de nossa sociedade atual. Nos últimos anos, instituições públicas e privadas aumentaram seus investimentos em segurança da informação, mas a quantidade de ataques vem crescendo mais rapidamente do que a nossa capacidade de poder enfrentá-los, colocando em risco a propriedade intelectual, a relação de confiança de clientes e a operação de serviços e negócios apoiados pelos serviços de TI. Especialistas em segurança afirmam que atualmente boa parte dos incidentes de segurança da informação ocorrem a partir de vulnerabilidades encontradas no software, componente presente em boa parte dos sistemas de informação. Para tornar o software fidedigno em relação à segurança, a criação e o uso de métricas de segurança serão fundamentais para gerenciar e entender o impacto dos programas de segurança nas empresas. Porém, métricas de segurança são cobertas de mistério e consideradas bastante difíceis de serem implementadas. Este trabalho pretende mostrar que hoje ainda não é possível termos métricas quantitativas capazes de indicar o nível de segurança que o software em desenvolvimento virá a ter. Necessitam-se, então, outras práticas para assegurar níveis de segurança a priori, ou seja, antes de se por o software em uso.

Palavras-chave

Medição, métricas, segurança, segurança de software

DBD


Abstract

Batista, Carlos Freud A.; Staa, Arndt v. (Advisor). Software Security Metrics. Rio de Janeiro, 2007. 102p. MSc. Dissertation - Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro

Today's growing dependency on information technology (IT) makes software security a key element of IT services. In recent years public and private institutions raised the investment on information security, however the number of attacks is growing faster than our power to face them, putting at risk intellectual property, customer´s confidence and businesses that rely on IT services. Experts say that most information security incidents occur due to the vulnerabilities that exist in software systems in first place. Security metrics are essential to assess software dependability with respect to security, and also to understand and manage impacts of security initiatives in organizations. However, security metrics are shrouded in mystery and very hard to implement. This work intends to show that there are no adequate metrics capable of indicating the security level that a software will achieve. Hence, we need other practices to assess the security of software while developing it and before deploying it.

Keywords

Measurement, metrics, security, software security

DBD


Sumário

1 INTRODUÇÃO ...........................................................................................15

1.1 Motivação...........................................................................................16

1.2 Proposta .............................................................................................17

1.3 Discussão e contribuições esperadas ................................................18

1.4 Organização deste trabalho ...............................................................19

2 CONCEITOS E PROPRIEDADES DESEJÁVEIS PARA UM SOFTWARE

SEGURO ....................................................................................................20

2.1 Definindo Segurança..........................................................................20

2.2 Propriedades desejáveis para um software seguro............................21

2.3 Relacionamento entre Fidedignidade e Segurança............................24

2.4 Terminologias associadas com segurança e seus relacionamentos..26

2.5 Relações entre Segurança da Informação, Segurança de Sistemas

de Informação, Segurança de Software ...................................................29

2.6 O que queremos em relação ao desempenho do software quanto à

questão da segurança?............................................................................33

3 MÉTRICAS DE SEGURANÇA DE SOFTWARE .................................................36

3.1 Medição de Software..........................................................................36

3.2 Métricas de Segurança de Software ..................................................38

3.3 Classificações de Métricas de Segurança encontradas na

Literatura ..................................................................................................40

3.4 Critérios de Avaliação.........................................................................41

3.4.1 Modelo de avaliação de segurança a partir de boas práticas do

mercado (Auditoria externa) .....................................................................42

DBD


3.4.2 Modelo de avaliação de segurança a partir de práticas de

segurança definidas internamente (Auditoria interna) ..............................44

3.4.3 Modelo de maturidade da capacitação............................................45

3.4.4 Modelo de Análise de Riscos ..........................................................45

3.4.5 Modelo de Eliminação de Defeitos ..................................................45

4 AVALIAÇÃO QUANTITATIVA DE SEGURANÇA DE SISTEMAS............................46

4.1 Esforço despendido por um atacante.................................................46

4.2 O Índice de Vulnerabilidade do Sistema.............................................48

4.3 MTTI – Minimum-Time-To-Intrusion ...................................................51

4.4 Avaliação Quantitativa para Monitorar a Segurança Operacional ......56

4.5 Método Wang e Wulf para Medir Segurança......................................63

4.6 Redução da Superfície de Ataque......................................................74

4.7 Proposta de um Framework para medir a segurança de um

software....................................................................................................78

4.8 Análise dos Métodos Apresentados ...................................................81

5 DIFICULDADES NA GERAÇÃO DE MÉTRICAS DE SEGURANÇA

QUANTITATIVAS ..........................................................................................83

5.1 Evolução de Nossa Capacidade de Tratar a Insegurança .................85

5.2 Dificuldades que encontramos na busca por métricas quantitativas

de segurança............................................................................................87

5.2.1 Outros campos têm números para expressar. Qual é a

equivalência para segurança do software? ..............................................87

5.2.2 Composição pode Introduzir Falhas................................................88

5.2.3 Pessoas e processos podem diminuir a segurança ........................88

5.2.4 Falta de embasamento teórico ........................................................89

5.2.5 O aspecto tempo .............................................................................90

5.2.6 Valores Lógicos Tradicionais...........................................................90

5.2.7 Terminologia de segurança .............................................................90

DBD


5.2.8 As facilidades e recursos hoje disponíveis ......................................90

5.2.9 Dificuldades dos Sistemas de Detecção de Invasão.......................91

5.2.10 A garantia da segurança após a evolução do software.................91

5.2.11 A complexidade de verificar segurança em grandes sistemas......91

5.2.12 A limitação de métodos baseados em contagem de Bugs de

segurança.................................................................................................92

5.2.13 Outras propriedades desejáveis podem afetar a segurança

como um todo...........................................................................................92

5.2.14 Nem sempre podemos só considerar uma análise quantitativa ....92

5.3 Recomendações para a Avaliação de Segurança..............................93

6 CONCLUSÕES E TRABALHOS FUTUROS ......................................................95

6.1 Trabalhos Futuros ..............................................................................96

7 REFERÊNCIAS BIBLIOGRÁFICAS .................................................................97

DBD


Lista de Figuras

Figura 1: Segurança em seu conceito mais tradicional ............................23

Figura 2: Relacionamento de Fidedignidade e Segurança (extraída

de Avizienis et al., 2004) ..........................................................................24

Figura 3: Conceitos relacionados à segurança e seus

relacionamentos. (extraída do Common Criteria , 2002)..........................26

Figura 4: Ameaça e vulnerabilidade (extraída de Pfleeger, 2003)............29

Figura 5: Sistemas de Informação............................................................30

Figura 6: Diferentes dimensões de segurança do sistema

(extraída de Goertzel et al., 2006)............................................................31

Figura 7: Classificação das métricas de software encontradas

em HENNING(2001) ................................................................................40

Figura 8: Caracterização de Métricas de Software (extraída de

HENNING, 2001)......................................................................................41

Figura 9: Histórico da Criação do Common Criteria. Figura extraída

do artigo “Computer Security Criteria: Security Evaluations and

Assessment” de 2001 da Oracle. .............................................................43

Figura 10: Visão Geral do protótipo AVA (extraída de

Voas et al., 1996) .....................................................................................54

Figura 11: Métrica MTTI. M é o número de localizações aonde

o AVA foi aplicado (extraída de .Voas et al., 1996) ..................................55

Figura 12: Métrica MinTTI (extraída de .Voas et al., 1996) ......................55

Figura 13: X obtém os privilégios do nó Y................................................57

Figura 14: Grafo de Privilégios (extraída de Ortalo et al., 1999) ..............58

Figura 15: O Atacante e o caminho até o alvo. ........................................60

Figura 16: Derivação das Attack state graphs a partir do Grafo de

Privilégios. Figura baseada no artigo de Ortalo e co-autores

(Ortalo et al., 1999).. ................................................................................61

Figura 17: Exemplo de decomposição. Figura extraída do artigo

“A Framework for Security Measurement” de Wang e Wulf (1997) ..........65

DBD


Figura 18: Exemplo da Porta (extraída do artigo “A Framework for

Security Measurement” de Wang e Wulf (1997)) .....................................67

Figura 19: Funcionamento da janela em relação aos seus fatores

(extraída do artigo “A Framework for Security Measurement” de

Wang e Wulf (1997)) ................................................................................69

Figura 20: Árvore de Decomposição para uma Casa (Extraída do

artigo “A Framework for Security Measurement” de Wang e

Wulf (1997))..............................................................................................71

Figura 21: Hype Cycle for Cyberthreats, (extraída de Williams et al,

2006) ........................................................................................................86

DBD


Lista de Tabelas

Tabela 1: Impacto Financeiro de Ataques de Vírus - Fonte Computer

Economics, (McManus, 2006). .................................................................16

Tabela 2: Indexes de Sensitividade (S.I.s) dos componentes básicos

da casa (extraída do artigo “A Framework for Security Measurement”

de Wang e Wulf (1997)). ..........................................................................72

DBD


Lista de Abreviaturas

AVA - Análise de Vulnerabilidade Adaptativa

CC - Common Criteria

CERT - Computer Emergency Response Team

COBIT - Control Objectives for Information and Related Tecnologies

CTCPEC - Canadian Trusted Computer Product Evaluation Criteria

CVE - Common Vulnerabilities and Exposures

DOD - Department of Defense

EAL - Evaluation Assurance Level

EPA - Extended Propagation Analysis

FIPS - Federal Information Processing Standard

IDS - Intrusion Detect System

ISO - International Standards Organization

ITSEC – Information Technology Security Evaluation Criteria

IVS - Índice de Vulnerabilidade do Sistema

METB - Mean Effort to Breach

METF - Mean Effort to Security Failure

MITRE - Massachusetts Institute of Technology

MTTF - Mean Time to Failure

MSFR - Minimum Security Functionality Requirements

ML - Memory Less

MTTI – Minimum-Time-To-Intrusion

NIST - National Institute of Standards and Technology

NW - Normalized Weight

PS - Prioritized Siblings

SDLC - System Development Life Cycle

SI - Sensitivity Index

SP - Short Path

SSE-CMM - System Security Engineering Capability Maturity Model

TCSEC – Trusted Computing System Evaluation Criteria

TI - Tecnologia da Informação

TM - Total Memory

WL - Weakest Link

WWL - Weighted Weakest Link

DBD


1 Introdução

A construção de um software fidedigno é um dos grandes desafios a ser

alcançado por todos aqueles que desenvolvem software. Entre as várias questões

relacionadas à fidedignidade do software, o desenvolvimento de software seguro

apresenta-se como uma área desafiadora e de interesse cada vez maior por parte

das empresas e dos pesquisadores (Redwine, 2004).

Apesar de todo o investimento realizado contra as ameaças à segurança da

informação, a quantidade de ataques a empresas e seus aplicativos vem

aumentando mais rapidamente do que a nossa capacidade em poder enfrentá-los.

Profissionais da indústria de informática concordam que um software inseguro é

uma das principais causas de falhas de segurança, que freqüentemente levam a

inúmeros problemas nos negócios das empresas (Lanowitz, 2005). Segundo o

relatório IT Security Study: The Current State of IT Security Budgets,

Management Practices, and Security Incidents da Computer Economics

(McManus, 2006), só o impacto dos ataques de vírus do computador no mundo já

atingiu a cifra de $111 bilhões de dólares se somarmos os gastos de 1995 até

2005, como pode ser observado na tabela 1 a seguir.

DBD


Introdução

16

Ano Valor

2005 $14.2 Bilhões

2004 $ 17.5 Bilhões

2003 $ 13.0 Bilhões

2002 $ 11.1 Bilhões

2001 $ 13.2 Bilhões

2000 $ 17.1 Bilhões

1999 $ 13.2 Bilhões

1998 $ 6.1 Bilhões

1997 $ 3.3 Bilhões

1996 $ 1.8 Bilhão

1995 $ 500 Milhões

Tabela 1: Impacto Financeiro de Ataques de Vírus - Fonte Computer

Economics, (McManus, 2006).

Diante deste grande desafio de se produzir software fidedigno em relação à

segurança da informação, como podemos garantir que o investimento das

empresas em segurança da informação está tendo o retorno desejado,

particularmente, aquele investimento realizado para garantir um software seguro,

isto é, em níveis aceitáveis de segurança?

Mas como avaliar a segurança de um software? É realmente possível hoje

medir se um software é seguro ou não? Se possível, como fazer isso?

1.1 Motivação

Várias pesquisas indicam que com o passar dos anos a segurança de

informação vem crescendo em prioridade para muitas organizações (Henning,

2001; Davis, 2004 ; Lanowitz, 2005; Goertzel et al., 2006). A preocupação com a

segurança de computador está se tornando crescentemente, não só em relação ao

investimento a ser aplicado em segurança, mas também em relação ao retorno

deste investimento num momento em que as áreas de TI vem sendo orientadas a

reduzirem seus custos.

DBD


Introdução

17

Diante dos relatórios freqüentes com notícias sobre falhas de segurança

sérias, principalmente nos softwares, gerentes de segurança e profissionais de TI

estão sendo, mais do que nunca, pressionados a demonstrar a efetividade dos seus

programas de segurança.

Como forma de justificar o investimento em segurança, cada vez mais as

organizações estão reconhecendo a importância de um programa de métricas de

segurança, porém há pouca informação disponível ao redor da prática "O como

fazer?" para estabelecer um programa com métricas confiáveis (Bellovin, 2006).

Como resultado, métricas de segurança são envoltas em mistério e são

consideradas muito difíceis de serem implementadas (Henning, 2001).

Como os gastos com segurança continuam subindo (McManus, 2006), os

analistas da indústria afirmam que as iniciativas de métricas de segurança serão

críticas para entender o impacto dos programas de segurança.

Mas avaliar a segurança de um software não é uma tarefa fácil. Se não

conseguimos medir segurança, então como podemos melhorá-la? (Bellovin, 2006)

Ao melhorar a segurança em um software, queremos que o software resista

a ataques deliberados ou acidentais, impedindo a divulgação de dados

confidenciais a quem não tem direito, registrando as tentativas de agressão e

acidentes e que disponibilize informações que facilitem localizar as brechas de

segurança e as faltas na sua implementação. Em suma, um software mais

fidedigno quanto aos seus requisitos de segurança.

1.2 Proposta

A proposta desta dissertação é mostrar que hoje ainda não dispomos de

métricas confiáveis para medir o nível de segurança de um software. Para a

realização deste trabalho, esta proposta de dissertação propõe:

1. Conceituar segurança, descrevendo as principais propriedades relacionadas

com o tema.

2. Descrever os princípios para avaliações de segurança de software e a

DBD


Introdução

18

importância das métricas de segurança de software.

3. Apresentar os principais métodos de avaliação quantitativa de segurança hoje

existentes, apontando as suas falhas.

4. Apresentar algumas dificuldades na geração de métricas de segurança

quantitativas.

5. Propor áreas de pesquisa para o estudo de métricas de segurança de software.

1.3 Discussão e contribuições esperadas

Segundo Redwine (2004), nem no mundo físico, nem em Engenharia de

Software a segurança pode ser garantida por completo. Apesar disto, um bom

programa de métricas deve ser adotado para obtermos evidências estatísticas de

que um processo produz software seguro ou que um software possui um nível de

segurança adequado. Um programa de métricas pode ajudar a uma organização a

ter respostas a perguntas como:

1. Qual o retorno do investimento em segurança nas aplicações?

2. Qual é a capacidade e a competência dos recursos em trabalhar com segurança?

3. As ações de segurança estão baseadas em boas práticas conhecidas e em acordo

com padrões aplicáveis e com requisitos legais?

4. Como os riscos de segurança estão sendo gerenciados?

5. Qual é a performance alcançada por nossos sistemas em termos de

gerenciamento de ameaças, de vulnerabilidades, de responder a eventos e de

retomar e controlar perdas?

Esta é uma iniciativa importante porque muitas empresas enfrentam hoje,

além do próprio problema do aumento do número de incidentes contra suas

políticas de segurança da informação, exigências de leis governamentais tais como

DBD


Introdução

19

a Sarbanes-Oxley1 (Tipton, 2004), que preconizam uma maior segurança das

aplicações utilizadas por estas instituições.

Os resultados deste trabalho podem ser utilizados para a melhoria de

práticas hoje utilizadas no desenvolvimento e na manutenção de softwares.

1.4 Organização deste trabalho

No segundo capítulo serão apresentados conceitos básicos sobre segurança

importantes para o entendimento e elaboração do trabalho.

O terceiro capítulo apresenta o conceito de métricas de segurança de

software, descrevendo a sua importância e os principais métodos para avaliação

de segurança de software.

No quarto capítulo são apresentados alguns métodos para avaliação

quantitativa de segurança presentes na literatura, suas vantagens e desvantagens.

Uma comparação entre os métodos também é apresentada ao final deste capítulo.

No quinto capítulo são apresentadas as dificuldades hoje encontradas na

geração das métricas de segurança de software e o porquê de até hoje não

conseguirmos definir com sucesso tais métricas.

1 Sarbanes-Oxley - lei americana que busca aperfeiçoar os controles financeiros das empresas e

apresentar eficiência na governança corporativa. A lei visa garantir a transparência na gestão

financeira das organizações, credibilidade na contabilidade, auditoria e a segurança das

informações para que sejam realmente confiáveis, evitando assim fraudes, fuga de investidores,

etc.

DBD


2 Conceitos e Propriedades Desejáveis Para Um Softwar e Seguro

Os objetivos deste capítulo são entender os principais conceitos, termos e

definições sobre segurança presentes nesta dissertação, compreender a

importância dos sistemas de informação para a garantia da segurança da

informação e discutir sobre o que é desejável nos softwares para a garantia da

segurança.

2.1 Definindo Segurança

O que é segurança? Dependendo do contexto pode significar coisas

diferentes para pessoas diferentes, tornando a definição e o entendimento do

conceito um pouco difícil. Na língua portuguesa, segundo o dicionário Aurélio

(Ferreira, 1999), segurança tem os seguintes significados:

1. Estado, qualidade ou condição de seguro.

2. Condição daquele ou daquilo em que se pode confiar.

3. Certeza, firmeza, convicção.

Ao consultar também o significado da palavra seguro neste mesmo

dicionário, presente no primeiro significado acima, é possível encontrar as

seguintes definições:

1. Livre de perigo (ameaças)

2. Livre de risco; protegido, acautelado, garantido.

3. Em que se pode confiar.

4. Certo, indubitável, incontestável.

DBD


Conceitos e Propriedades Desejáveis Para Um Software Seguro

21

5. Eficaz, eficiente.

Como podemos observar, na lingua portuguesa dizer que algo é seguro tanto

pode significar que está livre de perigos, como também algo eficaz. Diferentes

significados para o termo segurança também são encontrados na literatura

acadêmica (Avizienis et al., 2004), ITSEC (1991), (NBR ISO/IEC 17799, 2001),

causando, muitas vezes, uma grande confusão, principalmente quando ampliamos

o escopo do conceito de proteção (Chung et al., 2000).

Um software fidedigno (Staa, 2006) precisa ser confiável (Avizienis et al.,

2004) e seguro quanto a eventos não intencionais e intencionais. Entender a

motivação do evento que causa a insegurança nos ajuda a compreender que tipo

de segurança está sendo abordado.

Eventos não intencionais ocorrem quando o agente da insegurança, ou

agente de ameaças, não tem a intenção de provocar o dano, como por exemplo,

aqueles causados por acidentes naturais ou humanos.

Eventos intencionais ocorrem quando os agentes de insegurança têm como

objetivo executar ataques e causar incidentes que podem causar dano. Estes

agentes, geralmente, utilizam vulnerabilidades no sistema para comprometer a

segurança como um todo. O estudo da segurança para esta classe de evento é

abordado na literatura como security, isto é, segurança contra eventos

intencionais. Eventos decorrentes de ausência de responsabilidade e compromisso

com o desenvolvimento de software com qualidade também podem ser incluídos

em security.

A garantia de segurança (em inglês: security) em relação a eventos

intencionais contra o software é o objeto de estudo nesta dissertação.

2.2 Propriedades desejáveis para um software seguro

A garantia de segurança pode ser trabalhada com a inclusão de propriedades

no projeto de software que necessita ser seguro. Estas propriedades desejáveis

podem ser encontradas no ITSEC (1991), que define segurança (em inglês:

DBD



22

security) como uma composição de atributos de confidencialidade, integridade e

disponibilidade aplicáveis ao objeto software em um contexto de sistema de

informação. Este é o conceito mais tradicional de segurança da informação. A

definição mais detalhada de cada propriedade desejável de segurança é a seguinte

(Staa, 2006):

Disponibilidade (em inglês: availability) – prontidão para o serviço correto.

Preservar a disponibilidade consiste na garantia de que usuários autorizados

obtenham acesso à informação e aos ativos correspondentes sempre que

necessário. Deve ser evitada a destruição desautorizada da informação ou a

indisponibilização dos serviços.

Integridade (em inglês: integrity) – ausência de alterações não permitidas

(corrupção de elementos). Preservar a integridade consiste na salvaguarda da

exatidão e completeza da informação e dos métodos de processamento.

Normalmente, o interesse comercial por esta propriedade é maior do que a

confidencialidade. Pode ser subdividida em:

Integridade de dados – a propriedade de um dado não ser alterado,

destruído ou perdido de maneira acidental ou não autorizada.

Integridade do software – a qualidade de um software em preservar

suas funcionalidades (ausência de alterações não permitidas), não sendo

corrompido durante o seu desenvolvimento ou execução (Goertzel et al.,

2006).

Confidencialidade em (em inglês: confidentiality) – preservar a

confidencialidade consiste em garantir que o acesso à informação seja obtido

somente por pessoas autorizadas a terem esse acesso. A confidencialidade pode

ser considerada uma propriedade desejável para a garantia da privacidade (em

inglês: privacy), que é a habilidade de proteger dados e código de acesso indevido

(Staa, 2006).

A Figura 1 representa o conceito mais tradicional de segurança da

informação. A informação precisa estar disponível para quem tem o direito de

acessá-la. Quem não tem direito de acessá-la deve ser impedido de utilizar

DBD



23

vulnerabilidades para praticar atos que violem a integridade e a confidencialidade

do sistema. Neste casos a informação não pode sair do sistema (quebra de

confidencialidade) e nem pode ser modificada ou apagada para quebra de

integridade. Setas marcadas com um “X” representam ameaças as propriedades de

segurança que devem ser impedidas para que a informação não venha ser violada

e adulterada.

Figura 1: Segurança em seu conceito mais tradicional

Além das propriedades tradicionais, também estão sendo incluidas como

propriedades desejáveis para o software seguro a propriedade de não-

repudiabilidade (em inglês: non-repudiation), que consiste na habilidade em

prevenir o software (como um usuário) de refutar ou negar a responsabilidade por

ações por ele executadas, e a accountability (que em português pode ser traduzida

como responsabilidade) determina que todas as ações relevantes para a segurança

do software devem ser registradas e rastreadas junto com a atribuição de

responsabilidades, isto é, com a possibilidade de se poder responsabilizar alguém

por seus atos. O rastreamento deve ocorrer tanto no momento como depois em

que as ações ocorrem.

A propriedade não-repudiabilidade e a propriedade responsabilidade são,

geralmente, associadas ou com usuários humanos ou com entidades de software

que atuam como usuários (agents proxies, Web services) (Goertzel et al., 2006).

A segurança de software, então, consiste na preservação da

confidencialidade, da integridade, da não-repudiabilidade, da possibilidade de

prestar contas e da disponibilidade dos ativos e recursos de informação que o

DBD



24

software cria, armazena, processa ou transmite, incluindo o próprio programa em

execução.

2.3 Relacionamento entre Fidedignidade e Segurança

A segurança e a fidedignidade no funcionamento são duas áreas de pesquisa

já com cerca de três décadas de existência com muitos pontos em comum e com o

mesmo objetivo que é o funcionamento correto de sistemas computacionais

(Correia, 2006). Um software fidedigno apresenta garantia da execução de suas

funções requeridas, sob todas as circunstâncias possíveis, em um período de

tempo satisfatório, sem nunca executar qualquer ação cuja conseqüência leve a

resultados indevidos, tais como acidentes sérios, perda de vidas ou propriedades,

prejuízos para negócios de empresas ou violação de segurança.

Avizienis (Avizienis et al., 2004) em seu trabalho estabelece definições para

caracterizar vários conceitos relacionados à fidedignidade e a segurança de

sistemas de computação e comunicação, apresentando um forte relacionamento

entre estes dois conceitos a partir dos seus principais atributos.

Figura 2: Relacionamento de Fidedignidade e Segurança (extraída de Avizienis et al.,

2004)

Conforme a Figura 2 acima, além dos atributos disponibilidade, integridade

e confidencialidade já apresentados nesta dissertação, a fidedignidade de um

software é uma composição dos seguintes atributos (Staa, 2006):

• Confiabilidade (em inglês: reliability)- continuidade do serviço correto.

DBD



25

• Segurança (em inglês: safety) – ausência de conseqüências catastróficas

tanto aos usuários quanto ao ambiente, a partir de um evento não

intencional.

• Manutenibilidade (em inglês: maintainability) – habilidade de ser

modificado ou corrigido sem que novos problemas sejam inseridos.

Para melhor entender o relacionamento entre segurança e fidedignidade

considere a natureza das ameaças à segurança e, por extensão, a fidedignidade e as

conseqüências destas ameaças quando bem sucedidas. Algumas ameaças bem

sucedidas contra a fidedignidade do software são resultantes de falhas decorrentes

de faltas no software. De acordo com Avizienis et al, faltas de software caem em

uma das três categorias a seguir:

1. Faltas no desenvolvimento: um tipo de falta que é introduzida

durante o processo de desenvolvimento do software. Quando estas

faltas são exercitadas podem ocorrer erros que, uma vez observados,

constituem falhas.

2. Faltas físicas: um tipo de falta que é provocada por um defeito,

possivelmente transiente, ou anomalia no hardware em que o

software executa.

3. Faltas externas: um tipo de falta que é provocada externamente ao

software e de sua plataforma de hardware. Faltas externas podem

interagir com o software como parte dos dados de entrada de

usuários, variáveis passadas pelo ambiente, mensagens recebidas a

partir de outro software, etc.

Faltas humanas podem ser intencionais ou não intencionais e podem ou não

ser maliciosas. Faltas não maliciosas intencionais muitas vezes são resultantes de

uma má avaliação. Por exemplo, uma decisão de um desenvolvedor em investir

mais em performance e usabilidade do que em segurança em um projeto que

necessita ser seguro. Ferramentas e teorias errôneas também podem levar a perda

de segurança.

DBD



26

As faltas existentes no software tornam-se uma ameaça à fidedignidade

quando elas são exercitadas. Faltas são sempre latentes, ou seja existem, mas não

necessariamente resultam em erros e falhas. Faltas são interessantes por causa de

seu potencial em causar problemas quando forem exercitadas. Conseqüentemente,

faltas sempre constituem vulnerabilidades que um invasor pode explorar.

A ênfase dos estudos sobre segurança tem sido em problemas de origem

maliciosa (ataques, código nocivo), enquanto que o foco dos estudos sobre

fidedignidade tem sido mais nos problemas de origem acidental. No entanto, as

disciplinas não se excluem, pois a segurança pode tratar problemas de origem

acidental e a fidedignidade no funcionamento pode incluir problemas de origem

maliciosa (Correia, 2006).

2.4 Terminologias associadas com segurança e seus

relacionamentos

Alguns termos empregados relacionados com o tema security, representados

pela Figura 3, merecem uma breve descrição.

Figura 3: Conceitos relacionados à segurança e seus relacionamentos. (extraída do

Common Criteria , 2002)

DBD



27

Proprietários são os indivíduos responsáveis em decidir em nome da

organização no que diz respeito ao uso, à identificação, à classificação, e à

proteção de um recurso ou ativo específico da informação (Redwine, 2004).

Ativo é uma entidade que possui algum valor para seus proprietários como,

por exemplo, uma informação, um serviço ou um bem material. Normalmente,

seus proprietários buscam medidas preventivas, que nem sempre são eficientes,

para proteger seus ativos e recursos contra ameaças (Redwine, 2004).

No contexto da segurança em software, uma vulnerabilidade é uma falta em

um produto de software que juntamente com algum conhecimento sobre o

software e seu ambiente operacional, permite que uma invasão ocorra, tornando o

software inseguro, mesmo que esteja sendo utilizado adequadamente. Voas (1996)

define nível de vulnerabilidade como o grau de acesso não autorizado permitido a

um sistema. Por exemplo, o acesso a camadas internas de um sistema operacional

precisa ser protegido de usuários sem autorização, porém se tais usuários podem

obter este acesso, então o sistema operacional será classificado como tendo um

alto nível de vulnerabilidade. As vulnerabilidades podem se originar a partir da

tecnologia, pessoas ou processos. Davis (2004) afirma que a maioria das

vulnerabilidades de segurança encontradas hoje nos softwares ocorre a partir de

faltas que são inseridas de forma não intencional ao longo do processo de

desenvolvimento. Políticas e procedimentos organizacionais mal definidos e

comunicados são também vulnerabilidades. As vulnerabilidades conduzem a

riscos sobre os ativos e recursos de informação (Redwine, 2004).

O termo agente de ameaças é usado para indicar um evento da natureza

(meteoro, fogo, alagamento, etc), um grupo de indivíduos ou um indivíduo que

possui ou pode possuir capacidade e intenção de criar ameaças (Redwine, 2004).

Ameaças são eventos não esperados (deliberados ou acidentais), externos ao

sistema de software, que podem ocorrer, resultando em prejuízos aos ativos e

recursos de informação (Redwine, 2004). Normalmente, o software está sujeito a

duas categorias gerais de ameaças (Goertzel et al., 2006):

1. Ameaças durante o desenvolvimento (principalmente ameaças

DBD



28

internas): Um desenvolvedor pode sabotar o software em algum

ponto em seu ciclo de desenvolvimento, através de exclusões

intencionais, inclusões, ou modificações da especificação de

requisitos, do modelo de ameaças, dos documentos do projeto, do

código fonte, dos casos de testes e evidências de testes, etc. Um

processo de desenvolvimento seguro ajuda a reduzir a exposição

do software as ameaças internas durante o seu processo de

desenvolvimento.

2. Ameaças durante a operação (tanto internas como externas).

Qualquer sistema de software que roda sobre uma plataforma

conectada a uma rede corre o risco de ter suas vulnerabilidades

expostas durante a sua operação. O nível de exposição variará

dependendo de se a rede é pública ou privada, conectada a

Internet ou não. Quanto maior, mais aberta e descontrolada a

rede, mais exposto o software estará a ameaças externas. Mas,

mesmo se a rede é privada, pequena, e gerenciada com atenção,

esta é uma ameaça a partir de elementos não confiáveis na

comunidade de usuários autorizados do software (“pessoal

interno mal intencionado”).

Entre os exemplos de ameaças a que um sistema de informação pode estar

sujeito temos (Pfleeger , 2003):

1. Falhas do software ou hardware. Perturbações ambientais, incluindo

desastres naturais.

2. Erros de operação e administração.

3. Erros de projeto ou de implementação.

4. Ataques hostis (explorando os 2 pontos anteriores relacionados a erros)

Provavelmente jamais será possível a construção de uma lista definitiva de

todas as ameaças existentes contra os sistemas de informação, bem como a

implementação de proteção em relação a todas elas.

DBD



29

Uma abordagem interessante (figura 4) para entender ameaças e

vulnerabilidades está presente no trabalho de Pfleeger (2003) em que a água

representa uma ameaça para um compartimento e a rachadura na parede

representa uma vulnerabilidade.

Figura 4: Ameaça e vulnerabilidade (extraída de Pfleeger, 2003)

2.5 Relações entre Segurança da Informação, Seguran ça de Sistemas

de Informação, Segurança de Software

A informação é passiva por natureza (Goertzel et al., 2006). Ela não pode

executar ações, mas somente ter ações executadas sobre ela ou a partir dela. Não

se torna vulnerável por causa da forma como foi criada. A vulnerabilidade ocorre

quase sempre pela forma como é armazenada ou transmitida. Proteger a

informação como um ativo quanto à revelação não autorizada, modificação ou

destruição é o principal objetivo da segurança da informação (Goertzel et al.,

2006).

A segurança da informação estende a necessidade de proteção ao sistema de

informação que armazena, transmite, e processa a informação, representada na

forma de dado. Cada vez mais presentes e populares em nossa sociedade, sistemas

de informação são projetados para atender a uma grande variedade de importantes

serviços e aplicações presentes nos seguintes recursos computacionais:

• A Internet (serviços tais como transferência de arquivos, e-mail e World

Wide Web). Comércio Eletrônico

DBD



30

• Intranets (Uma parte da Internet composta por uma ou várias redes

locais)

• Computação móvel e ubíqua

A figura 5 a seguir representa um típico sistema de informação com os

recursos computacionais descritos acima:

Figura 5: Sistemas de Informação

Laudon (2001) define sistema de informação como um conjunto de

componentes inter-relacionados que coleta (ou recupera), processa, armazena e

distribui informações destinadas a apoiar a tomada de decisões e o controle de

uma organização. Segundo Goertzel et al. (2006), um sistema de informação

baseado em computador é constituído por pessoas, softwares, hardwares e

recursos (procedimentos e dados), o que torna a segurança em sistemas de

informação um assunto amplo que tem que capturar todos os aspectos relevantes

do sistema e de seu ambiente (Figura 6).

DBD



31

Figura 6: Diferentes dimensões de segurança do sistema (extraída de Goertzel et al.,

2006)

Devido às inúmeras possibilidades de interfaces de comunicação com o

software, uma pessoa tem a possibilidade de praticar atos inseguros, seja de

maneira intencional ou não, ameaçando a segurança do sistema. Implementar

segurança em sistemas de informação consiste em evitar ou minimizar desastres e

incidentes a partir de eventos inseguros. Isto pode ser tentado através de controles

e funções de seguranças necessários, implementados também por software, que

busquem garantir que a informação e os serviços por eles processados serão

protegidos (consistente com o objetivo do sistema de informação). Sistemas de

informação são dependentes da execução de autenticação e autorização de

usuários e controle de acesso para gerenciar quem está autorizado a usá-lo

enquanto mantém todas as entidades não autorizadas fora.

Alguns fatores contribuem para a exploração de um sistema de informação

(Goertzel et al., 2006):

1. O software como o link mais fraco. O número de ameaças

objetivando atingir especificamente o software está aumentando e a

maioria dos ataques a redes e aos sistemas de informação explora

vulnerabilidades de softwares. Segundo relatório do grupo Gartner

denominado “Now Is the Time for Security at the Application Level”

de dezembro de 2005 (Lanowitz, 2005), 75% dos ataques contra a

segurança de sistemas de informação ocorre no nível da aplicação.

DBD



32

2. O tamanho, a complexidade do software e as diversas interfaces em

um sistema de informação, dificultam a realização e a validação de

testes com suficiente abrangência.

3. Outsourcing e o uso de softwares não verificados aumentam os

riscos de segurança.

4. O reuso de softwares legados interfaceando com outras aplicações

em novos ambientes pode introduzir outras conseqüências não

analisadas, aumentando o número de vulnerabilidades. Os novos

riscos quase sempre não são entendidos.

O software é quase sempre uma parte de um sistema mais complexo e para

ser seguro significa que será executado neste contexto sem contribuir para um

incidente (acidente ou perda). O software necessita ser seguro por causa daquilo

que faz, incluindo como influencia outras entidades. O objetivo da segurança de

software é produzir software que não seja vulnerável a modificação não

autorizada, tampouco deve possibilitar a um usuário, mal intencionado ou não, ter

acesso a dados, podendo difundir, alterar ou mesmo destruí-los. Além disso, o

software não deve oferecer oportunidades para que venha a ser adulterado através

do uso de operações em princípio autorizadas, não permitindo o denial of service

durante a sua execução (Goertzel et al., 2006). Usar práticas de desenvolvimento

que aumentam a possibilidade dele ser seguro contribuirá para a capacidade do

sistema de informação em alcançar seus objetivos de segurança.

Leveson (2002), no contexto de software safety, afirma que, ao contrário do

que a maioria dos usuários e desenvolvedores imagina, funcionalidades de

softwares não necessariamente garantem segurança, mas podem contribuir para

alcançá-la. Segundo a autora, sendo o sistema inseguro é impossível que qualquer

software construído para este sistema seja seguro. A segurança é uma propriedade

que deve ser avaliada a partir do comportamento total de um sistema. Um bom

entendimento das propriedades essenciais de sistemas de informação é essencial

quando projetamos a segurança de um software. Incidentes podem ser causados

não só por um componente isolado deste sistema, mas também devido a uma má

interação entre os diversos componentes (humano, digital, eletromagnético, etc)

DBD



33

que compõem o sistema. O tratamento das interações desses componentes é um

dos maiores desafios para a avaliação da segurança.

Obviamente, existem sobreposições significantes entre os objetivos

principais da segurança da informação, da segurança de sistemas de informação e

da segurança de software. Contudo, estas sobreposições não devem ser mal

interpretadas quando afirmarmos que os requisitos de segurança de todas as três

entidades serão idênticos, ou que seus principais objetivos de segurança podem

ser alcançados pelos mesmos meios.

2.6 O que queremos em relação ao desempenho do soft ware quanto

à questão da segurança?

Queremos um software fidedigno, com execução previsível e conforme com

os seus requisitos de segurança, tanto como um componente individual quanto no

nível de segurança do sistema como um todo. Para isto, o software deve ser

resistente ou tolerante a ataques.

Para alcançar robustez, habilidade de detectar faltas de modo que as

conseqüências possam ser mantidas em um patamar aceitável, os componentes de

software e o sistema de informação como um todo devem ser capazes de

reconhecer padrões de ataques – nos dados de entrada ou sinais que eles recebem

a partir de entidades externas (pessoas ou processos) e resistir à entrada. A

resistência à padrões de ataques e faltas externas pode ser alcançada bloqueando

dados de entrada que contém os padrões de ataque e encerrando a conexão do

software com a entidade externa defeituosa e hostil.

Tolerar falhas resultantes de ataques bem-sucedidos ou de faltas externas

intencionais, significa manter a continuidade da operação do software apesar das

falhas. Freqüentemente a continuação da operação somente pode ser alcançada

por gerenciamento dos processos críticos. Quando o software entra um modo de

falha, processos não críticos são terminados de forma ordenada, com uma

condizente explicação para o usuário dos motivos do seu encerramento, enquanto

os processos críticos para o funcionamento de sistemas são mantidos com um

DBD



34

aceitável nível de funcionamento. Dependendo da capacidade de tratamento de

exceção do software, a operação continuada somente é possível até um certo nível

de operação degradada, para depois o software terminar completamente a

operação (falha severa).

O que o software seguro nunca deve fazer é simplesmente travar (Goertzel

et al., 2006). Nenhuma falha deve ser permitida sem que primeiro sejam apagados

todos os dados da memória temporária do computador, sinalizando neste

momento para todos os usuários a falha. Após estes passos, o software deve então

liberar de forma segura todos os recursos, finalizando os processos de software.

Isto é o que é entendido por “fail safe” , que reduz a possibilidade de um atacante

ganhar acesso de leitura a dados sensíveis em memória temporária.

A recuperabilidade do software, habilidade em ser rapidamente reposto em

operação fidedigna após a ocorrência de uma falha (ataque bem sucedido), é uma

forma de capacidade de sobrevivência que tem provado ser possível de ser

atingida somente ao nível do sistema como um todo (Goertzel et al., 2006). Para

alcançar o poder de recuperação de ataques, os sistemas de software devem ser

capazes de recuperação a partir de qualquer falha resultante de um ataque bem-

sucedido ao software (incluindo faltas externas intencionais) e reassumir a sua

operação em um nível mínimo aceitável em um período curto, até finalmente

conseguir restaurar todo o serviço no nível de performance especificado. A

recuperação do sistema de software deve ocorrer tão logo a fonte de ataque tenha

sido isolada e bloqueada, e os danos resultantes tenham sido encerrados.

Para conseguir um software com este nível de qualidade, o investimento em

segurança, aqui considerando desenvolvimento do software e o estabelecimento

do ambiente de operação, não é pequeno. Além das preocupações tradicionais do

desenvolvimento de software com qualidade assegurada, as equipes de

desenvolvimento e operação dos sistemas se vêem obrigadas a se preocupar com

conceitos e aspectos que não estão acostumadas a trabalhar. Para o cliente isto é

ruim, pois acaba sendo impactado no prazo e no custo da solução e, muitas vezes,

acaba não tendo um software com qualidade assegurada em relação à segurança.

Segurança esta que, na maioria dos casos, ele mesmo não entende quanto à

DBD



35

necessidade de ser incorporada à sua solução na maioria dos casos. Além disso, os

métodos e práticas atuais de Engenharia de Software têm tido sucesso limitado em

gerenciar a complexidade intelectual de projetar e implementar software seguro.

Normalmente, no projeto de sistemas de software, conceitos de segurança são

endereçados muito tardiamente ao invés de ser uma prática integrada ao projeto

como um todo, principalmente nas fases de especificação e arquitetura. Isto

significa que os sistemas de software, de qualquer tamanho e complexidade,

acabam tendo muitas vulnerabilidades passíveis de serem exploradas.

DBD



36

3 Métricas de Segurança de Software

Independente do modelo de avaliação da segurança de software, esta

dissertação busca um critério para medir segurança de softwares antes que estes

sejam colocados em produção. Conseguimos até com certo sucesso medir

insegurança, porém o que estamos buscando é como medir objetivamente se o

sistema é potencialmente seguro ao analisarmos o seu projeto, código, testes, etc,

isto é, antes de ser colocado em uso.

Devanbu (2000) declara que segurança é como beleza, depende do

observador. O entendimento do que é belo varia de observador para observador.

Apesar desta afirmação, métricas de segurança de software devem ser usadas para

avaliar a segurança, eliminando a advinhação e estimativas subjetivas sobre

segurança. O princípio de que uma atividade não pode ser gerenciada se ela não

pode ser medida também se aplica à segurança.

A prática de medição vem sendo reconhecida há muito tempo como uma

atividade crítica para o desenvolvimento de sistemas com qualidade assegurada.

Segurança necessita de meios de avaliação comparáveis a aqueles empregados em

outros atributos de qualidade de software, como por exemplo manutenibilidade,

que é um atributo de qualidade bem entendido e que pode ser quantitativamente

estimado ao avaliarmos propriedades tais como o tamanho e a complexidade.

Este capítulo tem como objetivo introduzir o tema métricas de segurança de

software.

3.1 Medição de Software

A medição pode ser definida como um processo pelo qual números ou

símbolos são associados a atributos de entidades do mundo real, com o objetivo

DBD



37

de caracterizá-la de acordo com um conjunto de regras claramente definido

(Fenton, 1995). Então, a medição requer: Entidades, Atributos e Regras.

Exemplos de entidades incluem: produtos, processos, recursos, artefatos,

atividades, agentes, organizações, ambientes e restrições. Entidades também

podem ser conjuntos ou coleções de outras entidades.

Atributos são características ou propriedades de entidades. Assim como uma

pessoa (entidade) pode ser descrita por características tais como altura, cor dos

olhos, sexo, idade e anos de experiência, entidades de software podem ser

descritas por atributos tais como tamanho, custo, tempo, esforço, tempo de

resposta, taxa de transações, número de defeitos encontrados, etc. Um processo de

medição de segurança precisa capturar os atributos relevantes de um sistema,

antes de realizar uma avaliação de segurança.

As regras definem como a medição será realizada. Um processo de medição

contém todos os passos a serem seguidos para a realização de medições em uma

organização.

A medição é um processo que produz como resultado um conjunto de

medidas. Uma medida constitui um mapeamento entre um atributo empírico e

uma escala matemática. Unidades de medida são estabelecidas para convencionar

como esses atributos devem ser registrados (Park et al., 1996).

Uma métrica consiste em uma unidade de medida e a correspondente

medição (definição + processo) utilizada para medir ou avaliar uma determinada

propriedade de uma entidade.

Um processo de medição pode ser baseado em instrumentos (Medir), pode

utilizar julgamento humano baseado em algum critério definido (Avaliar) ou

utilizar julgamento humano sem um critério definido (Julgar). Segurança deve ser

medida, pode ser avaliada, mas nunca deveria ser somente julgada.

Segundo Park et al. (1996), uma organização de software tem bons motivos

para estabelecer um programa de métricas de software. Através das métricas a

organização pode:

DBD



38

• Conhecer seus processos, produtos, recursos, ambientes e estabelecer

baselines para comparar com avaliações futuras.

• Avaliar se a situação de uma determinada entidade em relação às metas

pré-estabelecidas está com o seu desempenho conforme esperado.

Também avaliamos para verificar as metas de qualidade e para medir o

impacto das melhorias de processos e tecnologia sobre processos e

produtos.

• Prever para poder melhor planejar. A medição serve para obter

entendimento do relacionamento entre processos e produtos e construir

modelos a partir destes relacionamentos. Projeções e estimativas

baseadas em dados históricos também nos ajudam a analisar riscos e

fazer comparações de projetos e custos.

• Melhorar a organização ao coletar informações quantitativas que

auxiliam na identificação de obstáculos, causas raiz, ineficiências, e

outras oportunidades de melhoria da qualidade do produto e da

performance do processo, facilitanto a melhoria nessas atividades ao

aplicar ações corretivas, baseadas em medições observadas.

Existem poucos trabalhos sobre métricas de segurança, especificamente em

Engenharia de Software (Langweg, 2006). Um pouco de atenção até tem sido

dada a métricas focadas na segurança operacional de sistemas de informação em

seu ambiente de produção, mas de uma forma geral os trabalhos ainda são poucos.

3.2 Métricas de Segurança de Software

Métricas de segurança são ferramentas para que profissionais de segurança

da informação avaliem os níveis de segurança de seus sistemas, produtos e

processos, dando a possibilidade de tratar as questões de segurança que estão

enfrentando. Métricas podem ser úteis para identificar vulnerabilidades em

sistemas e avaliar os seus riscos, orientando as ações corretivas de maior

prioridade, aumentando o nível de maturidade sobre segurança na organização.

DBD



39

Com o conhecimento de métricas de segurança, um profissional de segurança da

informação poderia tentar responder a perguntas como:

• As aplicações estão hoje mais, ou menos, seguras do que antes?

• Como nós saberemos quando nossos sistemas estarão seguros?

• Estamos nós seguros o suficiente?

• Treinar em segurança realmente faz diferença?

As métricas também podem ser usadas para justificar e direcionar futuros

investimentos em segurança e também facilitar a prestação de contas dos

governantes e melhorar a confiança dos clientes. Isto porque o investimento em

segurança, aqui considerando desenvolvimento de software e ambiente de

operação, não é pequeno. Além das preocupações tradicionais no

desenvolvimento de software com qualidade assegurada, as equipes de

desenvolvimento e operação dos sistemas se vêem obrigadas a se preocupar com

conceitos que não estão acostumadas a trabalhar. Isso requer investimento em

treinamentos e contratação de consultoria especializada.

Distinguir métricas significativas é crítico para o desenvolvimento de um

programa de métricas de segurança efetivo, principalmente para os programas

com responsabilidade direta com a administração da segurança e para aqueles que

tratam diretamente com assuntos e interesses da administração da organização. As

métricas verdadeiramente úteis indicam o grau para o qual as metas de segurança,

como confidencialidade dos dados, está sendo alcançado e elas orientam ações

que devem ser tomadas para melhorar o programa de segurança de uma

organização como um todo.

Devido à impossibilidade de se medir diretamente o nível de segurança de

um software, sem considerar o sistema de informação em que está inserido,

diferentes fatores e conseqüências que têm efeito sobre este nível de segurança

devem ser avaliados. Para que isto seja possível, as métricas de segurança devem

ser obtidas em níveis diferentes dentro de uma organização, podendo ser mais

detalhadas, quando coletadas ao nível de sistema de informação, ou ser

DBD



40

acumuladas e desdobradas em níveis mais altos progressivamente, dependendo do

tamanho e complexidade de uma organização. Seja qual for o grau de

detalhamento da métrica de segurança, elas devem estar fundamentadas em metas

e objetivos de desempenho de segurança da organização (ITSEC, 1991).

3.3 Classificações de Métricas de Segurança encontr adas na

Literatura

A definição e escolha das métricas de segurança não é uma tarefa muito

simples. Muitas vezes, o termo métrica de segurança é confuso e ambíguo em

muitos contextos de discussão sobre segurança da informação. No ano de 2001 foi

realizado um evento intitulado Workshop on Information Security System Scoring

and Ranking (Henning, 2001) que tinha como principal objetivo discutir sobre o

assunto métricas para segurança da informação de produtos e tecnologia de

informação numa tentativa de minimizar estes problemas. Neste Workshop foi

proposta uma classificação para métricas de segurança em 3 categorias: técnico,

organizacional e operacional (Figura 7). Esta classificação tem sido adotada na

maioria dos trabalhos sobre métricas de segurança de software desde então.

Figura 7: Classificação das métricas de software encontradas em HENNING(2001)

Na categoria técnica estão incluídas as métricas empregadas para avaliar a

qualidade do software e do hardware. Estas métricas são usadas para descrever

DBD



41

e/ou comparar objetos técnicos. (exemplo: algoritmos, produtos ou modelos).

Métricas organizacionais avaliam processos e programas de segurança. Métricas

operacionais são utilizadas para avaliar sistemas e práticas operacionais em

relação aos princípios de segurança.

Neste mesmo Workshop Deborah Bodeau do MITRE sugeriu uma

caracterização interessante para métricas de segurança da informação. Ela

apresentou uma abordagem para métricas de segurança de software que leva em

consideração o tipo de objeto que será mensurado, o porquê da necessidade de

medi-los, e para quem estamos medindo. Sua caracterização está representada na

Figura 8 a seguir (Henning, 2001):

Figura 8: Caracterização de Métricas de Software (extraída de HENNING, 2001)

3.4 Critérios de Avaliação

Encontramos na literatura critérios qualitativos e quantitativos para a

avaliação de um software em relação à segurança. Segundo Bayuk (2000), os

modelos de avaliação de segurança se enquadram em uma das cinco categorias a

seguir: Avaliação de segurança a partir de boas práticas do mercado (Auditoria

externa), Avaliação de segurança a partir de práticas de segurança definidas

internamente (Auditoria interna), Modelo de Maturidade da Capacitação, Análise

de riscos e eliminação de defeitos.

DBD



42

3.4.1 Modelo de avaliação de segurança a partir de boas práticas

do mercado (Auditoria externa)

O modelo de avaliação de segurança a partir de boas práticas do mercado

(auditoria externa) assume que existem “melhores práticas” disponíveis sobre

como proteger um determinado tipo de ambiente ou produto. Este modelo mede a

segurança ao comparar o nível de controle gerencial sobre o ambiente do sistema.

O resultado final é uma lista de fragilidades de segurança, ou defeitos, que devem

ser corrigidos para que os sistemas operem em um nível aceitável de riscos de

segurança. Enquadram-se neste tipo de avaliação o ITSEC, TCSEC, ISO 9000,

ISO 17799, Common Criteria, COBIT, etc.

O marco inicial da avaliação de segurança ocorreu quando o governo norte-

americano publicou a norma TCSEC – Trusted Computing System Evaluation

Criteria (DOD, 85), também conhecido como Orange Book, para a avaliação de

segurança de dispositivos de segurança (criptografia, firewalls, etc.). Com relação

a software, o foco do TCSEC (DOD, 85) consistia na definição dos requisitos de

segurança necessários para a garantia da confidencialidade das informações. Na

época, o grande cliente comprador de segurança era o governo dos Estados

Unidos e o sigilo de informações sensíveis era o grande requisito que deveria ser

atendido.

Em 1991, uma comissão européia formada por França, Alemanha, Holanda

e Reino Unido, publicou uma norma para certificação de segurança intitulada

ITSEC – Information Technology Security Evaluation Criteria (ITSEC, 1991),

baseada no TCSEC (DOD, 85), tornando-se depois de fato um padrão europeu

voltado tanto para a avaliação de produtos como de sistemas. Diferente do

TCSEC, o ITSEC separava funcionalidade de segurança de garantia de segurança.

Em 1992 o National Institute of Standards and Technology (NIST) publicou

o Minimum Security Functionality Requirements for Muiti-user Operating

Systems (MSFR, 1992) que tinha como objetivo apresentar um conjunto mínimo

de requisitos funcionais de segurança para sistemas operacionais multi-usuário,

especialmente aqueles relacionados com o a garantia da qualidade do processo de

desenvolvimento dos fornecedores de software nos Estados Unidos. Estes

DBD



43

requisitos eram baseados no TCSEC e, futuramente, seriam parte do novo o novo

Federal Information Processing Standard (FIPS), que substituiria o TCSEC

(Orange Book).

Em 1993, o governo canadense juntou as normas TCSEC e ITSEC e criou o

Canadian Trusted Computer Product Evaluation Criteria (CTCPEC,1993) com o

mesmo objetivo.

Com tantas normas de certificação, as empresas multinacionais acabaram

tendo problemas ao ter que certificar seus produtos perante cada órgão de

governo, o que gerava enormes custos de certificação. Para resolver este

problema, os países envolvidos na definição destas normas encaminhou para a

ISO uma proposta de consolidação de todos estes critérios para avaliação de

segurança em um único critério. A ISO acatou a idéia e posteriormente apresentou

a Norma ISO 15.408:1999, dando-lhe o nome de Common Criteria. Os sete

órgãos de governo responsáveis pelos critérios comuns (The Common Criteria

Project Sponsoring Organizations) continuam proprietários do Copyright, porém

cederam os direitos de uso para a ISO (figura 9).

Figura 9: Histórico da Criação do Common Criteria. Figura extraída do artigo “Computer

Security Criteria: Security Evaluations and Assessment” de 2001 da Oracle.

DBD



44

Assim como os padrões que lhe deram origem, o Common Criteria tem por

objetivo ser a base para avaliação das propriedades de segurança dos sistemas de

computação. O Common Criteria permite comparações entre produtos fornecendo

um conjunto de requisitos de segurança e medidas de garantia de segurança

aplicadas a eles durante a avaliação. Ao final da avaliação de dois produtos, é

possível comparar as funções de segurança e os níveis de garantia de segurança

fornecido por ambos, de forma a possibilitar a escolha do produto que mais se

adequa às necessidades da organização. Logo, o mais importante é que a norma

ISO 15408 define diferentes níveis de confiança e garantias na avaliação (do

EAL0 ao EAL7). Ela é formada por um conjunto de três volumes, onde o primeiro

discute definições e metodologia, o segundo lista um conjunto de requisitos de

segurança e o terceiro descreve as metodologias de avaliação.

Diferentemente da ISO 17799, o Common Criteria é uma norma para

definir e avaliar requisitos de segurança de sistemas e não de organizações,

enquanto que a ISO 17799 é uma norma que aborda a segurança da informação da

organização.

Todas essas normas são usadas para avaliações qualitativas de segurança.

3.4.2 Modelo de avaliação de segurança a partir de práticas de

segurança definidas internamente (Auditoria interna )

O modelo de avaliação de segurança a partir de práticas de segurança

definidas internamente (Auditoria interna) assume que a organização adota um

conjunto de controles definidos internamente (política de segurança) com o intuíto

de proteger os ativos de sistemas de informação. A avaliação fornecer então

informações (medidas) que comprovam ou não a eficácia dos controles de

segurança adotados. A comparação é realizada com auditorias de anos anteriores

ou com ambientes de TI similares na organização. Esta é uma abordagem

qualitativa de segurança.

DBD



45

3.4.3 Modelo de maturidade da capacitação

Este modelo, em uma abordagem qualitativa, assume que organizações

devem se comprometem em proteger seus ambientes adotando formalmente um

processo que garanta esta segurança. Conforme as práticas são estabelecidas e

cumpridas, o nível de maturidade em segurança da organização aumenta. O SSE-

CMM (System Security Engineering Capability Maturity Model) avalia um

processo de gerenciamento de segurança, atribuindo um nível de maturidade (de 1

a 5), que representa o quão bem a organização cumpre todas as práticas.

3.4.4 Modelo de Análise de Riscos

Análise de riscos, em suas diferentes formas, pode ser considerado um

modelo útil de medição de segurança. O modelo de análise de riscos mais

empregado assume que existe um fator “valor monetário” que representa o quanto

deverá custar para proteger um ativo. A partir da análise de riscos, calcula-se o

quanto se gastar para que o risco não ocorra. O modelo assume que se nenhum

dinheiro é gasto em segurança, nenhuma segurança será alcançada. Outras

abordagens podem ser também usadas. (horas sem operação, reputação, etc).

3.4.5 Modelo de Eliminação de Defeitos

Esta é uma abordagem quantitativa de segurança.que assume a existência de

um parâmetro mensurável, inerente ao ambiente de tecnologia da informação, que

reflete o seu perfil de segurança. Quanto mais próximo do “zero defeitos”, mais

seguro o software. Por exemplo, no código contamos o número de bugs

encontrados ( ou corrigidos ao partir de uma versão para a próxima) e no nível de

sistema contamos o número de vezes em que uma versão de um sistema é

mencionada nos avisos do CERT®, Computer Emergency Response Team, nos

boletins de segurança da Microsoft ou no Mitre (Common Vulnerabilities and

Exposures - CVEs).

DBD


4 Avaliação Quantitativa de Segurança de Sistemas

Neste capítulo são descritos diferentes métodos para a avaliação quantitativa

de segurança de sistemas existentes na literatura. A ordem em que os métodos são

apresentados considera o ano em que foi publicado. Com isso, podemos ter uma

idéia da evolução dos métodos de avaliação quantitativa de segurança.

4.1 Esforço despendido por um atacante

Brocklehurst e co-autores (Brocklehurst et al., 1994) desenvolveram uma

teoria com a intenção de trabalhar métricas de segurança operacional de forma

similar àquelas que hoje são empregadas para medir a confiabilidade de software

e de hardware.

A confiabilidade do software é a probabilidade de um sistema operar sem

apresentar defeitos, sob certas condições, em um determinado intervalo de tempo.

Expressamos a confiabilidade em uma escala de 0 a 1. Um sistema altamente

confiável terá uma medida de confiabilidade próxima de 1, e um sistema que não

é confiável terá uma medida próxima de zero. A confiabilidade é medida durante

o tempo de execução e não durante o tempo real (ou seja, o tempo medido pelo

relógio), de modo a refletir mais precisamente o uso do sistema. Uma função de

densidade de probabilidade f do tempo t, escrita como f(t), que descreve a nossa

compreensão sobre a freqüência esperada com que o software falhará, pode ser

usada quando modelamos um defeito de software. Nem toda função de densidade

é uniforme, e um dos problemas que torna difícil entender e medir a

confiabilidade é obter o comportamento da falha em uma função apropriada de

densidade de probabilidade. Isto é, podemos definir uma função f(t) e utilizá-la

para calcular a probabilidade de um componente de software falhar, em

determinado intervalo de tempo [t1, t2]. Como essa probabilidade é a área abaixo

DBD


Avaliação Quantitativa de Segurança de Sistemas

47

das curvas entre os limites do intervalo, a probabilidade de um defeito entre t1 e t2

é

∫t2

t1 f(t) dt

Especificamente, a função de distribuição F(t) é o valor dessa integral no

intervalo de 0 até t. F(t) é a probabilidade de que o software falhe antes do tempo

t, e definimos a função de confiabilidade C(t) como sendo 1 – Fi(t), que é a

probabilidade de que o software funcione apropriadamente até o tempo t.

De forma análoga à medição da confiabilidade do software, agora considere

a segurança de um sistema em um determinado instante de tempo. Segundo

Brocklehurst e co-autores (Brocklehurst et al., 1994), se aceitarmos que esforço

em segurança pode ser representado da mesma forma como é feita em

confiabilidade (em inglês: reliability), então, é razoável considerar a distribuição

do “esforço para vencer uma brecha” como análoga à distribuição de tempo para

falha de confiabilidade. Assumindo que podemos obter uma variável apropriada

E, variável randômica, para representar este esforço, a segurança operacional

poderia, em princípio, agora ser expressa em termos de probabilidade: por

exemplo, significar o esforço para a próxima brecha de segurança, probabilidade

de resistir com sucesso a um ataque envolvendo um determinado gasto de esforço,

etc. Considerando, então, a distribuição de probabilidade do esforço requerido

(variável randômica), E, para a próxima violação do sistema. A função segurança,

por analogia com a função de confiabilidade, é dada por:

C = C(e) = Probabilidade (E > e)

A função distribuição e a função distribuição de probabilidade (se existe) de

esforço para a próxima violação são respectivamente:

F(e) = 1 – C(e), f(e) = F’ (e)

A taxa de violações de segurança (número esperado de violações em um

determinado período de tempo) pode ser então definida como v(e) = f(e)/C(e)

DBD



48

Vantagens do método

1. É possível capturar informações sobre o esforço que

determinados atacantes fazem para violar um sistema.

2. Talvez seja possível definir padrões de ataques.

3. Pode ser feito um estudo sobre o esforço despendido com

alguns tipos de vulnerabilidades conhecidas.

Desvantagens do método

1. A técnica é aplicada depois que o software é desenvolvido.

2. Atacantes têm habilidades e experiência diferentes. Não está

claro ser possível determinar uma medida de esforço que

possa ser associada ao sistema.

3. Muitas vezes um ataque à segurança não é reconhecido. O

processo de medição pode falhar para vulnerabilidades

desconhecidas.

4.2 O Índice de Vulnerabilidade do Sistema

Alves-Foss e Barbosa (1995) apresentam uma abordagem para identificar e

quantificar vulnerabilidades de sistemas computacionais ao introduzir um método

de avaliação denominado Índice de Vulnerabilidade do Sistema, IVS. O IVS é

formulado para avaliar fatores que podem afetar enormemente o estado de

segurança do sistema. Ações de super usuários2, bem como indícios de um

potencial estado de insegurança, servem como base para a escolha destes fatores

relevantes para a segurança. Estes fatores são divididos em três categorias:

2 Super usuário - A conta super usuário, normalmente chamada root, é usada para configurar e

facilitar a administração do sistema, e não deve ser usada para tarefas cotidianas como envio e

recebimento de e-mail, exploração geral do sistema, ou para programação.

DBD



49

• Características do sistema - configurações do software e hardware que

influenciam a segurança do sistema, mas não são facilmente modificadas

devido ao custo, as complexidades ou aos fatores externos. Como exemplos

destes fatores podemos ter:

o Vulnerabilidades de segurança física

o Senhas antigas

o Atualização do sistema operacional em relação a bugs de segurança

• Atos potencialmente negligentes - toda ação que degrada a segurança quando

omitida, ou impropriamente empregada. Alguns exemplos destes fatores são:

o Número de indivíduos com privilégios de super usuário

o Usuários com senhas fracas

o Contas inativas

• Atos potencialmente malevolentes - caracterizam ações que podem

enfraquecer ou violar a segurança, inclusive toda aquela que tenta enganar ou

vencer os mecanismos de segurança. Como por exemplo:

o Objetos com o mesmo nome de comandos do sistema ou

programas.

o Super usuários estranhos.

O Índice de Vulnerabilidade do Sistema é uma medida entre 0 e 1 que indica

a vulnerabilidade de um sistema em relação a condições adversas que podem levar

a uma exploração de um sistema em um determinado momento. Para entender o

significado do IVS, devemos começar definindo que ele (o índice) não significa.

Enquanto o IVS é uma medida entre 0 e 1 (quanto mais próximo de 1, maior é o

nível de vulnerabilidade), não deve ser interpretado como um valor de

probabilidade estatística. Portanto, um IVS de 0.84 não deve ser entendido como a

probabilidade de um sistema ser invadido por pessoal não autorizado. Este valor

serve, simplesmente, para alertar que condições para a exploração existem, pois se

DBD



50

invasores explorarem técnicas comuns, tornar-se-ão conscientes do estado de

vulnerabilidade do sistema.

Segundo os autores, os fatores que podem afetar o estado de segurança do

sistema são avaliados e combinados, através do uso de regras especiais, para

fornecer uma medida da vulnerabilidade do sistema. Para cada regra IVS, definida

a partir dos fatores que afetam a segurança, é atribuído um valor que responde a

seguinte questão: “Até que ponto a presença deste fator, torna o sistema

vulnerável para a exploração?”. Cada regra, então, pode ser definida da seguinte

forma: Se antecedente Então Conseqüente, por exemplo, Se “o sistema

operacional não for atualizado quanto a bugs de segurança já informados” Então o

nível de vulnerabilidade do sistema é 0,6. Para chegar ao valor final do indicador

de vulnerabilidade do sistema, devem ser combinados os índices de segurança de

todas as regras IVS aplicáveis ao fator considerado.

Demonstrar a vulnerabilidade de um software com valores numéricos entre

0 e 1 é inútil sem uma interpretação apropriada. Portanto, os autores introduzem

uma classificação de valores de IVS em quatro grupos, cada um deles

representando diferentes espectros de vulnerabilidades:

• Valores entre 0 e abaixo de 0,15 indicam uma baixa vulnerabilidade.

• Valores entre 0,15 e menores do que 0,3 indicam um nível moderado de

vulnerabilidades.

• Um valor entre 0,3 e menor do que 0,6 é considerado suficiente para ser

explorado por classes de ataques mais comuns.

• Um Valor igual ou acima de 0,6 é considerado extremamente vulnerável.


1. A vantagem deste método se situa na abstração do problema

que o torna útil para avaliar vulnerabilidades em sistemas

operacionais e implementações de software e hardware

distintas.

DBD



51

2. Um sistema especialista pode ser implementado a partir das

regras


1. A técnica é aplicada depois que o software foi desenvolvido.

2. Avaliadores diferentes podem chegar a resultados diferentes.

3. O método é muito dependente da experiência do avaliador.

4. É difícil avaliar o quanto um elemento influência a segurança

de outro elemento.

4.3 MTTI – Minimum-Time-To-Intrusion

Voas e co-autores (Voas et al., 1996) propõem uma métrica de tolerância a

falhas denominada minimum-time-to-intrusion, MTTI, para avaliar

quantitativamente segurança e a capacidade de resistência de sistemas de

informação. Esta métrica é baseada no período de tempo esperado para uma

invasão simulada poder acontecer.

Uma métrica quantitativa é computada para determinar se as ameaças

simuladas minam a segurança do sistema definida pelos usuários, conforme a

especificação do programa. A abordagem do método, chamada de Análise de

Vulnerabilidade Adaptativa (AVA), exercita o software, simulando a entrada de

ataques maliciosos e não-maliciosos que se incluem em várias classes de ameaças

conhecidas. Esta abordagem permite conhecer antecipadamente se sistemas estão

seguros em relação a um conjunto pré-definido de ameaças T = {t1, t2,..., tn},

constituído por ameaças recorrentes mais comuns de serem encontradas. O

conjunto de ameaças T é aberto para permitir a inclusão de novas ameaças,

podendo variar conforme a necessidade do avaliador. A possibilidade de

existência de vários conjuntos de ameaças diferentes torna este método adaptativo,

conforme o entendimento dos autores.

Este método não fornece uma métrica absoluta, tal como MTTF (Mean

DBD



52

Time to Failure), mas ao invés disso o método fornece uma métrica relativa, que

permite ao usuário comparar a segurança de diferentes versões do mesmo sistema

ou comparar com funcionalidades similares de outros sistemas.

A Análise de Vulnerabilidade Adaptativa (AVA) é um algoritmo de análise

de software adaptado a partir da extensão de uma técnica de análise de propagação

denominada em inglês Extended Propagation Analysis (EPA), utilizada na

avaliação de segurança (em inglês:safety) de softwares críticos. A simulação de

ameaças no AVA é efetuada através de uma combinação de injeção de faltas e

geração de casos de testes. A detecção de invasão é efetuada usando uma

linguagem de especificação de invasões baseada em predicados (PRED).

Baseado na modelagem de vulnerabilidades, entradas do programa e

invasões, o algoritmo AVA determina a proporção de invasões que ocorrem como

um resultado de injeção um programa com ameaças simuladas. O número

resultante deste algoritmo pode ser usado para calcular à métrica de segurança.

Seja P o programa, x representa um valor de entrada deste programa, Q

representa a distribuição provável da curva normal, Q' denota o inverso da

distribuição provável da curva normal usada e l corresponde a uma localização de

programa em P.

Algoritmo AVA:

1. Para cada localização apropriada l em P,

execute passos 2-7.

2. Inicialize a variável conta com zero.

3. Randomicamente selecione uma entrada x ou seqüência de Q ou !Q, e

Se P parar sobre x após um período de tempo fixado t, encontre o

estado dos dados correspondentes criados por x imediatamente

depois da execução de l.

Chame este estado dos dados de Z.

DBD



53

4. Altere o valor experimentado da variável a encontrada em Z criando Zi,

e Execute o código seguinte em Zi. A maneira pela qual a é alterado será

representativo da classe de ameaça de T que é desejada.

5. Se a saída de P satisfaz PRED, incremente conta.

6. Repita os passos 3-5 n vezes, onde n é o número de entradas de casos de

testes.

7. Divida conta por n produzindo ψalPQ, uma avaliação de

vulnerabilidade para cada linha l. Isto significa que (1 – ψalPQ) é a

avaliação de segurança que foi observada, dados P, Q e T.

Os primeiros dois passos do algoritmo são básicos. AVA é uma

metodologia baseada em código fonte, significando que instrumentação é

colocada entre linhas de comando específicas (que chamamos “localização” no

código). Ou um sistema automatizado que implementa o algoritmo (se ele é

inteligente suficiente), ou o usuário deve informar ao sistema que localizações são

relevantes para a injeção de faltas. Deste modo, o primeiro passo é localizar aonde

a injeção vai ocorrer. O passo seguinte, um contador é inicializado com zero,

porque desejamos observar quantas intrusões de segurança ocorrem devido às

ameaças simuladas que o protótipo empreendeu para uma localização particular

“l”.

Diferente da maioria das métricas de software atualmente em uso, nossa

medição de avaliação de software AVA não considera a estrutura do software,

mas particularmente o seu comportamento. Então o algoritmo seleciona casos de

testes sob quais os programa rodará, visto que necessitaremos executar o software

com o objetivo de quantificá-lo estatisticamente o seu comportamento. Esta

amostra de entradas é executada no passo 3. As entradas podem surgir de

diferentes esquemas de testes que são mais prováveis para disparar uma intrusão

bem sucedida: eventos raros (com respeito para o perfil operacional), seqüências

de entradas conhecidas que não são usuais ou prováveis de serem tratadas,

entradas totalmente randômicas, ou mesmo que o perfil operacional do sistema. O

quarto passo executa o estado de “corrupção” atual do programa ou mutação

DBD



54

sintática do código (o passo da injeção de faltas). Uma vez que a falta é injetada

no passo 4 é executado durante a fase de análise, o programa tem sido

“derrubado” em alguma maneira. O passo 5 determina se o problema forçado no

passo 4 ocasiona o programa a produzir um evento de saída que satisfaz nossa

definição do que constitui uma violação de segurança. Nesse caso o contador é

incrementado de 1. Para prover uma estimativa estatística de vulnerabilidades,

passos 3, 4 e 5 são repetidos (passo 6). Esta estimativa é calculada no passo 7.

A métrica minimum time to intrusion (MinTTI) é baseada na informação

produzida no algoritmo acima. Duas considerações devem ser feitas:

1. A métrica pode ser ajustada para qualquer unidade de tempo desejada.

2. O maior valor avaliado, a maior segurança, será prevista para o

sistema.

A Figura 10 fornece uma visão geral do protótipo AVA. Os três principais

componentes do sistema (injeção de falhas, geração de caso de teste, especificação

da invasão) fornecem um esquema para determinar o valor das métricas de

segurança.

Figura 10: Visão Geral do protótipo AVA (extraída de .Voas et al., 1996)

DBD



55

A métrica MTTI, definida como o intervalo de tempo médio antes que uma

invasão ocorra, é baseada nos casos de entrada em Q (e seu inverso), nas classes

de injeção de falhas que são usadas e nas classes de invasões definidas nos

predicados (PRED). O seu calculo é demonstrado na figura 11 a seguir:

Figura 11: Métrica MTTI. M é o número de localizações aonde o AVA foi aplicado

(extraída de .Voas et al., 1996)

O tempo mínimo para a invasão (MinTTI) é o período de tempo mais curto

previsto antes que qualquer invasão definida em PRED ocorra. O seu cálculo é

demostrado na figura 12 a seguir:

Figura 12: Métrica MinTTI (extraída de .Voas et al., 1996)


1. A técnica pode ser modificada para simular novas classes de

ameaças sem atrapalhar o processamento das classes antigas.

2. A técnica pode ser customizada pelo usuário para classes de

invasões específicas sem a necessidade de qualquer mudança na

forma de avaliação.

3. Determina de forma dinâmica o comportamento do sistema em

relação à segurança.

DBD



56

4. Produz informações importantes para a melhoria do processo de

desenvolvimento.

5. Os mesmos parâmetros de análise produzem os mesmos

resultados após um certo tempo.

6. Pode ser usada em conjunto com testes de penetração e outras

técnicas utilizadas para a melhoria da qualidade do software.

Desvantagens do método:

1. Está baseada em modelos de injeção de falhas e dessa forma

qualquer resultado será dado em relação às classes de ameaças

informadas. Novas classes de ameaças com um MinTTI menor

do que qualquer ameaça anterior resultará em um nível de

segurança superestimado.

2. A técnica é aplicada depois que o software foi desenvolvido.

3. A técnica pode ser usada contra o próprio sistema caso um dos

desenvolvedores tenham acesso às informações internas durante a

execução do algoritmo AVA.

4.4 Avaliação Quantitativa para Monitorar a Seguran ça

Operacional

Ortalo et al. (1999) modelam o sistema como um grafo de privilégios3, que

exibe suas vulnerabilidades e estima o esforço despendido por um atacante para

conseguir um ataque bem-sucedido, a partir da exploração de tais

vulnerabilidades. O cálculo da métrica quantitativa de segurança é realizado a

considerando a dificuldade que um possível atacante teria em explorar estas

vulnerabilidades e vencer os objetivos de segurança do sistema.

3 Um privilégio pode ser entendido como uma concessão cedida a um ou mais usuários,

possibilitando a utilização de funcionalidades no software, segundo o seu nível de permissão.

DBD



57

A Modelagem de Segurança do Sistema

Em um grafo de privilégios, um nó X representa um conjunto de privilégios

concedidos a um usuário ou a um grupo de usuários. Uma aresta em um grafo de

privilégios representa uma vulnerabilidade. Por exemplo, sejam X e Y dois nós

em um grafo de privilégios, uma aresta de um nó X para um nó Y representa uma

vulnerabilidade que permite a um usuário que possui os privilégios de X obter os

privilégios do nó Y (Figura 13).

Figura 13: X obtém os privilégios do nó Y

Três classes de arestas (vulnerabilidades) podem ser encontradas em um

grafo de privilégios:

1. Uma vulnerabilidade representada por uma aresta pode ser

uma falha de segurança, tal como uma senha facilmente

descoberta ou uma proteção ruim para diretórios e arquivos,

que permita a implantação de um Cavalo de Tróia.

2. Uma vulnerabilidade não é necessariamente uma falha de

segurança. A vulnerabilidade pode ocorrer a partir do uso

durante um ataque de qualquer recurso ou funcionalidade

designada para melhorar a segurança. A segunda classe de

arestas representa os recursos ou funcionalidades utilizadas

para melhorar a segurança do sistema que podem ser

utilizados contra a segurança do próprio sistema.

3. A terceira classe de arestas é a representada por subconjuntos

de privilégios decorrentes do esquema de proteção.

Um caminho no grafo representa um conjunto de vulnerabilidades que

podem ser utilizadas por um atacante para alcançar um alvo. O peso de cada aresta

representa o esforço para explorar uma vulnerabilidade representada pela aresta.

DBD



58

A Figura 14 a seguir exemplifica um grafo de privilégios com arestas

rotuladas por classes de vulnerabilidades.

Figura 14: Grafo de Privilégios (extraída de Ortalo et al., 1999)

Cada aresta no grafo é representada com os seguintes pesos:

1. X pode descobrir a senha de Y.

2. X pode instalar um cavalo de Tróia que Y pode ativar em algum

momento.

3. X pode explorar uma falha no programa de correio de Y.

4. Y é um subconjunto de X.

5. Y usa um programa que X pode modificar.

6. X pode modificar um programa de propriedade de Y

7. X está trabalhando com os privilégios de Y

Alguns conjuntos de privilégios são altamente sensíveis, como, por

exemplo, os privilégios de super usuários. Estes nós são chamados de “alvos”

visto que estes são provavelmente alvos de ataques. Os nós com os privilégios de

possíveis atacantes são chamados de nós atacantes. Se um caminho existe entre

um nó atacante e um nó alvo, então, por transitividade, uma brecha de segurança

pode ocorrer, permitindo que um possível atacante explore as vulnerabilidades do

sistema para obter privilégios alvo.

Mesmo que exista um caminho entre um nó atacante e um nó alvo,

dificilmente a segurança do sistema será derrotada se um atacante precisar de

DBD



59

muita inteligência, competência ou tempo para percorrer todas as arestas que

compõem o caminho. Esta dificuldade dos atacantes em alcançar os alvos pode ser

uma boa métrica de segurança do sistema. Para poder medir este esforço por parte

do atacante, basta atribuir para cada aresta no grafo um peso que quantifique o

esforço requerido para explorar uma determinada vulnerabilidade. Esta definição

de esforço é composta por várias características do processo de ataque tal como

uma ferramenta de ataque pré-existente, o tempo necessário para realizar um

ataque, o poder computacional disponível para o atacante, etc. Por exemplo, o

esforço necessário para obter uma senha pode ser medido pelo poder

computacional e pelo tempo necessário para quebrar uma senha. Para um ataque

de um cavalo de Tróia, o esforço pode ser medido como a competência necessária

para desenvolver um cavalo de Tróia, o tempo necessário para implantá-lo em um

programa que pode ser usado para atacar um usuário, e o tempo necessário para

um usuário ativá-lo. O peso do esforço atribuído para um aresta é deste modo um

parâmetro composto, que pode ser representado como uma taxa de sucesso para o

correspondente ataque elementar.

Estudando o comportamento do Atacante

Para avaliar métricas quantitativas que caracterizem a segurança operacional

baseada no grafo de privilégios é importante identificar os cenários de ataques que

podem ser empreendidos por um atacante em potencial para alcançar o alvo.

Normalmente, em um ataque, um atacante começa com algum privilégio

mínimo e parte em busca da obtenção de algum privilégio maior no sistema.

Sendo assim, em um grafo de privilégios, o caminho do nó de um atacante até o

nó alvo descreve o processo de ataque. Em um grafo podem existir mais de um

caminho do nó do atacante para o nó alvo. A figura 15 a seguir representa o

caminho de um atacante até o alvo:

DBD



60

Figura 15: O Atacante e o caminho até o alvo.

O progresso do atacante pode ser caracterizado por um grafo de transição de

estados onde cada estado identifica o conjunto de privilégios que ele já ganhou e a

transição entre os estados ocorre quando o atacante tem sucesso em um ataque que

o permite adquirir novos privilégios. Este grafo, denominado Attack state graphs,

consiste numa representação das diferentes maneiras que um invasor qualquer

pode utilizar para alcançar certo objetivo, tal como o acesso a informações sobre

senhas de usuários de um sistema. Os nós do grafo representam os privilégios que

podem ser alcançados pelo atacante.

Para estudar o comportamento dos atacantes, diferentes modelos podem ser

definidos dependendo das suposições consideradas sobre o seu comportamento.

No primeiro modelo o atacante escolhe o caminho mais curto que o conduz até o

alvo (denotado como SP), isto é, o caminho que tem o mais baixo valor de esforço

totalizado. Para ser possível o uso deste caminho por parte do atacante, ou o

atacante é um super usuário, ou o sistema atacado não possui nenhuma proteção.

Para melhor aplicar a abordagem de árvore de privilégios, os autores supõem que

o atacante não sabe qual é o caminho mais curto.

Duas outras suposições para específicos modelos de processos de ataque

(comportamento do atacante) são:

• Memória total (TM): todas as possibilidades de ataque serão

consideradas em qualquer estágio de ataque

• Sem memória (ML): em cada novo nó visitado, somente ataques

possíveis a partir daquele nó serão considerados.

DBD



61

A figura 16 a seguir representa a derivação de Attack state graphs a partir

de um grafo de privilégios, considerando os modelos de processos de ataque

memória total, TM, e sem memória, ML.

Figura 16: Derivação das Attack state graphs a partir do Grafo de Privilégios. Figura

baseada no artigo de Ortalo e co-autores (Ortalo et al., 1999)..

Modelo Matemático

Para sermos capazes de comparar a evolução da medida de segurança

correspondente às suposições TM, ML e SP, necessitamos especificar um modelo

matemático para avaliar o esforço médio despendido por um atacante para que

alcance um determinado alvo. Os autores Ortalo et al. (1999) propõem a utilização

do modelo de Markov, pois, segundo eles, este modelo satisfaz algumas

propriedades intuitivas relacionadas à evolução da segurança (Dacier et al., 1996).

O modelo de Markov está baseado na suposição de que a probabilidade de

conseguir um ataque elementar bem sucedido à segurança, antes que uma

quantidade de esforço “e” seja despendida, pode ser descrita por uma distribuição

exponencial dada por P(e) = 1 – exp(-λe), onde λ é uma taxa atribuída ao ataque.

Considerações práticas derivadas do uso desta distribuição são as seguintes:

• Um atacante em potencial será bem sucedido, eventualmente, em

DBD



62

pesquisar o alvo, se um caminho o levar ao alvo existente,

considerando que ele gasta um esforço razoável para isto.

• O esforço médio para quês atacante tenha sucesso em um

determinado ataque é dado por 1/ λ

O último ponto é particularmente valioso por que o conhecimento da taxa

do ataque é suficiente para caracterizar a distribuição completa. O primeiro ponto

ainda merece alguns esclarecimentos. De fato, segundo os autores, o objetivo

deste trabalho foi o de avaliar a resistência do sistema em relação a ataques bem

sucedidos a um alvo específico, considerando cenários de ataques que,

eventualmente, levam ao alvo e não os cenários que podem ser abortados durante

o processo de ataque.

Baseado na suposição de Markov, cada transição no processo de transição

de estados é taxado com a taxa de sucesso da vulnerabilidade correspondente.

Várias medidas probabilísticas podem ser derivadas a partir do modelo, entre

estas, o esforço médio para um atacante potencial alcançar o alvo especificado,

denotado como METF (Mean Effort To Security Failure, em analogia com o

Mean Time to Failure). Esta métrica permite fácil interpretação dos resultados:

quanto mais alto o METF, melhor será a segurança. Além disso, simples

expressões analíticas podem ser facilmente obtidas e analisadas para checar a

plausibilidade dos resultados do modelo.

O METF é dado pela soma dos esforços médios gastos nos estados que

levam até ao alvo que são sobrecarregados pela probabilidade de visitar estes

estados. O esforço médio gasto no estado j, denotado como Ej, é dado pelo

inverso da soma das taxas de transição de estados j’s :

Ej = 1 / ∑ λji

i Є out(j)

Out(j) é o conjunto de estados alcançáveis em uma transição simples do

estado j e λji é a taxa de transição do estado j para o estado i.

Denotamos por METFk o esforço médio quando o estado k é o estado inicial

DBD



63

e Pki a probabilidade condicional de transição do estado k para o estado i, então:

METFk = Ek + ∑ Pki * METFi i Є out(k)

Pki = λki * Ek

De acordo com este modelo, o valor mais alto da probabilidade condicional

de saída corresponde às transições com as taxas mais altas de esforço bem

sucedido.


1. Similar ao método de Brocklehurst et al.(1994), “Esforço

despendido por um atacante”.


1. A técnica é aplicada depois que o software é desenvolvido.

2. Atacantes têm habilidades e experiência diferentes.

3. Muitas vezes um ataque à segurança não é reconhecido. O

processo de medição pode falhar para vulnerabilidades

desconhecidas.

4.5 Método Wang e Wulf para Medir Segurança

Chenxi Wang e William A. Wulf (1997) apresentaram um framework para

medir de forma sistemática o nível de segurança de um software. O nível de

segurança é apresentado como uma n tupla de números reais, cada tupla

representando uma propriedade de segurança. Por exemplo, se a segurança do

sistema for definida como uma combinação de confidencialidade, integridade e

disponibilidade, uma possível métrica de segurança é a tupla <f1, f2, f3>, f1

representando confidencialidade, f2 representando integridade e f3 representando

disponibilidade. Os valores nesta tupla indicam a força da segurança, medida a

partir de sua confidencialidade, integridade e disponibilidade do sistema.

DBD



64

No caso em que uma medida simples é desejada, um modelo para derivar a

medida final a partir de medidas de diferentes aspectos. Por exemplo, a tupla

< �f1 (confidencialidade), f2 (integridade), f3(disponibilidade)>, g(f1, f2, f3)> onde

g(f1, f2, f3) = 0.65 f1 + 0.25 f2 + 0.1 f3 define uma medida em que o valor final

depende 65% da confidencialidade, 25% da integridade e 10% da disponibilidade

do sistema.

Esta metodologia utiliza a técnica de decomposição para desenvolver

modelos que relacionam atributos de segurança de nível mais alto com os de nível

mais baixo, que, segundo os autores, são componentes mais mensuráveis. O

processo de avaliação sugerido consiste de cinco passos:

• Decomposição

• Determinar os relacionamentos funcionais, isto é, as interações dos

componentes do sistema.

• Determinar pesos e prioridades

• Definir medições básicas, e

• Analisar a sensibilidade do componente

Estes cinco passos são analisados a seguir.

Decomposição

Decompor um sistema em partes menores pode ser um processo difícil.

Ainda mais, se ele resultar em elementos independentes que podem ser avaliados

sem qualquer necessidade de promover o particionamento. Estes componentes

básicos têm grande influência na segurança do software como um todo.

Os autores declaram que uma decomposição funcional de um software será

possível se a pergunta: “O que precisa acontecer para que o objetivo atual não

falhe?” for respondida. Para exemplificar a técnica de decomposição (figura 17),

os autores fazem uma analogia com a segurança de uma casa., considerando que

para a garantia da integridade e privacidade da segurança da casa, às portas e

DBD



65

janelas são os fatores principais que necessitam ser decompostos em seus

componentes funcionais.

Figura 17: Exemplo de decomposição. Figura extraída do artigo “A Framework for

Security Measurement” de Wang e Wulf (1997)

Cada componente de mais baixo nível na representação é avaliado ao

atribuirmos um valor de 0 a 1 em relação a uma propriedade de segurança.

O processo de decomposição pode ser executado nos seguintes passos:

1. Identifique um conjunto de objetivos de segurança para o sistema

sujeito à análise.

2. Identifique os componentes que contribuem para o sucesso dos

objetivos. Estes são as funções que têm acontecer para que os

objetivos não falhem.

3. Examine os nós subordinados, verificando a necessidade de se

decompor ainda um pouco mais. Caso seja necessário, repita o

processo com os nós subordinados.

4. Termine o processo de decomposição quando nenhuma folha

necessitar mais ser decomposta.

DBD



66

Determinando os Relacionamentos Funcionais

Uma vez empregado o processo de decomposição, a interação entre os

muitos componentes que contribuem para a segurança também deve ser

considerada. A análise das relações entre estes componentes não é uma tarefa

simples e nos leva a uma nova complexidade de significativos problemas

representados pela análise de suas relações.

A seguinte lista descreve um conjunto de relacionamentos lógicos entre os

componentes do sistema e as regras de composição associadas com eles.

Link mais fraco (WL) – WL significa que o funcionamento do pai é, em

última análise, restringido pela fraqueza dos seus filhos. A “fraqueza”, neste

contexto, se refere a uma medida da força da segurança. Em particular, uma falha

em um nó filho em uma relação WL causará uma falha da função objetivo.

Matematicamente, WL pode ser descrita como:

S(pai) = min(S(filho1), S(filho2),..., S(filhon)),

Onde S representa os valores da avaliação de nós e n é o número de nós

filhos.

Por exemplo, considerando o exemplo da casa, a segurança da casa depende

de dois fatores: a porta e a janela. É facilmente percebido que o comprometimento

de um dos dois fatores pode resultar na invasão da casa e as conseqüências são

igualmente prejudiciais. Portanto, uma relação WL existe entre a porta e a janela.

Supondo que os escores de avaliação para a porta e a janela são

respectivamente 0.75 e 0.83, o escore da casa é calculado da seguinte forma:

S(casa) = min (0.75, 0.83) = 0.75

Link mais Fraco Sobrecarregado (WWL)- O WWL é uma generalização

do WL. Enquanto o WL não diferencia entre trivial e fatores importantes, o WWL

leva em conta que diferentes nós filhos podem ter vários graus de impacto no nó

DBD



67

pai.

Por exemplo, considere o funcionamento de uma porta no exemplo da casa,

foi decidido que três fatores são importantes: a estrutura da porta, a fechadura e a

chave. Portanto, a segurança fornecida pela porta pode ser mais fortemente

influenciada por um subconjunto de outros fatores. Por exemplo, dependendo de

que espécie de vizinho da casa a casa possua, pode ser que vale à pena dar mais

atenção à resistência da porta e a segurança da fechadura do que dar atenção à

chave. Portanto, a relação WWL, que parece ser mais apropriada para esta

situação, está representada na figura 18 a seguir:

Figura 18: Exemplo da Porta (extraída do artigo “A Framework for Security

Measurement” de Wang e Wulf (1997))

Matematicamente, a saída de uma relação WWL é calculada seguindo os

seguintes passos:

1. Suposições: cada nó filho tem um escore S de avaliação e um peso W, onde S é

um número entre 0 e 1 e a soma dos pesos entre todos os irmãos é igual a 1.

Na figura 18, os pesos dos três nós folhas são 0.5, 0.05 e 0.45 e seus escores

de avaliação são 0.85, 0.6 e 0.90.

2. Normalize os pesos a partir do peso de valor mais alto. Os pesos normalizados

(NWs) para os três nós folhas na figura 18, são 1, 0.1 e 0.9.

3. Selecione o filho que possui a menor relação S/NW, min (S1/NW1, S2/NW2,...,

DBD



68

Sn/NWn), sendo n é o número de nós filhos. Na figura 18, o filho com menor

valor é a chave, onde S/NW = 0.222.

n

4. Compute a soma dos pesos dos nós filhos SomaPesos = ∑ (Si * Wi), onde n é i=1

o número de nós filhos. No exemplo da figura 18, a soma dos pesos é: (0.85 *

0.5 + 0.6 * 0.05 + 0.2 * 0.45) = 0.545

5. O escore WWL do nó pai é calculado como a raiz quadrada do produto da

soma dos pesos com o escore do filho mais fraco, isto é, de menor relação

S/NW é igual a:

√ 0.545 * 0.2 = 0.33

Irmãos Priorizados (PS): Esta relação existe entre irmãos, cada um

contribuindo para um aspecto independente da função pai. Por exemplo, o

elemento janela, no exemplo anterior da casa, é decomposto em estrutura e

cortina. É facilmente percebido que a cortina e a estrutura fornecem

funcionalidades independentes que, coletivamente, contribuem para a segurança

do elemento janela. Todavia, uma falha funcional de um elemento não

necessariamente causaria uma falha funcional na janela. Uma relação PS também

reconhece a relação de importância dos nós filhos para o pai. Formalmente, uma

relação PS pode ser descrita como:

n

S(pai) = ∑ (Si * Wi), onde S é o escore de avaliação e W representa o i = 1

peso em percentual, e n representa o número total de nós filhos.

Supondo que o valor de S (estrutura) é 0.98 e o valor de S(cortina) é 0.63, e

seus respectivos pesos são 0.85 e 0.15, o escore da janela pode ser calculado

como: S(janela)= 0.98 * 0.85 + 0.63 * 0.15 = 0.928. A figura 19 a seguir ilustra o

cálculo de S, segundo a relação irmãos priorizados:

DBD



69

Figura 19: Funcionamento da janela em relação aos seus fatores (extraída do artigo “A

Framework for Security Measurement” de Wang e Wulf (1997))

Determinando Pesos e Prioridades

Quando decompomos, os pesos indicam os graus com que os nós filhos

influenciam seus pais. Esta avaliação de pesos é crítica porque os pesos são

utilizados para computar a influência de vários elementos no sistema como um

todo.

Em um modelo baseado na técnica de decomposição de elementos, o nó

filho pode influenciar seus pais de maneiras diferentes. Portanto, de acordo com

os autores do método, considerarmos esta influência é de extrema importância

antes de introduzirmos os pesos que indicam os valores de tais efeitos.

Os pesos dos nós filhos podem ser definidos a partir de um questionário ou

experiência do próprio avaliador, o que torna o método aqui apresentado bastante

subjetivo.

Análise da Sensitividade do Componente

O último elemento da metodologia consiste em uma análise de sensitividade

de um componente. Segundo os autores, uma análise de sensitividade é realizada

para avaliar o impacto de variações nos componentes individuais. Ela permite

identificar a contribuição de um componente ou conjunto de componentes para a

segurança do sistema como um todo.

DBD



70

Se o valor da medida para a propriedade de segurança variar drasticamente

com a mudança de um certo conjunto de componentes, uma segunda visão mais

próxima deve ser executada sobre este conjunto particular de componentes.

Segundo os autores, recomendações para melhorar a força da segurança dos

componentes podem ser feitas baseadas neste estudo.

Vamos retornar ao exemplo da casa (Figura 17) para brevemente descrever

o processo de uma análise de sensitividade de um componente. Usando as regras

de decomposição definidas por cada relacionamento funcional, é possível medir

os atributos de segurança de nível mais alto a partir dos componentes básicos.

A figura 20 a seguir ilustra o exemplo anterior do sistema da casa com os

respectivos pesos dos nós folhas e o tipo de relacionamento funcional empregado.

A lista seguinte de equações é derivada a partir do relacionamento funcional

usado na árvore de decomposição.

1. S(casa) = min (S(porta, S(janela))).

2. S(janela) = 0.98 * S(estrutura) + 0.63 * S(cortina)

3. S(porta) = √(0.5 * S(estrutura) + 0.15 * S(chave) + 0.05 * S(fechadura)) *

√Min peso( S(estrutura), S(chave), S(fechadura))

4. S(casa)=S(porta)=

√S(fechadura)*(0.5*S(estrutura)+0.45*S(chave)+0.05*S(fechadura)

DBD



71

Figura 20: Árvore de Decomposição para uma Casa (Extraída do artigo “A Framework for

Security Measurement” de Wang e Wulf (1997))

Podemos agora calcular os indexes de sensitividade do componente.

Assumindo que os escores dos outros componentes são mantidos constantes, o

index de sensitividade (SI) de um determinado componente é definido como a

razão entre o escore geral e o escore do componente. Por exemplo, o SI da

estrutura da porta é calculado como segue:

S.I. estrutura_porta = δS(casa)/ δS(estrutura)

= 0.5 * S(chave)

2√ S(chave) * (0.5*S(estrutura) + 0.45*S(chave) + 0.05 * S(fechadura))

= 0.5 * 0.2

2√ 0.2 (0.5*S(estrutura) + 0.45*0.2 + 0.05 * 0.6)

= 0.5

√ 10 S(estrutura) + 2.4

Substituindo o valor de S (estrutura), nós temos que S.I.estrutura_porta =

0.1514. Para cada unidade de mudança na performance da estrura da porta, a força

da segurança da casa como um todo mudará 0.1514 unidades.

A tabela 2 abaixo mostra os indexes de sensitividade para todos os

DBD



72

componentes folhas do exemplo da casa:

Componente Equação S.I. Valor do S.I.

Estrutura da porta 0.5

√ 10 S(estrutura) + 2.4

0.1514

Fechadura 0.5

√ S(fechadura) + 26.5

0.096

Chave 2.275 + 4.5S(chave)

√ 45.5+ 45 S(chave)2

0.4617

Estrutura da Janela 0 0

Cortina 0 0

Tabela 2: Indexes de Sensitividade (S.I.s) dos componentes básicos da casa (extraída

do artigo “A Framework for Security Measurement” de Wang e Wulf (1997)).

Uma análise da sensitividade a partir da tabela 2 acima mostra que ao

melhorar a força da segurança da chave temos um maior aumento da segurança da

casa como um todo. Um componente em que o S.I. é maior do que 0.1 é

considerado um componente não trivial. Segundo os autores, a estrutura da janela

e a cortina possuem valores iguais a zero por causa da seguinte condição:

S(janela) > S(porta).

A análise de sensitividade pode também ser utilizada para validarmos o

esforço modelado. O modelo produzido após a decomposição pode estar errado se

o S.I. de algum componente tiver um valor muito mais alto do que dos outros. O

processo de decomposição, associado com uma análise de sensitividade adequada,

pode fornecer um guia útil para isolarmos as áreas de vulnerabilidade do sistema,

identificarmos a fonte do problema e , por último, levar a descobertas de falhas de

DBD



73

segurança ou vulnerabilidades.


1. Método simples e de fácil entendimento


1. Descrever atributos fundamentais com diferentes unidades e

escalas leva a uma inconveniente situação de não poder

comparar resultados de avaliação de segurança.

2. Decompor um sistema em partes menores pode ser um

processo difícil.

3. Estabelecer o quanto um elemento afeta a segurança de outro

é uma tarefa muito difícil.

4. Atribuir pesos sem subjetividade é muito difícil.

DBD



74

4.6 Redução da Superfície de Ataque

Os autores Manadhata e Wing (2004) apresentaram um trabalho focado em

definir uma métrica para medir de forma sistemática uma superfície de ataque de

um sistema. Intuitivamente, a superfície de ataque de um sistema constitui-se do

subconjunto de recursos que um atacante pode utilizar para atacar um sistema.

Quanto mais funcionalidades estiverem disponíveis a um usuário ou quanto mais

recursos forem acessíveis por essas funcionalidades, mais exposta será a

superfície de ataque. E, quanto mais exposta estiver, mais susceptível o sistema

estará a ataques com chances de sucesso, portanto mais inseguro será. A métrica

visa reduzir a superfície de ataque com o objetivo de diminuir a probabilidade de

um possível ataque, o que tornaria o sistema mais seguro.

Segundo os autores, os ataques registrados nos últimos anos mostraram que

certos recursos dos sistemas têm mais tendência de serem utilizados em um ataque

do que outros. Por exemplo, serviços executados com privilégio de root estão

mais sujeitos de virarem alvos de ataques do que serviços que operam sem

grandes restrições de privilégios. Arquivos com informações sobre o controle e

configuração de um sistema são mais prováveis de serem atacados do que

arquivos com privilégios mais restritos. Uma medida da superfície de ataque

indica o nível de dano que um suposto atacante pode, potencialmente, causar ao

sistema e o esforço necessário para o atacante causar tal dano.

Sendo assim, a métrica proposta considera que nem todos os recursos de um

sistema devem ser tratados de forma igual. Para medir a superfície de ataque

precisamos identificar estes recursos e sua contribuição para esta superfície. A

identificação dos recursos de um sistema, possíveis alvos de ataques, é feita

através de um conjunto de propriedades destes recursos categorizadas em classes

de ataque. Tais propriedades referem-se à oportunidade de ataque – ou

“atacabilidade” (em inglês: attackability) – de um tipo de recurso, isto é, alguns

tipos de recursos são mais vulneráveis a ataques que outros. . Normalmente, um

atacante conecta-se a um sistema utilizando os seus canais (portas abertas),

invocando os métodos deste sistema (API’s) ou enviando e recebendo dados a

DBD



75

partir do sistema.

A contribuição de cada recurso depende do potencial dano do recurso, isto é,

do nível de dano que um atacante pode causar ao sistema ao usar o recurso em um

ataque, e do esforço necessário para que um possível atacante adquira os direitos

de acesso necessários para ser capaz de utilizar estes recursos em um ataque.

Quanto maior o dano, mais alta será a contribuição. Para estimar a contribuição de

cada recurso para a superfície de ataque, os autores calculam esta contribuição em

função dos atributos destes recursos. Por exemplo, para estimar a contribuição dos

métodos, basta verificá-lo em relação aos seus direitos de acesso e concessão de

privilégios. De forma similar, para estimar a contribuição dos canais, devemos

considerá-la em termos dos protocolos e direitos de acesso do canal e para estimar

a contribuição dos itens de dados, devemos considerá-la em termos dos direitos de

acesso e tipo de itens. A superfície de ataque é medida, então, a partir destas três

dimensões: método, canal e dados.

Com um conjunto de classes de ataque e duas versões diferentes de um

mesmo sistema, é possível medir qual é o mais relativamente seguro submetendo-

os a uma comparação em relação às classes de ataque propostas. 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. Podem-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 para Medir a Superfície de Ataque

A medição da superfície de ataque consiste dos seguintes passos:

1. Dado um sistema, S, e seu ambiente, Es, identificamos um conjunto M de

pontos de entrada e saída, um conjunto C de canais e um conjunto I de itens de

dados não confiáveis de S.

2. Estime o esforço e o potencial dano, d(m) para cada método m Є M, d(c) para

cada canal c Є C e para cada item de dados i Є I.

DBD



76

3. A medida da superfície de ataque de S é a tripla:

<∑ d(m), ∑d(c) , ∑ d(i)> m Є M c Є C i Є I

O método utilizado nesta métrica é bem eficaz também quando comparamos

sistemas similares. Porém, quando comparamos dois sistemas completamente

diferentes o resultado não é muito bom, pois sistemas diferentes podem ter

conjuntos de classes de ataque distintos.

A redução da superfície de ataque está baseada na redução do uso do código

a zero. Tal redução seria alcançada, por exemplo, pelo emprego da regra 80/20, a

qual pode ser definida como: se oitenta por cento dos usuários não usam

determinada funcionalidade de um software, desligue a funcionalidade, mas

permita que possa ser ligada quando necessário.

A combinação de qualidade do código desenvolvido com a técnica de

redução da superfície de ataque pode levar a produção de um software mais

seguro, o que, segundo o autor, é inatingível apenas com um 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:

1. 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.

2. Reduzir o acesso a pontos de entrada para usuários não confiáveis –

restringir o acesso a quem não deveria, em essência, usar

determinado recurso e fortalecer os princípios de autenticação.

3. Reduzir o privilégio para limitar o potencial de dano – reduzir os

privilégios sob os quais o código deve ser executado.

4. Análise das entradas de dados – analisar o diagrama de fluxo de

dados (DFD) ou diagrama de interação da UML (Unified Modeling

Language) e identificar os pontos de entrada do sistema. A análise

permitirá identificar se há a necessidade de aumentar o nível de

DBD



77

autorização nesses pontos.

5. Reduza a superfície de ataque de forma preventiva – 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 instaladas de usuários. Dessa forma, os desenvolvedores

conhecerão desde o início como será a superfície de ataque.

6. 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.

7. 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.


1. Pode ser empregada na fase de desenvolvimento


1. Sistemas grandes tendem a ter grandes superfícies de ataque.

Definir esta superfície não parece ser algo muito simples.

2. Necessita de um razoável gerenciamento de mudanças para

controlar a evolução da superfície de ataque.

3. Sistemas com classes diferentes de ataque não podem ser

comparados.

DBD



78

4.7 Proposta de um Framework para medir a segurança de um

software

Como um primeiro passo em direção a definição de um framework

estruturado de propriedades, os autores (Scandariato et al, 2006) começaram

elicitando-os a partir da lista de práticas e princípios de segurança. Uma lista

parcial destes princípios está disponível em em (Graff, 2003) e Stoneburner et al

(2004). Os princípios propostos são mapeados para as fases do processo

correspondente em que eles se aplicam.

Segundo ou autores, práticas e princípios são um importante ponto de

partida para elicitar propriedades que podem ser medidas em diferentes níveis de

abstração.

Propriedades Consideradas na Metodologia

1. Faça pequeno e de forma simples (Keep it small and simple)

Os mecanismos simples tendem a ter poucas falhas exploráveis e exigem

menos manutenção. Além disso, como questões de gerência de configuração são

simplificadas, atualizar ou trocar um mecanismo simples se torna um processo

menos intensivo. Propriedades que podem ser usadas para estimar o esforço deste

princípio são as seguintes:

• Tamanho

• Complexidade

• Tamanho da superfície de ataque

Métricas

Tamanho e complexidade podem ser medidos com métricas de software no

nível do design e no código. Possíveis recursos para medir o tamanho da

superfície de ataque em diferentes níveis de abstração já foram discutidos

anteriormente.

DBD



79

2. Separação de Interesses (Separation of concerns)

Para obedecer este princípio enquanto desenvolver sistemas, características

podem ser otimizadas de forma independente um da outra, para que falhas de uma

não causem falhas nas outras também. Em geral, a separação de interesses torna

mais fácil entender, design, e gerenciar sistemas independentes complexos. Para

este princípio, a seguinte propriedade pode ser investigada.

• Grau de separação de interesses de segurança

Métricas

O grau de separação de interesses de segurança pode ser medido por meio

de métricas que foram definidas nas pesquisas de desenvolvimento orientado a

aspectos.

3. Implemente Segurança em Camadas

Projetistas de segurança devem considerar a abordagem de camadas para

endereçar uma ameaça específica oureduzir uma vulnerabilidade. Por exemplo, o

use de um roteador (filtrar pacotes) junto com um sistema para detectar invasão

aumenta o esforço de um atacante ao explorar com sucesso o sistema. Uma

propriedade simples foi definida para medir este princípio.

• Linhas de defesa

Métricas

Possíveis meios para avaliar a existência de um projeto (design) de

segurança em camadas são:

• O número de controles de validação de dados por fluxo de informação

• O número de controles de autorização/autenticação por cenário de uso.

4. Identifique e minimize criticidades

Em relação ao termo “módulos críticos” os autores consideram todas as

DBD



80

entidades (dados ou métodos) que são vulneráveis a ataques. Um módulo pode ser

avaliado como crítico a partir de vários critérios definidos, tais como: está ele

seguro, está ele localizado em um ambiente seguro, o módulo é um importante

ativo do proprietário do software, e o módulo está fundamentado no projeto e, por

conseguinte, pode ser um alvo de um ataque “Denial of Service”? Contudo,

também o número de módulos completamente confiáveis, isto é, componentes

intencionalmente não submetidos a um exame detalhado de segurança, devem ser

mantidos tão longe quanto possível das interfaces do sistema. Conseqüentemente,

a propriedade relevante a ser medida é:

• Número de módulos críticos

Métricas

A identificação de métodos pode empregar diagramas UML como entrada.

Por exemplo, diagramas de deployment descrvem as informações relacionadas à

localização de uma aplicação, e tal informação pode ser utilizada para apontar

relações de confiança, ambientes de deployment não confiáveis, e possíveis

gargalos (Dos). Para fazer a identificação de módulos que são importantes (asset-

wise), técnicas de análise de riscos devem ser usadas. Mais adiante métricas de

interesse são o “número de entidades confiáveis”, que têm que ser minimizadas, e

a “aferição do acomplamento dos componenetes”, que podem ser usados para

identificar módulos fundamentais. ( por conseguinte sensível ao Dos)

5. Alguns Indivíduos devem ser responsabilizados por seus atos (em inglês:

accountability)

Sistemas de software devem manter um registro das atividades para

certificar se os recursos de sistema estão funcionando adequadamente e que eles

não estão sendo utilizados de forma não autorizada. A trilha de auditoria pode ser

usada tanto para monitorar recursos, e também como evidência no caso de

violações à política de segurança. Neste caso, é interessante avaliar a seguinte

propriedade:

• Grau de responsabilidade final (accountability)

DBD



81

Métricas

Uma abordagem ingênua para avaliar a propriedade acima é representada ao

contar o número de operações não-auditadas (em relação a arquitetura) ou

métodos (em relação ao design) com respeito ao número total de

operações/métodos. Estas métricas podem ser checadas cuidadosamente com

aquelas da seção anterior, por causa da identificação dos módulos críticos que

devem ser auditados mais cuidadosamente, por causa de sua natureza sensível.


1. Pode ser utilizado na fase de desenvolvimento do software.

2. Pode ser usado com outros princípios.


1. Não foi comprovada pelo autor.

4.8 Análise dos Métodos Apresentados

Apesar de todas estas iniciativas para avaliação quantitativa de segurança,

nenhum dos métodos aqui apresentados consegue determinar com precisão que

um sistema é seguro. Os trabalhos de Brocklehurst et al.(1994), Alves e Foss

(1995) , Voas et al. (1996) , Ortalo et al. (1999) focam nas vulnerabilidades de um

sistema como uma métrica de segurança. A abordagem de usar vulnerabilidades

como uma métrica são falhas porque não conseguem tratar futuros ataques ao

sistema, por isso, não são totalmente indicadas para a avaliação da segurança de

um software antes que seja colocado em produção. A métrica da redução da

superfície de ataque parece ser interessante, mas necessita de estudos mais

aprofundados para que seja plenamente utilizada.

Infelizmente, métricas úteis relacionadas com o desenvolvimento de

produtos codificados de acordo com os requisitos de segurança do software ainda

estão em sua infância, e não existe até hoje nenhum consenso de quais métricas

constituem melhores práticas. Uma revisão da literatura revela a escassez de

DBD



82

trabalhos publicados, validados e aceito por todos, sobre métricas de segurança

relacionadas com o ciclo de vida de desenvolvimento. Apesar de tudo, existem

algumas métricas e práticas usadas no desenvolvimento de software que podem

ser proveitosas se estendidas para endereçar requisitos de segurança.

DBD


5 Dificuldades na Geração de Métricas de Segurança Quantitativas

Até hoje a ciência da computação não obteve sucesso em definir métricas de

segurança de software quantitativas que sejam simples, confiáveis e aceitas por

todos para a avaliação da segurança de sistemas de informação. Muitos

pesquisadores da comunidade de garantia da segurança de um software e da

Engenharia de Software se opõem à introdução de uma métrica para quantificar a

segurança e a qualidade de software respectivamente (Ortalo, 1999).

Se não podemos medir a segurança do software, então como podemos

melhorá-la? Bellovin (2006) afirma que quando podemos medir e expressar em

números algo sobre o objeto medido; mas quando não conseguimos expressar em

números, o nosso conhecimento sobre segurança é pobre e insatisfatório. Estaria

Bellovin certo em relação à segurança de software? Seria realmente impossível

avaliarmos a segurança de um software antes que ele seja colocado em produção?

Os métodos apresentados no capítulo anterior ainda se encontram em fase de

amadurecimento e não são conclusivos em relação ao assunto, apesar de algumas

vantagens por eles oferecidas.

De fato, temos dificuldades para definir métricas de software quantitativas,

isto porque a segurança ao conter sutilezas e desafios diferentes, principalmente

relacionadas a intenção de alguém em explorar vulnerabilidades dos sistemas, os

problemas de segurança da informação tornam-se mais difíceis de serem

entendidos do que em outras disciplinas da garantia da qualidade, tais como safe

software e tolerância à falhas. Por exemplo, é óbvio que uma série de eventos não

seguros certamente ocorreram antes de um desastre de avião, mas a maioria dos

ataques à segurança de computador são muito menos observáveis e são quase

sempre não detectados, ou só detectados muito tempo após a ocorrência do

evento.

DBD


Dificuldades na Geração de Métricas de Segurança Quantitativas

84

Uma abordagem interessante sobre as sutilezas que estão por trás da

segurança de software está em Voas (1996), que faz uma comparação entre

invasões militares em guerras tradicionais com invasões de software, a chamada

guerra cibernética. Voas (1996) diz: “uma ofensiva não bem sucedida ao software

quase sempre fortalece o atacante ao dar a ele o conhecimento sobre o alvo de

ataque e não fortalece o alvo atacado por meio do enfraquecimento do atacante.

Nas tradicionais invasões militares, muitas vezes, uma ofensiva não bem sucedida

enfraquece o atacante pelo menos tanto quanto o site atacado. Além disso, em

tradicionais estratégias de guerra, o potencial para retaliação fornece uma

intimidação ao atacante antes dele atacar. Na batalha da informação, contudo, o

medo de retaliação é mínimo, e não afeta a balança do poder. A maior parte das

técnicas de segurança da informação usadas hoje são ou baseadas em táticas

ultrapassadas de 20 anos atrás, ou são baseadas em táticas aplicáveis somente

em guerras convencionais”. Como muitas vezes não conseguimos nem detectar a

ocorrência de um evento inseguro ou um padrão de ataque, isto torna mais difícil a

medição de certas características de segurança do sistema, como por exemplo,

confidencialidade.

Além do modo intencional como o software é atacado, há outras

complicações adicionais que precisamos considerar na busca por métricas de

software significativas. Neste ponto, o valor dos ativos, as ameaças e as

vulnerabilidades são elementos críticos para a análise de riscos de segurança como

um todo e são (ou deveriam ser) considerados na maioria das decisões que têm a

ver com segurança. Cada um destes elementos traz dificuldades quando tentamos

incorporá-los em uma métrica de segurança útil. O valor do ativo é o mais fácil de

medir destes três elementos; porém, certos aspectos do valor, como a boa

reputação de uma companhia ou de uma pessoa é difícil, se não impossível, de se

quantificar.

Alguns acreditam que ameaças não podem ser sempre medidas, isto devido

a impossibilidade de realmente calcularmos o potencial dos danos (prejuízos),

embora os resultados de pesquisas e de outras fontes externas de informação

possam ser úteis para quantificar a ameaça em um nível mais alto, no nível

gerencial. Hoje até existem alguns benchmarks e ferramentas (Chess, 2007)

DBD



85

automatizadas desenvolvidas para descobrir níveis de vulnerabilidades de

sistemas de computador, porém medições de outros aspectos de vulnerabilidades,

como o grau de conhecimento sobre assuntos de segurança entre usuários de

computador, permanecem um pouco subjetivas.

Medir os riscos de segurança, a probabilidade de uma agressão intencional

ou não ser bem sucedida, junto com uma avaliação do tamanho do dano – impacto

– pode nos dar uma boa idéia de qual a nossa situação face à segurança.

5.1 Evolução de Nossa Capacidade de Tratar a Insegu rança

Um aspecto interessante para compreendermos as dificuldades de medirmos

segurança é avaliarmos como está evoluindo a nossa capacidade de tratar a

insegurança. O gráfico (figura 21) a seguir (Williams et al., 2006) denominado

Hype Cycle nos dá uma idéia que tipos de ameaças existem hoje em relação à

segurança e quais conseguimos tratar de forma eficiente ou não. Para

compreender a curva, é importante entender alguns conceitos sobre ela:

Technology trigger - período que vai do conhecimento da existência de uma

determinada classe de ameaça até se tornar umas das maiores preocupações de

segurança (ponto mais alto da curva). Neste período ainda não existe uma forma

razoável para o tratamento da ameaça, como por exemplo Insecure Application

Development.

Peak of Inflated hyperbole – neste período as organizações devem começar

a pesquisar a ameaça e seu impacto na organização, bem como entender as

possíveis soluções, pois o impacto sobre os negócios pode ser significativo.

Trough of complacency – a partir do pico em direção ao ponto mais baixo

da curva temos o período de desilusão em relação às contramedidas usadas pelas

organizações para minimizar os efeitos finais das ameaças. Normalmente isto

ocorre porque não temos soluções maduras para tratar uma determinada classe de

ameaça.

Slope of Enlightenment - Período em que ocorre o início do amadurecimento

DBD



86

das tecnologias e organizações no tratamento das classes de ameaças. As

organizações já começam a ser capazes de operacionalizar estas tecnologias.

Plateau of Permanent Annoyance – Período em que podemos constatar a

presença na maioria das organizações de programas, tecnologias e processos

maduros para tratar classes de ameaças.

Figura 21: Hype Cycle for Cyberthreats, (extraída de Williams et al, 2006)

A cada classe de ameaças temos associado um tempo que significa o tempo

estimado para que esta classe de ameaças atinja o Plateau of Permanent

Annoyance.

Uma análise da curva acima, particularmente o item Insecure Application

Development, nos mostra que a maioria das empresas ainda não tem adotado

práticas relacionadas com o desenvolvimento seguro, conseqüentemente, métricas

de segurança. Além disso, o desenvolvimento de aplicações carece de

metodologias, processos e ferramentas que possam ser aplicadas na Engenharia de

Software seguro, principalmente nos estágios iniciais do desenvolvimento e ao

longo do ciclo de vida da aplicação (Gartner, 2006). Vulnerabilidades podem ser

DBD



87

introduzidas nas fases de análise, projeto e construção dos programas. Hoje, boa

parte dos esforços de segurança é aplicada na fase de operação e, com menor grau

de dedicação, nas fases de garantia da qualidade e testes. Como resultado disso,

software é construído com vulnerabilidades e colocado em operação. Ainda

desenvolvemos sistemas não confiáveis que resultam em muitas reclamações dos

usuários. A questão é se não somos capazes de provar corretude, usabilidade,

confiabilidade e outros requisitos não quantificáveis, como podemos reivindicar

por métricas que quantifiquem segurança?

A curva acima também nos permite concluir que ainda levaremos um tempo

para estabelecermos métricas de segurança confiáveis. Tais métricas são difíceis

porque a própria disciplina ainda está em um estágio inicial de desenvolvimento,

basta verificar (antes do pico da curva) a quantidade de classes de

vulnerabilidades ainda não adequadamente tratadas.

A seguir são detalhadas algumas dificuldades encontradas na busca por

métricas de avaliação quantitativa de segurança.

5.2 Dificuldades que encontramos na busca por métri cas

quantitativas de segurança

5.2.1 Outros campos têm números para expressar. Qua l é a

equivalência para segurança do software?

O software não obedece às leis da física (Bellovin, 2006). Na maioria dos

casos, não podemos aplicar matemática no código para provar corretude da

mesma forma que um engenheiro civil pode aplicar fórmulas para provar a

características da resistência estrutural de uma ponte.

De fato, as métricas de segurança são mais qualitativas do que quantitativas.

Como segurança é freqüentemente não quantificada, o mínimo de segurança

necessário é quase sempre um sentimento. A natureza humana e a natureza da

segurança estão em conflito neste ponto, pois as pessoas e as organizações tendem

DBD



88

a se acomodar com o passar do tempo com a situação atual, mas, de fato, a

segurança pode degradar com o passar de tempo. Tipos novos de ataques e novas

aplicações para tipos velhos de ataques podem prejudicar a segurança de um

programa – Mesmo quando uma organização torna-se mais e mais complacente

porque segurança "Não tem sido ainda um problema!".

5.2.2 Composição pode Introduzir Falhas

Não temos conhecimento sobre as conseqüências da composição de vários

mecanismos de segurança (Bellovin, 2006). A agregação de várias medidas para

reduzir vulnerabilidades pode, paradoxalmente, resultar em um sistema menos

seguro. Simplesmente não sabemos o que nós temos quando montamos um

perímetro de segurança em um sistema de informação. Não temos nenhuma

certeza de que implementamos adequadamente a composição ou que o resultado

será um sistema mais resistente se nós desenvolvemos recursos adicionais.

Qualquer um que tem tentado corretamente configurar um firewall confirmará um

falso sentimento de segurança que pode ocorrer devido à alta probabilidade de

uma só má aplicação de uma regra ou a omissão de uma simples regra,

emparelhada com a propagação de dados de configuração através da empresa, e

nós compomos a possibilidade de um compromisso seguro. Nós mantemos a

confiança na experiência de nossos administradores de sistemas ou engenheiros de

segurança e seus conhecimentos específicos para garantir a corretude do sistema.

Medir segurança a partir da composição de sistemas de segurança é hoje

algo impossível. Precisamos estudar como podemos avaliar a segurança a partir da

composição de elementos, principalmente considerando a interação entre estes

elementos. Exemplo: firewall e tecnologia Java. Como um elemento, tecnologia

Java, pode influenciar a segurança estabelecida pelo outro, firewall?

5.2.3 Pessoas e processos podem diminuir a seguranç a

Pessoas, que são por natureza propensas ao erro, constroem software. Nós

podemos avaliar certas características do processo de construção do software e das

DBD



89

pessoas que trabalham nele, mas no fim – qualquer um deles pode,

intencionalmente ou não, corromper o sistema e diminuir sua segurança. Isto torna

questionável se abrir ou não o desenvolvimento de sistemas é uma medida útil ou

um pesadelo de controle de versão.

Hoje boa parte dos problemas ocorrem dentro do próprio ambiente de

trabalho (engenharia social) . Interessante observar é que estudos do Gartner e do

CERT® comprovam que os invasores mais comuns, que realizaram os crimes mais

significativos envolvendo software, são aqueles promovidos por pessoas que hoje

têm o acesso legitimo à informação, ou que tiveram recentemente o acesso.

Mesmo depois de um ou mais processos comprovarem que são ótimos para

produzir software seguro, estes processos e práticas devem permanecer eficientes

quando utilizados por diferentes pessoas e em diferentes organizações e ambientes

de desenvolvimento de software. A comprovação desta eficiência é relativamente

difícil.

5.2.4 Falta de embasamento teórico

Muitas vezes as métricas são definidas sem um modelo formal embasado.

Requisitos de segurança são definidos baseados em modelos de segurança.

Métricas de segurança são obtidas ou por análise estatística ou testes dinâmicos

baseados nos requisitos específicos de segurança e evidência da garantia da

qualidade. Contudo, apesar de existirem inúmeros modelos de avaliação de

segurança (demonstrados no capítulo 4), tais modelos ainda não estão bem

consolidados na prática e em pesquisas acadêmicas.

A literatura carece de uma clara definição de quais propriedades devem ser

consideradas ao fazer a avaliação da segurança do software. Então, para preencher

este gap, o primeiro ponto na agenda de pesquisa deve ser a elicitação de tais

propriedades.

DBD



90

5.2.5 O aspecto tempo

O aspecto tempo não vem sendo associado com as definições atuais de

métricas de segurança. Um sistema medido hoje e considerado seguro, não

significa que seja seguro amanhã. Isto porque novas vulnerabilidades são

descobertas com o passar do tempo. Além disso, devidos as mudanças na

tecnologia, práticas de desenvolvimento, políticas de segurança e leis, uma

métrica que é significativa e útil hoje pode ser menos relevante amanhã.

Este é um aspecto importante que dificulta o estabelecimento de uma

métrica quantitativa de segurança de software.

5.2.6 Valores Lógicos Tradicionais

Os valores lógicos tradicionais, verdadeiro ou falso, parecem não ser

adequados para analisar segurança. Isto torna difícil afirmar, sem considerar uma

margem de segurança, que um sistema é totalmente seguro.

5.2.7 Terminologia de segurança

A terminologia associada à segurança tem se demostrado inconsistente, o

que tem complicado o desenvolvimento de métricas de segurança. Como podemos

medir segurança se não conseguimos definir que propriedades devem ser

consideradas para esta medição? (Vaughn et al, 2003)

5.2.8 As facilidades e recursos hoje disponíveis

É mais fácil e rápido atacar um sistema hoje do que era há 5 anos atrás

devido aos recursos de comunicação existentes e ao conhecimento compartilhado

da Internet. Esta tendência é provável que vá continuar à medida que ferramentas

de ataque são desenvolvidas mais adiante, compartilhadas, e exploradas em uma

base global (Bellovin, 2006).

DBD



91

Um atacante pode adquirir facilmente uma cópia destes aplicativos e

praticar ataques em casa. Mesmo que um sistema de detecção de intrusão puder

detectá-lo, ele não poderá reagir rapidamente contra um ataque automatizado.

5.2.9 Dificuldades dos Sistemas de Detecção de Inva são

Sistemas de detecção de invasão podem ser usados para avaliação de

segurança. Porém, sistemas de detecção de invasão são muito famosos por falsos

negativos (Bellovin, 2006). Isto compromete o uso de suas informações para a

geração de resultados de segurança. Além disso, um atacante pode comprar uma

cópia de teu sistema e praticar ataques em casa. Mesmo se um IDS puder detectá-

lo, ele não poderá reagir rapidamente contra um ataque automatizado. Neste caso,

a métrica pode não servir para muita coisa.

5.2.10 A garantia da segurança após a evolução do s oftware

Mesmo que tenha sido desenvolvido um software seguro, sua evolução, suas

correções não devem comprometer sua segurança. Geralmente, não existe uma

maneira aceitável de se verificar que suas propriedades de segurança

permaneceram após a realização destas atividades. Testes de regressão podem

minimizar este problema.

5.2.11 A complexidade de verificar segurança em gra ndes

sistemas

Verificar em grandes sistemas se a quantidade de defeitos de segurança está

em um nível aceitável é extremamente difícil. Além disso, não existe uma

taxonomia dos principais bugs de segurança existentes. (Vaughn et al, 2003)

DBD



92

5.2.12 A limitação de métodos baseados em contagem de Bugs de

segurança

A contagem de bugs pode ser usada como uma métrica de segurança.

Contudo, temos as seguintes desvantagens:

• O processo de detecção de bugs pode perder alguns bugs e pode

leventar falsos positivos,

• Igual importância é dada para todos os bugs, mesmo que alguns bugs

sejam mais fáceis de ser explorados e produzam mais prejuízos do

que outros.

5.2.13 Outras propriedades desejáveis podem afetar a segurança

como um todo

Propriedades desejáveis como safety, performance, usabilidade, etc podem

comprometer a segurança. Encontrar o ponto de equilíbrio da qualidade desejada

do software é um desafio para a Engenharia de Software.

5.2.14 Nem sempre podemos só considerar uma análise

quantitativa

De fato, a segurança de sistemas baseados em software deve ser ponderada

em relação ao ambiente humano em que o sistema é utilizado. Segurança está

relacionada com ameaças, que dependem de fatores humanos. Por exemplo,

considere a aplicação do princípio de menor privilégio para reduzir os riscos de

exploração de um código executável. Para avaliar a efetividade de tal propriedade,

o comportamento humano deve ser considerado e, portanto, tal propriedade é

difícil de ser avaliada por números.

Avaliar quantativamente por meio de métricas de software pode não ser

suficiente para compreender todas as facetas da segurança.

DBD



93

5.3 Recomendações para a Avaliação de Segurança

Apesar de todos os problemas citados acima, existem algumas métricas e

práticas usadas hoje no desenvolvimento que podem ser de forma proveitosa

entendidas para endereçar requisitos de segurança. Métricas baseadas em

densidade de defeitos hoje já são utilizadas por alguns autores (Alhazmi et al,

2006)

Nenhuma métrica de segurança de software consegue quantificar com

precisão a garantia de segurança em um sistema. Uma prova disso é que hoje não

temos ainda qualquer métrica para medir quanto esforço um inimigo esperto

gastou para explorar uma vulnerabilidade de um sistema (Bellovin, 2006). Ainda

que não tenha sido encontrada tal métrica, segundo o relatório final produzido no

1th Workshop on Information-Security-System Rating and Ranking, tais

métricas podem ser em resumo supridas, a partir de uma combinação de métricas

(Henning, 2001). As métricas podem ser combinadas com outras métricas em um

contexto específico, mesmo que pareçam não ser muito úteis em seus próprios

contextos. Por exemplo, métricas baseadas em análise de riscos podem ser

combinadas com métricas baseadas em densidade de vulnerabilidades (Alhazmi et

al, 2006). Obviamente que esta combinação não pode ser aplicada de forma

genérica em todos os domínios de interesse.

Muitas métricas supostamente consideradas subjetivas e/ou qualitativas

mostraram-se mais úteis do que métricas quantitativas (Henning, 2001). Embora

as técnicas de penetração não sejam consistentes e repetíveis, seus resultados são

úteis e significativos, sendo uma das medições mais úteis que encontramos hoje

para a garantia da segurança de sistemas.

Avaliação de riscos pode ser empregada na avaliação de segurança de

software Trabalhos como System Development Life Cycle, SDLC, (Redwine,

2004) utilizam a análise de riscos ao longo do processo de desenvolvimento. Uma

boa vantagem ao utilizarmos a técnica de avaliação de riscos como métrica de

segurança é que ela faz uma boa análise da segurança ao endereçar possibilidades

e danos. Outra boa propriedade é que ela causa defensores para combater com

DBD



94

como adversários realmente atacam sistemas.

DBD


6 Conclusões e Trabalhos Futuros

Até hoje, a ciência da computação não obteve sucesso em sua tentativa de

definir métricas de segurança de software, por não conseguir fornecer métricas

confiáveis e que sejam aceitas por todos para a avaliação da segurança de sistemas

de informação. Talvez o problema esteja em estabelecer um objetivo inadequado.

O objetivo baseado em risco poderia ser mais adequado.

Enquanto estamos buscando desenvolver um software capaz de resistir a

ataques, tornando-o confiável sob o aspecto da segurança, ainda não temos hoje

com os métodos atuais como provar que o software é seguro. Hoje só podemos

provar que o software não é seguro. Provavelmente, será muito difícil podermos

um dia provar que seja seguro. Aqui ocorre o mesmo problema que em teste:

nunca saberemos se a última vulnerabilidade foi adequadamente considerada.

Segundo Kaner e co-autores (Kaner et al., 1993), o “planejamento de testes é

governado pela necessidade de selecionar alguns poucos casos de teste de um

gigantesco conjunto de possíveis casos. Independentemente de quão cuidadoso

você seja, você deixará de incluir alguns casos relevantes. Independentemente da

perfeição e esmero do seu trabalho, você nunca encontrará a última falta, e se

encontrar, jamais o saberá.”

Nós não conseguiremos sem um maior avanço da tecnologia. Precisamos

encontrar uma maneira de fazer o software menos frágil e que seja capaz de

detectar vulnerabilidades e fechá-las, mesmo sob um ataque a segurança.

Precisamos também de um estudo mais aprofundado sobre composições de

mecanismos de segurança. Estudo este que nos dê mais do que um aumento linear

em resistência a ataques contra a segurança.

Não existe dúvida de que muito trabalho ainda precisa ser feito pela

comunidade de pesquisa e a parte restante desta seção tenta destacar algumas

DBD


Conclusões e Trabalhos Futuros

96

destas prioridades.

6.1 Trabalhos Futuros

Com relação ao tema segurança de software este trabalho sugere alguns

trabalhos futuros nas seguintes linhas de pesquisa: linguagens de programação

orientadas a segurança, técnicas de programação que facilitem a implementação

de mecanismos de segurança, prova de corretude na construção do software,

evolução do software, taxonomias para a área de segurança (bugs, classes de

ameaças, vulnerabilidades, etc), composição de elementos de segurança. Esta

dissertação também sugere os seguintes trabalhos futuros de dissertação

relacionados ao tema segurança no desenvolvimento:

1. Como extrair políticas de segurança a partir dos requisitos?

2. Projeto de interface segura

3. Práticas de testes para segurança e privacidade

4. Como identificar usuários da Internet?

5. Como verificar propriedades de segurança de artefatos de software?

6. Arquitetura segura (otimizar, melhorar; fazer melhor ou tornar mais bem

definida)

7. Como descobrir bugs de segurança em um projeto (design) de software?

8. Estudos empíricos de padrões de ataques

9. Recuperabilidade do software. Como voltar a execução de um programa,

comando após comando, por causa de vulnerabilidades de segurança?

10. Análise de modo de falha aplicada a segurança

11. Como analizar a composição de especificações de sistemas para encontrar

falhas de segurança?

12. Avaliação econômica de ataques e contramedidas.

13. Como métricas de segurança diferentes podem ser interpretadas e

correlacionadas?

14. Metodologias para identificar métricas de interesse, como o “Goal Question

Metric” (GQM) de Basili, deve ser considerada e possivelmente adaptada para

segurança. Por exemplo, “security patterns” empregados durante a fase de

design (projeto) podem conter informações sobre métricas adequadas a serem

monitoradas.

DBD


7 Referências bibliográficas

ALHAZMI, O.; MALAIYA, Y.; RAY, I. Measuring, Analyzing and Predicting

Security Vulnerabilities in Software Systems. Computer and Security

Journal, Vol. 26, 2006. p. 219-228.

ALVES-FOSS, J.; BARBOSA, S. Assessing Computer Security Vulnerability,

ACM SIGOPS Operating Systems Review, Vol. 29, No. 3., 1995. p. 3-13.

AVIZIENIS, A.; LAPRIE, J. C.; RANDELL, B.; LANDWEHR, C. Basic

Concepts and Taxonomy of Dependable and Secure Computing; IEEE

Transactions on Dependable and Secure Computing; Los Alamitos, CA:

IEEE Computer Society; 2004. p. 11-33.

BAYUK, J. L. Information Security Metrics: An Audited-based Approach. NIST

e CSSPAB Workshop, Washington, D.C, 2000.

BELLOVIN, S. M. On the Brittleness of Software and the Infeasibility of Security

Metrics. IEEE Security and Privacy, vol. 04, no. 4, 2006. p. 96.

Informações em: http://www.cs.columbia.edu/~smb [última visita:

janeiro/2007].

BROCKLEHURST, S.; LITTLEWOOD, B.; OLOVSSON, T.; JONSSON, E. On

Measurement of Operational Security, COMPASS 94 (9th Annual IEEE

Conference on Computer Assurance), Gaithersburg: IEEE Computer

Society, 1994. p. 257-266.

CANADIAN TRUSTED COMPUTER PRODUCT EVALUATION CRITERIA –

CTCPEC. Version 3.0, Canadian System Security Centre, Communications

Security Establishment, Government of Canada, January, 1993.

CERT ® COORDINATION CENTER, CERT® advisories and other security

information , CERT/CC, Pittsburgh, PA, 2006. Informações em:

http://www.cert.org/ . [última visita: janeiro/2007].

DBD


Referências bibliográficas

98

CHESS, B.; WEST, J. Secure Programming with Static Analysis. Software

Security Series; Addison-Wesley Software Security Series, 2007.

CHUNG, L.; NIXON, B.; YU, E.; MYLOPOULOS, J. Non-Functional

Requirements in Software Engineering. Kluwer Academic, 2000.

COMMON CRITERIA MUTUAL RECOGNITION AGREEMENT

PARTICIPANTS (CCRA), CC Introduction, Common Criteria Support

Environment (CCSE) , 2002. Informações em: www.commoncriteria.org).

[última visita: janeiro/2007].

CORREIA, M. P. Serviços Distribuídos Tolerantes a Intrusões: Resultados

Recentes e Problemas Abertos. V Simpósio Brasileiro em Segurança da

Informação e de Sistemas Computacionais - Livro Texto dos

Minicursos, Sociedade Brasileira de Computação, 2005. p. 113-162.

DACIER, M.; DESWARTE, Y.; KAÂNICHE, M. “Models and Tools for

Quantitative Assessment of Operational Security”, em 12th International

Information Security Conference (IFIP/SEC’96), Chapman & Hall,

Samos (Greece), 1996. p. 177-186.

DACIER, M.; DESWARTE, Y.; KAÂNICHE, M. Quantitative Assessment of

Operational Security: Models and Tools, Technical Report, LAAS Report

96493, 1996.

DAVIS, N. Developing Secure Software. Software Engineering Institute;

Carnegie Mellon University; Washington DC SPIN. April 7, 2004.

DEPARTMENT OF DEFENSE. Trusted Computer System Evaluation

Criteria – TCSEC. (Orange book) (DOD), 1985.

DEVANBU, P. T.; STUBBLEBINE, S. Software Engineering for Security: a

Roadmap. Proceedings of the Conference on The Future of Software

Engineering; ICSE 2000. Limerick, Ireland. 2000. p. 227-239.

EUROPEAN COMMUNITY. IT Security Evaluation Criteria - ITSEC .

Version 1.2, Commission of the European Communities, 1991.

(EUROPEAN ORANGE BOOK).

DBD



99

FENTON, N.; WHITTY, R.; IIZUKA, Y. Software Quality Assurance and

Measurement: A Worldwide Perspective, International Thomson Computer

Press, London. 1995.

FERREIRA, A. Novo Dicionário Aurélio – Século XXI, 3. ed. Editora Nova

Fronteira. Rio de Janeiro. 1999.

GOERTZEL, K. M.; WINOGRAD, T.; MCKINLEY, H. L.; HOLLEY, P.;

HAMILTON, B. A. Security in the Software Life Cycle, Version 1.2

(Draft); Agosto 2006.

GRAFF, M.; WYK, K. Secure Coding: Principles and Practices; O’Reilly,

2003.

HENNING, R. Information System Security Attribute Quantification or Ordering.

Proceedings of the 1th Workshop on Information-Security-System

Rating and Ranking, Williamsburg, Virginia, USA, 2001. Informações

em: http://www.acsac.org/measurement/ [última visita: janeiro/2007].

KANER, C.; FALK, J.; NGUYEN, H. Q. Testing Computer Software;

International Thompson Computer Press, 1993.

LANGWEG, H. Framework for malware resistance metrics. Conference on

Computer and Communications Security. Proceedings of the 2nd ACM

workshop on Quality of Protection, Alexandria, Virginia, USA, 2006. p.

39-44.

LANOWITZ, T. Now Is the Time for Security at the Application Level;

Gartner, Inc; 2005.

LAUDON, K. C.; LAUDON, J. P. Sistemas de Informação. Tradução de:

Alexandre Oliveira. 3. ed. Rio de Janeiro: LTC, 2001. 433 p. Título original:

Essentials of Management Information Systems.

LEVESON, N. A New Approach to System Safety Engineering; Aeronautics

and Astronautics; Massachusetts Institute of Technology. 2002. Informações

em: http://sunnyday.mit.edu/book2.html; [última visita: novembro/2005].

MANADHATA, P. An Attack Surface Metric; School of Computer Science

Carnegie Mellon University, Pittsburgh, PA 152132005, 2005.

DBD



100

MCMANUS, M.; SCAVO, F. IT Security Study: The Current State of IT Security

Budgets, Management Practices, and Security Incidents. Computer

Economics. 2006.

MINIMUM SECURITY FUNCTIONALITY REQUIREMENTS FOR

MULTI-USER OPERATING SYSTEMS – MSFR. Draft, Issue 1,

National Institute of Standards and Technology (NIST), Computer Security

Division, 1992.

NBR ISO/IEC 17799: Tecnologia da Informação – Código de Prática para a

Gestão da Segurança da Informação; Associação Brasileira de Normas

Técnicas, ABNT/CB-21 – Comitê Brasileiro de Computadores e

Processamento de Dados; 2001..

ORACLE WHITE PAPER. Computer Security Criteria: Security Evaluations

and Assessment; 2001; disponível em

www.oracle.com/technology/deploy/security/seceval/pdf/seceval_wp.pdf.

[última visita: janeiro/2007].

ORTALO, R.; DESWARTE, Y.; KAANICHE, M. Experimenting with

Quantitative Evaluation Tools for Monitoring Operational Security, IEEE

Transactions on Software Engineering. 1999. p. 633-650.

PARK, R. E.; GOETHERT, W. B.; FLORAC, W. A. Goal-Driven Software

Measurement - A Guidebook, Handbook CMU/SEI- 96-HB-002, Software

Engineering Institute, Carnegie Mellon University, Hanscom, MA, 1996.

PFLEEGER, C. P.; PFLEEGER, S. L. Security in Computing, 3. ed., Prentice-

Hall, 2003.

REDWINE, S.; DAVIS, N. Processes to Produce Secure Software. Improving

Security Across the Software Development Lifecycle (National

Cybersecurity Partnership Taskforce Report), Appendix B. 2004.

SCANDARIATO, R.; DE WIN, B.; JOOSEN, W. Towards a Measuring

Framework for Security Properties of Software. Conference on Computer

and Communications Security; Proceedings of the 2nd ACM workshop

on Quality of protection. Alexandria, Virginia, USA. 2006. p. 27-30.

DBD



101

SAYDJARI, S. “Is risk a good security metric?”. Conference on Computer and

Communications Security; Proceedings of the 2nd ACM workshop on

Quality of protection; Alexandria, Virginia, USA; 2006; p. 59 – 60.

NIST SPECIAL PUBLICATION. Security Metrics Guide for Information

Technology Systems. 800-55, 2003.

SSE-CMM Project, “Systems Security Engineering Capability Maturity Model

(SSE-CMM) Description, Version 1.0,” to be distributed at the National

Information Systems Security Conference, Baltimore, Maryland, 2003.

STAA, A. v. Engenharia de Software Fidedigno. Monografias em Ciência de

Computação, No 13/06. Pontifícia Universidade Católica do Rio de Janeiro,

PUC-Rio, 2006.

STONEBURNER, G.; HAYDEN, C.; FERINGA, A. Engineering principles for

information technology security. NIST Special Publication 800-27,

Revision A, 2004.

TIPTON, H. F.; KRAUSE, M. Information Security Management Handbook,

5. ed. ; 2004.

VAUGHN, R. B.; HENNING, R. R.; SIRAJ, A. Information Assurance Measures

and Metrics - State of Practice and Proposed Taxonomy; Proceedings of

the Hawaii International Conference on System Sciences (HICSS-36).

Waikoloa, Hawaii; 2003. p. 10.

VOAS, J.; GHOSH, A.; MCGRAW, G.; CHARRON, F.; MILLER, K. Defining

an adaptive software security metric from a dynamic software failure

tolerance measure. In Proceedings of the 11th Annual Conference on

Computer Assurance, Junho 1996. p. 250-263.

WANG, A.; Information security models and metrics. Proceedings of the 43rd

annual southeast regional conference - Volume 2; ACM Southeast

Regional Conference; Kennesaw, Georgia , 2005. p. 178-184.

WANG, C.; WULF, W. A. A Framework for Security Measurement. Proceedings

of theNational Information Systems Security Conference, Baltimore,

MD, 1997. p. 522-533.

DBD



102

WILLIAMS, A.; HALLAWELL, A.; MOGULL, R.; PESCATORE, J.;

MACDONALD, N.; GIRARD, J.; LITAN, A.; ORANS, L.; WHEATMAN,

V.; ALLAN, A.; FIRSTBROOK, P.; YOUNG, G.; HEISER, J.; FEIMAN,

J.; Hype Cycle for Cyberthreats, Gartner, Inc, 2006.

ZUBROW, D.; MCCURLEY, J.; DEKKERS, C. Measures and Measurement

for Secure Software Development; Carnegie Mellon University; 2005.

DBD


Livros Grátis( http://www.livrosgratis.com.br )

Milhares de Livros para Download: Baixar livros de AdministraçãoBaixar livros de AgronomiaBaixar livros de ArquiteturaBaixar livros de ArtesBaixar livros de AstronomiaBaixar livros de Biologia GeralBaixar livros de Ciência da ComputaçãoBaixar livros de Ciência da InformaçãoBaixar livros de Ciência PolíticaBaixar livros de Ciências da SaúdeBaixar livros de ComunicaçãoBaixar livros do Conselho Nacional de Educação - CNEBaixar livros de Defesa civilBaixar livros de DireitoBaixar livros de Direitos humanosBaixar livros de EconomiaBaixar livros de Economia DomésticaBaixar livros de EducaçãoBaixar livros de Educação - TrânsitoBaixar livros de Educação FísicaBaixar livros de Engenharia AeroespacialBaixar livros de FarmáciaBaixar livros de FilosofiaBaixar livros de FísicaBaixar livros de GeociênciasBaixar livros de GeografiaBaixar livros de HistóriaBaixar livros de Línguas










http://www.livrosgratis.com.br/cat_1/administracao/1







http://www.livrosgratis.com.br/cat_2/agronomia/1







http://www.livrosgratis.com.br/cat_3/arquitetura/1







http://www.livrosgratis.com.br/cat_4/artes/1







http://www.livrosgratis.com.br/cat_5/astronomia/1







http://www.livrosgratis.com.br/cat_6/biologia_geral/1









http://www.livrosgratis.com.br/cat_8/ciencia_da_computacao/1











http://www.livrosgratis.com.br/cat_9/ciencia_da_informacao/1











http://www.livrosgratis.com.br/cat_7/ciencia_politica/1









http://www.livrosgratis.com.br/cat_10/ciencias_da_saude/1











http://www.livrosgratis.com.br/cat_11/comunicacao/1







http://www.livrosgratis.com.br/cat_12/conselho_nacional_de_educacao_-_cne/1















http://www.livrosgratis.com.br/cat_13/defesa_civil/1









http://www.livrosgratis.com.br/cat_14/direito/1







http://www.livrosgratis.com.br/cat_15/direitos_humanos/1









http://www.livrosgratis.com.br/cat_16/economia/1







http://www.livrosgratis.com.br/cat_17/economia_domestica/1









http://www.livrosgratis.com.br/cat_18/educacao/1







http://www.livrosgratis.com.br/cat_19/educacao_-_transito/1









http://www.livrosgratis.com.br/cat_20/educacao_fisica/1









http://www.livrosgratis.com.br/cat_21/engenharia_aeroespacial/1









http://www.livrosgratis.com.br/cat_22/farmacia/1







http://www.livrosgratis.com.br/cat_23/filosofia/1







http://www.livrosgratis.com.br/cat_24/fisica/1







http://www.livrosgratis.com.br/cat_25/geociencias/1







http://www.livrosgratis.com.br/cat_26/geografia/1







http://www.livrosgratis.com.br/cat_27/historia/1







http://www.livrosgratis.com.br/cat_31/linguas/1







Baixar livros de LiteraturaBaixar livros de Literatura de CordelBaixar livros de Literatura InfantilBaixar livros de MatemáticaBaixar livros de MedicinaBaixar livros de Medicina VeterináriaBaixar livros de Meio AmbienteBaixar livros de MeteorologiaBaixar Monografias e TCCBaixar livros MultidisciplinarBaixar livros de MúsicaBaixar livros de PsicologiaBaixar livros de QuímicaBaixar livros de Saúde ColetivaBaixar livros de Serviço SocialBaixar livros de SociologiaBaixar livros de TeologiaBaixar livros de TrabalhoBaixar livros de Turismo

http://www.livrosgratis.com.br/cat_28/literatura/1







http://www.livrosgratis.com.br/cat_30/literatura_de_cordel/1











http://www.livrosgratis.com.br/cat_29/literatura_infantil/1









http://www.livrosgratis.com.br/cat_32/matematica/1







http://www.livrosgratis.com.br/cat_33/medicina/1







http://www.livrosgratis.com.br/cat_34/medicina_veterinaria/1









http://www.livrosgratis.com.br/cat_35/meio_ambiente/1









http://www.livrosgratis.com.br/cat_36/meteorologia/1







http://www.livrosgratis.com.br/cat_45/monografias_e_tcc/1







http://www.livrosgratis.com.br/cat_37/multidisciplinar/1





http://www.livrosgratis.com.br/cat_38/musica/1







http://www.livrosgratis.com.br/cat_39/psicologia/1







http://www.livrosgratis.com.br/cat_40/quimica/1







http://www.livrosgratis.com.br/cat_41/saude_coletiva/1









http://www.livrosgratis.com.br/cat_42/servico_social/1









http://www.livrosgratis.com.br/cat_43/sociologia/1







http://www.livrosgratis.com.br/cat_44/teologia/1







http://www.livrosgratis.com.br/cat_46/trabalho/1







http://www.livrosgratis.com.br/cat_47/turismo/1







métricas de segurança de softwarelivros01.livrosgratis.com.br/cp040026.pdf · métricas de...

Documents