Operational Environment - An Example

The following figure illustrates the Industrial Edge system setup for its intended purpose.

The customer's IT & OT security concepts needs to define the setup and network protection concept, and adjust the reference architecture shown above to their specific requirements without lowering the security measures shown. The Industrial Edge Management and Edge Devices must NOT be operated in non-trusted networks. However, the IEM instances can be operated in networks exposed to the internet, e.g., if they are consumed as SaaS service by Siemens or the customer decides to run their IEM as an internet-exposed service that is protected by sufficient measures. In case of operating internet-exposed Industrial Edge components, they must be protected by suitable protection measures going beyond simple firewall-filtering on port-level. These measures have to include sophisticated firewall-protection and Denial-of-Service (DoS) protection measures analogous to the protection of other internet exposed webservices and according to the constellation specific risk mitigations identified by the company specific risk analysis.

In general, all system components are initializing connections from lower level to upper level using a secured communication channel (by using TLS encryption).

All components operated by the customer should be protected by a suitable perimeter protection.

This means especially protecting the communication

• between the IEDs running in the cell level
• between the IEDs and the connected IEM running in the Industrial Zone
• between the IEM and any external component (IE HUB and other Cloud Solutions) running on the internet

This can be achieved, e.g., by installing local firewall devices and tunneling the communication between the IEM and the IEH via a dedicated proxy with valid access restrictions. In case the IEM is running in a public cloud, the communication between the IEDs and the IEMs can also be routed through a proxy. By restricting the traffic, it must to be sure, that the update-Server is still reachable from IEMs.

The domains contacted by the Industrial Edge ecosystem in your environment are listed here.

Furthermore, the required network ports for communication between the Industrial Edge components on the corresponding firewalls are documented here.

A firewall should have always a block-by-default policy for in- and outgoing connections to prevent unauthorized communication from and to an Industrial Edge Device which was compromised by an attacker. Having also a block-by-default ruleset for egress traffic hinders an attacker from loading data and binaries from untrusted sources.

All required communication between the IEDs and the IEM and the IEM and the IEH are initiated only from one type of system. This implies that only an IED is initiating the communication to the IEM, but the IEM is NOT initiating the communication to IEDs. Similarly, only an IEM instance is the initiator of a connection to the IEH, but the IEH is NOT initiating the communication to IEMs.

In case Industrial Edge Apps are exposing their services on additional ports, i.e., not using the standard ones provided by the IED, one has to open the firewall to allow connections from these additional ports of the Industrial Edge Device to the app-specific backend services; same holds for additional app-specific incoming ports.

Administrative access (e.g., SSH) to the IEDs or orchestrator backends on which the IEM instances are running must NOT be exposed to untrusted networks - especially the internet.