Openness in the Internet of Things
Just because machines can talk to one another doesn't mean they should, warns Steve Cassidy in his latest column...
You will almost certainly have heard of the Raspberry Pi. It's the thing that's supposed to be a child's toy, or at least, an entry into serious computing for children. You probably haven't heard of it's tiny cousin, the mbed board (geddit?), which ARM put out as its much more serious-minded micro device controller for incorporation into all manner of systems and structures as part of the Internet of Things the idea that soon everything we use or touch or buy will be, in some microscopic way, smart.
The serious-minded ARM board has some fractionally less serious parts, like a tiny fine-grained backlit display and, just below it, a petite metallic encrustation helpfully identified by miniscule lettering on the motherboard as a joystick. This is assumed to be the neatest way to control a tiny computer in places where keyboards and screens might not be easily presentable, like at the top of a freighter's mast or deep inside the controls of a monstrous windfarm impeller housing.
What really attracted my attention to the little boards on show at Red Hat summit wasn't the joystick bit, honest: Nor was it what the team on the stand wanted to talk about which was a Cloud based board development and control system, with a browser-presented "compile" button and the ability to push the updated program down to the tiny little computer nestling at the end of some Ethernet, somewhere. What I was noticing most was the IP address of the boards, displayed in teeny tiny letters on their little flat panels. It was a private address range (10.40.something.something) which means that these boards were hidden away from the internet.
So it had to be a pull relationship, not a push. Every so often those tiny computers wake up and look at their update servers.
This whole subject came up again, in the presentation by Padmasree Warrior, who gave the classic rabble-rousing "everything's changing and we are here to help" style of speech appropriate to her position as head of strategy at Cisco. She wasn't short on rhetorical ambition, wanting to raise the game from "the Internet of things" to "the Internet of everything".
I hope that hardened network guys are ahead of me here, staring at their tablets in horror at the very idea that everything on earth might one day even be given the glimmer of a possibility of chattering away to everything else, without fear or favour. I pursued this a bit further with the guy from ARM, asking him if he had yet encountered a security problem, either with direct attacks on his equipment or with the attitudes of war-scarred network admins seeking to protect themselves against excessive openness of a different kind.
He was, I have to say, a little stumped by the question, and we could well have been falling over nothing more complex than competing uses of the word "open". Devices have to talk, that's what they are for. Openness produces emergent properties, uses and conclusions you didn't realise would be available and for someone heavily invested in the open invitation aspect of Open Source development, the whole information-wants-to-be-free mantra sits behind a lot of their thinking.
I suspect that the solution to this "mass of things" issue was actually within line of sight of his stand. Just across the aisle was the guy from Brocade; an old-school Storage business who has decided that the best way to survive the explosive churning of hot buzzwords, user uncertainty and architectural shift in the market is to move more or less directly against the whole "open" philosophy. One of Brocade's best party tricks is that a network of Brocade storage controllers will talk amongst themselves across reasonably standard links, using entirely proprietary and non-standard protocols to chat away. To the administrator of the system, and at least initially to servers wanting to get to the disks they control, the Brocades are all perfectly well-behaved IPv4 target devices. They put up web management pages, they take instructions but they don't use IP when talking to each other.
This is a modern trend. Cloudflare, the hack-attack recovery company, uses non-standard IP to bypass the otherwise-overwhelming load of a DDoS attack from tens or hundreds of thousands of compromised PCs. Picking and choosing the way you use standards in your Open system is no longer an unforgivable sin, reserved for the lazy or the avaricious: it is rapidly becoming a piece of sane self-preservation.
This, it seems to me, is going to have to be an absolute cornerstone of the Internet of Things. Just because your CCTV cameras speak the same network protocol and show you the same type of web page interface as your CNC Milling machine, baking oven or sewage tank, does not automatically imply that each of these categories of machinery should be able to see, converse, control or destroy one another. Many Internets of Things, not one.
In fact, after trawling around the stands at Red Hat Summit it rapidly became clear that the collection of standards which make up "The Internet" down in the traffic-management, packet-steering level are pretty much under attack from all sides. Everyone's got a product that sidesteps inefficiencies or woefully nave attitudes to public data transports, squeezing more performance or more security out of the basic IPv4 world that hackers and data-loggers frolic in with such criminal abandon.
I only hope that one of our roles as the Internet of Things gets more widespread, is that as old IT greybeards we can apply some simple security tests and propose the odd neat fix for gaping security holes in networks of smart, connected sensors. After all, a network of zombie things would not be good for anybody.
Managing security risk and compliance in a challenging landscape
How key technology partners grow with your organisationDownload now
Evaluate your order-to-cash process
15 recommended metrics to benchmark your O2C operationsDownload now
AI 360: Hold, fold, or double down?
How AI can benefit your businessDownload now
Getting started with Azure Red Hat OpenShift
A developer’s guide to improving application building and deployment capabilitiesDownload now