Log4j flaw: 10 questions you need to be asking
The UK National Cyber Security Centre (NCSC) is urging company boards to start asking key questions about how prepared they are to mitigate and remediate the widespread, critical Log4Shell flaw in Java-based application error logging component Log4j.
NCSC calls Log4Shell "potentially the most severe computer vulnerability in years" and called upon company boards to treat this bug with urgency. It stresses the Log4j bug – also known as Log4Shell – is a software component rather than a piece of software, which means it will be much more complicated to patch.
Log4Shell is bad news today and will likely lurk in enterprise systems for years despite major efforts from the US government, big tech and open-source contributors to address flaws in the original Log4J version 2 project, its implementation in major software products, and its deployment in hundreds of millions of enterprise applications, servers and internet-facing devices.
LOG4J FLAW COVERAGE – WHAT YOU NEED TO KNOW NOW
- Log4j flaw: Attackers are making thousands of attempts to exploit this severe vulnerability
- Security warning: New zero-day in the Log4j Java library is already being exploited
- Log4j RCE activity began on December 1 as botnets start using vulnerability
There are ongoing efforts via the Apache Foundation to patch the core Log4j project, as well as downstream efforts by IBM, Cisco, Oracle, VMware and others to patch products containing vulnerable versions of the Log4j component. Google has also released tools to prevent developers using vulnerable Log4j versions in new builds of open-source software. And the US government has ordered all federal agencies to patch or mitigate Log4Shell by Christmas.
The urgency is justified. State-sponsored hackers have started scoping out the bug for potential future attacks, according to Microsoft and Google, while cyber criminals are figuring out how to profit from it. Meanwhile, the Belgian Ministry of Defense confirmed an attack on its network using the Log4j bug.
Key challenges NCSC outlines include organizations finding out what services use Log4j; identifying which of these services an organizations uses; and then finding out if these services are vulnerable. CISA has already required all US federal agencies to enumerate any external-facing devices with Log4j installed. That's no small task, especially given the number of affected products from Cisco, IBM, Oracle and VMware. Because of the component's widespread use in other products, CISA estimates hundreds of millions of devices worldwide are exposed.
"How concerned should boards be?" NCSC asks.
Very, unless a business can afford disruptions to its operations from ransomware. While Microsoft has not found instances of the more dangerous human-operated ransomware using the vulnerability, it has seen Iranian threat actors tooling up to use it for ransomware attacks.
NCSC has posed 10 questions for boards worried about the flaw:
- Who is leading on our response?
- What is our plan?
- How will we know if we're being attacked and can we respond?
- What percentage visibility of our software/servers do we have?
- How are we addressing shadow IT/appliances?
- Do we know if key providers are covering themselves?
- Does anyone in our organisation develop Java code?
- How will people report issues they find to us?
- When did we last check our business continuity plans and crisis response?
- How are we preventing teams from burning out?
Boards should also consider Log4Shell's impact if the business needs to disclose where personal data was affected, as well as any costs linked to incident response and recovery, and damage to reputation.
"Managing this risk requires strong leadership, with senior managers working in concert with technical teams to initially understand their organisation's exposure, and then to take appropriate actions."
NCSC says Log4Shell warrants organizations creating a "tiger team" of core staff, including a leader, to address the threat. Boards should also ask 'what's our plan?', and to understand how Log4j issues will be remedied. Boards should understand this will take weeks or months to remediate, not days.
Boards should know how the company is prepared to respond to a Log4Shell attack if and when it happens, and whether the company can detect if such an attack were to take place. It stresses that boards should understand what visibility its teams have of vulnerable software and servers, including IT assets that are centrally managed and unmanaged.
LOG4J FLAW COVERAGE - HOW TO KEEP YOUR COMPANY SAFE
- Log4j zero-day flaw: What you need to know and how to protect yourself
- Security warning: New zero-day in the Log4j Java library is already being exploited
- Log4j flaw could be a problem for industrial networks 'for years to come'
The software supply chain is another key consideration. NSCS recommends organizations have an "open and honest conversation" with software-as-a-service suppliers that may also be trying to get a grip on which of their products are affected.
Java is a hugely popular programming language in enterprise IT that's used by an estimated 12 million developers worldwide.
"Java developers may have legitimately used Log4j, so it's important to ensure that any software written is not vulnerable," NCSC notes. As it's previously noted, Log4j version 2 ships with Log4j version 2 (Log4j2) popular Apache frameworks including Struts2, Solr, Druid, Flink, and Swift.
Finally, after two years of supporting remote work during the pandemic, a year of professional ransomware attacks and state-sponsored attacks on the software supply chain and of the critical Exchange Server zero-day vulnerabilities, NCSC is warning that some cybersecurity teams could suffer burnout during Log4Shell remediation. This is a board-level concern.
"Remediating this issue is likely to take weeks, or months for larger organisations. The combination of an ever evolving situation (and the potential for severe impacts) can lead to burnout in defenders, if they're not supported by leadership," NSCS stressed.