37 Threat Modeling Examples

Learning Objectives

After completing these worked examples, you will be able to:

Conduct systematic STRIDE threat modeling for connected medical devices and other safety-critical IoT systems
Construct attack trees for critical threats and prioritize risks using DREAD scoring
Formulate mitigations with documented residual risk acceptance for regulatory submissions (e.g., FDA cybersecurity)
Execute incident response procedures including containment, eradication, and recovery for IoT security breaches

Key Concepts

Security scenario analysis: A structured examination of a specific IoT deployment situation, applying threat modelling, control selection, and risk assessment methodologies to produce concrete security design recommendations.
Worked threat model: A complete STRIDE-based threat model for a realistic IoT system, showing every analytical step from system decomposition through threat identification to mitigation selection.
Control trade-off analysis: The explicit evaluation of alternative security controls for a specific threat, comparing effectiveness, cost, operational impact, and residual risk to select the most appropriate option.
Defence validation: The process of verifying that a selected security control actually prevents or detects the threat it is intended to address, through testing, proof of concept, or formal verification.
Residual risk documentation: The formal recording of which risks remain after controls are implemented, who has accepted those risks, and under what conditions the acceptance remains valid.

In 60 Seconds

Worked security examples guide you through complete, step-by-step analysis of realistic IoT security scenarios — from threat identification through control selection to residual risk assessment — demonstrating the reasoning process that expert security engineers apply and making explicit the trade-offs that are invisible in theoretical descriptions.

For Beginners: Threat Modeling Examples

IoT security threats are the various ways that connected devices and their data can be compromised. Think of your IoT system as a house – you need to understand how burglars might try to get in before you can choose the right locks, alarms, and security cameras. This chapter helps you understand the threats so you can build effective defenses.

Sensor Squad: Security Detective Work!

“Time for the most exciting part – real worked examples!” Max the Microcontroller rubbed his hands together. “We are going to do threat modeling on a connected insulin pump. This is serious stuff because if a hacker compromises a medical device, someone could get hurt.”

Sammy the Sensor walked through the process. “First, we decompose the system – break it into pieces. The insulin pump has Bluetooth LE connecting to a phone app, which syncs with the cloud, which doctors can monitor. Each connection point is a potential attack surface. Then we apply STRIDE to each component and rate the risks using DREAD.”

“The worked example also shows incident response,” Lila the LED said. “What do you do when an attack actually happens? Step one: contain the damage – isolate the affected devices. Step two: eradicate the threat – remove the malware. Step three: recover – restore services from clean backups. Step four: learn – document what happened and improve defenses.”

“Following these step-by-step examples is the best way to learn threat modeling,” Bella the Battery encouraged. “You will see real mitigations like mutual TLS authentication, encrypted Bluetooth pairing, and firmware integrity verification. Each decision is explained with WHY it was chosen and what residual risk remains. Read through them carefully and you will be ready to threat model your own IoT projects!”

37.1 Worked Examples

This chapter provides detailed, step-by-step worked examples for threat modeling and incident response in IoT security.

Concept Relationships

Concept	Relates To	Nature of Relationship
STRIDE Analysis	System Decomposition	STRIDE applied to each component and trust boundary
DREAD Scoring	Risk Prioritization	Numeric scores guide mitigation resource allocation
Attack Trees	Critical Threat Analysis	Trees decompose complex attacks into step-by-step paths
Residual Risk	Acceptance Decisions	Documented residual risk enables informed acceptance
Incident Response	Containment Strategy	IR follows Detection → Containment → Eradication → Recovery
Regulatory Compliance	Threat Documentation	FDA, IEC 62443 require systematic threat analysis

37.2 Worked Example: Threat Modeling for Connected Medical Device

Scenario: MedTech Innovations is developing “GlucoSmart Pro,” a connected insulin pump for Type 1 diabetes patients. The device communicates via Bluetooth LE to a smartphone app, which syncs with cloud services for remote monitoring by healthcare providers.

Goal: Systematically identify threats using STRIDE, build attack trees for critical threats, prioritize risks, and document mitigations with residual risk acceptance for FDA cybersecurity documentation.

What we do: Map all components, data flows, and trust boundaries in the insulin pump ecosystem.

System Components:

Component	Description	Trust Level
Insulin Pump	MCU (ARM M4), BLE radio, insulin reservoir	Device
Mobile App	iOS/Android app for display, dose adjustment	User
Cloud API	AWS API Gateway, patient database	Cloud
Provider Portal	Healthcare provider web interface	External

