Threat analysis and risk assessment (TARA)
IEC 81001-5-1:2021 · §5.2 — Security requirements and threat analysis
Key point
The Threat Analysis and Risk Assessment (TARA) is the foundational security activity in IEC 81001-5-1. Every security requirement, every design decision, and every security test traces back to a TARA finding. The TARA is a mandatory input to the Security Requirements Specification and must be maintained throughout the product lifecycle.
TARA in the context of IEC 81001-5-1 §5.2
IEC 81001-5-1 §5.2 requires the organisation to perform a threat analysis for each software system within scope. The TARA is explicitly analogous to the hazard analysis required by ISO 14971 for safety risk management — but instead of analysing physical failure modes leading to patient harm, the TARA analyses threat actors and attack vectors leading to security incidents that could in turn cause patient safety, privacy, or operational integrity failures.
The TARA must be initiated during the requirements phase and updated whenever: the software architecture changes significantly; new SOUP components are introduced; a security vulnerability is identified post-release; or the deployment environment changes.
Step 1: Asset identification
The first step is to identify what needs to be protected. For health software, typical security assets include:
- Patient health data (PHI / HIPAA-covered data / GDPR special category data)
- Device configuration and therapy parameters (e.g., infusion pump dosing limits)
- Software integrity (preventing unauthorised modification of device software)
- Device availability (ensuring the device can perform its intended function when needed)
- Audit logs and traceability records
- Authentication credentials and cryptographic keys
Step 2: Threat actor identification
IEC 81001-5-1 requires identifying the threat actors relevant to the deployment context. Typical threat actors for health software include:
| Threat actor | Typical motivation | Capability level |
|---|---|---|
| Opportunistic attacker | Financial gain (ransomware) | Low to medium — uses commodity tooling |
| Malicious insider | Sabotage, data theft, fraud | Medium — has privileged access |
| Nation-state actor | Espionage, disruption of critical infrastructure | High — advanced persistent threat (APT) |
| Competitor | IP theft, competitive sabotage | Medium to high |
| Researcher / white-hat | Recognition, responsible disclosure | High — but cooperative |
| Patient / user | Privacy access, self-harm, curiosity | Low — limited technical capability |
Step 3: Attack surface analysis
The attack surface is the set of paths through which an attacker can interact with the system. For health software, attack surfaces commonly include: network interfaces (REST APIs, HL7/FHIR endpoints, DICOM); removable media (USB, SD card); local network connections (Ethernet, Wi-Fi, Bluetooth); user interfaces (web applications, mobile apps); update mechanisms; and third-party integrations (cloud services, EHR connectors).
Step 4: Threat enumeration using STRIDE
IEC 81001-5-1 does not mandate a specific threat modelling methodology, but STRIDE is the most widely used in health software TARA practice. STRIDE systematically identifies six categories of threats:
| STRIDE category | Description | Health software example |
|---|---|---|
| Spoofing | Attacker impersonates a legitimate entity | Forged HL7 ADT message injecting false patient demographics |
| Tampering | Unauthorised modification of data or code | Alteration of therapy parameters in device configuration |
| Repudiation | Denial of an action that was performed | Clinician denies modifying alarm thresholds — no audit log |
| Information disclosure | Exposure of information to unauthorised parties | PHI leaked via unencrypted FHIR API response |
| Denial of service | Disruption of availability | Flood attack on infusion pump network interface causing device unavailability |
| Elevation of privilege | Gaining higher access rights than intended | Exploit in web UI allowing attacker to gain admin access |
Step 5: Security risk estimation
For each identified threat, the TARA must estimate the security risk. IEC 81001-5-1 does not prescribe a specific scoring method, but the CVSS (Common Vulnerability Scoring System) framework and the OWASP Risk Rating Methodology are commonly used. The risk is typically expressed as a function of: likelihood (probability that the threat will be realised, considering attacker capability and motivation) and impact (consequences if the threat is realised, including patient safety impact, privacy breach, and operational disruption).
Critically, the TARA must explicitly link security risks to patient safety. A security incident that could cause an incorrect therapy delivery — for example, a tampered infusion pump configuration — generates both a security risk in the TARA and a safety risk in the ISO 14971 risk management file. The two risk management processes must be coordinated to ensure the combined residual risk is acceptable.
Step 6: Security controls and residual risk
For each threat exceeding the risk acceptability threshold, the TARA must identify and document security controls. Controls are classified into preventive (reduce likelihood), detective (identify exploitation), and corrective (limit impact) types. Residual risk is estimated after controls are applied, and the TARA must demonstrate that all residual risks fall below the acceptability threshold.
TARA output documents
| Document | Content | Maintained by |
|---|---|---|
| TARA Report | Asset list, threat actor profiles, attack surface map, STRIDE threat enumeration, risk estimates, control assignments, residual risk summary | Security team / RA |
| Security Requirements Specification | Formal security requirements derived from TARA findings, each traceable to a specific threat | Systems engineering |
| Security Architecture Document | Architectural decisions implementing security controls, trust boundary diagrams, data flow diagrams | Software architect |
| Risk Management Report | Summary linking TARA security risks to ISO 14971 safety risks where patient harm is possible | RA / QA |
| TARA Change Log | Record of TARA updates triggered by architecture changes, new SOUP, post-release vulnerabilities | Security team |
Relationship to ISO 14971 risk management
The TARA and the ISO 14971 hazard analysis are separate but interconnected processes. The TARA focuses on threat actors and intentional exploitation; the hazard analysis focuses on random failures and use errors. However, a successful cyberattack is itself a hazard — for example, an attack that modifies drug delivery parameters can lead to patient harm. Manufacturers must establish a formal interface between the TARA and the Risk Management File to ensure that security threats with patient safety consequences are also captured as hazards in the ISO 14971 process.