Estgf - Instituto Politécnico do Porto

Transcrição

Instituto Politécnico do Porto
Escola Superior de Tecnologia e Gestão de Felgueiras
Licenciatura em Segurança Informática em Redes de Computadores
“Gestão de eventos de segurança de informação - SIEM”
Projeto realizado por: João Pedro G. Alves - Nº 8000055
Novembro 2015
Projeto realizado sob a orientação de:
Professor Doutor António Pinto
Página propositadamente deixada em branco.
Índice de conteúdo
Resumo................................................................................................................................... 1
Agradecimentos...................................................................................................................... 2
Abreviaturas............................................................................................................................ 3
1. Introdução........................................................................................................................... 1
2. Gestão de eventos de segurança de informação................................................................2
Introdução....................................................................................................................... 2
2.1 Como se define um SIEM.........................................................................................3
2.2 SIEMs de código livre................................................................................................5
3. Teste às soluções SIEM......................................................................................................9
Introdução....................................................................................................................... 9
Cenário de testes............................................................................................................ 9
3.1 Solução OSSEC......................................................................................................11
Instalação e descrição do seu funcionamento.....................................................11
Recolha de dados...............................................................................................12
Análise em tempo real e correlação de informação............................................13
Armazenamento e compliance............................................................................15
Reporte............................................................................................................... 16
Conclusão........................................................................................................... 17
3.2 Solução OSSIM.......................................................................................................18
Instalação e descrição do seu funcionamento....................................................18
Recolha de dados...............................................................................................20
Reporte............................................................................................................... 23
Conclusão........................................................................................................... 23
3.3 Solução Graylog......................................................................................................24
Reporte............................................................................................................... 28
Conclusão........................................................................................................... 28
3.4 Solução Prelude-Siem.............................................................................................29
Reporte............................................................................................................... 31
Conclusão........................................................................................................... 31
4. Análise comparativa.......................................................................................................... 32
4.1 Análise geral comparativa.............................................................................32
4.2 Análise crítica e conclusões..........................................................................34
4.3Trabalho futuro...............................................................................................35
5. Conclusão......................................................................................................................... 36
Referências bibliográficas.............................................................................................37
Índice de ilustrações
Ilustração 1: Funcionamento de um SIEM...............................................................................3
Ilustração 2: Cenário de testes..............................................................................................11
Ilustração 3: Funcionamento do OSSEC...............................................................................12
Ilustração 4: Exemplo do programa para criar agentes com adição de um agente do lado
servidor................................................................................................................................. 13
Ilustração 5: Agente OSSEC a ser executado.......................................................................14
Ilustração 6: Exemplo de resumo de eventos gerado em tempo real pelo KIBANA..............15
Ilustração 7: Exemplo de uma alerta de nível 6.....................................................................16
Ilustração 8: Funcionamento standard do OSSIM.................................................................19
Ilustração 9: Processo de correlação de eventos no OSSIM (Fonte: [3])..............................21
Ilustração 10: Exemplo da diretiva de correlação a detetar ataques por força bruta (Fonte[3] )
.............................................................................................................................................. 22
Ilustração 11: Ecrã inicial do Wizard OSSIM.........................................................................23
Ilustração 12: Arquitetura do Graylog[0]................................................................................25
Ilustração 13: Evidência de coneção de coletor Ms Windows ao Server...............................26
Ilustração 14: Dashboard parcial do input.............................................................................28
Ilustração 15: Componentes principais do Graylog[0]...........................................................29
Ilustração 16: Arquitetura simples do Prelude-Siem OSS[0]..................................................30
Índice de tabelas
Tabela 1: Comparação de soluções de código livre................................................................9
Tabela 2: Principais recursos alocados por máquina virtual..................................................11
Tabela 3: Comandos de configuração do coletor Graylog para máquinas Windows.............26
Tabela 4: Exemplo de uma regra em Python[5].....................................................................31
Tabela 5: Comparação de funcionalidades presentes em cada SIEM...................................34
Resumo
A gestão de eventos e de segurança da informação assume nos dias de hoje um papel
fundamental no quotidiano das organizações e de cada um em geral. Os contextos económicos
atuais desfavoráveis são um entrave à promoção e adoção de soluções que possam ajudar nesta
área.
Este projeto tem como principais objetivos investigar e analisar as principais soluções de
programas informáticos existentes no mercado em código aberto, para a gestão de eventos e
segurança da informação. Os principais procedimentos foram a comparação das várias soluções
investigadas, os resultados obtidos e as conclusões retiradas. Este relatório exibe todos os passos
efetuados no decorrer deste projeto.
I
Agradecimentos
Gostaria de agradecer a todos os docentes da licenciatura de SIRC em geral pelo seu empenho e
trabalho prestado, bem como a todos os que me apoiaram nesta etapa da minha vida académica.
Destaco a especial importância ao professor Dr. António Pinto, o docente que me coordenou nesta
importante unidade curricular do meu curso e ao professor Dr. João Paulo Magalhães por toda a
atenção e disponibilidade.
II
Abreviaturas
OSSEC
Open source host based intrusion detection system
OSSIM
Open source security information Management
SEC
Simple event correlator
SIEM
System information and event management
TI
Tecnologias da informação
RAM
Random Access Memory
MS
Microsoft
HDD
Hard Disk Drive
TCP
Transmission Control Protocol
MIT
Massachusetts Institute of Technology
CPU
Cnetral Processing Unit
III
1. Introdução
Desde os tempos mais longínquos, até aos dias de hoje, a informação assumiu sempre um
elemento valioso no nosso mundo, como tal, também foram desenvolvidos diversos mecanismos
para tentar protegê-la, como a cifra de César, o enigma G, entre outros mecanismos de cifras
utilizados pelo império Romano e exército Alemão.
Com a chegada da Internet e a massificação do seu uso, ficamos cada vez mais ligados e por
sua vez a informação muito mais exposta, sendo possível aceder-lhe de qualquer parte do mundo
e por qualquer pessoa. Com a preocupação em proteger a informação o que para muitos é o seu
bem mais precioso, tais como empresas, organismos governamentais, etc…, passamos a dispor
de outros mecanismos para assegurar a sua salvaguarda, tentando manter afastados potenciais
invasores.
Esses mecanismos vão desde ferramentas e tecnologias compostas por firewall's1 dedicadas,
soluções de antivírus, sistemas de deteção de intrusos, proxys2 e outros
que as empresas
passam a adicionar às suas infraestruturas. O senão é que cada mecanismo de proteção tem a
sua interface de gestão, a sua forma de atuar e de apresentar dados e para tal um analista em
segurança tem de despender muito tempo e sempre sem ter todas as áreas asseguradas. Neste
contexto e para tentar colmatar esta falha, começaram a surgir na última década os sistemas de
gestão de eventos de segurança da informação, SIEM – Security Information and Event
Management, em que o objetivo é agregar e correlacionar todas as informações de segurança
geradas pela infraestrutura de rede de computadores num único ponto central de gestão
administrativa, permitindo a um analista ter uma visão geral e otimizada do seu trabalho com o
mínimo de falsos-positivos e falsos-negativos.
Segundo um relatório publicado pela Gartner[1] em julho deste ano em , é-nos dado a conhecer
que o mercado dos SIEMs vale atualmente 1,6 biliões de dólares, em 2014 cresceu 11% e esperase que em 2015 se feche o ano com um crescimento de 12.4%, sendo esta área de particular
interesse e estar no foco entre o mercado da TI's.
Este relatório está organizado por capítulos. No capítulo 2 é abordado um conjunto de soluções
SIEM de código aberto onde se descrevem as suas principais características. No capítulo 3 é
evidenciado o estudo e teste às soluções anteriores e no capítulo 4 apresenta-se as conclusões
ao trabalho efetuado.
1
2
Firewall é uma solução de segurança baseada em hardware ou software em que a partir de uma série de instruções
ou regras, analisa o tráfego de rede para determinar quais as operações de transmissão ou receção podem ser
executadas.
Proxy pode ser um computador ou programa intermediário capaz de receber requisições de clientes e que por sua
vez solicita os recursos pedidos a outros servidores
1
2. Gestão de eventos de segurança de informação
Neste capítulo são enumeradas, descritas e comparadas as soluções de acordo com os princípios
e características que cada verdadeira solução SIEM deverá ter, para que sejam efetivamente
consideradas no estudo que se irá efetuar, sendo o objeto da nossa análise crítica global à melhor
solução SIEM Open Source.
Introdução
Atualmente as organizações de tecnologias de informação (TI) são constantemente confrontadas
com um volume crescente de registos oriundos das mais diversificadas fontes, sejam elas
computadores, equipamentos de rede, ou de outros sistemas, sendo que por isso os sistemas de
gestão de eventos de segurança de informação, ou SIEM, estão a assumir um papel cada vez
mais importante no apoio à gestão de tais registos de informação, essenciais para análise e
descoberta de incidentes de segurança.
Um sistema SIEM efetua a gestão de eventos de segurança de informação, e assume
normalmente a forma de um conjunto programas informáticos que recolhem, armazenam,
processam e correlacionam registos (logs) ou fontes de informação e eventos de segurança.
Estes sistemas recolhem dados de aplicações, de equipamentos de rede, de computadores, bem
como recolhem informação proveniente de outros sistemas de informação. A informação é
armazenada num ponto central, permitindo a sua analise para deteção de padrões ou ocorrências
que não sejam comuns. A generalidade dos SIEM opera com recurso a agentes, pequenos
programas ativos nos sistemas a analisar, por forma a fornecer informação relacionada com a
segurança destes sistemas. Os SIEM, usando uma base de conhecimento composta por regras
pré-estabelecidas, analisa e processa a informação tentando detetar anomalias. Uma vez
detetadas, estas anomalias são sinalizadas e posteriormente são despoletados alertas para o
operador.
A escolha de um SIEM por parte de uma organização não é uma tarefa fácil, agravando-se se se
limitar a escolha a produtos de código aberto. O objetivo deste projeto é o de analisar as demais
soluções de código aberto existentes na Internet, comparando-as e validando se estas reúnem as
características de um verdadeiro sistema de gestão de eventos de segurança de informação. Este
trabalho pretende ainda servir de apoio na escolha de uma destas soluções.
2
2.1 Como se define um SIEM
Um sistema SIEM trata-se de um conjunto programas informáticos que recolhem, armazenam,
processam e correlacionam registos (logs) ou fontes de informação de eventos de segurança. A
recolha de informação é feita normalmente em tempo real sobre ficheiros de log de sistemas e
aplicações, bem como de equipamentos de rede e outros. A informação é processada com base
num conjunto de políticas ou regras bem definidas previamente e tenta-se que todos os dados
sejam correlacionados para que se possa obter informações sólidas sobre a segurança da
informação e para proporcionar uma resposta rápida a incidentes de segurança. As ferramentas
SIEM devem possuir mecanismos de armazenamento da informação correlacionada para que
possa ser consultada quando necessário por equipas forenses em busca de pistas em casos
concretos de ameaças ou comprometimento da informação. Para que possa ser uma mais valia
nas organizações, os analistas de segurança devem poder contar com alertas e relatórios de uma
forma reativa e imediata a sinais positivos de risco ou ameaça.
Dados/Logs
Output
Informação recolhida
por agentes locais
Relatórios
Outros alertas externos
Fontes externas de
dados/logs
SIEM
Alertas
Processa informação
Informação Forense
Resolução de
problemas
Dados ou logs
Os SIEM's recolhem dados em ficheiros de log de uma diversificada quantidade de dispositivos,
aplicações, sistemas operativos, firewall's, routers, switchs,IDS e IPS, servidores proxy, sistemas
de controlo de acesso, entre outros que geram dado, pois os dados são a peça fundamental num
sistema SIEM. Os mecanismos usados para recolha da informação são geralmente através dos
protocolos Simple Network Management Protocol (SNMP), Netflow ou Internet Protocol Flow
Information Export (IPFIX) entre outros. Em caso de soluções que não suportam estes protocolos,
3
geralmente recorre-se ao uso de agentes, normalmente uma componente de software capaz de
recolher informação relevante e a normnaliza no formato de origem do seu SIEM. Geralmente o
uso deste mecanismo implica soluções mais complexas de implementar.,
Processamento de informação / SIEM
De forma a ultrapassar problemas gerados no uso de fontes de informação de várias origens e
formatos, processa-se a informação e é feita uma normalização para um formato específico de
cada solução em que a ideia essencial no final é todos os dados serem apresentados da mesma
forma. De seguida é desencadeado um processo de correlação afim de ligar os diversos eventos
de segurança ou alertas, dentro de um determinado intervalo de tempo e em vários sistemas para
identificar atividades anómalas que não sejam evidentes numa simples observação. Normalmente
para efetuar a correlação, existe um conjunto de regras ou políticas previamente configuradas que
indicam quais as áreas ou tipo de evento que interessa correlacionar. A informação depois de
normalizada e correlacionada disponibilizada para análise na etapa seguinte e é armazenada
geralmente em bases de dados relacionais, dependendo de cada SIEM.
Output
Após as etapas anteriores, a informação de segurança está pronta para ser analisada ou
monitorizada e o mecanismo mais comum a todas as soluções é através da disponibilização de
uma interface Web onde o utilizador pode interagir com a informação, efetuando pesquisas
específicas, filtrando eventos de maior interesse, etc... .Um sistema assume maior interesse
quando nesta fase e mediante as funcionalidades que possua, faça escalar para níveis superiores
alertas sobre eventos ou ameaças críticas detetadas.
4
2.2 SIEMs de código livre
Open Source SECurity (OSSEC)
O OSSEC é uma solução do tipo HIDS - Host-based Intrusion Detection System, sistema de
deteção de intrusão. Faz análise de logs, executa verificações de integridade de ficheiros, executa
monitorização baseada em políticas, com componentes de deteção Rootkit
3
e alertas em tempo
real com respostas ativas. O OSSEC é essencialmente composto por um programa servidor e por
um agente. Pode ser executada na maior parte dos sistemas operativos atuais, Linux, MacOS,
Solaris, HP-UX, AIX e Windows e é licenciado ao abrigo da GNU - General Public License (version
2). Esta ferramenta pode ser descarregada da Internet a partir do seguinte endereço:
http://www.ossec.net/.
Open Source Security Information and Event Management (OSSIM)
O OSSIM é uma solução que oferece uma plataforma unificada de diversas funcionalidades de
segurança essenciais, tais como, pesquisa de vulnerabilidades, deteção de intrusão,
monitorização de comportamentos, descoberta de ativos. Possuiu suporte gratuito baseado numa
comunidade ativa de colaboradores espalhados por todo o mundo. Tem três modelos de relatórios
de alto nível, com acesso a um único utilizador e a gestão de cada componente é feita de forma
individual na sua versão gratuita. Esta ferramenta pode ser descarregada da Internet a partir do
seguinte endereço: https://www.alienvault.com/products/ossim.
Logwatch
O Logwatch é um sistema parametrizável de análise de logs. Esta ferramenta analisa os ficheiros
de logs e cria relatórios sobre áreas específicas que foram previamente definidas, fazendo-os
escalar em modo de alertas para o operador. Consolida e centraliza as diversas fontes de
informação e o seu licenciamento é ao abrigo do MIT. Esta ferramenta pode ser descarregada da
Internet a partir do seguinte endereço: http://www.logwatch.org.
Simple Event Correlator (SEC)
O SEC é uma ferramenta de correlação de eventos avançada, para o processamento de eventos
recolhidos da monitorização de logs. Faz gestão da informação de segurança, com capacidades
para deteção de fraude. Esta solução é leve e tem independência de plataformas, correndo num
único processo simples ou vários em simultâneo com missões diferentes. Recorre essencialmente
a regras alojadas em ficheiros de configuração. É capaz de utilizar sub-rotinas desenvolvidas em
PERL4 e produz essencialmente ficheiros externos para serem analisados por outros programas
3 Conjunto de programas maliciosos com a finalidade de obter acesso a áreas protegidas dos sistemas
4 Linguagem de programação
5
de reporte. Esta ferramenta pode ser descarregada da Internet a partir do seguinte endereço:
http://www.simple-evcorr.github.io/.
Snare Backlog
O Snare Backlog é uma solução que assenta num sistema básico de registo de eventos, préWindows 2008. Não possuí suporte para auditoria, no entanto engloba-se nas soluções Open
Source. Possibilita a instalação de um servidor e diversos agentes (snares) ou laços que fazem a
recolha de informação. Esta solução foi uma das primeiras a ser desenvolvida e entretanto foi
migrada para uma versão Snare Enterprise Agents que é utilizada pelas 500 empresas Fortune e
pela maioria das empresas governamentais. Esta ferramenta pode ser descarregada da internet a
partir do seguinte endereço: https://www.intersectalliance.com/our-product/
Syslog-ng
O Syslog-ng é uma aplicação do tipo do sistema operativo Unix e é uma implementação Open
Source do protocolo Syslog para Unix. Utiliza filtragem rica de conteúdos. A sua configuração é
flexível dando poderosas funcionalidades ao Syslog. O seu licenciamento assenta na GPL. Esta
ferramenta pode ser descarregada da internet a partir do seguinte endereço: https://syslog-ng.org/.
Logsurfer
O Logsurfer foi desenhado para monitorizar em tempo real num sistema, ficheiros de texto de
logs. Utiliza expressões regulares para encontrar padrões que podem ser complementadas com
exceções. Processa blocos de mensagens em vez de simples linhas de texto. Implementa
múltiplas reações às ações despoletadas nas análises. Foi desenvolvido na linguagem de
programação C e recorre livraria de expressões regulares GNU REGEX. Esta ferramenta pode ser
descarregada da Internet a partir do seguinte endereço: http://www.crypt.gen.nz/logsurfer/.
Loghound
O Loghound foi desenhado para encontrar padrões frequentes em conjuntos de ficheiros de logs.
Baseia-se no algoritmo breath-first frequent itemst mining. Esta ferramenta pode ser descarregada
da internet a partir do seguinte endereço: http://ristov.github.io/loghound/
Log2timeline
O Log2timeline trata-se de uma framework para criação de cronogramas (timelines), com eventos
suspeitos ocorridos e recolhidos em ficheiros de logs em sistemas tais como equipamentos de
rede, servidores, computadores, com a finalidade de serem analisados por investigadores
forenses. Foi desenvolvida em PERL para Linux. Esta ferramenta pode ser descarregada da
internet a partir do seguinte endereço: https://code.google.com/p/log2timeline/.
6
Graylog
Graylog é uma plataforma completa para gestão de logs, com recolha, indexação, e análise
estruturada ou não de informação de proveniente de várias as fontes. Utiliza uma arquitetura
multi-tier afim de evitar congestionamentos em processamento e alojamento de dados.
Disponibiliza API’s REST5 para proporcionar extensibilidade. Esta ferramenta pode ser
descarregada da internet a partir do seguinte endereço: https://www.graylog.org/.
Prelude-SIEM
O Prelude-SIEM é uma solução com a qual pode-se recolher, normalizar, ordenar e correlacionar
eventos de segurança independentemente da marca ou do tipo de fonte de informação utilizada.
Funciona sem recurso a agentes e recorre a outras soluções anteriormente descritas para
enriquecer o su potencial, tais como OSSEC , SNORT, etc… . O eventos de segurança são
normalizados segundo um formato IDMEF – Intrusioin Detection Message Exchange Format,
descrita na RFC4765. Esta ferramenta pode ser descarregada da internet a partir do seguinte
endereço: https://www.prelude-siem.org/
Logalyze
O Logalyze é uma solução centraliza informação das mais variadas fontes de informação, tais
como servidores LINUX/UNIX, servidores Windows, dispositivos de rede e processa em tempo
real a deteção de eventos e pesquisas alargadas de padrões. Possui um sistema integrado de
estatísticas e relatório. Associa aos incidentes um sistema de tickets para uma maior eficácia na
gestão dos incidentes. Esta ferramenta pode ser descarregada da Internet a partir do seguinte
endereço: http://www.logalyze.com/.
Logstash
O Logstash trata-se de um pipeline de dados que processa registos de outros dados de eventos,
provenientes da diversificadas fontes. Contém 165 plugins e pode ser conectado a outros
sistemas idênticos com o mesmo propósito. Centraliza toda a informação recolhida e converte-a
num formato global comum para que possa ser utilizado noutros sistema de análise mais
familiares a cada utilizador. Esta ferramenta pode ser descarregada da internet a partir do
seguinte endereço: https://www.elastic.co/products/logstash.
5 Programas de interligação aplicacionais
7
2.3 Comparação
Efetuando uma análise à (Tabela 1), verifica-se que as soluções OSSEC, OSSIM, Graylog, e
Prelude-SIEM possuem todas as valências de uma verdadeira solução SIEM, recolhem,
correlacionam e analisam em tempo real fontes de informação ou logs, processam o seu
armazenamento para reanalise futura ou análise forense e permitem execução relatórios. Já as
ferramentas Logwatch, SEC e Snare Backlog não processam o armazenamento para análises
forenses nem possuem um sistema de relatórios.
Características SIEM
Solução
OSSEC
OSSIM
Logwatch
SEC
Snare
BackLog
syslog-ng
Logsurfer
LogHound
Log2timeline
Graylog2
Prelude-SIEM
Logalyze
Logstash
Recolha de
dados Logs
Análise
tempo real
Correlação de
eventos
Armazenamento
p/análise forense
Reporte
x
x
x
x
x
x
x
x
x
x
x
x
-
-
x
x
x
-
-
x
x
x
-
-
x
-
x
x
-
x
x
x
x
-
x
-
x
-
x
x
-
x
x
x
x
x
x
x
x
x
x
x
x
x
x
-
x
x
x
x
-
x
-
x
Tabela 1: Comparação de soluções de código livre
Baseado na análise anterior selecionaram-se as soluções OSSEC, OSSIM, Graylog, PreludeSIEM e Logalyze para um estudo mais aprofundado no próximo capítulo com a finalidade de se
obter a melhor solução a adotar numa possível implementação real.
8
3. Teste às soluções SIEM
Introdução
Neste capítulo são descritos os testes efetuados às soluções OSSEC, OSSIM, Graylog, e
Prelude-SIEM. O foco dos testes é direcionado para as principais características de um sistema
SIEM, nomeadamente comprovar a eficácia destes sistemas na recolha de informação de logs, a
análise em tempo real, a correlação de eventos, a forma como armazenam os dados para futuras
necessidades por parte de equipas forenses e o sistema de reporte.
Cenário de testes
Para os testes a efetuar à soluções, preparou-se um cenário assente numa máquina física
baseada em tecnologia intel x64, com 4GB de memória RAM, e 260 GB de espaço em disco
disponível, a executar o sistema operativo MS Windows 7 x64. Nesta máquina instalou-se o
software de virtualização Virtual Box ver. 5.08 disponível em <https://www.virtualbox.org/> afim de
ser possível recorrer à tecnologia de virtualização para termos um cenário virtual composto por
várias máquinas virtuais dispositivos de rede, alvos de recolha de informação para os nossos
testes e análise. Adicionou-se uma máquina real MS Windows 7 com 4 GB de memória RAM e
processador Core 2 Duo, uma máquina virtual Linux baseada em Ubuntu versão 6.06.1, uma
máquina virtual a executar a distribuição KALI, usada por muitos especialistas em segurança
informática para efetuar testes de penetração em sistemas, que servirá para simular possíveis
ameaças ou ataques por parte de um hipotético hacker6 de forma a comprovarmos a eficácia das
soluções a testar
e um router7 com acesso à Internet. A seguir descreve-se as principais
características em termos de capacidade de processamento e de memória alocados a cada
máquina virtual respetivamente para que fosse possível efetuar os testes com o mínimo de
performance. Em termos de soluções SIEM utilizamos quatro máquinas virtuais a executarem as
soluções a analisar, de acordo com a tabela de recursos seguinte. Apesar da representação
gráfica conjunta, casa solução será analisada separadamente, apenas com os ativos destacados
em execução simultânea.
6
7
Pessoa mal intencionada que efetua ataques a redes e sistemas com a finalidade de causar estragos
Router é um equipamento que reencaminha pacotes de dados entre várias redes
9
Solução
Memória
CPU
1024 MB
1 core
Xeon 2,33 GHz
2048 MB
2 core
Xeon 2,33 GHz
1024 MB
1 core
Xeon 2,33 GHz
1024 MB
1 core
Xeon 2,33 GHz
Tabela 2: Principais recursos alocados por máquina virtual
10
3.1 Solução OSSEC
Instalação e descrição do seu funcionamento
Efetuou-se download da versão 2.8.1, assente no sistema operativo Centos 6.6 de 64 bits. A
instalação foi feita de acordo com o manual de instalação em anexo (Anexo1 – Manual de
instalação OSSEC) a este relatório e é parte integrante deste projeto.
Esta solução funciona com uma componente servidora e e uma ou mais componentes “agentes”.
É preparado um servidor “OSSEC” a executar software específico para escuta e monitorização de
informação numa porta TCP 1514. São criados agentes num componente de software
manage_agents e gerada uma chave para cada um deles que será utilizada para efetuar
comunicação encriptada entre os agentes e o servidor. Do lado de cada máquina/equipamento ou
ponto de análise, instala-se um agente e importa-se a respetiva chave previamente gerada. Após
estes procedimentos, os agentes iniciam o trabalho de recolha de informação e enviam-na para o
servidor onde é centralizada, armazenada e analisada e reportada.
11
Recolha de dados
A recolha de dados nesta solução
pode ser feita de duas formas, uma delas é por via da
instalação de agentes que são pequenos programas que se instalam nos sistemas que queremos
monitorizar, são programas que consomem poucos recursos de memória e de utilização de CPU
e por isso não afetam muito a performance dos sistemas onde se instalam. São executados numa
área que é criada durante a instalação, com poucos privilégios, dentro de uma “jaula” de root
isolada do sistema. Estes agentes recolhem em tempo real a informação e reencaminham-na para
o manager para efetuar a sua correlação e análise. As configurações destes agentes, são
efetuadas do lado do manager e enviadas a cada agente. Caso estas configurações sejam
mexidas do lado do “agente”, o manager é alertado. Outra das formas desta ferramenta recolher
informações, é sem recurso a instalação de agentes, para sistemas onde não seja possível
instalá-los, como o caso de firewalls, routers, e outros, em que nestes a ferramenta efetua a sua
monitorização e verificação de integridade.
Estes mecanismos são um pouco trabalhosos de implementar pois exigem algum trabalho por
parte do operador que previamente tem criar os diversos agentes, criar chaves para cada um
12
deles e posteriormente repetir o procedimento do lado das máquinas a analisar, instalando os
agentes previamente criados e efetuando a importação das chaves.
Após se ter criado os agentes conforme ilustração anterior, precedeu-se à sua instalação do lado
dos clientes ou máquinas que irão servir de agentes de recolha de informação que por usa vez a
enviarão para o servidor OSSEC para correlação e análise. Estas tarefas ocorrem em tempo real
e devido ao tamanho reduzido de 1,09 MB por cada agente nas versões Windows e consumo de
memória de 2068 KB a performance do sistema em que opera não é afetada. Os agentes podem
ser instalados com duas opções adicionais, uma de monitorização de logs
do IIS (Internet
Information Server) e outra de verificação de integridade de ficheiros, no entanto ambas são
recomendadas durante a instalação.
Nesta ilustração podemos verificar um agente a ser executado do lado da máquina cliente alvo de
recolha de dados. Nele foi configurado o endereço IP do servidor OSSEC bem como adicionada a
chave previamente criada no servidor que serve de mecanismo de autenticação entre ambos.
Análise em tempo real e correlação de informação
Para análise, esta plataforma disponibiliza componentes baseados em páginas de web, onde é
centralizada toda a gestão e ações de monitorização. Do lado do servidor, iniciou-se o navegador
13
Mozilla Firefox com o endereço <http://localhost/ossec-wui/index.php> e acedemos à consola
central de interface com o utilizador. A partir daqui, podemos navegar para as páginas das
diversas componentes que nos permitem analisar a informação recolhida. Executando o link para
OSSEC Events, acedemos a uma página gerada pelo KIBANA8 fornecendo-nos um excelente
quadro resumo de todos os eventos analisados na informação que vai sendo recolhida e
processada.
Nesta solução salienta-se o facto de que as regras que vêm pré-configuradas serem bastante
satisfatórias fornecendo informação sobre o nível de alerta, o timestamp9 do evento, descrição e
detalhes, localização onde ocorreu o evento, origem, tipo e índice do evento no ficheiro de log.
Basicamente temos num único painel toda a informação centralizada e correlacionada proveniente
de vários agentes, para podermos analisar com o grau de personalização que quisermos
configurar baseado nas regras pré-estabelecidas.
Este sistema classifica os eventos com um nível de alerta entre 1 e 15, em que o grau de
importância do evento é mais importante quando o seu nível de alerta também o é (ex. Nível de
alerta 15 poderá corresponder a um ataque). Efetuou-se uma série de testes de penetração com a
máquina virtual KALI afim de atestar a eficácia deste sistema. Entre tentativas de login por
8
9
Interface muito personalizável com painéis de gráficos e histogramas para análises em tempo de real sobre dados
em logs.
Sequencia de caracteres ou informação codificada que identifica quando determinado evento ocorre.
14
ataques por força bruta e varrimentos aos portos de rede abertos, verifica-se que são gerados
com sucesso diversos eventos de segurança que a título de exemplo ilustramos a seguir.
Na ilustração acima, que é um excerto da lista de eventos da interface web central, evidenciandose um alerta de nível 6 para um evento de segurança encontrado pois existiu um varrimento aos
portos TCP por parte da máquina 192.168.1.36 com tentativa de conexão por via de SSH - Shell
segura.
Armazenamento e compliance
O OSSEC utiliza o manager que é a componente central de toda a solução para guardar a base
de dados de integridade de ficheiros, os logs, os eventos e as entradas de auditoria do sistema.
Todas as regras, descodificadores e as principais configurações também são armazenadas no
maneger, fazendo com que a administração tanto de sistemas com poucos agentes ou em
sistemas com muitos agentes seja fácil de efetuar. A localização de todos os logs é feita por
defeito em subdiretoórios em </var/ossec/logs>. As mensagens de log do próprio OSSEC são
armazenadas no ficheiro </var/ossec/logs/ossec.log>. Todas as mensagens provenientes dos
agentes por defeito não são armazenadas, depois de analisadas são eliminadas, a não ser que
seja ativado o parametro <loggall> no ficheiro de configuração do manager em <ossec.conf> e
neste caso essas mensagens serão armazenadas em </var/ossec/logs/archives/archives.log>,
com rotação diária.
No que respeita a compliance e de forma a que possíveis equipas forenses em cenários reais
tenham o seu trabalho facilitado, o OSSEC garante a integridade da sua informação através de
mecanismos FIM – File Integrity Checking. De base o OSSEC já efetua a verificação de
integridade aos seguintes ficheiros:
15
•
/var/log/messages
•
/var/log/auth.log
•
/var/log/syslog
•
/var/log/mail.info
•
/var/log/dpkg.log
•
/var/log/apache2/error.log
•
/var/log/apache2/access.log
Estes mecanismos segundo o livro OSSEC [2] detetam alterações na integridade do sistema,
recorrendo a alterações nos ficheiros de hash10 MD5/SHA1 e no Windows Registry. 11
Reporte
No que respeita a relatórios e reporte, esta plataforma possui uma componente OSSEC-reportd
que no fundo é uma aplicação que corre numa shell de sistema, para gerar relatórios a partir da
base de dados de eventos do OSSEC. Funciona aceitando alertas no stdin12 e efetua o seu
output sob a forma de relatório em stderr13. Um exemplo da utilização desta aplicação é o caso a
seguir, em que é solicitado um relatório de todos os alertas com um nível = 6 ou superior:
# cat /var/ossec/logs/alerts/alerts.log | /var/ossec/bin/ossec-reportd -f level 6
Outra das possibilidades é a utilização do Dashboard em que num ambiente web é-nos dado a
conhecer uma série de alertas escalados por níveis (1-15). Em tempo real e em modo gráfico são
gerados os principais relatórios com a explicação do níveis de alerta, o top 10 de alertas, alertas
assinados por operador, e alertas não assinados. Pode-se ainda personalizar estes relatórios com
uma pesquisa avançada por eventos ocorridos em determinado sistema, num determinado
período, de uma determinada origem (endereço IP) e com determinado nível de alerta.
10
11
12
13
Algoritmo que mapeia dados de comprimento variável para dados de comprimento fixo
Base de dados hierárquica que guarda definições de baixo nível do sistema operativo MS Windows
Canal de entrada de dados entre um programa e o ambiente, normalmente um terminal de texto
Canal de saida de dados relativos a erros normalmente direcionado para um terminal de texto afim de garantir a sua
observação
16
Conclusão
Esta solução mostrou ser simples na sua instalação e a sua operação. Acaba por ser uma boa
solução para a correlação de logs, deteção de rootkits, verificação de integridade e ficheiros e na
monitorização em tempo real. Destaca-se a análise de logs e verificação de integridade de
ficheiros, pois é fácil a compreensão dos dados apresentados durante a monitorização devido à
utilização de Dashboards gráficos e dinâmicos em ambiente web. Foi possível verificar a sua
eficácia na geração de eventos de segurança derivados no testes de penetração efetuados,
nomeadamente varrimentos ou scans aos portos TCP de uma das máquinas, e diversas tentativas
de login falhados de ataques por força bruta.
17
3.2 Solução OSSIM
Efetuou-se
download
da
appliance14
versão
4.15
disponível
em
<http://downloads.alienvault.com/c/download?version=current_ossim_iso>. A instalação foi feita de
acordo com o manual de instalação em anexo (Anexo2– Manual de instalação OSSIM). Esta
appliance combina um vasto leque de outras ferramentas de código livre, tais como a ferramenta
OSSEC anteriormente analisada, o SNORT que é um programa para deteção de intrusão para
rede e análise de tráfego, o NAGIOS, poderoso sistema de gestão e monitorização de ativos
numa rede ou infraestrutura, entre outros.
Esta plataforma assenta numa arquitetura de três camadas ou three-tier, pois possui três
componentes fulcrais, a componente Sensor, a componente Server e a Logger. Podem ser
implementadas individualmente em cada máquina ou todas integradas. Estes componentes,
fornecem análise em tempo real de ameaças, correlação de eventos e tecnologia inteligente para
tentar antecipar cada ameaça.
14 Dispositivo baseado em hardware e software integrado, pronto a utilizar.
18
Sensor – nesta solução os sensores são os módulos da linha da frente, e são responsáveis por
efetuar a descoberta automática dos ativos críticos existentes numa rede. Efetuam procuras ativas
e passivas e criam um inventário de ativos implementados. Outra das suas funções é descoberta
de vulnerabilidades existentes nos ativos previamente indetificados. Para além destas
funcionalidades, os sensores também efetuam deteção de intrusos através da identificação de
dispositivos ativos e as ameaças ativas que estes possuam, bem como a monitorização
comportamental.
Logger – este módulo é responsável por efetuar o arquivo seguro dos principais dados e eventos
para análises forenses futuras e para fins legais, registando a informação fornecida pela
componente anterior, os sensores. Permite efetuar a configuração e gestão dos das principais
áreas, descoberta de ativos, descoberta de vulnerabilidades, deteção de intrusos, monitorização
comportamental. Como técnicas, assina digitalmente a informação guardada para asseguar a sua
admissibilidade em casos legais, efetua a compressão dos dados afim de reduzir necessidade de
espaço de armazenamento.
Server – esta componente tem como propósito efetuar toda a automação da ferramenta no seu
todo. É aqui que se efetuam as configurações necessários, correlaciona a informação e identifica
as ameaças, gerando um relatório ou guião com as sugestões do que fazer para remediar as
falhas ou ameaças encontradas.
Utiliza bases de dados SQL – Structured Query Language ou bases de dados estruturadas
permitindo assim armazenar informação normalizada e disponibilizar uma capacidade de análise e
exploração de dados mais abrangente e atual. O interface com o analista ou operador é efetuado
em ambiente Web e nele são disponibilizados os acessos aos parâmetros de configuração e a
toda a informação sobre os eventos gerados. As principais tarefas que se podem realizar com este
interface são:

