This document will examine three use cases related to using Palo Alto Networks next generation firewall within an Industrial Control System (ICS) environment. The primary goal for all three use cases is to provide additional security measures to protect the ICS network. It is also important that these measures allow for automation where possible to reduce operational costs and incident response fatigue.

 

The three use cases:

• Introduce multi-factor authentication (2FA) for access to the Operational Technology (OT) networks and applications
• Auto-quarantine endpoints upon authentication failure and critical security events
• Provide encrypted conduits from ICS locations to various data centers and dynamically mesh these tunnels

Requirements

Required Item	Notes
PANOS 8	8.0.5 at the time of this document
Multi-factor Authentication	OKTA in this example
Ticketing System	ServiceNow in this example
GlobalProtect Cloud Service

 

High-level diagram depicting IT/OT boundary where the multi-factor security use cases would be applied:

 

Flow Chart for Multi-Factor Use Cases

The general flow is depicted in the chart below. In this example, administrative attention is required in order to remove an endpoint from the quarantine group. However, it is possible within PANOS version 8.x to dynamically remove as well as add a tag to the offending source traffic. This would potentially allow for complete automation in moving endpoints between quarantine and other dynamic address groups.

 

 

Configuration for Multi-Factor Use Cases

Traditionally, multi-factor authentication required that the application be capable of providing 2FA interaction. However, there are many applications that simply do not have this feature (especially legacy applications within the OT environment). It is now possible to enforce multi-factor authentication for these and any other applications by initiating the process at the network level. Specifically, PANOS version 8 provides this capability and is not dependent upon the application being 2FA aware. It is now possible to launch the MFA process when specific criteria are met within the ruleset (i.e. when users on the IT network attempt to reach applications on the OT network). If either of the authentication processes fail, access is denied.

 

The first use case is to introduce multi-factor authentication when users attempt to access applications which reside in the OT network. Users are prompted to enter their credentials on a web-based form (first authentication), followed by confrmation (second authentication) to ensure that the credential owner actually initiated the process.

First pass is through a Captive Portal login:

 

Second pass is validated out-of-band:

 

 

Add the multi-factor server profile under Device / Server Profiles / Multi Factor Authentication. Currently, there are four built-in templates for MFA providors (Okta Adaptive, PingID, and Duo v2). See screenshot for example. For detailed multi-factor authentication configuration see the PANOS 8.0 Administrators Guide: https://www.paloaltonetworks.com/documentation/80/pan-os/pan-os/authentication/configure-multi-factor-authentication

 

 

Enable additional authentication factors within an authentication profile (select the MFA server profile just created): Device / Authentication Profile:

 

 

Create an authentication enforcement object and select the Authentication Profile just created. This is under Objects / Authentication. Create a custom message users will see when prompted for the first level of authentication via Captive Portal.

 

 

Configure an Authentication Rule to trigger the multi factor authentication process. In this example we want to launch the multi factor process when traffic initiated from the IT Network is destined for the OT Network. This could be further refined by adding specific AD Groups or Users.

 

Policies / Authentication

 

 

Create a Security Policy rule which allows users to access the services and applications that require authentication. This could be further refined by adding specific AD Groups or Users and applications (i.e. Modbus, DNP3, Cygnet-SCADA, etc).

 

Policies / Security

 

 

Adding the Automation – Dynamic Address Groups

After introducing multi factor authentication, the next step is to take action upon either a failed authentication attempt, or a critical security event. In order to accomplish this, there are two features to deploy: Dynamic Address Groups and Log Forwarding Profiles.

 

Dynamic Address Groups (DAGs) allow flexible policies which adapt to changes. For example, a host may begin with a tag which places it in one address group that matches an allow rule but have its tag dynamically changed (and subsequently, moving it to a different address group) so that it matches a deny rule. This eliminates the need to continuously add/remove rules from the security policy. See the PANOS 8 Administrator’s Guide for detailed information on Dynamic Address Groups:

https://www.paloaltonetworks.com/documentation/80/pan-os/pan-os/policy/use-dynamic-address-groups-in-policy

 

To create a Dynamic Address Group go to Objects / Address Groups. This group will be empty as it will match based on a Quarantine tag for which no traffic will be tagged initially.

 

 

Next, create the required parameters to watch for within the logs. For each, create a built-in action which dynamically tags the source with a Quarantine tag.

 

Go to Objects / Log Forwarding and create a new entry.

 

 

Adding the Automation – Log Forwarding Profiles

For each failed MFA attempt, define the built-in action for dynamic tagging.

 

 

Now, add the automation of generating the service ticket. In the Forward Method, add your pre-defined HTTP server information for ServiceNow. The pre-defined HTTP server would be entered in Device / Server Profiles / HTTP.

 

Define the HTTP Server Profile for ServiceNow.

 

 

Click the Payload Format tab to use the built-in logging format for ServiceNow.

 

Click on Authentication and select ServiceNow Security Incident from the dropdown. The relevant authentication failure information will be sent to ServiceNow in a format readily consumable by the ServiceNow HTTP-based API.

 

 

