{"id":2967,"date":"2022-01-21T10:56:43","date_gmt":"2022-01-21T18:56:43","guid":{"rendered":"https:\/\/44.203.207.232\/?p=2967"},"modified":"2022-01-21T10:56:44","modified_gmt":"2022-01-21T18:56:44","slug":"log4shell-vulnerability","status":"publish","type":"post","link":"https:\/\/webdev.siff.io\/log4shell-vulnerability\/","title":{"rendered":"Log4Shell: Finding Where You Are Vulnerable"},"content":{"rendered":"\n
I\u2019m sure by now you are well aware of the Log4j 2 vulnerability which is putting an unprecedented number of companies at risk. In case you haven\u2019t heard, here are a couple of quick links to get you up-to-date and advise you on how to mitigate it:<\/p>\n\n\n\n
The big question, however, for those who are directly responsible for the security of your company or perhaps indirectly responsible as the application owner or as operational support, is where are the vulnerabilities located? Which Applications? Which Servers? Which tools are susceptible to the Log4Shell; and more importantly, how confident are you that you found every instance of it?<\/p>\n\n\n\n
Using the SIFF configuration monitoring platform, you can quickly discover the location of the Log4j vulnerability by using a SIFF Service Definition (SD) to discover and identify the java processes that are using Apache Log4j, then leverage a SIFF Policy Definition (PD) to validate whether these instances are compliant or not (i.e. Log4j version <= 2.14.1). Violations are flagged, users notified, and the platform can be configured to trigger automated remediation actions.<\/p>\n\n\n\n
To make this easy, we have created these SD\/PD and included them in the built-in SIFF community library. You simply have to activate these definitions and they will automatically examine any SIFF-managed devices for the Log4Shell vulnerability and notify you.<\/p>\n\n\n\n