Data Flow Inventory:

Flow ID	Source	Destination	Data Type	Sensitivity
DF-1	Pump	Mobile App	Glucose readings, dosing	PHI - HIGH
DF-2	Mobile App	Pump	Dose commands	Safety-Critical
DF-3	Mobile App	Cloud	Sync data	PHI - HIGH
DF-4	Cloud	Provider Portal	Patient history	PHI - HIGH
DF-5	Pump	Pump	Firmware updates	Integrity-Critical

STRIDE Threat Matrix:

Component	S	T	R	I	D	E
Insulin Pump	S1, S2	T1, T2	R1	I1	D1, D2	E1
BLE Connection	S3	T3, T4	R2	I2, I3	D3	-
Mobile App	S4	T5	R3	I4	D4	E2
Cloud API	S5	T6	R4	I5	D5, D6	E3

Key Threats Identified:

S1: Attacker spoofs legitimate mobile app to pump
T1: Firmware modification via debug interface
T3: BLE packet modification in transit (MITM)
T4: Replay attack of previous dose commands
I2: BLE sniffing exposes health data
D1: Battery exhaustion attack
E1: Debug mode enables unauthorized commands

Threat ID	Threat Description	D	R	E	A	D	Score	Priority
T-001	BLE MITM dose injection	10	7	5	1	7	30	CRITICAL
T-002	Firmware tampering via JTAG	10	8	3	1	5	27	CRITICAL
T-003	BLE replay attack	10	6	7	1	8	32	CRITICAL
T-005	Cloud API credential theft	5	7	6	10	8	36	CRITICAL
T-006	SQL injection patient data	5	8	7	10	6	36	CRITICAL

Critical Threat Mitigations:

T-001: BLE MITM Dose Injection

M1.1: Implement BLE Secure Connections (LESC) with numeric comparison (90% effective)
M1.2: End-to-end encryption with device-specific keys (95% effective)
M1.3: Command authentication with HMAC-SHA256 (85% effective)
M1.4: Dose command timeout - 10 second validity (70% effective)

T-002: Firmware Tampering via JTAG

M2.1: Disable JTAG in production fuses (95% effective)
M2.2: Secure boot with RSA-2048 signed firmware (90% effective)
M2.3: Hardware tamper detection - mesh sensor (80% effective)
M2.4: Firmware integrity monitoring (75% effective)

T-003: BLE Replay Attack

M3.1: Sequence numbers on all commands (95% effective)
M3.2: Timestamp validation - 10 second window (85% effective)
M3.3: Session tokens with 15-minute refresh (90% effective)

Residual Risk Summary:

Threat	Initial Score	Post-Mitigation	Reduction	Status
T-001 BLE MITM	30	8	73%	ACCEPT
T-002 Firmware Tamper	27	5	81%	ACCEPT
T-003 Replay Attack	32	6	81%	ACCEPT
T-005 Credential Theft	36	10	72%	ACCEPT
T-006 SQL Injection	36	4	89%	ACCEPT

Compensating Controls:

All dose commands logged with millisecond timestamps
Anomaly detection flags unusual patterns
24/7 clinical support hotline
Hardware override button on pump
Automatic glucose monitoring with alerts

Outcome: Comprehensive threat model documenting 10 significant threats, STRIDE analysis, attack trees, and mitigations reducing critical threat scores by 72-89%.

Key Decisions:

Chose BLE over Wi-Fi for proximity-based security
Allocated budget for secure elements despite 40% BOM increase
Required minimum 3 mitigations per critical threat
Accepted narrow residual risks with compensating controls

FDA Submission Artifacts:

Threat model documentation
STRIDE threat matrix with CVSS scores
Attack trees for life-threatening scenarios
Mitigation effectiveness analysis
Residual risk acceptance with clinical justification

Knowledge Check: Medical Device Threat Modeling

37.3 Worked Example: Incident Response for IoT Breach

Scenario: SmartTower Properties manages a 45-story commercial building with 2,400 IoT devices. At 2:47 AM, the SOC detects that 23 HVAC controllers are communicating with an unknown external IP address in Eastern Europe.

Goal: Execute structured incident response following NIST SP 800-61 guidelines while maintaining building operations and tenant safety.

Detection Timeline:

Time	Event
02:47:00	SIEM alert: Unusual outbound traffic from HVAC subnet
02:47:15	SOC analyst reviews, sees 23 devices affected
02:48:00	Analyst confirms traffic to known C2 server
02:52:00	Incident declared, IR team lead notified
02:55:00	IR team assembles, initial briefing
03:00:00	Severity classified as HIGH

Initial Indicators of Compromise:

Outbound HTTPS to 185.xx.xx.xx:443
Modified firmware hash on affected controllers
New user account “svc_maintenance” with admin rights
Scheduled task executing at 02:45 daily

Business Impact Assessment:

No immediate safety risk (HVAC has fail-safe)
Tenant comfort may be affected if HVAC disabled
Data exfiltration includes occupancy patterns (GDPR concern)

Short-Term Containment Actions (03:00 - 03:45):

Network Isolation (03:05)
- Block outbound traffic to C2 IP at perimeter firewall
- Enable ACL on BACnet switch: deny non-essential traffic
- Affected controllers can still reach BMS internally
Evidence Preservation (03:15)
- Capture network traffic from affected VLAN
- Snapshot memory of 3 affected controllers
- Export SIEM logs for 72-hour window
Prevent Lateral Movement (03:25)
- Disable BACnet routing between floor segments
- Reset BBMD (BACnet Broadcast Management Device)
- Enable enhanced logging on unaffected floors
Maintain Operations (03:35)
- Switch affected floors to manual HVAC schedules
- Notify building operations team
- Document degraded mode procedures

Containment Decision: Segment rather than full isolate - maintains safe operations for ~2,000 workers while containing threat.

Root Cause Analysis:

Root Cause: Default credentials on HVAC controllers

Attack Vector: "All affected units had factory password 'trane123'"
Timeline: Likely compromised 3+ months ago

Persistence Mechanisms Found:
- Modified firmware with backdoor
- Scheduled task "svc_daily_sync" (runs 02:45 daily)
- Backdoor account "svc_maintenance"

Eradication Steps (04:00 - 08:00):

Phase	Time	Actions
Firmware Recovery	04:00-06:00	Obtain clean firmware, test on single device
Mass Remediation	06:00-07:30	Reflash all 23 controllers with clean firmware
Credential Rotation	07:30-08:00	Change passwords on ALL 180 HVAC units
Verification	08:00-09:00	Verify no C2 traffic, check firmware hashes

Phased Recovery (09:00 - 12:00):

Floor 15 (Pilot):

09:00: Reconnect 3 HVAC units to BACnet VLAN
09:15: Verify BMS communication restored
09:30: Enable automated schedules
10:00: Monitor for 30 minutes
10:30: Confirm normal operation, proceed to next floor

Floors 16-22 (Rolling):

10:30-12:00: Restore remaining floors (20 min each)
Each floor gets 15-min monitoring period
Any anomaly triggers immediate rollback

Security Enhancements Deployed:

Permanent VLAN separation by floor
BACnet traffic inspection at boundaries
Outbound internet blocked for all BACnet devices
Unique passwords per device (stored in PAM)
90-day rotation schedule
BACnet-aware IDS rules

Root Cause (5 Whys):

Why did the breach occur?
-> Attackers gained access to HVAC controllers

Why could attackers access controllers?
-> Controllers had default passwords and internet access

Why did controllers have default passwords?
-> No password change process during 2019 installation

Why was there no password change process?
-> Building systems not included in IT security policies

Why were building systems excluded?
-> OT/IT security silos; no IoT security program

ROOT CAUSE: Lack of unified IT/OT security governance

Remediation Actions:

Finding	Owner	Due Date
Credential audit for all building systems	Facilities + IT	30 days
Network segmentation project	Network team	60 days
Firmware verification tooling	Security Ops	45 days
Update InfoSec policy for OT/IoT	CISO	14 days
Vendor access management	IT Ops	30 days
OT-specific IR procedures	Security Ops	45 days

Metrics:

Metric	Value
Time to detection	18 minutes
Time to containment	48 minutes
Time to eradication	5.5 hours
Time to full recovery	9 hours
Tenant-impacting downtime	0 hours
Total incident cost	~$125,000

Security Posture Improvements:

Before	After (60 days)
40% default credentials	0% default credentials
Flat network (2,400 devices)	12 segments with inspection
No OT security monitoring	BACnet-aware IDS (47 rules)
Building systems excluded from policy	Unified IT/OT policy
No IR playbook for building systems	Tested playbook (tabletop completed)

