1201 Louisiana Street Phone: 877.303.

DATA
Suite 400 Fax: 800.864.6249
Houston, Texas 77002 Email: [email protected]

patriotSCADA Distributed Firewall

for SCADA and Industrial Networks
What Makes This New Firewall Different?

By: Jonathan Pollet

PlantData Technologies, Inc.

Keywords

SCADA/DCS Security, Control Systems Security, Distributed Firewall, SCADA Security Zones,
PLC/DCS/RTU/IED Security, patriotSCADA, patriotCOMMAND, Firewall Comparison Guide

Abstract

Over the past few years, most companies with Critical Infrastructure controlled by SCADA, DCS,
and other Process Control Systems have taken the approach to group all of their real-time
systems in an environment called the PCN or Process Control Network, and try to keep that
environment as separate and isolated as possible from the IT and Corporate Networks. While this
concept is a move in the right direction, treating the PCN environment like a black box and trying
to manage one firewall or cyber defense solution at the border with IT is not adequate to protect
from changing external and internal threats. The sensitive nature of the PLC and DCS devices
controlling the Critical Infrastructure assets require a higher level of network segmentation and
advanced defense solutions not currently recommended or available through most security firms
and IT vendors.

A new type of firewall is designed to be distributed throughout the SCADA environment, and this
white paper will describe what is unique about this new product, and compare it to common IT
firewalls on the market now.

Page 1 of 13
Table of Contents

Introduction ........................................................................................... 3
Defining the Problem ..........................................................................................................3
Figure 1 – Typical Network Diagram of SCADA and IT Networks........................................................ 4
Figure 2 – Most Only Segment SCADA and IT into Two Security Zones .............................................. 4
Distributed Firewall Approach ..............................................................................................5
Figure 3 – Segmenting SCADA Networks into Security Zones is a Better Approach .............................. 5
Design Considerations............................................................................ 6
History of the patriotSCADA Design .....................................................................................6
Agent \ Console Approach...................................................................................................6
Figure 4 – Agent \ Console Design Implementation .......................................................................... 7
Technical Specifications ......................................................................... 8
6-Layers of Security for Defense-in-Depth Firewall Agents .....................................................8
Figure 5 – 6 Layer Cyber Defense Design for Distributed Firewall Agents ........................................... 8
Firewall Feature Comparison Table ....................................................................................10
Figure 6 – Firewall Feature Comparison Table ................................................................................ 10
Bridging vs. Routing Firewall .............................................................................................11
How does Bridging Work? .................................................................................................12
Figure 7 – Bridging Firewall Flow Schematic................................................................................... 12
Hardware Specifications....................................................................................................13

Page 2 of 13
Introduction

Defining the Problem

Over the past several years, with the blackouts and increased activity levels of worms and viruses
like Blaster (aka MSBlast), there is a recognition that these systems that were previously
proprietary and isolated systems are now connected to corporate networks, and many contain
connection points from the Internet. It is also common knowledge now that the electronic
equipment controlling critical infrastructure is susceptible to failure through DoS (Denial of
Service), malformed packets, and malicious code caused by viruses, Trojans, and worms.

Cyber Security Vulnerability Assessments performed on SCADA and Process Control Networks has
exposed a pattern in the approach that many companies take in securing their critical assets.
Over 80% of these Electric, Gas, Water, and Energy companies mentioned that one firewall or
equivalent cyber defense solution between their IT Corporate Network and Process Control
Network was sufficient for maintaining the security of their critical assets under control of SCADA
and Process Control Systems.

These companies typically considered the Process Control Network as one large black box, and
tended to approach securing these environments by attempting to isolate that environment as
much as possible from any other network. While this is a good first attempt, and a move in the
right direction, there are additional cyber security solutions that should be taken under
consideration given modern external and internal threats facing these critical assets that are
connected through Ethernet and Internet-routable protocols.

On the following page, there are two diagrams shown. The first diagram shows the Logical
Network Diagram of how a typical SCADA or DCS system is networked back to the Corporate
Network. The second diagram shows how most companies view the security of their real-time,
SCADA, and process control environments. They typically only segment their network into two
environments, one for Corporate/IT, and the other for SCADA and Process Control Systems.

