Threat model
A summary of the EDFlow threat and risk assessment: attacker models, STRIDE threats per component, the top risks and their mitigations, and residual risks.
Cette page n'est pas encore offerte en français; elle est affichée en anglais.
This is a summary. The full threat model is part of the confidential security package.
Objectives
- People see only what their role and relationship allow.
- No health information leaves the custodian's boundary: never in push, SMS, email, URLs, logs, analytics or sub-processors.
- Every access to a patient's information is attributable and reviewable.
- A stolen database copy opens no visit, link or account.
- Guessing a credential is infeasible within a visit's lifetime.
- A compromise is contained in minutes and scoped for notification in hours.
- The EHR feed can't be forged, replayed or used to exfiltrate data.
- The service stays available for staff under attack and fails safe for patients.
Attackers considered
| Attacker | Goal |
|---|---|
| Opportunistic internet attacker | Enumerate tokens and codes, credential stuffing, denial of service |
| Someone who knows the patient (for example an abusive partner) | Follow the visit, learn location or care details |
| Finder of a lost card | Open the visit |
| Another person in the waiting room | Read a screen, phish with a fake QR poster |
| Curious or malicious staff member | Snoop on a neighbour, celebrity or colleague |
| Compromised staff account | Everything above plus admin actions |
| Compromised integration engine | Forge or replay events, push PHI into prohibited fields |
| Compromised third party | Read message content, inject code |
| Malicious or careless operator | Bulk read, tamper with audit, disable controls |
STRIDE summary
| Threat | Main mitigations |
|---|---|
| Spoofing a patient or staff member | High-entropy tokens, knowledge factor on second devices, reverse pairing, MFA, SSO, device lock on staff phones |
| Tampering with events or audit | HMAC or OAuth ingest with a replay window, idempotency, append-only audit with a daily hash chain |
| Repudiation | Every staff action attributed and audited, with the membership and tab |
| Information disclosure | Projections per audience, generic notifications, tokens in URL fragments, log redaction, prohibited fields, site isolation |
| Denial of service | Per-target rate limits, WAF, size limits, queued engines that absorb outages, offline-safe patient screens |
| Elevation of privilege | Server-side authorization, separation of duties, two-person approvals for privileged roles and exports, step-up for sensitive actions |
Top risks and mitigations
| Risk | Mitigation |
|---|---|
| Wrong patient linked to a phone | Tokens with 128 bits of entropy, knowledge factor, rate limits, "Is this you?", staff revoke and reissue, "This wasn't me" |
| PHI leaking through adapters or logs | Raw payloads never stored; log allow-list; prohibited-field tripwire; CI payload tests |
| Insider browsing | Audit before read, monitoring rules (for example more than 30 patients in an hour, confidential access off the care team), quarterly access review |
| "Ghost" patients after a lost discharge message | Roster reconciliation and stale-visit closing, with a circuit breaker for bad rosters |
| Code-delay notices cause alarm | Only medical codes, approved generic copy, no location or count, subject and area excluded |
| Patients read "results are back" as "about to be seen" | Tested copy, usual reassessment range, never a promise |
| Residency requirements | Self-hosted in Canada; US providers optional, env-gated and carrying no PHI |
Residual risks
- A patient who shares their screen or phone shares their visit; the app offers a generic lock screen, biometric lock and "Sign out and forget this device".
- Text messages reveal that a phone number is associated with an ED visit to the SMS provider; texts are off unless the patient opts in.
- A hospital-network host holding a source key can send false events within its allowed types and sites until the key is revoked; IP allowlists and monitoring limit this.
Related
Dernière mise à jour le
Cette page vous a-t-elle été utile?
Controls
The EDFlow controls matrix: authentication and MFA, server-side authorization and projections, token hashing, encryption, rate limits, audit, log redaction, security headers and CSP, supply chain, vulnerability management and penetration testing.
Data residency
Where EDFlow stores hospital data: AWS ca-central-1 with disaster recovery in ca-west-1, backups in Canada, RPO and RTO, the web tier in Montréal, and which environments hold synthetic data only.