Week 8: CVSS v3.1 + Impact Scoring

Formal scoring. The CVSS v3.1 specification; per-metric definitions; vector strings; per-metric justification. The lab scores the SB6141 CSRF and defends the score against adversarial review.

Theme

A vulnerability without a score is a vulnerability without a comparative position. CVSS (Common Vulnerability Scoring System) v3.1 is the industry's shared vocabulary for "how bad is this." A vendor whose product receives a 9.8 CVSS patches it; a vendor whose product receives a 4.3 puts it in the queue. The score is not perfect; the score is what gets read first.

The week's discipline is to score the SB6141 CSRF accurately and defensibly. "Accurately" means using the FIRST.org specification's definitions, not your intuition. "Defensibly" means writing the per-metric justification so a reviewer can follow your reasoning step by step and either agree or push back on a specific metric rather than the gestalt.

Scoring is harder than it looks. Three common errors:

1. Inflating the score. A researcher proud of their finding scores it high. The SB6141 CSRF, scored honestly, is in the 6-7 range; it requires the victim to be on the lab network AND visiting the attacker's page AND with the modem in a particular state. Honest scoring sometimes feels disappointing; honest scoring is the discipline.

2. Deflating the score. A vendor's PR-trained voice argues every metric down. CVSS exists precisely to constrain this; the metric definitions are not negotiable.

3. Skipping the per-metric justification. A bare score ("8.7") is not defensible. A scored vector with one-paragraph-per-metric reasoning ("Attack Vector = Network: the CSRF triggers via cross-origin HTTP; no privilege required as the modem authenticates by network position; ...") is.

By the end of Week 8 you can: read CVSS v3.1 metric definitions correctly; produce a CVSS vector string for any CVE; write per-metric justification for the SB6141 CSRF specifically; defend the score against a reviewer who tries to push it up or down.

Schneier weave (~285 words, A Hacker's Mind Ch 14)

Schneier devotes Chapter 14 of A Hacker's Mind to the question of measurement in adversarial systems. His worked examples include credit scoring (where FICO assigns a numeric score that lenders treat as decisive despite its acknowledged limitations), TSA threat-scoring (where airline-passenger risk is computed without the passenger's visibility), and CVSS itself (Schneier mentions vulnerability-scoring as the security analog of credit-scoring). The pattern is the same: a single number, computed from a fixed set of inputs, becomes the operational signal even when domain experts know the number is reductive.

Schneier's argument is not that scores are bad; it is that scores are tools, and tools deserve evaluation against their purpose. CVSS's purpose is to provide a SHARED VOCABULARY for vulnerability comparison. A CVSS 9.8 issued by Vendor A and a CVSS 9.8 issued by Vendor B should mean approximately the same thing in operational terms; the shared vocabulary is what makes the comparison possible.

The implication for the ADV-101 scorer is that fidelity to the specification matters more than the final number. A score that follows the spec is a score that other practitioners can verify. A score that uses idiosyncratic metric interpretations is a score that breaks the shared vocabulary; the number is the same but the meaning is not.

