Rebecca Shapiro

Sergey Bratus

Edmond Rogers

Sean Smith

IDENTIFYING VULNERABILITIES IN SCADA SYSTEMS VIA FUZZ-TESTING

Keywords: Vulnerability assessment, SCADA systems, fuzz-testing

Security vulnerabilities typically arise from bugs in input validation and in the application logic. Fuzz-testing is a popular security evaluation technique in which hostile inputs are crafted and passed to the target software in order to reveal bugs. However, in the case of SCADA systems, the use of proprietary protocols makes it difficult to apply existing fuzz-testing techniques as they work best when the protocol semantics are known, targets can be instrumented and large network traces are available. This paper describes a fuzz-testing solution involving LZ-Fuzz, an inline tool that provides a domain expert with the ability to effectively fuzz SCADA devices.

Introduction

Critical infrastructure assets such as the power grid are monitored and controlled by supervisory control and data acquisition (SCADA) systems. The proper functioning of these systems is necessary to ensure the safe and reliable operation of the critical infrastructure -something as simple as an input validation bug in SCADA software can leave an infrastructure asset vulnerable to attack. While large software development companies may have the resources to thoroughly test their software, our experience has shown that the same cannot be said for SCADA equipment manufacturers. Proell from Siemens [START_REF] Proell | Fuzzing proprietary protocols: A practical approach[END_REF] notes that random streams of bytes are often enough to crash SCADA devices.

Securing SCADA devices requires extensive testing for vulnerabilities. However, software vulnerabilities are often not well understood by SCADA developers and infrastructure experts, who may themselves not have the complete protocol documentation. Meanwhile, external security experts lack the SCADA knowledge, resources and access to run thorough tests. This is a Catch-22 situation.

Fuzz-testing is a form of security testing in which bad inputs are chosen in attempt to crash the software. As such, it is widely used to test for security bugs in input validation as well as in application logic. However, applying fuzztesting methodologies to secure SCADA devices is difficult. SCADA systems often rely on poorly understood proprietary protocols, which complicates test development. The time-sensitive, session-oriented nature of many SCADA environments makes it impossible to prime a fuzzer with a large capture. (Session data is only valid for a short time and is often rejected out of hand by the target thereafter.) Furthermore, many modern fuzzers require users to attach a debugger to the target, which is not always possible in a SCADA environment. What is needed is a fuzzer than works inline.

This paper describes LZFuzz, an inline fuzzing tool that enables infrastructure asset owners and operators to effectively fuzz their own equipment without needing to modify the target system being tested, and without having to expose their assets or pass proprietary information to external security evaluators.

Fuzzing Overview

Barton Miller, the father of fuzz-testing, observed during a thunderstorm that the lightning-induced noise on his network connection caused programs to crash [START_REF] Miller | An empirical study of the reliability of UNIX utilities[END_REF]. The addition of randomness to inputs triggered bugs that were not identified during software testing. Upon further investigation, Miller discovered that the types of bugs triggered by fuzzing included race conditions, buffer overflows, failures to check return code and printf/format string problems. These bugs are often sources of software security vulnerabilities [START_REF] Meer | Memory corruption attacks: The (almost) complete history[END_REF]. Most modern software undergoes aggressive input checking and should handle random streams of bytes without crashing. Consequently, modern fuzz-testing tools have become more selective in how they fuzz inputs.

Whether or not data has been fuzzed, there usually are multiple layers of processing that the data has to undergo before it reaches the target software's application logic. Application logic is the soft underbelly of software -penetrating it greatly increases the likelihood of compromising the software. Fuzzed inputs trigger bugs only if they are not rejected by one of the processing layers before they get to the application logic. Therefore, a fuzzer must generate inputs that are clean enough to pass all the processing layer checks, but that are sufficiently malformed to trigger bugs in the application logic.

The most successful fuzzers create fuzzed inputs based on complete knowledge of the layout and contents of the inputs. If a fuzzer is given information on how a specific byte will be interpreted, it can manipulate the byte in ways that are more likely to compromise the target. For example, if a particular sequence of bytes has information about the length of a string that is contained in the next sequence of bytes, a fuzzer can try to increase, decrease or set the length value to a negative number. The target software may not check one of these cases and pass the malformed input to the application logic, resulting in a potentially exploitable memory corruption [START_REF] Meer | Memory corruption attacks: The (almost) complete history[END_REF].

Fuzzing Techniques

There are two methods for creating fuzzed inputs: generation-based fuzzing and mutation fuzzing. To simplify the presentation, we focus on fuzzing packets sent to networked software. The techniques, however, apply generally to fuzztesting (e.g., of files and file systems).

Generation-Based Fuzzing: This method constructs fuzzed inputs based on generation rules related to valid input structures and protocol states. The simplest generation-based fuzzers generate fuzzed inputs corresponding to random-length strings containing random bytes [START_REF] Miller | An empirical study of the reliability of UNIX utilities[END_REF]. State-of-the-art generation-based fuzzers such as Sulley [START_REF] Amini | Sulley: Pure Python fully automated and unattended fuzzing framework[END_REF] and Peach [START_REF] Eddington | Peach Fuzzing Platform (peachfuzzer.com)[END_REF] are typically block-based fuzzers. Block-based fuzzers require a complete description of the input structure in order to generate inputs, and often accept a protocol description as well. SPIKE [START_REF] Aitel | An introduction to SPIKE, The fuzzer creation kit[END_REF] was the first block-based fuzzer to be distributed. Newer generation-based fuzzers such as EXE [START_REF] Cadar | EXE: Automatically generating inputs of death[END_REF] instrument code to automatically generate test cases that have a high probability of success.

Mutation Fuzzing: This method modifies good inputs by inserting bad bytes and/or swapping bytes to create fuzzed inputs. Some modern mutation fuzzers base their fuzzing decisions on a description of the input layout (e.g., the mutation aspect of Peach [START_REF] Eddington | Peach Fuzzing Platform (peachfuzzer.com)[END_REF]). Other mutation fuzzers such as the General Purpose Fuzzer (GPF) [START_REF]General Purpose Fuzzer[END_REF] do not require any knowledge of the input layout or protocol; they use simple heuristics to guess field boundaries and accordingly mutate the input. Kaminsky's experimental CFG9000 fuzzer [START_REF] Kaminsky | Black ops: Pattern recognition[END_REF] occupies the middle ground by using an adaptation of the Sequitur algorithm [START_REF] Nevill-Manning | Identifying hierarchical structure in sequences: A linear-time algorithm[END_REF] to derive an approximation (context-free grammar) of the generative model of a protocol from a sufficiently large traffic capture, and then uses the model to generate mutated inputs. Most mutation fuzzers use previously-recorded network traffic as the basis for mutation, although there are some inline fuzzers that read live traffic. One of the most influential academic works on fuzzing is PROTOS [START_REF] Roning | PROTOS: Systematic approach to eliminate software vulnerabilities[END_REF], which analyzes a protocol, creates a model and generates fuzzing tests based on the model. A fuzzing test is typically deemed to be successful when it reveals a bug that harbors a vulnerability. However, in the case of critical infrastructure assets, a broader definition of success is appropriate -discovering a bug that creates any sort of disruption. This is important because any disruption -whether or not it is a security vulnerability -can severely impact the critical infrastructure.

Inline Fuzzing

In general, most block-based and mutation packet fuzzers work on servers, not clients. This is because these fuzzers are designed to generate packets and send them to a particular IP address and port. Since clients do not accept traffic that they are not expecting, only fuzzers that operate on live traffic are capable of fuzzing clients. Similarly, protocols that operate in short or timesensitive sessions are relatively immune to fuzzing that requires a large sample packet dump. For these reasons, inline fuzzing is typically required to fuzz clients.

Fuzzers that are capable of inline fuzzing (e.g., QueMod [START_REF]QueMod[END_REF]) either transmit random data or make random mutations. To our knowledge, LZFuzz, which is described in this paper, is the first inline fuzzer that goes beyond random strings and mutations.

Network-Based Fuzzing

Most modern fuzzers integrate with debuggers to instrument and monitor their targets for crashes. However, using a debugger requires intimate access to the target. Such access is unlikely to be available in the case of most SCADA systems used in the critical infrastructure.

Inline fuzzers like LZFuzz must recognize when the target crashes or becomes unresponsive without direct instrumentation. With some targets, this recognition must trigger a way to (externally) reset the target; other targets may be restarted by hardware or software watchdogs. Note that generation-based fuzzers, which for various reasons cannot leverage target instrumentation, encounter similar challenges. For example, 802.11 Link Layer fuzzers that target kernel drivers [START_REF] Cache | Exploiting 802.11 wireless driver vulnerabilities on Windows[END_REF] have had to work around their successes that caused kernel panics on targets.

In either case, stopping and then restarting the fuzzing iteration over the input space is necessary so that fuzzing payloads are not wasted on an unresponsive target. It is also important for a fuzzer to adapt to its target, especially when dealing with proprietary protocols.

Fuzzing Proprietary Protocols

It is generally believed that if a fuzzer can understand and adapt to its target, it will be more successful than a fuzzer that does not. Therefore, it is important for a fuzzer to leverage all the available knowledge about the target. When no protocol specifications are available, an attempt can be made to reverse engineer the protocol manually or with the help of debuggers. In practice, this can be extremely time-consuming. Furthermore, it is not always possible to install debuggers on some equipment, which makes reverse engineering even more difficult.

Consequently, it is important to build a fuzzing tool that can work efficiently on proprietary devices and software without any knowledge of the protocol it is fuzzing. Although a mutation fuzzer does not require knowledge of the protocol, it is useful to build a more efficient mutation fuzzer by incorporating field parsing (and other) heuristics that would enable it to respond to protocol state changes on the fly without protocol knowledge. Because instrumenting a target is difficult or impossible in a SCADA environment, the only option is to employ inline adaptive fuzzing. We refer to this approach as live adaptive mutation fuzzing.

