02/03/2014
Com a palavra do Gestor em TI da IDS
Assunto:SIEM
Segurança de TI é como uma torre de babel. Ao longo dos anos as empresas vão acumulando produtos e tecnologias diversas para cada tipo de ameaça ou função de segurança. Uma empresa de grande porte terá pelo menos dez tecnologias implementadas, não só em dispositivos diferentes como de fabricantes distintos. Para piorar é normal que produtos diferentes sejam usados para atender a mesma necessidade, como firewalls de vários fabricantes. Por sua vez cada fabricante consolida os eventos de seus produtos em consoles próprias, com óbvias limitações para importação de dados de outros, quando essa possibilidade existe. Além disso há dados relevantes nos logs de servidores que necessitam ser consolidados e processadas. O resultado são dados dispersos em diferentes sistemas e uma imensa dificuldade para gerar informação.
A integração de eventos e dados de segurança não é nenhuma panaceia, porém é necessária para algumas funções como compliance, investigação de incidentes e gerenciamento de ameaças. Em empresas com quantidade menor de eventos de segurança essa tarefa pode ser realizada manualmente, mas quando há milhares ou milhões de eventos isso se torna impossível. Assim o processo natural é o de adquirir um sistema SIEM (security information and event management), de gerenciamento de eventos e informações de segurança, na esperança de por ordem na bagunça. Infelizmente a implementação falha ou f**a aquém das expectativas em muitas empresas. É importante entender os motivos ou ao menos discutir algumas possibilidades.
Um sistema SIEM é por principio complexo, concebido para importar dados das fontes mais variadas possíveis, consolidar, processar, correlacionar, comparar e por fim gerar alguma informação relevante para o seu usuário. É também por principio um sistema de várias faces, ou possibilidades de uso. Parte desse último aspecto vem do fato que os sistemas atuais evoluíram de dois outros tipos de aplicação: os chamados SIM (security information management) e SEM (security event management), parecidos no nome mas diferentes na função. O primeiro foi uma evolução do sistemas de gerenciamento de logs especializado em segurança. Suas fontes principais são dispositivos diversos de rede, servidores e aplicações. Já o SIEM foi criado para consolidar e correlacionar eventos gerados por produtos de segurança. Como ambas funções são próximas nada mais natural que houvesse uma convergência.
Mas as possibilidades são muitas, indo além da pura consolidação de logs e eventos. O sistema pode ajudar na administração de compliance - a adequação da empresa às normas regulatórias, gerenciamento e investigação de incidentes, gerenciamento de ameaças em tempo real e gerenciamento de riscos em geral. Aqui vemos o primeiro problema, a aquisição e instalação de um SIEM sem embasamento de um projeto. Em outras palavras, o software precisa ser a ferramenta de um projeto, e não o projeto em si. Adquirir um sistema como ponto de partida é o primeiro equivoco e um atalho para problemas. A empresa portanto necessita de um projeto claro e de metas, até porque elas irão ajudar a definir qual é o melhor produto, o que não é tarefa fácil pois há no mercado mais de 50 produtos classif**ados como SIEM. O Gartner Group em seu famoso Quadrante Mágico pontua 24 produtos diferentes no relatório de 2011, sete deles no quadrante de líderes. O relatório inclui também uma solução baseada em código aberto. É natural portanto que existam produtos melhores em uma determinada função que outros.
Há outros dois pontos cruciais em qualquer projeto. O primeiro deles é levar em conta as fontes de dados as quais se deseja consolidar e a maneira como isso ocorrerá. Plataformas conhecidas irão contar com agentes nativos, outras irão exigir algum desenvolvimento ou configuração por syslog ou outros. O cliente deverá levar isso em conta antes e não depois da aquisição. A quantidade de fontes de dados influi também na capacidade de armazenamento, que deverá ser parte do projeto. O objetivo do projeto também influi nesse quesito. Se a empresa tem investigação de incidentes passados como meta, ela deverá definir o período de guarda dos dados e incluir na estimativa de capacidade. Se a meta é estar em conformidade com normas ou leis, o prazo pode alcançar a anos, com muitos terabytes de dados. Mas não é só capacidade. O desempenho da arquitetura de armazenagem pode influir muito no tempo de resposta da solução, sobretudo se utilizada para o gerenciamento e correlação de eventos em tempo real.
O segundo ponto é a equipe que irá operar o sistema. Funções tão variadas exigem perfis profissionais também variados. Como será a manutenção do sistema? Não digo do software mas das regras nele configuradas. A correlação de eventos, por exemplo, baseia-se em regras. Boa parte já vem inclusa no pacote inicial mas muitas outras deverão ser criadas para o que o sistema adapte-se à empresa e possa fornecer a informação que se espera dele.
Já compliance e investigação exigem outros perfis de regras e análise. Uma implementação mal planejada irá inundar a equipe com eventos que para eles não farão sentido, e que portanto serão ignorados. Os usuários irão também variar de acordo com a função, pois os administradores de compliance, risco e segurança de rede são normalmente pessoas diferentes.
A conclusão vale para qualquer produto mas é mais importante para sistemas caros e complexos. Primeiro o cliente precisa comprar bem, o que signif**a saber o que quer a curto, médio e longo prazos, sem menosprezar o tempo e recursos necessários para a implementação, nunca esquecendo-se que não há software que faça milagres.
