patriotscada Distributed Firewall for SCADA and Industrial Networks

1201 Louisiana Street Suite 400 Houston, Texas 77002 Phone: 877.303.DATA Fax: 800.864.6249 Email: info@plantdata.com 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 realworld 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: 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. 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 (Front View) (Back View) PatriotSCADA Agent Specifications: 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. (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 (Front View) (Back view) Page 13 of 13