Um sistema para gestão do conhecimento em ameaças, vulnerabilidades e seus efeitos

(1)

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE CENTRO DE TECNOLOGIA

PROGRAMA DE P ÓS-GRADUA ¸C ÃO EM ENGENHARIA ELÉTRICA

Um Sistema para Gest˜

ao do Conhecimento em Amea¸cas,

Vulnerabilidades e seus Efeitos

M´ıriam Valen¸ca Massud

(2)

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE CENTRO DE TECNOLOGIA

PROGRAMA DE P ÓS-GRADUA ¸C ÃO EM ENGENHARIA ELÉTRICA

Um Sistema para Gest˜

ao do Conhecimento em Amea¸cas,

Vulnerabilidades e seus Efeitos

M´ıriam Valen¸ca Massud

Orientador: Prof. Dr. Paulo S´ergio da Motta Pires

(3)

M´ıriam Valen¸ca Massud

Um Sistema para Gest˜

ao do Conhecimento em Amea¸cas,

Vulnerabilidades e seus Efeitos

Trabalho submetido ao Programa de Pós-Gradua¸cão em Engenharia Elétrica do Centro de Tecnologia da Universidade Federal do Rio Grande do Norte como requisito parcial para a obten¸cão do grau de Mestre em Ci-ências.

Orientador: Prof. Dr. Paulo S´ergio da Motta Pires.

(4)

Agradecimentos

Aos meus pais, Munir Massud e Gilda Valen¸ca Massud, pelo amor incondicional, pelo incen-tivo e por terem me estimulado a escolher o caminho das ciˆencias genu´ınas, onde s˜ao menores os enganos e maiores as esperan¸cas, minha homenagem e meu amor.

Ao ilustre Professor Doutor Paulo Sérgio da Motta Pires, insigne orientador desta Disserta-¸cão, devoto o meu apre¸co e o agrade¸co pelas luzes dos seus ensinamentos, pela sua extremada paciência e generosa disponibilidade. É certo que o guardarei na memória e no cora¸cão.

Aos queridos amigos Rafael Pereira, Talita Pitanga Santos e Marconi Cˆamara Rodrigues, companheiros nesta jornada, que contribu´ıram direta ou indiretamente para o meu aprendizado cient´ıfico e afetivo, concito-os a participarem comigo deste momento e de todos os outros, se houverem, em honra a amizade que nos une.

(5)

Resumo

Ataques a dispositivos conectados em rede constituem um dos principais problemas relacio-nados à confidencialidade das informa¸cões sens´ıveis e ao correto funcionamento dos sistemas de computa¸cão. Apesar da disponibilidade de ferramentas e de procedimentos que dificultam ou evitam a ocorrência de incidentes de seguran¸ca, dispositivos de rede são atacados com sucesso utilizando-se estratégias aplicadas em eventos anteriores. O desconhecimento dos cenários nos quais esses ataques ocorreram contribui de maneira efetiva para o sucesso de novos ataques. O desenvolvimento de uma ferramenta que disponibilize esse tipo de informa¸cão é, então, de grande relevância.

(6)

Abstract

Attacks to devices connected to networks are one of the main problems related to the con-fidentiality of sensitive data and the correct functioning of computer systems. In spite of the availability of tools and procedures that harden or prevent the occurrence of security incidents, network devices are successfully attacked using strategies applied in previous events. The lack of knowledge about scenarios in which these attacks occurred eﬀectively contributes to the success of new attacks. The development of a tool that makes this kind of information available is, therefore, of great relevance.

(7)

Sum´

ario

1 Introdu¸c˜ao 1

2 O Modelo ADBS 5

2.1 Introdu¸c˜ao . . . 5

2.2 O Banco de Dados . . . 6

2.3 O Sistema de Gerenciamento de Banco de Dados . . . 9

2.4 Opera¸c˜oes no Banco de Dados . . . 11

2.4.1 Adi¸c˜ao de Informa¸c˜oes . . . 11

2.4.2 Recupera¸c˜ao de Informa¸c˜oes . . . 11

3 Taxonomia de Incidentes de Seguran¸ca 14 3.1 Introdu¸c˜ao . . . 14

3.2 Descri¸c˜ao . . . 15

4 Implementa¸c˜ao do Sistema 24 4.1 Introdu¸c˜ao . . . 24

4.2 O Sistema de Banco de Dados . . . 25

4.2.1 Pol´ıtica de Acesso `as Informa¸c˜oes . . . 26

4.2.2 Esquema do Banco de Dados . . . 32

4.2.3 Acesso `as P´aginas do Sistema . . . 34

4.2.4 Funcionalidades . . . 36

4.3 O Assistente ao Especialista . . . 43

5 Estudos de Casos 53 5.1 Vermes . . . 53

5.1.1 Sasser . . . 54

5.1.2 Kelvir . . . 60

(8)

5.2.1 Citibank . . . 65 5.2.2 VISA . . . 71

(9)

Lista de Figuras

2.1 Tabela ATTACK SCENARIO. . . 6

2.2 Tabela ATTACK STEP. . . 7

2.3 Tabela ATTACK COMMENT. . . 8

2.4 Tabela USER. . . 8

2.5 Tabela ACTIVITY LOG. . . 8

2.6 ADBS envia mensagem ao usu´ario. . . 10

2.7 Usu´ario envia mensagem ao ADBS. . . 11

2.8 Etapas da opera¸cão de adi¸cão de informa¸cões no banco de dados ADBS. . . 12

2.9 Etapas da opera¸cão de recupera¸cão de informa¸cões armazenadas no banco de dados ADBS. . . 13

3.1 Eventos de computadores e de redes de computadores. . . 17

3.2 Ataques a computadores e a redes de computadores. . . 19

3.3 Representa¸c˜ao simplificada de um incidente de computador e de rede. . . 21

3.4 Taxonomia de incidentes. . . 23

4.1 Arquitetura do sistema implementado. . . 25

4.2 Usuário com n´ıvel de acesso confidencial (C) insere em Codigos de Ataque uma linha cujo código já havia ocorrido. Há, então, a mútipla instancia¸cão da linha cujo código é 1. . . 28

4.3 Usuário atualiza informa¸cão cuja classifica¸cão é idêntica ao n´ıvel de acesso dele (confidencial - C). A atualiza¸cão ocorre normalmente. Não há poliinstancia¸cão. . 29

4.4 Usuário atualiza informa¸cão cuja classifica¸cão (confidencial - C) é menor que o n´ıvel de acesso dele (secreto - S). A linha é poliinstanciada. . . 29

4.5 Usuário atualiza informa¸cão cuja classifica¸cão (confidencial - C) é menor que o n´ıvel de acesso dele (secreto - S). A linha já poliinstanciada é que é atualizada. . 30

4.6 Algoritmo de atualiza¸c˜ao adotado no sistema de gest˜ao do conhecimento. . . 31

(10)

4.8 Tabela ATTACK STEP do sistema implementado. . . 34

4.9 Tabela USER do sistema implementado. . . 34

4.10 Tabela ACTIVITY LOG do sistema implementado. . . 34

4.11 Opera¸cão de autentica¸cão. (a) Interface que os usuários encontram para acessar o sistema de banco de dados. (b) Interface após o processo de autentica¸cão. . . . 37

4.12 Opera¸cão de consulta de informa¸cões. (a) Formulário para o fornecimento do número do CVE. (b) Informa¸cão exibida ao usuário. . . 38

4.13 Opera¸cão de atualiza¸cão de informa¸cões. (a) Botão de atualiza¸cão. (b) Informa-¸cões para edi¸cão. (c) Mensagem emitida ao usuário informando que a atualiza¸cão foi bem sucedida. . . 39

4.14 Opera¸cão de remo¸cão de informa¸cões. (a) Formulário para a remo¸cão de informa-¸cões. Deve-se fornecer apenas o identificador do ataque. (b) Mensagem emitida ao usuário informando que a remo¸cão foi bem sucedida. . . 40

4.15 Opera¸cão de adi¸cão de usuários. (a) Formulários para preenchimento das infor-ma¸cões sobre o usuário. (b) Mensagem emitida ao usuário caso inser¸cão seja bem sucedida. . . 41

4.16 Opera¸cão de remo¸cão de usuários. (a) A remo¸cão de usuários é feita fornecendo-se apenas o login do usuário. (b) Ao final, é exibida uma mensagem informando ao usuário que a remo¸cão foi bem sucedida. . . 42

4.17 Sintaxe das regras do assistente ao usu´ario implementado. . . 43

4.18 Exemplo de regra. . . 44

4.19 Interface inicial de consulta do assistente ao especialista. . . 46

4.20 Algoritmo para transformar a classifica¸c˜ao da informa¸c˜ao de n´ıvel de atributo em n´ıvel de linha. . . 47

4.21 Interface simulada para ilustrar a execu¸cão do algoritmo de conversão de classi-fica¸cão de informa¸cões de n´ıvel de coluna em n´ıvel de linha. . . 48

4.22 Resultado do segundo e terceiro passos do algoritmo de convers˜ao de informa¸c˜oes de n´ıvel de coluna em n´ıvel de linha. . . 49

