Download PDF
ads:
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
PUC-Rio - Certificação Digital Nº 0410821/CA
ads:
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
Carlos Freud Alves Batista
Métricas de Segurança de Software
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
PUC-Rio - Certificação Digital Nº 0410821/CA
ads:
Carlos Freud Alves Batista
Métricas de Segurança de Software
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
Departamento de Informática – PUC-Rio
Profa. Karin Koogan Breitman
Departamento de Informática – PUC-Rio
Prof. José Eugenio Leal
Coordenador Setorial do CentroTécnico e Científico – PUC-Rio
Rio de Janeiro, 16 de abril de 2007
PUC-Rio - Certificação Digital Nº 0410821/CA
Todos os direitos reservados. É proibida a reprodução total ou
parcial do trabalho sem autorização da universidade, do autor e
do orientador.
Carlos Freud Alves Batista
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.
PUC-Rio - Certificação Digital Nº 0410821/CA
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.
PUC-Rio - Certificação Digital Nº 0410821/CA
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.
PUC-Rio - Certificação Digital Nº 0410821/CA
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
PUC-Rio - Certificação Digital Nº 0410821/CA
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
PUC-Rio - Certificação Digital Nº 0410821/CA
Sumário
1 I
NTRODUÇÃ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 C
ONCEITOS E
P
ROPRIEDADES
D
ESEJÁVEIS
P
ARA
U
M
S
OFTWARE
S
EGURO
....................................................................................................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
S
EGURANÇA DE
S
OFTWARE
.................................................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
PUC-Rio - Certificação Digital Nº 0410821/CA
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 A
VALIAÇÃO
Q
UANTITATIVA DE
S
EGURANÇA DE
S
ISTEMAS
............................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 D
IFICULDADES NA
G
ERAÇÃO DE
M
ÉTRICAS DE
S
EGURANÇA
Q
UANTITATIVAS
..........................................................................................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
PUC-Rio - Certificação Digital Nº 0410821/CA
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 C
ONCLUSÕES E
T
RABALHOS
F
UTUROS
......................................................95
6.1 Trabalhos Futuros ..............................................................................96
7 R
EFERÊNCIAS BIBLIOGRÁFICAS
.................................................................97
PUC-Rio - Certificação Digital Nº 0410821/CA
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
PUC-Rio - Certificação Digital Nº 0410821/CA
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
PUC-Rio - Certificação Digital Nº 0410821/CA
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
PUC-Rio - Certificação Digital Nº 0410821/CA
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
PUC-Rio - Certificação Digital Nº 0410821/CA
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.
PUC-Rio - Certificação Digital Nº 0410821/CA
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
199
7
$ 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.
PUC-Rio - Certificação Digital Nº 0410821/CA
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
PUC-Rio - Certificação Digital Nº 0410821/CA
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
PUC-Rio - Certificação Digital Nº 0410821/CA
Introdução
19
a Sarbanes-Oxley
1
(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.
PUC-Rio - Certificação Digital Nº 0410821/CA
2
Conceitos e Propriedades Desejáveis Para Um Software
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.
PUC-Rio - Certificação Digital Nº 0410821/CA
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:
PUC-Rio - Certificação Digital Nº 0410821/CA
Conceitos e Propriedades Desejáveis Para Um Software Seguro
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
PUC-Rio - Certificação Digital Nº 0410821/CA
Conceitos e Propriedades Desejáveis Para Um Software Seguro
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
PUC-Rio - Certificação Digital Nº 0410821/CA
Conceitos e Propriedades Desejáveis Para Um Software Seguro
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.
PUC-Rio - Certificação Digital Nº 0410821/CA
Conceitos e Propriedades Desejáveis Para Um Software Seguro
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.
PUC-Rio - Certificação Digital Nº 0410821/CA
Conceitos e Propriedades Desejáveis Para Um Software Seguro
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)
PUC-Rio - Certificação Digital Nº 0410821/CA
Conceitos e Propriedades Desejáveis Para Um Software Seguro
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
PUC-Rio - Certificação Digital Nº 0410821/CA
Conceitos e Propriedades Desejáveis Para Um Software Seguro
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.
PUC-Rio - Certificação Digital Nº 0410821/CA
Conceitos e Propriedades Desejáveis Para Um Software Seguro
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
PUC-Rio - Certificação Digital Nº 0410821/CA
Conceitos e Propriedades Desejáveis Para Um Software Seguro
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).
PUC-Rio - Certificação Digital Nº 0410821/CA
Conceitos e Propriedades Desejáveis Para Um Software Seguro
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.
PUC-Rio - Certificação Digital Nº 0410821/CA
Conceitos e Propriedades Desejáveis Para Um Software Seguro
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)
PUC-Rio - Certificação Digital Nº 0410821/CA
Conceitos e Propriedades Desejáveis Para Um Software Seguro
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 software 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
PUC-Rio - Certificação Digital Nº 0410821/CA
Conceitos e Propriedades Desejáveis Para Um Software Seguro
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 à
PUC-Rio - Certificação Digital Nº 0410821/CA
Conceitos e Propriedades Desejáveis Para Um Software Seguro
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.
PUC-Rio - Certificação Digital Nº 0410821/CA
Métricas de Segurança de Software
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
PUC-Rio - Certificação Digital Nº 0410821/CA
Métricas de Segurança de Software
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:
PUC-Rio - Certificação Digital Nº 0410821/CA
Métricas de Segurança de Software
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.
PUC-Rio - Certificação Digital Nº 0410821/CA
Métricas de Segurança de Software
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
PUC-Rio - Certificação Digital Nº 0410821/CA
Métricas de Segurança de Software
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 encontradas 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
PUC-Rio - Certificação Digital Nº 0410821/CA
Métricas de Segurança de Software
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.
PUC-Rio - Certificação Digital Nº 0410821/CA
Métricas de Segurança de Software
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
PUC-Rio - Certificação Digital Nº 0410821/CA
Métricas de Segurança de Software
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.
PUC-Rio - Certificação Digital Nº 0410821/CA
Métricas de Segurança de Software
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.
PUC-Rio - Certificação Digital Nº 0410821/CA
Métricas de Segurança de Software
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).
PUC-Rio - Certificação Digital Nº 0410821/CA
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 [t
1
, t
2
]. Como essa probabilidade é a área abaixo
PUC-Rio - Certificação Digital Nº 0410821/CA
Avaliação Quantitativa de Segurança de Sistemas
47
das curvas entre os limites do intervalo, a probabilidade de um defeito entre t
1
e t
2
é
∫
t
2
t
1
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 – F
i
(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)
PUC-Rio - Certificação Digital Nº 0410821/CA
Avaliação Quantitativa de Segurança de Sistemas
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ários
2
, 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.
PUC-Rio - Certificação Digital Nº 0410821/CA
Avaliação Quantitativa de Segurança de Sistemas
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
PUC-Rio - Certificação Digital Nº 0410821/CA
Avaliação Quantitativa de Segurança de Sistemas
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.
Vantagens do método
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.
PUC-Rio - Certificação Digital Nº 0410821/CA
Avaliação Quantitativa de Segurança de Sistemas
51
2. Um sistema especialista pode ser implementado a partir das
regras
Desvantagens do método
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
PUC-Rio - Certificação Digital Nº 0410821/CA
Avaliação Quantitativa de Segurança de Sistemas
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.
PUC-Rio - Certificação Digital Nº 0410821/CA
Avaliação Quantitativa de Segurança de Sistemas
53
4. Altere o valor experimentado da variável a encontrada em Z criando Z
i
,
e Execute o código seguinte em Z
i
. 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
PUC-Rio - Certificação Digital Nº 0410821/CA
Avaliação Quantitativa de Segurança de Sistemas
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)
PUC-Rio - Certificação Digital Nº 0410821/CA
Avaliação Quantitativa de Segurança de Sistemas
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)
Vantagens do método
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.
PUC-Rio - Certificação Digital Nº 0410821/CA
Avaliação Quantitativa de Segurança de Sistemas
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égios
3
, 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.
PUC-Rio - Certificação Digital Nº 0410821/CA
Avaliação Quantitativa de Segurança de Sistemas
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.
PUC-Rio - Certificação Digital Nº 0410821/CA
Avaliação Quantitativa de Segurança de Sistemas
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
PUC-Rio - Certificação Digital Nº 0410821/CA
Avaliação Quantitativa de Segurança de Sistemas
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:
PUC-Rio - Certificação Digital Nº 0410821/CA
Avaliação Quantitativa de Segurança de Sistemas
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.
PUC-Rio - Certificação Digital Nº 0410821/CA
Avaliação Quantitativa de Segurança de Sistemas
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
PUC-Rio - Certificação Digital Nº 0410821/CA
Avaliação Quantitativa de Segurança de Sistemas
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 :
E
j
= 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 METF
k
o esforço médio quando o estado k é o estado inicial
PUC-Rio - Certificação Digital Nº 0410821/CA
Avaliação Quantitativa de Segurança de Sistemas
63
e P
ki
a probabilidade condicional de transição do estado k para o estado i, então:
METF
k
=
E
k
+ ∑ P
ki *
METF
i
i Є out(k)
P
ki =
λ
ki *
E
k
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.
Vantagens do método
1. Similar ao método de Brocklehurst et al.(1994), “Esforço
despendido por um atacante”.
Desvantagens do método
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.
PUC-Rio - Certificação Digital Nº 0410821/CA
Avaliação Quantitativa de Segurança de Sistemas
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
PUC-Rio - Certificação Digital Nº 0410821/CA
Avaliação Quantitativa de Segurança de Sistemas
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.
PUC-Rio - Certificação Digital Nº 0410821/CA
Avaliação Quantitativa de Segurança de Sistemas
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(filho
1
), S(filho
2
),..., S(filho
n
)),
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ó
PUC-Rio - Certificação Digital Nº 0410821/CA
Avaliação Quantitativa de Segurança de Sistemas
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 (S
1
/NW
1
, S
2
/NW
2
,...,
PUC-Rio - Certificação Digital Nº 0410821/CA
Avaliação Quantitativa de Segurança de Sistemas
68
S
n
/NW
n
), 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 = ∑ (S
i
* W
i
), 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) = ∑ (S
i
* W
i
), 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:
PUC-Rio - Certificação Digital Nº 0410821/CA
Avaliação Quantitativa de Segurança de Sistemas
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.
PUC-Rio - Certificação Digital Nº 0410821/CA
Avaliação Quantitativa de Segurança de Sistemas
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)
PUC-Rio - Certificação Digital Nº 0410821/CA
Avaliação Quantitativa de Segurança de Sistemas
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
PUC-Rio - Certificação Digital Nº 0410821/CA
Avaliação Quantitativa de Segurança de Sistemas
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
PUC-Rio - Certificação Digital Nº 0410821/CA
Avaliação Quantitativa de Segurança de Sistemas
73
segurança ou vulnerabilidades.
Vantagens do método
1. Método simples e de fácil entendimento
Desvantagens do método
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.
PUC-Rio - Certificação Digital Nº 0410821/CA
Avaliação Quantitativa de Segurança de Sistemas
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
PUC-Rio - Certificação Digital Nº 0410821/CA
Avaliação Quantitativa de Segurança de Sistemas
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, E
s
, 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.
PUC-Rio - Certificação Digital Nº 0410821/CA
Avaliação Quantitativa de Segurança de Sistemas
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
PUC-Rio - Certificação Digital Nº 0410821/CA
Avaliação Quantitativa de Segurança de Sistemas
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.
Vantagens do método
1. Pode ser empregada na fase de desenvolvimento
Desvantagens do método
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.
PUC-Rio - Certificação Digital Nº 0410821/CA
Avaliação Quantitativa de Segurança de Sistemas
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.
PUC-Rio - Certificação Digital Nº 0410821/CA
Avaliação Quantitativa de Segurança de Sistemas
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
PUC-Rio - Certificação Digital Nº 0410821/CA
Avaliação Quantitativa de Segurança de Sistemas
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)
PUC-Rio - Certificação Digital Nº 0410821/CA
Avaliação Quantitativa de Segurança de Sistemas
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.
Vantagens do método
1. Pode ser utilizado na fase de desenvolvimento do software.
2. Pode ser usado com outros princípios.
Desvantagens do método
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
PUC-Rio - Certificação Digital Nº 0410821/CA
Avaliação Quantitativa de Segurança de Sistemas
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.
PUC-Rio - Certificação Digital Nº 0410821/CA
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.
PUC-Rio - Certificação Digital Nº 0410821/CA
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)
PUC-Rio - Certificação Digital Nº 0410821/CA
Dificuldades na Geração de Métricas de Segurança Quantitativas
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 Inseguranç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
PUC-Rio - Certificação Digital Nº 0410821/CA
Dificuldades na Geração de Métricas de Segurança Quantitativas
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
PUC-Rio - Certificação Digital Nº 0410821/CA
Dificuldades na Geração de Métricas de Segurança Quantitativas
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étricas
quantitativas de segurança
5.2.1 Outros campos têm números para expressar. Qual é 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
PUC-Rio - Certificação Digital Nº 0410821/CA
Dificuldades na Geração de Métricas de Segurança Quantitativas
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
PUC-Rio - Certificação Digital Nº 0410821/CA
Dificuldades na Geração de Métricas de Segurança Quantitativas
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.
PUC-Rio - Certificação Digital Nº 0410821/CA
Dificuldades na Geração de Métricas de Segurança Quantitativas
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).
PUC-Rio - Certificação Digital Nº 0410821/CA
Dificuldades na Geração de Métricas de Segurança Quantitativas
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 Invasã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 software
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 grandes
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)
PUC-Rio - Certificação Digital Nº 0410821/CA
Dificuldades na Geração de Métricas de Segurança Quantitativas
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.
PUC-Rio - Certificação Digital Nº 0410821/CA
Dificuldades na Geração de Métricas de Segurança Quantitativas
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
1
th
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
PUC-Rio - Certificação Digital Nº 0410821/CA
Dificuldades na Geração de Métricas de Segurança Quantitativas
94
como adversários realmente atacam sistemas.
PUC-Rio - Certificação Digital Nº 0410821/CA
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
PUC-Rio - Certificação Digital Nº 0410821/CA
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.
PUC-Rio - Certificação Digital Nº 0410821/CA
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 (9
th
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].
PUC-Rio - Certificação Digital Nº 0410821/CA
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 12
th
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).
PUC-Rio - Certificação Digital Nº 0410821/CA
Referências bibliográficas
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 1
th
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.
PUC-Rio - Certificação Digital Nº 0410821/CA
Referências bibliográficas
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.
PUC-Rio - Certificação Digital Nº 0410821/CA
Referências bibliográficas
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, N
o
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.
PUC-Rio - Certificação Digital Nº 0410821/CA
Referências bibliográficas
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.
PUC-Rio - Certificação Digital Nº 0410821/CA
Livros Grátis
( http://www.livrosgratis.com.br )
Milhares de Livros para Download:
Baixar livros de Administração
Baixar livros de Agronomia
Baixar livros de Arquitetura
Baixar livros de Artes
Baixar livros de Astronomia
Baixar livros de Biologia Geral
Baixar livros de Ciência da Computação
Baixar livros de Ciência da Informação
Baixar livros de Ciência Política
Baixar livros de Ciências da Saúde
Baixar livros de Comunicação
Baixar livros do Conselho Nacional de Educação - CNE
Baixar livros de Defesa civil
Baixar livros de Direito
Baixar livros de Direitos humanos
Baixar livros de Economia
Baixar livros de Economia Doméstica
Baixar livros de Educação
Baixar livros de Educação - Trânsito
Baixar livros de Educação Física
Baixar livros de Engenharia Aeroespacial
Baixar livros de Farmácia
Baixar livros de Filosofia
Baixar livros de Física
Baixar livros de Geociências
Baixar livros de Geografia
Baixar livros de História
Baixar livros de Línguas
Baixar livros de Literatura
Baixar livros de Literatura de Cordel
Baixar livros de Literatura Infantil
Baixar livros de Matemática
Baixar livros de Medicina
Baixar livros de Medicina Veterinária
Baixar livros de Meio Ambiente
Baixar livros de Meteorologia
Baixar Monografias e TCC
Baixar livros Multidisciplinar
Baixar livros de Música
Baixar livros de Psicologia
Baixar livros de Química
Baixar livros de Saúde Coletiva
Baixar livros de Serviço Social
Baixar livros de Sociologia
Baixar livros de Teologia
Baixar livros de Trabalho
Baixar livros de Turismo