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. They may not need to utilise log4j because they already have enough tried-and-tested methods, knowing that vulnerabilities will remain 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.
The Industry and Media
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.
While the cyber industry can rightly face criticism for selling on ‘fear, uncertainty, and doubt’ (FUD), the log4j vulnerabilities will likely persist for a long time due to the widespread use of the software across industries and organizations of all sizes.
Attackers are using the flaw now, and others are preparing to exploit it—possibly waiting until organizations assume they’ve patched everything or even hiding in networks they’ve already compromised 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:
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.
Focus your time on securing your key assets – such as physical, virtual, or IaaS servers that hold critical data that attackers could use 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. Apply new patches as soon as they are released, as they always contain important security improvements.
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 third-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 watertight in your response to an actual attack in the future.
Summing up log4j
In summary, log4j is here to stay. 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.
