Onde o “Zero Trust” começa e por que é importante?

A “Zero Trust” (Confiança Zero) é uma mudança importante na arquitetura de segurança da informação. Isso nos leva para longe dos modelos de defesa em profundidade e de perímetro do passado, para camadas de controle mais próximas do que é mais importante – os dados. Quando inicialmente definida por um analista da Forrester, a “Zero Trust” estava focada na rede, fornecendo isolamento de aplicativos para evitar a escalada de privilégios de um invasor. Ela evoluiu para se tornar granular e abrangente, fornecendo autenticação e garantia entre os componentes, incluindo micro-serviços.

À medida que os benefícios da Confiança Zero se tornam cada vez mais claros, a difusão deste modelo é evidente, contando com uma base de computação confiável e controles centrados em dados, conforme definido na Publicação Especial NIST 800-207. Então, à medida que a “Zero Trust” se torna mais difundida, o que isso significa? Como os profissionais de TI e cibersegurança podem gerenciar essa implantação e manter a garantia de sua eficácia?

Arquitetura “Zero Trust”: Nunca Confie, Sempre Verifique

As arquiteturas “Zero Trust” reforçam o ponto de que nenhuma camada da pilha confia nos componentes subjacentes, sejam eles hardware ou software. Como tal, as propriedades de segurança são verificadas para garantir que sejam as esperadas para cada dependência e interdependência no primeiro uso e de forma intermitente (a autenticação dinâmica e os princípios de verificação de confiança zero). Cada componente é construído como se os componentes adjacentes ou dependentes pudessem ser vulneráveis. Como tal, cada componente individual assume que deve ser o componente para garantir o nível de confiança declarado e deve ser capaz de detectar um comprometimento ou mesmo uma tentativa de comprometimento.

Esse pode ser um paradigma um tanto confuso, pois a confiança zero introduz os princípios de isolamento em todas as camadas. Isso reforça o chamado ponto de Confiança Zero entre os componentes, enquanto a verificação das propriedades de segurança e da identidade é realizada continuamente para fornecer uma garantia de que os controles esperados sejam atendidos. Um componente pode optar por não executar se as propriedades esperadas das dependências não forem garantidas. As arquiteturas de “Zero Trust” afirmam “nunca confiar, sempre verificar”. Isso permite a detecção e prevenção de movimento lateral e execução de privilégios para cada componente e resulta em maior segurança para o sistema e software.

Princípios Básicos

Identidade, autenticação, autorização, controles de acesso e criptografia estão entre os princípios básicos de qualquer arquitetura de “Zero Trust”, onde decisões deliberadas e dinâmicas são feitas continuamente para verificar a garantia entre os componentes. Embora a “Zero Trust” seja frequentemente discutida na camada de rede como resultado de sua origem como um conceito da Forrester, a definição de “Zero Trust” evoluiu consideravelmente na última década para ser um conceito difundido que abrange infraestrutura, firmware de dispositivos, softwares e dados.

A “Zero Trust” é frequentemente discutida no que se refere à rede, com isolamento de aplicativos por segmentos de rede, garantindo controles como criptografia forte e autenticação dinâmica. A “Zero Trust” também pode ser aplicada no nível de micro-serviços, fornecendo garantia de controles e medições por meio de verificação entre serviços. A aplicação granular desse modelo reforça ainda mais a prevenção e a detecção do movimento lateral do invasor.

Garantia de Infraestrutura

A “Zero Trust” começa com a garantia da infraestrutura; ele se difundiu em programas e nos aplicativos. Uma “hardware root of trust (RoT)” é imutável com uma identidade criptográfica vinculada ao “Trusted Platform Module (TPM)”. O exemplo de garantia de infraestrutura introduz os princípios de uma arquitetura de “Zero Trust”. Na inicialização, o sistema primeiramente verifica se os componentes de hardware são os esperados.

Em seguida, o processo de inicialização do sistema começa a verificar o sistema e cada dependência em relação a um conjunto de chamadas “políticas de ouro” que incluem medidas esperadas, atestadas com uma assinatura digital usando a identidade criptográfica no TPM. Se uma das comparações de políticas não corresponder, o processo pode ser reiniciado ou o processo de inicialização do sistema pode ser interrompido. Embora existam várias opções de RoT baseadas em hardware e software, desde a inicialização/boot, as diretrizes de resiliência para firmware e BIOS são geralmente seguidas no desenvolvimento das políticas e medidas usadas.

Os atestados são assinados por um RoT em cada estágio do processo de inicialização e são usados para identificar os componentes confiáveis e fornecer uma garantia de confiança. Assim verifica-se, desde o nível mais básico, que a identificação dos sistemas e seus componentes estão conforme os requisitos pré-estabelecidos. As dependências podem ser encadeadas ou verificadas individualmente. Esses atestados também são fornecidos ao longo do tempo de execução, suportando o requisito de “Zero Trust” para autenticação dinâmica e controle de acesso – neste caso, para componentes de infraestrutura. Os atestados auxiliam na exigência de verificação da identidade dos componentes, indispensáveis para a garantia do referido componente.

Qualquer invasor que venha a se infiltrar no componente ou software precisaria sobreviver a essa verificação e autenticação dinâmica e periódica para manter suas ações maliciosas. O invasor também teria que descobrir um modo de como escalar privilégios ou se mover lateralmente entre componentes que estão isolados e que não confiam uns nos outros, ou seja, o processo de “Zero Trust” gera uma grande dificuldade ao atacante.

Conjuntos de Controles Confiáveis

