Obtendo a segmentação correta com o controle estruturado de políticas

Em última análise, a segmentação Zero Trust trata de criar e aplicar regras de segurança.

Ao estabelecer políticas de acesso cuidadosamente definidas, a Segmentação Zero Trust evita que as violações se espalhem pelos sistemas e ambientes de TI.

Em qualquer organização, é inevitável que pelo menos um dispositivo de endpoint seja violado por atacantes. Mas se a organização tiver a segurança de Segmentação Zero Trust implementada, a violação poderá ser confinada a esse endpoint inicial, independentemente de esse endpoint ser um laptop, desktop, servidor ou até mesmo uma máquina virtual.

As políticas de segmentação evitarão que o malware acesse as portas e os protocolos de rede necessários para se copiar para outros servidores e data centers essenciais ou explorar a rede em busca de dados valiosos. A segmentação retém o ataque, como uma mosca embaixo de um copo.

Segmentação Zero Trust: duas abordagens

Um mecanismo de regras é um software que define a sintaxe das regras de segmentação. Ele também impõe essas regras quando elas são definidas. Geralmente, os fornecedores de software de segmentação adotam duas abordagens diferentes ao projetar mecanismos de regras para os clientes.

A primeira abordagem é oferecer aos clientes o máximo de flexibilidade, permitindo que as partes interessadas em toda a organização definam regras com as categorias ou rótulos que quiserem.

A outra abordagem é adotar uma filosofia de design conhecida como controle de política estruturado. Essa abordagem limita o número de rótulos disponíveis para regras de segmentação. Ele também coloca a regulamentação sob o controle de uma equipe centralizada de especialistas em segurança de TI. Os fornecedores que adotam essa abordagem acreditam que, no final das contas, a simplicidade será mais eficaz na redução de ataques do que a complexidade aberta.

Agora, examinaremos essas abordagens e compararemos suas vantagens e desafios para implantações reais.

A abordagem de máxima flexibilidade para segmentação

Em qualquer organização, os requisitos de segurança variam de departamento para departamento e de caso de uso para caso de uso. Aplicativos diferentes exigirão regras diferentes. Até mesmo o mesmo aplicativo pode ter regras diferentes, dependendo do data center em que está sendo executado, da versão do software em execução, dos recursos dos quais depende e assim por diante.

Muitos fornecedores de segmentação atendem a essa necessidade de flexibilidade ao permitir que diferentes usuários e proprietários de aplicativos definam suas próprias regras para sua área de especialização ou responsabilidade.

Normalmente, esses fornecedores oferecem suporte a três tipos de regras:

• Regras de “bloqueio” para impedir o movimento do tráfego ao longo de determinadas vias
• Regras de “permissão” para fornecer permissão para que certos tipos de tráfego percorram um caminho
• “Ignorar” as regras para evitar que outras regras bloqueiem ou permitam o tráfego em situações específicas

Em um alto nível, essa abordagem distribuída para a elaboração flexível de regras parece promissora. Afinal, os proprietários de ativos de TI devem ter o conhecimento de domínio necessário para definir as regras de segmentação mais adequadas para um determinado ativo de TI ou grupo de ativos relacionados. E fornecer três tipos de regras — bloquear, permitir e ignorar — parece oferecer às equipes de segurança de TI e às partes interessadas da empresa a precisão necessária para definir as políticas de segurança corretas para proteger os ativos de TI.

Infelizmente, na maioria das organizações — especialmente grandes organizações com dezenas ou centenas de milhares de cargas de trabalho distribuídas em ambientes de nuvem, locais e endpoints — o que logo resulta dessa abordagem é o “Velho Oeste”.

Claro, as partes interessadas em toda a organização definiram regras para proteger ativos valiosos de TI. Mas, em última análise, isso leva ao caos, porque existem muitas regras de muitos tipos diferentes para serem gerenciadas com eficácia.

Como a regulamentação é distribuída e descoordenada, o conjunto de regras acaba gerando conflitos e omissões, criando oportunidades para os atacantes escaparem. A governança central e consistente é virtualmente impossível.

Veja o que cria essas condições do “Velho Oeste”:

• Os domínios de responsabilidade geralmente se sobrepõem.
  Por exemplo, uma pessoa pode ser responsável por um aplicativo de negócios e outra pessoa pode ser responsável por um banco de dados. A aplicação pode depender do banco de dados, mas as regras de acesso definidas para a aplicação e para o banco de dados são desenvolvidas independentemente. Consequentemente, os dois conjuntos de regras podem ser inconsistentes, especialmente se outros aplicativos também utilizarem o banco de dados.
  
  Outro exemplo: Uma única pessoa é responsável pelo aplicativo de gestão de relacionamento com o cliente (CRM) da empresa. Outra pessoa é responsável pelo centro de dados da empresa em Nova York, onde o aplicativo CRM está sendo executado. Mesmo que essas duas pessoas concordem em relação às filosofias de segurança, é altamente improvável que suas implementações independentes de regras de segmentação funcionem perfeitamente juntas. A complexidade envolvendo endereços IP, portas e protocolos é excessiva para que seja possível criar dezenas ou centenas de regras de forma independente e eficaz.
   
• O controle de segmentação é distribuído em vez de centralizado, então os testes raramente ocorrem.
  Como o controle é distribuído entre muitas partes interessadas, é difícil para a organização de TI testar todas as regras de segmentação antes de ativá-las. A falta de testes aumenta o risco de erros e omissões. Isso pode até mesmo fazer com que o tráfego essencial para os negócios seja bloqueado inadvertidamente.
   
• O suporte para números ilimitados ou altos de etiquetas causa confusão.
  Produtos de segmentação que distribuem o controle dessa forma geralmente permitem que os clientes definam suas próprias categorias ou rótulos para segmentação.
  
  Aproveitando essa flexibilidade, os clientes logo passam a ter vinte, trinta ou mais rótulos para suas políticas de segmentação. Por exemplo, um cliente pode etiquetar todos os ativos de TI envolvidos na conformidade com o PCI com uma etiqueta de “Conformidade com o PCI”. Eles também podem etiquetar todos os ativos em um local específico com o nome do local ou ter etiquetas para unidades de negócios, aplicativos, ambientes (por exemplo, teste versus produção), regulamentações governamentais adicionais (como o GDPR) e assim por diante.
  
  Em teoria, essa proliferação de rótulos proporciona precisão e visibilidade. Na prática, isso leva a modelos de segurança que são complexos demais para serem gerenciados com eficácia.
  
  As equipes podem tentar reduzir esse caos por meio da ordenação de regras — por exemplo, estruturando os conjuntos de regras para aplicar primeiro as regras do centro de dados, em seguida as regras do aplicativo e, por último, as regras sobre regulamentos ou unidades de negócios. Na prática, porém, esse tipo de estruturação leva a políticas labirínticas, tornando muito difícil determinar quais regras estão em vigor em determinadas condições.
   
• As regras descentralizadas são mais difíceis de gerenciar quando os funcionários mudam de emprego.
  Outro problema com a criação de regras distribuídas é que ela dificulta o trabalho das equipes de TI e segurança de uma organização para rastrear quais regras foram criadas e por quê.
  
  Um autor de regras, como o proprietário de um aplicativo, pode não ter documentado o raciocínio que envolveu as regras de segmentação. Se esse funcionário deixar a empresa, o conhecimento operacional e de segurança vital será perdido.

O maior problema com essa abordagem altamente flexível? Isso deixa lacunas para os atacantes explorarem. O ransomware ainda entra, apesar de todo o tempo, dinheiro e esforço que uma organização investiu na segmentação de suas redes.

A abordagem estruturada de controle de políticas para segmentação

Em contraste com a abordagem " de flexibilidade máxima " para criar regras de segmentação, um fornecedor de segmentação pode restringir o número de rótulos que podem ser criados.

O número de rótulos permitidos pode ser tão baixo quanto quatro, abrangendo apenas funções, aplicativos, ambientes e locais. Ou o número pode ser um pouco maior, mas nem de longe tão alto quanto o número permitido na abordagem de flexibilidade máxima discutida acima.

Acontece que restringir rótulos funciona bem na prática. Na verdade, todas as maiores implantações bem-sucedidas da Segmentação Zero Trust adotam essa abordagem, limitando os rótulos a dez ou menos, mesmo que essas políticas estejam protegendo ambientes de TI híbridos e muito complexos.

Veja por que a abordagem estruturada de controle de políticas funciona tão bem:

• Etiquetas limitadas forçam a centralização e a coordenação antecipadas.
  Para que a gestão de políticas de segmentação funcione bem, uma organização precisa de uma equipe central para analisar o tráfego de rede e desenvolver em conjunto as políticas de segmentação a serem aplicadas.
  
  Os proprietários dos aplicativos coordenam-se com os proprietários dos bancos de dados, que por sua vez coordenam-se com os administradores de firewall. Como trabalham a partir de uma análise e compreensão compartilhadas dos padrões de tráfego autorizados, podem definir regras de segmentação coerentes e mutuamente consistentes que fornecem a segurança necessária.
   
• Ele se baseia na visibilidade abrangente da rede que o controle estruturado de políticas pode oferecer.
  Para coordenar a definição de regras em diferentes aplicações, bases de dados e outros recursos, as equipes de TI e segurança precisam de uma visibilidade abrangente do tráfego de rede da sua organização. Dessa forma, eles podem identificar o tráfego legítimo do qual seus aplicativos e serviços dependem.
  
  Uma vez identificado o tráfego essencial, torna-se mais fácil escrever políticas que bloqueiem todo o resto. Também se torna mais fácil para as diversas partes interessadas chegarem a um acordo sobre qual tráfego deve ser permitido. Quando as partes interessadas conseguem trabalhar a partir de um entendimento comum sobre o uso da rede, a colaboração torna-se simples.
   
• Ele fornece mais simplicidade ao negar todo o tráfego por padrão para a segurança Zero Trust.
  Em vez de oferecer aos stakeholders opções para bloquear o tráfego, permitir o tráfego ou substituir as regras de segmentação anteriores, uma abordagem de política estruturada pode começar bloqueando todo o tráfego por padrão para qualquer sistema ou ambiente. Em seguida, trabalhando com um mapa de visualização que mostra todo o tráfego legítimo da organização, as equipes de TI e segurança podem criar políticas para permitir apenas o tráfego necessário para o aplicativo, banco de dados ou serviço.
  
  Ao não confiar em nada por padrão, os fornecedores de controle de políticas estruturadas oferecem a rigorosa segurança Zero Trust recomendada pelo Instituto Nacional de Padrões e Tecnologia (NIST), pela Casa Branca dos EUA em sua Ordem Executiva sobre a Melhoria da Segurança Cibernética da Nação e por outras autoridades de segurança de TI.
   
• Como a elaboração de regras é centralizada, as equipes de TI e segurança podem testar e mapear as regras antes de aplicá-las.
  Outra vantagem de uma abordagem centralizada para a criação de regras é que, como há um modelo coerente para regras, todo o modelo pode ser executado no modo de teste. Além disso, os caminhos de comunicação entre cargas de trabalho podem ser mapeados visualmente antes da implementação das regras, alertando as equipes sobre possíveis problemas. Isso dá às equipes de TI e segurança a chance de solucionar problemas e ajustar as regras antes de aplicá-las.

Conclusão: Flexibilidade versus escalabilidade

A escolha entre essas duas abordagens se torna difícil quando você está implementando regras em grande escala.

Mesmo em organizações menores, a abordagem altamente flexível rapidamente se torna insustentável. As lacunas de segurança inevitavelmente persistem em meio a um emaranhado de conjuntos de regras desenvolvidos de forma independente. Os ataques passam ou uma regra de segurança bem-intencionada bloqueia acidentalmente o tráfego de missão crítica porque não há uma coordenação unificada.

Por outro lado, ao aplicar uma disciplina de design antecipada, a abordagem estruturada de controle de políticas para segmentação ajuda as equipes de TI e segurança a proteger de forma simples e eficiente qualquer tipo de ambiente de TI, desde startups até as maiores e mais complexas redes globais.

Para saber mais sobre a solução Illumio para segmentação Zero Trust:

• Obtenha o Relatório de Impacto do Zero Trust para conhecer as pesquisas do ESG sobre como as organizações estão abordando o Zero Trust.
• Baixe nosso guia detalhado Como criar uma estratégia de microssegmentação em 5 etapas.
• Obtenha uma cópia gratuita do Forrester New Wave: Microsegmentation, Q1 2022, no qual a Illumio é nomeada líder.
• Agende uma demonstração e consulta sem compromisso com nossos especialistas em Segmentação Zero Trust.