Week8: Vulnerability Management

Week-8 Vulnerability Management (VM)

From Discovery to Scoring and Building Resilience

Ali Jaddoa,

Ali.Jaddoa@roehampton.ac.uk

Date: of Nov 2025


25/26
Week8: Vulnerability Management

What Are Vulnerabilities?

A vulnerability is a weakness that an attacker can exploit.

  • Common causes include design flaws, coding errors, poor configuration, or missing security controls.
  • Over 259000 unique vulnerabilities were listed in the NVD by Aug 2024 (NVD, 2024).
  • Zero-day vulnerabilities are unknown to the vendor and exploited before a patch exists.
    Example: Stuxnet used several zero-day flaws to compromise Iran’s nuclear systems.

25/26
Week8: Vulnerability Management

Main Categories of Vulnerabilities

  • Hardware
    Flaws in physical components. Examples include Meltdown, Spectre, and Rowhammer-style attacks. More...

  • Software
    Bugs from poor coding, weak validation, or inadequate testing. Examples include buffer overflows and injection flaws.

  • Network
    Weak configurations such as open ports, outdated protocols, or weak firewalls.

  • Human Factors
    Errors like weak passwords, phishing, or mishandling sensitive data.


25/26
Week8: Vulnerability Management

Vulnerability Management: The Challenge

  • Modern computer systems are complex
  • Errors and vulnerabilities exist in both software and hardware
  • Vendors work to patch vulnerabilities, but new ones emerge constantly
  • Organisations need a structured approach to handle them

25/26
Week8: Vulnerability Management

The Vulnerability Life Cycle

A process that manages a vulnerability from discovery to resolution.
1. Discovery Finding vulnerabilities (More in the Term with security testing and operation)
2. Classification (CWE) Categorising weakness type (TODAY)
3. Identification (CVE) Assigning a global ID (TODAY)
4. Scoring (CVSS) Measuring severity (main focus) (TODAY)
5. Prioritisation (KEV) Identifying active exploitation (TODAY)
6. Resilience & Redundancy Preparing systems to withstand attacks (TODAY)

25/26
Week8: Vulnerability Management

Why VM?

  • Converts raw vulnerability data into actionable priorities
  • Ensures consistent scoring across platforms and vendors
  • Supports risk-based patching and resource allocation
  • Integrates with resilience planning to reduce impact before patchin

25/26
Week8: Vulnerability Management

Vulnerability lifecycle: Once more

width:10O% center

1. Discovery (Next Term with Cyber Operation and Testing)

  • How vulnerabilities are found: pentesting, bug bounties, research, incident analysis.
  • We assume discovery is complete - our focus is what happens next.

25/26
Week8: Vulnerability Management

2. Classification: CWE (Common Weakness Enumeration)

  • Community-developed list of common software and hardware weakness types
  • Maintained by MITRE
  • Focuses on categories of flaws rather than specific instances
  • Provides a common language for describing weaknesses
  • Enables root cause analysis to prevent recurrence
  • Supports security tools in identifying and reporting issues consistently
  • Serves as a bridge between weakness types and specific vulnerabilities (CVEs)

25/26
Week8: Vulnerability Management

Activity : Take 5 mins

What is the difference betweeen Weakness vs Vulnerability?


25/26
Week8: Vulnerability Management

Weakness vs Vulnerability

  • Weakness - root cause condition (e.g., missing authentication, improper bounds check)
  • Vulnerability - an instance of one or more weaknesses in a specific product
  • CWE focuses on root cause
Weakness Vulnerability
Weak password policy A specific system allows passwords as short as 3 chars
Poor input validation A shopping site lets attackers enter harmful text
Missing access control An employee portal lets anyone view salary records
Insecure data storage A mobile app saves customer data without encryption
Unprotected admin interface A device’s admin page is open to the public internet

25/26
Week8: Vulnerability Management

CWE Structure & Mapping Levels

CWE Structure Diagram
  • Over 900 weaknesses, ranging from abstract to very specific.
  • Four abstraction types:
      Pillar; Class; Base; Variant
  • For root cause mapping, use Base or Variant when possible.
  • Each CWE has a mapping label:
    • Allowed - can map to vulnerabilities
    • Allowed (with review) - use with caution
    • Discouraged - avoid mapping
    • Prohibited - must not be used for mapping

