Security Teams Still Struggling to Patch Log4Shell
A survey of 200 cloud security leaders published today by Valtix, a provider of a network security-as-a-service platform, finds more than three-quarters of respondents (77%) said they are still working toward patching all the instances of the open source Log4j log management tool for Java applications that were deployed.
Slightly more (78%) said they still lack clear visibility into what’s currently happening in their cloud environment, while a full 83% said patching Log4j has impacted their ability to address business needs. The survey found 95% of respondents view the zero-day Log4Shell vulnerability as a wake-up call, with 87% reporting they feel less confident about their cloud security now than they did prior to the incident. Only 53% said they feel confident that all their public cloud workloads and application programming interfaces (APIs) are fully secure.
Valtix CEO Doug Murray said that while patching Log4J remains a major challenge, it’s clear that there is now a greater appreciation for the importance of cloud security in the wake of the crisis because many of the instances of Log4j are being found on cloud platforms.
Overall, the survey found 86% of respondents view securing workloads in a public cloud to be more challenging than in an on-premises IT environment, with 82% acknowledging that visibility into active security threats in the cloud is usually obscured.
A total of 79% also said agent-based security solutions are difficult to operationalize in the cloud. A total of 88% also said bringing network security appliances to the cloud is challenging.
Murray said the survey results make it clear there is now a much greater appreciation for the fundamental differences in securing a cloud compared to securing an on-premises IT environment, an issue that only becomes more challenging as additional cloud platforms are added. Patching an application after a vulnerability is discovered is not enough to ensure cloud application security, he noted.
At the root of any cloud security challenge is the rate at which applications are now being built and deployed. Developers that have little to no cloud expertise today routinely provision cloud infrastructure. The chances those developers will make a security mistake are high. Cloud service providers are only responsible for securing their infrastructure. It’s up to each organization to both securely configure that infrastructure and remediate any vulnerabilities that might be lurking within an application workload. The security frameworks employed also need to be able to scale up and down alongside those cloud workloads. Finally, new classes of so-called cloud-native applications built using containers are being deployed alongside monolithic applications. That creates two distinct sets of application security requirements because containers are an entirely different type of software artifact.
In theory, more responsibility for securing cloud applications is shifting left toward application development teams but it may take years for developers to master the best DevSecOps practices required to achieve that goal. In the meantime, like it or not, it’s still the responsibility of security teams to make sure that the overall application environment is secure and any vulnerabilities discovered are patched in a timely manner.
