O que Hollywood me ensinou sobre Zero Trust

Ken Arora

Se algum dia — em alguma realidade alternativa ou futuro fantasioso — eu tiver a oportunidade de projetar os sistemas de computador da Frota Estelar, uma coisa que eu certamente garantiria é que os sistemas de armas não estivessem conectados às sub-rotinas de suporte à vida. Ou, se eu fosse o comandante de uma força de invasão alienígena incumbida de dominar a Terra — um planeta habitado por uma espécie completamente diferente, vale lembrar —, eu exigiria autenticação biométrica, em vez de uma senha ou token. E, por fim, se algum dos meus oficiais ou alguma de minhas naves espaciais, contra todas as probabilidades, “escapasse” milagrosamente de seus captores, eu certamente verificaria primeiro se não estavam carregando nenhum cavalo de Troia.

Então, o que isso tem a ver com confiança zero? Como você provavelmente já deve ter percebido, Hollywood adora enredos que retratam as consequências épicas de abrir mão de uma pequena dose de paranoia saudável desde o início. E, da minha perspectiva como profissional de cibersegurança, essa mesma mentalidade — manter uma paranoia saudável — está no cerne do verdadeiro significado da confiança zero.

Então, por que estou optando por me concentrar especificamente em confiança zero? Minha motivação se baseia em uma tendência na forma como o termo “confiança zero” é usado atualmente. Retomando outra história sobre produção cinematográfica, desta vez do final dos anos 1980, essa foi a época em que Hollywood estava migrando das antigas tecnologias analógicas para padrões digitais de áudio, vídeo e edição de pós-produção. Naquele contexto, muitos dos integrantes menos técnicos da comunidade cinematográfica não entendiam o que “digital” realmente significava, nem faziam muita questão de entender; para eles, o termo “digital” era, na prática, sinônimo de “o que há de melhor”. Como resultado — para grande desgosto dos meus amigos da área de tecnologia que trabalhavam com eles —, produtores e diretores começaram a perguntar se a iluminação ou a construção dos cenários era “digital”, quando o que realmente queriam saber era: “Este é o melhor projeto de iluminação ou a melhor construção de cenários?” Voltando aos dias de hoje, ouço com frequência excessiva o termo “confiança zero” ser usado na comunidade de CSOs praticamente da mesma forma como os produtores de cinema usavam “digital” em 1990.

Além disso, conheci recentemente a estrutura “Comece pelo porquê”, de Simon Sinek. Essa estrutura, combinada às lembranças de como Hollywood encarava os primórdios do “digital” e de como os filmes criavam histórias com base em (más) práticas de segurança, ajudou a organizar várias reflexões que eu tinha sobre confiança zero. No cerne da confiança zero está a moral das tramas de Hollywood com as quais iniciei: abrir mão de uma pequena dose de prevenção cibernética criteriosa ao projetar e operar a segurança de um sistema crítico resultará em uma grande dose de comprometimento e sofrimento mais adiante. De forma análoga, no nível central do “porquê” dessa estrutura, a confiança zero pode ser expressa pelo seguinte conjunto de convicções:

A. Sempre verifique explicitamente ‘quem’: Isto é, o agente que está tentando interagir com o seu sistema.

B. Adote como padrão o menor privilégio necessário: Depois que a identidade for estabelecida, conceda a esse agente apenas os privilégios necessários para interagir com o sistema na transação comercial específica que está sendo realizada, conforme os privilégios necessários enumerados no projeto.

C. Monitorar e (re)avaliar continuamente: A verificação de identidade e os direitos de acesso não devem ser algo estático e pontual; em vez disso, essas decisões devem ser avaliadas e reavaliadas continuamente.

D. E, ainda assim, presuma que você foi comprometido: Por fim, apesar de cumprir os três itens acima, presuma que um adversário sofisticado tenha conseguido superar as defesas. Portanto, o sistema também deve considerar como identificar e isolar quaisquer elementos ou identidades comprometidos, bem como uma estratégia para conter e/ou remediar o impacto deles sobre o sistema.

Em resumo: Não confie implicitamente; em vez disso, sempre verifique. E confie apenas o necessário. E avalie continuamente. E não presuma que você conseguirá detectar todos eles. Esse é o “porquê” da confiança zero.

É claro que o “porquê” é apenas parte da história. O “como” — isto é, as técnicas e ferramentas usadas para colocar em prática a mentalidade gerada pelo “porquê” — é outra perspectiva relevante para o profissional; ele surge como consequência das convicções mencionadas anteriormente. Mais uma vez, serei específico, situando a questão no contexto do conjunto atual de ferramentas disponíveis hoje para os profissionais de cibersegurança:

1. Autenticação: Qualquer agente que interaja com o sistema protegido deve declarar possuir alguma identidade ou, em alguns casos, um conjunto de identidades — como uma identidade para a pessoa ou o sistema automatizado, juntamente com uma identidade para o dispositivo ou a plataforma em que a pessoa ou o sistema opera e, talvez, até mesmo uma identidade para o navegador ou a ferramenta usada para viabilizar o acesso. A mentalidade de confiança zero pressupõe que qualquer declaração desse tipo seja verificada, ou “autenticada”, por um ou mais meios: um segredo compartilhado, um token ou certificado e, em sistemas mais modernos, também pela observação e verificação do padrão de comportamento desse agente.
   
2. Controle de acesso: Depois que a identidade for estabelecida, deve-se atribuir a ela um nível de confiança, representado pelos direitos de controle de acesso concedidos a essa identidade. A política de controle de acesso deve seguir o princípio do privilégio mínimo, segundo o qual são concedidos apenas os direitos mínimos necessários para que o agente desempenhe sua função no sistema. As implementações ideais de controle de acesso devem permitir a especificação granular dos direitos concedidos, como: A função <X> permite acesso às APIs <1>, <3> e <4>, além de privilégios de leitura para objetos das classes <Y> e <Z>. Uma prática recomendada importante é que cenários complexos de controle de acesso voltados a recursos de aplicações sejam abstraídos por meio de APIs, em vez de conceder acesso direto a objetos, arquivos e recursos de rede.
   
