How to Detect and Respond to Log4Shell Exploits in AWS, Azure, GCP and OCI

A few things are becoming clear as we near the end of the first month of the Log4Shell vulnerability:

• Attacks and exploits are continuing with millions of attacks per hour and attributed to nation-backed as well as opportunistic hackers. And, a range of new attacks are emerging, from the primary attack on vulnerable Log4J servers to bitcoin mining and attacks on end-users. 
• The situation is far from solved with flaws found in the initial Log4J fixes and new severity 10 CVEs announced. 
• Finding and patching vulnerable systems is taking more time as organizations have these deployed in everything from production and compliant systems which might be easy to track down, while connected low priority systems, including dev and test systems, become vectors for lateral (east-west) movement. Also, patching is often not simple as teams have to factor in application compatibility and subsequent dependencies, maintenance windows, and application uptime. Finally, there may be further patch updates to roll out. 
• Speed of deploying active protections matters when there are 10s and 100s of affected applications in 100s of VPCs and cloud accounts across multiple clouds to deal with. A security solution that provides continuous cloud visibility and automated virtual patching of Log4J is crucial. If the security solution itself takes multiple days and many people with skills across networking, security, cloud, and automation then it has failed in the job of helping protect you. 
• Getting visibility and disrupting the entire kill chain is essential and not a nice to have. So far almost all security tools have primarily focussed on the inbound protections with single-point products. A more essential necessity and requirement is to layer both WAF and IPS with SSL/TLS decryption so that the attacks are actually inspected. And, it is imperative to protect with allow lists for known good sites (FQDN and IP) for outbound traffic, and automatically block all malicious site categories and IPs. 

Valtix is built to provide all these capabilities, to learn more see our LOG4J RESOURCE PAGE.

What’s Cloud-Native Detection and Incident Response?

Traditional incident response approaches will continue to be helpful for incident response (IR) and security operations center (SOC) teams in dealing with the attacks. Valtix supports forwarding of traffic and threat logs to traditional SIEM tools like syslog, Splunk, and DataDog. But these approaches need to evolve and adapt to what’s possible in public clouds and was not possible in traditional data centers. The following approaches can work well at scale across individual clouds (10s and 100s of VPCs across multiple accounts) and also across multiple clouds (AWS, Azure, GCP, OCI). 

• Tag-based Visibility and Attack Detection
  As your teams identify systems with vulnerable Log4J implementations, you can apply a cloud-native tag such as key=type; value=log4j. This can be manual or automated. Now you can identify traffic to the vulnerable workloads automatically and continuously, including egress flows to malicious or benign sites, and protect them with specific security policies. This requires that your security system can continuously discover your cloud assets in near real-time and at scale, across 10s and 100 of VPCs, cloud accounts, and across multiple clouds.

• Tag-based Quarantine and Remediation
  Vulnerable Log4J systems that are suspected of being exploited or under an actual attack should be tagged with a separate tag in AWS, Azure, or GCP, say key=type; value=log4j-quarantine. Now you can apply additional monitoring, separate security policies, and stricter egress filtering rules. 

• Automated PCAPs of Each Attack as it Happens, Live
  Instead of dealing with just traffic and threat logs, an even better approach is to automatically capture the packets of the entire session if an attack is detected. Now the IR and SOC teams can diagnose the attack instead of just wading through logs or constantly waiting for the attack to happen. This should happen automatically every time a WAF rule or an IPS rule is triggered, and the PCAPs should be stored in a cloud-native storage bucket (AWS S3, Azure storage container, or GCP storage buckets).

Get in Touch

Cloud is different and Valtix has substantial experience in the public cloud. We’re here to help through our MULTICLOUD RESPONSE PROGRAM.

Learn more about the program and our special LOG4J Free Tier Offer.