O Manifesto de Integridade de Referência do “Trusted Computing Group” (TCG) baseado na Publicação Especial de Resiliência de Firmware do NIST fornece os controles confiáveis para a política e medição de firmware. Conforme você sobe na pilha, um conjunto de controle confiáveis são configurados para fornecer a verificação necessária, incluindo os “CIS Controls” e os “CIS Benchmarks”. Terceiros na cadeia de confiança, como NIST, CIS e TCG, fornecem um processo de verificação externo para melhor definir os requisitos de controle e benchmark.

Que evidências apoiam essa mudança para Zero Trust?

Curiosamente, mais ou menos na mesma época em que as arquiteturas de “Zero Trust” começaram a tomar forma, a Lockheed Martin desenvolveu a ideia da cyber “Kill Chain” (em 2011). A “Kill Chain” foi primeiro definida para separar os estágios de um ataque, permitindo a mitigação e as defesas de detecção entre os estágios. Atualmente, o muito utilizado “MITRE ATT&CK Framework”, tem suas bases no modelo da Lockheed Martin,agregando lacunas identificadas e aprendidas com o uso e com a evolução do cenário de ameaças cibernéticas. Para o propósito deste artigo, o “Kill Chain” será usado para simplificar o processo de correlação, mas pode ser abstraído ou até correlacionado com o “MITRE ATT&CK Framework”.

A Lockheed Martin “Kill Chain” foi desenvolvida em resposta à sofisticação cada vez maior de Ataques de Ameaças Persistentes Avançados (APT), que passaram a incluir ataques à cadeia de suprimentos. Ela implementa defesas e controles entre as fases do ataque, incluindo requisitos para confirmar a identidade (dinamicamente) por meio de autenticação; assim, os movimentos laterais dos invasores ou tentativas de escalonamento de privilégios podem ser detectados mais facilmente. Mover a detecção e prevenção para o início da “Kill Chain” é fundamental para evitar que os ataques obtenham maiores êxitos (por exemplo, exfiltração de dados ou interrupção na rede).

A aplicação de técnicas de detecção e prevenção de forma generalizada na pilha e em aplicativos e funções com controles de acesso dinâmicos para verificar os componentes com atestados de autenticação, oferece suporte aos princípios arquitetônicos de “Zero Trust” e permite a detecção de ataques logo no início da “Kill Chain”. A evidência dos princípios do funcionamento de Zero Trust é clara quando você considera sua implantação em conjunto com os controles de detecção na “Kill Chain”, conforme fica evidenciado pelos padrões de tempo de permanência do invasor.

Reduzindo o Tempo de Permanência

Desde que o uso da “Kill Chain” foi invocado pela primeira vez, o tempo de permanência do invasor (o tempo que um invasor permanece em uma rede sem ser detectado) foi reduzido drasticamente. Isso pode ser visto claramente com as mudanças de tempo de permanência de ataques a nível global e regional, conforme diferentes regiões adotaram a “Kill Chain” e defesas de “Zero Trust”. De acordo com os relatórios anuais M-Trends da FireEye, o tempo médio de permanência de um ataque a nível global foi de 229 dias em 2013 e no relatório de 2020 foi de 56 dias. Os números regionais também apoiam o sucesso dessa abordagem arquitetônica, com disparidade conhecida na adoção do padrão arquitetônico de “Zero Trust” e as estruturas de defesa de “Kill Chain” e do “MITRE ATT&CK Framework”.

Os Estados Unidos eram conhecidos por serem os primeiros a adotar ambos. Selecionando 2017 como exemplo, o tempo médio de permanência de ataques nas Américas foi de 75 dias e na Ásia de 172 dias. Organizações menores ou aquelas com menos recursos em qualquer região e em qualquer momento podem passar por tempos de permanência totalmente diferentes de organizações maiores e com bons recursos. Os números do tempo de permanência ajudam a demonstrar o sucesso desses controles com dados tangíveis.

O “Zero Trust” evoluiu de uma definição apenas de rede, em que os aplicativos eram segregados, para um nível mais granular de suporte à detecção de comportamentos inesperados entre todos os componentes. E a conexão lógica entre o “Zero Trust” e a Lockheed “Kill Chain” demonstra o valor claro dos modelos. Isso também ajuda a projetar o futuro de “Zero Trust” como cada vez mais centrado em dados, construído sobre uma base no isolamento dos componentes, desde a inicialização na infraestrutura, atestando sua identidade com verificações de níveis de garantia e segurança em toda a pilha, incluindo os micro-serviços.

Princípios de “Zero Trust”

A seguir está uma lista proveniente da publicação NIST CSRC SP 800-207 com alguns dos princípios da arquitetura “Zero Trust”, que podem apoiar a implantação e manter a garantia da eficácia deste modelo de arquitetura de segurança:

  1. Todas as fontes de dados e serviços de computação são considerados recursos;
  2. Todas as comunicações são protegidas, independentemente da localização;
  3. O acesso aos recursos individuais da empresa é concedido por sessão;
  4. O acesso aos recursos é determinado por uma política dinâmica;
  5. Todos os dispositivos próprios e associados estão no estado mais seguro possível;
  6. Todos os recursos de autenticação e autorização são dinâmicos e rigorosamente aplicados; e
  7. Colete o máximo de informações possível sobre o estado atual da infraestrutura de rede para melhorar a postura de segurança.

Informações obtidas/adaptadas de: https://www.cisecurity.org/blog/where-does-zero-trust-begin-and-why-is-it-important/ e https://csrc.nist.gov/publications/detail/sp/800-207/final