A Practical Guide to FAIR Risk Quantification

Why CVSS Alone Falls Short

Every security team knows the drill: a scanner dumps thousands of findings rated Critical, High, Medium, and Low. You triage by severity, patch what you can, and hope the board doesn't ask hard questions about residual risk.

The problem is that CVSS measures technical severity, not business impact. A Critical-rated vulnerability on a development server with no sensitive data is materially different from a Medium on a payment-processing database. CVSS cannot distinguish between the two.

This is where Factor Analysis of Information Risk (FAIR) comes in.

What FAIR Actually Does

FAIR is an open standard for quantifying information risk in financial terms. Instead of ordinal labels (High/Medium/Low), it produces a dollar-denominated loss distribution built from two core components:

• Loss Event Frequency (LEF) -- How often will the threat materialize?
• Loss Magnitude (LM) -- When it does, what will it cost?

Each component decomposes further. LEF breaks into Threat Event Frequency and Vulnerability (the probability of a threat succeeding). LM breaks into Primary Loss (direct costs) and Secondary Loss (regulatory fines, reputation damage, litigation).

The output is a Monte Carlo simulation: a probability distribution showing the range of likely annual losses, typically at the 10th, 50th, and 90th percentiles.

From Cloud Evidence to Risk Register

Here is the workflow Theodolite automates:

1. Scan the environment directly. A scanner deployed inside the cloud environment (Azure or AWS) discovers resources, misconfigurations, sensitive data, and access paths — verified evidence, not questionnaire answers.
2. Enrich with asset context. Each finding is tied to the resource it lives on, its data classification, and its exposure profile. A misconfiguration on a storage account holding customer PII scores differently than the same misconfiguration on an empty dev bucket.
3. Run FAIR quantification. Theodolite estimates Loss Event Frequency from threat intelligence and exploitability data, then models Loss Magnitude using industry benchmarks and your asset classification.
4. Prioritize by annualized loss expectancy. Instead of sorting by severity labels, you sort by dollar impact. Resources flow to where they reduce the most financial risk.

A Concrete Example

Consider two findings from the same scan:

| Finding | Severity | Asset | FAIR ALE (90th percentile) | |---|---|---|---| | Public network access enabled | Critical | Internal wiki storage | $12,400/year | | Anonymous read access on container | High | Customer billing data store | $2.1M/year |

By severity label, the wiki finding gets fixed first. By FAIR, the billing data store receives immediate attention because the probable financial impact is 170x greater. The wiki storage holds no sensitive data and sits behind a VPN, so the actual risk exposure is minimal despite the alarming label.

Getting Started

If you are new to FAIR, start small:

• Pick five critical assets and classify them by data sensitivity and exposure.
• Run a single scan of one cloud environment.
• Review the FAIR output alongside the raw severity rankings. Note where they diverge.

Those divergence points are where your current prioritization is likely misallocating resources. Over time, expanding FAIR coverage across your asset inventory builds a risk register that speaks the language of the business: dollars, not color codes.

Further Reading

• The Open Group FAIR Standard
• NIST SP 800-30: Guide for Conducting Risk Assessments
• FAIR Institute resources on building a risk quantification program