John Mulder

Moses Schwartz

Michael Berg

Jonathan Van Houten

Jorge Mario Urrea

Alex Pease

Analysis of Field Devices Used in Industrial Control Systems

Keywords: Industrial control systems, device analysis, firmware analysis

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Industrial control system (ICS) field devices monitor and control physical processes in the critical infrastructure. Prior to Stuxnet [START_REF] Falliere | Stuxnet Dossier, Symantec[END_REF], ICS security efforts focused primarily on human-machine interfaces (HMIs) and other supervisory control and data acquisition (SCADA) software. The high-profile attack, however, demonstrates the lack of security associated with ICS field devices. Meanwhile, there has been relatively little research focused on analyzing vulnerabilities associated with these critical assets.

Although many security solutions exist for analyzing software on commodity personal computers, limited tools are available and only a shallow understanding exists of the vulnerabilities related to ICS field devices. The vulnerabilities, however, do exist -initial research on ICS field devices has identified critical security flaws (e.g., hard-coded passwords extracted from firmware images, unauthenticated firmware uploads, multiple unauthenticated interfaces, and weak password hashing) [START_REF] Beresford | Exploiting Siemens Simatic S7 PLCs[END_REF][START_REF]Industrial Control System Cyber Emergency Response Team (ICS-CERT), Schneider Electric Quantum Ethernet Module Multiple Vulnerabilities[END_REF][START_REF] Moore | Shiny old VxWorks vulnerabilities, Metasploit (community[END_REF][START_REF] Peck | Security testing, vulnerabilities and exploits in operating systems used in control system field devices[END_REF][START_REF] Peck | Leveraging Ethernet card vulnerabilities in field devices[END_REF][START_REF] Santamarta | Reversing industrial firmware for fun and backdoors, Reversemode[END_REF]. As an example, in January 2012, a coali-tion of security researchers released a set of zero-day vulnerabilities targeting seven embedded ICS devices [START_REF] Peterson | Project Basecamp at S4, Digital Bond Blog, Digital Bond[END_REF]. Therefore, it is imperative that future security research focus on the analysis of the firmware and hardware implementations.

This paper describes a process for analyzing ICS field devices. Specifically, the components of various programmable logic controllers (PLCs) are examined to derive fundamental attributes that relate to common design characteristics. Note that this analysis is not intended to identify specific vulnerabilities or design flaws. Rather, it seeks a deeper understanding of device design, which is a prerequisite for identifying attack surfaces. The approach is consistent with an adversarial viewpoint -no attempts were made to leverage inside knowledge or obtain vendor cooperation. The analysis of a device was performed by disassembling the device, cataloging its electronic components and creating a functional diagram. The electrical connectivity between the pins was then examined to verify device interconnections. After characterizing the hardware, several techniques were used to extract the firmware, including locating firmware updates, connecting via debug ports and reading the flash memory contents using a chip programmer. Finally, methods were explored for examining the backplanes used for communications between PLC subcomponents.

PLC Overview

This paper primarily focuses on PLCs; however, the methodology and results are applicable to a wide range of embedded devices. Indeed, many types of automation equipment have similar control capabilities. For example, the primary automation components used in electrical substations are remote terminal units (RTUs). RTUs perform data aggregation and protocol conversion for the other devices in a substation. Many RTUs, sometimes called real-time automation controllers or substation controllers, execute the same control logic as a PLC. Note that PLC logic is usually written in a language defined in IEC 61131-3 such as Ladder Logic or Instruction List. The primary differences between PLCs and RTUs are in their target markets and configuration details (e.g., input and output specifications).

Modular PLCs, as demonstrated in Figure 1, comprise discrete modules that are connected via a backplane. The processor module reads values from the communications and input/output (I/O) modules, interprets and executes the control logic, and writes values to the communications and I/O modules. The communications modules dissect complex communications-protocolspecific code. Because some control system protocols are extremely complex, communications modules may possess significant processing power and intelligence. I/O modules convert signals between low voltage (3.3V DC or 5V DC), low current (milliamps) control logic and high voltage (24+V DC), high current (amps) process control. Additionally, analog I/O modules contain analog-todigital converters and digital-to-analog converters.

Hardware Analysis

PLC hardware is characterized by disassembling a device, photographing and cataloging the components, researching the parts, and determining the electrical connectivity between components. Although some embedded devices have minimal components that are easy to identify, even a simple PLC has many electronic parts. As such, a heuristic technique was used to discern the components of interest (e.g., memory and processor). The heuristic includes pin-count (higher is more interesting), type of chip package (ball grid array is often used for high-end components), proximity to other interesting parts, and chip markings. Although the heuristic technique approximates the significance of each component, it is adequate for this research effort.

Internet search queries were used for component identification, in particular, to correlate model numbers, brand markings, chip packages and pin counts. After identifying the components, a logical view of the PLC was derived. Component functions and connectivity were discerned using technical data sheets and tracings on the physical circuit card. Findings were verified using an ohmmeter to determine the connections between pins on different chips.

Example Device Analysis

An Allen-Bradley ControlLogic (Logix) PLC manufactured around 2005 is used to illustrate the methodology (Figure 2). It is one of the most popular lines of modular PLCs in North America. The PLC chassis is shown at the top of the Figure 2; the Logix 5555 processor is at the bottom left and the EtherNet/IP modules are at the bottom right. The PLC has a chassis with a power supply and slots for a control module, network communication modules and I/O modules. Figure 3 shows the logical diagram for the connections between the modules and components. This representation clarifies the roles of the various PLC components.

Annotated photographs help clarify the physical layout of the device components -with sufficiently detailed photographs, it is possible to trace the connections on the top and bottom layers of the printed circuit board. Figure 4 shows an annotated photograph of the Logix 5555 processor module and Figure 5 shows an annotated photograph of the EtherNet/IP module. The photographs are each linked to part lists in Tables 1 and2, respectively. The part name references the data sheet descriptor. The manufacturer part number is a combination of the brand and part number based on the data sheet, when available, or trademarks found on a chip. Note that the markings are the same symbols that are found on the surfaces of the chips.

General Findings

The majority of field devices we analyzed used production chips from large manufacturers; only a few of the chips were variants produced for a specific vendor. Additionally, we discovered that configurations of flash memory and RAM are consistent with other embedded systems and typically use fairly sim- ple two-to four-layer boards, whereas normal personal computer boards often have seven layers. Despite this simplicity, the interconnections can be difficult to discern primarily because the board layout is driven by efficiency. The most common processor architectures identified for ICS field devices were ARM, PowerPC and Motorola 68k. However, we also discovered that many devices are based on x86 processors, sometimes using commodity PC/104 form factor embedded computers to provide processing power. Multiple processor architectures on a single board are also common. For example, one device uses a Freescale PowerPC main processor and a separate ARM backplane communication processor. This is not a surprising configuration; however, deep analysis efforts require expertise in multiple architectures.

Firmware Analysis

The analysis of PLC device firmware differs from the typical analysis of software (binaries). In general, the toolset for personal computers is not well suited to firmware analysis. Additionally, it may require considerable effort to merely identify the processor and architecture of an embedded device.

The main challenges in understanding embedded devices stem from the diversity of components. Each device uses a different combination of processor architecture, embedded operating system, board design, backplane connector, protocol and logic representation. Many vendors use custom-built components, such as a system-on-a-chip (SOC) main processor, that do not have openly available documentation. The analysis is more difficult because SOCs and custom components are potentially unique, poorly documented and few analysts have experience with them. Unlike "normal" software analysis, the analysis of firmware can depend on chip-specific features. In the case of firmware, vulner- Analysis can proceed quite rapidly when the processor architecture is easy to determine. However, when the processor/operating system combinations are difficult to discern, the initial identification step in device analysis can take a significant amount of effort. To simplify the task, we developed a process for analyzing PLC device firmware that focuses on obtaining firmware images and identifying the processor architecture. The firmware analysis process is outlined in Figure 6.

Acquiring Firmware

We investigated four methods for acquiring firmware:

Read directly from the device using a debug port.

Read directly from flash memory using a chip programmer.

Unpack firmware update files.

Capture network traffic during a firmware update.

Each method for obtaining firmware has inherent difficulties. Connecting via debug ports (e.g., JTAG) works for some devices; however, it is often the case that the interfaces are disabled or non-standard protocols are used. Reading firmware from flash memory consistently worked to obtain the firmware, but unusual memory layouts can make reassembling the entire firmware extremely difficult.

Vendor firmware updates were often not available for the devices of interest to allow the unpacking of update files. In situations where the updates were available, the firmware contents had to be extracted and reconstructed. Additionally, firmware obtained by capturing network traffic from an update or backup mechanism had to be extracted from the data sections of multiple network packets. Whether they are captured on disk or reconstructed from network captures, the firmware updates obtained from vendor websites often did not represent the actual layout and configuration of the firmware on the devices.

4.2

Identifying the Device Architecture

Identifying the processor and memory architecture of a device was one of the more challenging tasks. In some cases, processors can be identified by their chip markings. However, even when a processor is identified, the memory architectures can vary considerably, especially the flash memory located on the microcontroller, the separate flash and memory boards with a field-programmable gate array (FPGA) interface, and the traceable direct connections between microprocessor and memory. Depending on the design or manufacturing date of a device, it may be possible to guess the likely processors based on their popularity at the time, the relationships between companies, and the processors used in similar devices.

In some cases, we identified the processor type by comparing byte patterns to function calls, register usage and instruction frequency for a likely processor. For example, at the beginning of a function call there is often a store instruction to preserve non-volatile registers and a load instruction is often present at the end of a function. After a processor is tentatively identified, the result can be verified by comparing the firmware code with other code for the processor. The start of function calls, register usage and instruction frequency often facilitate this verification.

Communication Backplane Analysis

Analyzing the firmware for every PLC or field device would be extremely time-consuming due to the wide range of hardware and firmware used even within a single product line. However, network protocols are common to a wide range of PLCs. In fact, we discovered that modular PLCs appear to use variants of common network protocols for backplane communications between modules. This means that the backplane presents an avenue for analyzing a wide range of PLCs. Note, however, that backplane analysis is not a replacement for firmware analysis; rather, the two approaches are complementary.

Identifying Physical Properties

Identifying the pin spacing and layout provides the initial structure of the backplane and allows an analyst to create custom connectors for data collection. A continuity tester and voltmeter can be used to identify various signals on the PLC backplane, which provides insight into the likely locations of ground pins and some power pins. It is necessary to identify the voltage on each pin to avoid damaging the logic analyzer and to further narrow the pins of interest. Additionally, a voltmeter can be used to identify the operating voltage of each pin on the backplane through startup and normal operation of the PLC.

Analyzing Pin Logic

After identifying the backplane pins and physical properties, a logic analyzer may be used for deeper analysis. The logic threshold and sampling rate are required to obtain clean captures of normal backplane traffic. These are determined through trial and error. Captures from the logic analyzer may be reviewed to form hypotheses about the use of each pin. Some possible signals of interest include clock-enable, end-of-frame, frame-header, clock and data. The packet timing is first determined by measuring the length of packets and gaps between packets. The backplane traffic is then monitored under several different hardware configurations by removing and reordering modules in the PLC. From these captures, it is possible to identify the modules that created the various packets.

Translating Backplane Traffic into Bytes

After the data signals have been identified, the analysis of the transmitted data can begin. Logic analyzer software can be used to export the backplane traffic captures to the comma-separated value (CSV) format. The presence of a signal (i.e., voltage above the determined threshold) is represented as a binary one and the absence (i.e., voltage below the threshold) is represented as a binary zero. A simple script can be used to parse the CSV file, translate the binary signals into bytes and identify the header and data sections. If the backplane sends bytes in parallel, it is necessary to identify the order of data pins. This is accomplished by testing different combinations and searching for data bytes that match known patterns (e.g., ASCII, low digits or network protocol headers).

Analyzing the Backplane Protocol

In order to understand the parser byte output, it is necessary to analyze the backplane protocol. The first step is to determine if the protocol is openly documented. The protocol specification identifies the required fields and unique field values, which can help categorize packets. If software implementations of the protocol are available, they can be used to determine the structure of conversations and packets. Additionally, a comparison between network packet captures and backplane traffic captures can provide insight into the use of some fields; this is especially useful when the captures were taken during the same time period. In our experience, PLC backplanes are often based on network protocols used by PLCs to communicate with external entities.

Dissecting Backplane Traffic

The final step in backplane analysis is to dissect the backplane traffic. A protocol traffic dissector (e.g., Wireshark) can automatically identify some fields in request and response packets. However, most traffic dissectors do not handle backplane protocols. Therefore, it may be necessary to develop a custom dissector program for analysis.

We have developed a dissector program that consists of a pre-processing script and a protocol field identifier. The pre-processing script reads in binary dumps, identifies packet boundaries, removes collection timestamps and writes ASCII-encoded hex values. The protocol field identifier reads in ASCII-encoded hex values, removes stray line noise, identifies known headers and payloads, and prints a human-readable summary of the packets.

Conclusions

Attack techniques that target PLCs will continue to grow in sophistication. As security mechanisms are developed to protect the application layer, attackers will begin to exploit lower levels of abstraction. It is imperative that the security community prepare for this threat and develop automated tools and techniques. The techniques described in this paper can be leveraged to develop automated tools for performing dynamic analyses of PLCs used in the critical infrastructure.

Figure 2 .

 2 Figure 2. Allen-Bradley Logix PLC.

Figure 4 .

 4 Figure 4. Allen-Bradley Logix 5555 processor module (annotations in Table1).

Figure 5 .

 5 Figure 5. Allen-Bradley EtherNet/IP module (annotations in Table2).

Figure 6 .

 6 Figure 6. Process for analyzing embedded device firmware.

Hardware Software PLC Chassis and Backplan Processor Module RAM Flash CPU Communications Module RAM Flash CPU Protocol Chip Protocol Port I/O Module Relays Registers Logic Operating System Backplane Driver Ladder Logic Operating System Backplane Driver Protocol Driver Figure

1. Generic modular PLC.

Allen-Bradley 1756-A7 B Chasis Power Supply Logix 5555 Processor Memory Board Flash Flash Flash Flash Flash Flash Flash Riser Riser Flash

			EtherNet/IP Module
			Ethernet Transceiver	RJ45
			EEPROM
	Philips ARM Main Processor		CPLD Flash	Digital I/O Module	Analog I/O Module
	1MB SRAM	Flash	Freescale CPU32+ 25MHz Comm.	RAM
			Controller
	1MB SRAM
	Philips ARM Backplane Comm.	Clock	Philips ARM Backplane Comm.
	Processor		Processor
	Backplane		Backplane
	Connector		Connector

Backplane Figure 3. Logical component diagram of the Allen-Bradley Logix PLC.

Table 1 .

 1 Allen-Bradley Logix 5555 processor module part list (see Figure4).

	Part Name	Manufacturer	Markings
		Part Number
	! Backplane	NXP (Philips	PHILIPS ARM
	Communications	Semiconductors)	VY21422E
	Processor	VY21422E2	Y43729Y1 03
		(Customer-specific	KP0250 E
		product; Discontinued	MIDRANGE P3E
		31 Dec 2005)	943631-64
	! Main Processor	NXP (Philips	PHILIPS ARM
		Semiconductors)	VY21754A
		VY21754A2	Y35737Y1 08
		(Customer-specific	KPr0224 A
		product; Discontinued	ARGUS-R2.1
		31 Dec 2005)	943881-71
	! Backplane Connector
	! 1M High Speed	Hitachi HM621864HB	JAPAN 0133
	SRAM		HM621864HBLJP-20
			00007NN0
	! 4 Mb Single Supply	STmicroelectronics	M29F040B
	Flash Memory	M29F040B	45K1
			585200210
			SINGAPORE
	! Y2K-Compliant	Dallas Semiconductor	DALLAS
	Watchdog	DS1501 (May also be	DS1501YEN
	Real-Time Clock	branded MAXIM)	0247A6
			045AM
	! 32 MB CMOS 5.0V	AMD AM29F032B	AM29F032B
	only, Uniform	(Made by Spansion)	-90EI
	Sector Flash		0113DPB H
	Memory		1998 AMD
	! Additional Flash Memory

! Riser to Memory Board abilities in startup and interrupts are just as interesting as vulnerabilities in network code and application logic.

Table 2 .

 2 Allen-Bradley Logix 5555 EtherNet/IP module part list (see Figure5).

	Part Name	Manufacturer	Markings
		Part Number
	! Backplane	NXP (Philips	PHILIPS ARM
	Communications	Semiconductors)	0102 y21230Y1
	Processor	VY21086-2	VY21086-
		(Customer-specific	Mid range 2.1
		product; Discontinued	943361-62
		31 Dec 2005)
	! MC68360 QUad	Freescale Semiconductor	MC68EN360CEM25L
	Integrated	MC68360 (CPU32+	OK36E IQAC0049
	Communication	architecture, 25 MHz)	KOREA
	Controller (QUICC)
	! Backplane Connector
	! Enhanced Ethernet	Freescale Semiconductor	MC68160 AFB
	Transceiver	MC68160A	HGR0045
	! 5V Byte Alterable	Xicor X28HC64	XICOR
	EEPROM		X28HC64JI-90
			Cy0047
	! 1M x 4-bit CMOS	Hyundai HY514400A	HY514400A
	DRAM	(Eight total)	LJ-60
			9751C KOREA
	! 5V FlashFile	Intel 28F008SA (Sticker	PA28F008SA
	Memory	covering this chip shows	85
		Ethernet MAC address)	U0200321W
			(M)(C) '92 '96
			Flash
	! High-Density EE	Lattice Semiconductor	Lattice
	CMOS	MACH210A	MACH210A-
	Programmable		10JE -12JI
	Logic		B023PE2

Acknowledgements

This research was supported by the Laboratory Directed Research and Development (LDRD) Program at Sandia National Laboratories, Albuquerque, New Mexico. Sandia National Laboratories is a multi-program laboratory managed and operated by Sandia Corporation, a wholly owned subsidiary of Lockheed Martin Corporation, for the U.S. Department of Energy National Nuclear Security Administration under Contract No. DE-AC04-94AL85000.


Lucille Mcminn

Jonathan Butts

A Firmware Verification Tool for Programmable Logic Controllers

Keywords:

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

The critical infrastructure depends on secure, reliable supervisory control and data acquisition (SCADA) systems that provide critical control, communication and monitoring capabilities over geographically dispersed locations [START_REF] Boyer | SCADA: Supervisory Control and Data Acquisition[END_REF]5]. Because SCADA systems are increasingly interconnected via unsecured networks, security solutions have focused on creating logical and physical boundaries between systems and the network layer [START_REF]Managing Information Security Risk: Organization, Mission and Information System View[END_REF][START_REF] Stouffer | Guide to Supervisory Control and Data Acquisition (SCADA) and Industrial Control Systems Security[END_REF]. However, even with network isolation, additional attack ingress points have manifested themselves. Indeed, attackers are increasingly leveraging non-traditional means to compromise SCADA systems [START_REF] Schwartz | Control System Devices: Architectures and Supply Channels Overview[END_REF].