Fuzzing in Industrial Settings

Proprietary protocols used by SCADA equipment, such as Harris-5000 and Conitel-2020, are often not well-understood. Understandably, domain experts neither have the time nor the skills to reverse engineer the protocols. Fuzzing experts can perform this task, but infrastructure asset owners and operators may be reluctant to grant access to outsiders. In our own experience with power industry partners, it was extremely difficult to gain approval to work with their equipment. Moreover, asset owners and operators are understandably disinclined to share information about proprietary protocols and equipment, making it difficult for outside security experts to perform tests. Clearly, critical infrastructure asset owners and operators would benefit from an effective fuzzing tool that they could use on their own equipment. Our work with LZFuzz seeks to make this possible.

Modern Fuzzers

This section briefly describes examples of advanced fuzzers that are popular in the fuzz-testing community. Also, it highlights some tools that are available for fuzzing SCADA protocols.

General Network-Based Fuzzing Tools: Sulley [3] is a block-based generation fuzzing tool for network protocols. It provides mechanisms for tracking the fuzzing process and performing post mortem analysis. It does so by running code that monitors network traffic and the status of the target (via a debugger). Sulley requires a description of the block layout of a packet in order to generate fuzzed inputs. It also requires a protocol description, which it uses to iterate through different protocol states during the fuzzing process.

The General Purpose Fuzzer (GPF) [START_REF]General Purpose Fuzzer[END_REF] is a popular network protocol mutation fuzzer that requires little to no knowledge of a protocol. Although GPF is no longer being maintained, it is one of the few open source modern mutation fuzzers that is commonly available. GPF reads network captures and heuristically parses packets into tokens. Its heuristics can be extended to improve the accuracy with which it handles a protocol, but, by default, GPF attempts to tokenize packets using common string delimiters such as " " and "\n." GPF also provides an interface to load user defined functions that perform operations on packets post-fuzzing.

Peach is a general fuzzing platform that performs mutation and blockbased generation fuzzing [START_REF] Eddington | Peach Fuzzing Platform (peachfuzzer.com)[END_REF]. Like Sulley, it requires a description of the fields and protocol. When performing mutation fuzzing, Peach reads in network captures and uses the field descriptions to parse and analyze packets for fuzzing as well as to adjust packet checksums before trans-mitting the fuzzed packets. Like Sulley, Peach also uses debuggers and monitors to determine success and facilitate post mortem analysis.

SCADA Fuzzing Tools: Some tools are available for fuzzing nonproprietary SCADA protocols. In 2007, ICCP, Modbus and DNP3 fuzzing modules were released for Sulley by Devarajan [START_REF] Devarajan | Unraveling SCADA protocols: Using Sulley fuzzer[END_REF]. SecuriTeam includes DNP3 support with its beSTORM fuzzer [START_REF]Beyond Security, Black box software testing[END_REF]. Digital Bond created IC-CPSic [START_REF]Digital Bond, ICCPSic assessment tool set released[END_REF], a commercial suite of ICCP testing tools (unfortunately, this suite is no longer publicly available). Also Mu Dynamics offers Mu Test Suite [START_REF] Dynamics | Mu Test Suite[END_REF], which supports modules for fuzzing SCADA protocols such as IEC61850, Modbus and DNP3.

LZFuzz Tool

LZFuzz employs a simple tokenizing technique adapted from the Lempel-Ziv compression algorithm [START_REF] Ziv | A universal algorithm for sequential data compression[END_REF] to estimate the recurring structural units of packets; interested readers are referred to [START_REF] Bratus | LZFuzz: A Fast Compression-Based Fuzzer for Poorly Documented Protocols[END_REF] for an analysis of the accuracy of the tokenizing method. Effective inputs for fuzzing can be generated by combining this simple tokenizing technique with a mutation fuzzer. The need to understand and model protocol behavior can be avoided by adapting to and mutating live traffic.

In our experience, SCADA protocols used in power control systems perform elaborate initial handshakes and send continuous keep-alive messages. If a target process is crashed, the process will often automatically restart itself and initiate a new handshake.

This behavior is unusual for other non-SCADA classes of targets that need to be specifically instrumented to ensure liveliness and be restarted remotely. Such restarting/session renegotiation behavior assists the construction of successful fuzz sessions. Based on this observation, we propose the novel approach of "adaptive live mutation fuzzing." The resulting fuzzer can adapt its fuzzing method based on the traffic it receives, automatically backing off when it thinks it is successful.

Design

The LZFuzz tool is inserted into a live stream of traffic, capturing packets sent to and from a source and target. A packet read into LZFuzz gets processed in several steps before it is sent to the target (Figure 1). When LZFuzz receives traffic destined for the target, it first tags the traffic with its type. Then, it applies a set of rules to see if it can declare success. Next, it looks up the LZ string table for the traffic type it is processing, updates the table and parses the packet accordingly. Next, it sends one or more tokens to a mutation fuzzer. Finally, it reassembles the packet, fixing any fields as needed in the packet finishing module. As LZFuzz receives traffic destined for the source, it checks for success and fixes any fields as required before sending the packet to the source. Intercepting Packets.

