Segurança Zero Trust: Por que a confiança zero é importante (e para mais do que apenas acesso)

Um dos principais temas no acesso à rede e aos aplicativos nos últimos anos tem sido o conceito de “confiança zero”.  Neste artigo, mostramos como, em sua essência, a confiança zero pode ser caracterizada por um pequeno conjunto de crenças simples que podem ser aplicadas não apenas ao acesso, mas também de forma mais ampla em todo o espaço da segurança cibernética. 

Este artigo apresenta uma estrutura para abranger os conceitos amplos em torno da confiança zero, relacionando-os ao cenário empresarial existente que motiva os líderes empresariais de segurança de aplicativos de hoje.  Por fim, este artigo fornece uma caracterização do sistema de crenças de confiança zero – o impulsionador das ferramentas e implementações de segurança que abordam as ameaças atuais e emergentes, que serão o foco de um artigo subsequente.

Os objetivos deste artigo são duplos: primeiro, transmitir a mentalidade de segurança que os líderes empresariais de aplicativos devem adotar e, segundo, apresentar uma estrutura para profissionais de segurança que expandiremos em futuros white papers. 

O termo “confiança zero” está associado a uma série de conceitos diferentes em várias camadas de abstração: às vezes como uma arquitetura de solução específica, às vezes como uma prescrição para aplicar tecnologias específicas e, outras vezes, quando pode se referir a uma propriedade de um produto.  Acreditamos que a segurança de confiança zero é, em sua essência, uma mentalidade – um sistema de crenças – da qual técnicas e táticas emergem e alavancam tecnologias específicas, que podem então ser aplicadas para lidar com um amplo espectro de ameaças à segurança.

O sistema de crenças que fundamenta a segurança de confiança zero (ZTS) pode ser visto como o próximo passo na evolução da mentalidade de segurança que começou com a “defesa em profundidade” anos atrás.  A defesa em profundidade se baseia na crença de que, embora qualquer tela defensiva tenha uma probabilidade pequena, mas real, de violação, a adição de camadas maiores de proteção para ativos importantes reduz essa probabilidade, retardando os invasores e também os forçando a usar mais recursos para um ataque bem-sucedido.

A confiança zero é um amadurecimento dessa mentalidade em três dimensões:

• Primeiro, ele evolui a premissa de proteção de um conjunto de “filtros” simples que controlam o acesso ao aplicativo para um conjunto de proteções mais apropriado aos ativos, aplicado contextualmente a qualquer transação do sistema .  A mentalidade de cada transação é entender:  Quem está tentando qual ação em quem .  O “quem” e “a quem” podem ser qualquer componente dentro do sistema ou usando o sistema, seja humano, automatizado ou um pedaço de código.  O conceito de identidade é fundamental para quem e quem , e o conceito de privilégios concedidos a uma identidade é usado para codificar o que pode ser feito.
• Em segundo lugar, considera a avaliação da decisão de segurança não como sendo estática e absoluta, mas sim mais dinâmica e adaptável , a ser continuamente reavaliada à luz dos comportamentos observados.  A decisão sobre a disposição de cada transação – se deve permitir a interação, bloqueá-la, criar confiança adicional e assim por diante – também deve considerar o contexto empresarial mais amplo e, especificamente, a compensação entre risco e recompensa.
• Por fim, é certo que, não importa quantas camadas de proteção sejam fornecidas, um adversário suficientemente motivado ou afortunado violará ou contornará as proteções . Portanto, a detecção oportuna de qualquer comprometimento e a mitigação de tentativas de exploração também devem ser uma parte fundamental da estratégia geral.

Essa evolução foi, em parte, resultado do tempo e da experiência, mas é cada vez mais impulsionada pela confluência de duas outras tendências de segurança de aplicativos.  Especificamente, as arquiteturas de aplicativos de hoje abrem um espaço potencial muito maior de vulnerabilidades de aplicativos – notavelmente ameaças de “dentro” da infraestrutura do aplicativo – que estão abertas à exploração pela sofisticação crescente dos adversários de hoje.  Felizmente, os avanços simultâneos em ferramentas de segurança, especialmente quando usados em conjunto com recursos modernos de coleta e análise de dados, permitiram a implementação prática de componentes-chave da estratégia defensiva.

O restante desta introdução apresenta uma visão geral da estrutura para nossa abordagem à segurança de confiança zero, bem como seu escopo.  A partir daí, as seções seguintes expandem a declaração do problema e sua relação com outras abordagens contemporâneas de confiança zero, levando a uma discussão sobre as crenças centrais – o “porquê” – que devem orientar a escolha de tecnologias de solução e sua aplicação.  Artigos futuros se aprofundarão no “como” – os requisitos impostos a tecnologias específicas, como autenticação, controle de acesso e análise assistida por IA, conforme se relacionam ao modelo de maturidade de confiança zero.

A abordagem “Comece pelo Porquê” de Simon Sinek é uma ferramenta eficaz para comunicar a estrutura ZTS, conforme mostrado na Figura 1 abaixo.  Você pode visualizar este gráfico de fora para dentro, começando com as classes de ameaças que o ZTS aborda, depois detalhando os métodos de segurança usados e, finalmente, resumindo tudo em princípios comuns.  Ou você pode vê-lo de uma perspectiva de dentro para fora, começando com as crenças fundamentais como a estrela-guia, de onde emergem as ferramentas e técnicas apropriadas, que então permitem que você enfrente uma ampla gama de ameaças.

Figura 1 — Segurança de confiança zero: Sistema de crenças, ferramentas e benefícios.

As seções posteriores abordam cada camada concêntrica deste diagrama, mas resumidamente:

• As crenças centrais da abordagem derivam do enquadramento do caso de uso como:
  “Quem está tentando o quê (ação) para quem?”
  • Para estabelecer Quem e Para Quem, verifique explicitamente qualquer atestado de identidade.
  • Depois de estabelecer Quem , use o princípio do menor privilégio para limitar O que pode ser executado.
  • Avalie e reavalie continuamente todos os três fatores: Quem, O quê e Quem, e continue a validar em relação às restrições políticas.
  • Sempre assuma que violações e comprometimentos ocorrerão . Esteja preparado para intervir se a ação ( O quê para Quem ), com base em uma análise de risco versus recompensa (a probabilidade de fraude na autenticação, ponderada pelo impacto comercial de uma aprovação de transação errônea), exceder um limite de segurança aceitável pré-determinado.
• Os métodos utilizados são:
  • Autenticação e controle de acesso para determinar Quem em algum nível de confiança e, então, limitar os privilégios em torno do Que (ações) devem ser permitidas por essa identidade com relação a um alvo Quem específico.
  • Visibilidade e análise assistida por ML para observar e avaliar continuamente o contexto completo de cada transação – Quem faz o quê para quem.
  • Remediação automatizada com reconhecimento de risco para intervir em uma transação quando o nível de risco-recompensa sobe acima do limite de tolerância especificado.
• Enfrente uma ampla gama de ataques cibernéticos aplicando estes métodos:
  • Ataques tradicionais, como desfiguração ou exfiltração de dados – Você pode abordar esses ataques detectam comprometimento de identidade ou escalonamento de privilégios, usando técnicas de autenticação e controle de acesso para limitar quem pode fazer o quê por política.
  • Ataques de disponibilidade/DDoS — Enfrente esses ataques combinando autenticação e controle de acesso com correção consciente de riscos.  Por exemplo, você bloqueia (ou limita a taxa) o acesso a atores não autenticados ou mal autenticados que tentam transações que exigem muitos recursos.
  • Ameaças avançadas , como ransomware ou ataques à cadeia de suprimentos : você pode lidar com essas ameaças detectando mudanças e anomalias nos comportamentos de Quem está fazendo o quê com Quem, novamente associado à correção consciente de riscos.

A segurança de confiança zero se estende holisticamente por todo o aplicativo, infraestrutura e pilha de entrega, e deve abranger todo o pipeline de desenvolvimento. Mais especificamente, isso deve incluir:

• Pilha completa de aplicativos e infraestrutura “de cima para baixo”
  • Substrato de computação de hardware, incluindo servidores, placas de interface de rede, coprocessadores e componentes da placa de sistema
  • Firmware de camada baixa e BIOS para o hardware.
  • O sistema operacional de camada mais baixa, como o hipervisor ou o executivo de tempo de execução.
  • O sistema operacional de nível de aplicativo/contêiner .
  • Componentes de aplicativos de terceiros importados, comerciais ou de código aberto.
  • Qualquer software aplicativo desenvolvido internamente ou personalizado.
• Pilha completa de entrega de aplicativos “da esquerda para a direita”
  • A cadeia de suprimentos usada para manutenção contínua e atualizações de cada elemento da pilha “de cima para baixo”.
  • Quaisquer componentes de entrega de aplicativos em linha, como firewalls, balanceadores de carga, gateways de API, controladores de entrada/saída/malha e dispositivos de mitigação de fraude em linha.
  • Quaisquer componentes de entrega de aplicativos que afetam indiretamente o tratamento de tráfego, como resolvedores do Sistema de Nomes de Domínio (DNS), ou que recebem metadados indiretamente, como soluções de gerenciamento de eventos de informações de segurança (SIEM) ou serviços de identidade federada.

Tradicionalmente, o foco da confiança zero tem sido direcionado às equipes de desenvolvimento e entrega de aplicativos, muitas vezes capturadas como as personas de Dev, DevOps, DevSecOps e SRE.  Destacamos isso principalmente para observar o panorama geral: uma abordagem abrangente à confiança zero deve, idealmente, incluir personas e infraestrutura não tradicionais, bem como fluxos de trabalho adicionais, como a estratégia de aquisição da cadeia de suprimentos.

Uma das principais prioridades do CIO e do CISO é modernizar a tecnologia da informação para ajudar a acelerar os negócios.  Eles também desempenham um papel fundamental na governança de riscos corporativos.  O objetivo deles é ajudar a empresa a encantar os clientes com novas experiências digitais, aumentar a eficiência operacional por meio da conectividade digital com terceiros e permitir que os funcionários sejam produtivos de qualquer lugar, minimizando os riscos comerciais. Isso exige que as organizações CIO e CISO liberem sua força de trabalho para usar as mais recentes tecnologias, arquiteturas e melhores práticas para agilidade, ao mesmo tempo em que encarregam esses mesmos indivíduos de tomar medidas de segurança apropriadas e estabelecer controles sobre o comportamento das pessoas, as informações que acessam e a tecnologia que usam para evitar a exposição a perdas. 

As organizações devem entender e controlar os riscos relacionados às mudanças nas condições de mercado e macroeconômicas, ao comportamento do consumidor, à cadeia de suprimentos e às exposições de segurança.  Uma avaliação precisa do risco e a capacidade de tomar medidas rápidas de mitigação são uma vantagem competitiva para as empresas.  Neste artigo, focamos no risco de exposições de segurança, que entre outras coisas podem causar perda de propriedade intelectual, interrupção de processos de negócios, perda de informações pessoais identificáveis e multas de reguladores.  O risco de segurança pode ser calculado avaliando os seguintes aspectos de uma situação em consideração:

1. Valor dos ativos envolvidos
   Os ativos envolvidos nas transações têm diferentes níveis de importância. Por exemplo, um banco de dados que consiste em informações de identificação pessoal é mais valioso do que um banco de dados que lista locais de varejo que vendem produtos fabricados pela empresa.  É possível que equipes de segurança e TI usem um processo determinístico para criar um inventário de todos os ativos, categorizados por uma pontuação que representa o “valor” do ativo.


2. Impacto do compromisso
   A natureza do comprometimento determina o impacto relacionado a ele.  Por exemplo, o impacto da ocultação das informações no armazenamento de dados que contêm informações de identificação pessoal é muito maior do que a interrupção da disponibilidade do armazenamento de dados.  Embora um pouco mais nebuloso, é possível listar vários tipos de comprometimentos e atribuir a eles uma pontuação de “impacto”.


