/data-breach-blast-radius

Blast Radius Calculator

Formulas, scoring matrices, and estimation heuristics for quantifying how many people, records, and systems would be affected by a data breach in the codebase under analysis.

Core Blast Radius Formula

Blast Radius Score (BRS) = Tier_Weight × Exposure_Likelihood × Population_Scale × Completeness_Factor × Context_Multiplier

Score ranges:

• 0–25: Low — limited exposure, few records
• 26–50: Medium — meaningful exposure, focused population
• 51–75: High — significant exposure, broad regulatory consequences
• 76–100: Critical — catastrophic exposure, immediate action required

Factor 1: Tier Weight (T)

Based on the data classification tier from data-classification.md:

Rule: When multiple tiers exist in the same exposure vector, use the highest tier weight.

Aggregation uplift: If 3+ fields from different tiers are exposed together, add +0.5 to the highest tier weight (aggregation attack risk).

Factor 2: Exposure Likelihood (E)

How likely is this vector to be exploited in a realistic breach scenario?

Factor 3: Population Scale (P)

Normalize the estimated number of affected records to a 0–1 scale.

Estimating Record Counts

Step 1: Look for explicit signals in the codebase

# Strong signals (use these if found):
- README mentions user count ("serves 5M users")
- Seeder/fixture files with record counts
- Migration comments ("adding index for 50K users")
- Analytics dashboards or monitoring configs mentioning scale
- Infrastructure configs (DB instance size implies scale):
  - db.t3.micro → < 10K active users
  - db.r5.large → 10K–500K users
  - db.r5.4xlarge / Aurora Serverless → > 500K users

# Medium signals:
- App category (SaaS product → higher, internal tool → lower)
- Multi-tenant vs. single-tenant architecture
- Presence of sharding or partitioning in DB schema

# Weak signals:
- Tech stack alone (no reliable correlation to user count)

Step 2: Apply default estimates when no signals are found

Always state the assumption used.

Population Scale Score (P)

Factor 4: Completeness Factor (C)

How complete/useful is the exposed data for an attacker?

Factor 5: Context Multipliers (M)

Apply these multipliers to the final score for specific contexts:

Blast Radius Score Calculation Examples

Example 1: E-commerce checkout system

Exposure vector: API endpoint /api/users/{id}/payment-methods — no ownership check (IDOR)

• Tier: T2 (card last 4 + billing address) = 4.0
• Exposure Likelihood: 0.9 (IDOR on sequential IDs, near-certain exploitation)
• Population Scale: 100K users = 0.6
• Completeness: Partial profile + joinable to user table = 0.9
• Context Multiplier: Payment data = 1.7

BRS = 4.0 × 0.9 × 0.6 × 0.9 × 1.7 = 3.30 (raw) → normalized to 66/100 → HIGH

Example 2: Internal HR tool

Exposure vector: Employees table visible to all company users via /api/employees

• Tier: T2 (salary + home address + SSN) = 5.0 (SSN is T1)
• Exposure Likelihood: 0.7 (auth required, but no RBAC; any employee can see all)
• Population Scale: 2,000 employees = 0.3
• Completeness: Full profile = 1.0
• Context Multiplier: Government IDs (SSN) = 1.6

BRS = 5.0 × 0.7 × 0.3 × 1.0 × 1.6 = 1.68 (raw) → normalized to 34/100 → MEDIUM

However — financial impact overrides score here because SSN exposure is Tier 1. Flag as HIGH regardless of score.

Score Normalization

The raw formula output typically ranges 0–8. Normalize to 0–100:

Normalized_BRS = min(100, (raw_BRS / 8.0) × 100)

Blast Radius Summary Table (per exposure vector)

Use this format when reporting:

| # | Exposure Vector | Tier | Likelihood | Pop. at Risk | BRS | Severity | Jurisdiction |
|---|----------------|------|-----------|-------------|-----|----------|--------------|
| 1 | /api/users endpoint - SSN returned in response | T1 | 0.9 | 50K | 87 | CRITICAL | GDPR, CCPA |
| 2 | Logs contain plaintext emails | T3 | 0.6 | 50K | 45 | MEDIUM | GDPR |
| 3 | Redis cache stores full user objects | T2 | 0.5 | 50K | 38 | MEDIUM | GDPR, CCPA |
| 4 | S3 bucket - public read on user avatars | T4 | 1.0 | 50K | 28 | LOW | - |

Total Organizational Blast Radius

After scoring all exposure vectors, compute:

Maximum Simultaneous Exposure (MSE): The number of unique individuals that could be affected if a single attacker gained broad DB access (worst case). This is the number used in regulatory reporting.

Expected Breach Exposure (EBE): The typical exposure based on the most likely attack vector (the highest-likelihood finding, not the highest-impact one).

Regulatory Trigger Count: The number of distinct regulatory regimes triggered (each one has its own notification obligation and fine formula).

## Organizational Blast Radius Summary

| Metric | Value |
|--------|-------|
| Maximum records at risk | [number] |
| Users with Tier 1 data | [number] |
| Users with Tier 2 data | [number] |
| Users with Tier 3+ data | [number] |
| Regulations triggered | GDPR, CCPA, [others] |
| Worst-case BRS | [score] |
| Most likely attack vector | [description] |
| Time to detect (estimated) | [industry avg: 194 days if no SIEM] |
| Time to contain (estimated) | [industry avg: 73 days] |

Breach Cost Benchmarks (IBM Data — Verify Annual Edition)

Use these when no specific cost data is available. Figures below are from the IBM 2024 edition. IBM publishes a new edition annually at https://www.ibm.com/reports/data-breach — the 2025 report reports a ~9% decrease in global average cost.

Source: IBM Cost of a Data Breach Report 2024. State these as benchmarks, not guarantees. Update this table when a new edition is released.