The Forgotten Part of Network Segmentation

Most people who study OT Security learn that networks must be segmented. And they learn about the Purdue Enterprise Reference Architecture model. They learn about layers of networks, but they don’t learn about how to segment the networks appropriately.

That’s because proper segmentation is left as an exercise for the reader. It is rarely discussed. Part of the reason it is rarely discussed is that it involves something that most OT practitioners are not exposed to all that much: Instrumentation and Control Systems Engineering.

Recall the purpose of network segmentation: you are supposed to be left with just enough stuff to operate things semi-automatically. If you are segmenting the network for anything other than that purpose, you have missed the whole purpose of segmentation. This is not about the network, or your ability to monitor what’s going on, or any convenience for you. This is about the application: The industrial process. So if you segment networks across an active control loop, it had better be something that can be operated semi-automatically with a minimal number of manual adjustments per shift.

This brings me to an important point: If you’re using large office grade switches for industrial control systems, please stop. First, distribute the switches to the field as much as possible. Keep things small so that if any switch loses power or gets damaged, it doesn’t take too much out of service. The notion of using a 48 port switch in a control system with extensive home-runs in to the field gives me shivers. Yes, I know, you can set up all sorts of very interesting monitoring and security features. But if that switch fails or is disabled for whatever reason, there will be no segmentation and there will be no plan B. The plant will be going to manual control very fast. There may not be enough people to handle it. You could be courting disaster if this happened at the wrong time.

More to the point: A VLAN is not for segmentation. You can use VLANs for trunks between segments, but it is not for establishing a segment. Use hardware for segmentation.

Yes, you must think about the physical equipment. The cool kids are telling everyone to virtualize everything; go with software defined networking; and bring everything back to one big room where really smart people can do something incomprehensibly cool. Just stop. If that’s what you’re doing, you missed a memo. The priority is survivability in the face of failure, not network management or even visibility. You don’t need everything in one great big SOC with lots of blinking lights and pew pew maps. We need plans for things to break apart and function on its own.

This is where I need to admonish my friends in the networking business: We engineers work hard to decentralize everything. Don’t introduce new dependencies without good cause. Your convenience is not a good cause unless you have a very well defined return on the investment and the risk. You need to discuss that risk with the engineers. If you are doing this all on your own to an OT network, you’re assuming a risk that you do not fully understand.

The goals are 1. Safety, 2. Reliability (and survivability), and 3. Performance. If you aren’t doing things with those concerns in mind, get with the program.

With more than 30 years experience at a large water/wastewater utility and extensive experience with control systems, substation design, SCADA, RF and microwave telecommunications, and work with various standards committees, Jake still feels like one of those proverbial blind men discovering an elephant. Jake is a Registered Professional Engineer of Control Systems. Note that this blog is Jake's opinion ONLY. No Employers, past or present were ever consulted with regard to these posts. These are Jake's notions. Don't blame anyone else for them.

Related posts