9 min read

Section 12

Case Studies & Templates

Theory meets practice. This section provides five complete TRA walkthroughs across different industries and architectures, plus reusable templates, checklists, and a regulatory mapping matrix. Use these as starting points for your own assessments.

Case Study 1: Cloud-Native E-Commerce

Context

System: E-commerce platform on AWS (EKS, Aurora, ElastiCache, CloudFront). Revenue: $120M/year. Data: 3M customer records, 500K stored cards (PCI DSS). Framework: NIST 800-30 + FAIR quantification.

Scope & Context

Triggered by annual PCI DSS revalidation and upcoming migration from EC2 to EKS. Scope includes: checkout flow, payment processing, customer data management, admin portal. Excludes: marketing website, email system (separate TRA).

Top Threats Identified

Threat STRIDE ATT&CK ALE (FAIR)
Card data exfiltration via API BOLA I, E T1190, T1530 $4.2M–$12M
Container escape from compromised pod E, T T1611 $1.5M–$5M
Supply chain compromise (npm dependency) T, I T1195.002 $800K–$3M
DDoS against checkout during Black Friday D T1498, T1499 $500K–$2M

Key Treatment Decisions

  • • Mitigate: API BOLA → implement object-level authorization checks + WAF rules ($150K implementation)
  • • Mitigate: Container escape → deploy Falco runtime monitoring + enforce pod security standards ($80K)
  • • Mitigate: Supply chain → SLSA Level 2 for all builds, SBOM generation, Snyk monitoring ($60K/year)
  • • Transfer: DDoS → AWS Shield Advanced ($3K/month) + cyber insurance ($200K/year premium)

Case Study 2: Healthcare API Ecosystem

Context

System: HL7 FHIR API platform connecting 50 hospitals and 200 clinics. Regulation: HIPAA, HITECH Act, state privacy laws. Data: 10M patient records (PHI). Framework: ISO 27005:2022 (event-based approach).

Critical Risk Scenarios

  • • Patient data exposure via FHIR API misconfiguration — unauthorized clinician accessing records outside their practice (HIPAA §164.312(a))
    Treatment: Implement SMART on FHIR scopes, patient consent management, break-glass audit controls
  • • Ransomware impacting clinical operations — encrypted EHR databases causing treatment delays
    Treatment: Immutable backups, network segmentation, 4-hour RTO/RPO for clinical systems
  • • Insider threat to celebrity/VIP records — unauthorized access by curious staff
    Treatment: Enhanced monitoring for VIP records, real-time SIEM alerts, disciplinary framework
  • • Third-party app data leakage — connected mobile app sending PHI to analytics
    Treatment: API scope restrictions, mandatory app security review, DLP controls on FHIR responses

Case Study 3: Financial SaaS Product

Context

System: Multi-tenant financial reporting SaaS (Azure, .NET, Cosmos DB). Regulation: PCI DSS 4.0, SOX, SOC 2. Clients: 500 enterprise customers. Framework: NIST RMF + FAIR.

Multi-Tenancy Risk Focus

Multi-tenancy introduces unique risks not present in single-tenant systems. This TRA specifically assessed tenant isolation boundaries.

  • • Tenant data leakage: Cosmos DB partition key collision → data served to wrong tenant (ALE: $5M–$20M). Mitigated with tenant-scoped encryption keys + integration test suite
  • • Noisy neighbor DoS: One tenant's heavy report generation impacts all tenants. Mitigated with per-tenant rate limiting + dedicated compute for Tier 1 clients
  • • Privilege escalation across tenants: Admin of Tenant A accesses Tenant B data via API manipulation. Mitigated with tenant ID in JWT claims validated at service layer

Case Study 4: AI/ML Recommendation Engine

Context

System: Product recommendation engine using collaborative filtering + LLM-enhanced descriptions. Data: 50M user behavior records, purchase history. Framework: NIST AI RMF + MITRE ATLAS. Regulation: EU AI Act (limited risk category), GDPR.

