.
Recurso patrocinado Quando vulnerabilidades de software e zero dias subiram na lista de preocupações das empresas há 15 anos, ninguém imaginou que o mundo um dia acabaria com uma ameaça tão desconcertante quanto Log4Shell – uma vulnerabilidade na estrutura de log de código aberto Apache Log4j que é usada em software em todos os principais sistemas operacionais, abrangendo tudo, desde serviços em nuvem até jogos para PC.
No que pode ser chamado de dias mais felizes do passado, as falhas eram algo que afetava aplicativos individuais e fornecedores de software individuais. Você podia ver onde estava o problema porque estava dentro do código de uma empresa. Consertar essas falhas nem sempre era simples – patches nem sempre estavam disponíveis rapidamente para zero dias – mas pelo menos a hierarquia de responsabilidade era clara.
Log4Shell, ou CVE-2021-44228 para dar seu nome preciso, era muito diferente. A megafalha do RCE de dezembro de 2021 se tornou o exemplo mais recente de um tipo novo e cada vez mais comum de supervulnerabilidade que desafiou essas prescrições simples. Esse era o tipo de dia zero que daria a um invasor remoto controle completo sobre um servidor vulnerável (pontuação CVSS 10,0), mas isso era apenas o começo da ansiedade.
Menos solúvel foi sua onipresença – o Log4j é uma das ferramentas mais populares usadas pelos desenvolvedores para coletar informações em redes, sites e aplicativos. Todo mundo tinha usado e estava dentro de inúmeros aplicativos construídos em torno do Apache Frameworks, incluindo serviços tão incorporados na vida cotidiana quanto o iCloud da Apple. As superfalhas, então, foram em parte um produto da maneira como o mundo se inclinou para sistemas de software em expansão construídos a partir de várias partes, algumas mais cuidadosamente cuidadas do que outras, o Lego no qual repousam as plataformas de nuvem de hoje.
De acordo com análise pela startup de segurança em nuvem Wiz e EY (Ernst & Young), 93% dos ambientes em nuvem eram vulneráveis à vulnerabilidade Log4Shell. A boa notícia foi que, 10 dias após a divulgação da falha, 45% dos ambientes de nuvem vulneráveis (excluindo servidores locais) foram corrigidos. E, no entanto, a tarefa de corrigir esse tipo de falha pode ser complexa em ambientes de nuvem. Mesmo encontrar a falha é uma tarefa importante, enquanto a biblioteca afetada pode ser implantada como um pacote ou já integrada a um aplicativo.
Se as falhas ameaçavam a integridade de aplicativos individuais, na era da nuvem um problema semelhante poderia prejudicar serviços inteiros e as plataformas das quais eles dependem. As correções seriam lentas, caras e poderiam nem acontecer. Em algumas organizações, o Log4J2 pode ser enterrado em centenas de instâncias individuais, um trabalho gigantesco de limpeza para algo tão importante.
exposição oculta
Crescendo a passos largos, a Wiz foi criada em 2020 para resolver esse e muitos outros problemas multifacetados que começam a pesar nas nuvens híbridas. Os fundadores da empresa perceberam que proteger essas plataformas era inerentemente difícil, mesmo quando as equipes de segurança não estavam correndo para corrigir falhas específicas, como o Log4Shell. Há muita coisa para dar errado:
– Falhas de segurança abertas por configuração incorreta.
– As exposições ocultas que surgem com Infraestrutura como código (IaC).
– Proteger pipelines e implantação de contêiner, incluindo ambientes de contêiner no local, como o OpenShift da Red Hat.
– Implementação de uma plataforma de proteção de aplicações nativa em nuvem (CNAPP) para unificar a gestão.
– Aplicação do gerenciamento de direitos de infraestrutura de nuvem (CIEM).
– Identificar repositórios de dados que contêm informações confidenciais que podem ser expostas acidentalmente.
É um desafio com o qual as ferramentas existentes lutam, argumenta o vice-presidente de produtos da Wiz, Yinon Costica, que aponta que elas foram adaptadas ad-hoc de um modelo de computação estabelecido que não foi criado com a segurança da nuvem em mente.
“As ferramentas existentes levam de meses a anos para implantar ferramentas de agente tradicionais e ainda resultam em pontos cegos e falta de visibilidade do ambiente”, diz ele. “Eles analisam camadas como contêineres ou um único fator de risco, como gerenciamento de vulnerabilidade ou CIEM, que geram muitos alertas ruidosos que exigem esforço manual para correlacionar o risco. Mas os caminhos de ataque reais são muito mais sofisticados e envolvem a exploração de muitos fatores de risco em combinação. “
As ferramentas específicas da plataforma são soluções pontuais que não funcionam bem nas nuvens híbridas de hoje ou se integram no local com o monitoramento da nuvem. Lidar com alertas de segurança é particularmente desafiador em ambientes de nuvem que apresentam várias partes interessadas e camadas de tecnologia, e corrigir o problema tende a criar problemas adicionais.
A Wiz foi fundada especificamente para resolver esses problemas de segurança na nuvem. Ele integra um conjunto de recursos em um novo tipo de plataforma que oferece suporte a toda a pilha de nuvem, incluindo sistemas operacionais e bibliotecas de código conectadas a AWS, Azure e GCP, bem como Kubernetes e OpenShift. Ao contrário das ferramentas rivais, não há nada para implantar – nenhum agente para instalar ou gerenciar – tudo o que os clientes precisam fazer é conectar seu ambiente de nuvem
Visibilidade é a chave
A plataforma primeiro verifica configurações incorretas, pontos fracos e possíveis comprometimentos maliciosos, função realizada por meio de chamadas de API sem a necessidade de agentes tradicionais, um dos diferenciais da plataforma. As vantagens da abordagem sem agente são que ela ignora o problema de que alguns sistemas não podem executar agentes, não existem por tempo suficiente para instalá-los ou executá-los consumiria recursos preciosos.
“Ao adotar uma abordagem 100% baseada em API para a varredura em nuvem, a Wiz pode reduzir rapidamente o tempo de implantação de meses para anos com abordagens tradicionais baseadas em agentes para minutos por dia.”, diz Costica.
Além disso, confiar na cobertura irregular fornecida pelos agentes pode resultar em uma imagem de segurança incompleta e enganosa. “Por meio de instantâneos, o Wiz pode ingerir todos os metadados de segurança relevantes, que são executados por meio de um mecanismo de análise de risco em diferentes camadas e modelados em um banco de dados gráfico para correlacionar tudo.”
Este é o Wiz Security Graph, uma representação visual contextual que cria uma única visão priorizada dos riscos em um ambiente, incluindo gerenciamento de vulnerabilidades e verificação de IaC, segurança Kubernetes, estado de proteção de carga de trabalho na nuvem e CIEM. O Graph acomoda controles e políticas personalizados e pode ser usado para responder a uma variedade de consultas mais profundas.
“Ao modelar o ambiente de nuvem e os fatores de risco em um gráfico, o Wiz oferece contexto e uma visão facilmente explorável da nuvem para os usuários. Além das visualizações e consultas, o Security Graph permite que o Wiz interrogue o ambiente de nuvem subjacente”, acrescenta.
Por meio do insight fornecido pelo gráfico de segurança, os clientes podem ver as vulnerabilidades, configurações incorretas e caminhos de ataque em toda a sua infraestrutura, em muitos casos a primeira vez que eles têm uma visão tão abrangente.
Mas simplesmente abordar o problema da equipe de segurança não é suficiente para fazer a segurança na nuvem funcionar. O desenvolvimento de aplicativos nativos da nuvem de maneira ágil envolve equipes que podem criar aplicativos fracamente acoplados – independentemente uns dos outros em toda a empresa. Isso significa que a segurança deve ser integrada a um processo de desenvolvimento que permita às equipes iterar aplicativos de maneira descentralizada.
“O Wiz permite que as equipes de desenvolvimento atuem independentemente da segurança com visibilidade direta, priorização de riscos e contexto nos ambientes de sua propriedade, para que possam enviar com mais rapidez e segurança”, diz Costica.
“O controle de acesso baseado em função garante que os desenvolvedores vejam apenas os recursos e riscos que possuem. As equipes usam o Wiz para implementar um pipeline de imagem de VM de ouro, fortalecendo suas imagens antes da distribuição e garantindo que todas as equipes criem instâncias a partir de imagens de VM reforçadas.”
Descobrindo pontos cegos
A Costica oferece o exemplo de um contêiner Jenkins exposto à Internet no qual vulnerabilidades de VM exploráveis fornecem aos invasores um backdoor no ambiente de produção. Qualquer um desses problemas é potencialmente perigoso, mas a combinação de descuidos transforma isso em um desastre em formação. O Wiz foi projetado para detectar precisamente esse tipo de problema de segurança complexo antes que o dano seja feito.
Segundo Costica, “os riscos mais críticos que podem levar a violações geralmente são uma combinação de vários fatores de risco diferentes. Os caminhos de ataque reais são muito mais sofisticados do que uma única configuração incorreta ou vulnerabilidade e geralmente envolvem a exploração de muitos fatores de risco combinados”.
Outro problema é a forma como muitas vulnerabilidades da nuvem ficam entre as lacunas de relatórios. Na esfera do software, as vulnerabilidades são divulgadas e rastreadas usando CVEs, um sistema que se mostrou menos adequado ao contexto de segurança em nuvem, argumenta Wiz. Em muitos casos, o que justifica um CVE cabe ao provedor de serviços em nuvem, que derruba de cabeça o modelo de CVE em que o cliente gerencia as correções a seu critério. Mas, sem CVEs para muitos problemas, os clientes acham mais difícil descobrir quais correções são as mais urgentes. Em muitos casos, quando são contadas, a notícia chega por e-mail, meio de comunicação pouco confiável.
A resposta de Wiz é O banco de dados de vulnerabilidades e problemas de segurança do Open Clouduma iniciativa aberta anunciado em 2022 que se propôs a se tornar um repositório público de falhas na nuvem e problemas de provedores de serviços. Como afirma o site:
“Nosso objetivo neste projeto é preparar o caminho para um banco de dados centralizado de vulnerabilidades na nuvem, catalogando os erros de segurança do CSP e listando as etapas exatas que os clientes do CSP podem seguir para detectar ou prevenir esses problemas em seus próprios ambientes.”
O que conta é que o cliente entenda sua exposição a questões críticas o mais rápido possível. Embora seja um exemplo extremo, o Log4Shell foi um exemplo, diz Costica.
“Menos de 24 horas após a descoberta do Log4Shell, os clientes puderam usar o Wiz para detectar se estavam utilizando bibliotecas Log4j vulneráveis em todas as nuvens e cargas de trabalho em seu ambiente e seguir as orientações de correção do produto para reduzir o risco”.
A realidade é que esse tipo de falha rapidamente se transforma em guerra de trincheiras e não retrocederá mais do que outras falhas infames, como Heartbleed de 2014 tem. Anos depois, muitos servidores permanecer vulnerável para esta questão, ele aponta. O Log4Shell continuará a ser um problema porque muitas organizações não têm tempo ou vontade de consertá-lo ou, pior, não conseguem ver sua vulnerabilidade em primeiro lugar. E quando eles consertam o Log4Shell, isso não resolve o problema mais amplo de que outra grande falha ocorrerá em algum momento.
“Os clientes precisam ver a escala do problema o mais rápido possível. Isso requer o software certo para o trabalho.”
Patrocinado por Wiz.
.