Although it may be possible to configure the source and target to communicate directly with the machine running LZFuzz, it may not always be practical to do so. Consequently, LZFuzz uses a technique known as ARP spoofing or ARP poisoning to transparently insert itself between two communicating parties. This method works when the systems are communicating over Ethernet and IP and at least one of them is on the same LAN switch as the machine running LZFuzz. (In the case of only one target host being local and the remote host located beyond the local LAN, the LAN's gateway must be "poisoned.") The ability to perform ARP spoofing means that fuzzing can be performed without the need to make any direct changes to the source or target configurations. LZFuzz uses the arp-sk tool [START_REF] Raynal | arp-sk: A Swiss knife tool for ARP[END_REF] to perform ARP spoofing.

Note that, although various Link Layer security measures exist against ARP poisoning and similar LAN-based attacks can be deployed either at the LAN switches or on the respective hosts or gateways (see, e.g., [START_REF] Convery | Hacking Layer 2: Fun with Ethernet switches[END_REF]), such measures are not typically used in control networks, because of the configuration overhead. This overhead can be especially costly in emergency scenarios where faulty or compromised equipment must be quickly replaced, because it is desirable in such situations that the replacement work "out of the box."

Estimating Packet Structure.

As LZFuzz reads in valid packets, it builds a string table as if it were performing LZ compression [START_REF] Ziv | A universal algorithm for sequential data compression[END_REF]. The LZ table keeps track of the longest unique subsequences of bytes found in the stream of packets. LZFuzz updates its LZ tables for each packet it reads. A packet is then tokenized based on strings found in the LZ table, and each token is treated as if it were a field in the packet. One or more tokens are then passed to GPF, which guesses the token types and mutates the tokens. The number of tokens passed to GPF is dependent on whether or not the windowing mode is enabled. When the mode is enabled, LZFuzz fuzzes one token at a time, periodically changing the token it fuzzes (LZFuzz may fuzz multiple tokens at a time in the windowing mode to ensure that there are enough bytes available to mutate effectively). When the windowing mode is disabled, all the tokens are passed to GPF. Figure 2 provides a high-level view of the tokenizing process.

Responding to Protocol State Changes.

Unlike traditional mutation fuzzers, LZFuzz's mutation fuzzer performs live mutation fuzzing. This means that, instead of mutating previously recorded packets, packets are mutated while they are in transit from the source to the target. Figure 3 shows how live mutation differs from traditional mutation. In particular, live inline mutation enables the fuzzing of short or time-sensitive sessions on real systems in both directions. Traditional mutation fuzzers mutate uncorrupted input from a network dump whereas LZFuzz mutates packets freshly from a source as it communicates with the target.

Recognizing Target Crashes.

Modern network protocol fuzzers tend to require the attachment of a debugger to the target to determine when crashes occur. However, such access is typically not available in SCADA environments. Since live communications are captured as they enter and leave the fuzzing target, our novel approach can make fuzzing decisions based on the types of messages (or lack thereof) sent by the target or source.

SCADA protocols tend to have continuous liveliness checks. If a piece of equipment revives itself after being perceived as dead, an elaborate handshake is typically performed as it reintroduces itself. LZFuzz possesses the ability to recognize such behavior throughout a fuzzing session.

Even if a protocol does not have these keep-alive/handshake properties, other methods can be used to deduce success from network traffic. If a protocol is running over TCP, the occurrence of an RST flag may signify that the target process has crashed. This flag is set when a host receives traffic when it has no socket listening for the traffic. Our experience with LZFuzz has shown that TCP RST flags are a reasonable success metric although they produce some false positives.

Mutation.

LZFuzz can work with a variety of fuzzers to mangle the input it fetches. Also, LZFuzz can be easily modified to wrap itself around new mutation fuzzers. Currently, LZFuzz passes packet tokens to the GPF mutation fuzzer for fuzzing before it reassembles the packet and fixes any fields such as checksums.

Extending LZFuzz

LZFuzz provides an API to allow users to encode knowledge of the protocol being fuzzed. The API can be used to tag different types of packets using regular expressions. New LZ string tables are automatically generated for each type of packet that it is passed. The API also allows users to provide information on how to fix packets before they are sent so that the length and checksum fields can be set appropriately. Finally, the API allows users to custom-define success conditions. For example, if a user knows that the source will attempt a handshake with the target when the target dies, then the user can use the API to tag the handshake packets separately from the data and control packets and to instruct LZFuzz to presume success upon receiving the handshake packets.

Experimental Results

An earlier version of LZFuzz was tested on several non-SCADA network protocols, including the iTunes music sharing protocol (DAAP). LZFuzz was able to consistently hang the iTunes version 2.6 client by fuzzing DAAP. It was also able to crash an older version of the Gaim client by intercepting and fuzzing AOL Instant Messenger traffic.

We selected these protocols because we wanted to test the fuzzer on examples of relatively complex (and popular) client-server protocols that are used for frequent, recurring transactions with an authentication phase separate from the normal data communication phase. Also, we sought protocols that supported some notion of timed and timed-out sessions. Of course, it was desirable that the target software be widely used so that most of the easy-to-find bugs would have presumably been fixed. More importantly, however, LZFuzz was able to consistently crash SCADA equipment used by an electric power company.

Beyond listing successes, it is not obvious how the effectiveness of a fuzzer can be quantitatively evaluated or compared. In practice, a fuzzer is useful if it can crash targets in a reasonable amount of time. But how does one encode such a goal in a metric that can be evaluated?

The best method would be to test the ability of a fuzzer to trigger all the bugs in a target. However, such a metric is flawed because it requires a priori knowledge of all the bugs that exist in the target. A more reasonable metric is code coverage -the portion of code in a target that is executed in response to fuzzed inputs. This metric also has its flaws, but it is something that can be measured (given access to the source code of the target), and still provides insight on ability of the fuzzer to reach hidden vulnerabilities. Indeed, in 2007, Miller and Peterson [START_REF] Miller | Analysis of Mutation and Generation-Based Fuzzing, White Paper, Independent Security Evaluators[END_REF] used code coverage to compare generational fuzzing against mutation fuzzing. Also, the usefulness of coverage instrumentation has long been recognized by the reverse engineering and exploit development communities. For example, Amini's PaiMei fuzzing and reverse engineering framework [START_REF] Amini | PaiMei and the five finger exploding palm RE techniques, presented at REcon[END_REF] provides the means to evaluate the code coverage of a process up to the basic block granularity; the framework also includes tools for visualizing coverage. Unfortunately, the code coverage metric glosses over differences between a fuzzer constrained to having canned packet traces and one that can operate in a live inline mode. Nevertheless, to provide a means for comparing LZFuzz with other methods of fuzzing proprietary protocols, we set up experiments to compare the code coverage of LZFuzz, GPF and random mutation fuzzing (with random strings of random lengths).

Experimental Setup

We tested GPF, LZFuzz, random mutation fuzzing and no fuzzing on two targets: mt-daapd and the Net-SNMP snmpd server. We chose these two targets because mt-daapd is an open source server that uses a (reverse engineered) proprietary protocol and Net-SNMP uses the open SNMP protocol used in SCADA systems.

The experiments were conducted on a machine with a 3.2 GHz i5 dual-core processor and 8 GB RAM running Linux kernel 2.6.35-23. Each fuzzing session was run separately and sequentially. The code coverage of the target was measured using gcov. The targets were executed within a monitoring environ-

!"#$%% &'($%%)* +,# -.'*/0 mt-daapd, Code Coverage (%) Run Length (min) ! " # $ !% &" %# !"$ "% !% !$ "' "" "# Run Length (min) ! " # $ !% &" %# !"$
Open-SNMP, Code Coverage (%) ment that would immediately restart the target when a crash was detected (to simulate the automatic reset of common power SCADA applications). Eight separate tests were conducted on each target; specifically, the fuzzer was run for 1, 2, 4, 8, 16, 32, 64 and 128 minutes. After each test run, the code coverage was computed before resetting the code coverage count for the subsequent run. No fuzzer was provided any protocol information beyond the IP address of the target, the transport layer protocol and the port used by the target. Because GPF uses a network capture as a mutation source, it was supplied with a packet capture of about 1,600 packets as produced by the source/target setup when no fuzzer was active.

4.2

Fuzzing mt-daapd mt-daapd is an open source music server that uses the proprietary iTunes DAA protocol to stream music. This protocol was reverse engineered by several developers who intended to build open source daapd servers and clients. We chose mt-daapd because we wanted to test a proprietary protocol but required source code in order to calculate code coverage. The tests used mt-daapd version 0.2.4.2. The mt-daapd daemon was run on the same machine as the client and fuzzer. The server was configured to prevent stray users from connecting to it. The Banshee media player was used as a client and traffic source. To maintain consistency between tests, a set of xmacro scripts were used to control Banshee and cause it to send requests to the daapd server.

In general, we discovered that, with respect to code coverage, LZFuzz does as well or better than running the test environment without any fuzzer (left-hand side of Figure 4). Furthermore, we found that LZFuzz triggered the largest amount of code in the target compared with the other fuzzers we tested. This means that LZFuzz was able to reach into branches of code that none of the other fuzzers reached. Interestingly, the random fuzzer consistently produced the same low code coverage on every test run regardless of the length of the run. Other than LZFuzz, no fuzzer achieved higher code coverage than that of a non-fuzzed run of Banshee and mt-daapd.

Fuzzing snmpd

Net-SNMP is one of the few open source projects that use SCADA protocols. Our experiments used snmpd, the daemon that responds to SNMP requests in Net-SNMP version 5.6.1, as a fuzzing target. Like mt-daapd, the daemon was run on the same system as the client. We scripted snmpwalk, provided by Net-SNMP, to continuously send queries to the server. For the purpose of code coverage testing, snmpwalk was used to query the status of several parameters, including the system uptime and location, and information about open TCP connections on the system. Because we were unable to make consistent code coverage measurements between runs of the same fuzzer and run length, we ran each fuzzer and run length combination five times. The averages are displayed in Figure 4 (right-hand side) along with error bars for runs with noticeable variation (standard deviation greater than 0.025%).

GPF outperformed LZFuzz when GPF was running at full strength. However, we were also interested in seeing the relative performance of LZFuzz and GPF when GPF had a rate-adjusted flow so that GPF would send about the same number of packets as LZFuzz for a given run length. This adjustment provided insight into how much influence a GPF-mutated packet would have on the target compared with a LZFuzz-mutated packet. We also observed that LZFuzz induced a larger amount of code coverage in snmpd when the mutation rate that controlled the mutation engine aggressiveness was set to medium (instead of high or low). The mutation rate governs how much the GPF mutation engine mutates a packet. Although this feature is not documented, the mutation rate is required to be explicitly set during a fuzzing session. Line 143 of the GPF source file misc.c offers the options "high," "med" or "low" without any documentation; we chose the "med" option for snmpd and "high' for mt-daapd. Because GPF uses the same mutation engine, we set GPF to run with the medium mutation level as well. Note that, in the case of snmpd, a 1% difference in code coverage corresponds to about 65 lines of code.

Figure 4 (right-hand side) shows the code coverage of GPF (with a rateadjusted flow and a medium mutation rate) compared with the code coverage of LZFuzz (with medium mutation), random fuzzing and no fuzzing. With rate-adjusted flow, LZFuzz induces a higher code coverage than GPF. LZFuzz also clearly outperforms random fuzzing.

Although LZFuzz and GPF share a common heuristic mutation engine, they belong to different classes of fuzzers and each has its own strengths and weaknesses. LZFuzz can fuzz both servers and clients; GPF can only fuzz targets that are listening for incoming traffic on a port known to GPF before the fuzzing session. LZFuzz is restricted to only fuzzing packets sent by the source; GPF can send many packets in rapid succession; GPF requires the user to prepare a representative packet capture and, thus, implicitly assumes that representative captures exist for the target scenario. Note that the time taken to prepare the network capture was not considered in our results. The packet capture given to GPF potentially provided it with a wealth of information about the protocol from the very beginning. On the other hand, LZFuzz had to develop most of its knowledge about the protocol on the fly. Also, the mutation engine of GPF was built and tuned specifically for what GPF does -fuzzing streams of packets. LZFuzz uses the same mutation engine, but only had one packet in each stream. While the GPF mutation engine was not designed to be used in this manner, we believe that the effectiveness of LZFuzz can be improved if the mutation engine could be tuned.

When GPF and LZFuzz were used at full strength against mt-daap, LZFuzz outperformed GPF in terms of code coverage. However, this was not the case when both fuzzers were tested against snmpd -GPF achieved 1-2% more code coverage than LZFuzz in comparable runs. It could be argued that GPF is the more effective fuzzer for snmpd. However, the clear advantage of LZFuzz over GPF and other similar fuzzers is that it can also fuzz SNMP clients (e.g., snmpwalk) whereas GPF cannot do this without session-tracking modifications.

LZFuzz Tokenizing

The final issue to examine is whether or not the LZFuzz tokenizing method improves the overall effectiveness of the tool. If tokenizing is disabled in LZFuzz during a run and the entire payload is passed directly to GPF, then GPF attempts to apply its own heuristics to parse the packet. Figure 5 shows how LZFuzz with tokenizing compares with LZFuzz without tokenizing when run against snmpd in the same experimental environment as described above. These results suggest that the LZ tokenizing does indeed improve the effectiveness of inline fuzzing with the GPF mutation engine.

Conclusions

The LZFuzz tool enables control systems personnel with limited fuzzing expertise to effectively fuzz proprietary protocol implementations, including the SCADA protocols used in the electric power grid. LZFuzz's adaptive live mutation fuzzing approach can fuzz the proprietary DAA protocol more efficiently than other methods. LZFuzz is also more effective than applying a random fuzzer to an SNMP server. The GPF mutation fuzzer appears to be more effective at fuzzing an SNMP server than LZFuzz; however, unlike LZFuzz, GPF is unable to fuzz SNMP clients.

Additional work remains to be done on LZFuzz to ensure its wider application in the critical infrastructure. The user interface must be refined to change the aggressiveness of fuzzing or temporarily disable fuzzing without having to restart LZFuzz. Another refinement is to identify checksums by intercepting traffic to the target and passively search for bytes that appear to have high entropy. Also, the tool could be augmented to test for authentication and connection setup traffic by inspecting traffic at the beginning of a run and traffic from the target after blocking replies from the client, and vice versa. This information can be used to specify traffic rules that would make LZFuzz more effective.

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.

Figure 1 .

 1 Figure 1. LZFuzz packet processing.

Figure 2 .

 2 Figure2. Tokenizing and mutating packets (adapted from[START_REF] Bratus | LZFuzz: A Fast Compression-Based Fuzzer for Poorly Documented Protocols[END_REF]).

Figure 3 .

 3 Figure 3. Comparison of live inline mutation with traditional mutation.

Figure 4 .

 4 Figure 4. Code coverage for mt-daapd (left) and Open-SNMP (right).

Figure 5 .

 5 Figure 5. Code coverage for the Net-SNMP server with and without tokenizing.

Acknowledgements

This research was supported by the Department of Energy under Award No. DE-OE0000097. The authors wish to thank Axel Hansen and Anna Shubina for their assistance in developing the initial prototype of LZFuzz. The authors also wish to thank the power industry personnel who supported the testing of LZFuzz in an isolated environment at their facility.


Daniel Guernsey

Mason Rice

Sujeet Shenoi

IMPLEMENTING NOVEL DEFENSE FUNCTIONALITY IN MPLS NETWORKS USING HYPERSPEED SIGNALING

Keywords: Hyperspeed signaling, network defense, MPLS networks

Imagine if a network administrator had powers like the superhero Flash -perceived invisibility, omnipresence and superior surveillance and reconnaissance abilities -that would enable the administrator to send early warnings of threats and trigger mitigation efforts before malicious traffic reaches its target.

This paper describes the hyperspeed signaling paradigm, which can endow a network administrator with Flash-like superpowers. Hyperspeed signaling uses optimal (hyperspeed) paths to transmit high priority traffic while other traffic is sent along suboptimal (slower) paths. Slowing the traffic ever so slightly enables the faster command and control messages to implement sophisticated network defense mechanisms. The defense techniques enabled by hyperspeed signaling include distributed filtering, teleporting packets, quarantining network devices, tagging and tracking suspicious packets, projecting holographic network topologies and transfiguring networks. The paper also discusses the principal challenges involved in implementing hyperspeed signaling in MPLS networks.

Introduction

The midnight ride of Paul Revere on April 18, 1775 alerted the Revolutionary Forces about the movements of the British military before the Battles of Lexington and Concord. The ability to deploy Paul-Revere-like sentinel messages within a computer network could help improve defensive postures. These sentinel messages could outrun malicious traffic, provide early warnings of threats and trigger mitigation efforts. Electrons cannot be made to move faster than the laws of physics permit, but "suspicious" traffic can be slowed down ever so slightly to enable sentinel messages to accomplish their task. To use an optical analogy, it is not possible to travel faster than light, but "hyperspeed signaling paths" can be created by slowing light along all other paths by increasing the refractive index of the transmission media.

The concept of offering different priorities -or speeds -for communications is not new. The U.S. Postal Service has numerous classes of mail services ranging from ground delivery to Express Mail that guarantees overnight delivery. The U.S. military's Defense Switched Network (DSN) [START_REF] Nicolls | Airman's Guide[END_REF] designed during the Cold War had four levels of urgency for telephone calls, where a call at a higher level could preempt a call at a lower level; the highest level was FLASH, which also incorporated a special FLASH OVERRIDE feature for the President, Secretary of Defense and other key leaders during defensive emergencies. Modern MPLS networks used by major service providers offer a variety of high-speed and low-speed paths for customer traffic based on service level agreements.

This paper proposes the use of optimal (hyperspeed) paths for command and control (and other high priority) traffic and suboptimal (slower) paths for all other traffic in order to implement sophisticated network defense techniques. The basic idea is to offer a guaranteed reaction time window so that packets sent along hyperspeed paths can arrive sufficiently in advance of malicious traffic in order to alert network devices and initiate defensive actions. Separate channels have been used for command and control signals. Signaling System 7 (SS7) telephone networks provide a back-end private network for call control and traffic management, which physically separates the control and data planes [START_REF] Russell | Signaling System #7[END_REF]. MPLS networks logically separate the internal IP control network from external IP networks that connect with the data plane [START_REF] Davie | MPLS: Technology and Applications[END_REF].

This paper describes the hyperspeed signaling paradigm, including its core capabilities and implementation requirements for MPLS networks. Novel defense techniques enabled by hyperspeed signaling, ranging from distributed filtering and teleportation to quarantining and network holography, are highlighted. The paper also discusses the principal challenges involved in implementing hyperspeed signaling, which include network deployment, traffic burden and net neutrality.

Hyperspeed Signaling

Hyperspeed signaling uses optimal (hyperspeed) paths to transmit high priority traffic; other traffic is sent along suboptimal (slower) paths. The difference in the time taken by a packet to traverse a hyperspeed path compared with a slower path creates a reaction time window that can be leveraged for network defense and other applications. Indeed, a hyperspeed signaling path between two network nodes essentially induces a "quantum entanglement" of the two nodes, allowing them to interact with each other seemingly instantaneously.

In general, there would be one or more hyperspeed (optimal) paths and multiple slower (suboptimal) paths between two nodes. Thus, different reaction time windows would be available for a hyperspeed path compared with (different) slower paths. These different windows would provide varying amounts of time to implement defensive actions. Depending on its nature and priority, traffic could be sent along different suboptimal paths. For example, traffic deemed to be "suspicious" could be sent along the slowest paths.

Note that hyperspeed paths need not be reserved only for command and control traffic. Certain time-critical traffic, such as interactive voice and video communications, could also be sent along faster, and possibly, hyperspeed paths. Of course, using faster paths for all traffic would reduce the reaction time windows, and, consequently, decrease the time available to implement defensive actions. Clearly, a service provider or network administrator would prefer not to reduce traffic speed drastically. Consequently, a suboptimal path should incorporate the smallest delay necessary to obtain the desired reaction time window.

Core Capabilities

Hyperspeed signaling provides the network administrator with "powers" like the superhero Flash. The reaction time window corresponds to the speed advantage that Flash has over a slower villain. The ability to send signals between two network nodes faster than other traffic provides superpowers such as perceived invisibility, omnipresence and superior intelligence, surveillance and reconnaissance abilities.

This section describes the core capabilities offered by hyperspeed signaling. These capabilities are described in terms of the "See-Think-Do" metaphor [15].

Omnipresence

Omnipresence in the hyperspeed signaling paradigm does not imply that the network administrator is everywhere in the network at every moment in time. Instead, omnipresence is defined with respect to a target packet -the network administrator can send a hyperspeed signal to any node in the network before the target packet arrives at the node.

Omnipresence with respect to multiple packets has two versions, one stronger and the other weaker. The stronger version corresponds to a situation where there is one Flash, and this Flash can arrive before all the packets under consideration arrive at their destinations. The weaker version corresponds to a situation where there are multiple Flashes, one for each packet under consideration. Note that the stronger version of omnipresence endows the network administrator with the ability to track multiple packets and to correlate information about all the packets regardless of their locations in the network.

Intelligence, Surveillance, Reconnaissance

Intelligence, surveillance and reconnaissance (ISR) are essential elements of U.S. defensive operations [START_REF] Best | Intelligence, Surveillance and Reconnaissance (ISR) Programs: Issues for Congress, CRS Report for Congress, RL32508[END_REF]. ISR capabilities are implemented in a wide variety of systems for acquiring and processing information needed by national security decision makers and military commanders.

Intelligence is strategic in nature; it involves the integration of time-sensitive information from all sources into concise, accurate and objective reports related to the threat situation. Reconnaissance, which is tactical in nature, refers to an effort or a mission to acquire information about a target, possibly a onetime endeavor. Surveillance lies between intelligence and reconnaissance. It refers to the systematic observation of a targeted area or group, usually over an extended time.

Obviously, hyperspeed signaling would significantly advance ISR capabilities in cyberspace. The scope and speed of ISR activities would depend on the degree of connectedness of network nodes via hyperspeed paths and the reaction time windows offered by the paths.

Defensive Actions

Hyperspeed signaling can help implement several sophisticated network defense techniques. The techniques resemble the "tricks" used in stage magic. In particular, the advance warning feature provided by hyperspeed signaling enables a network to seemingly employ "precognition" and react to an attack before it reaches the target. As described in Section 6, hyperspeed signaling enables distributed filtering, teleporting packets, quarantining network devices, tagging and tracking suspicious packets, projecting holographic network topologies, and transfiguring networks.

Distributed filtering permits detection mechanisms to be "outsourced" to various locations and/or organizations. Teleportation enables packets to be transported by "secret passageways" across a network without being detected. Quarantining enables a network device, segment or path to "vanish" before it can be affected by an attack. Tagging facilitates the tracking of suspicious traffic and routing other traffic accordingly. Network holography employs "smoke and mirrors" to conceal a real network and project an illusory topology. Transfiguration enables network topologies to be dynamically manipulated (i.e., "shape shifted") to adapt to the environment and context.

Multiprotocol Label Switching Networks

Circuit switching and packet switching are the two main paradigms for transporting traffic across large networks [START_REF] Peterson | Computer Networks: A Systems Approach[END_REF]. ATM and Frame Relay (OSI Layer 2) are examples of circuit-switched (i.e., connection-oriented) technologies that provide low latency and high quality of service (QoS). IP (OSI Layer 3) is a packet-switched (i.e., connectionless) protocol that unifies heterogeneous network technologies to support numerous Internet applications.

An important goal of service providers is to design networks with the flexibility of IP and the speed of circuit switching without sacrificing efficiency [START_REF] Gray | MPLS: Implementing the Technology[END_REF]. In traditional implementations, an overlay model is used, for example, to create an ATM virtual circuit between each pair of IP routers. Operating independently, the two technologies create a relatively inefficient solution. Since IP routers are unaware of the ATM infrastructure and ATM switches are unaware of IP routing, an ATM network must present a virtual topology such as a complete mesh (which is expensive) or a hub with spokes (which lacks redundancy) that connects each IP router. IP may then be used to route traffic based on the virtual, rather than physical, topology.

On the other hand, the routing control paradigm used in IP networks is closely tied to the forwarding mechanism. Since a classless inter-domain routing (CIDR) IP address consists of a network prefix followed by a host identifier, IP networks have a hierarchical model. IP nodes forward packets according to the most specific ("longest match") route entry identified by the destination address. Consequently, IP networks are only compatible with control paradigms that create hierarchical routes.

The need to enhance QoS and integrate IP with connection-oriented technologies like ATM has prompted the development of a more general forwarding scheme for MPLS -one that does not limit the control paradigm [START_REF] Black | MPLS and Label Switching Networks[END_REF][START_REF] Davie | MPLS: Technology and Applications[END_REF]. This forwarding mechanism, called "label switching," is similar to the technique used by circuit-switched technologies. Thus, MPLS enables connection-oriented nodes to peer directly with connectionless technologies by transforming ATM switches into IP routers. ATM switches participate directly in IP routing protocols (e.g., RIP and OSPF) to construct label switched paths (LSPs). LSPs are implemented in ATM switches as virtual circuits, enabling existing ATM technology to support the MPLS forwarding mechanism. Conversely, MPLS enables connectionless technologies, e.g., Ethernet, to behave in a connection-oriented manner by augmenting IP addresses and routing protocols with relatively short, fixed-length labels.

MPLS employs a single adaptable forwarding algorithm that supports multiple control components. MPLS labels are conceptually similar to the bar codes on U.S. mail that encode ZIP+4 information; these bar codes are used by the U.S. Postal Service to automatically sort, prioritize, route and track nearly 750 million pieces of mail a day. Within the MPLS core, label switching relies only on the packet label to select an LSP. Thus, any algorithm that can construct LSPs and specify labels can be used to control an MPLS network core. Some additional components are required at the edge where the MPLS core connects to other types of networks (e.g., an inter-office VPN running traditional IP). The MPLS edge routers interpret external routing information, place labels on ingress packets and remove labels from egress packets.

The following sections describe label switching and label distribution, which underlie packet transport in MPLS networks.

Label Switching

MPLS packet forwarding resembles the mechanism used in circuit-switched technologies; in fact, it is compatible with ATM and Frame Relay networks [START_REF] Black | MPLS and Label Switching Networks[END_REF][START_REF] Davie | MPLS: Technology and Applications[END_REF]. Each MPLS label is a 32-bit fixed-length tag that is inserted in the Layer 2 header (e.g., for ATM VCI and Frame Relay DLCI) or in a separate "shim" between Layers 2 and 3 [START_REF] Rosen | Multiprotocol Label Switching Architecture[END_REF]. A label works much like an IP address in that it dictates the path used by a router to forward the packet. Unlike an IP address, however, an MPLS label only has local significance. When a router receives a labeled packet, the label informs the router (and only that router) about the operations to be performed on the packet. Typically, a router pops the label on an incoming packet and pushes a new label for the router at the next hop in the MPLS network; the network address in Layer 3 is unchanged. MPLS networks carry traffic between other connected networks. As such, most user traffic travels from ingress to egress (i.e., the traffic is neither destined for nor originating from internal MPLS hosts). At the ingress, a label is placed in the packet between the OSI Layer 2 and 3 headers [START_REF] Rosen | Multiprotocol Label Switching Architecture[END_REF]. The label informs the next hop about the path, destination and relative "importance" of the packet. At each hop, the label is examined to determine the next hop and outgoing label for the packet. The packet is then relabeled and forwarded. This process continues until the packet reaches the egress where the label is removed. If the MPLS network is composed mainly of ATM switches, the ATM hardware can naturally implement the MPLS forwarding algorithm using the ATM header with little or no hardware modification.

Figure 1 shows a typical MPLS architecture that interconnects two customer VPN sites. Routers A through F in the MPLS network are called label switching routers (LSRs). Customer edge routers, CE1 and CE2, reside at the edge of the customer network and provide MPLS core connectivity.

Consider the label switched path (LSP) from VPN Site 1 to VPN Site 2 (Routers A, B, C and F). Router A is designated as the ingress and Router F is designated as the egress for the path. The ingress and egress nodes are called label edge routers (LERs) [START_REF] Rosen | Multiprotocol Label Switching Architecture[END_REF]. When an IP packet reaches the ingress of the MPLS network, LER A consults its forwarding information base (FIB) and assigns the packet to a forwarding equivalence class (FEC). The FEC maps to a designated label that specifies QoS and class of service (CoS) requirements based on Layer 3 parameters in the packet (e.g., source IP, destination IP and application ports). In this example, LER A pushes Label L1 onto the packet and forwards it to LSR B. LSR B reads the label and consults its incoming label map (ILM) to identify the FEC of the packet. It then pops the previous label, pushes a new label (L2) and forwards the packet to its next hop LSR C. LSR C behaves similarly, forwarding the packet to LER F. LER F then pops L3, examines the destination IP address and forwards the packet to VPN Site 2, where traditional IP forwarding resumes.

Label Distribution

A forwarding algorithm alone is not enough to implement an MPLS network. The individual nodes need to know the network topology in order to make informed forwarding decisions. The MPLS Working Group [START_REF] Anderson | LDP Specification[END_REF] defines a forwarding mechanism and control components to emulate IP routes using MPLS labels and paths. In IP, routing protocols such as RIP and OSPF populate IP forwarding tables [START_REF] Peterson | Computer Networks: A Systems Approach[END_REF]. Similarly, MPLS requires label distribution protocols to build end-to-end LSPs by populating the FIB and ILM of each node. Because MPLS is not tied to a particular paradigm, any routing protocol capable of carrying MPLS labels can be used to build MPLS LSPs. Such protocols include:

Label Distribution Protocol (LDP): This protocol is designed to build aggregate LSPs based on IP routing information gathered by a traditional IP routing protocol such as RIP [START_REF] Anderson | LDP Specification[END_REF].

Resource Reservation Protocol -Traffic Engineering (RSVP-TE): This protocol incorporates extensions to RSVP in order to construct LSP tunnels along requested paths with varying QoS. RSVP-TE is commonly used for traffic engineering (TE) in MPLS networks [START_REF] Awduche | RSVP-TE: Extensions to RSVP for LSP Tunnels[END_REF].

Multiprotocol Extension to Border Gateway Protocol 4 (MP-BGP): This protocol extends BGP, and generalizes distributed gateway addresses and carries labels. It is commonly used to build VPNs [START_REF] Bates | Multiprotocol Extensions for BGP-4[END_REF][START_REF] Rosen | BGP/MPLS IP Virtual Private Networks (VPNs)[END_REF].

The three protocols listed above are commonly employed in IP-based networks. This demonstrates that MPLS seamlessly supports the IP routing paradigm and enables IP to be efficiently deployed in ATM and Frame Relay networks without the need for convoluted virtual topologies.

MPLS Implementation Requirements

Two requirements must be met to implement hyperspeed signaling. First, the network must be able to recognize and distinguish hyperspeed signals from non-hyperspeed signals. Second, the network must be able to provide appreciable differences in delivery delays, so that the reaction time windows are satisfied by hyperspeed signals. The network environment and the delay techniques that are applied govern the degree of flexibility with respect to the maximum possible reaction time window.

MPLS is an ideal technology for implementing hyperspeed signaling because it has built-in identification and service differentiation technologies. Labels in MPLS act like circuit identifiers in ATM to designate the paths taken by packets in the network core. Hyperspeed signaling in MPLS would use the packet label to distinguish hyperspeed packets from non-hyperspeed packets. MPLS-capable routers are typically equipped with many QoS and traffic shaping features. LSRs can be configured to give hyperspeed packets the highest priority based on the packet label. Likewise, LSRs can be configured to delay non-hyperspeed packets in forwarding queues. Because the label dictates the QoS and the path, nonhyperspeed packets could be forced to take circuitous routes by constructing the corresponding LSPs using non-hyperspeed labels. The labels corresponding to optimal routes are reserved for hyperspeed packets.

Ingress Detector

Novel Defense Techniques

Hyperspeed signaling can help implement several sophisticated network defense techniques. These include distributed filtering, teleporting packets, quarantining network devices, tagging and tracking suspicious packets, projecting holographic network topologies and transfiguring networks.

Distributed Filtering

Hyperspeed signaling supports a variety of distributed filtering configurations. The simplest configuration is "egress filtering" that can be used by service provider networks and other entities that transport traffic between networks. As shown in Figure 2, when a malicious packet is identified, a hyperspeed sentinel message is sent to the egress filter to intercept the packet. If the reaction time window is sufficiently large, the sentinel message arrives at the egress filter in advance of the malicious packet to permit the threat to be neutralized. The sentinel message must contain enough information to identify the malicious packet. Note that the malicious traffic is dropped at the egress filter, and the downstream network is unaware of the attempted attack.

Hyperspeed signaling enhances flexibility and efficiency by distributing detection and filtration functionality. Also, it enables service provider networks and other networks (e.g., enterprise networks) that employ multiple detection modalities to maintain low latency. The traditional ingress filtering approach is shown in Figure 3(a). This approach deploys detector-filters in series, where each detector-filter (e.g., firewall) contributes to the overall delay. On the other hand, the distributed filtering approach shown in Figure 3(b) deploys detectors in parallel at ingress and a filter at egress. Thus, the overall delay is the delay introduced by the single slowest detector plus the delay required for egress filtering. Figure 4 shows an advance warning configuration where a hyperspeed signal (sentinel message) is sent to the customer (or peer) ingress instead of the provider egress. In this configuration, the service provider (or peer) network detects malicious packets, but only alerts the customer (or peer) network about the incoming packets. Since the other party has advance warning, it can observe, analyze and/or block the packets or take any other actions it sees fit.

Ingress Detector

The advance warning configuration enables networks to outsource detection. Copies of suspicious packets could be forwarded to a third party that has sophisticated detection capabilities (e.g., security service providers or government agencies). If the third party detects malicious activity, it can send a hyperspeed signal to trigger filtering. The third party could correlate packets observed from multiple client networks and provide sophisticated detection services to its clients without compromising its intellectual property or national security.

Teleportation

Hyperspeed routes can be used to teleport packets. Simple teleportation is shown in Figure 5. An operator located at A sends a packet along path ABFG where the hop from B to F involves teleportation. To teleport the packet from B to F, the packet could be encrypted and encapsulated in a labeled ICMP ping packet and sent to B along a hyperspeed path, where it would be converted to its original form and forwarded to G along a normal path. If the teleportation mechanism is to be further concealed, then the packet could be fragmented and the fragments sent along different hyperspeed paths to F (assuming that multiple hyperspeed paths exist from B to F).

Another teleportation approach takes after stage magic. Magicians often use identical twins to create the illusion of teleportation. To set up the act, the magician positions one twin at the source while the other is hidden at the destination. During the act, the magician directs the first twin to enter a box and then secretly signals the other twin to reveal himself at the destination. The same approach can be used to create the illusion of packet teleportation.

The staged teleportation approach is shown in Figure 6. An operator at A uses simple teleportation to secretly send a packet from A to F (Step 1). Next, the operator sends an identical packet from A to B along a normal path; this packet is dropped upon reaching B (Step 2). The operator then sends a hyperspeed signal from A to F (Step 3), which causes the staged packet to move from F to G along a normal path (Step 4). A casual observer would see the packet travel from A to B and the same packet subsequently travel from F to G, but would not see the packet travel from B to F (because no such transmission took place). Depending on the time-sensitivity of the operation, the stage can be set (Step 1) long before the act (Steps 2, 3 and 4) takes place.

A variation of the teleportation act involves a modification of Step 1. An operator located at F sends a copy of a packet to A along a covert hyperspeed path. As in the previous scenario, a casual observer would see the packet travel from A to B and then from F to G, but not from B to F. This staged teleportation approach can help conceal the real origins of network messages.

Ingress Target

Detector

Malicious Packet

Quarantine Messages Figure 7. Quarantining Network Devices.

Quarantining

Quarantining enables a network device, segment or path to disappear before it can be compromised by an attack. As shown in Figure 7, a detector located upstream of a targeted device identifies a threat. The detector then sends hyperspeed signals to the appropriate network nodes to prevent malicious traffic from reaching the device. This essentially quarantines the targeted device.

Note that if the attack reaches the targeted device before it is quarantined, the device is isolated before it can affect other parts of the network; the device is reconnected only after it is verified to be secure. Of course, the fact that quarantine messages travel along hyperspeed paths increases the likelihood that the attack will be thwarted before it impacts the targeted device. The same technique can be used to quarantine network segments or deny the use of certain network paths.

Tagging

One application of tagging is similar to the use of pheromone trails by animals. In this application, a network essentially tracks the paths taken by suspicious traffic. A network administrator sends diagnostic packets via hyperspeed paths to nodes along the path taken by a suspicious packet in order to observe its behavior. If, as shown in Figure 8, the suspicious packet causes anomalous behavior at one of the nodes, the diagnostic packet reports the anomaly via a hyperspeed signal and the compromised device can be quarantined as described above. In extreme cases, all the nodes on the path taken by the suspicious packet could be quarantined until the situation is resolved.

Tagging can also be used to mitigate the effects of attacks that originate from multiple sources, including distributed denial-of-service attacks (DDoS) and other novel attacks. Consider a sophisticated attack that works like the "five finger death punch" in the movie Kill Bill Vol. 2. The attack, which is fragmented into five benign packets, is executed only when all five packets are assembled in sequence. Since a single stateful firewall with knowledge about the fragmented attack could detect and block one or more packets, implementing a successful attack would require the packets to be sent from different locations.

The tagging mechanism can counter the fragmented attack by quarantining the target as soon as anomalous behavior is detected. The packets constituting the attack could then be traced back to their origins at the network perimeter, and security devices configured appropriately to detect the attack.

Network Holography

Networks can hide their internal structure, for example, by using private IP addresses. Hyperspeed signaling enables networks to project illusory internal structures or "holograms."

Conventional holograms are created using lasers and special optics to record scenes. In some cases, especially when a cylindrical piece of glass is used, a scene is recorded from many angles. Once recorded, the original scene may be removed, but the hologram still projects the recorded scene according to the viewing angle. If enough angles are recorded, the hologram creates the illusion that the original scene is still in place.

Similarly, an illusory network topology can be created in memory and distributed to edge nodes in a real network (Figure 9). The presence of multiple hyperspeed paths between pairs of edge routers can help simulate the illusory topology. Other nodes may be included, but the edge nodes at the very minimum must be included. When probes (e.g., ping and traceroute) hit the real network, the edge nodes respond to the probes as if the network has the illusory topology. It is important that the same topology is simulated from all angles (i.e., no matter where the probe enters the network) because any inconsistency would shatter the illusion.

Transfiguration

Transfiguration enables networks to cooperate, much like utilities in the electric power grid [START_REF] Wald | Hurdles (not financial ones) await electric grid update[END_REF], to provide services during times of crisis. Network administrators can manipulate their internal network topologies or modify the topologies along the perimeters of cooperating networks to lend or lease additional resources as required. Additionally, administrators may need to modify the topologies at the perimeter boundaries near an attack. This method is analogous to moving the frontline forward or backward during a battle.

Links and nodes may need to be strategically quarantined, disabled or reenabled based on the circumstances. As resources are lost and gained, the roles of devices, especially at the perimeter, may change. Hyperspeed signaling permits topology changes to occur seemingly instantaneously and enables devices with special roles to operate in proxy where necessary at the perimeter. As resources become available (either regained after being compromised or leased from other sources), the window for hyperspeed signaling can be adjusted to provide additional reaction time.

Implementation Challenges

This section discusses the principal challenges involved in implementing hyperspeed signaling in MPLS networks. The challenges include network deployment, traffic burden and net neutrality.

Network Deployment

Deploying a hyperspeed signaling protocol in a network involves two principal tasks. The first is programming the hardware devices to satisfy the hyperspeed signaling requirements for the specific network. Second, the hardware devices must be installed, configured and calibrated for efficient hyperspeed signaling. Ideally, vendors would program the algorithms/protocols in the hardware devices. The installation, configuration and calibration of the devices would be performed by network engineers and administrators. This task would be simplified and rendered less expensive if vendors were to offer software/firmware updates for deploying hyperspeed signaling without the need to replace existing network devices.

Traffic Burden

Sending traffic along suboptimal paths essentially increases network "capacitance" -keeping more packets in the network at any given time. Because the additional time that a non-hyperspeed packet spends in the network is specified by the reaction time window, the amount of additional traffic flowing in the network is approximately equal to the product of the reaction time window and the average link bandwidth.

Another metric for the burden imposed by hyperspeed signaling is the nonhyperspeed delay divided by the hyperspeed delay (the non-hyperspeed delay is equal to the hyperspeed delay plus the reaction time window). This metric only applies to pairs of communicating end points.

MPLS networks may need additional bandwidth depending on their capacity and the presence of alternate links. The traffic burden due to hyperspeed signaling can be reduced by strategically partitioning a network into multiple signaling domains to prevent critical links from being flooded.

A traffic burden is also induced in a distributed filtering scenario where malicious traffic is allowed to flow through the network and screened later (e.g., at an interior or egress node). However, this is not an issue because most service provider networks simply transport traffic, leaving the task of filtering to customers.

Net Neutrality

Issues regarding net neutrality must be considered because the implementation of hyperspeed signaling requires command and control traffic to be treated differently from other traffic. In particular, non-hyperspeed traffic is intentionally slowed to accommodate the desired reaction time windows.

At this time, there is no consensus on the definition of net neutrality [START_REF] Travis | The FCC's new theory of the First Amendment[END_REF]. Does net neutrality mean that all traffic should be treated the same? Or does it mean that only traffic associated with a particular application type should be treated the same?

Regardless of its definition, net neutrality is not a major concern for VPN service providers, who can give preferential treatment to traffic based on the applicable service level agreements. In the case of Internet service providers, net neutrality would not be violated as long as all customer traffic is slowed by the same amount.

Currently, no laws have been enacted to enforce net neutrality, although there has been considerable discussion regarding proposed legislation. Many of the proposals permit exceptions in the case of traffic management, public safety and national security. Since hyperspeed signaling, as discussed in this paper, focuses on network defense, it is reasonable to conclude that it would fall under one or more of the three exemptions.

Interestingly, the distributed filtering technique provided by hyperspeed signaling actually enables service providers to treat different types of traffic in a "more neutral" manner than otherwise. Consider a situation where a service provider employs a firewall that performs deep packet inspection. Certain types of traffic (e.g., suspicious packets) would require more inspection time by the firewall, contributing to a larger delay than for other traffic. But this is not the case when all traffic (including suspicious traffic) is allowed to enter the network while copies are simultaneously sent to a distributed detector. Malicious packets are filtered at egress or elsewhere in the network using hyperspeed signaling. Non-malicious packets in the same suspicious traffic pass through the network just like normal traffic.

Conclusions

As attacks on computer and telecommunications networks become more prolific and more insidious, it will be increasingly important to deploy novel strategies that give the advantage to network defenders. Hyperspeed signaling is a promising defensive technology that could combat current and future threats. The paradigm is motivated by Arthur C. Clarke's third law of prediction: "Any sufficiently advanced technology is indistinguishable from magic" [START_REF] Clarke | Profiles of the Future: An Inquiry into the Limits of the Possible[END_REF]. Hyperspeed signaling does not require electrons to move faster than the laws of physics permit; instead, malicious traffic is slowed down ever so slightly to endow defensive capabilities that are seemingly magical. The hallmark of good engineering is making the right trade-off. Intentionally slowing down network traffic may appear to be counterintuitive, but the defensive advantages gained by hyperspeed signaling may well outweigh the costs.

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

Figure 1 .

 1 Figure 1. MPLS packet forwarding.

Figure 2 .

 2 Figure 2. Egress filtering.

Figure 3 .

 3 Figure 3. Traditional and distributed filtering configurations.

Figure 4 .

 4 Figure 4. Advance warning.

Figure 5 .

 5 Figure 5. Simple teleportation.

Figure 6 .

 6 Figure 6. Staged teleportation.

Figure 8 .

 8 Figure 8. Tagging.

Figure 9 .

 9 Figure 9. Network holography.


Yujue Wang

Carl Hauser

An Evidence-Based Trust Assessment Framework for Critical Infrastructure Decision Making

Keywords: Trust assessment, Bayesian estimation, electric power grid

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

Introduction

The U.S. electric power grid is on the cusp of a tremendous expansion in the amount of sensor data available to support its operations. For decades, the power grid has been operated using supervisory control and data acquisition (SCADA) systems that poll each sensor once every two or four seconds -a situation that some in the industry have characterized as "flying blind." The widespread deployment of sensing systems called phasor measurement units (PMUs) that provide accurately time-stamped data 30, 60 or more times per second is near at hand. By the end of 2013, utilities, with the assistance of the American Recovery and Reinvestment Act of 2009 (ARRA), will have increased the number of these devices on the grid to nearly 1,000, roughly an order of magnitude increase over what exists today. Data from PMUs and other high-rate sensing devices will support new control schemes for the reliable and efficient operation of the power grid as larger fractions of electric power demand are met by intermittent sources such as wind and solar, and as controllable loads such as electric vehicle rechargers increase.

As power grid operations come to increasingly rely on these new control schemes, the availability and integrity of the data, but to some degree confidentiality as well, are of great concern. Good security practices and technologies such as those required by the NERC CIP standards [15] will be more essential to reliable grid operations than they are today. However, uncertainty is inherent to large-scale systems such as the power grid due to measurement errors (e.g., sensor reading errors) and the stochastic nature of physical processes (e.g., weather conditions).

Uncertainties associated with PMUs arise from several factors: (i) PMUs are deployed under the control of various entities, throughout the transmission and distribution systems, that have different management policies and configurations; (ii) a number of cyber attacks on PMUs can impact electric power systems; and (iii) with vastly more data available, it becomes possible to use a subset of data from the most trustworthy sources. For example, when PMU data authentication is performed using a public-key infrastructure, the reliability of the authentication is ultimately limited by the uncertainty of the binding between a particular public key and the authenticated entity. While one might wish that there were no uncertainty, it is, in fact, quite likely that some of the bindings in a large-scale system are incorrectly known at least some of the time by some entities, whether due to error or malicious manipulation.

If uncertainty is indeed unavoidable, the reliability of the system comes down to blind faith -we know that security is uncertain but we have to trust in it because it is all we have -or to decision processes that explicitly and appropriately take into account the uncertainties associated with security. This paper focuses on the latter viewpoint.

Since the power grid must be controlled in real time in an ever-changing security threat environment, we are interested in decision models that can be fully automated rather than models that rely on human insight. Because Bayesian decision theory fits well with our desire for a computational solution, our approach uses a Bayesian perspective [START_REF] Robert | The Bayesian Choice: From Decision-Theoretic Foundations to Computational Implementation[END_REF].

The word "trust" is introduced here for its connotations of one party's (trustor's) reliance on and belief in the performance of another party (trustee). An example is the trust in a public-key infrastructure (PKI) certifier to correctly bind a public key to some other entity. The reliance or belief often must occur without certainty or they may be in the form of a prediction about the future (itself a source of uncertainty). Trust, though uncertain, need not be blind: trustors can use evidence, in the form of past experience with a trustee, reputation information, or contracts and laws that impose penalties for nonperformance, to form their trust judgments. We believe that if critical infrastructures are to be resilient against attacks, then operational decision making processes must appropriately take into account evidence about the trustworthi- ness of their input data. As we will show, using evidence appropriately means that it is considered in the light of the particular decision being made: there is no single approach to judging trust that is universally appropriate.

