This is Part 3 of The OT Security Dozen – a 12-part series on building an OT/ICS cybersecurity program for an industrial operations environment.

Note: You may have noticed that operational technology (OT)/industrial control system (ICS) cybersecurity awareness is a common theme across "The OT Security Dozen," and hence no exclusive part on awareness itself. The aim for this series is to raise awareness on each type of controls covered, and therefore is considered an essential/integral necessity across this 12-part series.

This part is to help end-user (owner/operator) organizations understand the typical options for working towards designing and building a secure OT/ICS network architecture and its awareness for the technical staff. Ultimately, the goal is to familiarize oneself with execution flow for designing and building an OT/ICS network security architecture and segment the network via enforcements around different zones.

Assuming you've performed the OT Security Dozen Part 1: A Year of OT/ICS Cybersecurity Assessments against your industrial network environment and establishing OT Security Dozen Part 2: OT/ICS Cybersecurity Policy & Governance, hopefully you have a understanding of network architectural issues in terms of lack of properly segmenting the network into zones/conduits (between information technology [IT] and OT networks and more within the OT/ICS or production environment), along with the relevant policies and setting the goal towards establishing a secure OT/ICS network architecture. The next steps are to design, plan, and execute a short- to long-term plan for re-architecting the OT/ICS network and continue building and executing an OT/ICS cybersecurity program and strategy.

OT/ICS Cybersecurity Program & Mapping to Industry Standards

OT/ICS Network Architecture Basics

Whether an industrial manufacturing organization is operating at the level of industry 3.0, industry 4.0, or in between, having a secure network architecture is an essential first line of defense. If OT/ICS networks are compromised, it poses a higher level of risk to the organization, safety of its employees, and in few cases to the public (for critical infrastructure).

A typical method adapted is the separation or division of the systems into two distinct networks between a) enterprise/business/IT network, and b) process control/control/automation or simply OT/ICS network. Most organizations establish a strong perimeter around OT/ICS networks by segmenting the two networks via next-gen firewalls and/or data diodes, minimizing the possibility of intrusions in case of a compromise on the IT network.

Though, there are still many manufacturers (specially in Asia-Pacific [APAC]) that are either in the process or still don’t have any reasonable separation between the IT and OT systems and merely manage such separation at best with port-based virtual local area networks (VLANs) or assigning a different subnet mask (only limiting the broadcast domain) and believing it to be sufficient.

While segmenting between IT and OT networks is a good starting point, it isn’t enough. There’s a need for defining additional sub-perimeters/zones/conduits within the OT/ICS network to place additional preventive or detective controls, and to have a better contextual visibility and protection to contain potential compromises.

Purdue Enterprise Reference Architecture (PERA) Model

Analyze the environment and its traffic flow against ISA's Purdue Reference Model (PRM), which is a method of grouping technologies based on their criticality to cyber-physical processes.

A common approach is organizing the network architecture using industry reference models like Purdue Enterprise Reference Architecture (PERA), or simply Purdue levels, ISA/IEC 62443, a three-tier industrial internet of things (IIoT) consortium, the European Union Agency for Cybersecurity (ENISA), National Institute of Standards and Technology (NIST) OT security guidance, SANS ICS 410 and/or a combination of these models to organize OT/ICS network segmentation. PERA is a reference architecture that can model the enterprise in multiple layers and in multiple stages of the architectural lifecycle:

• Level  0: Physical process (defines actual physical processes)/field devices/equipment control (e.g., valves, pumps, motors, etc.).
• Level 1: Local control (controllers for local cell, line, process, distributed control system [DCS] controllers, programmable logic controllers [PLCs], remote terminal unit [RTU], etc.) and intelligent devices (sensing and manipulating the physical processes, e.g., process sensors, actuators, analyzers, and related instrumentation) for cell, line, process, etc.
• Level 2: Control systems; Supervising, monitoring, and controlling the physical processes; Real-time controls and software; DCS, human-machine interface (HMI); supervisory and data acquisition (SCADA) software, local alarm servers, process analytic systems, and other similar systems as level 3, but not just plant-wide.
• Level 3: Manufacturing operations systems; Managing production workflow to produce the desired products; Batch management; Manufacturing execution/operations management systems (MES/MOMS); Laboratory, maintenance, and plant performance management systems; Data historians and related middleware; Timeframe: Shifts, hours, minutes, seconds.
• Level 4: Business logistics systems; Managing the business-related activities of the manufacturing operation; Enterprise resource planning (ERP) is the primary system; Establishes the basic plant production schedule, material use, shipping, and inventory levels; Timeframe: Months, weeks, days, shifts.
• Level 5: Enterprise/IT Networks; Cloud, managing servers, financial, ERP type systems/applications, internet demilitarized zone (DMZ) (email, web, proxy, etc.).
• IIoT: Spans and interacts across layers 1-5.
• Safety systems: A recommended best practice is isolating safety systems to the greatest degree possible in their own segments with major enforcement boundaries in place. 

Secure Network Architecture Reference

