3 reflexões sobre a operacionalização da arquitetura Zero Trust

Desde a publicação da Ordem Executiva 14.028 em 2021, que, entre muitas outras coisas, orienta o governo federal dos Estados Unidos a adotar arquiteturas Zero Trust (ZTA), a Gigamon vem investindo em pesquisa e desenvolvimento em ZTA. Em fevereiro de 2024, a Gigamon está rastreando dez estruturas, modelos de maturidade e padrões diferentes que afirmam ser Zero Trust, além da “Arquitetura Zero Trust” do NIST SP 800-207, que é a orientação mais universalmente aceita. Em nossa opinião, no entanto, o “Zero Trust Reference Framework v2” do Departamento de Defesa (DoD) e o “Zero Trust Maturity Model v2” da Agência de Segurança Cibernética e de Infraestrutura (CISA) são as duas publicações seminais que impulsionam a evolução arquitetônica do ZTA para Gigamon e outros. Ambas as publicações são baseadas no NIST SP 800-207.

Nesta postagem do blog, quero falar sobre três tópicos de interesse em torno do ZTA. Estes são principalmente estratégicos e são um apelo à ação para os arquitetos que projetam infraestruturas ZTA.

Reflexão em: ZTA é impulsionado por telemetria

Esta é uma afirmação, e é surpreendente para mim quantos arquitetos de segurança me olham em estado de choque quando faço esta afirmação. O que você quer dizer com telemetria? Bem, vamos voltar ao básico e dar uma olhada no NIST SP 800-207 e no conceito arquitetônico fundamental:

Conceitualmente, o NIST SP 800-207 modela o ZTA como um dispositivo de rede, com dados e plano de controle separados. O ponto de decisão de política (PDP) é o controlador, subdividido em um mecanismo de política (PE) que avalia as decisões baseadas em risco e um administrador de política que orquestra essas decisões.

Então, o que impulsiona o mecanismo político? Telemetria. É fundamentalmente assim que funciona, apoiado por feeds de inteligência de ameaças e políticas organizacionais.

Isto leva a uma segunda constatação: quanto maior for a qualidade da telemetria, melhor funcionará o PE. É banal dizer, mas lixo entrando e lixo saindo é uma coisa que acontece. Se alimentarmos o PE com telemetria de baixa qualidade, ele não funcionará bem.

Quando os arquitetos de segurança pensam em telemetria, geralmente pensam em logs. Correndo o risco de compartilhar demais, tem havido uma grande discussão interna sobre exatamente o que é e o que não é um log. MELT (métricas, eventos, logs e rastreamentos) é uma definição, obviamente.

Meu colega Josh Perry observou que o NIST SP 800-92 define um log, ou melhor, especificamente, um log de segurança:

“Um log é um registro dos eventos que ocorrem nos sistemas e redes de uma organização. Os logs são compostos por entradas de log; cada entrada contém informações relacionadas a um evento específico que ocorreu em um sistema ou rede. Originalmente, os logs eram usados ​​principalmente para solucionar problemas, mas agora eles servem muitas funções na maioria das organizações, como otimizar o desempenho do sistema e da rede, registrar as ações dos usuários e fornecer dados úteis para investigar atividades maliciosas. Os logs evoluíram para conter informações relacionadas a muitos tipos diferentes de eventos que ocorrem em redes e sistemas. Dentro de uma organização, muitos logs contém registros relacionados à segurança do computador; exemplos comuns desses logs de segurança de computador são logs de auditoria que rastreiam tentativas de autenticação de usuários e logs de dispositivos de segurança que registram possíveis ataques. Este guia aborda apenas os logs que normalmente contém informações relacionadas à segurança do computador.”

Eu diria que a diferenciação entre “log de segurança” e algum outro tipo de log pode ser artificial e problemática. Na observação de erros inesperados não relacionados à segurança, por exemplo, podemos encontrar evidências de um intruso altamente furtivo. Pense, por exemplo, em travamentos incomuns da placa NIC indicando a presença de um implante de firmware em execução no microcontrolador incorporado como exemplo teórico. Contudo, a definição formal é bastante discutível: o que precisamos é de visibilidade. Os logs não são um fim em si mesmos – preciso que eles vejam os sinais e a postura, e eles estão me dando visibilidade sobre isso. Mas o que é visibilidade então? Gosto muito da definição de visibilidade da CISA em seu excelente “Rascunho do Guia do Programa Extensible Visibility Reference Framework (eVRF)”:

“No seu sentido mais geral, o termo ‘visibilidade’ é um substantivo abstrato que descreve algo que é visível. A CISA aplica o termo visibilidade para se referir (a) aos artefatos observáveis ​​de eventos digitais e (b) às características do ambiente digital em que esses eventos ocorrem. Ao coletar e analisar os artefatos e características observáveis ​​de um ambiente, as organizações terão os dados necessários para conduzir investigações forenses sobre atividades de ameaças e manter uma melhor consciência da atividade de forma contínua.“

Em uma postagem futura no blog, descreverei alguns dos desafios relacionados à visibilidade e, especialmente, à garantia de visibilidade. Para quem quiser uma prévia, veja minha apresentação IEEE MILCIS 2023. Para obter o feedback inicial da Gigamon sobre o rascunho do eVRF, onde desenvolvemos uma estrutura informal sobre garantia de telemetria, consulte esta postagem do blog.

Quando avaliamos nossos mecanismos de telemetria, uma coisa que observo é um viés de familiaridade inconsciente. Um viés de familiaridade é uma forma de viés cognitivo em que enfatizamos demais (e confiamos demais) no que é familiar e, inversamente, confiamos pouco em abordagens alternativas com as quais não estamos familiarizados.

O registro tradicional – eventos de syslog e Windows – é familiar. Muitos arquitetos de segurança os utilizam há décadas e, reflexivamente, os utilizam como sua primeira e, às vezes, única técnica de visibilidade. Não acho que devemos abandonar o registro em log, mas confiar apenas nos logs tradicionais de sistema operacional, aplicativos, agentes e dispositivos não é o que deveríamos fazer em 2024.

Então quais são as alternativas?

Bem, existem duas: primeiro, confie no comportamento de rede medido externamente das workloads monitoradas. Isso é chamado de observabilidade profunda, e a vantagem disso é que geralmente deriva de um toque ou serviço que está fora da carga de trabalho monitorada e, portanto, é muito difícil de ser evitado por um invasor.

Em segundo lugar, utilize a telemetria do seu hipervisor ou recursos como o eVRF. Um exemplo disso seria a tecnologia Gigamon Precryption™, que usa eVRF para interceptar tráfego criptografado e enviar texto simples para análise externa. Esta análise pode ser baseada em dados ou em metadados, dependendo das metodologias específicas de detecção de ameaças utilizadas.

Reflexão 2: Combinando Detecção e Resposta

O viés da familiaridade nos ataca novamente de outra maneira, e isso envolve controles de segurança que combinam detecção e resposta/remediação em um dispositivo ou serviço.

Este é um modelo muito familiar para a maioria das organizações: firewalls, sistemas de prevenção de invasões (IPS), detecção e resposta de endpoint (EDR) e até mesmo tecnologias legadas como antivírus incorporam esse modelo. Isto não inclui apenas dispositivos físicos e virtuais, mas também agentes.

Mas aqui está o desafio: não é o único modelo e não é o modelo ideal para uma infraestrutura ZTA totalmente realizada. Embora possa representar uma implantação de primeiro estágio para uma ZTA corporativa, existem três problemas fundamentais com a combinação de capacidades de detecção e resposta em um único controle:

1. A capacidade de resposta foi projetada principalmente para ser aproveitada no contexto do ecossistema específico da ferramenta. No contexto da ZTA, qualquer leitura lógica da arquitetura sugere que o controle primário deve ser exercido pelo PDP, e não pela ferramenta em si.3
2. Comprometer o controle individual compromete potencialmente a capacidade de detecção e resposta.4 Isso é agravado se a ferramenta for um dispositivo físico ou virtual, que adiciona todo o ambiente do sistema operacional à capacidade de detecção e resposta, e há ampla evidência de que tais dispositivos são de alta qualidade. metas prioritárias para atores de ameaças do Estado-nação, com numerosos exemplos recentes e atuais.
3. Uma ferramenta ou controle específico pode ter uma excelente capacidade de detecção ou resposta, mas, a menos que seja o melhor para ambos, somos forçados a aceitar também o lado menos impressionante. Se estiverem separados, escolhemos o melhor de ambos.5
4. Embora possamos alimentar o mecanismo de políticas com incidentes detectados, a maioria fornecerá contexto insuficiente para que o mecanismo de políticas funcione de maneira eficaz (ver Pensamento 3).