Go back to Objects / Log Forwarding to add the automation to the profile for failed MFA attempts and add the HTTP server created for ServiceNow.

 

 

When finished with the first use case (MFA failures), add the second use case (Quarantine OT hosts with critical security events).

 

 

Add the HTTP server profile for ServiceNow.

 

 

Final Log Forwarding Profile will look something like this:

 

 

Add the newly created Log Forwarding Profile to the security rule which allows the IT-to-OT traffic.

 

 

The use cases listed here require manual intervention to move isolated hosts from quarantine back to production. For other, less sensitive areas of the network, this could be dynamic as the built-in actions within log forwarding can also remove tags (i.e. remove a quarantine tag). To view source IP addresses which have been placed in the Quarantine DAG, go to Policies, find the rule which contains the DAG and hover over the DAG to see a drop-down. Select the drop-down, value, and more to see the list and to take action on individual sources.

 

 

Refer to the following page for maximum number of dynamically registered IP addresses available per plaform: https://www.paloaltonetworks.com/documentation/80/pan-os/pan-os/policy/use-dynamic-address-groups-in-policy

 

Dynamic Meshing of IPSec Tunnels

When there are many remote ICS/SCADA sites which require IPSec connectivity to multiple data centers (MPLS or over the Internet), it can be administratively burdensome to configure and maintain. This is especially true when fully meshed sites are a requirement. Rather than implement another appliance in front of the firewall to handle routing and dynamic tunnels, there is an elegant solution using the existing Palo Alto Networks firewalls or existing edge devices capable of building IPSec tunnels.

 

GlobalProtect Cloud Service offers a managed, scalable service to dynamically mesh remote ICS/SCADA sites with IPSec/SSL. This removes the complexity from cloud deployment (firewalls, portals, and gateways) while allowing for central security policy management via Panorama. The service auto-scales as demand increases and decreases so teams can focus on policy/incident management rather than the aspects of cloud deployment.

 

 

This greatly simplifies the data center architecture. Site-to-site and site-to-branch routing is handled in the GlobalProtect cloud service. The service may be incorporated to an overall corporate strategy when IPSec and remote access is required. Remote sites could be thought of as ICS/SCADA locations, remote offices, mobile workers, or even other public cloud services such as Amazon, Azure, Google, etc.

 

 

GlobalProtect Cloud Service Components

This service is configured through a Panorama plug-in and contains the following components:

 

 

Note that the GlobalProtect Cloud Service also includes a cloud-based logging service. The activity recorded within the firewalls, portals, and gateways are logged to this service. Panorama simply ‘points’ to this service like any remote log collector for queries and reporting.

 

There are a few licenses to retrieve for the service: GlobalProtect Cloud Service for Remote Networks and Mobile Users along with the Logging Service.

 

 

Using the new Panorama plug-in feature in version 8.x, install the latest GlobalProtect Cloud Service plug-in (available on the customer support portal).

 

 

Setup the cloud service and connect the main HQ data center to the service. Note that existing device groups and templates may be used which would include ICS/OT environments.

 

 

Configure the remote sites (ICS/SCADA) to connect through IPSec/SSL conduits.

 

 

Final step would be to configure security policies as usual.

 

A natural addition to these scenarios would be the implementation of anti-phishing and credential theft features of PANOS v8. For those who wish to have an even tighter security posture, it is possible to control OT access at the application level along with user-ID. For example, not everyone who accesses OT applications would need to write to registers/coils. This can be controlled by creating a security policy to strictly allow Modbus read activity for one group of OT users and Modbus write only for those who need it.

 

 

Summary

There are many other use cases for using various components of the Palo Alto Networks platform in securing ICS/SCADA environments. The three listed here cover specific requirements gathered from companies in the oil and gas sector.

 

This document has merely shown three use cases related to deploying Palo Alto Networks next generation firewall within an Industrial Control System (ICS) environment. The first scenario examines the use of the firewall to enforce multi factor authentication for users accessing the OT network. These users will be quarantined upon second factor authentication failures.

 

The second scenario examines activity from an already authenticated user accessing the OT network. This user may be quarantined upon a ‘critical’ security event and could even be quarantined upon a ‘high’ security event depending on policy. Such events would include a broad range of triggers (i.e. command-and-control activity, attempted access to known bad domains/IPs/URLs, vulnerability events such as heap buffer overflows etc and more). When the source user is triggering such events, they would be immediately cut off (quarantined tagged) from the OT network. In each of the first two scenarios, the source user is quarantined until an administrator removes them from the quarantine group (i.e. removes the tag).

 

The third use case focuses on operational effeciencies by building dynamically meshed IPSec/SSL conduits from the remote ICS/SCADA locations to the primary and/or secondary data center locations (or more). The complexities of scaling up and down are handled by the GlobalProtecl Cloud Service. This includes the auto deployment of firewalls, portals, gateways, and logging – all securely within the cloud. Security policies, reporting, and queries continue to be performed centrally by Panorama.

 

The primary goal for all three use cases is to provide additional security measures to protect the ICS network. These measures allow for automation to reduce operational costs and incident response fatigue.