Industrial Ethernet Security

I admit it. All this security talk makes my head spin. I didn’t go to Harvard. I didn’t go to MIT. I learned Computer Science at a school whose best attribute is that it’s kinda close to Yale. I’m not a wiz kid in security by any stretch of the imagination.

I really try to look at things a practically. Because I’m not that smart, I really look for simplicity. And that’s really what distresses me. Whenever the subject is security there isn’t a lot of simplicity to be found.

All I can tell from the reading I’ve done is that security is good and no security is bad. Everything after that confuses the issue for me.

There is a lot of technical-sounding terminology. There’s concepts like “defense in depth.” There’s the threats like “denial of service.” And then there are all the security protocols. If you’re like me, you have a general understanding of things like HTTPS, 802.1x, PKI, encryption technologies and all the rest. Not many of us are anything close to experts on these topics, even though part of my job to know about stuff like this.

So today I read that EtherNet/IP is working on a “secure” EtherNet/IP. I’m sure the same is in progress for Profinet IO.

I have two questions. One is “Really?” The other is “Why?”

I’ll start by asking the obvious question: Why do these networks need to be secure? Yes, I know that seems preposterous. Yes, I know it seems silly. But bear with me for a moment.

Those networks exist to move inputs from a field device to a controller and outputs from a controller to a field device. They really don’t have any other function. They are well-designed for that and really good at it.

I have this argument all the time with the PI and ODVA people. These are not information networks. They are I/O networks. They are not well adapted to moving information from the factory floor to the Enterprise. It’s a perversion to try to make them do that. They’re as cumbersome at moving information as I am doing a waltz. Yes, I can take my Buick and drive it in the Indianapolis 500. It will make it around the course, but it’s not really built for that.

Now, if the system needs to connect the controller to the Enterprise, that’s a connection that I can understand. The best way to do that is to use a separate NIC card and talk to the Enterprise on that second Ethernet channel.

The alternative, an alternative I don’t like, is to use the same Ethernet network as the I/O network. I wouldn’t do it this way, but you could. You could move information from the controller to the Enterprise over the same physical network as the I/O network. To do that, you should use an information protocol like OPC UA, MQTT, AMQP, XML or something of that ilk. If you did that, you would do it over a TCP port dedicated to that information flow, which means that those messages would not be processed as I/O network messages.

This means that a message spoofing an EtherNet/IP Explicit message, for example, could not come through the port dedicated to OPC UA and find its way into a drive and change a drive parameter. The drive would only accept that message on the port dedicated to EtherNet/IP, not the port dedicated to OPC UA.

By either dedicating an entire subnet to information or using another protocol with a different port, you are securing the I/O network.

The conclusion that I draw from all this is that there is no legitimate reason to secure the EtherNet/IP and ProfiNet IO networks unless you intend to pervert them and use them as information networks. And really, I think that’s what this is all about and I am totally and completely against that.

There’s no good reason for it that I can think of, and if you have one I’d like to hear it.
John