A falha Apache Log4j coloca software de terceiros em evidência

Enquanto as organizações ao redor do mundo lutam para resolver a vulnerabilidade crítica do Log4j, conhecida como Log4Shell, a pergunta número um na mente de todo líder de segurança é: "Como posso saber se fui afetado?".

A onipresença do Apache Log4j, uma estrutura de criação de log de código aberto, torna essa questão particularmente desafiadora de responder.

Muitas organizações não usam apenas o Log4j em seu próprio código-fonte, mas ele também é usado em muitos dos produtos que essas organizações adquirem de terceiros. As organizações que adotaram a abordagem de “teste antecipado” (shift left) para seu ciclo de vida de desenvolvimento de software seguro (SSDL) podem analisar seu próprio código-fonte para encontrar e corrigir a falha em seus sistemas.

É necessária uma abordagem SSDL que inclua teste de segurança de aplicativo estático (SAST), teste de segurança de aplicativo dinâmico (DAST), verificação de dependência de terceiros, verificação de segurança de contêiner, gerenciamento de vulnerabilidade e infraestrutura como código (IaC). Contudo, mesmo com todas essas práticas em vigor, as organizações ainda terão dificuldade em capturar tudo que está em perigo. O gerenciamento de vulnerabilidades e a verificação de aplicativos da Web também são cruciais, especialmente quando se trata de software de terceiros. Não é suficiente descobrir se a falha existe ou não, pois você também precisa ter uma compreensão do nível de risco que ela representa no contexto da combinação de aplicações, ativos e processos de negócios da sua organização.

Embora a recente ordem executiva da administração Biden exija que as organizações desenvolvam uma lista de materiais de software (SBOM), a maioria dos fornecedores não fornece SBOMs para seu software. E, mesmo que o fizesse, a maioria das organizações não teria os processos e os recursos em vigor para fazer uso eficaz delas. Portanto, quando ocorre um incidente como o log4j, os líderes de segurança cibernética ficam com uma única opção: ligar para seus fornecedores terceirizados e perguntar a eles. Isso é difícil, redundante e demorado, deixando as organizações à deriva enquanto os invasores correm para explorar a falha.

Apenas as perguntas frequentes: CVE-2021-45046, CVE-2021-4104: Frequently Asked Questions About Log4Shell and Associated Vulnerabilities.

Mesmo nas organizações mais maduras, onde as práticas de SSDL e SBOMs estão arraigadas nos processos, permanecem lacunas que tornam um desafio para as organizações de segurança responder a estas cinco questões cruciais:

1. Nós executamos isso em nossos ambientes?
2. E na nossa infraestrutura?
3. E em nossos próprios pipelines de construção? ‘
4. E os provedores de nossa infraestrutura? Este ponto é especialmente pertinente se você estiver usando serviços de provedor de serviços em nuvem.
5. Como a análise de composição de software (SCA) não descobre todas as instâncias do Log4J, executamos outros controles, como Infraestrutura como Código (IaC), gerenciamento de vulnerabilidade e verificação de aplicações Web, em todos os componentes do nosso código?

A questão é a seguinte: não existe uma solução fácil para o Log4j. Uma opção óbvia — implementar um firewall de aplicação Web — já se mostrou bastante fácil de contornar. Uma organização responsável precisa fazer o trabalho de atualização de seu software principal e entender como essa falha afeta o perfil de risco geral. As organizações que estão respondendo agora estão tomando decisões em modo de crise; assim que a crise inicial tenha passado, a tentação será declarar “missão cumprida” e encerrar. Em nossa opinião, esse é um erro catastrófico. Já passou da hora de as organizações fazerem o trabalho árduo de consertar sua infraestrutura e manter seus sistemas com uma abordagem de segurança em primeiro lugar.

Nós, da Tenable, estamos comprometidos com o SSDL e estamos tomando as seguintes ações em resposta ao Log4j:

• Temos portas de bloqueio e, neste caso, estamos bloqueando o uso de quaisquer instâncias vulneráveis ​​de software, para incluir Log4j. 
• Realizamos ativa e constantemente verificações de gerenciamento de vulnerabilidade e verificações de aplicações Web em toda a nossa infraestrutura e código de produto de pré-lançamento antes de enviar aos clientes.
• Além disso, acionamos todos os indicadores de comprometimento e ataque e implementamos controles nos níveis de rede e host.

Continuaremos monitorando a threat intel para rastrear o cenário de ameaças e fazer ajustes conforme necessário. No final das contas, responder a qualquer incidente é saber o que está em seu ambiente, conhecer sua superfície de ataque, incluindo todos os terceiros, e reduzir o risco rapidamente. O tempo é essencial. Os adversários estão sempre prontos para atacar as vulnerabilidades mais recentes e reaproveitá-las para seus próprios casos de uso. As organizações devem fazer tudo o que puderem para examinar com atenção suas práticas agora, visto que os efeitos em cascata desse incidente afetarão o software empresarial por muitos anos.

Saiba mais

• Acesse a Central de Soluções da Tenable para Log4j: https://www.tenable.com/log4j
• Leia o alerta da SRT: CVE-2021-44228: prova de conceito para vulnerabilidade crítica de execução remota de código do Apache Log4j disponível (Log4Shell)
• Leia as perguntas frequentes: CVE-2021-44228, CVE-2021-45046, CVE-2021-4104: Frequently Asked Questions About Log4Shell and Associated Vulnerabilities
• Leia a perspectiva do CTO: Apache Log4j Flaw: A Fukushima Moment for the Cybersecurity Industry
• Acesse nossa comunidade de usuários para saber mais sobre como a Tenable pode ajudar: https://community.tenable.com/s/