Skip to content ↓ | Skip to navigation ↓

 

Last week, the Internet fell over itself to report on a botnet allegedly comprised of 100,000 smart devices. Things. The Internet of Things had finally attacked!

While it’s inarguable that, at some point, these devices will be compromised, corrupted and otherwise made to serve the pernicious purposes of attackers, deeper technical analysis points out that there’s plenty of reason to be skeptical about the claim.

Now, I’m not going to comment on whether the analysis definitively answers the question regarding whether or not our “things” are bound to some evil purpose thanks to lax security practicesthat’s not as relevant as the point made during the analysis that IP-based identification is virtually worthless.

Okay, they didn’t go that far but I will.

As the author points out, the use of NAT by Internet routers obfuscates the identification of specific devices. My Fitbit, my phone, my TV and my Roku all appear  based on IP address  to be the same device thanks to the wonders (or evils, depending on which side of that debate you might be on) of NAT. It is rare to find a device natively on the Internet; its IP address is bound to be local and private, and translated to a public one shared by many other devices.

Add to that the reality that, in general, no consumer is paying the extra bucks per month for a personal, static all-their-own IP address and that pretty much guarantees that IP addresses are not an authoritative source of identity.

Certainly, you can dig deeper. Fingerprinting is not a new concept and in fact is often used to great advantage by fraud detection systems by financial institutions looking to prevent hijacked end-user devices from being used to perpetrate fraud. TCP fingerprinting has been used for ages (in Internet years) to identify the “real” server behind a web site.

Browser fingerprinting, though relatively new (in real years) has been shown to be fairly accurate; able to determine the “uniqueness” of any given browser based on hundreds of different variables available. But it is not authoritative, as it can only really identify an environment, and then only in certain situations (such as access via a JavaScript enabled browser). This option is not really viable for native mobile (or thing) applications which do not rely on browsers or allow the ability to arbitrarily execute client-side scripts.

Hence, we are, at this point in the maturity (which is to say not very far) of the Internet of Things, in need of a way to uniquely identify individual hosts. Whether that be a person or a refrigerator, a television or a Point-of-Sale (POS) system, a sensor or a car. And not just any refrigerator, television or car, but my refrigerator. My television and my car. Because it isn’t just about the thing, it’s about who owns the thing; because the owner is the one with the privacy concerns. Things are like honey badgers; they don’t care. But we do.

So, it can’t be just an IP address, and it also can’t be something that requires human interaction. These are things, after all, not people. And I’m going to go out on a limb and predict that if your refrigerator requires a token for access every time you go for your favorite drink, it’s not going to be in your kitchen very long. Unless you have teenagers, of course. That might change the equation a bit.

So, you can’t rely on IP, at least not alone. We’re going to need either systems or solutions that provide each and every device with its own personal, private, unique identity and a way to associate it with an owner.

This shift from IP-based security to ID-based security is going to cause ripples across every market because it will have to. Systems that traditionally rely on inspecting packets or base policies on IPs and IP ranges will be virtually useless in a world where IP is no longer the focus. Being able to block a device from a consumer IP address means that you’re denying access to the user, too. And if part of the reason you’re blocking a device is because it needs a patch, how can they manage it if you won’t let them interact with the management application from that IP address?

IP-based security and identity and access management are necessarily nearing the end of their useful lifecycle. It’s time to start seriously looking at ID and context and other means of protecting things and the applications they interact with before there really are 100,000 refrigerators engaged in a DDoS attack on my coffee maker.

 

Lori_MacVittieAbout the Author: Lori MacVittie is responsible for evangelism across F5’s entire portfolio including a broad set of network and application security solutions. Prior to joining F5, MacVittie was an award-winning technology editor at Network Computing Magazine with a focus on applications and security. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.

Editor’s Note: The opinions expressed in this and other guest author articles are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.

Hacking Point of Sale
  • jayk56

    Thanks for this interesting read on IP based and ID based securities, Lori. Would you happen to have some articles/books that talk about these concepts more deeply? If you'd be willing to share some of your insight about these resources it would be greatly appreciated!

    Thanks,
    Jay Kerschner

  • David Dickinson

    On the one hand, you acknowledge that the owners of things have an interest in maintaining their privacy. You also acknowledge that NAT makes communicating with hosts possible without a unique identifier that's accessible on the wider internet. Yet you emphasize that we now "need of a way to uniquely identify individual hosts".

    I completely disagree. First of all, devices connected to networks are uniquely identified by their MAC addresses, not by their IP addresses. IP addresses are simply intermediate identifiers used for routing communications to and from those devices. In addition, no device that communicates with another device across the internet needs to know the (usually) unique MAC address of its correspondent. All that those endpoint devices need are a symbolic name.

    The only possible entities who would have an interest in locating and uniquely identifying hosts are their owners and the service providers to which they subscribe in pursuit of using the "things" that they own. "Unique identification" beyond the means that are currently available is absolutely unnecessary.

    Unique identification is provided by many other means that work in conjunction with IP addresses, and those means are managed by machines. For instance, I have an account with XYZ which I access using various forms of authentication. My device communicates with XYZ using my account credentials or, possibly, different ones that are attached to my account. XYZ may store reference that "thing's" MAC address, but it doesn't have to. It would be more efficient to use dynamic DNS. If XYZ needs to poll my device, the device can tell XYZ when my house's dynamic IP address changes, or XYZ can call the device using dynamic DNS. My local router handles communication within my house.

    I never need to know the route to my device, and all that XYZ needs to know is the domain name of my house and the name of my device on my local network. My router handles everything from there.

    Identification can already be achieved without knowing the IP address of a specific host. Dynamic DNS services, especially those operated by service providers we contract with to help us manage our "things", can be updated by those things so that we access them from outside of the local networks to which they are attached.

    DNS provides all the identification that is needed. It's why DNS was invented. Humans don't need to know the IP addresses of their devices, and — as long as they can remember the names of their service providers and their account credentials — they don't even have to remember the FQDNs of their devices.