BLOG | ESCRITÓRIO DO DIRETOR DE TECNOLOGIA

O que Hollywood me ensinou sobre Zero Trust

Miniatura de Ken Arora
Ken Arora
Publicado em 05 de maio de 2022


Se eu algum dia — em alguma realidade alternativa ou futuro de fantasia — 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 a sub-rotinas de suporte de vida. Ou, se eu fosse o comandante de uma força de invasão alienígena encarregada de dominar a Terra — um planeta com uma espécie completamente diferente, veja bem — eu insistiria na autenticação biométrica, em vez de uma senha ou token. E, finalmente, se algum dos meus oficiais ou naves espaciais, contra todas as probabilidades, milagrosamente “escapasse” de seus captores, eu certamente verificaria primeiro para ter certeza de que eles não estavam carregando nenhum cavalo de Tróia.

Então, o que isso tem a ver com confiança zero? Como você provavelmente já deve ter adivinhado, Hollywood adora histórias que encenam as consequências épicas resultantes de abrir mão de algumas gramas de paranoia saudável e antecipada. E, da minha perspectiva como profissional de segurança cibernética, essa mesma mentalidade — manter uma paranoia saudável — está no cerne do que realmente significa a confiança zero.

Então, por que estou escolhendo focar especificamente em confiança zero? Minha motivação se baseia em uma tendência de como o termo “confiança zero” está sendo usado hoje. Voltando a outra anedota sobre produção cinematográfica, esta do final dos anos 80, esta foi a época em que Hollywood estava fazendo a transição das tecnologias analógicas legadas para os padrões digitais de áudio, vídeo e edição pós-processamento. Naquela época e lugar, muitos dos membros menos técnicos da comunidade cinematográfica não entendiam o que “digital” realmente significava, nem se importavam em entender; em vez disso, o termo “digital” era, para eles, efetivamente sinônimo de “o melhor da categoria”. Como resultado — e para grande desgosto dos meus amigos técnicos que trabalharam com eles — produtores e diretores começaram a perguntar se a iluminação ou a construção do cenário era "digital", quando o que eles realmente queriam dizer era: “Este é o melhor design de iluminação ou a melhor construção de cenário?” Agora, voltando ao presente, ouço muitas vezes o termo “confiança zero” sendo usado na comunidade das OSCs, da mesma forma que os produtores de cinema usaram o termo “digital” em 1990.  

Separadamente, fui recentemente apresentado à estrutura “Começa com o Porquê” de Simon Sinek. Essa estrutura, elaborada juntamente com lembranças de como Hollywood pensava sobre os primeiros dias do "digital" e como os filmes criavam histórias baseadas em (más) práticas de segurança, ajudou a destilar uma série de pensamentos que eu tinha sobre a confiança zero. No cerne da confiança zero está a moral das histórias de Hollywood com as quais comecei: abrir mão de alguns gramas de prevenção cibernética cuidadosa no design e na operação de proteção de um sistema crítico resultará em quilos de comprometimento e sofrimento posteriores. Analogamente, no nível central do “porquê” da estrutura, a confiança zero pode ser articulada como o seguinte conjunto de crenças:

UM.     Sempre verifique explicitamente ' quem': Que é o ator que está tentando interagir com seu sistema.

B.     Padrão para o menor privilégio necessário: Uma vez estabelecida a identidade, conceda ao ator apenas o privilégio necessário para interagir com o sistema para a transação comercial específica que está sendo realizada, com os privilégios necessários enumerados pelo design.

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

D. E, ainda assim, suponha que você foi comprometido: Por fim, apesar de fazer os três itens acima, presuma que um adversário sofisticado conseguiu passar pelas defesas. Portanto, o sistema também deve considerar como identificar e isolar quaisquer elementos ou identidades comprometidos, e uma estratégia para contenção e/ou remediação de seu impacto no sistema.

Simplesmente: Não confie implicitamente, em vez disso, verifique sempre. E confie apenas o necessário. E avalie continuamente. E não presuma que você vai pegar todos eles. Esse é o "porquê" da confiança zero.

Zero Trust