This paper establishes the need for a systematic method of dealing with uncertainty related to trust in the context of control systems. It presents a theoretical framework based on Bayesian decision theory that addresses this need by incorporating trust-related evidence.

Motivating Example

The consumer credit reporting and scoring system provides an interesting analogy for evidence-based decision making in the presence of risk. As shown in Figure 1, credit bureaus collect information from various sources and provide credit reports that detail individual consumers' past borrowing and bill paying behaviors. Some companies further analyze the information in credit reports from multiple sources to produce a single, numerical credit score based on the statistical analysis of an individual's credit reports. The credit score is claimed to statistically represent the creditworthiness of an individual. Now consider the decisions that lenders make in analyzing a loan application. They have to decide whether or not to make the loan and the terms under which the loan should be made. If the loan is made, then the lender stands to make a profit if the borrower pays it back, or the lender makes a loss if the borrower defaults on the payment. A loss function describes the lender's payback for various future behaviors of the borrower. While the loss function is known, the future behavior of the borrower is, of course, uncertain at the time the loan is made. The lender thus seeks to make a decision that minimizes the expected loss (maximizes the expected return) by assessing the probabilities of different future borrower behaviors. This is done by considering the credit report or credit score as well as information about employment, income and stability of residence that is contained in the loan application.

There are several important points to note in this analogy.