Current attack response and mitigation tools are inadequately tailored to SCADA systems [START_REF] Wilshusen | Cybersecurity: Continued Attention Needed to Protect Our Nation's Critical Infrastructure[END_REF]. In many cases, the available resources are IP network tools that have been adapted to SCADA environments (e.g., packet capture tools, general operating system analysis tools and network-based intrusion detection systems). Although these tools and systems provide protection in a broad sense, tailored security solutions are needed to address emerging threats specific to SCADA systems. Perhaps the most pressing concern is verifying the proper operation of field devices, such as programmable logic controllers (PLCs), that directly monitor and control physical systems. These devices typically operate "below" the network layer and have few security mechanisms. As demonstrated by Stuxnet, manipulation of these devices can have direct physical consequences.

This research describes a tool that helps validate PLC firmware. Firmware, in the most basic sense, is fixed microcode that provides a bridge between the hardware and programmable software on a device. An attacker who can gain access to and manipulate firmware has full control over the functionality of the device and can potentially mask actions from detection. The tool described in this paper helps validate firmware and ensure that any attempt to alter the firmware is detected. The tool is adaptable and portable. Its ability to quickly and safely interface to a computer in order to analyze data sent to a PLC makes it a viable security application in diverse SCADA environments.

Background

Most critical infrastructure protection strategies leverage traditional network security constructs. Firewalls and intrusion detection or prevention systems are used to implement a defense-in-depth security strategy. Many SCADA-systemspecific solutions engage encryption to achieve confidentiality [START_REF] Gilchrist | Secure authentication for DNP3[END_REF][START_REF] Pal | Cryptographic key management for SCADA systems: An architectural framework[END_REF], but such approaches make it more difficult to audit network traffic [START_REF] Shaw | Cybersecurity for SCADA Systems[END_REF]. Other security solutions often require the modification or addition of system components, which can hinder real-time performance or may be infeasible for large-scale SCADA systems in the field [START_REF] Basile | FPGA-based remote-code integrity verification of programs in distributed embedded systems[END_REF][START_REF] Jakobsson | Practical and secure software-based attestation[END_REF][START_REF] Morris | A retrofit network transaction data logger and intrusion detection system for transmission and distribution substations[END_REF][START_REF] Song | OMAP: One-way memory attestation protocol for smart meters[END_REF].

