Thank you for posting the call for volunteers, and the link to the MITRE attack flow project. I hadn't heard about this before, so I'm learning a lot. Needless to say I'm not going to be expert enough in the system to create the kinds of flows I'm thinking about very quickly, so I thought I'd share my ideas in human language here, so perhaps someone with more expertise can run with them.
A lot of these are weird edge conditions, but as some self-driving vehicle manufacturers have found out, instead of logging 20TB of boring humdrum driving data, they log 20GB of edge events, because what's where interesting things happen.
1. Need to make sure that the control system and process are not susceptible to replay attacks, whether just for identity, or for actual control and sensing
2. Make sure the data output from the sensors as well as control inputs are encrypted at rest and in motion, making sure the handshake/initialization process doesn't leak and/or allow man-in-the-middle, target-spoof, protocol spoof, etc. Need to be sure that source(s) and target(s) are positively identifiable. If the identification or data exchange process for any part of the system (even logging, ID verification, usage billing, maintenance data, etc.) use 3rd party address resolution, then that address resolution must be part of the system testing. If the endpoints are sufficiently verified, then that eliminates the usefulness of any "in-the-middle-redirection" attacks - but that means positive identity of all endpoints within the system scope must be validated from "power on" to "power off" - that means continuous validation protocols are required
2a. Make sure the encryption standard used is quantum safe avoiding "download now decrypt later"
3. Sensor and control inputs are time-sensitive. Need to be sure that any attack of a "DOS/DDOS" type, that puts junk on a network somewhere between the patient and the controller, or patient and viewing endpoint(s), doesn't cause sufficient retries/fails/slowdowns that control inputs or feedback are no longer timely (examples: a "slice" motion is too long, or an "X-ray off" command doesn't arrive on time, or at all, or a manual control/command is repeated because the visual confirmation doesn't arrive until it's too late).
3a. Also possible, if component health is continuously monitored, and a component doesn't respond within the timeout due to network attack, the system could mistakenly report "failure" and stop or reset in the middle of a medical procedure, potentially causing patient harm
4. Identity of each component and subcomponent within the system is critical. Attackers may replace components with "hacked" firmware, or suppliers may have firmware/software that is compromised in the supply chain, and activates when a component is replaced in the surgical system (whether through failure, normal maintenance, or even "hacking" the system to simulate failure, causing maintenance to illegitimately replace components with compromised ones).
4a. Removed components should not be able to have local data (cache/history) dumped outside the system, except by authorized persons/companies. That may imply at-rest encryption for firmware, software and data within the component module, and unit tests for these
4b. Components added to the system should not be able to be "pre-programmed" due to the possibility of supply chain compromise, but should be in a "Blank" state - and/or the system controllers should recognize new components and require a reinitialization prior to accepting the component in an operational mode
5. Need to consider how to guarantee that authorized system upgrade methodologies cannot be attacked. Since I don't know the authorized modalities of maintenance and upgrade for the system, I can't get into further detail on this one at this point
6. How would the system react in the case of deliberate hardware damage/sabotage
6a. How is in-operation failure reported, and can these reports be intercepted, falsified, blocked, and/or false-positived?
7. Are all system self tests properly protected against all types of attacks? (false-pass, false-fail, numeric value shift, data-target-intercept and redirect, logging)
That's all I can think of for now, if you have any follow up questions, or you'd like me to assist further at a later date, please reply privately and I'll send my contact info.
Sent: May 26, 2022 03:06:35 PM
From: Brian Russell
Subject: Help develop attack flows for robotic telesurgery
Call for volunteers to help create attack flows based on the MITRE attack flow notation: Attack Flow...
Our IoTWG is collaborating with MITRE to develop a set of attack flows that represent potential risk to patient safety in the health care industry. We are modeling these flows based on a cloud-enabled telesurgery use case. You can find more information on the work in our CSA Github site: GitHub - cloudsecurityalliance/IoT-Medical-Cloud: IoT-Medical-Cloud
Navigate to Telesurgery --> Attack Flows for details and an initial flow (example flow).
I've extracted a list of initial attack flows that we need to model. Initially, we can create these visually in any tool, but eventually we'll need to port to a machine-readable format. The goal is to create a library of these attack flows within github to allow HDOs to use. We are also considering working with tool vendors to see if we can leverage these for simulations.
Please let me know if you want to take any of the attack flows in the list, or simply create a flow and commit to our github repo.
We want to protect the patient from harm, so we must guard against misconfigurations in the robotic device.
- Attack Flow: Attacker uploads malicious firmware to robotic device due to failure to authenticate firmware upload.
- Attack Flow: Attacker modifies robotic device firmware through compromise of the vendor software update process (note: potential multi-patient effect).
- Attack Flow: Attacker modifies robotic device configuration file through compromise of a management system.
- Attack Flow: Attacker modifies device configuration settings through physical access to the device.
- Attack Flow: Attacker infects robotic device with virus/malicious code through cloned hard-drive, other means.
**We want to protect the patient from harm, so we must ensure the availability of the supporting cloud services. **(e.g. can't perform radiation verification because csp was attacked).
- Attack Flow: Attacker performs a denial of service through a network flood.
- Attack Flow: Attacker encrypts critical file through ransomware.
- Attack Flow: Attacker performs attack on cloud service provider (CSP) that renders services unavailable.
- Attack Flow: Attacker performs attack on cloud provider resulting in a lack of AI capability (results in further delay to care).
We want to protect the patient from harm, so we must ensure that a remote clinician has an accurate view of patient status.
- Attack Flow: Attacker modifies bio-sensor readings through tampering with biosensor data.
- Attack Flow: Attacker modifies notification messages meant for the clinician through tampering with data.
We want to protect the patient from harm, so we must ensure that remote commands to the robotic device cannot be modified.
- Attack Flow: Attacker modifies commands sent to the device through tampering with the data.
We want to protect the patient from harm, so we must ensure the availability of supporting communication infrastructure
- Attack Flow: Attacker disables wireless connectivity within the operating environment.
We want to ensure that if something goes wrong in the system, that the root cause can be traced and identified
- Attack Flow: Attacker modifies log files within a device
- Attack Flow: Attacker modifies log files within a CSP
We want to ensure that patient privacy is protected
- Attack Flow: Attacker gains unauthorized access to PHI data