It seems that every few weeks, we are alerted to a new significant security issue within one of the plethoras of code elements that are widely used. The same pundits discuss the same range of concerns with open-sourced code each time. The list of “usual suspects” is long, and I know I could add at least 20 additional “reasons” to this list without thinking about it too hard. I’m not sure that open-sourced code is riskier than proprietary developed code. There I said it.

This december, we are posting security advice and modules, every day until December 25th. Now, it’s December 14th, and we’ve gotten to the fourteenth day of the security hardening holiday calendar.

By now, you’re probably assessing your level of exposure — or are in the middle of remediating — the recently disclosed vulnerability known as Log4Shell. We recently introduced a native integration with Snyk, a leading provider of developer security solutions, to help you address zero-day vulnerabilities. Once enabled, Snyk scans your code and its dependencies, and alerts you about security vulnerabilities, including Log4j. All current versions of Log4j 2 up to 2.14.1 are vulnerable.

We see unfriendly customer practices all around in the SIEM space. For example, some major SIEM vendors use an Events Per Second (EPS) license model to monetize access to their tools. Typically, these vendors will drop data above the EPS license or stop data ingestion to incentive license compliance if you run over your EPS license. These license controls disrupt operations and risk enterprise security posture, which can cause chaos.

This post will be updated over the next several days. Recently, a Remote Code Execution vulnerability was discovered in the Apache Log4J library. This vulnerability, which is tracked in CVE-2021-44228, dubbed Log4Shell, allows attackers to execute arbitrary code on affected systems. While HAProxy Enterprise, HAProxy ALOHA, and other products within the HAProxy Technologies portfolio are not impacted by this (they do not use the Log4J library at all), you can use them to block the attack.

Imagine the scenario: you get an urgent call from one of your customers. All her files seem to be corrupted. And then there’s that email demanding payment via Bitcoin for restoration. She needs your immediate help to get her business up and running. Later on, she’ll demand to know how you let her business be vulnerable to this attack. You had installed firewalls, required strong passwords, and conducted email phishing drills—and still your customer was attacked.

The recent Apache Log4j vulnerability CVE-2021-44228 dubbed Log4Shell is a big deal. By now there is no shortage of blogs, other write-ups, and analysis about why this vulnerability is an urgent issue and why there is a very good chance it applies to your environment. Here are some of the articles that dive into the gory details on this CVE.

Last Thursday, a researcher from the Alibaba Cloud Security Team dropped a zero-day remote code execution exploit on Twitter, targeting the extremely popular log4j logging framework for Java (specifically, the 2.x branch called Log4j2). The vulnerability was originally discovered and reported to Apache by the Alibaba cloud security team on November 24th. MITRE assigned CVE-2021-44228 to this vulnerability, which has since been dubbed Log4Shell by security researchers.

Over the last few days, there have been a tremendous amount of posts about the Log4j 2 vulnerability, with Wired going so far as claiming that, “the internet is on fire.” Tl;dr: LogDNA is not exposed to risk from the Log4Shell vulnerability in Log4j 2 at this time. If that’s all you came for, you can stop reading here. If you want to learn more about the vulnerability and how LogDNA protects you from risks like these, grab a cup of coffee and read on.