Worked Example: Smart City Traffic Light Security Breach

Scenario: MetroCity operates 500 intelligent traffic lights connected via 4G cellular. A security incident exposed vulnerabilities in the deployment.

Initial Setup:

Traffic controllers: ARM Cortex-M4, 4G modem, running Linux
Authentication: Default credentials (username: admin, password: admin123)
Network: Public internet access, no firewall
Update mechanism: HTTP firmware downloads every 30 days
Total deployment cost: $15M

Attack Timeline:

Time	Event	Impact
Day 0	Attacker scans public IPs, discovers open SSH (port 22)	Discovery
Day 1	Brute force attack succeeds with default credentials	Initial access
Day 2-7	Attacker establishes persistence, maps network	Lateral movement
Day 8	Malware deployed to 350 controllers	Compromise
Day 9	Traffic lights turn green simultaneously during rush hour	Operational impact
Day 10	City detects anomaly, begins investigation	Detection

STRIDE Analysis:

Threat	Attack Vector	Actual Impact	DREAD Score
Spoofing	Default credentials allowed impersonation	Full admin access	8/10
Tampering	HTTP firmware updates allowed malware injection	Compromised 350 units	9/10
Repudiation	No audit logging of admin actions	Cannot trace attacker actions	6/10
Information Disclosure	Unencrypted 4G communication	Traffic patterns exposed	5/10
Denial of Service	All lights green simultaneously	3 accidents, 2 hours gridlock	10/10
Elevation of Privilege	Root access via default SSH	Complete system control	9/10

Financial Impact Analysis:

Direct Costs:
- Emergency response team: $50,000
- Forensic investigation: $120,000
- Firmware remediation (500 units): $200,000
- Manual traffic control (48 hours): $80,000
Total Direct: $450,000

Indirect Costs:
- Productivity loss (2-hour gridlock): ~$2M
- Legal settlements (3 accidents): $1.5M
- Reputation damage and public trust: Unquantified
Total Incident Cost: ~$4M

Recommended Mitigations:

Immediate (Week 1):

Change all passwords to unique 20-character random strings
Disable SSH access, enable only during maintenance
Deploy emergency firewall rules blocking external access

Short-term (Month 1):

Implement certificate-based authentication (X.509)
Switch firmware updates to HTTPS with signature verification
Deploy VPN for all management access
Enable audit logging to tamper-proof SIEM

Long-term (6 months):

Hardware security modules for key storage
Network segmentation by geographic zone
Anomaly detection using ML (detect unusual timing patterns)
Implement secure boot and firmware attestation

Lessons Learned:

Finding	Root Cause	Prevention
Default credentials	No password change process during deployment	Automated provisioning with unique credentials
Unencrypted firmware	Legacy HTTP update mechanism	HTTPS + Ed25519 signature verification
No network segmentation	Flat network design	Zone-based VLANs with firewall inspection
Lack of monitoring	No anomaly detection	Real-time behavioral analysis
Public internet exposure	No access control	VPN-only management access

Key Insight: Defense in depth failed here because there was NO depth - a single control failure (default credentials) led to complete compromise. The city should have implemented multiple layers: unique credentials AND VPN access AND certificate authentication AND anomaly detection.

Cost-Benefit Analysis:

Security Control	Implementation Cost	Annual Maintenance	Breach Prevention Value
Unique credentials	$25,000	$0	Would have prevented this breach
Certificate auth	$150,000	$30,000	Prevents credential theft attacks
VPN access control	$80,000	$15,000	Prevents public exposure
Firmware signing	$100,000	$20,000	Prevents malware injection
Total investment	$355,000	$65,000/yr	Prevented $4M loss

ROI: The security investment ($355K upfront + $65K annual) is less than 10% of the breach cost ($4M). Even if a breach occurs only once per decade, the investment pays for itself.

Decision Framework: Selecting Threat Modeling Methodology

When choosing a threat modeling approach for your IoT system, use this framework:

Criterion	STRIDE	DREAD	Attack Trees	PASTA	Trike
Best for	Early design	Risk prioritization	Critical threats	Enterprise	Data flow focus
Time required	2-4 hours	1-2 hours	4-8 hours	8-16 hours	4-8 hours
Team size	3-5 people	2-3 people	2-4 people	5-10 people	3-5 people
Expertise needed	Medium	Low	High	High	Medium
Output format	Threat matrix	Risk scores	Tree diagrams	Full framework	Attack scenarios
Regulatory fit	FDA, IEC 62443	General	Safety-critical	NIST CSF	Privacy-focused

Decision Tree:

START: What is your primary goal?
│
├─ Regulatory compliance (FDA, IEC 62443)
│  └─ Use STRIDE + DREAD
│     (Most regulators accept this combination)
│
├─ Focus on critical safety threats
│  └─ Use Attack Trees
│     (Detailed analysis of life-threatening scenarios)
│
├─ Quick risk assessment for existing system
│  └─ Use DREAD only
│     (Fast scoring, good for triage)
│
├─ Enterprise-wide security program
│  └─ Use PASTA
│     (Comprehensive, aligns with NIST CSF)
│
└─ Privacy-focused system (GDPR, HIPAA)
   └─ Use Trike
      (Emphasizes data flow and access control)

Example: Medical Device Selection:

For a connected insulin pump: - Primary requirement: FDA cybersecurity documentation - Safety criticality: High (life-threatening if compromised) - Team: 4 people (firmware, security, QA, clinical) - Timeline: 3 weeks for initial model

Recommended approach: STRIDE for comprehensive threat identification + Attack Trees for top 3 critical threats + DREAD for prioritization.

Why this combination:

STRIDE ensures no threat categories are missed
Attack Trees provide detailed analysis for regulators
DREAD scores justify resource allocation to management

Common Mistake: Treating Threat Modeling as a One-Time Activity

The Mistake: Many teams perform threat modeling during initial design and never revisit it as the system evolves.

Why It Happens:

Pressure to meet development deadlines
Perception that threat modeling is “done” after initial documentation
No process for triggering updates

Real-World Example:

A smart home hub initially threat-modeled in 2020: - Original design: Local-only control, no cloud connection - Threat model documented: Physical access, local network attacks - Considered safe: No internet exposure

Over 3 years, features added: - 2021: Optional cloud synchronization added - 2022: Voice assistant integration (requires internet) - 2023: Third-party app ecosystem launched - Threat model: Never updated

Result: A critical vulnerability discovered in 2023 - the third-party app API had no authentication. Attackers could control any hub remotely. The original threat model said “no internet exposure” but the system had evolved into a cloud-connected platform.

The Fix:

Trigger Event	Action Required
New feature with network connectivity	Full threat model update
Integration with third-party service	Review trust boundaries
Change in deployment environment	Reassess attack surface
Security incident (any IoT device)	Review similar vectors
Annual review	Full threat model refresh

Implementation:

BEFORE adding any feature, ask:
1. Does this change the attack surface?
   ├─ Yes → Update threat model BEFORE implementation
   └─ No → Document why no update needed

2. Does this change trust boundaries?
   ├─ Yes → Reassess STRIDE for affected components
   └─ No → Proceed with existing model

3. Does this introduce new data flows?
   ├─ Yes → Update data flow diagrams, re-run STRIDE
   └─ No → Proceed with existing model

Pro Tip: Treat threat models as living documents. Include threat model review as a mandatory step in your change management process, alongside code review and testing. Set calendar reminders for annual full reviews even if no features changed - threat landscape evolves independently of your system.

Cost of ignoring this: The smart home hub breach affected 2.3M devices, cost $50M in remediation, and resulted in a class-action lawsuit. An updated threat model would have caught the API authentication gap during design review, preventing the vulnerability entirely.

Match: Incident Response Phases to Their Primary Activities

Order: STRIDE Threat Modeling Process for an IoT Medical Device

37.4 Knowledge Check

Putting Numbers to It: Residual Risk Quantification

Residual risk after mitigation is calculated as:

\[R_{\text{residual}} = R_{\text{initial}} \times (1 - E_{\text{mitigation}}) + R_{\text{new}}\]

where $E_{\text{mitigation}}$ = mitigation effectiveness (0-1), $R_{\text{new}}$ = risk introduced by mitigation itself.

37.4.1 Interactive Residual Risk Calculator

Use this calculator to explore how layered mitigations affect residual risk:

Show code

