Por que as vulnerabilidades do Log4j destacam a importância do DevSecOps

Em dezembro de 2021, equipes de segurança de TI e organizações de desenvolvimento em todo o mundo receberam um alerta rude. Pesquisadores descobriram uma grave vulnerabilidade de segurança no utilitário Apache Log4j, um componente de registro popular incorporado em inúmeros aplicativos e serviços Java. As notícias dessa vulnerabilidade fizeram com que equipes de segurança de TI e organizações de desenvolvimento se esforçassem para encontrar todas as instâncias das versões vulneráveis do Log4j em suas próprias redes.

A vulnerabilidade Log4j também forçou as equipes de DevSecOps a responder a uma pergunta que agora parece menos teórica. Se o Log4j ou qualquer outra vulnerabilidade comprometesse um aplicativo desenvolvido internamente, as equipes de segurança seriam capazes de isolar o ataque e mitigar seus danos? As práticas atuais de DevOps preparam uma organização para caçar ameaças de forma rápida e eficaz por meio de seu próprio código?

Vamos dar uma olhada rápida na vulnerabilidade do Log4j, o que ela significa para as equipes de DevSecOps e como a segmentação Zero Trust da Illumio pode ajudar as equipes de DevSecOps a mitigar ameaças quando um software vulnerável é atacado antes que ele possa ser corrigido.

A vulnerabilidade do Log4j e por que ela é importante

A vulnerabilidade que receber toda essa atenção envolve O uso da interface de nomenclatura e diretório Java pelo Log4j (JNDI), uma popular API de nomenclatura e pesquisa para aplicativos Java. As versões anteriores do Log4j habilitavam o recurso de substituição de pesquisa de mensagens do JNDI por padrão. Usando esse recurso, os invasores podem enviar mensagens cuidadosamente construídas para um aplicativo, forçando o aplicativo a executar código carregado de servidores LDAP ou de outros endpoints sob o controle do invasor. Esse código pode instalar malware, exfiltrar dados ou realizar outras ações maliciosas na rede do aplicativo.

O Log4j é amplamente utilizado. O Google estima que está em 4 por cento dos pacotes Java no Repositório Central Maven, amplamente reconhecido como o repositório de pacotes Java mais importante. O Log4j é usado em todos os tipos de software, desde aplicativos da web até serviços de back-end e aplicativos personalizados para dispositivos de IoT.

Assim que essa vulnerabilidade foi anunciada, as equipes de segurança de TI começaram a vasculhar suas redes, procurando nomes de arquivos e outras indicações da presença do Log4j em qualquer diretório em seu ambiente. As equipes de DevOps também se ocuparam pesquisando seus próprios arquivos em busca de qualquer uso do Log4j em seus próprios aplicativos.

As apostas são altas. Os cibercriminosos já usaram essa vulnerabilidade para lançar ataques de ransomware, instalar software de mineração de moedas em redes corporativas e se infiltrar no Ministério da Defesa da Bélgica. Os atacantes estão criando novas formas de malware que visam a vulnerabilidade. Por exemplo, novos alvos de ransomware Night Sky Vulnerabilidades Log4j no software VMware Horizon.

Visão geral: vulnerabilidades do código-fonte e os riscos que elas representam

A vulnerabilidade Log4j destaca dois problemas maiores para organizações internas de desenvolvimento. Primeiro, não importa o quão bem organizados sejam suas ferramentas e processos de DevOps, a maioria das organizações tem dificuldade em determinar todos os componentes usados em seus aplicativos, especialmente se esses componentes estiverem incorporados como bibliotecas ou acessados por meio de dependências com outros serviços.

No caso do Log4j, por exemplo, é possível incluir o utilitário em um aplicativo sem deixar um arquivo JAR do Log4j em um repositório. Encontrar todas as versões de todos os componentes de software — de código aberto ou não — em aplicativos é um trabalho difícil e demorado.

Em segundo lugar, se for descoberto que um aplicativo está sob ataque por causa de uma vulnerabilidade, as equipes de segurança precisam de uma maneira de isolar o ataque imediatamente antes que o ataque possa se espalhar para outros sistemas na rede.

