Latest Analyst Report: The 2023 Gartner® Market Guide for Supplier Risk Management Solutions

Log4j Vulnerability: 8 Questions to Ask Your Vendors

Use this free questionnaire to determine your organization’s third-party risk exposure to the Apache Log4j vulnerability. Then, follow these best practices to accelerate future incident response.
By:
Scott Lang
,
VP, Product Marketing
December 13, 2021
Share:
Blog log4j vulnerability 1221

On December 9, 2021, security researchers announced a zero-day vulnerability, CVE-2021-44228, impacting the widely-used Apache Log4j Java-based logging library. Known as Log4Shell, the vulnerability can allow unauthenticated remote code execution and access to servers – in effect, a complete takeover of vulnerable systems.

Log4j is used in many cloud platforms, web applications and email services, meaning that there is a wide range of systems that could be at risk from the vulnerability. GitHub has published a list of vulnerable applications and systems, and security researchers report that cyber attackers are already making hundreds of thousands of attempts to exploit the vulnerability every minute.

Because it is deployed in millions of Java-based web applications worldwide, it is important for organizations to determine not only their internal attack surface, but also the risk they face from vulnerable third parties.

8 Questions to Immediately Determine Your Third-Party Exposure to Log4Shell

Prevalent has curated an 8-question assessment that can be leveraged to rapidly identify any potential impacts to your business by determining which of your third parties utilize Log4j in their applications, and what their mitigation plans are.

Questions Potential Responses

1) Has the organization identified whether it is impacted by the recent Apache Remote Code Execution (RCE) vulnerability on its Log4j utility program?

Help text: This question relates to the recent remote code execution (RCE) vulnerability (CVE-2021-44228) affecting the Apache Log4j utility program, on versions 2.0-beta9 to 2.14.1

Please select ONE of the following:

a) The organization has reviewed and identified that it is impacted by the recent Apache Remote Code Execution Vulnerability.

b) The organization has reviewed and identified that it is not impacted by the recent Apache Remote Code Execution Vulnerability.

2) Has the organization managed to update to Log4j 2.15.0 as recommended?

Please select ONE of the following:

a) Yes, the organization has managed to update the program to the latest 2.15.0 version.

b) The organization is unable to update to the latest Log4j version.

c) The organization has not yet updated the program to the latest 2.15.0 version.

3) Which version of the Log4j program does the organization currently run?

Please select ONE of the following:

a) The organization uses a release >=2.7 and <=2.14.1

b) The organization uses a release >=2.0-beta9 and <=2.10.0 (proceed to question 5)

4) If your current release of Apache Log4j is >=2.7 and <=2.14.1, and your organization has not updated to the latest version, then have the following actions been taken?

Help text: Apache have released these recommended actions to address the RCE vulnerability. Actions recommended are based on the version being used.

Please select ALL that apply:

a) For mitigation, the organization has set either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.

b) All PatternLayout patterns have been modified to specify the message converter as %m{nolookups} instead of just %m.

5) If your current release of Apache Log4j is >=2.0-beta9 and <=2.10.0, and your organization has not updated to the latest version, then have the following actions been taken?

Help text: Apache have released these recommended actions to address the RCE vulnerability. Actions recommended are based on the version being used.

Please select ALL that apply:

a) For mitigation, the organization has set either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.

b) The JndiLookup class has been removed from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

6) Has the cyber-attack affected critical applications delivered to or used to support client services?

Help text: Consideration should be given where client systems, or those holding client information are using the Log4j utility program.

Please select ONE of the following:

a) Yes, the vulnerability has affected applications delivered to, or used to support client services.

b) No, the vulnerability has not affected applications delivered to, or used to support client services.

7) Does the organization have an incident investigation and response plan in place?

Help text: Procedures for monitoring, detecting, analyzing and reporting of information security events and incidents should be in place, and allow an organization to develop a clear response strategy to handling identified incidents and events.

Please select ALL that apply:

a) The organization has a documented incident management policy.

b) The incident management policy includes rules for reporting information security events and weaknesses.

c) An incident response plan is developed as part of incident investigation and recovery.

d) Incident response planning includes escalation procedures to internal parties, and communication procedures to clients.

8) Who is designated as the point of contact who can answer additional queries?