3. Probabilidade de compromisso
   A probabilidade de uma transação levar ao comprometimento de um ativo é o fator menos determinístico na avaliação do risco associado à transação.  Os humanos não conseguem lidar com a escala de observações necessárias, então as organizações empregam aprendizado de máquina e inteligência artificial para aumentar a confiança em seus cálculos da probabilidade de comprometimento.

O desafio em questão é calcular o risco associado a cada transação quase em tempo real e tomar medidas de mitigação apropriadas para controlar o impacto de um possível comprometimento.

Figura 2 -- As pressões empresariais impulsionam novas práticas, o que leva a um risco maior.

1. Exigências de aceleração empresarial
   1. Experiências digitais
      Os consumidores têm um desejo insaciável por experiências digitais e exigem melhorias frequentes em diversas plataformas (PC, tablet, celulares).
   2. Negócios conectados
      Os processos de negócios digitais exigem conectividade com parceiros, fornecedores, distribuidores e serviços fornecidos por outras empresas.
   3. Força de trabalho móvel
      Os funcionários precisam poder acessar aplicativos de negócios de qualquer lugar para eficiência de execução.


2. Práticas para atender às demandas empresariais
   1. Metodologia de desenvolvimento ágil
      As empresas mudaram para a abordagem de desenvolvimento Agile incremental e iterativa, com forte foco na satisfação do cliente, em vez da abordagem sequencial em cascata, que se concentra na entrega pontual do projeto.
   2. Utilização de software pronto
      Para oferecer novas experiências digitais o mais rápido possível, os desenvolvedores reutilizam códigos de código aberto disponibilizados por seus colegas do setor.
   3. Desenvolvimento de contrato
      Terceirizar o trabalho para desenvolvedores contratados ajuda as empresas a dimensionar sua força de trabalho conforme a demanda.
   4. Uso de infraestrutura de nuvem
      Agilidade, flexibilidade e escalabilidade da nuvem e sua facilidade de uso permitem que os desenvolvedores obtenham a infraestrutura necessária sob demanda.
   5. Adoção de SaaS
      O software como serviço (SaaS) é vantajoso para aplicativos de operações comerciais, pois reduz a carga significativa de aquisição, implantação e manutenção de tais aplicativos em data centers privados.
   6. Arquitetura de microsserviços
      As equipes usam microsserviços para obter entrega contínua com tempo de colocação no mercado mais rápido.
   7. Componentes de aplicativos distribuídos
      As organizações alcançam eficiência executando microsserviços em uma infraestrutura que oferece as melhores ferramentas para desenvolver ou entregar a funcionalidade do serviço. Extensões recentes para fluxos de trabalho legados são feitas usando arquiteturas de aplicativos modernas que precisam se comunicar com os elementos legados, e os dois geralmente são executados em infraestruturas diferentes.
   8. APIs abertas
      Um ecossistema de vários serviços é mais eficiente do que uma empresa desenvolvendo todos os serviços por conta própria.
   9. Conectividade de rede com terceiros
      As empresas se conectam entre si usando túneis criptografados com seus parceiros, fornecedores e distribuidores para automatizar e agilizar os processos de negócios.


3. Risco de segurança aprimorado
   1. Aumento da superfície de ataque
      O uso de software de terceiros e bibliotecas de código aberto cria oportunidades para ataques à cadeia de suprimentos, e todas as vulnerabilidades de software desenvolvido externamente são herdadas.  Os desenvolvedores contratados são motivados a concluir a funcionalidade dos recursos no prazo e a segurança não é uma preocupação deles.  Além disso, depois que o software é entregue e o projeto é encerrado, é difícil e demorado para as equipes internas analisarem o código e encontrarem falhas de segurança. Os sprints ágeis são muito eficientes na entrega de funcionalidades de recursos, mas o aumento da velocidade de desenvolvimento não deixa muito tempo para auditorias e testes de segurança detalhados.  Um microsserviço vulnerável, que tem a capacidade de se comunicar com outros microsserviços, aumenta o risco de segurança para todo o sistema.

      Embora empresas interconectadas melhorem a eficiência operacional, uma consequência séria é que falhas de segurança em qualquer uma delas afetam todas elas.  Os invasores encontram o elo mais fraco para proliferar através do resto. Uma vulnerabilidade ou falha de segurança na plataforma SaaS ou na infraestrutura de nuvem se torna um vetor de ataque adicional, e o modelo de responsabilidade compartilhada pode complicar a detecção e a correção precoces.

   2. Aumento da complexidade arquitetônica
      Elementos de aplicativos distribuídos, desenvolvidos usando arquiteturas variadas e implantados em diversas infraestruturas, têm diferentes necessidades de segurança e conformidade.  Isso dificulta que as equipes de segurança projetem e implantem mecanismos apropriados para proteger aplicativos e dados corporativos e atender aos requisitos de conformidade regulatória.
      
   3. Hackers bem financiados, altamente motivados e qualificados
      Da Operação Aurora de 2010 ao Solargate de 2020, tivemos uma década de ataques cibernéticos avançados que são descobertos somente depois de causarem grandes danos.  As violações ocorreram em organizações equipadas com a melhor tecnologia de segurança, operadas por equipes de segurança altamente treinadas.  Os invasores persistiram na infraestrutura de TI dessas organizações por longos períodos antes de serem detectados.  Propriedade intelectual foi roubada, informações pessoais identificáveis foram roubadas, operações comerciais foram interrompidas, organizações foram mantidas reféns de ransomware, mesmo com equipes de TI e segurança se esforçando ao máximo para cumprir as regulamentações criadas para manter os ataques cibernéticos sob controle.

