Modelo para definição de criticidade em eventos de ...Modelo para de nição de criticidade em...

Manuel Alexandre Pinho Rocha

Modelo para definição de criticidade emeventos de segurança em redes decomputadores.

Man

uel A

lexan

dre

Pinh

o Ro

cha

dezembro de 2013UMin

ho |

201

3M

odel

o pa

ra d

efin

ição

de

criti

cida

de e

mev

ento

s de

seg

uran

ça e

m r

edes

de

com

puta

dore

s.

Universidade do MinhoEscola de Engenharia

deembro de 2013

Tese de MestradoCiclo de Estudos Integrados Conducentes aoGrau de Mestre em Engenharia de Comunicações

Trabalho efetuado sob a orientação doProfessor Doutor Henrique Manuel Dinis Santos

Manuel Alexandre Pinho Rocha

Modelo para definição de criticidade emeventos de segurança em redes decomputadores.

Universidade do MinhoEscola de Engenharia

Modelo para de�nição de criticidade em

eventos de segurança de redes de

computadores

Manuel Rocha

14 de Dezembro de 2013

Agradecimentos

A realização deste trabalho só foi possível devido à intervenção, directaou indirecta, de algumas pessoas, a quem gostaria de aqui mencionar eagradecer:

Ao meu orientador, professor Henrique Santos, pela disponibilidade e peloentusiasmo transmitido para que este trabalho chegá-se a bom porto.

Aos meus pais e à minha irmã por todo o apoio, carinho e paciência aolongo de toda a minha vida e por me ajudarem a tornar na pessoa que souhoje.

Aos meus amigos César Oliveira, Hélder Ribeiro, Hugo Leite, João Brito,João Pinheiro, Luís Nascimento, Mário Dias, Ricardo Maciel, Rui Rodrigues,Sérgio Oliveira, Tiago Pimenta, entre outros pela amizade e por todos os bonsmomentos.

Por �m gostaria de agradecer à Sara por todo o apoio e carinho, massobretudo por todo o amor que me faz sentir completo.

iii

Resumo

A invasão de redes de computador é hoje um dos maiores problemas nasvárias organizações que zelam pela segurança da sua informação, bem comopela operacionalidade dos seus sistemas. As várias ferramentas disponíveisque visam colmatar e atenuar este problema, nem sempre são su�cientes ounão traduzem de forma clara a informação relativa às várias invasões a queuma rede ou um sistema está exposto.

As ferramentas existentes revelam um dé�ce em relação à informação doseventos de segurança. A informação que derivada dos respectivos eventosé pouco especi�ca e pouco perceptiva em relação ao impacto dos mesmos,criando uma barreira muito grande na gestão e administração de sistemas eredes de computadores ao nível da detecção de intrusões.

Modelo para de�nição de criticidade em eventos de segurança de redes decomputadores é o tema em que se enquadra este projecto, que propõe ummétodo de classi�cação de eventos de segurança. Neste projecto pretende-secriar um método capaz de classi�car eventos de segurança, uma classi�caçãocom base na re�nação de informação de contexto, de forma a obter acriticidade e perigosidade de eventos de segurança.

PALAVRAS-CHAVE: Detecção de intrusões, Segurança da informação,Segurança em redes de computadores, gestão de eventos de segurança

v

Abstract

Intrusions in computer networks are a major problem for the organizationsthat care about the security of the information and the operability of theirsystems. Concerning the innumerous threats that a network or a systemcan be exposed, several tools are available on the market to address and tomitigate these issues.

However, those tools either aren't su�cient or aren't capable to translatethe information on a clear way because of the de�cit for generatingsu�cient information when security events are triggered. Usually, theinformation retrieved from these events is not very speci�c and is di�cultfor security analysts to comprehend which can be a major obstacle forthe management and administration of computer networks, regarding thedetection of intrusions.

The management of security events on information systems is under themain objective of this dissertation and a model to classify these eventsis proposed, implemented and tested. The classi�cation is based on there�nement of context information in order to obtain the criticism and thelevel of dangerousness on security events.

KEY WORDS: Intrusion detection, Information Security, Computernetwork security, Security events management.

vii

Lista de acronimos

AIDS Anomaly Intrusion Detection System

BGP Exterior Gateway Protocol

CAPEC Common Attack Pattern Enumeration and Classi�cation

DNS Domain Name System

DoS Denial of Service

FTP File Transfer Protocol

HIDS Host Intrusion Detection System

HTTP Hypertext Transfer Protocol

ICMP Internet Control Message Protocol

IDS Intrusion Detection System

IP Internet Protocol

NIDS Network Intrusion Detection System

OSSIM Open Source Security Information Management

OSPF Open Shortest Path First

RIP Routing Information Protocol

SEM Security Event Management

SIDS Signature Intrusion Detection System

ix

SIEM Security Information and Event Management

SIM Security Information Management

SMTP Simple Mail Transfer Protocol

SNMP Simple Network Management Protocol

TCP Transmission Control Protocol

TCP/IP Transmission Control Protocol/Internet Protocol

UDP User Datagram Protocol

XML eXtensible Markup Language

Conteúdo

Conteúdo xi

Lista de Figuras xv

Lista de Tabelas xvii

1 Introdução 1

1.1 Enquadramento e motivação . . . . . . . . . . . . . . . . . . . 11.2 Objectivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 Métodos de investigação . . . . . . . . . . . . . . . . . . . . . 41.4 Estrutura do documento . . . . . . . . . . . . . . . . . . . . . 7

2 Fundamentos teóricos de segurança de redes de

computadores 9

2.1 Fundamentos das redes de comunicações IP . . . . . . . . . . 92.2 Tráfego TCP/IP e as suas vulnerabilidades . . . . . . . . . . . 112.3 Segurança em Redes de Computadores . . . . . . . . . . . . . 13

2.3.1 Detecção de intrusões . . . . . . . . . . . . . . . . . . . 142.3.1.1 Registo de eventos de segurança . . . . . . . . 17

2.3.2 Modelação de ataques . . . . . . . . . . . . . . . . . . 182.3.2.1 Attack trees . . . . . . . . . . . . . . . . . . . 192.3.2.2 Attack graphs . . . . . . . . . . . . . . . . . . 202.3.2.3 Common Attack Pattern Enumeration and

Classi�cation . . . . . . . . . . . . . . . . . . 232.3.3 Modelação de vulnerabilidades . . . . . . . . . . . . . . 252.3.4 Security Information and Event Management . . . . . 25

2.4 Ferramentas/Frameworks . . . . . . . . . . . . . . . . . . . . . 272.4.1 Snort . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

xi

2.4.2 Ossec . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.4.3 Open Source Security Information Management . . . . 312.4.4 Bro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3 Especi�cação e implementação do sistema 35

3.1 Requisitos do sistema . . . . . . . . . . . . . . . . . . . . . . . 353.1.1 Cenários e contextos . . . . . . . . . . . . . . . . . . . 363.1.2 Requisitos funcionais . . . . . . . . . . . . . . . . . . . 363.1.3 Requisitos não funcionais . . . . . . . . . . . . . . . . . 37

3.2 Modelo de classi�cação e valorização de eventos . . . . . . . . 383.2.1 Vulnerabilidades . . . . . . . . . . . . . . . . . . . . . 38

3.2.1.1 Associação de vulnerabilidades . . . . . . . . 393.2.2 Ataques . . . . . . . . . . . . . . . . . . . . . . . . . . 403.2.3 Criticidade . . . . . . . . . . . . . . . . . . . . . . . . 40

3.2.3.1 Perigosidade . . . . . . . . . . . . . . . . . . 403.2.3.2 Tipos de ataque . . . . . . . . . . . . . . . . 423.2.3.3 Reputaçãp IP . . . . . . . . . . . . . . . . . . 43

3.3 Arquitectura e implementação do sistema . . . . . . . . . . . . 433.3.1 Arquitectura do sistema . . . . . . . . . . . . . . . . . 44

3.3.1.1 Módulo recolha de eventos . . . . . . . . . . . 443.3.1.2 Módulo reputação IP . . . . . . . . . . . . . . 443.3.1.3 Módulo vulnerabilidades . . . . . . . . . . . . 453.3.1.4 Módulo ataques . . . . . . . . . . . . . . . . . 453.3.1.5 Módulo valorização e classi�cação . . . . . . . 45

3.3.2 Implementação do sistema . . . . . . . . . . . . . . . . 453.3.2.1 Classes da aplicação . . . . . . . . . . . . . . 463.3.2.2 Algoritmos do modelo desenvolvido . . . . . . 47

4 Testes e avaliações 53

4.1 Ambiente de teste . . . . . . . . . . . . . . . . . . . . . . . . . 534.2 Testes e Resultados . . . . . . . . . . . . . . . . . . . . . . . . 55

4.2.1 Tipos de ataques . . . . . . . . . . . . . . . . . . . . . 564.2.2 Resultados obtidos . . . . . . . . . . . . . . . . . . . . 58

4.2.2.1 Teste 1 - Resultados obtidos . . . . . . . . . . 584.2.2.2 Teste 2 - Resultados obtidos . . . . . . . . . . 614.2.2.3 Teste 3 - Resultados obtidos . . . . . . . . . . 62

5 Conclusão e trabalho futuro 65

5.1 Conclusões do projecto . . . . . . . . . . . . . . . . . . . . . . 655.2 Análise critica . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.3 Trabalho futuro . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Bibliogra�a 69

Apêndice A Classes da aplicação 75

Apêndice B Imagens da aplicação 79

Apêndice C Tabelas de resultados 83

Apêndice D Tabelas de resultados 93

Apêndice E Tabelas de resultados 101

Lista de Figuras

1.1 Vulnerabilidades catalogadas . . . . . . . . . . . . . . . . . . . 21.2 Ataques mais frequentes . . . . . . . . . . . . . . . . . . . . . 31.3 Metodologia de investigação Design Science . . . . . . . . . . 6

2.1 Pilha protocolar TCP/IP . . . . . . . . . . . . . . . . . . . . . 112.2 Mapa da Internet . . . . . . . . . . . . . . . . . . . . . . . . . 122.3 Etapas de um ataque . . . . . . . . . . . . . . . . . . . . . . . 182.4 Exemplo de Attack Tree . . . . . . . . . . . . . . . . . . . . . 202.5 Exemplo de um Attack Graph: Host-based Network Attack Graph 232.6 Arquitectura conceptual dos SIEM . . . . . . . . . . . . . . . 262.7 Arquitectura genérica dos SIEM . . . . . . . . . . . . . . . . . 282.8 Arquitectura do Snort . . . . . . . . . . . . . . . . . . . . . . 292.9 Arquitectura do Ossec . . . . . . . . . . . . . . . . . . . . . . 302.10 Arquitectura do OSSIM . . . . . . . . . . . . . . . . . . . . . 322.11 Arquitectura do Bro . . . . . . . . . . . . . . . . . . . . . . . 33

