How I Assessed the Risk of Vulnerabilities on My Client’s Network?

As a cybersecurity consultant, one of the most critical tasks I undertake for clients is vulnerability assessment. This involves detecting vulnerabilities on their systems and networks, analyzing the risks they pose, and providing remediation advice.

I recently performed such an assessment for a client that operates an e-commerce platform. They were concerned about security gaps that could lead to a breach or service disruption. My goal was to methodically assess the risk of Vulnerabilities and prioritize the highest risks for remediation.

In this blog post, I’ll walk you through my process of evaluating vulnerabilities on my client’s infrastructure using the Common Vulnerability Scoring System (CVSS). I’ll explain some key concepts around CVSS and how I leveraged it to produce risk ratings and remediation guidance.

Overview of the Client’s Environment

My client operates a network of around 500 Windows servers across a mix of front-end web, application, and database tiers. Most of the servers run Windows Server 2016 or 2019. They utilize IIS for web services and SQL Server for their central database.

Additionally, they have various Linux-based appliances for security functions like firewalls and web application firewalls (WAFs). Client workstations run Windows 10 and macOS systems.

Starting with Vulnerability Scans

I kicked off the assessment by running vulnerability scans using Tenable.io. This gave me insight into security gaps across the client’s infrastructure.

After importing their assets into Tenable, I configured a range of vulnerability checks and policy compliance audits tailored to their environment. These included scans for:

  • Missing OS and application patches

  • Insecure system configurations

  • Default or weak passwords

  • Unnecessary services running

  • Outdated software components

I performed both authenticated and unauthenticated scans to identify issues that an insider or outsider attacker could potentially exploit.

Interpreting Scan Results with CVSS

The scans uncovered over 5,000 potential vulnerabilities that needed to be triaged and prioritized for remediation. Going through so many findings manually would have been ineffective and caused key risks to be overlooked.

This is where the Common Vulnerability Scoring System (CVSS) proved invaluable. CVSS provides a consistent methodology to gauge the severity level of vulnerabilities based on multiple factors. Specifically, it helps answer critical questions like:

  • How easy is it to exploit this vulnerability?

  • What level of access does an attacker need?

  • What’s the potential impact if exploited?

By leveraging the rich CVSS data attached to each finding by Tenable, I could objectively identify the most pressing risks across the client’s entire IT infrastructure.

Overview of CVSS Scores and Metrics

The Common Vulnerability Scoring System (CVSS) provides a standardized, flexible framework for rating the severity of software vulnerabilities in IT environments. CVSSv3.1, the latest version, includes rich vulnerability metrics across three categories:

CVSS produces a numerical score ranging from 0.0 to 10.0 for each vulnerability, with higher scores representing greater severity. Typically:

  • Scores 9.0+ are considered CRITICAL severity

  • Scores 7.0-8.9 are considered HIGH severity

  • Scores 4.0-6.9 are MEDIUM severity

  • Scores less than 3.9 are low severity

Severity Severity Score Range
None* 0.0
Low 0.1-3.9
Medium 4.0-6.9
High 7.0-8.9
Critical 9.0-10.0
Cvss 3 1 Vector

Base Metrics

Reflect the inherent qualities of a vulnerability that are constant over time and across user environments. The base metrics allow vulnerabilities to be ranked by their likelihood and impact of exploit.

See also  How To Fix The CVE-2021-40444 A New 0-Day MSHTML Remote Code Execution Vulnerability Targeting Windows Users?

Attack Vector (AV)

Defines the remoteness an attacker needs to initiate an attack that exploits the vulnerability:

  • Physical (P) – Exploitable only through physical access to the vulnerable system

  • Local (L) – Exploitable through local system access without privileges

  • Adjacent Network (A) – Exploitable from an adjacent network where traffic passes the vulnerable system

  • Network (N) – Exploitable across Layer 3 networks without adjacent access

  • Physical, Local, Adjacent Network have lower scores than remote Network vectors

