Jason Reeves

Ashwin Ramaswamy

Michael Locasto

Sergey Bratus

Sean Smith

Lightweight Intrusion Detection for Resource-Constrained Embedded Control Systems

Keywords:

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

Introduction

The critical infrastructure has become strongly reliant on embedded control systems. The electric power grid is not immune to this trend: one study predicts that the number of smart meters deployed worldwide, and by extension the embedded control systems inside these meters, will increase from 76 million in 2009 to roughly 212 million by 2014 [START_REF]Transmission and Distribution World, About 212 million "smart" electric meters in 2014, says ABI Research (tdworld.com/smart grid automa[END_REF].

The need to secure software that expresses complex process logic is well understood, and this need is particularly important for SCADA devices, where the logic applies to the control of potentially hazardous physical processes. Therefore, as embedded control devices continue to permeate the critical in-frastructure, it is essential that steps are taken to ensure the integrity of these devices. Failing to do so could have dangerous consequences. Stuxnet [START_REF] Falliere | Stuxnet Dossier, Symantec[END_REF], which targeted workstations used to configure programmable logic controllers and successfully modified the controller code, is an example of malware that caused widespread damage to a physical installation by infecting a SCADA system.

SCADA systems impose stringent requirements on protection mechanisms in order to be viable and effective. For one, the additional costs associated with security computations do not scale in SCADA environments. LeMay and Gunter [START_REF] Lemay | Cumulative attestation kernels for embedded systems[END_REF] note that, in a planned rollout of 5.3 million electric meters, incorporating a trusted platform module in each device would incur an additional power cost of more than 490,000 kWh per year, even if the trusted platform modules sat idle at all times. Embedded control systems in the power grid must also deal with strict application timing requirements, some of which require a message delivery time of no more than 2 ms for proper operation [START_REF]IEEE 1646-2004 Standard: Communication Delivery Time Performance Requirements for Electric Power Substation Automation[END_REF].

Several researchers [START_REF] Jiang | Stealthy malware detection through VMMbased "out-of-the-box" semantic view reconstruction[END_REF][START_REF] Litty | Hypervisor support for identifying covertly executing binaries[END_REF][START_REF] Payne | Lares: An architecture for secure active monitoring using virtualization[END_REF][START_REF] Petroni | Automated detection of persistent kernel control flow attacks[END_REF][START_REF] Riley | Guest-transparent prevention of kernel rootkits with VMM-based memory shadowing[END_REF][START_REF] Wang | Countering kernel rootkits with lightweight hook protection[END_REF] address the issue of malware by using virtualization -creating a trusted zone in which a monitoring program can operate and relying on a hypervisor to moderate between the host system and the monitor. These proposals, however, fail to consider the inherent resource constraints of embedded control systems. For example, the space and storage constraints of embedded devices may render the use of a separate hypervisor impractical. Petroni and Hicks [START_REF] Petroni | Automated detection of persistent kernel control flow attacks[END_REF] observe that simply running the Xen hypervisor on their test platform (a laptop with a 2 GHz dual-core processor and 1.5 GB RAM) imposed an overhead of nearly 40%. This finding indicates that virtualization may not be a feasible option for embedded SCADA devices, and that other approaches to intrusion detection should be considered.

In contrast, kernel hardening approaches, exemplified by grsecurity/PaX [20] and OpenWall [START_REF] Openwall | Linux kernel patch from the Openwall Project[END_REF], are very effective at reducing a kernel's attack surface without resorting to a separate implementation of a formal reference monitor. This is accomplished by implementing security mechanisms in the code of the Linux kernel by leveraging the MMU hardware and ELF binary format features of x86 and other architectures. Indeed, the PaX approach empirically demonstrates the possibility of providing practical security guarantees by embedding protection mechanisms in the kernel instead of relying on a separate operating layer below the kernel. It also shows that increased assurance and better performance can coexist in practice.

We note that, whereas many hypervisor-based approaches may appear attractive, the collective price in terms of maintenance, patching, energy, etc. [START_REF] Bratus | VM-based security overkill: A lament for applied systems security research[END_REF] obviates their use in embedded process control environments. In contrast, PaX demonstrates the suitability of implementing protection using already-deployed mechanisms in the hardware and operating system kernel stack. While dispensing with a separate reference monitor might appear to be a losing proposition from a security perspective, in practice, it requires extensive and creative machinations on the part of an attacker to overcome the protection provided by a hardened kernel.

Notably, Linux kernel attacks assume that one or more of the PaX-like protective features are disabled or absent. Little published work exists on the exploitation of grsecurity/PaX kernels; even leveraging high-impact "arbitrary write" kernel code vulnerabilities to exploit PaX kernels is very difficult [START_REF] Mittner | Exploiting gresecurity/PaX with Dan Rosenberg and Jon Oberheide (resources.infosecinstitute.com/exploiting-gresecuritypax[END_REF]. Proof-of-concept attacks on PaX underscore the complexity of the task, with the PaX team's rapid elimination of the generic attack vectors serving as further evidence of the viability of the defensive approach. This technical pattern forecasts the practicality of a "same-layer" protection mechanism.

This paper describes Autoscopy, an in-kernel, flow-control intrusion detection solution for embedded control systems, which is intended to complement kernel hardening measures. Autoscopy does not rely on a hypervisor; instead, it operates within the operating system, leveraging mechanisms built into the kernel (specifically, Kprobes [START_REF] Mavinakayanahalli | Probing the guts of Kprobes[END_REF]) to minimize the overhead imposed on the host. Autoscopy looks for control flow anomalies caused by the hijacking of function pointers in the kernel, a hallmark of rootkits seeking to inject their functionality into the operating system. In tests run on a standard laptop system, Autoscopy was able to detect control flow hooking techniques while imposing an overhead of no more than 5% with respect to several performance benchmarks. These results indicate that, unlike virtualized intrusion detection solutions, Autoscopy is well-suited to the task of protecting embedded control devices used in the critical infrastructure.

Background

This section describes the standard methods for intrusion detection and explains why they are difficult to use in embedded control system environments. The section also discusses the virtualization and self-protection approaches to intrusion detection, and highlights the tracing framework used in our intrusion detection solution.

Embedded Control Systems

The electrical power grid contains a variety of intelligent electronic devices, including transformers, relays and remote terminal units. The capabilities of these devices can vary widely. For example, the ACE3600 RTU [START_REF]ACE3600 Specifications Sheet[END_REF] sports a 200 MHz PowerPC-based processor and runs a VX-based real-time operating system. On the other hand, the SEL-3354 computing platform [START_REF]SEL-3354 Embedded Automation Computing Platform Data Sheet[END_REF] has an option for a 1.6 GHz processor based on the x86 architecture and can support the Windows XP and Linux operating systems.

In addition to the resource restrictions, embedded control systems used in the power grid are often subject to strict timing requirements. For example, intelligent electronic devices in a substation require a message delivery time of less than 2 ms to stream transformer analog sampled data, and must exchange event notification information for protection within 10 ms [START_REF]IEEE 1646-2004 Standard: Communication Delivery Time Performance Requirements for Electric Power Substation Automation[END_REF]. Given these timing windows, introducing even a small amount of overhead could prevent a device from meeting its message latency requirements, prohibiting it from doing its job -an outcome that may well be worse than a malware infection. Great care must be taken to limit the amount of overhead because device availability usually takes precedence over security.

Intrusion Detection Methods

Intrusion detection systems can be classified according to the device or medium they protect and the method they use to detect intrusions. An intrusion detection system can be host-based or network-based. A host-based system resides on a single platform and monitors running processes and user actions; a network-based system analyzes packets flowing through a network to detect malicious traffic. The two most common types of intrusion detection methods are misuse-based and anomaly-based. A misuse-based method looks for predefined bad behavior; an anomaly-based method looks for deviations from predefined good behavior. Note that other groupings, such as specification-based methods and behavioral detection methods [START_REF] Proctor | The Practical Intrusion Detection Handbook[END_REF], are also used in the literature.

The key to the success of an intrusion detection system is its ability to mediate the host it protects. Specifically, it must capture any actions that could change the state of the host system and determine whether or not the actions could move the system into an untrustworthy state. Conversely, an attack is successful when it evades such mediation.

In the ideal case, an intrusion detection system possesses two important characteristics. The first is that the intrusion detection system is separated in some manner from the rest of the system, enabling it to monitor the system while shielding it from host exploits (i.e., isolation). The second characteristic is that the intrusion detection system can monitor every action in the system (i.e., complete mediation). While these characteristics are attractive, they are expensive or impractical to implement in practice, especially in the light of the resource constraints imposed on an embedded control system. In contrast, Autoscopy engages less expensive methods of system mediation -its in-kernel approach permits the adjustment of the mediation scope.

Virtualization vs. Self Defense

Virtualization most often means the simulation of a specific hardware environment so that it functions as if it were an actual system. Typically, one or more of these simulations or virtual machines (VMs) are run, where each VM is isolated from the actual system and other VMs. A virtual machine monitor (VMM) is used to moderate the access of each VM to the underlying hardware.

Virtualization has become a common security measure, since in theory a compromised program remains trapped inside the VM that contains it, and thus cannot affect the underlying system on which it executes. Several recent intrusion detection proposals (see, e.g., [START_REF] Jiang | Stealthy malware detection through VMMbased "out-of-the-box" semantic view reconstruction[END_REF][START_REF] Litty | Hypervisor support for identifying covertly executing binaries[END_REF][START_REF] Petroni | Automated detection of persistent kernel control flow attacks[END_REF]) leverage this feature to separate the detection program from the system being monitored, which achieves the isolation goal. However, such a configuration is computationally expensive -a hypervisor can introduce a 40% overhead [START_REF] Petroni | Automated detection of persistent kernel control flow attacks[END_REF], and an embedded control system may not have adequate resources to support the configuration.

To avoid the overhead of a virtualized or other external solution, we propose an internal approach to intrusion detection, one that allows the kernel to monitor itself for malicious behavior. The idea of giving the kernel a view of its own intrusion status dates back to at least 1996, when Forrest and colleagues [START_REF] Forrest | A sense of self for Unix processes[END_REF] proposed the creation of a system-specific view of "normal" behavior that could be used for comparisons with future process behavior. The approach employed in Autoscopy can be viewed through the same lens: it endows the kernel with a module that allows it to perform intrusion detection using its own structures and to determine whether or not an action is trustworthy.

Kprobes

Several operating systems have introduced tracing frameworks to give authorized users standard and easy access to system internals at the granularity level of kernel symbols. Examples include DTrace [START_REF] Cantrill | Dynamic instrumentation of production systems[END_REF] for Solaris and Kprobes [START_REF] Mavinakayanahalli | Probing the guts of Kprobes[END_REF] for Linux.

Kprobes can be inserted at any arbitrary address in the kernel text, unless the address is explicitly blocked from probing. Once inserted, a breakpoint is placed at the address specified by the Kprobe, causing the kernel to trap upon reaching the address and to pass control to the Kprobe notifier mechanism [START_REF] Mavinakayanahalli | Probing the guts of Kprobes[END_REF]. The instruction at the specified address is single stepped and the user-defined handler functions execute just before and just after the instruction, permitting the state of the system to be monitored and/or modified at that point.

Related Work

Much of the research related to kernel rootkit techniques is described in hacker publications such as Phrack and public forums such as the Bugtraq mailing list. The discussion of system call hijacking and countermeasures can be traced back to at least 1997 (see, e.g., [START_REF]pragmatic/THC, (Nearly) complete Linux loadable kernel modules[END_REF]). A full survey of this research is beyond the scope of this paper; however, interested readers are referred to Phrack issue no. 50 [START_REF][END_REF] and subsequent issues.

Considerable research related to intrusion detection is based on the availability of a hypervisor or some other virtualization primitive. Petroni and Hicks's SBCFI system [START_REF] Petroni | Automated detection of persistent kernel control flow attacks[END_REF] uses VMs to create a separate, secure space for their control flow monitoring program, from which they validate the kernel text and control flow transfers in the monitored operating system. Patagonix [START_REF] Litty | Hypervisor support for identifying covertly executing binaries[END_REF] and VMWatcher [START_REF] Jiang | Stealthy malware detection through VMMbased "out-of-the-box" semantic view reconstruction[END_REF] use hypervisors to protect their monitoring programs, but they take different approaches to bridging the semantic gap between the hypervisor and the operating system. Patagonix relies on the behavior of the hardware to verify the code being executed, while VMWatcher simply reconstructs the internal semantics of the monitored system for use by an intrusion detection system within the secured VM. NICKLE [START_REF] Riley | Guest-transparent prevention of kernel rootkits with VMM-based memory shadowing[END_REF] and HookSafe [START_REF] Wang | Countering kernel rootkits with lightweight hook protection[END_REF] use trusted shadow copies of data to protect against rootkits. NICKLE creates a copy of VM memory space containing authenticated kernel instructions to ensure that unauthenticated code cannot run in kernel space, while HookSafe copies kernel hooks into a page-aligned memory area, where it can take advantage of page-level protection in the hardware to moderate access.

Several malware detection approaches that do not involve the use of a hypervisor have been proposed, but they suffer from other drawbacks that affect their utility in an embedded control system environment. For example, Kolbitsch and colleagues [START_REF] Kolbitsch | Effective and efficient malware detection at the end host[END_REF] create behavior graphs of individual malware samples using system calls invoked by the malware, and then attempt to match unknown programs to the graphs. However, much like traditional antivirus systems, this approach requires prior analysis of malware samples. Moreover, deploying updates to embedded devices, which may be remotely deployed in areas with questionable network coverage, remains a challenge. Other researchers attempt to integrate security policies into programs, but considerable effort is required to adapt this to new systems. For example, the approach of Hicks, et al. [START_REF] Hicks | From trusted to secure: Building and executing applications that enforce system security[END_REF], which brings together a security-typed language with the operating system services that handle mandatory access control, would most likely require the rewriting of many legacy applications.

Kprobes have been used for a number of tasks, most often related to debugging kernels and analyzing kernel performance (see, e.g., [START_REF] Prasad | Locating system problems using dynamic instrumentation[END_REF]). Other more novel applications of Kprobes include packet capturing [START_REF] Lee | Application-specific packet capturing using kernel probes[END_REF] and monitoring the energy use of systems [START_REF] Singh | The Atom LEAP Platform for Energy-Efficient Embedded Computing[END_REF]. However, to the best of our knowledge, Autoscopy is the first tool to leverage Kprobes for system protection.

Autoscopy

This section describes the Autoscopy system and explains how it is uniquely suited to secure embedded control devices. Interested readers are referred to [START_REF] Ramaswamy | Autoscopy: Detecting Pattern-Searching Rootkits via Control Flow Tracing[END_REF] for additional details about Autoscopy.

Overview

Autoscopy does not search for specific instances of malware on its host. Instead, the program looks for a specific type of control flow alteration that is commonly associated with malicious programs. The control flow of a program is defined as the sequence of code instructions that are executed by the host system when the program is executed. Diverting the control flow in a system has been a favored tactic of malware authors for some time, and using control flow constraints as a security mechanism is a well-explored area of research (see, e.g., [START_REF] Abadi | Control flow integrity: Principles, implementations and applications[END_REF]).

Autoscopy is designed to look for a certain type of pointer hijacking, where a malicious function interposes itself between a function pointer and the original function pointed to by the pointer. The malicious function invokes the original target function somewhere within its body, preserving the illusion of normalcy by giving the user the expected output while allowing the malicious function to perform its actions (e.g., scrubbing the output to hide itself and its activities).

Autoscopy has two phases of operation:

Learning Phase: In this phase, Autoscopy scans the kernel for function pointers to protect, and collects information about normal system behavior. First, Autoscopy scans kernel memory for function pointers by dereferencing every address it finds, looking for an address that could point to another location in the kernel. This list can be verified against the System.map file in the kernel, if desired. Next, the system places a Kprobe on every potential function pointer that is found. It then silently monitors the probes as the system operates, collecting the control flow information required for detection. Multiple rounds of probing may be necessary in some cases, and probes that are not activated are removed from consideration. The result is a list of all of the functions that are called by a function pointer along with the necessary detection information.

To obtain a more complete picture of trusted behavior, the Linux Test Project [35] is used to exercise as much of the kernel as possible, attempting to bring rarely-used functions under the protection scope and reduce false positives due to frequently-used functions. Note, however, that this method may leave out some task-specific behavior. Therefore, real use cases should be employed in the learning phase over and above any test suites.

Detection Phase: In this phase, Autoscopy inserts Kprobes in the functions tagged during the learning phase. However, instead of collecting information about system behavior, it verifies the information against the normal behavior that was compiled earlier. Anomalous control flows are reported immediately or are logged at the administrator's discretion.

Detection Methods

Autoscopy initially incorporated the argument similarity detection method, but currently implements trusted location lists.

Argument Similarity: The argument similarity between two functions is defined as the number of equivalent arguments (in terms of position and value) that the functions share. The register values or "contexts" of pointer addresses are collected during the learning phase, and the current and future directions of the control flow of each probed address are examined during the detection phase. The current control flow state is examined by looking at the call stack, and then checking the future direction by placing probes in functions called by the currently-probed function. Suspicious behavior is flagged when more than half of the arguments of the currently-probed function and a function discovered above or below it in the current control flow are similar. This threshold was chosen based on a manual analysis of rootkit control hijacking techniques.

Trusted Location Lists: This method uses the return address specified upon entering a probed function to verify whether or not the control flow has been modified. Location-based verification is not a new concept [START_REF] Levine | A methodology to detect and characterize kernel level rootkit exploits involving redirection of the system call table[END_REF][START_REF]s0ftpr0ject Team, Tools and Projects[END_REF], but it helps make simple decisions about the trustworthiness of the current control flow. The return addresses encountered at each probe during the learning phase are collected and used to build trusted location lists that are verified against during the detection phase. Return addresses that were not encountered during the learning phase are logged for analysis.

Moving from using argument similarity to building trusted location lists increases the flexibility of Autoscopy. However, it places more restrictions on the malware detection capabilities.

Advantages and Disadvantages

Autoscopy offers several advantages, especially with respect to embedded control systems. The most important advantage is lower space and processing requirements. Unlike most intrusion detection solutions, Autoscopy eliminates the overhead of a hypervisor or some other virtualization mechanism. Additionally, it leverages the built-in Kprobes framework of the Linux kernel, which reduces the amount of non-native code required.

Another key advantage is flexibility across multiple architectures. Indeed, this benefit was the main motivation for using trusted location lists. The argument similarity implementation [START_REF] Ramaswamy | Autoscopy: Detecting Pattern-Searching Rootkits via Control Flow Tracing[END_REF] disassembles entire functions to locate the hooks in question. With trusted location lists, however, only one instruction (i.e., function call) is disassembled per probe. This change limits the amount of knowledge required about the architecture and instruction set, which, in turn, limits the amount of code to be changed when porting the program to a host with a different underlying architecture.

Autoscopy also permits legitimate pointer hijacking. If desired, Autoscopy can be used in conjunction with other programs that alter the control flow for security or other reasons (see, e.g., [START_REF] Payne | Lares: An architecture for secure active monitoring using virtualization[END_REF]). Autoscopy simply tags this program behavior as trusted during the learning phase. However, as discussed below, indiscriminate tagging can be a drawback.

Finally, the design provides a simple way to adjust the scope of mediation. While the question of what to monitor and what not to monitor may require deeper analysis, changing the number of locations to probe is as simple as adding or removing them from the list of kernel hooks generated during the learning phase.

For all the advantages that Autoscopy offers, several shortcomings exist. First and foremost, the program itself is a target for malware. By operating within the kernel, Autoscopy is open to compromise just like the host system. While additional measures can be taken to protect the integrity of the program and kernel, e.g., by using W⊕X/NX [START_REF] Molnar | [END_REF] or Copilot [START_REF] Petroni | Copilot -A coprocessorbased kernel runtime integrity monitor[END_REF], these programs may run up against the resource constraints imposed on embedded control systems.

Another drawback is that Autoscopy requires a trusted base state. Because argument similarity is checked above and below a probed function, it is possible to detect malware that has been installed both before and after the deployment of Autoscopy. However, since the trusted lists are constructed by simply whitelisting every return address seen in a probed function, any malware installed before the learning phase would be classified as trusted behavior. Therefore, the system that hosts Autoscopy must be placed in a trusted base state before the learning phase to ensure that malicious behavior is classified properly.

Autoscopy has to be tuned to the host on which it resides, which can be tricky given the different types of embedded control systems that exist. The following issues must be addressed:

Kernel Differences: The kernel must be configured properly to support Autoscopy. This ranges from simple compilation configuration choices (e.g., enabling Kprobes) to differences in the kernel text across operating system versions (e.g., kernel functions used by Autoscopy must be exported for module use).

Architecture Differences: Autoscopy must be properly adapted to the host architecture. For example, it is necessary to know which register or memory location holds the return address of a function, and how it is accessed.

Tool Availability; External tools and libraries used by Autoscopy must be available across multiple platforms. For example, Autoscopy originally used udis86 [START_REF] Thampi | [END_REF], an x86-specific disassembler library, which means that a similar tool must be used with other architectures. This issue is made less important by the use of trusted lists because less disassembly is required.

Fortunately, although the task of configuring Autoscopy to run on different platforms is non-trivial, it is a one-time cost that is only incurred before installation.

Threats

At this point, it is important to consider the potential threats to Autoscopy. The principal threat is data modification. An attacker with the ability to read and write to arbitrary system locations could defeat Autoscopy's defenses by modifying the underlying data structures. For example, an attacker could modify a Kprobe or change a trusted location list to include the addresses of malicious functions.

Another threat is program circumvention. Autoscopy detects malware by checking for the invocation of kernel functions from illegitimate locations. However, an attacker who writes code that duplicates the functionality of a kernel function could avoid any probed functions and bypass Autoscopy entirely.

While these threats are a concern, the design raises the bar for a malicious program to subvert the system by forcing it to increase its footprint on the Other approaches can be used to protect Autoscopy's data. One approach is to store the trusted lists in read-only memory. However, the constraints imposed by embedded systems could render this approach infeasible.

Experimental Results

This section describes the results of testing Autoscopy on a standard laptop system running Ubuntu 7.04 with Linux kernel version 2.6.19.7. The experiments evaluated the ability of Autoscopy to detect common control flow altering techniques, and the amount of overhead imposed on the host in terms of time and bandwidth.

Detection of Hook Hijacking

We tested Autoscopy against several control flow altering rootkits that employ kernel hook hijacking techniques [START_REF] Ramaswamy | Autoscopy: Detecting Pattern-Searching Rootkits via Control Flow Tracing[END_REF]. Most of the rootkits tested are prototypes that demonstrate hooking techniques rather than malware from the wild. Nevertheless, they were written to showcase a broad range of control flow altering techniques and the corresponding control flow behaviors.

Table 1 lists several techniques used by malware to subvert an operating system, examples of text and/or code that demonstrate these techniques, and whether or not Autoscopy was able to detect these techniques. Note that Autoscopy was able to detect every one of the hooking behaviors listed. Interested readers are referred to [START_REF] Ramaswamy | Autoscopy: Detecting Pattern-Searching Rootkits via Control Flow Tracing[END_REF] for the complete list of rootkits that were tested.

Performance Overhead

We measured the performance overhead imposed by Autoscopy using five benchmarks: two standard benchmark suites (SPEC CPU2000 [START_REF]Standard Performance Evaluation Corporation, SPEC CPU2000 Benchmark Suite[END_REF] and lmbench [START_REF] Mcvoy | lmbench: Portable tools for performance analysis[END_REF]), two large compilation projects (compiling versions of the Apache web server and Linux kernel), and one test involving the creation of a large file. In the vast majority of these tests, Autoscopy imposed an additional time cost of no more than 5%. In fact, some of the tests indicated that the system ran faster with Autoscopy installed, which we interpreted to mean that Autoscopy had no noticeable impact on the system. Only one test (bandwidth measurement during the reading of a file) showed a large discrepancy between the results obtained with and without Autoscopy. We believe that this is due to the kernel preempting the I/O path or interfering with disk caching when it is probed.

Table 2 lists the results obtained in the five benchmarks tests. Note that in the case of the lmbench bandwidth measurements, lower values indicate more overhead. The experimental results demonstrate that the overhead imposed by Autoscopy did not heavily inconvenience the system.

False Positives and False Negatives

Autoscopy combats false positives -where non-existent rootkits are "detected" -using a type-checking mechanism that classifies hooks based on the structures in which they are enclosed and the offsets of the hooks within their enclosing structures. This classification prevents the flagging of a control flow containing two similar, but not equivalent, indirect calls.

False negatives -where existing rootkits are not detected -present an interesting challenge for Autoscopy. This is because locating potential hook hijacking locations depends on the definition of normal system behavior. For example, if a function is called indirectly from a pointer in the kernel, but is never called in this manner during the learning phase, then Autoscopy will not probe this location, leaving an opening for the hook to be hijacked silently. Therefore, it is important to use a comprehensive test suite during the learning phase to avoid these kinds of events.

Shortcomings

Some issues that could impact Autoscopy's performance were discovered during the transitioning to the new trusted location list approach. For example, each probe in the learning phase only reserves enough space for a single function call (which is overwritten every time the probe is hit), and indirect function calls are checked only after probing is completed. Thus, if a function is called both indirectly and directly, then it could be overlooked during the learning phase if it was last called directly before being checked. Furthermore, if a function is called indirectly from multiple locations, then all but one of these locations could be tagged as false positives. This issue and others like it will be identified and corrected in future versions of Autoscopy.

Future Work

Our ultimate goal is to demonstrate the feasibility of using Autoscopy to protect production systems in the power grid without impacting the ability of embedded devices to perform their required tasks. To accomplish this, we plan to port Autoscopy to embedded control devices that are currently used in the power grid and evaluate Autoscopy's performance on real equipment.

Currently, we are collaborating with Schweitzer Engineering Laboratories [30] to analyze how an Autoscopy-enabled power device would perform in simulated use cases compared with using a virtual machine and hypervisor. We are considering two systems in our analysis: an x86-based general computing platform and a weaker PowerPC-based device. The differences between the two systems, in terms of architecture and resource availability, will provide a good test of Autoscopy's flexibility and lightweight design.

We also plan to test a basic virtualized configuration on both power devices, placing the kernel inside a VM monitored by a hypervisor and running the same tests as performed on Autoscopy-enabled devices. This will provide a benchmark to show how Autoscopy performs in relation to a hypervisor-based solution. Our plan is to evaluate Autoscopy and the hypervisor alternative in terms of the overhead they impose on power systems, and to determine whether or not an in-kernel approach can offer better performance with less interference.

Conclusions

Autoscopy takes a practical approach to intrusion detection that operates within the operating system kernel and leverages its built-in tracing framework to minimize the performance overhead on the host system. Our tests demonstrate the effectiveness of Autoscopy in a non-embedded environment. However, Autoscopy also holds promise as a means for protecting embedded control systems in the electrical power grid. Given the critical, time-sensitive nature of the tasks performed by embedded devices in the power grid, Autoscopy offers the flexibility to balance detection functionality with the overhead imposed on the system. Since it is situated in the kernel, Autoscopy requires some hardware (e.g., memory immutability) or software (e.g., kernel hardening) protection measures. However, these protective measures would cost less than full-blown reference monitor isolation via hardware virtualization that underlies hypervisor-based solutions.

Note that the views and opinions in this paper are those of the authors and do not necessarily reflect those of the United States Government or any agency thereof.

Table 1 .

 1 Autoscopy detection results. of processor cycles (more computations are required to locate the appropriate data structures) and/or code size (to accommodate the extra functions needed to duplicate kernel behavior). These requirements, in turn, increase the chances of malware being detected on the host system.

	Technique	Malware	Detected
	Syscall table hooking	superkit	Yes
	Syscall table entry hooking	kbdv3, Rial, Synapsys v0.4	Yes
	Interrupt table hooking	enyelkm v1.0	Yes
	Interrupt table entry hooking DR v0.1	Yes
	/proc entry hooking	DR v0.1, Adore-ng 2.6	Yes
	VFS hooking	Adore-ng 2.6	Yes
	Kernel text modification	Phantasmagoria	No
	host in terms

Table 2 .

 2 Autoscopy results.

	SPEC CPU2000	Native	Autoscoped Overhead
	Benchmark	(s)	(s)
	164.gzip	458.851	461.660	+0.609%
	168.wupwise	420.882	419.282	-0.382%
	176.gcc	211.464	209.825	-0.781%
	256.bzip2	458.536	457.160	-0.303%
	254.perlbmk	344.356	346.046	+0.489%
	255.vortex	461.006	467.283	+1.343%
	177.mesa	431.273	439.970	+1.977%
	lmbench Latency	Native	Autoscoped Overhead
	Measurement	(µs)	(µs)
	Simple syscall	0.1230	0.1228	-0.163%
	Simple read	0.2299	0.2332	+1.415%
	Simple write	0.1897	0.1853	-2.375%
	Simple fstat	0.2867	0.2880	+0.451%
	Simple open/close	7.1809	8.0293	+10.566%
	lmbench Bandwidth	Native	Autoscoped Overhead
	Measurement	(Mbps)	(Mbps)
	Mmap read	6,622.19	6,612.64	+0.144%
	File read	2,528.72	1,994.18	+21.139%
	libc bcopy unaligned	6,514.82	6,505.84	+0.138%
	Memory read	6,579.30	6,589.08	-0.149%
	Memory write	6,369.95	6,353.28	+0.262%
	Benchmark	Native	Autoscoped Overhead
		(s)	(s)
	Apache httpd 2.2.10	184.090	187.664	+1.904%
	compilation
	Random 256 MB file	141.788	147.780	+4.055%
	creation
	Linux kernel 2.6.19.7	5,687.716	5,981.030	+4.904%
	compilation

Acknowledgements

This research was supported by the Department of Energy under Award No. DE-OE0000097. The authors also wish to thank David Whitehead and Dennis Gammel (Schweitzer Laboratories) and Tim Yardley (University of Illinois at Urbana-Champaign) for their advice and assistance with the Autoscopy test plan.


Hamed Okhravi

Adam Comella

Eric Robinson

Stephen Yannalfo

Peter Michaleas

Joshua Haines

CREATING A CYBER MOVING TARGET FOR CRITICAL INFRASTRUCTURE APPLICATIONS

Keywords: Cyber moving target, platform heterogeneity, virtualization

Despite the significant amount of effort that often goes into securing critical infrastructure assets, many systems remain vulnerable to advanced, targeted cyber attacks. This paper describes the design and implementation of the Trusted Dynamic Logical Heterogeneity System (TALENT), a framework for live-migrating critical infrastructure applications across heterogeneous platforms. TALENT permits a running critical application to change its hardware platform and operating system, thus providing cyber survivability through platform diversity. TALENT uses containers (operating-system-level virtualization) and a portable checkpoint compiler to create a virtual execution environment and to migrate a running application across different platforms while preserving the state of the application (execution state, open files and network connections). TALENT is designed to support general applications written in the C programming language. By changing the platform on-the-fly, TALENT creates a cyber moving target and significantly raises the bar for a successful attack against a critical application. Experiments demonstrate that a complete migration can be completed within about one second.

Introduction

Critical infrastructure systems are an integral part of the national cyber infrastructure. The power grid, oil and gas pipelines, utilities, communications systems, transportation systems, and banking and financial systems are examples of critical infrastructure systems. Despite the significant amount of effort and resources used to secure these systems, many remain vulnerable to ad-vanced, targeted cyber attacks. The complexity of these systems and their use of commercial-of-the-shelf components often exacerbate the problem.

Although protecting critical infrastructure systems is a priority, recent cyber incidents [START_REF] Brown | Stuxnet worm causes industry concern for security firms[END_REF][START_REF]Industrial Control Systems Cyber Emergency Response Team (ICS-CERT)[END_REF] have shown that it is imprudent to rely completely on the hardening of individual components. As a result, attention is now focusing on game-changing technologies that achieve mission continuity during cyber attacks. In fact, the U.S. Air Force Chief Scientist's report on technology horizons [START_REF]Report on Technology Horizons: A Vision for Air Force Science and Technology During 2010-2030[END_REF] mentions the need for "a fundamental shift in emphasis from 'cyber protection' to 'maintaining mission effectiveness' in the presence of cyber threats" as a way to build cyber systems that are inherently intrusion resilient. Moreover, the White House National Security Council's progress report [START_REF]Cybersecurity Progress after President Obama's Address[END_REF] mentions a "moving target" -a system that moves in multiple dimensions to foil the attacker and increase resilience -as one of the Administration's three key themes for its cyber security research and development strategy.

This paper describes the design and implementation of the Trusted Dynamic Logical Heterogeneity System (TALENT), a framework for live-migrating critical applications across heterogeneous platforms. In mission-critical systems, the mission itself is the top priority, not individual instances of the component. TALENT can help thwart cyber attacks by live-migrating the mission-critical application from one platform to another. Also, by dynamically changing the platform at randomly-chosen time intervals, TALENT creates a cyber moving target that places the attacker at a disadvantage and increases resilience. This means that the information collected by the attacker about the platform during the reconnaissance phase becomes ineffective at the time of attack.

TALENT has several design goals:

Heterogeneity at the instruction set architecture level, meaning that applications should run on processors with different instruction sets.

Heterogeneity at the operating system level.

Preservation of the state of the application, including the execution state, open files and sockets. This is an important property in mission-critical systems because simply restarting the application from scratch on a different platform may have undesirable consequences.

Working with a general-purpose system language such as C. Much of TAL-ENT's functionality is straightforward to implement using a platformindependent language like Java because the Java Virtual Machine provides a sandbox for applications. However, many commodity and commercial-of-the-shelf software systems are developed in C. Restricting TAL-ENT to a Java-like language would limit its use.

TALENT must provide operating system and hardware heterogeneity while preserving the state and environment despite the incompatibility of binaries between different architectures. TALENT addresses these challenges using: (i) operating-system-level virtualization (container-based operating system) to sandbox the application and migrate the environment including the filesystem, open files and network connections; and (ii) portable checkpoint compilation to compile the application for different architectures and migrate the execution state across different platforms.

TALENT is novel in several respects. TALENT is a heterogeneous platform system that dynamically changes the instruction set and operating system. It supports the seamless migration of critical applications across platforms while preserving their states. Neither application developers nor operators require prior knowledge about TALENT; TALENT is also application agnostic. Other closely-related solutions either lose the internal state of applications or are limited to specific types of applications (e.g., web servers). The TALENT implementation is optimized to reduce the migration time -the current prototype completes the migration of state and environment in about one second. To the best of our knowledge, TALENT is the first realization of a cyber moving target through platform heterogeneity.

Threat Model

The TALENT threat model assumes there is an external adversary who is attempting to exploit a vulnerability in the operating system or in the application binary in order to disrupt the normal operation of a mission-critical application. For simplicity and on-the-fly platform generation, a hypervisor (hardware-level virtualization) is used. The threat model assumes that the hypervisor and the system hardware are trusted. We assume that the authenticity of the hypervisor is checked using hardware-based cryptographic verification (e.g., TPM) and that the hypervisor implementation is free of bugs. We also assume that the operating-system-level virtualization logic is trusted. However, the rest of the system (including the operating system and applications) is not trusted and may contain vulnerabilities and malicious logic.

We also assume that, although an attack may be feasible against a number of different platforms (operating system/architecture combinations), there exists a platform that is not susceptible to the attack. This means that not all the platforms are vulnerable. Our primary goal is to migrate a mission-critical application to a different platform at random time intervals when a new vulnerability is discovered or when an attack is detected. Attacks can be detected using various techniques that are described in the literature (e.g., [START_REF] Carl | Denial-of-service attack detection techniques[END_REF]).

Heterogeneity at different levels can mitigate attacks. Application-level heterogeneity protects against binary-and architecture-specific exploits, and untrusted compilers. Operating-system-level heterogeneity mitigates kernelspecific attacks, operating-system-specific malware and persistent operating system attacks (rootkits). Finally, hardware heterogeneity can thwart supply chain attacks, malicious and faulty hardware, and architecture-specific attacks. It is important to note that TALENT is by no means a complete defense against all these attacks. Instead, it is designed to enhance survivability in the presence of platform-specific attacks using dynamic heterogeneity.

Design

TALENT uses two key concepts, operating-system-level virtualization and portable checkpoint compilation, to address the challenges involved in using heterogeneous platforms, including binary incompatibility and the loss of state and environment.

Virtualization and Environment Migration

Preserving the environment of a critical infrastructure application is an important goal. The environment includes the filesystem, configuration files, open files, network connections and open devices. Note that many of the environment parameters can be preserved using virtual machine migration. However, virtual machine migration can only be accomplished using a homogeneous operating system and hardware. Indeed, virtual machine migration is not applicable because it is necessary to change the operating system and hardware while migrating a live application.

TALENT uses operating-system-level virtualization to sandbox an application and migrate the environment.

OS-Level Virtualization

In operating-system-level virtualization, the kernel allows for multiple isolated user-level instances. Each instance is called a container (jail or virtual environment). The method was originally designed to support fair resource sharing, load balancing and cluster computing applications. This type of virtualization can be thought of as an extended chroot in which all resources (devices, filesystem, memory, sockets, etc.) are virtualized.

Note that the major difference between operating-system-level virtualization and hardware-level virtualization (e.g., Xen and KVM) is the semantic level at which the entities are virtualized (Figure 1). Hardware-level hypervisors vir- tualize disk blocks, memory pages, hardware devices and CPU cycles, whereas operating-system-level virtualization works at the level of filesystems, memory regions, sockets and kernel objects (e.g., IPC memory segments and network buffers). Hence, the semantic information that is often lost in hardware virtualization is readily available in operating-system-level virtualization. This makes operating-system-level virtualization a good choice for applications where semantic information is needed, for example, when monitoring or sandboxing at the application level.

Environment Migration As discussed above, TALENT uses operatingsystem-level virtualization to migrate the environment of a critical application. When migration is requested (as a result of a malicious activity or a periodic migration), TALENT migrates the container of the application from the source machine to the destination machine. This is done by synchronizing the filesystem of the destination container with the source container. Since the operating system keeps track of open files, the same files are opened in the destination. Because this information is not available at the hardware virtualization level (due to the semantic gap between files and disk blocks), additional techniques must be implemented to recover the information (e.g., virtual machine introspection). On the other hand, this information is readily available in TALENT.

Network connections can be virtualized in three ways: second layer, third layer and socket virtualization. These terms come from the OpenVZ documentation [START_REF] Kolyshkin | Virtualization in Linux[END_REF]. Virtualizing a network at the second layer means that each container has its own IP address, routing table and loopback interface. Third layer virtualization implies that each container can access any IP address/port and that sockets are isolated using the namespace. Socket virtualization means that each container can access any IP address/port and that sockets are isolated using filtration.

Figure 2 shows the different network virtualization approaches for two containers. In socket virtualization, the port numbers are divided between the containers, whereas in third layer virtualization, the entire port range is available to every container. TALENT uses second layer virtualization in order to be able to migrate the IP address of a container.

To preserve network connections during migration, the IP address of the container's virtual network interface is migrated to the new container. Then, the state of each TCP socket (sk buff of the kernel) is transferred to the destination. The network migration is seamless to the application, and the application can continue sending and receiving packets on its sockets. In fact, our evaluation example shows that the state of an SSH connection is preserved during the migration. Many operating-system-level virtualization frameworks also support IPC and signal migration. In each case, the states of IPC and signals are extracted from the kernel data structures and migrated to the destination. These features are supported in TALENT through the underlying virtualization layer.

Checkpointing and Process Migration

Migrating the environment is only one step in backing up the system because the state of running programs must also be migrated. To do this, a method to checkpoint running applications must be implemented. After all the checkpointed program states are saved in checkpoint files, the state is migrated by simply mirroring the filesystem.

Requirements Checkpointing in TALENT must meet certain requirements.

Portability: Checkpointed programs should be able to move back and forth between different architectures and operating systems in a heterogeneous computing environment.

Transparency: Heavy code modification should not be required to existing programs in order to introduce proper checkpointing.

Scalability: Checkpointed programs may be complex and may handle large amounts of data. Checkpointing should be able to handle such programs without affecting system performance.

A portable checkpoint compiler (PCC) can help meet the portability requirement. Figure 3 illustrates the portable checkpoint compilation process, which allows compilation to occur independently on various operating system/architecture pairs. The resulting executable program, including the inserted checkpointing code, functions properly on each platform on which it was compiled.

Transparency is obtained by performing automatic code analysis and checkpoint insertion. This prevents the end user from having to modify their code to indicate where checkpointing should be performed and what data should be checkpointed.

Scalability is obtained in two ways. First, the frequency of checkpointing bottlenecks in the checkpointing process is controlled. Second, through the use of compressed checkpoint file formats, the checkpoints themselves remain as small as possible even as the amount of data processed by the program increases.

Variable Level Checkpointing There are two possible approaches for checkpointing a live process: data segment level checkpointing (DSLC) and variable level checkpointing (VLC). Note that DSLC and VLC are different types of portable checkpoint compilers.

In DSLC [START_REF] Stellner | CoCheck: Checkpointing and process migration for MPI[END_REF], the entire state of the process including the stack and heap are dumped into a checkpoint file. DSLC preserves the entire state of a process, but since the checkpoint file contains platform specific data such as the stack and heap, this approach suffers from a lack of portability.

VLC [START_REF] Bronevetsky | Automated application-level checkpointing of MPI programs[END_REF], on the other hand, stores the values of restart-relevant variables in the checkpoint file. Since the checkpoint file only contains portable data, VLC is a good candidate for migration across heterogeneous platforms. In order to construct the entire state of the process, VLC must re-execute the non-portable portions of the code. The non-portable portions refer to the platform-dependent values stored in the stack or heap, not the variables.

To perform VLC, the code is precompiled to find restart-relevant variables. These variables and their memory locations are then registered in the checkpointing tool. When checkpointing, the process is paused and the values of the memory locations are dumped into a file. The checkpointing operation must occur at safe points in the code to generate a consistent view.

At restart, the memory of the destination process is populated with the desired variable values from the checkpoint file. Some portions of the code are re-executed in order to construct the entire state.

A simple example involving a factorial computation is presented to illustrate VLC operation. Of course, TALENT is capable of handling much more complicated code bases. The factorial code is shown in Figure 4. For simplicity, the code incorporates a main function with no inputs.

Figure 5 illustrates the VLC markup of the factorial program. All calls to the checkpointing tool are shown with pseudo-function calls with VLC prefixes. First, the checkpointer is initialized. Then, the variables to be tracked and checkpointed are registered with the tool. In the example, the variables fact, curr and i have to be registered. The actual checkpointing must occur inside the loop after each iteration. When the loop is done, there is no need to track the variables any longer, so they are unregistered. Finally, the environment is torn down before the return. Note that for transparency and scalability, the code markup has been done automatically and prior to compilation. TALENT uses the HDF5 format [START_REF] Hdf Group | HDF4 Reference Manual[END_REF] through the precompiler checkpointing tool. HDF5 is an open, versatile data model that can represent complex data objects. It is also portable in that it can represent various types of bitness and endianness. Like XML, HDF5 is self-describing. Unlike XML, HDF5 uses a binary format that allows for the efficient parsing of data.

Figure 6 illustrates the complete migration process. First, the environment of the application is migrated using container migration. Then, the application itself is checkpointed and resumed on the destination platform. Heterogeneous platforms are illustrated using different colors in the figure. The application box on the destination platform shows a different binary of the same application that is compiled for the platform.

Implementation

TALENT is implemented using the OpenVZ container-based operating system and the CPPC portable checkpoint compiler.

Environment Migration

Several operating-system-level virtualization implementations are available, including OpenVZ [START_REF] Kolyshkin | Virtualization in Linux[END_REF] and LXC [18] for Linux, Virtuozzo [START_REF] Parallels | Clustering in Parallels Virtuozzo-Based Systems[END_REF] for Windows, and Jail [START_REF] Sarmiento | Securing FreeBSD using Jail[END_REF] for FreeBSD. We have chosen UNIX-like operating systems as our platform. We have also chosen OpenVZ as the container because of its ease of use, stable code and support for second layer network virtualization. In particular, we have used OpenVZ version 2.6.27 and have patched it into different kernels; KVM [START_REF] Habib | Virtualization with KVM[END_REF] has been used as the underlying hypervisor.

We have implemented and tested TALENT on Intel Xeon 32-bit, Intel Core 2 Quad 64-bit and AMD Opteron 64-bit processors. Also, we have tested TALENT on the Gentoo, Fedora (9, 10, 11 and 12), CentOS (4 and 5), Debian (4 and 5), Ubuntu (8 and 9) and SUSE (10 and 11) operating systems. In total, we have tested 37 combinations.

For environment migration, we do not use the OpenVZ live migration feature because it migrates the processes within the container and causes binary incompatibility. Instead, we migrate the environment by freezing the container, synchronizing the filesystem, migrating the virtual network interface and transferring buffers, IPC and signals. We then substitute the binary of the application built for the destination processor. Note that TALENT can also be implemented across more diverse operating systems such as Windows using the Virtuozzo [START_REF] Parallels | Clustering in Parallels Virtuozzo-Based Systems[END_REF] container. In this case, migrating complex environment features such as signals and IPC requires more effort because they have to be mapped correctly to the destination platform.

Process Migration

Given the desired requirements enumerated in Section 3.2, TALENT employs the Controller/Precompiler for Portable Checkpointing (CPPC) [START_REF] Rodriguez | CPPC: A compiler-assisted tool for portable checkpointing of message-passing applications[END_REF] to save the state of a running program. CPPC is a VLC precompiler implementation. It is capable of storing the program state of a running program in a format that is operating system and hardware independent (HDF5), and then correctly restarting the program on a different platform using the previously-stored state.

CPPC is a compiler-assisted checkpointing program that involves four execution phases:

Compiling the Code: The code is compiled on each platform independently.

Configuring the Run: The preferences for checkpointing during a run are configured.

Checkpointing: The run is started and checkpointing of the state occurs automatically.

Restarting the Run: The checkpoint (after being migrated) is resumed on a new platform.

Compiling the Code CPPC can compile traditional C and Fortran 77 code. It compiles unmodified source code and the programmer does not need to have any knowledge of checkpointing. CPPC automatically determines how and where to checkpoint a program. Section 4.3 shows an example of how this is done.

CPPC interfaces with the user code as a precompiler. It uses the Cetus compiler infrastructure [START_REF] Lee | Cetus -An extensible compiler infrastructure for source-to-source transformation[END_REF] to determine the semantic behavior of a program in order to decide where to place checkpointing directives. Once this is determined, the code is re-factored with checkpointing function calls. The re-factored code can then be compiled using a traditional compiler such as cc or gcc.

Configuring the Run CPPC requires a configuration file in order to run with checkpointing. This file specifies the parameters used for checkpointing, including the frequency of checkpointing, the number of checkpoints to be stored and their storage locations. Although a default file is provided, a user may wish to configure the file based on the expected behavior of the program. For example, the frequency of checkpointing can be increased for critical applications that change frequently so as to capture the most recent state; or the frequency can be decreased for slowly-changing programs to avoid bottlenecks when writing files.

Run parameters can be changed directly in the configuration file by modifying the appropriate values or by using command line options when starting a run. Typically, a program will have a suitable configuration specified in the configuration file. However, a user may override the configuration to obtain different behavior by entering a new value for a parameter via the command line. The configuration file can be stored in text or XML formats.

Checkpoint Checkpoints are stored in a file using the HDF5 format [START_REF] Hdf Group | HDF4 Reference Manual[END_REF].

Since this format is deployed on many platforms, checkpoint files can be stored in a manner that is compatible across a range of architectures and operating systems. Additionally, a CRC-32-based algorithm is supported to verify the integrity of checkpoint files.

As stated above, checkpointing is done automatically. The user may change the rate at which checkpointing is performed via the configuration file or the command line. Compiler options also allow programmers to manually specify where checkpointing should occur by adding #pragma directives to the source code. Directives also exist for other CPPC functionality such as indicating code that should be run upon restart for re-initializing data not stored in memory, or for other initialization tasks such as restarting the message passing interface.

Restarting from a Checkpoint After a run has been started and a checkpoint has been recorded, it is possible to restart the run from the last recorded checkpoint. This is done on the same platform or on a different platform. "Jump" statements are added in the original code to the locations of the checkpoints. Based on the checkpoint file, the jump locations are known upon restart. These jump states are ignored during the initial run so that the program is executed as if no changes were introduced. In addition to jumping to the appropriate starting location, the checkpoint file contains information about variable values within the program. These are loaded upon restart to ensure that the program resumes in the same state it was upon checkpointing.

Code Example

We revisit the factorial code in Figure 4 to illustrate the operation of the checkpointer.

First, the code is automatically converted to a markup code using #pragma directives to specify where special CPPC content should be inserted. Figure 7 shows the markup for the factorial code. Note that the variables to be checkpointed are registered with CPPC.

Next, CPPC uses the markup in Figure 7 to create a final version of the code that the C compiler can understand. The final code is not shown here due to its length. However, the concepts involved in generating the code are straightforward. For each checkpoint, line labels are inserted to mark the locations of the checkpoints. The labels are tracked using an array that is populated when CPPC is initialized. Each label is assigned a unique ID based on its location in the array. When a call to checkpoint is made, the appropriate ID is also stored in the checkpoint file.

When the program is restarted, the call to initialize re-populates the registered values that were in memory from the previous run. The code then jumps to the appropriate checkpoint label. This is achieved by using a "goto" command to jump to the line in the line label array referenced by the ID stored in the checkpoint file. From here, the program proceeds as normal, continuing to checkpoint at the indicated locations in the program.

Evaluation

We have developed a test application to evaluate the performance of TAL-ENT. The application contains 2,000 lines of C code and a GUI developed using wxWidgets [START_REF] Smart | Cross-Platform GUI Programming with wxWidgets[END_REF]. The graphical output of the application is sent to a remote machine via an SSH connection. Upon receiving a migration request, the application and its GUI are migrated from a Gentoo/Intel Xeon 32-bit machine to an Ubuntu 10.04.1/AMD Opteron 64-bit machine using environment migration and checkpointing.

The original migrations took a long time (about a minute), so we decided to time the individual elements of migration. After breaking down the delays, we discovered that synchronizing the filesystem took 98.7% of the migration time. This is not surprising because, during a migration, the entire filesystem available to the container must be copied to the destination. As a result, we decided to focus on optimizing the filesystem synchronization.

In the optimized version, the filesystem is synchronized with the destination once before the migration occurs. The synchronization is subsequently performed at periodic intervals by sending the differences to the destination.

Figure 8 presents the optimized synchronization model. We chose 30 seconds as the synchronization interval. When a migration is requested, only the differences are sent to the destination. This simple optimization reduces the environment migration time to about one second.

Figure 9 shows the performance of TALENT with and without optimization. Note that quota and configuration refer to checking the resource quotas (CPU, disk, memory, etc.) assigned to each container and verifying the platform configurations, respectively. If the optimization is enabled, then network traffic to the destination platform has to be strictly limited to filesystem updates to prevent the attacker from performing a reconnaissance of the destination.

During the migration, the graphical output at the remote machine disappears for about two seconds. When the migration is completed, the graphical output reappears on the remote terminal (now running on the second platform) without any user intervention because the state of the SSH connection is preserved.

Related Work

Several data segment level [START_REF] Chen | CLIP: A checkpointing tool for message passing parallel programs[END_REF][START_REF] Stellner | CoCheck: Checkpointing and process migration for MPI[END_REF] and variable level process migration techniques [START_REF] Bronevetsky | Automated application-level checkpointing of MPI programs[END_REF] have been proposed in the literature. These methods are often used in high performance and cluster computing systems for load balancing and fault tolerance.

Virtual machine migration [START_REF] Clark | Live migration of virtual machines[END_REF] has also been proposed as a cluster administration technique for load balancing, online maintenance and power management. However, it requires a homogeneous architecture and operating system in order to preserve state.

The Self-Cleansing Intrusion Tolerance (SCIT) Project [START_REF] Sood | Intrusion tolerance to mitigate attacks that persist[END_REF] is closely related to TALENT. It migrates an application across different virtual machines to reduce the exposure time. Our work differs from SCIT in a number of ways. First, TALENT preserves the state of the application. SCIT-web server [START_REF] Bangalore | Securing web servers using self cleansing intrusion tolerance (SCIT)[END_REF] and SCIT-DNS [START_REF] Huang | Incorruptible self cleansing intrusion tolerance and its application to DNS security[END_REF] preserve the session information and DNS master file and keys, respectively, but not the internal state of the application. Second, TALENT uses heterogeneous platforms for migration. The designers of SCIT mention the use of diverse operating systems and memory images to further confuse an attacker, but the current implementation uses the same operating system with the same configuration [START_REF] Bangalore | Securing web servers using self cleansing intrusion tolerance (SCIT)[END_REF]. Finally, TALENT is designed to support general critical infrastructure applications and is not limited to a specific server.

The Resilient Web Service (RWS) Project [START_REF] Huang | Automating intrusion response via virtualization for realizing uninterruptible web services[END_REF] uses a virtualization-based web server system that detects intrusions and periodically restores them to a pristine state. Its successor, RWS-Moving Target (RWS-MT) [START_REF] Huang | A security evaluation of a novel resilient web serving architecture: Lessons learned through industry/academia collaboration[END_REF] plans to use diversity to create a moving target, but it only focuses on web servers as the critical application. In addition, both systems lose the state of the web server.

Certain forms of server rotation have been proposed by Blackmon and Nguyen [START_REF] Blackmon | Storage: High-availability file server with heartbeat[END_REF] and by Rabbat, et al. [START_REF] Rabbat | A high-availability clustering architecture with data integrity guarantees[END_REF] in an attempt to achieve high availability servers.

Conclusions

The TALENT system provides dynamic, heterogeneous platforms for critical infrastructure applications. It creates a cyber moving target that offers resilience in the face of platform-specific cyber attacks. To the best of our knowledge, TALENT is the first heterogeneous platform solution that preserves the internal state of a general application.

The current TALENT prototype is focused on providing high availability. There is no guarantee that the migrated state (persistent or ephemeral) is not already corrupted. In future work, we plan to extend TALENT by adding sanitization and recovery capabilities. This would provide integrity guarantees for an application under attack. We also plan to augment TALENT with an attack detection engine that can trigger migration. Finally, we plan to integrate TALENT with an assessment framework based on attack graphs [START_REF] Ingols | Modeling modern network attacks and countermeasures using attack graphs[END_REF] so that the destination platform can be selected based on formal vulnerability and reachability analysis.

Note that the opinions, interpretations, conclusions and recommendations in this paper are those of the authors and are not necessarily endorsed by the U.S. Government.

Figure 1 .

 1 Figure 1. OS-level and hardware-level virtualization approaches.

Figure 2 .

 2 Figure 2. Network virtualization approaches.

Figure 3 .

 3 Figure 3. Portable checkpoint compilation.

Figure 6 .

 6 Figure 6. TALENT migration process.

Figure 8 .

 8 Figure 8. Optimized filesystem synchronization model.

Figure 9 .

 9 Figure 9. TALENT's performance with and without optimization.

  Figure 7. CPCC markup of the factorial program.

	int main(int argc, char **argv)
	{
	int fact;
	double curr;
	int i;
	#pragma cppc init
	fact = 20;
	curr = 1;
	#pragma cppc register
	( fact, curr, i )
	for(i=1; i<=fact; i++)
	{
	#pragma cppc checkpoint
	curr = curr * i;
	}
	#pragma cppc unregister
	( fact, curr, i )
	printf("%d factorial is %f",
	fact, curr);
	#pragma cppc shutdown
	return 0;
	}

Acknowledgements

This work was sponsored by the U.S. Department of Defense under Air Force Contract FA8721-05-C-0002.

Checkpoint Portability

The checkpoint file itself must have a portable format to achieve portability across heterogeneous platforms. Storing the checkpoint in a simple binary file can result in incompatibility if the destination platform has different "bitness" (32 vs. 64 bits) or endianness (little vs. big). Thus, the checkpoint file format has to be portable.


Thomas Mcevoy

Stephen Wolthusen

A PLANT-WIDE INDUSTRIAL PROCESS CONTROL SECURITY PROBLEM

Keywords:

Industrial control systems are a vital part of the critical infrastructure. The potentially large impact of a failure makes them attractive targets for adversaries. Unfortunately, simplistic approaches to intrusion detection using protocol analysis or naïve statistical estimation techniques are inadequate in the face of skilled adversaries who can hide their presence with the appearance of legitimate actions.

This paper describes an approach for identifying malicious activity that involves the use of a path authentication mechanism in combination with state estimation for anomaly detection. The approach provides the ability to reason conjointly over computational structures, and operations and physical states. The well-known Tennessee Eastman reference problem is used to illustrate the efficacy of the approach.

Introduction

In industrial control systems, detection and prevention extend beyond the computational model into the physical realm. While protocol analysis may signal anomalies as proposed by Coutinho, et al. [START_REF] Coutinho | Attack and fault identification in electric power control systems: An approach to improve security[END_REF], a skilled adversary can issue apparently authentic commands [START_REF] Verba | Idaho National Laboratory Supervisory Control and Data Acquisition Intrusion Detection System (SCADA IDS)[END_REF] using legitimate protocols. Analysis may be extended using state estimation techniques, but should not be applied naïvely [START_REF] Mcevoy | Detecting sensor signal manipulations in non-linear chemical processes[END_REF][START_REF] Svendsen | Using physical models for anomaly detection in control systems[END_REF], especially in non-linear environments such as those encountered in the biochemical industry [START_REF] Gamez | Safeguarding critical infrastructures, in Dependable Computing Systems: Paradigms, Performance Issues and Applications[END_REF].

This paper describes an approach that utilizes state estimation in intrusion detection in combination with path authentication techniques. The approach assumes the existence of an adversary who can subvert channels and system functions [START_REF] Mcevoy | A formal adversary capability model for SCADA environments[END_REF]. Hence, it is necessary to verify the reliability and independence of channels and functions for message transmission. This is achieved by combining state estimation techniques using proxy measurements [START_REF] Mcevoy | Detecting sensor signal manipulations in non-linear chemical processes[END_REF] with algebraic proofs over structures and operations. The Tennessee Eastman reference prob-lem is employed as a case study to demonstrate the application of the approach to non-linear systems.

Related Work

Industrial control systems are a vital part of the critical infrastructure and are attractive targets for adversaries. Security in such systems is generally weak [START_REF] Creery | Industrial cybersecurity for power systems and SCADA networks[END_REF]. Recent research has focused on anomaly detection at the protocol level, since traffic in control networks is well-characterized and, hence, particularly amenable to such techniques [START_REF] Coutinho | Attack and fault identification in electric power control systems: An approach to improve security[END_REF]. Approaches using physical state estimation techniques have also been researched [START_REF] Su | Context information-based cyber security defense of protection system[END_REF], but these are largely limited to linear systems. However, many industrial systems, including biological and chemical processes, exhibit non-linear behavior or require non-linear control laws, resulting in less well-defined models and limited accuracy [START_REF] Gamez | Safeguarding critical infrastructures, in Dependable Computing Systems: Paradigms, Performance Issues and Applications[END_REF]. Real-time detection is also an important requirement for these industrial systems [START_REF] Ten | Cybersecurity for critical infrastructures: Attack and defense modeling[END_REF].

It has been argued that, in the presence of channel compromise, adversaries may use protocols correctly and present syntactically and semantically correct messages, resulting in the failure of conventional detection techniques to signal anomalies [START_REF] Mcevoy | A formal adversary capability model for SCADA environments[END_REF][START_REF] Verba | Idaho National Laboratory Supervisory Control and Data Acquisition Intrusion Detection System (SCADA IDS)[END_REF]. These attacks may also be concealed in noisy processes that are not amenable to elementary statistical analysis [START_REF] Svendsen | Using physical models for anomaly detection in control systems[END_REF]. In particular, this is true for non-linear systems [START_REF] Mcevoy | Detecting sensor signal manipulations in non-linear chemical processes[END_REF]. The Tennessee Eastman reference problem [START_REF] Downs | A plant-wide industrial process control problem[END_REF] is commonly considered in control systems research and pedagogy (see, e.g., [START_REF] Bie | Fault detection and diagnosis of a continuous process based on multiblock principal component analysis[END_REF][START_REF] Kraus | A moving horizon state estimation algorithm applied to the Tennessee Eastman benchmark process[END_REF][START_REF] Larsson | Plant-wide control -A review and a new design procedure[END_REF][START_REF] Ricker | Decentralized control of the Tennessee Eastman challenge process[END_REF]). It provides a well-defined problem space for using different control laws. Furthermore, a number of simulation models are available for this problem. The process calculus used to construct the control overlay model in this paper was defined in [START_REF] Mcevoy | A formal adversary capability model for SCADA environments[END_REF], where an adversary capability model for industrial control systems was also proposed. This paper uses the process calculus model to analyze computational structures and operations using techniques related to probabilistic packet marking and path authentication [START_REF] Dang | Performance analysis of probabilistic packet marking in IPv6[END_REF].

Control Problem

An attack on an industrial control system is usually accompanied by the use of concealment techniques. Protocol analysis by itself may not detect an attack that uses legitimate protocols. State estimation techniques rely on the integrity of the signals. They can deal with missing data and noisy signals, but not with deceptive or misleading signals from subverted channels. Hence, conjoint reasoning is required over both channels and signals to uncover malicious activity, helping separate false and true signals.

Solution Approach

We define a computational overlay for an industrial control system using an applied π-calculus [START_REF] Sangiorgi | π-Calculus: A Theory of Mobile Processes[END_REF]. In the context of the Tennessee Eastman challenge problem [START_REF] Downs | A plant-wide industrial process control problem[END_REF], we demonstrate the existence of proxy measurements of plant activity that can be used to detect anomalies. However, this requires the ability to reason about channel integrity. This is accomplished using path authentication methods that can be proven within the algebraic framework. An explicit model of human intervention is not presented, rather we consider operational capability in terms of detection.

Process Calculus

The capabilities of our π-calculus variant are specified by:

π ::= xy p,r | x(z p,r ) | τ | λ | f ( - → z ) → xw, w | [x = y]π
A simplified version of the process calculus was presented in [START_REF] Mcevoy | A formal adversary capability model for SCADA environments[END_REF], where it was used to represent adversary capabilities. Here, we expand on its functionality to permit proofs over structures and operations.

The capabilities of the process calculus are: (i) sending a name with priority and routing; (ii) receiving a name with priority and routing; (iii) performing an unobserved action (with the special meaning of decision-making); (iv) performing an observable inaction (process failure); (v) name generating function; (vi) replication capability; and (vii) conditional capability. z is used to denote a vector of names. Names are typed as channels, variables or constants.

The operations of the π-calculus are retained and augmented as follows:

P ::= M | P |P ′ | νz P | !P M ::= 0 | π.P | M + M ′ | M ⊕ M ′
where P is a process that may be a summation, concurrent, a new process with (restricted) names, or replication. M is a summation that may be null or termination, a capability guarding a process and -adding a variant summation -a soft choice between retained alternatives and a hard choice between mutually exclusive alternatives (see Sangiorgi and Walker [START_REF] Sangiorgi | π-Calculus: A Theory of Mobile Processes[END_REF] for additional details). Hence, a process may partially order its messaging and the exercising of its capabilities in a manner that is not mutually exclusive. For example, the process may send a set of messages in some order. However, it cannot be subverted as an agent of the adversary and also resist such subversion because these outcomes are mutually exclusive. The name generating function takes a set of parameters and returns a name. In general, it provides a parametric interface to the physical processes or control functions that may be defined by a state space equation or its transform. The function can also be used for other purposes, for example, to simulate automated decision-making or as a cryptographic primitive.

Routing captures the ability of the system to send a message to a process by means of another process, provided the name of the process exists in the intervening process. Routing information may be explicitly coded in the summation or understood implicitly from the process structure. For example, xm y .0|x(u).ru r .0 + x(u).su [y] .0|s(u).ȳu.0|r(u).0|y(u).0 sends m to x and for- wards it to y, but not to r. Prioritization can be captured by a simple ranking system [START_REF] Mcevoy | A formal adversary capability model for SCADA environments[END_REF].

Special types of functions are defined using a finite set of labels λ (e.g., delay and message loss). The actions of these properties can be described as necessary. However, they are essentially means for naming invisible process actions that would otherwise be regarded as degenerate terminations. The following equation illustrates one use of labels: ((xu + x(u)).0 + Loss + Delay) ≡ ((xu + x(u).0) + 0 + 0)

Model Creation

This section describes how a suitable state estimation algorithm may be used along with proxy measurements or estimators in combination with path authentication techniques to uncover reliable channels and to maintain system operations in the presence of malicious activity. The Tennessee Eastman challenge problem is used to illustrate the application of the approach to non-linear estimation problems for industrial control systems.

Tennessee Eastman Problem

The Tennessee Eastman plant is a non-contrived, albeit modified, model of a real chemical process (Figure 1). It consists of a reactor-separator-recycler arrangement involving two simultaneous irreversible gas-liquid exothermic reactions and two byproduct reactions given by:

A (g) + C (g) + D (g) → G (l) P roduct 1 A (g) + C (g) + E (g) → H (l) P roduct 2 A (g) + E (g) → F (l) Byproduct 3D (g) → 2F (l) Byproduct
The plant is open-loop, unstable and highly non-linear. Various approaches to its control have been described [START_REF] Larsson | Plant-wide control -A review and a new design procedure[END_REF], which can result in distinct channel architectures, rendering it a suitable candidate for testing a variety of models and techniques.

The gaseous reactants (g) form liquid products (l). Note that the products are not specifically identified and that the process was modified from the real industrial process by the original authors [START_REF] Downs | A plant-wide industrial process control problem[END_REF]. The gas phase reactions are catalyzed by a non-volatile substance dissolved in the liquid phase in the reactor. The reactor is pressurized and agitated, and uses an internal cooling bundle to remove the heat produced by the reactions.

The products leave the reactor in the vapor phase along with the unreacted feeds, while the catalyst remains in the reactor. The reactor product stream passes through a cooler that condenses the products, and from there to a vaporliquid separator. Non-condensed components cycle back to the reactor feed via a centrifugal compressor. Condensed components are sent to a product stripping column that removes the remaining reactants.

Products G and H exit the stripper base and are separated in a downstream refining section, which is not included in the problem statement. The byproducts and inerts are purged from the system in the vapor phase using a vapor-liquid separator. The system may be operated in six distinct modes to produce different product mass outputs.

The plant has twelve valves for manipulation, and a total of 41 measurements are involved in monitoring and control. Note that one of the valves is not shown in Figure 1, which only provides closed control loops; the valve is used for higher order control purposes.

Following the base control strategy outlined by McAvoy and Ye [START_REF] Mcavoy | Base control for the Tennessee Eastman problem[END_REF], most of the variables may be removed from consideration to leave the twelve control variables and twelve manipulated variables shown in Table 1. Hence, for state estimation purposes, depending on the control law used, not all the variables need to be considered. This implies a set of alternative measurements may be available as proxies for the main control variables. This also means that, for state estimation purposes, there are a number of possible measurements in addition to the main ones in the model that can be used for estimation by proxy [START_REF] Mcevoy | Detecting sensor signal manipulations in non-linear chemical processes[END_REF].

Tennessee Eastman Overlay

Using our process calculus, we can define a system architecture that satisfies the control purposes. To do so, we define the entities, messengers and agents of the system. By τ , entities make decisions. Messengers pass decisions as names. By f () →, agents are processes which act on decisions. For example, an operator that is an entity is defined by the equation:

Operator := xu.0 ⊕ x(u).0 ⊕ τ.0|!Operator
where the set Operator = {Operator, Adversary} and τ is the decision-making capability. A (simple) controller may be defined by:

Controller := νi((z(e) 1 .ze.f (p, k, e, i) → zi 1 + y(k ′ ) 2 .Controller⟨p, k ′ , e⟩.ȳk 2 + y(p ′ ) 2 .Controller⟨p ′ , k, e⟩.ȳp 2 ).0 + (y(m).Controller ′ ⟨p, k, e⟩.0 ⊕ Resist | !Controller)
where the controller may be changed to an agent of the adversary by a malicious message m that represents a successful attack, and R is the ability to resist such an attack with the set Agent := {Agent, P lantP rocess} representing the agent state. Other examples of control system structures are provided in [START_REF] Mcevoy | A formal adversary capability model for SCADA environments[END_REF]. They can be used to create the complete system infrastructure.

State Estimation

State estimation is the problem of accounting for the state of a system in the presence of process disturbances and measurement noise. A general non-linear system can be described as:

x k+1 = f (x k , u k ) + W k System Equation y k+1 = h(x k ) + v k Output Equation
where x is the state variable vector, u represents the inputs under control, w represents process noise, y is the measured output and v is the measurement noise. Note that x is not known directly, but is estimated based on y; this accounts statistically for both process and measurement noise. We assume that process and measurement noise can be represented as Gaussian white noise with a mean of zero (µ = 0) and a suitable variance (σ 2 ). Several state estimation algorithms are available for this purpose. An example is the extended Kalman filter [START_REF] Simon | Optimal State Estimation: Kalman, H ∞ and Nonlinear Approaches[END_REF]. Note, however, that state estimation techniques in general are defined recursively and hence have a "memory" of the previous states of a system. This distinguishes them from pure correlation techniques where the memory of previous system behavior is lost.

In the case of most industrial systems, it is possible to derive multiple sets of measurements that are functionally independent of each other in control terms. Thus, alternative means exist for testing the reliability of measurements and the ability to substitute one set of measurements for another for control and channel authentication purposes. For example, in the Tennessee Eastman system, influx A in Figure 1 can be measured directly by its flow meter and estimated by the initial flow analyzer, pressure controller and also inversely estimated based on D and E, C, G and H. Both the estimation techniques can be used and their results compared to identify inconsistencies and determine the integrity of channels and functions.

Model Application

We assume the existence of an adversary who can subvert channels and functions to act on his behalf. This means that encryption techniques cannot be used to guarantee the freshness or authenticity of messages since the message originators may be compromised by the adversary. In particular, the adversary (or rather his agents) can perfectly forge messages with respect to the protocol formulation and/or directly manipulate physical measurements.

We assume that a set of robust estimators E exist for a system such as the Tennessee Eastman problem, which we can use to detect inconsistent measurements. (The estimators are derived by simulation.) The goal is to clearly mark channels and sensors (controls) as reliable or unreliable to avoid an unnecessary system shutdown. To do this, it is necessary to prove that a set n = |E(•)| of independent channels exists for each estimator. In the case of untainted channels, the associated estimators can be used. However, if all the channels for an estimator are tainted, then a contingent estimator can be used provided that its channels are untainted. Clearly, a complete set of fully separated channels provides a trivial (but not minimal) solution. Non-trivial solutions are required because channels are generally shared by messages due to the convergence of channels onto an operator and resilience characteristics.

Channel independence may be demonstrated by variations on packet marking for path authentication [START_REF] Dang | Performance analysis of probabilistic packet marking in IPv6[END_REF]. Several such techniques may be investigated for applicability, considering parameters such as topological constraints.

We illustrate one technique by constructing a set of channels that use a "salt" to mark the route selected by a message. The salt is a shared secret between the channel and the operator. We assume that a set of known routes exist over which we define "normal routes" and "deviations." For each deviation, a salt is added to provide a trace of the path followed by a signal package.

Let the {P 1, P 2, P 3, P 4} be the controllers and Op be the operator as previously defined. We assume that each controller hashes the message identifiably. We define a set of channels such that each channel may re-route a message to an adjacent channel on message failure (Loss). Before doing so, it rehashes the message hash with its salt and attaches its name in order. The channels are defined by the equations:

Cn :=νs(x Dn u [Op] + x Cn (u) [Op] + Loss.Hash(u, s) → wC(n+1) z [Op] + w C(n-1) (z) [Op] + xDn z [Op] ).0|!Cn Dn :=νs(x D u [Op] + x Cn (u) [Op] + Loss.Hash(u, s) → wD(n+1) z [Op] + w D(n-1) (z) [Op] + xDn z [Op] ).0|!Dn En :=νs(x Op u [Op] + x En (u) [Op] + Loss.Hash(u, s) → wE(n+1) z [Op] + w E(n-1) (z) [Op] + xOp z [Op] ).0|!En
The overall structure is given by the equations:

xP 1 zx [Op] , 1.P 1|C1|D1|E1| xP 2 zx [Op] , 1.P 2|C2|D2|E2|Op xP 3 zx [Op] , 1.P 3|C3|D3|E3| xP 4 zx [Op] , 1.P 4|C4|D4|E4|
Note that the topology is deliberately constrained, a characteristic of industrial control systems. We claim that each message follows a route that is uniquely identified by its origin and its membership in the set of deviations. Let K m,n be a message with n salts and m = n + 1 names. The name order must be consistent with the deviations permitted by the topology and must match the salt order. We subtract a name and a salt from K. Let K m,n = K m-1,n-1 . We treat this as a move in a game. If the move K m,n α → K m-1,n-1 is not permitted, where α is the trace that is the set of channels between the two marked channels, say K P and K Q , then the routing is invalid. If the routing is valid then, the operation can be repeated until K 1,0 is reached, which should be the expected origin of the message. Thus, the route taken by each message can be identified. Since each message follows a uniquely identifiable route, an inconsistent message marks a potentially subverted route.

Using set elimination over routes between an orgin and destination, σ i,j α iα j , the subverted channels can be identified in a probabilistic manner. Hence, if a message is sent independent of an unreliable channel, it may be regarded as reliable; otherwise, it is not reliable. Observing the independence of channels permits the detection of the adversary's action and operation of the plant, even where manipulated signals share routes with reliable signals.

To complete the approach, the set of estimators should also be independent sources of information about the process. A cyclic dependency between estimators must be avoided. For example, if the estimator A1 is used to estimate B2, and B2 to estimate C4, and C4 to estimate A1, then the results become meaningless. Undermining this approach requires the adversary to capture all the salts that are regard as infeasible. In essence, we assume the adversary can only gain partial control of the system.

Conclusions

Research in the area of control systems security has shown that attackers can forge protocols or directly manipulate physical signals to mask their activities. In earlier work [START_REF] Mcevoy | Detecting sensor signal manipulations in non-linear chemical processes[END_REF], we have demonstrated previously that proxy measurements can detect such inconsistencies. However, to minimize the reengineering efforts, it is desirable to use measurements that are already present. Combining path authentication with state estimation techniques is an effective means for identifying subverted channels and processes, and, as such, promises to be a rich area of research in the area of control systems security. Our future research will focus on refining the path authentication technique and selecting robust estimators for state estimation by proxy.

Figure 1 .

 1 Figure 1. Tennessee Eastman problem under base control [11].

Table 1 .

 1 Manipulated and controlled variables.

	Manipulated Variable	Controlled Variable
	A-feed set point	Reactor level
	D-feed set point	Separator level
	E-feed set point	Stripper bottom level
	C-feed set point	Reactor pressure
	Purge set point	Reactor feed flow
	Product set point	Reactor temperature
	Stripper stream flow set point	Compressor power
	Separator bottom flow set point	Compressor exit flow
	Reactor cooling water set point	Separator pressure
	Condenser cooling water set point	Separator temperature
	Compressor recycle valve	Stripper pressure
	Stirrer speed	Stripper temperature