4.23 Resultado do quarto passo do algoritmo de convers˜ao de informa¸c˜oes de n´ıvel de coluna em n´ıvel de linha. . . 50

4.24 Resultado do quinto passo do algoritmo de convers˜ao de informa¸c˜oes de n´ıvel de coluna em n´ıvel de linha. . . 51

(11)

5.1 Entrada doevent log relativa a uma falha no processo lsass.exe. . . 55

5.2 Entrada noevent log relativa ao excesso de conex˜oes TCP. . . 56

5.3 Mensagem de erro relacionada ao verme Sasser. . . 57

5.4 Mensagem emitida pelo verme Kelvir. . . 60

5.5 Chaves de registro modificadas pelo verme Kelvir. . . 61

5.6 O URL referenciado pelo link do e-mail ´e modificado. A mensagem de erro exibida no navegador cont´em um URL diferente daquele presente na barra de ferramentas. . . 67

5.7 Embora o URL exibido na barra de ferramentas seja leg´ıtimo do Citibank, a página exibida no navegador é fraudulenta. Uma página apresenta ind´ıcios de conexão segura quando possui a imagem de um cadeado cadeado fechado ou uma chave completa na barra destatus. Não há nenhuma dessas imagens na referida localiza¸cão. . . 68

5.8 E-mail fraudulento no nome da empresa VISA. . . 73

(12)

Cap´ıtulo 1

Introdu¸

c˜

ao

Ataques a dispositivos conectados em rede constituem um dos principais problemas relacio-nados à confidencialidade das informa¸cões sens´ıveis e ao correto funcionamento dos sistemas de computa¸cão. Embora técnicas que evitam a ocorrência de incidentes sejam criadas e constan-temente aperfei¸coadas, diversos sistemas são invadidos utilizando-se estratégias já conhecidas e aplicadas em eventos anteriores. O desconhecimento dos cenários nos quais ocorreram ata-ques bem sucedidos, portanto, contribui de maneira efetiva para o sucesso de novos ataata-ques.

´

E importante, então, que as informa¸cões sobre as estratégias utilizadas pelos atacantes sejam conhecidas e disseminadas para a comunidade de seguran¸ca de uma corpora¸cão.

Este trabalho apresenta um sistema para gestão do conhecimento em amea¸cas, vulnerabili-dades e seus efeitos. Entende-se por amea¸ca uma potencial viola¸cão da seguran¸ca de um sistema [1] e por vulnerabilidade, uma fraqueza que permite a realiza¸cão de uma a¸cão não autorizada [2]. Este sistema armazena poss´ıveis formas de explorar a seguran¸ca do sistema de computa¸cão de uma corpora¸cão utilizando-se determinadas vulnerabilidades. Essas possibilidades de viola-¸cão são advindas de ataques bem sucedidos. Estes ataques representam amea¸cas e devem ser estudados com o objetivo primordial de evitar a ocorrência de ataques semelhantes.

(13)

ent˜ao, ´e armazenado no sistema de banco de dados, que o disponibiliza segundo uma pol´ıtica de acesso.

O acesso a informa¸cões sobre cenários de ataque oferecido por esta ferramenta contribui para a diminui¸cão do tempo de resposta ao incidente ocorrido e para a eleva¸cão do n´ıvel de seguran¸ca dos dispositivos de rede de uma corpora¸cão. Ademais, o sistema, após algum tempo de uso, constitui um acervo de documentos estruturados sobre estratégias de ataque, que pode ser utilizado, por exemplo, para a gera¸cão de relatórios sobre a incidência de ataques na corpora¸cão. Além disso, há a possibilidade desta ferramenta servir de base para o desenvolvimento de um sistema de treinamento na área de seguran¸ca.

´

E importante salientar que este não é um sistema para o armazenamento de vulnerabili-dades, como o CVE [3], Common Vulnerabilities and Exposures, e o OSVDB [4],Open Source Vulnerability Database, por exemplo. O sistema descrito neste trabalho visa armazenar cenários nos quais ataques reais ocorreram e foram bem sucedidos.

O conjunto de a¸cões realizadas pelos atacantes para perfazerem seus objetivos (cenários de ataque) é proveitosa para a identifica¸cão das vulnerabilidades existentes no dispositivo de rede alvo e da(s) estratégia(s) utilizada(s) pelo atacante. A existência de ferramentas que facilitem a reprodu¸cão dessas a¸cões é, então, de grande utilidade. Alguns trabalhos sobre gera¸cão de cenários de ataque foram encontrados na literatura pertinente e são sumariamente comentados nos próximos parágrafos com o objetivo prec´ıpuo de apresentar o estado atual do tema desta disserta¸cão.

NING et al. [5] apresentam uma ferramenta para a gera¸cão de cenários de ataque a partir de correla¸cões de alertas de sistemas de deteçcão de intrusos. A constru¸cão dos cenários de ataque é baseada em hiper-alertas, cada um dos quais constitu´ıdo pela tr´ıadefato,pré-requisito

e conseqüência, que correspondem, respectivamente, à informa¸cão que está sendo reportada no alerta, à condi¸cão primordial para o ataque suceder e ao resultado do ataque. Os pré-requisitos e as conseqüências são representados por predicados. Um ataque A está correlacionado com um ataque B quando pelo menos um dos predicados das conseqüências de A coincide com um dos predicados dos pré-requisitos de B. Além disso, A deve anteceder B. Esta ferramenta, embora constitua uma maneira automática de gera¸cão de cenários de ataque espec´ıficos, está condicionada, por sua própria natureza, a alertas de sistema de deteçcão de intrusos. Assim, a não deteçcão de um estágio (anterior ou posterior) do ataque pode comprometer a gera¸cão correta do cenário correspondente.

(14)

infor-ma¸cões de alertas provenientes de diversos entes de monitoramento, como sistema de deteçcão de intrusos,firewalls, verificadores de integridade de arquivos, entre outros, para fornecer dados em um mesmo n´ıvel de abstra¸cão a uma máquina de correla¸cão. Esta máquina é responsável por processar esses alertas e gerar cenários de ataque.

Há ainda a descri¸cão de uma ferramenta [7] que gera poss´ıveis cenários de ataque a partir de uma configura¸cão de rede e uma pol´ıtica de acesso espec´ıficas, e entradas CVE, que determinam as vulnerabilidades nos dispositivos de rede. Os cenários de ataque são mostrados na forma de grafos direcionados e identificam estratégias que podem ser utilizadas pelo atacante para invadir o sistema.

Conforme já mencionado, o sistema implementado neste trabalho utiliza um assistente ao especialista para a gera¸cão de cenários de ataque espec´ıficos. Diferentemente das ferramentas acima mencionadas, que utilizam informa¸cões provenientes de entes de monitoramento, o as-sistente ao especialista utiliza informa¸cões procedentes de um especialista em seguran¸ca. Estas informa¸cões são extra´ıdas através de uma consulta realizada por intermédio de interface web. Nesta consulta é realizada uma série de perguntas relativas ao incidente ocorrido. No parágrafo subseqüente descreve-se como este trabalho está organizado.

Este trabalho possui seis Cap´ıtulos. No Cap´ıtulo 2, é apresentado o modelo no qual o sistema de banco de dados está baseado. Tal modelo, chamado ADBS [8], Attack Database System, propõe um sistema de banco de dados seguro para disponibilizar, segundo uma pol´ıtica de acesso, cenários nos quais ocorreram ataques bem sucedidos. No ADBS, as informa¸cões possuem classifica¸cões e os usuários possuem n´ıveis de acesso. A disponibilidade de uma informa¸cão é determinada pela compara¸cão entre o n´ıvel de acesso do usuário e a classifica¸cão da informa¸cão que é requisitada. Este modelo dispõe de dois componentes: o banco de dados e o sistema de gerenciamento de banco de dados, SGBD. O banco de dados tem cinco rela¸cões, das quais três armazenam informa¸cões referentes aos cenários de ataque. As demais rela¸cões são utilizadas para registrar as atividades e os dados dos usuários do sistema. O SGBD, por sua vez, é composto por três controladores: controlador de acesso, controlador de seguran¸ca e controlador de dados. As fun¸cões inerentes a cada um desses controladores são descritas no Cap´ıtulo 2.

Para estruturar o conhecimento que o assistente ao especialista possui, adotou-se a taxono-mia de incidentes de seguran¸ca proposta por HOWARD & LONGSTAFF [9]. Esta taxonotaxono-mia, descrita no Cap´ıtulo 3, classifica cada uma das etapas que constituem um incidente de seguran¸ca. Um incidente de seguran¸ca ´e composto pelas etapasatacante,ferramenta,vulnerabilidade,a¸c˜ao,

alvo,resultado n˜ao autorizado e objetivos.

(15)

