Continuing to Stay Ahead of CVE-2021-44228: Addressing Your Top Questions 

Since it was disclosed on Friday, December 11, I have spoken with many customers about CVE-2021-44228 and the ways Imperva is working to ensure that they are protected. Countless others have contacted us with questions about ways to mitigate the impact from the Log4j vulnerability. 

In the spirit of transparency and information sharing, we’ve aggregated below the most common questions we’ve received to date and the answers we’ve been providing to assist our customers through this time. 

This is a complex and evolving situation — one that takes partnership, diligence and patience. The global Imperva team is dedicated to helping you. We will continue to keep you informed with additional information as it becomes available.

Q: What is the state of Imperva’s Application Security product posture?

A: Imperva Cloud Web Application Firewall (WAF), Imperva WAF Gateway and Imperva RASP were not affected by CVE-2021-44228. All Application Security products have the ability to detect and block exploits targeting the CVE.

Q: Is Imperva implementing rule changes for the Imperva Cloud Web Application Firewall (WAF) to combat Apache Log4j2?

A: Absolutely. We’ve deployed a dozen security rule updates since CVE-2021-44228 was disclosed to help our customers mitigate new attack variants.

We saw initial attacks attempting to exploit this CVE starting around December 9, 2021 at 18:00 UTC. As said in our initial blog post, our existing security rules put in place for Imperva Cloud WAF customers mitigated these early CVE attacks without requiring any patching.  

Imperva Threat Research detected new CVE-specific attack variants, resulting in the creation of additional security rules on December 10, 2021 at 5:41 UTC. These updates were tested and deployed to the Imperva Global Network and ThreatRadar Feed on December 10, 2021 at 11:44 UTC. 

Over the last few days, we’ve detected new variants and responded by creating and deploying updated rules. Imperva Threat Research is continuing to monitor, create, test and deploy CVE-specific security rules based on new attack variants. 

Q: What rule changes are being implemented for Imperva WAF Gateway (GW) to combat Apache Log4j2?

A: After monitoring initial attacks attempting to exploit this CVE starting around December 9, 2021 at 18:00 UTC, Imperva Threat Research immediately began creating additional security rules for Imperva WAF GW. 

Manual rules were supplied to Imperva WAF GW customers to mitigate CVE-specific attacks. An Imperva Documentation knowledge base article (login required) contains the signature information for creating the specific rule. This document was updated as of December 13, 2021 15:30 UTC.

Customers that have Threat Radar Emergency Feed Services received an initial update with these CVE-specific rules on December 10, 2021 11:30 UTC. As new variants were discovered, updated rules were published to Threat Radar on December 11, 2021 10:30 UTC, December 11, 2021 3:30 UTC and December 13, 2021 12:20 UTC.

Customers using Imperva Application Delivery Controller (ADC) were able to receive an update on December 13, 2021 at 10:00 UTC. ADC content can be updated manually or automatically. For information about configuring ADC, please visit the ADC Update Guide.

Just like for Cloud WAF, Imperva Threat Research is continuing to monitor, create, test and deploy CVE-specific security rules for WAF GW based on new attack variants. 

Q: For both Imperva Cloud WAF and Imperva WAF GW, where can I see if I am getting hit by traffic related to this Remote Code Execution (RCE) exploit? Is there a dashboard to help me?

A: Imperva Cloud WAF customers can see the CVE’s activity in Imperva Attack Analytics (screenshot below).

Attack Analytics v2

Incidents in Imperva Attack Analytics can be filtered by this specific CVE (screenshot below).

image 39 2

Once Imperva WAF GW customers establish the appropriate signatures (manually, via Threat Radar or via ADC), they will be able to see alerts and block events within the MX or within their SIEM, where log events are ingested. The default logging templates should include signature names and events like “CVE-2021-44228: Zero day RCE in Log4j2 via LDAP JNDI parser”.

Q: If I have Imperva RASP deployed across my Java applications, am I protected?

A: Yes. Given the nature of how Imperva RASP works, RCEs caused by CVE-2021-44228 were stopped without requiring any code changes or policy updates (additional details below). Applications of all kinds (active, legacy, third-party, APIs, etc.) are protected if Imperva RASP is currently deployed.

Q: What types of vulnerabilities does Imperva RASP protect out of the box?

A: Imperva RASP is complementary to Imperva WAF. While the latter keeps bad traffic out, RASP mitigates the risk posed by unknown exploits in first or third-party code/dependencies. By being embedded in the application, RASP has direct visibility into attacks relating to a RCE, which is an advantage for detecting and stopping a specific class of attack.

Q: Where can I learn more about Imperva RASP? 

A: Imperva RASP is an industry-leading product that is designed to protect against zero-days and the OWASP Top 10 application security threats, injections and weaknesses. Learn more here.

Q: Is the Log4j vulnerability impacting any of Imperva’s corporate systems (including customer/partner portals and FTP)?

A: No. Imperva worked quickly to update all vulnerable systems immediately after becoming aware of CVE-2021-44228, including third-party vendor solutions. Additionally, Imperva does not have any corporate external systems that are affected by this specific CVE.

Q: I need assistance or have questions. Who should I contact?

A: For customers looking for support, please access the Imperva Support Portal. If you’re looking for protection from CVE-2021-44228, please contact us.

The post Continuing to Stay Ahead of CVE-2021-44228: Addressing Your Top Questions  appeared first on Blog.

*** This is a Security Bloggers Network syndicated blog from Blog authored by Kunal Anand. Read the original post at:

Secure Guardrails