Six Weeks to Quantify a Brand-New API
A SaaS company plans to launch a partner API in eight weeks. Projected volume is 9 million calls per day across 12 enterprise customers; the API exposes invoice and payment metadata. There is no incident history because the product is new. Three analysts are available for 25 person-days total. The architecture team has produced a 40-page design document and a threat model with 63 STRIDE entries; the CISO wants every entry analyzed quantitatively. The CEO wants a single annualized loss estimate for the launch decision. Historical data from the legacy product, which has a different architecture, shows two minor incidents in five years, neither involving the API. The security team has an untested rate-limiting control, a 24/7 on-call rotation, and no formal tabletop exercise. The launch date is fixed by a customer contract with penalty clauses.
1. Scope the analysis. Explain which of the 63 STRIDE entries you would analyze, combine, or exclude, and the criteria you use.
Read the worked answer
The 63 STRIDE entries are threats and control gaps, not risk scenarios. Start with a screening pass: map each entry to an asset, a threat community, and a loss event. Combine entries that share the same loss-event path, such as multiple authentication weaknesses leading to API key compromise. Keep scenarios with plausible LEF and material LM. Exclude entries blocked by architecture or with no credible threat, and document the exclusion. With 25 person-days, analyze 5 to 8 scenarios, prioritizing payment metadata exfiltration, authentication bypass, rate-limit bypass or denial of service, and third-party integration compromise. Use the risk landscape to avoid double counting. State that the other entries were screened out and why. This preserves coverage without pretending that 63 labels are 63 independent risks.
2. Describe the estimation method given no incident history, and how you control bias.
Read the worked answer
Use calibrated estimation with subject-matter experts from API engineering, site reliability, fraud, and finance. Decompose estimates into TEF, vulnerability, and loss-magnitude components. Ask for 90 percent confidence intervals rather than point values, and use equivalent-bet or true/false calibration questions to test and adjust estimators. Elicit independently to avoid anchoring, then discuss outliers. Use PERT or lognormal distributions and Monte Carlo simulation. Treat the legacy incident rate as weak evidence only, since the architecture differs; adjust it for exposure and controls. Record rationale, assumptions, and participants. Have a second analyst review the model. Do not start from the CEO's desired number. Bias control is procedural: independent estimates, explicit ranges, documented adjustments, and sensitivity testing.
3. What do you give the CEO, and how do you keep the eight-week launch decision from becoming a false precision exercise?
Read the worked answer
Deliver a decision-focused package: scenario definitions, a loss exceedance curve, ALE with a 90 percent interval, probability of exceeding a stated threshold such as $2M, key drivers, and the cost of delay. Do not give a single number. Explain that the analysis supports the launch decision but does not make it. Recommend launch gating: test rate limiting, run a tabletop, add logging and alerting, and review contractual liability. Deliver a draft in three weeks and update after launch. Explicitly state exclusions and uncertainty. If the CEO demands one number, give the median and immediately show the range and the tail. That keeps the discussion on risk tolerance and control effectiveness rather than on a false precise estimate.