The Unpatched Server That Was Not a Risk
A security manager at a 1,200-person payment processor opens the quarterly risk meeting with a slide titled 'Top Risk: 14 unpatched Apache servers.' The servers sit behind the cardholder-data environment; patch SLA is 30 days, but 14 have been unpatched for 45 to 90 days. Last quarter two exploitation attempts were detected, one succeeded for six hours before containment. The CIO wants the item on the risk register as written. The CRO, who has read the Open FAIR standard, pushes back: 'That is not a risk; that is an asset and a vulnerability. Tell me what could happen, how often, and how much.' The analyst has 20 person-days, no reliable exploit data beyond the two attempts, and a board pack due in three weeks. The payment platform processes $4.1M per hour at peak and has a contractual 99.95 percent availability commitment.
1. Rewrite the CIO's register entry as an Open FAIR risk statement, naming the asset, threat community, threat agent, vulnerability, loss event, and the loss form(s) at stake. Explain why the original phrasing fails the Open FAIR definition of risk.
Read the worked answer
Open FAIR defines risk as the probable frequency and probable magnitude of future loss. '14 unpatched servers' describes an asset condition; it contains no loss event, no threat, and no loss. A workable scenario is: 'An external, financially motivated attacker exploits an unpatched Apache service in the cardholder-data environment, achieving code execution and data exfiltration.' The asset is the cardholder data and payment platform; the threat community is external financially motivated attackers; the threat agent is the specific intruder; the vulnerability is the unpatched service plus missing compensating controls; the loss event is code execution or exfiltration. Loss forms include productivity (outage), response (forensics, notification), fines and judgments (PCI or acquirer penalties), reputation, and competitive advantage. The slide should remain a finding or control gap, not a risk. The distinction matters because only a loss-event scenario can be analyzed for LEF and LM; a control gap cannot.
2. The CRO asks whether the two exploitation attempts last quarter can be used as the loss event frequency (LEF). Explain how you would treat that observation and what else you need to estimate LEF and loss magnitude.
Read the worked answer
Two detected attempts are evidence about threat event frequency (TEF), not LEF. LEF = TEF × vulnerability. The attempts tell you attackers are reaching the environment and attempting exploitation; the one success is one outcome from a very small sample. Do not divide 1 by 90 days and label it LEF. Instead, define the timeframe as annual, estimate TEF from attempts adjusted for detection coverage and exposure, estimate vulnerability from patch lag, exploit availability, segmentation, and response capability, then combine distributions. For loss magnitude, estimate primary loss per successful event: hours of downtime times revenue per hour, response days times staff cost, replacement costs; then secondary loss: regulatory fines, customer churn, contract penalties. With two observations the range will be wide. That is honest, not a failure. Document assumptions and use calibrated subject-matter estimates rather than false precision.
3. The CIO wants to label the item 'high risk' in a red/amber/green register and move on. Explain what is lost, and what minimum quantitative output you would give the board in three weeks.
Read the worked answer
A red/amber/green label collapses frequency and magnitude into an ordinal and invites false comparisons. 'High' cannot tell the board whether $50,000 or $5 million is at stake, nor whether a $180,000 control is worth it. In three weeks, deliver: a one-page scenario definition; LEF and LM ranges with the elicitation method and participants; an annual loss exceedance curve; ALE and the 90th and 95th percentiles; sensitivity showing which assumption moves the answer most; and explicit exclusions. If data are thin, say so and show a wide curve rather than a false point. The board can then compare residual risk with tolerance and decide whether to fund patching, segmentation, or monitoring. The output supports a decision; it does not make the decision.