viewof initialRisk = Inputs.range([0, 10], {value: 7.2, step: 0.1, label: "Initial DREAD Score"})
viewof e1 = Inputs.range([0, 1], {value: 0.90, step: 0.01, label: "Mitigation 1 Effectiveness (E₁)"})
viewof e2 = Inputs.range([0, 1], {value: 0.95, step: 0.01, label: "Mitigation 2 Effectiveness (E₂)"})
viewof e3 = Inputs.range([0, 1], {value: 0.85, step: 0.01, label: "Mitigation 3 Effectiveness (E₃)"})
viewof e4 = Inputs.range([0, 1], {value: 0.70, step: 0.01, label: "Mitigation 4 Effectiveness (E₄)"})
viewof riskFP = Inputs.range([0, 1], {value: 0.3, step: 0.05, label: "False Positive Risk (R_FP)"})
viewof riskBattery = Inputs.range([0, 1], {value: 0.2, step: 0.05, label: "Battery Drain Risk (R_battery)"})

Show code

combinedEffectiveness = 1 - (1 - e1) * (1 - e2) * (1 - e3) * (1 - e4)
residualAttackRisk = initialRisk * (1 - combinedEffectiveness)
finalResidualRisk = residualAttackRisk + riskFP + riskBattery
reductionPercent = ((initialRisk - finalResidualRisk) / initialRisk * 100).toFixed(1)

html`
<div style="background: #f8f9fa; padding: 20px; border-radius: 8px; border-left: 4px solid #2C3E50; margin: 20px 0;">
  <h4 style="color: #2C3E50; margin-top: 0;">Results</h4>

  <div style="display: grid; grid-template-columns: 1fr 1fr; gap: 15px; margin-bottom: 15px;">
    <div style="background: white; padding: 15px; border-radius: 6px;">
      <div style="font-size: 0.9em; color: #666; margin-bottom: 5px;">Combined Effectiveness</div>
      <div style="font-size: 1.8em; font-weight: bold; color: #16A085;">${(combinedEffectiveness * 100).toFixed(2)}%</div>
    </div>

    <div style="background: white; padding: 15px; border-radius: 6px;">
      <div style="font-size: 0.9em; color: #666; margin-bottom: 5px;">Residual Attack Risk</div>
      <div style="font-size: 1.8em; font-weight: bold; color: #3498DB;">${residualAttackRisk.toFixed(4)}</div>
    </div>
  </div>

  <div style="background: white; padding: 20px; border-radius: 6px; margin-bottom: 15px;">
    <div style="font-size: 0.9em; color: #666; margin-bottom: 5px;">Final Residual Risk (with mitigation-introduced risks)</div>
    <div style="font-size: 2.2em; font-weight: bold; color: ${finalResidualRisk < 1 ? '#16A085' : finalResidualRisk < 3 ? '#E67E22' : '#E74C3C'};">
      ${finalResidualRisk.toFixed(2)} / 10
    </div>
    <div style="font-size: 1.1em; color: #2C3E50; margin-top: 10px;">
      <strong>Risk Reduction:</strong> ${reductionPercent}%
      <span style="color: #666;">(from ${initialRisk.toFixed(1)} to ${finalResidualRisk.toFixed(2)})</span>
    </div>
  </div>

  <div style="background: ${finalResidualRisk < 1 ? '#d4edda' : finalResidualRisk < 3 ? '#fff3cd' : '#f8d7da'};
              padding: 15px; border-radius: 6px; border: 1px solid ${finalResidualRisk < 1 ? '#c3e6cb' : finalResidualRisk < 3 ? '#ffeeba' : '#f5c6cb'};">
    <strong style="color: ${finalResidualRisk < 1 ? '#155724' : finalResidualRisk < 3 ? '#856404' : '#721c24'};">
      FDA Assessment: ${finalResidualRisk < 1 ? 'ACCEPTABLE' : finalResidualRisk < 3 ? 'MARGINAL - Additional controls recommended' : 'UNACCEPTABLE - Requires stronger mitigations'}
    </strong>
  </div>

  <div style="margin-top: 20px; padding: 15px; background: #e8f4f8; border-radius: 6px;">
    <div style="font-size: 0.95em; color: #2C3E50;">
      <strong>Calculation:</strong><br>
      E<sub>total</sub> = 1 - (${(1-e1).toFixed(2)}) × (${(1-e2).toFixed(2)}) × (${(1-e3).toFixed(2)}) × (${(1-e4).toFixed(2)}) = ${combinedEffectiveness.toFixed(4)}<br>
      R<sub>residual</sub> = ${initialRisk.toFixed(1)} × (1 - ${combinedEffectiveness.toFixed(4)}) = ${residualAttackRisk.toFixed(4)}<br>
      R<sub>final</sub> = ${residualAttackRisk.toFixed(4)} + ${riskFP.toFixed(2)} + ${riskBattery.toFixed(2)} = ${finalResidualRisk.toFixed(2)}
    </div>
  </div>
</div>
`

