---

name: exposure-risk-quantification description: "FAIR-aligned exposure quantification: turns a pile of recon findings into a defensible 0-100 + A-F org risk score (Likelihood x Impact, three ownership-aware factors: exposure/threat/impact), an ownership + proof demotion cap so unproven or weakly-owned findings can't inflate the number, a $-denominated FAIR loss-magnitude estimate (IBM/Ponemon per-record cost bands, cross-source record dedup, threat-factor annualization), attack-path amplification (curated red-team chain catalog + generic graph-walk engine, with a kill-chain vs shared-fate honesty gate), and a board-ready one-pager deliverable (hero $ + letter grade + top-3 findings + top attack path + the ask). Extends osint-methodology's severity rubric and client deliverable templates with quantification. Passive analysis only -- operates on findings already collected, no target traffic, no API keys. Use when asked to score risk, quantify exposure, estimate breach cost, build a board report, translate technical findings to dollars, or explain why a grade or dollar figure came out the way it did." version: 1.0 sources: asm_reference_impl, ibm_ponemon, public_research triggers:

• risk score
• risk quantification
• cyber risk quantification
• CRQ
• FAIR methodology
• FAIR score
• loss event frequency
• loss magnitude
• risk grade
• letter grade risk
• A-F grade
• 0-100 risk score
• board report
• board deliverable
• board ready
• executive summary risk
• CISO report
• hero number
• dollar exposure
• breach cost estimate
• loss estimate
• annualized loss expectancy
• ALE
• per-record cost
• IBM Ponemon
• cost of a data breach
• exposed record count
• quantify risk
• risk translation
• attack path
• kill chain
• shared fate exposure
• attack path amplification
• ownership confidence
• proof demotion cap
• confidence cap
• TENTATIVE inflate score
• risk trend
• risk delta
• the ask
• remediation ask
• one-pager
• exposure risk
• business impact translation
• dominant risk driver

---

Exposure Risk Quantification — FAIR Scoring, $-Loss, and the Board Deliverable

Companion skill: osint-methodology (the "how to think" recon skill — see its §9 severity rubric and §16 client deliverable templates). This skill is the "how to quantify and present" layer on top of a finished recon pass: it takes findings the methodology skill's pipeline already produced and turns them into a number a board will act on.

0. When to Use / When NOT

