Which Log4j versions are installed in your own IT landscape? And which tools can help with transparency? SAM tools use inventory solutions to gather programs and files. Can't they just take on this task too?
This article describes how Spider can support the transparency of which Log4j versions are installed via jar archive files in the IT landscape. Learn more about our January 2022 expansion of the Spider suite.
First of all, there is a particular criticism of Log4j vulnerability. We understood from discussions with customers that it is not easy to achieve transparency about the Log4j versions used in a IT landscape. There are different strategies which are needed for the detection of Log4j. Windows Add And Remove Programs often does not go far enough. Instead, the specific JAR files and their locations are asked more often.
Because a SAM tool is based on inventory data, which also includes files, the question arises whether it might not be possible to collect and evaluate the "log4j*.jar" files. The Spider Recognition module was previously only able to process exe-files. The amount of exe-files in itself is a particular challenge in the recognition process. What would it mean if the log4j jar files are now also processed?
This has been investigated and a report has been developed. Only a few settings have to be made, to collect log4j.jar files and to get the report up and running about which jar file and which version are found on which system.
The collection can be done with the inventory solution Spider Inventory (former Columbus Inventory) as well as with the Microsoft Endpoint Configuration Manager (formerly SCCM).
The report on all file evidence (file scan) is often very time-consuming and slow, which is why we worked on a good solution so that a quick report can be created and also be exported.
These extensions are possible with the first January release 2022.
The report shows log4j jar files including the file path. The version is extracted from the file name during processing and enables a targeted search for specific versions.
Assets are shown with the columns AssetNo, Hostname, Status, Last Scan Date and Legal Entity. Only authorized assets via Legal Entities are visible.
The report was implemented as a procedure-based report and enables a quick response, even in large environments for which many files are processed (e.g. 1 million data records).
The following screenshot shows an example of a data record for the report.
If another connector or inventory system is used, that provides file scan, we can check whether it is possible to collect and export log4j*.jar files here. If you are interested, we look forward to a comment or an email.
For Spider Datacenter Inventory for Linux / Unix this functionality is currently not available. If Spider Datacenter Inventory is used and the collection and processing of jar files for Log4j is an important requirement for you, we look forward to an email for further coordination.
Jan 10, 2022 05:07 PM - edited Jan 10, 2022 05:16 PM