3 ms·

Even if embedded devices are updatable in principle, in practice how often do they receive security patches? Pointing to a feature list isn't a realistic evalua

Even if embedded devices are updatable in principle, in practice how often do they receive security patches? Pointing to a feature list isn't a realistic evaluation of what actually happens. We live in a world where even phones don't get patched as frequently as they should; you expect end users to patch their pacemakers? Putting them online and allowing auto-patching would probably be worse since it also increases their attack surface drastically. > This is why any it's important to practice responsible disclosure. Right, and fact is that 'responsible disclosure' ends up looking a lot like obscurity in a world where you can't guarantee that devices will be patched before an attacker would be interested in exploitation.

pdkl95 10y ago
> in practice how often do they receive security patches? I have no idea what the current patch rate is for pacemakers, but they do happen. The use of radio was a feature specifically to allow updating and management of the pacemakers while avoiding the serious risks of surgery. The pacemakers would be patched when the patient shows up for their next checkup appointment, which is probably every 1-2 months. They already connect to the devices for regular diagnostic purposes at those times. If the problem was severe enough, calls would be made to the patients to come in right away. Medical services already handle problems on a priority basis ("triage"). This already happens for other types of problems. > 'responsible disclosure' ends up looking a lot like obscurity That's a circular argument. You're implying that the manufacturer wouldn't want to fix their product, which is highly unlikely. The only reason they are resistant to the idea at present is because the source is closed. The entire point is that by opening up the source the community can work with the manufacturers to fix these problems. You're arguing that because the current system currently doesn't patch bugs that often, we shouldn't allow more debugging. Pretending that either bugs don't exist or that malicious actors won't find them without the source code is dangerous. "Pride goes before the fall"; do you really want to bet - potentially with your life - that all malicious actors are too stupid to find security problems? Hint: many medical devices have already been hacked (without the source). Or do you want to let the community at least attempt to find the bugs first?
- smallnamespace 10y ago
  > The use of radio was a feature specifically to allow updating and management of the pacemakers while avoiding the serious risks of surgery. In other words, it's a ready-made vector for potential attacks, as long as an attacker can get close to a pacemaker with a radio. You could probably even put a powerful device near a hospital and pick up random people coming and going. > Or do you want to let the community at least _attempt_ to find the bugs first? The promise of open-source security has always been that you let many eyes look for problems, then you patch ahead of potential attackers. Logistically, that's extremely problematic for embedded devices. Every time a vulnerability is found, you ask the patient to go back to the doctor to get it updated? That doesn't scale at all. The idea that device manufacturers will change their entire engineering and security philosophy is somewhere between idealistic and naive. I sincerely hope it's the former and not the latter.

pdkl95 10y ago

> in practice how often do they receive security patches? I have no idea what the current patch rate is for pacemakers, but they do happen. The use of radio was a feature specifically to allow updating and management of the pacemakers while avoiding the serious risks of surgery. The pacemakers would be patched when the patient shows up for their next checkup appointment, which is probably every 1-2 months. They already connect to the devices for regular diagnostic purposes at those times. If the problem was severe enough, calls would be made to the patients to come in right away. Medical services already handle problems on a priority basis ("triage"). This already happens for other types of problems. > 'responsible disclosure' ends up looking a lot like obscurity That's a circular argument. You're implying that the manufacturer wouldn't want to fix their product, which is highly unlikely. The only reason they are resistant to the idea at present is because the source is closed. The entire point is that by opening up the source the community can work with the manufacturers to fix these problems. You're arguing that because the current system currently doesn't patch bugs that often, we shouldn't allow more debugging. Pretending that either bugs don't exist or that malicious actors won't find them without the source code is dangerous. "Pride goes before the fall"; do you really want to bet - potentially with your life - that all malicious actors are too stupid to find security problems? Hint: many medical devices have already been hacked (without the source). Or do you want to let the community at least attempt to find the bugs first?

smallnamespace 10y ago
> The use of radio was a feature specifically to allow updating and management of the pacemakers while avoiding the serious risks of surgery. In other words, it's a ready-made vector for potential attacks, as long as an attacker can get close to a pacemaker with a radio. You could probably even put a powerful device near a hospital and pick up random people coming and going. > Or do you want to let the community at least _attempt_ to find the bugs first? The promise of open-source security has always been that you let many eyes look for problems, then you patch ahead of potential attackers. Logistically, that's extremely problematic for embedded devices. Every time a vulnerability is found, you ask the patient to go back to the doctor to get it updated? That doesn't scale at all. The idea that device manufacturers will change their entire engineering and security philosophy is somewhere between idealistic and naive. I sincerely hope it's the former and not the latter.