Securing the Internet of Things

 

Last Friday’s attack was apparently caused by the Mirai botnet, which targeted unprotected IoT devices, including Internet-ready cameras. In its wake, the inevitable has happened. There have been calls for more government regulation:

A U.S. Senator has joined security officials calling for stiffer cybersecurity for Internet of Things (IoT) devices following a major attack last Friday.

In a letter to three federal agencies, Sen. Mark Warner (D-Va.) on Tuesday called for “improved tools to better protect American consumers, manufacturers, retailers, internet sites and service providers.”

People (including Ricochet members) have been warning about the risks of the IoT for ages, but this hasn’t stopped manufacturers from flooding the market with cheap, unsecured devices — nor has it stopped consumers from purchasing them. The consensus of most of the experts I’ve read is that this is indeed a classic tragedy of the commons problem, as Senator Warner suggests, and that the only solution is for the government to step in to solve the problem.

It’s certainly true that no industry could have been warned more often that it had a problem. I read the warnings, and I sure wasn’t keen to buy any of those devices. Frankly, everything I read about the IoT creeps me out and reminds me of this:

But I seem to be an outlier in my instinctive aversion. And it seems to be true that neither manufacturers nor consumers paid those warnings much mind, either out of greed, laziness, or incomprehension. It’s also true that the cost of their error was borne by everyone, not just the specific manufacturers and consumers.

Bruce Schneier, who’s always interesting to read, thinks there’s no conceivable market solution to the problem:

The market can’t fix this because neither the buyer nor the seller cares. Think of all the CCTV cameras and DVRs used in the attack against Brian Krebs. The owners of those devices don’t care. Their devices were cheap to buy, they still work, and they don’t even know Brian. The sellers of those devices don’t care: they’re now selling newer and better models, and the original buyers only cared about price and features. There is no market solution because the insecurity is what economists call an externality: it’s an effect of the purchasing decision that affects other people. Think of it kind of like invisible pollution.

What this all means is that the IoT will remain insecure unless government steps in and fixes the problem. When we have market failures, government is the only solution. The government could impose security regulations on IoT manufacturers, forcing them to make their devices secure even though their customers don’t care. They could impose liabilities on manufacturers, allowing people like Brian Krebs to sue them. Any of these would raise the cost of insecurity and give companies incentives to spend money making their devices secure.

So is this genuinely a situation where government must step in? And if so, is it reasonable to expect the government to be any good at regulating this industry?

Also, a question for the lawyers: Why do we need the government to “impose liabilities” on the manufacturers? That’s to say, what’s preventing Brian Krebs from suing them right now? What prevents the people who were inconvenienced by last Friday’s attack from joining a class action suit against the companies in question?

Published in General, Science & Technology
Like this post? Want to comment? Join Ricochet’s community of conservatives and be part of the conversation. Join Ricochet for Free.

There are 172 comments.