seus componentes. São também descritos os procedimentos realizados para simular um ambiente multin´ıvel com requisitos de seguran¸ca e as adapta¸cões realizadas nas opera¸cões de consulta, de remo¸cão e de atualiza¸cão para a ado¸cão de uma pol´ıtica de acesso no sistema de banco de dados. A forma de representa¸cão do conhecimento e como esse conhecimento é processado pelo assistente ao especialista são explanados. Adicionalmente, são apresentados as linguagens e os

softwares que foram utilizados na implementa¸c˜ao desses componentes.

No Cap´ıtulo 5, s˜ao apresentados quatro estudos de casos, dois referentes a ataques de

phishing scam e dois a ataques de vermes. Nele é mostrada a seqüência de perguntas reali-zada durante a consulta e as poss´ıveis evidências a partir das quais essas informa¸cões podem ser determinadas ou inferidas. Há também uma análise dos cenários de ataque gerados e do comportamento do sistema quando submetido a testes de valida¸cão.

(16)

Cap´ıtulo 2

O Modelo ADBS

O sistema de banco de dados implementado no protótipo baseia-se na pol´ıtica de acesso e no esquema de tabelas propostos pelo modelo ADBS [8], Attack Database System. Tal mo-delo, descrito neste Cap´ıtulo, propõe um sistema multin´ıvel seguro para o armazenamento e a recupera¸cão de informa¸cões sobre cenários de ataque bem sucedidos.

2.1 Introdu¸

c˜

ao

Conforme mencionado no Cap´ıtulo 1, o modelo ADBS propõe um sistema seguro para o armazenamento e a recupera¸cão de informa¸cões sobre cenários nos quais ocorreram ataques bem sucedidos. Ele possui dois componentes principais: o banco de dados e o sistema de gerenciamento de banco de dados. O banco de dados é composto por cinco rela¸cões, que são utilizadas para o armazenamento de cenários nos quais ocorreram ataques bem sucedidos, o registro das atividades realizadas no sistema e o cadastro de usuários. O SGBD, por sua vez, é constitu´ıdo por três controladores: controlador de acesso, controlador de seguran¸ca e controlador de dados. As fun¸cões inerentes a cada um desses controladores na arquitetura do modelo são descritas posteriormente.

No ADBS, as informa¸cões sens´ıveis possuem classifica¸cões e os usuários possuem n´ıveis de acesso. As informa¸cões podem ser classificadas como FOUO (For Official Use Only), Confi-dential, Secret ou Top Secret. O termo FOUO é usado para referenciar uma informa¸cão sem classifica¸cão, mas que não pode ser usada publicamente. A pol´ıtica de acesso às informa¸cões estabelece que um usuário só acessa informa¸cões cujas classifica¸cões são iguais ou inferiores ao n´ıvel de acesso dele e só escreve informa¸cões que serão vistas por usuários cujos n´ıveis de acesso são iguais ou superiores ao dele.

(17)

ata-ques bem sucedidos devem ser codificadas antes de serem armazenadas. Segundo o modelo de referência, a criptografia de chave simétrica é suficiente. Por outro lado, as informa¸cões trocadas entre o ADBS e o usuário devem ser criptografadas utilizando-se um algoritmo de chave assi-métrica. Este sistema de criptografia é utilizado não somente para garantir a confidencialidade das informa¸cões que trafegam pela rede, mas também como mecanismo de autentica¸cão dos usuários do sistema.

O modelo ADBS propõe disponibilizar cenários de ataque real´ısticos. Informa¸cões dessa natureza não são adequadas para o uso público, pois revelam vulnerabilidades e, até mesmo, informa¸cões confidenciais de um sistema. O acesso ao ADBS, portanto, é restrito.

Neste Cap´ıtulo, a arquitetura do modelo ADBS é apresentada. Na Se¸cão 2.2, descreve-se cada uma das cinco rela¸cões do banco de dados. O SGBD ADBS é mostrado na Se¸cão 2.3. Nela, são atribu´ıdas as fun¸cões inerentes a cada um de seus componentes. Por fim, na Se¸cão 2.4, descreve-se como o sistema procede para realizar as opera¸cões de adi¸cão e recupera¸cão de informa¸cões sobre cenários de ataque.

2.2 O Banco de Dados

O banco de dados do modelo ADBS é composto por cinco rela¸cões. A primeira rela¸cão é a ATTACK SCENARIO. Ela visa fornecer as informa¸cões necessárias para o entendimento do incidente e é apresentada na forma de nove campos explicativos, conforme ilustra a Figura 2.1.

ATTACK SCENARIO Attack ID

Operating System OS Version Date of Attack

Attacker Info Target Category

Ultimate Goal Prerequisites Classification

(18)

Na tabela ATTACK SCENARIO são armazenadas informa¸cões sobre o nome e a versão do sistema operacional vulnerável (Operating System eOS Version, respectivamente). Há também entradas para a data de ocorrência do ataque (Date of Attack), informa¸cões sobre o atacante (Attacker Info) e o tipo de institui¸cão atacada (Target Category), que pode ser um banco ou uma universidade, por exemplo. Além disso, são armazenadas informa¸cões sobre a meta final do atacante ao invadir essa institui¸cão (Ultimate Goal), como, por exemplo, o acesso como super usuário, o roubo de arquivos, a nega¸cão de recursos, entre outros; além das condi¸cões necessárias para a ocorrência do incidente (Prerequisites). Finalmente, há o campo Classification, que armazena a classifica¸cão da informa¸cão. A chave primária da tabela ATTACK SCENARIO é o identificador do ataque (Attack ID).

A segunda tabela do banco de dados ADBS é a ATTACK STEP. Ela visa prover informa¸cões detalhadas sobre as a¸cões individuais que compuseram o ataque (cenário de ataque). Conforme se pode observar na Figura 2.2, a rela¸cão ATTACK STEP possui entradas para a porta e o endere¸co da máquina que foi utilizada pelo atacante (Source Port e Source Addr), assim como o endere¸co do sistema alvo (Dest Addr) e a porta pela qual este foi atacado (Dest Port). Os campos Description, Goal e Classification fornecem, respectivamente, a descri¸cão da a¸cão individual, o objetivo dessa a¸cão e a classifica¸cão da informa¸cão. Há ainda um campo de auto-incremento de números inteiros (Sequence Number), que constitui, juntamente com o campo para armazenamento do identificador do ataque (Attack ID), a chave primária dessa tabela.

ATTACK STEP Attack ID Sequence Number Source Port Source Addr Dest Port Dest Addr Description Goal Classification

Figura 2.2: Tabela ATTACK STEP.

(19)

do incidente. A chave prim´aria da tabela ATTACK COMMENT ´e o identificador do ataque (Attack ID).

ATTACK COMMENT Attack ID

Comments

Figura 2.3: Tabela ATTACK COMMENT.

