Explorando o uso da funcionalidade NGFW em um ambiente de microssegmentação

Por quase duas décadas, firewalls de próxima geração (NGFWs) têm sido uma ferramenta de segurança essencial. Mas, à medida que as redes atuais se tornam cada vez mais complexas, a proteção perimetral oferecida pelos NGFWs resolve um problema que está se tornando cada vez menos relevante.

A Illumio está pesquisando as possibilidades de implementar recursos NGFW em um microsegmentação ambiente, combinando as duas tecnologias para oferecer o tipo de segurança exigido por redes complexas.

Em parte um, analisei a história, o valor e os desafios dos firewalls de próxima geração (NGFWs).

Neste segundo artigo, falarei sobre o “e se?” cenário de incorporação de um subconjunto da funcionalidade NGFW em uma solução de microssegmentação. Falarei sobre diferentes casos de uso e quais recursos do NGFW podem ser adequados para cada um.

Os NGFWs trabalham para o tráfego norte-sul, mas têm dificuldades com o leste-oeste

O NGFW foi projetado com base na ideia de proteger o perímetro de uma rede e, em grande parte, na proteção contra ameaças no tráfego de entrada. No mundo da rede, esse tipo de tráfego geralmente é chamado de “norte-sul”. Essa terminologia deriva da prática generalizada de desenhar uma rede com a “bolha” da Internet no topo, com o tráfego fluindo para o data center viajando de cima para baixo ou de norte a sul. O tráfego dentro do data center normalmente é desenhado como se movendo lateralmente, da esquerda para a direita ou da direita para a esquerda e, portanto, geralmente denominado “leste-oeste”.

Usando essa terminologia, pode-se dizer que há um caso de uso poderoso para NGFWs usados em uma função norte-sul, como falei na primeira parte. Mas o caso de uso para leste-oeste é um pouco menos certo. Esta segunda afirmação provavelmente levantou alguns fios de cabelo na nuca, então deixe-me ser um pouco mais específico sobre essa afirmação.

Os firewalls custam três tipos de dinheiro: hardware, manutenção/suporte e configuração/monitoramento. Apesar do alto custo em todas as três categorias, o ROI dos NGFWs é bastante claro para o caso de uso norte-sul. Quando se trata de leste-oeste, verifica-se que apenas um subconjunto de recursos completos do NGFW é relevante, mas os fornecedores não oferecem descontos por não usar o conjunto completo de recursos. Muitas vezes, é difícil justificar a compra completa de um dispositivo NGFW e usar apenas metade da funcionalidade, ainda mais nos casos em que o conjunto de recursos NGFW não é exigido por lei ou regulamento.

NGFWs para tráfego sul-norte

Esses são dois dos bons casos de uso de um NGFW, mas na verdade há um terceiro que as pessoas raramente consideram, exceto de passagem: o caso de uso sul-norte ou, em inglês, controlar o tráfego de saída de dentro da rede. Os fornecedores do NGFW falam sobre isso, mas só um pouco. E a maioria das organizações, embora esteja ciente da ameaça de conexões externas irrestritas, faz muito pouco para realmente lidar com isso. Ao trabalhar com muitos clientes ao longo dos anos, descobri que a maioria das organizações nem mesmo tem um processo em vigor para que seus proprietários internos de aplicativos solicitem controles externos na fronteira da rede.

Meu trabalho é basicamente P&D, com um forte foco na parte “R”. Nesse sentido, vamos fazer um experimento mental. Por um momento, considere o problema norte-sul resolvido. Isso não é resolvido no sentido de que não há uma solução 100% perfeita, mas no sentido de que a maioria das organizações não considera mais esse caminho como a principal via de ataque às suas redes. Em vez disso, vamos pensar em como as redes poderiam se tornar mais seguras se você pudesse implementar recursos NGFW selecionados em sua solução de microssegmentação e melhorar seus controles NGFW leste-oeste e sul-norte, sem precisar comprar mais equipamentos ou combater seus próprios processos organizacionais internos que impedem que você aproveite os recursos NGFW externos.

Os casos de uso sul-norte e leste-oeste são diferentes, mas há uma sobreposição considerável. Além disso, muitas características norte-sul simplesmente não são relevantes para nenhuma delas. Vamos começar com o caso de uso leste-oeste.