3.1 Arquitectura do sistema implementado . . . . . . . . . . . . . 443.2 Diagrama de classes . . . . . . . . . . . . . . . . . . . . . . . . 46

A.1 Classe DataBase . . . . . . . . . . . . . . . . . . . . . . . . . 75A.2 Classe XmlParserCVE . . . . . . . . . . . . . . . . . . . . . . 76A.3 Classe XmlParserCapec . . . . . . . . . . . . . . . . . . . . . . 77A.4 Classe XmlParserNessus . . . . . . . . . . . . . . . . . . . . . 78A.5 Classe ReputationIP . . . . . . . . . . . . . . . . . . . . . . . 78A.6 Classe GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

B.1 Interface grá�ca - preenchimento dos parâmetros relativos aostipos de ataque(50%) . . . . . . . . . . . . . . . . . . . . . . . 79

xv



B.4 Interface grá�ca da ferramenta Armitage . . . . . . . . . . . . 81

Lista de Tabelas

1.1 Número de documentos relativos ao survey bibliográ�co . . . . 51.2 Elementos bibliográ�cos mais relevantes . . . . . . . . . . . . 6

2.1 Classi�cação dos IDS . . . . . . . . . . . . . . . . . . . . . . . 17

4.1 Serviços instalados nos diferentes hosts . . . . . . . . . . . . . 554.2 Testes e resultados - scanning . . . . . . . . . . . . . . . . . . 59

C.1 Ataques realizados em cada host . . . . . . . . . . . . . . . . . 84C.2 Testes e resultados - Windows XP Sp2 . . . . . . . . . . . . . 85C.3 Testes e resultados - Windows XP Sp2 . . . . . . . . . . . . . 85C.4 Testes e resultados - Windows XP Sp2 . . . . . . . . . . . . . 86C.5 Testes e resultados - Windows XP Sp2 . . . . . . . . . . . . . 86C.6 Testes e resultados - Windows XP Sp2 . . . . . . . . . . . . . 86C.7 Testes e resultados - Windows XP Sp2 . . . . . . . . . . . . . 87C.8 Testes e resultados - Windows Server 2008 . . . . . . . . . . . 87C.9 Testes e resultados - Windows Server 2008 . . . . . . . . . . . 87C.10 Testes e resultados - Windows Server 2008 . . . . . . . . . . . 88C.11 Testes e resultados - Windows Server 2008 . . . . . . . . . . . 88C.12 Testes e resultados - Windows Server 2008 . . . . . . . . . . . 88C.13 Testes e resultados - Ubuntu 13.04 . . . . . . . . . . . . . . . . 89C.14 Testes e resultados - Ubuntu 13.04 . . . . . . . . . . . . . . . . 89C.15 Testes e resultados - Ubuntu 13.04 . . . . . . . . . . . . . . . . 89C.16 Testes e resultados - Ubuntu 13.04 . . . . . . . . . . . . . . . . 90C.17 Testes e resultados - Ubuntu 13.04 . . . . . . . . . . . . . . . . 90C.18 Testes e resultados - CentOS 6 . . . . . . . . . . . . . . . . . 90C.19 Testes e resultados - CentOS 6 . . . . . . . . . . . . . . . . . 91

D.1 Testes e resultados - scanning . . . . . . . . . . . . . . . . . . 94

xvii

D.2 Testes e resultados - Windows XP Sp2 . . . . . . . . . . . . . 94D.3 Testes e resultados - Windows XP Sp2 . . . . . . . . . . . . . 95D.4 Testes e resultados - Windows XP Sp2 . . . . . . . . . . . . . 95D.5 Testes e resultados - Windows XP Sp2 . . . . . . . . . . . . . 96D.6 Testes e resultados - Windows XP Sp2 . . . . . . . . . . . . . 96D.7 Testes e resultados - Windows XP Sp2 . . . . . . . . . . . . . 96D.8 Testes e resultados - Windows Server 2008 . . . . . . . . . . . 96D.9 Testes e resultados - Windows Server 2008 . . . . . . . . . . . 97D.10 Testes e resultados - Windows Server 2008 . . . . . . . . . . . 97D.11 Testes e resultados - Windows Server 2008 . . . . . . . . . . . 98D.12 Testes e resultados - Windows Server 2008 . . . . . . . . . . . 98D.13 Testes e resultados - Ubuntu 13.04 . . . . . . . . . . . . . . . . 98D.14 Testes e resultados - Ubuntu 13.04 . . . . . . . . . . . . . . . . 98D.15 Testes e resultados - Ubuntu 13.04 . . . . . . . . . . . . . . . . 98D.16 Testes e resultados - Ubuntu 13.04 . . . . . . . . . . . . . . . . 99D.17 Testes e resultados - Ubuntu 13.04 . . . . . . . . . . . . . . . . 99D.18 Testes e resultados - CentOS 6 . . . . . . . . . . . . . . . . . 99D.19 Testes e resultados - CentOS 6 . . . . . . . . . . . . . . . . . 100

E.1 Testes e resultados - scanning . . . . . . . . . . . . . . . . . . 102E.2 Testes e resultados - Windows XP Sp2 . . . . . . . . . . . . . 102E.3 Testes e resultados - Windows XP Sp2 . . . . . . . . . . . . . 103E.4 Testes e resultados - Windows XP Sp2 . . . . . . . . . . . . . 103E.5 Testes e resultados - Windows XP Sp2 . . . . . . . . . . . . . 104E.6 Testes e resultados - Windows XP Sp2 . . . . . . . . . . . . . 104E.7 Testes e resultados - Windows XP Sp2 . . . . . . . . . . . . . 104E.8 Testes e resultados - Windows Server 2008 . . . . . . . . . . . 104E.9 Testes e resultados - Windows Server 2008 . . . . . . . . . . . 105E.10 Testes e resultados - Windows Server 2008 . . . . . . . . . . . 105E.11 Testes e resultados - Windows Server 2008 . . . . . . . . . . . 106E.12 Testes e resultados - Windows Server 2008 . . . . . . . . . . . 106E.13 Testes e resultados - Ubuntu 13.04 . . . . . . . . . . . . . . . . 106E.14 Testes e resultados - Ubuntu 13.04 . . . . . . . . . . . . . . . . 106E.15 Testes e resultados - Ubuntu 13.04 . . . . . . . . . . . . . . . . 106E.16 Testes e resultados - Ubuntu 13.04 . . . . . . . . . . . . . . . . 107E.17 Testes e resultados - Ubuntu 13.04 . . . . . . . . . . . . . . . . 107E.18 Testes e resultados - CentOS 6 . . . . . . . . . . . . . . . . . 107E.19 Testes e resultados - CentOS 6 . . . . . . . . . . . . . . . . . 108

Capı́tulo 1Introdução

1.1 Enquadramento e motivação

Todos os dias são usadas novas técnicas de invasão cada vez mais robustase e�cazes, que exploram novas vulnerabilidades dos diversos sistemascomputacionais, estando estes constantemente sujeitos a enumeras ameaçasque podem dar origem a consequências de diversos tipos. A motivação dequem invade é originada por diversos factores: o simples facto de conseguiralgo potencialmente inacessível e inatingível, a obtenção de informaçãorestrita e importante, ou até mesmo a fama, são alguns exemplos do quemuitas vezes origina uma invasão.

Na �gura 1.1 é possível veri�car que o número de vulnerabilidades nossistemas computacionais aumentou exponencialmente na última década,mantendo-se igualmente distribuído nos últimos anos. Este aumento épreocupante pois o número de ameaças também aumenta, tendo comoconsequência o crescimento do número de malware e ataques cibernéticos.

Segundo o estudo de Richardson (2010/2011), em que participaram 285organizações, 41.1% dos participantes relatam ter sido vitimas de algum tipode incidente informático. No mesmo estudo foi perguntado quais os tipos deataques foram presenciados pelos participantes nas suas organizações, sendopossível veri�car na �gura 1.2 que os incidentes veri�cados são de diferentestipos e em número considerável.

1Fonte: http://www.cert.org/stats/ e http://www.symantec.com/es/es/threatreport/,visitados em Junho de 2013

2Imagem retirada de Richardson (2010/2011)

1

Modelo para de�nição de criticidade em eventos de segurança de redes de

computadores

Figura 1.1: Vulnerabilidades catalogadas.1

Na tentativa de colmatar este problema existem vários tipos de ferramentas,com características diferentes, que apesar de tudo têm as suas limitações. Asferramentas normalmente utilizadas neste tipo de problema geram eventosquando detectado algum comportamento classi�cado como anormal, deforma a alertar o sucedido. Contudo o número de eventos gerados énormalmente elevado, tornando a tarefa dos gestores e/ou administradoresde rede demorada. Para além disso, o facto dos ataques cibernéticos poderemser de diferentes tipos torna a tarefa de detecção ainda mais complexa.

Os eventos gerados pelas ferramentas de segurança são normalmenteregistados em logs3, de forma a ser possível efectuar auditorias aossistemas computacionais. Segundo Kent en Souppaya (2006) o número ea variedade de logs de segurança tem aumentado consideravelmente devidoao fornecimento contínuo de dados para análise, ao número elevado de fontesde registo e à geração de logs redundantes, o que resulta numa auditoriamenos e�ciente. Para além deste problema, a análise da informação contidanos vários eventos nem sempre é uma tarefa fácil, muitas vezes devido

3Registo de eventos num sistema computacional.

2

CAPÍTULO 1. INTRODUÇÃO

Figura 1.2: Ataques mais frequentes2

à complexidade do conteúdo dessa informação, bem como a forma comoa informação é apresentada e descrita. Isto faz com que o gestor e/ouadministrador de rede não actue de uma forma rápida e e�ciente em casode anomalia no sistema, expondo assim a informação ao �mundo alheio�,bem como colocando em risco a operacionalidade dos vários sistemas.

Surge então a necessidade de criar ferramentas e mecanismos capazes deanalisar e interpretar a informação contida nos diversos eventos, cruzando-acom informação disponível de diversas fontes, de forma a priorizar os eventosem função da sua criticidade. Com isto obtém-se informações mais precisase completas em relação, por exemplo, a uma possível intrusão ou anomalia

3


computadores

no sistema.

1.2 Objectivos

O objectivo deste projecto foca-se na classi�cação de eventos de segurançaassociados a redes de computadores, de forma a criar um modelo declassi�cação que permita valorizar os diferentes eventos em função do seutipo. Dado o objectivo principal deste projecto surge naturalmente a seguintequestão de investigação subjacente:

• Como valorizar os eventos de segurança.

Sobre esta questão resultam as seguintes subquestões:

• Que eventos podem e devem ser valorizados

