Zero Trust: três componentes estratégicos essenciais da abordagem "Assuma a violação"

Ken Arora

Zero trust é um tema popular nos círculos de cibersegurança hoje em dia, mas ainda recebo olhares estranhos sempre que menciono o conceito de presumir uma violação como parte fundamental da mentalidade de zero trust. Presumo que essa reação decorra de uma entre duas possíveis preocupações. Primeiro, alguns profissionais de segurança podem interpretar isso como uma visão terrivelmente pessimista do mundo; para eles, “presumir uma violação” seria algo como: “Então, você está dizendo que estamos todos condenados. Bem, nesse caso, vamos simplesmente desistir e parar até mesmo de tentar.” Outros, talvez os mais orgulhosos, podem ter uma atitude do tipo: “Bem, as suas coisas podem sofrer uma violação, mas a minha segurança é extremamente sólida, e não há como os invasores conseguirem passar pelas minhas defesas.”

Minha intenção não é defender nenhum desses extremos, mas sim enfatizar a importância de assimilar a realidade de operar em um mundo digital: violações ocorrerão e, portanto, podem e devem ser levadas em consideração no projeto de qualquer sistema de segurança. Esse não é um conceito novo, e devemos nos inspirar na sabedoria adquirida por gerações de artesãos e profissionais de ofícios que adotaram essa abordagem.

Encanadores, eletricistas e outros profissionais que atuam no mundo físico há muito compreenderam a verdadeira essência de “presumir uma violação”. Como são responsáveis por criar soluções que precisam ser robustas em ambientes concretos, eles aceitam e incorporam implicitamente o simples fato de que falhas acontecem no âmbito de seu trabalho. Eles também entendem que as falhas não são uma condenação de suas habilidades, nem um motivo para deixar de contratar seus serviços. Pelo contrário, somente os mais qualificados, por entenderem que suas criações acabarão falhando, incorporam os aprendizados de falhas anteriores e conseguem prever possíveis falhas futuras.

Recentemente, tive de lidar com uma falha desse tipo: um cano de esgoto da minha casa ficou entupido no meio do percurso de drenagem. A casa tem mais de 30 anos, portanto, uma falha — uma violação — não deveria ser uma surpresa. Afinal, a probabilidade de violação de qualquer sistema ao longo de um período prolongado se aproxima de 100%.

Essa é a questão. Prever que uma falha ocorrerá com o tempo é tão válido para uma solução de segurança de aplicações quanto para o sistema hidráulico da minha casa. Além disso, presumir que “meu sistema hidráulico nunca falhará” não é mais adequado como estratégia de manutenção doméstica do que presumir que “minhas defesas cibernéticas nunca serão violadas”.

Portanto, tanto o encanador quanto o profissional de cibersegurança devem estar preparados para lidar com a falha — ou seja, a violação — que inevitavelmente ocorrerá.

Três componentes estratégicos essenciais da abordagem Assume Breach

Uma estratégia eficaz para lidar com falhas em sistemas — físicos ou cibernéticos — geralmente tem três componentes.