Como eu disse anteriormente, certamente há um caso de uso para um subconjunto limitado de controles NGFW leste-oeste. O ROI de um dispositivo completo (ou dispositivo virtual) pode ser questionável, dado o custo, mas a necessidade é real. Se sua rede contiver PII, HIPPA ou PCI dados, é quase certo que você esteja sujeito às leis e regulamentações relacionadas à proteção desses dados. Em muitos casos, isso inclui um requisito explícito para implementar serviços NGFW tradicionais, como DLP (Prevenção de perda de dados) e IDS/IPS (Serviço de Detecção/Prevenção de Intrusões). Mesmo que não haja mandato, continua sendo uma boa prática. O ID do aplicativo, em outras palavras, a capacidade de bloquear ou permitir tráfego com base no tipo real de tráfego, em oposição à porta e ao protocolo, também é uma ferramenta poderosa e desejável para evitar ataques e exfiltração de dados.

Para o caso de uso sul-norte, alguns recursos adicionais podem ser úteis. O DLP provavelmente ainda é necessário, e o ID do aplicativo é igualmente útil para esse caso de uso, mas eu adicionaria a filtragem de URL e a capacidade de controlar o tráfego com base na reputação e na geografia do IP de destino. Claro, seu NGFW de fronteira já pode fazer isso, mas, como indiquei anteriormente, geralmente não há como o proprietário de um aplicativo aproveitar esses recursos se os dispositivos de borda não estiverem sob seu controle. E eles raramente estão em um grande ambiente de data center.

A maioria dos outros serviços NGFW tem valor limitado para leste-oeste ou sul-norte. DDoS e QoS fazem pouco sentido dentro de uma rede. Da mesma forma, o software antivírus moderno executado no sistema operacional provavelmente é mais eficiente do que uma solução baseada em rede, portanto, o antivírus baseado em rede provavelmente não está na agenda.

O desempenho dos recursos do NGFW em dispositivos de endpoint

É hora de falar sobre as implicações de desempenho dos recursos do NGFW em execução no pontos de extremidade. Se você se lembra, a primeira parte mencionou que os dispositivos NGFW são sistemas quase da classe de supercomputadores com muitos hardwares especializados para obter um desempenho respeitável. Obviamente, uma penalidade substancial de desempenho seria imposta a servidores individuais ao implementar a mesma funcionalidade. Felizmente, parece que pode ser um daqueles momentos em que a intuição sai pela janela. Vamos falar sobre o porquê.

