About a month ago we all started down an ever-evolving and lengthy path that consists of researching and resolving impacts related to vulnerabilities within log4j. If you are not familiar with log4j, please check out my Dec 10th post titled Log4j – what you should know… 

This post provides a few updates, as the saga continues…

It’s not just about your own Applications…

Think about it…  your own internal applications (including those you might sell) are NOT the only applications that could be impacted by log4j.  Think about Avaya. Think about AWS. Think about Cisco. Think about HP Enterprises. Think about IBM.  Think about McAfee. Think about VMWare. Think about Schneider. Think about Splunk.   And, these are just a few of the ones that WERE impacted by log4j.  Your reliance on these tools, has indirectly exposed you by extension…

You scared yet? If you haven’t thought about those applications. most of which were severely impacted by log4j, then you might be getting nervous..

There’s a story (a fable, if you will) about the new CISO who found 3 envelops in their desk top drawer…. For those who haven’t heard that story, click here…

Some technologies were impacted pretty heavily, and some were not…

While a great number of applications (nearly 3,000) have been impacted by this series of vulnerabilities (ref: CVE-2021-44228 and CVE-2021-45046),  Microsoft’s products, for the most part, have been spared because they are built on .NET and don’t natively reply on the Apache log4j library.   However, as you’d imagine in the case of application development and App Dev operations, teams often leverage open and commonly used libraries to support a broader set of integrations: log4j is common and very popular. This means that there are a couple of features impacted within specific members (mostly app dev-related) of the Microsoft product family…

Some of the search features found in both Azure DevOps, Azure DevOps Server and a few others have been impacted by log4j due to their dependency on Elasticsearch (which was affected).  Here is a recently updated post on that from Microsoft on Azure DevOps

• Nearly all of our clients leverage Microsoft Office 365 (Microsoft 365) for their workforce productivity tools (email, word, excel, collaboration (Teams), sharepoint, etc.).  If you do too, then relax: none of these tools are affected by Log4j.
• Also, any products in Azure or Dynamics 365 are NOT impacted by log4j, provided your deployments of these leverage the native integration features…

You should STILL scan and evaluate your environment for exposures to log4j – as in my second paragraph (the scary story…)  And, you should ensure that you have a good patch management strategy in place… And, you should stay current on updates related to log4j.

Be careful about casual Internet searches (especially those offering free tools) as bad actors are using log4j-scanning utilities/tool-offers as a way to further spread malware.

You can start here as a trustworthy source – The Cybersecurity & Infrastructure Security Agency (CISA) is a dedicated extension of the US Department of Homeland Security. CISA is maintaining up-to-date information and guidance related to the Log4j vulnerability in the following: Apache Log4j Vulnerability Guidance | CISA

Also, you update and train your Microsoft Defender Protections to ensure immediate action on the detection of Log4j, and extend that detection into your Azure Sentinel deployment.  Oh yeah… that’s right… Microsoft automatically did that for you on Dec 17th…

Automation is the key to efficiency and rapid detection and response… We can help you check your environment, clean up the mess, and help ensure your environment is continuously optimized and secure from this and other security weaknesses.  Please contact us if you need assistance…

Until next time,

Ed