An OT/ICS network security architecture reference provides a blueprint or a template for a site network implementation with a common set of standards vocabulary to refer to for designing, building, and implementing either a greenfield (new) or a brownfield (existing) network environment.

Note: Having a reference architecture does not guarantee a secure or compliant implementation, nor is it systems (SCADA/DCS, etc.) specific. It is just a means to design an OT/ICS system implementation to achieve a certain secure state, or, in terms of the ISA/IEC 62334 series of standards, achieve the right target “security level” (SL). They are defined to achieve an objective of securing the OT/ICS networks against different type of threat actors and attacks tactics as defined below:

• SL 1: Non-targeted attackers
• SL 2: Hacktivist/hobbyist hackers
• SL 3: Professional hackers
• SL 4: Nation states

An end-user organization needs to decide what target security level is desirable. ISA/IEC 62443 #5 is the only functional requirement that applies to the network reference architecture.

Note: More on the security levels to define segments and zones/conduits are coming in later parts.

The Impact of IIoT & Industry 4.0 on OT/ICS Secure Network Architectures

The accelerated adoption of IIoT, internet of things (IoT), analytics, cloud, 5G, and the increased hyper connectivity towards industry 4.0 have a great impact on traditional OT/ICS secure network architectures. There’s been a great debate about whether the PERA/Purdue model is "dead" or not when it comes to industry 4.0 or IIoT-based implementations.

Organizations can begin the process of characterizing and segmenting the devices/assets based on data flows, location, critical functionality, level of trust, management ownership and/or other logical combinations. Also, consider how the configuration of zones and isolation impacts the day-to-day operations, safety, and response capabilities.

Create an ICS/industrial demilitarized zone (iDMZ) as an enforcement boundary (major) between IT & OT network segments by utilizing levels, tiers, or zones while ensuring operational performance and safety.

Enforcement capabilities or controls to segment and isolate can be achieved using devices such as access-control lists (ACLs) on layer 3 switches, routers, firewalls, and unidirectional gateways/data-diodes. Firewalls are typically deployed as boundary protection and to control information flows and connections between network segments.

For example, implementing firewall rules and connection flows that prevent Level 4 devices from directly communicating with Level 2, 1, or 0 devices. Allowing outbound connections from lower levels/tiers/zones may represent a significant risk if unmanaged. Ensure outbound rules are as stringent as inbound rules to reduce these risks.

On the other hand, a unidirectional gateway, or data diode, allows traffic to flow in only one direction and acts as an additional protection against system compromises at higher levels or tiers. For example, a unidirectional gateway between layers 2 and 3 may protect the devices in layers 0, 1, and 2 from cybersecurity attacks that occurs at layers 3, 4, or 5. 

Typical IIOT implementations have a tier model from edge to cloud, have different requirements for connectivity/traffic flows, and use different communication channels and security. It also has specific needs for architecting the implementation of Unified Name Space (UNS), MQTT, Sparkplug B, 5G, and other analytics and cloud technologies.

Organizations have an option to control both north-south and east-west traffic flows using advance techniques for OT/ICS microsegmentation (a network security technique that further segments an environment for lateral visibility of all assets in the same broadcast domain) and zero trust security models (assumes breach, verifies all identities/devices, uses least privileges, and has continuous monitoring and response capabilities) using specialized tools and solutions. More on these in later parts!

An example of the representation of an enhanced industry 4.0/IIOT-ready secure OT/ICS network architecture is depicted below:

Figure 1: Enhanced Purdue Model - IIoT, Wireless, & Security Enforcement Boundaries

Figure 1 highlights an enhanced Purdue reference model including an implementation of IIoT, cloud, wireless, and other traditional IT and OT systems in a layered model with certain enforcement boundaries (major/minor). A few key things to know:

1. Purdue levels have different components, services, and functions, and can comprise of multiple subnets with network defenses placed between subnets, even in the same Purdue levels.

2. Example attack surface components at different Purdue levels have slightly different attack surfaces with few examples highlighted in figure 1 above.

3. Enforcement boundary includes functions and cybersecurity defenses necessary to segment and protect the various levels.

4. Internet DMZ boundary & IT enforcement boundary includes level 5 and enterprise wide area network (WAN) components, and also defines internet perimeters.

5. ICS/iDMZ enforcement boundary is a major ICS/OT perimeter boundary between Level 4 and Level 3 (sometimes known as Level 3.5 – IT & OT separation) and can have one or more sub-zones (depending upon the size/needs of environment):

• Level 4 to 3 sub-zone (limits all in-bound traffic)
• Level 3 to 4 sub-zone, (limits all out-bound traffic)
• Cloud Access sub-zone,
• Remote Access sub-zone,
• IIOT/MQTT broker/UNS sub-zone.

6. Enforcement Boundary (Minor): Between Level 3 and Level 2, a lesser enforcement boundary for restricting flow.

7. Airgap Enforcement Boundary: A major perimeter between safety systems and the rest of the OT network.

8. Secure communications flow across ICS/iDMZ enforcement boundaries are:

• Level 4/5 pushes to and Level 3 pulls from ICS/iDMZ (level 3.5)
• Level 3 pushes to and level 4/5 pulls from ICS/iDMZ (level 3.5)
• Levels 0-2 (if required) pushes to ICS/iDMZ (level 3.5)

Applying IT & OT Cybersecurity Best Practices

• Level 4: Limit email, internet access, and enterprise active directory at this level and explicitly deny this type of traffic to lower levels.
• Level 3.5: Devices/servers placed in ICS/iDMZ is where all inbound and outbound traffic must stop.
• Updates for patches and endpoint signatures should be pushed through ICS/DMZ
• Simple proxies are to be avoided at all costs since they can blindly pass on exploits.
• Limit and monitor traffic using next-gen firewalls/intrusion prevention systems (IPS)/intrusion detection systems (IDS) and network behavior anomaly detection (NBAD) or via modern data diodes.
• Level 3 can have an ICS specific cybersecurity operations subnet (say SecOps zone) for patch management servers, endpoint security solutions, and security information and event management (SIEM). Use ACLs to prevent compromise of this subnet against other layer 3 subnets. If needed, place an OT active directory (separate domain) with no trust relationships to the enterprise/IT.
• For cloud connectivity, assume a state of an attack and isolate traffic patterns by moving the on-premise server communicating with cloud to ICS/iDMZ cloud access sub-zones and limit the server to specific-only systems in the ICS network.
• For IIoT solutions, consider them as a single process, isolated from other processes.  

OEMs & Vendors – Secure Network Architecture References

Almost all the major original equipment manufacturers (OEMs), hardware manufacturers, and/or product vendors have some documented reference OT/ICS secure network architecture. A few examples are below:

• Securing OT in the Face of IIoT and 5G
• Industrial Automation Reference Architecture
• Reference Architecture for OT and IoT Device Security in Industrial Control Systems
• OT Architecture Design
• Industrial Network Security Architecture
• Practical Overview of Implementing IEC 62443 Security Levels in Industrial Control Applications
• ABB Reference Architecture
• Industrial Network Architectures
• MQTT-Based Manufacturing Reference Architectures
• MS Azure IOT Reference Architecture
• Industrial IOT Architecture Patterns

Recommendations

For owner/operators, start by using a preferred reference architecture using both general industry best practices from international standards (e.g., ISA/IEC 62443), industry guidance (e.g., NIST Special Publication [SP] 800-82r3, Guide to Operational Technology [OT] Security, Europe NISA, etc.), or your specific industry sector guidance* (e.g., energy/gas, utility/power, maritime, automotive, railway, aviation, etc.), along with close coordination with OEMs/vendors. Start with separating IT and OT networks between levels 4 and 3, defining iDMZ, then go to lower Purdue levels to start defining zones and conduits for separation between level 3 and level 2.

For vendors, it’s essential to provide detailed reference architecture guidance on how the products/systems developed by OEMs/vendors can support designing and implementing a secure OT/ICS network architecture layered model.  

Key Takeaways

For owner/operators:

• Start segmenting: Do not operate a flat or unsegmented OT/ICS network architecture.
• Limit or restrict all incoming traffic from IT networks (especially internet, email, web) to OT/ICS networks, utilizing technical controls like firewalls and/or data diodes/unidirectional gateways, etc.
• Understand and document all the traffic flows between levels or zones/conduits while allowing only traffic that is required for OT processes, along with business and technical justifications in place.
• Define a target goal to achieve a desired security and protection level for OT/ICS networks.
• For greenfield implementations (new setup), incorporate the latest methods for secure network architecture, utilizing the latest techniques like zero trust, micro/macro segmentation, software-defined wide area network (SD-WAN), 5G, secure IIoT architecture, etc.
• For brownfield environments (existing setup), use a phased approach to re-architecting OT/ICS networks with minimal business disruptions to production operations. 

Next Steps

If you are unsure about where to start, engaging with an expert is your best bet to perform an OT/ICS network architecture review/re-design, and/or to get in touch.

References

• Tech and OEM vendors reference links provided above
• ISA/IEC 62443 Standards
• Industrial IoT Consortium (IIC)
• NIST Guidelines
• SG CII CCOP v2
• SANS

Stay tuned for Part 4 – OT/ICS Asset Discovery, Vulnerabilities, & Threat Detection (or OT IDS) - Tool Selection & Implementation

*Yes, each major industrial sector mentioned above have different types of connectivity needs, use a variety of solutions, have different automation machine types, and cover different distances. Therefore, each have some form of their own reference architecture documented in their respective sector-specific cybersecurity guidance standards/documents. So, it is highly recommended to refer to your sector/regulatory specific guidance as well when designing or re-architecting your OT/ICS networks.

A version of this article originally appeared on LinkedIn. The author will be first featuring the series on this platform and encourages everyone to follow along in the SecuringThings newsletter.

See Intro blog here. See Part 1 here. See Part 2 here. See Part 4 here.