• Quais as fontes de informação utilizadas para a valorização

• Qual a relação entre as diferentes fontes

• Como demonstrar a e�cácia da valorização

1.3 Métodos de investigação

Atendendo à natureza do problema apresentado e aos objectivos inicialmenteestipulados, recorreu-se ao método Design Science (Pe�ers et al. 2007)complementado com survey bibliográ�co

Para a obtenção da bibliogra�a, foi seguida uma estratégia de pesquisa com asseguintes Keywords : intrusion detection, alert aggregation, alert correlation,information security, event classi�cation, log analysis e Network security.Obteve-se assim um número considerável de elementos bibliográ�cos,relacionada com a grande área do tema deste projecto: Modelo para de�niçãode criticidade em eventos de segurança de redes de computadores. Foramobtidas 58 referências bibliográ�cas, sendo efectuado uma leitura das mesmascom o objectivo de seleccionar aquelas que abordam as questões desteprojecto.

Cada referência bibliográ�ca com informação relevante, em função da etapaem que o projecto se encontrava, seguia-se uma leitura e análise integradessa referência bibliográ�ca. No �nal deste procedimento foi efectuada uma

4


síntese de todas as referência bibliográ�cas sendo seleccionadas 41 das 58inicialmente obtidas.

Em relação aos documentos do survey bibliográ�co, na tabela 1.1 é possívelveri�car a quantidade por intervalos de ano de publicação.

Ano do documento Número de documentos

Anterior a 2000 3

Entre 2000 e 2005 4

Entre 2006 e 2010 27

Depois de 2010 7

Total de documentos 41

Tabela 1.1: Número de documentos relativos ao survey bibliográ�co

Contudo nem todos os elementos bibliográ�cos seleccionados tiveram omesmo grau de importância no processo de investigação deste projecto. Natabela 1.2 é possível identi�car os temas mais relevantes no âmbito dainvestigação deste projecto e o número de elementos bibliográ�co de cadatema.

Com todos os elementos bibliográ�cos seleccionados, foi então possível umamelhor compreensão do problema aqui apresentado, de forma a que aabordagem da solução do mesmo fosse a melhor.

Em relação ao método Design Science, na �gura 1.3 é apresentado todoo processo do método. Tal como descrito em Pe�ers et al. (2007) aprimeira fase do processo é identi�car o problema que o investigador pretendesolucionar e quais as suas principais motivações, demonstrando qual aimportância de encontrar uma solução para esse problema. Depois deidenti�cado o problema é necessário de�nir quais os objectivos para encontrara sua solução. De acordo com objectivos referentes à solução proposta, oartefacto é desenvolvido e implementado. Por último a avaliação do artefactodesenvolvido em função dos resultados obtidos e da e�ciência da solução. No

5


computadores

Tema abordado Número de documentos

Detecção de intrusões 5

Gestão e análise de eventos de segurança 4

Vulnerabilidades em sistemas computacionais 3

Modelação de ataques cibernéticos 6

Total de documentos 18

Tabela 1.2: Elementos bibliográ�cos mais relevantes

�nal, de forma a terminar todo o projecto, a respectiva publicação de modoa transmitir todo o conhecimento adquirido.

Figura 1.3: Metodologia de investigação Design Science: Imagem retiradade Pe�ers et al. (2007)

Para validação do trabalho proposto, bem como de todas as conclusões delederivadas e demonstrar a e�ciência da solução proposta, recorreu-se a ensaioslaboratoriais. Todos os resultados obtidos neste processo são devidamenteanalisados, documentados e comparados entre si, nos diversos cenários emque este trabalho se enquadra.

6


O ensaio laboratorial foi efectuado com recurso de uma rede virtual, compostapor cinco máquinas virtuais, de forma a criar uma "bancada"de teste a todoo trabalho proposto.

1.4 Estrutura do documento

Nesta secção é apresentada uma descrição de como o presente documento seencontra organizado, explicando resumidamente os capítulos que o compõem.

No primeiro e presente capítulo é efectuado um enquadramento relativo aotema desta dissertação, e qual a principal motivação para a sua realização.Neste capítulo é ainda especi�cado o objectivo deste projecto e quais foramos métodos de investigação utilizados para o alcançar.

No capítulo 2 é efectuado um enquadramento de conceitos teóricos relativosao problema inicialmente identi�cado com base na revisão de toda abibliogra�a seleccionada.

O capítulo 3 consiste essencialmente na especi�cação e implementação dosistema proposto. Inicialmente são detalhados os requisitos do sistema(funcionais e não funcionais), seguido de uma descrição detalhada do desenhodo sistema e das principais componentes que o constituem. Por �m adescrição da arquitectura e implementação do sistema proposto.

No capítulo 4 são apresentados os testes realizados em laboratório ao sistemae as respectivas conclusões, de forma a avaliar a solução proposta.

No capítulo 5 são apresentadas as conclusões de todo o trabalho desenvolvidoe também uma análise critica de todos os aspectos deste trabalho, de formaa salientar os aspectos menos positivos. Por �m é descrito o trabalho futurodo mesmo.

7


computadores

8

Capı́tulo 2Fundamentos teóricos de segurança de

redes de computadores

O presente capítulo tem como objectivo enquadrar conceitos teóricosrelativos ao tema desta dissertação, nomeadamente segurança em redesde computadores, referenciando também o estado actual de algunsprojectos e trabalhos relativos à segurança de redes de computadores, maisconcretamente na detecção de intrusões.

Dadas as questões de investigação descritas no capitulo anterior e na tentativade as responder, é necessário todo um enquadramento teórico em relação àinvestigação realizada, de forma a conhecer a origem do problema identi�cadoe o que o caracteriza.

2.1 Fundamentos das redes de comunicações IP

As redes de comunicações IP (Internet Protocol) são hoje em diaimprescindíveis a qualquer organização. É sobre a rede que �ui toda ainformação que permite à sociedade e às organizações comunicarem deforma rápida, e�ciente e a grandes distâncias. Este tipo de redes assentasobre um modelo denominado de Transmission Control Protocol/InternetProtocol (TCP/IP), que consiste numa pilha protocolar, caracterizada por serportável e independente da plataforma usada, onde diversos sistemas podemcomunicar entre si, possibilitando assim a ligação entre redes heterogéneas. Oprotocolo TCP/IP é também conhecido pelo protocolo da Internet, conhecidacomo a "Grande Rede"ou somente "A Rede"(Kurose en Ross 2002).

9


computadores

Como é possível visualizar na �gura 2.1, a pilha protocolar TCP/IP écomposta por cinco camadas (Kurose en Ross 2002):

• Camada Física: É composta pelos componentes físicos que de�nem omeio de transmissão do canal de comunicação e os respectivos sistemasmecânicos que o compõem, bem como as características dos sinais decomunicação que "passam"pelos mesmos.

• Camada de Ligação: Especi�ca as tecnologias usadas natransferência de dados, bem como os meios de ligação. É responsávelpelo controlo de �uxo, especi�ca a(s) técnica(s) de acesso ao meio,sendo também responsável pela detecção e correcção de erros.

• Camada de Rede: É responsável pelo encaminhamento dosdatagramas, vulgo pacotes de dados, entre a origem e o destino. Mesmoquando os datagramas tenham que passar por pontos intermédiosda rede, a camada de rede calcula a melhor rota para efectuar aentrega dos mesmos. Dos protocolos envolvidos no encaminhamento(interno e externo) destacam-se os seguintes: RIP (Routing InformationProtocol), OSPF (Open Shortest Path First), BGP (Exterior GatewayProtocol) e ICMP (Internet Control Message Protocol). A camada derede também é responsável pelo endereçamento, isto é, a atribuição deum endereço único a todas as interfaces dos vários dispositivos da rede.

• Camada de Transporte: Permite uma comunicação entre máquinas.É também responsável pelo controlo de �uxo fornecendo um serviçoorientado à conexão no caso do protocolo TCP (Transmission ControlProtocol), e um serviço não orientado à conexão quando utilizado oprotocolo UDP (User Datagram Protocol). Em relação ao protocoloTCP a entrega de todos os pacotes é efectuada de forma �ável, ou seja,existe uma garantia da entrega de mensagens provenientes da camadasuperior ao destino. Já no protocolo UDP não há qualquer garantia daentrega dos datagramas.

• Camada de Aplicação: É responsável por apoiar as aplicações derede. A camada de Aplicação especí�ca os protocolos que directamenteservem as aplicações. Os protocolos HTTP, SMTP e FTP são algunsexemplos.

10

CAPÍTULO 2. FUNDAMENTOS TEÓRICOS DE SEGURANÇA DE REDES DECOMPUTADORES

Figura 2.1: Pilha protocolar TCP/IP

2.2 Tráfego TCP/IP e as suas vulnerabilidades

O protocolo TCP/IP foi desenvolvido pelo Departamento de Defesa dosEstados Unidos para a sua rede de pesquisa ARPANET, nos meados dosanos 70. Esta rede tinha como principal objectivo conectar centenasde universidades e institutos nos Estados Unidos da América. Contudo,a segurança do protocolo não foi levada em consideração por quem odesenvolveu, muito devido ao ambiente de con�ança que se vivia naquelaépoca no departamento onde foi criado. Tal como a segurança dos protocolos,também não foram tomadas medidas de precaução em relação a suaescalabilidade e ao espaço de endereçamento (Li en Jiang 2012).

A Internet é hoje um fenómeno de elevada popularidade, universalidade ede escala mundial, sendo possível veri�car na �gura 2.2 um mapeamentoda Internet, realizado por um projecto denominado de The Opte Project1.Em função deste fenómeno e de alguns aspectos de segurança outroradescartados, tornaram a Internet de alguma forma muito vulnerável aataques cibernéticos.

1http://opte.org/

11


computadores

Figura 2.2: Mapa da Internet em 20032

Existe uma variedade de vulnerabilidades na pilha protocolar TCP/IP, quederivam da forma como a pilha protocolar foi "desenhada"e "projectada".Esses problemas de segurança são provenientes dos serviços fornecidos pelasvárias camadas da pilha protocolar (Bellovin 1989).

Como já referido, é na camada de rede que se encontram os vários protocolosde encaminhamento interno e externo. Estes protocolos apresentam algumasvulnerabilidades que exploradas podem ter consequências graves no devidofuncionamento da rede. Um exemplo disto é a propagação de falsas rotase informação falsa do estado de ligação (Bruhadeshwar et al. 2009). Já nacamada de transporte, onde de encontram os protocolos TCP e UDP, existemtambém alguns problemas de segurança. Estes dois protocolos baseiam-

2Imagem retirada em Junho de 2013 de http://www.opte.org/maps/

12


se no endereço IP para identi�car os vários host da rede, não existindoassim nenhuma forma de autenticação, tanto ao nível da origem dos pacotesbem como da integridade e validade dos dados que são transferidos (Hao-yu et al. 2010).