25/26
Week8: Vulnerability Management

CWE Structure & Mapping Levels

CWE Views Diagram
  • Developer View (699) - ~400 common software weaknesses, 2 levels deep
  • Research View (1000) - deep tree, 10 high-level pillars
  • NVD View (1003) - ~130 most common weaknesses in NVD
  • Hardware Design View (1194) - ~100 hardware-specific weaknesses
  • Software Assurance Trends View (1400) - 22 high-level categories for large-scale analysis

25/26
Week8: Vulnerability Management

What Does a CWE Include?

CWE Element Description
ID & Name Unique number and descriptive title (e.g., CWE-798: Use of Hard-coded Credentials)
Summary 1-2 sentences describing the weakness, focusing on the mistake made
Extended Description More detail on why it’s a problem and its context
Modes of Introduction How/when the weakness can appear in the product lifecycle
Potential Mitigations Techniques to prevent or reduce the frequency/impact
Common Consequences Typical negative impacts if exploited
Applicable Platforms Languages, OSs, architectures, or tech where found
Demonstrative Examples Code, diagrams, or explanatory text showing the weakness
Observed Examples Real-world CVEs that exhibit the weakness
Relationships Links to other related CWE entries
References External resources such as papers, blogs, or videos

25/26
Week8: Vulnerability Management

CWE Examples
CWE-79 Improper Neutralization of Input During Web Page Generation (Cross-site Scripting) - Web apps fail to properly filter or encode user input, allowing injection of malicious scripts.
CWE-89 Improper Neutralization of Special Elements used in an SQL Command (SQL Injection) - Application improperly constructs SQL queries using unsanitized input.
CWE-120 Buffer Copy without Checking Size of Input (Classic Buffer Overflow) - Program writes data past the end of an allocated memory buffer.
CWE-798 Use of Hard-coded Credentials - Passwords or keys embedded in code, allowing attackers to gain unauthorized access.
CWE-352 Cross-Site Request Forgery (CSRF) - Application does not verify if a request was intentionally made by the authenticated user.

25/26
Week8: Vulnerability Management

How to Look It Up for an CWE

  1. Go to https://cwe.mitre.org/
  2. In the search box, type CWE-79
  3. Open the result and review:
    • Summary
    • Examples
    • Mitigations

25/26
Week8: Vulnerability Management

3. Identifiction - CVE: Common Vulnerabilities and Exposures

  • CVE = Common Vulnerabilities and Exposures
  • Provides a unique identifier for a specific vulnerability
  • Maintained by MITRE and CVE Numbering Authorities (CNAs)
  • Format: CVE-YYYY-NNNNN
    Example: CVE-2024-12345
  • Used globally to ensure everyone refers to the same vulnerability

25/26
Week8: Vulnerability Management

Purpose of CVE

  • Consistency - One ID for a vulnerability across all reports
  • Clarity - Avoids confusion between similar flaws
  • Tracking - Links to security databases and advisories
  • Integration - Connects with:
    • CWE for weakness type
    • CVSS for severity score
    • KEV for exploitation status

25/26
Week8: Vulnerability Management

CWE vs CVE

CWE CVE
Describes weakness types Lists specific vulnerabilities
Focuses on what could go wrong Focuses on what actually went wrong
Helps with prevention and secure design Helps with remediation and patching
Generic categories like CWE-79 (XSS) Real incidents like CVE-2021-44228 (Log4Shell)

CWE = theory and patterns, used to avoid mistakes
CVE = real world cases, used to fix mistakes


25/26
Week8: Vulnerability Management

How to Look Up a CVE

  1. Go to https://www.cve.org/
  2. Enter the CVE ID in the search bar (e.g., CVE-2024-12345)
  3. Review:
    • Description - What the flaw is
    • Affected Products - Versions impacted
    • References - Vendor advisories and patches

25/26
Week8: Vulnerability Management

Example CVE

CVE-2021-44228 - Apache Log4j Remote Code Execution

  • Summary: Log4j versions 2.0-2.14.1 allow attackers to execute arbitrary code via crafted log messages.
  • Impact: Widespread exploitation, critical remote execution vulnerability.
  • References: Apache advisory, NVD entry, security blogs.

