How I Assessed Vulnerabilities that Don’t Have CVE Identifier and CVSS Score?

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:

  1. The vulnerability may not have been publicly disclosed yet and so a CVE has not been assigned.

  2. The software vendor may not participate in the CVE assignment process.

  3. 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.

Understanding CVSS

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.

See also  How To Export A Private Key File From A Windows Machine?

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.

My Process for Evaluating Vulnerabilities

When faced with a vulnerability lacking CVE/CVSS information, I follow these key steps to analyze and score it appropriately:

Step 1: Gather All Available Information

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.

Step 2: Analyze Base Severity Metrics

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.

Step 3: Calculate Base Severity Score

Once base metrics are determined, I can generate the Base Score using the CVSS Calculator.

See also  How to Enable TLS 1.2 and TLS 1.3 on Windows Server?

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.

Step 4: Evaluate Temporal and Environmental Factors

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.

Step 5: Document Assessment

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

Real-World Example

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.

Step 1: Information Gathering

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

Step 2: Base Metrics Analysis

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.

Step 3. Score 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.

See also  How to Start Preparing for CISSP? What Resources Are to be Used for CISSP Preparation?

Step 4. Analyze Temporal & Environmental Metrics

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.

Step 5: Document Assessment

Finally, I compiled full details into a vulnerability assessment document for tracking and future analysis.

Conclusion

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!

Leave a Reply

Your email address will not be published. Required fields are marked *