Observando alguns protocolos comuns da camada de aplicação da pilhaprotocolar TCP/IP, tais como DNS (Ariyapperuma en Mitchell 2007), FTP(Xia et al. 2010), SNMP (Jiang 2002) e SMTP (Takesue 2011) (Riabov 2007),são relatados alguns problemas de segurança, como por exemplo, ao nível daautenticação, sni�ng, cache poisoning, stack over�ow, spoo�ng e negação deserviço.

2.3 Segurança em Redes de Computadores

Actualmente a expansão da Internet é um dos maiores fenómenos observadosnos últimos anos. Vivemos numa sociedade cada vez mais dependenteda "Rede", tanto a nível pessoal como empresarial. Sem grande "regra"aInternet cresce de dia para dia "tomando conta"do nosso quotidiano e delasomos, de certo modo, cada vez mais dependentes. Todo este rápido processode popularização da Internet, bem como o facto de ser "aberta", partilhadae de dimensão mundial, faz com que seja cada vez mais vulnerável (Li 2012).

O conceito de Segurança em redes de computadores surge com a tentativade eliminar, ou pelo menos atenuar as consequências dos problemasreferidos, através da inclusão de medidas técnicas e da correta gestão dainfraestrutura de rede. Este conceito assenta no estudo e compreensão deáreas como as ciências da computação, tecnologias de comunicação, redes decomputadores, segurança da informação, teoria da informação e caracteriza-se pela privacidade, integridade, con�abilidade, disponibilidade e não repudiode transferência de informação (Li 2012) (Yan-ping et al. 2010).

Existe um conjunto de problemas e ameaças que levam a ter em atençãoo "assunto"da segurança das redes de computadores e da informação.Desde os problemas de design e implementação dos protocolos utilizadosnas redes, passando pelos problemas de autenticação dos mecanismos decontrolo e encaminhamento de rede, que são muitas vezes mínimos ouinexistentes. No entanto existem outras preocupações, nomeadamente todasas vulnerabilidades do vasto número de software utilizado, bem como toda aespécie de software malicioso existente. Estas são algumas razões fortes pelaqual a segurança de redes de computadores e da informação é importante

13


computadores

(Xiaoling 2011) (Yan-ping et al. 2010).

Segundo Zúquete (2010), uma das grandes áreas de actividade que se devemconsiderar no âmbito da segurança computacional é e defesa contra actividadenão autorizada e maliciosa. A defesa contra actividade não autorizada emaliciosa consiste na iniciativa de alguém contra o normal funcionamentodos sistemas computacionais. Este problema tem normalmente duas origensdiferentes: indivíduos que pertencem à organização proprietária do sistemacomputacional ou indivíduos que não pertencem à organização.

As actividades não autorizadas dividem-se em cinco tipos diferentes:

• Acesso a informação - Todos os tipos de acesso a informaçãocon�dencial, quer se encontre guardada em sistemas computacionaisou se encontrem em trânsito na rede.

• Alteração de informação - Tudo que envolva a alteração e destruiçãode informação sem autorização, quer de forma implícita ou explícita.

• Utilização abusiva de recursos - O uso abusivo de recursos como amemória principal ou secundária, tempo de processamento e ocupaçãode rede, pode ter o efeito de não disponibilidade desses recursos aterceiros.

• Impedimento de prestação de serviço - Pode ser entendido comoum caso extremo de utilização abusiva de recursos, pois normalmenteo seu principal objectivo é impedir que terceiros tenham acesso aosrecursos.

• Vandalismo - Consiste na interferência com o normal funcionamentodos sistemas computacionais, sem que isto traga qualquer benefíciopara quem o causa.

2.3.1 Detecção de intrusões

Entende-se por detecção de intrusões todos os processos de identi�cação deactividades não autorizadas e maliciosas, internas ou externas, numa dadarede de computadores. Uma intrusão pode ser de�nida por uma acção ouconjunto de acções que visam comprometer de alguma forma, um ou maisrecursos de uma rede de computadores.

No âmbito da segurança da informação, a detecção de intrusões tem um

14


papel fundamental, onde os mecanismos básicos de segurança tais como:autenticação, controlo de acesso, �rewalls e anti-vírus, por si só já não sãosu�cientes para garantir a segurança dos sistemas computacionais, bem comotoda a informação neles contida (Li et al. 2005).

Existe um conjunto de tecnologias que podem ser implementadas de forma aauxiliar e agilizar a detecção de intrusões e a actividade maliciosa. Das maisconhecidas e utilizadas destacam-se as �rewalls, os IDS (Intrusion DetectionSystem) e os anti-vírus. Embora todas estas tecnologias assumam o seupapel na detecção de actividade não autorizada, cada uma delas tem uma�nalidade diferente em relação às demais.

Uma �rewall consiste numa tecnologia que implementa um conjunto demedidas e políticas de segurança e controlo de acesso, entre duas redes comníveis de con�ança diferentes, podendo ser vista como um "separador"ou um"limitador"entre duas redes. As �rewalls impedem o acesso não autorizado,tanto a informação como a recursos do sistema, tendo um papel reactivo noque toca à segurança do sistema. Funcionalmente uma �rewall analisa e �ltrao tráfego da rede com base num conjunto de regras previamente estipuladas,seja para controlar o acesso dos hots da rede interna para a rede externa ourestringir o acesso da rede externa aos hots da rede interna (Yue et al. 2009).

Os anti-vírus são uma tecnologia que visa a protecção de sistemascomputacionais contra vírus informáticos3, permitindo a sua detecção eeliminação. Esta tecnologia tem então a capacidade de ao detectar algumtipo de malware gerar um alerta e eliminar de alguma forma o problematendo, como as �rewalls, um papel activo em relação à segurança do sistema(Yue et al. 2009).

Os IDS são sistemas que têm como função detectar actividade classi�cadacomo fora do normal. Baseiam-se no principio de que o comportamentomalicioso e não autorizado de um sistema computacional é claramentediferente do comportamento normal. De forma a detectar actividademaliciosa, os IDS analisam diversas fontes de dados do sistema computacionalque está a ser monitorizado, detectando padrões anormais gerados pelaactividade maliciosa (Zeng et al. 2010).

Os IDS são classi�cados em dois tipos: os IDS que operam num único host(HIDS) e os IDS que operam como um dispositivo autónomo numa rede

3Software malicioso que tal como um vírus biológico tem a capacidades de se propagar.

15


computadores

de computadores (NIDS). Os HIDS monitorizam os diversos componentesrelativos a um host ao qual este se encontra hospedado, tais como: sistemaoperativo, sistema de �cheiros, hardware, tráfego de entrada e saída. Estetipo de IDS utiliza também os recursos disponíveis do host em que seencontra hospedado, para desempenhar a sua função. Em relação aosNIDS, estes monitorizam todo o tráfego de uma rede, podendo assimmonitorizar um vasto número de hosts, de forma a detectar actividades ilícitas(Garuba et al. 2008).

Existem dois métodos de detecção de intrusões: SIDS Signature Based) eAIDS (Anomaly Based). O primeiro método, contém uma base de dadosde assinaturas de ataques conhecidos e analisa todo o tráfego da redecomparando-o com essas assinaturas. Caso encontre uma correspondênciaé gerado um alerta (Gupta et al. 2012). O segundo método consiste nadetecção de desvios à normalidade da actividade, gerando um alerta caso talse veri�que.

Contudo os diferentes modos de detecção dos IDS têm alguns problemase limitações. Os SIDS apenas detectam intrusões para as quais possuemassinatura e geram uma quantidade de falsos positivos elevada. Estesproblemas podem ocorrer, por exemplo, devido à especi�dade das assinaturasou ao não conhecimento do ambiente que o IDS está a monitorizar(Gupta et al. 2012). Quanto aos AIDS, que apesar de terem maior capacidadede detectar ataques desconhecidos, apresentam problemas na classi�caçãodo tráfego da rede, dada a complexidade de o classi�car como normal ouanormal, dando origem a muitos falsos alarmes. Para além do mais énecessário ainda inspeccionar manualmente um alerta, de forma a poderidenti�car se um ataque desconhecido existe ou não (Sato et al. 2012).

Em relação aos tipos de análise, os IDS podem ser do tipo Singular Basedou Collaborative Based. O tipo Singular Based consiste num tipo de análisemais simplista, onde existe apenas um sensor como fonte de dados. Já o tipoCollaborative Based, consiste na análise diversas fontes de dados (múltiplossensores) provenientes de diversas camadas do sistema. Segundo Zhou et al.(2010), os collaborative IDS, ao contrário do tipo de análise Singular Based,têm a capacidade de reduzir o número de falsos positivos, devido ao facto decorrelacionarem eventos provenientes de diversos sensores.

Na tabela 2.1 é possível visualizar de forma mais resumida a classi�caçãodos IDS, em função das suas diferentes características.

16


Característica operacional Classi�cação

Modo de detecção Signature Based

Anomaly Based

Fonte de eventos Host Based

Network Based

Tipo de análise Singular Based

Collaborative Based

Tabela 2.1: Classi�cação dos IDS: Modi�cado de (Zúquete 2010), Página 210

Os falsos positivos continuam a ser os maiores problemas, independentementedo tipo de IDS. Segundo Sourour et al. (2009) cerca de 99% dos alertasgerados pelos IDS não estão relacionadas com qualquer tipo de actividademaliciosa. O elevado número de falsos positivos leva à sobrecarga da entidadede segurança dada a quantidade de informação falsa a analisar (Shimamuraen Kono 2006).

2.3.1.1 Registo de eventos de segurança

As tecnologias para detecção de intrusões e actividade maliciosa gerameventos quando detectadas anomalias ou quebras de segurança que podemcomprometer o sistema a monitorizar. Dada a quantidade de eventos geradospor este tipo de tecnologias, é necessário um mecanismo de registo desseseventos, para posterior análise. Para tal são utilizados logs. Logs sãocompostos por entradas que contem informação relativa a um determinadoevento que tenha ocorrido (Kent en Souppaya 2006).

As tecnologias acima referidas geram eventos quando detectam actividadeanómala, contudo existem algumas particularidades que diferenciam oseventos gerados por estas. Os eventos gerados pelas �rewalls e anti-vírusreportam uma quebra de segurança no sistema, já os eventos gerados pelosIDS reportam anomalias e actividade suspeita (Kent en Souppaya 2006).Este é o factor de diferenciação entre os eventos gerados por estas tecnologias,dado que a informação contida nos eventos gerados pelos IDS não é explicita

17


computadores

em relação à causa da sua geração. Por este motivo os eventos provenientesdos IDS requerem informação complementar de forma a enriquecê-los,agilizando todo o processo da sua análise.