Page 3 of 13
 Figure 1 – Typical Network Diagram of SCADA and IT Networks

Figure 2 – Most Only Segment SCADA and IT into Two Security Zones

Page 4 of 13
Distributed Firewall Approach

While keeping the SCADA/DCS environment separate from the Corporate IT environment is a
good first step, devices like PLCs, RTUs, and IEDs that control physical equipment, should be in a
different security zone, with additional access controls for limiting access to them. The SCADA
servers and operator consoles should be in another security zone. It has been proven in research
studies, and in the cyber hardening testing that PlantData has done on SCADA equipment, that
these controllers are susceptible to crash when the network is at elevated bandwidth level, or of
if malformed network packets are sent to the SCADA software or equipment. The diagram below
in Figure 3 shows a better approach to segmenting the SCADA environment into security zones.
The small patriotSCADA agents can be installed throughout the SCADA environment to work as a
distributed firewall.

Figure 3 – Segmenting SCADA Networks into Security Zones is a Better Approach

Page 5 of 13
Design Considerations

History of the patriotSCADA Design

To understand what makes the patriotSCADA distributed firewall different, it helps to understand
the origin of its design. Over the period of three years, the SCADA Security Team at PlantData,
in partnership with DYONYX, had participated in over 20 Vulnerability Assessments and Red
Team Penetration tests on real-time control systems. Most of these environments only had one
firewall at the perimeter of the SCADA network to segment it from the Corporate IT network.
Once inside the SCADA network, the team found very little security solutions implemented. This
flat network environment, although optimum for the SCADA and control systems, made a nice
environment for planning and executing cyber attacks.

The SCADA Security Team at PlantData was also contracted to conduct intense cyber attack
penetration tests directly on several SCADA, DCS, and PLC software and hardware systems.
These systems routinely suffered crashes and complete system failure when PINGFLOOD,
malformed packets, buffer overflow, and other cyber attacks were allowed to be directed at
them. The team was also able to hijack sessions between the SCADA I/O servers and the
Operator Terminals, and even modify data being presented to the screen. Lastly, and more
importantly, the team was able to send spoofed SCADA packets directly to the PLC and RTU
hardware over Ethernet connections, and these spoofed packets changed setpoints and real-
world I/O on the local PLC and RTU controllers.

The combination of a flat network environment, and equipment and software susceptible to most
cyber attacks, made for an environment in need of a new defense solution. It was a combination
of the real world vulnerability assessment work and the penetration testing on test systems that
drove the design of the patriotSCADA product.

Agent \ Console Approach

Since many SCADA Systems are spread out over multiple locations and sites (i.e. gas compressor
stations, electric power sub-stations, tank batteries, and dehydration facilities), this new solution
would have to be inexpensive enough so that a small firewall agent could be placed at each
physical location where the end devices and controllers are installed. By separating the firewall
into a small firmware that resides in an embedded device with no moving parts, and leaving the
Management GUI controls in one console rack-mountable appliance, the Agent \ Console design
allows the firewall capabilities to be distributed out to multiple locations, but managed centrally.
It also created a method for producing a cost model that matches the environment. By keeping
the costs of the agents down below the cost of most traditional IT firewalls, these agents could
be implemented at multiple sites at a very economic cost.

Also, any violations of any of the firewall rules, from any of the distributed firewalls, can be
reported back to the Management Console for analysis and reporting. These alerts can also be
forwarded onto Syslog, HP OpenView, or other network monitoring tools. The Management
Console acts as a communications bridge to OPC so that network or security errors can be routed
to the SCADA System Data Historian and archived right along with the rest of the real-time data.

Page 6 of 13
The Agent \ Console design also allows the Console to be placed on any network at any location
in the world. The Agents have three network interfaces, and the third network interface is for
communicating with the Console. Some companies have already expressed an interest in
outsourcing the management of the patriotSCADA system, and the console can be installed
offsite at a collocation facility, where it can be monitored and maintained 24x7.

Figure 4 – Agent \ Console Design Implementation

Page 7 of 13
Technical Specifications