Claro, o "porquê" é apenas parte da história. O "como" — isto é, as técnicas e ferramentas usadas para incorporar a mentalidade que o "porquê" engendra — é outra lente que é relevante para o praticante; ela surge como consequência das crenças acima mencionadas. Aqui, novamente, serei específico, formulado dentro do contexto do conjunto atual de ferramentas que os profissionais de segurança cibernética de hoje têm disponíveis:

  1. Autenticação : Qualquer ator que interaja com o sistema protegido deve atestar que possui alguma identidade ou, em alguns casos, uma tupla de identidades, como uma identidade para o sistema humano ou automatizado, juntamente com uma identidade para o dispositivo ou plataforma em que o humano/sistema está, e talvez até mesmo uma identidade para o navegador ou ferramenta usada para facilitar o acesso. A mentalidade de confiança zero implica que qualquer atestado desse tipo deve ser verificado, ou “autenticado”, por um ou mais meios: um segredo compartilhado, um token ou certificado e, em sistemas mais modernos, também observando e verificando o padrão de comportamento desse ator.
     
  2. Controle de acesso : Uma vez estabelecida a identidade, deve ser atribuído 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 menor privilégio, onde os únicos direitos concedidos são o conjunto mínimo necessário para que o ator desempenhe sua função dentro do sistema. Implementações ideais de controle de acesso devem permitir especificações detalhadas dos direitos concedidos, como: A função permite acesso às APIs <1>, <3> e <4> e privilégios de leitura para objetos da classe e . Uma prática recomendada a ser observada é que cenários complexos de controle de acesso direcionados a recursos de aplicativos devem ser abstraídos por trás de APIs, em vez de conceder acesso direto a objetos, arquivos e recursos de rede.
     
  3. Visibilidade : Passando para a parte de “monitorar” da mentalidade — um pré-requisito para “reavaliação contínua” — o sistema deve ser capaz de visibilidade contínua e em tempo real dos comportamentos de cada ator no sistema. Neste contexto, a afirmação “se você não viu, não aconteceu” é axiomática. Além disso, a “telemetria” coletada não só deve ser visível, mas também deve ser consumível, no sentido de que deve existir dentro de uma estrutura que permita o compartilhamento e a contextualização do que é relatado. Isso permite que dados de diversas fontes sejam combinados e correlacionados de forma significativa, permitindo uma avaliação de risco mais robusta e de maior eficácia.
     
  4. Análise contextual, assistida por ML : A motivação para a visibilidade mencionada acima é poder executar o princípio de “reavaliação contínua”. Na implementação, esse preceito exige não apenas visibilidade, mas análise — normalmente, em diversas fontes de dados (exigindo a estrutura de compartilhamento amigável mencionada anteriormente) quase em tempo real. Para fazer isso, a avaliação contínua frequentemente exigirá assistência de sistemas de aprendizado de máquina de IA para detectar agentes que estejam agindo de forma anômala, a fim de 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/não binário — de preferência, uma avaliação de risco junto com uma pontuação de confiança associada.
     
  5. Remediação automatizada com reconhecimento de risco : Por fim, como parte do sistema de crenças é que alguns adversários sofisticados ainda conseguirão se infiltrar no sistema, o sistema deve ser capaz de agir para monitorar mais profundamente e, quando necessário, conter e/ou bloquear tais ações ou atores. A resposta do sistema — desde o mero registro até uma inspeção mais profunda, passando pelo bloqueio da tentativa de ação ou até mesmo enganando o suspeito — deve ser considerada no contexto empresarial de nível superior. A probabilidade e o impacto de falsos positivos ou negativos, e o risco comercial da ação, fazem parte dessas considerações. Por exemplo, bloquear a navegação em um catálogo de produtos pode ser apropriado somente se houver alta confiança de que o agente seja um scraper de site malicioso, mas exigir autenticação adicional pode ser apropriado para uma transação bancária com um grau menor de confiança. Por fim, devido à sofisticação e à velocidade dos ataques cibernéticos modernos, a ação de remediação operacional deve ser automatizável, com a política especificada pelo ser humano sendo descrita em termos de objetivos orientados pela intenção.

O aspecto final da estrutura “por que, como, o quê” é o “o quê” — ou seja, os objetivos podem ser alcançados e as classes de ataques podem ser prevenidas ou mitigadas, usando as ferramentas e técnicas acima. Uma taxonomia completa do conjunto completo de ataques cibernéticos será um tópico para um artigo futuro; no entanto, como uma prévia das atrações futuras, o “porquê” e o “como” descritos aqui abordam o espectro de “ameaças avançadas” sofisticadas. Como exemplo, a mentalidade de confiança zero pode lidar com ameaças de ransomware, mesmo se iniciadas por componentes de software “confiáveis” (também conhecidos como “ataques à cadeia de suprimentos”). Especificamente, a aplicação do princípio do menor privilégio, incorporado na política de controle de acesso, deve ser usada para limitar as permissões de leitura/gravação de arquivos apenas aos atores que exigem esse privilégio, impedindo a criptografia de recursos de arquivo. Além disso, caso algum agente — talvez um componente de software existente com permissões de gravação de arquivo seja comprometido (usando o vetor de ataque da cadeia de suprimentos mencionado anteriormente) — tente criptografar dados de alta taxa em muitos arquivos, a reavaliação e análise contínuas devem detectar o comportamento anômalo em pouco tempo, conforme descoberto ao observar o intervalo de arquivos acessados e a taxa em que eles são acessados. A detecção, acoplada à mitigação automatizada, pode ser usada para bloquear rapidamente tal atividade. 

Então, voltando aos mundos alternativos com os quais comecei... Se todos os subsistemas de computador da Frota Estelar operassem com base no princípio do menor privilégio, a API que lança torpedos de fótons não deveria ser invocável pelo subsistema de controle de gravidade. E os controles da nave-mãe alienígena não apenas executariam MFA com base biométrica, mas os controles de segurança da nave-mãe também presumiriam que violações ocorreriam — e, portanto, estariam monitorando e reavaliando continuamente, detectando a anomalia de um drone de caça que voasse pela nave e mitigando a ameaça se esse drone anômalo se dirigisse ao núcleo do motor. Essas poucas medidas preventivas evitariam muito drama consequente — ruim para Hollywood, mas bom para os profissionais de segurança cibernética.

Para saber mais sobre a estrutura que abrange os conceitos amplos em torno da confiança zero, em relação ao cenário empresarial existente e a mentalidade de segurança que os líderes empresariais de aplicativos devem adotar, leia nosso whitepaper Segurança de confiança zero: Por que o Zero Trust é importante (e para mais do que apenas acesso) .