Para caracterizar melhor um evento de segurança, uma das informaçõesnecessárias é a natureza do ataque que lhe estará associado. Nesse sentido asecção seguinte resume alguns dos aspectos fundamentais dos ataques e dosrepetidos modelos de representação.

2.3.2 Modelação de ataques

Os ataques cibernéticos são a principal razão para o uso de políticas emecanismos de segurança. Os ataques cibernéticos aumentam de dia paradia, são cada vez mais difíceis de detectar, tendo sempre um objectivo�nal e de natureza diversa. Os atacantes seguem uma sequência lógica deprocedimentos para atingir o seu objectivo �nal, com recurso a ferramentaspara o efeito, sendo possível visualizar na �gura 2.3 as etapas necessárias naexecução de um ataque genérico (Eom et al. 2008) (?).

Fim!?-Ataquecom

sucesso?

Escolha deferramentas,exploits e

rootkits a utilizar

Levantamento deinformação.Scanningde portas e

vulnerabilidades...

Escolhado(s) alvo(s)

Não

Sim

Figura 2.3: Etapas de um ataque

As técnicas utilizadas em ataques cibernéticos são cada vez mais robustase dinâmicas, sendo cada vez mais difícil para os mecanismos de segurançainformática detectarem estes ataques. Dado isto são necessários métodos

18


capazes de detectar os ataques em si e de ter a capacidade de avaliar osefeitos que estes causam, obtendo uma análise profunda e concisa sobre oimpacto do ataque em relação ao sistema a proteger (Ning et al. 2008).

2.3.2.1 Attack trees

Attack trees consistem numa representação formal de como um sistema podeser atacado, representando ataques numa estrutura em árvore compostapor vários nós, que representam as várias formas de atingir a meta, sendoesta representada pelo nó da raiz da árvore (Camtepe en Yener 2007). Aoconseguir visualizar e compreender as diferentes maneiras que um sistemapode ser atacado, é possível conceber medidas de forma a tentar impedir essesataques. Segundo Eom et al. (2008) cada nó tem três atributos: condiçõesprévias, que são propriedades do sistema que facilitam a execução do ataque,sub-metas, que são os nós adjacentes ao nó da raiz da árvore e pós-condições,que são as mudanças em diferentes sistemas e ambientes. Segundo Camtepeen Yener (2007) é possível ainda capturar e identi�car etapas atómicas de umataque, sendo possível parametrizar custos e pesos a cada etapa do ataque.

Segundo Saini et al. (2008) O processo de construção uma Attack tree éa seguinte:

1. De�nir o principal objectivo do ataque.

2. Decompor o objectivo do ataque em sub-objectivos.

3. Decompor gradualmente os sub-objectivos em em tarefas cada vezmenores.

4. Atribuir valores aos atributos relativos aos nós adjacentes.

5. Atribuído os valores a todos os nós, é possível avaliar a segurança dosistema em relação ao objectivo do ataque.

Na �gure 2.4 é possível visualizar um exemplo de um attack tree.

As attack tress apresentam contudo alguns problemas. Segundo Camtepe enYener (2007) um ataque pode exigir que as suas acções atómicas aconteçampor uma dada ordem temporal rigorosa, ou então, que essas mesmas acçõesapenas são válidas num determinado período de tempo, o que é difícil derepresentar em attack trees. Segundo Saini et al. (2008) outro aspectoproblemático, é o facto de não existir nenhum método sistemático para aatribuição dos valores aos atributos dos nós adjacentes da árvore.

19


computadores

Figura 2.4: Exemplo de Attack Tree: Imagem retirada de (Eom et al. 2008)

2.3.2.2 Attack graphs

Attack graphs tal como attack trees, consistem numa representação formalde como um sistema pode ser atacado, bem como os processos e acções aque um atacante recorre para explorar vulnerabilidades de um sistema. Sãografos direccionados onde podem ser descritos as possíveis acções tomadaspor um intruso, bem como vulnerabilidades e exploits4 de um dado sistema.Para além disso, os attack graphs podem auxiliar na análise do número decaminhos de um ataque, bem como no cálculo de número de ataques bemsucedidos.

Segundo Alhomidi en Reed (2012) existem vários modelos de representaçãode attack graphs, com características e �nalidades diferentes, sendo eles:

• Graph-Based Attack Graph: este modelo pode ser considerado omodelo genérico ou modelo base, dos attack graphs. Ele demonstracomo construir diagramas que representam ataques, usando os várioscaminhos e probabilidades de sucesso de um ataque como base deconhecimento. Ele representa os estados possíveis de um ataque e osexploits utilizados, em hosts especí�cos, bem como serviços que os hostsfornecem. Os nós do grafo deste modelo representam o estado de umataque e as ligações entre nós representam um exploit

• State Enumeration Attack Graph: este modelo consiste numcontrolo simbólico, onde é representada o estado de uma rede, bem

4conjunto de código ou comandos que se aproveitam de vulnerabilidades presentes emsistemas computacionais.

20


como as transições de estado. As entradas deste modelo são asvulnerabilidades de cada host da rede, as ligações de rede e aspossíveis capacidades e recursos do atacante. Dado o objectivo doataque, o modelo produz o "grafo de ataque"e veri�ca se a sequênciade vulnerabilidades leva à concretização do ataque. Com isto, estemodelo revela que vulnerabilidades devem ser corrigidas. Contudo estemodelo apresenta uma limitação pois apresenta caminhos de ataquesredundantes, o que resulta em cálculos desnecessários. Os nós do graforepresentam o estado de uma rede e as ligações representam a transiçãode estados.

• Coordinated Attack Graph: este modelo consiste na representaçãode ataques em conjunto, isto é, para um ataque alcançar o seu objectivo,este necessita de um grupo de intervenientes coordenados. Nestemodelo é representado um sistema e as várias acções do ataque. Éutilizado o modelo matemático de máquina de estados �nita pararepresentar as várias acções conjuntas que levam ao objectivo doataque. O problema deste modelo é a dimensão que o grafo geradopode apresentar, dado ao número de estados que este pode conter.Os nós deste grafo representam o estado de um sistema e as ligaçõesrepresentam uma acção.

• Dependency Attack Graph: este modelo baseia-se numa relaçãocausal de condições relativas à especi�cação e con�guração de umsistema, isto é, um pré-requisito de um determinado ataque nunca éinválido pelo sucesso de um outro ataque. Esta abordagem melhorousigni�cativamente a escalabilidade em relação a outros modelos. Nografo gerado por este modelo, os nós representam condições de estadodas con�guração de um sistema e as ligações representam a relaçãocausal entre essas condições.

• Full and Predictive Attack Graph: este modelo começa porrepresentar o host do atacante e todas as suas acções possíveis.De seguida é representada a acessibilidade de outros hosts emrelação ao host do atacante. Sempre que um host é alcançável,é feita uma tentativa de comprometer o host em função das suasvulnerabilidades.Contudo esta abordagem tem alguns problemas, poisgera caminhos redundantes. Os nós do grafo gerado por este modelorepresentam hosts de uma rede e as ligações entre os nós representamvulnerabilidades.

• Host-Compromised Attack Graph: este modelo consiste num grafo

21


computadores

de ataques construído com base em informação produzida por umteste de penetração, de forma a representar o estado de uma redee os respectivos exploits utilizados. Este modelo indica que hostspodem estar comprometidos sem o conhecimento das acções do ataqueutilizado. Os nós do grafo gerado por este modelo representam o estadode uma rede e as ligações representam a utilização de um exploit.

• Topological Vulnerablitiy Attack Graph: este modelo consiste navisualização de uma espécie de topologia de vulnerabilidades, isto é,ele tem como objectivo a análise de vulnerabilidades de um sistema,como podem ser exploradas cada uma delas e quais as dependênciasentre si. O modelo cria um grafo de dependência de um dado ataquecom os exploits a utilizar. Dado uma condição inicial ele mostra todasas condições seguintes para o sucesso do ataque. Neste modelo os nósdo grafo gerado representam condições e as ligações representam umexploit

• Host-Based Network Attack Graph: este modelo é constituídopor três partes: per�s de ataques, descrição de hosts, as ligações derede e vulnerabilidades e por �m um conjunto de regras e acções deataque. O algoritmo usado neste modelo para gerar o grafo de ataquecomeça pelas vulnerabilidades de um host e de seguida usa os recursosdesse mesmo host para atacar outros hosts, até o ataque atingir o seuobjectivo. Este modelo mostra a sequência de ataques a partir de umhost origem até um host destino. Neste grafo os nós representam umou mais hosts e as ligações representam um exploit.

• Multiple-Prerequisites Attack Graph: neste modelo estãopresentes três tipos de nós: os estados, pré-requisitos e vulnerabilidades.Os estados representam hosts e o nível de acesso do atacante, ospré-requisitos representam as condições que um ataque necessita paraconseguir explorar uma vulnerabilidade. No grafo gerado por estemodelo, os nós podem representar um estado, um pré-requisito ou umavulnerabilidade, e as ligações representam a transição entre os váriostipos de nós.

• Logical Attack Graph: este modelo baseia-se na relação decausalidade entre as con�gurações do sistema e os privilégios doatacante. São representadas as instruções lógicas de um ataque eas relações de causalidade da rede com os privilégios do atacante.O objectivo do ataque é representado no nó raiz do grafo geradosendo o ataque expresso numa formula proposicional em relação aos

22


parâmetros de con�guração da rede. Neste modelo os nós representamuma instrução lógica, enquanto as ligações representam a relação causalentre as con�gurações de rede e os potencias privilégios do atacante.

• Goal-Oriented Attack Graph: neste modelo são representadasvulnerabilidades e as acções para a execução de um ataque,independentemente do sistema em causa. Este modelo tem comoobjectivo descrever todos os passos de um atacante, em função deum conjunto de pré-condições e os exploits que podem ser utilizadospara um determinado ataque atingir o seu objectivo. No grafo geradopor este modelo os nós representam vulnerabilidades e as ligaçõesrepresentam acções.

Na �gura 2.5 é possível visualizar um exemplo de um attack graph: Host-based Network Attack Graph

Figura 2.5: Exemplo de um Attack Graph: Host-based Network AttackGraph6

2.3.2.3 Common Attack Pattern Enumeration and Classi�cation

Common attack Pattern Enumeration and Classi�cation (CAPEC) (cap n.d.)é uma lista de padrões de ataques informáticos e uma descrição de métodoscomuns de exploração de vulnerabilidade em sistemas de computação. Estalista é de domínio publico, desenvolvida por uma comunidade com o intuito

6Imagem retirada de (Alhomidi en Reed 2012)

23


computadores

