(Micro)Segmentação sob uma perspectiva prática

Antes de passarmos para as práticas recomendadas e estratégias, precisamos definir nosso cenário. A segmentação de rede envolve "quebrar" a rede em partes (segmentos) e definir quem pode acessar o quê e de que maneira (por exemplo, servidores da Web só podem ser acessados via HTTP/S). 

Isso foi alcançado, de maneira tradicional, usando VLANs e firewalls físicos, mas ultimamente vemos cada vez mais abordagens baseadas em software para firewalls e segmentação (Akamai Guardicore Segmentation, por exemplo). Não recomendamos uma forma ou outra, há prós e contras em ambas as abordagens. Nossas políticas e estratégias recomendadas são independentes do fornecedor e podem ser aplicadas em qualquer lugar.

Ao deixar de controlar o tráfego usando VLANs, listas de controle de acesso (ACLs) e intervalos de IP para usar rótulos personalizados independentes do fornecedor, você entra no reino da microssegmentação. Todas as nossas estratégias nesta postagem presumirão que estamos usando microssegmentação.

Deve ser possível adaptar as estratégias e diretrizes para não exigir segmentação, mas o processo para definir todas as VLANs, ACLs e listas de IP e, em seguida, mantê-las provavelmente é impraticável ou resultará no esgotamento imediato de todos os administradores e engenheiros de rede. (Tente definir o intervalo/grupo de IP de todos os servidores financeiros. Pode ser possível, mas você consegue manter essa lista com precisão por muito tempo? É apenas um grupo de servidores; em uma rede corporativa, você terá muitos outros, usuários finais, controladores de domínio, administradores de domínio, impressoras, etc.)

Antes de podermos discutir como segmentar, precisamos discutir um pré-requisito importante: visibilidade. A microssegmentação não vive isolada. Não há como proteger o que não se pode ver. Uma boa segmentação só é eficaz ao lado da visibilidade da rede que organiza e resume o tráfego. Em geral, há muito tráfego para analisar tudo a olho nu de forma realista.

Antes de entrarmos nas estratégias de segmentação reais, gostaríamos de discutir algumas diretrizes ou princípios que acreditamos serem cruciais para uma boa segmentação.

De um modo geral, os servidores que têm muito tráfego de entrada estão mais no lado da manipulação de solicitações, como servidores da Web ou de arquivos (até os controladores de domínio se enquadram nessa categoria). Dessa forma, não deve haver muito tráfego de saída deles ou, pelo menos, deve ser estritamente definido. 

Além disso, ter restrições mínimas tanto na saída quanto na entrada corre o risco de o servidor ser usado como pivô pelos invasores, pois os servidores são mais acessíveis para os invasores e podem ser usados para acessar uma parte mais ampla da rede.

Existem algumas máquinas para as quais as políticas precisam ser flexíveis, pois há muita variabilidade no tráfego que sai da máquina; portanto, é preciso conceder muitas exceções. 

Veja, por exemplo, os servidores jump box; diferentes usuários os usam para se conectar a diferentes servidores com diferentes protocolos. Você não conseguirá cobrir todos os casos de uso sem ser muito permissivo (o que anula todo o propósito da segmentação). 

Nesses casos, acreditamos que é melhor empregar outros mecanismos de defesa e torná-los mais rígidos (como usar um controle de acesso de usuário mais forte para o exemplo do jump box ou limites de alerta mais baixos para serviços de monitoramento).

Só porque já existe uma vertente de tráfego quando você começa a segmentar, não significa que você deva permiti-la. Às vezes, você terá que modificar as configurações existentes de aplicações ou servidores quando decidir que o tráfego que eles produzem é desnecessário. Às vezes, você também terá que consultar as configurações existentes para entender por que determinado tráfego existe.

Nesse caso, a segmentação é como o firewall tradicional: você bloqueia o tráfego de entrada de fora da sua rede que não deveria entrar. Esse tráfego geralmente seria da Internet, mas também pode ser de redes de terceiros conectadas à sua. 

Portanto, bloquear portas Secure Shell (SSH) ou protocolo de área de trabalho remota (RDP) expostas (ou basicamente qualquer porta na seção de movimento lateral) é aconselhável. De fato, é melhor usar uma lista de permissões em vez de uma lista de proibições para o tráfego originário de fora da sua rede, especialmente da Internet (considere, por exemplo, quantos scanners de Internet estão ativos em um determinado momento).

