Incorrect (Naive) Solution: Direct Connectivity from HMI to the Cloud

The simplest solution — the one that might seem obvious at first glance — is to deploy the Optix-Fiix library directly within the FT Optix application running on the Optix Edge device in the OT network, i.e., within the visualization application itself. This results in a single application that simultaneously handles HMI and data transmission to the cloud-based Fiix CMMS.

Since Fiix is an internet service, the prerequisite for this solution is that the Optix Edge device has direct outbound access to the public internet.

All devices are connected to a single flat network: both PLCs, the Optix Edge, and the three HMI panels share the same network segment. The Optix Edge communicates with both the PLCs and the internet. There is no protective layer or inspection point.

Direct Exposure of the OT Network to the Internet
An Optix Edge device with active outbound internet connectivity represents a potential entry point for an attacker from the public network. Any vulnerability in the Optix-Fiix library, the FT Optix runtime, or the device operating system could be exploited for remote access. An attacker who compromises the Optix Edge immediately finds themselves in the same network segment as both PLCs.

A Single FT Optix Application Handling Multiple Roles
A single FT Optix application here handles both visualization and cloud communication simultaneously. As in the previous article, it is of course possible to split these functions into two separate FT Optix applications running on two different Optix Edge hardware devices — or on a single device using containerization.
This separation would certainly be correct from the perspective of separation of concerns and with regard to future project management and maintenance, but it would not eliminate the fundamental security issue: the direct exposure of the OT network to the public internet.

Lack of Segmentation and Difficulty of Monitoring
It is also worth noting that in a flat, unsegmented network, it is not possible to effectively control or audit data flows between OT devices and the outside world. There is no inspection point that would allow anomalies to be detected, unwanted connections to be blocked, or a record of what is actually being sent and where.

Compromise Solution: Integration Host Without Staging

The compromise solution introduces one key improvement: the cloud integration function is moved out of the OT network into a dedicated host located in an IDMZ (Industrial Demilitarized Zone). This integration host runs an FT Optix application with the Fiix-Optix library deployed, responsible exclusively for sending data to Fiix CMMS.

The FT Optix HMI visualization application remains in the OT network. This application does not use the Optix-Fiix library and does not communicate with the Fiix cloud in any way.

An industrial firewall is placed between the OT network and the integration host. The integration host reads data directly from the OT network, and there are several options for configuring this communication, including:

• Direct data reading from control systems into FT Optix
• OPC communication between two FT Optix applications
• MQTT communication between two FT Optix applications

Firewall rules would then be set to match the chosen communication method.

What We Improved

• The Optix Edge in the OT network no longer requires direct internet access. HMI panels and control systems are therefore no longer directly exposed to the public network.
• The visualization application and cloud integration are separated into different devices, each in a different network and with a narrower scope of communication permissions.
• The firewall makes it possible to restrict outbound traffic to a specific destination address. HTTPS can thus be permitted exclusively to the Fiix API server, and all other outbound communication can be blocked. This significantly reduces the risk of the integration application being exploited for unwanted communication with other servers.
• The use of an industrial firewall also provides options for network traffic monitoring and auditing.

Where the Risk Remains
The integration host has direct access to the OT network for reading data, and at the same time direct internet access for sending data to the Fiix cloud. It therefore acts as a kind of bridge between two worlds that should be strictly separated. Compared to the previous solution, the connection to the outside world is somewhat more distant from the control systems — but the bridge still exists. If an attacker gains control of the integration host, the direct path into the OT network remains open.

The security of this solution depends directly on how thoroughly the integration host is configured, updated, and monitored. For less critical projects, this option may be sufficient, but it cannot be recommended as a long-term solution for industrial environments with high security requirements.

Secure Solution: Architecture with Staging SQL

The fully secured architecture is based, as in the previous article, on the Purdue Model and the principle of defense-in-depth.

The network is divided into three zones separated by industrial firewalls: the OT network (Purdue L1–L2), the IDMZ (Purdue L3.5), and the IT network (Purdue L4).

OT Network
The device configuration in the OT network is essentially identical to the one used in the previous article for data logging. Functionality is split between two FT Optix applications running on two separate Optix Edge devices, or on a single device using a Docker container. One application drives the HMI terminals, which are isolated in a dedicated network. The second FT Optix application handles the collection of maintenance-relevant data — that is, the data intended for eventual transmission to the Fiix API.

IDMZ and Staging SQL Server
The device configuration in the OT network is essentially identical to the one used in the previous article for data logging. Functionality is split between two FT Optix applications running on two separate Optix Edge devices, or on a single device using a Docker container. One application drives the HMI terminals, which are isolated in a dedicated network. The second FT Optix application handles the collection of maintenance-relevant data — that is, the data intended for eventual transmission to the Fiix API.

IT Network
The FT Optix integration application is located here, in the IT network — that is, behind the second firewall. Its role is to periodically read data from the staging SQL server. This communication also follows a pull principle — communication is always initiated by the reading application, i.e., the IT network. The retrieved data is stored in the internal variables of the FT Optix application.

This integration application makes full use of the Optix-Fiix library. Using its objects, it transmits data via HTTPS to the Fiix API.

At this point, one might ask whether FT Optix is strictly necessary as the integration application. It is not, of course. A similar application that periodically reads data from a SQL database and sends it via HTTPS requests to a designated API endpoint can be coded in many programming languages. However, FT Optix together with the Optix-Fiix library offers the ability to create the integration application conveniently in Optix Studio using pre-built objects — without any programming required.

Firewall Rules

• Firewall 1 (separating OT from IDMZ): permits a single data flow — writing tags from Optix Edge to the staging SQL server (TCP 1433). All communication in the opposite direction is blocked.
• Firewall 2 (separating IDMZ from IT): permits only communication from the IT network to the IDMZ for reading data from the staging database. All other traffic is blocked.
• The IT network perimeter permits outbound HTTPS communication from the integration application to the Fiix API (TCP 443).

Result
The proposed architecture strictly separates the OT and IT layers using an IDMZ zone. PLCs and HMI systems in the OT network write data to a staging database located in the IDMZ. The integration application running in the IT network accesses this database in read-only mode (pull principle) and subsequently sends the processed data to the Fiix cloud API system via secured HTTPS communication (TCP 443).
This approach ensures that:

• OT devices are never directly exposed to the IT network or the internet,
• the IDMZ serves as a secure intermediary for data exchange,
• the integration application in the IT network does not communicate directly with PLC devices,
• all communication toward the cloud takes place exclusively from the IT zone.