Healthcare Example - Complete PASTA Walkthrough

This case study provides a complete, realistic walkthrough of threat modeling a healthcare patient portal using the PASTA methodology. You’ll see all seven stages applied with over fifty documented attack paths, two detailed attack trees, and a prioritized remediation plan.

The System: VitalCare Portal Patient Portal

VitalCare Portal is a patient portal for a mid-sized healthcare network. Here’s the system at a glance:

The portal handles protected health information (PHI) subject to HIPAA regulations. A breach could expose sensitive medical data, result in significant fines, and damage patient trust irreparably.

Let’s threat model it.

Stage 1: Define Business Objectives

The first PASTA stage establishes what we’re protecting and why. Without business context, threat modeling becomes a technical exercise disconnected from organizational reality.

Business Drivers

VitalCare Portal exists to improve patient experience and operational efficiency. Patients expect digital access to their healthcare information. Staff spend less time on phone calls when patients can self-serve. The portal differentiates the practice from competitors still using paper-based processes.

Revenue implications are significant. Patient satisfaction scores affect reimbursement rates. A competing health system launched their portal two years ago and has seen patient retention improve by 15%. The organization can’t afford to be left behind.

Security Objectives

Consequence of Failure

HIPAA fines range from $100 to $50,000 per record depending on negligence level, with annual caps of $1.5 million per violation category. With 500,000 patient records, theoretical exposure is enormous, though practical enforcement rarely reaches maximum levels.

Patient harm is harder to quantify but more important. Medical identity theft can follow victims for years. Sensitive diagnoses (HIV, mental health, substance abuse) being exposed can destroy lives.

Risk Appetite

The organization has zero tolerance for PHI breaches. This doesn’t mean zero risk exists (that’s impossible), but it means no known, unmitigated risks that could reasonably lead to PHI exposure are acceptable. Budget will be found for any control necessary to address credible PHI threats.

Key Stakeholders

Stage 2: Define Technical Scope

With business context established, Stage 2 maps the technical attack surface.

System Architecture

VitalCare Portal uses a modern cloud-native architecture hosted on AWS. The frontend is a React single-page application served from CloudFront CDN. The backend consists of Node.js microservices running in ECS containers. Data lives in PostgreSQL on RDS with Redis for caching and session storage. Documents and images are stored in S3.

Component Inventory

Third-Party Dependencies

Data Classification

Network Boundaries

Stage 3: Application Decomposition

Stage 3 creates detailed data flow diagrams and identifies every trust boundary where security assumptions change.

Primary Data Flows

Trust Boundary Analysis

Seven critical trust boundaries exist in this system:

Asset Inventory

Stage 4: Threat Analysis

Stage 4 identifies threats at multiple levels using STRIDE, industry intelligence, and attacker personas.

Industry Threat Intelligence

Healthcare is the most targeted industry for data breaches. The numbers are stark:

Common attack vectors include phishing (still the primary initial access method), exploitation of unpatched software, credential theft and reuse, insider threats (intentional and accidental), and third-party vendor compromises.

STRIDE Analysis: Authentication Service

Spoofing threats: An attacker could obtain valid credentials through phishing, credential stuffing (using passwords from other breaches), or brute force. Session tokens could be stolen through XSS attacks or insecure transmission. Auth0 itself could be compromised, though this is lower probability given their security focus.

Tampering threats: An attacker with access could modify authentication logic to bypass checks. JWT tokens without proper validation could be tampered with. OAuth flows could be manipulated if redirect URIs aren’t strictly validated.

Repudiation threats: Without adequate logging, users could deny login attempts. Attackers could cover tracks by manipulating or deleting audit logs. Legitimate users might not be able to prove they didn’t authorize certain actions.

Information disclosure threats: Authentication errors might reveal valid usernames. Failed login attempts might indicate valid accounts. Debug information might expose internal details. Password reset flows might confirm email addresses exist.

Denial of service threats: Account lockout mechanisms could be weaponized (locking out legitimate users). Excessive login attempts could exhaust resources. Auth0 rate limits could be triggered, affecting all users.

Elevation of privilege threats: Horizontal escalation where a user accesses another patient’s data. Vertical escalation where a patient gains provider privileges. Privilege escalation within Auth0 configuration giving users unintended roles.

STRIDE Analysis: Records Service

