No âmbito do Secure Access Service Edge (SASE), a integração dos sistemas de detecção e prevenção de intrusões (IDPS) é quase universal.
Sua função vai além de simplesmente impedir explorações conhecidas, ele serve como uma sentinela vigilante para IOC (Indicators of Compromise), proporcionando uma camada abrangente de proteção.
Eu diria até que o IDPS está sendo usado para indicadores de comprometimento e indicadores de ataque mais recentemente pelas organizações.
O poder do IDPS está em sua capacidade de fornecer informações valiosas sobre o tráfego de rede; ele não apenas extrai metadados de conexão, como os 5 tuplos da conexão, mas também se aprofunda nos detalhes sutis de vários campos de protocolo.
Essa profundidade de extração produz informações valiosas sobre as características dos dados que atravessam a rede, aprimorando a percepção contextual.
O IDPS usa vários métodos para fortalecer a segurança da rede.
Ele detecta e obstrui com eficiência as explorações e os malwares conhecidos por meio de métodos de detecção baseados em assinaturas.
Além disso, ele se protege contra dados anômalos empregando regras que podem identificar padrões irregulares de pacotes ou fluxos.
Essas regras ampliam seu alcance para abranger tamanhos anormais de atributos de protocolo e comportamento imprevisto de valores de protocolo.
Embora os recursos e a eficácia da segurança do IDPS dentro da estrutura SASE possam apresentar pequenas variações entre os provedores de serviços, os principais recursos permanecem em grande parte semelhantes, devido à utilização de bancos de dados de assinaturas normalmente provenientes de fornecedores terceirizados de inteligência contra ameaças.
Além disso, as tecnologias de IDPS amadureceram e desenvolveram recursos semelhantes, mesmo diante de várias técnicas de evasão empregadas pelos invasores.
Na minha avaliação, a principal diferenciação entre os provedores está no campo da observabilidade e nos recursos que oferecem para a busca de ameaças, com foco na minimização de falsos positivos e falsos negativos.
A intenção deste artigo não é se aprofundar na diferenciação dos recursos de IDPS entre os serviços SASE.
Em vez disso, ele busca explorar os pontos exatos no caminho do pacote em que as funções do IDPS são executadas pelos serviços SASE e se esses pontos de inserção detectam efetivamente padrões de ataque no tráfego original.
Alguns acreditam que a incorporação da funcionalidade do Sistema de Detecção e Prevenção de Intrusões (IDPS) no nível do proxy dentro dos serviços Secure Access Service Edge (SASE) é suficiente.
A justificativa deles decorre do fato de que muitas organizações já empregam o IDPS OnPrem para a detecção de intrusão no tráfego genérico.
O principal desafio do OnPrem IDPS está na sua incapacidade de inspecionar o tráfego criptografado por TLS.
Como os proxies SASE realizam a inspeção TLS Man-in-the-Middle (MITM), eles obtêm acesso ao tráfego não criptografado.
Portanto, acredita-se que ter o ponto de inserção do IDPS nos proxies é adequado.
Além disso, alguns argumentam que um número significativo de sistemas está adequadamente corrigido contra ataques em nível de rede (L3/L4) e em nível de TLS.
Em resposta, os atacantes mudaram seu foco para o emprego de táticas mais sofisticadas nos níveis de aplicativos (L7) e de dados.
Consequentemente, há uma noção predominante de que é justificável não estender a funcionalidade do IDPS além do nível de proxy dentro da rede.
Entretanto, esse argumento não é válido em todos os casos. Considere os dispositivos de IoT que continuam a operar com sistemas operacionais mais antigos e pouco atualizados.
Esses dispositivos podem permanecer vulneráveis a uma gama mais ampla de ataques, o que exige uma abordagem de segurança abrangente.
Muitos também reconhecem que os serviços SASE devem incorporar o IDPS nos níveis de proxy e L3 para garantir a inspeção completa de todo o tráfego de rede.
Para obter uma detecção abrangente de ataques, a funcionalidade do IDPS deve ser aplicada não apenas no nível do proxy, conforme discutido anteriormente, mas também no nível das interfaces WAN, onde o tráfego entra e sai das interfaces designadas para o tráfego de e para a Internet.
Embora essa abordagem represente uma melhoria em relação à implementação do IDPS somente no nível do proxy, ela apresenta um desafio.
Nos casos em que o tráfego passa pelos proxies, o IDPS pode não ter visibilidade do tráfego original em ambas as direções das sessões.
Normalmente, os proxies encerram conexões e estabelecem novas.
Como dependem da pilha TCP/IP local, eles remontam os pacotes originais, sequenciam novamente os dados TCP, recriam as opções IP/TCP e geram novamente as mensagens de handshake TLS.
Consequentemente, o IDPS no nível da interface WAN pode não ter visibilidade do tráfego original originado da rede interna, o que pode fazer com que ele ignore os padrões de ataque que faziam parte do tráfego original.
É importante observar que os atacantes nem sempre são externos; pode haver atacantes internos também.
Além disso, os ataques podem se originar de sistemas internos devido a infecções anteriores por malware.
Portanto, é fundamental garantir que o IDPS observe de forma consistente o tráfego original em ambas as direções para a detecção e a prevenção eficazes de ameaças.