AI-Specific Risk Findings

  • • Filter bubble bias: Recommendation algorithm reinforces demographic biases in purchasing patterns, creating discriminatory outcomes for protected groups.
    Treatment: Fairness metrics (demographic parity, equalized odds) in model validation pipeline. Quarterly bias audits.
  • • Training data poisoning: Adversary creates fake accounts to influence recommendations for specific products (marketplace manipulation).
    Treatment: Anomaly detection on user behavior patterns, minimum interaction thresholds before influencing model, human review for trending shifts.
  • • LLM prompt injection via product descriptions: Sellers embed instructions in product descriptions that manipulate LLM-generated recommendation text.
    Treatment: Input sanitization before LLM processing, output validation against allowed content patterns, human review for flagged outputs.
  • • Privacy — user re-identification: Recommendation patterns could reveal sensitive preferences (health products, political books) even from "anonymized" data.
    Treatment: Differential privacy in model training, aggregate-only recommendation explanations, LINDDUN+ analysis (see Section 04).

Case Study 5: IoT Fleet Management

Context

System: Fleet management for 10,000 industrial IoT sensors (MQTT → Azure IoT Hub → data lake). Industry: Manufacturing (OT convergence). Framework: TARA + IEC 62443. Concern: IT/OT convergence creating new attack paths.

OT-Specific Risk Findings

  • • IT-to-OT lateral movement: Compromised cloud management portal used to push malicious firmware to field sensors. ALE: $2M–$8M (safety + production loss).
    Treatment: Unidirectional gateway (data diode) for sensor telemetry, separate management network with jump box, firmware signing with hardware root of trust.
  • • MQTT broker compromise: Unauthenticated MQTT broker allows message injection, causing sensors to report false readings. ALE: $500K–$3M.
    Treatment: mTLS for all MQTT connections, message integrity verification, anomaly detection on sensor data patterns.
  • • Legacy sensor vulnerabilities: 30% of sensors run firmware from 2019 with no update mechanism. Known CVEs with public exploits.
    Treatment: Network micro-segmentation, compensating monitoring controls, 18-month hardware refresh plan for end-of-life devices.

TRA Report Template

tra-report-template.txt 
Threat & Risk Assessment Report Template
════════════════════════════════════════

1. EXECUTIVE SUMMARY
   1.1 Assessment purpose and trigger
   1.2 Scope and boundaries
   1.3 Key findings summary (top 5 risks with ALE)
   1.4 Overall risk posture rating
   1.5 Investment recommendations with ROI

2. ASSESSMENT CONTEXT
   2.1 System description and architecture
   2.2 Business context and value
   2.3 Regulatory environment
   2.4 Previous assessment findings (if applicable)
   2.5 Assessment methodology and framework used

3. SCOPE & DECOMPOSITION
   3.1 System boundary diagram
   3.2 Component inventory
   3.3 Data flow diagrams
   3.4 Trust boundaries
   3.5 Crown jewels and critical assets (CIA ratings)
   3.6 Exclusions and inherited risks

4. THREAT LANDSCAPE
   4.1 Relevant threat actors (profiled)
   4.2 Industry threat intelligence
   4.3 ATT&CK technique mapping
   4.4 Threat scenarios (structured)

5. VULNERABILITY & ATTACK SURFACE
   5.1 Attack surface inventory
   5.2 Technical vulnerabilities
   5.3 Architecture weaknesses
   5.4 Process and control gaps
   5.5 Supply chain vulnerabilities

6. RISK ANALYSIS
   6.1 Risk assessment methodology (FAIR/800-30)
   6.2 Risk register (full)
   6.3 Risk heat map (for visual reference only)
   6.4 FAIR quantification results for top risks
   6.5 Monte Carlo simulation outputs

7. RISK TREATMENT PLAN
   7.1 Treatment decisions per risk
   7.2 Control recommendations with cost estimates
   7.3 Implementation roadmap (30/60/90 day)
   7.4 Risk acceptance decisions needed
   7.5 Residual risk after treatment

8. APPENDICES
   A. Detailed threat scenarios
   B. Attack trees
   C. FAIR analysis worksheets
   D. Control mapping to frameworks
   E. Regulatory compliance mapping
   F. Glossary of terms

Regulatory Mapping Matrix

This matrix maps TRA activities to regulatory requirements — use it to ensure your assessment satisfies compliance obligations.