1. Visibilidade. Garanta visibilidade suficiente para permitir a detecção de uma falha o mais rápido possível. Um vazamento no encanamento do ralo de um banheiro, se não for corrigido, causará apodrecimento e o surgimento de bolor ou mofo no contrapiso, o que pode levar meses ou anos para ser percebido. Outra possibilidade é alguém notar água pingando do teto do ambiente abaixo de um banheiro no segundo andar, depois que uma bandeja de contenção sob o piso transbordou e o drywall ficou encharcado. Em qualquer um desses cenários, o problema só é detectado algum tempo após a falha inicial e depois que outros danos secundários já ocorreram. O primeiro princípio da abordagem de presumir falhas ou violações deve ser fornecer indicadores claros de um possível comprometimento o mais rápido possível após a falha e, idealmente, até mesmo emitir notificações proativas sobre falhas prováveis. Por exemplo, porões que dependem de bombas de drenagem para remover água geralmente têm sensores que disparam um alarme quando o nível da água ultrapassa um limite predefinido. Em outras situações, nas quais não é viável emitir alertas proativos para todos os modos de falha prováveis, são realizadas verificações de manutenção de rotina — por exemplo, a inspeção semestral de aquecedores de água. Em segurança cibernética, isso significa que a arquitetura de segurança da aplicação deve incluir uma estratégia de telemetria bem planejada e testada, que considere os modos de falha mais importantes e forneça visibilidade em tempo hábil sobre possíveis violações. Na prática, a telemetria deve ser transmitida para ferramentas de análise e notificação por meio de práticas de AISecOps e, simultaneamente, armazenada de forma persistente em repositórios de dados para uso posterior. Ferramentas de IA e de alerta devem ser usadas para aumentar a eficácia, fornecer contexto às pessoas e garantir uma resposta em tempo hábil. Os dados armazenados devem ser usados para gerar aprendizados e ajudar a orientar melhorias futuras de robustez. 
2. Robustez. As soluções devem incluir meios para contornar uma falha ou reduzir sua duração. Os padrões comuns de robustez nesse contexto são (a) degradação gradual ou (b) redundância, e a escolha depende da viabilidade de operar com um componente degradado. Alguns sistemas, como aquecedores de água, podem contar com ambos. Por exemplo, meu aquecedor de água usa um sistema de recirculação alimentado por bomba para manter a água quente sempre pronta para uso. Porém, se a bomba falhar, ainda terei água quente, mas precisarei esperar um pouco mais por ela. Por outro lado, a falha de um sensor da resistência de aquecimento — quando o elemento de aquecimento não desliga — pode levar a uma falha catastrófica, por isso é utilizada redundância na forma de uma válvula de alívio de pressão. A robustez deve ser considerada em vários escopos do sistema. Por exemplo, considerando apenas a tubulação de escoamento, um encanador que trabalhe em uma solução de nível comercial pode instalar duas linhas de escoamento redundantes, para que a falha de qualquer uma delas não inutilize o ralo. Por outro lado, um arquiteto que trabalhe no nível de abstração do sistema poderia projetar redundância nesse nível, como adicionar uma segunda pia ou um segundo vaso sanitário nas proximidades, o que também teria a vantagem de contemplar mais modos de falha do que apenas tubulações de escoamento entupidas. Sem dúvida, a redundância é uma prática comum em segurança cibernética, pois muitos dispositivos de segurança são implantados no modo ativo/em espera (redundância total) ou ativo/ativo (degradação gradual). No entanto, o mundo da segurança cibernética difere um pouco do mundo físico. Primeiro, o fato de haver invasores ativos, dotados de intenção e inteligência, no mundo da segurança cibernética significa que as falhas raramente resultam de causas naturais. Uma segunda diferença, mais significativa, é a escala. Como o software é virtual, e não físico, ele segue o paradigma de “escrever uma vez, implantar muitas vezes”. Embora essa seja uma propriedade excelente para a escalabilidade, ela também implica que uma vulnerabilidade no código de um componente central de software provavelmente afetará todas as instâncias desse código no sistema. Portanto, a solução de segurança cibernética para a robustez também se baseia em evitar pontos únicos — e classes únicas de elementos — de falha, uma estratégia às vezes chamada de “defesa em profundidade”. A autenticação multifator é um ótimo exemplo dessa ideia na prática. O modo de falha (o meio de comprometimento) de cada fator é diferente, e o comprometimento de apenas um deles não comprometerá o sistema como um todo. 
3. Contenção. É fundamental limitar o impacto — a área afetada — de uma falha. Assim como aceitamos que falhas ou violações ocorrerão, também precisamos aceitar que não conseguiremos evitar totalmente pontos únicos de falha nem implementar redundância para cada requisito funcional. Portanto, o arquiteto também deve considerar como minimizar o impacto de uma falha, usando tanto o esforço quanto as consequências como duas importantes métricas de eficácia. Por exemplo, um encanador pode adicionar pontos de inspeção estrategicamente posicionados às tubulações de esgoto para reduzir o tempo de reparo. Para falhas mais catastróficas, um empreiteiro pode optar por tubulações de esgoto de PVC em vez de galvanizadas, facilitando o reparo de um vazamento e reduzindo o esforço necessário. Uma prática comum em instalações hidráulicas residenciais é a inclusão de registros para limitar as consequências de uma falha (detectada), evitando assim danos secundários a gabinetes e pisos. No mundo da cibersegurança, os conceitos análogos são isolamento, manutenibilidade e modularidade. Isolamento consiste em minimizar danos colaterais ou estancar o problema; uma boa prática é contar com uma infraestrutura capaz de atuar como um disjuntor, usando tecnologias como a microssegmentação. Manutenibilidade significa possibilitar, sempre que possível, uma recuperação rápida e de baixo esforço, passando de um estado comprometido para um não comprometido; por exemplo, reiniciar uma carga de trabalho comprometida por ataques de estouro de memória pode ser um método de mitigação eficaz (embora incompleto). Modularidade é a prática de construir sistemas que permitam substituir facilmente componentes funcionais equivalentes, de modo que, quando a manutenção não for possível ou suficiente, o esforço necessário para a correção seja minimizado.

Estas são algumas das melhores práticas que aprendi para lidar com violações, embora certamente não afirme que não existam outras. O mais importante é que os desenvolvedores e profissionais de segurança responsáveis por proteger aplicações entendam que falhas passarão despercebidas e que violações inevitavelmente acontecerão. Diante disso, a forma como nos preparamos para essas falhas e lidamos com elas é igualmente importante e merece tanta reflexão cuidadosa quanto as medidas que tomamos para minimizar a frequência dessas ocorrências.

Em última análise, seremos avaliados não apenas pela frequência com que as violações ocorrem, mas também pela forma como reagimos a elas quando inevitavelmente acontecem.

Sobre o autor

Ken Arora

Mais publicações de Ken Arora