Configuring Firewalls for OT Networks

Configuration, testing and commissioning of firewalls for OT networks

What is the function of a firewall?

Firewalls are networked devices consisting of hardware and/or software for segmenting networks and preventing unauthorized access to critical ICS assets. However, a firewall is only as good as its configuration. Proper configuration of firewalls requires not only a skilled operator trained on the particular brand of firewall but also requires considerable understanding of process control network,  industrial protocols and control system applications. Small mistakes can render a firewall worthless as a security appliance.  

aeSolutions has extensive experience in designing, configuring and commissioning firewalls in industrial applications. We have experience in all major brands of firewalls, whether they be general-purpose IT firewalls used to segregate the ICS networks from company business networks or industrial firewalls used to protect individual zones and conduits.  Our team has experience with firewalls from a variety of manufacturers such as Tofino, Phoenix Contact mGuard,  Cisco ASA, SonicWall, Siemens Scalance, Downstream, etc.  

Looking to assess an optimize existing ICS firewalls? 

Description of the Service

A typical firewall configuration service includes both offsite analysis and onsite visits:

  • Project Planning, preparation, and status updates

  • Firewall rules rationalization

  • Configure and Testing of rules and devices

  • Evaluate/Fine tune rules based on Syslog & other testing

  • Vulnerability Scan and Discovery based on current firmware version

  • Help develop roll out planning and further status updates

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. 

Service Deliverables

  1. Firewall Migration Planning and Deployment

  2. Rules Optimization Report

  3. Configuration and Features Validation Testing

  4. Vendor Evaluation Reports

  5. Training and documentation for administering and maintaining the firewall

Contact Us Today

Frequently asked questions for OT firewalls

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. Ideally these firewalls would be managed by separate groups to create a separation of duties, limiting the ability for one party to modify and compromise both the North and the South firewalls allowing unauthorized traffic to traverse from the business network to the PCN.

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.

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.

What are the implications and use cases for using separate AD for each Purdue level?

Please see explanation above. In addition,

  • L4/Business/IT – Should have own domain
  • L3.5/DMZ – Recommend own domain or RODC, or read-only domain controller
  • 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 Engineering Work Station console, Maintenance station, etc.

What are the implications on connecting AV/WSUS directly, for example from DMZ to 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.

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.

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.

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.

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.

Learn more about

auditing your OT firewalls :