A network designed on cybersecurity principles such as Defence in Depth and Zero Trust needs to be a primary focus for organizations looking to secure their OT environments. Defence in Depth is a well-known security principle of implementing security in layers. Zero Trust is a security paradigm that focuses on protecting organizational resources such as data, applications, devices and systems on the premise that authorization of users and devices is continuously evaluated and not implicitly granted. Meaning, no user or device or user is to be trusted by default. These security principles should guide the network architecture, whether it is a smart building OT and IoT environment or an industrial plant process. Having a centrally managed physical network infrastructure for your automation and controls systems is key to securing the OT environment. When designing your OT network architecture, the following areas should be considered:
Having a centrally managed physical network infrastructure for your automation and control systems enables securing the OT environment. This eliminates siloes and enables centralized management of onboarding, monitoring and troubleshooting connectivity issues in OT systems. Redundancy needs to be built into the converged network, as a lack of it would make it a single point of failure. This network can share the physical backbone with the IT or enterprise network or be separate. However, all OT systems should receive connectivity from a converged network.
Zones can be defined as grouping of OT (or IT) assets based on parameters such as: operational function, criticality to operations, risk exposure, physical or logical location, or organization responsible for management. For example, all Building Management system devices can be designated a single zone and the physical security access system can be designated another zone. This is an example of grouping based on operational function. A zone will usually have the same cybersecurity requirements. However, certain equipment within an OT system may be more critical than others, leading to ‘sub-zones’. For example, control devices serving a data center or the Central Utility Plant might be more critical to overall operations than the controls serving an auxiliary air handling unit.
Conduits consist of grouping assets dedicated to communications that share common security requirements and connect two or more zones. Defining conduits will allow mapping data and information flows. It will expose which systems need to talk to each other and where communication channels and integrations are needed.
ISA-62443 defines security levels as the level of confidence that a zone, OT system or conduit is free from vulnerabilities and functions in the intended manner. This is an interesting way to describe security level. The higher the level of confidence, the more secure that zone needs to be. For example, your enterprise network will have higher security level than a OT system that is full of devices with unpatched vulnerabilities. Defining security levels can be an introspective exercise to determine the most important assets in your network and where security flaws and vulnerabilities lie in your environment.
No OT devices should be openly accessible to the public internet. A strong network perimeter defense is essential for that. A single firewall or multiple ones can be used to control the ingress and egress of traffic between your internal networks and public networks. Firewalls can also be used between internal zones to control the flow of traffic. There are various types of firewalls and the level of inspection and control they can do, and you'll need to select the right one for different levels of the architecture. The more firewalls you have, the more configuration and ongoing maintenance and management you will need to do. There are cost considerations here, both the initial cost of installation and ongoing maintenance and management.
Network segmentation or microsegmentation is a practical way to implement zones and conduits in your network. If you’ve already defined your zones, conduits and security levels, using network equipment such as Layer 3 and Layer 2 managed switches will help you enable that design in your network. These switches need to be properly configured and maintained and the more you have, the more complex that setup can get (and costly to maintain!).
Just having network security devices is not enough. Ongoing network management is also necessary to ensure network equipment functions as intended and that threats are detected in time. This is where many OT teams fall short and may rely on the internal IT teams to help, or a managed security services provider (MSSP) specializing in OT.
Various OT and IoT applications run in the cloud whereas others utilize cloud storage from a third-party as part of the solution. The adoption of cloud-based solutions has picked up in recent years, with more and more asset owners using these solutions for their OT environments. The cloud security model with your vendor should be carefully studied by reviewing their contract clauses and understanding the responsibilities of each party. Appropriate provisions need to be made in your vendor agreement if anything is lacking. The concept of zones also applies to cloud architecture and services and needs to be reviewed with your vendor and IT team. Network security tools will be part of cloud security. Authenticating network devices and users, encrypting data in transit and rest (where possible), identity and access management, privileged access management, and data residency are some other considerations when it comes to cloud security.
We covered some of the broad areas of network security using well-known networking tools and concepts. Each item covered here can be a detailed topic in and of itself. Some MSSPs can provide security-as-a-service and may have their specific hardware and tools. These topics will still apply if you are relying on an MSSP.
We’ll continue this series on foundational measures by exploring the importance of secure remote access.
Here are other articles in this series of Setting the Foundation for OT Cybersecurity:
Part 1 - Policies, Standards, and other Documentation
