One month of log4j – what have we learnt?

It’s been a month since the world was thrown into frenzy around the log4j vulnerabilities, so what do we know now and what have we learnt since then?

What's happened so far?

Perhaps bizarrely, given the amount of noise in the media, we’re yet to see widespread use of log4j in ransomware. Answers as to why this is will be no more than speculation at this stage. Perhaps attackers (threat actors, more specifically) are aware that security teams may be more focused on specific technology or indicators of attack and compromise at this time relating to log4j. Maybe it’s because they simply have enough existing methods that are tried and tested and so don’t need to utilise log4j, knowing that there will be vulnerabilities in the wild for years to come. There will be lower hanging fruit further down the line, once the immediate panic dies down.

We also know that most breaches aren’t found for a long time, estimates differ wildly: IBM puts the average time to detect and contain a breach at 280 days, with variances by industry. It may also be down to a lack of reporting or even awareness from victims – whilst it can be hard to quantify, we know that a large number of cyber-attacks go unreported, either because the organisation simply isn’t aware, or out of choice, with the perception that it may avoid reputational damage.

There are, of course, notable exceptions, for example the NHS SOC recently reported that hackers are targeting log4j vulnerabilities in the VMWare Horizon product exposed to the internet. You can read their excellent cyber alert post here, which includes useful advice for remediation and threat hunting.

Does this mean that the industry and media have oversold the risks of log4j and we won’t expect to see much use of the vulnerabilities in ransomware? Unfortunately, not. Whilst the cyber industry can rightly be accused of selling on ‘fear, uncertainty and doubt’ (FUD), the likelihood is that log4j vulnerabilities will be with us for a long time due to how widespread the software use is across all industries and organisation sizes.

The flaw is being used now and other attackers will be preparing to use it, perhaps biding their time until organisations assume they’ve patched everything appropriately or maybe even already hiding in networks that they’ve successfully exploited with log4j.

What's our advice?

Our advice remains the same as it has since the uncovering of the vulnerabilities. The good news is that the advice is simply good practice, with the potential attacks being business as usual for a well-run Security Operations Centre (SOC). To recap:

• Focus on protecting and monitoring your internet-facing assets first – these are anything that is placed on an internet-facing server and include web servers, firewalls, VPN gateways, remote access services, cloud application platforms and more. There is a lot of guidance here, but all of the below advice should be prioritised with regards to your internet-facing assets.

• Improve your asset management and inventory – it’s easy to assume that your organisation knows what devices, users and software you have on your network. The reality is that most organisations don’t have an accurate picture, and this makes it harder to detect anomalies that could be an indicator of attack or compromise. This is difficult to do, but asset discovery tools can be a good starting point.

• Spend your time working on securing your key assets – such as physical, virtual or IaaS servers that hold your key data that could be used against you. The obvious valuable data here is customer data, but don’t lose sight of your strategy (think emails) and Intellectual Property (IP). This also includes hardening and patching these assets – new patches are coming out all the time and should be applied as soon as possible as they’ll all have security improvements in them.

• Implement an Endpoint Detection & Response tool – onto these assets where supported, as soon as possible.

• Update detections, rules, use cases and playbooks – covering logging policies (how often, what and where) and network traffic monitoring. Also be sure to implement asset management / deeper systems monitoring and inventories to give your security team the richest data possible to be able to spot potentially successful attacks as opposed to chasing every scan! This will allow you to make informed decisions and update your detection use cases and processes to ensure you cover signs of compromise, as opposed to trying to investigate each attack – there will continue to be thousands of log4j ‘attacks’ for years to come, some genuine, others from researchers and defenders.

• Develop and practice incident response – link this back to scenarios relating to 3rd party software vulnerability or compromise (i.e. similar potential scenarios). If you don’t have this scenario in your plan, add it now and consider variations such as a developer of open-source software that you rely on accidentally or intentionally introducing a major vulnerability or compromised code into your key systems. This proactive approach of ongoing testing of your incident response plans will give you the best chance to be water-tight in your response to an actual attack in the future.

In summary, log4j is here to stay and the best defence is to build a robust security operation so that issues like this are simply business as usual, with a few tweaks based on the specific threats.

If you’d like to talk through any of the challenges your organisation is facing, then get in touch today. To keep up to date with all of e2e's updates regarding log4j, follow our blog.