While network defense is critical to security, network-based attacks are unlikely to be the primary method of exploitation in the future. Stuxnet infiltrated a non-networked environment via a nontraditional vector -a USB device [START_REF] Falliere | Exploring Stuxnet's PLC Infection Process, Symantec, Mountain View[END_REF]. Indeed, because critical infrastructure assets are high value targets, an advanced persistent threat can be expected to find an input vector to compromise even the most secure system [START_REF] Gao | On SCADA control system command and response injection and intrusion detection[END_REF][START_REF] Gorman | Computer spies breach fighter-jet project[END_REF][START_REF] Wilshusen | Information Security: Cyber Threats and Vulnerabilities Place Federal Systems at Risk[END_REF]. Considering the variety of non-network-based input vectors, security must be applied beyond the network layer [START_REF] Schwartz | Control System Devices: Architectures and Supply Channels Overview[END_REF].

In SCADA systems, PLCs are field devices that directly connect to physical equipment. The devices control equipment and report data about their operation to remote monitoring stations. The PLCs themselves are typically monitored via a remote human machine interface [START_REF] Bolton | Programmable Logic Controllers[END_REF]. As demonstrated by Stuxnet and other recent attacks [START_REF] Falliere | Stuxnet Dossier, Symantec[END_REF][START_REF] Turk | Cyber Incidents Involving Control Systems[END_REF], a PLC under the control of a malicious entity can have devastating effects.

A PLC presents three main targets for attack: hardware, firmware and logic program. Hardware is the lowest layer of abstraction and, at some level, must be trusted. Hardware security requires a trusted supply chain or methods for thoroughly testing the device. In this research, we consider firmware, which includes the PLC operating system, to be the lowest electronically-modifiable layer of a PLC. Note that some PLCs do not have modifiable firmware and others have additional modifiable levels such as a reprogrammable BIOS. Nevertheless, the basic methodology presented in this paper can be used for these architectures, where the lowest modifiable layer is synonymous with firmware.

This research specifically focuses on devices with modifiable firmware and logic program layers. Logic program modifications alter PLC functionality and can be performed fairly easily by accessing the PLC management software. Manipulations of PLC programs, however, can be identified during an inspection. On the other hand, PLC firmware modification is the most intrusive and least detectable attack -there are no easy methods to extract and verify the firmware after it is loaded on a PLC [START_REF] Stradley | The electronic part supply chain and risks of counterfeit parts in defense applications[END_REF]. As shown in Figure 1, the problem is exacerbated by the many potential input vectors that enable firmware alteration (e.g., programming computers, SCADA control systems and firmware update software). Indeed, any access point to a PLC or access to firmware code to be uploaded is an avenue for altering PLC firmware.

Tool Design and Evaluation

A tool for verifying that a source device is sending unmodified firmware to a PLC must have three primary features: (i) ability to capture communications data; (ii) ability to analyze captured data; and (iii) ability to determine the validity of the firmware. The tool, which is positioned between the sending device and the PLC, must capture communications data without impacting PLC operations. After the data capture, the tool must analyze the data to determine if the firmware is unmodified.

In the most basic form, the identification of modified firmware is accomplished by comparing the firmware under test with a known good firmware version. For our purposes, we assume a known good baseline version is available for comparison. Note that simple hash comparison for firmware is not as straightforward as checking for modified files in a traditional operating system. Indeed, the requirements to capture and analyze the data as it is being loaded and then perform the comparison render firmware validation nontrivial.

Another important feature is to emulate PLC communications and verify the unmodified firmware independently without the need for a PLC. This type of independent verification is critical to tool portability as it enables implementation on a generic personal computer or mobile computing device for multiple PLC and firmware instances.

Evaluation Environment

The environment for evaluating the verification tool used a standard Windows XP personal computer and an Allen Bradley FlexLogix 5434 PLC. The personal computer emulated a programming or maintenance system designed to upload the RSLogix firmware. The upload computer had the Rockwell Software RSLogix 5000 suite installed as well as ControlFLASH 9.00.015, the firmware loading program. For the initial baseline capture, the verification tool was connected to the primary communication line via a passive serial adapter tap, enabling the interception of communications data while preserving communications between the uploading computer and PLC. The serial port was configured for the serial data capabilities of the PLC, specifically a baud rate of 19200, eight data bits, no parity and one stop bit. Figure 2 shows the environment used for the initial baseline capture.

During the baseline capture, the uploading computer was connected directly to the PLC with the corresponding DF1 driver controlling communications exchange on the uploading computer side. Firmware version 15.06.01 was loaded on the PLC with the baseline firmware file and the corresponding binary files stored in the ControlFLASH program directory. Each individual ControlFLASH upload was executed in an identical manner using the same version and the same selection method to eliminate variations in the serial data transfer. Data capture started when the ControlFLASH program was opened and ended when the firmware upload was announced as having been completed.

The verification tool was initialized using two captures to create a known good baseline. During this initial capture phase, a firmware load from the uploading computer to the PLC was captured using the serial line. Thus, the verification tool received all the transferred data in a passive manner. The tool used a multithreaded environment to capture serial port data from each line as soon as it became available and stored the data in a binary format. The captured data was then separated into data sent from the firmware uploading computer and reply data sent from the PLC. Note that the data from the uploading computer contained the uploaded firmware bytes.

The entire firmware loading process was executed and captured twice. This allowed the capture program to identify variable protocol packet fields. The two captures were then used to create a baseline for communications. The communications were parsed and the variable bytes were checked against typical protocol field patterns [START_REF] Butts | DF1 Protocol and Command Set: Reference Manual[END_REF][START_REF]Handbook of Networked and Embedded Control Systems[END_REF][START_REF]IEEE Standard for Electric Power Systems Communications -Distributed Network Protocol (DNP3)[END_REF][START_REF] Modicon | Modicon Modbus Protocol Reference Guide, PI-MBUS-300 Revision J[END_REF]. After all the differences were accounted for, a protocol profile was created, which contained the pattern for communications. The pattern was then applied to the received data in order to emulate future communications.

After the firmware has been loaded on the PLC, the PLC can be taken out of the communications setup and the emulation environment can be implemented by directly connecting the uploading computer to the verification tool (Figure 3). The emulator may then be used to capture and verify subsequent firmware uploads. Note that the emulation environment enables an independent system to evaluate the firmware without the need for the PLC. Indeed, this configuration allows multiple PLC platforms and firmware versions to be validated on a single system without impacting system operations.

Design

The verification tool was designed in Microsoft Visual Studio to execute on the Windows 7 operating system. The program utilizes two separate serial ports for data capture, where each port is monitored by a thread. The protocol packet field format is not hard coded; instead, it is adapted through analysis of the captured communications data.

