Nesta seção é apresentado um modelo geral para a composição de sistemas de detecção de in- trusão. Para tanto são introduzidas as características desejáveis para o modelo proposto e a infra- estrutura projetada para atender a tais requisitos.
4.2.1 Características das Composições de IDSs
Uma composição de IDSs é efetivada com o auxílio de uma infra-estrutura de serviços. A com- posição de IDSs deve permitir tanto a integração de IDSs completos e independentes, quanto a confi- guração de novos sistemas de detecção a partir de elementos de IDSs. São adotados como elementos básicos de um IDS aqueles definidos no modelo de detecção de intrusão do IETF [Wood e Erlinger, 2002], apresentado na seção 3.1: sensores, analisadores e gerenciadores. A escolha da arquitetura orientada a serviços se deve às facilidades de integração que caracterizam as tecnologias que seguem tal paradigma.
A composição de sistemas de detecção de intrusão, a partir dos serviços do modelo proposto, deve atender às necessidades de ambientes fechados de médias e grandes empresas, mas principalmente às de ambientes abertos que fazem uso da Internet. As composições de IDSs, segundo o modelo, podem se estender por diferentes organizações, permitindo, por exemplo, o compartilhamento de alertas de segurança. Esta troca de informações pode estar sujeita a políticas que limitam o fluxo que sai de cada organização na comunicação entre elas. Para lidar com esta dificuldade, tanto os elementos de uma composição de IDSs, quanto a infra-estrutura de serviços, são representados como Web Services[W3C, 2004].
Em geral, os IDSs são especializados e não são capazes de tratar com informações provenientes de diversos níveis e de diferentes ambientes. O modelo que propomos enfatiza o uso de elementos heterogêneos e distribuídos, permitindo a integração de ferramentas previamente existentes, mesmo que de diferentes fabricantes. É necessário nessas composições que seus elementos compartilhem for- mas padronizadas de comunicação e de integração. Portanto, a interoperabilidade é fundamental nas composições de IDSs. O presente trabalho se concentra nos esforços dos organismos de padronização IETF1, OASIS2e W3C3.
Uma composição de IDSs pode ser permanente ou temporária, sendo formada para coletar dados de determinados sensores, pesquisar diversas bases de dados de eventos ou para compartilhar infor- mações sobre um ataque em andamento. A composição dinâmica permite a adaptação a situações novas em um ambiente distribuído de larga escala.
A segurança dos próprios IDSs é obviamente um ponto crítico para qualquer sistema de monitora- mento. Para tal, é necessário o uso de mecanismos que possam garantir as propriedades de segurança das próprias informações trocadas ou manipuladas nestas composições distribuídas de IDSs.
4.2.2 Infra-estrutura de Serviços para Composição de IDSs
A composição de IDSs envolve o uso de um conjunto de serviços e suportes que são apresentados em uma forma simplificada na Figura 4.1. Os elementos de uma composição de IDSs são vistos como serviços e disponibilizados por meio de Web Services (Elementos de IDS com suporte WS).
1http://www.ietf.org 2http://www.oasis-open.org 3http://www.w3c.org
Elementos de IDS sem suporte WS (COTS) Serviço de Registro e Pesquisa Serviço de Segurança Elementos de
IDS com suporte WS (IDS, Sensores, Analisadores, Gerenciadores, etc) Suporte de Configuração SOAP Transporte (HTTP, SMTP, FTP, etc) Compatibilizador de Formatos
Figura 4.1: Infra-estrutura de Serviços para Composição de IDSs
As informações referentes aos serviços prestados por elementos de composições de IDSs, ne- cessárias nas interações com os mesmos, são acessadas por meio do Serviço de Registro e Pesquisa (SRP), disponível na infra-estrutura proposta. Tal serviço está fundamentado na especificação UDDI (Universal Description, Discovery and Integration specification) [OASIS, 2004a]. A descrição no SRP de um elemento de detecção de intrusão, na forma de Web Service, além de conter a identifica- ção do serviço e a sua localização, precisa fornecer informações relacionadas ao acesso do serviço e às políticas que o governam.
Qualquer elemento de uma composição de IDSs pode funcionar no modo requisitante (cliente), no modo fornecedor (servidor) ou em ambos os modos. As interações entre Web Services normalmente seguem o modelo cliente/servidor, trocando requisições (requests) e respostas (replies). Contudo, o fornecimento de serviços entre elementos de composições de IDS está sujeito às suas atividades, o que implica que as respostas dos provedores (modo fornecedor) não são imediatas a uma requisi- ção e muitas vezes não são únicas. Por exemplo, quando uma atividade suspeita é identificada por um sensor, este como prestador de serviço envia ao cliente uma mensagem contendo um alerta de segurança. Esse monitoramento pode ter um tempo determinado de duração, após o qual o serviço deixa de ser prestado, como, por exemplo, na primeira ocorrência do evento. Mas também pode durar indefinidamente, gerando inúmeras notificações.
Os elementos de composição de IDSs se comunicam enviando notificações de eventos e alertas. Portanto, as operações de Requests e Replies são usadas para enviar as notificação de eventos e alertas entre os elementos da composição.
O Serviço de Segurança trata da autenticação, do controle de acesso dos elementos envolvidos na composição e do gerenciamento dos certificados usados na composição.
Para definir elementos “serviços” a partir de partes dos IDSs convencionais é necessário introduzir um nível de funções que formam o que chamamos de “Compatibilizador de Formatos” (CF), cuja principal atividade é tratar com os formatos usados nas trocas de mensagens das composições de
serviços. Essas funções, por exemplo, atuam também na intermediação da comunicação entre partes usadas de IDSs convencionais (sem suporte web) e os Web Services que os disponibilizam para as composições. O Compatibilizador de Formatos atua ainda na configuração dos elementos serviços e na segurança das mensagens (estabelecimento do contexto de segurança das mensagens, cifragem e assinaturas das mensagens XML, etc).
4.2.3 Interações nas Composições de IDSs
No modelo proposto, um IDS pode ser composto, por exemplo, por sensores que fornecem servi- ços de geração de eventos e elementos que executam análise, redução ou correlação destes eventos.
Sensores e analisadores podem ser autônomos4ou dependentes5, assumindo papéis de requisitantes
e fornecedores de serviços dependendo do tipo de interação que esteja participando. Outro aspecto que estamos explorando é a possibilidade do compartilhamento destes componentes elementares en- tre IDSs; na Figura 4.2, as composições “A” e “C” compartilham um mesmo sensor, enquanto que as composições “B” e “C” compartilham um mesmo analisador. Os gerenciadores usam serviços de sensores e analisadores, podendo também interagir com outros gerentes no nosso modelo. Na figura, as setas indicam o sentido das mensagens contendo notificações de segurança.
Diferentemente do que ocorre com o modelo de detecção de intrusão do IDWG (seção 3.1), na figura, alguns elementos sensores trocam informações diretamente com o gerenciador. Isto é possível, pois os sensores da composição também podem ser IDSs completos, que agregam as funcionalidades de sensor e analisador. Gerenciador C Gerenciador B Gerenciador A Sensor Sensor Sensor Sensor Sensor Analisador Analisador Composição A Composição B Composição C Infra-estrutura de Serviços (Suporte Integrador)
Figura 4.2: Distribuição física das composições e a comunicação entre seus elementos A Figura 4.3 expande as composições da Figura 4.2 a fim de ilustrar as relações e interações entre seus elementos e sua distribuição física. No exemplo da Figura 4.3 as composições possuem
4Funcionam de forma independente de outros componentes do IDS.
5Dependem de outro(s) componente(s) do IDS para seu funcionamento, sendo ativado somente se requisitado por outro
elementos distribuídos em quatro domínios administrativos distintos. A composição “B” é formada por elementos contidos exclusivamente no domínio “2”. A composição “A” é formada por elementos pertencentes aos domínios “1” e “3”, enquanto que a composição “C” usa elementos dos domínios “1”, “2”, “3”, e “4”. Gerenciador C Gerenciador B Gerenciador A Sensor Sensor Sensor Sensor Sensor Analisador Analisador Composição A Composição B Composição C Domínio 1 Domínio 2 Domínio 3 Domínio 4 Formatos Nativos Comunicação Segura (IDMEF + WS-SEC + SOAP) CF
CF CF
CF
CF
CF Compatibilizador de Formatos
Figura 4.3: Possibilidades de Composições
Conforme ilustrado no exemplo da Figura 4.3, as mensagens entre elementos de IDS são enviadas por elementos serviços, utilizando os formatos suportados para as comunicações da composição. Quando a comunicação se dá no escopo de uma rede local, os elementos podem enviar notificações usando formatos originais dos elementos. Nas interações que envolvem domínios administrativos distintos, a comunicação está baseada em formatos padrões, como o IDMEF (Intrusion Detection Message Exchange Format) [Debar et al., 2006], seguindo um modelo de comunicação segura e padronizada, que será descrito na seção 4.3.