Todos os campos das tabelas anteriormente descritas podem ser nulos, exceto os correspon-dentes `as chaves prim´arias.

O modelo ADBS também propõe a existência de uma tabela para armazenar informa¸cões relacionadas aos usuários do sistema: USER. Esta tabela, mostrada na Figura 2.4, possui o iden-tificador, a senha, a chave pública e o n´ıvel de acesso do usuário armazenados, respectivamente, nos camposUser ID,password,public keyeclearance. A senha é armazenada criptografada por uma fun¸cão hash-one way. A chave primária da tabela é o identificador do usuário.

USER

User ID password public key

clearance

Figura 2.4: Tabela USER.

A quinta tabela do banco de dados ADBS é a ACTIVITY LOG, utilizada para registrar as atividades dos usuários que acessam o sistema. Ela possui campos para armazenar o número da a¸cão (Action Number), o identificador de usuário (User ID), o tipo da a¸cão (Action Type) e a data de ocorrência desta (Date), conforme se pode observar na Figura 2.5.

ACTIVITY LOG Action Number

User ID Action Type

Date

(20)

Nesta tabela devem ser registradas mudan¸cas em cenários, tempos delogin elogout dos usuários do sistema, entre outros. A tabela ACTIVITY LOG é especialmente útil em situa¸cões de uso inadequado dos registros do sistema. Ela serve como documento para investigar o sucedido e atribuir responsabilidades.

2.3 O Sistema de Gerenciamento de Banco de Dados

O sistema de gerenciamento de banco de dados ADBS é composto por três controladores: controlador de acesso, controlador de seguran¸ca e controlador de dados. As fun¸cões inerentes a cada uma destes controladores nas opera¸cões de consulta e adi¸cão de informa¸cões são explicitadas nos parágrafos subseqüentes.

O controlador de acesso é o principal componente do sistema de gerenciamento de banco dados ADBS. Ele corresponde à interface inicial encontrada pelos usuários que desejam acessar o sistema. Devido à natureza das informa¸cões que o modelo propõe disponibilizar, determina-se que o acesso ao ADBS deve ser restrito. Portanto, para o usuário autenticar-se no sistema, ele deve fornecer o identificador de usuário (UserID) e a senha (password). As senhas dos usuários do sistema são armazenadas criptografadas por uma fun¸cão hash-one way. O controlador de dados, portanto, criptografa automaticamente a senha fornecida para, posteriormente, verificar a legitimidade do usuário que está acessando o sistema. O usuário tem acesso ao sistema apenas se oUserID e a senha coincidirem com as informa¸cões armazenadas nos camposUserID

epassword de alguma linha da tabela USER. Caso o usuário seja autenticado, o controlador de acesso extrai o n´ıvel de acesso do usuário, armazenado no campo Clearance da tabela USER, e o passa como parâmetro, juntamente com o identificador do usuário, para o controlador de seguran¸ca. O usuário não possui mais contato com este componente durante a sessão.

O segundo componente do sistema de gerenciamento de banco de dados ADBS é o contro-lador de seguran¸ca. Ele recebe como parâmetros o identificador e o n´ıvel de acesso do usuário do controlador de acesso e os utiliza, primeiramente, para registrar o acesso do usuário no sis-tema na tabela ACTIVITY LOG. A principal fun¸cão do controlador de seguran¸ca é refor¸car a arquitetura multin´ıvel do modelo, garantindo que os usuários acessem apenas informa¸cões cujas classifica¸cões sejam iguais ou inferiores aos n´ıveis de acesso deles. Outra fun¸cão inerente a este controlador refere-se à prote¸cão das informa¸cões transmitidas entre o usuário e o banco de dados. Utiliza-se um algoritmo de chave pública para codificar e decodificar, respectivamente, as informa¸cões enviadas e recebidas. Nos parágrafos subseqüentes há uma descri¸cão do processo de troca de informa¸cões entre o usuário e o ADBS.

(21)

obtida no campopublic key da tabela USER, e, posteriormente com a chave privada do banco. Para obter as informa¸cões em texto plano, o usuário deve decodificar a mensagem utilizando, respectivamente, a chave pública do ADBS e a chave privada dele. A Figura 2.6 ilustra esse processo.

Figura 2.6: ADBS envia mensagem ao usu´ario.

Para enviar informa¸cões ao banco de dados, o usuário deve criptografar a mensagem com a chave pública do ADBS e, posteriormente, com a chave privada dele. O controlador de seguran¸ca decodifica a mensagem utilizando a chave pública do usuário e a chave privada do ADBS para obter as informa¸cões em texto plano. A Figura 2.7 ilustra esse processo.

O processo de gera¸cão de chaves não é especificado. A chave pública do ADBS é distribu´ıda somente aos seus usuários, enquanto a privada é mantida no sistema. O controlador de seguran¸ca passa o n´ıvel de acesso do usuário e as informa¸cões por ele decodificadas para o controlador de dados.

O controlador de dados constitui o terceiro componente do SGBD ADBS. Ele cria visualiza-¸cões requisitadas pelos usuários e edita as informavisualiza-¸cões provenientes dos usuários em um formato proprietário. O controlador de dados é o único ente que possui acesso direto às informa¸cões armazenadas no banco de dados. Ele atua codificando as informa¸cões que serão armazenadas no banco de dados e decodificando-as em caso de consulta.

´

(22)

Figura 2.7: Usu´ario envia mensagem ao ADBS.

2.4 Opera¸

c˜

oes no Banco de Dados

Nesta Se¸cão são descritas as seqüências de a¸cões realizadas pelos controladores que consti-tuem o SGBD ADBS nas opera¸cões de adi¸cão e recupera¸cão de informa¸cões.

2.4.1 Adi¸c˜ao de Informa¸c˜oes

Para realizar a opera¸cão de adi¸cão, o usuário deve encaminhar as informa¸cões ao banco de dados em arquivos, que podem ser enviados separadamente ou compactados em um único arquivo. Essas informa¸cões devem estar em formato proprietário e devem ser duplamente codi-ficadas. Quando as informa¸cões são recebidas pelo ADBS, elas devem ser decodificadas e, caso necessário, descompactadas pelo controlador de seguran¸ca. As informa¸cões em texto plano, então, são enviadas ao controlador de dados, que decodifica as tabelas relacionadas ao ataque e converte as informa¸cões contidas nos arquivos em linhas dessas tabelas. Como novas informa-¸cões foram inseridas, o controlador de dados atualiza os ´ındices multin´ıveis do sistema. Por fim, os ´ındices e as tabelas relacionadas aos ataques são codificados (algoritmo de chave simétrica) e armazenados no banco de dados. A Figura 2.8 ilustra essa opera¸cão.

2.4.2 Recupera¸c˜ao de Informa¸c˜oes

(23)

informa¸c˜ao e a passa, juntamente com o n´ıvel de acesso do usu´ario, para o controlador de dados.

Figura 2.8: Etapas da opera¸cão de adi¸cão de informa¸cões no banco de dados ADBS.

Ao receber o pedido em texto plano, o controlador de dados decodifica os ´ındices multin´ıveis que possuem classifica¸cão igual ou inferior ao n´ıvel de acesso do usuário que está requisitando a informa¸cão. A partir dos ´ındices decodificados, ele obtém os números de identifica¸cão de registro, RINs - Record Identification Numbers, das linhas que satisfazem os parâmetros do pedido. O controlador de dados, então, decodifica as informa¸cões das linhas correspondentes aos RINs selecionados na busca e as utiliza para criar uma visão. A classifica¸cão da visão é idêntica à maior classifica¸cão das informa¸cões que foram inclusas nela. A visão, então, é encaminhada ao controlador de seguran¸ca.

(24)

Figura 2.9: Etapas da opera¸cão de recupera¸cão de informa¸cões armazenadas no banco de dados ADBS.

(25)

Cap´ıtulo 3

Taxonomia de Incidentes de

Seguran¸

ca

O assistente ao especialista implementado possui a fun¸cão de facilitar a composi¸cão de cenários de ataque e informa¸cões relacionadas. Para cada tipo de ataque existe um conjunto de perguntas que visam extrair do especialista em seguran¸ca o conhecimento que ele possui sobre o incidente ocorrido. A união de todos estes conjuntos compreende a base de conhecimento. Com o intuito de estruturar o conhecimento do assistente ao especialista, adotou-se a taxonomia de incidentes de seguran¸ca proposta por HOWARD & LONGSTAFF [9]. Tal taxonomia é descrita neste Cap´ıtulo.

3.1 Introdu¸

c˜

ao

Taxonomia consiste em uma ciência de classifica¸cão [10] e, segundo AMOROSO [11], para que ela seja satisfatória, deve ser:

• mutuamente exclusiva: a classifica¸cão em uma categoria exclui todas as outras; • exaustiva ou completa: a jun¸cão de todas as categorias inclui todas as possibilidades; • não amb´ıgua: clara e precisa de modo que a descri¸cão de cada categoria não gere incertezas

na classifica¸c˜ao;

• repet´ıvel: classifica¸c˜oes repetidas devem gerar os mesmos resultados;

• aceitável: lógica e intuitiva de modo que suas categorias tenham aprova¸cão generalizada; • usável: as categorias devem ser intelig´ıveis - os termos utilizados devem ser compreens´ıveis;

(26)

Segundo HOWARD & LONGSTAFF [9], uma taxonomia é uma aproxima¸cão da realidade e, por isso, deve-se esperar que uma taxonomia satisfatória falhe em alguns desses requisitos. Esse pode ser particularmente o caso em que as caracter´ısticas dos dados a serem classificados sejam imprecisas e incertas, como é o caso da informa¸cão t´ıpica de seguran¸ca de computador. No entanto, a classifica¸cão é um pré-requisito importante e necessário para um estudo sistemático.

3.2 Descri¸

c˜

ao

Um evento, do ponto de vista de computador e de rede de computadores, consiste em uma a¸cão direcionada a um alvo que possui o objetivo de causar uma mudan¸ca no estado do mesmo. A ocorrência de um evento não implica necessariamente na modifica¸cão do estado do sistema alvo. Uma tentativa de acesso sem êxito a uma conta, por exemplo, é um evento. Neste caso, a a¸cão é a de autentica¸cão e o alvo, a conta.

Uma a¸cão pode ser direcionada a uma entidade lógica (conta, processo ou dado) ou a uma entidade f´ısica (componente, rede ou inter-rede). Os poss´ıveis alvos de uma a¸cão são descritos nos próximos parágrafos.

• Conta: consiste no dom´ınio de acesso do usuário em um computador ou em uma rede que é controlado de acordo com um registro de informa¸cão [9]. Este registro contém o nome da conta do usuário, a senha dele e as restri¸cões de uso.

• Processo: é um programa em execu¸cão. Ele é constitu´ıdo por um programa executável, os dados e a pilha do programa, o seu contador de programa, o ponteiro de pilha e outros registros, e todas as outras informa¸cões necessárias para se executar um programa [12]. • Dados: são representa¸cões de fatos, conceitos ou instru¸cões em uma maneira conveniente

para a comunica¸cão, interpreta¸cão ou processamento por humanos ou por meios automá-ticos [12]. Os dados podem se apresentar na forma de arquivos em uma memória volátil ou não volátil, em um equipamento de armazenamento de dados ou em trânsito através de um meio de transmissão [9].

• Componente: ´e uma das partes que comp˜oe um computador ou uma rede [12].

(27)

• Rede: consiste em um grupo interconectado ou interelacionado de computadores, elemen-tos de liga¸c˜ao e ramos de interconex˜ao [12].

• Inter-rede: consiste em uma rede de redes [9].

Diversas a¸cões podem ser direcionadas a cada um dos alvos anteriormente mencionados. As a¸cões que podem ser direcionadas aos dados são as de leitura, cópia, modifica¸cão, roubo ou remo¸cão; a um processo, as de probe, scan, autentica¸cão, bypass e flood; a uma conta, a de autentica¸cão; entre outras poss´ıveis combina¸cões. Em seguida são descritas as a¸cões que podem ser direcionadas aos alvos anteriormente descritos.

• Probe: consiste em uma a¸c˜ao utilizada para determinar as caracter´ısticas de um alvo espec´ıfico.

• Scan: consiste em uma a¸cão na qual um usuário ou processo acessa uma ordem de alvos seqüencialmente para determinar aqueles que possuem caracter´ısticas particulares. • Flood: consiste em acessar o alvo repetidamente para sobrecarregar a capacidade dele. • Autentica¸cão: é uma a¸cão realizada pelo usuário para assumir uma identidade. Ela se

inicia quando um usuário acessa um processo de autentica¸cão, que requer uma identifica¸cão [9]. Uma autentica¸cão pode ser requerida não somente para o acesso a um sistema, mas também para o acesso a objetos do sistema, a execu¸cão de processos, entre outros. • Bypass: consiste em uma a¸cão realizada para evitar um processo usando um método

al-ternativo para acessar o alvo [9]. Alguns sistemas operacionais possuem vulnerabilidades que podem ser exploradas por atacantes para acessar contas sem a necessidade de forne-cimento de uma combina¸cão válida de identificador e senha ao processo de autentica¸cão. Esta a¸cão é debypass, já que ela utiliza um método alternativo para acessar o alvo. • Spoof: consiste em uma a¸cão na qual uma máquina da rede assume a identidade de

outra. Falsificando-se o endere¸co IP de origem de um pacote, o atacante pode injetar ou modificar dados que trafegam em um canal de comunica¸c˜ao, redirecionar respostas de conex˜oes, entre outros.

• Leitura: ocorre quando o atacante obt´em dados de um arquivo ou de outro meio de armazenamento de dados.

(28)

• Roubo: a concep¸cão de roubo de arquivos pode ser feita por analogia ao roubo de bens f´ısicos. No roubo de um carro, por exemplo, o ladrão obtém o carro e o proprietário do ve´ıculo, sem carro, é privado de seu uso. Em rela¸cão a dados, isso significa que o atacante obtém uma cópia dos dados e, em seguida, os remove do sistema alvo, tornando-os indispon´ıveis ao proprietário e aos usuários cujo acesso era permitido.

• Modifica¸cão: ocorre quando o atacante altera dados do sistema alvo, seja pela adi¸cão, remo¸cão ou substitui¸cão de informa¸cões.

• Remo¸c˜ao: ocorre quando dados s˜ao apagados do sistema alvo.

A Figura 3.1 [9] ilustra uma matriz de a¸cões e alvos. Ela representa poss´ıveis eventos de computadores e de redes de computadores. Pode-se observar que nem todas as combina¸cões de a¸cões e alvos são poss´ıveis. A combina¸cão debypass e dados, por exemplo, é inadmiss´ıvel.

(29)

Vale salientar que não se pode definir um conjunto de a¸cões autorizadas e não autorizadas. Uma a¸cão que pode ser autorizada em um sistema pode ser não autorizada em outro. Segundo HOWARD & LONGSTAFF [9], a¸cões usualmente vistas de maneira hostil, como tentativas de fraudar processos de controle de acesso para acessar uma conta privilegiada (bypass), podem ser autorizadas em circunstâncias especiais. Os administradores de seguran¸ca, portanto, são quem determinam as a¸cões autorizadas estabelecendo uma pol´ıtica de seguran¸ca para seus sistemas. A etapa de a¸cão, portanto, engloba a¸cões autorizadas e não autorizadas.

• autorizado: aprovado pelo propriet´ario ou administrador [9].

• não autorizado: não aprovado pelo proprietário ou administrador [9].

Um ataque constitui uma série de passos realizados pelo atacante para alcan¸car um resul-tado não autorizado. Ele envolve o uso de uma ferramenta para explorar uma vulnerabilidade existente no sistema alvo e visa obter um resultado que não é permitido, do ponto de vista do sistema alvo, para o atacante. A Figura 3.2 [9] ilustra as etapas de um ataque: ferramenta,

vulnerabilidade, a¸cão, alvo e resultado não autorizado. Nela pode-se observar que um ataque engloba uma a¸cão direcionada ao alvo (evento). As etapas de um ataque não explicitadas até o presente momento são descritas nos parágrafos subseqüentes.

Ferramentas são o primeiro passo da seqüência realizada em um ataque. Elas são um meio de explorar uma vulnerabilidade de um computador ou de uma rede e objetivam conduzir o sistema alvo a um resultado não autorizado. As ferramentas são categorizadas conforme a seguir.

• Ataque f´ısico: ocorre quando um computador, rede, componentes de computador ou de rede, ou sistemas de suporte à eles (como ar condicionado, potencia elétrica, etc.) são roubados ou danificados.

• Troca de informa¸cão: consiste em um meio de obter informa¸cão de outros atacantes ou de outras pessoas que possuam algum conhecimento sobre o sistema alvo (engenharia social). • Comando de usuário: conforme o próprio nome sugere, essa categoria refere-se aos coman-dos que o atacante digita em uma interface gráfica ou de linha de comando para realizar o ataque.

• Script ou programa: consiste em um meio de explorar uma vulnerabilidade através da execu¸cão de um arquivo de comandos (script) ou de um programa em interface de processo. • Agente autônomo: consiste em um meio de explorar uma vulnerabilidade utilizando um

(30)

Figura 3.2: Ataques a computadores e a redes de computadores.

(31)

• Toolkit: é um pacote de software que contém scripts, programas ou agentes autônomos, que exploram vulnerabilidades.

• Ferramenta distribu´ıda: consiste em uma ferramenta que pode ser distribu´ıda em m´ultiplos

hosts. Estas ferramentas, quando coordenadas, podem efetuar ataques contra um alvo ap´os um determinado tempo de espera.

• Data Tap: consiste em um meio de monitorar a radia¸c˜ao eletromagn´etica que emana de um computador ou de uma rede usando um equipamento externo.

Conforme se pode observar, com exce¸cão de ataque f´ısico, troca de informa¸cão edata tap, as categorias descritas anteriormente podem englobar as demais. Esse fato não satisfaz o requisito de exclusão mútua de uma taxonomia satisfatória. Porém, se duas ou mais ferramentas forem utilizadas em um ataque, a categoria escolhida é aquela que engloba a ferramenta mais complexa. Comandos de usuário, por exemplo, são usados para iniciar programas. A categoria que deve ser escolhida é a descript ou programa, já que ela é mais complexa que a de comando de usuário. Segundo HOWARD & LONGSTAFF [9], a obediência a essa regra torna as categorias acima mencionadas mutuamente exclusivas na prática.

Vulnerabilidade, segundo KRSUL [2], é uma fraqueza no sistema que permite a realiza¸cão de uma a¸cão não autorizada. Ela pode ser originária de diferentes estágios: projeto, implementa¸cão ou configura¸cão, descritos a seguir.

• Vulnerabilidade de projeto: vulnerabilidade herdada do projeto ou da especifica¸c˜ao de um

hardware ousoftware.

• Vulnerabilidade de implementa¸cão: vulnerabilidade ocasionada por um erro de implemen-ta¸cão de um software ou hardware, ambos com projeto satisfatórios.

• Vulnerabilidade de configura¸c˜ao: vulnerabilidade resultante de um erro de configura¸c˜ao do sistema.

Dentre as vulnerabilidades anteriormente descritas, a mais grave ´e aquela ocasionada por um erro de projeto, pois, devido ao projeto ser o primeiro est´agio de desenvolvimento de um

(32)

• Crescimento de acesso: crescimento n˜ao autorizado do dom´ınio de acesso em um compu-tador ou rede [9].

• Descoberta de informa¸cão: dissemina¸cão da informa¸cão para qualquer pessoa que não esteja autorizada a acessá-la [13].

• Corrup¸cão da informa¸cão: qualquer altera¸cão não autorizada dos arquivos armazenados em um computador ou dos dados em trânsito pela rede [11].

• Nega¸c˜ao de servi¸co: degrada¸c˜ao intencional ou bloqueio de recursos do computador ou da rede [14].

• Roubo de recursos: uso n˜ao autorizado de recursos de um computador ou de uma rede [9].

Um incidente consiste em um conjunto de ataques relacionados. Ele é constitu´ıdo por um atacante, um ou mais ataques, e objetivos, conforme ilustra a Figura 3.3 [9]. Um atacante é um indiv´ıduo que ataca uma ou mais vezes o sistema alvo para alcan¸car um objetivo. Objetivo(s) é (são) o(s) propósito(s) ou meta(s) final(is) do atacante.

Figura 3.3: Representa¸c˜ao simplificada de um incidente de computador e de rede.

Atacantes são as fontes de ataques a computadores e a redes de computadores. Eles são classificados segundo o critério de quem eles são e quais seus os objetivos ou motiva¸cões, conforme é mostrado em seguida.

• Hackers: invadem computadores principalmente pelo desafio estatus de obterem o acesso. • Espi˜oes: atacantes que invadem computadores principalmente para obterem informa¸c˜oes

que podem ser usadas para ganho pol´ıtico.

• Terroristas: atacantes que invadem computadores principalmente para causarem medo, que ajudar´a no ganho pol´ıtico.

(33)

• Criminosos profissionais: atacantes que invadem computadores para obterem ganho finan-ceiro pessoal.

• Vˆandalos: atacantes que invadem computadores para causarem preju´ızos.

• Voyeur: atacantes que invadem computadores com o objetivo de obter informa¸c˜oes sens´ı-veis.

Finalmente, a taxonomia de incidentes proposta por HOWARD & LONGSTAFF [9] ´e ilus-trada na Figura 3.4.

(34)

Figura 3.4: Taxonomia de incidentes.

(35)

Cap´ıtulo 4

Implementa¸

c˜

ao do Sistema

Neste Cap´ıtulo é mostrada a arquitetura do sistema de gestão do conhecimento. As fun¸cões inerentes a cada um de seus componentes e os procedimentos realizados para implementa-los são apresentados. Conforme já mencionado, o sistema de banco de dados está baseado na pol´ıtica de acesso e no esquema de tabelas propostos pelo modelo ADBS, descrito no Cap´ıtulo 2, e o assistente ao especialista possui seu conhecimento estruturado segundo a taxonomia de incidentes de seguran¸ca descrita no Cap´ıtulo 3.

4.1 Introdu¸

c˜

ao

O sistema de apoio à gestão de seguran¸ca corporativa possui dois componentes: um sistema de banco de dados e um assistente ao especialista. O primeiro componente, o sistema de banco de dados, possui a fun¸cão de prover um sistema com requisitos de seguran¸ca para o armaze-namento e a recupera¸cão de cenários de ataque e informa¸cões relacionadas. A necessidade de implementa¸cão de requisitos de seguran¸ca nesse sistema é advinda da natureza das informa¸cões que ele propõe disponibilizar. Cenários de ataque revelam, além da estratégia utilizada pelo atacante, vulnerabilidades existentes nos dispositivos de rede de uma corpora¸cão. É notório que essas informa¸cões não devem ser de uso público. É importante, então, que o acesso a elas seja feito de forma controlada. O segundo componente, o assistente ao especialista, consiste em uma forma automatizada de extrair o conhecimento que o especialista em seguran¸ca possui sobre o incidente ocorrido. Ele abstrai do usuário a necessidade do conhecimento das tabelas do banco de dados relacionadas aos incidentes de seguran¸ca para a gera¸cão do cenário de ataque espec´ıfico.

(36)

por interfaces web e arquivos texto, e interfaces web e banco de dados. Através das interfaces web do assistente ao especialista é que realiza-se consultas para a constru¸cão dos cenários. O conhecimento sobre ataques são armazenados em arquivos texto. Para realizar uma consulta, uma das interfaces deste componente lê as perguntas do arquivo texto correspondente ao tipo de ataque especificado. Nessas interfaces também são processadas as informa¸cões fornecidas pelo usuário para gera¸cão do cenário correspondente ao incidente ocorrido. Nas interfaces web do sistema de banco de dados estão implementados a pol´ıtica de acesso, os requisitos de seguran¸ca para evitar o acesso não autorizado às informa¸cões sens´ıveis e as opera¸cões de adi¸cão e remo¸cão de informa¸cões e de usuários do sistema. Novamente na Figura 4.1, pode-se observar que as interfaces web do assistente ao especialista se comunicam com o banco de dados através da linguagem SQL, Structured Query Language. A interface do assistente ao especialista após o processo de autentica¸cão pode ser acessada através de interface do sistema de banco de dados e a interface do sistema de banco de dados após o processo de autentica¸cão pode ser acessada através de interface do sistema especialista. Detalhes inerentes a cada um dos componentes do sistema implementado são apresentados nas Se¸cões subseqüentes.

Figura 4.1: Arquitetura do sistema implementado.

4.2 O Sistema de Banco de Dados

(37)

adds-lashes [15] é usada para evitar ataques de SQL Injection. Este ataque ocorre submetendo-se uma string maliciosa ao banco de dados para conseguir, por exemplo, acesso a um sistema. A criptografia da senha dos usuários, por sua vez, é realizada pela fun¸cão crypt [16], que codifica

strings utilizando um algoritmohash-one way. O mecanismo de sessão é usado para evitar que usuários não autenticados possuam acesso ao sistema. A sessão armazena o n´ıvel de acesso do usuário, que é utilizado para controlar o acesso às informa¸cões sens´ıveis.

A comunica¸cão cliente-servidor é protegida pelo SSL, Secure Sockets Layer. O SSL é um protocolo da camada de aplica¸cão que estabelece canais de comunica¸cão seguros entre cliente e servidor utilizando algoritmos de chaves simétrica e assimétrica.

O SGBD que está sendo utilizado é o PostgreSQL, pois, além de ser um software livre, ele oferece recursos intr´ınsecos de seguran¸ca como o suporte a transa¸cões, que contribui de maneira efetiva para consistência e integridade das informa¸cões armazenadas no banco de dados. A linguagem utilizada para comunica¸cão com o banco de dados é a SQL.

Por projeto, todos os códigos são executados no servidor. Esse fato é importante para a seguran¸ca do sistema, uma vez que as chaves e fun¸cões de criptografia dos cenários de ataque e das senhas dos usuários do sistema se encontram nesses códigos.

4.2.1 Pol´ıtica de Acesso `as Informa¸c˜oes

