In Information Technology (IT) environments, the Demilitarized Zone (DMZ) is used as a buffer between external and internal networks to prevent direct access between the two network zones. The DMZ can host publicly accessible services such as web servers. For an ICS environment, it is as equally important to create this security boundary between the ICS network and the Business network. One example of why this is important is in scenarios where IT (Business network) incidents can sprawl into the ICS network. In fact, a large proportion of ICS incidents can be escalations of IT incidents from the Business network.
Firewalls are used in an IDMZ to help create the enforcement boundary between the Enterprise and Control networks. This solution has been validated to run with a certain set of firewall access-list rules that restrict the flow of data between the Enterprise and Control networks to only allow traffic for basic functionality between PTC components and for access to PTC resources. Users will have to take into consideration any unique requirements for their environments as well as the list of expected ports, protocols, and services for each software component in this solution. Additionally, it is essential to confirm and test different use cases once the IDMZ with a firewall has been implemented. It is also recommended to define a baseline of expected traffic to further enhance these rules or define additional rules.
The following table lists validated access-list rules for this solution’s architecture, that can be used as a guideline for different types of firewalls. The rules assume that the firewall is stateful, keeping track of the connections between endpoints. For this DVD, a Palo Alto 850 running software version 9.1 was used to validate the listed use cases. This list can be used as a starting point for developing a final firewall configuration for an IDMZ with this solution deployed. The list in the table references the two figures in terms of which component is the source and destination of the traffic flow. The two figures represent two different architectures, an example architecture for a single factory deployment and a multi-factory deployment. The rules cover the use cases listed below. Other use cases are out of scope, but ports and services information listed in this document can be used to help develop other rules.
Supported use cases include:
- Allow Business/Enterprise users to access DPM dashboard hosted on Control network
Description:In a single factory deployment scenario, designated business/enterprise end users will require access to view DPM dashboards. User traffic will be routed through a reverse proxy hosted in the IDMZ network. This functionality prevents direct access to ThingWorx on the control network and does not require enterprise users to know the control network URLs.
Note: This was validated using IIS as the reverse proxy using the URL Rewrite module and ARR extension. Since IIS is a third-party application, it is not supported by PTC if there are any issues. If using DPM and IIS as a reverse proxy, be aware that certain security settings may have to be backed-off.
- Allow Kepware connection to ThingWorx on Enterprise Network using ThingWorx Native Interface
Description: In a multi-factory deployment, it could be necessary to aggregate factory edge data gathered on Kepware Servers at a single and centrally located ThingWorx instance on the Enterprise network. These rules are validated by configuring Kepware to use the ThingWorx Native Interface and to send data over a proxy in the IDMZ to avoid sending data directly though the firewall.
Note: Proxy settings for Kepware Server can be found by opening ThingWorx Kepware Server 6 Configuration menu. Afterwards, right-click on Project, select Properties, go to the ThingWorx tab, and scroll down to Proxy.
|Allow Enterprise users to access DPM dashboard hosted on Control network
|Enterprise user (1)
|Reverse Proxy (2)
|Allow designated enterprise user(s) to access Reverse Proxy via HTTPS
|Reverse Proxy (2)
|Control ThingWorx with DPM (3)
|Allow Reverse Proxy to forward enterprise user traffic to Control ThingWorx with DPM over HTTPS
|Allow Kepware connection to ThingWorx on Enterprise Network using ThingWorx Native Interface
|Kepware Server (4)
|Allow Kepware to access IDMZ proxy
|Enterprise ThingWorx with DPM (6)
|Allow IDMZ proxy to forward traffic over SSL to Enterprise ThingWorx with DPM