The captured data is first grouped into similar packet-like segments. The groupings are based on a start field block consisting of the maximum possible length that occurs a maximal number of times throughout the captured data -both these traits are indicative of a start field block.

A similar method is used to find end field blocks. Note that start/end blocks for the PLC and uploading computer are identified independently. This is because the start/end field blocks may not be the same between the two devices.

After the packet blocks are formed, field mismatches are identified between different communications captures and are accounted for by stateful packet fields. The analysis process checks for typical stateful fields including a BCC error correcting code and a packet identification byte that is sent by the computer and echoed back by the PLC. Escape bytes are also checked because escaping bytes may not be included in the checksum.

The program uses a brute-force parsing method to find optimal field matches. During the evaluation, data captures averaged 2 MB with parsing taking an average of ten minutes (the parsing time would increase for larger data captures). After the initial parsing, the protocol profile that is created is saved and reloaded for future execution to reduce the subsequent run time. Note that the duration of a firmware upload does not change because this is determined by the serial baud rate and the firmware data size.

Given a known good baseline configuration, the emulator is connected to the firmware upload computer directly, replaying PLC responses in accordance with any stateful protocol modifications. The capture program sends responses after each packet is received and can independently induce a firmware upload without the presence of a PLC.

After the uploading is complete, a verification check is performed on the captured communications, validating the received firmware bytes. If all the stateless bytes are the same and the communication matches the baseline communication profile, then it can be concluded that the firmware upload is consistent with the baseline and that the firmware is unmodified.

More thorough checking of the uploaded capture can be performed if the protocol standards are known. All the packets that contain the command to upload firmware packets are parsed to reproduce the loaded firmware file byte-for-byte. This is a more thorough check because it uses prior protocol knowledge to isolate and reproduce the uploaded firmware. The tool has this capability on full-duplex DF1 with the embedded Common Industrial Protocol [START_REF] Butts | DF1 Protocol and Command Set: Reference Manual[END_REF][START_REF]Handbook of Networked and Embedded Control Systems[END_REF].

Evaluation Results

The tool was evaluated using two firmware versions of FlexLogix 5434. The two sets of captured data for protocol analysis were separated by an intermediate period of transferred data to account for any slow changing packet identification variables. All the communications data was successfully captured and parsed into packets using simple optimization algorithms for each variable field. Several versions of modified or incomplete firmware were uploaded, each of which was detected successfully. Additionally, all instances of unmodified firmware were uploaded without any false positive errors.

Analysis

Parsing, verifying and emulating serial communications between a computer and a PLC require no system modifications, but they provide a thorough security measure. Directly verifying serial data at the last point between the external system and the PLC provides increased assurance that any modifications from the firmware uploading device or any of its input vectors would be identified. Because the firmware uploading procedure follows a deterministic progression, modified firmware can be detected by comparing each new upload against the baseline, even with stateful protocol packet fields. In every test instance, the verification tool was able to identify all the possible outcomes associated with firmware uploads:

If the firmware is modified to contain at least one more byte or one less byte, then the modified upload contains at least one more byte or one less byte than the baseline.

If the firmware is modified but still contains the same number of bytes as the previous firmware, then it can be concluded that these bytes are either different from the bytes in the original firmware, or the bytes are in a different order, or both. Therefore, the corresponding packet bytes would be modified in the same manner and must be different from those in the baseline.

If the firmware is unmodified but the firmware loading program is changed to send modified data, then any changes that correspond to either of the two previous situations are detected.

If protocol fields are changed so that the load occurs in an identical manner as the baseline but the function codes are changed (e.g., a "store byte" command is changed so that the store is no longer executed, modifying the firmware bytes after they are stored on the PLC instead of prior to upload execution), then the modified function codes are detected as being modified from the baseline function codes.

If there are no detected differences, then it can be concluded that the uploaded firmware is the same as the original firmware.

Discussion

The verification tool is currently limited to capturing serial data; however, a similar design can be implemented for other media. While there are many possible configurations for SCADA control devices, the majority of these devices use RS-232, which renders this solution feasible for use on a range of systems [START_REF] Bolton | Programmable Logic Controllers[END_REF][START_REF] Schwartz | Control System Devices: Architectures and Supply Channels Overview[END_REF].

The firmware is the lowest electronically-modifiable level of a SCADA control device. Indeed, firmware validation is the first logical step when considering electronic security. Beyond this, it is also necessary to ensure that the firmware cannot be uploaded remotely by any other means.

PLC memory does not conform with the typical von Neumann architecture. When firmware is loaded, a BIOS writes the uploaded firmware to ROM or flash memory, and the logic program is stored in volatile memory. Without a modified BIOS, the firmware cannot be self-modifying. Executable memory and data are stored separately, preventing a firmware level remote code injection from running PLC firmware.

Impact

The primary goal of validating firmware extends beyond ensuring that known good firmware is loaded on a PLC -it also helps create a closed system with respect to the PLC. PLCs have the highest level of local control over a SCADA system, so it is critical that they are verified at the basic hardware and software levels before additional security measures are applied at a higher level.

The verification tool offers a novel approach for SCADA security because it requires no system modifications or additions and does not affect the produc-tion system. Additionally, the verification tool does not introduce new attack vectors to a PLC because the tool is not physically wired to exchange communications with the PLC. Moreover, the tool can operate independently of a PLC.

Conclusions

Creating security tools specific to SCADA systems is necessary to maintain and build trust in critical infrastructure systems. The verification tool described in this paper is a viable option for enhancing PLC firmware security. While serial data capture, data verification and emulation are by no means new concepts, the tool combines these concepts in a novel manner that is tailored to SCADA system security. Ideally, a system should be secured from the bottom up. From this point of view, the tool is significant because it helps verify the security of a PLC at the lowest electronically-modifiable level.

Other advantages of the verification tool are that it does not require modifications to the SCADA system, and that it can replay captured data and analyze firmware without the presence of a PLC. These advantages, along with the ability to isolate the tool from production systems and adapt it to various architectures, make the tool attractive for use in diverse SCADA environments.

Note that the views expressed in this article are those of the authors and do not reflect the official policy or position of the U.S. Air Force, Department of Defense or the U.S. Government.

Figure 1 .

 1 Figure 1. Example non-traditional SCADA system inputs.

Figure 2 .

 2 Figure 2. Initial baseline capture configuration.

Figure 3 .

 3 Figure 3. Emulator environment configuration.

Acknowledgements

This research was partially supported by ICS-CERT under Award HSHQDC-11-X-00089 from the U.S. Department of Homeland Security.


Henry Bushey

Juan Lopez

Jonathan Butts

QUANTIFYING CONTROLLER RESILIENCE USING BEHAVIOR CHARACTERIZATION

Keywords: Programmable logic controllers, behavior characterization, resilience

Supervisory control and data acquisition (SCADA) systems monitor and control major components of the critical infrastructure. Targeted malware such as Stuxnet is an example of a covert cyber attack against a SCADA system that resulted in physical effects. Of particular significance is how Stuxnet exploited the trust relationship between the human machine interface (HMI) and programmable logic controllers (PLCs). Current methods for validating system operating parameters rely on message exchange and network communications protocols, which are generally observed at the HMI. Although sufficient at the macro level, this method does not support the detection of malware that causes physical effects via the covert manipulation of a PLC. This paper introduces an alternative method that leverages the direct analysis of PLC inputs and outputs to derive the true state of SCADA devices. The inputoutput behavior characteristics are modeled using Petri nets to derive metrics for quantifying the resilience of PLCs against malicious exploits. The method enables the detection of programming changes that affect input-output relationships, the identification of the degree of deviation from a baseline program and the minimization of performance losses due to disruptive events.

Introduction

Supervisory control and data acquisition (SCADA) systems provide for the automated monitoring and control of major components of the critical infrastructure [1]. SCADA systems were implemented in many industry sectors as early as the 1960s, but security was not a priority at the time. However, recent events -intentional and unintentional -have raised concerns regarding SCADA security [START_REF] Stouffer | Guide to Supervisory Control and Data Acquisition (SCADA) and Industrial Control Systems Security[END_REF]. Non-intentional actions have traditionally been addressed using redundant and fault tolerant architectures. Unfortunately, current solutions for dealing with intentional malicious actions are woefully inadequate [START_REF] Wilshusen | Cybersecurity: Continued Attention Needed to Protect Our Nation's Critical Infrastructure[END_REF].

A primary risk factor associated with intentional malicious actions is the trend to integrate SCADA systems and enterprise networks to save costs. Indeed, interconnecting critical SCADA systems via LAN and WAN technologies enables numerous attack entry points -from the Internet, internal workstations and communications links between the control center and field sites [START_REF] Stouffer | Guide to Supervisory Control and Data Acquisition (SCADA) and Industrial Control Systems Security[END_REF]. As demonstrated by Stuxnet, an attack that propagates from an enterprise network can execute code on field devices such as programmable logic controllers (PLCs) that ultimately results in physical damage to the process system [START_REF] Falliere | W32[END_REF].

Current methods for validating the functional parameters of a PLC primarily consider message exchange and network communications protocols, which are generally observed at the human machine interface (HMI). Although this method is sufficient at the macro level, it does not allow for the detection of malware that causes negative physical effects while employing deception techniques to mask the effects from the HMI. Additionally, quantifying the resilience of a PLC requires metrics for assessing its susceptibility to degradation and its ability to recover after an attack. This paper describes a method for detecting programming changes to PLCs by monitoring and characterizing PLC inputs and outputs. Focusing on PLCs at the micro level enables the effects of malicious actions to be observed despite efforts to mask the effects at the HMI, as was the case with Stuxnet.