Attack Complexity (AC)

Denotes the conditions beyond the attacker’s control that determine exploitability:

  • Low (L) – Specialized access conditions or extenuating circumstances do not exist. Default for most vulnerabilities.

  • High (H) – Significant configuration, policy, or special prerequisites obstruct straightforward exploit. Examples include requiring a capable authenticated user or needing to collect information leakage first. Much less common.

Privileges Required (PR)

Indicates the level of privileges an attacker would need on the target to exploit:

  • None (N) – The attacker can exploit the flaw without any prior access or privileges

  • Low (L) – Some level of non-admin or guest privileges required

  • High (H) – Admin-level privileges needed on target system to exploit

User Interaction (UI)

Captures whether user interaction on the vulnerable component is needed for successful compromise:

  • Not Required (N) – The vulnerability can be exploited solely via remote network access.

  • Required (R) – Exploiting requires a user to take some action such as visiting an attacker-controlled website or opening a malicious file.

Scope (S)

Evaluates if a successfully exploited vulnerability can access resources beyond its means:

  • Unchanged (U) – Compromising a vulnerable software component only gives limited access typical for that component

  • Changed (C) – Attackers can use the vulnerable component to access resources not ordinarily available to it

Security Impact Ratings

These metrics measure how a vulnerability, if successfully exploited, will directly impact confidentiality, integrity, and availability:

  • Confidentiality Impact – Target systems, data, or resources could leak information

  • Integrity Impact – Data or code could be altered without authorization

  • Availability Impact– Systems, networks, or resources could have degraded availability or even suffer a complete denial-of-service

Each impact rating receives a severity score of None, Low, or High based on assessed technical or business criticality.

Temporal Metrics

Represent the threat of vulnerabilities changing over time:

Exploit Code Maturity (E)

Considers whether exploitation code is publicly released and how sophisticated it is:

  • Unproven (U) – No exploit code is available or it is theoretical

  • Proof-of-Concept (P) – Unreliable demonstration code is available

  • Functional (F) – Exploit code works in most situations where prerequisites are met

  • High (H) – Automated attack tools are prevalent on multiple attack platforms

Remediation Level (RL)

Looks at whether and when official vendor patches or workarounds are available:

Report Confidence (RC)

Reflects the highest assessment of existence and accuracy of vulnerability details:

  • Unknown (U) – Major aspects of vulnerability are inferred with significant uncertainty

  • Reasonable (R) – Details are logically inferred or partially confirmed

  • Confirmed (C) – Vulnerability details are corroborated by multiple independent sources

Environmental Metrics

Enable customization of scores for a user’s unique IT environment by addressing:

Security Requirements (CR, IR, AR) – Sets the confidentiality, integrity, and availability requirements per organization standards for affected IT asset types.Allows adjusting impact ratings accordingly.

Overriding Base Metrics

CVSS allows advanced users to override the base metrics scores by substituting customized values that better reflect a specific target environment.

For example, the default base metrics may list a vulnerability’s Attack Vector (AV) as Network (N) – meaning it can be exploited remotely over a network.

However, if an organization’s environment implements strong network segmentation controls, that vulnerability may only be exploitable locally.

In this case, the security team could choose to override the AV as Local (L) instead by configuring a Modified Attack Vector (MAV) metric.

Represented in Vector String

When a base metric is overridden, the modified metric will be represented in the CVSS vector string format.

The modified metric ID precedes the original base metric ID with an upper-case M.

Using the prior example, the modified attack vector would appear as:

MAV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

The modified metrics allow organizations to adjust base scores to more accurately indicate risk levels within their unique environment constraints and security priorities.

However, given their complexity, modified metrics should only be leveraged by expert CVSS practitioners. Their inappropriate use could improperly skew scores.

Combined Metric Scoring

