Slashdot Mirror


DHS Investigates 24 Potentially Lethal IoT Medical Devices

An anonymous reader writes: In the wake of the U.S. Food and Drug Administration's recent recommendations to strengthen security on net-connected medical devices, the Department of Homeland Security is launching an investigation into 24 cases of potential cybersecurity vulnerabilities in hospital equipment and personal medical devices. Independent security researcher Billy Rios submitted proof-of-concept evidence to the FDA indicating that it would be possible for a hacker to force infusion pumps to fatally overdose a patient. Though the complete range of devices under investigation has not been disclosed, it is reported that one of them is an "implantable heart device." William Maisel, chief scientist at the FDA's Center for Devices and Radiological Health, said, "The conventional wisdom in the past was that products only had to be protected from unintentional threats. Now they also have to be protected from intentional threats too."

79 comments

  1. Fine, but... by Jonifico · · Score: 3, Insightful

    Of course, it's always good to see patient safety is encouraged. I hope making it public does push towards fixing the issues and not people panicking.

    1. Re:Fine, but... by Thanshin · · Score: 0

      Unless panic is warranted!

      A hacker could hack the hospital doors and windows and everybody would die of starvation sooner or later!

    2. Re:Fine, but... by JasonGoatcher · · Score: 1

      Unless panic is warranted!

      A hacker could hack the hospital doors and windows and everybody would die of starvation sooner or later!

      Can you picture the carnage as people waste away as they vainly dance around and wave their arms at the little motion detector that was destroyed by the hacker, never realizing they could simply throw stuff at the glass in the sliding doors to make it break, thus freeing themselves from the hell they're in?

    3. Re:Fine, but... by Anonymous Coward · · Score: 0

      also most of these types of motion activated doors have manual release in case of power failures. just push it and it should open (swing) out.

      but yes it would be funny to watch as someone stands there waving their arms jumping around trying to get it to open up.

    4. Re:Fine, but... by sexconker · · Score: 1

      Unless panic is warranted!

      A hacker could hack the hospital doors and windows and everybody would die of starvation sooner or later!

      Can you picture the carnage as people waste away as they vainly dance around and wave their arms at the little motion detector that was destroyed by the hacker, never realizing they could simply throw stuff at the glass in the sliding doors to make it break, thus freeing themselves from the hell they're in?

      Already covered by history's greatest hero: https://www.youtube.com/watch?...
      I recommend watching the whole episode (and series).

    5. Re:Fine, but... by weilawei · · Score: 1

      There is no situation that panic cannot make worse.

      In the immortal words of Douglas Adams, Don't Panic.

  2. At last... by Anonymous Coward · · Score: 3, Insightful

    William Maisel, chief scientist at the FDA's Center for Devices and Radiological Health, said, "The conventional wisdom in the past was that products only had to be protected from unintentional threats. Now they also have to be protected from intentional threats too."

    This statement comes so late... The security community has been saying that for years! What happened to forward-thinking?

    1. Re:At last... by Frobnicator · · Score: 1

      This statement comes so late... The security community has been saying that for years! What happened to forward-thinking?

      In the engineering community that is so standard it entered into the common usage. "Fail safe", meaning that for any failure you need to go to the safe option. A gate or switch or lock should either fail open or closed, which one is safe depends on the circumstances.

      On a more prophetic note, the story two weeks ago predicting the first online murder by the end of the year seems that much closer. The reports nearly give explicit instructions.

      Seems like this Billy Rios researcher identified the problem but didn't kill anyone with it. But he could have if he wanted. Someone else could read the details and figure they are anonymous enough to flip the switch just for grins and giggles.

      --
      //TODO: Think of witty sig statement
    2. Re:At last... by Frobnicator · · Score: 1

      Looks like it is out in more than just the report. More news agencies are publishing extra details.

      The news agencies are pointing out the brand (Hospira) and the exact models of devices that are Internet-controllable. They mention the type of signals that need to be sent (multiple commands to infuse the drug) and they discuss the security measures already in place.

      It seems the only thing they left out of news stories is the actual payload.

      --
      //TODO: Think of witty sig statement
  3. I, for one, will be happy... by Overzeetop · · Score: 5, Insightful

    ...when referring to connected/connectable devices as IoT dies.

    --
    Is it just my observation, or are there way too many stupid people in the world?
    1. Re:I, for one, will be happy... by arth1 · · Score: 2

      It's the buzzword of the year. Give it 3-4 years to die out.

      Words that have peaked and are on the way down and out include freemium, cloud, neet, big data, crowd[anything], agile and emoji.
      Slightly worrying is that [anything]gate has not petered out yet.

      The good things about the buzzwords is that they serve to positively identify those who use them as sheep, not wolves.

    2. Re:I, for one, will be happy... by coinreturn · · Score: 1

      ...when referring to connected/connectable devices as IoT dies.

      What's wrong with Internet of Toilets? I like mine to tweet the weight and offensiveness of every poop.

    3. Re:I, for one, will be happy... by Anonymous Coward · · Score: 0

      I work as a security consultant in the medical device industry, and it's the first time I've seen it. Maybe I'll develop a hatred soon?

    4. Re:I, for one, will be happy... by Bob+the+Super+Hamste · · Score: 1

      Then we need a bit of clarity on the Hobo Power scale.

      --
      Time to offend someone
    5. Re:I, for one, will be happy... by TubeSteak · · Score: 1

      It's the buzzword of the year. Give it 3-4 years to die out.

      Please let me know when all the companies with "-ly" names are expected to die off.

      Embedly, Nextly, Locately, Drizly, Intelligent.ly, Delightfully, Crowdly, Bitly, Attentive.ly, etc
      I cannot wait to bid you goodbye.

      /I also hold a special hatred for adf.ly and their link shortening interstitial ad-pages.

      --
      [Fuck Beta]
      o0t!
    6. Re:I, for one, will be happy... by Anonymous Coward · · Score: 0

      I was wondering what the hell that stood for. I've been in the medical devices inductry for years and have never heard anyone in the industry use this term to describe a medical device yet.

    7. Re:I, for one, will be happy... by sjames · · Score: 1

      Whenever I see that, I think of the Illuminates of Thanateros though the device one probably doesn't have nearly as much magick in the chaos.

  4. Most metal impants are "hackable" by davidwr · · Score: 2

    As I pointed out a few weeks ago, most implants with electronics or metal can be "hacked" by targeting them with microwaves. Sure, so can the human body but you don't need as much power to disable a possibly-life-sustaining electronic device as you to do cook flesh. Even metal parts will heat up (and cook adjacent living tissue) with less power than the human body.

    However, if my heart is dying and I have a choice between getting an implantable artificial heart even knowing that I could be killed by someone armed with a microwave gun or dying waiting for a human donor, I'll take the artificial heart.

    --
    Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
    1. Re: Most metal impants are "hackable" by Anonymous Coward · · Score: 1

      This is why Krusty can't use the microwave at the Kwik-E-Mart

    2. Re:Most metal impants are "hackable" by Anonymous Coward · · Score: 0

      A microwave gun requires someone to actively hunt you in real life and be in Line of Site of you. The issues that are coming up is Internet connected devices or devices that can be hacked via a passer-by with an infected cell phone. These two examples could potentially kill nearly everyone in the world, with little effort and remotely, that has dependencies on these issues.

  5. Well ... duh! by gstoddart · · Score: 3, Insightful

    If you are going to connect things to the internet, you pretty much need to harden them against malicious attacks.

    So many of these things are done with the very naive "what could possibly go wrong?" kind of attitude where there's pretty much no attempt at security.

    So many companies (especially some of the medical companies) treat security as something they don't need to worry about. The problem is if something is accessible, and people can muck about with it, they will simply because it's there.

    It may sound like a movie plot, but if I know you have a particular kind of internet-enabled implant ... it's far easier to go after you from a distance than up close.

    Sadly, while they're looking at the medical stuff, I'm betting there will still be a huge list of other "IoT' devices for which security is a complete joke, if not outright non-existent.

    Which is why I have no interest at all in the Internet of Things. At present, it's marketing hype, which hasn't even begun to address basic security and privacy issues.

    --
    Lost at C:>. Found at C.
    1. Re:Well ... duh! by gurps_npc · · Score: 2, Informative
      I disagree. You don't have to harden your internet connected refrigerator against malicious attacks.

      Why? Because when you ask "what could possibly go wrong?" the answer is your food will spoil, and you will have to throw it out. It's not like spoiled food is not instantly recognizable.

      But when you ask that company about medical equipment, the answer is PEOPLE WILL DIE.

      The problem is obvious, it just takes half a second to think and you know you need security.

      Actually, the real problem is that idiot manufacturers refused to think at all.

      --
      excitingthingstodo.blogspot.com
    2. Re:Well ... duh! by Anonymous Coward · · Score: 2, Insightful

      Depends entirely on what is in the fridge.

      Turning off the fridge containing your supply of insulin can make the insulin go bad. Hide the fact the fridge has been off that long by turning it back on.

      If you take the dosage before realizing the fridge has been off that long could kill you.

    3. Re:Well ... duh! by Anonymous Coward · · Score: 1

      Another problem is that people who develop software with security defects are quite often also not competent enough to develop software without other kind of defects.

    4. Re:Well ... duh! by Anonymous Coward · · Score: 0

      Unless, of course, you can trick the compressor to go into overdrive, burn out, and start an electrical fire....

    5. Re:Well ... duh! by gstoddart · · Score: 3, Interesting

      You don't have to harden your internet connected refrigerator against malicious attacks. Why? Because when you ask "what could possibly go wrong?" the answer is your food will spoil, and you will have to throw it out. It's not like spoiled food is not instantly recognizable.

      See, anything which would allow a remote attacker to destroy your property and cause you to spend money is an indication than in internet enabled fridge is either a really stupid idea, or that it needs to be hardened.

      So, other than some moronic social experiment of "information wants to be free so if you see what's in my fridge what's the harm" ... what the hell would I want one for? What benefit does it give me? It's just another stupid, insecure application which wants to tie into a smart phone so I can feel all hip and cool.

      If some asshole hacking my fridge and spoiling my food (or, possibly my medication) is the price of having an internet connected fridge ... then why would I even consider owning one? What is the upside here for me?

      You sound like you're willing to give manufacturers of fridges some kind of free pass to be incompetent/indifferent to security. I'm saying any manufacturer which is either of those two things doesn't deserve to get my money.

      The same goes for my thermostat. And my lights. And my stove. And my freezer. If you're not taking security seriously, I'm not taking your fscking product seriously.

      So, if the internet of things is predicated on terrible security, or being indifferent to it altogether ... then the internet of things is a bad joke doomed to failure. And, of course, things which are that bad at security make additional risks for other things.

      If I have to firewall my fridge to make it useful, I won't connect it to the internet at all. If it pokes holes in my security and provides an access point to attack other things ... then I really don't want it.

      To me there is no scenario in which I'm willing to accept companies being too damned lazy to care about security. Because that pretty much makes the devices not trustworthy from the start.

      --
      Lost at C:>. Found at C.
    6. Re:Well ... duh! by geekmux · · Score: 2

      I disagree. You don't have to harden your internet connected refrigerator against malicious attacks.

      Why? Because when you ask "what could possibly go wrong?" the answer is your food will spoil, and you will have to throw it out. It's not like spoiled food is not instantly recognizable.

      If I turn off your fridge for 8 hours during the day and spoil your mayo or other like food that may be very difficult to discern is bad or not, and then turn your fridge back on before you get home, you have no damn idea the dangers that could be lurking in the spoiled food that you were unaware had been exposed to dangerously high temps for several hours.

      The CDC estimates that 1 in 6 Americans are affected by a foodborne illness each year, resulting in 3,000 fatalities. So yeah, PEOPLE DIE

      Funny thing about comparing food to people with hackable implants. Everyone has to eat. Not everyone has an implant.

      Try and understand the true risk beyond your simple analysis here.

    7. Re:Well ... duh! by Anonymous Coward · · Score: 0

      I disagree. You don't have to harden your internet connected refrigerator against malicious attacks.

      As others have pointed out, you are yet another one of those who don't get it. You should ask yourself if you would like to have an internet connected fridge that was hacked and tampered with. If the answer is no, it probably means that it's a bad idea to do it in the first place or that it needs proper security.

      The comes the next, possibly harder step. What if there are security flaws in a medical device?
        * If malicious people want to find out, they need to spend a bunch of cash, but they will, so they will find the security flaws.
        * If the supplier wants to spend money to find out, he will. But he spends as little as possible, so he likely doesn't find any flaws.
        * If the customer wants to find out he needs to spend a bunch of cash, but that bunch is likely 100 times what the product costs, so he won't

      So... Only the malicious people find out.

    8. Re:Well ... duh! by rjforster · · Score: 1

      I disagree. You don't have to harden your internet connected refrigerator against malicious attacks.

      Why? Because when you ask "what could possibly go wrong?" the answer is your food will spoil, and you will have to throw it out. It's not like spoiled food is not instantly recognizable.

      Unless your fridge has the capability of re-ordering food that you've run out of. Or ordering all the ingredients from a menu you scan with your smartphone. Or whatever.
      Then it can be hacked to order really expensive stuff. If it normally needs human approval then that is just another bump to cross before it can be hacked to be done without your approval.

      Why would anyone do this other than as a prank? Well what if I order something from a company with a policy of "if it's listed as in stock but we can't deliver it within x days for some reason then you get it free when we eventually restock" then I get you to buy out all their stock half a second before I confirm my order. I wait a few extra days but get that crate of champagne for free. The supermarket can't detect anything because they aren't the ones being hacked.

      As ever, it will be an arms race of attack and mitigation until it all settles down.

    9. Re:Well ... duh! by Khyber · · Score: 1

      " It's not like spoiled food is not instantly recognizable. "

      As former head chef of Jack's Bar and Grill, BULLSHIT.

      And this, ladies and gentlemen, is why some states require licensing for food handling jobs, even if you're working for McDonald's as a janitor.

      --
      Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
    10. Re:Well ... duh! by Anonymous Coward · · Score: 0

      What happens if your fridge gets hacked? How do you fix a fridge that's part of a botnet? Sending spam? monitoring your local network? If anything gets hacked at "home", then how do you catch it inside your home network? Stop it from being a launching point for other hacks inside your home network?

      What happens if your Smart TV gets hacked? Smart Home Monitor? Nest?

      Yes, the implications are more likely lethal in the hospital... but that in no way shape or form negates the severity of having huge gaping holes in your home network that are piss poorly thought out. It may be a fridge... but that fridge is inside your home network.

      That makes your home network only as strong as it's weakest link.

    11. Re:Well ... duh! by wagnerrp · · Score: 1

      The same goes for my thermostat. And my lights. And my stove. And my freezer. If you're not taking security seriously, I'm not taking your fscking product seriously.

      The entire industrial control world is completely indifferent to security. Things like HMI applications may implement user-level restrictions, but ultimately the hardware they interface with is usually just open access over OPC or HTML. This works in general when you're on an isolated industrial network, of course these networks are typically not completely isolated, allowing remote access for maintenance and support. Even when completely isolated, you still have the issue of operators connecting infected hardware to the network, as seen with stuxnet.

      The problem with IoT is that the same embedded and controls engineers are just applying the same methodology to this as industrial applications, and assuming someone upstream will handle the security issue. Security is a double edged sword. While it's necessary at some level, it's going to add considerable overhead and latency, and is all but unusable if you intend to do real time control. The isolated, open network is the only sensible approach. Now IoT parts could completely embrace the industrial methodology, and while the typical controls engineer might think nothing of running ethernet or RS-485 drops throughout their home with a central secured gateway for access, the typical consumer user is enamored will all things wireless. On the other hand IoT parts are not doing any form of real time control over their remote interfaces, so there's no reason for them to be externally behaving like industrial hardware, and programmers stuck in that mindset should not be left in charge of building those interfaces.

    12. Re:Well ... duh! by ic3m4n1 · · Score: 1

      So, other than some moronic social experiment of "information wants to be free so if you see what's in my fridge what's the harm" ... what the hell would I want one for? What benefit does it give me? It's just another stupid, insecure application which wants to tie into a smart phone so I can feel all hip and cool.

      Well you may not want it due to security issues. But there are many who would just buy it because its has one latest and greatest feature available on market(even if useless/unwanted) or simply because its the most expensive thing available.

      Look I can turn off my fridge light with this app. Its off now. Now on. Now off.
      Go to see open door, it should be off, oh well..

      On the other side if I am manufacturer and can charge a premium for showing your spam mails on fridge, I will make sure my marketing team sells you one.

      Security, you ask? Well thats just someone else problem to fix. You were targeted specifically and company cannot be held responsible. We should catch that thief and make sure he lands prison. That will teach him a lesson hacking someones fridge on internet. Who does he thinks he is sending arbitrary keystrokes floating on internet causing cold to other fridges.

    13. Re:Well ... duh! by Anonymous Coward · · Score: 0

      Depends entirely on what is in the fridge.

      Turning off the fridge containing your supply of insulin can make the insulin go bad. Hide the fact the fridge has been off that long by turning it back on.

      If you take the dosage before realizing the fridge has been off that long could kill you.

      Insulin user here: most insulin will go cloudy/lumpy when bad, most insulin gets used before 90 days even refrigerated at home. Insulin has an official use by of 30 days uncooled, I routinely use insulin beyond its recommended room temperature time limits by up to %100, it will just stop working before it kills you. Procedure is to examine every dose, so no, not likely to hurt anyone unless you tamper with a regional storage refrigerator.

      On other breaking medical news, EBOLA EBOLA. Now panic without thinking about it first.

    14. Re:Well ... duh! by crbowman · · Score: 1

      I'm not sure this is true. If you could hack my fridge to control the temperature then it would be fairly easy to turn it off right after I leave for work and turn it back on before I return at the end of a long day. Many foods in my fridge like liquids (excluding milk) and condiments wouldn't go back in a noticeable way, but it could leave me at increased risk for salmonella from the chicken or eggs.

    15. Re:Well ... duh! by renaistre · · Score: 1

      Problem is, you gave the wrong answer to the question "what could possibly go wrong?" The right answer includes the possibility that a compromised refrigerator could be the foot in the door that allows an attacker into the network, which can then be used to compromise other devices on the network, which can in turn be used for any number of bad things. Same with internet-connected light bulbs, which was a real item in the news not long ago. So, yes, even an internet-connected refrigerator should be designed with security in mind. You have to think beyond the implications of breached security affecting only the device itself.

  6. Since these people still don't get it.... by MitchDev · · Score: 2

    Anything computerized with a network connection can (and most likely WILL) be hacked...

    Screw this stupid "Internet of Things"

    1. Re:Since these people still don't get it.... by naasking · · Score: 1

      Anything computerized with a network connection can (and most likely WILL) be hacked...

      Not if you take appropriate precautions, like using a safe programming language.

    2. Re:Since these people still don't get it.... by jittles · · Score: 1

      Anything computerized with a network connection can (and most likely WILL) be hacked...

      Not if you take appropriate precautions, like using a safe programming language.

      Last I checked, programming languages are designed and implemented by human beings. Even if a programming language can decrease your attack surface, there could still be an exploit associated with the interpreter/compiler or a mistake in implementation of the language. When an omniscient being develops your language and its corresponding dev tools, I would say you may have a meaningful point.

    3. Re:Since these people still don't get it.... by arth1 · · Score: 1

      Not if you take appropriate precautions, like using a safe programming language.

      That's the most hilariously funny comment I've read in a long time.
      I'm sure there are people out there that believe it too.

    4. Re:Since these people still don't get it.... by naasking · · Score: 2

      Last I checked, programming languages are designed and implemented by human beings. Even if a programming language can decrease your attack surface, there could still be an exploit associated with the interpreter/compiler or a mistake in implementation of the language.

      That's what theorem provers are for. The seL4 microkernel was just formally verified as correct, we have verified C compilers, we have C verification tools (Frama-C for instance), and we have higher level, safer languages even at the systems level (Ada and Spark-Ada). This isn't an open theoretical CS question anymore, these technologies can and have been used very successfully to produce formally verified software, but the inertia behind outdated technologies and the hubris of developers who think they know better will continue to result in exploitable software.

      The idea that there's a non-zero probability that your compiler, the theorem prover used to certify it, and the theorem prover used to certify that theorem prover, may all have a bug that coincidentally permit an exploit is about as meaningful as the argument that hypothetically, QM implies there's a non-zero probability that you could spontaneously be transported to the surface of the sun.

    5. Re:Since these people still don't get it.... by naasking · · Score: 1

      I'm sure it would seem funny to someone who doesn't understand what "safe" means, in a technical sense.

    6. Re:Since these people still don't get it.... by firewrought · · Score: 1

      Anything computerized with a network connection can (and most likely WILL) be hacked...

      Not if you take appropriate precautions, like using a safe programming language.

      Don't be naive... security is a deep and subtle problem, full of nasty surprises. There is no magic bullet solution... your "safe programming language" has thousands of bugs in its standard API and run-time; it won't prevent devs from concatenating SQL with user input, misusing threading primitives, or bungling up an authentication protocol; it certainly won't patch up the numerous ways of subverting https or the modern web browser. To be secure (or have a reasonably good chance at being secure), you must at minimum use an approach where (1) security is a primary design concern thru the entire product lifecycle, (2) security solutions are deployed in a structured/layered approach using (3) actual expertise, and (4) security is an ongoing program with both proactive and reactive elements.

      (Convincing your government to help software/hardware/network companies fix their security problems instead of purposely introducing them would be a good idea too, but it looks like society is determined to learn this the hard way.)

      --
      -1, Too Many Layers Of Abstraction
    7. Re:Since these people still don't get it.... by Anonymous Coward · · Score: 0

      Yeah... any idiot knows that this would be an issue if PHP was used.

    8. Re:Since these people still don't get it.... by jittles · · Score: 1

      My point is that you can't depend on the language to protect you. I'm not saying you should ignore good technology choices because you know better than those crazy compiler people. But I do not believe that it is possible to create something that is completely unhackable. Perhaps you can create something that is non-trivial to exploit, or that is unexploitable using known techniques, but that doesn't mean that you can create a software/hardware combination that is completely foolproof. There will always be risk associated with any device that is network accessible.

    9. Re:Since these people still don't get it.... by naasking · · Score: 2

      Don't be naive... security is a deep and subtle problem, full of nasty surprises. There is no magic bullet solution... your "safe programming language" has thousands of bugs in its standard API and run-time

      I think you should update your knowledge of this field. Then you should also realize that over 90% of security vulnerabilities in programs written in unsafe languages wouldn't have occurred with safe languages. And of the vulnerabilities among safe languages, 90% of those wouldn't have occurred if they were designed to be capability secure (which is just another safety property most languages ignore).

      it won't prevent devs from concatenating SQL with user input

      You can't do this in, say Haskell, unless you write your own SQL interface library that builds solely on strings.

      misusing threading primitives

      You can't do this in concurrent safe languages, like Concurrent ML, Rust and Haskell.

      bungling up an authentication protocol

      Session types, which Haskell can verify too. Of course, all of these safety properties are encodable in even more powerful systems, like Agda or Coq.

      you must at minimum use an approach where (1) security is a primary design concern thru the entire product lifecycle, (2) security solutions are deployed in a structured/layered approach using (3) actual expertise, and (4) security is an ongoing program with both proactive and reactive elements.

      So basically, safety properties have importance on par with domain requirements, and must be subject to the same rigour that domain features get, ie. testing, verification, etc. So basically, the safer the language, in the sense that the more properties can be assured at compile-time, the more features and safety properties you can verify, and the fewer security vulnerabilities.

    10. Re:Since these people still don't get it.... by naasking · · Score: 1

      My point is that you can't depend on the language to protect you. I'm not saying you should ignore good technology choices because you know better than those crazy compiler people. But I do not believe that it is possible to create something that is completely unhackable.

      With a theorem prover like Coq, you can statically check any property you want. So you'll have to more precisely define "unhackable" before "it is impossible to create something that is completely unhackable" can have a truth value.

      If used extensively, the only bugs you can introduce with a theorem prover are specification bugs, ie. we implemented X but actually need Y. This can certainly introduce exploits in the sense of customer surprise that say, some private information is revealed when they didn't expect it, but I'm not sure I would call this a hack. The device is working perfectly as expected, it's the expectations themselves that were wrong.

    11. Re:Since these people still don't get it.... by arth1 · · Score: 1

      With a theorem prover like Coq, you can statically check any property you want.

      And that you know of. The problem is that you do not know everything.

      And no matter how safe a programming language is isn't going to stop programmers from making mistakes like saving input that's later used by another app that trusts the input, or set up a database or filesystem with too wide privileges, or any other kind of things that are outside the language itself.
      You won't be safe just because the language is safe. That's foolish thinking.

    12. Re:Since these people still don't get it.... by arth1 · · Score: 1

      Then you should also realize that over 90% of security vulnerabilities in programs written in unsafe languages wouldn't have occurred with safe languages

      Good luck starting a security company with the slogan "We provide 90% security!"

      Sorry, no, you're dead wrong. Most exploits are due to human errors they could have done in any language. Extending trust. Not seeding a rng. Leaving a developer backdoor. Not scaling.

      I do use Haskell myself for certain things, and I can tell you it's no problem creating insecure applications in Haskell. And if you count DoS as a problem, Haskell with ghc is worse than most of them. There may be other compilers that doesn't create horribly bloated code that lends itself to resource exhaustion by doing what it's supposed to do, but I don't know of any.

    13. Re:Since these people still don't get it.... by naasking · · Score: 1

      And that you know of. The problem is that you do not know everything.

      No, that's not how it works. You don't outlaw all possible bad behaviours, you enable only the behaviours you want to achieve the features you need. Everything is is forbidden statically.

    14. Re:Since these people still don't get it.... by naasking · · Score: 1

      Good luck starting a security company with the slogan "We provide 90% security!"

      I don't know what you're talking about. If anything, that would be "90% fewer security vulnerabilities", which sounds like perfectly good marketing.

      I do use Haskell myself for certain things, and I can tell you it's no problem creating insecure applications in Haskell.

      I never said Haskell was the perfect language, just that it provides good examples of achieving the needed safety properties, in that it can be extended to verify many properties that may be of interest. I didn't define "safe" in my original post, as the requried "safety" properties are domain-specific. Memory safety is the minimum needed, which would automatically handle one of the most common vulnerabilities in single programs (buffer overflows). A language that can be used to specify and check the required properties is a "safe" language for a given domain. Many languages fit most problems, few languages may be safe for all problems (although possibly undesirable for other reasons).

      If all we had were Haskell's DoS vulnerabilities, we would be in a much better place.

      Most exploits are due to human errors they could have done in any language

      Not a chance. Here's a list of the top 25 exploits from 2011. From this list, numbers 3 and 20 would have been solved right away by using any memory safe language. Most memory safe languages also implement overflow checking, so that's 24 off too.

      Languages featuring parametric polymorphism can tag unsafe values received as user inputs, so you can easily solve vulnerabilities 1, 2, 10, 14, 22, and 23 (all you really need is parametric polymorphism -- I've even done this in C#).

      The crypto entries can be handled with session types that expect encrypted packets, not plaintext. Even the selection of appropriate crypto algorithm can be constrained by various parameters and checked at compile-time, ie. a Haskell type class constraint could specify a whitelist of unbroken crypto algorithms for unrestricted use, and those which are only good in restricted scenarios.

      Design by contract can handle precondition violations, ie. #18, and such contracts can be statically checked these days in Haskell, C# and Ada.

      A capability-secure language would handle the rest (mainly "porous defense" category remains). Few languages implement full capability security properties, and they remain vulnerable to the extent that they violate those principles.

      The point is that the needed safety properties to address most common security vulnerabilities have been known for decades. Capability security was invented in the 1960s, and memory safety has been available since the first Lisp. Unfortunately, many programmers aren't interested in safety properties because they're focused too much on raw speed, but don't want to spend the verification effort to use that speed safely (Frama-C or Ada), or they want to avoid all verification effort period (dynamically typed languages).

    15. Re:Since these people still don't get it.... by firewrought · · Score: 1

      Don't get me wrong: safer programming languages and runtimes definitely help, especially with buffer overflows (thanks C++!), but it's one aspect of many that impact security.

      it won't prevent devs from concatenating SQL with user input

      You can't do this in, say Haskell, unless you write your own SQL interface library that builds solely on strings.

      Granted, I lost interest in Haskell somewhere around hitting the Functor/Monad point, but if devs can send raw SQL to the database, they will do so.

      misusing threading primitives

      You can't do this in concurrent safe languages, like Concurrent ML, Rust and Haskell.

      Yes, you can.

      So basically, safety properties have importance on par with domain requirements, and must be subject to the same rigour that domain features get, ie. testing, verification, etc.

      Good luck spreading that attitude. Makers of device drivers, SCADA, etc., dearly need it.

      Basically, the safer the language, in the sense that the more properties can be assured at compile-time, the more features and safety properties you can verify, and the fewer security vulnerabilities.

      That helps get us closer, certainty. The language and runtime can help catch/eliminate common, elementary mistakes. It's not the silver bullet though: wherever creative work is being done, therein lies the potential for new vulnerabilities.

      --
      -1, Too Many Layers Of Abstraction
  7. OK by koan · · Score: 1

    But don't we have an agency that is competent and less "Ministry of Information Retrievaly" than the DHS?
    https://www.youtube.com/watch?...

    --
    "If any question why we died, Tell them because our fathers lied."
  8. The only surprise by sinij · · Score: 3, Insightful

    The only surprise is that catastrophes are not commonplace. As an information security professional I can tell you based on a first-hand experience that we are metasploit module away from a major disaster. Industrial automation, medical, automotive and many other industries simply do not get information security. Chances are, your municipal water treatment system, you office building's elevators and heating, your glucose monitoring system, your car's infotainment system, your neighborhood's stoplights are trivially hackable. The only good news is that there is no money (but plenty of mayhem) to be made from compromising these systems. As such, people who can ether don't have a motivation or a conscientious enough to do that. Such miniscule margin of safety keeps me up at night.

    1. Re: The only surprise by Anonymous Coward · · Score: 0

      Take a nap during the day.

  9. Basic Medical Technology 101. by jellomizer · · Score: 1

    Data Protocol: HL7 While 3.0 is XML based, almost everyone uses v.2 which is a multi-row Pipe (Technically is is definable, but everyone uses pipes) delimited file.

    How the data is transferred.
    There are two common ways to transfer HL7 data.
    File Drop and read,
    Push via a non encrypted TCP/IP.

    Most healthcare systems try to put in VPN and separate networks in place to minimize the damage. But if someone was on the network they could say data update new dose, on the OBX.

    We need to get technology to support encryption better. But health care system are notoriously decades out of date.

    --
    If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    1. Re:Basic Medical Technology 101. by sinij · · Score: 2

      Only liability insurance industry can force the change. Otherwise it will be impossible to put a monetary value on this effort.

      When bad things happen, the liability is covered by the insurance. The insurance industry can accurately estimate the risk, and raise premiums accordingly. They generally don't reward greatly reducing marginal risks, as such expense of completely securing medical information systems would not meaningfully reduce premiums. It is only when prevalence of compromise increases, something (at much greater expense and urgency) will be done.

      The underlying issue is that these types of risks seen as negligible. Historically, this is accurate view, but they have not experienced almost-none to all-the-time ramp up of incidences we have seen in say network security.

    2. Re:Basic Medical Technology 101. by TubeSteak · · Score: 1

      Only liability insurance industry can force the change. Otherwise it will be impossible to put a monetary value on this effort.

      Only the insurance industry can force change without getting buried in lobbying and politics.

      But even then, the insurance industry will still end up negotiating the industry standards with device manufacturers.

      --
      [Fuck Beta]
      o0t!
  10. Wolf! Wolf! by Anonymous Coward · · Score: 0

    Isn't this it a bit over the top?

    I don't have to be an "independent security researcher" to be able to tell you that kitchen knives are potentially lethal if used by a "hacker". And cars. And plastic bags. And that most dangerous chemical, dihydrogen monoxide (lethal if inhaled for just a few minutes).

    Is that a reason to have a government agency investigate them, or is it sufficient to just keep prosecuting and punishing those who actually abuse them?

    1. Re:Wolf! Wolf! by sinij · · Score: 1

      Using your kitchen knives "example". How would you "just keep prosecuting" if stabbing could be done remotely, anonymously, on a large scale, and with nearly unlimited frequency?

      That is, imagine that it could be possible for a group of individuals to remotely cause 1mil/second stabbings in all households in say New York. It is just like that.

  11. this has been a problem fro quite some time. by nimbius · · Score: 3, Interesting

    in neonatal units for example, nearly everything is wireless and unencrypted. Its why visitors and parents are frequently told to shut off cellphones as no ones entirely certain the devices wont interfere with heart rate monitors or life support systems. Its theoretically possible to create a denial of service condition in a hospital where a nurses station for an entire floor suddenly sees life-threatening conditions for every patient, or receives a nurse request page for every patient. Injection attacks can also result in patients that are dead for hours but reported as still alive.

    --
    Good people go to bed earlier.
    1. Re:this has been a problem fro quite some time. by Anonymous Coward · · Score: 0

      Injection attacks can also result in patients that are dead for hours but reported as still alive.

      I'd worry much more about things called "injection attacks" if they involved real injections. Misreporting sensor and alert data is child's play compared to the havoc that could actually occur from these things.

  12. Law & Order - "Virus" April 21, 1993 by Anonymous Coward · · Score: 0

    I know security comes way down the list for a lot of device manufacturers but when plot lines from TV shows from over 20 years ago are ahead of the curve on device security you know you're doing something wrong...

  13. Secure it but.... by Nashirak · · Score: 1

    A friend of mine and I were just talking about this. He has a pacemaker that they put in that also has a recorder. The doctor pulls data off of the device using a wireless connection (so he doesn't have to open him up again). The device has no security on it (the doctor actually pointed that out at one point). Depending on the device you could theoretically kill someone by "hacking" into something like that (upload a new set of heart settings that drive you into a heart attack). The problem becomes though what happens if you loose the password (you are going to have to open him up to "reset" the device). Worse yet, what happens when you are rushed to the ER and they need to adjust your device. You may be unresponsive and not be able to give the password. Do they sit there with technical support for your device while you code on the table? I am not saying that medical devices don't need security, there just need to be a lot of checks and balances, especially when you are dealing with someones life.

    1. Re:Secure it but.... by Anonymous Coward · · Score: 0

      > Worse yet, what happens when you are rushed to the ER and they need to adjust your device. You may be unresponsive and not be able to give the password.

      That's easy. The device has a button on it that unlocks it when pressed. This requires opening you up. So, if the worst happens, they slice you open, hit the button, and have access. Please try for a hard one now.

    2. Re:Secure it but.... by msauve · · Score: 1

      I just knew there was a reason for tattoos other than self-mutilation.

      --
      "National Security is the chief cause of national insecurity." - Celine's First Law
    3. Re:Secure it but.... by jittles · · Score: 1

      Tattoos can be damaged or destroyed. People can get your password when they video tape you undressing at a department store changing room, or even by implanting hidden cameras in your home. But I supposed if someone went to those efforts to get your pacemaker password, they would find some way to kill you.

    4. Re:Secure it but.... by ColdWetDog · · Score: 1

      You can stop a pacemaker with a magnet near the chest wall. If you are one of those ** very few ** people who need a pacer to survive, you can get temporarily paced in the ER until they can put a new one in.

      Surprisingly enough, people HAVE thought through most of this.

      ** most pacemakers work intermittently, some people need them all of the time. Pacers do fail, it's pretty rare but sometimes even the wonders of technology aren't enough to keep you alive.

      --
      Faster! Faster! Faster would be better!
    5. Re:Secure it but.... by Anonymous Coward · · Score: 0

      > Worse yet, what happens when you are rushed to the ER and they need to adjust your device. You may be unresponsive and not be able to give the password.

      That's easy. The device has a button on it that unlocks it when pressed. This requires opening you up. So, if the worst happens, they slice you open, hit the button, and have access. Please try for a hard one now.

      The issue in this approach is the "slice you open". Most medics will tell you that this is the most risky procedure and the last resource in a medical intervention due risks such as infection, reaction to anaesthetics, etc. When designing such devices you have to conciliate usability and desired level of risks. Im sure also that most people will prefer a device that wont require someone opening their chest in order to reset it, particularly when this could be avoided and with people with advanced age.

      I had my own experience with some prototypes for assisted living for elderly people. Not something like a pacemaker, but it captured images for recognition and location. so you can imagine the privacy issues involved. We had one that was so "secure", that after losing the Wifi settings for it (WPA2 passkey, expected ssid, etc), the only way to reconfigure it was sending it back to the manufacturer.

  14. Please by ThatsNotPudding · · Score: 1

    the complete range of devices under investigation has not been disclosed, it is reported that one of them is an "implantable heart device."

    Please let it be the same one DICK Cheney uses. Though if it is on the list, he'll just switch back to yet another heart of a forsaken orphan.

    1. Re:Please by turning+in+circles · · Score: 2

      Dick Cheney had the wireless connection to his defibrillator removed just so he couldn't be targeted wirelessly. Of course, there are supposed to be regulations to ensure privacy and security on all new wireless health devices, so the FDA is not completely napping.

      --
      Might as well face it I'm addicted to data.
  15. There are some actual uses by sjbe · · Score: 1

    So, other than some moronic social experiment of "information wants to be free so if you see what's in my fridge what's the harm" ... what the hell would I want one for? What benefit does it give me?

    A good question. I've heard a few answers that make some sense, mostly revolving around service and maintentance. I leave it as an exercise to you to determine whether these uses are actually of any value.

    1) An internet connected device can notify maintenance services in the event of equipment failure automatically. You could have a service contract whereby the "health" of the machine is monitored by qualified service companies and service scheduled as needed possibly even before failure.

    2) It would allow data gathering for manufacturers regarding operating conditions and usage to help improve designs and optimize performance in real time. Perhaps manufacturers could offer an improved warranty in exchange for such monitoring capabilities.

    3) Some devices like refrigerators may integrate displays on the door and any time there is a screen there are potential applications for internet connectivity. For example if you use an online grocery service (like Amazon's) you could reorder milk or other items directly from the fridge the moment you realize you need them. You could also display movies or stream music through the fridge for entertainment while working in the kitchen.

    4) Monitoring your stove to actually make sure you turned it off. (No I wouldn't allow it to be turned on remotely - just off)

    I'm sure there are more. You have to think a little harder about how and why such a thing might be helpful. To make use of internet connectivity you have to completely re-evaluate how you use the device and what features might work well with it. No you probably aren't going to hook your toaster up to the internet but there are actual applications that make sense for some people in certain circumstances.

    1. Re:There are some actual uses by Anonymous Coward · · Score: 0

      1 has almost no benefit for the cost. The vast majority of refrigerators will run for decades before needing repair, at which point you might as well replace it.

      2 only helps the manufacturer, not the customer paying for it.

      3 seems like an extraorinarily expensive solution for what a tablet could fulfill and probably fulfill it better.

      4 is the only one that makes some sense. But it's not a refrigerator.

  16. The part I cannot understand... by Anonymous Coward · · Score: 1

    .... is why this comes under the Department of Homeland Security at all???

    1. Re:The part I cannot understand... by Anonymous Coward · · Score: 0

      It's one of the only Departments that the GOP isn't actively trying to break if I were to guess. Basically everything else they will either try to strangle the budget or prevent anyone from being confirmed to replace departing personnel. There aren't hundreds of unfilled judicial positions because Obama has been failing to nominate anyone.

    2. Re:The part I cannot understand... by Anonymous Coward · · Score: 0

      Because of Homeland the series.

  17. What surprises me here ... by golodh · · Score: 1
    is that the Government is actually doing something sensible.

    Like airing the vulnerability, launching an investigation, and giving off a signal that the *manufacturers* should pay attention to security and at least make a reasonable effort to make their kit tamper-resistant

    It would be in total accordance with a certain political outlook to suppress the news, pose as being "tough on crime" by imposing ridiculous penalties on offences that could be construed as breaking into medical equipment, and criminalising research into and publications of weaknesses.

    Perhaps I'm being optimistic ... perhaps this will still happen. That "certain political outlook" I mentioned could be a bit behind the tech news on this issue. We can still hope though.

  18. DHS does what by Anonymous Coward · · Score: 0

    It's good to see the DHS worry about security and not theatre. But given the 'stop-n-search ordinary citizens' policy of many DHS departments, I wonder when this will be applied to the IoT.

  19. Fact follows Fiction by Anonymous Coward · · Score: 0

    Apropos is a 1990's story about how medical devices connected to an "internet of things" were used to kill their users: "Killobyte" by Piers Anthony.