O IDS/IPS é um ótimo lugar para começar. De todos os serviços NGFW, o IDS/IPS é considerado um dos “mais pesados”, o que significa que ele consome um número desproporcional de recursos e é uma das razões para a grande quantidade de silício personalizado em um dispositivo NGFW. Se estou protegendo um data center de tamanho moderado de 1.000 cargas de trabalho com uma solução IDS/IPS, provavelmente preciso oferecer suporte a assinaturas IDS/IPS para pelo menos uma dúzia de sistemas operacionais diferentes (Windows 2008, 2012, 2016, 2019, pelo menos meia dúzia de variações e versões do CentOS, RedHat e Ubuntu (além, possivelmente, do Solaris ou do AIX, se eu estiver na área da saúde ou no setor bancário). Cada um desses 1.000 servidores executa pelo menos um serviço que eu gostaria de observar, possivelmente até três ou quatro serviços diferentes cada, todos com possíveis vulnerabilidades. E com uma dúzia de sistemas operacionais, talvez eu esteja executando uma dúzia de versões diferentes de cada um desses três ou quatro serviços, cada um com vulnerabilidades diferentes.

Resumindo, estou procurando algo entre 10.000 e 100.000 assinaturas de vulnerabilidade para essas mil máquinas. E estou procurando sinais deles em cada pacote que flui pelo meu dispositivo de rede NGFW — em todas as portas possíveis em que eles possam estar operando. Claramente, essa não é uma carga que queremos impor a todos os servidores do data center.

Na prática, não precisamos. Não há motivo para procurar vulnerabilidades do Windows em um host Linux. Não há necessidade de procurar vulnerabilidades do apache2 em uma máquina executando o NGINX. Não há necessidade de procurar vulnerabilidades do Aplicativo X versão 1.0, 1.1, 1.2, 1.3, 2.0, 2.1 em um sistema executando o Aplicativo X versão 2.2.

Em vez de procurar 10.000 a 100.000 vulnerabilidades em cada pacote, procuramos talvez quatro. Não 4.000. Quatro. E quatro é um problema solucionável.

Como? Porque, como temos um agente em cada servidor, temos acesso total para entender o sistema operacional, quais patches foram e não foram aplicados, quais softwares (e quais versões desse software) estão instalados e em execução e, especificamente, em quais portas eles se comunicam. Procuramos vulnerabilidades específicas das versões do sistema operacional e do software detectadas, especificamente nas portas às quais os processos relevantes estão vinculados. Reduzimos o espaço de busca em cerca de quatro ordens de magnitude. E quatro ordens de magnitude é um número espetacularmente grande na ciência da computação. É a diferença entre difícil e fácil.

Estratégias semelhantes podem ser aplicadas a serviços como DLP e filtragem de URL. Não é necessário filtrar cada pacote em cada servidor para obter conteúdo DLP restrito, nem manter bancos de dados massivos de URLs ou informações de IP para endereços públicos em cada servidor. No caso do DLP, você pesquisa somente conteúdo específico em um conjunto muito específico de servidores com base em rótulos de carga de trabalho, da mesma forma que a política de segmentação é aplicada. Para filtragem de URL, o grande banco de dados de características de IP pode ser mantido no sistema central de gerenciamento de políticas, obtido em uma conexão LAN de baixa latência quando necessário e armazenado em cache localmente para pesquisas subsequentes. A maioria dos servidores conversa repetidamente com o mesmo conjunto relativamente pequeno de servidores.

Recursos NGFW para uma solução de microssegmentação

Ao adicionar recursos NGFW a um microsegmentação solução, um dos benefícios que você mais obtém é que, assim como a política de firewall, os recursos do NGFW são aplicados cirurgicamente, exatamente onde você precisa deles, em vez de em VLANs ou sub-redes inteiras como um grupo. Uma política baseada em rótulos permite que o proprietário do aplicativo aplique cirurgicamente serviços muito específicos, exatamente onde necessário, em vez de pintar o datacenter com um pincel largo. Os recursos específicos do NGFW podem ser ativados somente para os servidores necessários e somente realizando com precisão a inspeção necessária. Isso mantém a sobrecarga no mínimo necessário para atender às suas necessidades específicas de segurança e permite equilibrar segurança, desempenho e custo.

Lembre-se de que o objetivo aqui não é substituir seus dispositivos NGFW fronteiriços. Em vez disso, é para preencher seletivamente as lacunas em que as soluções NGFW existentes não fazem sentido arquitetônico ou financeiro com um poderoso subconjunto de recursos NGFW em execução nos próprios servidores. Essa abordagem permite que os proprietários de aplicativos “possuam” sua segurança externa onde, de outra forma, isso não seria possível, bem como ofereçam esses recursos em situações que, de outra forma, seriam proibitivas em termos de custos usando soluções tradicionais.

Olhando para o futuro

Para resolver isso, vamos olhar ainda mais para o futuro.

O TLS 1.3 foi ratificado em 2018 e está lentamente se tornando o próximo padrão para web criptografada e outros serviços. Sua reação inicial a isso pode ser: “Não é meu problema” ou talvez “E daí?” Eu diria que, na verdade, é extremamente relevante. Um NGFW não pode fornecer a maioria dos serviços disponíveis sem a Inspeção Profunda de Pacotes (DPI). E para que o DPI seja significativo, os dados devem estar em texto não criptografado.

Quando os NGFWs chegaram ao mercado pela primeira vez, apenas uma pequena fração do tráfego da web era criptografada. Com o passar do tempo, mais e mais tráfego foi transferido para HTTPS, ou tráfego criptografado. Atualmente, quase 100% de todo o tráfego da web é criptografado e, portanto, não pode ser analisado em busca de malware, vírus, exfiltração de dados ou qualquer outro servidor NGFW. A solução desenvolvida para isso é chamada de TLS MiTM (man-in-the-middle).

Configurar o TLS MiTM é um pouco entediante, embora tenha um conceito simples. Há várias partes móveis na solução. Primeiro, a organização cria um certificado TLS interno. A chave pública é enviada para todos os sistemas (laptops, desktops, servidores etc.) da organização, e cada sistema operacional é configurado para confiar nesse certificado e usá-lo para criptografar todas as comunicações de saída, independentemente do destino. A chave privada é então distribuída para seus dispositivos NGFW de perímetro, que são configurados como proxies web transparentes.

Quando um usuário (ou servidor ou qualquer outro dispositivo) faz uma conexão de saída com um site externo, digamos gmail.com neste exemplo, em vez de usar o certificado TLS do Google, ele criptografa o tráfego com o certificado interno da organização. Quando o perímetro NGFW vê esse tráfego de saída, ele é capaz de descriptografá-lo e analisar completamente o conteúdo do tráfego em virtude de ter uma cópia da chave privada. O NGFW encerra a conexão interna e origina uma nova conexão TLS com o gmail.com usando o certificado do Google e envia por proxy o conteúdo das duas conexões (a conexão interna de dentro da organização à conexão externa com o Gmail) e, portanto, é capaz de visualizar e analisar todo o tráfego, mesmo que esteja criptografado.

Embora trabalhoso e consuma muita CPU, esse método funcionou razoavelmente bem para a maioria dos serviços por cerca de uma década usando SSL e depois TLS 1.0, 1.1 e 1.2.

Até agora, tudo bem. Mas o TLS 1.3 muda o jogo. Primeiro, o TLS 1.3 exige o Perfect Forward Secrecy, na forma de trocas de chaves DH por conexão. Por causa disso, um dispositivo passivo não tem como descriptografar a carga, mesmo com acesso à chave privada em uso. Com o TLS 1.3, é obrigatório inserir um dispositivo no stream e fazer o proxy do tráfego. Em segundo lugar, o TLS 1.3 desativa as cifras de baixa segurança, removendo a capacidade de um dispositivo proxy rebaixar uma conexão proxy para o TLS 1.2, que é uma estratégia comum frequentemente empregada para economizar recursos de computação no NGFW (porque cifras de menor segurança normalmente exigem menos computação).

Se a história da criptografia nos ensinou alguma coisa, é que padrões antigos e confiáveis tendem a ser considerados vulneráveis ao longo do tempo com quase 100% de certeza. A prática atual de rebaixar o TLS 1.3 para o TLS 1.2 para permitir a decodificação passiva e/ou o rebaixamento para economizar recursos está em um cronômetro, apenas esperando que o TLS 1.2 seja descontinuado. Quando esse dia chegar, muitos dispositivos de inspeção passiva se tornarão pesos de papel caros, enquanto muitas soluções em linha rapidamente ficarão sobrecarregadas em virtude de serem forçadas a usar criptografia computacionalmente mais cara.

Um pequeno segredo sujo do mundo do NGFW é que, pelo menos no momento em que este artigo foi escrito, seu tráfego do WebSocket provavelmente não está sendo inspecionado em busca de ameaças de qualquer tipo. Por quê? Porque um NGFW típico não consegue descriptografar o tráfego em tempo real. O tráfego do WebSocket deve ser visualizado em seu navegador (usando as Ferramentas do Desenvolvedor) ou capturado e descriptografado após o fato usando algo como o Wireshark (supondo que você tenha as chaves privadas) para inspecionar a carga útil. Os WebSockets estão se tornando cada vez mais comuns em aplicativos da web, pois a tecnologia fornece uma ótima solução para aplicativos JavaScript moverem dados entre seu navegador e um servidor web. Literalmente, qualquer coisa pode ser movida através de uma conexão WebSocket, e é completamente opaca para o seu NGFW.

Por fim, não vamos esquecer outras novas tecnologias difundidas, como o uso do QUIC para tráfego na web. Embora o QUIC seja uma nova ferramenta poderosa para obter tráfego para seu navegador com mais rapidez e eficiência, ele não usa criptografia TLS padrão. Isso significa que seu NGFW em linha deve bloquear todo o tráfego QUIC (forçando um downgrade para TLS) ou permitir que o tráfego passe sem ser inspecionado. A primeira solução reduz a qualidade da experiência do usuário e a segunda expõe a organização a riscos. Nenhum dos dois é ideal.

Lidar com algumas tarefas de NGFW no nível da carga de trabalho ajuda a prolongar a vida útil do investimento em dispositivos NGFW existentes. Ele permite a descarga de uma porcentagem de processos computacionalmente caros ao lidar com eles por carga de trabalho. Isso permite que o cliente descarregue parte da carga útil de inspeção de seus dispositivos de rede, atrasando assim uma atualização de firewall necessária e, ao mesmo tempo, trazendo os benefícios do Zero Trust para partes de sua rede que, de outra forma, não fariam sentido técnico ou financeiro.