The aftermath of Log4j - What can be done to protect businesses?

Last year's Apache Log4j vulnerability created a lot of chaos, so what can be done to protect companies from the security implications?

Tim Mackey, principal security strategist with Synopsys Cybersecurity Research Centre, says that while it might be tempting to view a major vulnerability as an indication of open source somehow being deficient, the reality is far from that.

"Open source software is not more or less secure than commercial software, and in reality most commercial software either includes or runs on open source technologies," he says,.

"Open source simply means that the software is developed in a manner where the source code is available to anyone who wants it."

Mackey says, "What we are seeing with the Log4J response from the Apache Log4J team is exactly what we'd expect to see a team that is taking the software they produce seriously and being responsive to the needs of their install base.

"Considering that they are volunteers, such a response is indicative of the pride of ownership we often see within open source communities," he says.

"In reality, an incident like Log4J is likely to improve open source development as a whole much in the same way that Heartbleed improved development practices of both open and closed source development teams."

Mackey says common thought pattern is that there should be a commercial replacement to protect companies from security implications after Log4j, but one that misunderstands how software development really works.

"Every software component has what is known as an interface. That interface might be in the form of an API if its a web service, or it might represent the functions that can be called when the component is loaded into an application," he says.

"What that interface looks like, how it behaves, what types of data it takes and in what format, are all examples of decisions the development team creating the component make as they write the component.

"Those decisions can also change as new features are implemented or as the code evolves. Log4J has an interface for each of its major versions, and they are not the same," Mackey says.

"For a commercial replacement of any component to exist, there must be an available market for it. In the case of Log4J, the component logs message data to a log file. There is nothing sexy about it, and there are many other ways of logging data than just Log4J."

He says that means there is not much of a commercial software market for a replacement.

"But, lets assume someone was willing to make that investment to have a commercial replacement for Log4J. In that case, they would need to both re-implement the current Log4J interface and then write what is presumed to be more secure code," Mackey says.

"The concept of open source somehow being less secure than commercial software may have been true decades ago, but that is far from true today, but let's assume that our fictitious company was able to create a perfect logging utility that faithfully reproduced the Log4J interface.

"Once they've created that replacement, they need to market it and ensure that it doesn't break any software using Log4J."

Mackey says detection of vulnerabilities in open source isn't a problem, but detection of software defects representing a weakness that could be exploited is an important topic.

"This distinction is important as vulnerabilities might not represent flaws in code, but instead flaws in deployment configuration or changes in hardware," Mackey says.

"It is important to note that open source and closed source software have an equal potential for security issues, but with open source it is possible for anyone to identify those issues," he explains.

Since its possible for anyone to identify issues, Mackey says the question really is one of how many people are actually attempting to identify issues in open source and how diligent those efforts are.

"Part of the problem is a sentiment that has consumers or users of open source projects behaving as if they expect the open source project to behave like a commercial software vendor," he says.

"If you look at the issues list of any reasonably popular open source project on GitHub, you'll see feature requests and comments about when certain problems might be resolved. The modern open source movement was founded on the principle that if you didn't like the way the code was working, then you were free to modify it and address whatever gaps in functionality that were perceived to exist. Feature requests in GitHub issues and complaints about serviceability have an implicit expectation that a product manager is on the receiving end of those requests and that they will be added to a roadmap and eventually be released all for free."

Mackey says that in reality, gaps in functionality and even in perceived bugs represent opportunities not to request free programming services but instead to contribute to the future success of code that is significantly important to the person complaining for them to complain.

"Yes, some people wont know the programming language used by the project, but to expect other people to prioritise a complaint from an unknown third party over changes that solve problems for active contributors isn't realistic. As much as anything, open source functions through the altruism of contributors," he says.

"Over recent years, we've heard core contributors for popular open source projects express frustration about the profits made by large businesses from the use of their software. While its easy to relate to someone putting their energy into a project only to have a third party profit from the efforts, the reality is that if that third party is profiting from the efforts of an open source development team, then they should be contributing to its future success.

"If they don't then they run not only the risk that the code in question might change in ways they didn't expect, but also that when security issues are identified and resolved that they might have delays in applying those fixes," Mackey says.

After all, if a business isnt taking the time to engage with teams creating the software that powers their business, then its likely they don't know where all the software powering their business originates and cant reliably patch it."