Para ser justo, essa combinação também tem pontos positivos:

1. A latência desde a detecção até a resposta pode ser minimizada, o que pode ser valioso para TPPs sabidamente ruins com baixas taxas de falsos positivos. Esse é um ponto justo.
2. Uma única ferramenta tem uma sobrecarga de aprendizagem menor, pode custar menos e pode ter outros benefícios – basicamente, todo o argumento de consolidação da ferramenta, com todos os riscos e ineficiências inerentes que se aceitam ao seguir esta estratégia.

Eu diria que a separação entre capacidade de detecção e capacidade de resposta é altamente desejável. Este não é um modelo familiar, mas tudo bem quando descartamos nosso viés de familiaridade e olhamos para o que o ZTA precisa.

Reflexão 3: Ignorando o valor da correlação de telemetria

Quando a Gigamon iniciou esta jornada de P&D da ZTA em 2021, uma das primeiras abordagens que adotamos foi compreender uma abordagem de telemetria orientada pela ciência de dados. Especificamente, que tipo de dados poderíamos alimentar o mecanismo político, e em que formato, para que funcione melhor?

Você pode observar domínios de telemetria, que o eVRF chama de superfícies de visibilidade. Vou ficar com os domínios de telemetria no restante desta postagem do blog. Na maioria das organizações, eles são distintos e tratados de forma diferente, principalmente porque a maioria das ferramentas de detecção são projetadas para ingerir apenas os seus próprios dados de telemetria.

Então, vamos considerar a tríade da telemetria: logs tradicionais (MELT) do sistema operacional ou aplicativo, telemetria dos agentes de segurança e o comportamento de rede de um sistema ou serviço medido pela rede. Tipos de telemetria muito diferentes, certo? Não são úteis juntos?

Bem, não. Na verdade, eles são incrivelmente úteis para correlacionar e, quando combinados e correlacionados positiva e negativamente, fornecem insights incríveis sobre ações normais e atípicas (ou seja, ameaças potenciais) dentro do seu ambiente ZTA.

A assimetria na tarefa entre atacante e defensor está bem documentada, com alguns apontando para “Vom Kriege” (1831) de Karl von Clausewitz como a fonte original desta observação. É mais difícil ser defensor do que atacante, em geral. No entanto, uma vez dentro da nossa infra-estrutura Zero Trust, o papel do atacante e do defensor inverte-se, com o PDP a tornar-se o atacante e o defensor a ser o nosso intruso. É por isso que os invasores praticam rotineiramente a evasão, e esta é uma fase da estrutura MITRE ATT&CK. De acordo com a estrutura, Defense Evasion possui 43 técnicas documentadas, a maior de todas as fases.

Portanto, pense como um invasor: cada uma dessas técnicas é específica para um tipo específico de domínio de telemetria ou superfície de visibilidade e, na verdade, ativar técnicas de evasão geralmente afeta apenas uma e pode, na verdade, aumentar a telemetria para outra. Por exemplo, um invasor baixando um script Python para reciclar constantemente /var/log/messages com carimbos de data/hora atualizados enquanto desativa o registro real gerará tráfego de rede extra ao fazer isso. Também irá gerar uma entrada EDR informando que um novo arquivo executável foi criado.

Mas também, as operações normais (sem risco) também verão clusters únicos de diferentes domínios de telemetria operando juntos. Esse tipo de cluster é perfeito para técnicas de IA/ML caracterizarem e gerarem relatórios. É assim que o mecanismo político deve funcionar, mas requer uma telemetria razoavelmente densa dos controles para ser alcançado. Uma ferramenta que diz apenas “detectei uma ameaça” aqui não é útil para esse tipo de análise.