Após uma série de ataques cibernéticos persistentes contra várias agências governamentais federais, estaduais e locais dos EUA, e diversas corporações norte-americanas, o presidente Joe Biden emitiu uma ordem executiva para melhorar a segurança cibernética do país em 12 de maio de 2021.  Um dos principais elementos desta ordem é que as agências governamentais usem os princípios de confiança zero para se prepararem para ataques cibernéticos. O governo Biden seguiu essa ordem com um memorando do escritório de gestão e orçamento (OMB) para os chefes de departamentos executivos e agências em 26 de janeiro de 2022.  Este memorando do OMB “estabelece uma estratégia de arquitetura Federal Zero Trust (ZTA), exigindo que as agências atendam a padrões e objetivos específicos de segurança cibernética até o final do ano fiscal (AF) de 2024, a fim de reforçar as defesas do governo contra campanhas de ameaças cada vez mais sofisticadas e persistentes”.¹  Tanto a ordem executiva quanto o memorando do OMB fazem referência à arquitetura de confiança zero descrita na publicação SP 800-207 do Instituto Nacional de Padrões e Tecnologia (NIST) , publicada em agosto de 2020, e exigem que as agências governamentais a sigam.

Líderes de opinião em agências governamentais e no setor privado publicaram artigos que ajudam a explicar a arquitetura de confiança zero e oferecem conselhos sobre a melhor forma de adotá-la. Resumimos abaixo as ideias contidas nestes artigos. Observamos que a essência crítica das ideias e sugestões contidas nestes documentos é examinar cada transação para avaliar quem está tentando qual ação sobre quem e tomar uma decisão em tempo real para permitir ou não a transação com base no cálculo do risco associado a ela.

A equipe do NIST enumera os princípios da confiança zero e define uma arquitetura abstrata de confiança zero (ZTA) em seu artigo NIST SP 800-207.² Além disso, eles discutem variações de abordagens de confiança zero e descrevem diferentes maneiras de implantar a arquitetura abstrata.

As principais abstrações discutidas no artigo são o Ponto de Decisão de Política (PDP) e o Ponto de Aplicação de Política (PEP), que funcionam em conjunto.  O Ponto de Decisão de Política é composto pelo Mecanismo de Política (PE) e pelo Administrador de Política (PA).  O Policy Engine usa um algoritmo de confiança para tomar decisões sobre se o acesso a um recurso deve ser concedido a um sujeito.  Essa decisão é executada pelo Administrador de Políticas, que se comunica com o Ponto de Aplicação de Políticas para permitir ou não uma nova sessão e para modificar ou encerrar uma sessão existente. Além disso, o artigo discute variações do algoritmo de confiança, componentes de rede para um ambiente de confiança zero e vários casos de uso ou cenários de implantação.  Por fim, há uma consideração sobre as maneiras pelas quais a arquitetura de confiança zero pode ser frustrada por invasores, de modo que os implementadores estejam cientes das ameaças e tomem as medidas apropriadas para proteger seus componentes de arquitetura de confiança zero.

Com o objetivo de auxiliar as agências no desenvolvimento de seus planos de confiança zero, os líderes de pensamento da Agência de Segurança Cibernética e de Infraestrutura (CISA) publicaram um modelo de maturidade de confiança zero .³  O trabalho se baseia na arquitetura abstrata de confiança zero descrita no artigo NIST SP 800-207.  Os autores identificaram cinco áreas e recomendam que as organizações façam progresso consistente no cumprimento dos princípios de confiança zero em cada área.  As áreas são (i) identidade, (ii) dispositivo, (iii) rede, (iv) carga de trabalho do aplicativo e (v) dados.  Eles recomendam o uso de visibilidade e análise, além de automação e orquestração em cada uma das cinco áreas.

O documento oferece um modelo de maturidade de alto nível em todos os cinco pilares fundamentais da confiança zero identificados anteriormente e, em seguida, se aprofunda em cada área.  As organizações podem usar o modelo de maturidade para entender seu estado atual e definir um curso iterativo em direção ao estado ideal.

Após a descoberta dos ataques Solar Winds, a Agência de Segurança Nacional (NSA) emitiu orientações aconselhando as equipes de segurança cibernética a adotar um modelo de segurança de confiança zero em seu artigo “Adotando um modelo de segurança de confiança zero”.⁴  Especialistas da equipe de engenharia de confiança zero da Agência de Sistemas de Informação de Defesa (DISA) e da Agência de Segurança Nacional criaram a arquitetura de referência de confiança zero do Departamento de Defesa (DOD).⁵  Os autores expressam a necessidade da adoção da confiança zero com a seguinte declaração: “Vulnerabilidades expostas por violações de dados dentro e fora do DOD demonstram a necessidade de um modelo de segurança cibernética novo e mais robusto que facilite decisões bem informadas baseadas em risco.”⁶

Esta arquitetura de referência baseia suas recomendações nas abstrações definidas no documento de arquitetura de confiança zero NIST SP 800-207.  O documento apresenta um modelo operacional de alto nível e descreve seus elementos em detalhes.  Inclui também um modelo de maturidade de alto nível e o mapeamento de capacidades para aplicação de princípios de confiança zero a diversas áreas de interesse.  Juntos, esses documentos ajudam as organizações a avaliar seu estado atual e elaborar um plano.

Ter uma atitude que “assume violação” e seguir os princípios de confiança zero pode ajudar as organizações em suas práticas de gestão de risco e governança.  Os princípios de confiança zero de “monitoramento contínuo” e “verificação explícita” dos atores envolvidos nas transações permitem que as organizações criem uma pontuação de risco dinâmica para todos os atores e suas atividades. Isso está de acordo com a recomendação da Gartner de usar a metodologia de “avaliação contínua adaptativa de risco e confiança” (CARTA) para aprimorar os programas de segurança existentes.  A adoção do princípio de permitir apenas o acesso de privilégios mínimos aos recursos reduz o risco de perda, mesmo após uma violação.  As informações geradas pelo monitoramento contínuo e verificação explícita também são úteis na geração de relatórios de conformidade.

