A história — e os desafios — dos firewalls de próxima geração

Há cerca de dezesseis anos, em 2007, a Palo Alto Networks lançou seu primeiro produto, alterando para sempre a segurança da rede. O termo “Firewall de próxima geração” ou NGFW, ainda não havia sido cunhado. Isso aconteceria quando a Gartner introduziu o termo em 2009. Na época, os produtos da Palo Alto se enquadravam no termo anterior “Unified Thread Management”, ou UTM. Embora Palo Alto não tenha inventado o UTM ou o NGFW, eles se tornaram o produto definidor nesse espaço, contra o qual todos os concorrentes são comparados. Para os fins desta postagem, usaremos apenas o apelido NGFW para simplificar.

Embora o que hoje chamamos de “nuvem” certamente existisse em 2007, os data centers ainda estavam sendo construídos da maneira tradicional: uma camada rígida de segurança em torno de um centro macio e pegajoso de dados e computação. Somente as organizações mais ousadas estavam transferindo ativos para a AWS (Amazon Web Services) e outras novas serviços em nuvem. O data center ainda tinha um limite definido e conhecido. As linhas estavam claras entre os ativos dentro do data center e os do lado de fora. ‍

NGFws: perfeito para proteger o perímetro do data center

O NGFW, com seu conjunto de recursos de segurança poderosos, foi uma ótima opção para esse modelo. Os NGFWs rapidamente se tornaram os guardiões dos data centers, controlando cuidadosamente o que entrava (e, em muito menor medida, o que saía) de uma determinada rede. CPUs personalizadas poderosas analisaram e moveram pacotes rapidamente, e as pessoas encarregadas da segurança dormiram um pouco melhor à noite, sabendo que seus ativos estavam protegidos por um conjunto de novas ferramentas.

NGFW fornecedores como Redes de Palo Alto, a Check Point e a Fortinet agora estabeleceram uma nova meta: dominar o data center, monitorar e controlar o tráfego entre aplicativos, como segmentação de rede entrou em voga como a “novidade quente”.

Aqui, porém, eles enfrentaram um desafio muito maior. Os NGFWs foram uma escolha óbvia para proteger o perímetro do data center. O custo proibitivo de hardware, licenciamento e suporte foi justificado pelos claros benefícios, e o preço foi controlado pelo fato de que as conexões de Internet aos data centers eram relativamente lentas em comparação com a conectividade interna, e o preço sobe com a largura de banda. No interior, no entanto, não foi encontrada nem de perto uma relação custo/benefício tão clara. Uma porcentagem significativa de Características do NGFW, considere a mitigação de DDoS ou a modelagem do tráfego como exemplos, não tinham valor interno. Mas você pagou por eles, independentemente.

Como se o custo impressionante de 10 G de produtividade não fosse suficiente para impedir o uso interno, cada custo foi dobrado por uma questão de redundância. Era extremamente difícil justificar cinco vezes o gasto de um firewall tradicional com um conjunto de recursos que eram exagerados e, muitas vezes, não eram relevantes para a tarefa em questão.

Dito isso, as regulamentações do setor e do governo exigem certos controles internos, pelo menos para determinadas classes de aplicações. HIPPA e PCI vêm à mente como exemplos de destaque. Então, os clientes optaram por soluções híbridas, com dispositivos NGFW protegendo o limite e algumas aplicações críticas e específicas, com os tradicionais NGFWs com estado, ocupando a lacuna da proteção interna. Esse casamento infeliz entre o antigo e o novo funcionou por um tempo. Até a aceitação geral da nuvem pública.

Gerenciando a complexidade do NGFW na nuvem

A nuvem pública virou o mundo da segurança de cabeça para baixo. Mas não para todos, e nem sempre de maneiras óbvias.

Lembre-se de que os NGFWs realizam uma quantidade impressionante de processamento em cada pacote que passa pelo chassi. A arquitetura Intel, por mais onipresente que seja, é uma escolha ruim para a quantidade épica de trabalho de baixo nível a ser feito em um NGFW. A Palo Alto escolheu os processadores de rede Cavium para fazer toda essa inspeção e manipulação de pacotes de baixo nível. A Fortinet projetou seus próprios processadores internos para clientes para fazer o trabalho.

O NGFW de hoje, pelos padrões de apenas uma década atrás, é um supercomputador da classe de uma agência governamental, o que certamente responde por parte do custo. Os fornecedores de NGFW responderam rapidamente à mudança para a nuvem com versões virtuais de seus produtos, mas o desempenho foi péssimo em todos os setores devido às limitações da arquitetura Intel.

Isso resultou em grandes mudanças na forma como a segurança era tratada na fronteira das redes em nuvem. Muitas vezes, dezenas de firewalls virtuais tinham a carga balanceada. As redes foram rearquitetadas para ter muito mais pontos de peering de Internet do que na época tradicional, reduzindo os requisitos de desempenho por firewall. E os fornecedores de firewall começaram a vender suas implementações de VM (máquina virtual) em pacotes de seis e dez pacotes, porque um ou dois firewalls não podiam mais fazer o trabalho.

Se isso parece complexo de criar e gerenciar, tenha pena da empresa mais típica que transferiu apenas uma parte de seus ativos para a nuvem. Como ambos IaaS (infraestrutura como serviço) e PaaS (plataforma como serviço) proliferados, os limites da rede começaram a se tornar cada vez mais indistintos. Embora a definição de “nuvem” relacionada à TI tenha sido derivada da ideia de um grande número de computadores (análogos ao vapor de água) vistos juntos como um à distância, começou a se tornar mais apropriado usar uma definição diferente: “Algo que obscurece ou mancha”.

Quando os data centers começaram a hospedar uma seleção aleatória de aplicativos e partes de aplicativos na nuvem, com outros aplicativos (e partes de aplicativos) permanecendo no local, ficou incrivelmente difícil protegê-los e aplicar a política de segurança. Isso ocorre principalmente porque se tornou quase impossível definir limites, onde a segurança é normalmente aplicada. E mesmo nos casos em que os limites eram claros, o grande volume de hardware, software e configuração de segurança se tornou impressionante.

Como resultado, a segurança deu um grande passo atrás.

Olhando para o futuro: recursos do NGFW em um ambiente de microssegmentação

Assim começou a área do que era conhecido nos primeiros dias como microsegmentação, e o que agora é mais frequentemente chamado de Zero Trust Segmentation (ZTS).

O conceito de microssegmentação é simples: aplicação de políticas (ou seja, firewalls) em todos os servidores, controlando o tráfego de entrada e saída para todos os outros servidores. Fundamentalmente, a microssegmentação é simplesmente uma extensão da ideia de segmentação de rede levada ao máximo (um firewall por servidor). A microsegmentação deu às equipes de segurança uma nova ferramenta poderosa para lidar com os “limites difusos” em torno e dentro de nossos data centers, abordando a segurança servidor por servidor (ou pelo menos aplicativo por aplicativo).

Historicamente, a microssegmentação lidou com portas e protocolos sem mergulhar no território de inspeção profunda necessário para os recursos do NGFW.

No escritório do CTO, meu trabalho é jogar “e se?” e tente analisar possíveis problemas futuros e suas possíveis soluções. Assim, a pesquisa atual na Illumio inclui a análise das possibilidades de implementação de recursos NGFW em um ambiente de microssegmentação.

Leia meu blog na próxima semana para saber mais sobre a pesquisa da Illumio e esses possíveis desenvolvimentos futuros em microssegmentação.