Such problems have the potential to disproportionately affect small and medium-sized businesses — and make it difficult to fix easily, he said. Sonatype analysis found that about 30% of Log4j consumption is from vulnerable engine versions. “Some companies have no message, no documentation, and don’t even know where to start,” says Fox. Sonatype is one of the companies that offers scanning tools to identify the problem if it exists. One customer told them that without that, they would have to send an email to the 4,000 app owners they work with asking them to find out if they were affected.
Part of the problem, of course, is that for-profit businesses have too much faith in free, open-source software developed and maintained by a small, over-invested group of volunteers. Log4j’s problem isn’t the first — Bleeding bug that devastated OpenSSL in 2014 is a prime example of a similar problem — and won’t be the last. “We won’t buy products like cars or food from companies with supply chain operations,” said Brian Fox, chief technology officer at Sonatype, a software supply chain security and management specialist. really bad. “However, we are doing it all the time with software.”
Companies that know they use Log4j and are using a fairly recent version of the utility will have no worries and little to do. That’s the pointless answer: It could actually be very easy, says Fox.
The problem arises when companies don’t know they use Log4j, because it is used in a small part of the application or inclusion tool that they don’t monitor and don’t know how to start looking for it. “It’s like understanding what iron ore goes into the steel that goes into the pistons in your car,” says Glass. “As a consumer, you have no chance of understanding that.”
Moussouris said the Log4j vulnerability, in the software library, makes it difficult to fix, as many organizations have to wait for software vendors to patch themselves – something that can take time and testing. “Some organizations have people with more technical skills inside of them who can figure out various mitigations while they wait, but essentially the majority of organizations rely on suppliers to produce high-quality patches that include updated libraries or updated components in those packages,” she said.
However, companies large and small across the United States – and around the world – are moving and fast. One of them is Starling Bank, a UK-based challenger bank. Because its systems were primarily built and encrypted in-house, they were able to quickly discover that their banking system would not be affected by the Log4j vulnerability. “However, we are also aware of potential vulnerabilities in both the third-party platforms we use and the source code,” said Mark Rampton, head of cybersecurity at the bank. from the library that we use to integrate them.
Had. “We quickly identified cases where the Log4j code included in our third-party integrations had been replaced by other logging frameworks,” he said. Starling has removed those traces and prevented them from being used in the future. At the same time, the bank tasked its security operations center (SOC) to analyze hundreds of thousands of events to see if Starling was being targeted by attackers looking for a Log4j vulnerability. They haven’t, but are keeping an eye on them. Rampton said the effort needed was substantial, but necessary. “We decided to take a ‘guilty until proven innocent’ approach, as the vulnerability is being unraveled at a rate that makes it impossible for us to make any false claims,” he said. which decision.
“I understand where the FTC is trying to come from,” said Thornton-Trump. “They are trying to encourage people to do vulnerability management. But it completely fails to hear the actual threat this vulnerability poses to many businesses. They’re basically making you hit the panic button about something you don’t even know if you have at this point. “
Stories with WIRED are more amazing