Use this skill when: you have a completed set of recon findings (from any engagement, not just one tool's output) and need to (a) compute a defensible 0–100 + A–F risk score, (b) estimate a $-denominated loss range, (c) rank attack-path chains by exploitability, or (d) assemble a board/exec one-pager. Also use it to explain a score — "why did this grade come out D and not F" is exactly what §7 is for.

Do NOT use this skill when: you still need to go collect findings — that's osint-methodology (methodology) / offensive-osint (arsenal). This skill does not probe anything; it has nothing to say until a recon pass has already produced findings, assets, and (ideally) ownership/proof annotations.

---

1. Posture: Passive Analysis, Not New Recon

Every computation in this skill is a pure function over findings + assets you already hold — no network calls, no new probes, no target traffic. The reference implementation (reporting/{risk_score,loss_model,board_report,board_render,attack_paths, attack_graph,owner_confidence,proof}.py) is explicit about this: risk_score.py docstring calls itself "Pure compute over scan.db — no network, no schema change"; loss_model.py calls itself "Pure, no network"; attack_graph.py calls itself "Pure + offline."

That means this skill inherits the authorization posture of whatever collected the inputs (see osint-methodology §1) but adds none of its own — quantifying findings you already lawfully hold is never itself an intrusive act. It also means the outputs are only as good as the inputs: garbage findings (unowned namesakes, unverified snippet matches) produce a garbage score unless you apply the demotion cap in §7.5 first.

---

2. Confidence Levels

Reuses osint-methodology §2 verbatim — every finding you're about to score already carries one of:

| Level | Meaning | |---|---| | TENTATIVE | Plausible, unverified. | | FIRM | Directly observed, uncorroborated. | | CONFIRMED | Multiple independent corroborations OR directly verified. |

What this skill adds is a second, orthogonal axis — ownership certainty — and the rule for how the two combine so neither one alone can inflate a number (§7.5).

---

3. Output Format

Three artifacts, each a pure dataclass with a to_dict():

OrgRisk:
  risk: float            # 0-100 headline
  grade: str              # A|B|C|D|F
  exposure, breach_likelihood, impact: float   # the three factors x100
  dominant_driver: str    # "exposure" | "breach-likelihood" | "business-impact"
  narrative: str          # 2-3 sentence board-language explanation

LossEstimate:
  records: int
  low, expected, high: float     # $ range
  annualized: float | None
  basis: str              # human-readable "N records x $X/record (source)" string

BoardSummary:
  target, hero (HeroNumbers), top_findings[], top_paths[], the_ask[], methodology, narrative

Rule: every number ships with its basis. LossEstimate.basis and OrgRisk.narrative are not optional decoration — never present the bare risk float or expected dollar figure without the sentence that explains what drove it. §4 and §12 make this a hard rule, not a style preference.

---

4. Source Hygiene & Assumption Disclosure

For every quantified number, disclose:

• The cost band used and its source (default: IBM/Ponemon Cost of a Data Breach, ~$165/record — see §8.1). If you swapped in a region/industry-tuned band, say so.
• The record count's provenance — which breach source(s) it came from and whether multiple sources were deduped (§8.2 — max-across-sources, never summed).
• Which likelihood fed the annualization — the Threat factor (T), not the composite risk score (§8.3). These are different numbers computed differently; conflating them is the single most common way to misstate an ALE.
• The scan/snapshot timestamp — a risk score is a point-in-time read of a continuously-changing external surface. Say when it was computed.

---

5. Do NOT

• Do NOT present the point estimate (expected) without the range (low–high).
• Do NOT let a TENTATIVE or weakly-owned finding stand in for a CONFIRMED, owned one — run the demotion cap (§7.5) before scoring, and check what did not get demoted (§12).
• Do NOT claim a shared-fate (co-location) graph path is a proven attack chain — see §9.3. It is blast-radius context, not a kill-chain, and must be labeled as such.
• Do NOT fabricate a dollar figure when the record count is 0. Say what the score is actually grading (posture / proven exposure) instead — see §10.1.
• Do NOT compare risk scores across two different targets as if they sit on a shared absolute scale beyond the A–F band; only a target's own risk_trend (§10.1) is a valid time-series comparison.
• Do NOT treat the model's output as ground truth. It is a calibrated heuristic over the findings you hold, not a claim that a breach is certain, imminent, or quantified to the dollar. See §12.

---

6. FAIR Primer — Mapping Recon Findings onto Risk = LEF × LM

FAIR (Factor Analysis of Information Risk) decomposes risk into:

Risk = Loss Event Frequency (LEF) × Loss Magnitude (LM)

External recon cannot observe LEF or LM directly — no one is handing you an actuarial table for this specific target. What recon can do is produce calibrated proxies for both halves, and that's what this skill's three-factor model does:

| FAIR concept | Recon proxy | Computed by | |---|---|---| | Loss Event Frequency (probability a bad event happens) | Likelihood = combine(Exposure, Threat) | §7.1–§7.2 | | — breadth/severity of what's exposed | Exposure (E) | attack-surface findings, severity-weighted | | — how actively that exposure is being targeted | Threat (T) | KEV/EPSS, leaked creds, adversary chatter, proven exploits, attack-path chains | | Loss Magnitude (cost if it happens) | Impact (I) | §7.3 — worst-case, ownership-gated business value of what's exposed | | Loss Magnitude, in dollars | loss_model.estimate() | §8 — exposed-record count × per-record cost band |

Keep it honest: a 0–100 score and a $ range are likelihood and magnitude inputs, not a claim that a breach has happened, will happen, or costs exactly that much. Every FAIR practitioner treats the output as a decision-support number with stated assumptions — this skill enforces that discipline structurally (§4, §12) rather than leaving it to the writer's memory.

This skill deepens osint-methodology §9 (severity rubric — CRITICAL/HIGH/MEDIUM/LOW/ INFO anchors) by rolling those per-finding severities into one org-level number, and §16 (client deliverable templates — exec summary, risk translation table, reporting cadence) by adding the $ figure and the board one-pager layout those templates gesture at but don't compute.

---

7. The 0–100 + A–F Score

Source: reporting/risk_score.py. risk = round(likelihood × Impact × 100, 1), where likelihood = combine(Exposure, Threat).

The independent-evidence combiner, used everywhere two-or-more probabilistic signals need to merge without double-counting:

combine(weights) = 1 - Π(1 - w_i)     for each w_i clamped to [0, 1]; empty list -> 0

This is the same shape used for OR-of-independent-events probability — one strong signal dominates, several weak signals still add up, and nothing can exceed 1.0.

7.1 Exposure (E) — breadth × severity of the attack surface

Sum a severity-weighted load S over every finding in the scan (this term is not gated by confidence or ownership — see the sharp edge called out in §12), then saturate:

| Severity | Weight | |---|---| | critical | 1.0 | | high | 0.4 | | medium | 0.1 | | low | 0.02 | | info | 0.0 |

S = sum(severity_weight[f.severity] for f in findings)
E = min(1 - e^(-S / 25), 1 - 1e-15)        # K=25: calibration constant

K = 25 is chosen so a couple of findings reads low and a broad/severe surface approaches 1 — deliberately not an independent-evidence combine (which would saturate to ~1.0 on a single critical and give zero discrimination between a 2-critical and a 200-critical target).

The proven-critical floor: if the scan carries an owned (owner_confidence ≥ 70) finding that is severity CRITICAL and either confidence == "confirmed" or is_proven (§7.5), E = max(E, 0.5). A proven critical on an asset you own is material risk — this floor is the mechanism that stops such a target from grading A ("strong posture") purely because it has few other findings.

7.2 Threat (T) — breach-likelihood multiplier

A weighted list, combined via combine(). Each condition below appends a weight if true; absent conditions contribute nothing (not zero-weight — simply omitted from the list):

| Signal | Weight | Gate | |---|---|---| | Proven exploit on an owned host, OR an owned CONFIRMED/proven critical (same predicate as the §7.1 floor) | 0.90 | owner_confidence ≥ 70 | | CISA KEV match (cve asset with attrs.kev, OR finding evidence kev_cves) | 0.90 | KEV-asset: unconditional; finding-evidence: owned host only | | Max EPSS score across CVEs | min(1, epss_max) × 0.7 | same split as KEV | | Active-sale (a market-escalation finding with evidence.for_sale) | 0.90 | unconditional | | Held leaked credentials for the org (elif no active-sale) | 0.80 | credential asset: unconditional; secret asset: owned host only | |