Na segunda versão do Modelo de Maturidade de Confiança Zero da CISA (pp. 21–22), na coluna “Ótimo” de “Visibilidade e Capacidade de Análise”, eles observam:

“A agência mantém a visibilidade da comunicação em todas as redes e ambientes da agência, ao mesmo tempo que permite o conhecimento situacional em toda a empresa e recursos avançados de monitoramento que automatizam a correlação de telemetria em todas as fontes de detecção.”

(Minha ênfase adicionada.)

Embora este tenha sido o feedback que demos à CISA na versão 1 do seu documento, não temos ideia se a recomendação veio do nosso feedback ou de uma análise razoável e independente da operação de um mecanismo de política. Mas faz sentido, independentemente da fonte.

Embora a detecção de ameaças possa ser feita com telemetria mínima, além de alertas de ferramentas individuais, a caracterização de “normal” ou “risco mínimo” versus “anormal” e “indicativo de risco” exigirá mais do que normalmente obtemos com ferramentas de segurança. Isso exigirá um log denso de aplicativos e sistemas operacionais, caracterização comportamental da rede e análise de dados em uso – em movimento e em repouso. Será a correlação desses dados densos que fará com que o Zero Trust funcione bem, e precisamos arquitetar isso hoje.

Um comentário final sobre a questão dos domínios de telemetria/superfícies de visibilidade: embora seja totalmente aceitável e indiscutivelmente inevitável ter diferentes formatos de dados em diferentes domínios de telemetria, é altamente desejável ter o mesmo formato em vários ambientes cobertos pelo mesmo domínio de telemetria. Deixe-me esclarecer isso com um exemplo: embora a telemetria originada pelo agente e a telemetria originada pelo tráfego de rede estejam necessariamente em um formato diferente e contenham diferentes elementos de dados, é altamente indesejável que a telemetria originada pelo tráfego de rede tenha um formato diferente quando derivada de redes locais, redes virtuais e redes de nuvem pública. Eles devem estar basicamente no mesmo formato, o que significa que nenhuma normalização é necessária para a ingestão. Isso permitirá uma correlação mais fácil de atividades em vários ambientes, de modo que as táticas, técnicas e procedimentos (TTP) de um invasor implantados em um ambiente de nuvem pública versus local serão detectados prontamente, e sua taxonomia de dados não terá lacunas para alguns ambientes que um um ator de ameaça mal-intencionado poderia implantar.

A Gigamon reconhece o valor dos formatos comuns de dados de telemetria, pois eles facilitam muito a ingestão. No entanto, um formato comum de dados de telemetria também pode se tornar uma camisa de força e resultar em comprometimento da transmissão de dados (elementos são descartados porque não cabem na taxonomia, por exemplo) ou em extensões aleatórias que ninguém suporta.

Conclusão

Vou fazer uma declaração muito provocativa: se você está construindo uma arquitetura Zero Trust e não está pensando em alimentar um mecanismo de política, então questiono se você está realmente fazendo Zero Trust ou outra coisa e apenas chamando-o de Zero Trust.

O ponto de decisão política, que consiste em um mecanismo de política e um administrador de política, é o núcleo de uma arquitetura Zero Trust. Sem ele, você terá apenas uma coleção de controles e talvez um SIEM: nada que não construímos há 20 anos. Isso não é Zero Trust.

Os mecanismos de política são movidos por telemetria. Isso significa mais do que apenas logs de sistema operacional e de aplicativos, e quanto mais ricos forem os dados que alimentamos e quanto mais domínios de telemetria diferentes pudermos encontrar, melhor ele será capaz de funcionar. No futuro, a implantação de algoritmos de aprendizagem e IA, como a análise comportamental de usuários e entidades (UEBA), mas implantada em toda a empresa, proporcionará realmente uma melhoria significativa na postura, identificando precocemente comportamentos anômalos. No entanto, precisará ser alimentado por telemetria de alta qualidade para evitar falsos positivos e falsos negativos.

Por fim, vamos parar de pensar em controles consolidados como padrão, ou mesmo preferíveis, porque para Zero Trust, detecção e resposta são ações diferentes, e há grandes benefícios nessa separação, especialmente para Zero Trust.

Tal como acontece com todas as postagens do blog Gigamon, convido seus comentários e opiniões.