As a security analyst, one of my main responsibilities is to assess vulnerabilities in my organization’s systems and networks. This process allows me to understand the risks posed by vulnerabilities and prioritize remediation efforts.
A key part of assessing vulnerabilities is looking at their Common Vulnerabilities and Exposures (CVE) identifier and Common Vulnerability Scoring System (CVSS) score. The CVE identifier uniquely identifies publicly disclosed vulnerabilities, while the CVSS score indicates the severity of the vulnerability.
However, sometimes I come across vulnerabilities that don’t have a CVE identifier or CVSS score. This can happen for a few reasons:
The vulnerability may not have been publicly disclosed yet and so a CVE has not been assigned.
The software vendor may not participate in the CVE assignment process.
The vulnerability may have been identified by my own testing and analysis.
When this happens, I need to leverage my skills in assessing vulnerabilities that don’t have CVE identifier and determining risk.
In this blog post, I’ll walk through my process for assigning the CVSS score for a newly identified vulnerabilities so that I can understand the risk it poses.
Before we get into the details, let’s do a quick overview of CVSS. The CVSS scoring system provides a standardized way to assess the severity of vulnerabilities. The overall CVSS score is calculated using three metric groups:
Base Score: intrinsic qualities of a vulnerability that do not change over time (attack vector, attack complexity, privileges required, user interaction, scope, confidentiality, integrity, availability impacts)
Temporal Score: characteristics of a vulnerability that do change over time (exploit code maturity, remediation level, report confidence)
Environmental Score: qualifications from the perspective of users, assets, and environments (security requirements, modified base metrics)
These metrics are combined using the CVSS formula to calculate an overall score between 0-10, with higher scores indicating more severe vulnerabilities.
CVSS helps identify high-risk vulnerabilities, allowing me to prioritize mitigation efforts. When a vulnerability doesn’t have a CVE or CVSS score, I need to leverage the CVSS methodology to analyze the vulnerability and assign a score myself.
When faced with a vulnerability lacking CVE/CVSS information, I follow these key steps to analyze and score it appropriately:
I start by gathering as much information as possible about the vulnerability:
Type of system/software affected
Versions affected
Components affected (e.g. function, module, protocol)
Vulnerability details provided by the discoverer/reporter
Any vulnerability details I can uncover myself through testing and research
Exploits that target the vulnerability
Related vulnerabilities in similar systems/components
I compile this into a single document so all relevant information is in one place for analysis.
Next, I leverage the CVSS framework to break down the base metrics that don’t require environmental or temporal context:
Attack Vector – How the vulnerable component can be exploited (e.g. network, adjacent network, local, physical)
Attack Complexity – Level of access or knowledge required to exploit
Privileges Required – Level of privileges needed before attack can occur
User Interaction – If user interaction is needed to exploit
Scope – Whether vulnerability in one component impacts resources beyond its scope
Confidentiality Impact – Effect on confidentiality of info/data
Integrity Impact – Effect on integrity of system/data
Availability Impact – Effect on availability of system/resources
I assign the appropriate values to each metric based on vulnerability details, CVSS category definitions, and using the worst-case assumptions when details are limited.
Key information like remote exploitability and authentication requirements help guide these choices.
Once base metrics are determined, I can generate the Base Score using the CVSS Calculator.
This provides the final 0-10 Base Score severity rating based on the inherent qualities of the vulnerability.
In situations with limited information, I tend to error on the side of caution with higher severity ratings.
If more information is available, I also evaluate temporal and environmental metrics:
Temporal
Exploit maturity
Remediation level
Report confidence
Environmental
Security requirements
Modified base metrics – tailored for environment
I then input these into the CVSS Calculator to produce environmental and overall severity scores.
Finally, I document the vulnerability assessment for reference, including:
Information gathered
Analysis worksheets
CVSS vector string
All calculated scores
Recommended remediation/mitigations
Plan for re-evaluation as new details emerge
To illustrate this process, let me walk through a real-world vulnerability lacking CVE/CVSS data that I recently analyzed.
A vulnerability was found in our bookkeeping software and allowed remote exploitation by an unauthenticated user.
irst, I gathered as much information as possible about the vulnerability:
Type of software affected
Versions affected
Vulnerability details provided by the vendor
Any additional vulnerability details I could uncover through research
Next, I analyzed the vulnerability’s characteristics to determine appropriate base metric values:
Attack Vector: Network (N) – remotely exploitable
Attack Complexity: Low (L) – no special access situation needed
Privileges Required: None (N) – authentication not required
User Interaction: None (N) – no user interaction needed
Scope: Unchanged (U)
Confidentiality Impact: Low (L) – some confidential data exposed
Integrity Impact: Low (L) – data modification unlikely
Availability Impact: None (N)
This analysis was based on the details provided by the vendor. The key phrases “remote exploitation” and “by an unauthenticated user” helped guide the base metrics.
I then input these base metrics into the CVSS Calculator to generate a Base Score. In this case, the Base Score came out to 6.5 or Medium severity.
I also analyzed temporal and environmental metrics that may affect the score:
No exploit code publicly released
Official vendor patch available
Software used for financial data
The lack of exploit code reduces severity, but the high confidentiality requirement for financial data increases it.
I updated the metrics and score in the CVSS Calculator:
Exploit Code Maturity: Unproven (U)
Remediation Level: Official Fix (O)
Confidentiality Requirement: High (H)
The overall CVSS v3.1 score increased to 7.6 or High severity based on the increased confidentiality requirement.
Finally, I compiled full details into a vulnerability assessment document for tracking and future analysis.
By leveraging the CVSS methodology, I was able to analyze a vulnerability without a CVE or CVSS score and determine that it poses a high amount of risk to my organization. I can now accurately communicate the severity of this vulnerability to management and prioritize applying the vendor-provided patch.
The process requires diligent information gathering and analysis – assessing vulnerabilities that don’t have CVE identifier can be difficult. But it allows me to fully understand the risks posed to my environment when CVE data is not available.
Prioritizing vulnerabilities without CVSS data is a key skill for security analysts. I hope this blog post provided some insight into my process and approach. As always, please share any feedback or questions!
We hope this post helped in learning about how i assessed vulnerabilities that don’t have CVE identifier and CVSS score. 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.
You may also like these articles:
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.
“Knowledge Arsenal: Empowering Your Security Journey through Continuous Learning”
"Cybersecurity All-in-One For Dummies" offers a comprehensive guide to securing personal and business digital assets from cyber threats, with actionable insights from industry experts.
BurpGPT is a cutting-edge Burp Suite extension that harnesses the power of OpenAI's language models to revolutionize web application security testing. With customizable prompts and advanced AI capabilities, BurpGPT enables security professionals to uncover bespoke vulnerabilities, streamline assessments, and stay ahead of evolving threats.
PentestGPT, developed by Gelei Deng and team, revolutionizes penetration testing by harnessing AI power. Leveraging OpenAI's GPT-4, it automates and streamlines the process, making it efficient and accessible. With advanced features and interactive guidance, PentestGPT empowers testers to identify vulnerabilities effectively, representing a significant leap in cybersecurity.
Tenable BurpGPT is a powerful Burp Suite extension that leverages OpenAI's advanced language models to analyze HTTP traffic and identify potential security risks. By automating vulnerability detection and providing AI-generated insights, BurpGPT dramatically reduces manual testing efforts for security researchers, developers, and pentesters.
Microsoft Security Copilot is a revolutionary AI-powered security solution that empowers cybersecurity professionals to identify and address potential breaches effectively. By harnessing advanced technologies like OpenAI's GPT-4 and Microsoft's extensive threat intelligence, Security Copilot streamlines threat detection and response, enabling defenders to operate at machine speed and scale.