0
0
“Instâncias vulneráveis do Log4j permanecerão nos sistemas por muitos anos, talvez uma década ou mais”, concluiu o Conselho de Revisão de Segurança Cibernética (CSRB).
Exploração Log4j: Risco e efeitos dos esforços de remediação
O relatório se concentra no Log4Shell e em outras vulnerabilidades que foram descobertas (e exploradas) no ano passado na biblioteca Log4j de código aberto.
Embora os fornecedores de segurança cibernética continuem a sinalizar ataques envolvendo a exploração do Log4Shell, “o Conselho também descobriu que, até o momento, de um modo geral, a exploração do Log4j ocorreu em níveis mais baixos do que muitos especialistas previram, dada a gravidade da vulnerabilidade”.
Anteriormente, a cyber MGA At-Bay chegou a uma conclusão semelhante, principalmente porque outras vulnerabilidades críticas ainda apresentam uma opção melhor para ataque.
O esforço pelos defensores das organizações para encontrar e corrigir instâncias vulneráveis do Log4j foi considerável, mas afetou sua prontidão para a segurança cibernética (e os planos de férias de dezembro dos defensores).
“O fato de não haver uma ‘lista de clientes’ abrangente para o Log4j, ou mesmo uma lista de onde ele está integrado como um subsistema, dificultou o progresso do defensor. Empresas e fornecedores se esforçaram para descobrir onde usaram o Log4j. O ritmo, a pressão e a publicidade agravaram os desafios defensivos: os pesquisadores de segurança encontraram rapidamente vulnerabilidades adicionais no Log4j, contribuindo para a confusão e a “fadiga de correção”; os defensores lutaram para distinguir a varredura de vulnerabilidades por pesquisadores de boa-fé dos atores de ameaças; e os socorristas tiveram dificuldade em encontrar fontes de informação autorizadas sobre Isso culminou em uma das respostas mais intensivas da comunidade de segurança cibernética da história”, observou o Conselho.
Lições aprendidas
O CSRB, que reúne líderes do governo e do setor, foi criado para “revisar e avaliar eventos significativos de segurança cibernética para que o governo, a indústria e a comunidade de segurança em geral possam proteger melhor as redes e a infraestrutura [dos EUA”.
A análise da CSRB de todo o evento Log4j permitiu que eles formulassem recomendações para várias partes interessadas do governo e do setor privado para:
- Abordando o risco contínuo de exploração do Log4j
- Melhorando o gerenciamento de vulnerabilidades e a higiene da segurança
- Construindo um ecossistema de software melhor, e
- Faça as mudanças culturais e tecnológicas necessárias para melhorar a segurança digital dos EUA a longo prazo
A CEO da Luta Security, Katie Moussouris, líder em segurança cibernética e membro do CSRB, resumiu as lições que organizações, fabricantes de software e mantenedores de código aberto podem aprender com este relatório. Em tópicos, ela também ofereceu sua opinião sobre o efeito adverso da divulgação precoce de vulnerabilidade exigida pelo governo no processo coordenado de divulgação de vulnerabilidades.
“O relatório está repleto de informações e ideias específicas sobre o que pode ser feito para prevenir ou mitigar o próximo Log4j, mas talvez a conclusão mais importante seja que o Conselho conclui que o Log4j poderia ter sido evitado – e isso é verdade -“, disse Dan Lorenc, cofundador e CEO da Chainguard, à Help Net Security.
“Impedir que outro Log4j ocorra é possível, mas exigirá uma mudança fundamental em várias áreas críticas por muitos, incluindo uma abordagem coletiva para apoiar a comunidade de código aberto por meio de recursos e definição de padrões de segurança em todo o setor e maior foco das organizações dos setores público e privados para incorporar segurança em seu processo de desenvolvimento de software e definir como elas avaliam o risco no gerenciamento
Mas a boa notícia é que estão sendo feitos progressos.
“Há um movimento da indústria em direção à construção de ‘pontos de verificação’ e ferramentas de segurança no processo de desenvolvimento de software, muitas vezes referidos como ‘segurança por padrão’. O relatório da CSRB chama essa direção e pede à comunidade de código aberto e às empresas comerciais que priorizem essas práticas. Acreditamos que este é o futuro da segurança de software e que os desenvolvedores e mantenedores colherão os benefícios de mais tempo para construir e inovar, enquanto as empresas economizarão enormes custos na mitigação e na aquisição de ferramentas”, acrescentou.
FONTE: HELPNET SECURITY