Security Risk Analysis Under AAMI SW96: A Worked Example on a Vital-Signs Bracelet. Part II. Risk Control.
- Alex Moskvin
- 1 day ago
- 10 min read
In Part 1 we reframed how you rate a threat to a connected medical device: severity alone flattens everything to "Serious," so we paired it with exploitability - how reachable the attack actually is: to turn a flat list into an ordered one. That gives us an initial risk for every threat, before anything is done about it.
This second part is about what you do with those ratings. It turns on one idea that separates medical-device security from ordinary infosec - that some of these risks don't stop at the data, they reach the patient - and follows the reasoning through to its honest end: how controls actually lower risk, why they can't lower all of it, and what a defensible record of the leftover looks like.
3 Risk Control
This section describes what mitigating controls have to be applied to the risks evaluated in Section 2.
3.1 Common Mitigation Controls
According to STRIDE recommendations, following high-level desired mitigation controls are advised.
Table 2.14 – STRIDE desired resolution strategy
STRIDE element | Desired Property |
|---|---|
Spoofing | Authentication |
Tampering | Integrity |
Repudiation | Traceability/Non-repudiation |
Information Disclosure | Confidentiality |
Denial Of Service (DOS) | Availability |
Elevation of Privilege (EoP) | Authorization |
There are standard actions for each threat according to the STRIDE classification.
Table 2.15 – STRIDE common mitigation controls
Mitigation Technique | STRIDE Element | Mitigation Control |
|---|---|---|
Authentication | S | External devices have to authenticate themselves using X.509 certificates |
Digital Signature | T | Secure Boot |
Authorization | E | Device role is part of the certificates |
De-identication | I | Pseudonymization |
Filtering | I, T, D | Allow-List |
Message authentication code | T | Append an HMAC to each Log Record |
Physical tamper resistant | T | Protect the chassis of the device |
Protect secrets and secret data | I,T | AES-256 Encryption |
Input sanitization | I,T,D | Sanitize data received from external device |
Least privileges | E | Role concept |
Audit trail | R | Security Event Log |
3.2 Advanced Mitigation Controls
The controls in 3.1 address individual threats at the property level. The four capabilities below go deeper: they are cross-cutting mechanisms - tamper-evident logging, SIEM, mandatory access control, and configuration management - that several of the per-asset controls in 3.3 rely on. Each is described here once, in its own right, so the mitigation table that follows can reference it rather than re-explain it.
3.2.1 Secure logging
The main objective of the secure logging module is to provide tamper evident logging, i.e. to adequately protect log records of an information system and to provide a sensor indicating attack attempts. The secure logging module achieves this by authentically encrypting each log record with an individual cryptographic key used only once and protecting the integrity of the whole log archive by a cryptographic authentication code.
Each attempt to tamper with either an individual log record or the log archive itself will be immediately detected during log archive verification. Therefore, an attacker can no longer tamper with log records without being detected.
Solution: A log entry should be a pair Xn = (Mn, Tn), where Mn is the nth log message received, and where Tn = Hash(Xn-1) is the cryptographic hash of the last log entry. Use a collision-resistant cryptographic hash function for this purpose (example SHA256).
It’s proposed to implement the solution using the following toolchain:
syslog-ng + secure logging (slogkey + slogverify)
More explanation and usage examples can be found here: https://www.mankier.com/7/secure-logging
3.2.2 Security Information and Event Management (SIEM) usage
SIEM is a security platform that collects and analyzes data from various sources, such as network devices, servers, and applications, in real-time. By centralizing and analyzing this data, a SIEM tool can identify and alert on potential security threats, as well as provide detailed insights into past security incidents.
SIEM is represented as a nonbinding recommendation by Cybersecurity in “Medical Devices: Quality System Considerations and Content of Premarket Submissions” document re
It’s proposed to use the SIEM tool to capture forensic evidence, including but not limited to any log files kept for a security event:
Device telemetry (PAS.7)
Diagnostic Logs (IAS.3)
SIEM is supposed to collect logs from target medical devices through Android clients acting as proxy/gateway to the cloud instance of SIEM system.
Figure 3.1 – High-level diagram that depicts high-level SIEM integration approach
The following table describes types of logs that’s proposed to have and their functional designation.
Table 2.16 – Logging scope
Log aspect | Logging scope | Log format |
Vital signs readings |
| |
Battery level |
| Syslog using syslog-ng (see section 3.2.1 for the reference) |
BLE session events |
| |
System resource utilization (similar to sar) | CPU load | |
RAM usage | ||
IOPS allocation | ||
Swap usage (if applicable) | ||
File system utilization | ||
Run queue length | ||
Target application infrastructure | CPU usage by vital signs reading applications | |
Firmware management application | ||
OS infrastructure changes | Changes done to the OS files /etc and /sbin, /usr/bin files | |
Target application infrastructure changes | Changes done to the target application configuration files and binaries | |
MAC (SELinux) security events | Restrictive actions |
Figure 3.2 – Diagram that explain logging of telemetry and application diagnostic logs
3.2.3 Mandatory access control (MAC) usage
Mandatory access control (MAC) is a model of access control where the operating system provides users with access based on data confidentiality and user clearance levels. In this model, access is granted on a need-to-know basis: users must prove their need for information before gaining access.
MAC is also called a non-discretionary access control model, which means that control isn’t granted at the discretion of the user or file owner. The control mechanisms of the MAC model enable organizations to implement zero-trust principles. MAC is known for its high security levels. Organizations rely on it to protect sensitive data, limit the risk of cyberattacks, and meet regulatory requirements.
The core of the security model should be relied on using a MAC system, please refer to SELinux as an example MAC implementation for Linux.
SELinux defines access controls for the applications, processes, and files on a system.
It uses security policies, which are a set of rules that tell SELinux what can or can’t be accessed, to enforce the access allowed by a policy.
When an application or process, known as a subject, makes a request to access an object, like a file, SELinux checks with an access vector cache (AVC), where permissions are cached for subjects and objects.
Figure 3.3 – Diagram that explain core MAC function principles using SELinux as an example
3.2.4 Configuration protection and management
Inconsistent system configurations lead to security gaps and operational instability.
Attackers may compromise systems and modify various configuration resources in order to perform malicious activities. The solution lies in maturing centralized configuration management practices.
Configuration automation delivers efficiency, reliability and compliance at scale through code-driven configuration control.
Establishing robust configuration management disciplines prevents insecure or unreliable systems, instead enabling continuous deployment of hardened and compliant stacks.
It’s proposed to use SaltStack for configuration management. It is an event-driven automation tool and framework to deploy, configure, and manage complex IT systems. Salt is used to automate common infrastructure administration tasks and ensure that all the components of your infrastructure are operating in a consistent desired state.
Figure 3.4 - Diagram that explains configuration protection and management principles using SaltStack as an example
3.3 Mitigation Controls
Following are the mitigation controls proposed.
Table 2.17 – Proposed mitigation controls
Mitigation control # | Asset # | Attack Vector # | Mitigation control description |
|---|---|---|---|
Informational assets | |||
MC.1 | IAS.1 | AV.1 |
|
MC.2 | IAS.2 | AV.1 |
|
MC.3 | IAS.3 | AV.1 |
|
MC.4 | IAS.4 | AV.1 | Implement configuration protection and management as specified in 3.2.3 |
MC.5 | IAS.5 | AV.1 |
|
Physical assets | |||
MC.6 | PAS.1 | AV.2 |
|
MC.7 | PAS.2 | AV.3 |
|
MC.8 | PAS.3 | AV.1 |
|
MC.9 | PAS.4 | AV.1 |
|
MC.10 | PAS.5 | AV.1 |
|
MC.11 | PAS.6 | AV.1 |
|
MC.12 | PAS.7 | AV.1 |
|
3.4 Risk Control Traceability
Table 2.18 – Traceability for informational assets
Threat # | Asset | Mitigation Control | Initial Risk | Residual Exploitability | Residual Risk | Acceptable? | Verification evidence |
|---|---|---|---|---|---|---|---|
Attack vector: AV.1 | |||||||
TID.1 | IAS.1 | MC.1 | Medium | Low | Low | Yes | Traffic capture shows ciphertext; GATT audited read-only |
TID.2 | IAS.1 | MC.1 | High | Low | Medium | Cond. (14971) | Negative write-test on vitals characteristics; pen-test |
TID.3 | IAS.1 | MC.1 | High | Low | Medium | Cond. (14971) | GATT service enumeration confirms no privileged/writable characteristic reachable from client profile; negative write/command test against vitals interface; pen-test attempting service escalation |
TID.4 | IAS.1 | MC.1 | Unacceptable | Medium | High | No. benefit-risk + loss-of-signal alarm | Pairing-flood test; verify rate-limit + alarm |
TID.5 | IAS.2 | MC.2 | Medium | Low | Low | Yes | Replay captured pairing traffic; confirm timestamp reject |
TID.6 | IAS.2 | MC.2 | High | Low | Medium | Cond. | Session-takeover / spoof test |
TID.7 | IAS.2 | MC.2 | High | Medium | High | No. DoS residual; alarm + benefit-risk | High-rate replay/flood test |
TID.8 | IAS.3 | MC.3 | Medium | Medium | Medium | Yes | Confirm SIEM access logging (theft is detect-only) |
TID.9 | IAS.3 | MC.3 | Medium | Low | Low | Yes | Tamper a log entry; hash-chain verify fails + SIEM flags |
TID.10 | IAS.3 | MC.3, MC.8 | Medium | Low | Low | Yes | Wipe local logs; SIEM retains + MAC denies |
TID.11 | IAS.4 | MC.4 | Low | Low | Low | Yes | Unauthorized config read; confirm MAC deny |
TID.12 | IAS.4 | MC.4 | Medium | Low | Low | Yes | Modify config; SaltStack reverts + logs |
TID.13 | IAS.4 | MC.4, MC.8 | Medium | Low | Low | Cond. | Delete config; restore + MAC + log |
TID.14 | IAS.5 | MC.5 | High | Low | Medium | Yes | Unauthorized firmware pull; confirm role enforcement |
TID.15 | IAS.5 | MC.5 | High | Very Low | Low | Yes | Flash tampered image → signature reject + secure boot |
TID.16 | IAS.5 | MC.5 | Medium | Low | Low | Yes | Tamper update module w/o role → deny + log |
Table 2.19 – Traceability for physical assets
Threat # | Asset | Attack Vector | Mitigation Control | Initial Risk | Residual Exploitability | Residual Risk | Acceptable? | Verification evidence |
|---|---|---|---|---|---|---|---|---|
TID.17 | PAS.1 | AV.2 | MC.6 | Low | Very Low | Low | Yes | Extract app storage (confirm encrypted); keystore attempt |
TID.18 | PAS.1 | AV.2 | Low | Very Low | Low | Yes | As TID.17 (control inherited from sibling) | |
TID.19 | PAS.1 | AV.2 | MC.6 | Medium | Low | Medium | Cond. (14971) | Modify stored readings on non-rooted device |
TID.20 | PAS.1 | AV.2 | MC.6, MC.8 | Medium | Low | Medium | Cond. — data-loss indication | Corrupt app data; confirm integrity + loss alarm |
TID.21 | PAS.2 | AV.3 | MC.7 | Medium | Very Low | Low | Yes | Access mgmt app w/o biometric → deny |
TID.22 | PAS.2 | AV.3 | Medium | Very Low | Low | Yes | As TID.21 (control inherited from sibling) | |
TID.23 | PAS.2 | AV.3 | MC.7, MC.5 | Medium | Very Low | Low | Yes | Push tampered firmware from mgmt → device rejects |
TID.24 | PAS.2 | AV.3 | MC.7, MC.8 | Low | Low | Low | Yes | Corrupt update file → signature validation catches |
TID.25 | PAS.3 | AV.4 | MC.8 | High | Low | Medium | Cond. | Priv-esc read under SELinux enforcing; OS pen-test |
TID.26 | PAS.3 | AV.4 | MC.1, MC.2, MC.8 | High | Low | Medium | Cond. (14971) | Binary tamper under MAC; secure boot + confinement |
TID.27 | PAS.3 | AV.4 | High | Medium | High | No — alarm + benefit-risk | Binary corruption under MAC; loss-of-signal alarm | |
TID.28 | PAS.4 | AV.1 | MC.9 | High | Low | Medium | Cond. (provisional) | Config/binary read under MAC |
TID.29 | PAS.4 | AV.1 | MC.9 | High | Medium | High | No (provisional) — alarm | Tamper/DoS test under MAC + alarm |
TID.30 | PAS.4 | AV.1 | MC.9 | High | Medium | High | No (provisional) — alarm | DoS test; watchdog + alarm |
TID.31 | PAS.5 | AV.1 | MC.10 | High | Very Low | Low | Yes | Identity-clone attempt; ROM key + CRL check |
TID.32 | PAS.5 | AV.1 | MC.10 | Medium | Low | Low | Yes | Replay key-exchange → reject |
TID.33 | PAS.5 | AV.1 | MC.10 | High | Low | Medium | Cond. | Key-removal attempt; confirm ROM protection |
TID.34 | PAS.6 | AV.1 | MC.11 | High | Medium | High | No — MC.11 detective-only; add disk quota | Fill disk → alert fires (+ quota enforcement) |
TID.35 | PAS.6 | AV.1 | MC.11 | High | Medium | High | No — MC.11 detective-only; add process limits | Fork bomb → alert fires (+ cgroups limit) |
TID.37 | PAS.7 | AV.1 | MC.12 | Medium | Low | Low | Yes | Telemetry read under MAC → deny |
TID.38 | PAS.7 | AV.1 | MC.12 | Medium | Low | Low | Yes | Tamper telemetry → hash-chain verify fails |
TID.39 | PAS.7 | AV.1 | MC.12 | Medium | Low | Low | Yes | Wipe telemetry → SIEM retains + MAC |
4 Conclusion
This document presents an example security risk assessment that demonstrates how Plexteq approaches medical hardware security - from threat analysis through to the integration of concrete security controls, using a wireless, patient-worn vital-signs monitor as a representative device. It is intended to illustrate our methodology and the reasoning behind it; a live engagement applies the same process to the specifics of the actual device, its architecture, and its intended use.
The assessment follows the process of ANSI/AAMI SW96:2023, with AAMI TIR57 and TIR97 as underlying references and STRIDE as the enumeration method. Assets were identified and evaluated for confidentiality, integrity, and availability impact; threats were enumerated against each asset and attack vector, and rated not by severity alone but by severity combined with exploitability, yielding a defensible initial risk for every threat. Mitigation controls were then mapped to each risk, and the residual risk remaining after those controls was re-evaluated against explicit acceptability criteria.
The analysis shows that the majority of identified risks reduce to an acceptable level once the proposed controls - encrypted and read-only BLE interfaces, signed firmware, tamper-evident logging, mandatory access control, and centralized configuration management are implemented. A defined subset does not close by technical means alone: the wireless and resource-exhaustion denial-of-service threats are inherently irreducible and are addressed instead through detective and fail-safe measures, chiefly loss-of-signal alarming at the clinician's tablet, together with documented benefit-risk determination. All residual risks capable of causing patient harm are carried into the ISO 14971 safety risk management file, so that security and safety are managed as linked but distinct processes.
Because the threat landscape evolves and vulnerabilities in a device's software, middleware, and operating environment emerge over time, an assessment of this kind is not a one-time exercise: Plexteq treats it as a lifecycle activity, maintained through postmarket vulnerability monitoring and periodic reassessment as required under AAMI TIR97 and Section 524B.
