Skip to main content

Threat & Environmental Metrics

7. Environmental Metrics: Scoring for Your Environment​

The Core Principle​

CVSS Base metrics represent the intrinsic technical severity of a vulnerability — what happens in a reasonable worst-case scenario on an unmitigated, generic deployment. The vendor who published the score has not seen your network topology, your compensating controls, or your data classification. Environmental metrics are how you apply that local knowledge as documented, auditable adjustments.

Per the CVSS v4.0 User Guide: "The Base Score represents a reasonable worst-case impact across different environments. The Environmental metrics allow organizations to customize scores based on the importance of the vulnerability to them."

Practical Environmental Metric Decisions​

Decision 1: Network Exposure

Vendor scored: AV:N (reachable from anywhere on the internet)

Scenario A — Internet-facing server:
  No change needed. AV:N reflects reality.

Scenario B — Internal VLAN, firewall-controlled:
  MAV:A (Modified Attack Vector: Adjacent)
  Documentation: "System resides on VLAN 10, firewall rule FW-2041 blocks
  all inbound access from WAN. Last verified: [date], Change ticket: [ID]"
  Score effect: -1.5 to -2.5 points typically

Scenario C — Jump host required, no direct network path:
  MAV:L (Modified Attack Vector: Local)
  Documentation: "SSH access only via jump-host JUMP-01, no direct routing
  from any external zone. Network diagram: NDG-004"
  Score effect: more significant reduction

Decision 2: Compensating Security Controls

Vendor scored: AC:L (low complexity — straightforward exploitation)

Your reality: system access requires:
  (1) VPN authentication with hardware MFA token
  (2) Jump host with session recording
  (3) IP allowlisting to specific bastion hosts

→ MAC:H (Modified Attack Complexity: High)
  "Exploiting this in our environment requires bypassing enterprise VPN
  (MFA-protected), jump host IP filtering, and session monitoring.
  Policy reference: NET-POLICY-022"

Decision 3: Data Sensitivity

Vendor scored: VC:H (high confidentiality impact — assumes worst-case data)

Scenario A — System processes PII, financial, or health data:
  No change. VC:H is appropriate.
  Consider setting CR:H to amplify the score.

Scenario B — System is a build server, processes only source code and
artifact hashes, no customer data:
  MVC:L (Modified Vulnerable System Confidentiality: Low)
  Documentation: "System data classification: Internal/Technical per
  DLP-2023. No PII, financial, or regulated data categories."

Decision 4: Blast Radius (Subsequent System Impact)

Vendor scored: SC:H/SI:H/SA:H (can affect downstream systems)

Your reality: this system has no outbound connections except to its
own read-only database. No service accounts with lateral movement
potential. Network segmentation enforced by firewall.

MSC:N / MSI:N / MSA:N
Documentation: "System [ID] network connections: inbound from [A,B],
outbound to [DB-READONLY] only. Firewall egress rules [FW-2201 through
FW-2203] block all other outbound. Network architecture diagram NDG-007."

Decision 5: Security Requirements — Adjusting for Asset Criticality

Security Requirements (CR/IR/AR) work differently from Modified Base metrics. Instead of overriding vendor assumptions, they adjust the score up or down based on how important CIA is for this asset in your organization:

High-criticality asset (production customer database):
  CR:H / IR:H / AR:H
  → Score increases above the environmental-adjusted Base
  → The same vulnerability is MORE severe here than the vendor assumed

Low-criticality asset (developer test environment):
  CR:L / IR:L / AR:L
  → Score decreases below the environmental-adjusted Base
  → The same vulnerability is LESS severe here

Same vulnerability, CVE-2023-44487 (HTTP/2 Rapid Reset):
  On production CDN edge:  BTE = 8.9 High (AR:H — availability critical)
  On dev test instance:    BTE = 3.2 Low  (AR:L — availability optional)

Environmental Adjustment Documentation Template​

CVE: [CVE-XXXX-XXXXX]
Asset: [system name / ID]
Asset Classification: [Confidentiality: L/M/H] [Integrity: L/M/H] [Availability: L/M/H]

