Table of Contents
As a security analyst, I frequently need to assess the risk posed by vulnerabilities that are discovered on systems in my organization’s environment. To accurately evaluate how much of a threat a vulnerability represents, I utilize the industry-standard Common Vulnerability Scoring System (CVSS).
CVSS provides a detailed framework for analyzing vulnerabilities and assigning them risk scores. These scores consist of three components – Base Metrics, Temporal Metrics, and Environmental Metrics. In this post, I’ll be focusing on CVSS Temporal Metrics, which measure the characteristics of a vulnerability that change over time.
Why Calculate Temporal Metrics?
The Base CVSS metrics analyze the inherent qualities of a vulnerability – how it can be exploited, the access required, its impacts, etc. However, other factors come into play after a vulnerability has been publicly disclosed. The availability of exploits and remediation also affects the overall risk.
This is why CVSS has a separate Temporal Metrics component. It allows me to take into account real-world conditions and threats to my systems. Factors like exploit code maturity and the existence of patches influence how urgently I need to act.
By scoring vulnerabilities using the CVSS Temporal Metrics, I can refine my risk analysis and prioritization of remediation efforts. Next, let’s look at the specific metrics I use.
Key Temporal Metrics in CVSS
CVSS v3.1 defines three primary Temporal metrics that capture the evolving real-world threat landscape of a vulnerability. By assessing flaws on these metrics, I can focus remediation on ones with clear and urgent danger. Let’s examine each metric and its impact on my analysis:
Exploit Code Maturity
This metric describes the existence and sophistication of exploit code publicly circulating for a vulnerability. It directly captures the likelihood of attackers developing functioning attacks leveraging the flaw.
Attackers analyze technical writeups of new vulnerabilities to build weaponized “exploits” – code that triggers the weakness to compromise systems. The more complete and reusable the exploit material publicly available is, the higher the chances of mass attacks succeeding, even by relatively unskilled threat actors.
As such, CVSS specifies 6 possible values for the Exploit Code Maturity metric based on real-world observations:
Possible Values
| Value | Abbreviation | Score |
| Not Defined | X | 1 |
| High | H | 1 |
| Functional | F | 0.97 |
| Proof of Concept | P | 0.94 |
| Unproven | U | 0.91 |
Not Defined (1.0)
Insufficient information to determine if exploit code exists.
Worst-case High risk rating assigned due to uncertainty.
I enforce maximum isolation rules as a precaution until more details emerge.
High (1.0)
Complete exploit code is widely circulated in the criminal underground and hacker forums.
The code works reliably to exploit the vulnerability without needing customization or specialized environments.
Exploits incorporated in penetration testing frameworks like Metasploit enable automation with very high attack volume.
Attacks succeeding independent of target – applicable across platforms, system hardened configurations and environments.
For such highly commoditized threats with self-propagating worms or easy-to-execute binary downloads, I enforce emergency controls like isolation or shutdowns. These indicate extreme danger necessitating urgent response.
Functional (0.97)
Public exploits exist but significant effort is required to modify or rewrite elements of the code before functioning reliably.
The attacks likely cannot be easily automated without additional developer work.
Success conditions may be narrow and still specific to certain platforms or system configurations.
While functionally mature, exploit customization effort limits scale of attacks. But the flaw can still be leveraged in targeted intrusions by skilled actors. I isolate or patch affected assets rapidly after in-depth testing.
Proof-of-Concept (0.94)
Only demonstration exploit code exists showcasing that attacks are theoretically possible under strictly defined conditions.
The PoC code is highly unstable and unreliable, requiring major modifications by security testers before functioning somewhat.
Works only for very specific system environments and setups like outdated unpatched software versions.
Despite needing customization, evidence of successful compromise in limited situations still warrants urgent action. I enforce strict isolation rules temporarily while testing systems and deploying permanent fixes.
Unproven (0.91)
No observations of exploit code publicly circulating among ethical or criminal security research sources yet.
Developing working exploits appears impractical currently though theoretically possible.
Absence of threats lowers response urgency but I still remain vigilant. Weaknesses get continuously scrutinized and advances in exploit techniques can unexpectedly rescale dormant flaws into critical risks.
I regularly review technical details and reassess metrics based on updated threat intelligence throughout the vulnerability lifetime. Risk ratings are fluid based on real-world exploit emergence, not just static technical qualities.
Remediation Level
This metric focuses on the state of fixes available for a vulnerability, either from the vendor or third-parties. It aims to quantify how effectively the core weakness can be eliminated from affected systems.
The Remediation Level has a very tangible impact on how I respond to threats. Flaws without fixes require implementing restrictive workarounds that hamper usability and productivity. On the other hand, with comprehensive vendor-provided patches, I can rapidly eliminate risks at the root.
CVSS v3.1 defines five possible values:
| Value | Abbreviation | Score |
| Not Defined | X | 1 |
| Unavailable | U | 1 |
| Workaround | W | 0.97 |
| Temporary Fix | T | 0.96 |
| Official Fix | O | 0.95 |
Not Defined (1.0)
Insufficient information to determine if any fixes exist.
Worst-case High risk rating assigned due to uncertainty.
I enforce maximum isolation rules as a precaution until more details emerge.
Official Fix (0.95)
Vendor has released complete fixes, usually through patches, software upgrades, or other official supported means.
These completely eliminate the root weakness rather than just treating the symptoms.
Once patches are tested and verified in staging environments, I rollout deployment enterprise-wide as rapidly as change controls permit. This eliminates the requirement of maintaining interim restrictive workarounds.
Temporary Fix (0.96)
The fixes are limited in scope and interim, mitigating only some attack vectors related to the weakness.
Original flaw may still remain exploitable under certain conditions.
Vendors develop these stopgaps while working on an official fix to buy extra remediation time.
I deploy temporary fixes or mitigations if official patches are delayed but active attacks escalate risk. But I continue tracking vendor security advisories closely for arrival of comprehensive fixes so these short-term measures can be rolled back.
Workaround (0.97)
Unofficial mitigations developed by third-party security researchers or IT community.
Shared via public blogs, forums rather than vendor-supported channels.
Usually quite restrictive and not eliminating root cause.
With no vendor support for fixing vulnerabilities in legacy solutions, I often have to rely on unstable workarounds. These tend to impair functionality and productivity until migration modern platforms is feasibile.
Unavailable (1.0)
No fixes exist yet, leaving systems completely vulnerable.
Forced to endure risk exposure for extended periods waiting on vendors.
The most dreaded scenario that necessitates making hard decisions on mitigating business impact. I isolate unaffected systems to limit blast radius while weighing options like temporary suspension of vulnerable services.
Continuous pressure on vendors to deliver fixes is critical else flaws can persist for months or even indefinitely. Custom application code audits by security firms may become unavoidable despite the effort and costs.
Report Confidence
This metric indicates the credibility of vulnerability reports, typically made by third-party security researchers and vendors. It aims to minimize acting on unvalidated threats that turn out overblown or false.
I routinely come across flaw disclosures from previously unknown researchers. However, before taking potential disruptive action like patching production systems, the claims must be validated. This metric helps quantify confidence in the report’s accuracy.
CVSS v3.1 defines four levels of Report Confidence:
| Value | Abbreviation | Score |
| Not Defined | X | 1 |
| Confirmed | C | 1 |
| Reasonable | R | 0.96 |
| Unknows | U | 0.92 |
Confirmed (1.0)
Detailed technical writeup of testing methodology and observations provided.
Hard evidence like proof-of-concept exploit code demonstrations lend high credibility.
Indicates high likelihood of reproducible outcomes across environments.
Such well-documented reports from reputable sources are assigned high confidence. I expedite testing and remediation rollout after ensuring report accuracy.
Reasonable (0.96)
Supporting details around observations provided but some gaps exist.
Potential alternate explanations for behaviors seen.
Not independently validated by third-parties.
While potentially still legitimate, I don’t accept claims at face value without scrutiny. I consult vulnerability databases and monitor threat feeds for more evidence.
Unknown (0.92)
Very limited information about methodology and observations made public.
Validity cannot be ascertained based on available data so weighted conservatively.
With inadequate data to judge report credibility, I enforce precautionary measures until more details emerge. This avoids reacting prematurely to unsubstantiated threats.
Not Defined (1.0)
Used when processing new threat reports before having time to ascertain details.
Defaults to worst-case High rating early on due to uncertainty around credibility.
My typical process is to designate new unvalidated findings as Not Defined temporarily. This ensures adequate protections are adopted in the interim during actual confirmation testing.
Isolating affected assets until report confidence improves prevents neglecting severe threats. Regularly revisiting metrics to adjust response urgency is key against a fluid threat landscape.
Real-World Example of Scoring Temporal Metrics
Recently, I came across a critical remote code execution vulnerability in OpenSSL disclosed by a reputable researcher. Assessed using the CVSS Temporal Metrics, the threat level was:
Exploit Code Maturity: High (1.0) – Public exploits released.
Remediation Level: Temporary Fix (0.96) – Vendor issued temporary mitigations.
Report Confidence: Confirmed (1.0) – Researcher released technical details.
This urgent risk rating prompted me to immediately implement the temporary server configuration changes. I also tracked the vendor’s progress on an official patch through their security advisories.
Within two weeks, the vendor released the official fix which I could rapidly roll out. This eliminated the root cause instead of simply treating the symptoms.
Extending Assessment to Environmental Metrics
In addition to Base and Temporal metrics, CVSS includes Environmental metrics that quantify organizational and system-specific factors. These answer questions like:
What confidentiality level do we classify the server data as per regulatory policies?
What are the compliance implications if server availability is disrupted due to an attack?
Would the vulnerability allow access to other connected backend systems?
By tailoring scores to my unique environment using these metrics, I can further improve accuracy. For example, a vulnerability on a server storing sensitive customer data would warrant higher priority than the same issue on a HR application.
Conclusion
To summarize, analyzing CVSS Temporal Metrics enables me to focus remediation efforts on actively exploited vulnerabilities that can actually impact real systems. Relying solely on technically-oriented Base Metrics has led to chasing “ghosts” in the past – flaws that are intriguing but have no real-world attacks.
Now, by incorporating threat intelligence and considering relevant organizational factors, I can patch rapidly without getting distracted by hypothetical risks. This balanced approach has helped refine our vulnerability management program. What has your experience been with utilizing CVSS for prioritization? I would love to hear other perspectives.
We hope this post helped in learning about how i calculated CVVSS temporal metrics for a vulnerability. Thanks for reading this post. Please share this post and help secure the digital world. Visit our website, thesecmaster.com, and our social media page on Facebook, LinkedIn, Twitter, Telegram, Tumblr, Medium, and Instagram and subscribe to receive updates like this.
Arun KL
Arun KL is a cybersecurity professional with 15+ years of experience in IT infrastructure, cloud security, vulnerability management, Penetration Testing, security operations, and incident response. He is adept at designing and implementing robust security solutions to safeguard systems and data. Arun holds multiple industry certifications including CCNA, CCNA Security, RHCE, CEH, and AWS Security.
