A blog series with the title The Log4J lessons might suggest that the fallout of the Log4j vulnerability is mostly behind us. Indeed, since the end of 2021 there has been tremendous effort from technology vendors, SOC’s and IT-departments to mitigate this threat. But given the widespread usage of this open-source logging library and the well-publicized ease of the attack, it’s highly unlikely that we’ve heard the last of Log4j in 2022.
The Log4j vulnerability that was discovered on Thursday, December 9th, is still a pressing issue for many companies. Since its discovery, we’ve received many questions from customers, most of which we have gathered on this FAQ page. If you have any questions regarding the Log4j vulnerability, you can find the answer to many of them here. This page will be continuously updated as we monitor the development of this situation.
On Thursday, December 9th a serious vulnerability was discovered in the much-used Apache Log4j Java logging library (Log4j). Through this vulnerability, an unauthenticated, unauthorized RCE (Remote Code Execution) is made possible, which can be used to take over a server. A patch was quickly made available, but executing said patch is proving to be a more complex activity.
The revelation of this week’s serious RCE vulnerability in the relatively unknown software agent OMI (Open Management Infrastructure) is eye-opening to many, and sheds a light on the perhaps overlooked topic of hidden risks.
Last week’s uproar on the Microsoft Azures database (Cosmos bug) hit the boardroom. A lot of major companies use Microsoft Cloud, so Azure customers were in for a rough surprise. Wiz's Chief Technology Officer Ami Luttwak (his company found the vulnerability) describes it as “the worst cloud vulnerability you can imagine.”
In a timespan of ten years, the IT-landscape has changed beyond recognition. Infrastructures that used to cost millions of dollars and took months of implementation are now available within minutes