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.
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:
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:
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 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 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):
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:
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:
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.
For owner/operators:
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
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.