A pol´ıtica de acesso às informa¸cões é idêntica àquela adotada pelo modelo ADBS. Essa pol´ıtica resulta da agrega¸cão de duas propriedades do modelo de Bell-La Padula, comumente referenciadas comono read up (propriedadesimple security - um usuário só acessa informa¸cões com classifica¸cões iguais ou inferiores ao n´ıvel de acesso dele) e no write down (propriedade * -um usuário só escreve informa¸cões que serão vistas por usuários com n´ıveis de acesso iguais ou superiores ao dele). Os procedimentos utilizados para evitar a viola¸cão dessa pol´ıtica de acesso são apresentados nos próximos parágrafos.

Opera¸cões que modificam a base de dados devem preservar a pol´ıtica de acesso às informa-¸cões. Em decorrência disso, convencionou-se que um usuário só insere e remove informa¸cões cujas classifica¸cões são idênticas ao n´ıvel de acesso dele. A opera¸cão de atualiza¸cão envolve a expansão das chaves primárias das tabelas que armazenam informa¸cões sens´ıveis e a ado¸cão de um algoritmo. Os motivos para a realiza¸cão desses procedimentos são explicitados a seguir.

(38)

posteriormente atualizada por um outro usuário cujo n´ıvel de acesso é superior. A classifica¸cão final da informa¸cão é idêntica ao n´ıvel de acesso do usuário que a atualizou. A informa¸cão inserida pelo primeiro usuário, portanto, se torna indispon´ıvel para ele mesmo. O segundo caso ocorre quando um usuário insere uma informa¸cão com uma determinada chave primária e outro, com n´ıvel de acesso inferior, tenta inserir uma informa¸cão com essa mesma chave. Do ponto de vista do segundo usuário, o sistema apresenta um comportamento inconsistente, na medida em que ele não pode inserir uma informa¸cão que, para ele, não consta no banco de dados. Para evitar situa¸cões dessa natureza, expandiu-se a chave primária das tabelas nas quais as informa¸cões possuem classifica¸cão, que são aquelas que armazenam cenários de ataque e informa¸cões relacionadas, e implementou-se um algoritmo de atualiza¸cão adequado.

