Last updated: 17th of Dec. 2021 19:19 CET / 10:19 PST
Please note that as this is an evolving situation, we will continue to update this page as necessary.
On Thursday the 9th of December, a critical vulnerability in Apache Log4j was published as CVE-2021-44228. Log4j is a software component, that integrates with lots of Java applications: it is the most commonly used logging framework. So, this means it is used in thousands of different applications, software systems, and even in networking devices such as routers. This leads to risk of compromised systems on an unprecedented scale.
At SkyKick our cloud security and site reliability teams began a full investigation of our software stack immediately upon becoming aware of this vulnerability. While SkyKick does not use Log4j directly in any software that we develop, our Elastic Cloud Search Engine contains software packages which do use Log4j.
Elastic Search was not affected to the degree that access to data was possible. And we have updated those packages to mitigate any issue in close collaboration with the vendor.
We have now concluded that SkyKick system environments were not affected by the Log4J vulnerability, and that no system environment variables, partner or customer data was compromised.
Our cloud security and site reliability team continue to monitor and evaluate any risk to our environment for any possible indirect exposure.
What makes the Log4J vulnerability so impactful?
The Log4J vulnerability has the highest CVSS score. This is because it can be very easily exploited remotely and can lead to full compromise of a server. And it is already actively being exploited on a global scale.
The real impact is yet to be determined, as every organization will have to investigate their systems environment integrity. This is a daunting exercise. As it becomes clear how many systems have been affected reports of incidents and ransomware attacks will come in.
Helping our partners and customers address the risk
Discovering how the vulnerability affects your systems is a lot of work. It’s hard to detect all possible areas of risk and your attack surface. This is because the Log4J vulnerability can really be used anywhere, and it can be abused in a myriad of ways
For the threat actors, however, it’s relatively simple to identify vulnerable systems through mass scanning. Consequently, the Log4J vulnerability can be easily exploited.
The team at SkyKick has therefor compiled a list of resources and options by which the potential impact of the Log4J vulnerability can be mitigated.
It is good to see that the entire security community is working in unison to address and mitigate the Log4J vulnerability and that there are a lot of information sources on the topic. Collectively sharing information and security best practices will help all of us mitigate the risks faster.
We were made aware of some really good resources through our network early on, and we heartily advise security specialists to consult the GitHub site of the Dutch National Cyber Security Centre (NCSC), as they track the vulnerability and mitigation actions closely.
The following resource from Microsoft on securing Microsoft 365 and Azure with Defender is also very valuable: Guidance for preventing, detecting, and hunting for CVE-2021-44228 Log4j 2 exploitation
These are some great resources to help you identify the risk, scan your environment and remediate. And there is even a PowerShell script which was developed by the Dutch National Cyber Security Centre that you could use to scan your customer’s environments using SkyKick Cloud Manager: Log4j PowerShell Checker 
SkyKick’s Data Protection team can be reached at email@example.com for any data protection related inquiries, GDPR questions and further information about its continuous security and compliance efforts.
 Please note that Log4j PowerShell Checker script is provided by a 3rd party and SkyKick does not assume any responsibility for its use or function. We recommend reviewing the script thoroughly prior to running it against your environment so you are aware of any potential impact and always recommend testing on non-production systems first.