I am generally opposed to liabilities for software defects, but system integration seems a more reasonable place to apply rules.
Because from what I can tell, it would require formal proof that the connected parts are safe (logic bugs can also be exploited, so just using a safe language is insufficient).
If you can't get manufacturers to do the cheap, easy air-gapping, how will you get them to do the very expensive and time-consuming formal verification, that only a tiny, tiny fraction of developers is proficient in? Intractable doesn't even begin to describe it!
Nobody is going to air-gap anything and I think there is ample evidence over the last 20 years that the trend goes in the opposite direction. Given the reality of the world we actually live in, productive conversations about securing embedded and IoT systems can't involve air gaps.
Slightly later
Here's another, simpler way to say the same thing: you might just as productively argue that these products shouldn't be built at all.
It's kind of like how I've seen you comment multiple times about how software shouldn't be written in C. You even said it during the DNS fuzzing thread earlier today.
You saying that is just as pointless. You would be very surprised at how much new stuff is written in C!
The opposite is the case for network connectivity: the trend is demonstrably and decisively towards increased connectivity, and "air-gapping" is not taken seriously in the industry. There is no indication of that changing.
The comparison you're making is invalid. I'm not trying to score points; I'm observing that the litany of "this should be air-gapped" complaints isn't productive, because things are not going to be air-gapped.
(My full-time job is assessing software security and my background is in C software vulnerability research, so it's less likely that I'd be "surprised" by a new C package than that I'd warn my clients to avoid it, and flunk it in vendorsec assessments.)
So, how would one be productive about it?
Your post seems to say, and please correct me if I am wrong, that because things aren't currently happening and there are some barriers to making it happen, we should all give up on pushing for it? To me, that seems like a rather fatalist attitude to have. Do we apply this line of thinking to everything? Or just air-gapping?
I am not, by the way, happy about this, but I've also spent essentially a lifetime (minus maybe 13-14 years at the beginning) having all the surprise on this particular issue knocked out of me.
I guess I have a little bit of surprise left in me on this issue.
It's good to raise the bar from drive-by internet strangers to people and organizations willing to take mild physical risks, but it's not a panacea.
I don't quite know how my comment led you to believe that I think airgapping is a pancea which solves all the existing computer woes in the world.
I certainly don't think, and didn't intend to imply, that airgapping removes the risk from contractors or a reason to not keep up on patches. Again, I'm confused how you reached that conclusion based on my comment.
"And even if there weren't, if you've been thinking of the airgap as a "solution" and not keeping up with patches, ..."
Nobody here is going to say airgap and done, but out in the wild they will certainly deprioritize updates on airgapped equipment.
Perhaps the 'you' was intended to be generalized. I interpreted as directed at me, since the entirety of the comment is directed at me. Maybe I'm mistaken.
The joys of trying to have meaningful conversations over text.
One might start by observing that there are reasons these things aren't air-gapped. A person could go on to note which of these reasons continue to apply and are considered compelling by those who make the relevant decisions, and thus that air-gapping is likely to persist.
So maybe the system could be connected to the network except for when it is treating a patient. A big red slider with 'On Air/Isolated' could be present which would lock out the patient treating options as soon as the machine is networked. Now, this would still leave some gaps: an update could be faulty, a malicious actor could install something that triggers only after a while or when the machine is used to treat a patient. But it would remove a lot of the concern I have with equipment like this being online all the time.
The risks of compromise of an anesthesia machine are scary. It’s also scary that without EMR integration, a dosage might be misreported or an allergy missed.
It’s possible to securely segment a network to defend against these types of risks. The bigger problem here is that the professional practice of IT is such a garbage fire, it’s assumed that the LAN is compromised and airgapping is the responsible choice.
When will we get an ANSI standard for one of these new fangled languages?
Go is captive to Google, and Rust is more akin to C++ than C -- neither have an actual standard with competing compilers.
Until that changes, I think plenty of new software will be written in C, especially freestanding and embedded software.
C++ doesn't have an actual standard? Are you sure about that?
Yes both C and C++ have standards, and I consider that to be a good thing, though apparently tptacek says I shouldn't care.
C is on the way out. It's not gone, but it's going. There will not be a revitalization of the language. It'll be good to know, because some things (OS kernels and device drivers) will continue to be written in C for the foreseeable future. But that's a very small niche relative to the industry as a whole.
Nobody cares, and nobody should care, about ANSI standards.
There are, no doubt, a number of niche systems that require specific toolchains. There are, in our fallen world, systems that require Ada or even particular variants of C. If you want to tell me that aviation flight control systems are such a niche, I will believe you --- I've never had to assess one.
But it is not the case that industrial computing or medical device software are locked into memory-unsafe languages due to industry-wide certificational requirements; in fact, that's something I know not to be true from specific experience. And virtually all of the embedded systems I've had to assess over the years would have benefited, commercially, from a memory-safe implementation language.
This is a major barrier to entry for new programming languages in these markets. Note that I am not saying that improved memory safety wouldn't be useful in embedded software. But the market is so conservative in parts that real uptake is at least a decade or two away.
Since many people are interested in using Rust for such applications, there are efforts underway to stabilize the compiler and do the necessary paperwork so that not every company needs to do it themselves.
What test suite are you talking about? I am really curious because this would completely upset the whole industry if what you ssid was true for the toolchain.
I've been a contractor for a medical devices company for one year, and the process where really lightyears away from what you are describing. Nothing even forces you to write and run unit tests…
Yes, that's scary.
The next company I worked at was industry, not medical, and this one did it right. So while there's black sheep out there, not all of them are.
Side note: whether a device can fall back to becoming inert on a failure depends on the type of device and the specific risks involved with that failure mode. It may be that stopping to do anything is the wrong thing to do, e.g. in a blood pump.
Borrow checking is unrelated to whether you are on an embedded device or not.
Guarding against mutable aliasing with respect to hardware state could be enormously valuable.
I don't quite understand what you are saying in your second paragraph.
let mut x: Result<i32,f32> = Ok(1);
let y = x.as_ref().unwrap();
x = Err(1.0);
println!("{}", y); // unsafe cast of float to int
The borrow checker is great for all sorts of things, like ensuring that you only have a single mutable reference or an arbitrary number of immutable references to objects (to prevent corruption) and for the pseudo-threaded model interrupts entail. Memory safety matters in embedded systems, too. You can encode state cleanly with ADT enums [2] where the language can statically detect invalid state transitions.
It's also a much more expressive language, providing you with great abstractions with no added cost. The ergonomics are pretty great compared to dealing with C once your peripherals / register accesses are wrapped, as often are already. For instance, check out the stm32 package [1].
Being able to rely on the compiler more means you get correct code faster, and debugging on embedded systems can be absolute hell. Anything that helps me avoid it is a massive win in my books.
[1] https://github.com/stm32-rs/stm32-rs
[2] https://hoverbear.org/2016/10/12/rust-state-machine-pattern/
Specifically speaking to medical devices, there is a bit of systemic bias. Early hospital networks were isolated, and this led to some naive thinking about security (e.g. DICOM protocol has no auth provisions). Many early machines weren't connected to anything at all, then they were but only "safe" networks so not much care taken. Development lifecycles on complicated devices is incremental over sometimes even decades. But now hospitals etc. have lots of pressure to connect all the things, for all kinds of good and productive reasons, and air-gapping just isn't a realistic solution.
It's not an easy problem to solve, especially quickly.
You are starting to see some partial hardening of devices, which will probably be the practical solution.
So even if you can't normally access certain records or data, if you claim it is an emergency you suddenly can!
There are sometimes calibration modes or research keys that let you do odd things to, say, imaging machines. But there are also processes in place to disallow clinical use.