In today’s technology landscape headlines about major cyber security breaches are becoming more and more frequent. Companies are increasingly forced to take cyber security more seriously and ensure that they have adequate risk mitigation and controls in place to deal with this potential threat. The risk of a cyber security incident is ever-increasing as networks grow, become more interconnected and attacks become more sophisticated.
Unfortunately, Operational Technology (OT) systems are some of the most vulnerable systems, because they remain operational beyond the expected lifetime of normal IT systems, and they are also rarely patched or updated. The risk is compounded by the fact that an attack on an OT system can result in serious negative outcomes. As OT systems become more and more like IT systems, it also becomes more critical to manage the security of the networks in which they reside.
Operational systems generate a lot of valuable data for the business. To extract the most value out of the data it must be transferred out of the OT network and into an enterprise network where it can be processed, transformed and stored. This should happen in real-time so that analysts and data scientists can work with the latest data and extract the most value. The primary mechanism for securing two networks is usually a firewall. This creates a kind of digitally controlled airgap that can be configured and monitored to allow or block specific networks, ports, applications and these days, even specific packets.
However, now that the OT and enterprise networks are physically connected and the airgap is controlled using software, security is only as strong as the weakest link. One configuration error or vulnerability in the firewall can completely expose the OT network. Furthermore, if a system and its data has become compromised the firewall might not even be aware of this. For this reason, simply having a firewall is not enough to protect the OT systems.
There are still other problems that need to be solved to reduce the risk of an attack or to reduce the impact an attack can cause – also known as the blast radius. In fact, a firewall is just one small part of the security landscape. Security must be designed and implemented at every layer and in every system – this means at the networking level, at the protocol level and at the application level.
Network Segregation
Security is a very advanced topic, and several cyber security frameworks exist that deal with cyber security across enterprises and government and IT more generally. Some frameworks relevant to Industrial Control Systems (ICS) include:
An important concept in many of these frameworks is the idea of network segregation and building a layered architecture. This concept was first developed in an early model called the Purdue Enterprise Reference Architecture (PERA) model for Industrial Control Systems (ICS). The key idea behind segregating networks into different levels in the Purdue model, and similar frameworks, is to enhance security, reliability, and manageability of the entire system. The following diagram shows the typical levels and the types of equipment or systems that you might find in each.
OT Security with OAS
When you choose OAS as your data solution you are also choosing an OT platform with security that is configurable at every layer.
There are four key aspects of OAS security:
- Network security
- Database security
- Device driver security
- Authentication and authorization
In this article we are going to focus on network security to understand how different architectures can be applied to create a secure network.
A properly designed network architecture ensures that your network is divided into layers that restrict access and permit only specific networks, ports and applications to run or communicate with that layer. The networking features provided by OAS allow you to segregate your data into networking layers and ensure data transfer is restricted and controlled.
Basic Networking
OAS basic networking is the standard IP connectivity functionality of an OAS instance that allows it to communicate with other OAS instances, databases, field devices and client devices. You can create various networking architectures using different data flow configurations. This will allow you to move data securely between layers of your networking architecture.
Every tag that you define in OAS consists of many different parameters to represent the various OAS features like tag settings, counters, alarm limits, thresholds and so forth. The most important parameter is the Value parameter as this contains the tag’s last known value. The key behind a good network architecture is to properly manage the data flow by configuring how tag values are sourced and passed from one tag to another across the layer boundaries.
In the following sections we will look at some common OAS networking patterns that allow you to move tag data between tags and between OAS instances in the same or in different layers of the networking stack.
Tag Data Source
One of the main features of basic networking is that you can address a tag in another instance using the remote tag notation. This notation consists of the instance IP or hostname as well as the tag path, tag name and parameter. This feature can be used where a tag’s Data Source is set to Tag. What this effectively means is a tag’s value can be sourced from another tag’s value. In the following diagram the equivalent tags are copied from Instance 1 to Instance 2 using remote tag notation on Instance 2.
If a tag is within a nested tag group structure you can use the remote tag notation to reference any tag within a nested group. The instance that is reading the tag values doesn’t have to use the same tag group structure. If you want you can mirror the structure of the tag groups, but you can also put your tags in whatever structure you want as long as each tag references the correct tag on the other side. In the following diagram the tags in Instance 1 are structured into tag groups. Instance 2 reads the tags but changes the structure into a flat structure. It is completely up to you how you want to arrange the tags.
Note that this type of tag-to-tag relationship is inherently unidirectional (read-only) in that every tag has only one data source. In the above example the data sources for the tags in Instance 1 are set to the PLC. The tags in Instance 2 are then sourced from Instance 1. Given the tags configured above, it is not possible for Instance 2 to write tag value changes back to Instance 1. This ensures that data is always flowing in only one direction and can be secured at the source.
From a data flow and security point of view, Instance 2 must use a security account to login to Instance 1 and the security group defined in Instance 1 for that account must allow tag reading. Instance 1 controls the access, but Instance 2 makes the request to read the tag value.
👉 Get started with Basic Networking: https://openautomationsoftware.com/networking/basic-networking/🔗
Data Route
In the Tag Data Source method, we’ve seen how a higher layer can pull data from a lower layer. This works great for passing data along a chain of tags. The problem is the tag in Instance 2 must specify the data source as Tag and therefore this tag can’t be attached to any other data source. Let’s say you want to write data to another device using a driver such as Allen Bradley, CAN Bus, Modbus, MT Connect, OPC UA, Siemens, or a UDI driver. You have to set the data source of a tag to the relevant driver type in order to write data, but you can’t set it to both Tag and Modbus for example.
To get around this we have to use the Data Route feature. This feature is primarily used for device to device or device to cloud communication. You can also use it to pass data between networking layers in more advanced way.
👉 Get started with Data Route: https://openautomationsoftware.com/getting-started/getting-started-opc-tunnel/🔗
👉 Data Route in practice: IIoT Data Transfer with No Code🔗
Data Route – Tag to Tag
The first data route feature is Tag to Tag which is defined at the tag level. Let’s say you have a tag in Instance 1 that is reading data from a Modbus driver data source. You want to copy this data to another tag in Instance 2. The tag in Instance 2 is also talking to a device – let’s say it has the driver set to a Siemens data source. You can’t use the Tag data source method described in the previous section in Instance 2, because you have already set it to a Siemens data source. Instead, you will make the tag in Instance 1 target the tag in Instance 2. Whenever there is a change to the tag in Instance 1, the OAS engine will write this change to the target tag in Instance 2.
From a data flow and security point of view, Instance 1 must use a security account to login to Instance 2 and the security group defined in Instance 2 for that account must allow tag writing. Instance 2 controls the access, but Instance 1 makes the request to write the tag value.
👉 Get started with Data Route – Tag to Tag: https://openautomationsoftware.com/knowledge-base/tag-to-tag-data-route/🔗
Data Route – Multiple Tags
The data transfer methods described previously are based on one-to-one tag relationships. In other words, a tag reads data from another tag or a tag writes data to another tag. These are great for simple use cases. The Multiple Tags method is more powerful and provides more flexibility for bulk tag data transfer.
The main benefit of the multiple tags method is that you can configure multiple independent data routes and each data route can contain as many source-destination tag pairs as you need. Each data route can be enabled or disabled based on another tag’s value, which opens the door for dynamically controlling your data flow based on external conditions. On top of this, data copying in a data route can be triggered by various conditions such as rising or falling triggers, time-based schedule or data change detection.
From a security point of view, data routes are a feature that can be managed using a set of dedicated permissions and you can configure the system to only allow certain accounts to manage data routes. The networking features of OAS allow you to configure data routes for tags on the same instance or on different instances. As with other methods, Instance 2 still needs to be configured to allow writing to tags from Instance 1. If the data route is configured on Instance 2 then Instance 1 must allow reading tags. If a data route is configured on an independent (third) instance, then the source must allow tag reading and the destination must allow tag writing. This gives you a lot of flexibility in terms of network architecture.
👉 Get started with Data Route – Multiple Tags: https://openautomationsoftware.com/knowledge-base/multiple-tags-data-route/🔗
Unidirectional Network Gateway
OAS basic networking uses OAS to OAS communication ports and protocols. In some critical systems, this is not sufficiently safe as someone could accidentally configure OAS to write data to the wrong tag or incorrectly configure the security groups and allow permissions that should not be allowed. To mitigate any risk of failure caused by external access we need to be able to block all bidirectional networking and only allow a single unidirectional port to communicate to an instance outside of the network.
In OAS this feature is called the unidirectional network gateway and is achieved by setting up a UPD protocol data stream that only allows traffic to flow in one direction. This allows you to isolate critical PLC networks from downstream systems such as HMIs, databases and other less critical PLCs or services. This architecture is commonly used where the control system layer is extremely critical to the safe and proper operation of the overall system. This architecture is important in systems you might find at a nuclear power station.
In the OAS platform this feature is also known as UDP Broadcast and UDP Receive and is illustrated in the diagram below. The sender is configured in the UDP Broadcast configuration and points to one or more OAS instances using IP and port number pairs. Each receiver is then configured to listen on the given port in UDP Receive configuration. The UDP protocol is great for this one-way type of communication as it allows for data transfer to be performed using a broadcasting method without requiring any data to be written back to the sender.
👉 Get started with Unidirectional Network Gateway: https://openautomationsoftware.com/getting-started/getting-started-udp-broadcast/🔗
Cloud Connectors
You can use OAS cloud connectors to pass data from an OAS instance to an AWS IoT or Azure IoT cloud service. By configuring an OAS instance in an enterprise DMZ, you can configure a cloud connector using SSL/TLS security and choose which tags you want to publish. The cloud connectors support many configuration options to filter the tags, manage topics and the payload structure.
👉 Get started with AWS IoT Gateway: https://openautomationsoftware.com/knowledge-base/getting-started-aws-iot-gateway/🔗
👉 Get started with Azure IoT Data Hub: https://openautomationsoftware.com/knowledge-base/getting-started-azure-iot-data-hub/ 🔗