A TI tradicional tem sim muito a oferecer em relação a melhores práticas e tecnologias de Segurança da Informação, mas uma delas não são os Intrusion Protection Systems. Acho que a tecnologia é boa, mas demorou muito a chegar. Os firewalls de ponta hoje já executam estas atividades de forma integrada ao nível de rede e os principais anti-vírus de mercado, possuem funções de proteção para o host que dispensam em grande maioria dos casos a necessidade de mais um software adicional.
Além do overhead administrativo que mais um software cria – mais uma licença, mais uma console, mais memória e CPU, mais um contrato de manutenção e suporte – enfim, um software dedicado que só faz intrusion protection, acho dispensável. Da mesma forma ao nível de rede, uma caixa a mais acrescenta latência à rede, o que representa perda de banda efetiva disponível para as aplicações. Claro que, um firewall que realiza inspeção avançada, também vai adicionar um pouco mais de latência do que um firewal tradicional, mas com o uso de QoS isso pode ser contra-balanceado. O problema é maior quando a rede em questão é uma rede de processos, aí o IPS tem que se justificar muito para valer a pena. Quando vejo uma rede de automação sendo segregada da rede corporativa com o uso exclusivo de um IPS fico muito preocupado. Principalmente, porque tal inciativa mostra que o projetista da solução tem pouco conhecimento sobre IPS de rede e ainda menos sobre redes de automação. Tecnologia mal aplicada é dinheiro jogado fora e os IPS, ao contrário do que prometem os fabricantes, não é uma panacéa. O projetista que usa o IPS como único mecanismo de segregação de redes ignora um dos princípios básicos da segurança, o “Princípio do Menor Privilégio”.
De acordo com este princípio, num sistema seguro, tudo que não for explicitamente permitido, deve ser proibido. Aplicando esta idéia ao desenho de perímetros de rede, podemos dizer que todo tráfego que não for explicitamente permitido deverá ser bloqueado. Assim, a primeira coisa a fazer para proteger a rede de automação é bloquear tudo que não for permitido, através de access control lists. Ora, um IPS não agrega nada demais quando o tráfego já é previamente bloqueado, pois não resta nada para ser checado. Lembrem-se que pelo seu princípio de funcionamento, o IPS irá inspecionar o tráfego que passa através dele e irá bloquear pacotes que carregam conteúdo malicioso, como vírus, scans e exploits, tudo isso até mesmo na camada de aplicação. Um bom projetista deve saber quais protocolos representam alto risco para a rede de automação e irá bloquea-los de acordo, restando pouco ou nada para o IPS fazer. Se no entanto, após a configuração dos bloqueios, ainda tivermos algumas regras permitindo a comunicação entre as redes de processo e a corporativa (senão, pra que conectar as redes?), teremos que dar ainda mais alguns passos. Vejamos.
Uma grande dor-de-cabeça, na minha opinião, herdada dessa migração que os sistema de automação estão fazendo para o ambiente Windows é o OPC (ole for process communication). O OPC é baseado na arquitetura DCOM que a Microsoft desenvolveu para a plataforma Windows e é este protocolo por onde se instalam e se reproduzem os principais worms e vírus que temos notícia, como o blaster, sasser e mytob, só para citar alguns. Então, após configurar o firewall você descobre que tem que permitir as portas do DCOM para que os drivers e o servidor OPC se comuniquem corretamente. É nessa hora que o IPS irá entrar na jogada. Mesmo com a regra do firewall permitindo o tráfego, o IPS irá atuar bloqueando os pacotes perigosos ao mesmo tempo que permite que o tráfego legítimo flua normalmente. Muito bom, né? Seria, se o seu firewall já não tivesse esta capacidade embutida. Os principais nomes do mercado como Juniper, Cisco Systems, Nokia, StoneGate, SonicWall e Check Point já trazem consigo algum recurso de proteção nos mesmos moldes do IPS. Daí, é lógico que não basta dizer que o IPS é inteiramente dispensável, tem que ser feita uma análise de custo/benefício e das particularidades de cada ambiente. Mas na maioria dos casos, principalmente onde o firewall está configurado apenas para permitir o tráfego na direção planta->escritório, ele deve ser o suficiente.
Em resumo, o que eu quero dizer é que se for para otimizar custos, comece com o firewall e deixe o IPS para depois (jamais o contrário!). Com um bom design de perímetro e uma boa configuração de regras é possível sim desenhar um ambiente confiável apenas com um bom firewall as mãos.
Então, a discussão é polêmica ou não? Qual sua opinião? Escreva-a aqui nos comentários.
30 Janeiro, 2008 às 4:02 pm |
Aproveito para parabenizá-lo pela iniciativa deste blog. Acabei de ser apresentado a ele e pretendo me tornar visitante assíduo.
Uma característica importante dos principais IPSs (no que tange a disponibilidade) é o fato de poderem ser configurados como dispositivos “fail open”. Firewalls, por conceito, não devem ser configurados dessa forma.
Em poucas palavras, se o meu Firewall falhar, eu quero que por default, ele deixe de rotear tráfego e impeça qualquer acesso aos ativos protegidos por ele. Já o IPS, caso falhe, eu quero que o tráfego continue fluindo, mesmo que este não esteja mais sendo analisado.
Assim, apesar de concordar com você, e acreditar que as soluções de inspeção de tráfego que a Checkpoint e outros estão embutindo nos Firewalls pode ser suficiente para muitos casos (tendência prevista e recomendada pelo Gartner em seu Hype Cycle for Information Security, 2007) , gestores de segurança de ambientes com alto requerimento de uptime devem avaliar appliance IPSs sim.
30 Janeiro, 2008 às 11:59 pm |
Olá Geraldo! Obrigado pela participação. O blog está um pouco abandonado porque estou sem tempo de atualizá-lo, mas isso porque minha rotina mudou muito recentemente com a chegada do meu filho, mas agora já estou voltando ao ritmo e em breve vou publicar muita cosia que tá na fila por aqui.
Sobre a questão de transparência para a rede, existe uma diferença filosófica entre um elemento de segurança de rede para proteger um perímetro externo, como a Internet por exemplo, e outro usado para melhorar a proteção de um perímetro interno. Como elemento de segurança de rede, entenda como firewall, IPS, application gateways etc. No primeiro caso, o princípio filosófico básico é “bloquear tudo o que não for explícitamente permitido”, por que a rede externa em questão trás muito mais riscos para o negócio e isso se reflete na decisão do downtime, ou seja, se o meu firewall de Internet cair, eu concordo com você, pois vou querer que ele pare de rotear também. No entanto, é cada vez mais comum o uso de firewalls em redes internas, por várias razões, por exemplo como uma ferramenta de resposta à incidentes para criar áreas de quarentena, DMZs internas etc. Ocorre que neste segundo caso, a filosofia é exatamente oposta “permite tudo o que não for explicítamente proibido”. Nesse caso, se o firewall cair é interessante que o tráfego flua, assim como no IPS e os fabricantes já descobriram isso porque os firewalls mais modernos podem operar em modo bridge, sem participar do roteamento. É claro que muitas funcionalidades, como o NAT, se perdem nesta configuração e por isso ela não é indicada para perímetros externos por exemplo. Mas num cenário onde o que se deseja proteger é a rede de processos, onde a disponibilidade é por muitas vezes mais importante do que todo o resto, o firewall em modo bridge pode proporcionar a continuidade em caso de falha, bastando para isso retirá-lo do enlace manualmente ou instalando-o com um patch panel especial, que permite o bypass de tráfego quando o elemento de rede ativo que está no caminho venha a falhar.
Espero ter me explicado melhor. E aí, o que acha? Qual sua opinião?
Abraços e volte sempre.
jcfaial