First, different lenders have different loss functions, and a single lender may have different loss functions for different kinds of loans: trust decisions are situational. In the power grid domain, a decision to turn off electric car charging at a time when the power supply is stressed carries different loss implications than a decision to shed load by turning off power to an entire region.

Second, different lenders may assess the probability of various borrower behaviors differently based on the same credit report facts: trust decisions are subjective.

Third, the analogy is imperfect. In the case of lending, risk pooling allows businesses to balance losses from some loans with profits from others, so decisions take into account not only an individual loan but a portfolio of loans. The consequences of decisions related to power grid operations cannot be easily aggregated, so the decision processes generally emphasize the analysis of individual decisions.

Thus, there are similarities and differences between the two domains. However, the structure is basically the same: the trustor collects evidence about a trustee and uses it to probabilistically predict the behavior of the trustee according to a model. The trustor may make decisions that, in hindsight, seem wrong, but the decisions are, nevertheless, the best that could be made at the time based on the available information.

Preliminaries

The distributed control system for a large-scale critical infrastructure (such as the electric power grid) can be described abstractly as consisting of a collection of controllers, a collection of data sources and a collection of actuators. Controller and actuators share the essential characteristics related to the uncertainty of security, so we focus primarily on controllers and information sources. In the power grid, for example, controllers include protective relays, automatic generator controls, remedial action schemes, etc. Data sources include sensors, human operators and controller outputs. Communication channels link data sources to controllers. The essential property of controllers is that they receive inputs from data sources and repeatedly make decisions based on the data, with the decisions ultimately being reflected in an action that changes the physical state of the grid.