É claro que, como acontece com qualquer outra ferramenta de segurança, a segmentação de prática (ou política) não é uma solução abrangente para ameaças. Nesse caso, a segmentação não pode abranger todos os vetores de acesso iniciais e confiar apenas na segmentação deixa sua rede exposta a riscos. Muitas violações começam com e-mails ou links de phishing ou outras formas de engenharia social. 

Algumas violações também começam com vulnerabilidades em protocolos que deveriam ser permitidos ou com credenciais fracas para serviços legitimamente expostos à Internet, como o servidor VPN. Por isso, recomendamos não confiar apenas na segmentação para impedir o acesso inicial e empregar soluções de segurança para proteção de host e e-mail além da segmentação.

Existem muitas maneiras de executar o movimento lateral; não vamos abordar todas. Especificamente, vamos nos concentrar na prevenção de movimentos laterais que podem ocorrer por meio de processos legítimos que já existem na máquina, usando protocolos como RDP ou SSH, serviços baseados em RPC como gerenciador de serviços ou agendador de tarefas, ferramentas de gerenciamento como PowerShell ou WMI ou alguns dos protocolos e ferramentas disponíveis no Linux que discutimos em uma postagem separada.

Não vamos discutir vulnerabilidades de dia um ou dia zero porque elas podem estar em qualquer produto e com diferentes implementações, então é impraticável ter uma estratégia geral que se aplique a elas. Nossa única recomendação é a segmentação, pois algo inacessível é muito mais difícil de explorar.

Antes de nos aprofundarmos nas diferentes considerações para cada um dos diferentes protocolos, há dois princípios que se aplicam a todos eles.

Os usuários não precisam acessar as máquinas de outros usuários, especialmente não pela rede. A menos que alguém trabalhe em TI, não há muitas justificativas para se conectar remotamente à máquina de outro usuário. Dessa forma, deve ser bastante viável restringir o tráfego entre as máquinas dos usuários sem comprometer muito a operacionalidade da rede.

Além disso, como os protocolos discutidos nesta seção podem ser usados para controle remoto ou execução, também podem servir como vetores de acesso inicial. Por isso, reiteramos a necessidade de restringir o acesso arbitrário à Internet por meio desses protocolos.

Como esses serviços são interativos e gráficos, seu uso automatizado é bastante limitado. Portanto, não espere ver o uso desses protocolos entre os servidores com muita frequência (a palavra-chave é "esperar", se você vir, é hora de investigar o motivo). 

O mesmo raciocínio se aplica às máquinas dos usuários, eles não precisam se conectar uns aos outros. As exceções a essas suposições podem ser jump boxes e servidores de terminal que permitem aos usuários pular ambientes ou acessar servidores, conexões de pessoal de TI com máquinas de usuários ou proprietários de aplicações que se conectam ao servidor de aplicações. 

O tratamento dessas exceções deve ser feito criando políticas adequadas usando segmentação, mas esses esforços também devem ser complementados com soluções adequadas de gerenciamento de acesso à identidade (IAM).

Embora o SSH seja semelhante em conceito aos RDPs, a história é mais complicada. Como o SSH é baseado em terminal (texto), é muito mais fácil usá-lo para interagir com o software, e há programas e scripts que o utilizam. Além disso, o SSH também é usado para encapsular protocolos menos seguros, como SFTP, que é o encapsulamento SSH do protocolo de transferência de arquivos.

Por esses motivos, o SSH requer uma abordagem muito mais granular do que outros RDPs. Sem visibilidade adequada do tráfego de rede, será muito difícil segmentar adequadamente o SSH sem afetar os usuários finais ou a operacionalidade da rede.

Tanto o MS-RPC quanto o SMB não permitem imediatamente o movimento lateral, outros protocolos construídos sobre eles permitem (consulte a Figura 4). O SMB é usado para transferência de arquivos e comunicações, enquanto o RPC é usado para chamar funções remotas a partir de interfaces definidas. Às vezes, o RPC também é transportado pelo SMB, portanto, eles estão fortemente acoplados. Eles também são notoriamente difíceis de segmentar adequadamente, pois são incorporados ao sistema de domínio do Windows. 

Por exemplo, a autenticação de domínio é implementada no Netlogon, um protocolo baseado em RPC. As políticas de grupo de domínio e os scripts de logon são armazenados em uma pasta compartilhada no controlador de domínio chamada SYSVOL, e as máquinas que ingressaram no domínio a acessam por SMB.