Spoofing: Requests might not have their user identity verified after passing the gateway. Service-to-service calls might lack proper authentication.

Tampering: SQL injection could modify database records. API parameter manipulation could alter what data is requested or modified. File uploads could contain malicious content.

Repudiation: Insufficient audit logging of record access. Bulk exports without adequate tracking.

Information disclosure: IDOR (Insecure Direct Object Reference) allowing access to other patients’ records. Excessive data in API responses. Error messages revealing system information. Logging sensitive data.

Denial of service: Expensive queries exhausting database resources. Large file operations consuming memory. Malformed requests causing service crashes.

Elevation of privilege: Provider impersonation to access restricted records. Administrative function access through parameter manipulation.

Attacker Persona Analysis

Threat Summary (Top 20 by Risk Score)

Additional Threats (THR-011 through THR-050):

The complete threat model documents 50 significant threats across four categories:

Stage 5: Vulnerability and Weakness Analysis

Stage 5 maps concrete weaknesses to the threats identified. This is where theoretical threats meet actual system state.

Code Review Findings

Configuration Issues

Dependency Scan Results

Penetration Testing Results

Weakness-to-Threat Mapping

Stage 6: Attack Modeling

Stage 6 creates detailed attack trees showing how attackers could achieve high-value goals. This connects individual threats into complete attack paths.

Attack Tree 1: Steal PHI Database

Goal: Exfiltrate complete PHI database (500,000 records)

Critical Chokepoint Analysis: Database access controls appear in multiple paths. Strengthening database authentication, implementing query monitoring, and eliminating direct database access from non-essential systems would disrupt several attack paths simultaneously.

Credential hygiene affects multiple paths. Proper secrets management, phishing resistance, and credential monitoring provide cross-cutting protection.

Attack Tree 2: Ransomware Attack

Goal: Encrypt systems and demand ransom for recovery

Kill Chain Disruption Points

Stage 7: Risk and Impact Analysis

Stage 7 prioritizes threats and creates an actionable remediation plan.

Risk Priority Summary

Business Impact Quantification

For THR-001 (Credential Stuffing), assume successful attacks compromise 0.1% of accounts monthly (500 accounts). Each compromised account potentially exposes that patient’s PHI. Breach notification costs run approximately $5 per affected patient. HIPAA fines for willful neglect not corrected could reach $50,000 per violation. With 6,000 compromises annually, potential exposure is $300,000 to $300M depending on severity classification and enforcement approach.

For THR-006 (Ransomware), the healthcare average ransom demand is $1.27M. Downtime costs run approximately $7,900 per minute for healthcare organizations. A two-week recovery (typical for healthcare ransomware) costs $159M in downtime alone. Add remediation costs, legal fees, notification, and reputation damage.

For THR-004 (IDOR), a single researcher discovering this publicly could lead to disclosure, regulatory investigation, mandatory remediation, and potential fines. Mass exploitation before discovery could affect thousands of patients.

Mitigation Plan

Immediate Actions (Week 1-2)

30-Day Actions

90-Day Actions

Address remaining medium-priority threats through systematic remediation. Implement comprehensive logging and monitoring improvements. Conduct security awareness training focused on phishing. Complete dependency vulnerability remediation. Establish regular penetration testing schedule.

Ongoing Activities

Monthly vulnerability scanning and remediation. Quarterly access reviews. Annual penetration testing. Continuous security awareness training. Regular threat model updates.

Risk Treatment Decisions

Residual Risk Assessment

Summary: Critical risk count drops from 2 to 0. High risk count drops from 9 to 3.

Budget Summary

Compared to potential breach cost of $50M to $200M, this represents strong ROI. The 30-day actions alone address threats with combined potential impact exceeding $500M.

Summary

This healthcare threat model identifies 50 threats across authentication, data access, infrastructure, and operational domains. Three critical threats require immediate action, and the prioritized remediation plan addresses them within two weeks. The 30-day plan tackles high-priority threats including ransomware preparedness and credential management.

Key Findings

The attack tree analysis reveals that database access controls and credential hygiene are critical chokepoints where investments disrupt multiple attack paths.

Total recommended first-year security investment: $628,000 against potential breach exposure of $50M to $200M plus business continuity impact.

Part 3 Complete | Continue to Part 4 →