de melhorar os aspectos de segurança no desenvolvimento de software ede ajudar à detecção e prevenção de ataques informáticos. Esta lista éuma espécie de "catálogo"e um esquema de classi�cação, que incluí umataxonomia de classi�cação de ataques bem como a sua descrição, padrões emétodos comuns de exploração de vulnerabilidades, métodos e soluções paraque de alguma forma o ataque seja evitado ou não surta efeito, fornecendoainda uma perspectiva do atacante na óptica das suas possíveis motivações.

A lista de padrões de ataques do CAPEC segue uma estrutura em árvorepara cada tipo de ataque, onde no topo da árvore se encontra a categoriados ataques, seguido dos ataques subjacentes que pertencem a essa categoria.Cada ataque contém a seguinte informação (Barnum et al. 2007):

• Pattern Name and Classi�cation - Identi�cador exclusivo doataque.

• Attack Prerequisites - Condições/funcionalidades que devem existirpara o sucesso do ataque.

• Typical Severity - indicador de severidade do ataque.

• Typical Likelihood of Exploit - Indicador de probabilidade deexploit.

• Description - Descrição do ataque.

• RelatedVulnerabilities or Weaknesses - Referência às vulnerabilidades efraquezas que o ataque explora.

• Method of Attack - Que tipo de ataque é usado, por exemplo:Analysis, Brute Force, Spoo�ng...

• Attack Motivation-Consequences - Resultado técnico desejadopelo atacante, para que este consiga alcançar o seu objectivo.

• Attacker Skill or Knowledge Required - Nível de conhecimentotécnico que o atacante deverá ter para conseguir executar o ataque.

• Resources Required - Que recursos, do sistema computacional aatacar, são necessários para executar o ataque.

• Solutions and Mitigations - Que acções devem ser tomadas paramitigar o ataque.

24


• Context Description - Quais os contextos técnicos em que esteataque é relevante, como por exemplo o sistema operativo ou linguagemde programação.

• References - Outras fontes de informação disponíveis sobre o ataque.

Esta informação, depende da versão utilizada do CAPEC, sendo que oCAPEC está constantemente a ser actualizado pela comunidade que nelatrabalha. Em alguns ataques nem sempre está disponível toda a informaçãoaqui indicada.

2.3.3 Modelação de vulnerabilidades

Uma vulnerabilidade é uma falha na concepção, implementação ouoperacionalidade de um sistema computacional, que pode ser explorada paraviolar um sistema computacional (IETF RFC 2828).

Diariamente são descobertas e reportadas novas vulnerabilidades, o que setraduz num aumento de "pontos fracos" nos sistema de computação, queleva ao aumento de ataques cibernéticos. Para além do mais, a relaçãotemporal entre o anuncio de uma nova vulnerabilidade e o aparecimento deum ataque que explore essa mesma vulnerabilidade diminuiu, o que di�cultamitigação da ameaça (Cukier en Panjwani 2009).

CVE (cve n.d.) é um dicionário que contém informação sobrevulnerabilidades já conhecidas. Esta lista contém um nome para cadavulnerabilidade e a respectiva descrição. Tal como o CAPEC, o CVE éde domínio publico.

O processo de criação de um identi�cador CVE começa com a descobertade uma potencial vulnerabilidade, sendo-lhe atribuído um identi�cadortemporário CVE (Ex. CVE-2000-0004 ), �cando de seguida sujeito a umprocesso de veri�cação. Terminado o processo de veri�cação o estado davulnerabilidade passa a de�nido. O CVE é hoje visto como um standardcompatível com inúmeros serviços e produtos de segurança da informação.

2.3.4 Security Information and Event Management

Security Information and Event Management, ou simplesmente SIEM,consiste na combinação de Security Information Management (SIM) comSecurity Event Management (SEM). Esta abordagem foca-se na recolhae análise da informação de segurança relevante e proveniente de diversos

25


computadores

pontos, de forma a ser plausível a observação dessa informação de um únicoponto de vista, mais amplo e especi�co.

Os sistemas SIEM fazem a recolha da informação gerada pelos váriossensores do sistema computacional, como por exemplo IDSs e �rewalls,correlacionando toda essa informação, de forma a conseguir detectarintrusões. Os SIEM tiram partido de todo histórico de informação, de formaa optimizar a precisão de detecção de intrusões e anomalias, com a criaçãode modelos dos mesmos. Na �gura 2.6 é possível visualizar a arquitecturaconceptual de um SIEM (Gabriel et al. 2009) (Souppaya et al. 2006).

Figura 2.6: Arquitectura conceptual dos SIEM: Imagem retirada de(Gabriel et al. 2009)

Os SIEM podem fazer a recolha de eventos utilizando um de dois métodos:Agentless ou Agent-Based. No caso de Agentless o servidor SIEM recebeos dados dos vários host que estão a ser monitorizados e de seguida sãoefectuadas as funções �ltragem, agregação, normalização e análise doseventos. Em relação ao método Agent-Based, é instalado um software emcada host a monitorizar, de forma a este efectuar as tarefas de �ltragem,agregação e normalização de eventos, para de seguida enviar para aoservidor SIEM, para que este proceda à sua análise e armazenamento(Souppaya et al. 2006).

26


Segundo Miller et al. (2010) um SIEM é normalmente composto por seispartes:

• Source Device - Fonte de onde provém toda a informação a seranalisada pelo Servidor SIEM. A informação pode ter origem dequalquer equipamento real, como um router, bem como ter origem doslogs de uma aplicação.

• Log Collection - Consiste na recolha da informação gerada pelosvários Source Device.

• Parsing/Normalization - Neste processo toda a informaçãorecolhida é normalizada para um formato padrão.

• Rule Engine/Correlation Engine - O Rule engine é o mecanismoresponsável por geral alertas em função da informação contida noseventos. O Correlation Engine é um sub processo do Rule Engine, quetem como função correlacionar os vários eventos de diferentes origens.

• Log Storage - Processo responsável por armazenar toda a informação.Os SIEM podem guardar a informação numa base de dados, numsimples �cheiro de texto ou em �cheiro binário.

• Event Monitoring - Interface com o utilizador. Onde é apresentadatoda a informação processada pelo SIEM. Onde é efectuada toda acon�guração do SIEM.

Na �gura 2.7 é possível visualizar a arquitectura de um SIEM:

2.4 Ferramentas/Frameworks

As ferramentas de segurança têm hoje um papel importante na tentativade salvaguardar as propriedades de segurança dos sistemas computacionais.Existem ferramenta de diversos tipos com propósitos e funcionalidadesdiferentes, seja na detecção de intrusões ou na veri�cação de falhas evulnerabilidades, tendo como objectivo auxiliar todos os processos queenvolvem a segurança da informação.

27


computadores

Figura 2.7: Arquitectura genérica dos SIEM: Imagem retirada de (Swift 2006)

2.4.1 Snort

O Snort é um detector de intrusões utilizado na inspecção de redes decomputadores, que possui um motor de monitorização de tráfego de rede. éum NIDS baseado em conhecimento multiplataforma, que contém um vastonúmero de assinaturas de ataques conhecidos. É normalmente utilizadona monitorização de redes de pequena e média escala, permite a detecçãode ataques em tempo real e a adição de módulos de resposta a ataques(Roesch 1999a).

Ao nível da arquitectura, o Snort é composto por três camadas funcionais:o descodi�cador de pacotes, o mecanismo de detecção e o mecanismo deregisto e alerta. Estas camadas assentam sobre a biblioteca libcap, quepermite a captura de datagramas IP em diversos sistemas operativos sendousada também por várias aplicações de análise de tráfego. A descodi�caçãode pacotes fornece informação sobre os datagramas IP. Os mecanismos dedetecção são compostos por um conjunto de pré-processadores, que fazemuma análise prévia e uma normalização da informação capturada, queincluem módulos de reconstrução de datagramas, detecção de actividadesem portos da camada de transporte, detecção de tráfego anormal enormalizadores de protocolos de camada de aplicação. Por �m, o mecanismo

28


de registo e alerta, baseado em regras pré-de�nidas, em que cada regraespecí�ca um conjunto de padrões característicos de um datagrama de umataque previamente conhecido. Todas as regras activas são percorridas,até encontrar uma que se enquadre com os dadas a analisar, de forma apoder tomar uma decisão. Essa decisão pode ser aceitar os dados comonormais, registar apenas a sua ocorrência ou gerar um alerta (Roesch 1999a)(Roesch 1999b).

Na �gura 2.8 é possível visualizar a arquitectura do snort.

Figura 2.8: Arquitectura do Snort7

2.4.2 Ossec

O Ossec8 é um HIDS com a capacidade de análise de logs, veri�cação damodi�cação não autorizada de �cheiros, detecção de actividade maliciosa emonitorização de políticas de segurança. É uma ferramenta multiplataformacom capacidade de gerar alertas em tempo real e com a capacidade deresposta a ataques.

O Ossec segue uma arquitectura centralizada, permite con�gurar as políticasde segurança bem como con�gurar a prioridade de cada tipo de alerta, quecontem um bloco de integração com o protocolo SMTP, que permite gerarnoti�cações de alertas via e-mail. O Ossec é composto por dois blocosfundamentais: o Manager e os Agents. O Manager é o bloco central dasua arquitectura, é onde são armazenados os logs, as base de dados da

7Imagem retirada em Junho de 2013 de http://seclists.org/8http://http://www.ossec.net/ visitado em Junho de 2013

29


computadores

veri�cação da integridade dos �cheiros e todos os eventos Ossec. São tambémarmazenadas noManager as con�gurações, as regras e políticas de segurança,bem como os descodi�cadores, o que faz com que a con�guração do Ossecseja relativamente fácil.

Para além do Manager o Ossec contém outro bloco, os Agents, que consisteem software instalado nos hosts a serem monitorizados. O agent temcomo função recolher toda a informação do host a analisar, enviando deseguida para o Manager para ser devidamente analisada e correlacionada.A ferramenta Ossec permite ainda a instalação de Agents em máquinasvirtuais e permite ainda a recolha, e posteriormente análise, de informaçãoproveniente de routers, switches e �rewalls.

Na �gura 2.9 é possível visualizar a arquitectura do Ossec.

Figura 2.9: Arquitectura do Ossec9

9Imagem retirada em Junho de 2013 de http://www.ossec.net/

30


2.4.3 Open Source Security Information Management

OSSIM (Open Source Security Information Management)10 é um SIEMdesenvolvido pela AlienVault11 com a capacidade de correlação enormalização de eventos de segurança. O OSSIM agrega um conjunto deferramentas de segurança de forma a obter informação de segurança dosmais diversos tipos e fontes.

Como é possível veri�car na �gura 2.10 o OSSIM é composto por quatroblocos fundamentais: os sensores, o Management Server, a base de dados eo Frontend (Madrid et al. 2009).

