What the Log4j vulnerability means for CISOs
A vulnerability was found in Log4j, an open-source logging library commonly used by apps and services across the internet last week. If left unfixed, attackers can break into systems, steal passwords and logins, extract data, and infect networks with malicious software.
Log4j is used worldwide across software applications and online services, and the vulnerability requires very little expertise to exploit. This makes Log4shell potentially the most severe computer vulnerability in years.
According to the National Cyber Security Centre, almost all software will have some form of ability to log (for development, operational and security purposes), and Log4j is a very common component used for this.
Palo Alto Networks
Cybersecurity company, Palo Alto Networks, says the recent Log4j vulnerabilities are a "particularly pernicious problem for two reasons".
In a blog on Palo Alto Network's website, Ryan Olson Vice President of Threat Intelligence says: "First, Apache Log4j has a very large footprint as a back-end logging library that is incorporated into many widely-used, open sourced and internally developed applications used by enterprises around the world. Issues with Apache Log4j affect almost everyone. Second, remediation can take weeks. The best way to protect yourself is to upgrade to the latest version; however, that requires that you first know where every instance needs to be patched and second that Java 8 is installed. There are many reasons why customers may not be able to upgrade for days or weeks, including the big effort required to upgrade Java before applying this patch, the full test cycle needed before upgrading Log4j, so it doesn’t break applications or year-end production freezes."
Tufin
Reuven Harrison, CTO at network security company Tufin says: "The exploit, like many others, relies on a call-home step to a command-and-control (C2) server.
"To prevent these kinds of attacks, organisations should restrict egress (outbound) connectivity. Each subnet, server and workload should be allowed to connect only to the endpoints that are required by business. All other destinations should be blocked.
"Blocking egress connections is easy with standard security controls such as firewalls, but defining the policy, which egress connections are allowed, is tough. Doing this properly requires continuous learning of legitimate application connectivity patterns, and enforcement in production environments.”