Background

The National Infrastructure Advisory Council [START_REF]Critical Infrastructure Resilience Final Report and Recommendations[END_REF] defines resilience as the ability to reduce the magnitude and/or duration of disruptive events. An infrastructure is resilient if it can anticipate, absorb, adapt to and/or rapidly recover from a disruptive event. This definition provides a resilience framework with the following four characteristics:

The ability to monitor the current state to identify deviations from an accepted baseline and anticipate potentially disruptive events.

The ability to absorb potentially disruptive events by incorporating mechanisms that minimize the amount, if any, of performance loss.

The ability to adapt by ensuring that contingencies are available that allow for flexible system adjustments to maintain operational availability.

The ability to recover from disruptive events by incorporating automated or manual mechanisms that allow the system to provide functionality consistent with its baseline.

The method presented in this paper addresses the first two characteristics of the resilience framework and supports mechanisms that help address the last two characteristics. Effectively monitoring and absorbing disruptive events caused by malicious manipulations of PLC functionality requires examination at the micro level. This level of inspection isolates the PLC and its effects on the external end devices from potentially deceptive reporting to the HMI. The monitoring process is, thus, able to detect the true output states in response to PLC inputs. Analyzing the true output behavior of a PLC provides an accurate method for measuring the absorptive capability of the PLC against disruptive events. Furthermore, the results support the evaluation of contingencies and mechanisms to examine the ability of a system to adapt to and recover from disruptive events.

Other research efforts focus primarily at the macro level and involve static analysis. Queiroz, et al. [START_REF] Queiroz | Survivable SCADA systems: An analytical framework using performance modeling[END_REF] present a model for quantifying SCADA system performance against denial-of-service attacks by determining the probabilistic failures of interdependent nodes of a SCADA system. Germanus, et al. [START_REF] Germanus | Increasing the resilience of critical SCADA systems using peer-to-peer overlays[END_REF] present a model in which SCADA system communications use redundant links. Both these methods approach their analysis at a macro level view of the system and are dependent on a trusted HMI for system status.

Shah, et al. [START_REF] Shah | Mechanisms to provide integrity in SCADA and PCS devices[END_REF] present a method for verifying PLC executable code. This method utilizes a challenge-response protocol between the verification functions of an untrusted PLC and an external device. While this method approaches the problem at the micro level, the authors have noted that certain logistical issues arise when taking a PLC offline. Note, however, that the method does not protect against timed attacks in which malware is inactive during the verification process. Also, the method does not mitigate the negative effects that occur after malicious code is detected.

Our analysis uses Petri nets derived from PLC inputs and outputs. Petri nets provide a powerful analysis method by abstracting the observed behavior in terms of its graphical and mathematical equivalents. A Petri net C is a four-tuple C = (T, P, I, O) where T is a set of transitions, P is a set of places, I is a set of input functions for each transition and O is a set of output functions for each transition [START_REF] Peterson | Petri Nets[END_REF]. The Petri nets engaged in our research have been shown to be safe and bounded [START_REF] Peterson | Petri Net Theory and the Modeling of Systems[END_REF]. This yields finite reachability sets that provide quantifiable data to measure PLC performance during malicious events with respect to the resilience framework.

Behavior Characterization Methodology

This section describes the methodology for characterizing the input-output relationships of a PLC. An initial baseline program is established that incorporates PLC programming corresponding to an operational system. After the baseline is established, modifications are made to emulate a PLC infected with malware. Protective schemes are then applied to mitigate the effects of the malware. The enumerated instances of the PLC programs are evaluated to observe deviations in input-output behavior. Petri net models are then utilized to extract metrics that measure PLC security performance with respect to the resilience framework.

PLC Behavior Characterization

The two primary parameters monitored are: (i) the system input to the PLC; and (ii) the resulting output that translates directly to the physical system end devices (e.g., state of motors, lights and actuators). Because the output behavioral responses are based on the actual status of the physical end devices, the observations can be considered to represent the true state of the system. In order to categorize the observations, PLC interactions with the physical end devices are classified into three input-output response categories:

Valid: Nominal input results in nominal output processes.

Degraded: Nominal input results in deviant but safe output processes. A safe outcome is defined as a non-nominal output response in which system interactions with end devices do not cause catastrophic losses.

Unstable: Nominal input results in deviant and unsafe processes. An unsafe outcome is defined as a non-nominal output response in which system interactions with end devices cause catastrophic losses.

The research environment employed the LogixPro 500 programming software [START_REF][END_REF] for process emulation and the ProSim II tool [START_REF]The Learning Pit[END_REF] for simulation. LogixPro 500 provides a graphical user interface to develop, compile and execute instances of PLC programs with various system operating parameters. The multiple instances demonstrate distinct observable input-output behavior patterns when subjected to malicious attacks. For each instance, four program categories are established:

Baseline: A program that meets the defined process requirements and generates valid input-output responses.

Attack Baseline: A targeted attack applied to the baseline that generates degraded or unstable input-output responses.

Protection Baseline: A protection scheme applied to the baseline that is intended to generate valid input-output responses. The protection scheme produces a fail-safe system state (e.g., flashing red lights at a traffic intersection).

Attack Protection Baseline: A targeted attack applied to the protection baseline that generates valid, degraded or unstable input-output responses.

PLC Program Development

The various PLC instances establish a basis of observable input-output responses that are modeled and analyzed using Petri nets. The observations obtained from the input-output responses are consistent with black-box analysis; however, using the PLC program in conjunction with the targeted attacks and protection schemes helps differentiate between the observed behavior and defined nominal process requirements.

A PLC is programmed with a baseline program that is analyzed indirectly by applying baseline input signals and observing the output. The program is analyzed for nominal output behavior (i.e., valid inputs resulting in the nominal output) to demonstrate the PLC baseline interactions with its environment; this establishes the baseline behavior patterns for the model. Next, a series of targeted changes to the baseline program code are implemented that are indicative of alterations by malware. These enumerated versions of the PLC baseline program are also analyzed indirectly by applying the baseline inputs to each enumerated version. The subsequent outputs, which may include inappropriate behavior (e.g., invalid output states), demonstrate the altered interactions of the PLC with its environment; these form the deviated behavior patterns for the model. The purpose of the deviated behavior patterns is to quantify the level of behavioral deviation that is observable in the baseline program. A protection scheme is then applied to the PLC baseline program code. The established protection scheme represents a resilient program that enters a safe state to counter degraded or unstable states. Finally, the targeted malware is applied to the protection scheme in order to evaluate the resilient behavior patterns (i.e., inputs resulting in safe or unsafe outputs). The purpose of the resilient behavior patterns is to quantify the level of behavioral deviation that is observable in the resilient program.

Petri net analysis is performed on the results; this mirrors the states and transitions in the PLC. The absorptive capacity of the protection scheme applied to the PLC is a derivative of the behavioral differences between the baseline and resilient programs. In theory, a fully resilient protection scheme would maximize these measured differences and provide full absorptive capacity against malicious code.

Petri Net Derivation

This section outlines the methodology for deriving each of the four program categories and the equivalent Petri nets.

Establish Baseline Program

(a) Develop a ladder logic program that implements the defined nominal process requirements. The baseline program generates valid system input-output responses. Consider, for example, a silo plant that fills containers using a conveyer belt and automated sensors. The nominal processes are: bring an empty container into the plant, maneuver the container under the silo valve, fill the container until it is full, and ship the full container from the plant. Figure 1 Figure 2 shows the Petri net derived from the example baseline PLC program. The token (black dot) in "stop deliver" denotes that the place is actively manifested as a physical state. From this state, the only transition enabled is Transition 2 to 3. Note that the label "2 to 3" represents the combined decimal input value for the PLC (i.e., Transition 2 to 3 indicates that the system input value changes from decimal value 2 to decimal value 3). Firing Transition 2 to 3 changes the marking of the Petri net and "deliver container" becomes the active physical state. Two transitions are enabled from the active state "deliver container." In cases where there are two or more transitions enabled, the Petri net non-deterministically selects the transition that fires. The resulting Petri net for the baseline program identifies the possible states that the PLC can reach with valid operations.

Establish Attack Baseline

(a) Modify the baseline program ladder logic in a manner consistent with a targeted malicious attack. The attack baseline program generates degraded or unstable system input-output responses. (b) Repeat Steps 1(a) through 1(e) to produce the equivalent Petri net for the attack baseline PLC program. An example attack in this scenario targets the proximity sensor so that the silo valve is deceived into remaining open despite a container not being in close proximity to the fill station. The resulting attack manipulates the process to continually dispense product regardless of whether or not a container is in position. The protection scheme implemented for this example utilizes additional ladder logic to provide a secondary fail-safe check for the silo valve to prevent it from opening when the conveyor belt is in motion. In the case of the baseline attack example, the protection scheme provides fail-safe procedures for safeguarding against the observable effects of the targeted attack that manipulates the proximity sensor. The attack protection baseline program represents the attacks applied to the system with the implemented protection schemes.

Establish Protection Baseline

Establish Attack Protection Baseline

In our experiments, we reviewed ten instances and several attacks on the silo process. Each PLC instance generated four programs and the corresponding Petri nets. A total of 40 Petri nets were utilized to mirror the physical states and transitions resulting from the different PLC programs. The quantitative analysis of the 40 Petri nets revealed several consistent findings for assessing PLCs with respect to the resilience framework.

