If you're neck-deep in Log4Shell remediation and wanting the assurance of an automated process to ensure your hosts are patched and stay patched, the following approach may be helpful to you.

Identify Vulnerable Hosts

We found that ossie-git/log4shell_sentinel is a fast and accurate file-based scanner for vulnerable Log4J dependencies. JupiterOne Security team has wrapped this scanner with some additional scripts that ingest its output into the JupiterOne graph.

That project can be found here: https://github.com/JupiterOne/secops-automation-examples/tree/main/ingest-log4j-vulns

If Docker is available on your target hosts, this is the easiest way to use the tool. We provide an image on dockerhub that you can pull down via:

docker pull jupiterone/ingest-log4j-vulns:latest

Additionally, you may use this tool by:

• Installing a log4shell_sentinel binary into your hosts' system PATH.
• Cloning the secops-automation-examples repo, or downloading this zipfile.
• Copy the contents of the ingest-log4j-vulns folder onto your host, and install dependencies with npm install.

See project README.md for more details.

You will want to set up the scanning/ingestion script to run periodically, say at least every hour.

Prioritize Your Remediation

Once one or more hosts are reporting into JupiterOne, head to the JupiterOne Insights app and import this JSON schema. It should create a dashboard that gives you insight into which hosts need patching, how many vulnerabilities are still unpatched, and how long these hosts have been unpatched:

Patch Your Hosts, Monitor Insights

Use the above insights to help guide your remediation efforts. As you roll out patches, the scanning/ingestion script will verify them, and report each hosts' updated status to JupiterOne.

Watching the number of vulnerabilities fall is satisfying, and you'll have the confidence that regressions will not reoccur without your awareness.

Technical Notes

If you're using a different scanning tool, or this ingest-log4j-vulns project is otherwise not immediately helpful to you today, you may still find the approach taken here generally useful for cases where you want individual hosts to report periodically to the J1 graph.

The ingestion script uses the "Bulk Upload"/Sync Job API, and passes a unique scope for each host. This scope parameter is important: it ensures that multiple runs of the ingestion script will be idempotent, and that previous log4j_vulnerability Findings will be removed accurately from the graph once remediated. In our ingestion script we randomly generate a scope parameter for each host, persist it to the filesystem, and re-use on later runs of the script.

If you have more questions about this solution, or log4shell remediation in general, we have a dedicated channel, #rapid-response-log4shell, on our public slack. Please join us.