• Sensores - Fazem a recolha da informação de segurança nos diversospontos da rede, de forma passiva para não afectarem o tráfego darede. Os sensores tem como função a recolha de informação tais como:intrusões, vulnerabilidades, anomalias, monitorização de redes. Paraalém de isso, os sensores têm ainda a capacidade de colher informaçãode routers, �rewalls e outros IDSs. O agent, que está incorporado nossensores, é responsável por enviar a informação dos sensores para oManagement Server.

• Management Server - É onde a informação é tratada, analisadae correlacionada. É no Management Server que estão de�nidas aspolíticas de segurança. O Management Server é composto por umdaemon12 de controlo das partes integrantes do OSSIM e pelo OSSIMServer que centraliza toda a informação recebida dos sensores.

• Base de dados - Contêm os eventos e toda a informação útil para agestão do sistema.

• Frontend - É responsável por toda a visualização e interacção daaplicação com o utilizador, sendo no Frontend que são efectuadas todasas con�gurações do OSSIM.

10http://communities.alienvault.com/ visitado em Junho de 201311http://www.alienvault.com/ visitado em Junho de 201312Programa que corre em Background, sem que o utilizador tem qualquer interacção e

controlo directo sobre ele13Imagem retirada em Junho de 2013 de

https://www.alienvault.com/wiki/doku.php?id=documentation:architecture

31


computadores

Figura 2.10: Arquitectura do OSSIM 13

2.4.4 Bro

Bro, é um NIDS que analisa o tráfego de rede à procura de actividademaliciosa. Para além de ser um NIDS, Bro suporta uma variedade defuncionalidades no campo da análise de tráfego. Uma das principaiscaracterísticas desde NIDS, é um facto de conter um extenso conjunto de�cheiros logs, onde são registadas todas as actividades da rede monitorizadaem todos os níveis. O Bro faz o registo das várias ligações de rede, bem comode toda a actividade da camada de aplicação, tais como: sessões HTTP,solicitações de DNS, certi�cados SSL, etc.

Ao nível da arquitectura o Bro é fundamentalmente composto por doiscomponentes principais: o event engine e o policy script interpreter. O eventengine tem como �nalidade analisar todo o tráfego da rede, criando eventosde alto nível através do �uxo de pacotes onde os eventos não representamobrigatoriamente intrusões, mas sim a actividade da rede. O event enginecomeça por analisar os cabeçalhos dos pacotes de forma a veri�car se estes

32


estão bem formados. Caso a veri�cação falhe o Bro gera um alerta indicandoo problema e descarta o pacote, caso contrário, são gerados eventos de altonível, e posteriormente enviados para o policy script interpreter. O policyscript interpreter tem como função analisar esses eventos com base numconjunto de políticas de segurança, de forma a identi�car tráfego malicioso.O policy script interpreter contêm um conjunto de Scripts que analisam oseventos gerados pelo event engine, de forma a gerar alertas de segurança e/outomar uma atitude activa quando encontrada uma intrusão (Paxson 1998).

Na �gura 2.11 é possível visualizar a arquitectura do Bro.

Figura 2.11: Arquitectura do Bro14

14Imagem retirada em Junho de 2013 de http://www.bro.org/documentation/overview.html

33


computadores

34

Capı́tulo 3Especi�cação e implementação do

sistema

No presente capítulo é apresentada a descrição da arquitectura da soluçãoproposta, bem como todas as suas funcionalidades de forma a satisfazeros objectivos propostos. São também descritas todas as decisões tomadasrelativamente à implementação do sistema proposto e a descrição dascaracterísticas do mesmo.

Inicialmente são especi�cados os requisitos do sistema seguido do desenhoe arquitectura do mesmo, devidamente explicada e fundamentada. Por �mé feito uma descrição detalhada da implementação do sistema, de forma asalientar todas as opções tomadas que derivam dos requisitos inicialmentedescritos.

3.1 Requisitos do sistema

A especi�cação dos requisitos do sistema é uma tarefa importantíssima, deforma a poder identi�car as necessidades funcionais e não funcionais domesmo. Através do estudo e análise da informação resultante dos eventos desegurança gerados pelos IDS, tentou-se identi�car quais os principais aspectosque poderiam, eventualmente, melhorar a análise dos eventos de segurança,uma vez que os IDS geram muitos falsos positivos. Para além dos mais, oseventos de segurança gerados pelos IDS são de difícil análise, em relação aoutras tecnologias de segurança. Os vários cenários em que o sistema poderáactuar têm as suas diferenças, o que também foi levado em consideração naespeci�cação dos requisitos, de forma a que o sistema seja moldável para

35


computadores

diferentes contextos.

Com a especi�cação dos requisitos funcionais identi�cou-se as característicastécnicas dos sistema, de forma a obter os resultados esperados, em função doobjectivo proposto neste trabalho. Em relação à especi�cação dos requisitosnão funcionais, que embora não estejam directamente relacionados com asfuncionalidades e características técnicas do sistema, estes caracterizam a suausabilidade. Os requisitos não funcionais1, de uma forma geral, caracterizamo sistema quanto à sua disponibilidade, manutenção, portabilidade, e�ciênciae �abilidade, por exemplo.

3.1.1 Cenários e contextos

Observando um ataque cibernético, independentemente do que o caracteriza,este tem diferentes consequências dependendo do cenário que foi exposto aoataque. Os danos causados por um ataque têm maior ou menor relevo emfunção do conjunto de factores que caracterizam o cenário. Cada cenáriotem as suas próprias características, dai quando se analisa um evento desegurança é necessário ter em conta os aspectos que levaram a geração domesmo, dependendo do tipo e da importância da informação nele contida.

Diferentes tipos ataques fazem os IDS gerar diferentes eventos, dai anecessidade de os classi�car e priorizar, isto dependendo sempre do cenárioe contexto. A título de exemplo, observando todas as consequências que umataque de Denial of Service (DoS) sobre um operador de telecomunicações,estas são bastante diferentes se o mesmo ocorresse na rede de um sistema desaúde. Observando as consequências de um ataque Sql Injection, em funçãodos cenários acima descritos, este à partida teria muito mais impacto na rededo sistema de saúde do que na rede de um operador de telecomunicações.

Todas estas premissas devem ser tomadas em consideração quando desenhadauma estratégia de segurança, de forma a aumentar a detecção precoce dapossível actividade maliciosa que mais estragos poderá fazer em relação aocontexto analisado.

3.1.2 Requisitos funcionais

Para o problema identi�cado foram de�nidos os seguintes requisitosfuncionais:

1IEEE Std 830-1998

36

CAPÍTULO 3. ESPECIFICAÇÃO E IMPLEMENTAÇÃO DO SISTEMA

• Recolher e interpretar informação proveniente do IDS Snort.

• Relacionar eventos de segurança com informação de contexto.

• Classi�car eventos de segurança quanto ao tipo de ataque que estespossam representar.

• Identi�car se um evento de segurança é oriundo de uma origemreputado como malicioso.

• Identi�car quais os ataques que um evento de segurança possa estarassociado.

• Descrever toda a informação disponível de um ataque.

• Relacionar informação recolhida do sistema computacional amonitorizar, nomeadamente as suas vulnerabilidades, com informaçãorecolhida do IDS.

• Descrever toda a informação disponível de uma vulnerabilidade.

• Classi�car eventos de segurança quanto a sua perigosidade e criticidade.

• Priorizar eventos de segurança, em função de valores introduzidos peloutilizador.

3.1.3 Requisitos não funcionais

Para o problema identi�cado foram de�nidos os seguintes requisitos nãofuncionais:

• Multi-plataforma.

• Escalável.

• Composto por módulos funcionais independentes entre si.

• Tolerante à possível falta de informação especí�ca.

• Interface grá�ca simples e intuitiva.

• Possibilidade de implementação de novas funcionalidades.

• Tempo de resposta do sistema o mais curto possível.

37


computadores

3.2 Modelo de classi�cação e valorização de

eventos

Conhecido o problema bem como todas as razões e características que oclassi�cam como tal, neste trabalho foi criado um sistema capaz de valorizare classi�car eventos de segurança de forma a priorizar a análise dos mesmos.

O eventos analisados são oriundos do IDS Snort, por isso optou-se por criarum sistema que opere como uma camada superior deste. O sistema faz arecolha periódica dos eventos gerados pelo Snort e de seguida analisa cadaum dos eventos individualmente, de forma a valoriza-lo com informação decontexto, obtendo assim a respectiva criticidade do mesmo.

No sistema foram implementadas as seguintes funcionalidades:

1. Recolher eventos gerados pelo Snort.

2. Veri�car as vulnerabilidades associadas a cada evento.

3. Relacionar as vulnerabilidades de um evento com as vulnerabilidadesdo sistema a monitorizar (Match de vulnerabilidades).

4. Criar lista de possíveis ataques que cada evento pode representar,tenham eles já ocorrido, ou apenas sejam uma possibilidade.

5. Calcular criticidade de cada evento.

• Calcular perigosidade de cada evento.• Identi�car o tipo de ataque que cada evento possa ter associado.• Reputação do endereço IP de origem de cada evento.

Dado que o Snort é um NIDS, os eventos gerados correspondem à rede a queestá con�gurado para monitorizar.

3.2.1 Vulnerabilidades

A cada evento analisado existe um conjunto de vulnerabilidades associadas.Quando o IDS veri�ca actividade suspeita, gera um evento relativo àmesma, estando normalmente essa actividade associada a uma ou maisvulnerabilidades do sistema computacional. Cada regra do Snort contémos indicadores CVE relativos a cada vulnerabilidade, o que torna mais fácil

38


essa veri�cação.

Contudo essas vulnerabilidades podem ou não estar presentes no sistemacomputacional a monitorizar, o que à partida se traduz num evento de poucaimportância, ou até mesmo inofensivo. Um ataque dirigido a um determinadosistema, que explora uma determinada vulnerabilidade que não se encontrapresente nesse sistema, tem normalmente uma taxa de sucesso reduzida.

Para isso é necessário que o sistema conheça as vulnerabilidades dosistema computacional a monitorizar, de forma a ser possível relacionaras vulnerabilidades associadas a um evento com as vulnerabilidades que seencontram presentes no sistema.

3.2.1.1 Associação de vulnerabilidades

De forma a veri�car as vulnerabilidades do sistema computacional amonitorizar, é necessário recorrer a ferramentas para o efeito. Para o efeitodeste projecto foi utilizado o software Nessus2. Este software efectua umscan a cada host da rede a monitorizar, fazendo correr um conjunto descripts de modo a encontrar problemas de segurança. Estes problemasde segurança podem ser vulnerabilidades do sistema, vulnerabilidades deaplicações instaladas e erros de con�guração. No �nal deste processo o Nessusgera um relatório contendo essa informação.