6-Layers of Security for Defense-in-Depth Firewall Agents

After conducting several red team penetration tests and taking the feedback from the cyber
hardening work performed on PLC and RTU equipment, PlantData developed a multi-layer
approach to securing real-time control systems software, hardware, and Ethernet-enabled plant
equipment without impacting the speed or performance of the network.

The diagram below in Figure 5 describes each defense layer inside of the firmware running in the
patriotSCADA agents. Individually, these defense layers may exist in one or more current security
solutions; however, the patriotSCADA distributed firewall is the first product on the market that
specifically addresses all of these considerations in one small embedded unit with no moving
parts.

Figure 5 – 6 Layer Cyber Defense Design for Distributed Firewall Agents

Page 8 of 13
These cyber defense layers were designed with a very intuitive interface so that a Control
Systems Engineer, with limited security knowledge, could define all of the system characteristics
of a normal running SCADA system, then lock down all other traffic. The patriotSCADA design is
the opposite of most other traditional IT security products. Most firewalls, IDS systems, and
Antivirus solutions work by coming out of the box fully open, then a security professional has to
program the systems with the configuration rules, IDS signatures, or Antivirus updates so that
the security solution knows what packets to alert on or block. These traditional IT defense
solutions require frequent updates and fine-tuning so that the product is up to date with the
latest security threats. It is a response solution to changing threats. When a new antivirus or IDS
signature is released, the updates must be quickly downloaded and enabled to so that this new
threat can be recognized and mitigated.

Since SCADA, DCS, and PLC environments are very static, and do not change much. The
PlantData engineers designed the patriotSCADA product to come out of the box with the settings
to deny or block all traffic and all ports. The Control Systems Engineer, or someone with
knowledge of the IP/MAC addresses, ports, and protocols for the SCADA System, logs into the
management console and starts defining approved hosts, ports, and protocols. Then the settings
for the approved network bandwidth thresholds and malformed packets are set. Lastly, the
administrator may want to link the management console to other network monitoring consoles or
software, and that is all that must be done to setup the system.

All of the underlining code for setting up these security layers is pre-programmed into every
patriotSCADA firewall and is operational out of the box. No complicated IOS or firewall rule set
programming is required, and there are no signatures to update. Once the initial setup is
complete, the system only needs to be updated when a SCADA computer, server, or equipment
is replaced, or if any new equipment is installed in the system. The concept is to first model only
the traffic that is allowed to let the SCADA System operate, then block all other traffic, and alert
when there is foreign unauthorized access.

A comparison guide is provided on the next page to see how this new approach stacks up to
Nokia Checkpoint and Cisco PIX firewalls.

Page 9 of 13
Firewall Feature Comparison Table

Figure 6 – Firewall Feature Comparison Table

Page 10 of 13
Bridging vs. Routing Firewall

What is the difference between a bridging firewall and a conventional firewall? Usually a firewall
also acts as a router so that the systems on the inside are configured to see the firewall as a
gateway to the outside network, and routers on the outside are configured to see the firewall as
the gateway to the protected network. A bridge is piece of equipment that connects two (or
more) network segments together and passes packets back and forth without the rest of the
network being aware of its existence. In other words, a router connects two networks together
and translates between them; a bridge is like a patch cable, connecting two portions of one
network together. A bridging firewall acts as a bridge but also filters the packets it passes, while
remaining unseen by either side.

Why would this be advantageous for SCADA environments?

§ Allows the ability to easily plug in a bridging firewall anywhere within an existing network
without changing any of the existing network routing, IP addresses, or software
configuration.
§ Protects a part of a network when you do not have control of the external routing into
your network.
§ The bridging firewall acts as a “bump-in-the-line” firewall that can be placed anywhere
on the network with minimum downtime, a key factor in mission-critical SCADA
environments.
§ A bridging firewall is undiscoverable with network scanning tools because it does not
provide any routing functions. It does not have an IP address, does not respond to ICMP
or any network scans, and it not only hides itself from the network, but anything on the
protected side of the bridge as well.
§ Does not impact throughput or performance of approved network traffic – key factor in
time critical SCADA applications for electric power.
§ Empowers Control System Engineers and Operations with the ability to segment their flat
SCADA network easily without requiring a background in security or involving IT network
administrators.
§ Since no routes have to be modified, or any IP addresses changed, a bridging firewall
can be installed very quickly without requiring the IP addresses and network
configuration in all of the end devices or controllers to be changed. Saves time and
reduces threat of downtime due to network configuration changes.
§ For those facilities or assets that share network connections with third-parties, the asset
owner can protect the SCADA system components without making any changes to the
network, which may be owned or maintained by another company.

