Dec 23, 2021
Have you and your security team been working weekends and long days to remediate Log4j2 vulnerabilities? With new Log4j vulnerabilities being announced every few days, the situation can feel overwhelming, to say the least.
To help with immediate remediation efforts, we wrote a blog on how to detect Log4j vulnerabilities on AWS, Azure, and Google Cloud, which we are updating as soon as new developments occur. In addition, we compiled a 10-step Log4j Cloud Remediation Checklist that you can share with your security team to make sure you’ve covered all your bases.
Although no one would wish for this type of vulnerability to occur, especially not so close to the holidays, now that it’s here, we can try to use it as a learning experience. Crises often provide an opportunity to make the changes that have been needed for a long time but lacked immediate urgency. I bet that your executive board members are now suddenly much more willing to listen to your suggested improvements.
To help you manage your Log4Shell response efforts and prepare for other serious vulnerability crises, we asked 8 cybersecurity leaders: “What advice would you give to organizations on how to respond to Log4j?”. Their responses are listed below.
“With new Log4j vulnerabilities being announced at an alarming rate, it is becoming clear that this isn’t going to end soon. Companies can get ahead of the curve by having full visibility into their environments. If you don’t know which workloads you have, down to the level of their installed applications and libraries, you cannot ensure their safety. Log4j is just another example of why you need to have continuous visibility into what’s in your environment. This enables you to quickly remediate issues and triage new critical CVEs, even before a patch is released.”
“When responding to situations such as the Log4j vulnerability, it is critical to have complete coverage and insight into your cloud applications and workloads. The ability to quickly gain a thorough understanding of which VMs, containers and serverless functions need to be fixed, and in what order, makes all the difference when responding to emergency situations. This type of speed and full visibility can really only be attained with an agentless cloud security solution. In the last week, Orca Security has had many organizations literally onboarding thousands of cloud accounts with hundreds of thousands of instances. I cannot even imagine how organizations could ever have gained this visibility if they needed to install an agent for each workload.”
“When you’re dealing with patching systems, be aware that you might have to patch twice. Or even thrice – we’ve already seen multiple revisions, as 2.15 and 2.16 still had issues. This doesn’t mean you should just wait until everything settles down to start patching; but be aware that sometimes, multiple rounds of patching might be necessary.
This is also a good opportunity to end-of-life some systems. If you find workloads that aren’t really useful, and it feels like the cost to patch them isn’t worth it, then why do you have the system? The cost to your incident response process to deal with those systems is a cost you should make sure you never have to bear again.
“Internet-facing” isn’t really the only filter for high-priority patching. Even business intelligence databases can create exposures, if URL parameters are stored where they might be processed by vulnerable internal systems. Tracking systems that use invisible pixels are certainly targets you need to think about and understand whether you or one of your vendors is vulnerable.”
“The Log4j vulnerability demonstrates the impact and far reach of misconfigured open source code because Log4j use is so widespread; The open source Java library is in use across so many websites and products that it is likely to take months to recover in order to update all the platforms and devices that are vulnerable to attack. The good news is that there is a patch that can be applied immediately to remediate the issue. However, it can be challenging and take a lot of manual effort to find the instances and usage of Log4j to apply the patch. The other approach to mitigate risk if systems cannot be patched is to isolate them from the internet so that an attacker cannot get to them. Organizations should also be monitoring logs for exploitation attempts. This is a time when your security solutions and related vendors can help you quickly act to reduce the manual labor and time involved in the above.”
“If your organization struggles with inventory, then issues like Log4j will expose this challenge for everyone to see. You simply cannot do vulnerability management properly without a good solid understanding of your assets – and this includes your data, applications, systems, services, and other infrastructure elements, along with the appropriate metadata required to drill down into how these assets are configured. This is not easy – but it is the essence of world-class enterprise security. Without proper inventory, you are exposed.”
“With new lists on how to remediate all of the Log4j vulnerabilities, CISOs and security leaders are looking to get off the treadmill of panic and move “left of (the next) bang”. To do this, you need to have a clearly defined strategy for handling new threats for identifying, protecting, detecting, and responding to threats. Since patches aren’t instant, it will take time for you to uncover their dependencies and any unintended consequences they may have, as well as their cumulative effect on business goals. The relationships you have cultivated, coupled with strong communication will bridge this gap. Make sure your peers and stakeholders know the status, next steps, expectations, results of testing, and when you release to production. Not only are you recovering the application’s uptime but your stakeholders’ business.”
“We wrote a piece for Dark Reading with high level lessons.
The advice to highlight now as we’re well into dealing with the issue, is to prepare for a potentially significant increase in incident response activity: multiple adversaries have already incorporated Log4j exploitation into their kits. For senior IT executives, this means supporting your security teams, both in terms of resources to address the demands now, as well as support for future projects to help implement more robust security architectures. For security teams, it means continuing to triage where the flaw may exist, even if it is many layers inside the organization, with paying additional attention to alerts that may indicate potential compromise or lateral movement.
As we look beyond the immediate triage and response, this crisis highlights the need for more robust software supply chain pipelines and for more resilient systems overall. The Omdia Dark Reading article discusses high level lessons and touches on key points such as proper inventory (particularly on cloud assets, which can be created or modified easily via APIs), least privilege, and more.
Importantly, we keep mentioning: many times it’s not security teams that need to hear this, but others in the organization. The true meaning of “security is everyone’s responsibility” goes well beyond individual actions by employees.”
Orca Security offers a radical new, agentless cloud-native application protection platform (CNAPP) that detects and prioritizes security risks at every layer of your AWS, Azure, and Google Cloud estates providing 100% visibility – in a fraction of the time and operational costs of other solutions.
Discover Your Log4j2 Vulnerabilities In Minutes
Scan your entire AWS, Azure, and Google Cloud environments for Log4Shell vulnerabilities with Orca Security’s free, no obligation risk assessment.