Using Intelligence to Drive Vulnerability Prioritization
The goal if this article is to address some of the ways Cyber Threat Intelligence can compliment a vulnerability management program, particularly surrounding the prioritization of vulnerability patching and mitigation. Often times, there can be a gap with the way vulnerability management programs assess vulnerabilities and their associated risk that can leave out out critical information.
Vulnerability programs tend to focus on Common Vulnerability Scoring System(CVSS) scores, which do take a number of criteria into account. Things such as attack vector, privileges, attack complexity and exploitability are all factors that weigh the CVSS score. Taken from the CVSS 3.1 specification “CVSS consists of three metric groups: Base, Temporal, and Environmental. The Base group represents the intrinsic qualities of a vulnerability that are constant over time and across user environments, the Temporal group reflects the characteristics of a vulnerability that change over time, and the Environmental group represents the characteristics of a vulnerability that are unique to a user’s environment.” Our intelligence tends to fall in line with the Temporal group that reflects changes over time, more specifically, exploitability.
Exploitability
While exploitability is a consideration for CVSS, Intel teams can often times use information sharing platforms and open source or paid intelligence feeds to provide updates on new information in the wild at a quicker pace.
The criteria can vary for what works best for you or your organization, but here are four things to help get started.
Interest / Chatter
Interest through either open source or closed source (e.g. Darkweb) channels can create a bit of buzz. Increased chatter could indicate more immediate ambitions for threat actors or security researchers to create proof of concepts or exploit code related to the vulnerability. It’s important to monitor the level of interest since is could be a precursor for a more serious threat to develop.
Proof of Concept / Exploit Claims
Prior to a working proof of concept(PoC) or exploit, you might discover folks claiming to have a PoC or be in the process of developing one. Generally when this happens, it’s only a matter of time before a real one is published publicly or sold to potential attackers.
Proof of Concept / Exploit Development
Once a PoC exists attackers can test and develop successful exploits and weaponize the code for use in future attacks.
Exploitation in the Wild
Exploitation in the wild is the last criteria on the list but it’s also a bit broad and can be broken down quite a bit further if it better fits your approach. If assessing the threat level (as it pertains to Intel) you might want to consider things like the intent, opportunity and capability. Some examples of questions aligned with this might include:
- Is the vulnerability being leveraged by a threat actor that regularly targets your company or industry?
- Is the vulnerability included in common exploit frameworks?
- Is the vulnerability associated with common Malware?
- Does the vulnerability target anything in your tech stack?
Framing some of these types of questions into your assessment model can improve the way we approach assessing vulnerabilities and the information provided to Vulnerability Management teams or other stakeholders.
Continuous Monitoring
One of the things that intelligence teams can provides that separates itself from initial discovery is having the ability to continuously monitor any changes in information to some of the criteria mentioned previously. The information obtained can act as a precursor to changes in the CVSS Temporal Score.
Pre-NVD
Another common use case of good intelligence collection is discovery prior to publication in the National Vulnerability Database (NVD). This allows analysts to get a head start on information gathering to alert stakeholders before they read about it in the Wall Street Journal.
Example
A critical vulnerability CVE-2020–1350(SIGRed) was discovered by Checkpoint Research and given the rating of CVSS 10.0. The vulnerability was published on July 14th, 2020. This was a remote code execution(RCE) vulnerability with Windows Domain Name System servers. It wasn’t long before open source channels such as Twitter began showing interest in the details and possible proof of concepts.
Shortly after, security researcher(ZephrFish) posted a alleged proof of concept to GitHub, which was quickly shared among the community. Turned out, the proof of concept was illegitimate and what was initially a troll turned into a valuable social experiment. Nevertheless, the events led to further interest and highlighted another important lesson, check code before you execute it.
A day or two later, two real exploits were published publicly to GitHub.
While I didn’t discover anything else too substantial, there were various files uploaded to VirusTotal that could be associated with malware or hack tools using the exploit. At any rate, that would be the next logical step in the chain should malware leverage the vulnerability to self-propagate.
In order to gather this data many organizations may rely on paid intelligence subscriptions to easily monitor various sources of information. This article isn’t meant to provide technical details on other open source collection options, however I imagine you can leverage something such as Twitter’s API to collect and analyze data similarly.
The Bigger Picture
Assessing the true risk associated with a vulnerability is generally a joint effort. Intelligence can only paint one part of the picture. You’ll generally need to engage other teams such as Vulnerability Management, Asset Management and other Security Teams to understand impact and overall risk.
The model might look something like this depending on access to information and how teams are defined in your organization.
It’s important to have a grasp of your tech stack, or important technology critical to your organization allowing you to gauge overall potential impact. Other mitigating factors play an additional role, for example if security controls are in place to limit the impact of a vulnerability. Taking some of these factors into account, intelligence can help guide vulnerability prioritization through a controlled process of continuously monitoring changes or new developments surrounding the vulnerability.
A basic sample workflow from threat identification to risk calculation. There won’t always be a threat actor behind a newly published vulnerability, particularly if there hasn’t been an exploit code associated with it yet.
This is a fairly simple model to a complex problem, but I hope some of the information here can help guide you in the right direction when it comes to leveraging intelligence around vulnerability management.