3. Visibilidade: Passando à parte de “monitoramento” dessa abordagem — um pré-requisito para a “reavaliação contínua” —, o sistema deve ser capaz de oferecer visibilidade contínua e em tempo real dos comportamentos de cada agente no sistema. Nesse contexto, a afirmação “se você não viu, não aconteceu” é axiomática. Além disso, a “telemetria” coletada não só deve estar visível, como também deve ser utilizável, no sentido de que precisa existir em uma estrutura que permita o compartilhamento e a contextualização das informações relatadas. Isso possibilita que dados de várias fontes sejam combinados e correlacionados de forma significativa, permitindo uma avaliação de riscos mais robusta e eficaz.
   
4. Análise contextual assistida por aprendizado de máquina: A motivação para a visibilidade mencionada anteriormente é permitir a aplicação do princípio de “reavaliação contínua”. Na prática, esse preceito exige não apenas visibilidade, mas também análise — geralmente de várias fontes de dados (o que requer a estrutura propícia ao compartilhamento mencionada anteriormente) — quase em tempo real. Para isso, a avaliação contínua frequentemente precisará do auxílio de sistemas de aprendizado de máquina com IA para detectar agentes que apresentem comportamentos anômalos e identificar qualquer possível comprometimento do sistema. Por fim, um mecanismo de análise robusto deve ser capaz de fornecer uma resposta mais detalhada do que um simples sim ou não — idealmente, uma avaliação de risco acompanhada de um respectivo grau de confiança.
   
5. Remediação automatizada e orientada a riscos: Por fim, como parte da premissa é que alguns adversários sofisticados ainda conseguirão se infiltrar no sistema, este deve ser capaz de agir para realizar um monitoramento mais aprofundado e, quando necessário, conter e/ou bloquear essas ações ou agentes. A resposta do sistema — que pode variar do simples registro de eventos à inspeção aprofundada, ao bloqueio da ação tentada ou até mesmo ao uso de técnicas para enganar o agente mal-intencionado suspeito — deve ser considerada no contexto mais amplo dos negócios. A probabilidade e o impacto de falsos positivos ou negativos, bem como o risco da ação para os negócios, fazem parte dessas considerações. Por exemplo, bloquear a navegação em um catálogo de produtos talvez só seja apropriado quando houver um grau muito alto de confiança de que o agente é um coletor mal-intencionado de dados do site; por outro lado, exigir autenticação adicional pode ser apropriado para uma transação bancária mesmo com um grau de confiança mais moderado. Por fim, devido à sofisticação e à velocidade dos ataques cibernéticos modernos, a ação operacional de remediação deve ser passível de automação, e a política definida por pessoas deve ser descrita em termos de objetivos orientados por intenção.

O aspecto final da estrutura “por quê, como, o quê” é o “o quê” — ou seja, os objetivos podem ser alcançados e as classes de ataques podem ser prevenidas ou mitigadas por meio das ferramentas e técnicas mencionadas acima. Uma taxonomia completa de todo o conjunto de ataques cibernéticos será tema de um artigo futuro; no entanto, como uma prévia do que está por vir, o “por quê” e o “como” descritos aqui de fato abrangem o espectro das sofisticadas “ameaças avançadas”. Por exemplo, a mentalidade de confiança zero pode lidar com ameaças de ransomware, mesmo quando iniciadas por componentes de software “confiáveis” (também conhecidas como “ataques à cadeia de suprimentos”). Especificamente, a aplicação do princípio do privilégio mínimo, incorporado à política de controle de acesso, deve ser usada para limitar as permissões de leitura e gravação de arquivos apenas aos agentes que realmente necessitam desse privilégio, impedindo a criptografia dos recursos de arquivos. Além disso, caso algum agente — talvez um componente de software existente com permissões de gravação de arquivos — seja comprometido (por meio do vetor de ataque à cadeia de suprimentos mencionado anteriormente) e tente criptografar rapidamente um grande número de arquivos, a reavaliação e a análise contínuas devem detectar o comportamento anômalo em pouco tempo, observando a abrangência dos arquivos acessados e a frequência com que são acessados. A detecção, aliada à mitigação automatizada, pode ser usada para bloquear rapidamente esse tipo de atividade.

Então, voltando aos mundos alternativos com os quais comecei... Se todos os subsistemas de computador da Frota Estelar operassem segundo o princípio do privilégio mínimo, a API que lança torpedos de fótons não deveria poder ser acionada pelo subsistema de controle de gravidade. E os controles da nave-mãe alienígena não apenas realizariam MFA com base em biometria, como também partiriam do pressuposto de que violações ocorrerão — e, portanto, fariam monitoramento e reavaliação contínuos, detectando a anomalia de um drone de combate que atravessasse a nave e neutralizando a ameaça caso esse drone anômalo se dirigisse ao núcleo do motor. Essas poucas e essenciais medidas preventivas evitariam uma grande dose do drama subsequente — ruim para Hollywood, mas bom para os profissionais de cibersegurança.

Para saber mais sobre a estrutura que abrange os conceitos gerais de confiança zero, considerando o contexto empresarial atual e a mentalidade de segurança que os líderes de negócios responsáveis por aplicações devem adotar, leia nosso white paper Segurança de confiança zero: por que a confiança zero é importante (e não apenas para o acesso).

Sobre o autor

Ken Arora

Mais publicações de Ken Arora