A expansão da chave primária ocorre adicionando-se a classifica¸cão da informa¸cão ao menor conjunto de atributos que identificam uma linha em uma rela¸cão. Uma rela¸cão multin´ıvel é aquela na qual as informa¸cões possuem classifica¸cão. Em uma rela¸cão multin´ıvel, o menor conjunto de atributos que identificam uma linha é chamado chave aparente. Ainda neste tipo de rela¸cão, a união da chave aparente com a classifica¸cão da informa¸cão é denominada chave primária. Na Figura 4.2, o código (Codigo) é a chave aparente da tabela Codigos de Ataque. A chave primária da rela¸cão multin´ıvel, portanto, consiste na união do atributo Codigo com a classifica¸cão da informa¸cão (Classificacao). Nesta mesma Figura pode-se observar que o usuário confidencial (C) só inseriu uma linha com código idêntico ao daquela já existente porque a chave primária da tabela foi expandida. O usuário confidencial não visualiza a informa¸cão secreta (S), uma vez que esta possui classifica¸cão superior ao n´ıvel de acesso dele. A expansão da chave primária ocasiona poliinstancia¸cão, definida em seqüência.

A poliinstancia¸cão, idéia primeiramente abordada pelo projeto SeaView [17], consiste em múltiplas instancia¸cões de linhas que possuem a mesma chave aparente. Na Figura 4.2, pode-se observar que, após a inser¸cão da informa¸cão, ocorreu a poliinstancia¸cão.