0 0 0 0 0 1 0 0 0 M1 0 1 0 0 0 0 0 0 0 M2 0 0 0 1 0 0 0 0 0 M3 0 0 0 0 0 0 0 1 0 M4 1 0 1 0 0 0 0 0 0 M5 1 0 0 0 0 0 1 0 0 M6 0 0 0 0 1 0 0 0 0 M7 0 0 0 0 0 0 0 0 1

Analysis and Findings

The analysis of the Petri nets yielded several metrics that directly address or indirectly support the four characteristics of the resilience framework. The Petri net simulation application PIPE v4.0 was used to evaluate the Petri nets. The Petri net analysis produced a reachability matrix for each Petri net. These matrices were analyzed to identify comparative metrics that assess true inputoutput performance with respect to the resilience framework.

Reachability Matrix

A reachability matrix defines all the possible states in a given Petri net [START_REF] Peterson | Petri Net Theory and the Modeling of Systems[END_REF]. Table 1 shows the reachability matrix for an example baseline PLC instance. Note that the analysis of the ten instances and the various attacks is consistent with the example used in the discussion. The rows in the table represent the tangible states and the columns represent the places that characterize the states. The elements of each matrix are marked "0" or "1," representing the absence or presence of a token, respectively. For example, State M0 represents the Petri net marking in Figure 2 in which the place "stop deliver" is active. The baseline PLC presented for this instance has eight distinct states.

0 0 0 0 0 1 0 0 0 M1 0 1 0 0 0 0 0 0 0 M2 0 0 0 1 0 0 0 0 0 M3 0 0 0 0 0 0 0 1 0 M4 1 0 1 1 0 0 0 0 0 M5 1 0 0 0 0 0 1 0 0 M6 0 0 0 0 1 0 0 0 0 M7 0 0 0 0 0 0 0 0 1
Table 2 shows an example attack baseline matrix for the PLC instance. Note that State M4 has been altered to incorporate a targeted attack. The attack implemented in this instance causes the silo valve to remain open even though a full container has left the fill station. This state represents a change in the PLC that results in a degraded or unstable operating process, which is not defined in the Petri net corresponding to the baseline program.

Metrics

The differences between the four program categories form the basis for deriving quantitative metrics. Table 3 summarizes the results of applying the attack instances against the baseline program and the protection baseline program. Note that "d/u" denotes degraded or unstable impact while "fs" denotes system transition to the fail-safe or resilient state.

Attack Instances 1 through 4 alter one state by manipulating one element (e.g., modifying the silo sensor for State M4). Attack Instances 5 through 7 alter one state by manipulating two elements. Attack Instances 8 through 10 alter two states by manipulating two elements for each state. As shown in Table 3, the protection baseline resulted in fail-safe operations for Attack Instances 1 through 7; however, the protection baseline was insufficient for attacks targeting multiple states and multiple elements (Attack Instances 8 through 10).

Comparing these observations with the pairwise differences observed for the ladder logic suggests a correlation between the net changes to the output behavior and the net changes to the ladder logic. As indicated by the results, the most significant metric resulting from the evaluation is the difference observed between the PLC program and the input-output behavior corresponding to the instance. With respect to the resilience framework, this evaluation serves as a self-sufficient metric as well as a complementary metric. Indeed, comparative analysis directly addresses two aspects of resilience (i.e., detecting a change occurrence and quantifying the degree of change occurrence) and supports mechanisms to minimize performance losses due to disruptive events.

The following list summarizes the implications with respect to the resilience framework:

The ability to anticipate a potentially disruptive event requires the system to be self-aware of its baseline and monitor its current state.

The proposed evaluation identifies when physical input-output relationships deviate from the baseline. This metric may support one of two triggering mechanisms: (i) the number of identified deviations exceeds a threshold; and (ii) a violation against a whitelist of expected outcomes.

The ability to absorb potentially disruptive events requires the system to have mechanisms in place that minimize the amount, if any, of performance loss.

The proposed evaluation in combination with the difference in ladder logic changes can help assess the ability of a PLC to absorb disruptive events: (i) if the input-output behavioral difference is zero, then the differences in ladder logic may be used to assess the inherent robustness of the PLC ladder logic program; and (ii) if the input-output behavioral difference is greater than zero, then the differences observed in the input-output behavior may be utilized to assess the overall absorption by the PLC.

The ability to adapt requires the system to have contingencies that permit flexible system adjustments to maintain operational availability.

The proposed evaluation supports this feature by providing triggering mechanisms that initiate adaptive processes. Note that the adaptive processes may exist external to the PLC (e.g., requiring coordination with additional hardware and/or software).

The ability to recover from a disruptive event requires mechanisms, either automated or manual, that enable the system to operate in a manner consistent with its baseline.

The proposed evaluation supports this feature by providing triggering mechanisms that initiate recovery processes. Note that the recovery processes may exist external to the PLC (e.g., requiring coordination with additional hardware and/or software).

Extending the Implementation

Although the analysis presented here focuses on an individual PLC program implementation, the methodology can be applied to a more general protection scheme. This is important because the protection mechanism may be an external, and preferably, parallel process. Figure 3 illustrates an example Petri net that models the input-output behavior metric as the primary means for monitoring and detecting state security.

In the example, a monitoring system is incorporated to signal the need to transition to a backup PLC when unstable or degraded operations are detected. The primary PLC executes the baseline program; however, the secondary protective PLC is isolated from direct communications with the SCADA network. If a deviation from the expected behavior is detected, then the secondary PLC triggers a fail-safe operation. During nominal operations, the subnet of the primary PLC controls process flow. In the case of an input-output behavior deviation, process control is transferred to the subnet of the secondary PLC as represented by the current state in the Petri net. The Petri net illustrates an architecture that supports absorptive, adaptive and recovery features that are triggered primarily by an analysis of the input-output metric.

Conclusions

The behavior-based method described in this paper provides a practical means for assessing the security posture of a PLC against malicious code. The resulting framework helps quantify PLC resilience in terms of its ability to monitor, detect and absorb intentional malicious actions. Analyzing the system in real time for nonconforming behavior by the PLC supports attack detection and mitigation. Indeed, metrics from input-output behavior characterization constitute true representations of system state that cannot be deceived by alterations at an HMI or communications channel. Thus, the behavior-based method provides a measure of PLC resilience against malicious code and provides a baseline for quantitatively assessing the security posture. Indeed, analyzing security at the micro level by focusing on field devices and system functions can help prepare for and address future Stuxnet-like attacks.

Note that the views expressed in this article are those of the authors and do not reflect the official policy or position of the U.S. Air Force, Department of Defense or the U.S. Government.

  shows the baseline program for the silo plant. (b) Abstract the possible combinations of the inputs of the formal ladder logic as transitions T in a Petri net. NOT in fill area, OR if box is full, then energize conveyor motor. If fill level is reached, then latch and hold full light on, while box remains in the fill area. If box is in the fill area, AND box is NOT full, then energize fill valve and light.

Figure 1 .Figure 2 .

 12 Figure 1. Example baseline ladder logic program for a silo plant.

  (a) Modify the baseline program ladder logic to incorporate a protective scheme that mitigates the effects of the attack baseline program. The protection baseline program, which implements fail-safe operation, is intended to generate valid system input-output responses. (b) Repeat Steps 1(a) through 1(e) to produce the equivalent Petri net for the protection baseline PLC program.

( a )

 a Modify the protection baseline program ladder logic to incorporate targeted attacks derived in the attack baseline. The attack protection baseline program generates degraded or unstable input-output responses. (b) Repeat Steps 1(a) through 1(e) to produce the equivalent Petri net for the attack protection baseline PLC program.

Figure 3 .

 3 Figure 3. Petri net model for monitoring and detecting security in a fail-safe state.

Table 1 .

 1 Set of tangible states (baseline).

	Container	Deliver	Depart	Fill	Ship	Stop	Stop	Stop	Stop
	Full	Container	Silo	Container	Container	Deliver	Depart	Fill	Skip
	M0

Table 2 .

 2 Set of tangible states (attack baseline).

	Container	Deliver	Depart	Fill	Ship	Stop	Stop	Stop	Stop
	Full	Container	Silo	Container	Container	Deliver	Depart	Fill	Skip
	M0

Table 3 .

 3 Comparison of baseline and protection programs.

	Attack	Baseline Protection
	Instance Program	Baseline
	1	d/u	fs
	2	d/u	fs
	3	d/u	fs
	4	d/u	fs
	5	d/u	fs
	6	d/u	fs
	7	d/u	fs
	8	d/u	d/u
	9	d/u	d/u
	10	d/u	d/u


Thomas Mcevoy

Stephen Wolthusen

Agent Interaction and State Determination in SCADA Systems

Keywords: Critical infrastructure, agents, state determination, π-Calculus

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Critical infrastructure systems have received significant attention as targets of cyber attacks [START_REF] Chen | Stuxnet, the real start of cyber warfare[END_REF]. Remote attackers, however, face problems in determining the system state due to limitations on communications [START_REF] Genge | Investigating the effect of network parameters on coordinated cyber attacks against a simulated power plant[END_REF][START_REF] Mcevoy | A formal adversary capability model for SCADA environments[END_REF]. At the same time, operators must respond in real-time to sophisticated attacks and may have to make decisions based on partial knowledge of the system state. The outcomes of these interactions may depend on the state (or knowledge of the state) of a single channel or process. We argue that such situations require the deployment of software agents by both sides to automate, in whole or in part, attack and defense strategies.