25/26
Week8: Vulnerability Management

4. Scoring/Measuring Severity - Using CVSS:

Common Vulnerability Scoring System

  • Open standard for measuring vulnerability severity
  • Developed by FIRST (Forum of Incident Response and Security Teams)
  • Produces a score from 0.0 to 10.0, Increment of
  • Helps prioritise remediation efforts

25/26
Week8: Vulnerability Management

Purpose of CVSS

  • Consistent scoring of vulnerabilities across platforms
  • Allows comparison of different vulnerabilities
  • Supports risk-based prioritisation
  • Widely used in vulnerability management tools and databases

25/26
Week8: Vulnerability Management

CVSS Scoring Components

  1. Base Metrics - Intrinsic characteristics of the vulnerability (constant over time)
  2. Threat Metrics - Current likelihood of exploitation
  3. Environmental Metrics - Context-specific impact to your organisation
  4. Supplemental Metrics - Additional details (e.g., safety, automation)

25/26
Week8: Vulnerability Management

CVSS v4.0 Metrics

1. Base Metrics ()
Attack Vector (AV) Network (N), Adjacent (A), Local (L), Physical (P) How far the attacker must be from the target. Network means remote, physical means direct access.
Attack Complexity (AC) Low (L), High (H) How many conditions the attacker must overcome. High means extra steps or conditions.
Privileges Required (PR) None (N), Low (L), High (H) The level of access the attacker needs before exploiting the flaw.
User Interaction (UI) None (N), Required (R) Whether a victim must do something, such as clicking a link.
Confidentiality (C) None (N), Low (L), High (H) How much data exposure the exploit causes.
Integrity (I) None (N), Low (L), High (H) How much the attacker can alter data.
Availability (A) None (N), Low (L), High (H) How much the exploit disrupts system or service uptime.

N = remote over internet ; A = same network ; L = needs local access ; P = physical contact ; N is highest risk


25/26
Week8: Vulnerability Management

CVSS v4.0 Metrics

2. Threat Metrics

Metric Options Explanation
Exploit Maturity (E) Not Defined (X), Proof-of-Concept (P), Functional (F), High (H) How developed the exploit is. Proof-of-concept means basic code exists, high means widely available and reliable.
Confidentiality (C) Unknown (U), Reasonable (R), Confirmed (C) How certain we are that confidentiality is affected. Confirmed means evidence clearly shows data exposure.

25/26
Week8: Vulnerability Management

CVSS v4.0 Metrics

3. Environmental Metrics

Metric Options Explanation
Confidentiality Requirement (CR) Low (L), Medium (M), High (H) How important protecting data secrecy is for the environment being assessed.
Integrity Requirement (IR) Low (L), Medium (M), High (H) How critical it is to keep data accurate and unaltered.
Availability Requirement (AR) Low (L), Medium (M), High (H) How essential system uptime and service continuity are.
Modified Base Metrics Modified AV, AC, PR, UI, C, I, A Adjusted values that reflect how the specific environment changes the impact or likelihood.

25/26
Week8: Vulnerability Management

CVSS v4.0 Metrics

4. Supplemental Metrics

Metric Options Explanation
Safety (S) None (N), Environmental (E), Human (H) Whether the vulnerability could harm the environment or people, rather than just systems.
Automatable (AU) No (N), Yes (Y) Whether the attack can be reliably automated without human steps.
Provider Urgency (PU) Not Defined (X), Low (L), Medium (M), High (H) How urgent the vendor considers fixing the issue based on impact and exposure.
Recovery (R) Not Defined (X), Low (L), Medium (M), High (H) How difficult it is to recover systems after exploitation.
Value Density (VD) Not Defined (X), Low (L), Medium (M), High (H) How much valuable data or assets are concentrated in the affected system.
Vulnerability Response Effort (VRE) Not Defined (X), Low (L), Medium (M), High (H) The effort needed for organisations to apply fixes, mitigations, or updates.

25/26
Week8: Vulnerability Management

Example:

CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Metric Name Value Meaning Interpretation
Attack Vector (AV) Local (L) Attacker must have local access to the system. Someone already on the machine can exploit it.
Attack Complexity (AC) Low (L) Exploit is straightforward with few conditions. The attack is easy to carry out.
Attack Technique (AT) Human (P) The attack requires a person rather than automated tools. Manual attacker action is needed.
Privileges Required (PR) Low (L) Attacker needs a basic account with limited rights. A normal user account is enough to exploit.
User Interaction (UI) None (N) No victim action is required. The attack runs without clicks or prompts.
Confidentiality Impact (VC) High (H) Significant loss of data confidentiality. Sensitive data could be accessed or leaked.
Integrity Impact (VI) High (H) Serious effects on data accuracy. Data could be modified or corrupted.
Availability Impact (VA) High (H) Major disruption of service availability. The system could crash or become unusable.
Safety: Environmental (SC) None (N) No environmental safety consequences. No harm to environmental systems.
Safety: Human (SI) None (N) No direct physical risk to people. Human safety is not affected.
Safety: Asset (SA) None (N) No physical asset safety impact. Hardware and equipment are not at risk.

25/26
Week8: Vulnerability Management

Overall interpretation

  • The vulnerability is easy to exploit, requires only low privileges, and no user interaction.
    Its impact on confidentiality, integrity, and availability is high, so it represents a high-severity risk.

  • Although it does not affect safety, the technical damage is significant and remediation should be prioritised.


25/26
Week8: Vulnerability Management

5. Prioritisation using KEV

The KEV catalogue is a public list managed by CISA that records vulnerabilities which are confirmed to be actively exploited by attackers.

Why

  • A vulnerability in KEV is not theoretical. It is already being used in real attacks.
  • This makes it a higher priority than vulnerabilities with a similar CVSS score but no known exploitation.
  • CISA also provides remediation deadlines, which helps organisations decide what to fix first.

25/26
Week8: Vulnerability Management

How KEV is used:

  • Combine CVSS severity with KEV status.

    • Example: a Medium CVSS vulnerability that appears in KEV may become a higher priority than a High CVSS issue that is not exploited.

  • Helps organisations focus on the vulnerabilities that pose the most immediate real-world risk.


25/26
Week8: Vulnerability Management

Example:

  • CVE-2021-44228 (Log4Shell) - Added to KEV in Dec 2021
  • CVSS: 10.0 (Critical)
  • Actively exploited by multiple threat actors worldwide

25/26
Week8: Vulnerability Management

6. Resilience & Redundancy

Beyond detection and prioritisation


25/26
Week8: Vulnerability Management

Where They Fit

  • CWE: Describes the type or category of the weakness
  • CVE - Identifies the specific vulnerability
  • CVSS - Scores the severity
  • KEV - Confirms active exploitation
  • Resilience & Redundancy - Keep systems running even before a fix is applied

25/26
Week8: Vulnerability Management

Redundancy

  • Backup components or systems ready to take over
  • Examples:
    • Standby servers and failover clusters
    • Data replication across sites
    • Load balancing

25/26
Week8: Vulnerability Management

Resilience (More in Inciednet Response Week)

  • System’s ability to absorb and recover from attacks
  • Examples:
    • Segmented networks
    • Defence in depth
    • Automated incident response

25/26
Week8: Vulnerability Management

Why It's important:

If KEV flags a vulnerability as actively exploited and a patch can’t be applied immediately, resilience and redundancy buy time and limit damage until remediation is complete.


25/26
Week8: Vulnerability Management

Lab and Acticities


25/26

![width:1OO% height:200px center](../../figures/stepsvulmang.png)

![CWE vs CVE](imgs/cwe-cve.png)

--- ### How to Use KEV 1. Visit **https://www.cisa.gov/known-exploited-vulnerabilities-catalog** 2. Search by CVE ID or keyword 3. Check: - **Exploitation status** (confirmed active) - **Due date** for remediation - **Links** to vendor advisories and technical details

## Another Model Prioritisation ### [Exploit Prediction Scoring System (EPSS)](https://www.first.org/epss/) EPSS estimates the probability that a CVE will be exploited in the next 30 days. - It uses vulnerability metadata, public exploit data, threat-intelligence feeds, and real-world attack telemetry to train a predictive model. - Scores range from 0 to 1 and update daily. **Why**? - Helps prioritise which vulnerabilities to patch first. - Complements CVSS by focusing on likelihood, not severity. - Organisations choose their own EPSS thresholds based on risk appetite. ---