Page 11 of 13
How does Bridging Work?

A bridging firewall implementation works by tying together two or more network interfaces. By
monitoring activity on all the attached network segments the bridge code learns which MAC
addresses are accessible from each interface and uses this information to decide which packets
to send out on each interface. The bridge code can also be setup not to listen to any network
traffic, but only pass traffic to the other side of the bridge based on bridging rules programmed
into the bridge. The interfaces attached to the bridge do not normally have an IP address
associated with them, but the entire bridge is configured as a single interface to the firewall.

As the diagram in Figure 7 shows, a bridging firewall can be placed directly in-line between
source and destination objects without modifying any of the IP addresses or routes. Installation
is simple because the Ethernet cable going into the front of the PLC or RTU is plugged into the
eth0 RJ45 port on the firewall. Another short cat5 cable can be used to go from the eth1 RJ45
port over to the front of the device. The eth2 port on the firewall is a third interface that is used
only for managing the firewall remotely. This third interface is the only one that requires an IP
address so that the device can be found by the management console. A bridging firewall can
support as many devices as the network class can support. For a class C network, it can support
up to 255 devices on either side of the firewall.

Figure 7 – Bridging Firewall Flow Schematic

Page 12 of 13
 Hardware Specifications

PatriotCommand Console
Specifications:
(Front View)
System
§ CPU: Intel Celeron 2.0GHX 478pin, 128K L2 Cache, 400MHz
FSB processor.
§ Memory: 512MB of PC3200 DDR SDRAM In Dual Channel
Configuration. 4GB max.
§ Chipset: Intel E7210 chipset
§ Network: 1 x Intel 82547GI CSA gigabit Ethernet controller;
1 x Intel 82541 gigabit Ethernet controller
§ EIDE: 2 ports support 4 devices at Ultra DMA 100 MB/sec
§ Storage: 2 Seagate 80GB SATA ST380021A model hard
drives mirrored on a 3ware 8006 RAID controller.
(Back View)
§ Video: Integrated ATI Rage XL
Chassis
§ Form Factor: Mini 1U; 14" rack-mountable IDE/SATA
chassis
§ Dimensions: 16.7"W x 1.7"H x 14"D
Expandability
§ USB: 2 x rear USB ports; 2 x USB header
§ Serial Ports: 1 x rear serial port; 1 x serial port header
§ Parallel Port: 1 x rear parallel port
§ Keyboard/Mouse: 1 x PS/2 Keyboard, 1 x PS/2 mouse
§ LAN: 2 x LAN ports, RJ-45

PatriotSCADA Agent
Specifications:
(Front View)
§ Small Embedded Single-Board Computer
§ 100/133 MHz AMD ElanSC520
§ 16-64 Mbyte SDRAM, soldered on board
§ 1 Mbit BIOS/BOOT Flash
§ Compact FLASH Type I/II socket, 8 Mbyte FLASH to 4 Gbyte
Microdrive
§ 1-3 10/100 Mbit Ethernet ports, RJ-45
§ 1 Serial port, DB9. (optional 2nd serial port)
§ Power LED, Activity LED, Error LED
§ Mini-PCI type III socket. (Back view)
(For optional hardware encryption.)
§ PCI Slot, right angle 3.3V only.
(For optional WAN board.)
§ 8 bit general purpose I/O, 14 pins header
§ Hardware watchdog
§ Board size 4.85" x 5.7"
§ Power using external power supply is 6-20V DC, max 10 Watt
§ Option for 5V supply using internal connector
§ Operating temperature 0-60 °C
§ No moving parts

Page 13 of 13