Federal IT teams are scrambling to patch the Log4j and Log4Shell vulnerabilities before they cause major damage – and meet newly updated CISA guidance for Federal civilian agencies requiring immediate mitigation.
Log4j is an extremely popular logging framework for Java which acts as a journal or log of what happens in software applications and online services. There are two factors that make the vulnerability a significant problem. First, almost all large enterprise organizations use Java in some capacity. Java runs on portable devices, and on embedded instances, which can make resolution more complex. For example, military organizations might use Java in an edge or disconnected, air-gapped environment, which makes patching more difficult than in a more traditional DevOps environment.
Second, while the vulnerability was first reported on November 24, this flavor of Java has existed since 2013 and has therefore has likely been used in other forms of software for almost a decade – making its tentacles incredibly far-reaching.
With this in mind, the Cybersecurity and Infrastructure Security Agency (CISA) issued an updated directive on December 17, requiring all Federal agencies to immediately patch internet-facing network?assets for Apache Log4j vulnerabilities or take other appropriate?mitigation measures.?CISA had originally stated that Federal civilian agencies would have until December 24 to address the issue, but noted the update is, “in response to the active exploitation?by multiple threat actors of vulnerabilities found?in?the?widely used Java-based logging package Log4j.”
CISA created a dedicated webpage with mitigation guidance and?resources and has added the vulnerability to its Known Exploited Vulnerabilities Catalog, a new list created to provide agencies with a catalog of vulnerabilities organized by severity.
New vulnerabilities seem to arise every day, and as the number of and sophistication level of cyber threats continues to rise, how can we reduce the risk posed to Federal agencies and military organization as well as mitigate the impact? What best practices can agencies use when this inevitably happens again?
Mitigating the Impact
There are several ways to reduce risk and potential vulnerability impact. The best fix is to upgrade your Log4j dependencies immediately to the newest version (2.15.0), which resolves the issue in several layers and improves the overall security of Log4j.
What if you can’t update? Another option is to disable message lookups. This also adds an extra layer of protection if you suspect not all Log4j dependencies have been properly updated. It can protect against third-party Java packages that depend/embed a vulnerable version of Log4j and have not been properly patched yet.
When using the Log4j version older than 2.10.0, it is possible to remove the JndiLookup class from any Java applications. However, you should manually verify that no JndiLookup classes are available to any Java application. This will find all Log4j-core files and remove their vulnerable class. However, you should only use this method as a last resort.
Best Practices for the Future
Cyber leaders using network architecture best practices will be in the best shape to provide a strong defense against exploits from [inevitable] future vulnerabilities.
One of the key principles we recommend employing is the concept of least privilege, which suggests that users, systems, and processes only have access to the resources (networks, systems, and files) required to perform their assigned function.
Too often, the operational control plane and the command control plane are not maintained separately, which leads to greater risk with mixed logging data.
In an ideal system, the IT team maintains three separate silos:
- Operational, where the system is running;
- Command-and-control, where you can send commands to the system; and
- Logging, which contains logging and other incidental data, for analysis or observability, but is kept separate and does not have the ability to become an active component in the command-and-control plane.
Military systems typically follow these best practices, so they are less vulnerable. However, Federal civilian agencies that are less likely to take this approach are – as a result – more vulnerable to Log4j exploits.
Another best practice is to implement a software bill of materials (SBOM). SBOM is essentially a list of components or “ingredients” in a software that tells customers exactly how it’s composed.
The SBOM also provides a chain of custody, detailing all the people who touched a particular piece of software, or anything related to the product – from the development stages to runtime security testing to the distribution of the software and all the way to the edge. This makes it easier to find a vulnerability before it is too late. The 2021 Executive Order on Strengthening the Nation’s Cybersecurity includes the recommendation for all agencies to maintain an SBOM, noting “A widely used, machine-readable SBOM format allows for greater benefits through automation and tool integration. The SBOMs gain greater value when collectively stored in a repository that can be easily queried by other applications and systems. Understanding the supply chain of software, obtaining an SBOM, and using it to analyze known vulnerabilities are crucial in managing risk.”
Future vulnerabilities are inevitable. However, Federal leaders can take proactive steps to reduce risk and breach impact, including consistently updating software, maintaining a separate data silo for log data, and implementing a SBOM.