Esta seção pretende focar na mentalidade – o sistema de crenças, o “Por quê” – que motiva a estratégia e as decisões em torno das ferramentas e do design que uma empresa deve adotar para segurança de confiança zero.  Na verdade, é possível destilar o ímpeto de todos os métodos e tecnologias de componentes empregados pelas soluções de confiança zero de hoje em quatro princípios-chave simples.  Esta seção abre com uma enumeração desses princípios, seguida por uma discussão sobre como eles podem ser aplicados dentro do contexto mais amplo do ciclo de vida de desenvolvimento do aplicativo – ou seja, como considerar esses princípios antecipadamente, na fase de design, bem como operacionalmente, na implantação/tempo de execução do aplicativo.

Se as soluções de confiança zero forem entendidas como fundamentalmente construindo confiança nas interações do sistema – “ Quem está fazendo o quê para quem ?” – então a construção de um nível de confiança apropriado para a interação pode ser dividida em quatro componentes.

Como o nome sugere, a mentalidade de confiança zero é: “Não confie cegamente, sempre verifique”.  Portanto, qualquer ator no sistema – o Quem e Quem nas interações do sistema – deve ser capaz de:

1. Ateste sua identidade, incluindo o caso especial de uma identidade “anônima”, se o sistema permitir interações originadas ou destinadas a identidades anônimas – como navegadores anônimos em um sistema de reservas aéreas.  Para todas as outras identidades, o ator deve ser capaz de declarar Quem ele é, em um namespace que o sistema aceite.
2. Receber e validar “prova” colateral da identidade atestada do ator (para qualquer identidade atestada não anônima).  A natureza da “prova” – senhas, certificados, comportamentos, etc. – pode variar, assim como a força dessa prova, mas o sistema deve ser capaz de determinar algum grau de confiança na atestação.  Sistemas simples podem ter uma visão binária sim/não de confiança na prova, enquanto sistemas mais avançados podem ter uma pontuação de confiança numérica que pode ser explicitamente referenciada como parte de uma política baseada em risco-recompensa.  Observe que o sistema também pode aumentar ou reduzir a confiança por outros meios, como a resposta a um desafio ativo ou mesmo a partir da observação passiva do comportamento do ator.
3. Avaliar e ajustar a confiança na identidade atestada, com base na contextualização adicional do comportamento atual em relação aos comportamentos passados.  Por exemplo, o sistema pode manter metadados históricos sobre o ator, como a geolocalização anterior e atual do ator, plataformas de hardware, endereços IP, reputação e assim por diante, para serem usados com o objetivo de aumentar ou diminuir a confiança na “prova” de identidade.

Além disso, o princípio de verificação explícita pode ser aplicado não apenas à identidade, mas também à ação – o quê da transação.  Um caso de uso comum é quando a ação é expressa como uma chamada de API, como uma API para executar uma consulta de banco de dados.  Neste exemplo, o princípio de verificação explícita pode ser usado não apenas para ter confiança na identidade do ator que chama a API, mas também para verificar a exatidão do uso da ação da API, como verificar se os parâmetros passados para a API estão em conformidade com as restrições apropriadas.

Em uma mentalidade madura de confiança zero, a “prova” quase nunca é absoluta.  Credenciais de identidade podem ser roubadas e dispositivos podem ser comprometidos; restrições de parâmetros de API geralmente são incompletas. Portanto, o termo “confiança” no contexto de confiança zero deve ser interpretado mais como uma indicação de quão provável é que a identidade atestada ou os parâmetros de transação sejam legítimos.  Assim, o nível de “confiança” deve ser visto como um fator-chave, mas não o único, na decisão de permitir, bloquear ou inspecionar mais profundamente uma transação.

Uma vez que um nível aceitável de “confiança” é estabelecido nos atores que participam de uma transação, a abordagem de confiança zero exige que o ator (normalmente, o solicitante, o “ Quem” ) receba apenas o conjunto mínimo de privilégios necessários para que ele possa fazer o que foi projetado para realizar naquele sistema.  Este princípio incorpora o que também é conhecido como “modelo de segurança positivo” – uma abordagem em que todas as ações são proibidas por padrão, com privilégios específicos sendo concedidos apenas conforme necessário para a operação do sistema.  Por exemplo, um sistema de reservas pode permitir que usuários anônimos naveguem pelos horários de voos, mas – de acordo com os requisitos de design do aplicativo – um usuário anônimo pode não ter permissão para reservar um voo.

Esses privilégios podem ser aplicados a atores individuais ou a classes de atores.  Normalmente, os consumidores de aplicativos são atores humanos ou representantes de humanos e são agrupados em classes, como “usuários anônimos”, “clientes”, “parceiros” ou “funcionários”.  As classes de atores menos confiáveis normalmente exigem um limite de confiança menor para passar na autenticação, mas também têm acesso a APIs menores ou menos sensíveis.  Atores internos ao aplicativo ou sua infraestrutura, como serviços ou contêineres específicos dentro de um aplicativo, geralmente podem ter privilégios mais personalizados, como “somente os contêineres <X> e <Y> podem acessar o banco de dados, somente <X> pode gravar no armazenamento de objetos, mas <Y> e <Z> podem ler a partir dele”.

Uma consideração importante para a implementação do privilégio mínimo é se esforçar para aplicá-lo de uma maneira mais personalizada e com premeditação.⁷ Especificamente, em vez de aplicar um conjunto genérico de privilégios a todos os atores, ou a uma classe de atores, uma implementação madura de confiança zero deve ter uma visão mais granular de qual ação está sendo tentada.   Por exemplo, em um nível muito grosseiro, “acesso ao sistema de arquivos” pode receber privilégio, mas “leitura ao sistema de arquivos” é uma especificação mais rigorosa do verdadeiro privilégio necessário, o que produz uma implementação de alta qualidade do modelo de segurança positivo.

