The FAIR model for cloud security: putting a dollar value on your attack surface

Every cloud security tool produces a list of findings ranked by CVSS score. Critical findings go to the top of the queue; engineers fix them in order. This approach has an intuitive appeal — surely the highest-severity vulnerability is the most urgent.

The problem is that CVSS measures the exploitability and impact of a vulnerability in isolation. It does not know whether your environment has compensating controls. It does not know whether the vulnerable resource is a developer's test server or your payment processing API. It does not know whether you process ten thousand transactions per day or ten million. Two organisations with identical CVSS scores can face risks that differ by three orders of magnitude.

FAIR — Factor Analysis of Information Risk, published by The Open Group as the O-RT (Risk Taxonomy) and O-RA (Risk Analysis) standards — is the framework that fills this gap. It does not replace CVSS. It uses it as one input in a model that produces what your board actually cares about: the dollar value of your attack surface.

The developer server vs. the payment processor

Consider two findings, both rated CVSS 9.1 (Critical):

• An unauthenticated RCE vulnerability in a web framework running on a developer's personal EC2 instance used for feature testing. The instance has no production data and can only be reached from the corporate VPN.
• The same vulnerability in the same web framework running on the API servers that process payment authorisations for your e-commerce platform, directly accessible from the internet.

CVSS says these are equivalent. Any security engineer knows they are not. FAIR makes that difference numerically explicit.

FAIR fundamentals: frequency times magnitude

FAIR models risk as the product of two variables: Loss Event Frequency — how often will a loss event occur? — and Loss Magnitude — how much will it cost when it does?

Loss Event Frequency has two components:

• Threat Event Frequency — how often will a threat actor attempt to exploit this?
• Vulnerability — when a threat actor attempts exploitation, what is the probability of success?

Loss Magnitude breaks down into primary and secondary losses:

• Primary losses — incident response costs, forensics, data recovery, business downtime.
• Secondary losses — regulatory fines, legal liability, reputation damage, customer churn.

In a full FAIR analysis each variable is expressed as a range, and simulation produces a distribution of annualised loss exposure rather than a single point estimate. That makes uncertainty explicit rather than hiding it behind a precise-looking score.

How Onam applies a FAIR-style estimate

The traditional objection to FAIR is that it needs too many manual inputs to scale. Onam computes a FAIR-style estimate for each finding from data the platform already has, and shows the inputs next to the result.

Loss event frequency from EPSS and exposure. FIRST's Exploit Prediction Scoring System (EPSS) gives the probability that a CVE will be exploited in the next 30 days. Onam multiplies it by an exposure factor: a publicly reachable resource counts fully, an internal one at a fraction. Findings that sit on an attack path have their exposure raised, and more so when they appear on several paths.

Loss magnitude from records, sensitivity and asset value. Primary loss starts from the number of records at risk and a per-record cost for your industry, then is scaled by the data's sensitivity (restricted, confidential, internal or public) and by the value of the asset — a crown jewel such as an encryption key, an admin role or a data warehouse weighs far more than an ordinary resource. You can replace the default record count, per-record cost and sensitivity weights with your own figures, so the estimate reflects your business rather than an industry average.

Regulatory exposure

Secondary losses from regulation are often larger than the incident itself. When a finding's region and data class bring a regulation into play — GDPR, HIPAA, PCI DSS, CCPA, SOX and others — Onam does two things. It applies a regulatory weight to the loss magnitude, taking the single highest applicable weight rather than stacking them, so one finding is not double-counted. And it estimates a separate regulatory fine range from each regulation's published penalty structure, using the record count and annual revenue you configure. GDPR, for example, allows fines of up to €20 million or 4% of worldwide annual turnover, whichever is higher (Regulation (EU) 2016/679, Article 83(5)).

From a finding list to a ranked queue

Each finding gets a minimum, likely and maximum loss estimate, a risk tier, the regulations that apply and the MITRE ATT&CK techniques involved, with the calculation inputs shown alongside. Instead of forty Critical findings and eighty High findings sorted by CVSS, you get a list ordered by estimated loss.

This reordering often surprises security teams. The highest-loss finding is not always the highest-CVSS finding. It can be a Medium-severity misconfiguration — an RDS instance missing encryption at rest, a bucket open to another account — on a resource that holds sensitive data and never reached the top of a severity-sorted queue.

Making the business case to engineering management

Security teams have historically struggled to translate findings into language that resonates with engineering managers and financial stakeholders. "We have a Critical finding" does not answer the question an engineering manager is actually asking: "What is the cost of not fixing this right now compared to shipping the feature we have committed to?"

FAIR makes this conversation tractable. "This finding puts an estimated range of loss on a customer data store, most of it regulatory. The fix is a small IAM policy change." That is a conversation an engineering manager can act on.

The goal of FAIR is not to produce a precise dollar figure — the uncertainty ranges in the model make that clear. It is to produce a defensible, data-grounded estimate that turns security prioritisation from an argument about severity scores into a business decision with quantified stakes.