Because of the noise in sensor outputs, system inputs are assumed to be probabilistically related to the actual state of the sensed world by considering that each measurement corresponds to the actual state plus a normally-distributed noise term. System failures can lead to bad inputs (highly improbable in the model with normally-distributed noise), which can often be detected and excluded by bad-data detection algorithms that exploit redundancy present in the inputs. Several researchers have studied how input data streams might be intentionally attacked in a manner that is invisible to the bad-data detectors that are in use today (see, e.g., [START_REF] Liu | False data injection attacks against state estimation in electric power grids[END_REF]).

The approach described in this paper is, at a high level, aimed at providing controllers with the ability to evaluate evidence from a variety of sources regarding the correctness of data received from sensors and the ability of actuators to carry out the commanded actions. The uncertainties associated with these aspects and the outcomes are modeled probabilistically, albeit with much greater flexibility than afforded by current approaches that assume normallydistributed noise, and with the explicit incorporation of uncertain results in the form of loss functions.

Bayesian Decision Model

Decision theory studies the values and uncertainties related to making rational and optimal decisions [START_REF] French | Decision Theory: An Introduction to the Mathematics of Rationality[END_REF]. Statistical theory has been widely applied to decision making problems [START_REF] Pratt | Introduction to Statistical Decision Theory[END_REF]. Our method is based on the Bayesian statistical paradigm, which quantifies the uncertainty of decisions using personal probability [START_REF] O'hagan | Bayesian statistics: Principles and benefits, in Bayesian Statistics and Quality Modeling in the Agro-Food Production Chain[END_REF]. Interested readers are referred to [START_REF] Robert | The Bayesian Choice: From Decision-Theoretic Foundations to Computational Implementation[END_REF] for a systematic introduction to Bayesian decision theory.

