UNIVERSIDADE DO VALE DO RIO DOS SINOS - UNISINOS

CINCIAS EXATAS E TECNOLGICAS,

PROGRAMA INTERDISCIPLINAR DE PS-GRADUAO EM COMPUTAO
APLICADA - PIPCA
NVEL MESTRADO
ANDERSON DA CRUZ
Um Sistema Multiagente para Gerao Automtica de
uma Rede Bayesiana para Anlise de Riscos de
Tecnologia de Informao
SO LEOPOLDO
2011
ANDERSON DA CRUZ
Um Sistema Multiagente para Gerao Automtica de
uma Rede Bayesiana para Anlise de Riscos de
Tecnologia de Informao
Dissertao submetida avaliao
como requisito parcial para a obteno
do grau de Mestre em Computao
Aplicada
Orientador: Prof. Dra. Patrcia Jaques
SO LEOPOLDO
2011





C957s Cruz, Anderson da
Um sistema multiagente para gerao automtica de uma
Rede Bayesiana para anlise de riscos de tecnologia de
informao / por Anderson da Cruz. So Leopoldo, 2011.

107 f. : il. ; 30 cm.

Dissertao (mestrado) Universidade do Vale do Rio
dos Sinos, Programa Interdisciplinar de Ps-Graduao em
Computao Aplicada, So Leopoldo, RS, 2011.
Orientao: Prof. Dr. Patrcia Jaques, Cincias Exatas e
Tecnolgicas.

1. Proteo de dados. 2. Administrao de risco.
3.Sistemas multiagentes. 4.Rede Bayesiana. 5.Tecnologia da
informao. I.Jaques, Patrcia. II.Ttulo.

CDU 004.056.53
004.89
004.72

Catalogao na publicao:
Bibliotecria Carla Maria Goulart de Moraes CRB 10/1252

