CVSS vs EPSS – Why EPSS is More Practical in Real-World Operations

• CVSS (Common Vulnerability Scoring System)

  • Designed to be universal and standardized.

  • Provides a severity score (0–10) based on exploitability + impact metrics.

  • Issues in practice:

    • Many CVEs end up with high scores (7–10) → alert fatigue.

    • CVSS does not factor in whether a vuln is being actively exploited in the wild.

    • Static → doesn't change once published, even if threat landscape evolves.

• EPSS (Exploit Prediction Scoring System)

  • Focuses on likelihood of exploitation in the next 30 days.

  • Uses real-world data (threat intel feeds, malware samples, honeypots, etc.).

  • Why it's more practical:

    • Lets you prioritize patching based on threat activity, not just theoretical risk.

    • A CVE with CVSS 9.8 but EPSS 0.2% = probably low urgency.

    • A CVE with CVSS 6.5 but EPSS 80% = patch immediately.

  • Best practice: Use CVSS for baseline severity and EPSS for prioritization.

In short: CVSS = “impact if exploited”, EPSS = “chance it will be exploited soon”.
Combining both prevents wasted effort on “paper tigers”.

How to check for Vulnerabilities using SOCFortress SIEM

Option 1 – Using SOCFortress Copilot

Lon into your Copilot instance, and from there Agents – Agents List

Select an agent (left panel) and go to the “Vulnerabilities” tab:

Vulnerabilties can be listed by priority.

Obtaining full details for any given vulnerability.

Select a vulnerability and a new panel will show the following information:

- General data for this particular CVE:

- External reference (vendor's info about this CVE)

- EPSS Score:

Option 2 – Using Wazuh UI

Log into your Wazuh UI instance and navigate to Threat Intelligence – Vulnerability Detection:

NOTE: The vulnerabilty module included in Wazuh does NOT include EPPS values out of the box. These scores are available via SOCFortress integration.

Option 3 – Using Grafana

Only avaiable in the MSP/MSSP organization in Grafana.

Since the vulnerability module doesn't take into account agent's group, all the vuln for all tenants will be displayed.

It is not possible to create separate dashboards for each tenant.

In this dshboard there's a panel with CVE IDs and a direct link to EPSS API to check their exploitation scores:

Prioritization Strategy for Patching Endpoints

When deciding what to patch first, think of it as a matrix of three dimensions:

1. Threat likelihood → (EPSS, threat intel, active exploits).

2. Technical severity → (CVSS, local exploitability, privilege required).

3. Business impact / criticality → (asset value, role in operations, exposure).

Concrete approach:

• Critical servers & internet-facing assets first (domain controllers, VPN gateways, jump hosts, web servers).

• Business-critical endpoints/apps (finance systems, endpoint agents that handle sensitive data, executive laptops).

• High-risk vulns (high EPSS, known exploited CVEs → per CISA KEV catalog).

• Everything else → regular cycle.

A good formula for prioritization is:
Risk = (CVSS Score × EPSS Probability × Asset Criticality Weight)

Practical Guide: Asset Criticality Weighting

We'll use a 1–5 scale (1 = low, 5 = highest) that plugs into your risk formula:

Risk = (CVSS × EPSS × Criticality Weight)

Domain & Identity Infrastructure

• Domain Controllers, AD FS, LDAP servers → Weight 5

  • Compromise = total domain compromise.

  • Identity = single point of failure for authentication.

• PKI / Certificate Authorities → Weight 5

  • Forged certificates = invisible lateral movement.

Network & Perimeter

• Firewalls, VPN gateways, reverse proxies, WAFs → Weight 5

  • Internet-exposed, first line of defense.

  • Compromise often leads to immediate access.

• Routers, core switches → Weight 4

  • Network availability + traffic control.

  • Exploits can enable man-in-the-middle or outage.

NOTE: More on vulnerability management for network devices later in this article

Core Business & Application Servers

• Email servers (Exchange, O365 hybrid) → Weight 5

  • Initial access vector, sensitive comms.

• ERP, Finance, HR, CRM systems → Weight 5

  • Directly tied to regulatory & financial risk.

• File servers with sensitive/confidential data → Weight 4–5

  • Depends on data classification.

• Application servers (internal, not business-critical) → Weight 3

Endpoints & User Devices

• Executive laptops / privileged user endpoints → Weight 4–5

  • High-value target, lateral movement potential.

• Standard employee workstations → Weight 2–3

  • Still important, but impact is limited compared to infra servers.

• Kiosk / shared devices → Weight 1–2

  • Low data value, easy to reimage.

Special Categories

• OT/ICS systems → Weight 5

  • Safety, uptime, compliance risk.

• SIEM / SOC tooling, Backup servers → Weight 5

  • Compromise = blind defenders, lost recovery ability.

• Dev/Test environments → Weight 1–2

  • Unless directly exposed or sharing creds with prod.

How to Operationalize It

1. Tag assets in CMDB/EDR/AD with categories:

   • role=domain_controller

   • role=finance_server

   • role=workstation_standard

2. Assign weights automatically based on role → feeds into risk calculation.

3. Review quarterly with IT + business owners:

   • E.g., “Does this new cloud HR system count as critical?”

4. Refine scoring with exposure:

   • Critical system + internet-exposed = extra multiplier.

   • Example: Exchange on-prem OWA facing internet → 5 × 2.

Summary table – Asset Criticality

Example in Practice

• CVE-2025-1234

  • CVSS = 8.8

  • EPSS = 0.7 (70% chance exploited soon)

  • Asset = Domain Controller (weight = 5)

    Risk = 8.8 × 0.7 × 5 = 30.8 (Very High Priority)

• Same vuln on a test lab server (weight = 1)
  Risk = 8.8 × 0.7 × 1 = 6.1 (Low Priority)

priority_score = (CVSS_base or 0) × (1 + EPSS) × criticality_weight × exposure_weight × KEV_multiplier