This paper introduces an extension to the Applied π-Calculus [START_REF] Sangiorgi | π-Calculus: A theory of mobile processes[END_REF] that provides the ability to define and classify agent-based attack and defense strategies. The extension augments a previously-proposed formal adversary capability model [START_REF] Mcevoy | A formal adversary capability model for SCADA environments[END_REF]. A model of a coordinated attack and defense scenario is presented to illustrate the utility of the extension.

Background

Software agents often use learning behavior techniques and rely on their perception of the environment to make autonomous decisions [START_REF] Wooldridge | An Introduction to MultiAgent Systems[END_REF]. Indeed, in recent years malicious code has exhibited increasingly agent-like behavior, a trend that is likely to continue [START_REF] Mclaughlin | On dynamic malware payloads aimed at programmable logic controllers[END_REF][START_REF] Patsakis | New malicious agents and SK virii[END_REF].

Software agents permit an attacker to launch sophisticated attacks, including coordinated attacks on targets. From the offensive perspective, there are several advantages to launching agent-based attacks [START_REF] Braynov | Representation and analysis of coordinated attacks[END_REF][START_REF] Braynov | Detecting malicious groups of agents[END_REF]. Responding to such attacks requires the operator to make dynamic interventions in the face of changing adversary behavior. The difficulty for the operator is exacerbated by the intrinsic nature of critical infrastructure systems, which may require continued operations even in a compromised state [START_REF] Boyer | Supervisory Control and Data Acquisition[END_REF][START_REF] Krutz | Securing SCADA Systems[END_REF]. Moreover, the scale and complexity of critical infrastructure systems render it unlikely for a human operator to make the appropriate responses to deal with a coordinated attack.

The ability of software agents to autonomously perform a range of security tasks provides a distinct advantage in countering agent-based attacks [START_REF] Tesauro | A multi-agent systems approach to autonomic computing[END_REF]. Understanding agent-based attack and defense strategies is key to protecting critical infrastructure systems. However, reasoning about agent-based systems presents a complex set of problems, especially with regard to multiple cooperating agents that "recruit" normally trusted processes to work on their behalf [START_REF] Mcevoy | A formal adversary capability model for SCADA environments[END_REF]. An extension to the well-known π-Calculus makes it possible to reason about such complex scenarios. The extension also provides a model to examine a distinct class of attacks that are dependent on malicious software agents and not on direct adversary intervention.

3.

G{π}-Calculus

The π-Calculus provides a formal mechanism for modeling process actions [START_REF] Mcevoy | A formal adversary capability model for SCADA environments[END_REF][START_REF] Mcevoy | A plant-wide industrial process control security problem[END_REF][START_REF] Mcevoy | Defeating node-based attacks on SCADA systems using probabilistic packet observation[END_REF][START_REF] Sangiorgi | π-Calculus: A theory of mobile processes[END_REF]. The associated algebraic theory facilitates formal reasoning, including automating proofs [START_REF] Sangiorgi | π-Calculus: A theory of mobile processes[END_REF]. This section describes the extended goal transform π-Calculus (G{π}-Calculus). Interested readers are referred to [START_REF] Sangiorgi | π-Calculus: A theory of mobile processes[END_REF] for fundamentals of the basic π-Calculus and to [START_REF] Mcevoy | A formal adversary capability model for SCADA environments[END_REF] for details about the Applied π-Calculus, which is used as the basis of the extension described in this paper.

||G|| AgentN ame is defined by a set of inter-related goals. If G is a goal then:

G ::= 0|π.G|νz G|G.G|G + G|G ⊕ G|G|G ′ |!G|[L]G
where the possible actions α of G are defined in Table 1. Note that L is a first-order logic with equivalence and ordered relations, and π is a capability of the π-Calculus.

Goal actions are defined by the capabilities of the Applied π-Calculus:

π ::= x⟨z⟩ c|x(z) c|λ|f (ṽ c′ ) ⊃ ṽ′ c|[L]π
with the semantics defined in Table 2. Goals execute until they invoke another goal, at which point they terminate. G 0 is a reserved label that represents the null goal. Receive a name with characteristics λ A "silent" function

f (ṽ c′ ) ⊃ ṽ′ c A function over a set of names [L]π
Conditional execution of a capability The set of system names N comprises channels, constants, message characteristics, variables and function labels. Note that z denotes a vector of names, denotes a set of concurrent goals or processes, and denotes a sum M over capabilities. A label for an inaction represents a process action that may not be directly observable. For example, if P := M + λ is a process, then λ, P ⊃ 0 is an inaction or "silent" function of P .

A key characteristic of the model is that processes may be overwritten by messages from another agent. Hence, the outcomes of messages need to be precisely defined. For example, if m is a message and P := M + Ω|Q, then Ω, m, P ⊃ P ′ where P ′ may be defined arbitrarily. In general, P ′ behaves like P , except under certain conditions where it executes a different behavior useful to the adversary (i.e., Byzantine behavior).

Destination addresses are characteristics in the example scenario presented in this paper. Assume that ⟨z⟩ Xj is used to route the name z to the process X j . Routing is conditional on the characteristic and, for brevity, is denoted as xi ⟨z⟩ [Xj ] rather than the more conventional [z.r = X j ]x Xj ⟨z⟩ Xj where z.r indicates the characteristic routing address of the name z. Hence, any name with the destination address z.r = X j as a characteristic is routed by xi , even when xi is not the final destination. A proof reduction is indicated using the notation:

||Goal.Subgoal.Action|| Agent → ||Goal.Subgoal.N extAction|| Agent
where N extAction is any capability or goal invocation. The proof reduction is identical to that of the π-Calculus [START_REF] Sangiorgi | π-Calculus: A theory of mobile processes[END_REF], with the exception that goal labels are used to limit the consideration to the active (i.e., dotted) goals || • Goal|| of each agent.

Coordinated Attack

This section models a coordinated attack. Using automated agents, the adversary seeks to manipulate three valves in order to cause a critical failure, while concealing its actions. The first step is to define the goal labels for scenario planning. In fact, without interference in channels and processes, the G{π}-Calculus would be sufficient to prove the outcome of any interactions, provided that the goals are defined precisely.

In the coordinated attack shown in Figure 1, two defined "launch" agents send malware as a name to a system to overwrite various network nodes and transform them into additional malicious agents that work on behalf of the adversary. The scenario has four possible outcomes: (i) success for both agents;

The attack uses two routing processes to forward malware.

||Stage1.x 9 ⟨g 2 ⟩ X i || L1 (i = 4) ||Stage2.x 10 ⟨g 3 ⟩ X j || L2 (j = 12) ||X 9 .x 9 (z)|| System ||X 10 .x 10 (z)|| System
After the messages are sent, the launch agents wait for success.

||Stage1.x S1 (s)|| L1 ||Stage2.x S2 (s)|| L2
The routing agents report either success or failure.

(φ is a silent function that indicates failure)

||X 9 .(x i ⟨m 2 ⟩ X i .x S1 ⟨⊤⟩ ⊕ φ.x S1 ⟨⊥⟩ S1 )|| Agent0 ||X 10 .((x j ⟨m 2 ⟩ X j .x S2 ⟨⊤⟩ ⊕ φ.x S2 ⟨⊥⟩ S2 )|| Agent00 ||X i .x i (z)|| System |X j .x j (z)|| System Case 1: Both attempts succeed. ||Stage1.x S1 (s)|| L1 ||Stage2.x S2 (s)|| L2 ||X 9 .x S1 ⟨⊤⟩ S1 )|| Agent0 |X 10 .x S2 ⟨⊤⟩ S2 || Agent00 ||X i ′ |G|| Agent2 ||X j ′ |G|| Agent3
Case 2: Either attempt fails and the initial attack continues.

Case 3: Neither attempt succeeds and the attack is aborted. (ii) failure for Agent 1 and success for Agent 2; (iii) success for Agent 1 and failure for Agent 2; and (iv) failure for both agents. Based on the initial outcome, a third launch agent initiates the final part of the attack.

Figure 2 shows the reduction of the coordinated attack. Note that X i is a system node, g 2 is a message used to infect the system and s is a Boolean variable.

In the example, the launch agents L1 and L2 send malicious names into the system using channels X 9 and X 10 , respectively. In turn, these are routed to the target nodes i and j. If the initial subversion succeeds, the newly formed agents flag their success to agent L3, which launches the final part of the attack. Note that the messages indicating success or failure may arrive in any order, which may affect the planned outcome.

As demonstrated in Figure 3, the messages update a Boolean predicate a and the final attack launches if the predicate evaluates to T RU E. In this instance, the update order is not relevant to the outcome. The result of Case 1 is that the final part of the attack is launched by L3. At this point, L3 sets the target valve to Steady and signals the other two agents to set their target valves to Open and Closed. The attack is concluded by masking the signal from the operators as demonstrated in Figure 4; this serves to conceal the attack.

Distributed Detection

For the defense strategy, an operator employs observer agents for state determination and trusted routes for alerts regarding critical conditions. As described in [START_REF] Mcevoy | A plant-wide industrial process control security problem[END_REF][START_REF] Mcevoy | Defeating node-based attacks on SCADA systems using probabilistic packet observation[END_REF][START_REF] Song | Advanced and authenticated marking schemes for IP traceback[END_REF], each network node that receives a message adds its address

