Netflow no Gerenciamento e Segurança de Rede

Nesse post reproduzo artigo de minha autoria publicado na revista RTI - edição de Julho/12. Vocês poderão ver a edição virtual da revista em http://www.arandanet.com.br/midiaonline/rti/index.html 

As áreas de rede e segurança trabalham como duas retas paralelas na maior parte das empresas, com interesses diferentes porém não antagônicos. Enquanto a primeira se preocupa em fazer com que os dados trafeguem o mais rápido possível até o seu destino, a outra procura garantir que cheguem com segurança.  Um observador externo diria com razão que esses objetivos são na verdade complementares, já que os dados precisam trafegar ao mesmo tempo com velocidade e segurança.  Mas é de outro ponto em comum que gostaria de comentar nesse artigo: ambos tem a mesma deficiência: falta de visibilidade da rede. Tanto os administradores de rede como de segurança gerenciam equipamentos limitados em fornecer uma visão completa sobre o tráfego que passa pela rede. Essa limitação não afeta inicialmente os objetivos de cada área, mesmo com ela é possível garantir os requerimentos de velocidade e segurança, mas visibilidade significa conhecimento. Ao se conhecer melhor e mais profundamente o tráfego aumenta-se consideravelmente a eficiência da administração.

Foi certamente levando isso em consideração que a Cisco criou em 1996 o protocolo Netflow para coleta de informações de tráfego. Em poucos anos se tornou o padrão da indústria e motivou o IETF a iniciar um grupo de trabalho para a criação de um padrão formal, IPFIX (Internet Protocol Flow Information eXport), definido em várias RFCs e presente na maior parte dos switches e roteadores de diferentes fabricantes. É interessante observar que apesar do nome criado pela IETF e por concorrentes, como JFlow pela Juniper e NetStream pela 3Com, hoje HP, o termo original continuou como o mais usado, mesmo por aqueles que não são usuários Cisco. A versão mais atual e base das RFCs é a 9 embora a mais utilizada seja a 5.

O serviço está baseado na coleta das informações básicas dos fluxos de comunicação de rede e seu envio a um analisador que irá gerar informações gerenciais como a base de referencia (baseline) do tráfego, os protocolos mais utilizados ou um mapa completo da comunicação de rede. A coleta ocorre normalmente no próprio equipamento de rede embora haja produtos especializados nessa função, chamados de coletores. O seu êxito está em responder às perguntas de “quem”, “o que”, “quando”, “onde” e “como” em relação à rede.  É importante ressaltar que ele não inclui a inspeção total dos pacotes (deep packet inspection), a única forma de dizer com precisão o que está sendo transmitido.  Mas para a administração pura de rede, que não leva em conta segurança, essa informação não é necessária e os benefícios são muitos: planejamento de capacidade, previsão de crescimento de rede, planejamento de QoS, detecção de anomalias, remanejamento de equipamentos ociosos, entre outros.  Por tudo isso sua implementação e uso é recomendado para empresas de qualquer porte e tamanho de orçamento. Há inclusive versões disponíveis de analisadores e coletores em código aberto.

Uso em Segurança

Por permitir a detecção de anomalias o protocolo passou rapidamente a ser utilizado também em segurança, já que um ataque de rede, interno ou externo, é por definição uma anomalia. Há quem inclusive defenda que essa deveria ser a forma como as empresas detectam ataques de rede, em crítica direta à segurança de perímetro representada pelos firewalls e IPS. Eu discordo e defendo o uso combinado, para não dizer integrado, dessas tecnologias. A segurança de perímetro ainda é o melhor filtro de tráfego indesejado e é ainda insubstituível. Por outro lado há carências que são supridas pela detecção de anomalias. 

A primeira delas é a segurança da rede interna, normalmente implementada com os mesmos produtos utilizados no perímetro.  É muito complexo e dispendioso analisar todo o tráfego interno com produtos instalados em determinados segmentos de rede. Complexo porque dificilmente uma rede de grande porte terá um só ponto onde se poderá instalar um único equipamento. Dispendioso porque o volume de tráfego será bem mais alto, exigindo produtos mais parrudos.  Como os dados de netflow são coletados nos equipamentos de rede já existentes, por onde passa todo o tráfego de rede, ambos temas são solucionados. A segunda carência é justamente relacionada aos ataques DoS e principalmente DDoS, áreas em que firewalls e IPS são limitados. Para isso a detecção de anomalias é bem mais eficiente. A terceira é que por mais avançado que seja, um equipamento perimetral ainda depende de assinaturas ou algoritmos para detectar um ataque. Algo completamente novo não será detectado, mas pode (repito, pode) ser detectado como anomalia.

Mais recentemente a Cisco expandiu o uso do protocolo em segurança ao criar o NSEL (NetFlow Security Event Logging), extensão do Netflow implementada em firewalls que inclui informações de como um determinado fluxo foi tratado pelo dispositivo, ou seja, se os pacotes foram ou não bloqueados. Essa informação já é exportada pelos firewalls através de eventos syslog ou outros métodos, mas de acordo com os entusiastas há vantagens em concentrar tudo em um único analisador, além é claro de melhorar os resultados gerenciais, que dirão não somente se há um flow anômalo mas também se este flow foi ou não bloqueado por um firewall. Esse é um ótimo exemplo de integração de segurança perimetral com detecção de anomalias.

Outra maneira de integrar Netflow, firewalls e IPS é via os sistemas SIEM, abordados nos últimos dois artigos aqui na RTI. Quanto mais informação é recebida pelo sistema melhor será seus alertas, relatórios e ações relativas a compliance e resposta a incidentes.  Em geral o SIEM não receberia diretamente os dados de flow mas eventos gerados pelo analisador, como um alerta de desvio de baseline, computador desconhecido comunicando-se ou outra anomalia. Nenhuma das três possibilidades de uso do Netflow em segurança são excludentes, muito pelo contrário, e dependendo da situação particilar de cada empresa há vantagens claras em utilizar todas elas.

SIEM

** Esse artigo, assim como a maioria dos textos do blog, foi publicado em minha coluna mensal na revista RTI **

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 fica 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 classificados 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 significa 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.