O algoritmo de atualiza¸cão implementado é uma adapta¸cão de um algoritmo de atualiza¸cão de informa¸cões descrito em JAJODIA & SANDHU [17]. Ele prevê dois casos de estudo: o usuário atualiza uma informa¸cão com classifica¸cão igual ao n´ıvel de acesso dele e o usuário atualiza uma informa¸cão com classifica¸cão inferior ao n´ıvel de acesso dele. Este último caso envolve dois subcasos, que serão mostrados a seguir. Em concordância com a pol´ıtica de acesso adotada, não existe situa¸cão na qual o usuário atualiza uma informa¸cão com classifica¸cão superior ao n´ıvel de acesso dele.

(39)

Codigos de Ataque

Codigo T ipo Ataque Risco Classif icacao

1 Buﬀer Overflow Severo S

INSERT INTO Codigos de Ataque (Codigo, Tipo Ataque, Risco) VALUES (‘1’, ‘Nega¸c˜ao de Servi¸co’, ‘Severo’);

↓

Codigos de Ataque

1 Nega¸c˜ao de Servi¸co Severo C

Figura 4.2: Usuário com n´ıvel de acesso confidencial (C) insere em Codigos de Ataque uma linha cujo código já havia ocorrido. Há, então, a mútipla instancia¸cão da linha cujo código é 1.

informa¸cão com classifica¸cão inferior ao n´ıvel de acesso do usuário que está realizando a opera¸cão não sucede de forma habitual, pois, conforme mencionado, isso resultaria na indisponibilidade da informa¸cão. A solu¸cão provida pelo algoritmo de atualiza¸cão para esse caso é manter a linha com classifica¸cão inferior inalterada e inserir uma nova linha com classifica¸cão idêntica ao n´ıvel de acesso do usuário. Essa linha herda as informa¸cões daquela de classifica¸cão inferior, exceto aquelas que foram atualizadas pelo pedido. A Figura 4.4 ilustra essa situa¸cão.

(40)

Codigos de Ataque

UPDATE Codigos de Ataque SET Tipo Ataque=‘Buﬀer Overflow’;

↓

Codigos de Ataque

1 Buﬀer Overflow Severo C

Figura 4.3: Usuário atualiza informa¸cão cuja classifica¸cão é idêntica ao n´ıvel de acesso dele (confidencial - C). A atualiza¸cão ocorre normalmente. Não há poliinstancia¸cão.

Codigos de Ataque

UPDATE Codigos de Ataque SET Tipo Ataque=‘Buﬀer Overflow’;

↓

Codigos de Ataque

(41)

Codigos de Ataque

1 Nega¸c˜ao de Servi¸co Mediano C

1 Roubo de Arquivos Severo S

UPDATE Codigos de Ataque SET Tipo Ataque=‘Buﬀer Overflow’ WHERE Tipo Ataque=‘Nega¸c˜ao de Servi¸co’;

↓

Codigos de Ataque

1 Nega¸c˜ao de Servi¸co Mediano C

Figura 4.5: Usuário atualiza informa¸cão cuja classifica¸cão (confidencial - C) é menor que o n´ıvel de acesso dele (secreto - S). A linha já poliinstanciada é que é atualizada.

(42)

Seja t a linha que está sendo atualizada e c o n´ıvel de acesso do usuário que está realizando a modifica¸cão:

Passo 1. Se a classifica¸cão de t é igual ao n´ıvel de acesso do usuário, então a atualiza¸cão o-corre normalmente.

Passo 2. Se a classifica¸cão de t é menor que o n´ıvel de acesso do usuário que está atualizan-do a informa¸cão, então há dois subcasos:

a. t n˜ao foi poliinstanciada no n´ıvel c.

Deve-se adicionar uma linha com mesma chave primária e classifica¸cão c através da seguinte regra:

- Os parâmetros que não fazem parte da cláusula SET são herdados da linha t.

- Os demais parˆametros s˜ao atualizados com o valor determinado no pedido. b. t foi poliinstanciada no n´ıvel c.

A linha que deve ser atualizada é aquela que está poliinstanciada no n´ıvel c, através da seguinte regra:

- Os parâmetros que não fazem parte da cláusula SET são mantidos.

- Os demais parˆametros s˜ao atualizados com o valor determinado no pedido.

(43)

4.2.2 Esquema do Banco de Dados

Modifica¸cões foram efetuadas no esquema de tabelas proposto do modelo ADBS. Estas modifica¸cões são mostradas nos parágrafos subseqüentes.

Primeiramente foram acrescidos os seguintes campos `a tabela ATTACK SCENARIO (Figura 2.1, Cap´ıtulo 2):

• titulo: armazena o t´ıtulo do ataque, que deve identificar, de forma sucinta, o dispositivo de rede alvo, a causa e a principal conseqüência do ataque. O t´ıtulo “Vulnerabilidade no LSASS do Windows XP permite acesso como super usuário no dispositivo de rede 192.168.0.2”, por exemplo, esclarece a causa: vulnerabilidade no LSASS, Local Security Authority System Service, do Windows XP; a principal conseqüência do ataque: acesso como super usuário; e o dispositvo de rede alvo: 192.168.0.2. Ao ler esse t´ıtulo o usuário terá ciência de que o cenário de ataque revela como uma vulnerabilidade no LSASS do Windows XP do dispositivo de rede 192.168.0.2 foi explorada para obter privilégio de super usuário.

• solucao: contém as solu¸cões ou medidas paliativas para a vulnerabilidade revelada pelo cenário de ataque.

• prevencao: armazena as formas de prevenir que um sistema seja atacado explorando-se a vulnerabilidade em quest˜ao.

• doc rel: armazena nomes de documentos ou endere¸cos de sites que reportam informa-¸c˜oes sobre a vulnerabilidade do incidente de seguran¸ca. Este campo visa relacionar as informa¸c˜oes do banco de dados com aquelas dispon´ıveis na Internet.

• data pub: armazena a data em que a informa¸cão foi inserida no banco de dados. • ult mod: armazena data de última modifica¸cão da informa¸cão.

(44)

do modelo ADBS que permaneceram nas demais tabelas também foram traduzidos para o por-tuguês. Conforme já mencionado, adicionou-se a classifica¸cão da informa¸cão à chave primária das tabelas ATTACK SCENARIO, ATTACK STEP e ATTACK COMMENT.

ATTACK SCENARIO ID ataque sce

titulo software vulneravel versao software data info atac categ alvo impacto prerequisitos solucao prevencao doc rel data pub ult mod class sce

Figura 4.7: Tabela ATTACK SCENARIO do sistema implementado.

Na tabela ATTACK STEP (Figura 2.2, Cap´ıtulo 2), o campo que armazenava o número de seqüência foi substitu´ıdo por um campo para armazenar o número da a¸cão no cenário de ataque (passo). Essa substitui¸cão foi necessária para que se atualizasse corretamente cada passo dos cenários. A Figura 4.8 ilustra a tabela ATTACK STEP do sistema implementado. O campo “class step” armazena a classifica¸cão da informa¸cão e é equivalente ao campo Classification do

ADBS.

Na tabela USER (Figura 2.4, Cap´ıtulo 2), o campo para a chave púbica do usuário ( pu-blic key) foi removido, pois tornou-se desnecessário. A Figura 4.9 ilustra a tabela USER do sistema implementado.

Outra tabela modificada foi a ACTIVITY LOG (Figura 2.5, Cap´ıtulo 2). Nela, os seguintes campos foram adicionados:

• hora: armazena a hora que uma determinada a¸c˜ao foi executada pelo usu´ario;

(45)

ATTACK STEP

passo ID ataque step

end orig end dest port orig port dest descri impacto class step

Figura 4.8: Tabela ATTACK STEP do sistema implementado. USER

ID usuario senha nivelacesso

Figura 4.9: Tabela USER do sistema implementado.

A Figura 4.10 ilustra a tabela ACTIVITY LOG do sistema implementado. O campo “se-quencia”corresponde ao campo “Action Number”do modelo ADBS.

ACTIVITY LOG sequencia ID usuario tipo acao

hora data IP

Figura 4.10: Tabela ACTIVITY LOG do sistema implementado.

4.2.3 Acesso `as P´aginas do Sistema

(46)

Quando uma sessão é iniciada, um identificador de sessão, formado por 32 d´ıgitos hexade-cimais, é gerado aleatoriamente e enviado através de cookies para o navegador do cliente. No servidor, há a cria¸cão de um arquivo vazio, cujo nome é constitu´ıdo pelastring sess seguida do identificador de sessão. Este arquivo armazena as variáveis registradas na sessão. Caso a sessão já exista, o identificador de sessão é extra´ıdo do navegador e utilizado para localizar o arquivo correspondente no servidor.