As previously noted, uncertainty is inherent in complex systems. Thus, risk, which is a state of uncertainty where some of the possibilities involve a loss, catastrophe or other undesirable outcome, is unavoidable. In order to reduce risk, every entity in a system should have the ability to incorporate evidence about the trustworthiness of other entities and be inclined to rely on entities that are (more) trustworthy.

To formalize this view, we assume that there are a number of trust-related attributes E = (E 1 , E 2 , . . . , E p ) concerning each entity in the system, which together form the trust evidence. By focusing on a single entity A at a certain point in time, it is possible to collect the current evidence about an entity B, which is denoted as x i = (ε 1 , ε 2 , . . . , ε p ) ∈ R p . Over a period of time, a number of x i s, denoted by x = (x 1 , x 2 , • • • , x n ), would be collected. Based on x, A makes a decision d ∈ D (where D is the decision space) on B in the light of A's estimate of the value of θ (0 ≤ θ ≤ 1) from the parameter space Θ, which is the trustworthiness that is placed on B. Essentially, θ is the probability that B is trustworthy.

In the proposed model, the decision making process is considered as a choice of action made by the decision maker from among a set of alternatives according to their possible consequences. In the electric power grid, these decisions are made under uncertainty, i.e., the decision maker can neither know the exact consequence of a chosen decision before it occurs nor obtain accurate values of the evidence due to system complexity and uncertainty. Probabilistic modeling is a natural choice for interpreting the evidence E and evaluating the conse-quences. The model should not only incorporate the available information in E, but also the uncertainty of this information. In the probabilistic model,

