According to your observations, the Cybereason fix appears to be the real deal? Does it have the potential to address the vulnerability for security teams? How comprehensive a solution could this be?

It appears to be genuine and has the potential to assist security teams. The existing tool’s effectiveness is limited (it does not work for versions prior to 2.10, requires a restart, and the exploit must fire properly in order to be effective), and even when it does run properly, it still leaves the vulnerable code in place.

 

Or, if this fix is only for specific situations, what kinds of situations would it be best suited for?

This strikes me as a very clever “option of last resort.” Many organizations are currently struggling to inventory where log4j exists in their environment, and updating a component like this necessitates a dependency analysis in order to avoid breaking a system in the pursuit of fixing a vulnerability. All of this adds up to a lot of work, and having a “fire and forget” tool to clean up anything that may have been missed at the end of it all seems like a scenario that many organizations will find themselves in in the coming weeks.

Another scenario in which it could be useful is rapid emergency prevention, such as if a self-propagating piece of malware like Wannacry appears before patching is completed.

 

What benefits do you see for security teams using this patch to address this vulnerability?

Because the tool must first trigger the exploit in order to function, it will only work where it is required (given the tool’s known limitations). This saves time in an otherwise time-constrained situation.

 

Is this a potentially much faster way to address the problem than patching all systems?

Certainly, but since speed is the natural enemy of good security, I see this as a potential supplement rather than a replacement.

 

Do you think a lot of businesses will use this fix?

Because of the complexity of regression testing log4j, I’ve already heard from a number of organizations that are pursuing the workarounds contained in the Cyberreason tool as their primary approach. It remains to be seen whether many enterprises choose to exploit the vulnerability itself in order to achieve this, but for the reasons stated above, I would expect at least some to use the tool selectively and situationally.

 

Finally, could this fix assist businesses in resolving the vulnerability issue faster than you had anticipated?

It’s critical to understand that this isn’t a solution – it’s a workaround with a number of limitations. It has intriguing potential as a tool in the toolbox as organizations reduce log4j risk, and if it makes sense for them to use it, one of the primary reasons will be speed to risk reduction.