from the don't-add-them-to-begin-with dept.
Why fixing security vulnerabilities in medical devices, IoT is so hard:
When your family opened up that brand-new computer when you were a kid, you didn't think of all of the third-party work that made typing in that first BASIC program possible. There once was a time when we didn't have to worry about which companies produced all the bits of licensed software or hardware that underpinned our computing experience. But recent malware attacks and other security events have shown just how much we need to care about the supply chain behind the technology we use every day.
The URGENT/11 vulnerability, the subject of a Cybersecurity and Infrastructure Security Agency advisory issued last July, is one of those events. It forces us to care because it affects multiple medical devices. And it serves as a demonstration of how the software component supply chain and availability of support can affect the ability of organizations to update devices to fix security bugs—especially in the embedded computing space.
URGENT/11 is a vulnerability in the Interpeak Networks TCP/IP stack (IPNet), which was licensed out to multiple vendors of embedded operating systems. IPNet also became the main networking stack in Wind River VxWorks, until Wind River acquired Interpeak in 2006 and stopped supporting IPNet. (Wind River itself was acquired by Intel in 2009 and spun off in 2018.) But the end of support didn't stop several other manufacturers from continuing to use IPNet. When critical bugs were discovered in IPNet, it set off a scare among the numerous medical device manufacturers that run it as part of their product build.
The average medical or Internet of Things (IoT) device relies on multiple free software or open source utilities. These pieces of software are maintained by any number of third parties—often by just one or two people. In the case of Network Time Protocol (ntp)—software that is in billions of devices—its code is maintained by a single person. And when the OpenSSL Heartbleed vulnerability came out in 2014, the OpenSSL project had two developers working on it. While there are many more developers working on it now, the Heartbleed crisis is emblematic of what happens when we use free software in our devices—the software gets adapted, not really patched, and not really maintained on the device, and little benefit goes back to the project.
The S in IoT stands for Security
(Score: 1, Touché) by Anonymous Coward on Tuesday February 25 2020, @10:12AM (2 children)
https://soylentnews.org/article.pl?sid=20/02/19/2140209 [soylentnews.org]
(Score: 2) by JoeMerchant on Tuesday February 25 2020, @04:54PM
Let's do the time warp, again!
I generally read back until I recognize a story, but this one is messing with the sequence.
🌻🌻 [google.com]
(Score: 2) by janrinok on Wednesday February 26 2020, @09:05AM
(Score: 4, Insightful) by Anonymous Coward on Tuesday February 25 2020, @10:23AM (12 children)
If you you remove the word free, you would also be correct. The entire fucking summary is about IPNet, which is NOT free.
https://www.windriver.com/security/announcements/tcp-ip-network-stack-ipnet-urgent11/ [windriver.com]
https://en.wikipedia.org/wiki/Computer_virus#First_examples [wikipedia.org]
https://en.wikipedia.org/wiki/Category:Hacking_in_the_1980s [wikipedia.org]
Also, don't confuse IoT with medical devices. Different scope. Confusing a $50 IP camera with $6000 implants is one thing. Another is purpose - why is a pacemaker on the internet?? And what does it have to do with NTP or OpenSSL? I do not want my pacemaker running OpenSSL! ;)
(Score: 4, Insightful) by All Your Lawn Are Belong To Us on Tuesday February 25 2020, @11:24AM (11 children)
I don't blame you for not wanting your medical device to be internet-facing. The answer, paraphrasing Heinlein, is the same answer to most questions beginning with "Why?": Money. For a device that requires either periodic log monitoring or needs to be reprogrammed, using the Internet is going to be nearly inevitable simply on cost/benefit grounds. The alternative is that you pack up your device and walk it to your physician's office or DME company and let them connect up to it, or make the device cost a few hundred or thousand more to maintain some other nebulous system of connectivity. (Even then, the data from those devices are taking and aggregated with other data. Do you really expect them to use an airgapped device to do that? If so, that's quaint.)
Even if you have the time to walk the device (or yourself) to them, your physician does not. He or she needs to look for ways to save time as well because insurance reimbursements never truly go up - the insurers are always finding ways to force the medical community to do more with less.
It's the real driver behind all telehealth: The people paying the bills want it as cheap as possible, which means using the most expedient options that achieve the purpose. Now if your device never requires monitoring or adjustment, or whatever device it is will never have a firmware adjustment, then connectivity makes no sense. But any such device is probably of limited utility anyway.
This sig for rent.
(Score: 1, Insightful) by Anonymous Coward on Tuesday February 25 2020, @03:12PM (1 child)
> Even if you have the time to walk the device (or yourself) to them, your physician does not.
Right -- this looks like the source of the problem. Not enough doctors, possibly due to the AMA (in USA) controlling the number of new MD's minted every year. Scarcity of doctors --> doctors raise their prices.
If my doc is going to adjust a setting on a device that is inside me, I want to be looking right at them when they do it. I do recognize that the doc may not be looking right at me...but I should be able to drag their attention away from their screen if I squawk in person!
(Score: 0) by Anonymous Coward on Tuesday February 25 2020, @04:23PM
I'd love to know how you think the AMA does that. (Hint: they don't.... Second hint: state licensing boards issue medical licenses Third hint: the number of residency slots is what limits new physician production, and that isn't controlled by the AMA Fourth hint: I'm not saying the AMA doesn't like to try and influence the number, just that it's not as simple as you're putting out.) But as I said, it has absolutely nothing to do with that: In the US it is Medicare and the Insurance Industry that is the tail which wags the dog of US healthcare, and has for over 20 years now. You think a greater supply would lower physician reimbursements and therefore more physicians would be available to see you face to face. The reality is that lower physician reimbursements will cause all physicians to figure out how to do more with less even harder, and you'd probably never physically see the Doctor at all. It would accelerate that which you're trying to stop. This is where telemedicine is taking us. But anyway...
And it's more than devices inside of you. Awhile back I felt like my CPAP machine needed to be able to deliver more pressure to me. A call to my Doc, who got the data from the DME provider, and an automated pressure level reset later and I'm sleeping better. Didn't have to unplug my machine from the wall. Didn't even get charged a consult visit, which I appreciated.
But let's play along and say the Doc is right there next to you. (I agree this is preferable - there's few things worse than telemedicine for intrinsically sucking the humanity out of medical care). Still... how's the Doc going to connect to your device? Are you going to want them to wire a USB port to your body? Or an DB-9 to use RS-232? There are devices that do have leads coming outside the body like LVADs do for their power supply. But any orifice (natural or surgeon-made) is an infection risk. And how much more are you willing to pay for your device such that it uses something other than off-the-shelf protocols?
(Score: 2) by RS3 on Tuesday February 25 2020, @04:12PM (4 children)
Money is certainly the huge factor, but time is also. For some reason most people don't seem to consider time and timelines when discussing things.
A friend's mom recently had a pacemaker installed. In the old days pacemakers just produced pulses, but now they monitor things too. The point being- if she has a problem that she might not be aware of, the pacemaker system might signal an alert to someone somewhere. It comes with a base station that "talks" directly to cell network. I'm not sure how it communicates with the pacemaker, but for sure the pacemaker itself is not "online".
And I seriously doubt the base station is "online", rather, probably initiates communication with some kind of address somewhere.
An option would be to use an external wearable monitor, such as a "Holter", but they're uncomfortable and skin contact pads need to be replaced every so often. And then it has to be taken to a medical center to read out the data.
Maybe an option could be a semi-sneakernet system where the pacemaker's monitor station would not be online. The patient (or someone) would insert a USB drive and the system would copy some data that then could be uploaded or emailed to a medical center. If changes were needed to the pacemaker's parameters, the monitoring station could be taken to a medical center and programmed manually, or maybe a parameter file could be emailed and checked against a cert, the base station would only accept it if it passes integrity checks, etc. Point being- base station would not be online, exposed to repeated attacks.
BTW, it seems obvious that none of the gruntwork would be done by physicians; no more than the other things that are typically done by nurses and med techs.
(Score: 0) by Anonymous Coward on Tuesday February 25 2020, @04:50PM (3 children)
Of the different ways pacemakers can be classified one is demand versus automatic. Demand pacemakers are always sensing the heart rhythm and when it detects a lack of impulse (either atrial or ventricular) it then delivers the impulse - it senses when you're missing a beat and delivers it. This is different from the 'old school' of automatic where a shock is delivered in time according to its' own frequency whether your heart was going to supply the impulse or not. And a little different from that is an ICD, which senses when your heart is going dysrhythmic and delivers a defibrillating pulse to try and reset the beat. The first and last types can very much benefit from being able to deliver telemetry. It can be very helpful to the client that a central monitoring station reads that a device has monitored 15 premature ventricular contractions in the last 5 minutes.
Yes, there are Holter monitors. They are beginning to be considered old-school, in part because they are limited to recording the length of their onboard memory. There are also telemetry monitors, which likewise are talking to a base station that is relaying your data to a central monitoring point. Telemeters are also used extensively in hospitals... While it may still be called a "Holter" by staff, almost all in-hospital cardiac monitoring is done by telemetry where a staff member may be monitoring 12-30 patients simultaneously.
But the last main thing... yes, many systems do indeed use the cellular network. More to the point, then use cellular data services. Which are connected to.............. oh... Hopefully they're VPNing in - they certainly should be. But TCP/IP is the delivery method of choice.
(Score: 2) by RS3 on Tuesday February 25 2020, @05:34PM (2 children)
I don't know if you're a doctor, but you're certainly knowledgable. I do know all that, but not everyone does, so thanks for writing it up.
Not sure if they're VPNing into the pacemaker monitor. I forget the brand, but I'll write it down when I visit her next. I'm hoping the base station sits quietly offline, and turns on cell data when it wants to upload, check in, etc., rather than always be on and exposed.
BTW, the in hospital monitor systems use software to detect cardiac rhythm anomolies, so the whole system is not limited by 1 human watching so many patients.
My friend's mom has "heart block", so I'm guessing the pacemaker is always pulsing. But that said, I wonder how these new pacemakers know when to speed up or slow down... Maybe you know?
(Score: 1, Informative) by Anonymous Coward on Wednesday February 26 2020, @04:27PM (1 child)
Good point - they initiate contact and that is indeed the way it needs to be. I wonder what would happen if a full DDOS attack were launched at the IP where the data is coming from (I doubt that the devices carry static IP's, but I don't know which would be worse - having a static range to be assaulted, or a dynamic range which rotates such that the receiving end can't lock out incorrect IP ranges). I also wonder how/if the system manufacturer hardens against such a possibility. Hopefully the cell towers themselves would serve as a stronger firewall buffer as well.
Anyway, not a doctor but I have more than layperson's knowledge. And using the cloak of AC so that nobody treats any of this as medical advice. (I'm not being paid for it anyway, but still don't want it directly attributed to me). I know there are devices (not implanted) which can be remotely accessed, though, without the end user needing to initiate it. That should change (something like a WiFi configuration button to let the device know it is OK to accept an unsolicited inbound connection in addition to all the other security). And pacemaker bases can initiate the connection on their own when they have significant data to report. Most implanted defibrillators require the end user to initiate the data upload.
The monitoring software does indeed detect rhythm anomalies and reports them. For externally worn monitors (pads on skin) they are accurate maybe 50% of the time at best, and for the 50% of the time they are accurate maybe 10% are of actual clinical significance. (Premature ventricular contraction, for example, when the second part of the beat sequence decides to fire early. 2 in a row are not uncommon in some kind of periodic rolling sequence, and so long as it is "stably unstable" it's not to worry about. 3 or 4 in a row are of some concern. More than that and you wonder what's going wrong. Internally fixed ones (like pacemakers) are much more accurate and do not suffer nearly as much from anomalies like breathing motion or other movement fuzzing up the picture. But the point is that it still takes a human monitoring and the point of the monitor room is that there is a human who makes the judgment whether or not to call the nurse about a given issue.
Heart block.... you can Google a lot on it but I can speak a little bit about it.
Forgive me if you already know this (we're a smarter than average bunch, so maybe many of us already know the first bits of cardiac circulation). But the electrical contraction wave starts at the top right of the heart ("right" from the patient's right side... the sinoatrial node), passes to nearly the center of the mass (septum between the atria and the ventricles, atrioventricular or AV node), then into the bundle and down two separate paths (Bundle of His and Left and Right bundles) to the bottom center of the apex where it wraps back around upwards and outside on the ventricles (purkinje fibers). It's better to see it, and here's a great animation even if the narration could be more interesting: https://www.youtube.com/watch?v=RYZ4daFwMa8 [youtube.com]
So a heart block occurs below the AV node. The conduction pathway gets lost somewhere after the AV node. So the top part (atrial contraction) fires regularly and on time. But the part below (ventricles) don't fall in the correct rhythm. A fun thing about the heart is that it has conductivity (the depolarizing and repolarizing should occur in smooth waves giving you a regular ECG picture) but it also has automaticity - those lower parts of the heart will try and fire on their own if they don't receive a signal from above....... but it does so more slowly. This can cause a rhythm problem where the part of the heart (and it can be both top/bottom and side-side) starts firing out of rhythm to the system, which if you think about it as a two-phase pump can be a problem.
Anyhoo, now to what you were asking.... What your friend most likely has is a ventricular demand pacemaker. It is sensing the the atrial depolarization wave (first bump) and then monitoring for the ventricular wave (the big spike). It counts from when it determines the peak of the atrial wave has occured and if it does not sense a timely ventricular spike (about 160 milliseconds from top of P wave to initiation of Q wave) it will fire. The heart is pacing itself but the pacemaker is sending the second wave that isn't getting to the ventricle), hence it is supplied "on demand."
This isn't your friend's condition, but if the opposite is happening and the atrial wave isn't happening on time the pulse rate will be somewhere between 20 and 59(ish) beats per minute. The midline or the ventricles will send out their waves even without input, but slower, see? (Strong atheletes can get a pulse in the 50s naturally which is fine). So instead the pacemaker looks at the QRS complex (the spike) and then counts a specified interval, and if no wave happens it will stimulate the atria. The stimulation may be a few milliseconds late, but that's OK. As long as the heart had time to repolarize, the next beat will then progress naturally. The pacemaker sends the first wave (that isn't going to the atria), hence it is Atrial Demand.'
If neither the atria nor the ventricles are supplying waves with good timing then usually an automatic pacemaker is called for. This can either be just an atrial spike, or if the patient also has a block in addition to the loss of the sinoatrial conduction, it can supply both atrial and ventricular pulses (which is interesting to see on an EKG, two very rapid double spikes about 40 milliseconds apart and then one sees the rest of the wave).
Anyway, sorry for going on about it. The cardiac system is really awesome and fun to study even if you have no interest in medicine. :)
(Score: 2) by RS3 on Thursday February 27 2020, @04:07PM
> "Anyway, sorry for going on about it."
Sorry? Are you kidding? This is awesome; I can not thank you enough!
Being somewhat medically savvy, and just trying to pay attention and help where I can, over recent months I occasionally checked friend's mom's pulse at wrist. It was always quite irregular. I also have a finger clip "pulse ox" that has an LED that blinks for each detected heartbeat. It was quite erratic too.
Not knowing what that meant, I didn't think to do anything. She did have regular doctor checkups. I assume he was checking her heart. She just had a checkup in December. Maybe "heart block" happened since then?
I'll have to do some research on what can cause "heart block".
Another area of curiosity- "cardioversion". I know some people who've had that done. I pretty much know what it is and what the procedure is. My question is: if there's a problem with rhythm, how can one "zap" fix the problem? I'll do some research...
Thank you again so much.
(Score: 2) by Immerman on Tuesday February 25 2020, @04:29PM (2 children)
>For a device that requires either periodic log monitoring or needs to be reprogrammed, using the Internet is going to be nearly inevitable simply on cost/benefit grounds.
Fine, but again, why is the device connected to the internet?
Use a second, external device as an intermediary that connects to the internet, and communicates with the medical device via a simple, easily auditable wired or short-range single channel serial communication protocol with the absolute minimum of functionality necessary. Any software or setting updates must be cryptographically signed, with the signature checked immediately after the data has been transferred to the device, before the data is even looked at.
You're talking medical devices with multi-thousand dollar price tags. Even a full-fledged Raspberry Pi based intermediary is barely going to nudge the price tag.
(Score: 1, Informative) by Anonymous Coward on Tuesday February 25 2020, @05:01PM (1 child)
Why? Because using the internet as the transport via VPN is much more economical than requiring modems and land lines. It means not having to re-invent the wheel to figure out how the data gets from A to B. It might be nice to develop a separate network but not necessary to.
OK. So the device is separated from the reporting mechanism. Most intra-body devices have to be anyway. But having any intermediary then adds the risk of all the potential compromises that the intermediary may encounter as well. While "only" having your device data compromised is a lot less destructive than allowing an attack on the actual therapeutic modality, it's still an unacceptable risk as well.
And yes, "minimum functionality necessary," sure. But what are the minimum functions? Do they include changing parameters on the device? If not, fine, but very few medical devices are created without the need to change settings. And not requiring the person to take the device somewhere is part of the risk-benefit analysis in terms of healthcare cost as well. (Not to mention the times when it may be determined that a device firmware does contain a flaw. Being able to reflash a device without having to cut it out of the person is certainly more preferable from an infection control standpoint).
(Score: 3, Interesting) by Immerman on Tuesday February 25 2020, @08:33PM
I won't address the first part, since my previous post already accepted that the internet will be involved at some level.
> But what are the minimum functions?
Primarily, receive a file and verify that the digital signature is valid.
Once you've done that, then you can do whatever you want with the contents of that file - Is it a settings file? Apply the settings. An update? Apply the update. (Though really, updating the software on a medical device should be done in a medical setting where correct functioning can be confirmed, and the patient can get emergency care in case of any malfunctions)
So long as the patient don't have to adjust the settings themselves (as is generally the case for medical devices), you've just made sure that the *only* way to compromise the device, is to compromise the digital signature. It's not perfect, but nothing is, and it dramatically reduces the attack surface. A simple serial interface is several orders of magnitude easier to audit to ensure there are no exploitable I/O flaws than an internal TCP/IP stack, hardware drivers, etc.
(Score: 0) by Anonymous Coward on Tuesday February 25 2020, @07:10PM
That's the stupidest fucking thing ever. The doctors shouldn't be the ones that are applying patches, that's a stupid waste of their time and energy. It should be either somebody else in the office or somebody that works for the manufacturer of the device. Depending upon what the device does, there can be potentially life threatening consequences if somebody gets in there and changes the programming so as to affect the operation of the device.
Also, there's no inherent reason why the software update couldn't come to the patient via the sneakernet. Device updates for these things should be few, far between and not needed to avoid life threatening complications.
(Score: 2, Insightful) by Anonymous Coward on Tuesday February 25 2020, @01:17PM (2 children)
It's going to be a heck of a lot more fun if the embedded cert in the device expires after a year...
(Score: 2) by hendrikboom on Tuesday February 25 2020, @01:25PM (1 child)
Or if certificate security is broken by new code-breaking technology.
(Score: 2) by DannyB on Tuesday February 25 2020, @06:34PM
Of if the algorithm always has already been compromised by no such agency and the compromise gets leaked.
The lower I set my standards the more accomplishments I have.
(Score: 2) by hendrikboom on Tuesday February 25 2020, @01:23PM (2 children)
And allocating more developers is possible precisely because it's free software. Anyone with the necessary competence can do maintenance.
And for proprietary software that's supported by a still-extant manufacturer, maintenance is also possible, at least in principle.
But for devices with proprietary software whose manufacturer is gone, there's little hope.
Same for devices with the software in soldered-in ROM, whether the software was originally free or not. Even source code doesn't help much if you can't get an update into your box.
(Score: 2) by Rich on Tuesday February 25 2020, @01:50PM
Free or non-free does not matter here, and no one cares.
No one cares: About 15 years ago, I updated an old Microware OS/9 68K system to an embedded PowerPC with Linux. No one in about three echelons above me as contractor had any detail knowledge about the licensing issues. So I ensured all is well, told them so, packed all upstream sources, all our patches, and all that was statically linked to LGPL (a good bit, because dynamic linking C++ was broken at the time) onto a CD, told them to archive it well, and hand it out everyone asking for the source. Just before shipping, someone from a remote corner of the big company got involved, noted all was well and added a printed copy of the GPL with an offer for the source to the packing list. 10 Years later, they must have had an audit and called me about how I dealt with the licence. I re-told them the history, they found the CD, and the auditors seemed to be happy. To my knowledge, no customer ever asked for the sources.
It does not matter: If anyone had the full sources, they could not release a fix they made, because they need to go through regulations. To pass that, they would basically need the whole company fabric to show they adhered to the processes that the software works. There is of course the "COTS" (*) magic spell, which could be creatively applied, but the effort needed to deploy a local fix is impossibly high. It might work with a foundation of device owners pooling together for such things, but I haven't heard of this happening.
"COTS" means "Commercial Off The Shelf", which allows manufacturers who have gone though painstaking tests of their own software to (more or less) let it run on whatever version of Windows MS feels it might ship on any random day.
(Score: 3, Interesting) by JoeMerchant on Tuesday February 25 2020, @05:03PM
Surprisingly, around here, in industry, there are 10 programmers on the market with some level of (self proclaimed) competence in various closed source toolsets for every one that will even apply to a position that involves the typical open source tech. Now, being one of those open source guys, I'm a bit biased and believe that every one of us is worth at least 4 of the other guys, but even still, that makes it hard to hire up for an open source based development project.
Around 10 years ago, I took over for a guy that was stuck on a proprietary solution, went and found an open source alternative and within 3 days had surpassed his level of progress in the "supported" libraries for the past month - 3 days was the average turn around time for support response from the "support team," so.. I proceeded to develop the open source alternative while waiting for answers on the other side. Within 2 weeks, I had received about 3 unhelpful answers from paid support, and gotten to a "working solution" with the open source tools - so I presented my results. The guy who had thrown in the towel trying to do it himself with the supported library was extremely pissed off that I had abandoned "his people" in favor of this "unsupported" alternative, and it was basically impossible to convince him that the open source library was a preferable choice - where I could look up answers in Google within hours instead of waiting days per exchange with the closed source team.
🌻🌻 [google.com]
(Score: 2) by Rich on Tuesday February 25 2020, @02:11PM (9 children)
TFA's a repost, but since we're here again now, I can offer to answer questions. I've spent half of my whole, and almost all of my professional life, on medical devices. Mostly in the diagnostics sector, with everything from simple handheld stuff over robotics, embedded controllers and their software, embedded computers and their software, front end computers and their UI software to networking with customer IT for automated workflow.
So if there's anything you always wanted to know about the sector, ask away.
(Score: 3, Interesting) by takyon on Tuesday February 25 2020, @02:41PM (1 child)
Where are some good sources for purchasing discounted medical and lab equipment?
Are ~$100 3D-printed prosthetics or robot parts going to replace the $10,000 ones? Maybe by sneaking around FDA regulations, selling on Etsy, etc.?
What is the best/cheapest path to acquiring a robotic exoskeleton for someone who doesn't have a medical or employment need for it? One answer would be to go it alone [hackaday.com].
Is anyone talking about the "chemputer" [twitter.com]? That concept has been around since at least 2012 [theguardian.com] but seems to be getting close to reality.
What do you think of the "tricorder" [wikipedia.org] idea? Ideally, a device could scan and diagnose somebody using information from as many minimally invasive sensors as possible. This might be useful for preventative medicine since people would be willing to scan themselves daily but not go to a doctor very often.
[SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
(Score: 4, Informative) by Rich on Tuesday February 25 2020, @06:45PM
Well, I see a lot of the stuff before it even goes into proper production and hardly get to deal with used stuff in the field. Every now and then I have looked around the net what actually happens there, and search results popped up with stuff for sale. I just did a search, found a site "dotmed.com" and indeed, there's one of the devices I just work on on offer. Not sure if this is a reliable channel, though. For all lesser stuff, I'd probably try ebay. Face masks might be in short supply these days, though.
I think prices for individual things have to be seen in context. I was recently suprised how relatively cheap dental drills can be. By the time an orthopedic part for a patient has to be paid, a lot of people, doctors, orthopedics, the supply chain, already were paid, and easily so in the order of the ten grand. I don't think the grand scheme of things will change here without the whole system changing. I wrote in the pre-duplicate article that verification overhead over development is somewhere around factor 20, you get an idea where the prices come from. You'll get a milled-to-spec titanium strut for way less than the $10k from any English countryside cottage motorsport shop. So, cheap prosthetics will be DIY for the time to come. If you want it powered, it is indeed your best choice to DIY, with a bit of help from the maker scene. Some Japanese hardcore mecha cosplay otaku probably has more advanced stuff today than western industry.
Reagents and their chemistry are really far away from device developers in the industry. As a device developer you have a basic knowledge that something chemical/biological reacts in some way and the hardware can pick that up (e.g. darkens, tinges, or scatters a light beam, changes electrical resistance, or even mechanical resistance when stirred). You work from there. I know more about biochemistry from my high school days than I picked up in my professional life.
What gets talked about is specialized microchemistry, so the whole functionality of that badass quarter-ton, hundred grand, 240 samples per hour cellar lab analyzer gets reduced into a little throwaway chip with print-head technology. A simple handheld device can then do an assay profile anywhere in the world, with instant results, from just a drop of blood instead of a full tube. Given that the cost is more in the process than the materials anyway, and the advantages of speed and ease-of-use, I see this becoming important.
Initially I was thinking about such microtechnology for synthesis. I think that's a pie-in-the-sky thing, and even if it worked, would not yield the amounts of product usually required (unless you're doing stuff that works in micrograms: lsd? novichok?). On a larger scale, a lot could be done on the foundation of today's in-vitro-diagnosis technology: Storage for racks full of reagent tubes, pipettor arms, colour sensitive photometers, it's all there. You'd just have to add what misses from a human chemists lab, and you'd have your fully automatic mini-lab. Concerning efficiency and throughput, it couldn't compete in any way with specialized processes, so the main commercial market would probably be for illicit substances.
I like the thought a lot and have had my own ideas. Particularly, after I saw a video of the sensitivity of an atomic magnetometer, I've been pestering a physicist at a customer to run the numbers if a portable fixed-antenna phase-array MRT would be feasible in any way. Unfortunately he retired and now dedicates his life to the fine arts.
It's a good thing that Star Trek created a goal to aim for, and I think that over the time we will see more and more, mostly integrated with or connectable to the smartphones we have, contactless temperature bolometers, gas sensors, whatever stuff modern fitness watches have built in, and maybe even an interface for microchemical profiling as described above (look at the blood glucose over-the-counter diagnosis market to see where it heads). Machine Learning might yield good results from a spectrum of seemingly unrelated inputs; I think that will account for a good bit of tricorder magic in the future.
(Score: 0) by Anonymous Coward on Tuesday February 25 2020, @05:05PM (1 child)
Whether intranetted or otherwise, is TCP/IP still the common method for telemetry to be transmitted? What about UDP?
How much extra testing, if any, do medical devices go through for security assurance?
(Score: 2) by Rich on Tuesday February 25 2020, @07:26PM
There are two "telemetries" to consider. One is the connectivity of a device to a host of its owner (e.g. a hospital's IT schedules assays over a number of available analyzers for different things). The other is phone-home logic to the vendor.
The first thing has mostly been a serial-interface connection with a de-facto standard called "ASTM Protocol" for ages. Then, there is a newer thing called "HL7", or the upcoming "FHIR", which I haven't worked with yet. These protcols don't really define their transport, but especially for HL7, TCP transport seems to be preferred.
Phone-Home over TCP is an entirely different thing and hasn't been in any devices I've been working on. If it was, I'd assume, there would be an encrpted VPN tunnel between the device and the vendor, and it would be used to read out troubleshooting data and transfer (signed and checked) updates onto the device. I've also heard from a vendor that they are setting up their kind-of-App-Store for such updates, so that may not be tunneled. YMMV.
UDP never was a deal. It doesn't fit with any of the text-stream protocols, and on lower layers it has no use because it is not guaranteed. CAN is used for packet messaging between device components.
It is part of the overall process. For legacy devices, security development may be separate from the functional (that might have gone on since the pre-internet age). There is a developer (or more) responsible for the hardening of the platform, and test cases get written and verified to make sure that all this works as intended. However, those test cases have clear expectations, so they won't cover what a good hacker can achieve. In the later course of development, an audit may (or may not) take place, where a "good hacker" (i.e. a corporate script kiddie) tries an attack, but unless he is successful, you'll never know how good he really was. Generally, the devices should be pretty safe on a system level, because they limit the attack surface, but I'm pretty sure a nation state actor could, after analyzing the applications, root many of them by exploiting flaws in the application protocols.
At the moment, the big issue in the "data protection" sector is implementing the GPDR limitations, though.
(Score: 2) by JoeMerchant on Tuesday February 25 2020, @05:06PM (4 children)
How much "hands on" integration is required when you sell networked products into a new customer site? We're just starting to develop for that (EMR/HL7/FHIR) market and the intel we've gotten back so far is: "a lot, every site is different, it's hopeless to try to automate it, one configuration never fits more than a few..."
🌻🌻 [google.com]
(Score: 3, Informative) by Rich on Tuesday February 25 2020, @07:40PM (3 children)
That's pretty much it. Every customer is doing their own stuff and there are peculiarities with how the devices understand things. If a customer has no in-house software development and just the usual admin crew, I'd estimate an effort of anything between 2 to 20 work days to get an interfacing going - if the devices claim to speak the same protocol. If not, all bets are open.
That said, I haven't developed anything against HL7 so far, only ASTM and legacy protocols, and internal communications of a local sample handling system. I often hear HL7 being a requirement for this or that, but always because it's the "in" thing, never because "it finally gets rid of all the connectivity issues for good".
(Score: 2) by JoeMerchant on Tuesday February 25 2020, @08:17PM (2 children)
I've been bouncing off of HL7 since 1991, this is _finally_ starting to look like a commercial development and rollout of something that uses it. It reminds me a lot of DICOM, the non-standard standard - more like the "Pirate Code" guidelines really. Sort of state of the art for the early 90s when "compatible" meant 90%+ compatible, some tweaking required.
If you ever do wander into serious HL7 implementation across multiple vendors, we've found https://www.iheusa.org/ihe-connectathon-overview [iheusa.org] to be a good way to develop some level of internal confidence that "our stuff works." Too bad it's still going to need massaging in the field.
🌻🌻 [google.com]
(Score: 2) by Rich on Tuesday February 25 2020, @09:08PM (1 child)
Thanks for the lead. I wouldn't be surprised if some of my customers show up there with their stuff.
I don't like the networking and connectivity things much and generally try to avoid them - alas, coming up in two months or so I've got a set of host drivers to work on as part of a general software overhaul. I can do all that, if I need to, but it's a bit of a chore to me. I feel more at home in the lower layers. :)
(Score: 2) by JoeMerchant on Tuesday February 25 2020, @09:57PM
For family reasons I don't travel unless absolutely necessary - so, the younger staff get "experience" doing the Connectathon field work. Years ago I might have wanted to go to the European one, but I don't think I'd ever be wanting to go to Cleveland in January...
🌻🌻 [google.com]
(Score: 0) by Anonymous Coward on Tuesday February 25 2020, @02:26PM (3 children)
They use the example that NTP is only maintained by ONE PERSON!... but isn't NTP "finished"? What changes are really left to add? Can't be much at all.
(Score: 4, Funny) by DannyB on Tuesday February 25 2020, @06:40PM (2 children)
NTP needs to be reimplemented. In Java. With lots of XML. And more XML that configures the interpretation of the XML. And more XML that configures the interpretation of the first configuration XML file.
An object that holds the current time would be produced by a TimeFactory. The factory object could be configured in numerous ways to precisely control just how various aspects of "the current time" objects get created.
Because the factory object may need to be configured, a TimeFactoryFactory would be configured and used to create a TimeFactory in the precise way that you want that factory to be configurable. Then it can be configured to create "current time" objects in exactly the way you want.
Now what time is it at the other end of that network connection again? Oh, the system requesting the current time has been upgraded to a new OS while we were responding to the network request? Oh, nevermind.
The lower I set my standards the more accomplishments I have.
(Score: 2) by Rich on Tuesday February 25 2020, @07:50PM (1 child)
Your own fault. That happens when you don't roll out with continous integration into properly orchestrated containers.
(Score: 2) by DannyB on Tuesday February 25 2020, @08:41PM
No matter how slow individual the response time is to service an individual NTP request, you can make up for it with scale! Have say, 100,000 threads ready and listening for requests.
There. That should fix it.
(most of my family was handicapped by having only one left hand.)
The lower I set my standards the more accomplishments I have.
(Score: 0) by Anonymous Coward on Tuesday February 25 2020, @04:10PM (1 child)
chances are that if you need a iots device that you're probably on the way to see the daisy grow from below.
so let's give this battlefield to m$ where they calculate how much it needs to cost to cover all lawsuits stemming from malfunction and still making enough to buy a yacht or two.
after all if it costs money it's better!
sidenote: suing a greedy careless for-profit entity has better profit outcomes!
(Score: 0) by Anonymous Coward on Tuesday February 25 2020, @05:08PM
Double-sidenote: You realize that the vast majority of medicine is based on cost-benefit analyses (not even risk-reward, but straight up cost-benefit)? And that the industry as a whole does incorporate legal costs into their budgeting, because they can't stop being sued whether legitimate or not? i.e. they're ready for you and the decision to settle or fight depends on how much you're asking and whether they think they'll lose....