Detectar e interromper os ataques do Log4j é importante não apenas para proteger dados confidenciais e garantir a continuidade operacional, embora essas metas sejam obviamente críticas.

Mas também há um ângulo de conformidade. Em 4 de janeiro de 2022, o A Comissão Federal de Comércio dos EUA (FTC) anunciou que aplicaria penalidades e multas contra empresas que permitiram que dados confidenciais de consumidores fossem violados como resultado das vulnerabilidades do Log4j.

Citando sua Penalidade de 700 milhões de dólares contra a Equifax por vazar dados do consumidor devido a uma vulnerabilidade não corrigida na estrutura do Apache Struts, a FTC anunciou que “pretende usar toda a sua autoridade legal para perseguir empresas que não tomam medidas razoáveis para proteger os dados do consumidor da exposição como resultado do Log4j ou de vulnerabilidades conhecidas semelhantes no futuro”.

O Log4j, ao que parece, é a ponta de um enorme iceberg de ameaças em potencial. Para encontrar e corrigir vulnerabilidades não apenas relacionadas ao Log4j, mas ao qualquer componente de software em seus próprios aplicativos ou aplicativos de terceiros que estão executando, as empresas precisam de visibilidade abrangente de seus ambientes de software. Deixar de encontrar essas vulnerabilidades antes que elas resultem em uma violação de dados pode levar a multas regulatórias pesadas e danos permanentes à marca de uma organização.

Felizmente, o DevSecOps pode ajudar.

O papel do DevSecOps na mitigação de ameaças de vulnerabilidade de software

A ideia por trás do DevSecOps é simples: a segurança não deve ser uma reflexão tardia quando se trata de desenvolver e implantar software. Em vez disso, a segurança deve ser incluída em todas as etapas do DevOps, do design ao desenvolvimento, passando pelos testes e pelo gerenciamento de lançamentos e operações. DevSecOps é a prática de incorporar segurança aos aplicativos de software desenvolvidos e gerenciados por meio de processos de DevOps.

Como o DevSecOps pode ajudar a resolver problemas como a vulnerabilidade Log4j?

Primeiro, as melhores práticas do DevSecOps exigiriam que as equipes de desenvolvimento usassem versões atualizadas de componentes como o Log4j ao criar e gerenciar aplicativos.

Em segundo lugar, o DevSecOps também exigiria que as organizações de desenvolvimento e teste rastreassem as versões de todos os componentes, incluindo componentes de código aberto, usados em aplicativos. Dessa forma, se a comunidade de segurança de TI anunciar uma vulnerabilidade em um componente específico, a organização DevSecOps poderá determinar rapidamente quais de seus próprios aplicativos, se houver, são afetados.

Igualmente importante, as melhores práticas de DevSecOps exigiriam a incorporação de controles de segurança nos aplicativos, para que, quando, inevitavelmente, outra biblioteca ou componente de código aberto for considerado vulnerável, as equipes possam estar preparadas para conter qualquer ataques de dia zero contra essa vulnerabilidade de forma rápida e eficaz. Se as medidas defensivas já estiverem em vigor, a organização pode agir para se defender contra um ataque, mesmo que faltem dias ou semanas para a correção da vulnerabilidade.

Um dos melhores controles de segurança a serem incorporados é uma solução de segmentação Zero Trust que usa os firewalls integrados nos sistemas para aplicar políticas de segurança que limitam o tráfego de rede somente a usuários e processos autorizados. Ao reduzir drasticamente os caminhos de rede disponíveis para os invasores, a Segmentação Zero Trust aprisiona os atacantes, isolando-os nos poucos sistemas que eles poderiam inicialmente comprometer. Com a Segmentação Zero Trust implementada, os invasores não conseguiriam baixar e executar o código de um site malicioso.

Se um ataque for isolado na rede, os cibercriminosos não poderão espalhar o ransomware para outros sistemas. Eles não conseguem explorar furtivamente a rede em busca de dados valiosos para extrair. Eles estão presos no lugar como um ladrão infeliz que conseguiu entrar por uma clarabóia apenas para se encontrar em uma armadilha para ursos. Eles entraram, mas não vão a lugar nenhum. E um alarme foi soado.

