In a recent report by the incident response giant Mandiant, which was purchased by Google in March, their researchers found that 2021 was a record year for the total number of 0-day vulnerabilities disclosed and exploited.
According to their findings, their team identified some 80 0-days exploited in the wild.
At the same time, Google Project Zero researchers reported the detection and disclosure of 58 0-days. This is the highest collection of 0-days that Google says that they have found since they began their tracking back in 2014.
The reason for the discrepancy is that the Project Zero team does not track Internet of Things vulnerabilities while the Mandiant team does.
But no matter how you count them, this spike in potentially dangerous vulnerabilities is troubling news for Security Operations Center (SOC) teams that have to seek out ways to mitigate the initial risk and then remediate once a fix has been issued.
To understand the implications of this spike in vulnerabilities, we break down the risks from 0-days and why they can be such pains for the SOC teams that have to address them.
The Threat of 0-Days
Over the better part of the past decade, the concept of 0-days has caught a lot of attention in the press and in our consciousness in general within the security community — and for good reason.
By definition a 0-day vulnerability is a vulnerability that had not been previously reported (as opposed to N-days), and therefore does not have a fix issued for it.
This means that even if your team has been scrupulous about updating their software, an attacker with one of these vulnerabilities can still slip past your defenses because you simply do not know that you have that vulnerability.
0-days have been used for everything from hacking Iranian nuclear centrifuges to breaking into iPhones with surveillance tools.
While not every 0-day is going to be that golden ticket for remote code execution on the iPhone, they are still highly valued. Markets with legal and illegal brokers have popped up, selling these vulnerabilities and their exploits to buyers.
More often than not the buyers are nation states, but not in all cases. There have been reports that criminal groups have been using more 0-days, buying them from black markets that sell them to the highest bidder. This proliferation has some potentially scary consequences, though it is still too early to know if criminals will either get access to any high value 0-days or will simply keep working with the N-days and phishing kits that are getting the job done now.
Even as the reports of the increase in 0-days is concerning, there are some reasons to be optimistic.
According to the researchers, they believe that the reason that they are finding so many more 0-days is because the industry is getting better at detecting and disclosing them.
This is a good thing because it means that many of the efforts aimed at uncovering these vulnerabilities are showing fruit.
But for the SOC teams that need to respond to these new vulnerabilities and ensure the security of their organizations, this growing batch of 0-days are just piling onto their extensive list of N-days that they are already struggling with day-to-day.
Challenges for the SOC Team in Handling 0-Days
The SOC team is the front line for the organization’s defenses and is responsible for handling much of the grunt work that is necessary to ensure its security.
So naturally it falls to them to manage the response to a new 0-day popping up on the radar.
For our purposes here, let’s break down a couple of the important steps that the SOC team will have to take in the vulnerability response process as laid out by the Cybersecurity and Infrastructure Security Agency.
Identification of Activity Vulnerability is Exploited in the Wild
In order to respond to the threat from a 0-day, the SOC team needs to know that the vulnerability exists.
This information may come from the vendor of the commercial software like Microsoft, Cisco, Atlassian, and others.
If the software is an open source like Apache Tomcat, Spring, or one of the other open source projects that so much of the world is built on, then the information may be a little harder to find. This is because the open source community is more distributed than the commercial world, more of a bazaar than a centralized cathedral as it were.
One of the problems that defenders face here is that the researcher who discovers the 0-day is not going to announce it to the world as soon as they find it. That would alert the defenders that they have a problem, but it would also broadcast it to the bad guys as well.
Common accepted practice calls for keeping the vulnerability on a need to know basis for 60-90 days, giving the software owner time to come up with a fix. If we are talking about commercial software, then they will push out the fix in a patch for customers to implement. Open source projects are a little more complicated because of their distributed nature.
Most all of these vulnerabilities will end up on the National Vulnerability Database eventually, becoming N-days.
The challenge is that in the meantime, some of these malicious actors may have already either discovered the vulnerability on their own or somehow acquired it. This leads to a window where the vulnerability may be used in the wild but the defenders do not yet know about it.
This is where threat intelligence feeds can be incredibly useful, helping the SOC team to gain early warnings of the 0-day being used to exploit other organizations — hopefully helping them to prepare their mitigation plans. Sorting through the mass of threats out in the wild can be a daunting task for the SOC team, but the risk of missing that one attack that could slip through is too high to take threat intelligence lightly.
Understanding if the Vulnerability Impacts the Organization
Not every vulnerability is going to be relevant for the organization. When the SOC team receives the threat intelligence, they need to understand if they are using software that is impacted by the vulnerability being exploited in the wild.
This means checking versions of the commercial products that they are using and combing through the software bill of materials in their own code base.
If they are using vulnerable software, then they need to look for signs that an attacker has tried to exploit them.
Look for Indicators of Compromise (IOC)s
The next step in the evaluation process, the SOC team needs to go through their logs and seek out any indicators that malicious actors may have accessed their assets.
If something looks amiss, then the team should call in an incident response crew to perform the deep dive. Any information that they find and can share with the rest of the security community for threat intelligence should be transmitted. This may include alerting authorities if mandated.
Mitigation
If the SOC team was dealing with an N-day, then the obvious next step would be to patch.
However, since the patch does not yet exist, the best thing that can be done is to mitigate the situation.
What exactly to do will likely come from the vendor. Often times it involves disabling permissions or use of specific tooling if possible.
Monitoring for suspicious activity is also essential at this stage, especially if the attackers may have gained access and persistence inside the organization.
Give your SOC the Training to Succeed
N-days are not being addressed. Attackers are still using these known vulnerabilities to great effect. The combination of scrambling to mitigate for 0-days paired with the Sisyphean task of dealing with the N-days can be overwhelming for SOC teams.
SOC teams are often the first step into the world of security for many, offering them a taste of the work and giving them the experience for future roles. However, this means though that they are often underskilled and may lack some of the more technical and operational knowledge that are critical for them to be successful.
Training your team to prepare them for all of the challenges that they will face on the job is essential. Good training needs to be ongoing, bringing team members of all levels up to speed on the latest technologies, threats, and techniques.