CVSS Scoring & Finding Classification in STE Reports

Prerequisites

• STE-K001: What STE Is
• PEN-K004: Vulnerability Assessment & CVE Research (CVSS background)

Why This Lesson Matters

Every STE finding needs a severity. Without a consistent scoring system, two evaluators score the same vulnerability differently, and clients cannot prioritise remediation. CVSS v3.1 is the industry standard. This lesson builds the scoring fluency that turns vague descriptions ("this is bad") into defensible numbers ("AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H = 10.0 Critical").

1. The CVSS v3.1 Base Score: A Decision Tree

Work through the metrics in order. Each has a small number of options.

Step 1 — Attack Vector (AV): Where is the attacker?
  Network (N):   Exploitable remotely, no physical presence needed
  Adjacent (A):  Attacker must be on the same network segment (Wi-Fi, LAN)
  Local (L):     Attacker needs local shell access
  Physical (P):  Attacker needs physical access to hardware

Step 2 — Attack Complexity (AC): Are special conditions required?
  Low (L):    No special conditions; attack can be repeated reliably
  High (H):   Attacker needs to defeat a defence mechanism or race a condition

Step 3 — Privileges Required (PR): What privilege level does the attacker need?
  None (N):   No login required
  Low (L):    Authenticated as any user
  High (H):   Authenticated as admin

Step 4 — User Interaction (UI): Must a victim do something?
  None (N):   No victim action required
  Required (R): Victim must click, open, or view something

Step 5 — Scope (S): Does the impact extend beyond the vulnerable component?
  Unchanged (U): Impact stays within the same system
  Changed (C):   Impact affects other systems (e.g., browser is victim, but server data is affected)

Steps 6-8 — CIA Impact (C, I, A):
  None (N):  No impact on this CIA property
  Low (L):   Limited impact (partial access, non-critical data)
  High (H):  Complete loss of this CIA property

2. Worked Scoring Examples

Example 1 — Unauthenticated SQLi on public login page

Vulnerability: Blind time-based SQL injection, unauthenticated, allows full DB extraction

AV: N   → exploitable from the internet
AC: L   → no special conditions; standard SQL injection
PR: N   → no credentials required
UI: N   → no victim action
S:  U   → impact stays within the application
C:  H   → full database contents readable
I:  H   → database writable (UPDATE/INSERT possible)
A:  N   → cannot cause downtime via SQL injection alone

Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Score: 9.1 — Critical

Example 2 — Stored XSS on a comments page

Vulnerability: Stored XSS allows session cookie theft of any user who views comments

AV: N   → exploitable from the internet
AC: L   → attack reliably reproduces (comment is stored)
PR: L   → must be authenticated to post a comment
UI: R   → victim must view the page containing the comment
S:  C   → scope changes: the browser (victim) is the impacted component
C:  L   → session cookie stolen (significant, but limited to this application)
I:  L   → attacker can act as the victim in the application
A:  N   → no availability impact

Vector: AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N
Score: 5.4 — Medium

Example 3 — Missing account lockout on admin login

Vulnerability: Admin login has no account lockout — enables brute force

AV: N   → exploitable from the internet
AC: H   → attacker must successfully guess a password (uncertain outcome)
PR: N   → no initial privilege needed
UI: N   → no victim action
S:  U   → impact stays within the application
C:  H   → if brute force succeeds, full admin access
I:  H   → full data modification possible
A:  L   → no direct availability impact, but flooding might cause latency

Vector: AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:L
Score: 8.1 — High

3. Temporal & Environmental Modifiers

The base score is the worst-case scenario. Temporal and Environmental metrics allow adjustment.

Temporal — adjusts for current exploitability:

Environmental — adjusts for the specific deployment:

For STE reports, always include the base score. Include temporal/environmental if the deployment context significantly changes the real-world risk.

4. The STE Finding Risk Rating

Beyond CVSS, STE reports use a composite risk rating that accounts for business context:

Risk = CVSS Base Score × Asset Criticality

Asset criticality:
  Tier 1 (Critical business process): multiplier 1.5
  Tier 2 (Important):                 multiplier 1.0
  Tier 3 (Non-critical):              multiplier 0.7

Example:
  CVSS 7.5 High finding on a Tier 1 payment system:
  STE risk = 7.5 × 1.5 = 11.25 → capped at 10 → remains Critical

  CVSS 7.5 High finding on a Tier 3 test server:
  STE risk = 7.5 × 0.7 = 5.25 → Medium in business context

5. Common Mistakes

Mistake 1: Setting S:C (Scope Changed) for everything. Scope changed means the impact crosses a security boundary into a different component. A web app SQLi that reads the web app's own database is S:U. A web app SSRF that reaches a separate internal service is S:C.

Mistake 2: Using AC:H for "it requires technical skill." AC:H means the attack requires overcoming a specific defence mechanism (ASLR, timing constraint, information prerequisite). Skill level of the attacker is not a CVSS metric.

Mistake 3: Giving C:H for informational disclosure. C:H means full disclosure of confidential information — everything, not just some. A finding that leaks one field from a user record is C:L.

6. Practice Exercises

1. Score these two findings and justify each metric:
2. "Authenticated attacker can modify another user's profile data but cannot read it"

3. "Unauthenticated attacker can download any file from the server by modifying a path traversal parameter"

4. A finding scores AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 9.8. However, the vulnerable service is only accessible from the internal office network (not the internet). What is the correct AV value? How does the score change?

5. Explain the difference between C:L and C:H using a concrete database finding example.

7. Lab

Assessment mode: quiz

8 scoring exercises: for each described vulnerability, select the correct value for each of the 8 base metrics and compute the base score. Compare your score against the provided answer and explain any differences.

8. Framework Alignment

9. Further Reading

• CVSS v3.1 Specification Document — https://www.first.org/cvss/specification-document — Required reading; the metric definitions are the authoritative reference
• CVSS v3.1 Calculator — https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator — Interactive scorer
• FIRST CVSS Examples — https://www.first.org/cvss/examples — Official worked scoring examples

["Score three described vulnerabilities using the CVSS v3.1 decision tree, selecting and justifying all eight base metrics for each", "Explain the Scope metric by correctly classifying five described vulnerabilities as S:U or S:C, with a one-sentence justification for each", "Apply the environmental modifier to a base score of 7.5 by adjusting AV from Network to Adjacent for a described deployment context, and explain the business impact of the score change"]

Prerequisites → Why this matters → CVSS v3.1 as a decision tree (8 steps, options for each) → Worked examples (SQLi, stored XSS, missing lockout) → Temporal and environmental modifiers → STE composite risk rating (CVSS × asset criticality) → Common mistakes → Practice exercises → Quiz lab → Framework alignment → Further reading