Finalmente, personificações mais sofisticadas de privilégio mínimo podem trabalhar em conjunto com implementações maduras de “verificação explícita”, visualizando privilégios autorizados para um ator não como absolutos, mas sim como baseados na confiança fornecida pela autenticação.  Assim, os privilégios são concedidos somente se a confiança na identidade atestada ( Quem ) atingir um limite mínimo, sendo os limites específicos para a ação que está sendo tentada. Por exemplo, alguma ação particularmente impactante (por exemplo, desligar o sistema) pode exigir 90% ou mais de confiança de que o ator é um administrador.  Neste exemplo, se a confiança do sistema na identidade for de apenas 80% quando o desligamento for tentado, o sistema exigirá verificação adicional para aumentar a pontuação de confiança na identidade atestada antes de permitir a ação.

Verificação explícita e privilégio mínimo são conceitos-chave; no entanto, o princípio de avaliação contínua captura o fato de que esses princípios devem ser avaliados continuamente, no sentido de que:

1. Todas as transações devem estar sujeitas a verificação e privilégio.  Em outras palavras, não deve ser o caso de apenas um subconjunto de transações estar sujeito à inspeção – como “a primeira transação em uma sessão de usuário” ou “aquelas transações que são iniciadas por meio da carga de trabalho do contêiner Docker”.  Embora isso possa parecer evidente, muitas implementações de confiança zero não validam todas as transações, seja por design ruim ou por falta de visibilidade.  Deficiências comuns nessa área surgem da aplicação de confiança zero apenas a atores externos, mas não aos internos, e/ou da suposição de que um veredito de confiança zero permanece verdadeiro por um longo período de tempo.
2. Os fatores-chave na avaliação – a confiança na identidade do ator e os direitos permitidos a esse ator – devem ser vistos como dinâmicos e sujeitos a mudanças .  Por exemplo, a confiança em uma identidade pode aumentar ou diminuir ao longo do tempo, com base em comportamentos observados e metadados de banda lateral, e qualquer política baseada em confiança deve, portanto, também se ajustar dinamicamente às mudanças de confiança.  Além disso, um limite de privilégio concedido pela política anteriormente pode ser revogado um pouco mais tarde, ou uma confiança mínima necessária para alguma ação pode mudar.  Embora os prazos para mudanças de políticas variem – eles podem mudar lentamente (em prazos de processos operacionais humanos) ou rapidamente (por meio de agentes de governança automatizados) – o sistema deve ser capaz de responder dinamicamente e honrar essas mudanças.

O princípio final está enraizado na presunção de adversários altamente motivados num contexto de paranóia saudável.  Especificamente, a premissa é “suponha que você foi violado”, onde “violação” é definida como “uma transação que deveria ter sido negada (com perfeito conhecimento e execução), mas foi permitida”.  A causa raiz dessa fuga pode ser conhecimento imperfeito (por exemplo, uma pontuação de alta confiança incorreta da autenticação decorrente de credenciais fraudulentas não detectadas) ou pode ser limitações de implementação (por exemplo, não ter especificidade suficientemente precisa dos privilégios concedidos, como ter "conexão de rede aberta" como um privilégio, mas sem a capacidade de diferenciar com base na geolocalização do destino da rede) ou pode ser causada por uma implementação incompleta de confiança zero (por exemplo, não aplicar confiança zero a componentes vulneráveis de código aberto usados internamente).

Portanto, a mentalidade de confiança zero também deve abordar a melhor forma de gerenciar/minimizar o impacto de tais violações.

A implementação deste princípio varia mais do que os outros princípios, mas geralmente se manifesta como:

• Primeiro, identifique quaisquer transações que, embora tecnicamente permitidas pela política, sejam suspeitas.  “Suspeito” geralmente é muito contextual, mas interpretações comuns são: (a) transações anômalas muito diferentes de comportamentos observados anteriormente, (b) grupos de transações que são individualmente normais, mas são coletivamente incomuns – por exemplo, ler e escrever um arquivo pode ser comum, mas ler e escrever a uma taxa de 1000 arquivos por segundo pode ser incomum, ou (c) ações que são correlacionadas com um impacto indesejado e não visto anteriormente no sistema – um exemplo seria um padrão em que uma transação específica abre uma conexão de rede com um nó TOR ou faz com que a carga da CPU do sistema aumente significativamente.
• Em seguida, execute uma análise mais profunda, seja um fluxo de trabalho totalmente automatizado ou um fluxo de trabalho híbrido controlado por humanos/assistido por ML, para determinar se essas transações são inválidas.  Se essas transações forem consideradas inválidas, aplique a mitigação.  Isso pode assumir a forma de uma atualização geral da política ou, como uma camada adicional de mitigação, um “recurso” para as outras mitigações orientadas por políticas.

Se a abordagem escolhida for usar ajustes baseados em políticas, os ajustes podem ser aplicados aproveitando qualquer uma das ferramentas de políticas estáticas disponíveis.  Exemplos de ajustes baseados em políticas seriam restringir os privilégios de controle de acesso granular de transação (ou seja, não permitir mais Quem fazer o quê a quem ) ou, em vez disso, aplicar um "padrão de prova" mais rigoroso (ou seja, exigir MFA ou uma pontuação de confiança mais alta) para que um ator (ou classe de atores) execute uma ação específica. 

Se, em vez disso, for escolhida a abordagem de usar uma camada adicional de “recuo”, essa estratégia também pode ser implementada como granulação fina ou granulação grossa.  A estratégia mais refinada seria bloquear exatamente e somente aquelas transações que ultrapassam uma relação risco-recompensa específica, embora essa solução também tenha a possibilidade de adicionar níveis inaceitáveis de latência a algumas transações permitidas se a implementação exigir análise adicional.  Estratégias mais genéricas poderiam ser usadas, como isolar transações futuras daquele ator ou até mesmo proibir totalmente o ator do sistema.  Em casos extremos, métodos de mitigação ainda mais grosseiros – como desligar E/S de arquivo – podem ser apropriados. 

É claro que, se tudo o mais permanecer igual, uma mitigação de salvaguarda mais refinada é geralmente preferível. No entanto, muitas vezes é preciso fazer compensações com base nas restrições das tecnologias de solução disponíveis, e um backstop de granulação grossa geralmente é melhor do que nenhum backstop.  Por exemplo, se a resposta mais ampla para evitar suspeitas de ransomware for desabilitar E/S de arquivo, os efeitos colaterais dessa resposta ainda podem ser preferíveis à alternativa – permitir que o agente continue a operar no sistema sem ser verificado – assumindo que o resultado da inação seria um sistema de arquivos criptografado por ransomware. 

