As the holiday season approaches, my family has a tradition of watching all of our favorite holiday movies—my favorite being Home Alone. It is the time for festive decorations, eggnog, and large heartwarming feasts with family and friends. Sadly, though, it is going to take a lot more than your aunt’s mystery casserole to ward off nefarious actors during the holiday season. After working in infosec for a few years, I am beginning to feel like Kevin McCallister spending every Christmas creatively warding off the Sticky Bandits.
In December 2020, as many people were busy Christmas shopping, there was the SolarWinds supply chain attack that was a Russian advanced persistent threat (APT) group “APT29” (aka Nobelium). At least one hundred public and private organizations were impacted in this attack and the discovery and mitigation effort lasted well into the new year for many organizations.
On 24 November 2021, as the US was preparing their stretchy Thanksgiving pants, a zero-day vulnerability impacting the widely used Apache Log4j Java library was discovered. The vulnerability was publicly disclosed on 09 December 2021. There are few CVE numbers that cyber security professionals can recite from memory, however CVE-2021-4428 is likely one of them.
One year later, as we prepare for another holiday season heist Log4Shell remains a target for cybercriminals. Attackers have had a year to embed Log4Shell into their scripts, penetration testing tools, and exploit kits. However, security teams have had a year to learn from the mistakes of others and are stronger for it.
Within this month’s Vulnerability Intelligence roundup, I am going to discuss five lessons learned since Log4Shell was announced on 09 December 2021.
- Visibility is critical for defense
There is an age old saying in security that you can’t protect what you can’t see. Any time a high profile vulnerability is disclosed, there are typically four types of reactions from IT teams:
- Calm and collected as they are quickly able to identify or rule out potentially vulnerable assets
- False sense of confidence, believing they are not impacted (only to find out they are)
- Slow and steady wins the race, believe the vulnerability is over hyped and they have plenty of time before an exploit or proof of concept (PoC) is created
- A mad panic and a scramble to remediate
Of course, of these scenarios, you’ll want your response to mirror option 1. Asset management is critical for organizations if they want to have a chance of defending against opportunistic attackers targeting zero-day vulnerabilities. True visibility, though, goes beyond knowing what your assets are. want to know what they are, what business function they serve, where they are, and who can access them.
In addition to asset management, having sufficient logging capabilities is equally important to ensure all relevant events are being monitored. The 2022 Verizon Data Breach Investigation Report (DBIR) identified the average time to detect breaches is a few days or less versus a month or more. At first glance, it sounds like the security community is making great strides, the discovery method for over 50 percent of breaches was actor disclosure. This means organizations are more often than not detecting breaches because an attacker informed them via ransom note or a public announcement taking responsibility for the attack.
Responding to zero-day vulnerabilities includes searching through environments to ensure exploitation has not already occurred. Insufficient logging and monitoring capabilities would obstruct visibility and potentially result in a more significant breach.
2. Manage risk with a software bill of materials (SBOM)
A software bill of materials (SBOM) isa detailed inventory of all the ingredients that make up software components. Log4Shell the importance of having a comprehensive understanding of tools and components used in enterprise environments.
It takes time for vendors and researchers to identify all the software that is or is not impacted by vulnerabilities. Having a detailed inventory of your own can help prioritize and fine tune patch management processes.
Even when a software vendor identifies they use a particular piece of technology—such as the Apache Log4j Java library—it takes time to identify the full extent of how it is used and how quickly it can be mitigated. Particularly with open source software, there is a large amount of creative freedom permitted to users in altering tooling to match their requirements. Having the visibility into which assets and business functions could be impacted is half the battle, allowing alternative mitigations, or work arounds, to be implemented.
Editor’s Note: To read the full blog, please visit ReliaQuest, our teammates site by clicking here.