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

Esta série de posts no blog aprofunda as ideias apresentadas na minha publicação de março, “A Confiança Zero não é difícil… Se você for pragmático”.

Nessa postagem, descrevi seis etapas para alcançar o Zero Trust e, aqui, gostaria de expandir uma dessas etapas, a saber, prescrever 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

No último post desta série, abordei os tópicos “Determine em qual pilar do Zero Trust focar” e “Especifique o controle exato”. A avaliação dessas etapas resultou nas seguintes informações para ajudá-lo a avançar na implementação do Zero Trust:

• Determine em qual pilar do Zero Trust focar: Segurança e visibilidade da carga de trabalho, pois a Avaliação de Maturidade do Zero Trust que você realizou identificou esses 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ê tiver conhecimento pré-existente: especifique uma regra de segmentação com base no IP de origem, IP de destino, porta, 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 membro da equipe de operações de segurança , uma versão do evento é claramente superior. A versão com contexto fornece uma visão completa do fluxo: você pode ver que o Servidor Web de Pagamentos de Produção tem uma dependência do Servidor DNS de Produção, que possui o processo nomeado recebendo conexões na porta 53/udp. Como avaliador, você pode decidir rapidamente se o fluxo lhe interessa, se é um tráfego normal ou se justifica uma investigação mais aprofundada. Você pode classificá-lo facilmente (ou até mesmo criar ferramentas para classificá-lo automaticamente), e isso só é possível graças ao contexto adicional que você possui.

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.

O Illumio Core utiliza esses metadados, coletados do CMDB de uma organização ou de outra fonte de dados confiável (ou autorizada), para preencher os rótulos associados a uma carga de trabalho. Essas etiquetas associam uma Função, Aplicativo, Ambiente e Localização a cada carga de trabalho e nos ajudam a construir um mapa de dependências de aplicativos abrangente que identifica claramente as dependências upstream e downstream para cada aplicativo. E isso nos coloca em uma ótima posição para revisar fluxos e elaborar 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.