An enterprise wide Industrial Control Systems (ICS) landscape consists of a large array of applications, tools and endpoints spread across multiple facilities at the very core of plant management and manufacturing. This dependency on automation systems mandates companies to develop specific criteria to adequately protect the infrastructure that supports their production processes. Creating strong boundaries between business networks and process control networks (PCN) potentially minimizes the number of vulnerabilities and attack paths that an internal or external attacker may use to manipulate certain critical systems and gain unauthorized access. A PCN Demilitarized Zone or DMZ is considered one of the key security protection mechanisms in the isolation and segmentation of client networks from the underlying OT networks. Listed below are a compilation of FAQs based on our project experience and interactions with asset owners, product vendors and subject matter experts in the industry.
1. With IT and OT requirements, do you recommend the use of dual firewalls (IT firewall and DCS firewall) to isolate the DMZ?
The prevailing trend in the industry and recommendation is to deploy a dual firewall architecture separating business and PCN facing services and dataflow. North firewall manages all ingress and egress traffic to the business network while the South firewall controls traffic to and from the PCN. All traffic originating from either business network or PCN is terminated within the DMZ.
An enhancement to a dual firewall configuration is using firewalls from different manufacturers to mitigate common mode issues. Having different vendors will limit vulnerability exposure since it is unlikely that both vendors have the same bug at the same time. So, if vendor A has a vulnerability and is waiting to get patched, it is likely that vendor B does not have that same vulnerability since both devices do not use the same OS. However, because there are two vendors, it introduces firewall management challenges such as separate licenses, support contracts, procedure documentation, different upgrade paths, etc.
2. What risk do you take by adding additional layers of complexity with a dual firewall DMZ design?
The major risk will be the management aspect of firewall configurations. Typically, the north firewall is managed by IT and south firewall should be managed in cooperation with OT personnel. Misconfigurations on one firewall can cause unexpected downtime or traffic drops on the other firewall. An effective change management process will need to be implemented and enforced. Vulnerability tracking and mitigation planning/execution will now be two-fold as well.
3. Whose Domain should the PC's in the DMZ reside - IT domain, PCN domain, or possibly some on one and some on another? Is a unique PCN domain recommended?
This depends on the acceptable risks that a company is willing to take. Does the company really want users in the DMZ to authenticate to the IT DC? Or even have DMZ servers access the PCN DC’s? If either is an acceptable risk, then all DMZ PCs should authenticate to that domain controller. In other words, DMZ hosts should not be authenticating to both IT and PCN domain controllers. It’s one or the other. However, our recommendation is one of the following:
· Create a forest for the DMZ and have it separate from the IT and PCN domains
o This may lead to higher costs and require additional support due to creating trust relationships between the DMZ domain and the IT/PCN domain.
· Install a RODC or read-only domain controller
o This does unilateral replication, so the only replication done is from the IT/DCS domain controller to the DMZ RODC
o Availability is limited since RODCs do not store passwords. If the IT/PCN domain controller is down, then users in the DMZ will not be able to log into their hosts
Each of these has advantages and disadvantages and the final design should be based on required risk reduction and tolerable risk level.
4. Do you recommend using VLAN's to separate the DCS PCs and DMZ PCs from each other?
Yes, it is highly recommended. Ideally, physical segmentation is preferred between DCS PCs and DMZ PCs because these asset classes have very different criticalities belonging in different layers of the Purdue reference model.
5. Directly porting through the DMZ, for example so that computers on the PCN network, or LIMS network can gain access to AD servers?
This is also referred to as “punching a hole in the firewall” by jumping Purdue levels. Not recommended if it can be avoided. Best practice is to terminate all connections in the DMZ. We recommend creating a separate domain for the PCN or establishing a RODC or read only domain controller. Both have pros and cons.
6. Should the PCN DMZ connect to L4 Business Network (BN) or a DMZ off of the L4 BN? More of a DMZ to DMZ connection.
PCN DMZ should not connect directly to L4. We are seeing a trend towards local and central DMZ architectures. Locating critical services on local DMZ and leveraging central DMZ for shared services which then interfaces to L4.
7. What are the implications and use cases for using separate AD for each Purdue level.
Pl see explanation above. In addition,
· L4/Business/IT – Should have own domain
· L3.5/DMZ – Recommend own domain or RODC
· L3 and below – Recommend own domain, RODC, or stand-alone AD server
The most common use case for multiple ADs in each Purdue Level is to ensure maximum Availability in case network connections are lost to the upper level AD. This is typically a risk-based design decision based on worst case operational impact resulting from users unable to log on to EWS console, Maintenance station, etc.
8. What are the implications on connecting AV/WSUS directly
Symantec/Microsoft and not connecting to relay servers in L4 Business servers.
It is best practice to reduce the attack surface of nodes within the PCN DMZ. Any compromise to the PCN DMZ can potentially provide a pathway to the underlying PCN assets. Therefore, using a relay server approach for internet facing nodes such as WSUS, AV, etc., is recommended.
9. Can Deep Packet Inspection (DPI) based firewall introduce latencies in system response?
Most DPI firewall vendors provide detailed specs based on their system tests. If the firewall is designed and sized per the vendor’s specifications, then there should not be any latencies. DPI firewalls are routinely deployed in safety critical and similar applications successfully in the industry.
10. What are some of the best ways to monitor the Switches and the back firewall (collect logs, alerts) to have visibility into these devices under the DMZ?
Each networking device should have logging configured to send to a syslog server. The syslog application on that server should be configured to create alerts based on the logs they receive i.e. critical alerts, warnings, emergencies, etc. The best ways to stay on top of these alerts is to create a policy on what should be immediate alerts, what should be part of a weekly report, and what we can ignore. As far as the placement goes, we recommend that PCN network devices and PCN host logs be sent to a syslog server in the DMZ. We also recommend configuring alerts for any SYN packets sourcing from the syslog server since the server should only be responding to traffic and not initiating it.
11. Is the integrated safety instrumented systems (SIS) also similar to PCN?
Safety instrumented systems are part of the PCN, but they must be segmented and isolated due to their criticality to operations. ISA 62443 recommends a zone level firewall for safety instrumented systems.
A cybersecurity risk assessment framework such as CyberPHA or similar should form the basis for the design of a PCN DMZ network. Several options exist with regards to the design architecture with Security, Manageability and Scalability as the overarching requirements. Network segmentation and segregation of services, phased deployment including testing, site adoption, training and tracking and measuring risk reduction are key factors to consider for the successful implementation and operation of PCN DMZ.