What does the Log4j/Log4Shell vulnerability mean for your company?

This vulnerability is particularly critical because Log4j is widely used in open source and commercial software and remote exploitation of the vulnerability against any internet-facing server is trivial using a single HTTP post. Exploitation results in full system compromise. The vulnerability has a CVSS Score of 10 out of a possible 10 meaning it is as bad as it gets.

Our SOC has launched a new app that detects the presence of vulnerable versions of Log4j however, detecting it does not mean you have been exploited.

My advice: Scan your network to get a full visibility report i.e. find all your legacy and shadow IT that you didn't know existed which means you should find all potential instances of Log4j, patch all of the Log4J environments, monitor your systems 24/7 using your SOC and if you don't have a SOC invest in a Managed SOC provider. 

Yet another chance to test our incident response procedures. 

So far I would say we're a B. Good on the process, and an A on team response and interactions and reducing threat risk were about a B. 

ID'g your external assets exposed to this vulnerability is your teams' #1 priority and mitigate or patch (if available) the threat. 

You also have to notify and communicate with any 3rd party to make sure they're aware so they can start the same process. You ALSO need to be fully aware of your vendors' weaknesses and defenses (mitigations, patches, knowledge and reaction time). 

Then be prepared to roll out patches or in this case shut systems down OR put mitigations in place immediately to mitigate risk to the entire environment.

One excellent opportunity for the company to test your CMDB/Inventory (at medium and big companies). 

Tenable, and I think, other Vulnerability Scanners offer a specific plugin used to check your infrastructure against Log4shell. 

If you don't have VS, you can try looking at your logging system for evidence or use:

- https://buff.ly/3lYZRh0
- https://gist.github.com/SwitHa...

In the future, Patch Mgmt pre-defined and applied schedules need to be first (proactive) from scanners/vulns. (reactive).

WhiteSource has released a utility to detect log4j vulnerability in the codebase. 

Take a look at this if it helps. In our case, a lot of projects use Elastic Search and Azure DevOps Server - both of them have log4j being used and that's where additional fixes have to be done.

https://github.com/whitesource/log4j-detect-distribution

Hello @Jangsun KIM, @Cuneyt KALPAKOGLU Phd. , @reviewer1572348, @Nachu Subramanian, @Letsogile-Baloi, @Nagaraj Sheshachalam, @Nadeem Syed, @reviewer1362132, @Chiheb Chebbi ​and @Abbasi Poonawala,

Can you please join this discussion and share your advice with the community?

Thank you!