Log4j hearing: ‘Open source is not the problem’

The high-tech community is still trying to figure out the long-term impact of the serious vulnerability found late last year in the open-source Apache Log4j software, and so is the US Senate.

“Open source is not the problem,” stated Dr. Trey Herr, director of the Cyber Statecraft Initiative with Atlantic Council think tank during a US Senate Committee on Homeland Security & Government Affairs hearing this week. “Software supply-chain security issues have bedeviled the cyber-policy community for years.”

Experts have been predicting a long-term struggle to remedy the Log4j flaw and its impact. Security researchers at Cisco Talos for example stated that Log4j will be widely exploited moving forward, and users should patch affected products and implement mitigation solutions as soon as possible.

The popular, Java-logging software is widely used in enterprise and consumer services, websites, and applications as an easy-to-use common utility to support client/server application development. If exploited, the Log4j weakness could let an unauthenticated remote actor take control of an affected server system and gain access to company information or unleash a denial of service attack.

The Senate panel called on experts in order to find out about industry responses and ways to prevent future software exposures.

Since Logj4 is found in open source software, experts spent a lot of time defending the use of open-source software in critical platforms.

“The weakness in Log4j, which can be exploited by only typing in 12 characters, is just one example of how widespread software vulnerabilities, including those found in open-source code, or code that is freely available and developed by individuals, can present a serious threat to national and economic security,” stated committee chairman Sen. Gary Peters (D-MI).

“In terms of the amount of online services, sites, and devices exposed, the potential impact of this software vulnerability is immeasurable, and it leaves everything from our critical infrastructure, such as banks and power grids, to government agencies, open to network breaches.”

But Cisco’s security chief pushed back. “It is my opinion that open-source software did not fail, as some have suggested, and it would be misguided to suggest that the Log4j vulnerability is evidence of a unique flaw or increased risk with open-source software,” Brad Arkin, Cisco’s senior vice president and chief security officer told the committee. “The truth is that all software contains vulnerabilities due to inherent flaws of human judgment in designing, integrating, and writing software.”

“Cisco is a significant user of and an active contributor to open-source security projects. These are important efforts necessary to maintain the integrity of code blocks shared across foundational elements of IT infrastructure,” Arkin stated. “However, I believe that focusing narrowly on the risks posed by open-source software may distract us from other significant areas where we can address security risks inherent in all software.”

Atlantic Council’s Herr said similar vulnerabilities are sure to crop up in the future. “Log4j is an exceptionally widely used logging program,” said Atlantic Council’s Herr, “and addressing its flaws has required significant effort and public attention, but it will not be the last time this kind of incident occurs.”

“The key for this body, and a watchword for federal efforts to improve the security of open source, is to fund the mundane—providing resources where industry might not, or where public attention fades, to drive structural improvements in the security of software supply chains across all developers and maintainers. Better securing software supply chains and open-source code is an infrastructure problem, and the same long term investment model applies.”

Jen Miller-Osborn, deputy director of threat intelligence with the Unit 42 security researchers at Palo Alto Networks recommended risk reductions as a response to Log4Shell and future vulnerabilities, including:

• Automate compliance with vulnerability management policies: “We applaud [the Department of Homeland Cybersecurity and Infrastructure Agency] for building and maintaining a catalog of known exploited vulnerabilities, but manual reporting across 100-plus federal civilian agencies is unlikely to stay ahead of the adversary.”
• Drive industry-wide commitment to development security operations: “Impressive work is already being done in this arena, but the community would be well-served by increasing adoption of existing development tools to control access to open-source components. These tools can scan all of the open-source packages for both integrity and security before they are approved and allowed for engineering teams to use in products.”

Cisco’s Arkin stated that implementing secure architectures are critical to creating the necessary separation inside of systems to limit the impact of vulnerabilities and enable rapid recovery and resiliency.

“Proper segmentation, for example, makes it difficult for an attacker to move laterally through the network, even if they can gain initial access by exploiting a vulnerability,” Arkin stated. “Implementing a zero-trust environment further protects critical data and systems from intrusion and exploitation by ensuring that every attempt to connect to the network and access important data and systems is examined.” 

Arkin and others said secure software development and zero-trust networking requirements issued in a presidential order last year are important steps to follow, regardless of whether they would have prevented the Log4Shell vulnerability.

The problem of imperfect code is not likely to go away, said stated David Nalley, president of the Apache Software Foundation. “The reality is that humans write software, and as a result there will continue to be bugs, and despite best efforts some of those will include security vulnerabilities. As we continue to become ever more connected and digital, the number of vulnerabilities and potential consequences are likely to grow,” he said.

“There is no easy software-security solution; it requires defense in depth—incorporating upstream development in open-source projects, vendors that incorporate these projects, developers that make use of the software in custom applications, and even down to the organizations that deploy these applications to provide services important to their users,” Nalley stated.