The importance of network design

By Josh Glass

In this ever-evolving world of interconnected enterprises, it has never been more important to consider network design when developing new systems or retrofitting legacy systems into the larger enterprise network. Executives need data at their fingertips to make decisions at a moment's notice, but sometimes organizations do not consider what they should to ensure the security of the network delivering that data. The goal is to have centralized data while keeping the underlying systems separated in a way that enables defense in depth and avoids widespread attacks echoing through the entire enterprise.

In our experience, there are two typical approaches to accomplishing these tasks. The first is the simpler, hardware-focused method of isolating networks through physical separation. Companies separate disparate network traffic into separate physical wires. A benefit of this design is that replacing network equipment is very simple and straightforward. Several issues can arise, however, when the number of separate physical networks increases and there is a desire to have them functionally act as one single network. The separate network approach adds unnecessary complexity, as computers need connections to multiple networks to enable communication in modern plant landscapes. The physically separate networks can quickly become a large web of interconnected computers, which could let a virus run rampant if not designed properly, as seen in the previous year's attacks. Furthermore, if advanced features of domains are desired, such as a domain name system, most organizations have a hard time resolving all devices without statically assigning everything, which can be difficult to maintain.

In contrast to the physically separated approach is the use of virtual local area networks (VLANs). This approach consists of using the same physical "wire," but marking the traffic with different identifiers to keep the traffic routes separate. Each virtual LAN is defined at the data link layer of the OSI model. Due to the added complexity of switch configuration, a networking expert is required to configure the network based on design requirements.

Despite the increased cost of design and network expertise, in our experience there is a considerable cost savings when implementing a new network as opposed to the physically separate option. The slight increase in design cost is dwarfed by the decreased hardware cost.

The goal when doing a network implementation project for control networks is to ensure that the network has as few attack vectors as possible. The risk is weighed to determine how interconnected the control network will be with the enterprise, leading to a defined network architecture. Risk is also factored in when determining whether to go with a physical or virtual LAN (or potentially a hybrid, as we see on many projects). If the singular goal is total isolation of the control network, then physical separation is the clear choice. However, due to expanding enterprises and connected devices, complete control network isolation is becoming very difficult to maintain (although we have seen some companies manage large networks in this manner). We have executed several projects that involve nothing more than untangling disparate networks and implementing a comprehensive network strategy. In cases like these, the ability to create a VLAN to keep network traffic separate becomes cost effective and can be designed in a way that mitigates attack risk.

In our experience, we have seen all these strategies employed to create control networks. It typically boils down to the risk that an organization is willing to accept coupled with past experiences and desired end states. The best advice is to evaluate the risks versus the costs of different network solutions and choose a design philosophy that meets security requirements without hamstringing your team. For example, to design a new pharmaceutical control system network from a greenfield state, it is beneficial to gather all operation technology (OT) and information technology (IT) personnel together to design the network as a team. That way both sides have their requirements met (or are at least cognizant of the reasons they cannot be met) and have a stake in the final design.

When planning for a project, we usually suggest that the network be physically separated from the enterprise network and have at least a demilitarized zone (DMZ) separating the two networks from each other. There would be two firewalls on either side of the DMZ to control traffic and create a deny-all rule by default, only allowing what is absolutely necessary to pass through networks. Typically, we design it such that the network traffic only flows up from the control network to the DMZ, and if necessary to the enterprise. There are several ways to approach a networking project but having a plan and buy-in from both sides is the best way to begin.

 subscribe now jpeg

About the Author

Josh Glass is a network automation engineer for Panacea Technologies, Inc. He is passionate about designing, implementing, and supporting secure network-focused automation projects for the regulated industries. Panacea Technologies, Inc., is a member of the Control System Integrators Association.

More Channel Chat  

Beauty is in the eye of the beholder—How saleable is your business?

So many security breaches! Are we focusing on the wrong things?

Integrating cybersecurity into a greenfield ICS project

The path to cybersecurity

Airport integration shows IT-OT convergence

What else is in the box? Selecting a batch solution just got simpler

Achieving pilot-scale process control flexibility and agility

Have you come to terms with the traditional instrumentation and control skill set?

The future of automation is not so distant

Grease manufacturer’s new facility achieves world-class performance with modern DCS

Top five upfront project considerations for effective risk management

Five tips to avoid costly ITAR violations

Sequenced changeover yields system upgrade without production downtime

Unintended consequences of cutting technical head count

Process Monitor, IIoT, and Industry 4.0

See all Channel Chat Articles

Reader Feedback

We want to hear from you! Please send us your comments and questions about this topic to