The first agent sets a valve to a steady value.

||X k ′ |SetSteady.set(u, Steady) ⊃ u ′ || Agent1 ||X i |W aitf or1|| Agent2 ||X j |W aitf or2|| Agent3 ||X k ′ |SetSteady.Send.xs⟨u ′ ⟩ C2 || Agent1 ||X i |W aitf or1|| Agent2 ||X j |W aitf or2|| Agent3
The instruction is sent to the controller.

||X k ′ ||F lagSteady|| Agent1 ||X i |W aitf or1|| Agent2 ||X j |W aitf or2|| Agent3
Messages are received.

||X k ′ |F lagSteady.xs(u)|| Agent1 ||X i |W aitf or1|| Agent2 ||X j |W aitf or2|| Agent3
After the flag is steady, the next agent is signaled.

||X k ′ |F lagSteady.[u = Steady]xs⟨s⟩ X 5 .G 0 || Agent1 ||X i |W aitf or1|| Agent2 ||X j |W aitf or2|| Agent3
Fake are used to conceal the true plant state.

||X k ′ .Send(u)|Conceal|| Agent1 ||X i |W aitf or1.xs(s)|| Agent2 ||X j |W aitf or2|| Agent3
The next agent opens the valve and signals the third agent.

||X i |OpenV alve|| Agent2 ||X j |W aitf or2|| Agent3 ||X j |CloseV alve|| Agent3
The attack completes. to mark the route. Each node may also probabilistically forward a message copy to "observer" agents for comparison.

The attributes provide a formal definition for observer agents, which use the information to make state determinations. Note that in [START_REF] Mcevoy | Defeating node-based attacks on SCADA systems using probabilistic packet observation[END_REF], IP traceback algorithms were used to detecting the locations of malicious agents -a different goal from the one addressed in this work. Here, the observer algorithm uses messages and copies of messages to determine a trusted set of paths. This is demonstrated by the observer definition in Figure 5.

Observe := x Ob j (z) + [z ∈ M ]U pdateState + [z ∈ C]U pdateP ath U pdateState := ν p (Store(z, ST ORE) ⊃ ST ORE ′ + P i [z ∈ C i ∧ ¬(M arked(z.path)]Store(z, ST AT E) ⊃ ST AT E ′ + ([p rand()]EvaluateState ⊕ Observe) EvaluateState := (Evaluate(ST AT E, c) ⊃ CRIT ICAL ′ + [CRIT ICAL]Alert) + Observe U pdateP ath := Compare(u, z, k, ST ORE) ⊃ w P i [¬w]M arkP ath(u, z, C i T REE) ⊃ C i T REE ′ + P i [w ∧ M arked(z.path)]U nM arkP ath(u, z, C i T REE) ⊃ C i T REE ′ + Observe Alert := ν f (⊥) (x Op ⟨f ⟩ Op ) ν kc, ST ORE, ST AT E, CRIT ICAL, C i T REE || • Observe||
State determination is restricted to considering messages received on trusted paths. Figure 6 provides the initial reduction of the observer using copied messages to determine route trustworthiness. The observer receives a message and invokes the goal U pdateP ath to compare the message with the original. If no discrepancy is found, the observer moves to the next message. If a discrepancy is found, then it notes the route and marks the forward neighboring node as untrusted. The marked messages can be represented using a graph and defined algebraically.

The indication that the path marking algorithm responds correctly depends on whether a message is marked before or after manipulation. If the message is copied before it is manipulated, then the malicious agent node appears to deliver trustworthy messages, but any subsequent node appears untrustworthy. Hence, the next node in the communication chain is marked. Alternatively, when any previous node appears to deliver a trustworthy copy, the agent node is indicated using the bar notation. In both instances, a message traversing the agent node is not trusted for state determination.

Figure 7 demonstrates another case for examining a trustworthy message and, depending on the probability, a snapshot of state. The observer receives the original message and retains the message in ST ORE. If the message arrives on a trusted path, the message is included in ST AT E to make a determination of the system state. If the state is detected as critical, the operator is signaled by the Alert goal.

Dynamic behavior such as agent migration can be accommodated. For example, a change of status for X 8 and X 6 can be represented as shown in Figure 8. The ability to track the possible range of dynamic system behavior is a key aspect of the modeling technique. This provides the ability to consider probable outcomes of any state determination during a changeover in node state. The ability to represent dynamic defense strategies facilitates reasoning about agent interaction schemes. Indeed, the modeling approach facilitates the analysis of agent behavior in order to determine the appropriate responses during a coordinated attack.

i .Send|| (i = 1, 2, 3) ||Observe.x ob j (z)|| Observer j (z ∈ M ) ||U pdateState.Store(z, ST ORE) ⊃ ST ORE ′ ||

Conclusions

The π-Calculus extension described in this paper uses goal-based syntax and semantics to explicitly capture the operation of agents in critical infrastructure environments. It also provides the ability to model an increased range of attack and defense capabilities compared with previous approaches. Specifically, it facilitates the modeling of coordinated attacks and defenses, and the ability to reason about complex interactions at a granular level. The example scenario demonstrates state determination in the face of a coordinated attack by leveraging trusted paths.

Our future work will concentrate on modeling and analyzing complex operator and adversary interactions in critical infrastructure environments. We will also seek to extend the approach to incorporate learning behavior and timing considerations.

Figure 1 .

 1 Figure 1. Initial coordinated attack.

Figure 2 .

 2 Figure 2. Reduction of the coordinated attack.

Case 2 :Figure 3 .

 23 Figure 3. Determining if the final attack should be executed.

Figure 4 .

 4 Figure 4. Concealing the coordinated attack.

Figure 5 .

 5 Figure 5. Formal specification of an observer agent.

Figure 6 .

 6 Figure 6. Using copied messages to determine route trustworthiness.

|X

Figure 7 .

 7 Figure 7. Using store and alert messages to determine trustworthiness.

Figure 8 .

 8 Figure 8. Dynamic behavior of agent migration.

Table 1 .

 1 G{π}-Calculus syntax.

	Term	Semantics
	0	Null action
	π.G	Exercise a π-Calculus capability
	νz G Declare a new goal and its names
	G.G	Execute goals sequentially
	G + G Execute feasible goals in order
	G ⊕ G Execute exclusive goals
	G|G ′	Execute two goals concurrently
	!G	Replicate goal action
	[L]G	Execute a goal based on a first-order logic condition

Table 2 .

 2 π-Calculus terms.

	Term	Semantics
	x⟨z⟩ c	Send a name with characteristics
	x(z) c

  Two agents send malware to selected system nodes. ||Stage1.SendM alwareT oN ode 4 || Launch1 (i = 4) ||Stage2.SendM alwareT oN ode 12 || Launch2 (j = 12) The selected nodes are ready to receive the messages. ||X 4. ReceiveM essage|X 12 .ReceiveM essage| ' k=1...15,k̸ =i,k̸ =j X k || System After the messages are sent, the launch agents poll for success. ||Stage1.P ollSuccess|| Launch1 ||Stage2.P ollSuccess|| Launch2 ||X 4 .BecomeM aliciousAgent|X 12 | . . . || System One of the attacks succeeds and the success is reported to Agent 3. ||Stage1.ReportSuccessT oLaunch3|| Launch1 ]

	The second launch agent continues its initial subversion attempts.
	||Stage2.SendM alware|| Launch2 (j = 11)
	||X 4 || Agent1 ′
	||X 4 |X 11 .ReceiveM essage|	'

k=1...15,k̸ =j X k || System

The third agent waits for complete success before it attacks. ||Stage3.W aitF orLaunch1and2 + [Success]LaunchF inalAttack|| Launch3

  Observer j CRIT ICAL ′ || Observer j

	Trusted messages are stored in STATE variable
	||Store(z, ST AT E)|| Observer j
	→	(p > rand())
	||Observe|| Observer j
	No critical state found, continue
	||Observe|| Observer j
	Alert on finding a critical state
	||Alert|| Observer j

→ (p rand())

Evaluate plant state using trusted messages ||EvaluateState.Evaluate(ST AT E, c) ⊃

  ||X 10 .M ark.x⟨y⟩ Op |X 10 .x 10 (z)|C 1 .x 12 ⟨z⟩ Op |X 12 .x 12 (z)|| System ||X 10 .M ark.x 8 ⟨y⟩ Op |X 12 .M ark.x 9 ⟨y⟩ Op | X 9 .M ark.x 9 (z)|C 1 .x 13 ⟨y⟩ Op |X 13 .x 13 (z)|| System ||X 8 ′ .x 8 (z)|| Agent2 ||X 8 ′ .M ark.x 5 ⟨y⟩ Op || Agent2 ||X 13 .M ark.x 10 ⟨y⟩ Op |X 9 .M ark.Observe(y)| C 1 .x 12 ⟨z⟩ Op |X 12 .x 12 (z)|X 10 .x 10 (z)|X 5 .x 5 (z)|| System ||X 10 .M ark.x 7 ⟨y⟩ Op |X 5 .M ark.x 2 ⟨y⟩ Op | X 12 .M ark.x 9 ⟨y⟩ Op |X 9 .M ark.x 6 ⟨y⟩ Op | C 1 .x 13 ⟨y⟩|| System Case 1 -X 8 and X 6 are marked '

i ||U pdateP ath.M arkP ath(c, y, C 1 T REE)|| Ob i Case 2 -Neither node is marked Case 3 -X 6 is marked but not X 8