Operational Environment - An Example

The following figure shows the setup of the Industrial Edge system as an example.

The customer's IT security concept needs to define the setup and network protection concept, and adjust the reference architecture shown above to their specific requirements. The Industrial Edge Management and Edge Devices must NOT be operated in non-trusted networks. However, the IEM and IEH 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. In case of operating internet-exposed Industrial Edge components, it is highly recommended protecting them by suitable protection measures, e.g., firewalls with block-by-default rulesets for in- and outgoing traffic.

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 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 HTTPS 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.

One can look up here which domains the Industrial Edge ecosystem running in your environment is contacting.

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.