Operacionalizando o Zero Trust — Etapa 4: prescrever quais dados são necessários

Esta série de blogs expande as ideias apresentadas em minha postagem de março,”Zero Trust não é difícil... Se você é pragmático.”

Nesse post, descrevi seis etapas para alcançar o Zero Trust e, aqui, gostaria de expandir uma dessas etapas, a saber: prescrevendo quais dados são necessários. Mostrarei como essa etapa pode apoiar a implementação de uma estrutura sólida que pode ser usada por qualquer profissional de segurança para tornar seus projetos mais bem-sucedidos, independentemente do tamanho da organização.

Antes de começar, aqui está uma atualização sobre as seis etapas:

Etapa 4: prescrever quais dados são necessários

Na última postagem nesta série, examinei “Determinar em qual pilar do Zero Trust focar” e “Especificar o controle exato”. A avaliação dessas etapas resultou nas seguintes informações para ajudá-lo a avançar na operacionalização do Zero Trust:

• Determine em qual pilar do Zero Trust focar: Segurança e visibilidade da carga de trabalho porque o Avaliação de maturidade Zero Trust você os identificou como os pilares com as lacunas mais significativas.
• Especifique o controle exato: Como a avaliação identificou o acesso excessivo à rede como a lacuna de segurança mais significativa, o controle em que você se concentrará é a microssegmentação.

Depois de definir exatamente para que você deseja melhorar a proteção e quais controles deseja aproveitar, você pode começar a reunir as informações necessárias para implementar esses controles de forma eficaz.

Vamos começar com o estado final desejado:

• Você quer criar uma política de microssegmentação para proteger suas cargas de trabalho.
• Você quer que essa política siga os princípios do Zero Trust.
• Portanto, as regras que você cria devem permitir somente o acesso às cargas de trabalho necessárias para realizar suas funções comerciais.

Então, o que você precisa para isso? Dependendo se você tem conhecimento pré-existente sobre os fluxos necessários ou se está realmente começando do zero em um ambiente abandonado, que já está operando há muitos anos, você pode ter duas respostas ligeiramente diferentes para isso.

• Se você tem conhecimento pré-existente: Especifique uma regra de segmentação com base no IP de origem, IP de destino, porta e protocolo
• Se você estiver em um ambiente abandonado: Obtenha registros de tráfego para ajudá-lo a identificar fluxos que possam ser relevantes

Você já passou muitas horas e dias analisando registros de tráfego de firewalls tentando descobrir o que uma conexão específica está fazendo? E você foi forçado a procurar informações ou pessoas que possam fornecer um contexto valioso a um fluxo para que seu propósito possa ser entendido adequadamente? Você repetiu isso para a próxima linha nos registros, e na próxima, e na próxima...? Agora imagine ter que fazer isso para todos os aplicativos no escopo da segmentação — não é minha ideia de diversão. Parece jogar “encontre a agulha no palheiro” repetidamente.

Agora, imagine um universo alternativo em que todos esses excelentes dados de tráfego de repente forneçam mais do que apenas as 5 tuplas de informações padrão. E se, em vez disso, você pudesse reunir o contexto de uma conexão imediatamente, sem precisar fazer essa busca, para poder entender o contexto de um evento de trânsito apenas olhando para ele? É como passar de um filme em preto e branco sem áudio para algo em 4K com som Dolby Atmos.

Para contextualizar isso, vamos usar um exemplo.

Registro de tráfego normal:

• Fonte: 10.0.0.1
• Destino: 192.168.0.1
• Porta: 53
• Protocolo: UDP
• Ação: Permitir

Registro de tráfego com contexto:

• Fonte: 10.0.0.1
• Contexto de origem: servidor Web, aplicativo de pagamentos, produção, Reino Unido
• Destino: 192.168.0.1
• Destino: Contexto: Respondente de DNS, Infraestrutura de DNS, Produção, Reino Unido
• Processo de destino: nomeado
• Porta: 53
• Protocolo: UDP
• Ação: Permitir

Como proprietário de um aplicativo ou operações de segurança membro da equipe, uma versão do evento é claramente superior. A versão com contexto fornece uma visão completa do fluxo: você pode ver que o Production Payments Web Server depende do Respondente DNS de Produção, que tem o processo nomeado recebendo conexões em 53/udp. Como revisor, você pode decidir rapidamente se é um fluxo que lhe interessa, se é tráfego normal ou se ele merece uma investigação mais aprofundada. Você pode classificá-lo facilmente (ou até mesmo criar algumas ferramentas para classificá-lo automaticamente) e só pode fazer isso por causa do contexto adicional que você tem.

Um dos aspectos mais importantes do Zero Trust — e ele não recebe tanta cobertura quanto deveria — é que a implementação efetiva do Zero Trust depende do acesso a informações contextuais, ou metadados, para ajudar a formular políticas. Portanto, ao falar sobre microssegmentação no contexto da proteção de cargas de trabalho, os metadados mínimos fora de um relatório de tráfego padrão de que você precisa descrevem as cargas de trabalho no contexto de seus aplicativos e ambientes de data center.

Núcleo Illumio usa esses metadados coletados do CMDB de uma organização ou de outra fonte dourada (ou autorizada) para preencher os rótulos associados a uma carga de trabalho. Esses rótulos associam uma função, aplicativo, ambiente e local a cada carga de trabalho e nos ajudam a criar uma rica mapa de dependência de aplicativos que identifica claramente as dependências upstream e downstream de cada aplicativo. E isso nos coloca em uma ótima posição para revisar fluxos e projetar políticas.

Em meu próximo post, discutirei como criar uma política de Zero Trust.

Pronto para dar o próximo passo em sua jornada com o Zero Trust? Visite nossa página sobre como operacionalizar sua estratégia Zero Trust com microssegmentação.