Key Insight: Notice how layered mitigations multiply their effectiveness. Four controls at 70-95% effectiveness combine to 99.98% effectiveness, reducing attack risk from 7.2 to 0.0014. However, the mitigations themselves introduce operational risks (false positives, battery drain), yielding a final residual of 0.50 - still LOW but not zero.

37.4.2 Worked Calculation: Insulin Pump Security Mitigations

Given: Initial DREAD score for BLE MITM attack = 7.2/10

Step 1: Calculate effectiveness of layered mitigations - M1 (BLE Secure Connections): $E_1 = 0.90$ (90% effective) - M2 (End-to-end encryption): $E_2 = 0.95$ - M3 (HMAC command auth): $E_3 = 0.85$ - M4 (10s timeout): $E_4 = 0.70$

Combined effectiveness (assuming independence): \[E_{\text{total}} = 1 - (1 - E_1)(1 - E_2)(1 - E_3)(1 - E_4)\] \[E_{\text{total}} = 1 - (0.10)(0.05)(0.15)(0.30) = 1 - 0.000225 = 0.9998\]

Step 2: Calculate residual risk \[R_{\text{residual}} = 7.2 \times (1 - 0.9998) = 7.2 \times 0.0002 = 0.0014\]

Step 3: Add mitigation-introduced risks - Timeout false positives (legitimate commands rejected): $R_{\text{FP}} = 0.3$ - Encryption overhead battery drain: $R_{\text{battery}} = 0.2$ \[R_{\text{final}} = 0.0014 + 0.3 + 0.2 = 0.50\]

Result: Mitigations reduce attack risk from 7.2 to 0.0014 (99.98% reduction), but introduce operational risk of 0.50, yielding final residual 0.50/10 = LOW (acceptable for FDA submission).

Step 4: Calculate acceptable residual risk threshold For life-safety systems, acceptable residual risk: \[R_{\text{accept}} < \frac{1}{MTBF_{\text{target}}}\]

With target Mean Time Between Failures = 10,000 years: \[R_{\text{accept}} < \frac{1}{10,000} = 0.0001 \text{ failures/year}\]

Converting DREAD to failure probability (empirical): \[P(\text{failure}) = \frac{R_{\text{DREAD}}}{10} \times P(\text{attack})\]

With $P(\text{attack}) = 0.001$ per device-year: \[P(\text{failure}) = \frac{0.50}{10} \times 0.001 = 0.00005\]

Result: $P(\text{failure}) = 0.00005 < 0.0001$ threshold, residual risk is ACCEPTABLE for medical device deployment.

In practice: Regulators (FDA, IEC 62443) require quantitative residual risk documentation. Subjective “we think it’s safe enough” is insufficient - mathematical proofs of acceptable risk levels are mandatory for safety-critical deployments.

Label the Diagram

37.5 What’s Next

Now that you’ve studied detailed worked examples, continue to:

Visual Reference Gallery - Review security diagrams and attack visualizations
Interactive Security Tools - Use risk calculators and visualizers
Practice Exercises - Apply your knowledge with hands-on exercises

Previous	Current	Next
Practice Exercises	Threat Modeling Examples	Exam Preparation

Common Pitfalls

1. Reading worked examples passively without attempting the analysis first

The maximum learning value of a worked example is obtained by attempting the analysis yourself before reading the solution. Write down your threat identification, control selection, and risk assessment before comparing to the worked solution.

2. Treating the worked example solution as the only correct answer

Security problems often have multiple valid solutions with different trade-offs. If your analysis reached a different conclusion than the worked example, evaluate whether your answer is also defensible — security engineering involves judgment, not unique correct answers.

3. Not generalising from worked examples to similar problems

A worked example for a smart building HVAC system teaches principles applicable to industrial control systems, smart vehicles, and medical devices if you extract the generalised pattern rather than memorising the specific IoT domain solution.

💻 Code Challenge