1
Dedico este trabalho
aos meus pais e a
minha esposa.
2
AGRADECIMENTOS
Agradeo em primeiro lugar aos meus pais Normlio Francisco da Cruz e Maria Rejane
da Cruz e minha irm Janaina da Cruz, que sempre me apoiaram e incentivaram minha
evoluo pessoal, prossional e acadmica.
A minha esposa Camila Kunrath da Costa que alm de apoiar, soube compreender as
limitaes impostas por este desao.
A minha orientadora, Prof, Dra Patrcia Jaques, por ter possibilitado e apoiado
o desenvolvimento deste trabalho, pelos conselhos dados que contriburam na minha
formao como pesquisador e professor e tambm pelos conselhos relacionados a carreira
acadmica.
Ao Prof. Dr Joo Gluz, por contribuir para o trabalho com sua experincia na
utilizao de Redes Bayesianas e Sistemas Multiagentes.
Aos professores do Programa Interdisciplinar de Ps-Graduao em Computao
Aplicada da UNISINOS, que tive o privilgio de conhecer e em alguns casos, t-los como
professores durante mestrado.
Aos colegas de mestrado, que sempre mantiveram uma relao de amizade e ajudando
um ao outro nos momentos de tenso e presso no nivelamento e tambm durante as
disciplinas.
3
No conseguimos segurar uma tocha para
iluminar o caminho de outra pessoa,
sem clarearmos o nosso prprio.
Ben Sweetland
4
RESUMO
A cada ano, a informao ganha mais importncia no meio corporativo e a utilizao
de sistemas de tecnologia de informao cada vez mais comum em empresas dos mais
diversos segmentos. No entanto, estes sistemas so compostos por aplicaes que so
sujeitas a vulnerabilidades que podem comprometer a condencialidade, integridade e
disponibilidade, ou seja, a segurana destas informaes. Fornecedores de tecnologia
esto sempre corrigindo falhas em suas ferramentas e disponibilizando correo para seu
produtos para que estes se tornem mais seguros. O processo de correo de uma falha
leva um determinado tempo at que o cliente possa atualizar o seu sistema. Muitas vezes
este tempo no suciente para evitar um incidente de segurana, o que torna necessrio
solues de contorno para diminuir riscos referentes aos aplicativos vulnerveis. O processo
de anlise/avaliao na Gesto de Riscos prioriza as aes que so tomadas para mitigar
estes riscos. Este processo rduo, envolvendo a identicao de vulnerabilidades para
as aplicaes utilizadas na empresa, sendo que o nmero de vulnerabilidades aumenta
diariamente. Para apoiar na anlise de riscos de tecnologia da informao, este trabalho
prope um mtodo para gerao automtica de uma Rede Bayesiana baseado em sistemas
multiagentes. O sistema multiagente conta com quatro agentes, sendo um destinado a
monitorar as vulnerabilidades na National Vulnerability Database, outro para monitorar
os ativos que compem o negcio da organizao, outro para monitorar os incidentes
ocorridos no ambiente da organizao e outro, destinado a reunir todas estas informaes
com o intuindo de determinar um fator de risco para os ativos da organizao. Este ltimo
agente utiliza Redes Bayesianas para determinar o risco dos ativos. O mtodo proposto
mostrou-se eciente para identicar mudanas no ambiente da organizao e alterar o
risco dos ativos de acordo com os diversos fatores que inuenciam no seu clculo, como o
surgimento e/ou alterao de uma vulnerabilidade, surgimento e/ou alterao na base de
dados de congurao de ativos da organizao e identicao e/ou alterao no relato
de incidentes de segurana no ambiente da empresa. Este resultado deve-se a utilizao
de Redes Bayesianas para calcular o risco dos ativos, visto que esta capaz de considerar
a relao causal entre os ativos da organizao.
Palavras-chave: Gesto de Risco, Redes Bayesianas, Sistemas Multiagentes.
5
TITLE: A Multi-agent System for Automatic Generation of a Bayesian Network Based
Risk Analysis of Information Technology
ABSTRACT
Every year information gains more signicance in the corporative scenario and
information technology system use is incresingly more commom on dierent segment
companies. However, these systems are composed by applications that are under
vulnerabilities that can compromise the condentiality, integrity and availability, i.e.
infomation security. Technology providers are always correcting aws in their tools and
providing it for their products in order for them to be safer. The aw correction process
considers some time until the client update his system. Many times this window is not
enough to avoid a security incident, which turns necessary workarounds for minimizing
risks concerning these vulnerable applications. The risks evaluation/analysis process
aims primarily actions to mitigate these risks. This process is ardous, involving the
identication of vulnerabilities in the used applications of a company, with this number
growing each day. For supporting the information technology risks evaluation/analysis, a
method for automated generation of a Bayesian Network multiagent system was proposed.
This system is composed by four agents, one being destinated to monitoring vulnerabilities
in National Vulnerability Database, another one for monitoring actives that compose the
organition business, another one is responsible for to monitor the incidents occured in the
organization enviroment and another one to gather all these information with the objective
of determining a risk factor for the organization actives. The last one uses a Bayesian
Network in order to determine the risk factor for the organization actives. The proposed
method has shown to be eective in the identication of enviroment changes and in the
changing of active risks according with several factors that inuence its calculation, such
as the emergence or changing of vulnerabilities, emergence or alteration on the business
organization actives conguration database or identication and alteration of security
incidents report on the company enviroment.
Keywords: Risk Management, Bayesian Network, Multi-agent System.
6
LISTA DE FIGURAS
Figura 1.1 Nmero de vulnerabilidades por ano, segundo o NVD . . . . . . . . 17
Figura 1.2 Nmero de incidentes por ano, segundo CERT.br . . . . . . . . . . 18
Figura 2.1 Governanas especcas no contexto da governana corporativa . . . 24
Figura 2.2 Fluxograma de gesto de risco em segurana da informao(ABNT,
2008). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Figura 2.3 Mtricas e equaes do CVSS (MELL et al., 2007). . . . . . . . . . 39
Figura 3.1 Uma Rede Causal para o problema ao ligar o carro (JENSEN e
NIELSEN, 2007). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Figura 3.2 Conexo serial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Figura 3.3 Exemplo de conexes em uma Rede Causal. . . . . . . . . . . . . . 49
Figura 3.4 Rede causal para o problema de ligar o carro. . . . . . . . . . . . . 51
Figura 3.5 Exemplo de uma Rede Bayesiana com as Tabelas de Probabilidade
Condicional. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Figura 4.1 Um agente em um ambiente. (RUSSEL e NORVIG, 2004) . . . . . 58
Figura 4.2 Estrutura tpica de um sistema multiagente (WOOLDRIDGE, 2001). 60
Figura 4.3 Diagrama da metodologia Prometheus . . . . . . . . . . . . . . . . 62
Figura 5.1 Arquitetura do ferramenta AURUM . . . . . . . . . . . . . . . . . . 67
Figura 6.1 Viso geral do sistema multiagente proposto . . . . . . . . . . . . . 69
Figura 6.2 Modelo ER da base de dados DB Vulnerability . . . . . . . . . . . . 71
Figura 6.3 Modelo ER da base de dados DB Asset . . . . . . . . . . . . . . . . 72
Figura 6.4 Modelo ER da base de dados DB Incident . . . . . . . . . . . . . . 74
Figura 6.5 Modelo ER da base de dados DB Risk . . . . . . . . . . . . . . . . 75
Figura 6.6 Fluxo para adio de um ativo computacional na Rede Bayesiana. . 80
Figura 6.7 Exemplo de conexes em uma Rede Causal. . . . . . . . . . . . . . 81
7
Figura 6.8 Grafo representando a Rede Bayesiana gerada at a etapa trs da
simulao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Figura 6.9 Grafo representando a Rede Bayesiana gerada at a etapa quatro
da simulao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Figura 6.10 Grafo representando a Rede Bayesiana gerada at a etapa cinco da
simulao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Figura 6.11 Grafo representando a Rede Bayesiana gerada at a etapa seis da
simulao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Figura 6.12 Grafo representando a Rede Bayesiana gerada at a etapa sete da
simulao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Figura 6.13 Evoluo do risco durante a simulao . . . . . . . . . . . . . . . . 99
Figura 6.14 Evoluo do impacto durante a simulao . . . . . . . . . . . . . . 99
Figura 6.15 Evoluo do risco durante a simulao . . . . . . . . . . . . . . . . 100
8
LISTA DE TABELAS
Tabela 2.1 Relao entre nomes de organizaes, domnios e descrio do
vendedor de um nome CPE . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Tabela 2.2 Abreviaes de nomes de produtos . . . . . . . . . . . . . . . . . . 37
Tabela 2.3 Abreviaes utilizadas em nomes de produtos. . . . . . . . . . . . . 38
Tabela 3.1 Tabelas de probabilidade condicional para Rede Bayesiana do
problema ao ligar o carro. . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Tabela 6.1 Mensagens trocadas com o agente ag asset". . . . . . . . . . . . . . 77
Tabela 6.2 Mensagens trocadas com o agente ag incident. . . . . . . . . . . . 77
Tabela 6.3 Mensagens trocadas com o agente ag vulnerability". . . . . . . . . 78
Tabela 6.4 Ativos que compem o ativo computacional Zeus. . . . . . . . . . . 89
Tabela 6.5 Ativos que compem o ativo computacional Apolo. . . . . . . . . . 90
Tabela 6.6 Ativos que compem o ativo computacional W140. . . . . . . . . . 90
Tabela 6.7 Ativos que compem o ativo computacional W265. . . . . . . . . . 91
Tabela 6.8 Ativos que compem ao ativo computacional W126. . . . . . . . . . 91
Tabela 6.9 Risco obtidos durante a simulao. . . . . . . . . . . . . . . . . . . 93
Tabela 6.10 Probabilidades obtidas durante a simulao. . . . . . . . . . . . . . 93
Tabela 6.11 Impactos obtidos durante a simulao. . . . . . . . . . . . . . . . . 94
9
LISTA DE ALGORITMOS
Algoritmo 3.1 ASK-ENUMERATION-JOIN . . . . . . . . . . . . . . . . . . . 54
Algoritmo 3.2 ENUMERATE-JOIN . . . . . . . . . . . . . . . . . . . . . . . . 55
Algoritmo 3.3 ASK-ENUMERATION . . . . . . . . . . . . . . . . . . . . . . . 55
Algoritmo 3.4 ENUMERATE-ALL . . . . . . . . . . . . . . . . . . . . . . . . 56
Algoritmo 6.1 Algoritimo para gerao de TPC . . . . . . . . . . . . . . . . . 82
Algoritmo 6.2 GENERATE-CPT . . . . . . . . . . . . . . . . . . . . . . . . . 82
10
LISTA DE SIGLAS
STI - Sistema de Tecnologia da Informao
TI - Tecnologia da Informao
GTI - Governana de Segurana da Informao
ISG - Information Security Governance
ITG - Information Technology Governance
SGSI - Sistema de Gesto de Segurana da Informao
NVD - National Vulnerability Database
SI - Segurana da Informao
CISR - Center for Information System Research
CVE - Common Vulnerabilities and Exposures
CPE - Common Platform Enumeration
CCE - Common Conguration Enumeration
URI - Uniform Resource Identiers
IETF - Internet Engineering Task Force
RFC - Request for Comments
SMA - Sistema Multi Agente
IDA - Inteligncia Articial Distribuda
IA - Inteligncia Articial
UML - Unied Modeling Language
TPC - Tabela de Probabilidade Condicional
11
SUMRIO
1 INTRODUO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.1 MOTIVAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2 PROBLEMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3 OBJETIVOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.4 ORGANIZAO DO TEXTO . . . . . . . . . . . . . . . . . . . . . . . . . 19
2 SEGURANA DA INFORMAO . . . . . . . . . . . . . . . . . . . 20
2.1 DEFINIO DE SEGURANA DA INFORMAO . . . . . . . . . . . . 20
2.1.1 Propriedades de Segurana da Informao . . . . . . . . . . . . . . . 22
2.2 SEGURANA DA INFORMAO E GOVERNANA EM SI . . . . . . . 23
2.3 GESTO DE RISCO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.1 Identicao de riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3.1.1 Identicao de ativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3.1.2 Identicao de ameaas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3.1.3 Identicao de controles existentes . . . . . . . . . . . . . . . . . . . . . . 30
2.3.1.4 Identicao de vulnerabilidades . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3.1.5 Identicao de conseqncias . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3.2 Estimativa de Riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3.3 Gesto de Riscos e Redes Bayesianas . . . . . . . . . . . . . . . . . . 32
2.4 BASE DE DADOS DE VULNERABILIDADES . . . . . . . . . . . . . . . 33
2.4.1 Common Platform Enumeration . . . . . . . . . . . . . . . . . . . . . 34
2.4.1.1 Componentes de um nome CPE . . . . . . . . . . . . . . . . . . . . . . . . 36
2.4.2 Common Vulnerability Scoring System . . . . . . . . . . . . . . . . . 38
2.4.2.1 Mtricas bsicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.4.2.2 Mtricas temporais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.4.2.3 Mtricas de Ambiente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.4.2.4 Clculo da pontuao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
12
3 REDES BAYESIANAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.1 REDES CAUSAIS E D-SEPARATION . . . . . . . . . . . . . . . . . . . . 46
3.2 DEFINIO DE REDES BAYESIANAS . . . . . . . . . . . . . . . . . . . 49
3.3 INFERNCIA EM REDES BAYESIANAS . . . . . . . . . . . . . . . . . . 53
4 SISTEMAS MULTIAGENTES . . . . . . . . . . . . . . . . . . . . . . 57
4.1 AGENTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2 DEFINIO DE SISTEMA MULTIAGENTE . . . . . . . . . . . . . . . . 59
4.3 METODOLOGIA PROMETHEUS . . . . . . . . . . . . . . . . . . . . . . 61
4.3.1 Especicao do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.3.2 Design Arquitetural . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.3.3 Design Detalhado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5 TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . . . . . . 65
6 TRABALHO PROPOSTO . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.1 CENRIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.2 BASES DE DADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.2.1 DB Vulnerability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.2.2 DB Asset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.2.3 DB Incident . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.2.4 DB Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.3 AGENTES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.3.1 Ag Asset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.3.2 Ag Incident . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.3.3 Ag Vulnerability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.3.4 Ag Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.4 CRIAO DA REDE BAYESIANA . . . . . . . . . . . . . . . . . . . . . . 79
6.4.1 Identicar e Relacionar os Ns . . . . . . . . . . . . . . . . . . . . . . 79
6.4.2 Determinar Pesos e Escalas . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.4.3 Validar a Rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
13
6.5 CLCULO DO RISCO DE TI . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.6 IMPLEMENTAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.7 AVALIAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.7.1 Simulao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.7.2 Anlise dos Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
7 CONCLUSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
7.1 TRABALHOS FUTUROS . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
BIBLIOGRAFIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
14
1 INTRODUO
A introduo apresenta os fatores que serviram como motivao para o
desenvolvimento deste trabalho, assim como o problema que abordado e o objetivo que
se deseja alcanar com a realizao do trabalho. A Seo 1.1 apresenta a atual realidade
das organizaes e explica brevemente o motivo pelo qual a gesto de riscos assunto de
grande importncia para estas organizaes. O problema existente na anlise/avaliao de
risco, que uma fase importante da gesto de risco, abordado na Seo 1.2. Finalizando
o Captulo, exposto na Seo 1.3, o objetivo que o trabalho busca atingir para contribuir
com o problema apresentado na Seo 1.2.
1.1 MOTIVAO
A informao torna-se cada vez mais vital para uma organizao, sendo capturada,
armazenada, processada e transmitida atravs de Sistemas de Tecnologia da Informao
(STI). Estes sistemas esto expostos a um vasto nmero de ameaas, que oferecem
um grande risco para as informaes, ameaando a condencialidade, integridade e
disponibilidade (CID)
1
de tais informaes (SOLMS e SOLMS, 2009).
Atualmente, o grande desao para proteger a informao utilizar uma disciplina que
garanta a segurana da informao em meios eletrnicos e que as protejam contra riscos
que possam surgir. A quantidade de regulamentaes legais as quais as organizaes so
submetidas torna esse desao ainda maior (SOLMS e SOLMS, 2009).
Segurana da Informao uma disciplina que visa garantir a proteo desejada para
a informao. A Governana em Segurana da Informao um ambiente completo
destinado a garantir esta proteo e sendo considerado um componente essencial para o
sucesso da gesto da organizao (SOLMS e SOLMS, 2009). A fragilidade da segurana
da informao exige que sejam tomadas medidas imediatas para assegurar que os dados
no sejam comprometidos e que os sistemas de informao permaneam seguros (ISG,
2004).
A Gesto de Risco apontada pelos guias de melhores prticas em governana como
sendo uma das maiores responsabilidades da Governana Corporativa, visto que existem
muitos tipos de riscos a serem geridos nas organizaes, tais como: riscos nanceiros,
humanos etc (SOLMS e SOLMS, 2009). Guias de melhores prticas em Segurana da
Informao, como a norma ABNT ISO/IEC 27001:2006, mais comumente conhecida como
1
CID - Condencialidade, integridade e disponibilidade so propriedades de segurana da informao
e sero abordadas na Seo 2.1.1.
15
ISO 27001, tambm salientam a importncia e a necessidade da Gesto de Risco (ABNT,
2006).
Um dos riscos ou tipos de riscos administrveis mais importantes so aqueles
relacionados com a Tecnologia da Informao (TI) baseada em infraestrutura, como
redes, banco de dados, etc. Essas infraestruturas geralmente manipulam todos os ativos
2
eletrnicos da organizao e se essa viesse a perder esta infraestrutura, isso poderia gerar
a paralisao do negcio da organizao (SOLMS e SOLMS, 2009).
Pode-se perceber que a idia de risco e Gesto de Risco o cerne da Governana
Corporativa e tambm que o uso de qualquer sistema baseado em TI gera srios riscos
para uma organizao. Sendo assim, a competncia de gerir riscos gerados pelo uso de TI
tambm o cerne da Governana em Tecnologia da Informao (GTI) (SOLMS e SOLMS,
2009).
O motivo pelo qual a gesto de riscos de TI um dos componentes mais importantes
da Governana em Tecnologia da Informao o fato de que os sistemas de tecnologia de
informao se tornam ativos eletrnicos da organizao, incluindo nisto:
todos os dados e informaes armazenadas eletronicamente em arquivos e banco de
dados;
todos os dados e informaes transmitidas pela rede; e
todos os sistemas e aplicaes necessrias para armazenar, transmitir e processar
dados e informaes.
Ativos eletrnicos possuem muitas ameaas, que podem afet-los de diversos modos,
porm, os mais relevantes so os relacionadas ao comprometimento das propriedades
da segurana desses recursos. Isso faz com que se torne importante garantir estas
propriedades perante um vasto nmero de ameaas que tentam compromet-los. Estas
ameaas podem ser (SOLMS e SOLMS, 2009):
ataques externos como ataques maliciosos da internet atravs de vrus, malware etc;
ataques internos de funcionrios descontentes;
ataques internos de erros gerados por funcionrios; e
ataques fsicos como roubo, incndio etc.
2
A denio de ativo apresentada na Seo 2.1.
16
A concretizao das ameaas, os ataques, podem gerar srios riscos aos ativos de uma
organizao, podendo levar at mesmo a paralisao de seu processo de negcio. No
entanto, o benefcio da segurana da informao no apenas a reduo de riscos ou a
reduo do impacto sobre a organizao, se algo prejudicial vier a ocorrer. Outros retornos
que a segurana da informao gera organizao so reputao e conana do cliente
e das pessoas que conduzem os negcios, podendo at melhorar sua ecincia, evitando
perda de tempo e esforos relacionados a recuperao de um incidente de segurana (ITGI,
2006).
1.2 PROBLEMA
A informao um ativo to importante em uma organizao quanto qualquer outro,
sendo essencial para os negcios de uma organizao, necessitando ento, de uma proteo
adequada. Isso se deve principalmente ao fato que essa informao se encontra em um
ambiente de negcio cada vez mais interconectado, que a expe a um crescente nmero e
a uma grande variedade de ameaas e vulnerabilidades (ABNT, 2005).
Muitos sistemas de informao no foram projetados para serem seguros e a
capacidade de se obter segurana atravs de meios tcnicos limitada. Devido a
esta limitao, os sistemas de informao devem ser apoiados por uma gesto e por
procedimentos aprimorados (ABNT, 2005).
Para se alcanar tal proteo, normas e/ou manuais de melhores prticas em
Segurana da Informao so utilizados, como por exemplo, a ABNT NBR ISO/IEC
27002:2005, que apresenta os controles necessrios para um Sistema de Gesto de
Segurana da Informao (SGSI), que especicado pela norma ABNT NBR ISO/IEC
27001:2006 (SOLMS e SOLMS, 2009).
A ABNT NBR ISO/IEC 27002:2005 sugere que uma avaliao de risco seja realizada
no incio do processo de Gesto de Segurana da Informao, ajudando ento a direcionar
e a determinar as aes apropriadas e prioritrias para o gerenciamento de riscos de
segurana da informao e para a implementao dos controles selecionados para a
proteo contra estes riscos (ABNT, 2005). A anlise/avaliao de riscos quantica ou
descreve o risco qualitativamente, possibilitando ento aos gestores priorizar os riscos de
acordo com sua gravidade ou critrios estabelecidos (ABNT, 2008).
Uma boa anlise/avaliao de risco vital para a etapa de tratamento de risco.
possvel que o tratamento de risco no resulte em um nvel aceitvel de risco residual,
tornando necessria uma nova iterao na anlise/avaliao de risco (ABNT, 2008).
A etapa de anlise/avaliao de riscos composta por duas atividades: (i) a anlise
17
de riscos, que por sua vez possui duas tarefas e (ii) a avaliao de riscos. A anlise de
risco tem com propsito a identicao de riscos, bem como a estimativa destes mesmos
riscos. Esse propsito obtido atravs das suas duas tarefas, que so a identicao de
risco e a estimativa de risco (ABNT, 2008).
Existem diversos modos de se identicar riscos, no entanto, todas partem da idia
bsica de identicar os ativos, ameaas e preferencialmente vulnerabilidades (SOLMS e
SOLMS, 2009).
Analisando relatrios gerados pelo National Vulnerability Database (NVD)
3
sobre as
vulnerabilidades reportadas, possvel perceber o elevado nmero de vulnerabilidades
reportadas todos os anos, como mostra a Figura 1.1. O mesmo ocorre com o nmero
de incidentes reportados ao CERT.br
4
, que mostra um crescimento em incidentes de
segurana a cada ano, como mostra a Figura 1.2.
Figura 1.1: Nmero de vulnerabilidades por ano, segundo o NVD
A Figura 1.1 mostra um aumento signicante de vulnerabilidades em ativos eletrnicos
reportadas ao NVD entre os anos de 2004 e 2006. Aps o ano de 2006, o nmero de
vulnerabilidades encontradas nestes ativos manteram-se entre de 5.632 e 6.608 ao ano.
Isso signica que, aproximadamente, dezessete novas vulnerabilidades aparecem a cada
dia, aumentando o risco de organizaes que utilizam estes ativos.
A Figura 1.2 ilustra o crescimento no nmero de incidentes reportados ao CERT.br a
partir do ano de 2006, chegando a aumentar cerca de 473% no intervalo entre 2006 e 2009.
O nmero de incidentes em 2006 foi 75.722 ao ano e em 2009 de 358.343. Incidentes sempre
geram algum prejuzo as organizaes, ento pode-se armar que o prejuzo relacionado
3
http://nvd.nist.gov/
4
http://cert.br
18
Figura 1.2: Nmero de incidentes por ano, segundo CERT.br
segurana da informao tambm cresceu nos ltimos dez anos.
Considerando que os sistemas de informao existentes em organizaes esto expostos
a diversos tipos de ameaas segurana da informao, incluindo fraudes eletrnicas,
espionagem, sabotagem e vandalismo (ABNT, 2005), o alto nmero de vulnerabilidades
reportadas e o aumento de incidentes de segurana envolvendo estes sistemas, a
anlise/avaliao de riscos de sistemas de tecnologia da informao se torna cada vez
mais complexa e tambm necessria.
Um dos principais motivos pelo qual a anlise/avaliao de riscos to complexa
a relao existente entre os ativos da organizao. O no funcionamento de ativo
pode impactar diretamente no funcionamento de outros ativos. Sendo assim, necessrio
considerar o risco de todos os ativos do qual um determinado ativo depende para se obter
um valor de risco adequado.
1.3 OBJETIVOS
Este trabalho tem como objetivo implementar um sistema multiagente que auxilie na
atividade de anlise de risco. O sistema gerar automaticamente uma Rede Bayesiana,
com base nos dados obtidos da organizao e de uma base de dados de vulnerabilidades.
Esta Rede Bayesiana ser utilizada no sistema para estimar o risco relacionado segurana
da informao dentro da organizao.
Uma abordagem multiagente permite reduzir a complexidade de um sistemas criando
componentes modulares que executam sub-tarefas que juntas constituem um objetivo,
que neste caso, auxiliar na atividade de anlise de riscos de tecnologia da informao.
19
O sistema conta com um agente responsvel por monitorar a base de dados de
vulnerabilidades NVD, identicando novas vulnerabilidades e tambm a alterao em
vulnerabilidades j existentes. Outro agente responsvel por identicar novos ativos
na base de dados de congurao de ativos (interna) e tambm alteraes em sua
congurao. Os incidentes de segurana da informao ocorridos na organizao so
monitorados por um terceiro agente, assim como alteraes de seus dados.
Todas as informaes coletadas por estes agentes so repassadas a um quarto agente
que ser responsvel por criar dinamicamente uma Rede Bayesiana, que ser utilizada
para calcular o risco dos ativos existentes na organizao. Com a utilizao de Redes
Bayesianas para determinar o riscos dos ativos, possvel considerar a relao entre os
ativos, permitindo identicar alteraes que podem ser ignoradas por outras formas de
clculo, que dependem da percepo humana para considerar as relaes entre os ativos.
1.4 ORGANIZAO DO TEXTO
O Captulo 2 apresenta a denio de Segurana da Informao, apresentando os
principais termos e nomenclaturas. A disciplina de Segurana da Informao relacionada
com Governana em Segurana da Informao, deixando evidente a necessidade mtua
da Gesto de Risco. As atividades necessrias para a Gesto de Riscos, tendo um
maior foco na tarefa de identicao de riscos, sendo essa relacionada com o objetivo
do trabalho. Bases de dados de vulnerabilidades, que fornecem informaes importantes
para especialistas em segurana, tambm so abordadas no Captulo 2, juntamente com
o clculo de pontuao para vulnerabilidades. O Captulo 3 introduz Redes Causais e o
conceito de d-separation, que servem como base para as denies de Redes Bayesianas,
tambm apresentadas neste captulo. Os conceitos e denies de Agentes e Sistemas
Multiagentes so apresentados no Captulo 4, juntamente com a metodologia Prometheus
para desenvolvimento de sistemas multiagente, que utilizada neste trabalho. Os
trabalhos relacionados que foram utilizados como idia inicial para o presente trabalho so
apresentados no Captulo 5. O trabalho proposto apresentado no Captulo 6. Nele so
apresentados os cenrios, base de dados, agentes, percepes, aes e como ser gerada
a Rede Bayesiana no sistema proposto. Finalizando o trabalho, so apresentadas as
consideraes nais no Captulo 7.
20
2 SEGURANA DA INFORMAO
Como visto no Captulo 1, a Segurana da Informao uma disciplina que tem como
objetivo garantir a condencialidade, integridade e a disponibilidade das informaes
armazenadas em meios eletrnicos, ou seja, garantir a segurana destas informaes.
Sendo esta disciplina integrante da Governana em Segurana da informao e tambm
relacionada s atividades de Gesto de Risco de ativos de TI, este captulo se destina
a apresentar os principais conceitos de Segurana da Informao para uma melhor
compreenso do trabalho proposto.
Este captulo apresenta, na Seo 2.1, a denio de Segurana da Informao,
apresentando os principais termos e nomenclaturas, a famlia de normas 27000 juntamente
com o seu propsito e os controles de segurana que so beneciados com este trabalho.
Na Seo 2.2, a disciplina de Segurana da Informao relacionada com Governana em
Segurana da Informao, deixando evidente a necessidade mtua da Gesto de Risco.
Na Seo 2.3, sero apresentadas todas as atividades necessrias para a Gesto de Riscos,
tendo um maior foco na tarefa de identicao de riscos, sendo essa relacionada com o
objetivo do trabalho. Finalizando o captulo, a Seo 2.4 apresenta o tema das bases de
dados de vulnerabilidades, que fornecem informaes importantes para especialistas em
segurana.
2.1 DEFINIO DE SEGURANA DA INFORMAO
Antes de apresentar a denio de Segurana da Informao, necessrio denir o
que um ativo. Um ativo qualquer coisa que tenha valor para a organizao (ABNT,
2006). Podemos dar como exemplos de ativos de uma organizao: os funcionrios, a
imagem da organizao perante seus clientes, seu patrimnio, etc. Os ativos podem ser
classicados em subconjuntos, como por exemplo, ativos eletrnicos, que aparecem com
maior freqncia neste trabalho. Por este fato, quando o termo ativo aparecer no texto,
este est se referindo especicamente a um ativo eletrnico.
A forma mais objetiva para se denir Segurana da Informao utilizando a denio
da norma ABNT NBR ISO/IEC 27001:2006, que a apresenta como a preservao da
condencialidade, integridade e disponibilidade da informao e de outras propriedades,
como autenticidade, responsabilidade, no repdio e conabilidade (ABNT, 2006).
Smola (2003) corrobora esta denio e ainda complementa como sendo uma rea do
conhecimento dedicada proteo de ativos da informao contra acessos no autorizados,
alteraes indevidas ou sua indisponibilidade. O autor a conceitua como um m alcanado
21
por meio de prticas e polticas voltadas a uma padronizao operacional e gerencial dos
ativos e processos que manipulam e executam a informao.
A norma ABNT NBR ISO/IEC 27002:2005 dene Segurana da Informao como
sendo a proteo da informao de vrios tipos de ameaas para garantir a continuidade
do negcio, minimizar o risco ao negcio, maximizar o retorno sobre os investimentos e
as oportunidades de negcio (ABNT, 2005).
A denio mais completa, e tambm complexa, apresentada por Solms e Solms
(2009), em que esta aparece como sendo uma disciplina multi-dimencional direcionada
para a Governana em Segurana da Informao. Os autores defendem esta teoria
armando que Segurana da Informao s pode ser implementada com sucesso e
ecientemente em uma organizao se todas as suas dimenses forem abordadas de uma
forma holstica e compreensvel (SOLMS e SOLMS, 2009).
As dimenses propostas por Solms e Solms (2009) so:
Dimenso da governana (corporativa);
Dimenso organizacional;
Dimenso de gesto;
Dimenso de polticas (de SI);
Dimenso de melhores prticas;
Dimenso tica;
Dimenso de certicao;
Dimenso legal;
Dimenso de garantia;
Dimenso humana;
Dimenso de conscincia;
Dimenso tcnica;
Dimenso mtricas;
Dimenso de auditoria; e
Dimenso forense em TI.
22
Analisando estas denies, possvel perceber uma relao entre estas. A base para
todas as denies sempre corrobora com a primeira denio apresentada neste trabalho,
a da norma ABNT NBR ISO/IEC 27001:2006, que tem como base as trs principais
propriedades de segurana. Solms e Solms (2009) apenas consideram em sua denio o
contexto em que se tenta garantir estas propriedades.
2.1.1 Propriedades de Segurana da Informao
Ao longo do texto, os termos integridade, condencialidade e disponibilidades
aparecem sempre relacionados entre si e vinculados a denies de Segurana da
Informao. Isso ocorre porque estes so os pilares da Segurana da Informao.
As denies destas propriedades so simples e objetivas, no entanto, a forma com
que estas so relacionadas para se obter a segurana da informao requer um pouco
mais de ateno, pois esta depende da utilizao dos ativos de informao em que as
propriedades esto sendo aplicadas. Devido a simplicidade e objetividade das denies
destas propriedades, este trabalho se baseia nas denies da norma ABNT NBR ISO/IEC
27001:2006 (ABNT, 2006).
Integridade a propriedade que garante que a informao no ser alterada
ou destruda sem a autorizao adequada. Para melhor entender esta propriedade,
pode-se imaginar um documento eletrnico contendo um contrato qualquer. Este tem
a sua integridade preservada enquanto seu contedo no seja alterado por algum no
autorizado (ABNT, 2006).
A condencialidade garante que a informao no ser revelada sem autorizao
adequada. Utilizando ainda o exemplo do documento eletrnico, imagine que este
extremamente sigiloso e no pode nem ao menos ser acessado por uma pessoa no
autorizada. Ento este tem sua condencialidade preservada enquanto seu contedo no
seja acessado por algum no autorizado (ABNT, 2006).
Por m, a disponibilidade garante que a informao estar acessvel aos usurios
legtimos quando solicitada. No mesmo exemplo, imagine que as duas propriedades
anteriores esto preservadas e que no momento em que uma das partes autorizadas for
abrir o documento para imprimir, o computador no liga. Neste caso sua disponibilidade
est comprometida at que o computador funcione (ABNT, 2006).
Alm destas trs propriedades de segurana da informao, existem outras que so
complementares a estas, que so autenticidade, no repdio e conabilidade.
Autenticidade garante que a informao foi realmente criada ou emitida por um
23
determinado autor/emissor e obtida principalmente por infraestrutura de chaves pblicas
(criptograa). Em um caminho inverso, o no repdio garante que o autor/emissor no
possa negar a autenticidade da informao.
Conabilidade a propriedade que representa a capacidade de um ativo
desempenhar satisfatoriamente a sua funo em condies de operao estabelecidas e
em um perodo de tempo predeterminado.
Com base nessas denies, pode-se armar que a segurana da informao violada
quando h a quebra de uma ou mais propriedades de segurana. Sendo a violao de
segurana relacionada com as propriedades de segurana, pode-se classic-las em trs
categorias:
Violao de integridade: modicao no autorizada da informao;
Violao de condencialidade: revelao no autorizada da informao;
Violao de disponibilidade: negao de servio.
2.2 SEGURANA DA INFORMAO E GOVERNANA EM SI
Termos como Segurana da Informao, Governana Corporativa, Governana de
Tecnologia da Informao e Governana de Segurana da Informao aparecem neste
trabalho justicando a importncia da Gesto de Risco em uma organizao. A relao
existente entre estes termos tnue, podendo levar a dvidas. Esta Seo aborda a relao
existente entre essas reas/disciplinas, propiciando um melhor entendimento sobre o tema.
No meio corporativo, a governana recebe o nome de Governana Corporativa, que
denida como o conjunto de relaes estabelecidas entre gestores de uma organizao, seus
conselhos de administrao, acionistas e demais interessados, como: credores, governos,
sociedade, fornecedores, funcionrios, entre outros (BRURE et al., 2007).
Governana Corporativa tambm pode ser denida como uma relao entre
investidores que regula e controla a direo estratgica e o desempenho das organizaes,
estando voltada para a identicao de prticas que garantam que as decises sejam
tomadas de forma correta (VEIGA, 2006).
No Brasil, o IBGC - Instituto Brasileiro de Governana Corporativa - lanou em
1990 o primeiro Cdigo de Prticas de Governana Corporativa, fundamentado em quatro
princpios bsicos: a transparncia, a eqidade
1
, a prestao de contas e a responsabilidade
corporativa (BRURE et al., 2007).
1
Segundo o dicionrio Michaelis: Disposio para reconhecer imparcialmente o direito de cada
acionista. Igualdade, justia, retido.
24
A Governana Corporativa est em processo evolutivo e acredita-se que este processo
est apenas comeando. Uma iniciativa que demonstra isso o Sarbanes-Oxley Act,
uma lei que adiciona mais responsabilidades aos administradores pblicos sob a forma de
penalidades criminais. A Sarbanes-Oxley Act teve impacto sobre companhias abertas que
tem seus papis negociados no mercado americano (BRURE et al., 2007) .
Na Governana Corporativa, podem existir governanas especcas responsveis por
gerir reas de uma organizao, como a Governana de Tecnologia de Informao (TI),
Governana de Segurana da Informao (SI) e Governana Ambiental. Dentre as citadas,
a Governana de Tecnologia da Informao e a Tecnologia de Segurana da Informao
esto mais prximas, sendo que uma inuncia na outra.
Figura 2.1: Governanas especcas no contexto da governana corporativa
A Figura 2.1 representa o alinhamento da Governana Corporativa com a viso, misso
e estratgia da organizao, a comunicao existente entre as Governanas de Tecnologia
da Informao e Segurana da Informao e o alinhamento destas perante a Governana
Corporativa.
Governana de Tecnologia da Informao uma estrutura de relacionamento entre
processos com o intuito de direcionar e controlar uma organizao para atingir seus
objetivos estratgicos atravs de agregao de valor e gesto de riscos na utilizao da
tecnologia da informao e comunicao, visando a fuso da tecnologia da informao e
comunicao ao negcio. A Governana de TI determina o comportamento desejvel no
uso da tecnologia da informao e comunicao no meio corporativo (BERNARDES e
MOREIRA, 2006).
Basicamente, a Governana de Tecnologia da Informao pode ser resumida na
resposta s trs perguntas (MANSUR, 2007):
1. Que decises devem ser tomadas?
2. Quem deve tom-las?
3. Como tom-las e monitor-las?
25
O Center for Information System Research (CISR), da MIT Sloan School, identicou
as principais decises e os arqutipos
2
da Governana de Tecnologia da Informao.
Dentre as tomadas de decises, foram identicados os (i) princpios de TI, que
so basicamente as decises de alto nvel sobre o alinhamento entre TI e o negcio;
(ii) arquitetura de TI, que so basicamente as decises sobre a organizao lgica
dos dados, aplicaes e infraestrutura, denidas a partir de um conjunto de polticas,
padronizaes e integraes; (iii) infraestrutura de TI, que so basicamente as decises
sobre a capacidade atual e planejada de TI disponvel para o negcio, sob a forma de
servio compartilhado; (iv) necessidades de aplicao de negcio, que so basicamente
decises sobre as necessidades do negcio que geram valor, onde deve-se encontrar o
equilbrio entre criatividade e disciplina; e (v) investimentos e priorizao de TI, que so
basicamente as decises sobre quanto gastar, em que gastar e como equilibrar a diferentes
necessidades (MANSUR, 2007).
As demandas de controle, transparncia e previsibilidade deram origem Governana
de TI. Estas demandas se originaram das questes relativas qualidade, que ganharam
importncia no cenrio mundial no comeo da dcada de noventa.
Na Governana da Tecnologia da Informao, existem alguns guias de melhores
prticas de controles que so utilizados para atender o seu objetivo, como o COSO -
The Comitee of Sponsoring Organization, COBIT - Control Objectives for Information
and Related Technology, ITIL - Information Technology Infra-structure Library, ISO
20000 - Gerenciamento de Servios, AS 8015:2005 - Australian Standard for Corporate
Governance, CMM - Capability Maturity Model, CMMI - Capability Maturity Model
Integrated e ValIT - Value of Information Technology.
Algumas destas melhores prticas de controle so utilizadas tambm na Governana
da Segurana da Informao para atender ao seu objetivo e ao objetivo da Governana
Corporativa.
A Governana de Segurana da Informao um subconjunto de organizaes da
Governana Corporativa (ISG, 2004). Governana de Segurana da Informao pode ser
denida como o sistema pelo qual a condencialidade, integridade e disponibilidade dos
ativos so mantidos pela organizao (SOLMS, 2007).
Tambm pode-se dizer que Governana de Segurana da Informao a ao que
leva ao controle de uma organizao e ao alinhamento com os objetivos estratgicos,
garantindo a cultura da segurana da informao, otimizando os processos relacionados e
determinando atividades para que pessoas competentes possam desempenhar (ALVES et
al., 2006).
2
Segundo o dicionrio Michaelis: Modelo dos seres criados. O que serve de modelo ou exemplo, em
estudos comparativos.
26
Governana de Segurana da Informao considerada um componente essencial para
o sucesso da gesto organizacional. A sua fragilidade exige que sejam tomadas medidas
imediatas para assegurar que os dados no sejam comprometidos e que os sistemas de
informao permaneam seguros (ISG, 2004).
A Governana da Segurana da Informao consiste em liderana, estruturas
organizacionais e processos que garantam a segurana da informao. Para o sucesso
destas estruturas e processos essencial haver a comunicao ecaz entre todas as
partes com base em uma relao construtiva, linguagens comuns e compartilhamento
de compromissos para abordar questes (ITGI, 2006).
2.3 GESTO DE RISCO
Esta seo apresenta uma viso do processo de Gesto de Riscos e detalhando a
atividade de anlise de risco. As denies apresentadas nesta seo so fortemente
baseadas na norma ABNT NBR ISO/IEC 27005:2008, que aborda a Gesto de Riscos
de Segurana da Informao, visto que a normal sugerida como referncia pela norma
ABNT NBR ISO/IEC 27001:2006.
Todos os tipos de empreendimentos se deparam com situaes (ou eventos) que
constituem oportunidades de benefcio ou ameaa ao seu sucesso. Oportunidades podem
ser aproveitadas ou ameaas podem ser reduzidas por uma gesto ativa (ABNT, 2005b).
Gesto de riscos, em reas como a do mercado nanceiro, trata das utuaes
monetrias como uma oportunidade de ganhos ou como uma potencial perda. Na
Segurana da Informao em STI, a Gesto de Risco focada na preveno e mitigao
dos danos em ativos de TI (ABNT, 2005b).
Segundo a norma ABNT NBR ISO/IEC 27005:2008, uma abordagem sistemtica de
gesto de risco de segurana da informao necessria para se identicar as necessidades
da organizao em relao aos requisitos de segurana da informao e para criar um
sistema de gesto de segurana da informao (SGSI) que seja ecaz. Convm que os
esforos de segurana da informao lidem com riscos de maneira efetiva e no tempo
apropriado, onde e quando forem necessrios (ABNT, 2008).
importante que a gesto de segurana da informao seja um processo contnuo que
dena o contexto, avalie os riscos e trate os riscos usando um plano de tratamento a m
de implementar as recomendaes e decises. Convm que a gesto de risco analise os
possveis acontecimentos e suas consequncias, antes de decidir o que ser feito e quando
ser feito, a m de reduzir os riscos a um nvel aceitvel (ABNT, 2008).
O processo de gesto de risco de segurana da informao consiste na denio do
27
contexto, anlise/avaliao de risco, tratamento do risco, aceitao do risco, comunicao
do risco e monitoramento e anlise crtica do risco (ABNT, 2008). Essas etapas e suas
relaes podem ser melhor visualizadas no uxograma apresentado na Figura 2.2.
Figura 2.2: Fluxograma de gesto de risco em segurana da informao(ABNT, 2008).
Como pode-se visualizar na Figura 2.2, o processo de gesto de risco de segurana da
informao pode ter as atividades de anlise/avaliao de risco e/ou tratamento de risco,
sendo realizadas mais de uma vez. Um enfoque iterativo na execuo da anlise/avaliao
de risco torna possvel aprofundar e detalhar a avaliao em cada repetio e tambm
28
permite minimizar o tempo e o esforo despendidos na identicao de controles e,
ainda assim, assegurar que os riscos de alto impacto ou de alta probabilidade possam
ser adequadamente avaliados (ABNT, 2008).
A primeira etapa do processo de gesto de risco a denio o contexto, em seguida,
executa-se a anlise/avaliao de risco, que pode ser refeita at se obter informaes
sucientes para que se determine de forma ecaz as aes necessrias para reduzir os
riscos a um nvel aceitvel, nalizando ento esta etapa. O tratamento de risco sucede
a anlise/avaliao de risco e tem seus resultados dependentes desta etapa. Existem
situaes em que o tratamento de risco no chega a um nvel de risco residual, sendo ento
necessria uma nova iterao na anlise/avaliao de risco, com mudanas nas variveis
do contexto, seguida de uma fase adicional de tratamento de risco. Ao trmino da etapa
de tratamento de risco, inicia-se a etapa de aceitao do risco, em que esta deve assegurar
que os riscos residuais sejam explicitamente aceitos pelos gestores da organizao (ABNT,
2008).
A norma ABNT NBR ISO/IEC 27005:2008 salienta que, durante o processo de gesto
de risco de segurana da informao, importante que os riscos e a forma com que so
tratados sejam comunicados ao pessoal das reas operacionais e gestores apropriados.
Tambm salientado que mesmo antes do tratamento de risco, informaes sobre riscos
identicados podem ser muito teis para o gerenciamento de incidentes e ajudar a reduzir
possveis prejuzos (ABNT, 2008).
At agora, uma viso supercial do processo de Gesto de Riscos em Segurana da
Informao foi apresentada. As sees subseqentes abordam de forma mais detalhada
as duas tarefas da anlise de risco para sua melhor compreenso, tendo em vista que o
trabalho visa auxiliar diretamente nestas duas tarefas.
2.3.1 Identicao de riscos
A nalidade da identicao de riscos desenvolver uma lista abrangente de fontes
de risco e eventos que podem ter um impacto na consecuo de cada um dos objetivos
identicados nos contextos. Os riscos no identicados podem se tornar uma ameaa
organizao ou fazer com que percam oportunidades importantes (CICCO, 2005). O
propsito da identicao de riscos, segundo a norma ABNT NBR ISO/IEC 27005:2008,
determinar eventos que possam causar uma perda potencial e deixar claro como, onde
e por que a perda pode acontecer. As etapas que servem de entrada para atividade de
estimativa de risco so (ABNT, 2008):
Identicao de ativos;
Identicao de ameaas;
29
Identicao de controles existentes;
Identicao de vulnerabilidades; e
Identicao de conseqncias.
Cada uma destas etapas abordada separadamente e com melhores detalhes a seguir.
2.3.1.1 Identicao de ativos
Como visto na Seo 2.1 deste captulo, um ativo algo que tem valor para a
organizao e que, portanto, requer proteo. Para a identicao dos ativos, convm
que se tenha em mente que um sistema de informao compreende mais que hardware
e software. A norma ABNT NBR ISO/IEC 27005:2008 sugere que a identicao dos
ativos seja executada com um detalhamento adequado que fornea informaes sucientes
para a anlise/avaliao de riscos. O nvel de detalhe usado na identicao dos ativos
inuncia na quantidade geral de informao reunidas durante a anlise/avaliao de
risco. O detalhamento pode ser aprofundado em cada iterao da anlise/avaliao de
risco (ABNT, 2008).
Esta atividade tem como resultado uma lista de ativos com risco a serem gerenciados
e uma lista dos negcios relacionados aos ativos e suas relevncias (ABNT, 2008).
2.3.1.2 Identicao de ameaas
Uma ameaa tem o potencial de comprometer ativos (tais como, informao, processo
e sistemas), por isso, tambm as organizaes. Ameaas podem ser de origem natural ou
humana e podem ser acidentais ou intencionais. recomendado que tanto as ameaas
acidentais, quanto as intencionais sejam identicadas genericamente e por classe (por
exemplo, aes no autorizadas, danos fsicos, falhas tcnicas) e, quando apropriado,
ameaas especcas identicadas dentro das classes genricas. Isso signica que nenhuma
ameaa ignorada, incluindo as no previstas, mas que o volume de trabalho exigido
limitado (ABNT, 2008).
Algumas ameaas podem afetar mais de um ativo. Nesses casos, elas podem provocar
impactos diferentes, dependendo de quais ativos so afetados.
Dados de entrada para a identicao das ameaas e estimativas de probabilidade de
ocorrncia podem ser obtidas dos responsveis pelos ativos ou dos usurios, do pessoal,
dos administradores das instalaes e dos especialistas em segurana da informao,
de peritos em segurana fsica, do departamento jurdico e de outras organizaes,
incluindo organismos legais, autoridades climticas, companhias de seguros e autoridades
governamentais nacionais.
30
Convm que experincias internas de incidentes e avaliaes anteriores das ameaas
sejam consideradas avaliao atual. Pode ser til a consulta a outro catlogo de ameaas
a m de completar a lista de ameaas genricas, quando relevantes. Catlogos de ameaas
e estatsticas so disponibilizados por organismos setoriais, governos nacionais, organismos
legais, companhias de seguros etc (ABNT, 2008).
Esta atividade resulta em uma listagem com as ameaas e sua respectiva identicao
do tipo e da fonte das ameaas (ABNT, 2008).
2.3.1.3 Identicao de controles existentes
Convm que a identicao dos controles existentes seja realizada para evitar custos
e trabalho desnecessrio, por exemplo: na duplicao de controles. Alm disso, enquanto
os controles existentes esto sendo identicados, convm que seja feita uma vericao
para averiguar se estes esto funcionando corretamente. Uma referncia aos relatrios j
existentes de auditoria do Sistema de Gesto de Segurana da Informao (SGSI) pode
reduzir o tempo gasto nesta tarefa.
Deve ser tambm levado em considerao a possibilidade de um controle selecionado
falhar durante sua operao, tornando necessria a existncia de controles complementares
para tratar efetivamente o risco identicado (ABNT, 2008).
Para identicar controles existentes ou planejados, as seguintes atividades podem ser
teis (ABNT, 2008):
Analisar de forma crtica os documentos contendo informaes sobre os controles
(por exemplo: os planos de implementao de tratamento de risco). Se os processos
de gesto da segurana da informao esto bem documentados, convm que todos
os controles existentes ou planejados e a situao de sua implementao estejam
disponveis;
Vericar, com as pessoas responsveis pela segurana da informao e com os
funcionrios, quais controles, relacionados ao processo de informao ou ao sistema
de informao sob considerao, esto realmente implementados;
Revisar, no local, os controles fsicos, comparando os controles implementados com
a lista de quais convm que estejam presentes; e vericar se aqueles implementados
esto funcionando efetiva e corretamente; ou
Analisar criticamente os resultados de auditorias internas.
Esta atividade resulta em uma lista de todos os controles implementados ou
planejados, sua implementao e o seu nvel de utilizao (ABNT, 2008).
31
2.3.1.4 Identicao de vulnerabilidades
As vulnerabilidades podem ser identicadas nas seguintes reas (ABNT, 2008):
Organizao;
Processos e procedimentos;
Rotinas de gesto;
Recursos humanos;
Ambientes fsicos;
Congurao de sistemas de informao;
Hardware, softwares ou equipamentos de comunicao; e
Dependncia de entidade externa.
A presena de uma vulnerabilidade no causa prejuzo por si s, pois precisa haver
uma ameaa presente para explora-l. Uma vulnerabilidade que no tem uma ameaa
correspondente pode no requerer implementao de um controle no presente momento,
mas convm que nela seja reconhecida como tal e monitorada, no caso de haver mudanas.
Um controle implementado, que funciona incorretamente, ou sendo usado incorretamente,
pode, por si s, representar uma vulnerabilidade. Um controle pode ser ecaz ou no,
dependendo do ambiente no qual ele opera. Inversamente, uma ameaa que no tenha
vulnerabilidade correspondente pode no resultar em um risco.
Vulnerabilidades podem estar ligadas a propriedades dos ativos, as quais podem ser
usadas de uma forma ou para um propsito diferente daquele para qual o ativo foi
adquirido ou desenvolvido. Vulnerabilidades decorrentes de diferentes fontes precisam
ser consideradas, por exemplo: as intrnsecas ao ativo e as extrnsecas.
Esta atividade resulta em uma lista de vulnerabilidades associadas aos ativos, s
ameaas e aos controles; assim como uma lista de vulnerabilidades que no se refere a
nenhuma ameaa identicada para anlise (ABNT, 2008).
2.3.1.5 Identicao de conseqncias
Uma conseqncia pode ser, por exemplo, a perda da eccia, condies adversas de
operao, a perda de oportunidade de negcio, reputao afetada, prejuzo etc.
Essa atividade identica o prejuzo ou as consequncias para a organizao que podem
decorrer de um cenrio de incidente. Um cenrio de incidente a descrio de uma ameaa
32
explorando uma vulnerabilidade ou um conjunto delas em um incidente de segurana
da informao. O impacto dos cenrios de incidentes determinado considerando-se os
critrios de impacto denidos durante a atividade de denio do contexto. Esta pode
afetar um ou mais ativos ou apenas parte de um ativo. Conseqncias podem ser de
natureza temporria ou permanente como no casa da destruio de um ativo (ABNT,
2008).
Esta atividade resulta em uma lista de cenrios de incidentes com suas conseqncias
associadas ao ativos e processos de negcio (ABNT, 2008).
2.3.2 Estimativa de Riscos
A estimativa de riscos pode seguir uma metodologia qualitativa ou quantitativa ou
ainda uma combinao de ambas. Freqentemente, a estimativa qualitativa utilizada
primeiro para se obter uma indicao geral do nvel de risco e para revelar grandes riscos.
Depois desta estimativa prvia, poder ser utilizada a estimativa quantitativa (ABNT,
2008).
A estimativa qualitativa utiliza uma escala de atributos que descrevem a magnitude
das conseqncias potencias, como por exemplo, pequena, mdia e grande, e tambm
a probabilidade destas conseqncias ocorrerem. Por sua vez, a estimativa quantitativa
utiliza uma escala numrica tanto para conseqncias quanto para probabilidade (ABNT,
2008).
A estimativa quantitativa pode ser relacionada diretamente com os objetivos de
segurana da informao e interesses da organizao, no entanto, leva desvantagem sobre
a estimativa qualitativa com relao a falta de dados de novos riscos ou sobre fragilidades
de segurana da informao (ABNT, 2008).
Os valores atribudos aos ativos, seja da forma qualitativa ou quantitativa, so
utilizados na avaliao das conseqncias, ou seja, do impacto no negcio. Este impacto
tambm pode ser representado de forma qualitativa ou quantitativa. A valorizao dos
ativos deve levar em considerao sua criticidade e sua importncia para a realizao dos
objetivos de negcio da organizao (ABNT, 2008).
2.3.3 Gesto de Riscos e Redes Bayesianas
A Seo 2.3 apresentou uma breve viso sobre Gesto de Risco aplicada a Segurana
da Informao. A atual seo tem como objetivo apenas criar uma relao entre Gesto
de Riscos e Redes Bayesianas, que sero apresentadas com mais detalhe no Captulo 3.
Como mencionado na Seo 2.3.2, a estimativa de risco pode ser qualitativa ou
33
quantitativa. Um possvel abordagem para se obter uma estimativa de risco quantitativa
atravs da utilizao de Redes Bayesianas, visto que cada n desta rede representa uma
probabilidade quantitativa de um determinada evento.
Esta abordagem utilizada em trabalhos como Dantu e Kolan (2005), Fenz e Hudec
(2009), Fenz e Neubauer (2009), Lee et al. (2008) e Lucas et al. (2004) para calcular riscos
operacionais, em projetos, de sade, de segurana etc.
Dantu e Kolan (2005) formularam um mecanismo para estimar o nvel de risco de
recursos crticos atravs de um grafo de ataques baseados no comportamento do atacante.
Este utilizado para calcular o nvel de risco dos recursos.
Fenz e Hudec (2009) propem um mtodo para gerao de Redes Bayesianas com base
em ontologia, possibilitando identicar o grau de certeza sobre um determinado evento e
sua inuncia sobre outros componentes da organizao.
Fenz e Neubauer (2009) mostram como determinar a probalidade de ameaas com a
utilizao de ontologias e Redes Bayesianas com o objetivo de possibilitar a gestores de
risco uma visualizao compreensvel e quantitativa do estado da segurana da informao
em suas organizaes.
Lee et al. (2008) utilizam Redes Bayesianas para construir um diagrama de causa
e conseqncia, considerando isso uma metodologia adequada para gesto de risco em
projetos com processos integrados e sistemticos.
Lucas et al. (2004) apresentam o estado da arte de Redes Bayesianas aplicada
a medicina, apresentando os problemas de incerteza da biomedicina em que Redes
Bayesianas geralmente so empregadas.
Neste seo foi apresentada apenas um pequeno resumo dos trabalhos que utilizam
Redes Bayesianas aplicada a Gesto de Risco, visto que os trabalhos relacionados sero
melhor detalhados no Captulo 5.
2.4 BASE DE DADOS DE VULNERABILIDADES
Esta seo apresenta a base de dados de vulnerabilidade National Vulnerability
Database (NVD) e como ela organizada. Como o trabalho baseado nesta base de
dados, esta seo fortemente baseada na documentao disponibilizada pela NVD.
Para se manter um sistema de tecnologia de informao seguro, necessria a
utilizao das melhores prticas em Segurana da Informao. Para isso, base de
conhecimentos de vulnerabilidades, estados de sistema e checklists de segurana da
informao devem ser criados. Para que isso possa se tornar de fato uma melhor prtica,
34
as descries de vulnerabilidades de conguraes de sistemas devem seguir um padro
comum de nomes (BUTTNER e ZIRING, 2009).
A utilizao de um padro comum para descrever vulnerabilidades e conguraes,
prov interoperabilidade, melhora da correlao dos resultados e facilita a coleta de
mtricas de Segurana da Informao. Outra motivao para esta padronizao a
tendncia para a automao em prticas de segurana, em que um padro essencial,
sendo ento possvel identicar claramente uma vulnerabilidade e as plataforma de
Tecnologia da Informao as quais elas se aplicam (BUTTNER e ZIRING, 2009).
O padro de nomenclatura que est se popularizando o Common Vulnerabilities and
Exposures (CVE), que utilizado para identicar e descrever plataformas de Tecnologia
da Informao e Vulnerabilidades. Um padro similar destinado a congurao de
plataformas de Tecnologia da Informao o Common Conguration Enumeration
(CCE). Esta especicao descreve um esquema estruturado de atribuio de nomes para
as plataformas informticas (hardware, sistemas operacionais e aplicaes), que recebe o
nome de Common Platform Enumeration (CPE)(BUTTNER e ZIRING, 2009).
2.4.1 Common Platform Enumeration
O Common Platform Enumeration (CPE) baseado na sintaxe genrica para
Uniform Resource Identiers (URI)
3
e especica sintaxe de nomes e convenes
para a construo de nomes e informao sobre os produtos, criando um dicionrio
chamado CPE Dictionary, que pode ser atualizado atravs do endereo eletrnico
http://cpe.mitre.org.
Esta especicao foi criada com base em trs propsitos (BUTTNER e ZIRING,
2009):
1. Nomes Comuns - Se uma ferramenta cria uma descrio e/ou resultado aplicvel
a um certo tipo de plataforma, uma segunda ferramenta deve ser capaz de
compreender o que foi descrito pela primeira ferramenta e saber que ao tomar;
2. Correspondncia - Uma congurao manual pode ser aplicvel para todas as
verses de um determinado sistema operacional e ser atribudo um nome a este
CPE. Portanto, a ferramenta pode consultar um sistema e determinar um nome
mais especco, que inclui uma verso exata, ou talvez uma determinao complexa
utilizando a plataforma de descrio CPE .
3. Relatrios - Quando utilizado em relatrios sobre um sistema especco ou de um
grupo de sistemas, um nome CPE permite a correlao dos resultados com fontes
3
Maiores informaes sobre Uniform Resource Identiers (URI) podem ser obtidas em
http://labs.apache.org/webarch/uri/rfc/rfc3986.html
35
adicionais. Se um nome CPE atribudo para cada sistema, esse identicador pode
ser utilizado para pesquisar em outro sistema as possveis vulnerabilidades que so
aplicveis para esse tipo de plataforma.
Um nome CPE sempre comea com um prexo URI cpe:
4
e seguido de uma
estrutura que identica qualquer plataforma. A estrutura de um nome CPE formada
por um ou mais componentes separadas por :. O primeiro componente identica a parte
da plataforma que est sendo especicada; o segundo identica um vendedor ou fornecedor
do item; o terceiro identica o nome do produto; o quarto indica uma verso do produto;
o quinto utilizado para determinar a atualizao ou service pack; o sexto identica a
edio e o stimo usado para especicar internacionalizao das informaes. O exemplo
abaixo representa a estrutura completa de um nome CPE.
cpe:/part:vendor:product:version:update:edition:language
Estrutura de um nome CPE.
O CPE permite componentes nulos, o que signica que qualquer aspecto do respectivo
componente vlido. Por exemplo, o nome CPE abaixo designado a todas as edies
do Microsoft Windows XP Professional, independentemente do service pack nvel.
cpe:/o:microsoft:windows_xp:::pro
Para forar que um determinado componente seja congurado como vazio, utilizado
o -. Quando empregado o -, as consultas s retornaro nomes em que o determinado
componente nulo ou vazio, ao contrrio do exemplo anterior, em que retornaria qualquer
valor para aquele componente. Por exemplo, uma aplicao no pode ter diferentes
edies. Um nome CPE para tal aplicativo pode usar o - para a edio componente,
como visto abaixo.
cpe:/a:acme:product:1.0:update2:-:en-us
O sinal - tambm utilizado para determinar a primeira verso de uma plataforma
que se identica com o componente. Como, por exemplo, a primeira liberao de uma
aplicao, antes que exista uma atualizao, como pode ser visto a seguir:
cpe:/a:acme:product:1.0:-
4
O prexo cpe no um prexo ocializado pela Internet Assigned Numbers Authority - IANA.
Maiores informaes sobre a IANA em http://www.iana.org.
36
Aps a primeira atualizao:
cpe:/a:acme:product:1.0:update1
Ambas opes seriam selecionadas em uma consulta em que o componente referente
atualizao esteja com o valor vazio, ou seja:
cpe:/a:acme:product:1.0:
2.4.1.1 Componentes de um nome CPE
Da estrutura especicada de um nome CPE, o primeiro componente determina
a particularidade da plataforma que est sendo identicada, que so denidas pelos
seguintes cdigos:
h - hardware;
o - sistema operacional; e
a - aplicao.
O segundo componente do nome CPE, que determina o vendedor ou fornecedor
do item, pode ser fonte de divergncias pelas diversas forma de expressar o nome de
uma organizao. Para evitar esta divergncia, utilizado o nome do domnio DNS da
organizao, mesmo que este domnio seja diferente do nome da organizao. A tabela
2.1 mostra alguns exemplos que representam esta situao.
Nome da Organizao Domnio Componente CPE
Cisco Systems, Inc. cisco.com cisco
The Mozilla Foundation mozilla.org mozilla
University of Oxford oxford.ac.uk oxford
Tabela 2.1: Relao entre nomes de organizaes, domnios e descrio do vendedor de
um nome CPE
Algumas organizaes podem utilizar mais de um domnio, como, por exemplo,
hewlett-packard.com e hp.com. Nestes casos, deve ser utilizado o nome que a organizao
utiliza em publicidade ou documentaes. No caso do exemplo anterior, seria utilizando
hp para referenciar o componente do nome CPE.
Caso o nome especco do domnio de uma organizao seja compartilhado por
uma segunda organizao, diferenciando apenas o suxo do endereo DNS, deve-se
37
ento utilizar o nome completo do domnio DNS. Por exemplo, se ao registrar um
nome cpe:/a:acme for identicado que o mesmo referente a organizao com domnio
acme.com, ento dever utilizar o nome de componente cpe:/a:acme.org.
Em casos em que o vendedor ou fornecedor no possui um endereo DNS, deve-se
ento utilizar o termo pelo qual o vendedor ou fornecedor seja mais conhecido, sempre
substituindo os espaos entre palavras por sublinhado (_).
Quando se est gerando um nome para uma aplicao que no possui um vendedor
ou fornecedor, comum em aplicaes open-source, utiliza-se o nome do desenvolvedor para
determinar vendedor ou fornecedor do componente. Neste caso, tambm se substitui os
espaos por sublinhado.
Em situaes em que um vendedor ou fornecedor muda o seu nome devido a sua
comercializao ou aquisio, o nome CPE original deve permanecer o mesmo, sendo
gerado um novo nome CPE contendo o nome do novo vendedor ou fornecedor.
Em tal caso, o nome utilizado no terceiro componente do nome CPE, refere-se ao
nome do produto. Utiliza-se o nome mais comum para o produto, considerando materiais
de publicidade e documentao. Produtos que possuem um nome composto por mais
de uma palavra, devem ser descritos integralmente, sempre substituindo os espaos por
sublinhados. Como por exemplo, um produto com o nome de ZoneAlarm Internet Security
Suite version 7.0 deve ter um nome CPE:
cpe:/a:zonelabs:zonealarm_internet_security_suite:7.0
Em casos em que o produto possui um nome composto por mais de uma palavra e
o vendedor ou fornecedor utiliza uma abreviatura ocial para o mesmo, esta ltima
utilizada. A tabela 2.2 apresenta alguns exemplos deste caso.
Nome do Produto Abreviao
Internet Explorer ie
Java Runtime Environment jre
Tabela 2.2: Abreviaes de nomes de produtos
O quarto componente do nome CPE, refere-se verso da plataforma descrita,
utilizando a verso de forma idntica a utilizada pelo produto, empregando como
delimitadores, pontos, vrgulas, sublinhados, etc.
O mesmo ocorre com o quinto elemento do nome CPE, que refere-se atualizao da
plataforma descrita, em que utilizado o nome determinado pelo vendedor ou fornecedor.
Como, por exemplo, para determinar suas atualizaes a Microsoft utiliza o formato
Servive Pack 1 (ou sp1) e a Red Hat que utiliza o formato Update 1.
38
O sexto componente, referente edio da plataforma, utilizado para determinar
o objetivo especco da arquitetura de hardware ou aplicao, ou seja, diferentes edies
de uma plataforma. Um exemplo de edio para hardware pode ser a arquitetura a qual
se refere, i386 e x64. Um exemplo de edio para aplicao o sistema operacional de
destino da aplicao, que pode ser Windows, Linux ou Macintosh OS X, ou at mesmo,
a edio do sistema operacional, como Windows Vista Home, Professional ou Ultimate.
O ltimo componente de um nome CPE referente linguagem da plataforma
descrita, que representada pela IETF RFC 4646
5
.
Algumas palavras e frases que so comumente utilizadas no meio da Tecnologia
da Informao com relao denominao de produtos, e que possuem abreviaturas
j conhecidas, so utilizadas para facilitar a utilizao de nomes CPE e tambm para
reduzi-los.
A tabela 2.3 apresenta as principais abreviaes utilizadas em nomes de produtos.
Termo Completo Abreviao
advanced adv
professional pro
server srv
standard std
edition ed
version 3.4 3.4
patch level 3 pl3
release 3 r3
release candidate 2 rc3
service pack 4 sp4
support pack 2 sup2
service release 2 sr2
security rollup sru
general availability ga
Tabela 2.3: Abreviaes utilizadas em nomes de produtos.
A lista completa e atualizada de abreviaturas pode ser obtida atravs do endereo
eletrnico http://cpe.mitre.org.
2.4.2 Common Vulnerability Scoring System
O Common Vulnerability Scoring System (CVSS) um framework aberto que
relaciona caractersticas de comunicao e impacto de vulnerabilidades de TI para obter
5
IETF: Internet Engineering Task Force; RFC: Request for Comments; A IETF RFC 4646 recebe
o nome de Tags for Identifying Languages. Maiores detalhes podem ser obtidos atravs do endereo
http://www.ietf.org/rfc/rfc4646.txt
39
uma pontuao. Estas pontuaes auxiliam na tarefa dos gestores de Segurana da
Informao a priorizar as vulnerabilidades que sero abordadas em seu ambiente, visto
que, geralmente, devem monitorar um grande nmero de hardware e aplicativos, que por
sua vez, possuem inmeras vulnerabilidades. A documentao do CVSS disponibilizada
em Mell et al. (2007) e esta seo est totalmente baseada nesta documentao.
O CVSS est dividido em trs grupos de mtricas que fornecem uma pontuao entre
0 e 10, que so: bsicas, temporais e de ambiente.
Mtricas bsicas: Representam caractersticas fundamentais e intrnsecas de uma
vulnerabilidade que constante no tempo e no ambiente do usurio;
Mtricas Temporais: Representam as caractersticas da vulnerabilidade que mudam
no tempo, porm, no no ambiente de usurio;
Mtricas de Ambiente: Representam as caractersticas das vulnerabilidades que so
nicas e relevantes para o ambiente de usurio.
Quando os valores das mtricas bsicas so denidos, uma equao calcula a
pontuao, retornando um valor entre 0 e 10 e um vetor criado, como pode ser visualizado
na Figura 2.3.
Figura 2.3: Mtricas e equaes do CVSS (MELL et al., 2007).
Como pode-se observar no uxo apresentado na Figura 2.3, a utilizao dos grupos
de mtricas temporais e de ambientes so opcionais para se obter a pontuao da
vulnerabilidade. As mtricas temporais e de ambiente somente so utilizadas, caso seja
necessrio renar a pontuao obtida a partir das mtricas bsicas.
40
2.4.2.1 Mtricas bsicas
Este grupo capta as caractersticas das vulnerabilidades que so constantes no tempo
e nos ambientes de usurios. Estas caractersticas so o vetor de acesso, a complexidade
de acesso, autenticao e impacto.
O vetor de acesso corresponde a como a vulnerabilidade explorada e seus possveis
valores so:
Local : Que corresponde s vulnerabilidade que necessitam de acesso local para serem
exploradas.
Adjacent Network: Que correspondem s vulnerabilidades que necessitam de acesso a
uma rede adjacente para serem exploradas, como por exemplo, acesso a rede local,
acesso via Bluetooth, IEEE 802,11 e um segmento da rede.
Network: Que corresponde s vulnerabilidades que podem ser exploradas atravs da
rede.
A complexidade de acesso corresponde ao nvel de diculdade que o atacante tem para
explorar a vulnerabilidade e seus possveis valores so:
High: Existem condies de acesso especializadas, como por exemplo, em casos em que
algum momento do ataque necessrio acesso privilegiado ao sistema, o atacante
necessita de engenharia social ou a congurao da vulnerabilidade muito rara;
Medium: Quando as condies de acesso so menos especializadas, como por exemplo,
em casos em que o atacante j faz parte de um grupo de usurios do sistema, onde
o atacante j tenha alguma informao que facilite o ataque ou que a congurao
da vulnerabilidade no padro, mas comumente encontrada;
Low: Quando condies de acesso especializado no existem, com por exemplo, quando
o produto afetado requer acesso annimo e no convel a uma grande nmero de
sistemas e usurios, a congurao da vulnerabilidade padro e ubqua ou quando
o ataque pode ser efetuado de forma manual e com pouco conhecimento ou com
poucas informaes.
A mtrica de autenticao corresponde ao nmero de vezes que o atacante deve realizar
autenticao para conseguir explorar a vulnerabilidade. Seus possveis valores so:
Multiple: Quando o atacante deve autenticar no sistema duas ou mais vezes para
conseguir explorar a vulnerabilidade;
41
Single: Quando o atacante necessita autenticar apenas uma vez para conseguir explorar
o vulnerabilidade;
None: Quando o atacante no necessita autenticao para explorar a vulnerabilidade.
As mtricas de impacto so subdivididas em trs mtricas, referentes ao impacto na
CID, ou seja, na Condencialidade, Integridade e Disponibilidade. As trs mtricas de
impacto podem assumir os seguintes valores:
None Quando a vulnerabilidade no impacta na condencialidade, integridade ou
disponibilidade;
Partial Quando a vulnerabilidade impacta parcialmente na condencialidade,
integridade ou disponibilidade;
Complete Quando a vulnerabilidade impacta totalmente na condencialidade,
integridade ou disponibilidade.
importante ressaltar que existe uma mtrica para condencialidade, uma segunda
para integridade e outra para disponibilidade, sendo que as trs possuem as mesmas
opes de valores.
2.4.2.2 Mtricas temporais
A ameaa representada por uma vulnerabilidade pode mudar ao longo do tempo. Os
trs fatores que podem ser alterados ao longo do tempo que so utilizados pelo CVSS so: a
conrmao dos detalhes de uma vulnerabilidade, o estado de correo da vulnerabilidade
e a disponibilidade de cdigos para explorar a vulnerabilidade. As mtricas que compes
este grupo so: explorabilidade, nvel de correo e conana do relatrio.
A explorabilidade corresponde ao estado atual de tcnicas e cdigos para explorar a
vulnerabilidade e seus possveis valores so:
Unproven: Quando nenhum cdigo de explorao encontra-se disponvel, ou uma
explorao meramente terica;
Proof-of-Concept: Quando existe prova de conceito ou uma demonstrao de ataque,
sendo este no prtico para a maioria dos sistemas disponveis;
Functional : Quando o cdigo de explorao est disponvel e funcional para a maioria
das situaes onde a vulnerabilidade existe;
High: Quando a vulnerabilidade pode ser explorada de forma automtica e os detalhes
so amplamente disponveis;
42
Not Dened: Sinal para ignorar a mtrica no resultado nal.
O nvel de correo de uma vulnerabilidade um fator importante para a priorizao.
Um tpico caso de vulnerabilidade no corrigida quando ela recm publicada. As
solues alternativas ou correes podem gerar uma correo, ou uma atualizao ocial.
Cada uma destas fases inui na pontuao temporal. Os valores que esta mtrica pode
assumir so:
Ocial Fix: Quando uma soluo completa do fornecedor est disponvel;
Temporary Fix: Quando existe uma soluo ocial, no entanto, temporria;
Workaround : Quando existe uma soluo de contorno no ocial;
Unavailable : Quando no existe uma soluo disponvel;
Not Dened: Sinal para ignorar a mtrica no resultado nal.
Essa mtrica mede o grau de conana na existncia da vulnerabilidade e da
credibilidade dos detalhes tcnicos conhecidos. Em alguns casos, apenas a existncia
de vulnerabilidades divulgada, mas sem detalhes especcos. A vulnerabilidade pode
ser posteriormente conrmada. A urgncia em tratar uma vulnerabilidade maior quando
uma vulnerabilidade conrmada. Esta mtrica tambm sugere o nvel de conhecimento
tcnico disponvel para possveis atacantes. Seus possveis valores so:
Unconrmed: Quando no existe uma nica fonte no conrmada ou possivelmente
vrios relatos conitantes. Como por exemplo, boatos;
Uncorroborated: Quando existem vrias fontes no ociais, possivelmente incluindo
empresas de segurana ou organizaes independentes de pesquisa;
Conrmaded : Quando a vulnerabilidade reconhecida pelo fornecedor ou autor do
tecnologia afetada ou quando publicada uma prova de conceito ou cdigo para
explorar a vulnerabilidade;
Not Dened: Sinal para ignorar a mtrica no resultado nal.
2.4.2.3 Mtricas de Ambiente
Diferentes ambientes podem ter uma grande inuncia sobre o risco que representa
uma vulnerabilidade para uma organizao e seus parceiros. Este grupo de mtricas coleta
caractersticas da vulnerabilidade que esto associadas a um usurio do ambiente de TI.
43
As mtricas que compem este grupo so dados colaterais em potencial, distribuio do
objetivos e requisitos de segurana.
A mtrica de danos colaterais em potencial mensura a potencial perda de ativos fsicos
por meio de danos ou furto de bens ou equipamentos, assim como a perda de produtividade
ou da receita. Os possveis valores para esta mtrica so:
None: Quando no existem potenciais dados para perda de vida, ativos fsicos,
produtividade ou receita;
Low: Quando uma explorao bem-sucedida desta vulnerabilidade pode resultar em
danos fsicos ou materiais leves;
Low-Medium: Quando uma explorao bem-sucedida desta vulnerabilidade pode
resultar em danos fsicos ou materiais moderada;
Medium-High: Quando uma explorao bem-sucedida desta vulnerabilidade pode
resultar em danos fsicos ou materiais ou perda substancial;
High: Quando uma explorao bem-sucedida desta vulnerabilidade pode resultar em
danos catastrcos ou danos materiais e perdas;
Not Dened: Sinal para ignorar a mtrica no resultado nal.
A mtrica de distribuio de alvos mensura a proporo do sistema vulnervel.
Entende-se como um indicador para cada ambiente a m de aproximar o percentual do
sistema que pode ser afetado pela vulnerabilidade. Os seus possveis valores so:
None: Quando no existem alvos no ambiente, ou os alvos so altamente especializados
que s existem em um ambiente de laboratrio;
Low: Quando existem alvos dentro do ambiente, mas em pequena escala.;
Medium: Quando existem objetivos dentro do ambiente, mas em escala mdia;
High: Quando existem alvos dentro do ambiente em escala considervel;
Not Dened: Sinal para ignorar a mtrica no resultado nal.
A mtrica de requisitos de segurana permite ao analista personalizar a pontuao do
CVSS de acordo com a importncia do ativo para a organizao, mensurando em termos
de condencialidade, integridade e disponibilidade. O pleno efeito sobre a pontuao do
ambiente determinado pela sua mtrica bsica de impacto. importante ressaltar que
as mtricas bsicas de impacto no so alteradas. Apenas atribudo um impacto do CID
44
as mtricas de ambiente. Atribuindo pesos de impacto ao ambiente, possvel realizar
uma ponderao do impacto, Por exemplo, a mtrica de impacto na condencialidade
(bsica) diminui se o peso da exigncia de condencialidade (no ambiente) for baixo. Os
valores possveis para esta mtrica so:
Low: Quando a perda de condencialidade, integridade, disponibilidade suscetvel
de ter um efeito limitado sobre a organizao ou os indivduos associados com a
organizao;
Medium: Quando a perda de condencialidade, integridade, disponibilidade
susceptvel de ter um efeito grave sobre a organizao ou os indivduos associados
com a organizao;
High: Quando a perda de condencialidade, Integridade, disponibilidade susceptvel
de ter um efeito catastrco sobre a organizao ou os indivduos associados com a
organizao;
Not Dened: Sinal para ignorar a mtrica no resultado nal.
2.4.2.4 Clculo da pontuao
A equao para obter a pontuao bsica dada pela seguinte formula:
BS = 0, 6 I + 0, 4 E 1, 5 f(I) (2.1)
onde: BS a pontuao bsica, I o impacto, E a explorabilidade e f(I) 0 se
impacto = 0, caso contrrio 1.176.
O impacto obtido pela equao:
I = 10.41 (1 (1 Conf) (1 Int) (1 Avail)) (2.2)
onde: I o impacto, Conf 0 se o impacto na condencialidade for igual none, 0,275
se igual a partial, 0,66 se igual complete, Int 0 se o impacto na integridade for igual none,
0,275 se igual a partial, 0,66 se igual complete, Avail 0 se o impacto na disponibilidade
for igual none, 0,275 se igual a partial, 0,66 se igual complete.
A explorabilidade obtida pela equao:
E = 20 AV AC AH (2.3)
45
onde: E a explorabilidade, AV 0,395 se o vetor de acesso igual a required local
access, 0,646 se igual a adjacent network accessible e 1 se igual a network accessible, AC
0,35 se a complexidade de acesso igual a high, 0,61 se igual a medium e 0,71 se igual
a low, AH 0,45 se a autenticao igual a requires multiple instances of authentication,
0,56 se igual a requires single instance of authentication e 0,704 se igual a requires no
authentication.
A equao para se obter a pontuao temporal dada pela frmula:
TS = BS E RL RC (2.4)
onde: TS a pontuao temporal, BS a pontuao bsica, E 0,85 se explorao
igual a unproven, 0,9 se igual a proof-of-concept, 0,95 se igual a functional, 1 se igual high
e 1 se igual a not dened, RL 0,87 se o nvel de correo igual a ocial-x, 0,90 se igual
a temporay-x, 0,95 se igual a wokaround, 1 se igual a unavailable e 1 se igual a not dened
e RC 0,90 se o grau de conana igual a unconrmed, 0,95 se igual uncorroborated, 1 se
igual a conrmed e 1 se igual a not dened;
A equao para obter a pontuao de ambiente dada pela seguinte frmula:
ES = (AT + (10 AT) CDP) TD (2.5)
onde: AT o ajuste temporal recalculado na frmula da pontuao bsica, alterando
a sub-equao de impacto pela sub-equao de ajuste do impacto, CDP 0,1 se potencial
dano colateral for igual low, 0,3 se igual a low-medium, 0,4 se igual a medium-high, 0,5 se
igual a high ou 0 caso contrrio, TD 0.25 se a distribuio de objetivos igual a low, 0.75
se igual medium e 1 se igual a high ou not dened.
O ajuste do impacto dado pela equao:
AI = min(10; 10, 41 (1 (1 ConfImp ConfReq) (1 IntImp IntReq) (2.6)
(1 AvailImp AvailReq)))
onde: AI o ajuste de impacto, ConfImp o impacto na condencialidade. ConfReq
a condencialidade necessria, intImp o impacto na integridade, intRe a integriadde
necessria, AvailImp o impacto na disponibilidade e AvailReq a disponibilidade
necessria.
46
3 REDES BAYESIANAS
No Captulo 2, foi apresentada a denio de segurana da informao, sua relao
com Governana em Segurana da Informao o processo de Gesto de Risco em Segurana
da Informao, em que tcnicas probabilsticas como Redes Bayesianas foram comentadas.
Este captulo aborda de forma breve este assunto.
A Seo 3.1 introduz redes causais e o conceito de d-separation, que servem como base
para as denies de Redes Bayesianas apresentadas na Seo 3.2.
3.1 REDES CAUSAIS E D-SEPARATION
As denies apresentadas nesta seo so baseadas no exemplo de Jensen e Nielsen
(2007), que se refere ao raciocnio humano no dia-a-dia.
Pela manh, meu carro no ligar. Posso escutar o motor de arranque, mas
ele no liga. Podem existir diversas razes para o meu problema. Eu posso
escutar o motor de arranque, ento a bateria deve ter carga. Portanto, as
causas mais provveis so que a gasolina tenha sido roubada durante a noite
ou que as velas estejam sujas. Pode ser tambm que o carburador esteja sujo,
uma conexo do sistema de ignio solta ou alguma coisa mais sria. Para
encontrar uma sada, eu primeiramente olho para o medidor de combustvel.
Ele indica meio tanque, ento eu decido limpar as velas.
Para que um computador tenha o mesmo tipo de raciocnio, necessrio responder
questes como: O que me faz concluir que a causa provvel roubo de combustvel e
sujeira nas velas? ou Por que a deciso de olhar o medidor de combustvel e como essa
observao pode me fazer concluir que o problema aparente relacionado s velas?.
Para isso necessrio meios de se representar o problema e tambm de realizar
inferncia nesta representao, possibilitando que um computador simule esses tipos de
raciocnios e, talvez, fazer isso melhor e mais rpido que humanos.
No raciocnio lgico, so utilizados quatro tipo de conexes lgicas: conjuno,
disjuno, implicao e negao. Um exemplo de uma declarao lgica simples pode
ser, se est chovendo, ento a grama est molhada. A partir um conjunto de declaraes
lgicas, possvel deduzir novas declaraes. Das duas declaraes se est chovendo,
ento a grama est molhada e a grama no est molhada, ento pode-se inferir que no
est chovendo.
47
Quando se lida com eventos de incerteza, utilizar, preferencialmente, conectividades
similares com certezas melhor que usar ligaes de valores de verdade. Ento deve-se
estender os valores de verdade da lgica proposicional para certezas, que so nmeros
entre 0 e 1. Quanto maior for o nmero, maior a certeza. O valor 0 signica que a
certeza falsa e o valor 1, signica que a certeza verdadeira.
Isso possibilita o uso de declaraes tais como, se eu tomar uma xcara de caf no
intervalo, eu permanecerei acordado na prxima aula com 0,5 de certeza ou se eu der
uma pequena caminhada durante o intervalo, eu permanecerei acordado na prxima aula
com 0.8 de certeza. Suponhamos que eu faa uma caminhada e ainda tome um caf no
intervalo. Qual a certeza de eu permanecer acordado? Para responder isso, necessrio
uma funo que combine duas certezas, no caso 0, 5 e 0, 8 e retorne um nmero, que deve
ser a certeza resultante da combinao das certezas de duas declaraes.
O mesmo necessrio para o encadeamento: se a ento b com x de certeza e se b
ento c com y de certeza. Sabendo a, ento qual a certeza de c? Qualquer funo para
combinao e encadeamento levam a algumas situaes que conduzem para concluses
erradas. Outro problema que tambm pode ser encontrado, que tambm um problema
de raciocnio lgico, e deduo e pode ser exemplicado da seguinte maneira: eu tenho a
regra uma mulher tem cabelos longos com 0,7 de certeza. Se eu olhar uma pessoa com
cabelo longo, o quanto eu posso inferir sobre o sexo desta pessoa?
Um meio de estruturar uma situao para o raciocnio sobre incerteza construir
um grafo representando relaes causais entre eventos. Para exemplicar, utilizado o
exemplo do problema do carro.
Assume-se os eventos {sim, no} para combustvel?, {sim, no} para as velas esto
limpas?, {cheio, 1/2, vazio} para medidor de combustvel e {sim, no} para o carro
liga?. Sabendo qual o estado do combustvel? e do estado as velas esto limpas?,
tem-se ento um impacto causal sobre o estado o carro liga?. O mesmo acontece para
o estado combustvel?, que impacta no estado medidor de combustvel. Essa relao
pode ser vista na Figura 3.1, que apresenta em forma de grafo a direo dos impactos
entre os eventos.
Sabendo que as velas no esto limpas, a certeza que o carro no ligar aumenta.
No entanto, a situao do exemplo oposta. Como a certeza sobre o evento o carro
liga? se move em uma direo negativa, possvel encontrar as possveis causas, que so
combustvel? e as velas esto limpas?, visto que ambos se relacionam com o evento o
carro liga? positivamente.
Analisando o medidor de combustvel possvel obter uma informao relacionada
com o problema. Se ele estiver marcando 1/2 tanque, possvel mover-se na direo
inversa, ou seja, de forma negativa e determinar a certeza relacionada ao evento
48
Figura 3.1: Uma Rede Causal para o problema ao ligar o carro (JENSEN e NIELSEN,
2007).
combustvel?. Assim possvel deduzir que provavelmente o motivo do problema no
falta de combustvel, dado que o medidor est marcando 1/2 tanque.
Este raciocnio sobre incerteza foi estruturado a partir de um grafo representando
relaes causais. Grafos tambm so utilizados em Redes Causais. Essas redes so
compostas por um conjunto de variveis e um conjunto de associaes direcionadas, que
matematicamente, recebe o nome de grafos direcionados.
Em grafos direcionados, utiliza-se palavras referentes a relaes familiares para
representar a relao entre as variveis. Se houver uma associao de A para B, ento
se diz que B lho de A e A pai de B. Em uma rede causal, uma varivel representa
um conjunto de possveis estados de casos. Uma varivel est exatamente em um destes
estados.
Um exemplo simples de uma rede causal apresentado na Figura 3.2. Neste exemplo,
A tem inuncia sobre B, que por sua vez tem inuncia sobre C. Uma evidncia sobre
A inuenciar na certeza de B, que tem inuncia sobre C. Sendo assim, uma inuncia
sobre C inuenciar em A atravs de B. Se o estado de B conhecido, ento o canal
bloqueado e A e C se tornam independentes. Ento se diz que A e C so d-separados dado
B. Quando o estado de uma varivel conhecido, diz-se que a varivel est instanciada.
Figura 3.2: Conexo serial
Com base no exemplo da Figura 3.2, conclui-se que a evidncia talvez seja transmitida
atravs de uma conexo serial a menos que o estado da varivel na conexo seja conhecido.
Existem dois tipos de conexo: (i) de divergncia e (ii) de convergncia. Estas so
exemplicadas nas Figuras 3.3a e 3.3b.
49
(a) Conexo divergente (b) Conexo convergente
Figura 3.3: Exemplo de conexes em uma Rede Causal.
No exemplo da Figura 3.3a a inuncia pode passar entre todos os lhos de A, desde
que A seja conhecido. Ento B, C, . . . , E so d-separados dado A. A Figura 3.3b mostra
um caso que requer mais cuidado. Neste exemplo, se no se sabe nada sobre A, exceto
que talvez seja inferido de seus pais B, . . . , E, ento os pais so independentes, ou seja,
uma evidncia sobre um deles no pode inuenciar nos demais atravs de A.
Tanto no exemplo da Figura 3.2, quanto no da Figura 3.3a, foi comentado que um
varivel d-separada de outra. Diz-se que uma varivel A d-separada (d para grafo
direcionado, do ingls directed graph) de outra B quando entre todos os caminos entre A
e B, haja uma varivel intermediria V , distinta de A e B, de tal forma que:
a conexo seja serial ou divergente e V seja instanciada; ou
a conexo seja convergente e nem V , nem qualquer valor descendente de V , tenha
recebido evidncia.
Se A e B no so d-separados, ento so d-conectados.
Os temas abordados at ento neste captulo, servem como base para as denies de
redes bayesinas, que sero apresentadas na Seo 3.2.
3.2 DEFINIO DE REDES BAYESIANAS
Segundo Jensen e Nielsen (2007), uma Rede Bayesiana consiste em:
Um conjunto de variveis e um conjunto de arestas direcionadas entre variveis;
Cada varivel tem um conjunto nito de estados mutuamente exclusivos;
As variveis, juntamente com sua aresta direcionada, formam um grafo acclico
direcionado; e
50
Para cada varivel A com pais B
1
, . . . , B
n
, uma tabela de probabilidade condicional
P(A|B
1
, . . . , B
n
) associada.
A denio de Redes Bayesianas no se refere a causalidade e no tem a necessidade de
ter ligaes que representem um impacto causal. Quando constri-se um modelo de Redes
Bayesianas, no necessrio insistir em ter as ligaes que levam a uma direo causal.
No entanto, necessrio vericar as propriedades d-separation do modelo e assegurar que
elas correspondem a percepo das propriedades independentes condicionais do mundo.
Se A e B so d-separados dado um evidncia e, o clculo da probabilidade por Redes
Bayesianas deve ser P(A|e) = P(A|B, e) (JENSEN e NIELSEN, 2007).
Pearl (1997) dene Redes Bayesianas como um grafo acclico direcionado, em que os
ns representam variveis e as arestas representam a existncia de uma inuncia causal
direta entre variveis associadas e a fora destas inuncias so expressadas atravs de
propriedades condicionais. Russel e Norvig (2004) complementam armando que cada
n representado por uma probabilidade quantitativa e tambm apresentam a seguinte
especicao:
Um conjunto de variveis aleatrias constitui os ns da rede. As variveis podem
ser discretas ou contnuas.
Um conjunto de vnculos orientados ou arrestas conecta pares de ns. Se houver
uma arresta de n X at o n Y , X ser denominado pai de Y .
Cada n X
i
tem uma distribuio de probabilidade condicional P(X
i
|Pais(X
i
)) que
quantica o efeito dos pais sobre o n.
O grafo no tem nenhum ciclo orientado (e consequentemente um grafo acclico
orientado).
Para Pearl (1992), Redes Bayesianas proporcionam a sistemas baseados em
conhecimento, meios grcos para representao e manipulao de conhecimentos
probabilsticos. Suas propriedades e capacidades bsicas so elencadas da seguinte forma
(PEARL, 1992):
1. Mtodos grcos so criados facilmente para manter a consistncia e completude
nas bases de conhecimento probabilstico. Estes tambm denem os procedimentos
modulares para a aquisio de conhecimento que reduz signicativamente as anlises
necessrias;
2. Independncias podem ser tratadas de forma explcita. Estas podem ser articuladas
por um especialista, gracamente codicadas, lidas fora da rede e raciocinadas e
ainda sempre permanecerem robustas para a impreciso numrica.
51
3. Oportunidades descobertas para representao grca para uma computao
eciente. A atualizao distribuda possvel em uma estrutura de conhecimento
rica o suciente para exibir interaes intercausais. Quando prorrogados por
agrupamento ou condicionamento, os algoritmos de propagao em rvore so
capazes de atualizar redes de topologia arbitrria.
4. A combinao de inferncias preditivas e abdutivas resolvem muitos problemas
encontrados na primeira gerao de sistemas especialistas e torna redes de crenas
(bayesinas) um modelo vivel para funes cognitivas, necessitando inferncias
top-down e bottom-up.
Redes Bayesianas so consideradas por Pearl (1992) uma ferramenta de grande
versatilidade e poder e tambm o maior esquema de representao comum de
conhecimento probabilstico, sendo utilizadas para: diagnsticos mdicos, compreender
histricos, interpretar imagens, ltragem, visualizao e predio, facilitar planejamento
de ambientes de incerteza e estudar causas, no monotonicidade, atividade, alterao e
ateno. Esta tambm pode ser vista como um instrumento de inferncia para deduzir
novas relaes independentes a partir das utilizadas para construir a rede.
A partir do problema utilizado como exemplo ao longo do captulo, pode-se criar
uma Rede Bayesiana, onde o estado Cb representa combustvel?", MC o medidor de
combustvel;", Lc o carro liga?"e V L as velas esto limpas?"(JENSEN e NIELSEN,
2007).
Figura 3.4: Rede causal para o problema de ligar o carro.
Considerando P(Cb) = (0, 98; 0, 02) e P(VL) = (0,96; 0,04), obtm-se as tabelas de
probabilidades condicionais apresentadas na tabelas 3.1.
possvel perceber na Tabela 3.1a reete o fato de que o medidor talvez no esteja
funcionando bem e a Tabela 3.1b deixa espao para outras causas, no caso, combustvel?
e as velas esto limpas?, representado por P(Cl = no | Cb = sim, VL = sim) > 0 .
Toda entrada na distribuio de probabilidade conjunta pode ser calculada a partir das
informaes armazenadas na rede, tendo como entrada genrica a probabilidade de uma
52
Cb=sim Cb=no
MC=Cheio 0,39 0,001
MC=1/2 0,60 0,001
MC=vazio 0,01 0,998
(a) P(CM|Cb)
Cb=sim Cb=no
VL=sim (0,99; 0,01) (0,1)
VL=no (0,01; 0,99 (0,1)
(b) P(Cl|Cb, V L)
Tabela 3.1: Tabelas de probabilidade condicional para Rede Bayesiana do problema ao
ligar o carro.
conjuno de atribuies especcas de cada varivel, tal como P(X = x
1
. . . X
n
= x
n
),
ou de uma forma resumida P(x
1
, . . . , x
n
), o valor desta entrada dada pela formula
(RUSSEL e NORVIG, 2004):
P(x
1
, . . . , x
n
) =
n

i=1
P(x
i
|pais(X
i
)) (3.1)
onde os pais(X
i
) denotam os valores especcos das variveis em Pais(X
i
).
Certos relacionamentos de independncia condicional podem ser utilizados na
construo da topologia da rede. O primeiro passo para isso rescrever a distribuio
conjunta em termos de uma probabilidade condicional atravs da regra do produto
(RUSSEL e NORVIG, 2004):
P(x
1
, . . . , x
n
) = P(x
n
|x
n1
, . . . , x
1
)P(x
n1
, . . . , x
1
) (3.2)
Aps esta etapa, repetido o processo, reduzindo cada probabilidade conjuntiva a
uma probabilidade condicional e uma conjuno menor, levando a um grande produto:
P(x
1
, . . . , x
n
) = P(x
n
|x
n1
, . . . , x
1
)P(x
n2
, . . . , x
1
) . . . P(x
2
|x
1
)P(x
1
) (3.3)
=
n

i=1
P(x
i
|x
i1
, . . . , x
1
)
Comparado com a Equao 3.1, possvel visualizar que a especicao da distribuio
conjunta equivalente assero geral de que, para toda varivel X
i
na rede, tem-se:
P(X
1
|X
i1
, . . . , X
1
) = P(X
i
|Pais(X
i
)) (3.4)
desde que Pais(X
i
) {X
i1
, . . . , X
1
}.
53
A Equao 3.4 demostra que a Rede Bayesiana uma representao correta do domnio
somente se cada n condicionalmente independente de seus predecessores na ordenao
dos ns, dados seus pais. Por sua vez, para construir uma Rede Bayesiana com a sua
estrutura correta para o domnio, necessrio selecionar pais para cada n de tal forma
que essa propriedade seja mantida. Sendo assim, os pais de X
i
devem conter todos os ns
em X
1
, . . . , X
i1
que inuenciam diretamente em X
i
(RUSSEL e NORVIG, 2004).
Figura 3.5: Exemplo de uma Rede Bayesiana com as Tabelas de Probabilidade
Condicional.
A Figura 3.5 apresenta uma representao grca de uma Rede Bayesiana que possui
quatro ns, Nublado, Regador, Chuva e Grama Molhada. O Fato do tempo estar ou
no nublado, que o que representa o n Nublado, tem inuncia direta sobre o regador
estar ligado (n Regador) e estar chuvendo (n Chuva). Por sua vez, estes dois ns
tem inuncia direta do o n Grama Molhada. possvel perceber que cada n da
Rede Bayesiana possui uma Tabela de Probabilidade Condicional composta por todas as
possibilidades de resultado possvel para o n, dado evidncias ou no de seus pais (ns
que o inuenciam).
3.3 INFERNCIA EM REDES BAYESIANAS
Sistemas de inferncia probabilbilistico tem como objetivo calcular a distribuio
de probabilidade posterior para um conjunto de variveis de consulta, dado um evento
54
observado. Geralmente, uma consulta busca a distribuio posterior P(X|e) (RUSSEL e
NORVIG, 2004).
Tendo como exemplo uma Rede Bayesiana que represente o problema do carro
funcionar pela manh, pode-se ter como exemplo de inferncia:
P(Lc|Mc = V azio, Cb = False) = < 0.998, 0.02 > (3.5)
Embora existam mais meios de realizar inferncias, com as apresentadas em Link e
Barker (2010), Darwiche (2009), este trabalho aborda apenas inferncia por enumerao,
que abordada de forma direta e objetiva por Russel e Norvig (2004), sendo este, o
algoritmo utilizado na implementao do presente trabalho.
O algoritmo de inferncia por enumerao uma adaptao do ask-enumeration-join,
que realiza inferncia por enumerao a partir da distribuio conjunta total. Este
algoritmo denido pela equao:
P(X|e) = P(X, e) =

y
P(X, e, y) (3.6)
e implementado de acordo com os Algoritmos 3.1 e 3.2.
Algorithm 3.1: ASK-ENUMERATION-JOIN
input : varivel de consulta X,
valores observados e para varivel E,
uma distribuio conjunta P sobre variveis { X } E Y
/* Y = variveis ocultas */
output: uma distribuio sobre X normalizada
1 Q(X) uma distribuio sobre X, inicialmente vazia
2 foreach valor x
i
de X do
3 Q(x
i
) = ENUMERATE-JOIN(VARS[P],e)
4 endfor
5 return NORMALIZE(Q(X))
Sendo que uma Rede Bayesiana fornece uma representao completa da distribuio
conjunta total, a equao
P(x
1
, . . . , x
n
) =
n

i=1
P(x
i
|pais(X
i
)) (3.7)
mostra que os termos P(x, e, y) na distribuio conjunta podem ser escritos com os
produtos de probabilidades condicionais da rede. Desta forma, uma consulta pode ser
respondida com o uso de uma Rede Bayesiana, calculando-se as somas dos produtos das
55
Algorithm 3.2: ENUMERATE-JOIN
input : x,
evidncias e,
variveis vars,
valores values,
distribuio conjunta P
output: um nmero real
1 if vars est vazio then
2 P(x, e, values)
3 end
4 Y PRIMEIRO(vars)
5 return ENUMERATE JOIN(x, e, RESTO(vars), [y|values], P)
probabilidades condicionais (RUSSEL e NORVIG, 2004).
Para realizar inferncia por enumerao em uma Rede Bayesiana, basta adaptar
o algoritmo ask-enumetation-join para receber uma Rede Bayesiana ao invs de uma
distribuio conjunta total e pesquisar entradas conjuntas multiplicando as entradas da
Tabela de Probabilidade Condicional (TPC) correspondentes a partir da Rede Bayesiana.
Esta adaptao apresentada nos Algoritmos 3.3 e 3.4.
Algorithm 3.3: ASK-ENUMERATION
input : varivel de consulta X,
valores observados e para varivel E,
uma rede bayesiana rb com variveis { X } E Y
/* Y = variveis ocultas */
output: uma distribuio sobre X normalizada
1 Q(X) uma distribuio sobre X, inicialmente vazia
2 foreach valor x
i
de X do
3 estender e com valor x
i
para X
4 Q(x
i
) = ENUMERATE-ALL(VARS[rb],e)
5 endfor
6 return NORMALIZE(Q(X))
Um fator que deve ser levado em considerao que inferncia em Redes Bayesianas
possuem complexidade NP-Difcil, ou seja, mais difcil que problemas NP-Completo,
(RUSSEL e NORVIG, 2004). Considerando uma Rede Bayesiana com cinco ns, em uma
consulta com uma evidncia necessrio somar quatro termos que so obtidos atravs
da multiplicao de cinco nmeros. Sendo assim, a complexidade do algoritmo para uma
rede de n ns booleanos O(n2
n
), o que torna a sua execuo crtica de acordo com o
nmero de ns da rede.
Existem formas para minimizar este problema de desempenho, como por exemplo, a
utilizao de um algoritmo de eliminao de variveis ou ento de agrupamentos de ns,
56
Algorithm 3.4: ENUMERATE-ALL
input : lista com ns da rede bayesiana vars
evidncias e
output: um nmero real
1 if vars est vazio then
2 return 1.0
3 end
4 Y PRIMEIRO(vars)
5 if Y tem valor y em e then
6 return P(y|pais(Y ))ENUMERATE ALL(RESTO(vars), e)
7 else
8 return

y
P(y|pais(Y ))ENUMERATE ALL(RESTO(vars), e
y
)
9 end
como apresentado por Russel e Norvig (2004). Como o presente trabalho tem foco na
gerao automtica de uma Rede Bayesiana, estes tipos de algoritmo no so abordados
neste trabalho.
57
4 SISTEMAS MULTIAGENTES
No Captulo 2, foi comentado sobre a utilizao de Redes Bayesianas e Sistemas
Multiagentes para beneciar algumas tarefas do processo de Gesto de Riscos. Neste
captulo, as denies de Agentes e Sistemas Multiagentes so apresentadas, assim como
sua relao com Redes Bayesianas e a utilizao de Sistemas Multiagentes com Redes
Bayesianas para beneciar o processo de Gesto de Riscos.
Agentes, em Sistemas Multiagentes, surgem como um potencial tecnolgico para
auxiliar na complexidade e variedade de cenrios atuais de Tecnologia da Informao. Na
indstria, existem experincias de agentes sendo utilizados no processo de produo, Web
Services, negcios baseados em Web, entre outros. No meio acadmico, estudos apontam
para a possibilidade de explorar Agentes e Sistemas Multiagentes como uma tecnologia
para uma variedade de futuros cenrios, como computao pervasiva, computao em
grade, Web semntica etc (BERGENTI et al., 2004).
Existe um entendimento geral que Sistema Multiagente mais que uma tecnologia
efetiva, representando na verdade, um novo paradigma de desenvolvimento de software.
Computao baseada em agentes compreende o projeto e o desenvolvimento de aplicaes
em termos de entidades de softwares autnomos, ou seja, agentes. Este agentes esto
situados em um ambiente e podem alcanar, de forma exvel, seus objetivos por meio de
interao com outros agentes atravs de linguagens e protocolos de alto nvel (BERGENTI
et al., 2004).
A denio de agente ser apresentada na Seo 4.1, possibilitando, ento, a
introduo a sistema multiagente, que ser abordada na Seo 4.2.
4.1 AGENTE
Autores como Weiss (1999), Wooldridge (2001), Bergenti et al. (2004) e Rezende
(2005) armam no existir uma denio amplamente aceita para agentes. No entanto,
existe um consenso geral que uma caracterstica essencial em um agente autonomia.
Relacionado ao meio computacional, Wooldridge (2001) dene um agente como um
sistema que est situado em um ambiente e que capaz de efetuar aes autnomas
neste ambiente, a m de satisfazer seus objetivos de projeto.
De uma forma mais ampla, Russel e Norvig (2004) denem um agente como qualquer
coisa que capaz de perceber seu ambiente por meio de sensores e de agir sobre este
por meio de atuadores. Ferber e Gasser (apud REZENDE, 2005) corroboram com esta
denio e complementam que so movidos por um conjunto de inclinaes, possuem
58
recursos prprios e podem, eventualmente, se reproduzir.
Para representar a denio de um agente, Russel e Norvig (2004) apresentam
exemplos com relao entre humanos, robs e softwares. Um humano possui olhos,
ouvidos e outros rgos como sensores, e possui mos, pernas, boca e outras partes do
corpo que servem como atuadores. Um rob poderia ter uma cmera e detectores de faixa
infravermelho funcionando como sensores e vrios motores como atuadores. Um agente
de software recebe seqncias de teclas digitadas, contedo de arquivos e pacotes de rede
como entradas sensrias e atua sobre o ambiente exibindo algo na tela, gravando arquivos
e enviando pacotes de rede.
As denies apresentadas podem ser representadas com a Figura 4.1, que mostra um
agente, composto por sensores e atuadores. Os sensores so responsveis pelas percepes
do ambiente e os atuadores por realizar aes neste ambiente.
Figura 4.1: Um agente em um ambiente. (RUSSEL e NORVIG, 2004)
Na maioria dos domnios de complexidade razovel, um agente no ter total controle
sobre o ambiente e ter no melhor dos casos, um controle parcial. Do ponto de vista de
um agente, isso signica que a mesma ao desempenhada duas vezes em circunstncias
aparentemente idnticas, podem, ter efeitos completamente diferentes e deixar de ter o
efeito desejado. Desta forma, os agentes devem estar preparados para uma possvel falha
(WOOLDRIDGE, 2001).
Para evitar falhas, normalmente, os agentes possuem um repertrio de aes
disponveis, que representam a capacidade efetivadora do agente, que possibilita modicar
o ambiente. A escolha de qual ao desempenhar para melhor satisfazer os objetivos de
projeto o problema chave de um agente (WOOLDRIDGE, 2001).
Com base nesta denio, um termostato pode ser considerado um agente. Este agente
59
possui um sensor que detecta a temperatura de uma sala e gera duas possveis sadas:
(i) a temperatura est baixa e (ii) a temperatura est adequada. As aes disponveis
para este agente so: (i) ligar aquecimento e (ii) desligar aquecimento. Sempre que o
sensor identicar que o ambiente est com a temperatura baixa, a ao que ele efetuar
ligar aquecimento e quando identicar que a temperatura est adequada, a ao que
ele realizar desligar aquecimento.
O termostato pode ser visto com um agente, no entanto, no pode ser considerado
um agente inteligente. Para um agente ser considerado inteligente, este deve possuir
caractersticas como: reatividade, pr-atividade, sociabilidade.
Reatividade: Agentes inteligentes so capazes de perceber seu ambiente e responder em
tempo hbil a mudanas que ocorram nele, a m de satisfazer seus objetivos de
projeto.
Pr-atividade: Agentes inteligentes so capazes de expor o seu comportamento voltado
a sua meta, de forma a satisfazer seus objetivos de projeto.
Sociabilidade: Agentes inteligentes tem a capacidade de interagir com outros agentes
de forma a satisfazer seus objetivos de projeto.
4.2 DEFINIO DE SISTEMA MULTIAGENTE
Existem situaes em que agentes podem operar com sucesso isoladamente, no
entanto, com o crescimento de interconees e redes de computadores, este cenrio raro
e os agentes comunicam-se com outros agentes, compreendendo e trocando mensagens
entre si.
De fato, solues centralizadas so mais ecientes, mas algumas vezes, sistemas
computacionais distribudos so mais fceis de compreender e tambm de se desenvolver,
especialmente quando o problema que est sendo resolvido tambm est distribudo.
Tambm existem casos em que uma abordagem centralizada no possvel devido
aos sistemas e dados serem independentes de organizao, ou seja, encontram-se em
organizaes diferentes (WEISS, 1999).
Os cenrios em que a informao distribuda podem ser classicados em: (i) elas so
geogracamente distribudas, (ii) possuem muitos componentes, (iii) possuem um grande
contedo e (iv) possuem um grande escopo.
As quatro grandes tcnicas para lidar com o tamanho e complexidade dos sistemas de
informao destas organizaes so modularidade, distribuio, abstrao e inteligncia,
caracterizando a Inteligncia Articial Distribuda (IDA) (WEISS, 1999).
60
Sistemas multiagentes so o melhor meio de categorizar e projetar sistemas
computacionais distribudos, em que o processamento da informao ubqua, tendo
como principais caractersticas (WEISS, 1999):
1. Ambientes multiagentes possibilitam uma estrutura especca de comunicao e
protocolos de comunicao;
2. Ambientes multiagentes so, tipicamente, distribudos e no possuem um projeto
centralizado;
3. Ambientes multiagentes possuem agentes que so autnomos e distribudos, e talvez,
auto-interessados ou cooperativos.
Um sistema multiagente possui agentes que interagem um com outros atravs de
comunicao, formando uma relao organizacional. Estes agentes so capazes de agir
sobre o ambiente, em que diferentes agentes possuem uma esfera de inuncia sobre este
mesmo ambiente. Estas esferas podem coincidir em alguns casos, podendo aumentar a
dependncia do relacionamento entre agentes (WOOLDRIDGE, 2001).
Figura 4.2: Estrutura tpica de um sistema multiagente (WOOLDRIDGE, 2001).
A Figura 4.2 apresenta de forma mais clara a denio de Wooldridge (2001). A
Figura 4.2 apresenta na parte superior, a comunicao entre agentes, formando ento
uma relao organizacional. Na base da Figura 4.2 pode ser visto o ambiente em que o
61
sistema multiagentes atua. Na centro da Figura 4.2, podem-se visualizar as esferas de
inuncia que o agente tem sobre o ambiente.
Sistemas multiagentes so relevantes para solucionar problemas complexos e
distribudos e as aplicaes projetadas so cada vez mais complexas. Essa complexidade
tem origem e diculdades como (BERGENTI et al., 2004):
Identicar as tarefas que o sistema global tem que resolver;
Identicar qual entidade do sistema um agente;
Denir interao entre agentes;
Especicar protocolos adequados e/ou complexos;
Denir interaes entre o sistema e seu ambientes; e
Denir o comportamento relevante do agente.
Novas ferramentas e modelos ajudam engenheiros a trabalhar com estas novas noes.
Alm disso, o software contm uma enorme quantidade de linhas de cdigo e sua
distribuio aumenta a complexidade para os projetistas que so obrigados a ter em conta
novos problemas, como mobilidade e segurana. Metodologias ajudam os projetistas a
lidar com estes problemas e gerenciar a complexidade envolvida (BERGENTI et al., 2004).
Uma metodologia baseada em agente ou multiagente consiste em um processo, uma
linguagem de modelagem ou notao e uma ferramenta para auxiliar no processo e
na notao, ajudando o projetista. Atualmente, as principais fases deste processo so
similares a aquelas usadas em metodologias orientadas a objetos, ou seja, requisitos,
anlise (ou especicao), projeto, desenvolvimento (ou implementao) e publicao do
sistema (BERGENTI et al., 2004).
Algumas metodologias j foram propostas para o desenvolvimento de sistemas
multiagente e so abordades em Bergenti et al. (2004), como: Gaia, Tropos, MaSE,
ADELFE, MESSAGE, SADDE e Prometheus. A metodologia que ser abordada e
tambm utilizada neste trabalho a Prometheus, que apresentada na Seo 4.3.
4.3 METODOLOGIA PROMETHEUS
Prometheus uma metodologia que tem como objetivo proporcionar a prossionais
e a estudantes de graduao um fcil desenvolvimento de sistemas multiagente sem a
necessidade de um conhecimento prvio do assunto (BERGENTI et al., 2004).
62
Mesmo com este objetivo, a metodologia Prometheus uma abordagem consistente
para construo de sistemas multiagentes. Esta composta por trs fases distintas:
Especicao do Sistema, Projeto Arquitetural e Projeto Detalhado.
Na primeira fase, Especicao do Sistema, so analisados os fatores de entrada
(inputs), sada (outputs), e repositrios de dados (data sources), sejam compartilhados ou
no. Posteriormente, na fase de Design Arquitetural, usam-se os outputs para determinar
que agentes iro existir no sistema, bem como as suas interaes. Tendo isto concludo, a
fase de Design Detalhado pode ser iniciada, em que avaliado internamente como cada
agente ir concluir as suas tarefas (PADGHAM e WINIKOFF, 2004).
Figura 4.3: Diagrama da metodologia Prometheus
A Figura 4.3 apresenta os principais artefatos de projeto que surgem em cada uma
das fases existentes na metodologia, alguns itens intermedirios e a relao entre os itens.
Esta gura dividida horizontalmente e verticalmente. Horizontalmente, esta possui
trs regies que representam as trs fases existentes na metodologia. Verticalmente,
esta tambm possui trs regies, sendo que a regio mais esquerda lida com os
comportamentos dinmicos do sistema, a regio central lida com as vises gerais do
sistema e a mais direita, que detalha cada entidade do sistema (BERGENTI et al.,
2004).
63
O desenvolvedor, ao utilizar esta metodologia, deve considerar alguns fatores
importantes na modelagem do seu respectivo SMA (PADGHAM e WINIKOFF, 2004):
Informaes provenientes do ambiente do sistema so consideradas percepes do
agente;
Mecanismos que podem afetar este ambiente so considerados aes que o agente
pode tomar;
Um evento no considerado igual a uma percepo, trata-se de um conceito de
maior importncia para um agente;
Nem tudo que ocorre no ambiente faz o agente alterar seus planos para alcanar um
objetivo;
Percepes necessitam de processamento por parte do agente para se tornarem um
evento; e
Tal processamento deve ocorrer no agente para ser considerada uma metodologia
Prometheus.
4.3.1 Especicao do Sistema
Esta fase consiste em trs atividades: (i) determinar a interface do sistema para o
ambiente, (ii) determinar os objetivos e funcionalidades do sistema e (iii) capturar os
cenrios que reetem a utilizao do sistema.
A Prometheus utiliza a terminologia utilizada por Russel e Norvig (2004), em que o
o agente percebe alteraes no ambiente atravs de percepes e age sobre ele por meio
de aes. Os dados em forma bruta das percepes podem precisar de um processamento
para se obter informaes dos eventos signicantes para um agente.
A determinao dos objetivos e funcionalidades do sistema so obtidos a partir dos
seguintes passos (BERGENTI et al., 2004):
Identicar e renar objetivos do sistema - principal e secundrio;
Agrupar objetivos em funcionalidades;
Preparar descritores de funcionalidades; e
Vericar se todos os objetivos esto abrangidos pelo cenrio;
Um conjunto de objetivos iniciais obtido de um requisito inicial. Funcionalidades
so limitadas do comportamento do sistema, que descrevem em sentido mais amplo que
64
o sistema precisa ser capaz de fazer. Descritores de funcionalidades capturam o nome de
descrio de cada funcionalidade, assim como os eventos que as ativam, quais objetivos so
alcanados, quais aes so executadas, quais percepes so recebidas, quais mensagens
so enviadas e recebidas e quais dados so utilizados e produzidos (BERGENTI et al.,
2004).
4.3.2 Design Arquitetural
Basicamente, so trs aspectos que so abordados durante o Design Arquitetural, que
so (BERGENTI et al., 2004):
1. Decidir quais tipos de agentes sero utilizados no sistema. O tipo de agente
formado agrupando um nmero de funcionalidades. Os diagramas utilizados para
auxiliar nesta anlise so: data coupling diagrams e agent acquaintance diagrams;
2. Criar a estrutura global do sistema (com um diagrama de viso geral do sistema,
juntamente com descritores); e
3. Descrever interaes entre agentes utilizando o diagrama de interaes e protocolos
de interao.
4.3.3 Design Detalhado
Esta fase lida com a parte interna de cada agente, ao invs do sistema como um todo.
utilizado um modelo hierrquico de modo que cada agente dividido em capacidades e
estas podem ser includas em mais de uma agente.
Os passos que compe o Design Detalhado so:
1. Desenvolver a viso geral dos agentes (mostrando as interaes entre as capacidades)
e os descritores de capacidade.
2. Desenvolver o processo interno dos protocolos de interao de um agente, utilizando
uma variante de diagramas de atividade Unied Modeling Language UML.
3. Desenvolver o projeto interno de cada capacidade em termos de planos, eventos,
crenas e possivelmente sub-capacidades.
65
5 TRABALHOS RELACIONADOS
Este captulo apresenta os trabalhos relacionadas com o trabalho proposto. At o
presente momento, no foram encontrados trabalhos com o mesmo objetivo do trabalho
proposto. Os artigos que so apresentados neste captulo so os que contriburam e
tambm serviram como base para a elaborao deste trabalho, mas em alguns casos no
possuem relao entre si, impossibilitando a comparao entre eles.
Segurana da Informao uma rea de pesquisa muito recente e tambm com muitos
temas ainda em abertos. Este o principal motivo por no existirem trabalhos com o
mesmo objetivo que o trabalho proposto.
A utilizao de Redes Bayesianas para favorecer a Gesto de Riscos em Segurana
da Informao abordada por Dantu e Kolan (2005) e Dantu et al. (2007). Dantu
e Kolan (2005) calculam o nvel de riscos dos recursos crticos da organizao tendo
em vista o aparecimento de novas vulnerabilidades e no comportamento do atacante,
utilizando Redes Bayesianas para isto. A metodologia proposta possui cinco etapas: (i)
criao do perl do atacante, (ii) criao de um grafo de ataque, (iii) atribuir atributos
de comportamento ao grafo de ataque, (iv) clculo do risco, e (v) otimizao do nvel de
risco.
Criao do perl do atacante O perl de um atacante fornece os recursos
prescindveis associados com o atacante. Esses recursos podem ser: qualquer custo,
habilidades na informtica e no hacking, tenacidade, perseverana (como vingana)
e reputao. Diferentes pers de ataque possuem diferentes valores para atributos
comportamentais para o recurso do atacante. Uma espionagem corporativa envolve
mais dinheiro que um script kiddie
1
, que realiza o hack apenas por diverso. O
funcionrio de uma empresa tem mais conhecimento que um hacker sobre a topologia
da rede. Com base nestas relaes, atribudo um custo para cada perl de atacante.
Criao de uma grafo de ataque Um grafo criado com base na topologia da rede,
interconexes entre hosts e vrias vulnerabilidades de uma dado host. O grafo de
ataque representado por um grafo de causalidade, em que cada n representa uma
causa e seus ns lhos representam um efeito. Cada n do grafo representa um
evento, e um caminho do n raiz do at a folha representa um ataque bem sucedido.
Atribuir atributos de comportamento ao grafo de ataque Para o perl de um
determinado invasor, os ns do grafo so rotulados com um conjunto de atributos de
comportamento, tais como: conhecimento em informtica, habilidades de hacking,
tenacidade, custo do ataque, tcnicas para evitar deteco etc.
1
Termo utilizado para denir atacantes inexperientes, geralmente jovens.
66
Clculo do risco O nvel de risco para todos os recursos so calculados com base no
conjunto de caminhos, atributos e o tipo do atacante. Nesta etapa, uma estimativa
baseada em Redes Bayesianas utilizada para calcular o valor de risco agregado
para cada recurso.
Otimizao do nvel de risco Em uma rede tpica, a correo de uma vulnerabilidade
pode impactar outros elementos da rede. Por exemplo, depois de corrigir algumas
falhas e mudar a congurao da rede (mover o rewall para outro local na topologia,
alterar as regras de rewall ou implementar um sistemas de deteco de intruso),
a etapa (iii) desta metodologia necessita ser executada repetidamente para se obter
um valor de risco timo. Este valor estimado de risco ajudaria em processos como
o gerenciamento de patches e teste de invaso etc.
Complementando esta abordagem de Dantu e Kolan (2005), o trabalho de Dantu et al.
(2007) apresenta uma classicao de atributos e comportamentos em Gesto de Riscos
utilizando Redes Baysianas. Neste trabalho, os princpios apresentados em Dantu e Kolan
(2005) so mantidos, tendo como foco o perl de comportamento.
Fenz e Hudec (2009) propoem um mtodo para gerao de Redes Bayesiana baseado
em uma ontologia de segurana da informao. O mtodo desenvolvido permite, com base
na ontologias, gerar de forma semi-automtica e alterar a Rede Bayesiana.
O mtodo proposto por Fenz e Hudec (2009) possui quatro fases, que so:
Componentes, Relaes, Axiomas e Instancias.
Componentes Ns Os conceitos da ontologia que so considerados importantes para
o problema, so selecionados para formar a Rede Bayesiana.
Relao Links As relaes da ontologia que comeam e terminam entre os conceitos
selecionados so utilizados para estabelecer as ligaes entre os ns da Rede
Bayesiana.
Axiomas Escala e peso dos ns A escala e o peso dos axiomas relevantes so
utilizados para determinar os estados e pesos potenciais dos ns da Rede Bayesiana.
Instncias Resultados Instncias de conceitos representados pelos ns folhas da
Rede Bayesiana so utilizados para obter e tambm inserir resultados concretos
na rede.
Este mtodo permite a criao semi-automtica de Redes Bayesianas a partir de uma
ontologia j existente, reduz a complexidade de modelagem de Redes Bayesianas utilizando
conceitos de alto nvel e relaes relevantes para a integrao de sub-conceitos para a Rede
67
Bayesiana e prev, atravs do uso de ontologias, a possibilidade de fcil manuteno do
conhecimento subjacente das Redes Bayesianas.
As limitaes do mtodo proposto, apresentadas pelos prprios autores so: (i)
as funes para calcular tabelas de probabilidade condicional no so fornecidos pela
ontologia e necessitam ser modelados externamente, e (ii) a interveno humana ainda
necessria se a ontologia fornece um modelo de conhecimento que no est ajustado ao
domnio de interesse.
A pesquisa sobre o perl do atacante realizada por Dantu et al. (2007) a principal
contribuio para o trabalho proposto. Os comportamentos classicados pelos autores
podem ser utilizados para complementar o modelo proposto.
As etapas sugeridas por Fenz e Hudec (2009) serviram como base para o modelo
proposto. No entanto, a forma pelo qual os dados so obtidos so diferentes. Dantu
et al. (2007) buscam informaes em uma ontologia para montar sua Rede Bayesina.
No trabalho proposto, as informaes so obtidas a partir de agentes que localizam
as informaes em ambientes especcos, como a base de dados de congurao de
ativos, base de dados de incidentes reportados na organizao e em base de dados de
vulnerabilidades reportadas no mundo. Desta forma, as limitaes do mtodo de Dantu
et al. (2007) podem ser minimizadas.
A ferramenta proposta por (EKELHART et al., 2009) utiliza a gerao de Redes
Bayesianas de Fenz e Hudec (2009). Esta ferramenta, que recebe o nome de Automated
Risk and Utility Management (AURUM) destinada a minimizar a interao entre
gestores de segurana da informao e sistemas.
Para alcanar este objetivo, o AURUM utiliza uma ontologia de segurana da
informao, uma ferramenta de inventrios, redes bayesianas e o mtodo para o clculo
do risco. A arquitetura do AURUM apresentada na Figura 5.1.
Figura 5.1: Arquitetura do ferramenta AURUM
O AURUM tem como principal caracterstica a descoberta automtica de ativos no
ambiente da organizao atravs de ferramentas como NMAP, PING, OCS Inventory NG,
68
etc, que so ferramentas que coletam informaes sobre os ativos computacionais atravs
da rede. Outra caracterstica importante a criao de uma rede bayesiana a partir de
uma ontologia do domnio de segurana da informao.
Este trabalho o mais prximo do trabalho proposto, visto que possui um objetivo
similar. No entanto, o trabalho no considera informaes pontuais sobre incidentes que
aconteceram na organizao e tambm as vulnerabilidades existentes para os ativos que
compem o negcio da organizao.
69
6 TRABALHO PROPOSTO
Este captulo apresenta o trabalho proposto, assim como sua estrutura, arquitetura,
algoritmos e mtodos utilizados. Como o mtodo proposto baseado em sistemas
multiagentes, o captulo inicia com a descrio dos cenrios existentes no sistema,
seguido de todos os itens que compem o sistema multiagente. Detalhes especcos
do mtodo de gerao da Rede Bayesiana so apresentados na Seo 6.4. Detalhes
sobre o desenvolvimento do prottipo so apresentados na Seo 6.6. A simulao para
teste do prottipo descrita na Seo 6.7.1 e os resultados obtidos com o prottipo so
apresentados na Seo 6.7.2.
O sistema multiagente proposto no presente trabalho composto pelos seguintes
cenrios; o identify asset, o identify incedent e o identify vulnerabilty. Nestes trs cenrios
esto presentes quatro agentes de software e quatro bancos de dados.
Figura 6.1: Viso geral do sistema multiagente proposto
A Figura 6.1 apresenta uma viso geral do sistema multiagente que est sendo proposto
para atender os objetivos do trabalho. O diagrama ilustrado na Figura 6.1 apresenta os
trs cenrios que inicia o sistema multiagente, que so: (i) identify asset, (ii) identify
incident e (iii) identify vulnerability. Cada cenrio possui um agente, que so eles: (i)
ag Asset, (ii) ag Incident e (iii) ag Vulnerability, respectivamente. Estes trs agentes
comunicam-se com o agente ag Risk, que o principal agente do sistema.
Os trs cenrios existentes no sistema esto diretamente relacionados aos os agentes
ag asset, ag incident e ag vulnerability. O cenrio identify asset disparado a partir
da alterao realizada pelos responsveis pela TI da organizao na base de dados de
congurao de ativos. O cenrio identify incident disparado a partir da alterao
70
na base de dados de incidentes de segurana, que administrada pelos responsveis
pela segurana na organizao. O cenrio identify vulnerability disparado a partir da
alterao na base de dados de vulnerabilidades da NVD, que realizada com a colaborao
de organizaes de apoio a incidentes de segurana.
Ao longo deste captulo, maiores detalhes sobre o sistema sero abordados. A Seo 6.1
existentes no sistema proposto. As bases de dados utilizadas no sistema so apresentadas
na Seo 6.2. Os agentes que compem o sistema so abordados na Seo 6.3, assim como
as mensagens trocadas por estes agentes. Finalizando o captulo, a Seo 6.4 apresenta
os detalhes sobre a gerao da Rede Bayesiana pela agente ag Risk.
6.1 CENRIOS
Esta seo apresenta os trs cenrios que compem o sistema multiagentes proposto
e introduz o funcionamento do sistema a partir de cada cenrio.
Identify Asset: As percepes que caracterizam este cenrio so a identicao de um
novo ativo na infraestrutura de tecnologia da informao ou alguma alterao nestes
ativos. A identicao de um novo ativo ou a identicao da alterao de um
novo ativo so as percepes do agente ag asset. Quando identicado um novo
ativo, o agente ag asset armazena a informao no banco de dados db asset e,
posteriormente, envia para o agente ag risk as informaes do ativo identicado,
que ir executar todos os processos necessrios para atualizar a Rede Bayesiana de
riscos, incluindo este novo ativo na rede.
Identify Incident: Este cenrio tem incio com a identicao de novos incidentes
envolvendo os ativos de tecnologia da informao da organizao ou alteraes nos
incidentes relacionadas a segurana da informao nos ativos de TI da organizao,
caracterizando ento as duas percepes do agente ag incident. Quando este agente
identica um novo incidente ou a alterao de um incidente, este informa ao agente
ag risk as alteraes do ambiente identicadas para que este execute todos os
processos necessrios para atualizar a Rede Bayesiana de riscos. Estes incidentes
so tratados como evidncias na rede.
Identify Vulnerability: Este o cenrio em que o sistema identica uma nova
vulnerabilidade nos ativos de TI da organizao ou alguma alterao nas
vulnerabilidades j conhecidas. O agente ag vulnerability identica as alteraes
no ambiente atravs das suas duas percepes e comunica ao agente ag risk" sobre
estas alteraes para que este realize os processos necessrios para montar ou alterar
a Rede Bayesiana.
71
6.2 BASES DE DADOS
Este seo descreve a utilizao as base de dados utilizadas no sistema proposto
no presente trabalho, assim como as estruturas relacionais que foram utilizadas no
desenvolvimento do sistema.
6.2.1 DB Vulnerability
Esta base de dados possui as vulnerabilidades reportadas em todo mundo e so
disponibilizadas livremente no endereo eletrnico http://cve.mitre.org. Os dados so
disponibilizados em um formato eXtensible Markup Language - XML. Este documento
XML utiliza padres de nomenclatura, conforme subseo 2.4.1, que possibilita a
identicao exata dos ativos que esto sujeitos s vulnerabilidades nela reportadas. As
informaes contidas nesta base so armazenadas em um banco de dados local para que
sejam utilizadas para o clculo do fator de risco dos ativos de TI.
Futuramente, outras fontes de vulnerabilidades tambm podero ser utilizadas, visto
que estas bases possuem referncias entre elas, o que possibilita que vulnerabilidades no
sejam duplicadas.
Figura 6.2: Modelo ER da base de dados DB Vulnerability
A Figura 6.2 apresenta o modelo relacional utilizado para armazenar as
vulnerabilidades importadas da base de dados do NVD. Como pode se perceber, o modelo
composto por trs tabelas.
A primeira tabela, chamada Vulnerability, destinada a armazenar os dados
relacionados s vulnerabilidades. Esta tabela segue a mesma estrutura da base do NVD,
exceto por dois campos, que so: is_new e hash. O campo is_new utilizado para
identicar as vulnerabilidade novas, ou seja, recm adicionadas na base local. Este campo
72
alterado para false assim que a vulnerabilidade processada pela primeira vez no
sistema. O Campo hash utilizado para armazenar um hash dos dados que compem a
vulnerabilidade e utilizado para identicar qualquer alterao na congurao de uma
vulnerabilidade. Quando uma alterao na congurao da vulnerabilidade identicada,
esta alterao divulgada no sistema e o valor da campo hash atualizado com o hash
da nova congurao da vulnerabilidade.
A segunda tabela, chamada VulnerabilitySoftwares faz a relao das vulnerabilidades
com os softwares afetados, que so armazenados na terceira tabela, chamada Softwares.
A tabela Softwares segue a mesma estrutura de um nome CPE, apenas separando cada
parte de um nome CPE em colunas.
6.2.2 DB Asset
A base de dados de ativos possui todos os ativos pertencentes aos processos de
negcio da organizao. Estes ativos se relacionam com determinados processos e tambm
possuem uma estrutura que gera uma dependncia entre eles.
Este trabalho assume que a organizao segue a estrutura proposta por este trabalho
para gerenciar seu banco de dados de congurao de ativos.
Figura 6.3: Modelo ER da base de dados DB Asset
A Figura 6.3 apresenta o modelo relacional proposto para armazenar as informaes
referentes aos ativos da organizao. Como pode-se perceber, o modelo composto por
trs tabelas.
A primeira, chamada ComputerAsset, que armazena as informaes referentes aos
ativos computacionais da organizao. A estrutura desta tabela descrita a seguir:
id: coluna utilizada para armazenar o identicador do registro;
description: coluna destinada a armazenar uma descrio a m de identicar o ativo
computacional;
73
hardware: coluna destinada a armazenar o nome CPE referente ao hardware do ativo
computacional;
operational_system: coluna destinada a armazenar o nome CPE referente ao sistema
operacional do ativo computacional;
condenciality_impact: coluna destinada a armazenar um valor referente ao impacto
na condencialidade que o ativo computacional possui sobre o negcio da
organizao;
integrity_impact: coluna destinada a armazenar um valor referente ao impacto na
integridade que o ativo computacional possui sobre o negcio da organizao;
availability_impact: coluna destinada a armazenar um valor referente ao impacto na
disponibilidade que o ativo computacional possui sobre o negcio da organizao;
is_new: coluna destinada a identicar os ativos computacionais novos, ou seja, recm
adicionado base local. Este campo alterado para false assim que o ativo
computacional processado pela primeira vez no sistema; e
hash: coluna destinada a armazenar um hash dos dados que compem o ativo
computacional, sendo este, utilizado para identicar qualquer alterao na
congurao do ativo computacional.
A segunda tabela, camada ComputerAssetSoftwares, que relaciona os ativos
computacionais aos seus softwares (que tambm so seus ativos), que so armazenados
na terceira tabela apresentada, chamada de softwares, que segue a mesma estrutura de
um nome CPE.
6.2.3 DB Incident
Esta base de dados armazena todos os incidentes de segurana da informao que
ocorreram nos ativos de TI da organizao. As causas que levaram ao incidente, sempre
que identicadas, tambm so armazenadas nesta base. O mesmo ocorre com os ativos
envolvidos.
A estrutura desta base de dados ser denida de forma a atender os requisitos do
sistema proposto neste trabalho. Assume-se que a organizao utilizar esta estrutura
para armazenar os incidentes que ocorrem em seus ativos de TI.
A Figura 6.4 apresenta o modelo relacional proposto para armazenar os incidentes de
segurana da informao. Como pode-se perceber, o modelo composto por duas tabelas.
A tabela chamada de Incident armazena os dados dos incidentes e sua estrutura
descrita a seguir:
74
Figura 6.4: Modelo ER da base de dados DB Incident
id: coluna utilizada para armazenar o identicador do registro;
id_software: coluna destinada a relacionar o incidente a um software;
aected_os: coluna utilizada para informar se o incidente comprometeu ou no o
sistema operacional;
aected_computer_asset: coluna utilizada para informar se o incidente comprometeu
ou no o funcionamento do ativo computacional;
description: coluna destinada a armazenar uma descrio a m de identicar o ativo
computacional;
active: coluna destinada a informar se o incidente ainda est ativo ou se alguma soluo
de contorno foi adotada;
is_new: coluna destinada a identicar novos incidentes, ou seja, recm adicionados
base de dados. Este campo alterado para false assim que o incidente processado
pela primeira vez no sistema; e
hash: coluna destinada a armazenar um hash dos dados que compem o incidente, sendo
este, utilizado para identicar qualquer alterao na congurao de um incidente.
6.2.4 DB Risk
uma base de dados consolidada, onde os fatores de risco dos ativos de TI so
armazenados. A partir desta base de dados, os usurios (prossionais de gesto de risco)
podero efetuar consultas e analisar os riscos de segurana existentes na organizao.
Por esta ser a base de dados utilizada pelo Ag Risk, esta possui um modelo que replica
todo o sistema. Esta abordagem utilizada para melhorar o desempenho do sistema,
diminuindo a quantidade de consultas a outros agentes no momento da execuo do
algoritmo que gera a Rede Bayesiana. As informaes desta base de dados so modicadas
75
de acordo com as informaes enviadas pelos outros agentes que compem o sistema
multiagente.
A nica tabela que no possui um relao direta com as informaes enviadas pelos
agentes do sistema a tabela RiskHistory. Esta tabela utilizada para armazenar
o resultado do clculo do risco dos agentes computacionais, possibilitando assim, a
gerao de grcos que demonstram a evoluo no tempo do risco relacionado aos ativos
computacionais. A gerao deste tipo de grco est fora do escopo do presente trabalho.
A Tabela RiskHistory composta por trs colunas, sendo a coluna id destinada a
armazenar o identicador do registro na tabela, id_risk_computer_asset utilizado para
relacionar ao ativo computacional referente ao resgistro, risk que armazena o fator de risco
do ativo computacional e date, que armazena a data e hora que o clculo foi realizado.
Figura 6.5: Modelo ER da base de dados DB Risk
76
6.3 AGENTES
Esta seo apresenta os agentes que compem o sistema, assim como suas ligaes
com os banco de dados, suas percepes, aes, comunicaes com outros agentes e o seu
papel dentro do sistema.
6.3.1 Ag Asset
O agente ag asset" lida com as informaes dos ativos de TI da organizao. O
ambiente sobre o qual ele atua o banco de dados de congurao de ativos, que recebe o
nome de db asset" neste sistema. O papel que este agente tem no sistema de monitorar
alteraes na congurao de ativos da organizao.
As percepes que este agente tem do ambiente so (i) percept new asset" (perceber
um novo ativo), que detecta a existncia de um novo ativo na organizao e (ii) percept
change asset" (perceber alterao na congurao de ativos), que detecta a alterao da
congurao de um ativo.
Para este trabalho, assume-se que a organizao possui um processo de gesto de
ativos e que mantm a base de dados de congurao de ativos sempre atualizada.
O termo congurao utilizado pelo fato de um ativo poder ser composto por um
conjunto de outros ativos. Isso possibilita que um computador (hardware), que um ativo,
tenha um sistema operacional Windows instalado, que tambm um ativo. Caso este
computador seja formatado e tenha o sistema operacional Linux instalado, uma alterao
na congurao de um ativo foi realizada e deve ser identicada.
A partir destas percepes, o agente executa as aes act inform new asset" (informar
um novo ativo) e act inform change asset" (informar alterao de um ativo), efetuando
ento seu papel de identicar alteraes no ambiente que recebe o nome de rule chance
asset environment". O outro papel que este agente possui o rule answer about asset",
que responde a consultas sobre os ativos.
A comunicao deste agente com o agente ag risk" realizada atravs das mensagens
que so apresentadas na Tabela 6.1.
6.3.2 Ag Incident
O agente ag indicent" lida com as informaes relacionadas aos incidentes de
Segurana da Informao que ocorreram nos ativos de TI da organizao. O ambiente
sobre o qual ele atua o banco de dados com o histrico de incidentes de Segurana da
organizao, ou seja, o banco db incident.
77
Tabela 6.1: Mensagens trocadas com o agente ag asset".
Nome Descrio Origem Destino
msg inform new asset Informa a existncia de um novo ativo no
ambiente
ag risk ag asset
msg inform change asset Informa a existncia de uma alterao na
congurao de um ativo no ambiente
ag risk ag asset
msg ask about asset Solicita informaes com relao aos
ativos
ag asset ag risk
msg answer about asset Retorna informaes sobre os ativos ag risk ag asset
As percepes do agente ag incident tem do ambiente so (i) percept new incident
(perceber um novo incidente), que detecta o relato de um novo incidente de segurana
e (ii) percept change incident" (perceber alterao em um incidente) que detecta que
a descrio de um incidente foi alterada. Incidentes podem afetar mais de um ativo.
Existem casos que isto s identicado em um segundo momento, necessitando ento que
um relato do incidente seja atualizado. O trabalho assume que a organizao possui uma
base de dados em que os incidentes de segurana so informados pelos responsveis pelo
setor de TI.
A partir das percepes do agente, este executa as aes act inform new incident"
(informar um novo incidente) e act inform change incident (informar alterao de um
incidente), efetuando ento seu papel de identicar alteraes no ambiente, que recebe o
nome de rule change incident environment. O outro papel que este agente possui o
rule answer about incident", que responde a consultas sobre os incidentes.
A comunicao deste agente com o agente ag risk" realizada atravs das mensagens
que so apresentadas na Tabela 6.2.
Tabela 6.2: Mensagens trocadas com o agente ag incident.
Nome Descrio Origem Destino
msg inform new
incident
Informa a existncia de um novo
incidente no ambiente
ag risk ag incident
msg inform change
incident
Informa a existncia de uma alterao
na congurao de um incidente no
ambiente
ag risk ag incident
msg ask about incident Solicita informaes com relao aos
incidentes
ag incident ag risk
msg answer about
incident
Retorna informaes sobre os
incidentes
ag risk ag incident
78
6.3.3 Ag Vulnerability
O agente ag vulnerability" lida com as informaes relacionadas a vulnerabilidades
de Segurana da Informao de ativos de TI. O ambiente sobre o qual ele atua o banco
de dados com o histrico de vulnerabilidades de ativos de TI em uma escala mundial.
As percepes que o agente ag vulnerability" tem do ambiente so: (i) percept new
velnerability" (perceber uma nova vulnerabilidade), que detecta o relato de uma nova
vulnerabilidade de segurana e (ii) percept change vulnerability" (perceber alterao
em uma vulnerabilidade) que detecta que houve alguma alterao no relato de uma
vulnerabilidade. Uma vulnerabilidade pode afetar diversas verses de um ativo (como o
Windows). Em um primeiro momento, uma vulnerabilidade pode ter sido identicada
para o Window XP, posteriormente, pode ter sido constatado que o Windows Vista
tambm vulnervel a mesma vulnerabilidade. Neste caso, o relato desta vulnerabilidade
ter uma alterao para adicionar o novo ativo vulnervel.
Tabela 6.3: Mensagens trocadas com o agente ag vulnerability".
Nome Descrio Origem Destino
msg inform new
vulnerability
Informa a existncia de uma nova
vulnerabilidade no ambiente
ag risk ag
vulnerability
msg inform change
vulnerability
Informa a existncia de uma alterao
na descrio de uma vulnerabilidade
ag risk ag
vulnerability
msg ask about
vulnerability
Solicita informaes com relao a
vulnerabilidade
ag
vulnerability
ag risk
msg answer about
vulnerability
Retorna informaes sobre
vulnerabilidades
ag risk ag
vulnerability
A partir das percepes do agente, ele executa as aes act inform new vulnerability"
(informar uma nova vulnerabilidade) e act inform change vulnerability" (informar
alterao de uma vulnerabilidade), efetuando ento seu papel de identicar alteraes no
ambiente, que recebe o nome de rule chance vulnerability environment". O outro papel
que este agente possui o rule answer about vulnerability", que responde a consultas
sobre vulnerabilidades.
A comunicao deste agente com o agente ag risk" realizada atravs das mensagens
que so apresentadas na Tabela 6.3.
6.3.4 Ag Risk
Este agente o centro do sistema, sendo responsvel por administrar a Rede
Bayesiana, ou seja, adicionar e remover ns da rede, realizar consultas na rede e consultar
79
outros agentes do sistema para complementar a rede. O agente ag risk" troca mensagens
com todos os agentes do sistema.
O funcionamento deste agente descrito na Seo 6.4, que aborda o modo pelo qual
gerada a Rede Bayesiana.
6.4 CRIAO DA REDE BAYESIANA
Esta seo descreve o mtodo que est sendo proposto para criar uma Rede Bayesiana
com base nos ativos de TI da organizao, suas vulnerabilidades e o histrico de incidentes
de segurana da organizao.
A criao da Rede Bayesiana baseada na idia do mtodo proposto por Fenz e Hudec
(2009). No entando, este trabalho trata as vulnerabilidades de uma forma diferente. Fenz
e Hudec (2009) utilizam em sua ontologia vulnerabilidades de processo, como por exemplo
No Security Audits" (Sem auditorias de segurana), que indica que no foram realizadas
auditorias de segurana na organizao. O presente trabalho lida com vulnerabilidades
tcnicas de ativos eletrnicos que so reportadas em bases de dados pblicas, como
apresentado na Seo 2.4.
O mtodo proposto para gerar automaticamente uma Rede Bayesiana composto por
trs etapas, que so estas:
1. identicar novos ns e relacion-los;
2. determinar pesos e escalas; e
3. validar a rede.
Cada uma destas etapas comentada com detalhes nas subsees subsequentes.
6.4.1 Identicar e Relacionar os Ns
Esta etapa utiliza as informaes enviadas pelo agente ag Asset, que so relacionadas
a congurao dos ativos da organizao. Esta etapa consistem em gerar um grafo
representando a relao entre os ativos de acordo com o mtodo proposto.
A relao proposta no mtodo organizada da seguinte forma:
Os ativos computacionais tem como pais, todos os ativos de aplicao e de sistema
operacional que o compem; e
80
Os ativos de sistema operacional tem como pais todos os ativos de aplicao que
esto instalados sobre ele e tambm o ativo de hardware em que est instalado.
Para elaborar esta relao foi considerado que uma vulnerabilidade em um aplicativo
pode comprometer o sistema operacional no qual ele est instalado e/ou comprometer
a funo para qual o ativo computacional destinado. Por exemplo, a falha de um
hardware pode comprometer o funcionamento do sistema operacional. E por m, falhas
em aplicativos e sistemas operacionais podem comprometer a funo para qual o ativo
computacional destinado.
Esta organizao forma um grafo de quatro nveis, cada um representando um tipo de
ativo (hardware, aplicativo, sistema operacional e computacional). Como as mensagens
que so trocadas entre os agentes so baseadas no padro de nomenclatura CPE e
este possui apenas trs classicaes para plataforma, que so hardware (h), sistema
operacional (o) e aplicao (a), foi adicionado uma classicao a este padro, que
o computacional (c), sendo este utilizado apenas no mtodo proposto no presente
trabalho. Os demais ativos so apenas considerados como parte integrante de um ativo
computacional.
Para evitar ns duplicados, so executadas os seguintes passos : (i) vericar se o
ativo computacional j existe na rede, caso no exista, este adicionado como um n;
(ii) verica se os ativos que compem o ativo computacional j existem na rede, caso no
existam, estes so adicionados; (iii) remover a relao do ativo computacional com ativos
que no mais pertencem a sua congurao; e (iv) adicionar relaes com novos itens de
congurao (ativos). Este uxo pode ser melhor visualizado na Figura 6.6.
Figura 6.6: Fluxo para adio de um ativo computacional na Rede Bayesiana.
A Figura 6.7 apresenta dois grafos representando as relaes de uma Rede Bayesiana.
O grafo que pode ser visto na Figura 6.7a representa o relacionamento da Rede Bayesiana
com apenas um ativo computacional, que o ativo que recebe o nome de Estao de
Trabalho 1. O grafo apresentado na Figura 6.7b mostra o estado desta mesma rede
aps acrescentar um novo ativo computacional, o qual recebeu o nome de Estao de
81
Trabalho 2. possvel perceber que alm do n referente ao ativo Estao de Trabalho
2, surgiram outros ns, que so referentes aos ativos que integram o ativo computacional,
que so eles: OO Writer, Piddigin e Windows XP. Note que os ns Firefox e Dell no
foram duplicados, visto que so utilizados nos dois ativos computacionais existentes.
(a) Rede Bayesiana inicial (b) Rede Bayesiana aps etapa dois
Figura 6.7: Exemplo de conexes em uma Rede Causal.
Para melhor entender o relacionamento da rede gerada na etapa 2, a Figura 6.7a ser
utilizada como exemplo. Na Figura 6.7a pode ser visto o n Estao de Trabalho 1. A
probabilidade de uma vulnerabilidade vir a ser explorada no ativo que este n representa
depende da probabilidade de uma vulnerabilidade vir a ser explorada nos ativos que
compem este ativo, ou seja, seus pais. Na caso do exemplo da Figura 6.7a, os pais do n
Estao de Trabalho 1 so os ns: Firefox, MS Word, MSN e Windows Seven. O
mesmo ocorre para os ns Firefox, MS Word e MSN, que possuem uma dependncia
do ns Windows Seven.
No grafo apresentado na Figura 6.7b possvel visualizar um caso que no visto no
grafo apresentado na Figura 6.7b. Neste grafo, o n que referente ao ativo Firefox
possui inuncia sobre os ns Estao de Trabalho 1 e Estao de Trabalho 2 e
inuenciado pelo ns referentes aos ativos Windows Seven e Windows XP.
6.4.2 Determinar Pesos e Escalas
Com os ns da rede j atualizados, tem-se incio a segunda etapa, que consiste em
determinar pesos e escalas. Nesta etapa as Tabelas de Probabilidade Condicional (TPC)
so geradas. Esta etapa divida em dois passos distintos. O primeiro passo gera todos
os estados possveis, dados os pais do ns. O segundo passo calcula os peso de cada uma
das possibilidades geradas.
82
Estes dois passos so executados pelo Algoritmo 6.1, sendo o primeiro passo executado
na linha 6, em que executado o Algoritmo 6.2, responsvel por gerar a estrutura da TPC.
A segunda etapa executada no trecho de cdigo entre as linhas 7 e 15 do Algoritmo 6.1.
Algorithm 6.1: Algoritimo para gerao de TPC
1 nodes_finalized um conjunto com os ns j processos, inicialmente vazio
2 nodes la contendo todos os ns da rede
3 while nodes = do
4 node nodes.dequeue()
5 if length(node) == 0 or parents(node) nodes_finalized then
6 GENERATE-CPT(node)
7 if length(node) == 0 then
8 P(node) = probapriore(node)
9 nodes_finalized.add(node)
10 continue
11 end
12 foreach valor k
i
de node.cpt do
13 node.cpt[k
i
] = getstatistic(node)
14 nodes_finalized.add(node)
15 endfor
16 else
17 nodes.queue(node)
18 end
19 end
Algorithm 6.2: GENERATE-CPT
input: um n da rede node
1 if length(node) == 0 then
2 P(node) = null
3 continue
4 else
5 auxctp = null
6 lastcpt = node.parents[0]
7 foreach valor p
i
de node.parents do
8 row = (True, False)
9 foreach valor k1
i
de p.cpt do
10 foreach valor k2
i
de row do
11 auxcpt[k1 k2] = null
12 end
13 end
14 lastcpt = auxcpt
15 end
16 node.cpt = lastcpt
17 end
Para gerar a TPC necessrio que a TPC de todos os ns pais j estejam criadas.
83
Para no utilizar recursividade, que aumenta a complexidade do algoritmo, foi usada um
la para armazenar os ns que j tiveram sua TPC calculada. Pode-se perceber que o
Algoritmo 6.1 permanece em uma lao at que todos os ns da rede sejam processados. Na
linha 5 do Algoritmo 6.1 realizado um teste para vericar se o n que vai ser processado
possui pais, caso positivo, se todos os pais pertencem ao conjunto de ns j processados.
Caso este teste no seja verdadeiro, o n adicionado ao nal da la e ser processado
futuramente. Caso o teste retornando verdadeiro, o algoritmo continua sua execuo e ao
seu trmino, o n adicionado no conjunto de ns j processados.
A linha 6 do Algorimo 6.1 gera a estrutura da TPC do n que est sendo processado
atravs do Algoritmo 6.2. O Algoritmo 6.2 apenas gera a estrutura da TPC, sendo que
os valores da TPC sero atribudos nos prximos passos do Algoritmo 6.1.
Para atribuir os valores a TPC gerada, so considerados dois casos. O primeiro caso
quando o n no possui pais. Neste caso o valor atribudo a TPC a probabilidade a priore
do n, que neste caso a pontuao bsica do ativo no CVSS. O outro caso quando
o n possui ns pais. Possuindo ns pais atribudo um valor obtido atravs de uma
anlise estatstica na base de incidentes reportados. Esta anlise leva em considerao
a quantidade de incidentes relacionados ao mesmo tipo de ativo do pai que afetaram o
mesmo tipo de ativo do ns lhos. Desta forma possvel obter o impacto que determinado
ativo tem sobre outro, caso este no exera sua funo corretamente. Neste caso o valor
atribudo utiliza a equao:
NOA
NO
BS (6.1)
para calcular sua probabilidade a priori, onde NOA o nmero total de ocorrncias de
incidentes que afetam o ativo computacional, NO o nmero de ocorrncias de incidentes
e BS a pontuao bsica da vulnerabilidade.
Obtendo os valores da TPC atravs de estatstica real baseada em uma base de
incidentes que ocorrem no ambiente de tecnologia da informao da organizao leva
a uma Rede Bayesiana que reete a realidade desta organizao e que ajustada de
acordo com os acontecimentos neste ambiente. A possibilidade de utilizar dados de
outras organizaes disponibilizados anonimamente em uma base de dados cooperativa
ser avaliada em trabalhos futuros.
6.4.3 Validar a Rede
Para garantir que a rede gerada at a etapa dois realmente uma Rede Bayesina,
necessrio validar esta rede, sendo essa a terceira etapa do mtodo. Essa etapa consiste
em vericar se o grafo gerado acclico, e tambm, as TPCs geradas.
84
Para vericar se o grafo acclico, percorrido todos os ns do grafo. Caso o n
inicial seja encontrado durante o percurso, identicado um ciclo no grafo. Este processo
realizado para todos os ns do grafo. Caso seja identicado um ciclo no grafo, o n
que est sendo adicionado ao grafo desconsiderado. Quando o n desconsiderado por
estar gerando um ciclo no grafo, gerado um alerta para informar a situao ao usurio
(administrador), possibilitando que possa ser realizada uma anlise na congurao do
ativo na base de dados de congurao de ativos para identicar alguma provvel falha
no processo.
A validao da TPC realizada em duas etapas. A primeira etapa valida o nmero
de linhas existentes na TPC. O nmero de linhas deve ser igual 2
n
, onde n a quantidade
de ns pais do n atual, visto que a Rede Bayesiana utilizada no presente trabalho utiliza
apenas ns booleanos, isto , que possuem apenas como valor, verdadeiro ou falso. Esta
validao representado pela equao:
rows(x) = 2
n
(6.2)
onde rows uma funo que retorna o nmero de itens de uma TPC e n o nmero
de pais de x.
A segunda etapa valida a distribuio de probabilidade conjunta, que representada
pela equao:

P{} = 1 (6.3)
onde o espao amostral e representa a probabilidade de um evento.
Finalizando as trs etapas, uma Rede Bayesiana est criada e apontando os principais
riscos de TI existentes no ambiente da organizao, favorecendo a identicao de
vulnerabilidades e ameaas crticas para a organizao.
A Rede Bayesiana gerada ser alterada sempre antes que os riscos de TI sejam
calculados. O perodo de tempo em que o risco calculado denido pelo administrador do
sistema. A possibilidade de alterar a Rede Bayesiana sempre que uma alterao no sistema
fosse identicada foi considerada, no entanto, esta possibilidade se mostrou invivel, visto
o tempo que o algoritmo leva para gerar e calcular as TPC.
85
6.5 CLCULO DO RISCO DE TI
Possuindo a Rede Bayesiana que reete o cenrio atual da estrutura de TI da
organizao e conhecendo os ativos que fazem parte desta estrutura, possvel calcular o
potencial risco destes ativos computacionais.
Sendo o risco uma medida da extenso em que uma entidade est ameaada por uma
circunstncia ou evento em potencial e, normalmente, uma funo de: (i) os impactos
negativos que se vericariam se a circunstncia ou evento ocorresse; e (ii) a probabilidade
de ocorrncia (LOCKE e GALLAGHER, 2011), clculo realizado utilizando a frmula
base para se obter o ndice de risco (CICCO, 2005):
R = P x I (6.4)
onde R o risco, P a probabilidade de um ativo vir a no executar sua funo e I
o impacto do ativo computacional para a organizao.
Como o agente ag Risk conhece todos os ativos identicados pelo agente ag
Asset, alm de conhecer todos os ativos que compem este ativo e possuir acesso a
Rede Bayesiana, possvel obter todas as informaes necessrias para calcular os riscos
associados aos ativos.
O impacto utilizado no clculo de risco obtido atravs da pontuao do CVSS, obtida
utilizando as mtricas de ambiente, conforme visto na Seo 2.4.2. As mtricas temporais
foram ignoradas para este clculo, visto que o sistema no possui os dados necessrios
para o clculo.
Para se obter a probabilidade de um ativo vir a no executar sua funo, utilizada a
Rede Bayesiana utilizando como evidncias, todos os incidentes que esto ativos na base
de dados de incidentes. Com estas evidncias, possvel realizar a inferncia P(X|e), que
exemplicada a seguir:
P(WorkStation1|Firefox = True, WindowsXP = True)
Esta inferncia pode ser interpretada da seguinte forma: qual a probabilidade de
um ativo no executar corretamente sua funo dado o no funcionamento dos ativos
utilizados como evidncia.
Desta forma, podemos armar que o risco associado a um ativo denido por:
R(x) = P(x|e)I(x) (6.5)
86
onde R o risco, x o ativo computacional P a probabilidade de um ativo no
desempenhar corretamente sua funo, e so as evidncias encontradas e I o impacto
sobre o negcio da organizao.
Utilizando esta frmula, o agente ag Risk reliza o clculo de risco de todos os ativos
computacionais existentes na organizao e armazena estas informaes em uma base de
dados que possui as informaes consolidadas. Com estas informaes consolidadas, o
agente ag Risk tem a possibilidade de retornar consultas referentes aos riscos dos ativos
de uma forma mais eciente, sem a necessidade de realizar inferncias na Rede Bayesiana
sempre que uma informao for solicitada.
6.6 IMPLEMENTAO
Para avaliar o mtodo proposto, foi desenvolvido um prottipo de Sistema
Multiagente. Este prottipo foi desenvolvido nos seguintes linguagens/frameworks:
Python
SPYSE
Django
SQLite
A linguagem Python
1
foi adotada por atender as seguintes caractersticas:
Simples: Sua sintaxe simples e de fcil compreenso;
Alto Nvel: Manipula automticamente a memria e converte tipos automaticamente;
Portvel: Funciona em um grande nmero de plataformas;
Orientada a Objetos: Alm de suportar o programao procedural (estruturada), tem
suporte a programao orientada a objetos, assim como Java e C++; e
Extensvel: Possibilita que trechos crticos do cdigo sejam implementados em C/C++
e utilizados a partir do cdigo Python.
No intuito deste trabalho pesquisar sobre as caractersticas da linguagem e nem
ao menos fazer apologia, sendo assim, esto sendo descritas apenas as caractersticas que
levaram a optar por esta linguagem.
1
Maiores informaes sobre a linguagem Python pode ser encontradas em http://www.python.org
87
O framework Smart Python Simulation Environment SPYSE foi utilizado por ser
implementado em Python e por seguir uma estrutura e forma de utilizao do framework
JADE (implementado em Java). Sua implementao guiada pela documentao do
JADE. um framework que suporta troca de mensagens no padro FIPA, ontologias,
entre outras caracterstica que podem vir a ser utilizadas em futuros trabalhos relacionados
ao presente trabalho.
O framework Django
2
, apesar de ser um framework destinado ao desenvolvimento de
aplicaes Web, fornece uma camada de acesso a dados que abstrai o banco de dados
relacional, permitindo que o banco de dados seja manipulado atravs de objetos. Por esta
facilidade em acessar o banco de dados, este framework foi utilizado.
Apesar da camada de acesso a dados do Django possuir suporte aos principais banco
de dados existentes atualmente, foi utilizado o SQLite
3
, que um banco de dados de
acesso local simples. O SQLite pode ser utilizado em diversos tipos de ambientes,
incluindo navegadores de internet, computadores convencionais, servidores e inclusive
dispositivos mveis, visto que um banco de dados que necessita de poucos recursos para
seu funcionamento, caracterstica esta, que de interesse do presente trabalho.
A implentao da Rede Bayesiana no utilizou nenhum framework em especial. O
cdigo desenvolvido para a Rede Bayesiana foi baseado no cdigo disponibilizado no
livro de Russel e Norvig (2004), que foi desenvolvido em Python. O cdigo original no
orientado a objetos, portanto, esta foi a primeira modicao realizada. As demais
alteraes foram para adicionar as funcionalidades necessrias para que a rede pudesse
ser gerada automaticamente.
6.7 AVALIAO
Como o presente trabalho aborda um tema atual e com poucos trabalhos relacionados
publicados, a comparao dos resultados obtidos com outros resultados se torna invivel.
Para avaliar a ecincia do sistema desenvolvido, foi elaborada um simulao composta
por treze etapas. Levando em considerao que cenrios complexos geram uma Rede
Bayesiana grande, o que gera um problema de desempenho, a simulao utiliza um cenrio
controlado e resumido.
Sendo assim, a avaliao se limitou a cinco ativos computacionais, utilizando para
teste apenas seus principais ativos, ou seja, os ativos relacionados diretamente funo a
qual o ativo computacional destinado.
2
Maiores informaes sobre o framework Django podem ser obtidas em http://www.djangoproject.com
3
Maiores informaes sobre o banco de dados SQLite podem ser encontrato em http://www.sqlite.org
88
6.7.1 Simulao
Para simular um ambiente onde o sistema poder ser utilizado, foi elaborado um
cenrio controlado e resumido que represente o mais prximo possvel da realidade. Este
cenrio se resume aos principais ativos que compem o ativo computacional. Para isso, foi
montada uma base de dados de congurao de ativos que simula o ambiente fornecido,
porm, deixando alguns ativos reservados para a simulao, atendendo ento o cenrio da
incluso/alterao de ativos na base de dados de congurao de ativos.
Para gerar os dados para a simulao, foi utilizado uma base de dados de nomes CPE,
que tem a funo de dicionrio para consultas de nomes CPE j cadastrados. Esta base
de dados fornecida livremente pelo NVD
4
.
Para simular a identicao de novas vulnerabilidades, a importao das informaes
da base de dados de vulnerabilidades tambm deixou registros reservados para testes.
Como os dados sobre incidentes no foram cedidos, os eventos so todos simulados.
O seguinte roteiro foi elaborado para simular o funcionamento do sistema e avaliar o
mtodo proposto:
1. Realizar carga inicial de dados de vulnerabilidades;
2. Realizar carga inicial da base histrica de incidentes;
3. Adicionar um ativo computacional na base de congurao de ativos;
4. Adicionar um segundo ativo computacional na base de congurao de ativos;
5. Adicionar um terceiro ativo computacional na base de congurao de ativos;
6. Adicionar um quarto ativo computacional na base de congurao de ativos;
7. Adicionar um quinto ativo computacional na base de congurao de ativos;
8. Adicionar uma evidncia direcionada para um ativo utilizado em apenas um ativo
computacional;
9. Adicionar uma evidncia direcionada para um ativo utilizado em mais de um ativo
computacional;
10. Remover software de um ativo computacional na base de dados de congurao de
ativos;
11. Acrescentar software em um ativo computacional;
4
Disponvel em http://static.nvd.nist.gov/feeds/xml/cpe/dictionary/ocial-cpe-dictionary_v2.2.xml
89
12. Atualizar base de vulnerabilidades com os arquivos recentes e modicados; e
13. Alterar um ativo computacional, aumentando o seu impacto perante o negcio da
organizao.
Ao iniciar o sistema, executada a primeira etapa do roteiro. Esta uma etapa
que ir ocorrer apenas um vez, visto que ela destinada a realizar a importao das
vulnerabilidades disponibilizadas como base histrica na NVD. Para a simulao do
sistema foram utilizadas apenas as vulnerabilidade referentes aos anos 2009 e 2010 para
diminuir o tempo de carga dos demais anos. As vulnerabilidades do ano de 2011 so
utilizadas durante o roteiro para simular o surgimento de novas vulnerabilidades.
Na segunda etapa do roteiro, gerada uma base histrica de incidentes de segurana.
Esta base gerada a partir da seleo aleatria de ativos na base de dados de
vulnerabilidades do NVD. A base de incidentes de segurana alterada durante a
simulao.
Da etapa trs sete so adicionados ativos base de dados de congurao de ativos.
A cada etapa realizada vericada a estrutura da Rede Bayesiana gerada e calculado
pelo sistema o risco para os ativos computacionais.
Na etapa trs, adicionado um servidor que recebe o nome de Zeus. Este ativo
computacional composto pelos ativos apresentados na Tabela 6.4.
Tabela 6.4: Ativos que compem o ativo computacional Zeus.
Hardware Identicador
h:dell:poweredge:830 PowerEdge
Sistema Operacional Identicador
o:microsoft:windows_2003_server::sp2:standard
Aplicativos Identicador
a:avg:avg_anti-virus:8.0 AVG 8
a:march-hare:cvsnt:2.5 CVSNT 2.5
a:microsoft:ie:7 IE 7
a:microsoft:sql_server:2005:sp2 SQL 2005
a:microsoft:.net_framework:1.0 .NET FW 1.0
a:microsoft:.net_framework:2.0:sp1 .NET FW 2.0
a:microsoft:.net_framework:3.5 .NET FW 3.5
a:sun:jre:1.6.0:update_1 JRE 1.6
a:sun:jdk:1.6.0:update_10 JDK 1.6
a:cobiam:cobian_backup:8 Cobian 8
90
Na etapa quatro, adicionado um servidor que recebe o nome de Apolo. Este ativo
computacional composto pelos ativos apresentados na Tabela 6.5.
Tabela 6.5: Ativos que compem o ativo computacional Apolo.
Hardware Identicador
h:dell:poweredge:830 PowerEdge
Sistema Operacional Identicador
o:microsoft:windows_2003_server::sp2:standard
Aplicativos Identicador
a:avg:avg_anti-virus:8.0 AVG 8
a:microsoft:ie:7 IE 7
a:microsoft:.net_framework:1.0 .NET FW 1.0
a:microsoft:.net_framework:2.0:sp1 .NET FW 2.0
a:microsoft:.net_framework:3.5 .NET FW 3.5
a:vmware:server:1.0.4 VMWare
Na etapa cinco, adicionada uma estao de trabalho que recebe o nome de W140.
Este ativo computacional composto pelos ativos apresentados na Tabela 6.6.
Tabela 6.6: Ativos que compem o ativo computacional W140.
Hardware Identicador
h:dell:vostro:200 Vostro
Sistema Operacional Identicador
o:microsoft:windows_xp::sp2 WinXP
Aplicativos Identicador
a:avira:antivir Avira
a:openoce:openoce.org :3.1 OO 3.1
a:7-zip:7-zip:9.11 7-Zip 9.11
a:sap:crystal_reports:2008 Crystal 2008
a:foxitsoftware:foxit_reader:3.0 Foxit
a:microsoft:ie:7 IE 7
a:microsoft:.net_framework:1.0 .NET FW 1.0
a:microsoft:.net_framework:2.0:sp1 .NET FW 2.0
a:microsoft:.net_framework:3.5 .NET FW 3.5
a:microsoft:sql_server_express:2005 SQLx 2005
a:tigris:tortoisecvs1.1.1 TortoiseCVS
a:microsoft:visual_basic_sdk:6.3 VB 6.3
91
Na etapa seis, adicionada uma estao de trabalho que recebe o nome de W265.
Este ativo computacional composto pelos ativos apresentados na Tabela 6.7.
Tabela 6.7: Ativos que compem o ativo computacional W265.
Hardware Identicador
h:dell:vostro:200 Vostro
Sistema Operacional Identicador
o:microsoft:windows_vista:sp1 WinVista
Aplicativos Identicador
a:adobe:acrobat_reader:8.0 Acrobat
a:winrar:winrar_archiver WinRAR
a:avg:avg_anti-virus:8.0 AVG 8
a:sap:crystal_reports:2008 Crystal 2008
a:microsoft:.net_framework:1.0 .NET FW 1.0
a:microsoft:.net_framework:2.0:sp1 .NET FW 2.0
a:microsoft:.net_framework:3.5 .NET FW 3.5
a:microsoft:sql_server_express:2005 SQLx 2005
a:tigris:tortoisecvs1.1.1 TortoiseCVS
a:microsoft:visual_basic_sdk:6.3 VB 6.3
a:microsoft:visual_studio:2008 VS 2008
a:microsoft:ie:7 IE 7
a:mozilla:refox:3.6 Firefox 3.6
Na etapa sete, adicionada uma estao de trabalho que recebe o nome de W126.
Este ativo computacional composto pelos ativos apresentados na Tabela 6.8.
Tabela 6.8: Ativos que compem ao ativo computacional W126.
Hardware Identicador
h:dell:vostro:200 Vostro
Sistema Operacional Identicador
o:microsoft:windows_xp::sp2 WinXP
Aplicativos Identicador
a:adobe:acrobat_reader:8.0 Acrobat
a:avira:antivir Avira
a:sap:crystal_reports:2008 Crystal 2008
a:tigris:tortoisecvs1.1.1 TortoiseCVS
a:microsoft:.net_framework:1.0 .NET FW 1.0
92
a:microsoft:.net_framework:2.0:sp1 .NET FW 2.0
a:microsoft:.net_framework:3.5 .NET FW 3.5
a:microsoft:sql_server_express:2005 SQLx 2005
a:microsoft:visual_studio:2008 VS 2008
a:microsoft:visual_basic_sdk:6.3 VB 6.3
a:microsoft:ie:7 IE 7
a:winrar:winrar_archiver winRAR
Na etapa oito, adicionado, base de dados de incidentes, um novo incidente
relacionado ao ativo a:7-zip:7-zip:9.11. Este ativo pertence apenas ao ativo computacional
W140.
Na etapa nove, adicionado, um aplicativo base de dados de incidentes, um segundo
incidente relacionado ao ativo a:tigris:tortoisecvs1.1.1. Este ativo pertence a todas as
estaes de trabalhos existentes no sistema.
Na etapa dez, removido o aplicativo a:microsoft:oce:2007:sp1:: do ativo
computacional W265, validando ento a capacidade de alterar a Rede Bayesiana gerada
e tambm a mudana no risco relacionado ao ativo computacional W265.
Na etapa onze, acrescentado o software a:google:chrome:8.0.552.344 no ativo
computacional w140. Sendo que o aplicativo a:google:chrome:8.0.552.344 possui registros
de vulnerabilidades no NVD.
Na etapa doze, realizada a importao de novas vulnerabilidades e tambm das
alteradas, utilizando para isto o perodo de vulnerabilidades reservado na etapa inicial
para a simulao.
Na etapa treze, o ativo computacional w126 tem seu impacto alterado, aumentando
seu valor perante o negcio da organizao. Com esta ltima etapa, todas as
caractersticas propostas para o presente trabalho foram simuladas.
Os resultados obtidos durante a simulao so apresentados na subseo 6.7.2, assim
como os comentrios relacionados aos resultados.
6.7.2 Anlise dos Resultados
Esta subseo apresenta os dados obtidos na simulao descrita na subseo 6.7.1.
Os resultados obtidos a partir do sistema proposto esto normalizados em valores entre
0 a 1, inclusive, com o intuito de manter a compatibilidade entre os valores utilizados na
inferncia da rede bayesiana e no clculo do CVSS.
93
A Tabela 6.9 apresenta os fatores de risco de cada ativo computacional ao longo da
simulao. Os campos em branco na Tabela 6.9 so referentes a inexistncia do ativo
computacional na etapa da simulao.
Tabela 6.9: Risco obtidos durante a simulao.
Etapa Zeus Apolo w140 w265 w126
1
2
3 0,283144919
4 0,283566426 0,297289929
5 0,283566426 0,297289929 0,235670548
6 0,283566426 0,297289929 0,235670548 0,307948209
7 0,283566426 0,297289929 0,23674143 0,307948209 0,224901298
8 0,283611221 0,297367254 0,266900968 0,307972788 0,225997108
9 0,295356363 0,31302739 0,274954698 0,315634269 0,232222123
10 0,295356363 0,31302739 0,274954698 0,306513963 0,232222123
11 0,295356363 0,31302739 0,257630576 0,306513963 0,231606591
12 0,289427769 0,312866358 0,266537442 0,306513963 0,231981113
13 0,289427769 0,312866358 0,266537442 0,306513963 0,311626667
As probabilidades obtidas atravs de inferncia na Rede Bayesiana, utilizadas para
calcular os fatores de risco apresentados na Tabela 6.9, so apresentadas na Tabela 6.10.
Os campos em branco na Tabela 6.10 so referentes a inexistncia do ativo computacional
na etapa da simulao.
Tabela 6.10: Probabilidades obtidas durante a simulao.
Etapa Zeus Apolo w140 w265 w126
1
2
3 0,300722957
4 0,301170632 0,3381885
5 0,301170632 0,3381885 0,282151536
6 0,301170632 0,3381885 0,282151536 0,334536658
7 0,301170632 0,3381885 0,283433627 0,334536658 0,32359194
8 0,301218208 0,338276463 0,319541491 0,33456336 0,325168612
9 0,313692504 0,356090984 0,329183647 0,342886338 0,334125273
10 0,313692504 0,356090984 0,329183647 0,333799764 0,334125273
94
11 0,313692504 0,356090984 0,308442711 0,333799764 0,333239634
12 0,310486515 0,355907799 0,320707178 0,333799764 0,333778503
13 0,310486515 0,355907799 0,320707178 0,333799764 0,333778503
Outro item que compe o clculo do risco o impacto que o ativo tem sobre o negcio
da organizao. Os impactos utilizados para calcular os fatores de risco apresentados na
Tabela 6.9 so apresentados na Tabela 6.11. Os campos em branco na Tabela 6.11 so
referentes a inexistncia do ativo computacional na etapa da simulao.
Tabela 6.11: Impactos obtidos durante a simulao.
Etapa Zeus Apolo w140 w265 w126
1
2
3 0,941547403
4 0,941547403 0,879065756
5 0,941547403 0,879065756 0,835262325
6 0,941547403 0,879065756 0,835262325 0,920521568
7 0,941547403 0,879065756 0,835262325 0,920521568 0,69501514
8 0,941547403 0,879065756 0,835262325 0,920521568 0,69501514
9 0,941547403 0,879065756 0,835262325 0,920521568 0,69501514
10 0,941547403 0,879065756 0,835262325 0,918256978 0,69501514
11 0,941547403 0,879065756 0,835262325 0,918256978 0,69501514
12 0,932175005 0,879065756 0,83109285 0,918256978 0,69501514
13 0,932175005 0,879065756 0,83109285 0,918256978 0,933633125
As duas primeiras etapas da simulao descrita na subseo 6.7.1 no geram
resultados, visto que so etapas destinadas a inicializar o sistema, que utilizam dados
histricos da organizao.
A evoluo da simulao pode ser melhor visualizada nas Figuras 6.13, 6.14 e 6.15. A
Figura 6.13 apresenta a evoluo dos fatores de risco ao longo da simulao. A Figura 6.14
apresenta a evoluo das probabilidades obtidas atravs de inferncia na Rede Bayesiana
gerada e a Figura 6.15 apresenta as pontuaes de impacto ao negcio.
O primeiro detalhe que deve-se atentar que os resultados obtidos at a etapa sete da
simulao so estveis, ou seja, variam pouco. Essa caracterstica esperada, visto que
at a etapa sete da simulao, apenas so acrescentados novos ativos no sistema. Estas
etapas avaliam a capacidade do sistema em perceber novos ativos no ambiente.
95
A capacidade do sistema identicar novos ativos e modicar a Rede Bayesiana pode ser
percebida a partir dos grcos apresentados nas Figuras 6.13, 6.14 e 6.15. Nestes grcos,
possvel perceber que at a etapa sete, includo um novo ativo computacional. Esta
capacidade tambm pode ser percebida atravs das Figuras 6.8, 6.9, 6.10, 6.11 e 6.12, que
representam a evoluo da Rede Bayesiana at a stima da simulao.
Os grafos apresentados nas Figuras 6.8, 6.9, 6.10, 6.11 e 6.12 referenciam os ativos
utilizando um identicador. Este identicador relacionado aos ativos atravs da coluna
identicador nas Tabelas 6.4, 6.5, 6.6, 6.7 e 6.8.
Figura 6.8: Grafo representando a Rede Bayesiana gerada at a etapa trs da simulao.
A Figura 6.8 apresenta um grafo representando a forma da Rede Bayesiana gerada
aps a execuo da terceira etapa da simulao. Neste grafo possvel perceber a
existncia de um ativo computacional, um ativo de hardware, um ativo de sistema
operacional e nove ativos de aplicao.
Figura 6.9: Grafo representando a Rede Bayesiana gerada at a etapa quatro da simulao.
A Figura 6.9 apresenta um grafo representando a forma da Rede Bayesiana gerada
aps a execuo da quarta etapa da simulao. Neste grafo possvel perceber que o
96
nmero de ativos computacionais aumentou para dois e o nmero de ativos de aplicao
aumentou para onze, no entanto, a quantidade de ativos de hardware e sistema operacional
se manteve igual, visto que os dois ativos computacionais utilizam o mesmo tipo de
hardware e sistema operacional.
Figura 6.10: Grafo representando a Rede Bayesiana gerada at a etapa cinco da simulao.
A Figura 6.10 apresenta um grafo representando a forma da Rede Bayesiana gerada
aps a execuo da quinta etapa da simulao. Neste grafo possvel perceber o
surgimento de mais um ativo computacional, um ativo de hardware e um de sistema
operacional e que a quantidade de ativos de aplicao subiu para dezenove.
A Figura 6.11 apresenta um grafo representando a forma da Rede Bayesiana gerada
aps a execuo da sexta etapa da simulao. Neste grafo possvel perceber o surgimento
de mais um ativo computacional, no entanto, a quantidade de ativos de hardware, de
aplicao e sistema operacional se mantiveram.
A Figura 6.12 apresenta um grafo representando a forma da Rede Bayesiana gerada
aps a execuo da stima etapa da simulao. Neste grafo possvel perceber o
surgimento de mais um ativo computacional e que a quantidade de ativos de aplicao
subiu para vinte e quatro, no entanto, a quantidade de ativos de hardware se manteve.
Com o cadastro de um incidente envolvendo o aplicativo a:7-zip:7-zip:9.11, na
etapa oito da simulao, pode-se perceber no grco que apresenta as probabilidades
obtidas, apresentado na Figura 6.14, que a probabilidade do ativo computacional w140
aumentou, visto que este ativo computacional utiliza o aplicativo a:7-zip:7-zip:9.11, que
possui um relato de incidente ativo no sistema. O incidente simulado na etapa oito
afeta indiretamente o ativo computacional w126. Isto ocorre pelo fato dos dois ativos
97
Figura 6.11: Grafo representando a Rede Bayesiana gerada at a etapa seis da simulao.
computacionais utilizarem a mesma verso de sistema operacional.
A mudana no risco dos ativos computacionais w140 e w126 pode ser percebida
visualmente no grco apresentado na Figura 6.13. No entanto, esta etapa afeta
praticamente todos os ativos computacionais existentes no sistema, como pode ser
percebido na Tabela 6.9 comparando os fatores de risco da etapa sete e oito. O novo
incidente afeta todos os ativos computacionais por que essa informao, alm de ser
utilizada como evidncia no momento da inferncia na Rede Bayesiana, utilizada na
estatstica que determina o peso entre os ns da Rede Bayesiana.
A execuo da etapa nove, acrescenta mais um incidente ao sistema, desta vez referente
ao aplicativo a:microsoft:ie:7, que utilizado por todos os ativos computacionais existentes
no sistema. Nesta etapa pode-se perceber no grco apresentado na Figura 6.13 que o
risco de todos os ativos computacionais aumenta. Mesmo o aplicativo sendo utilizado em
todos os ativos computacionais, o risco no aumenta proporcionalmente para todos os
ativos computacionais. Isso ocorre por dois motivos principais: (i) A inferncia na Rede
Bayesiana considera todos os relacionamentos existentes, sendo assim, a quantidade de
aplicativos instalados em um ativo computacional afeta o resultado a inferncia; e (ii) O
clculo do risco utiliza uma pontuao de impacto que pondera os requisitos de impacto
do ativo computacional.
Com a remoo do aplicativo a:microsoft:oce:2007:sp1 do ativo computacional
w265, na etapa dez, pode-se perceber que o risco referente ao ativo computacional
98
Figura 6.12: Grafo representando a Rede Bayesiana gerada at a etapa sete da simulao.
diminuiu, como pode-se perceber no grco apresentado na Figura 6.13.
A etapa onze realiza a troca do aplicativo a:microsoft:ie:7 pelo
a:google:chrome:8.0.552.344 no ativo computacional w140, o que reete diretamente
no seu fator de risco. A queda no fator de risco do ativo computacional est ligada
diretamente ao fato do aplicativo no possuir registro de vulnerabilidades na base de
dados.
Na etapa doze, a situao do aplicativo a:google:chrome:8.0.552.344 muda, visto que
na etapa doze realizada a importao dos registros do ano de 2011 da base de dados
do NVD e esta possui registro de vulnerabilidade para este aplicativo. O efeito disto
o aumento do fator de risco relacionado ao ativo w140. Um fato que merece ateno
nesta etapa a reduo do fator de risco referente ao ativo computacional Zeus. Isso
ocorre porque a importao da base de vulnerabilidades da NVD traz novos registros
e tambm as modicaes em registros antigos. O que pode ter ocorrido neste caso,
que alguma vulnerabilidade estava relacionada com o sistema operacional que o ativo
computacional utiliza e depois constatou-se que a vulnerabilidade no afetava este sistema
operacional, atualizando ento o registro. Como as informaes sobre vulnerabilidades
so amplamente utilizadas no mtodo proposto, a atualizao pode ser percebida inclusive
no grco apresentado na Figura 6.15, que apresenta o impacto do ativo computacional
no negcio da organizao. Neste grco, pode-se perceber uma leve queda no impacto
no negcio do ativo computacional Zeus. Esta situao tambm importante para avaliar
99
Figura 6.13: Evoluo do risco durante a simulao
Figura 6.14: Evoluo do impacto durante a simulao
a capacidade do sistema de perceber estas alteraes no NVD.
A etapa treze, que simula a troca de funo do ativo computacional w126 para uma
funo que crtica para o negcio da organizao, o ltimo caso simulado na avaliao
do sistema. Esta alterao reete diretamente no impacto no ativo computacional perante
o negcio, que pode ser percebido facilmente no grco apresentado na Figura 6.15. No
momento que a etapa treze executada, o impacto do ativo computacional w126 e igual
ao impacto de Zeus, que at o momento, era o ativo computacional mais importante.
Com o aumento do impacto relacionado ao ativo computacional w126, o fator de risco
atribudo a ele aumentou consideravelmente, chegando bem prximo do risco referente ao
ativo computacional Apolo, que at a etapa doze era ativo com maior risco na organizao.
100
Figura 6.15: Evoluo do risco durante a simulao
101
7 CONCLUSO
Ao longo do trabalho, possvel perceber o valor que a informao tem e o motivo
pelo qual esta considerada o ativo mais importante das organizaes. As ameaas que
envolvem a informao tambm foram apresentadas, assim como os mtodos utilizados
para diminuir os riscos relacionados aos ativos eletrnicos que compem os processos de
negcio da organizao, momento este que torna clara a importncia da Gesto de Risco
para a Segurana da Informao, sendo esta para um Sistema de Gesto de Segurana da
Informao ou para a Governana de Segurana da Informao.
Considerando a forma com que os ativos se relacionam para formar um processo de
negcio, a possibilidade de utilizao de Redes Bayesianas para a estimativa de risco foi
identicada. Em um processo de negcio, os ativos possuem uma relao causal, em que
um ativo tem um impacto direto sobre o bom funcionamento de outros ativos.
Um trabalho abordando a gerao automtica de Redes Bayesianas para estimar riscos
de segurana foi publicado por Fenz e Hudec (2009). No entanto, este trabalho aborda
riscos de processos/controles de segurana de uma forma genrica, como por exemplo,
"sem auditorias de segurana", que apenas indica que no foram realizadas auditorias de
segurana na organizao e no o motivo especco que gerou a ameaa. A idia de gerar
uma Rede Bayesiana automaticamente prosposta por Fenz e Hudec (2009) foi agregada
ao trabalho atual para melhor atender o objetivo proposto, que auxiliar na atividade de
anlise de risco.
Um modelo para gerao automtica da Rede Bayesiana baseado em Sistemas
Multiagentes foi formulado e um prottipo foi desenvolvimento para que o modelo pudesse
ser avaliado.
Apesar no ser possvel comparar os resultados obtidos com o modelo proposto com
os modelos dos trabalhos relacionados, visto que o presente trabalho considera fatores
que os trabalhos relacionados no consideram, como por exemplo, a relao causal entre
os ativos da organizao, foi possvel constatar que os resultados obtidos reetem as
situaes que requerem ateno no dia-a-dia de prossionais de Segurana da Informao
e que conseguem identicar alteraes no cenrio de segurana a partir de toda a relao
existente entre ativos, vulnerabilidades e incidentes. A qualidade dos dados obtidos pode
ser avaliada com a utilizao do sistema em um ambiente real, no entanto, o prottipo
requer otimizaes de desempenho para que isto seja possvel.
102
7.1 TRABALHOS FUTUROS
Durante o perodo de pesquisa e desenvolvimento do prottipo para avaliar o modelo
proposto, alguns temas foram identicados como trabalhos futuros. Estes temas so
apresentados na ordem cronolgica que surgiram no presente trabalho.
O primeiro tema, que surgiu no incio da pesquisa e no foi incorporado no trabalho
por limitao de tempo a utilizao de informaes referentes aos controles de segurana
no clculo do risco. Mesmo existindo vulnerabilidades em aplicativos em um ativo
computacional, alguns controles/medidas de segurana podem e so utilizados para
diminuir o risco sobre estes ativos. Sendo assim, para obter-se um resultado mais
preciso, considerar estes controles necessrio. Para isso, pode-se utilizar como base
os trabalhos de Ekelhart et al. (2009) e Fenz e Hudec (2009), que foram citados nos
trabalhos relacionados.
Uma das limitaes do prottipo desenvolvido com relao ao nmero de ns gerados
na Rede Bayesiana, visto que o algoritmo de inferncia utilizado tem complexidade
NP-Difcil, o que torna sua execuo lenta. Uma pesquisa referente a este problema pode
possibilitar a utilizao do prottipo em ambientes mais complexos e que leva a resultados
mais reais. A utilizao de megans, existente em Russel e Norvig (2004), chegou a
ser considerada no presente trabalho, no entanto, o tempo necessrio para pesquisa e
desenvolvimento no era vivel para o presente trabalho.
A integrao do prottipo desenvolvido com ferramentas de inventario j existentes
contribui com a eliminao do processo de atualizao da base de dados de congurao
de ativos, visto que este processo seria automtico, como no sistema AURUM.
Visto que o presente trabalho possui uma limitao quanto a sua avaliao, a utilizao
do mtodo proposto por Fenz e Ekelhart (2010) para vericar e avaliar a gesto de risco
em segurana da informao o trabalho futuro mais prximo. Este mtodo no foi
utilizado na avaliao do trabalho porque foi publicado no ano de 2010 e disponibilizado
apenas em fevereiro de 2011.
103
BIBLIOGRAFIA
ABNT. Tecnologia da informao - Tcnicas de segurana - Sistema de gesto de
segurana da informao - Requisitos. http://www.abnt.org.br, 2005. Tcnicas de
segurana - Cdigo de prtica para a gesto da segurana da informao.
ABNT. Gesto de risco - Vocabulrio - Recomendaes para uso em normas.
http://www.abnt.org.br, 2005b.
ABNT. ABNT NBR ISO/IEC 27001. http://www.abnt.org.br, 2006.
ABNT. Tecnologia da informao - Tcnicas de segurana - Gesto de risco de
segurana da informao. http://www.abnt.org.br, 2008.
ALVES, G. A. de O.; CAMARGO, L. F. R. da C.; ALMEIDA, A. C. R. D. de.
Enterprise security governance. 2006.
BERGENTI, F.; GLEIZES, M.-P.; ZAMBONELLI, F. Methodologies and Software
Engeneering For Agent Systems. : Frederico Bergenti and Marie-Pierre Gleizes and
Franco Zambonelli, 2004.
BERNARDES, M. C.; MOREIRA, E. dos S. Um modelo para incluso da governaa
da segurana da informao no escopo da governana organizacional. Instituto de
Cincias Matemticas e de Computao - ICMC, 2006.
BRURE, A. J.; SILVA, W. M. da; SANTOS, J. F. dos. Aspectos da governana
corporativa de empresas listadas na bovespa: Um estudo exploratrio sobre a
composio e perl dos conselhos de administrao. UNISINOS, 2007.
BUTTNER, A.; ZIRING, N. Common Plataform Enumeration (CPE) - Specication.
2.2. ed. Maro 2009.
CICCO, F. D. Gesto de risco: Diretrizes para a implementao da AS/NZS
4360:2004. : Risk Tecnologia Editora, 2005. (Risk Management).
DANTU, R.; KOLAN, P. Risk management using behavior based bayesian networks.
ISI (Springer-Verlag Berlin Heidelberg), p. 115126, 2005.
DANTU, R.; KOLAN, P.; AKL, R.; LOPER, K. Classication of attributes and
behavior on risk management using bayesian networks. IEEE Xplorer, 2007.
DARWICHE, A. Modeling and Reasoning with Bayesian Networks. : Cambridge
University Press, 2009.
104
EKELHART, A.; NEUBAUER, T.; FENZ, S. Automated risk and utility management.
In: Proceedings of the 2009 Sixth International Conference on Information Technology:
New Generations. Washington, DC, USA: IEEE Computer Society, 2009. p. 393398.
ISBN 978-0-7695-3596-8.
FENZ, A. M. T. S.; HUDEC, M. Ontology-based generation of bayesian network.
International Conference on Complex, Intelligent and Software Intensive System
(IEEE Computer Society), 2009.
FENZ, S.; EKELHART, A. Verication, validation, and evaluation in information
security risk management. IEEE Security and Privacy, IEEE Computer Society, Los
Alamitos, CA, USA, v. 99, n. PrePrints, 2010. ISSN 1540-7993.
FENZ, S.; NEUBAUER, T. How to determine threat probabilities using ontologies
and bayesian networks. CSIIRW09 ( ACM), April 2009.
FERBER, J.; GASSER, L. Intelligence articiele distribue. The 11th Conference on
Expert Systems and their Applications (Avignon91), FR, 1991.
ISG, I. S. G. Information Security Governance: A Call To Action. 2004.
ITGI. Information Security Governance: Guidance for Boards of Directors and
Executive Management. 2nd edition. ed. 3701 Algonquin Road, Suite 1010 Rolling
Meadows, IL 60008 USA: Printed in the United States of America, 2006. ISBN
1-933284-29-3. Disponvel em: <www.itgi.org>.
JENSEN, F. V.; NIELSEN, T. D. Baysian Networks an Decision Graphs. second. :
Springer Science+Business Media, LLC, 2007. (Information Science e Statistic).
LEE, E.; PARK, Y.; SHIN, J. G. Large engineering projetc risk management using a
bayesian belief network. Expert System with Applications, Elsevier Ltd, 2008.
LINK, W. a.; BARKER, R. J. Bayesian Inference with Ecologial Applications. First. :
Elsevier Ltd, 2010.
LOCKE, G.; GALLAGHER, P. D. Managing Information Security Risk: Organization,
Mission, and Information System View. 800-39. ed. March 2011.
LUCAS, P. J.; GAAG, L. C. van der; ABU-HANNA, A. Bayesian networks in
biomedicine and health-care. Articial Intelligence in Medicine (Elsevier), 2004.
MANSUR, R. Governana de TI: metodologia, framework e melhores prticas. :
Brasport, 2007. ISBN 978-85-7452-322-4.
105
MELL, P.; SCARFONE, K.; ROMANOSKY, S. A Complete Guide to the Common
Vulnerability Scoring System Version 2.0. 2007.
PADGHAM, L.; WINIKOFF, M. The prometheus metodology. April 2004.
PEARL, J. Plausible reasoning: From numerical probabilities to qualitative beliefs.
In: The 2nd Pacic Rim International Conference on Articial Intelligence (PRICAI
92). 1992.
PEARL, J. Probabilistic reasoning in intelligent systems : networks of plausible
inference. : Morgan Kaufmann, 1997. Paperback. ISBN 1558604790.
REZENDE, S. O. Sistemas Inteligentes: Fundamentos e Aplicaes. : Solange Oliveira
Rezende, 2005.
RUSSEL, S.; NORVIG, P. Inteligncia Articial: traduo da segunda edio / Stuart
Russel, Peter Norvig. : Stuart Jonathan Russel, 2004.
SMOLA, M. Gesto da segurana da informao: viso executiva da segurana
da informaao : aplicada ao Security Ocer / Marcos Smola e Mdulo Security
Solutions S.A. : Campus, 2003.
SOLMS, B. von. The Relationship between Corporate Governance, IT Governance
and Information Security Governance. 2007.
SOLMS, S. von; SOLMS, R. von. Information Security Governance. : Springer
Science+Business Media, LLC, 2009.
VEIGA, L. R. da. A controladoria como um mecanismo interno de Governana
Corporativa: Um estudo envolvendo empresas de pases relacionados aos modelas de
Governana Corporativa anglo-saxo, alemo e latino-europeu. 2006.
WEISS, G. Multiagent System: A Modern Approachn to Distribuct Articial
Intelligence. : Gerhard Weiss, 1999.
WOOLDRIDGE, M. J. An Introduction to Multiagent System. : Michael J.
Wooldridge, 2001.