Buscar serviços SASE com vários pontos de inserção de IDPS

Defendemos que os serviços SASE ofereçam a flexibilidade de inserir IDPS em vários pontos, todos ativos ao mesmo tempo.
As organizações devem ter a liberdade de escolher se querem implantar o IDPS em cada interface L3 e no nível do proxy.
Essa abordagem permite que o IDPS inspecione o tráfego original dos pontos de extremidade do cliente e do servidor das sessões, mesmo quando o tráfego é criptografado por TLS e passa pelos proxies.
Além disso, as organizações devem procurar ativamente por serviços SASE que evitem a geração de alertas e registros duplicados resultantes de vários pontos de inserção.
Por exemplo, o tráfego que não passa por nenhum proxy, mas atravessa várias interfaces L3 (recebido em uma interface e enviado por outra), pode ser visto por duas instâncias do IDPS, o que pode levar a alertas e registros duplicados.
É recomendável que as organizações garantam que essa redundância nos logs seja minimizada, evitando a inundação do pessoal administrativo que já está lidando com um grande volume de logs gerados pelas funções de segurança.
O ideal é que os serviços SASE apresentem inteligência por sessão de tráfego e evitem, de forma inteligente, a execução duplicada da função IDPS se não houver modificações no tráfego dentro do serviço SASE.
Além disso, as organizações devem buscar soluções que permitam a correlação de logs gerados por várias funções de segurança, inclusive várias instâncias de IDPS, para uma determinada sessão de tráfego.
Essa correlação ajuda a melhorar a observabilidade e agiliza o trabalho dos caçadores de ameaças, simplificando o mapeamento dos eventos de segurança.
Reconhecendo a natureza computacionalmente intensiva do IDPS, as organizações também devem se esforçar para economizar recursos sempre que possível.
Por exemplo, se as organizações já empregam IDS de host (HIDS) ou IDPS no local, talvez queiram manter o controle sobre a desativação do IDPS em instâncias específicas para determinados tipos de tráfego.
Os serviços SASE que oferecem direcionamento de IDPS com base em políticas podem permitir que as organizações determinem qual tráfego deve ser submetido à inspeção por diferentes instâncias de IDPS dentro da estrutura SASE.
Em resumo, a eficácia do IDPS dentro do paradigma da SASE vai além de seus recursos; ela depende da flexibilidade que a SASE oferece em relação aos pontos de inserção do IDPS e do grau de controle que ela proporciona às organizações para alinhar com seus requisitos específicos.

  • Blog CTO Insights

    A série de blogs Aryaka CTO Insights oferece liderança de pensamento para tópicos de rede, segurança e SASE.
    Para obter as especificações dos produtos Aryaka, consulte as fichas técnicas da Aryaka.