The Challenge

Executive management at a financial services company is asking the security team how it is handling the Log4j vulnerability with respect to the supply chain, but the team has too many vendors to ask everyone how it is doing (and how badly they are affected), especially since the team is swamped with its own remediation. Specifically, the team asks:

• How can we reduce the load of securing our supply chain around Log4j?
• Can IANS provide a questionnaire to save time?
• What should we communicate to executives when asked about supply chain security and Log4j?

Josh More: The answer is you don’t (mostly). There is inherent risk in outsourcing. This is a classic example. You don’t ask the vendors, because they don’t know yet. As they find out how bad things are, they’re fixing things. Asking the vendor these questions actually increases your risk, because the vendor must devote resources to answering all the questions, instead of addressing the issue. (Yes, there could be different resources assigned to the tasks, but it’s still not a productive use of time.)

Do your due diligence by listing your vendors and tracking their public statements on the issue. Start with the public trackers that are collecting detail for the major vendors. Then go through the remaining vendors and identify which ones—if this issue were exploited—would cause serious harm to your organization. Search those vendors’ websites and emails for statements. If there are any left, reach out to just your contacts at those vendors and ask for a statement by the end of the week on how their risk level impacts you.

That’s all you need to do vendor-wise, because doing anything else just consumes your resources and theirs and won't change the situation in any substantial way. After all, if you have a vendor that isn’t going to address this unless and until you bug them about it, that’s not a vendor you need to fix. That’s a vendor you need to fire.

Josh Marpet: Software bills of material (SBOMs). This is a longer-term answer, but SBOMs will give you an easily searchable list of who is affected in your supply chain.

This is such a difficult topic. Organizations should concentrate on performing an asset inventory, making sure everything on the inventory is patched to current, and do egress traffic monitoring to check to see if Log4Shell is trying to grab code from an external repository. Then ask your partner organizations if they are doing these things.

Anand Singh: Start with high and critical vendors. Reach out with a basic questionnaire:

• Are you impacted by CVE-2021-44228?
• Have you completed patching any affected environments?
• Do you contract with vendors that use the affected Apache Log4j utility?
• Are you reaching out to the vendors to understand any direct or indirect impacts/results from the vulnerability?
• Have you discovered any impacts of the vulnerability in your environment, including any active exploits?
• If you have been impacted, what has been your remedial action?

Once you have received the responses, you can do follow-ups on the basis of the received input. The absence of a response should be considered a flag worthy of pursuing.

Kevin Johnson: One good thing to do is to actually focus on “testing” the systems themselves. Don’t try to exploit the flaw, but look for all the systems—yours and your vendors’—to find which systems appear to be running Java.

Any views or opinions presented in this document are solely those of the Faculty and do not necessarily represent the views and opinions of IANS. Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our written reports, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by the client in connection with such information, opinions, or advice.