Reader Comment – Log4Shell Do Something Now

Yesterday I received a DM from a long-time reader and ICS influencer as part of an ongoing discussion about software updates for ICS products for the Log4Shell problem. It said:

“Patrick we need to shake up the ICS vendors they are not doing justice to the seriousness of this vulnerability .... (sic) they and their customers are all likely to be impacted .... (sic)”

My first inclination was to agree; this is certainly a problem, and something needs to be done about it now. But I recognized that response as being an emotional response and I have learned over the years that I need to let such responses simmer, so that I don’t say something that I later regret. And, this morning, I am glad that I did.

The Siemens Example

Siemens was one of the first ICS companies to respond to Log4Shell. This is to be expected. They have lots of experience dealing with newly discovered vulnerabilities. They published their advisory on December 13^th, and their first update on December 15^th. Part of the reason for the quick update was the discovery of a second Log4J vulnerability and the ineffectiveness of the first workaround. Then there was a second update on the same day. More affected products were listed, and one was removed. Now that there is a third Log4J vulnerability, I suspect that a third update is probably in the works.

Fixing Means Stopping Production

If an owner/operator started working on the first suggestions from the initial advisory, they may have had to start anew with the later information. The problem, however, is that to ‘fix’ and ICS system, you have to take that system out-of-service for some amount of time to apply the fix. That means that production must stop. If an owner/operator tried to do that for each of the Siemens’ updates, that would quickly begin to impact the bottom line.

Oh, and if you had taken the system down to ‘fix’ a device that was not really affected by Log4Shell after all, the cost would have come without any benefit.

Risk Notification

Okay, so maybe we really do want to have vendors to get a good fix made before the owner/operator tries to fix their systems. And remember, the fixes really need to be tested and evaluated in a mirror of the deployed system to make sure the fix does not cause even more problems. But we should be able to expect quick notification about the vulnerabilities from the vendors, right?

To be fair, the response that I reported upon earlier this week is the most comprehensive (far from perfect, but the best yet) set of vendor responses that I have seen since I started reporting on vendor advisories. It is far from complete, and many of the reports were of the ‘we are looking at the problem’ sort, but that is still much more than what we typically see for library vulnerabilities.

SBOM

The big problem here is that the Lib4J library is much more pervasive that first thought. This has grown beyond just a vendor or 3^rd party provider problem; we are starting to see that this is a 4^th or 5^th party provider problem. It certainly points out the need for software bill of materials, but it also points out how complex the SBOM issue is becoming in modern software development.

But SBOM is not a be all and end all. It must be accompanied by a vulnerability notification system that pushes those notifications down the line. This is the only way that vendors and end users will know to look at the vulnerabilities in the first place.