posted by Bryon Moyer
While the Internet of Things (IoT) is full of promise, there’s one word that summarizes all that people fear about it: security.
We got to hear a bit about that at a session dedicated to the topic at the recent Internet of Things Engineering Summit co-conference at EE Live. Presented by consultant George Neville-Neil, it wasn’t about technology per se; it was about our state of mind.
Most of us believe it’s important to keep intruders out. His main takeaway: assume they will get in. Because, eventually, they will. Building sturdy walls is good and important, but planning for what happens next is also important.
What caught my ear in particular is one of the less-obvious possible consequences of not minding the store properly: a “consent decree.” I’ve heard the term in a generic sense, but it’s not obvious what the implications are if you’ve never had one (which I haven’t, which is why I asked). Apparently, if you’ve been careless with security, a consent decree allows the Federal Trade Commission (FTC) to become your overseer, getting all up in your business and stepping in when they want. Most of all, the documentation required during the term of the decree sounds particularly onerous. So… avoid this.
That aside, the following are my attempt to summarize his supporting recommendations (“attempt” because I was writing furiously to keep up):
- Shrink the “attack surface” (i.e., expose less). Meaning, drivers, daemons, features, debug access, web servers, data loggers, etc.
- Separate out “concerns.” I.e., no processes with root access or super-control; restrict access to data. Nothing gets access to anything irrelevant.
- “Defense in Depth” – rings of security. What happens when the first wall is breached?
- Provide only those features really needed. (OK, marketing will have a fun time with this. You know the drill:
- Marketing: Here are the features we need in the next release.
- Engineering: You can’t have them all; which ones do you really need?
- Marketing: We need them all. We didn’t bother asking for the nice-to-haves.
- Engineering: Well, which of these do you need least?
In other words, marketing probably already thinks they’re getting less than the really-needed features.)
- Be conservative in what data you accept and send.
- Review your code.
- Review other people’s code – especially when incorporating someone else’s code or IP. Do an internet search for the package along with words like “crash” or swear words to find red flags.
- Use “sandboxing” to provide isolation.
- Use automation to test and analyze your code. Oh, and don’t forget to look at the results.
- And, the bottom line, “Plan for Compromise.”
And sleep with one eye open. Because They’re coming, you know…
posted by Bryon Moyer
I was talking to Atmel the other day – they had announced the release of their ATPL230 power line communication (PLC) chip, which was filling in of one of the squares in the strategy that we reported on some months ago. PLC is one of the ways in which smart meters can communicate back with the utility. But when you look at Atmel’s overall communication strategy for smart energy devices, there are other options, including Zigbee, but notably not including WiFi or Bluetooth.
This may look simply like yet another battle in the wireless world, but there’s more to the story than that. First, the inclusion of Zigbee has less to do with technology than you might think. In fact, it’s partly a money story – and it almost sounds like a strategy determined by tactical dollars. As Atmel describes it, some years ago, stimulus dollars were available. Without going into the details, putting Zigbee into smart meters was a “future-proofing” step that made those stimulus funds available. Now the Department of Energy recommends (although doesn’t require, since it’s not a safety issue) Zigbee for “smart energy” home use.
But the other thing that occurred to me is that “smart energy” and “smart homes,” which would appear to be versions of the same thing, have more nuance in them as well. “Smart” tends to mean “connected,” and the smart home has lots of connected items in it. Thermostats are frequently cited as examples, but so are refrigerators and dryers and door locks.
But there are two things going on here. “Smart energy” tends to refer to energy-related devices that communicate on the utility’s network. And they do so via protocols like PLC and Zigbee. The kinds of devices that qualify as “smart energy” obviously include smart meters and other equipment dedicated to the efficient delivery of electrical energy.
But utilities also want to be able to reach into homes and factories and tinker with usage to optimize energy consumption when supplies are tight. That clearly means turning down the thermostat, but it could also mean communication with appliances that consume lots of energy, and whose use involves options, like your clothes dryer.
Would the utility actually try to reach in and prevent you from drying your clothes when energy use peaks? Perhaps not. Might a dryer manufacturer elect to include a feature that allows the utility to display current electricity pricing in an era of demand-based pricing so that you can decide whether to dry now or later? Possibly.
But there’s another aspect of the smart home, and that’s the ability to connect items to the cloud and to smartphones or computers. Yup, the Internet of Things (IoT). This is a completely separate network from the one the utilities use for smart energy. And they tend to use WiFi or Bluetooth Smart because that’s what’s in phones and computers.
So, in theory, a thermostat following the DoE-recommended approach could communicate with the utility via Zigbee and with the IoT via WiFi. The dryer could communicate via Zigbee to receive electric pricing – or it’s possible – even likely – that the utilities would also place that pricing information in the Cloud, accessed using WiFi.
According to Atmel, much of the smart-meter Zigbee capability out there now via is unused within the home. It’s clearly available for connecting outwards towards the utility, but to access nodes inside the home, the meter could also use WiFi or Bluetooth. You could even argue that it would be much more efficient to do it that way, since the smart meter would be the single transition point between the utility network and the home/IoT network. The alternative would be to require numerous devices in the house – thermostats, dryers, anything that may need to talk to the utility – to have both radios so that they can talk both to the utilities and the IoT.
All of this is, of course, still in play, so there’s no one “right way” to implement this. And yes, I keep coming back to this wireless question, not so much because I have a preferred “winner,” but because it seems to be a confusing space, and I look for those occasional refreshing moments of clarity.
posted by Bryon Moyer
As companies rush out to take advantage of the Internet of Things (IoT), platforms are popping up all over. We looked at some of the companies participating a while back, trying to impose some structure on the chaos, but the thing is, everyone has a different idea of what a “platform” is. The common denominator seems to be that some aspect of the IoT is abstracted away, making it easier and cheaper to get up and running. Which is a good thing. The confusing part is which platforms contain which elements.
At EE Live, I got a chance to talk with Xively (a company that did appear briefly in the prior piece). They offer a platform that focuses on communication, which I knew, but I didn’t have a good sense of what that meant. Even in the early discussion, it was tough to calibrate – there are a bazillion buzzwords coined by the IoT, and if you’re not smack-dab in the middle of it, it can be impenetrable. Even once you get calibrated, the buzzwords are overloaded, so you can still think you understand something when, in fact, you don’t.
I think Xively provides a good example of taking the generalities – a “platform” – down to more specifics. In my mind, there are three levels you can work at when setting up communication between a Thing and the Cloud.
At the most basic level, you have the formal communications protocols – WiFi, Ethernet, TCP/IP, etc. The good news about those is that they’re well established and there are lots of solutions available.
The challenge is that, to use them, you typically need lots of fiddley code to establish a connection, get sessions up and running, and then do something useful with the data. Yes, libraries and stacks may be available, but, given the number of people trying to make this part easier, it’s pretty clear that working at this level can be a pain in the tuckus for the uninitiated.
So the next level up is where you can abstract that away: by providing a generic data handling layer. Some – like Xively – might call this a “channel.” At this level, you have higher-level commands that establish connections, wrapping all of the detail required at the protocol level. It’s more of a one-step-and-you’re-on kind of thing. Data is unformatted and has no semantics – it’s just data.
You can take things one level higher and provide business objects. This is more than data: it’s data in a context; it’s semantic data. At the generic level, a payload may contain the temperature setting of a thermostat or an image from a surveillance camera. At the business object level, only a thermostat object can have the temperature setting and only a camera object can have the image.
As a programmer, you program at the business object level. Depending on your resources, you might not do literal object-oriented programming, but presumably you think at the level of a business object. The question is, when communicating with the Cloud, at which level do you inject your data?
- If all you have is the protocol, then you have data marshalling and all kinds of details to package up your message, and then you have to unpack it on the other side.
- If you have the generic data level, then you take your data and ship it to the other side in a message of some sort. The other side has to know what’s coming and what to do with it – after all, it’s just generic data when it arrives. But protocol details are replaced with simple “read” and “write” types of concepts.
- If you actually have formalized business objects available, then you simply ship some semantic element and the other side automatically knows what it is and where it goes.
In this specific case, Xively provides the generic data “channel.” There are no semantics, but the messy protocol details are abstracted away.
Note that this doesn’t mean that Xively provides the entire stack up to and including this generic data level. You implement your own protocol stack (or someone provides their version of a platform that includes this), and you then have it link to the Xively layer. This, of course, implies ecosystem. As a case in point, LogMeIn, a full-up end-to-end communication solution, uses the Xively platform, and they just announced that they’re joining TI’s IoT ecosystem.
The high-level lesson learned is that, when someone offers up a platform, make sure you understand in great detail what’s in the platform and what’s not. It’s not so much that “the platform with the most stuff wins” – maybe, maybe not – but it’s about not being surprised later.