x i (1 ≤ i ≤ n) follows a probability distribution f i , x i ∼ f i (x i |θ, x 1 , • • • , x i-1 ) on R p ,
where f i is known but θ is unknown. If x is collected over a short enough period of time, it is reasonable to assume that x 1 , x 2 , • • • , x n are independent repeated trials from identical distributions and that the distribution can be denoted as:

x ∼ f (x|θ) .
The likelihood function l is defined as:

l (θ|x) = f (x|θ) .
The likelihood function l is equal to f , but it emphasizes that θ is conditional on x and manifests that θ can be inferred from x. According to our assumptions and the likelihood principle [START_REF] Berger | Statistical Decision Theory and Bayesian Analysis[END_REF], all available information to make an inference about θ is contained in the likelihood function l (θ|x). Decisions can then be made based on the inferred value of θ. To combine these processes, when the likelihood function l (θ|x) is fixed, a function from X to D can be obtained as δ (x), which is called the decision rule as it relates to trust. Note that trustworthiness assessment is only one aspect of the overall decision process. Decisions are made according to the inferred trustworthiness value, but trustworthiness evaluation is not the end goal.

Next, we describe the elements involved in a Bayesian determination of decision rule δ (x), namely prior distributions and loss functions, and proceed to specify the derived rule.

Modeling Prior Information

As previously noted, trust decisions are subjective: based on the very same evidence, different trustors may make different decisions. In the Bayesian model, the uncertainty of the trustworthiness value θ of a trustor regarding a trustee before receiving evidence is modeled using a prior probability distribution π(θ) on Θ. Subjectivity of trust is naturally modeled by different prior distributions.

Loss Function

While it is easy to talk about making "good" decisions, the model requires a precise formalization of the notion of goodness. All the possible choices in a decision should be ordered or quantified. Decision theory uses a loss function for this purpose. The loss function is a function L ≥ 0 from Θ × D to R p , which represents the penalty L (θ, d) associated with the decision d when the parameter takes the value θ. In our case, the penalty L (θ, d) is the quantified consequence at the time the decision is made when the trustee's trustworthiness value is θ and the trustor chooses decision d. However, it is very hard to measure the trustworthiness value of a trustee in a complex system due to the dynamic and fuzzy nature of trust [START_REF] Chang | The fuzzy and dynamic nature of trust[END_REF]. Therefore, it is important that the model can reflect this uncertainty. A simple way to obtain the loss is to integrate over all possible values of θ. Moreover, instead of focusing on one decision, our goal is to assess a decision rule δ (x), which is the allocation of a decision to each outcome x ∼ f (x|θ). Thus, the loss function L (θ, δ (x)) should also be integrated over X , the entire space of x.

Given the prior distribution π (θ) and the distribution f (x|θ) of x, θ should be integrated in proportion to π (θ) and x in proportion to f (x|θ). Thus, the loss function can be written as:

r (π, δ) = E π [R (θ, δ)] = Θ X L (θ, δ (x)) f (xθ) dxπ (θ) dθ
where r (π, δ) is called the risk function of δ.

Bayesian Estimation

The goal of the decision making model is to derive an "optimal" decision rule that provides trustors with rational decisions about trustees based on observations (evidence) x. Optimality is implemented by minimizing the risk function r (π, δ). The decision maker follows the decision rule that gives the smallest risk. However, the trustworthiness value θ is often unknown, so a problem arises regarding the situation under which the risk function is minimized.

A common choice is the minimax rule, which chooses the δ that satisfies the equation:

sup θ r θ, δ = inf δ sup θ r (θ, δ) sup θ r θ, δ = inf δ sup θ r (θ, δ) .
The minimax rule also fits our original intention to make decisions that reduce the risk of trustors under uncertainty.

As an implementation of the likelihood principle, the Bayesian paradigm satisfies the decision-related requirements for trust assessment. It not only quantifies the uncertainties and minimizes the decision making risk, which is crucial when making rational decisions, but it also smoothly incorporates the trustors' prior information about the trustees' trustworthiness. This is essential when the decision process is viewed in the context of long-term system operation: trustors continuously acquire new evidence that must be combined with their prior information when making new decisions.

Illustrative Example

This section illustrates the application of the decision making model. It examines the simplified decision making case involving the inference of the trustworthiness value of a trustee based on the observation x, for which D = Θ.

The evidence aggregator of the trustor collects values of the related attributes E = (E 1 , E 2 , . . . , E p ) and stores the values in the corresponding vector (ε 1 , ε 2 , . . . , ε p ). Within a short time T , the evidence aggregator collects the n vectors forming x = (x 1 , x 2 , • • • x n ). Since the time T is short, we assume that x 1 , x 2 , • • • x n are independent repeated trials from identical distributions f . According to the probabilistic model, the values of the attributes are conditional on the trustworthiness value θ, so the distribution can be denoted as f (x|θ).

As mentioned before, trust is subjective. For example, risk-averse trustors may tend to make negative decisions and risk-preferred trustors may tend to make positive decisions. The differences among trustors could be attributed to many factors. For instance, the difference might be due to the previous experience of trustors. A positive experience on the part of a trustor means that the trustor has made many correct decisions regarding trustworthy entities and makes the trustor more risk-preferred. Conversely, negative experience, which means that a trustor has made wrong decisions and trusted the wrong entities, makes the trustor more cautious. For one-dimensional evidence, this type of subjectivity can be modeled using a Beta-distribution with parameters α and β as the prior distribution of trustors. Let α be the number of past negative experiences and β be the number of past positive experiences. The prior information of trustors can be modeled as:

π (θ) = Beta (α, β) = θ α-1 (1 -θ) β-1 1 0 t α-1 (1 -t) β-1 dt
where π (θ) is the probability that the trustor decides to trust the trustee. Increasing the value of α makes the trustor more risk averse and increasing β makes the trustor more risk preferred. As shown in Figure 2, a decision maker with α = 8 and β = 2 (top line) tends to make negative trust decisions since the probability is high that trust-worthiness values under 0.5 are allocated. On the other hand, a decision maker with α = 2 and β = 8 (bottom line) is more likely to make positive decisions.

In this simplified example, since it is only necessary to estimate the value of θ, we select a commonly-used simple loss function, called the "quadratic loss function." This function is given by:

L (θ, δ) = (θ -δ) 2 .
The risk function is:

r (θ, δ) = Θ X (θ -δ) 2 f (x|θ) dxπ (θ) dθ.
The corresponding the computed estimator is:

δ (x) = Θ θf (x|θ) π (θ) dθ Θ f (x|θ) π (θ) dθ .

Related Work

The issue of trust is drawing increasing attention in the information security community. In 1996, Rasmussen and Jansson [START_REF] Rasmusson | Simulated social control for secure Internet commerce[END_REF] examined the relationship between security and social control, and classified security mechanisms as: "soft security" such as trust and reputation systems, and "hard security" such as authentication and access control. Most security mechanisms include some aspects of trust, but they make implicit "trust assumptions" [START_REF] Christianson | Why isn't trust transitive[END_REF]. In order to overcome the drawbacks of current security mechanisms such as the inadequacy of authentication [START_REF] Blaze | The role of trust management in distributed systems security[END_REF], a more general concept of trustworthiness should be engaged [START_REF] Abdul-Rahman | A distributed trust model[END_REF].

Trust management is largely associated with inference and decision making. Related evidence should be collected first and delivered to the trust management system as an input to the decision making model. Several trust management systems, such as PolicyMaker [START_REF] Blaze | The role of trust management in distributed systems security[END_REF], KeyNote [START_REF] Blaze | KeyNote: Trust management for public-key infrastructures[END_REF] and REFEREE [START_REF] Chu | REF-EREE: Trust management for web applications[END_REF], have been designed to collect security credentials and test the compliance of the credentials with security policies. Also, some trustworthiness computing models (e.g., [START_REF] Denko | Trust management in ubiquitous computing: A Bayesian approach[END_REF]) collect trustors' prior experience as evidence and make predictions based on the experience. Some models collect evidence from other entities -these are essentially reputation systems [START_REF] Josang | A survey of trust and reputation systems for online service provision[END_REF][START_REF] Kamvar | The Eigentrust algorithm for reputation management in P2P networks[END_REF]. Generally, however, trust management systems and trustworthiness computing models [START_REF] Abdul-Rahman | Supporting trust in virtual communities[END_REF][START_REF] Conner | A trust management framework for service-oriented environments[END_REF] attempt to determine a numerical trustworthiness value for a trustee or make a binary decision about whether or not a trustee is trustworthy. Our approach goes beyond this view by focusing on trust decision making as coupled with succeeding decision processes.

Conclusions

The Bayesian paradigm provides an elegant framework for incorporating trust into decision making processes associated with the control of large-scale critical infrastructure systems. The risk function, prior distribution and the distribution of evidence are three key components of the Bayesian paradigm. A prior distribution, which models the subjectivity of trustors, is combined with newly-acquired evidence and the derived Bayes risk function to obtain a decision rule by minimizing the risk function.

Although the mathematical structure of the framework is straightforward, its applicability depends on gaining experience with the kinds of data that are available in critical infrastructure systems and what the data say about trustworthiness. While it may not be clear, for example, what a particular ratio of good/bad past experience means for a particular decision, the framework shows what should be done with such data when it is collected.

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.

Figure 1 .

 1 Figure 1. Credit reporting system.

Figure 2 .

 2 Figure 2. Cumulative distribution functions of three prior distributions.

Acknowledgements

This research was partially funded by Department of Energy Award No. DE-OE0000097 (TCIPG) and by matching funds provided by Washington State University.