When defined, the modified metrics will override the respective base metrics in calculating the overall CVSS score. The base, temporal, and environmental metrics are then combined per the CVSS equations to compute a singular vector score. This final vulnerability score will be specialized to the target environment versus a generic rating across all users.

CVSSv3.1 provides a flexible hierarchy of metrics enabling highly customized vulnerability ratings tailored to users’ unique IT environments and security priorities. Proper application of CVSS delivers efficiency, consistency, and accuracy in assessing risk exposures.

Filtering Scan Findings by Severity

With thousands of vulnerabilities detected, I needed to reduce noise and highlight the most critical risks for prompt patching.

As a first step, I filtered to show only findings scoring 7.0 or higher in CVSS. This identified over 50 high severity vulnerabilities that represented an imminent threat to the environment if exploited.

I specifically called attention to ~15 issues scoring 10.0 in CVSS.

Adding Temporal Context

However, not all vulnerabilities marked “critical” require rushing to patch. The temporal metrics within CVSS also require consideration.

Some detected vulnerabilities like CVE-2015-1635 (MS15-034) related to a long-patched flaw in HTTP.sys from 2015. While technically still a “critical” bug in the base CVSS score, the patched status and age of the vulnerability reduces the actual risk significantly.

See also  How to Fix CVE-2023-20154- An Authentication Bypass Vulnerability in Cisco Modeling Labs?

Likewise, several other findings were for theoretical issues unlikely to affect this environment like CVE-2021-36934, a CVSS 10 RCE in the MySQL client from December 2021. However, my client doesn’t run MySQL clients at all.

By applying temporal context from CVSS about vulnerability age, patches, and exploit likelihood, I could filter out some of the false positives and noise from the high severity list.

Incorporating Environmental Factors

I also needed to account for environmental factors to determine realistic risk levels for this client.

Some detected medium severity vulnerabilities might actually pose serious harm depending on the affected asset. For example, CVE-2020-5902 on their F5 Big-IP load balancers allows for arbitrary file reads with a CVSS score of 7.5.

However, given the central role of the load balancers in maintaining website availability, any disruption of those systems severely impacts operations. By adjusting the environmental metrics in CVSS to maximize the availability (AR) requirement, the score for CVE-2020-5902 effectively rises to one of the highest priorities for rapid patching.

Conversely, some vulnerabilities like missing OS patches on ancillary systems may be annoying from a compliance standpoint, but realistically pose negligible risk. I could communicate these accordingly rather than diluting truly critical risks.

Presenting Actionable Remediation Guidance

Applying CVSS provided me both a risk-based ranking of vulnerabilities and specific details on remediation guidance needed for the client.

In my final report, I included user-friendly remediation instructions linked to each finding such as:

  • Step-by-step patching guidance for relevant CVEs

  • Configuration adjustments required to resolve findings

  • Instructions to upgrade outdated software versions

  • Recommendations to apply security hardening measures

I tailored these instructions to my client’s environment accounting for the systems affected, corporate change control processes, and impact to operations.

For the most critical verified risks, I provided short term mitigation advice as an interim containment measure before vendors issued patches. This included recommended firewall rule changes and vulnerability scanning recommendations.

By accompanying CVSS severity ratings with clear guidance for remediation methods suited for their infrastructure, I empowered the client to efficiently drive down risk and strengthen their security posture.

Conclusion

Prioritizing vulnerabilities is an overwhelming but essential process to manage security threats and compliance obligations. The CVSS framework gave me an efficient, standardized way to objectively identify the most pressing risks affecting this client across a sea of thousands of scan findings.

I continue consulting with them frequently as new threats emerge to evolv vulnerability assessment tips and hardening best practices. By combining CVSS data to focus remediation efforts with clear mitigation and patching advice, I’ve helped the client materially reduce risk while still concentrating on growing their core business.

What questions do you have on leveraging vulnerability management and CVSS more effectively? I welcome your feedback below!

Leave a Reply

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