Gestão de utilizadores;

Alteração de configuração;

Gestão de vulnerabilidades;

Visualização de informação em tempo real;

Criação de relatórios;

Sistema de tickets;

Gestão de tráfego de rede

Respostas
19
Recolha de dados
O OSSIM é uma solução orientada à monitorização de rede. Uma das formas de recolha de dados
de segurança é a através da utilização do snort para efetuar pesquisas ou sniffing ao tráfego de
rede analisando-o de seguida e efetuando comparações com uma base de dados de assinaturas.
Toda a informação analisada pelo snort origina eventos no OSSIM e são catalogados como
tráfego suspeito, mesmo não sendo perigoso. Posteriormente é necessário efetuar monitorização
adicional para que se decida que eventos se guardam e quais os que se eliminam. Outra das
formas é utilizar um coletor de logs chamado de logs collector. Em máquinas Unix ou Linux é
utilizado o syslog15 . Curiosamente para máquinas Windows, esta solução recorre a outras
plataformas como o Snare ou mesmo o OSSEC, descritos anteriormente. A recolha de dados
incide essencialmente sobre a lista de ativos previamente criada.
De acordo com o guia de referencia da Alien Vault[3] a correlação de informação é associada a
múltiplos eventos com do mesmo tipo de evento ou não dentro da mesma origem de dados. Os
sensores enviam os eventos normalizados para o motor de correlação do OSSIM onde este por
sua vez lhes aplica política e regras de avaliação de risco e de seguida os correlaciona, gerando
novos eventos com níveis de prioridade mais elevados. O motor trata estes eventos já
classificados como novos eventos e reinjeta-os no processo Server onde este detetando níveis de
risco elevado gera alarmes.
15 Mecanismo standard para efetuar registos de sistema
20
O nível de risco de cada ativo é calculado da seguinte forma:
[VALOR ATIVO(0-5 * PRIORIDADE(0-5) * FIABILIDADE(0-10)] / 25 = RISCO DO EVENTO (0-10)
Cada ativo no OSSIM tem um valor entre 0 e 5, em que quanto maio for o número, mais valioso é
esse ativo. A prioridade mede a importância do evento, a fiabilidade é a probabilidade de existir
um ataque e valores obtidos entre 9 e 10, níveis altos, indicam que o ataque é real. Os alarmes
são despoletados quando o valor obtido é 1 ou superior. A decisão de conectar os eventos é
gerida por diretivas de correlação, que são uma ou mais regras de correlação definidas em
árvores lógicas. A ilustração a seguir mostra um exemplo do funcionamento de uma diretiva de
correlação. Neste caso esta diretiva é utilizada para detetar eventos de autenticação por força
bruta, ligando dois tipos de eventos, os de login16 bem sucedidos e os falhados. Neste exemplo
baseado no número de ocorrências individuais o motor de correlação consegue perceber se um
administrador se engana a digitar o seu código de acesso(um evento de login falhado seguido de
um bem sucedido) ou no caso de um ataque por força bruta de alta fiabilidade em que ocorrem
100000 logins falhados, seguido de um bem sucedido. Estes eventos devem ter a proveniência no
mesmo IP e serem destinados também a um único endereço IP de destino para que a diretiva seja
criada. O motor de correlação também pode usar tabelas de reputação sobre os endereços de
origem e destino afim de gerar eventos de segurança.
Após termos efetuado a instalação e configuração, seguimos para a primeira fase de operação do
16 Processo de controlo de entrada num sistema através de credencias de acesso
21
sistema, acedendo via interface Web ao endereço <https://192.168.1.28> onde se iniciou a adição
de ativos. Neste caso utilizou-se uma ferramenta automática ou wizard que facilitou muito as
tarefas inicias para configuração e colocação em funcionamento da solução. Este wizard começou
por identificar a rede a gerir de seguida a descoberta de ativos, e por fim a recolha de informação,
que se inicia depois de efetuarmos a instalação do HIDS, que no caso das máquinas Windows é
efetuado por via de instalação de um agente, e nas máquinas Linux através da configuração de do
HIDS remoto para obtermos as funcionalidades de monitorização de ficheiros, deteção de rootkit's
e recolha de logs.
Ilustração 11: Ecrã inicial do Wizard OSSIM
Para apoio à monitorização, o OSSIM disponibiliza um interface Web baseado em Apache17 e
MySql. Neste ambiente temos acesso a gráficos e tabelas com informação gerada em tempo real,
e é disponibilizado links para ferramentas de calendarização de pesquisas de vulnerabilidades
através do OpenVas, ferramenta de código livre para pesquisa de vulnerabilidades em ativos. É
possível efetuarmos ações sobre os eventos tais como envio de emails ou execução de
programas.
17 Servidor de páginas Web denominado HTTP Server
22
No que respeita ao armazenamento, o OSSIM armazena as suas regras num ficheiro em
/etc/ossim/server/directives.xml, que podem ser personalizadas pelo operador. A informação de
eventos é armazenada em base de dados SQL. Em termos de compliance, esta solução
disponibiliza relatórios de alto nível. Quanto à segurança da sua informação para fins forenses,
esta solução não efetua qualquer tipo de auditoria com admissibilidade em tribunal de acordo com
informação recolhida na publicação[4] da Alien Vault
sobre as características do OSSIM em
comparação com a sua versão paga.
Reporte
Em termos de reporte e relatórios o OSSIM fornece até 25 relatórios pré-instalados e a
possibilidade de criar novos relatórios baseados em Jasper Report, uma ferramenta de código
livre em JAVA18 para execução de relatórios com possibilidade de exportação de informação para
diferentes alvos, para o ecrã, impressora, ficheiros PDF, HTML, XLS, ODT, etc...
Conclusão
O OSSIM mostrou ser uma plataforma completa no que respeita a appliances SIEM com vocação
pura para analise de tráfego em redes pois combina um vasto leque de outras aplicações também
de código livre tais como o OSSEC, o SNORT, NAGIOS, OPENVAS, entre outros, com esse
propósito o que lhe confere potencialidades diferenciadoras quando analisadas outras soluções.
Esta appliance foi bastante simples de instalar e com os seus assistentes quer de configuração
inicial quer de operação tornam-na numa boa solução a ter em conta por empresas que queiram
uma solução de implementação rápida com foco em análise de informação de segurança de rede,
no entanto salienta-se que a sua performance deixa um pouco aquém as expectativas iniciais,
pois revelou-se uma plataforma lenta a executar os seus componentes comparativamente com a
solução OSSEC.
18 Linguagem de programação interpretada e orientada a objetos
23
3.3 Solução Graylog
Os testes a esta solução foram efetuados na virtual appliance Graylog OVA appliance versão 1.2.2
pronta
a
utilizar
disponível
para
descarga
em
<https://github.com/Graylog2/graylog2-
images/tree/master/ova>. Procedeu-se à sua instalação de acordo com o manual de instalação,
(Anexo3 - Manual de instalação Graylog). O seu funcionamento de acordo com a ilustração
seguinte assenta numa componente servidora (Graylog Server)
capaz de efetuar o
processamento da informação recebida, a sua categorização, a gestão e controlo de acessos, o
armazenamento e os alertas. A receção de informação é feita através de um coletor de dados
(Graylog Collector) que se foca na recolha de dados de dispositivos, sistemas operativos e
aplicações. Utiliza a ferramenta Elasticsearch para efetuar pesquisas e apresentação de
informação sobre os dados processados mesmo em tempo real e assegura o armazenamento da
informação de segurança em bases de dados baseadas em MongoDB, bases de dados
multiplataforma orientada ao documento, normalmente catalogada como sendo NoSQL, ou base
de dados não de consultas estruturadas. A informação tratada pelo Graylog Server é gerida
através de um interface Web (Graylog Web Interface) e funciona por API's REST que também
servem para exportar a informação para outros SIEM's ou utilitários.
24
Nesta fase efetuamos a instalação de um coletor na máquina MS Windows e procedemos à sua
configuração, que basicamente se traduz na alteração de um ficheiro colletor.conf onde
indicamos o endereço HTTP do servidor Graylog2. Após iniciamos a execução do coletor afim de
começar a enviar informação de log da máquina MS Windows para o Servidor. A seguir ilustra-se
o ficheiro de configuração do coletor e o seu estado do lado do servidor.
server-url = "http://192.168.1.26:12900/"
inputs {
win-eventlog-application {
type = "windows-eventlog"
source-name = "Application"
poll-interval = "1s"
}
win-eventlog-system {
source-name = "System"
}
win-eventlog-security {
source-name = "Security"
}
}
outputs {
gelf-tcp {
type = "gelf"
host = "192.168.1.26"
port = 12201
}
}
Tabela 3: Comandos de configuração do coletor Graylog para máquinas Windows
25
Neste área, o Graylog recorre a uma ferramenta intitulada Docker – ferramenta de código livre
para automatizar aplicações dentro de “contentores” isolados dos sistema operativo, adicionando
uma camada adicional de abstração. A ideia é não sobrecarregar o sistema e isolar em simultâneo
a execução de diversas aplicações. Uma vez iniciada a execução de aplicações individuais em
diversos “contentores”, para entrada de dados, o Graylog utiliza um mecanismo proprietário GELF
– Graylog Extended Log Format para normalizar a informação processada nesses “contentores” e
fá-la sair para o STOUT ou STDERR do sistema Graylog Server já formatada, com a adição de
campos importantes sobre cada “contentor” com a finalidade de facilitar tarefas de resolução de
problemas que são os seguintes:
•
Hostname – nome da máquina “Docker”
•
Container ID – identificação do contentor
•
Container Name – descrição inteligível do contentor
•
Image ID – identificação da imagem usada para criação do contentor
•
Image Name – descrição inteligível da imagem
•
Command – comandos executados no contentor
•
Tag – referencia rápida para identificação simples do contentor
•
Creation time – data e hora de criação
•
Log level – campo que indica para onde seguiu a mensagem (STDOUT or STDERR)
(Fonte:<https://www.graylog.org/centralize-your-docker-container-logging-with-graylog-native-integration/>)
Toda a informação processada é convertida em Streams
que é o mecanismo usado para
catalogar os eventos em tempo real enquanto são processadas. Estas Streams podem ser
convertidas em erros com atribuição de níveis que servirão para futuramente configurar alertas.
Exemplos:
campo nível > que 4
campo origem deve validar a expressão regular ^database-host-\d+
Na ilustração seguinte evidencia-se um dos painéis de informação ou dashboards onde nos é
mostrado em tempo real um histograma de eventos, uma grelha de mensagens recebidas e várias
zonas de seleção pesquisa e filtragem. A informação está a ser alimentada por um input
previamente criado do tipo GELF – Graylog Extended Log Format por via TCP e atua nas
mensagens enviadas pelo coletor.
26
Ilustração 14: Dashboard parcial do input
É de referir a facilidade com que se operam estes dashboards, são intuitivos e têm diversos
pontos de ordenação e disponibiliza os campos necessários para efetuarmos ordenações
personalizadas.
O Graylog no que respeita ao armazenamento, utiliza dois componentes principais,
Elasticserach nodes que são responsáveis por armazenar a informação de logs/mensagens
que a sua performance depende do CPU e da RAM do sistema, e o MongoDB responsável
armazenar meta-dados – informação sobre os dados armazenados, e não é muito exigente
termos de recursos do sistema.
27
os
em
por
em
Em termos de regras e normas de compliance, esta solução não fornece sistemas de auditoria ou
outros mecanismos de segurança da sua própria informação, invalidando assim o seu uso em
situações de litígio e questões legais. De acordo com informação recolhida no seu website em
<http://docs.graylog.org/en/1.2/pages/faq.html> verifica-se que é uma funcionalidade que poderá
estar em desenvolvimento e poderá ser disponibilizado em versões futuras.
Reporte
A geração de relatórios e envio de informação de alertas automatizada é outra das áreas que esta
solução não possui. Baseado em informação recolhida no link anterior devido a esta solução ter
muito presente a característica de API's REST para integração com aplicações externas, os
programadores do Graylog deixam um pouco ao gosto de cada um o desenvolvimento das suas
aplicações ou integrações por esta via para colmatar esta falha.
Conclusão
Esta solução mostrou-se bastante ágil no que respeita à velocidade de operação da interface Web
na pesquisa de informação e ambiente de configuração. Não possuindo alguns componentes
como suporte a compliance e os alertas automatizados, mesmo assim graças à sua possibilidade
de interação via API's REST poderá ser a base de um ou mais complementos externos,
desenvolvidos à medida ou não para resolver falta deles.
28
3.4 Solução Prelude-Siem
Procedeu-se à instalação dos componentes desta solução de acordo com o instruções em anexo
(Anexo4– Manual de instalação Prelude-Siem) assente numa distribuição Linux Centos 6.5. Esta
solução é uma variante de código livre à sua solução idêntica mas paga (Prelude Pro) destinado a
organizações de grande dimensão. A versão que vamos analisar é composta por vários módulos:
•
Libprelude: livraria de comunicação entre módulos
•
Libpreludedb: livraria de acesso e gestão da base de dados
•
Prelude Manager: módulo de receção de eventos e armazenamento, limitado nesta
versão a um utilizador ou gestor
•
Prelude Correlator: módulo de correlação de eventos
•
Prelude LML: gestor de ficheiros de log
•
Prewikka: interface para gestão de eventos
De acordo com informação no sítio Internet desta solução em <http://www.preludesiem.com/index.php/uk/products/prelude-oss>, esta versão de código livre destina-se a pequenas
organizações e a instituições de investigação e desenvolvimento, pelo que alertam para a fraca
performance desta à medida que os ativos a gerir aumentam. A sua arquitetura nesta versão de
código livre é composta por sensores que efetuam a deteção de intrusão e geram alertas para um
sistema central, o Prelude manager server. Este manager, por sua vez processa estes alertas e
entrega-os num repositório específico pré-configurado tal como base de dados MySQL, ficheiros
XML, ou qualquer outro formato suportado por extensões nesse sequencia os dados ficam pronto
para serem visualizados pelo Prelude console.
29
A análise da informação é assegurada pelo módulo Prelude-LML, que se trata de um analisador
de logs e faz a coleção da informação e a transforma em alertas do tipo Prelude-IDMEF. Estes
alertas. Este módulo assume particular importância nesta solução pois fornece interoperabilidade
com quase todos os sistemas existentes no mercado. Esta solução é agentless não dependendo
portanto de quaisquer marca de equipamento ou aplicação, por isso, nativamente é compatível
com as soluções AuditD, Nepenthes, ufwi-filterd, OSSEC, Pam, Samhain, Sancp, Snort, Suricata.
Ao nível de logs é de acordo com informação consultada on-line capaz de interpretar a maioria
das soluções de log existentes, IDS, Switchs,SMTP/POP, FTP Server, Web Server, Nessus,
Honeypots, OpenSSH, Selinux… Ao nível da correlação, é usado o módulo Prelude-Correlator, no
fundo um motor de correlação escrito em Python baseado em regras. Consegue ligar-se a um ou
vários Prelude-Manager's e efetuar a correlação à medida que vão chegando os alertas. Em
caso de sucesso, são-lhes aplicadas as regras IDMEF e ao alertas correlacionados são
escalados.
from PreludeCorrelator.context import Context
from PreludeCorrelator.pluginmanager import Plugin
class EventScanPlugin(Plugin):
def run(self, idmef):
source = idmef.Get("alert.source(*).node.address(*).address")
target = idmef.Get("alert.target(*).node.address(*).address")
if not source or not target:
return
for saddr in source:
for daddr in target:
ctx = Context(("SCAN EVENTSCAN", saddr, daddr), { "expire": 60,
"threshold": 30, "alert_on_expire": True }, update = True, idmef=idmef)
if ctx.getUpdateCount() == 0:
ctx.Set("alert.correlation_alert.name", "A single host has
played many events against a single target. This may be a vulnerability scan")
ctx.Set("alert.classification.text", "Eventscan")
ctx.Set("alert.assessment.impact.severity", "high")
Tabela 4: Exemplo de uma regra em Python[5]
No que respeita a monitorização em tempo real, esta solução consegue fornecer uma visualização
através de um interface Web, o seiu módulo Prewikka. Desta forma garante que se possa efetuar
resposta a incidentes num baixo período de tempo. Este interface está programado de base para
efetuar a atualização automática da informação apresentada, mostrando os eventos por ordem
cronológica.
30
O armazenamento faz-se centralmente, normalmente numa SAN-Storage Area Network e em
bases de dados estruturadas. Atualmente este solução suporta MySQL, PosgreSQL e SQLlite. De
forma a garantir segurança na transação da informação, todas as comunicações são encriptadas
ao nível do transporte (SSL) e por via de certificados X509 para autenticação. Para garantir regras
de compliance é sempre efetuado uma cópia dos dados originais no seu formato original pelo
módulo Prelude-LML e como referido a informação é normalizada segundo as normas IDMEF
disponíveis em <http://www.ietf.org/rfc/rfc4765.txt>. A sua base de dados central está desenhada
para manter o rasto forense da informação.
Reporte
Em termos de reporte, o Prelude-SIEM apresenta uma série de relatórios de base com
possibilidade de personalização. Podem ser exportados para diferentes formatos, email, base de
dados, IDMEF XML, ficheiro de texto.
Conclusão
Ao analisar esta solução, consegue-se verificar a existência de todas as características de uma
solução SIEM, no entanto numa escala reduzida, pois o Prelude-SIEM em código livre está muito
limitado comparando com a sua versão paga. Não possui suporte X509 para certificados externos,
tem limitação de análise de 100 eventos por nó por segundo e ao nível de performance não
suporta paralelismo dos seus módulos. Mesmo assim, em cenários de treino e de gestão de
eventos de segurança em pequenas organizações, é uma solução a ter em consideração.
No capítulo seguinte é feita uma reflexão sobre o trabalhado realizado e uma análise crítica do
contributo que cada solução pode dar para colmatar a necessidade que comça agora a ser muito
evidenciada nesta área das TI's. Por fim descreve-se o trabalho a realizar num futuro próximo de
forma a acrescentar valor a este projeto.
31
4. Análise comparativa
Este capítulo reflete uma análise em geral comparativa às soluções SIEM estudadas ao longo
deste projeto e uma análise crítica sobre a melhor solução SIEM de código livre a adotar por uma
eventual organização.
4.1 Análise geral comparativa
Em resultado do estudo efetuado e em análise geral comparativa, verifica-se por parte das
organizações cada vez mais atenção dedicada a esta temática. Garantir a segurança da
informação promovendo implementação de técnicas e mecanismos de SIEM entra agora na lista
de prioridades de cada uma delas.
Atentos a este facto, verifica-se que os principais
desenvolveres das soluções de código livre estudadas tentam aproveitar esta necessidade,
começando a limitar as funcionalidades dos seus produtos de código livre, criando versões
equivalentes pagas mais poderosas e mais funcionais. O caso a Alien Vault empresa que
desenvolve o OSSIM limitou o uso desta solução promovendo uma outra paga o USM. Assim o
OSSIM padece falta de otimização e performance, no entanto continua a ser a solução SIEM
orientada à rede mais completa, pois muitos das outras soluções vêm integradas nela. O caso do
Prelude-SIEM entra no mesmo âmbito, mantido pelo CS Group, este SIEM é uma ótima solução
no que respeita à implementação, pois não recorre à instalação de agentes no entanto foram-lhe
removidas capacidades tais como paralelismo entre os seus módulos, limitando o número de
eventos analisados por segundo, entre outras, afetando assim a sua performance e promovendo a
comercialização do seu concorrente direto pago o Prelude Pro e Enterprise. Por outro lado, a
acentuada procura por parte das grandes empresas em criar SOC - Security Operations Center
ou centros de operações de segurança podem comprometer o fomento das soluções de código
livre, pois derivado da criticidade e o impacto que a segurança da informação dessas empresas
uma vez comprometida possa causar empurram-nas para a aquisição de soluções comerciais ou
pagas.
De acordo com o trabalho, pode-se admitir que no domínio das soluções SIEM de código livre
abordadas existe uma característica presente em todas elas, que é a orientação para análise de
rede, deixando menos aprofundada a análise aplicacional. Outra das curiosidades é que o OSSIM
é a plataforma mais completa no entanto esse facto deve-se a integrar muitas das outras soluções
aqui evidenciadas. Em termos de rapidez de resposta o OSSEC assumiu uma posição relevante
32
em relação às outras soluções mas carece de algum trabalho extra a configurar os agentes que
recolhem dados noutros sistemas. Esta particularidade no OSSIM é resolvida com a instalação
assistida do lado do servidor, facilitando assim o trabalho de implementação. Estas duas soluções
são mais indicadas para implementação em organizações com maior elevado número de ativos, e
portanto maior número de eventos de segurança para analisar. O Graylog2 não deixa de ser
menos importante e o que o melhor o define é a falta de funcionalidades SIEM contudo deixa aqui
em aberto um enorme potencial a explorar na integração com outras soluções por via da utilização
das API's REST disponibilizadas. O Prelude-SIEM em pequenas organizações é a solução mais
indicada, pois reúne todas as valências de um SIEM e é de simples usabilidade ainda que
limitadas em performance. Na tabela que se segue resume-se as principais funcionalidades
encontradas em cada solução de acordo com os focos de teste efetuados no capítulo anterior.
Funcionalidade
Solução SIEM
OSSEC
OSSIM OSS
GRAYLOG2
PRELUDE-SIEM
Recolha de dados
X
X
X
x
Análise em tempo real
X
X
X
x
Correlação de informação
X
X
X
x
Compliance
X
X
-
x
Armazenamento
X
X
X
x
Reporte
X
X
-
X
~14.000
~5.000
~10.000
~10.000
Excelente
Razoável
Boa
Excelente
EPS
(Eventos por segundo)
Performance Geral
Tabela 5: Comparação de funcionalidades presentes em cada SIEM
De acordo com a tabela anterior, verifica-se que o Graylog2 não possui de base suporte em
termos de compliance, nem alertas automáticos e relatórios, deixando assim esta solução um
33
pouco atrás em relação às outras. Os ambientes gráficos das soluções estudadas estão mais ou
menos enquadrados na mesma categoria, pois todos utilizam interfaces Web na interação com o
operador. Por ordem de usabilidade e qualidade destes interfaces o OSSIM assume a primeira
posição, seguido do OSSEC e GRAYLOG, em que neste último apesar de não ser o mais
agradável é sem dúvida o mais rápido no retorno da informação. Ao nível da documentação de
apoio técnico e de instalação no geral todas disponibilizam o suficiente, sendo que a forma de
apresentação da informação na solução PRELUDE-SIEM é mais rudimentar. O suporte nas
nestas soluções em geral, talvez por serem de código livre, assenta em fóruns ou blogs de
discussão online onde a comunidade em geral de utilizadores e membros das equipas de
desenvolvimento partilham os problemas e soluções.
Salienta-se o facto dos testes efetuados não serem totalmente objetivos uma vez que o seu uso
foi limitado a poucos ativos, sendo que testes mais aprofundados em cenários com muitos ativos
físicos poderia-nos dar uma visão geral um pouco diferente.
4.2 Análise crítica e conclusões
Nesta linha de análise pode-se concluir que a melhor solução SIEM de código livre é difícil de
escolher pois os cenários reais com que nos deparamos são muito heterogéneos, com níveis de
criatividade diferentes de organização para organização e com disponibilidade de recursos a
alocar nesta área também muito variada. A título de exemplo, caso estejamos a tratar um grande
número de eventos e ativos a gerir, a solução ideal a adotar seria o OSSIM, por se tratar da
solução mais completa pois para além de cobrir todas as áreas importantes de um SIEM, acaba
por integrar muitas das outras soluções as quais se destaca o OSSEC, NAGIOS, OSIRIS, SORT,
etc...
e fornece uma base sólida de arranque nesta área, no entanto se necessitarmos de
implementar esta solução, teremos de ser bastante generosos em termos de recursos físicos
nomeadamente memória e processador pois esta plataforma assim o exige afim de ser
minimamente eficiente. Para casos mais simples e ou redes de ativos menores a solução mais
eficiente é o Prelude-SIEM, combinando todas as valências necessárias à recolha e tratamento de
informação, não sendo muito exigente em termos de recursos físicos de memória e processador
mas tendo limitações de processos concorrentes face aos produtos equivalentes pagos ou com
fins comerciais. Podemos concluir que a escolha de um SIEM de código livre, é sem dúvida uma
tarefa exigente e nada fácil, deve ser ponderada e selecionada de acordo com a dimensão de
cada empresa ou organização.
34
4.3Trabalho futuro
Devido ao grau de complexidade que cada solução testada exprime, de futuro, seria uma mais
valia a execução de testes aprofundados com ativos reais e comprovar a quantidade de eventos
de segurança por segundo (EPS) que cada solução consegue analisar, dando assim um ponto
muito relevante na escolha da melhor solução. Será interessante também acompanhar a evolução
dos SIEM's e dos de código livre afim de confirmar a convergência das melhores soluções em
código livre em soluções comerciais pagas. Outro aspeto a verificar será o posicionamento desta
vertente das TI's, será que as organizações implementarão as soluções SIEM de código livre
dentro de portas ou tenderão a delegar esta área em prestadores de serviços externos?
35
5. Conclusão
É certo que a relevância desta temática está a assumir atualmente um nível elevado. A decisão de
utilizar uma ferramenta SIEM ou não e de código livre acarreta uma enorme responsabilidade por
parte do responsável pela segurança da informação. Neste contexto e com este relatório
pretendeu-se contribuir com disponibilização de mais informação nesta matéria e focada nos
aspetos essenciais de que cada solução SIEM de código livre face às funcionalidades efetivas que
um SIEM deve ter. Esta, além de outras funções é uma área em que um especialista em
segurança deve poder dar o seu contributo, fazendo com que as empresas ou organizações
sejam bem sucedidas na implementação de sistemas de proteção da sua informação e na análise
dos eventos críticos com ela relacionada.
36
Referências bibliográficas
1: Gartner, Magic Quadrant for Security Information and Event Management, 2015
http://www.gartner.com/technology/reprints.do?id=1-2JM4RVZ&ct=150720&st=sb
2: Andrew Hay, Daniel Cid, Rory Bray, OSSEC Host-Based Intrusion Detection Guide, 2008
3: Alien Vault, Correlation Reference Guide, 2015,
https://www.alienvault.com/doc-repo/usm/securityintelligence/AlienVault_Correlation_Reference_Guide.pdf
4: Alien Vault, AlienVault Professional SIEM and AlienVault Open Source SIEM (OSSIM, 2015)
https://www.alienvault.com/products/ossim
5: Graylog, Graylog Architecture, 2015, https://www.graylog.org/architecture/
7: Mitchel Anicas, , 2014, Graylog2 Installation Guide
https://www.digitalocean.com/community/tutorials/how-to-install-graylog2-and-centralize-logs-onubuntu-14-04
8: Jean-Philippe Lang, , 2014, PreludeArchitecture,
https://www.prelude-siem.org/projects/prelude/wiki/PreludeArchitecture
9: Website da solução OSSEC. Página e subpáginas consultadas em 01-08-2015,
http://www.ossec.net/
10: Centro de documentação da alienvault, “categoria OSSIM”. Página e subpáginas consultadas
em 15-09-2015. <https://www.alienvault.com/forums/categories>
11: Páginas e vídeo sobre o passado, presente e futuro de SIEM, por Mike Rothman, presidente
da Securosis “categoria SearchSecurity”. Página e vídeo consultados em 26-10-2015.
<http://searchsecurity.techtarget.com/video/The-past-present-and-future-of-SIEM-technology>
37

Estgf - Instituto Politécnico do Porto

Transcrição

Documentos relacionados

Política de Privacidade do SIEM Web

OSSEC 4 Conceitos O OSSEC é um HIDS (Host

Termo de Uso do SIEM Web

Diapositivo 1

Descobrir Angkor 4 dias

Guia de Regras – TGG

LOG IN Patrícia Sousa 02 May – September 2015 ROSA ET AL

Boletim MPA 2010 versaoFinal

Vietnã e Camboja

WhatsUp Event Log Management Suite