Bloquear o SMB sem quebrar todo o domínio é praticamente impossível, . Então, o que é possível fazer? Com o SMB, é possível criar políticas com base em unidades lógicas, a maioria dos servidores e máquinas não devem se comunicar por SMB, a menos que o destino seja um servidor de arquivos. Dessa maneira, a segmentação adequada de ringfencing deve ajudar a mitigar o risco de SMB.

Uma abordagem semelhante pode ser aplicada ao RPC, mas pode ser ainda mais restritiva, pois não precisamos permitir o tráfego RPC para servidores de arquivos, ao contrário do SMB. Além disso, como o RPC é tratado no modo de usuário, é possível criar políticas de segmentação com base no serviço ou processo de destino, portanto, você só precisa lidar com interfaces do RPC que podem ser abusadas pela movimentação lateral (e somente se você tiver um agente de segmentação que possa lidar com regras baseadas em processo ou serviço). 

A tabela a seguir mostra as interfaces RPC que devem ser gerenciadas para evitar o movimento lateral.

Como nem todas as operações nessas interfaces RPC são mal-intencionadas (por exemplo, algumas soluções de monitoramento e watchdogs interagem com o gerenciador de serviço remotamente para verificar a integridade do serviço), recomendamos pesquisar as comunicações RPC existentes. Se normalmente não são acessadas remotamente (ou se você pode restringir a lista de origem), recomendamos criar políticas de segmentação em torno delas para o benefício extra de segurança.

Tanto o PowerShell quanto o WMI são capazes de interagir com máquinas remotas, e essa interação é "alimentada" por Windows Remote Management (WinRM). Como o uso legítimo geralmente é o gerenciamento ou monitoramento remoto (com WMI), deve haver poucos casos de uso em sua rede. Deve ser possível criar políticas de segmentação que restrinjam o uso arbitrário e o permitam somente a partir de servidores de monitoramento ou máquinas de TI. 

É claro que é possível haver exceções e vimos alguns casos em que o PowerShell remoto foi usado extensivamente pelos desenvolvedores por conveniência; provavelmente seria necessário uma decisão caso a caso.

A menos que você queira controlar todo o tráfego de saída no estilo de 1984, não pode esperar realisticamente impedir a exfiltração de dados durante ataques usando apenas segmentação. A Internet é grande e ampla, não é realista ter um veredicto preciso para cada website e servidor aos quais os usuários estão se conectando a partir de sua rede. Dessa forma, os agentes de ameaças podem facilmente camuflar as tentativas de exfiltração entre todos os outros tráfegos de saída.

Em vez de tentar controlar o tráfego de saída, é mais viável controlar quem pode acessar dados confidenciais. O único local onde pode ser possível restringir o tráfego de saída é nos servidores da rede; ao contrário das máquinas dos usuários, deve haver muito menos variabilidade em seus destinos de saída.

O princípio abrangente para toda esta seção é "Só porque existe, não significa que deva ser permitido." Ao segmentar uma parte da rede, seja uma aplicação crítica para os negócios (como SWIFT), uma unidade operacional (como o controlador de domínio) ou um ambiente (como servidores de produção), a primeira tarefa é pesquisar o tráfego existente (Figura 5). 

Depois de analisar o tráfego existente, você pode criar políticas que permitem os fluxos relevantes e restringem o restante (essa também é sua oportunidade de encontrar qualquer configuração incorreta que deva ser tratada pelo proprietário da aplicação em vez da segmentação). 

Recomendamos não implementar uma política de bloqueio imediatamente, mas executá-la em modo somente alerta por algum tempo. Você deve mudar para uma política de restrição somente depois de considerar que a política está sendo executada conforme o esperado e que os alertas de violação da política estão em um valor mínimo ou controlado. 

Também é importante diferenciar seu ambiente atual (aquele que existia antes de você começar a segmentá-lo) e seu ambiente futuro (aquele depois de implementar sua política de segmentação). Ao implementar a segmentação pela primeira vez, você deve ter cuidado e aprender a rede para evitar problemas. 

Novas adições, no entanto, devem ser feitas considerando a política de segmentação existente. Faça exceções e concessões da política quando necessário para a operação normal, mas não desconsidere a política existente apenas porque você está expandindo a rede.

Com o ringfencing, estamos mais interessados nas interfaces do segmento com o resto da rede e com o mundo. Queremos controlar o que entra e sai da parte da rede que queremos segmentar sem considerar o que está acontecendo dentro do segmento.