Base Vector (from NVD):
  [CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H]
  Base Score: [10.0 Critical]

Threat Enrichment:
  E: [A/P/U] — Source: [CISA KEV / ExploitDB EDB-XXXXX / No evidence]
  EPSS: [score] — Percentile: [XX]th

Environmental Adjustments:
  [MAV:A] — [System on internal VLAN, not internet-accessible. Evidence: FW-RULE-XXXX]
  [MAC:H] — [Access requires MFA VPN. Evidence: POLICY-NET-022]
  [MSC:N/MSI:N/MSA:N] — [Isolated system, no lateral movement paths. Evidence: NDG-007]

BTE Vector:
  [CVSS:4.0/.../E:P/MAV:A/MAC:H/MSC:N/MSI:N/MSA:N]
  BTE Score: [5.9 Medium]

Approved by: [Name, Title]
Date: [YYYY-MM-DD]
Next Review: [YYYY-MM-DD or "on next change event"]
Change Ticket: [TICKET-ID]

8. Environmental Metrics in Practice: Additional Context​

The environmental documentation template above captures the full audit trail required for regulatory compliance. Each Modified metric entry requires:

  1. The metric value (e.g., MAV:A)
  2. A specific, verifiable justification (e.g., "System resides on VLAN 10")
  3. Evidence reference (firewall rule ID, policy document, network diagram)
  4. A dated review tied to change management

Tying Environmental reviews to change management is the operational key. Any of the following events should trigger a CVSS-BTE re-evaluation for all CVEs currently scored against the affected asset:

  • Network topology change (new firewall rule, VLAN reassignment)
  • New service account or API credential added
  • Data classification change (system begins processing PII)
  • Access control change (MFA removed, VPN requirement lifted)
  • New network path created (cloud connector, new VPN tunnel)

Without this tie-in, Environmental metrics silently become stale — and a previously documented MAV:A may no longer reflect reality.

Worked Adjustment: CVE-2023-44487 (HTTP/2 Rapid Reset)​

A concrete example of the full environmental decision process for one CVE across two system types:

CVE-2023-44487 — HTTP/2 Rapid Reset DDoS
Base: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H
CVSS-B: 8.7 High
Threat:  E:A (CISA KEV — actively exploited)  → CVSS-BT: 8.7 High

System A — Public CDN edge node (production, customer-facing):
  Network:   AV:N → no change (internet-facing, correct)
  Complexity: AC:L → no change (mass exploitation automated)
  Data:       VC:N/VI:N → no change (DoS only, no data theft)
  Availability: VA:H/SA:H → no change (this IS the risk here)
  Criticality: AR:H (customer-facing, every minute of downtime = revenue + SLA breach)
  Vector: .../E:A/AR:H
  CVSS-BTE: ~9.3 Critical — patch immediately or deploy L7 DDoS mitigation

System B — Internal CI/CD build server running HTTP/2 for internal API:
  Network:   MAV:A (not internet-facing — internal VLAN 172.16.x.x)
  Complexity: MAC:H (require build system credentials + VPN to reach)
  Availability: AR:L (build server downtime = inconvenience, not revenue)
  Vector: .../E:A/MAV:A/MAC:H/AR:L
  CVSS-BTE: ~4.8 Medium — next maintenance window

Justification documents required:
  MAV:A: "System BSRV-001 has no inbound connections from WAN. Firewall policy FW-EGRESS-009."
  MAC:H: "Access requires corporate VPN (MFA) + build system account (separate approval flow)."
  AR:L:  "Classified Internal/Non-Critical per asset register AST-2024. SLA: Best-effort."
ChapterWhat you'll find
Scoring LifecycleWhere Threat and Environmental metrics fit in the B→BT→BTE flow
Vector String AnatomyHow Modified metrics slot into the vector string
Worked ExamplesFull enrichment walkthrough for Log4Shell, CitrixBleed, MOVEit
Enrichment ToolAutomate KEV + EPSS + Environmental enrichment for any CVE list
Practical VM WorkflowEnd-to-end scanner-to-ticket workflow using these metrics
Common MistakesWhat goes wrong when E: and MAV: are applied incorrectly