The SB6141 CSRF is a useful scoring exercise precisely because the metrics are nuanced. Attack Vector is Network (the CSRF is cross-origin). User Interaction is Required (the victim has to load the attacker's page). Scope is Unchanged (the action affects only the modem, not the broader network). Confidentiality / Integrity / Availability impacts depend on the destructive action's specifics. Each metric requires per-CVE reasoning. The discipline is to write the reasoning down so it can be reviewed.

Reading list (~1 hour)

1. Schneier, A Hacker's Mind, Ch 14 ("Hacking Measurement"). Academy library; calibre id 677.
2. FIRST.org, CVSS v3.1 Specification Document at https://www.first.org/cvss/v3.1/specification-document. Read in full; ~30 pp; the canonical reference.
3. FIRST.org, CVSS v3.1 User Guide at https://www.first.org/cvss/v3.1/user-guide. Read in full; ~20 pp; the worked examples are the most useful part.
4. FIRST.org, CVSS v3.1 Calculator at https://www.first.org/cvss/calculator/3.1. The interactive tool you use for the lab.
5. NIST NVD CVSS examples at https://nvd.nist.gov/vuln-metrics/cvss. NVD scores every CVE in the National Vulnerability Database; the examples are the practitioner reference.

Lecture outline (~50 min)

Part 1: CVSS v3.1 structure (10 min)

• Three metric groups. Base metrics (vulnerability-intrinsic; do not change over time). Temporal metrics (change as patches, exploits, reports appear). Environmental metrics (deployment-specific). ADV-101 scores Base only; Temporal and Environmental are operator concerns.
• The Base metrics: 8 components. Attack Vector, Attack Complexity, Privileges Required, User Interaction, Scope, Confidentiality Impact, Integrity Impact, Availability Impact. Each has a small set of allowed values; the combination produces the vector string.
• The vector string. Format: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H. Each component's letter values are defined in the spec. The vector is the canonical record; the numeric score is computed from it via the formula in the spec.
• The numeric score. 0.0 to 10.0; rounded to one decimal. Computed from the vector via the FIRST.org formula; the calculator does this for you.

Part 2: Per-metric definitions (15 min)

• AV (Attack Vector). How does the attacker reach the vulnerability?

  • N (Network): attacker accesses via the network stack; CSRF qualifies.
  • A (Adjacent): attacker must be on the same physical or logical network.
  • L (Local): attacker has local user account.
  • P (Physical): attacker has physical access.
  • For SB6141 CSRF: N (cross-origin HTTP; reachable from any network the victim's browser can reach the modem from).

• AC (Attack Complexity). Does the attack succeed every time, or only under specific conditions?

  • L (Low): consistently exploitable.
  • H (High): requires conditions the attacker must overcome (timing; specific configuration; uncommon prerequisite).
  • For SB6141 CSRF: L (works any time the modem is in operational state; no special conditions).

• PR (Privileges Required). What privileges must the attacker have BEFORE the attack?

  • N (None): unauthenticated.
  • L (Low): regular user account.
  • H (High): administrative account.
  • For SB6141 CSRF: N (the modem has no authentication; "network position" is not in PR terms).

• UI (User Interaction). Does the attack require the victim to take some action?

  • N (None): purely attacker-initiated.
  • R (Required): victim must perform some action (click; load page; etc.).
  • For SB6141 CSRF: R (the victim must load the attacker's page in their browser).

• S (Scope). Does the action affect resources beyond the vulnerable component's security authority?

  • U (Unchanged): impact stays within the vulnerable component.
  • C (Changed): impact extends to other components / authorities.
  • For SB6141 CSRF: U (the modem is the vulnerable component; the destructive action affects only the modem; no escape to other systems).

• C / I / A (Confidentiality / Integrity / Availability impacts).

  • N (None): no impact.
  • L (Low): partial impact.
  • H (High): total impact.
  • For SB6141 CSRF (factory-reset specifically):
    • C: L (configuration loss exposes that the device was configured; not a confidentiality breach per se, but borderline; some scorers argue N)
    • I: H (configuration replaced with defaults; integrity of the configuration is fully compromised)
    • A: H (modem is unavailable for ~60 seconds during reset; argue L if the brief outage is not considered material)

Part 3: Score computation + walkthrough (15 min)

• The vector for SB6141 CSRF (factory-reset action): CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:H/A:H
• Computed score (via the calculator): roughly 8.3 (High severity).
• Walkthrough at the calculator. Open https://www.first.org/cvss/calculator/3.1. Click each metric's correct radio button. Observe the score and vector string update.
• Common scoring debates for this CVE.
  • C: should it be N (no confidentiality impact) or L (configuration loss reveals something)? Defensible either way; the per-metric justification carries the argument.
  • A: should it be L (brief outage) or H (total outage during reset)? Specification says H is "total loss of availability"; ~60s is total during that window; defensible as H. Some scorers argue L because the outage is bounded; defensible as L.
  • The lab's expected score range: 7.5 to 8.5 depending on the C and A interpretations. A score below 6.0 or above 9.0 is hard to defend.

Part 4: Defending the score (10 min)

• Per-metric justification. One paragraph per metric. The paragraph names the spec definition, names the SB6141 behavior that matches the definition, and concludes with the value choice.
• Adversarial review. A reviewer attacks specific metrics: "Why C:L not N? The CSRF reveals nothing." You respond on the specific metric: "The default-state markers I look for in the fingerprint reveal the modem's pre-reset state; an attacker who can issue the reset can observe the reset and infer something about the prior configuration. The information leak is small; L is the conservative choice; N is defensible too. I picked L."
• The score is not the report. The disclosure report (Week 9) uses the score; the score itself is one section. The defense is: vector + per-metric justification + acknowledgment of the close calls.

Disclosure-Ethics Sidebar

The score is professional vocabulary; the authorization is the legal precondition. They are separate axes; conflating them is the failure mode.

Labs (~3 hr)

Lab 8: CVSS Scoring (labs/lab-8-cvss.md)

• Goal: produce the CVSS v3.1 vector + score + per-metric justification for the SB6141 CSRF
• Time: ~3 hr
• Artifact: lab-8/cvss-scoring.md in ~/adv-101/lab-8/

Independent practice (~5 hr)

1. Score five recent CVEs without looking at NVD (1.5 hr). Pick five CVEs from the last 30 days at https://nvd.nist.gov/vuln/search; read each advisory; score each Base only; compare your score to NVD's. Document divergences.
2. Read FIRST.org User Guide worked examples (1 hr). The worked examples in the User Guide are the practitioner-grade reference. Read the CSRF example (if present); compare to your SB6141 reasoning.
3. Adversarial-review drill (1 hr). Pair with a cohort peer. Each scores the SB6141 CSRF independently; then each defends their score against the other's challenges. Document the disagreement and resolution.
4. Schneier A Hacker's Mind Ch 15 (45 min). Continues the measurement framing; cited in Week 9.
5. CVSS v4.0 preview (45 min). FIRST.org has published CVSS v4.0; read the overview at https://www.first.org/cvss/v4.0/specification-document. Note: v3.1 is still the academy default because NVD scores in v3.1; v4.0 awareness is forward-stretch.

Reflection prompts (~30 min)

1. The SB6141 CSRF scores roughly 8.3. A score that high suggests a vendor SHOULD patch. The SB6141 is end-of-life; no patch is coming. Does the score still matter? For whom?
2. You may have scored Confidentiality differently from your cohort peer. Whose interpretation aligns more closely with the spec? Defend.
3. CVSS Base ignores operator deployment context. A device deployed in a residential network has a different threat model than one deployed in a hospital. What captures the difference?
4. A vendor argues your score is inflated. They claim Availability should be L because outages are brief. How do you respond?
5. One thing from this week you want to know more about?

Adversary Diary (Week 8)

New entries:

• FIRST.org CVSS v3.1 calculator at https://www.first.org/cvss/calculator/3.1. The scoring tool.
• CVSS v3.1 Specification Document at https://www.first.org/cvss/v3.1/specification-document. The reference.
• CVSS v3.1 User Guide at https://www.first.org/cvss/v3.1/user-guide. The worked-examples reference.
• NVD CVSS examples at https://nvd.nist.gov/vuln-metrics/cvss. The NIST scoring practice.
• CVSS v4.0 overview at https://www.first.org/cvss/v4.0/specification-document (forward-stretch).

What would a reviewer ask?

1. "Walk me through your CVSS vector. Why did you pick AV:N over AV:A?"
2. "Your Availability is H. Defend that. The outage is bounded; why not L?"
3. "What's the difference between your score and NVD's score for VU#419568, if any?"

What comes next

Week 9 introduces coordinated vulnerability disclosure. You draft a CERT/CC-grade disclosure report; the SB6141 CSRF score from Lab 8 becomes a section of the report. The CVD discipline is the discipline that turns a researcher's discovery into a vendor's patch.