Uma maneira de roubar sessões consiste em capturar o número de uma sessão válida e arma-zenar em uma variável do navegador. Quando a página restrita for acessada, o servidor extrairá o número da sessão armazenado no navegador do cliente, que é válido, e então disponibilizará a página solicitada. Uma forma de se obter um número de sessão válido é executando um programa em PHP no mesmo servidor do site que se deseja roubar a sessão. Pode-se, primei-ramente, executar o código<? phpinfo(); ?>para descobrir onde os arquivos de sessões estão armazenados. Em seguida, deve-se executar um programa para abrir e ler o diretório encontrado no passo anterior. Os identificadores de sessão correspondem aos caracteres hexadecimais do nome do arquivo após a string sess .

Conforme já mencionado, implementou-se no sistema um esquema de chaves para evitar roubo de sessões. Este esquema é detalhado nos parágrafos subseqüentes.

Primeiramente, uma chave secreta, também chamada de chave privada, é inicializada no pro-grama. A partir dela é criada uma chave pública, utilizada para validar as sessões estabelecidas. A chave pública é própria de cada sessão. Ela é obtida, primeiramente, concatenando-se ologin

do usuário ($temp login), a chave secreta ($CHAVE SECRETA), o endere¸co IP da máquina que o usuário está utilizando para acessar o sistema ($ip) e o instante, em segundos, em que a página foi acessada ($hora). A chave pública é o md5 da string obtida no passo anterior. A fun¸cão md5 pode ser substitu´ıda por qualquer outra fun¸cãohash-one way, como, por exemplo, a sha1, disponibilizada pela linguagem PHP.

$CHAVE PUBLICA=md5($temp login.$CHAVE SECRETA.$ip.$hora).

A variável da sessão é um vetor ($usuario). Ele armazena ologin ($temp login), o instante, em segundos, em que a página foi acessada ($hora), a chave pública ($chave) e o n´ıvel de acesso do usuário ($acesso). Note que o endere¸co IP não é armazenado na sessão.

$usuario=array($temp login, $hora, $chave, $acesso);

(47)

naquela sessão. Uma vez dispon´ıveis, elas são utilizadas para construir a chave pública. O endere¸co IP do usuário é obtido através do seguinte comando:

$ip=$HTTP SERVER VARS[“REMOTE ADDR”];

A chave pública reconstru´ıda, então, é comparada com aquela armazenada na sessão. Se as chaves forem idênticas, o usuário terá acesso ao sistema se não ficar inativo por um per´ıodo superior a uma hora. Caso contrário, a sessão é destru´ıda e o usuário é redirecionado para a página principal.

Vale salientar que a chave pública é modificada toda vez que o usuário acessa uma página do sistema, o que dificulta poss´ıveis falsifica¸cões. Isso só é poss´ıvel porque a variável $hora não é idêntica para acessos distintos.

4.2.4 Funcionalidades

Nesta Se¸cão são mostradas as funcionalidades do sistema de banco de dados. Primeiramente são ilustradas as opera¸cões de inser¸cão, remo¸cão e atualiza¸cão de informa¸cões sobre cenários de ataque. Posteriormente, relata-se sobre inser¸cão e remo¸cão de usuários no sistema.

(48)

• Autentica¸c˜ao

A Figura 4.11 ilustra a interface inicial encontrada pelos usuários que desejam acessar o sistema. Ela possui campos para o login (identificador de usuário) e a senha, que são os ´ uni-cos parâmetros requeridos pelo processo de autentica¸cão do sistema. Nesta mesma Figura é mostrada a interface exibida aos usuários imediatamente após o processo de autentica¸cão. Ela informa ao usuário a hora e a data do último acesso.

(49)

• Recupera¸c˜ao de Informa¸c˜oes

A recupera¸cão de informa¸cões sobre cenários de ataque ocorre fornecendo-se um número do CVE do ataque. Esse número é avaliado antes do pedido ser enviado ao banco de dados. A informa¸cão é mostrada apenas se a classifica¸cão dela for igual ou inferior ao n´ıvel de acesso do usuário que a requisitou e o número do CVE fornecido for válido. A Figura 4.12 ilustra esta opera¸cão.

(50)

• Atualiza¸c˜ao de Informa¸c˜oes

A atualiza¸cão de informa¸cões ocorre logo após a visualiza¸cão da mesma. Ao final da infor-ma¸cão consultada é exibido um botão “Atualizar”. Esse botão direciona o usuário para uma página cujas informa¸cões a serem atualizadas estão dispon´ıveis em formulários. A Figura 4.13 ilustra esta opera¸cão.

(51)

• Remo¸c˜ao de Informa¸c˜oes

A remo¸cão de informa¸cões é realizada fornecendo-se apenas o número do CVE do ataque. Caso o usuário possa remover a informa¸cão (situa¸cão na qual a classifica¸cão da informa¸cão é idêntica ao n´ıvel de acesso do usuário que está realizando a opera¸cão) e o número do CVE seja válido, o usuário é informado que a exclusão ocorreu normalmente. Caso contrário, uma mensa-gem de erro é emitida ao usuário. A Figura 4.14 ilustra o processo de remo¸cão de informa¸cões.

(52)

• Adi¸c˜ao de Usu´arios

A adi¸cão de usuários é realizada fornecendo-se o o n´ıvel de acesso, a senha e o login do usuário. De forma idêntica às opera¸cões mencionadas, emite-se um mensagem informando se a opera¸cão foi bem sucedida. A Figura 4.15 mostra as interfaces de adi¸cão de um usuário e de exibi¸cão de mensagem.

(53)

• Remo¸c˜ao de Usu´arios

A remo¸cão de usuários é realizada fornecendo-se o identificador do usuário, constitu´ıdo apenas pelo seulogin. A Figura 4.16 ilustra esta opera¸cão.

(54)

4.3 O Assistente ao Especialista

O assistente ao especialista implementado é composto por interfaces web e arquivos texto. De forma idêntica ao sistema de banco de dados, as interfaces do assistente ao especialista são providas pelo servidor Apache e foram escritas utilizando-se as linguagens PHP, HTML e JavaScript.

O conhecimento que o assistente ao especialista possui está codificado nos arquivos texto. Ele está representado na forma de regras de produ¸cão, que são declara¸cões condicionais que especificam uma a¸cão a ser realizada caso uma condi¸cão seja satisfeita. Elas codificam o conhe-cimento na forma de pares de premissa-a¸cão e apresentam a sintaxe mostrada a seguir.

SE <condi¸cão>ENTÃO<a¸cão>

A parte esquerda da regra é chamada de parte de condi¸cão ou de premissa e estabelece as condi¸cões de aplicabilidade da regra. A parte direita da regra é denominada de parte de a¸cão ou de conclusão e ocorre apenas se a condi¸cão estabelecida na respectiva parte de condi¸cão for satisfeita.

A Figura 4.17 ilustra a forma na qual as regras de produ¸cão devem ser inseridas na base de conhecimento. O primeiro parâmetro da regra refere-se à chave de busca; o segundo, à pergunta realizada ao especialista e o terceiro, ao tipo de interface de entrada. Os tipos de interfaces de entrada do sistema englobam três entradas de controle [19] disponibilizadas pela linguagem HTML: text (entradas do tipo texto), radio (entradas de única escolha) e checkbox (entradas de múltipla escolha). As demais linhas da regra representam poss´ıveis respostas à pergunta realizada. O caractere “P” concatenado com a resposta selecionada determina a próxima chave de busca. Conforme se pode observar nesta mesma Figura, toda op¸cão de resposta é precedida de um identificador. Esse identificador é necessário para que possam existir no mesmo arquivo perguntas com respostas idênticas.

Figura 4.17: Sintaxe das regras do assistente ao usu´ario implementado.

(55)

que as entradas são de única escolha; a palavra “multipla” para especificar que as entradas são de múltipla escolha e a palavra “texto” para especificar que as entradas são do tipo texto.

P14

Como esse programa foi explorado? uma

15-Através de um código enviado ao dispositivo de rede. 50-Enviando uma cópia como anexo de e-mail.

300-Atrav´es de um programa de mensagens instantˆaneas. 517-Especificar.

313-Desconhecido.

Figura 4.18: Exemplo de regra. ´

E importante salientar que cada arquivo texto da base de conhecimento corresponde a um tipo de ataque. A busca por regras, então, dá-se no arquivo relacionado à categoria do inci-dente ocorrido. Essa forma de organizar o conhecimento se assemelha à de regra de produ¸cão estruturada, na qual regras são separadas em classes para acelerar o processo de inferência.

O assistente ao especialista processa a análise das regras de forma progressiva. A seqüência de perguntas é determinada pelas respostas fornecidas pelo usuário durante a consulta. Uma regra é selecionada quando a premissa dela satisfaz a condi¸cão estabelecida pela última pergunta respondida. As respostas dos usuários e as respectivas perguntas realizadas pelo sistema são armazenadas em uma matriz de strings.