TRA Activity NIST CSF ISO 27001 PCI DSS 4.0 HIPAA SOX GDPR
Risk assessment ID.RA 6.1, 8.2 12.3.1 §164.308(a)(1) §302, §404 Art. 35
Threat identification ID.RA-3 A.5.7 6.3.1 §164.308(a)(1)(ii)(A) — Art. 32
Vulnerability analysis ID.RA-1 A.8.8 6.2, 11.3 §164.308(a)(8) — Art. 32
Risk treatment plan ID.RA-6 6.1, 8.3 12.3.2 §164.308(a)(1)(ii)(B) §404(a) Art. 24, 32
Third-party risk ID.SC A.5.19-22 12.8 §164.308(b) §404 Art. 28
Continuous monitoring DE.CM 9.1, 10.1 10, 11.5 §164.312(b) §404(b) Art. 5(2)

Assessment Checklists

tra-checklists.txt 
Pre-Assessment Checklist
════════════════════════
□ Assessment purpose and trigger documented
□ Scope boundaries defined and agreed
□ Stakeholders identified and briefed
□ Framework selected (NIST/ISO/OCTAVE/hybrid)
□ Previous assessment reports reviewed
□ Architecture documentation collected
□ Regulatory requirements identified
□ Assessment timeline and milestones set
□ Risk appetite statement obtained from leadership

During-Assessment Checklist
═══════════════════════════
□ System decomposition complete (DFD, components, data flows)
□ Crown jewels analysis performed
□ Threat landscape documented (actors, TTPs, CTI)
□ Threat modeling performed (STRIDE/PASTA/hybrid)
□ Attack surface mapped (all six categories)
□ Vulnerabilities correlated with threats
□ Risk quantification completed (FAIR for top risks)
□ Risk register populated with all findings
□ Treatment options analyzed with cost-benefit

Post-Assessment Checklist
═════════════════════════
□ Executive summary written (1-page max)
□ Full report with all appendices compiled
□ Risk register finalized with owners assigned
□ Treatment plan with 30/60/90 day milestones
□ Risk acceptance forms prepared for leadership
□ Findings briefed to technical team
□ Executive presentation delivered
□ Risk register loaded into GRC tool
□ Follow-up reassessment date scheduled
□ Lessons learned documented

Section Complete

What You've Covered

  • • Five complete TRA case studies across different industries
  • • Full TRA report template structure (8 sections + appendices)
  • • Regulatory mapping matrix (NIST CSF, ISO, PCI, HIPAA, SOX, GDPR)
  • • Pre/during/post assessment checklists
  • • Real-world treatment decisions with cost justification

Evidence to Capture

Adopting a case study means adopting its evidence discipline: every rating traceable, every treatment decision costed, every template row justified for the system in front of you.

Adapted scope: Which parts of the case study or template were applied, which were dropped as inapplicable, and the reason for each omission.

Inputs and their origin: The framework, the quantified inputs and where each came from, so the adapted assessment stays comparable with the source case.

Loss range and method: The annualised range with the method behind it — simulation inputs, or the qualitative scale used — not only the resulting figure.

Treatment decisions and cost: What was done, at what cost, against what quantified benefit, and who approved it.

Template revision used: The report template and checklist revision applied, so a later assessment can be diffed against this one.

Local deviations: Where the industry baseline was overridden for this environment, and on what evidence.

Template False Positives

Templates are persuasive: they produce a complete-looking document that may describe another organisation entirely.

  • Benchmark figure copied: A loss figure from a case study in another industry and control environment is a reference point, not an estimate for this system.
  • Template filled by habit: A completed template with unsourced inputs is a formatted opinion, and the audit finding follows the formatting rather than the content.
  • Control gap in the risk row: Templates invite listing missing controls in the risk column. State the event and the consequence instead.
  • Outcome adopted without its assumptions: Copying the treatment a case study chose, without the assumptions that produced it, buys controls with no measured effect.
  • Checklist completion as assurance: Ticking every pre-, during- and post-assessment row evidences process, not an assessed system.
  • Scope assumed rather than adapted: Each case study has its own architecture. Threats from an IoT fleet do not transfer to a web application without re-scoping.

Localise Before Adopting

Treatment is adoption with localisation, plus the cadence that keeps the template set honest as frameworks and systems move.

Localise

  • • Re-scope the template to this system and record the deviations
  • • Recalibrate loss figures against your own incident and benchmark data
  • • Replace example threats with threats the architecture can actually face

Keep the set current

  • • Version the report template and the checklists
  • • Re-map the regulatory matrix when a regulation or framework revision lands
  • • Retire case studies that no longer reflect the guidance in the earlier sections

Review trigger

  • • Framework or regulation revision
  • • New industry case that changes the baseline
  • • An assessment where a template row could not be completed because the input does not exist