Become a member to join the conversation. Or sign in if you're already a member.
  1. Chuck Enfield Inactive
    Chuck Enfield
    @ChuckEnfield

    Spin:

    anonymous: What I don’t understand is how it’s possible for a mobile phone, from outside the local network, to initiate a connection to, say, the baby monitor. I can see how the baby monitor could, say, post images on a third party site which could be accessed by the phone, but not how a direct outside-to-inside connection could be established. Can anybody explain this?

    This largely has to do with how the firewall is configured. There are inbound rules and outbound rules. That has nothing to do with which way the traffic is flowing, but which device initiates the traffic. If the device is outside the firewall initiates the traffic, then it must be allowed by an inbound rule. It remains a question whether one’s firewall is capable of these kinds of rules (not all are). Also, I don’t have a good enough understanding of UPnP to know if this kind of thing would be allowed by it.

    Another way this might work is if a public service brokers the connection between the iPhone and the baby monitor. Say the baby monitor is configured to initiate a connection with a server and download configuration changes. And the iPhone is configured to make those changes on the server. It would appear to the user as if they were making changes to the baby monitor directly.

    Spot on, but I’ll add that UPnP can affect this.  It can allow the inside device to configure port forwarding on the router as well as poke a hole through the stateful firewall.  I say can because not all routers support this, but it’s fairly common and it can be difficult to determine if any specific router permits this.  It’s why I make a no-exceptions recommendation to disable UPnP on routers.

    • #91
  2. The Reticulator Member
    The Reticulator
    @TheReticulator

    Austin Murrey: That’s a violation of our property rights.

    Jager:I think there should be more of a 2 part question before the government acts. 1) Is there a problem? 2) Does the government have a good fix that is both effective and not overly burdensome?

    If the answer is not yes to both of these then there should be no action. We get into trouble with simply saying there is a problem, so there should be a law. The details of the government action matter.

    Yes.

    • #92
  3. Guruforhire Inactive
    Guruforhire
    @Guruforhire

    anonymous: What I don’t understand is how it’s possible for a mobile phone, from outside the local network, to initiate a connection to, say, the baby monitor. I can see how the baby monitor could, say, post images on a third party site which could be accessed by the phone, but not how a direct outside-to-inside connection could be established. Can anybody explain this?

    Probably something like ICE

    • #93
  4. Chuck Enfield Inactive
    Chuck Enfield
    @ChuckEnfield

    So far this discussion has focused on the devices used for the attack, and the responsibilities of the owners and manufacturers.  I have no problem with this, but it overlooks two other key factors – network providers and the protocols used by the attacked.

    In theory, network providers have the ability to detect and mitigate DOS attacks.  Most large networks have systems in place to do this automatically, but for those to work the attack vector needs to employ unusual traffic patterns.  We use such system in our network to detect infected systems.  When we see hundreds or thousands of devices start talking to the same server in Russia that nobody was talking to yesterday, we investigate.  We’ll block malicious connections and notify device owners that they’re infected.  Software Defined Networks and cheaper/faster deep packet inspection, will make this more effective in the future, but it won’t solve the problem by itself.

    Unfortunately, these systems aren’t very good at detecting attacks against the DNS protocol.  Almost every device on the network uses DNS, so large volumes of traffic using that protocol are common.  Furthermore, the millions of DNS servers around the world act as unwitting accomplices in attacks against the relatively small numbers of authoritative servers that act as official sources of domain name information.  The nature of DNS is that it’s a very easy protocol to attack, which is why it’s the vector of choice for most DOS attacks.  A protocol revision that wasn’t so self-defeating would be a huge win in the fight against DOS attacks.  Of course, I don’t mean to suggest that’s easy.

    As is the case with any kind of defense, it’s best to defend in depth.  If every party behaves responsibly – protocol designs build robust protocols so that attacks can be identified by network operators, network operators monitor for and block attacks, and device manufacturers take reasonable care to prevent their devices from being weaponized – we might prevent the worst of these problems.

    You may wonder why I left the consumer out of this defense in depth strategy.  It’s because we’re quickly being removed from the equation.  Consumer knowledge about computing systems peaked in the late ’90’s when computers and broadband internet were common, but you needed to know something about them in order to keep them working.  Now most computing devices are fire and forget.  They do things all by themselves, and often you can’t control their behavior even if you want to.  People know how to make the device do what they want in a superficial sense, but have little idea what they’re actually doing.  This is an ongoing trend that gets worse by the month.  In an environment like that there’s not much consumers can contribute.

    • #94
  5. cirby Inactive
    cirby
    @cirby

    Eric Hines: Not so much. My DVR is hooked up to my TV, not to the Internet. My TV has no Internet capability beyond an ability to receive television programming via my cable box. My cable box has not even the capability to store TV guide information; it has to go to the head end to get that stuff. Neither my DVR nor my TV have the CPUs necessary for Internet interaction, either. Even the on-board ROMs are just that; they’re not PROMs or EPROMs.

    You mean you have to manually program it every time you want to record? You’re not selecting from an onscreen menu? Because that’s the only way that works. When your cable box talks to the headend to retrieve that TV Guide info, it’s talking to the Internet.

    If your DVR has an RF hookup talking to the cable headend at ALL, you’re open. You don’t have ROMs on most DVRs now anyway – they store that info on the hard drive.

    • #95
  6. Eric Hines Inactive
    Eric Hines
    @EricHines

    cirby: You mean you have to manually program it every time you want to record?

    Yup.  Why would I want anything else?

    I also carry around a cell phone, not a pocket computer that happens to run a call make/break app as an afterthought.

    Eric Hines

    • #96
  7. Spin Inactive
    Spin
    @Spin

    Eric Hines:

    cirby: You mean you have to manually program it every time you want to record?

    Yup. Why would I want anything else?

    I also carry around a cell phone, not a pocket computer that happens to run a call make/break app as an afterthought.

    Eric Hines

    Eric, why do you always sign your comments with your name, even though the comment has your name already?  Out of curiosity?

    • #97
  8. Spin Inactive
    Spin
    @Spin

    Chuck Enfield: The nature of DNS is that it’s a very easy protocol to attack, which is why it’s the vector of choice for most DOS attacks.

    The issue of course is not DNS, which is not a protocol, but the fact that DNS uses UDP, making it easy for hackers to send DNS queries and making them look like they came from you.  That is one issue, among many, that make DDoS attacks using DNS so prevalent.

     

    • #98
  9. Damocles Inactive
    Damocles
    @Damocles

    Claire Berlinski, Ed.: There is a public commons here; we all use it.

    That’s not correct.  I buy access from a private entity, and it’s possible you do as well. The entities we buy access from have peering arrangements whereby our data can travel between the private networks.

    Unlike radio communications, there’s not even a physically defined limitation as to the amount of traffic that can be carried.  If you want more bandwidth, there are tons of providers happy to sell you as much as you desire.

    • #99
  10. Matt Bartle Member
    Matt Bartle
    @MattBartle

    I would tell you a joke about UDP, but you probably wouldn’t get it.

    • #100
  11. Damocles Inactive
    Damocles
    @Damocles

    Claire Berlinski, Ed.: Their negligence took Ricochet down for a few minutes: That’s a violation of our property rights.

    If you’re going to go down this route, it was Ricochet’s own negligence in choosing a DNS provider who did not properly defend themselves against a DDOS attack.

    If Ricochet had (for example) chosen Amazon’s Route 53 service you would have been unaffected.  Same for the other DYN customers.

    But that’s the difficulty of working in a relatively new and highly complex environment such as the Internet.  You will recall in the 90’s the problem was people hooking up unprotected PCs and having them taken over by mail bots.  That was fixed (by the private sector), and vulnerabilities such as IOT DDOS attacks will be fixed as well.

    At least three well-funded players in the home automation space (Apple, Google, Amazon) are putting immense resources into this problem; I have more faith that they will come up with solutions faster and more effectively than the U.S. government.

    • #101
  12. Chuck Enfield Inactive
    Chuck Enfield
    @ChuckEnfield

    Spin:

    Chuck Enfield: The nature of DNS is that it’s a very easy protocol to attack, which is why it’s the vector of choice for most DOS attacks.

    The issue of course is not DNS, which is not a protocol…

    RFC1035 repeatedly refers to the DNS protocol.

    …but the fact that DNS uses UDP, making it easy for hackers to send DNS queries and making them look like they came from you. That is one issue, among many, that make DDoS attacks using DNS so prevalent.

    UDP makes DNS more vulnerable, but if we began using TCP tomorrow it would still be vulnerable to application layer flooding.  Sure, you need 4x to 6x more bots, but bots are easy to come by.

     

     

    • #102
  13. Chuck Enfield Inactive
    Chuck Enfield
    @ChuckEnfield

    Damocles: If Ricochet had (for example) chosen Amazon’s Route 53 service you would have been unaffected. Same for the other DYN customers.

    I’m suspicious of claims that Route 53 DNS is invulnerable to DDoS.  No doubt it’s state of the art, but it’s just a matter of time.

    Oh, and your whole argument is akin to saying that if you use the wrong door lock you deserve to be robbed.

    • #103
  14. Dave S. Member
    Dave S.
    @DaveS

    @claire as a network admin, will add my thoughts.  To start, and I almost started my own post with this, conservative and libertarians need to get out in front of this as quick as they can.  I am on the NANOG (North American Network Operators Group) mailing-list and this came in Monday:

    “P.S.  To all of you Ayn Rand devotees out there who still vociferously argue that it’s nobody else’s business how you monitor or police your “private” networks, and who still refuse to take even minimalist steps (like BCP 38), congratulations.  Via your inaction and self-centered intransigence you have today moved us all one step closer to the day when the relevant decisions will be taken out of your hands.  You are succeding brilliantly at creating the exact thing that you most abhor, i.e. government control.”

    I won’t get in to it on the merits, but just want to show shed some light on the climate.  Like most arguments from the left, his solution, BCP38, has nothing to do with this particular attack.

    Will try to keep it short:
    -Go after the manufacturers via tort law
    -Many will be fly by night and disappear before being held accountable
    -Hold end-users accountable.  I don’t want to see a Fed. agency dishing out fines but if a reverse-class action suit dished out lots of $20 fees to consumers, I think it would help incentivize better network management

    • #104
  15. Eric Hines Inactive
    Eric Hines
    @EricHines

    Spin:

    Eric Hines:

    cirby: You mean you have to manually program it every time you want to record?

    Yup. Why would I want anything else?

    I also carry around a cell phone, not a pocket computer that happens to run a call make/break app as an afterthought.

    Eric Hines

    Eric, why do you always sign your comments with your name, even though the comment has your name already? Out of curiosity?

    It’s a habit I picked up early on when I started blogging.  I’ve seen no reason to change away from it.

    Eric Hines

    • #105
  16. Eric Hines Inactive
    Eric Hines
    @EricHines

    Matt Bartle: I would tell you a joke about UDP, but you probably wouldn’t get it.

    And you wouldn’t care.

    Eric Hines

    • #106
  17. Eric Hines Inactive
    Eric Hines
    @EricHines

    Damocles: If you’re going to go down this route, it was Ricochet’s own negligence in choosing a DNS provider who did not properly defend themselves against a DDOS attack.

    No, down this route it’s the negligence of the end users who freely chose to put their unprotected IoThings onto the Internet.

    Eric Hines

    • #107
  18. Dave S. Member
    Dave S.
    @DaveS

    Continued:
    What I think none of us here want to see is government regulation grinding progress to a halt.  The most dangerous place for this to happen is within the telecom infrastructure itself.  There are “common-sense” steps that I think most ISPs would be fine with seeing as laws, but we all know it doesn’t stop there.  Aside from the slippery slope, attackers will always find a new attack vector.

    If someone breaks in to my house and falls on the cactus I put under the window, I don’t think I should be responsible.  But, given the current climate, I don’t see an issue with holding consumers partially responsible.

    • #108
  19. Eric Hines Inactive
    Eric Hines
    @EricHines

    Dave S.: -Go after the manufacturers via tort law

    -Hold end-users accountable.

    I disagree with going after the manufacturers other than for their negligence.  In the present case, they’re just selling into the market what buyers want to buy; the manufacturers’ stuff is working as advertised. This also is the road down which auto manufacturers will be held liable for a driver’s decision to drive carelessly or drunkenly; it’s already the road down which the Left is trying to hold gun manufacturers liable because someone committed a crime using a gun.

    The latter solution–holding end-users accountable–is absolutely correct.  Change the incentive of the actors by holding them accountable for the outcomes of their behaviors; don’t punish someone else over an end user’s misbehavior.

    Eric Hines

    • #109
  20. Dave S. Member
    Dave S.
    @DaveS

    Continued:

    What you can do to help, lots of great suggestions from others!

    -YES, change the password!
    -BUT, that isn’t always enough, some devices have a different telnet/ssh password that isn’t the same as the GUI you use to login and sometimes, can’t be changed by you.
    -Yup, upnp can make your devices internet reachable without manually created NATs or firewall rules
    -Look in to vulnerability scanners, like nessus and nmap

    For more advanced users, I would recommend setting up static DHCP reservations for known devices.  Specifically deny outbound access for everything except what you expect to talk to the internet (laptop, desktop, etc).  Or, set up specific denies for suspect devices, fridge, IP camera etc.

    If you want to look at your webcamera from the internet, configure a VPN.  Some of this is complicated but it isn’t something anyone here couldn’t learn to do in an afternoon.  For a firewall, I personally recommend pfSense.  You can run it on an old computer you don’t use anymore and it has excellent documentation.

    • #110
  21. Chuck Enfield Inactive
    Chuck Enfield
    @ChuckEnfield

    Eric Hines: The latter solution–holding end-users accountable–is absolutely correct. Change the incentive of the actors by holding them accountable for the outcomes of their behaviors; don’t punish someone else over an end user’s misbehavior.

    Manufacturers produce products that few consumers are equipped to understand and design them with major flaws that makes them unnecessarily vulnerable to malicious exploits and you conclude we should blame the consumer.  Sorry, not buying it, and neither will the courts.

    • #111
  22. Dave S. Member
    Dave S.
    @DaveS

    Eric Hines:

    I disagree with going after the manufacturers other than for their negligence. In the present case, they’re just selling into the market what buyers want to buy; the manufacturers’ stuff is working as advertised.

    A lot of times, unless you are a technical expert in the field, you have no way of knowing the devices aren’t working as advertised.

    “this Focscam camera was one of several newer models the company makes that comes with peer-to-peer networking capabilities baked in. This fact is not exactly spelled out for the user (although some of the models listed do say “P2P” in the product name, others do not).”

    https://krebsonsecurity.com/2016/02/this-is-why-people-fear-the-internet-of-things/

    If a manufacturer built a car whose brakes didn’t work under specific circumstances, which the average person wouldn’t expect, they should be held liable.

    To be clear, I am not saying they should regulate those devices in a mother-may-I fashion.  Instead, irresponsible manufacturers should be held responsible for wreaking havoc.

    I assume most of these IoT devices aren’t vulnerable for a meaningful reason or in a way that the average person would expect them to be based on their advertising.

    If a hacker needs to engage in a sophisticated cryptograhpy attack to get in to a device, that’s one thing.  If all they have to do is port-scan port 23 and login with admin/admin, that is another.

     

    • #112
  23. Damocles Inactive
    Damocles
    @Damocles

    Chuck Enfield:

    Damocles: If Ricochet had (for example) chosen Amazon’s Route 53 service you would have been unaffected. Same for the other DYN customers.

    I’m suspicious of claims that Route 53 DNS is invulnerable to DDoS. No doubt it’s state of the art, but it’s just a matter of time.

    Oh, and your whole argument is akin to saying that if you use the wrong door lock you deserve to be robbed.

    I’m not claiming it’s invulnerable, just that it survived where dyn didn’t.  There’s an article on Hacker News that talked about why that was, but it boils down to AWS being a big distributed network and therefore more sturdy in the face of distributed attacks.

    My whole argument is that it’s silly to start talking about introducing a government regulatory framework for this issues.

    Obligatory Conservatism:  Claire, you’re down for 3 hours and that makes you want the government to start with the enforcement?

     

    • #113
  24. Damocles Inactive
    Damocles
    @Damocles

    Eric Hines:The latter solution–holding end-users accountable–is absolutely correct. Change the incentive of the actors by holding them accountable for the outcomes of their behaviors; don’t punish someone else over an end user’s misbehavior.

    What are you going to do?  Start suing Granny coz she had a bad password rotation scheme or didn’t keep her firmware patched?

    • #114
  25. Dave S. Member
    Dave S.
    @DaveS

    Damocles:

    Eric Hines:The latter solution–holding end-users accountable–is absolutely correct. Change the incentive of the actors by holding them accountable for the outcomes of their behaviors; don’t punish someone else over an end user’s misbehavior.

    What are you going to do? Start suing Granny coz she had a bad password rotation scheme or didn’t keep her firmware patched?

    If granny’s negligence caused my company a million dollar outage, I wouldn’t lose sleep over a small fine.

    Regarding route 53, Dyn is a distributed network too.  As I said in one of the other threads, in part, Dyn’s business is preventing this from happening to their customers because they can provide the service on a better scale to multiple customers than each of the customers could do individually.  Yes, Amazon probably has a more robust system but I have seen no evidence that Dyn was at fault here.  They were targeted specifically (based on reports I have seen).

    • #115
  26. Damocles Inactive
    Damocles
    @Damocles

    Dave S.:

    Regarding route 53, Dyn is a distributed network too. As I said in one of the other threads, in part, Dyn’s business is preventing this from happening to their customers because they can provide the service on a better scale to multiple customers than each of the customers could do individually. Yes, Amazon probably has a more robust system but I have seen no evidence that Dyn was at fault here. They were targeted specifically (based on reports I have seen).

    For the record, I agree with this.  I’m careful to protect all my wireless and IOT devices, but that was because I didn’t want them attacked in the traditional manner.  I certainly didn’t see the DDOS scenario coming!

    • #116
  27. Damocles Inactive
    Damocles
    @Damocles

    Dave S.:If granny’s negligence caused my company a million dollar outage, I wouldn’t lose sleep over a small fine.

     

    This is the part I’m puzzling over.  I’m just failing to see how something like this would work at all.  You’re going to sue all 100,000 people who bought a defective piece of equipment?

    • #117
  28. Dave S. Member
    Dave S.
    @DaveS

    Damocles:

    Dave S.:If granny’s negligence caused my company a million dollar outage, I wouldn’t lose sleep over a small fine.

    This is the part I’m puzzling over. I’m just failing to see how something like this would work at all. You’re going to sue all 100,000 people who bought a defective piece of equipment?

    The fault needs to either lie with the user or with the manufacturer, or a mixture*.  I understand it sounds implausible, to me it is just preferable to some of the alternatives, such as requiring a rubber-stamp from the “Bureau of Internet Regulation” as the cost for selling an internet capable device.

    *Edit, obviously with the actual criminal as well…

    • #118
  29. Eric Hines Inactive
    Eric Hines
    @EricHines

    Damocles:

    Eric Hines:The latter solution–holding end-users accountable–is absolutely correct. Change the incentive of the actors by holding them accountable for the outcomes of their behaviors; don’t punish someone else over an end user’s misbehavior.

    What are you going to do? Start suing Granny coz she had a bad password rotation scheme or didn’t keep her firmware patched?

    You want to let Granny off the hook coz she didn’t know how to drive her car well, but she drove it anyway and caused an accident?

    Eric Hines

    • #119
  30. Damocles Inactive
    Damocles
    @Damocles

    Eric Hines:

    Damocles:

    Eric Hines:The latter solution–holding end-users accountable–is absolutely correct. Change the incentive of the actors by holding them accountable for the outcomes of their behaviors; don’t punish someone else over an end user’s misbehavior.

    What are you going to do? Start suing Granny coz she had a bad password rotation scheme or didn’t keep her firmware patched?

    You want to let Granny off the hook coz she didn’t know how to drive her car well, but she drove it anyway and caused an accident?

    Eric Hines

    That’s funny, but I’m trying to get a straight answer out of you.  Are you really thinking of lawsuits if someone doesn’t keep their equipment patched?

    • #120
Become a member to join the conversation. Or sign in if you're already a member.