Security leaders are still dealing with the impact of Log4Shell, and cloud security leaders are changing the way they secure cloud workloads in the aftermath of Log4Shell. New Valtix research reveals that 95% of cybersecurity leaders say Log4Shell was a wake-up call for cloud security, changing it permanently, and that 87% feel less confident about their cloud security now than they did before the incident. 


Log4Shell was a significant zero-day vulnerability in the Log4J developer library that posed a critical risk to too much of the internet. Even three months after the incident, the research found that 77% of IT leaders are still dealing with Log4J patching, with 83% stating that Log4Shell has impacted their ability to address business needs.


For organizations that don’t have a solid understanding of their exposed attack surface, moving to a cloud environment can create critical gaps in security visibility — further emphasizing that lack of knowledge, explains Matthew Warner, CTO and Co-Founder at Blumira. “Log4Shell was a reminder for IT professionals that it’s important to not only understand your attack surface from a port-exposure perspective, but also the actual applications used.”

  

Despite better tools and knowledge, 78% of IT leaders still lack clear visibility into what’s currently happening in their cloud environment:

  • 82% say visibility into active security threats in the cloud is usually obscured.
  • 86% agree it’s more challenging to secure workloads in a public cloud than in an on-prem data center.
  • Only 53% feel confident that all of their public cloud workloads and APIs are fully secured against attacks from the internet.


Both on the researcher and defender side, Casey Ellis, Founder and CTO at Bugcrowd, says Log4J pushed security leaders to defend against a widespread, pervasive vulnerability to its limit. Bugcrowd, for instance, saw a ton of activity starting with the release of the Log4Shell POC, and this activity continued until it mysteriously dropped around January 2nd or 3rd.

“When we looked into this, it wasn’t necessarily because there was nothing left to patch and nothing left to hack,” Ellis explains. “Most often, it was literally because everyone was looking forward to their Christmas and New Year break, and had been denied it by the Log4J vulnerability announcements. Bug hunters and security managers alike were weighing the cost of pushing just a little further against the practical importance of sanity and capacity to ‘fight another day.’”


“Following least-access practices, treating your cloud architecture like a sensitive component of on-prem, and utilizing cloud features to support your security needs will help,” Warner says, “but you must also know how your environment is built and what the attack surface is to stay ahead of ongoing threats.”


A complimentary copy of the full report can be downloaded here.