Podemos levar o ringfencing um passo adiante e aplicar políticas a máquinas individuais com base em sua finalidade. Por exemplo, se um servidor funciona apenas como um banco de dados, só deve receber acesso pelas portas do banco de dados; um servidor da Web, através de portas da Web.

Claro que não é tão simples assim. Normalmente, há mais serviços que precisam de acesso a esses servidores, como watchdogs, monitores de desempenho ou TI. Em geral, essas portas de acesso também se parecem muito com as técnicas de movimentação lateral, pois geralmente giram em torno de algum tipo de controle remoto. (Por exemplo, watchdogs remotos consultam o gerenciador de serviços, de maneira semelhante à técnica de movimentação lateral do PsExec. A única maneira de distinguir entre as chamadas é a inspeção profunda de pacotes, que geralmente não está disponível.)

Para superar esse desafio, sempre que precisar permitir tráfego adicional além do que já deve acessar o serviço, recomendamos limitar as fontes permitidas ao segmento que deve fazer o monitoramento.

Além disso, podemos limitar o acesso do usuário a locais confidenciais dos quais ele não precisa. Se o banco de dados atende apenas a aplicações internas, há poucos motivos para permitir que usuários arbitrários as consultem. Acreditamos que bloquear o acesso arbitrário do usuário seja a etapa de segurança mais importante, pois muitos ataques começam a partir de usuários comprometidos.

Com a microssegmentação, estamos aplicando outra camada de granularidade à nossa política de segmentação, separamos as máquinas no segmento com base em sua função ou sensibilidade. Podemos pensar nisso como um híbrido entre ringfencing de aplicação e ringfencing geral. A principal diferença do ringfencing é que agora também controlamos o tráfego dentro do segmento e não confiamos automaticamente nos vizinhos.

Nosso princípio aqui é que não devemos confiar no tráfego de máquinas vizinhas só porque estamos dentro do mesmo segmento. Os invasores usarão qualquer conexão que puderem para se propagar pela rede, independentemente dos segmentos. 

Portanto, mesmo que tenhamos o mesmo tipo de servidor de aplicações no segmento, não há razão para que eles possam se comunicar entre si em todas as portas e protocolos. A microssegmentação significa que aplicamos regras de política em todos os tipos de tráfego, mesmo dentro do segmento de rede e entre as máquinas com a mesma função.

É claro que as máquinas dentro do mesmo segmento geralmente são mais fortemente acopladas, por isso é mais difícil adicionar políticas sem ser excessivamente permissivo.

Dependendo de como você define os segmentos em sua rede, os princípios de ringfencing de aplicação também podem ser aplicados como princípios de microssegmentação. Por exemplo, se dividirmos nossa rede em um segmento de usuário, segmento de banco de dados e segmento de servidor da Web, os princípios definidos no ringfencing de aplicação também são adequados para microssegmentação. A única adição necessária é a aplicação dos mesmos princípios dentro de cada segmento de aplicação, entre diferentes máquinas.

No entanto, se nossa rede for dividida em um segmento financeiro, segmento de vendas e segmento de TI, e cada segmento tiver uma mistura de servidores e máquinas de usuários, precisamos ser mais criativos. Depois de aplicar as estratégias gerais de ringfencing aos segmentos, devemos passar à criação de políticas entre os segmentos e dentro deles. Podemos considerar cada segmento como uma minirrede; então podemos dividir cada um em diferentes aplicações e tipos de máquinas que o compõem. (Por exemplo, para um segmento de vendas, podemos ter um servidor de arquivos, banco de dados e máquinas de usuários.) Podemos tratar cada tipo de máquina como um novo segmento e seguir as diretrizes de ringfencing ou ringfencing de aplicação novamente.

A Figura 6 resume as relações entre as várias estratégias de segmentação.

A segmentação de rede é uma ferramenta útil para aumentar a segurança da rede e lidar com ameaças baseadas na rede. Também é uma ferramenta que pode fornecer valor de segurança imediato, já que você não precisa começar com projetos de segmentação longos ou árduos e pode dividir seu trabalho em vários subprojetos, cada um melhorando a postura de segurança da rede passo a passo. 

Fornecemos diretrizes para várias políticas e estratégias de segmentação para ajudar os administradores de rede a fazer exatamente isso. Esperamos que nossas recomendações sejam práticas e ajudem a manter as organizações mais seguras.

O Akamai Akamai Security Intelligence Group continuará monitorando, estudando e publicando pesquisas sobre diversos tópicos de segurança. Para ver as atualizações em tempo real e as pesquisas mais recentes, siga-nos no Twitter!