A Illumio fornece a visibilidade e a automação que as equipes de DevSecOps precisam

Segmentação Illumio Zero Trust é uma solução de segurança valiosa para qualquer organização de DevSecOps, pois facilita que as equipes de desenvolvimento incorporem controles de segurança rigorosos aos aplicativos sem precisar aprender as complexidades das práticas de rede ou segurança.

O Illumio protege os aplicativos facilitando a definição de políticas de segmentação Zero Trust para desenvolvedores e equipes de segurança. Uma vez criadas, as organizações podem aplicar facilmente essas políticas usando o Illumio Node de fiscalização virtual (VEN) junto com os firewalls baseados em host já incorporados aos sistemas em que os aplicativos da organização estão sendo executados. O Illumio VEN é um cliente leve e à prova de falhas que pode ser facilmente incluído em compilações de software. Não são necessárias alterações extensivas no design.

A solução Illumio usa firewalls, mas poupa os desenvolvedores do trabalho de programar conjuntos complexos de regras de firewall. Em vez disso, permite que os desenvolvedores e a equipe de segurança definam as políticas que desejam aplicar, permitindo que somente o tráfego necessário passe por seus aplicativos e, em seguida, enviem essas políticas para os VENs incorporados aos aplicativos para aplicação.

As organizações de DevSecOps podem ajustar as políticas para vários aplicativos e ambientes. Especificamente, eles podem definir políticas com base em:

• Funções dentro do aplicativo
• O aplicativo em si
• O ambiente em que o aplicativo é executado, como desenvolvimento, teste ou produção
• A localização do ambiente: por exemplo, um ambiente de produção em um data center na costa oeste dos EUA

Em seguida, a equipe DevSecOps simplesmente adiciona um Illumio VEN a uma compilação de software. Uma vez executado no ambiente do aplicativo, o VEN impõe Políticas de Zero Trust, emite alertas ao detectar movimentos laterais suspeitos e reduz o tráfego em resposta a ataques ativos, isolando os endpoints infectados do resto da rede.

Illumio também oferece um Cliente C-VEN e serviço Kubelink para uso em ambientes conteinerizados, que são populares em arquiteturas de microsserviços. O C-VEN é um agente leve do Illumio, executado como um pod em cada nó em um cluster Kubernetes, que protege o nó e todos os pods em execução nele. Fornecido como um DaemonSet, o C-VEN aumenta e diminui a escala à medida que o cluster evolui. O Kubelink é um serviço da Illumio que monitora o servidor da API Kubernetes para aprender sobre os recursos dentro do cluster e fornecer o contexto do Kubernetes ao PCE. Ele é entregue como um pacote e requer apenas uma réplica por cluster, ajudando a tornar as soluções de contêiner da Illumio altamente escaláveis.

As equipes de DevSecOps têm duas maneiras de interagir com o Illumio PCE: por meio da interface de usuário do PCE ou de suas APIs REST bem documentadas. As equipes de DevSecOps podem usar as APIs para integrar o Illumio aos pipelines de CI/CD, para que a segmentação Zero Trust se torne uma parte padrão dos fluxos de trabalho do DevSecOps. As APIs também permitem que as equipes de segurança integrem o Illumio a outras ferramentas e fluxos de trabalho de segurança.

O pacote de produtos Illumio fornece segmentação Zero Trust sempre que aplicativos e serviços são implantados, incluindo endpoints em:

• Centros de dados: Núcleo Illumio
• Nuvens públicas, privadas ou híbridas: Illumio CloudSecure
• Dispositivos de endpoint: Illumio Edge

O Log4j não será o último componente de software que incluirá uma vulnerabilidade perigosa. Ao adotar práticas de DevSecOps e usar o Illumio para impor a segmentação Zero Trust em aplicativos em todos os lugares, as organizações podem estar prontas para proteger seus dados, aplicativos e pessoas enquanto o trabalho demorado de varredura de rede e busca de ameaças continua.

Para saber mais:

• Confira o resumo da solução, Illumio para DevSecOps.
• Entre em contato conosco para uma demonstração.