O melhor ponto de partida para o desenvolvimento de um aplicativo seguro usando confiança zero é, sem surpresa, o começo. Os princípios fundamentais que permitem a operacionalização dos princípios de confiança zero devem ser incorporados à fase de design dos processos de desenvolvimento de aplicativos.  Portanto, qualquer discussão sobre uma solução operacional de confiança zero integrada ao pipeline de CI/CD deve começar com uma compreensão desses elementos fundamentais que devem ser considerações de design de primeira classe.

O núcleo desses elementos fundamentais deve capturar o comportamento desejado/pretendido da interação dos comportamentos do sistema, juntamente com visibilidade e controle suficientes para detectar desvios e agir de acordo com eles.  As interações pretendidas são usadas para definir o conjunto desejado de ações ( o quê ) para cada ator ( quem ) em relação a cada alvo ( quem ).  Dito isso, pode haver alguns cenários e ambientes em que os padrões de interação pretendidos são desconhecidos. Nesses casos, uma organização pode aproveitar uma visibilidade mais profunda para “descobrir” o conjunto de interações apropriadas,⁸ que pode então codificar em políticas.

Por exemplo, nas soluções ZTNA atuais, que se concentram no controle de acesso orientado por identidade às APIs externas de um aplicativo, a visibilidade e os controles nas APIs de autenticação são necessários.  Ou, no contexto da plataforma de proteção de carga de trabalho na nuvem (CWPP), a detecção de uma carga de trabalho de contêiner comprometida requer visibilidade das ações que cada contêiner executa e em tempo real, se for necessária correção em tempo real.

A seguir está uma lista de “baldes” de alto nível relacionados a considerações fundamentais que devem fazer parte do processo de design, com detalhamentos adicionais para fornecer perguntas específicas para pensar sobre cada um dos pontos-chave:

• Quais são as interfaces de caixa preta – entradas e saídas – do sistema?
  • Quais são as classes de usuários – administradores, usuários autenticados, usuários não autenticados, parceiros – que interagem com o aplicativo e o que eles precisam fazer?
  • Todas as comunicações são feitas por meio de uma API definida ou há comunicações de rede “brutas” ou comunicações por meio de um armazenamento de dados, como um banco de dados ou armazenamento de objetos?
    • Para comunicações de API, quão bem definida é a API, em termos de quais usuários podem interagir com ela e as restrições em torno dessas interações (por exemplo, restrições de parâmetros, limites de taxa, etc.)? 
    • Para qualquer comunicação de rede, todos os dados transmitidos são criptografados?
    • Se houver alguma interface de dados “brutos” (por exemplo, as informações são compartilhadas entre o cliente e o aplicativo por meio de um armazenamento de objetos ou banco de dados), há logs de auditoria para rastrear quem acessou quais informações e quando?
• Da mesma forma, no nível interno de “caixa branca”, quais são os serviços componentes que compõem os aplicativos gerais, incluindo quaisquer serviços fornecidos externamente, e como eles se comunicam?
  • Como esses serviços se comunicam – qual API está sendo usada e quais são as restrições (funções, controles de acesso, limites de taxa, parâmetros, etc.) nessas interações?
    • Questões semelhantes às acima existem em torno da formalidade da API e suas restrições e da criptografia das comunicações.
    • As comunicações “internas” (por exemplo, entre cargas de trabalho/contêineres) têm mais probabilidade de usar memória compartilhada e interfaces baseadas em sistema de arquivos; quaisquer interfaces desse tipo devem ser identificadas.
• Quais mecanismos de controle o sistema disponibiliza para limitar o acesso às interfaces de caixa preta e aos caminhos de comunicação interna?
  • Existe uma política que indica quem – quais funções – pode invocar APIs específicas e o que acontece se a política for violada?  Da mesma forma, quais meios existem para detectar e mitigar qualquer tipo de abuso das APIs, como parâmetros inválidos ou invocações em uma taxa muito alta?  Essas políticas podem ser atualizadas dinamicamente, com base em entradas contextuais de outros sistemas?
  • Analogamente, existem políticas que restringem as outras formas de comunicação entre cargas de trabalho – sistemas de arquivos, armazenamentos de objetos, tabelas de banco de dados – em termos de quem pode acessar quais arquivos/armazenamentos/tabelas e evitar o abuso desses recursos (por exemplo, “SELECT * from <table>”)?
• Que visibilidade (painéis, logs, estatísticas) o sistema disponibiliza para limitar o acesso às interfaces de caixa preta e aos caminhos de comunicação interna?
  • O sistema consegue identificar quem está invocando qual API e em que momento?  Esses dados são retidos e, em caso afirmativo, por quanto tempo?  Com que rapidez (em tempo real, por hora, etc.) esses dados são disponibilizados?  Quão consumíveis são os dados – são um log de arquivo não estruturado, uma Notação de Objeto JavaScript (JSON) estruturada que pode ser enviada para um serviço de gerenciamento de incidentes e eventos de segurança (SEIM) ou dados registrados em uma tabela de banco de dados de big data?
  • Quais são as respostas para as mesmas perguntas quando se trata de outros caminhos de comunicação – memória, arquivos, objetos, bancos de dados?  Quem está fazendo o quê?  Como esses dados são expostos?
• Além dos caminhos de comunicação, que outros controles e visibilidade o sistema fornece para evitar excesso de subscrição ou consumo excessivo de recursos ?
  • O sistema tem visibilidade das métricas de consumo de recursos – CPU, memória, largura de banda, dimensionamento de pod, etc.?  Se sim, em que granularidade e quão consumíveis são esses dados?
  • O sistema tem controles ou barreiras para consumo de recursos – limites de memória/CPU/E/S de arquivo por carga de trabalho, rastreamento de chamadas de sistema de criação de processos, limites de expansão/redução de escala de pods, limites de taxa para APIs que invocam outros serviços?

