Atif Chaughtai, Axway’s Director of Healthcare Solutions, on the hot topics at HIMSS 2014.
By Dave Brunswick, Head of Technology Strategy, Security Solutions Group, Axway
Everyone is talking about the Internet of Things and the potential it has for changing the dynamics of our everyday lives at home and at work. We’ve seen the first manifestations of this in the consumer arena with the introduction of connected home automation products, smart metering, and connected cars (to name just a few), and this trend is going to continue to explode over the next couple of years. And of course, behind any connected thing is the underlying infrastructure to drive it — the “Thingfrastructure,” if you like. If your smartphone is going to be able to control your car, then the two have to be connected somehow, and you want to make sure that some random stranger can’t hijack that connection. Equally, if you are collecting information from connected devices for customer billing purposes, you want to be sure that there is no way to spoof the connected device and falsify that information.
So authentication, authorization, and security are important. But what does that really mean?
In the last couple of months, I joined the IoT revolution by connecting my hot tub to the internet; now I can control it via a mobile app. On the road back from the ski resort, I can turn the heat on so the water is at just the perfect temperature to soak my weary muscles in when I get home. Of course, this is a trivial example, but it does help illustrate some of the key things we have to think about in this area.
Given all of this, here are the five best reasons to secure access to the Thingfrastructure:
1. You only want authorized people to access your things. I don’t want random folks turning on my hot tub and running up my utility bills. Even more importantly, imagine my garage-door remote — I certainly don’t want to make that available to just anyone!
2. You need to know who is accessing your things and when. Even with the best intentions, people mess up. You can only take appropriate action if you monitor who is doing what. (E.g., “Okay, young lady! You left the hot tub on again! I’m withdrawing your access!”)
3. Permission to have access to a thing should be precisely that — permission. The ability to turn my hot tub on or off should not imply or require access to anything other than the hot tub itself — and I should certainly make sure that I have the right degree of isolation between it and the internet, and between it and other things on my network. It should not be a vector for accessing anything else, and the interface it presents should only allow those permitted functions. If I have guests, maybe I want to grant them access to my hot tub, but that’s not the same thing as letting them access the rest of my home network and personal files.
4. How a thing works is irrelevant to the people interacting with it. Knowing how my hot tub controller is implemented should not be relevant to controlling it. Indeed, there should be isolation between the back-end implementation and the external interfaces, and the transition across this isolation layer should be secure and monitored. (See items 1 and 2 above.)
5. Protect against accidental as well as deliberate threats. The four previous points give me a pretty good handle on mitigation of deliberate threats, but don’t necessarily protect me against accidental problems. With an internet-exposed API, it’s quite possible that an authorized user might decide to develop a new app — for example, using map and GPS data to predict arrival time at home, and turning on the hot tub at the optimal time to be up to temperature on arrival. If this app is buggy, it could result in rapid toggling of the hot tub heater and pump, leading to an expensive repair bill. This is a whole new level of denial of service! Securing access should also mean protecting your things.
Who would’ve thought getting my hot tub online would give me so much to think about?