security_risk_quantification v1.0.0

name: security_risk_quantification description: "Quantify security risk in money terms from a full asset list and incident history: scope loss scenarios, build calibrated frequency and loss ranges, run them through a Monte Carlo calculator, read sensitivity instead of a single score, and write a one-page board summary. Use when asked to quantify cyber risk, build a FAIR-style analysis, estimate annualized loss, justify a security budget with numbers, compare control options by loss removed, or report cyber risk to a board or finance lead."

Security Risk Quantification

Purpose

Turn "high risk" into a defensible range of annual loss in money, per scenario, with the sources and the uncertainty on the page. The method follows the Open FAIR standard from The Open Group and the enterprise roll-up guidance in NIST IR 8286, and it ships a tested calculator so the numbers come from a rerunnable model, not from a slide.

Use it for budget and control decisions. Do not use it to score a single vulnerability, to rank scanner findings, or to put a number on a scenario nobody can describe as a threat acting on an asset with a loss.

Workflow

1. Scope the scenarios that matter

• Start from the asset list and the incident history, not from a threat feed. List the assets whose loss would hurt: systems, data stores, sales channels, plants, and the services other firms run for you.
• Write each candidate as one sentence: a threat, an asset, an effect, and a loss. Example: an external attacker uses a stolen VPN credential to encrypt the file servers and stops order processing.
• Cut candidates that fail the sentence test. A threat actor with no asset, or a missing control with no loss, goes back for reframing.
• Keep 5 to 12 scenarios for a first run. Pick by possible loss and by decision value: a scenario earns a place if a decision, a budget line, or an insurance choice depends on it.
• Split scenarios that bundle two different losses, for example an outage and a disclosure. Merge scenarios where one event always triggers the other, and note the merge.

2. Build frequency and loss ranges from evidence

• Give every input as a 90 percent range, low to high. No point estimates.
• Estimate Loss Event Frequency, in loss events per year. Use your incident counts first. When history is thin, split it: Threat Event Frequency from logs and reporting, times Vulnerability, the share of attempts that become losses, from testing and past outcomes. The formula and the loss forms are in references/model-and-estimation.md.
• Build loss per event from the Open FAIR loss forms that apply: productivity, response, replacement, fines and judgments, competitive advantage, reputation. Price each form from records, quotes, contracts, or finance figures. Split primary loss, the direct cost to you, from secondary loss, the cost when regulators, customers, or courts react. Give secondary loss its own probability.
• Rank your sources as you go: own incident and cost records, own measurements and tests, contract and finance figures, public data as an anchor, calibrated expert ranges last. Record the tier, the estimator, and the date for each range in the scenario file under source_notes.
• Treat public figures as anchors with a year and a source attached. A published average breach cost describes the organizations in that study. It is a sanity check on your high end, never a substitute for your own loss range.
• Calibrate each hard range with the protocol in references/model-and-estimation.md: start absurdly wide and cut, run the equivalent bet test, decompose into parts you can price, check for anchoring, then record the range.

3. Run the Monte Carlo model

• Write the scenarios as JSON in the format of examples/sample_scenarios.json. Each scenario needs a name, an asset, a threat, a lef range, a primary_loss range, and, when secondary loss applies, a secondary_prob between 0 and 1 with a secondary_loss range.
• Run the calculator:

python3 scripts/risk_calc.py examples/sample_scenarios.json --trials 20000 --seed 42 --outdir risk-output

• Keep the seed and the input file with the report. Same seed and same input give the same output, so anyone can rerun and check the numbers.
• Read all four outputs: summary.md for the report, summary.csv for mean, median, and the 90th, 95th, and 99th percentiles per scenario, exceedance.csv for the chance of passing each loss threshold, and sensitivity.csv for the ranked drivers.
• Sanity check before you present anything: a rare scenario should show a median of zero and a high chance of no loss, a frequent small scenario should not. A mean far above the 95th percentile means one input range is doing strange work. Find it before a board member does.

4. Read sensitivity, then tighten what matters

• Rank the inputs by swing in sensitivity.csv. The top driver is where better data changes the decision, so spend your next research hour there and nowhere else.
• Restate the finding in words: the ransomware result is driven mostly by the loss per event range, so a restore test and two real response invoices would tighten the answer more than another threat report.
• State the limits with the ranking: the test moves one input at a time, so it misses interactions, and the portfolio total assumes scenarios are independent. Flag any pair of scenarios that share a cause.
• If the top two options in a decision swap places inside the ranges, report that plainly. A tie inside the uncertainty is a valid result.

5. Model controls as changed inputs

• Express each proposed control as the input it changes: resistance controls lower the share of attempts that become losses, response controls lower primary loss, transfer moves part of the loss to an insurer up to a limit and after a retention.
• Rerun with the same seed and the changed inputs. Report control cost per year next to mean loss removed and the change at the 95th percentile.
• Reject any control case that subtracts a round percentage from total risk with no input changed. That is arithmetic on a guess.

6. Write the one-page board summary

• Fill references/board-summary-template.md. One page, decision first, mean and tail together, one threshold the board already cares about, top drivers, options with costs, and a short section on how solid the inputs are.
• Keep the full model, the scenario file, and the register row per scenario behind the summary, following the register and aggregation approach in NIST IR 8286A and IR 8286C: aggregate distributions, never add percentiles together.
• Set the refresh trigger in the summary: a real incident, a new asset, a changed control, or a stated date, whichever comes first. When a real loss lands outside a stated range, widen the range and record the miss.

Output Contract

Deliver all of these, or state which one is missing and why:

1. The scenario file (JSON) with ranges, source notes, estimator names, and dates.
2. The calculator outputs: summary.md, summary.csv, exceedance.csv, and sensitivity.csv, with trials and seed recorded.
3. A per scenario statement in ranges: mean annual loss, median, 95th percentile, and chance of no loss in a year, plus the portfolio exceedance chances at the chosen thresholds.
4. A sensitivity statement naming the top drivers and what evidence would tighten each one.
5. For each control option: yearly cost, mean loss removed, change in the 95th percentile, and the inputs it changes.
6. The one-page board summary, filled from the template, with the decision asked, the limits, and the refresh trigger.

Operating Rules

• Every factual claim needs a source or a label. Public figures carry their source and year. Ranges built from judgment are labeled as calibrated estimates with the estimator named. Unverifiable numbers get cut, not rounded.
• Report ranges, never a single risk score. If a reader asks for one number, give the mean with its 95th percentile next to it.
• Never add percentiles across scenarios, and never average averages from public studies into your own loss range.
• Keep the asset scope full. An analysis built only on externally visible exposure misses internal, third party, and availability scenarios, which often carry the largest losses.
• Show your work: input file, seed, trial count, and source notes travel with every result. A number nobody can rerun is an opinion.
• State correlation and shape assumptions in every report. The calculator fits a lognormal to each 90 percent range and treats scenarios as independent unless you merged them. Both choices are on the page, not buried.
• Refresh after real incidents and compare the actual loss to the range it landed in. That comparison, kept over time, is what makes the next set of ranges better.