Fazer essas perguntas explicitamente ajudará você a descobrir onde existem lacunas na fundação para permitir a confiança zero.  Frequentemente, o simples ato de perguntar, no início do projeto, fará com que a lacuna seja resolvida com um esforço mínimo de projeto adicional.  E, quando uma lacuna persistir, a simples conscientização sobre ela ajudará a direcionar foco adicional de segurança ou identificar superfícies de ameaças vulneráveis.

Fazer esse tipo de análise de desenvolvimento seguro antecipadamente é uma parte crucial da mentalidade de confiança zero.  Apesar desse fato, no entanto, grande parte do foco da confiança zero hoje está no que acontece após o design inicial, e o foco da maioria das empresas se concentra nos aspectos pós-design da confiança zero.  No entanto, ser cuidadoso, na fase de design, sobre os requisitos para a implementação efetiva da confiança zero evitará esforços incrementais muito maiores necessários para “corrigir as falhas” após a implantação do aplicativo.

Como a premissa de “assumir violação” da mentalidade incorpora, um profissional de segurança deve assumir que algum adversário suficientemente motivado conseguirá executar uma transação maliciosa – uma instância de Quem faz o quê a quem que atendeu às regras da política, mas, em um mundo perfeito, não deveria ter sido permitida.  Nesses casos, o foco muda para ter um mecanismo de “backstop” eficaz que possa encontrar esses casos, geralmente com base em observações de padrões de transações e efeitos colaterais do sistema, conforme descrito na seção anterior “assumir violação”.

No entanto, tal como acontece com a noção de identidade, o conhecimento sobre se uma transação específica é maliciosa ou não nunca será perfeito.  Portanto, assim como acontece com a identidade, uma solução ideal de confiança zero deve relatar uma pontuação de “confiança” na legitimidade da transação. Por exemplo, ver um daemon ler e gravar 10 vezes a taxa normal de arquivo por 10 segundos pode resultar em uma pontuação de confiança (de malícia) de 70%, mas ver a taxa aumentar 100 vezes, sustentada por 1 minuto, pode aumentar a confiança para 95%. Neste exemplo, tomar a ação corretiva de inibir futuras gravações de arquivos ainda terá alguma chance (uma possibilidade de 30% ou 5%) de ser a resposta incorreta – um “falso positivo”.  Portanto, a decisão de corrigir ou não deve considerar o risco de falsos positivos em comparação com o impacto potencial de permitir um comportamento possivelmente malicioso.

O objetivo do exemplo é destacar que qualquer decisão de tomar uma ação corretiva visível ao usuário é realmente uma decisão empresarial, que considera todos os riscos, custos e recompensas em torno da atividade suspeita.  Introduzir atrito adicional à transação aumenta a probabilidade de que o valor não seja recebido, mas não intervir/adicionar atrito introduz o risco de comprometimento. Portanto, a decisão de agir (ou não) em tais casos é uma função de três fatores:

1. Qual é o risco de permitir que transações possivelmente maliciosas continuem?
   Esse risco pode ser diretamente monetário, como a transferência de fundos bancários, ou pode ter custos indiretos, sejam operacionais (por exemplo, registros importantes criptografados e mantidos para resgate) ou de marca (por exemplo, desfiguração de um site). Também pode haver custos legais ou de conformidade, como os decorrentes do vazamento de dados pessoais de clientes. Em essência, a atribuição de risco é uma questão de governança, e uma boa governança compreenderá e quantificará os riscos da aplicação.


2. Quais são os efeitos colaterais de tomar a ação corretiva?
   Os efeitos colaterais podem ser expressos ao longo das dimensões de (a) atrito introduzido e (b) zona de explosão. O atrito é o quanto mais difícil é para uma transação legítima prosseguir; pode variar de um pouco mais inconveniente (por exemplo, um nível extra de autenticação) a impossível (a transação simplesmente não é permitida). A zona de explosão refere-se a se quaisquer outras transações independentes também serão afetadas e, em caso afirmativo, quantas.  Por exemplo, bloquear um usuário específico afetará apenas esse usuário, mas encerrar um serviço de registro afetará a capacidade de auditoria de todos os usuários e transações. 


3. Qual é a confiança na crença de que a transação é maliciosa? 
   Construir confiança normalmente implica coletar mais pontos de dados e correlacionar mais fontes de dados, o que leva tempo, então essa troca geralmente é, na prática, "Por quanto tempo devo observar antes de decidir agir?"

Portanto, embora uma estratégia de confiança zero deva aceitar o fato de que violações ocorrerão, uma abordagem ponderada adotará uma abordagem de risco versus recompensa na correção de transações que são permitidas, mas parecem suspeitas.  Essa compensação compreenderá o nível de risco de diferentes transações de aplicativos e as consequências da aplicação da correção, e da aplicação da correção somente se o nível de risco exceder a recompensa comercial esperada.

¹ https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf

² https://csrc.nist.gov/publications/detail/sp/800-207/final

³ https://www.cisa.gov/zero-trust-maturity-model

⁴ https://media.defense.gov/2021/Feb/25/2002588479/-1/-1/0/CSI_EMBRACING_ZT_SECURITY_MODEL_UOO115131-21.PDF

⁵ https://dodcio.defense.gov/Portals/0/Documents/Library/(U)ZT_RA_v1.1(U)_Mar21.pdf

⁶ https://dodcio.defense.gov/Portals/0/Documents/Library/(U)ZT_RA_v1.1(U)_Mar21.pdf

⁷ A premeditação começa na fase de projeto, conforme descrito mais adiante.

⁸ Ou, pelo menos, o conjunto de interações “consideradas apropriadas” que o sistema parece exigir.  Existe sempre o risco de que o conjunto de interações derivadas da observação possa ser incompleto ou possa ter algum risco pré-existente.  Portanto, é sempre preferível ter cuidado no design.