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

Em última análise, 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 pode ser confinada para 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 para 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íticas 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, requisitos de segurança variará 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ídos em ambientes de nuvem, locais e de terminais — o que logo resultará 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 elaboração de regras é 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. O aplicativo pode depender do banco de dados, mas as regras de acesso definidas para o aplicativo e o banco de dados são desenvolvidas de forma independente. Como resultado, os dois conjuntos de regras podem ser inconsistentes, especialmente se outros aplicativos também usarem o banco de dados.
  
  Outro exemplo: uma pessoa é responsável pelo aplicativo de gerenciamento de relacionamento com clientes (CRM) da empresa. Outra pessoa é responsável pelo data center da empresa em Nova York, onde o aplicativo de CRM está sendo executado. Mesmo que essas duas pessoas concordem com as filosofias de segurança, é altamente improvável que suas implementações independentes de regras de segmentação funcionem perfeitamente juntas. Há muita complexidade envolvendo endereços IP, portas e protocolos para 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.
  Os produtos de segmentação que distribuem o controle dessa forma geralmente permitem que os clientes definam seus categorias ou rótulos próprios para segmentação.
  
  Aproveitando essa flexibilidade, os clientes logo terão vinte, trinta ou mais rótulos para suas políticas de segmentação. Por exemplo, um cliente pode rotular todos os ativos de TI envolvidos em PCI conformidade com o rótulo de “Conformidade com PCI”. Eles também podem rotular todos os ativos em um local específico com o nome do local ou ter rótulos para unidades de negócios, aplicativos, ambientes (por exemplo, teste versus produção), regulamentações governamentais adicionais (como GDPR) e assim por diante.
  
  Em teoria, essa proliferação de rótulos fornece precisão e visibilidade. Na prática, isso leva a modelos de segurança que são muito complexos para serem gerenciados com eficiência.
  
  As equipes podem tentar reduzir esse caos por meio da ordenação de regras — por exemplo, estruturar conjuntos de regras para aplicar primeiro as regras do data center, depois aplicar as regras do aplicativo e, por último, aplicar 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 dizer 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 regulamentação distribuída é que ela dificulta que as equipes de TI e segurança de uma organização acompanhem 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 a 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, o maiores implantações bem-sucedidas Todos da Zero Trust Segmentation 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 o gerenciamento 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 de aplicativos coordenam com os proprietários do banco de dados, que, por sua vez, coordenam com os gerentes de firewall. Como estão trabalhando a partir de uma análise e compreensão compartilhadas dos padrões de tráfego autorizados, eles podem definir regras de segmentação coerentes e mutuamente consistentes que forneçam a segurança de que precisam.
  
• Ele se baseia na visibilidade abrangente da rede que o controle estruturado de políticas pode oferecer.
  Para coordenar a elaboração de regras em diferentes aplicativos, bancos de dados e outros recursos, as equipes de TI e segurança precisam visibilidade abrangente no tráfego de rede de sua organização. Dessa forma, eles podem identificar o tráfego legítimo do qual seus aplicativos e serviços dependem.
  
  Depois que esse tráfego essencial é identificado, fica mais fácil escrever políticas que bloqueiem todo o resto. Também fica mais fácil para várias partes interessadas concordarem sobre qual tráfego deve ser permitido. Quando as partes interessadas podem trabalhar a partir de um entendimento compartilhado do uso da rede, a colaboração se torna simples.
  
• Ele fornece mais simplicidade ao negar todo o tráfego por padrão para a segurança Zero Trust.
  Em vez de oferecer às partes interessadas opções para bloquear o tráfego, permitir o tráfego ou ignorar as regras de segmentação anteriores, uma abordagem de política estruturada pode começar bloqueando todo o tráfego por padrão em qualquer sistema ou ambiente. Em seguida, trabalhando a partir de um mapa de visualização que mostra todo o tráfego legítimo em toda a organização, as equipes de TI e segurança podem criar políticas para permitir apenas o tráfego exigido pelo aplicativo, banco de dados ou serviço.
  
  Ao não confiar em nada por padrão, os fornecedores estruturados de controle de políticas fornecem a rigorosa segurança Zero Trust recomendada pela Instituto Nacional de Padrões e Tecnologias (NIST), a Casa Branca dos EUA em sua Ordem executiva para melhorar a segurança cibernética do paíse 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 aprender 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: microssegmentação, primeiro trimestre de 2022 em que Illumio é nomeado Líder.
• Cronograma uma demonstração sem compromisso e uma consulta com nossos especialistas em Segmentação Zero Trust.