Surgery-bot can be hacked to HACK YOU TO PIECES Surgical robot makers are just as good at security as the rest of the world - ie, hopeless - according to University of Washington infosec boffins. The researchers targeted a product of their own university's research, a telesurgery unit called the Raven II, and among other things found an exploitable safety mechanism in the …
This post has been deleted by its author
I used to work a lot with satellite communications and for some things it is great. However, commanding a remote control robot to stop and start is not one that I would favour given the delays inherent in such links. Add the normal digital transmission link delays and it would require very careful calibration of both machine and surgeon to limit accidents. Satellite links can be prone to drop outs and periodic loss due to rain, cloud, sun spots, etc. Not too important with routine telemetry and trend analysis but dangerous when cutting microscopic fibres!
Encrypted tunnels and hardened security are mandatory. It is stupid to sell a multi thousand pound/dollar/whatever machine and do a <sixpenny security job to protect its functions.
This post has been deleted by its author
This post has been deleted by its author
So I stand by my original claims, and note that the downvoters are clearly ignorant of satcoms technology too. Well done.
The more you scream "I'm right!, I'm right!, Everyone else is a retard!", the more you obsess about being given thumbs down, and the less you are able to substantially counter points made that directly contradict assertions you have made, the more your reputation plummets. You been here a little over a month and have already been compared to Eadon and you have already been shown to be talking complete nonsense on a few occasions.
Your claims are not really worth very much to begin with. I could tear apart your assertions w.r.t. satellite but have no appetite for a massive time sink with someone solely interested in stroking their own ego.
I think that I prefer that the developers do One Thing: Build a Surgeon to be as good, user friendly and safe as they can. Then Security (and QoS) is added by another set of developers - doing just that One Thing.
Building "everything" into one system is exactly what went wrong with SNMPv3 and Java - Security may be baked in, but, it is so complicated to use that it is useless (SNMPv3) or it is so complicated that it is just one huge attack surface (Java).
NETCONF, HTTP, et. al. rely on"external" security: VPN, SSH et cetera. This is a *far* better approach IMO - when for example SSH is hacked, it can be Replaced. And everyone understands the common protocols - "baked in" means "customised", which will mean funny exceptions and special cases for all equipment.
Really, do people not understand that the internet is not an interference-free, guaranteed availability network?
No, they don't. To "Joe Public", and the politicians in charge, the Internet is a utility just like mains water, power and gas. They assume it's rigidly held to exacting standards, highly available, centrally-controlled, and has a safe off switch. Tell them what it's really like and the result is total disbelief, along the lines of "don't be silly, no-one would ever have made it like that".
Really, do people not understand that the internet is not an interference-free, guaranteed availability network?
Do you really think they never stopped to consider issues like that? That an entire team of engineers spent years and millions developing a product in one of the most highly regulated sectors imaginable and no-one stopped to evaluate the connectivity requirements? Of course not. What they understand but apparently you don't is that high quality connectivity is available if you need it. It is utter naivete to assume that because something is TCP/IP for interoperability it is going to be operated over any old crap like the £10/month DSL connection you have at home.
Instead look at e.g. the MPLS cloud providers. If both sites are already connected to the cloud you can ring up and say "We need a 10 Mbit path between these two nodes". They reconfigure the switches and call you back a couple of hours later - "You have 10 Mbit, latency no more than 5ms". Those are not aspirational theoretical maximums, subject to traffic levels and with a trailing wind but guaranteed minimums - the link will not so much as fart.
So yes, I can see legitimate use for devices such as this, operated by competent individuals and backed up by competent IT professionals who understand how to specify what they need. If the circumstances demanded it I'd be happy to be operated on by such a device and so would you be. Clearly most of the time you would rather the surgeon was there in person but that isn't always possible. Consider the stories of professional divers who receive the most horrendous injuries but can't be taken to hospital until they have spent a month in depressurization. Would you rather be left there for that month with only basic nursing care, or would you rather they use something like this on day one?
Before the down votes start: I better clarify what I meant.
https://www.youtube.com/watch?v=5XDTQLa3NjE
If people look at that, they'll realise that these are medicos that understand about as much about programming and computer security, as the average stereotypical acne-ridden teenager understands about brain surgery.
Yes, a 510K is required for a device like this (Class-III) prior to sale and use.
No, the FMEA would not necessarily outline risks due to network intrusion (but it'd be insane not to). It's up to the engineers to identify the risks, and if they don't have a security background ... well, no risks will be identified much less development of a mitigation strategy (like requiring VPN).
There is no required security auditing of medical software by anyone at any time. IME, properly managing a firewall is a bit beyond the typical knowledge level and skill of the people writing the code running these devices.
Just build robots that ONLY play golf, invest in more operating theaters/staff/equipment, and yer consultants can concentrate on applying their considerable skills to surgery and catch up with Robo-Golf progress on their E-Scorecards via smartphones when they take a tee break.
The situations envisaged for these robotic surgeons are doing Exceeding Complicated Specialist Surgery in relatively remote locations - so rather than travelling to London village, you get your ECSS* in your local hospital. It will also help in emergency situations (a long way in the future) as it will be permanently available and you can have a roster of surgeons in your distant location (or even spread across the country).
So no, nobody's thought about security and although they will be tested on closed networks, they will be on open ones before anyone gets round to sorting it out. Unless the authors of this paper get a bit more traction... more power to them.
* I think I can sell this acronym to surgeons. It sounds flashy enough.
It will also help in emergency situations (a long way in the future) as it will be permanently available and you can have a roster of surgeons in your distant location (or even spread across the country).
Very possible though it would depend on the emergency. If power's out, infrastructure is destroyed or and earthquake has flattened the hospital on the robot.. then no.
Your point is good and I particularly like the image of a hospital lying on top of a robot. I was thinking of one patient's emergency, not a mass disaster. And I work in a hospital that's the safest earthquake building in town, so everywhere else may be destroyed but the hospital (should) just keep going...
This post has been deleted by its author
"Frankly, it's quite sad that the developers of such a sophisticated machine could be so ignorant of basic security issues."
I don't think they are ignorant of these issues. If you RTFA, the attacks amount to a) If you send it unsafe movements, it stops, so you can DOS it by continually sending it unsafe movements. b) If you hijack the connection, you can drop packets (making movement jerky) or send it your own instructions.
I don't know if there's any way around the denial of service.. even if everything's nice and locked down, one could simply flood the internet connection and prevent commands from getting through. The second problem could be solved with authentication. However, I would see a device like this being on it's own, isolated network (the hospitals I'm aware of have any networked medical devices strictly on their own network), with an ssh tunnel or VPN to the remote end. No matter how secure the equipment is (or is supposed to be), any hospital I'm aware of would absolutely flip if they found out any of their equipment was accessible from the public internet.
As for using KU links for telemedicine... yes, but there's a big difference between having a video chat and teleoperating a robot. Video chat? A time delay is no big problem (it causes people to interrupt each other a bit if they both want to talk, but that's about it) and if there's some fade you just resume your Q&A later. Teleoperated robot? A second or two delay is very hard to get used to, if you even can, and having the link fade out mid-cut could be a big problem.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