Please state the key contact for managing information and cybersecurity incidents.

Name:

Title:

Email:

Phone:

9 Steps to a Third-Party Incident Response Plan

When one of your critical vendors is breached, being ready with a prescriptive incident response plan is essential to preventing your company from becoming the next victim.

Read Now
White paper incident response 0421

5 Best Practices to Accelerate Third-Party Incident Response

Prevalent recommends a comprehensive 5-step third-party risk management approach to be more proactive in determining future third-party vulnerability exposure.

1. Inventory third-party technology

The first step to discovering your exposure to a third-party vulnerability is to determine which vendors use what technologies. Whether determined passively through external scanning or actively via a dedicated internal assessment, the results should enable your organization to automatically create entity relationship maps by 4th party technology. With this capability, you can more clearly visualize technology concentration risk among your third parties, and quickly identify which vendors might be at risk in a security incident such as Log4Shell.

2. Issue targeted assessments to vulnerable third parties

The next step is to issue a dedicated risk assessment questionnaire to potentially vulnerable third parties. However, because of the complexity of most security incidents and the speed required to respond, you certainly don’t want to use a spreadsheet to collect this due diligence.

Instead, leverage a platform that automates the collection of third-party responses to a standard questionnaire, centralizes results in a single risk register, and provides easy-to-read reporting that shows which vendors are vulnerable and the status of their remediation plans.

3. Validate assessment results with external scanning

Considering the severity of the Log4Shell vulnerability and the consequences of a potential business disruption to you vendors, it is essential to validate results of the risk assessment by comparing vendor responses to externally observable risks such as possible malware in a vendor’s company IT infrastructure, or public-facing misconfigurations and other web vulnerabilities. This can be accomplished by correlating assessment findings with cyber scanning results in a single risk register that adds context to findings. The alternative is a labor-intensive manual scan of vulnerability databases – and you don’t have time for that!

4. Remediate and report

Once you have collected, analyzed and correlated vendor assessment responses, triage results to focus on those vendors with the highest-priority impact to your organization. The best third-party risk management solutions will offer vendor tiering to better understand which vendor is most critical; built-in remediation guidance for vendors; and regulatory and security framework-specific reporting templates to simplify the inevitable auditor request.

5. Continuously monitor for security incidents

Maintain a continuous feed of security incident news and updates. Look for an automated solution to accomplish this, since simply watching vendor RSS feeds or news sites will never provide the depth or context required to be more proactive in your response. Good data breach monitoring solutions include types and quantities of stolen data, compliance and regulatory issues, and real-time vendor data breach notifications.

Prevalent Can Help Accelerate Third-Party Incident Response

The Prevalent Third-Party Incident Response Service, is a solution that helps to rapidly identify and mitigate the impact of third party security incidents like Log4Shell by providing a platform to centrally manage vendors, conduct targeted event-specific assessments, score identified risks, and access remediation guidance. Prevalent offers this solution as a managed service to enable your team to offload the collection of critical response data so they can focus on remediating risks and accelerating response to mitigate potential disruptions.

Next Steps to Address the Log4j Vulnerability

Use this questionnaire to determine the impact the Log4Shell vulnerability could have on your supplier ecosystem. Then, learn more about how Prevalent can help by downloading a best practices white paper or contact us for a demo!

Note to Prevalent customers: We are updating the Prevalent platform to include the above questionnaire. Prevalent’s cybersecurity team has kicked off an internal review of systems, applications, and suppliers over the weekend to assess potential vulnerabilities, and track mitigation and remediation steps. We’ll be providing details and advisories to our customers as the investigation continues. Please visit our customer support portal or contact your customer success manager for more details.

Tags:
Share:
Leadership scott lang
Scott Lang
VP, Product Marketing

Scott Lang has 25 years of experience in security, currently guiding the product marketing strategy for Prevalent’s third-party risk management solutions where he is responsible for product content, launches, messaging and enablement. Prior to joining Prevalent, Scott was senior director of product marketing at privileged access management leader BeyondTrust, and before that director of security solution marketing at Dell, formerly Quest Software.

  • Ready for a demo?
  • Schedule a free personalized solution demonstration to see if Prevalent is a fit for you.
  • Request a Demo