Com a informação das vulnerabilidades e problemas de segurança do sistemaa monitorizar, é possível veri�car quais vulnerabilidades correspondentes acada evento que estão presentes em cada host da rede.

Esta associação de vulnerabilidades dos eventos e do sistema só é possíveldevido ao facto de os eventos gerados pelo Snort e a informação resultanteso Nessus utilizarem a mesma nomenclatura. Tanto o Snort como o Nessusutilizam a lista CVE para identi�carem as vulnerabilidades.

Através das vulnerabilidades catalogadas na lista CVE é possível aceder àdescrição detalhada de cada vulnerabilidade, bem como saber quando estafoi reportada.

2Software que possibilita veri�car as falhas e as vulnerabilidades de uma rede decomputadores, efectuando um scan para o efeito.

39


computadores

3.2.2 Ataques

De forma a identi�car os ataques que possam estar associados aoseventos de segurança gerados, foi adoptada uma estratégia que consiste nacorrespondência da assinatura do evento com a descrição do ataque. Estacorrespondência é efectuada através de palavras chave contidas na assinaturado evento gerado pelo Snort. Com essas palavras foi possível criar umdicionário, de forma a ser possível associar as mesmas às descrições contidasnas lista CAPEC. Sempre que um ataque tem uma correspondência maior ouigual que 60% é adicionado à lista de ataques do evento em análise. Apesarde tudo esta solução apresenta as suas limitações, sendo estas descritasposteriormente. Dado isto, para cada evento analisado é criada uma listade ataques que podem corresponder ao tipo de anomalia detectada.

3.2.3 Criticidade

No projecto desenvolvido a criticidade consiste na valorização e classi�caçãode um evento, de forma a priorizá-lo em relação aos demais. Para a obtençãoda criticidade de um evento foram de�nidos os seguintes parâmetros: asua perigosidade, se o endereço consta na lista de reputação e pelo tipode ataque mais relevante que este possa representar. Dado que um eventopode corresponder a vários tipos de ataques, o tipo de ataque mais relevanteé aquele que for de�nido inicialmente como tal, através de parâmetros, ondeé efectuado uma priorização dos diferentes tipos de ataques.

Na prática a criticidade de um evento consiste num número de 0 a 100,sendo este calculado em função destas três proposições.

3.2.3.1 Perigosidade

A perigosidade de um evento é um valor numérico que pode variar entre 0e +∞, que consiste num indicador de quão prejudicial pode ser a causa quelevou a geração do evento, independentemente do sistema computacional deonde este foi gerado. Contudo, um evento pode obter um valor elevadona perigosidade, mas pode não representar uma ameaça critica, ou serconsiderado pouco critico no sistema computacional em causa.

O valor da perigosidade é calculado através de informação relativa ásvulnerabilidades e ataques associados ao evento, bem como de informaçãocontida no relatório Nessus.

40


Relativamente ás vulnerabilidades são utilizados os seguinte indicadores,provenientes da lista de vulnerabilidades CVE:

• Status - Indica se a vulnerabilidade em causa já faz parte da lista CVE(Entry) ou se ainda se encontra sobre análise (Draft).

• Age - Ano em que foi reportada a vulnerabilidade.

Relativamente aos ataques são utilizados os seguintes indicadores,provenientes da lista de ataques CAPEC:

• Severity - Severidade do ataque

• Typical Likelihood of Exploit - Di�culdade de realização e/ouconcretização do ataque.

• Attacker Skills or Knowledge Required - Nível (genericamente)de perícia exigida ao atacante.

• CIA Impact - Impacto do ataque relativamente as propriedades decon�dencialidade, integridade e disponibilidade.

Relativamente ao relatório Nessus, os indicadores utilizados para o cálculoda perigosidade são relativos à porta de destino indicada pelo evento, sendoestes:

• Severity - Severidade relativa ao problema encontrado e/ou relativa avulnerabilidades no serviço activo na porta em questão.

• Risk factor - Factor de risco relativa ao problema encontrado e/ourelativo a vulnerabilidades no serviço activo na porta em questão.

Todos os indicadores, à excepção do indicador Age relativo àsvulnerabilidades, são qualitativos e apresentam-se em níveis de Very Low,Low, Medium, High e Very High. Dado que a perigosidade é umindicador numérico, é efectuado um parsing para um valor numéricocorrespondeste:Very Low - 0, Low - 1, Medium - 2, High - 4 e Very High- 5. Em relação ao indicador Age, dado que este representa a idade davulnerabilidade, a operação de transformação é um pouco diferente. Primeiroveri�cou-se qual o ano da vulnerabilidade mais antiga presente na listade vulnerabilidades (CVE). Sempre que usada uma vulnerabilidade com o

41


computadores

mesmo ano dessa essa vulnerabilidade, o indicador Age toma o valor de 0,e para vulnerabilidades seguintes o indicador toma o valor da diferença deidades entre a vulnerabilidade mais antiga e a vulnerabilidade em questão.Esta estratégia foi adoptada devido à proposição que quanto mais recente fora vulnerabilidade, menos informação existe sobre ela, sendo potencialmentemais perigosa em relação a vulnerabilidades mais antigas e bem conhecidas.

Em função de todos estes indicadores, e através de uma da experiêncialaboratorial realizada, a perigosidade de um evento é calculada através daequação (3.1) :

PER = PERvul + PERatt + PERnessus (3.1)

PERvul = Status+ Age (3.2)

PERatt = Severity + TypicalLikelihoodOfExploit+

+AttackerSkillsOrKnowledgeRequired+ CIAimpact(3.3)

PERnessus = Severity +RiskFactor (3.4)

O valor calculado através da equação de perigosidade tem um peso de 40%do calor da criticiade.

3.2.3.2 Tipos de ataque

Um evento de segurança é gerado quando detecta actividade suspeita oualgum tipo de anomalia, ou seja, actividade fora do normal que pode ou nãorepresentar actividade maliciosa. Hoje em dia os vários tipos de actividademaliciosa podem ser caracterizados e identi�cados num tipo especi�co deataque cibernético. Os ataques cibernéticos possuem características muitoespeci�cas, que permitem caracterizar os mesmos quanto ao seu tipo emfunção dos seus efeitos e consequências. Contudo, quando um evento detectaactividade maliciosa, esta pode não ser correspondente apenas a um únicotipo ataque, mas sim a vários tipos.

Existem alguns aspectos comuns em diferentes tipos de ataques, ou seja,quando um evento é gerado, este por vezes não é totalmente especí�co quantoao tipo de malware ou anomalia. Dado que para um ataque cibernético atinjao seu objectivo, é necessário um conjunto de operações, o que faz com queos IDS gerem vários eventos relativos a esse ataque.

42


De forma a priorizar os vários eventos em função do tipo de ataque quelevou à sua geração, é necessário atribuir pesos aos vários tipos de ataque.O peso de cada tipo de ataque é atribuído quando iniciado o sistema, sendoestes introduzidos como parâmetro. Para cada tipo de ataque é introduzidoum valor de 0 a 100%. Na lista de ataques de cada evento é veri�cado qual oataque

Modelo para definição de criticidade em eventos de ...Modelo para de nição de criticidade em...

Documents

Transcript of Modelo para definição de criticidade em eventos de ...Modelo para de nição de criticidade em...

Ministério da Agricultura, Pecuária e Abastecimento BRASIL ... · dos rios brasileiros criticidade quali- ... Área de recarga dos principais sistemas aqÜÍferos do paÍs: ...

Eventos internacionais e Mega eventos

Ventiloconvectores murais UniTrane™ W-Line...Deﬁ nição do modo de funcionamento (apenas ventilador, arrefecimento, aquecimento) XXX Deﬁ nição da hora XXX Programa ligar/desligar,

Módulo de MDM Fila Dashboard Comunicação · CAS HEMERA Dashboard 1.2 1.1 Cadastro de criticidade de eventos Nesse módulo, foi criado um novo cadastro de criticidades de eventos,

GESTÃO DE SOBRESSALENTES - tecem.com.br · A Criticidade de um sobressalente é definida pela criticidade do ativo ao qual pertence. Dessa forma, para os equipamentos cuja criticidade

FORNECIMENTO DE ITENS CR ÍÍÍTICOS E DESENVOLVIMENTO DE ...antigoprominp.petrobras.com.br/objects/files/2008-07/2145_4... · Consorcio de compras Criticidade do Item (Fatores Internos)

Biodiversidade em Unidades de Conservação~d3nehc6yl9qzo4.cloudfront.net/downloads/wwf_biodiversidade_ucs... · ser úteis tanto na gestão das unidades quanto na deﬁ nição de

João André Leitão Morais - repositorium.sdum.uminho.ptrepositorium.sdum.uminho.pt/bitstream/1822/28564/1/Tese_JoãoMorais... · Uma vez definida a Criticidade de cada grupo de

Alimentação de Caprinos · PDF fileipb.jpg De nição comprtamentalo dos caprinos Ciclo de ropdução Necessidades alimentares Alimentação em sistemas de pastoreio Recomendações

TÉCNICAS PARA DINAMINIZAÇÃO DA PASTORAL DO DÍZIMO · capaz de levar a pessoa a produzir alguma coisa. Criticidade óptica Criticidade hermenêutica Criticidade Praxiológica.

DAIKIN ROOM AIR CONDITIONER MANUAL DE OPERAÇÕES · • Para defi nição do modo de funcionamento, consulte a tabela seguinte. Modo Defi nição da temperatura Taxa de fl uxo

uma abordagem quantitativa para a definição da criticidade de ...

Métodos Estatísticos Básicos - regisely.comregisely.com/files/3-stat.pdf · Média aritmética De nição As medidas de tendência central são estatísticas que caracterizam um

eventos - lbcomunica.com · .eventos Planejamos e organizamos eventos corporativos únicos, personalizados e de resultados! Estruturamos, administramos, produzimos e coordenamos eventos

· Web viewExemplos: precisão, clareza, coesão, rapidez, criticidade e complexidade a partir dos quais o desempenho do aluno será avaliado. Para isto, ...

Manual do Fornecedor - 2011portaldofornecedor.sesisc.org.br/documentos/manual_do_fornecedor... · fornecedor dentro dos parâmetros de criticidade estabelecidos de acordo com o grau

Manual de auditoria - tse.jus.br · 5.2 Materialidade, relevância e criticidade ... auditoria consiste em fornecer julgamentos imparciais, com independência e objetividade, contribuindo

Modelo para definição de criticidade em eventos de ...repositorium.sdum.uminho.pt/bitstream/1822/29096/1/tese_Manuel... · DNS Domain Name System DoS Denial of Service FTP File

Virtualização - eduardosan.com · Casos de uso Cluster De nição: Implementação de compartilhamento de recursos computacionais, utilizando dois ou mais dispositivos de computação

Agência EI Eventos Inteligentes - Apresentação Eventos Sustentáveis