The Internet of Things used to be a topic involving more questions than answers. How should we organize the network? What type of sensors? What type of communication? How to store data? Where to store data? Cloud or fog or both?

While I’m not going to suggest that all of those questions have been answered to everyone’s satisfaction (actually, they have been, many different ways, but there’s obviously not universal agreement on those answers), most questions have been muted as compared to the one big remaining question still being shouted from the rooftops: “How do we secure the IoT?” (OK, there are probably some still asking, “Why do I need to secure my IoT?” but we’re not going to tackle that today.)

We’ve spent oodles of pages on the topic in the past, but that was more about background and basics. Specific solutions are still rolling out, and, often, they deal not with grand solutions to everything, but rather with specific use cases that have their own needs. Such will be today’s discussion.

Because the IoT as a notion is so new, much focus is placed on designing new equipment. Might be edge nodes, brokers, local servers, cloud servers… anything that’s going to participate in the grand IoT party. A security discussion for such devices then takes on a number of guises.

• For edge devices, there are obvious questions about how many computing resources are available. Can a simple, less-than-$100 unit (retail) handle the complexities of public key exchange, certificates, and all the other bureaucracy that good security claims to require?
• Middle-of-the-IoT devices (hubs, brokers, set-top boxes, local servers) end up getting some of the burden of deciding who else gets to play on the network. They have roles as gatekeepers, interrogating and challenging would-be entrants to the network. Is that latest sensor node groupie to arrive at the stage door on the VIP list, or is it crashing the party?
• If we’re talking about a cloud server, then it’s assumed to have good security built-in. But does it? Seems to be a lot of those getting hacked lately. And is response time quick enough for the cloud server to act as the network gatekeeper?

Ultimately, the answers to these questions, determined network-by-network, result in security stacks in all those boxes, with each box having a stack that’s suitable for the resources available. Some of the stack might even be provided by hardware, since there are chips that can handle some of the gnarlier algorithmic stuff and protect keys far better and faster than software can. And so new systems come out that are secure. (Until someone proves them not.)

Of course, specifics are going to vary by application. Consumer-oriented devices have to last as long as, oh, until the new pretty powder-blue version comes out. Or perhaps until someone comes up with the brilliant idea to eliminate, say, a major audio I/O port because who needs to pay a few tens of dollars or less for audio earpieces when you can pay hundreds instead? Everyone will flock to that! So the solution to the prior model won’t need to last.

The industrial IoT (IIoT), on the other hand, is a rather different beast. If you want to annoy the manager of a manufacturing facility (your own or a foundry), just tell them that, for the next thing they need to build, they’re going to have to buy new equipment. That’s not how manufacturers like to do things. They like to buy equipment that’s going to allow plenty of time to depreciate, and then hopefully a lot longer after that, when the equipment is bought and paid for.

In addition to the costs involved in new capital equipment, it’s tough to argue for changes to the line – even if it involves no new machinery. Manufacturing lines have one job: manufacturing. Downtime for maintenance and upgrades are par for the course, but minimizing it is a high priority. A down line is a line not paying for itself. Making too many changes at once also raises the risk of some unanticipated side effect keeping the line down for longer than budgeted. And nobody wants that.

Working the IoT into such a factory may not come as a requirement of some specific new product that’s going to be built, but it is a change with real implications to capital equipment. No one is going to throw everything out and replace it with new; existing equipment, and its automation, will continue as always, even if designed back in the ‘80s. “If it ain’t broke, then we ain’t going broke buying new equipment when the old is just fine.”

So you leave those venerable old PLCs in place. Perhaps you add sensors elsewhere to monitor temperature, vibration, and other indicators of equipment health. Then, when you need to replace something for some other reason, you can consider a sexier model with lots of IoTness built in.

That’s all well and good, but how do you secure this stuff? When deciding where to add sensors and other sources of intelligence, you can make decisions case by case, beefing up the network where necessary, and leaving it alone where it’s too hard or too expensive to replace. But security? That’s sort of an all-or-nothing affair.

Any new sensor nodes you add can be secure (although today, it’s not guaranteed that they will be… but let’s assume so). You can beef up your servers and hubs and routers so that they meet modern security standards. Maybe through upgrade, maybe through replacement. They’re not super expensive (although they add up).

But what are you going to do about those older parts of the network – machines, sensors, etc. – that were installed before security was a thing? That’s where the real money is. But with security, you really can’t simply say, “Oh, we’ll get to that when we replace them in 5 years” the way you can with other equipment decisions. During those 5 years, the unprotected nodes will be an invitation to enter not by the back door, where that beefy bouncer stands guard with that all-important VIP list, but via the side door that everyone forgot about.

These old machines are like a stubborn old grandpa, still in his childhood home while the neighborhood gets turned into a mall*. And he’s still got plenty of useful years left. So he’s staying put, nothing’s going to make him move except six bodies and a box. So how do you integrate grandpa into the new neighborhood rather than forcing him out?

In other words, how do you lock those parts of the network down without replacing the grandpa equipment? There is at least one solution to this very specific application from Icon Labs. They call it Floodgate Defender, and it’s a hardware appliance that does all of those things that a security stack in new equipment would do. It’s basically a small, standalone firewall.

(Image courtesy Icon Labs)

Obviously, separate firewalls aren’t new; there are presumably racks of them floating up in the Cloud. But those cost lots of money and are way overkill for simply protecting a little piece of equipment. So this is a small unit, with Ethernet in and Ethernet out, that you add as a bump in the wire. Unplug the Ethernet from your equipment, and insert the firewall in between. Of course, this does mean that grandpa can’t be so old that he doesn’t even have a network connection. This works perhaps better for septuagenarians rather than centenarians – grandpas with network connections, but without security.

Configured in the default mode, your equipment is now protected from the network; if someone is prowling about, the firewall will stop them before they can monkey with your machinery. While useful, that’s frankly a scenario opposite to the one I tend to think in terms of, where the edge node becomes a possible point of entry to the network. So, is the firewall protecting the edge node from the network, or is it protecting the network from the edge node?

In this case, the answer turns out to be both. The device can be configured to protect in both directions, although you have to make sure to set that configuration up.

Presumably, in the future, when you replace the equipment that you’ve isolated with the mini-firewall, then you will do so with a device with built-in firewall capabilities, and you can decommission the external firewall. Or not; maybe it’s just as easy to keep the manufacturing line humming along with as few changes as possible (since those changes all too often come with unanticipated consequences). Just as long as everyone stays off the lawn.

*Sorry, I’m having trouble picking one metaphor and sticking to it… Actually, this particular one was a simile… for anyone that was planning a grammar-correction post…

More info:

Icon Labs Floodgate Defender