Yanjun Zuo

MODELING SERVICE MIGRATION AND RELOCATION IN MISSION-CRITICAL SYSTEMS

Keywords: Mission-critical systems, migration, reliability, availability

Mission-critical information systems are commonly used in critical infrastructure assets such as the electric power grid, telecommunications networks, healthcare systems, water management systems and national defense. Damage or disruption of these systems could result in the loss of services and potentially serious societal consequences. Therefore, it is important to ensure that the essential services provided by these systems are reliable and dependable. This paper presents a modeling framework for service migration and relocation, which can dynamically transfer critical services from a compromised platform to other healthy platforms. The mechanism guarantees that vital services are continuously available despite malicious attacks and system failures. When the compromised platform has recovered, the services can be moved back to the platform. The modeling framework provides a means for studying the important factors that impact service migration and relocation, and how an assured service migration mechanism can be designed to increase confidence about the reliability of mission-critical information systems.

Introduction

Mission-critical systems provide vital services and must, therefore, be reliable and dependable despite malicious attacks and system failures. Their use in critical infrastructure assets such as the electric power grid, telecommunications networks, healthcare systems, water management systems and national defense raises serious concerns about their ability to withstand hardware and software failures, operator errors, power outages, environmental disasters and attacks by adversaries [START_REF] Marsh | Critical Foundations: Protecting America's Infrastructures, Report of the President's Commission on Critical Infrastructure Protection[END_REF].

Despite the best efforts of system developers and security practitioners, it is infeasible to assure that a mission-critical system will be invulnerable to well-organized attacks and unpredictable system failures. Indeed, the scale and complexity of mission-critical systems make it almost impossible to build completely secure and reliable systems. Consequently, it is prudent to prepare for the worst-case scenarios involving security incidents and system failures while ensuring that critical services continue to be available.

This paper focuses on service migration and relocation as a means for ensuring critical service availability. Informally, service migration is a process that suspends a critical service on its current faulty platform and moves its core programs and data to a clean, healthy platform where the service is resumed from where it left off. At a later time, after the compromised platform has recovered and the environment has been sanitized, the critical service is relocated to the original platform and its execution is resumed. Such migration and relocation is incorporated in the architectures of many safety-critical systems [START_REF] Keromytis | A holistic approach to service survivability[END_REF].

Compared with other survivability approaches, service migration is a viable solution to ensure that the most critical services are available in a challenging environment. Techniques such as fault tolerance/masking and damage avoidance are often too expensive or infeasible for large and complex mission-critical systems. In situations where faults are extensive and non-maskable, system operations cannot be continued, even when the system has multiple redundancies. Reconfiguration [START_REF] Koester | Design optimizations for tiled partially reconfigurable systems[END_REF][START_REF] Zick | Low-cost sensing with ring oscillator arrays for healthier reconfigurable systems[END_REF] can avoid intensive replication, but it requires a change in the functional specifications of the platforms that are in operation. Dynamically reconfiguring a system is not always possible, especially when system components have been compromised and only untrustworthy components are available for reconfiguration. Unlike these techniques, strategic migration allows critical services to be continuously provided by other healthy platforms without incurring expensive resource duplication or attempting to reconfigure a system that is not trustworthy.

This paper presents a modeling framework for service migration and relocation in mission-critical systems. A stochastic process algebra, i.e., the Performance Evaluation Process Algebra (PEPA) [START_REF] Hillston | Performance Evaluation Process Algebra (PEPA)[END_REF], is used to represent the activities and components of a complete service migration and relocation procedure. Since critical services are essential, minimal time and effort should be required to move the mission-critical services and relocate them back after the original platform has recovered. This paper studies how important factors such as the probability of severe damage on a platform and the probability and duration of viable migration scheduling can impact the effectiveness and efficiency of service migration and relocation. The resulting model can be used to determine the important factors and how they impact service availability. Also, it can reduce the magnitude of service interruptions by helping deploy the most effective and efficient service migration and relocation mechanisms.

Related Work

Migration has been studied for a number of purposes, including application and service survivability, improvement of the quality of services, resource optimization, system agility and network virtualization. Migration has been proposed at a variety of levels, including services, system components, operating system processes, program threads and applications (e.g., mobile agents).

Choi, et al. [START_REF] Choi | Fast software component migration for application survivability in distributed real-time systems[END_REF] have proposed a methodology for run-time software component migration for application survivability in distributed real-time systems. Two properties are necessary for fast component migration: lightweight service and data transfer and proactive resource discovery. Choi and colleagues developed middleware to support prompt software component migration and identify the available resources to complete the migration. Experimental results demonstrate that the approach takes much less time compared with techniques based on reactive resource discovery.

Amoretti, et al. [START_REF] Amoretti | Service migration within the cloud: Code mobility in SP2A[END_REF] have studied service migration in SP2A-based clouds (SP2A is a framework and middleware for peer-to-peer service-oriented architectures). They propose a framework and middleware for highly dynamic and adaptive clouds, characterized by peer providers and services that can be replicated by code mobility mechanisms.

Another service migration mechanism [START_REF] Fu | Service migration in distributed virtual machines for adaptive grid computing[END_REF] moves the computational services of a virtual server to other available servers for adaptive grid computing. This enables computations to be resumed on a remote server without service reinstallation. The mechanism is incorporated in DSA, a Java compliant distributed virtual machine that accommodates adaptive parallel applications in grids.

Cohen, et al. [START_REF] Cohen | Service migration in an enterprise system architecture[END_REF] have proposed a service migration approach for enterprise system architectures. Instead of locating and delivering data to a processing site as in the case of traditional systems, services are delivered to the data sites for efficiency and higher levels of service availability. This approach extends the notion of a service-oriented architecture and is particularly effective when massive volumes of data (in terabytes) have to be processed. However, the approach requires new technical infrastructures and policies for client and server systems.

Li, et al. [START_REF] Li | A multimedia service migration protocol for single user multiple devices[END_REF] have presented a service migration protocol that supports multimedia transfer in single-user, multiple-device scenarios. Data sessions are grouped by users and can seamlessly migrate to devices associated with the same user. A proxy is used to bridge a client and a server and a protocol is used to retain the current client and server operations while placing new functions at the proxy through naming and control and data plane designs.

The migration approaches described above are very specific and are defined at the lower level of system processes. Our methodology complements these approaches with the objective of providing a general analytic framework that can model and simulate service migration and relocation. Furthermore, it helps users identify the factors that influence the effectiveness and efficiency of service migration and relocation.

Service Migration and Relocation

Let SYS be a distributed system that provides critical services S 1 , S 2 , ..., S n . SYS is composed of a set of computing platforms P 1 , P 2 , ..., P m . Each service S j is executed on one platform at any time and operates as a set of programs. It is assumed that service S j is executed in a virtualized container and is, thus, self-contained, i.e., the service programs, data and processes can be referenced within its namespace. Technically, it is possible to move a service from its current platform P i to a new platform P k in a situation where P i has been severely damaged. In such a case, allowing the platform to continue to perform mission-critical functions could be disastrous. To ensure that the critical services can be provided continuously and to avoid further losses, the services must be transferred to other healthy platforms that are immune to the same types of attacks that compromised the original platform.

Figure 1 shows the workflow of a service migration and relocation process. We assume that a set of services S 1 , S 2 , ..., S n are currently executing on platform P i . Suppose that abnormal behavior is detected on P i and reported as shown in Step 1. This event triggers a thorough investigation and analysis of P i by the security systems of SYS. If the damage assessment indicates that P i has been severely damaged and service migration is the most appropriate strategy, then a service migration and relocation process initiates. For simplicity, we discuss the migration and relocation of one critical service S j .

After a migration decision is made, two actions are taken concurrently as indicated by Step 2. The first action is to halt service S j appropriately, e.g., by freezing the service processes, recording global data (service configuration and state), recording the states of individual processes and terminating the entire service program. As part of the second action, a migration scheduler attempts to generate a service migration arrangement for service S j to be migrated from P i to a new, healthy platform P k . The new platform must be able to support the core functions of S j and should be immune to the same types of attacks suffered by P i . Since a suitable platform may not always be available (e.g., in an environment in which resources are limited), we use a stochastic process to quantify the probability of whether or not an appropriate platform is available. If a platform is not available, the scheduler is modeled to constantly repeat the scheduling process -on the chance that a new platform becomes available at a later time when the operating environment has improved.

The service migration process is composed of three sub-processes [START_REF] Zuo | Moving and relocating: A logical framework of service migration for software system survivability[END_REF]: (i) migration preparation, which saves the service programs and data in a resumeable image in a self-contained format with header, global data, internal process dependencies and shared resources (task structure and open files); (ii) service and data transfer, which synchronizes data copies, withdraws transactions, establishes recovery points and disseminates the packed service programs and data to the new platform P k ; and (iii) service setup on P k , which creates a new namespace and restores the service configuration and state. Since some data associated with S j may have been damaged, the system must provide supplemental data or generate fuzzy data to support the continuity of service S j . When S j is executed on the new platform P k , the compromised platform P i is immediately repaired. A recovery process in the model covers fault diagnosis and damage repair.

In Step 3 in Figure 1, after the service and data are set up on the new platform P k , the execution of S j is resumed. S j may continue to execute on P k to completion. However, for a long-running service, if the previously damaged platform P i has recovered, then S j must be moved back to P i . This relocation is necessary for several reasons [START_REF] Zuo | Moving and relocating: A logical framework of service migration for software system survivability[END_REF]: (i) it improves data access locality by relocating a service closer to the data; (ii) it provides better system response time by relocating the service closer to users; and (iii) it makes for better load balancing by relocating the service to its initial platform based on an optimal resource assignment scheme.

In Step 4, a repair completion notification is sent by the recovery manager to P k when P i is fully recovered. In Step 5, the relocation manager arranges to move S j back to P i . Service relocation is composed of three sub-actions similar to the migration process, but with one major difference -any fuzzy data used by S j when it is running on P k is meant to be used only temporarily while P i is being repaired. A correctional recovery must be performed when S j is relocated back to P i so that the data items reflect the exact values instead of inaccurate, albeit acceptable, values. Finally, in Step 6, S j runs to completion on the repaired platform P i .

To ensure that critical services are provided with minimal interruption, we examine how important factors, such as various system security and functional properties, affect the activities that support an effective and efficient migration and relocation process. For example, the probability (or frequency) of severe damage to a platform significantly impacts the normal operations of the critical services on the platform. Intuitively, if a system has a strong security baseline, few vulnerabilities, efficient intrusion detection and high levels of fault tolerance and masking abilities, then the probability of a platform being severely damaged would be low. Consequently, the critical services can operate on their original platforms most of the time. In such situations, the need for service migration and relocation is minimized. Even in a worst-case scenario, when a migration is necessary, it is necessary to ensure that some key system properties, if satisfied, will provide for effective and efficient service migration. For example, a new platform must be available to host the services when damage is detected to the original platform. Halting the services on the compromised platform and setting them up on the new platform must be completed as quickly as possible. The service priority, response time and throughput must be ensured both during and after the service migration. As will be seen below, these factors are expressed as model parameters (e.g., activity rates) in a simulation because we are interested in learning how the parameters affect the normal execution of critical services.

Service Migration and Relocation Modeling

We use the PEPA model [START_REF] Hillston | Performance Evaluation Process Algebra (PEPA)[END_REF] to express and simulate the activities and behavior of system components in a service migration and relocation process. PEPA introduces delays and probabilistic occurrences to process algebras. The timing behavior of a system is quantified by associating a random variable with each activity, which represents its duration. Behavior uncertainty is determined by probabilistic branching -the probabilities of occurrence of some activities are determined by race conditions between the enabled activities. The model represents service migration and relocation activities as stochastic actions that are non-deterministic and whose occurrence or non-occurrence are predicted by one or more random variables (i.e., activity rates).

Figure 2 shows the PEPA model representing a system SYS. The system SYS is modeled in terms of interactions between the service migration and relocation components (i.e., a migrating scheduler, a platform supporting a critical service and a relocation manager) and the damage recovery components (i.e., a fault diagnosing agent and a damage repairer). The model has eleven processes (components) representing the entire procedure for service S j to migrate from a compromised platform P i to a new platform P k and relocate from P k to P i after P i has recovered. The model also includes the recovery procedure of the compromised component. The PEPA processes and their activities are described below.

Process Execution i j models the behavior of platform P i where service S j is executed. It either executes normally or needs to be investigated if the intrusion detection system (implicitly modeled) reports suspicious (or abnormal) behavior. Correspondingly, P i behaves either as (monitor anomaly, p 1 ).(alarm, al) .Contingency i or (monitor normal, p 2 ).(executing i j , f ).Execution i j in the PEPA model. The former describes the situation where the system reports damage symptoms (represented by the PEPA activity monitor anomaly). In this case, an alarm is trigged (represented by the PEPA activity alarm) and P i enters a contingency state (represented by the PEPA process Contingency i ), where the symptoms are further analyzed. The latter represents the case when no abnormal symptom is detected (represented by the PEPA activity monitor normal). Therefore, S j is continuously executed on P i (represented by executing i j ). The probabilities of occurrence of the two cases are denoted by p 1 and p 2 , respectively. In our model, monitor anomaly and monitor normal have default activity rates of one; alarm and executing i j have the rates al and f , respectively, indicating that the two activities have durations that are negatively exponentially distributed with parameters al and f , respectively. The probabilities that alarm and executing i j occur within a period of time length t are 1e -al * t and 1e -f * t , respectively. The PEPA process Contingency i represents the investigation of platform P i for advanced analysis given the reported suspicious behavior. Based on the investigation results, Contingency i behaves either as (investigate damaged, (it * p 3 )).(recovery notif y i , tt).M igration M anager or (investigate self contain, (it * p 4 )).Execution i j . In the first case, the investigation reveals that P i is severely damaged (represented by the PEPA activity investigate damaged). Thus, a recovery notification (recovery notif y i ) is sent to Recovery M anager in order to arrange for P i to recover. Furthermore, the system starts the service migration process (represented by the PEPA process M igration M anager) to move the critical service S j executing on P i to a new, healthy platform. In the second case, the damage is not severe and the system can self-contain or mask the damage without disrupting S j (represented by investigate self contain). Therefore, the workflow transits back to the normal execution of S j on P i , i.e., Execution i j . The probabilities of the two investigation results are denoted by p 3 and p 4 , respectively. The activity rate it probabilistically determines the duration of the investigation procedure, i.e., the probability that the investigation is completed within a period of time t is 1e -it * t .

Executioni_j (monitor_anomaly, p1).(alarm, al).Contingencyi + (monitor_normal, p2). (executingi_j, f).Executioni_j

Service migration is modeled using three processes: M igration M anager, M igration Scheduler and M igration i k . M igration M anager initializes the migration procedure by halting service S j on P i (represented by the PEPA activity halting i j with a rate h). M igration Scheduler represents the behavior of the migration scheduler, which identifies a new platform P k , if one exists, and arranges for S j to migrate to P k . The scheduling process takes an amount of time that is negatively exponentially distributed with parameter st. As discussed earlier, the new platform must be capable of providing the functions required by S j and in the meantime be immune to the same types of attacks that compromised platform P i .

The scheduling process yields one of two possible results: (i) a suitable platform P k is identified (represented by the PEPA activity schedule ok) with probability p 5 ; and (ii) no P k is available given the current system resources (represented by schedule f ailure) with probability p 6 . For the first case, the actual migration can start as represented by the PEPA process M igration i k . M igration i k engages three activities m P re, m T r and m Su, which correspond to migration preparation, service and data transfer, and setup on the new platform P k , respectively. Their corresponding PEPA activity rates are m 1 , m 2 and m 3 . However, if the scheduling process does not identify a suitable P k , then the workflow returns to M igration Scheduler for rescheduling (hopefully a suitable platform will be available the next time).

The PEPA process Execution k j represents the execution of service S j on the new platform P k . Depending on whether the compromised platform P i has recovered or not, P k behaves differently. As discussed above, S j has to be relocated when P i has recovered. The first behavior of the process Execution k j , i.e., (recovery check ok, p 7 ).(recovered i , T ).Relocation M anager covers this case with a probability p 7 when the status of P i is periodically checked (recover y check ok). Indeed, in this case, P k synchronizes with the Recovery M anager through the activity recovered i . This activity has an unspecified rate (denoted by T and is determined by the repair notification rate rp when the two processes Execution k j and Recovery M anager are synchronized). Then, the system starts the relocation process Relocation k i , which moves S j to its original platform P i . Relocation k i engages three activities r P re, r T r and r Su. The second behavior of Execution k j , i.e., (recovery check pending, p 8 ).(executing k j , f ).Execution k j represents the continuous execution of S j on P k given the condition that P i is still being repaired (represented by the PEPA activity recovery check pending). The probability of this case is represented by p 8 . In terms of time, S j is executed on P k (represented by executing k j ) for a duration that is negatively exponentially distributed with a parameter f before the process returns to Execution k j for the next cycle of repair checking.

The damage recovery subsystem of SYS is modeled by three PEPA components: (i) Recovery M anager, a coordinator that waits for a recovery notification (represented by recovery notif y i ) and then starts a recovery process; (ii) Recovery i , a local agent responsible for recovering platform P i ; it first performs fault diagnosis on P i (represented by the PEPA activity diagnose with a rate dt) and then develops a plan for repair; and (iii) Repairer, a component responsible for the actual repair of P i . System repair is application-specific and can take various forms, e.g., system restoration, check pointing and rollback, and re-programming. Given the diagnosis information, P i may be successfully repaired (represented by repair success) with probability p 9 or repair is not possible (represented by the activity repair f ail) with probability p 10 . In the first case, the workflow returns to the PEPA process Recovery M anager, indicating that the damage recovery system has completed the recovery of P i and is waiting for the next recovery request. In the second case, since the repair attempt has not resulted in successful repair, further diagnosis is necessary. Therefore, the workflow returns to Recovery i for more diagnostic information about the cause and nature of the damage on the promised platform.

Finally, the service migration and relocation enabled system SYS is modeled using the PEPA cooperation operator Execution i j ◃▹ L Recovery M anager (where L = {recovery notif y i , recovered i }) to represent the concurrent interactions of the execution of service S j on platform P i , and the damage recovery activities in the case of severe damage to P i , via synchronized participation in the events Recovery notif y i and recovered i . While a severe damage event triggers the service migration process, a successful repair results in the migrated service being moved back to the original platform.

Simulation Results and Analysis

The PEPA model presented in this paper was solved using the PEPA Eclipse plug-in software [START_REF] Hillston | Performance Evaluation Process Algebra (PEPA)[END_REF]. The activity rates used in the model are shown in Table 1. A Bayesian network decision model was used to determine the activity rates. Due to space limitations, the Bayesian network model is not presented in this paper.

Overview

We conducted several rounds of simulations for steady-state, utilization, passage-time, throughput and experimental analysis in order to study how the important factors influence the effectiveness and efficiency of service migration and relocation.

In order to run the PEPA simulation, the system states corresponding to the underlying continuous time Markov processes were derived and the probability of the system at each state was generated. The PEPA model incorporated 33 The system activities were represented as non-deterministic stochastic actions whose occurrence or non-occurrence were predicted by one or more random variables. The system SYS was modeled in terms of interactions between the service migration and relocation components and the damage recovery subsystems. The interactions reached a set of steady states after an extended execution time. The term "steady state" means that there was a statistically determined possibility that the system remained in the state.

Our simulations showed that the PEPA states with dominating steady-state probabilities were associated with the two local states executing i j .Execution i j (0.891) and Recovery M anager (0.981). This was also observed in our utilization analysis, which showed the long-run utilization of each top-level process in the PEPA model. More precisely, the percentage of time that a top-level component Execution i j (resp. Recovery M anager) was in the local state executing i j .Execution i j (resp. Recovery M anager) was 0.891 (resp. 0.981). Since executing i j .Execution i j represents the normal execution of service S j on its original platform P i , maximizing the utilization of this state is the objective of an efficient service migration and relocation process. Therefore, in the following discussion, we focus on how the important factors influence the utilization of executing i j .Execution i j . This utilization rate is denoted by p.

The activity throughput was also studied in the simulations. The throughput analysis yielded the rate at which PEPA actions were performed at steadystate. The two PEPA activities with the highest throughputs were executing i j (0.09) and monitoring normal (0.09). The former indicates that service S j was executing on platform P i and, hence, a higher value is more desirable. The latter indicates that the intrusion detection system reported normal system operations in most cases (i.e., no suspicious behavior was detected). Just as the steady-state analysis focused on the local state executing i j .Execution i j , the throughput of executing i j represented the desired behavior of S j on P i ; therefore, it is another metric of interest.

Simulation Results

We executed the PEPA model with parameter values in the desired ranges. The experiments were designed to study how system security and functional factors affect the utilization rate of executing i j .Execution i j , i.e., p and the throughput of executing i j as mentioned above.

We started with the two factors determined by the security features of system SYS: (i) probability of anomaly detection on a platform P i (p 1 ) in an intrusion detection reporting cycle; and (ii) probability that the detected damage is severe (p 3 ). Intuitively, if a system has strong security mechanisms and the ability to contain and mask potential damage, then the need for the critical services to migrate from their normal executing platforms is low. Hence, the utilization of executing i j .Execution i j should be higher. The experimental results confirmed this observation. Figure 3 shows the utilization of executing i j .Execution i j for different p 1 and p 3 values. In particular, it shows that p decreases when p 1 and p 3 increase. This clearly indicates that a higher compromise rate for a platform decreases the amount of time that the platform effectively supports the critical services. Furthermore, the quantitative relationship between p and p 1 is roughly linear given a fixed p 3 rate. This implies that a significant improvement in system security results in an almost equal increase in the normal execution of critical services on their original platforms. A similar pattern is observed in Figure 4 for the throughput of executing i j for different p and p 3 values.

As discussed earlier, the migration manager is responsible for halting a critical service on a compromised platform, scheduling and arranging a new platform for service migration, moving the data and program space of the service to the new platform, and finally setting up the service on the new platform. In the meantime, the recovery manager diagnoses the faults and attempts to repair the compromised platform. The performance of these two system components clearly affects service migration. Figures 5 and6 show that a higher probability of a successful migration-scheduling rate (i.e., p 5 ) and a higher probability of a successful repair of a compromised platform (i.e., p 9 ) positively affect the utilization of executing i j .Execution i j (i.e., p). This indicates that effective damage recovery and the availability of healthy platforms increase the overall efficiency of service migration, which, in turn, increases the percentage of time that critical services are executed on their normal platforms. However, Figure 6 shows that p becomes stable after p 5 reaches a certain value (0.1 in our simulation). This means that any further improvement in migration scheduling will not improve p significantly. Therefore, migration scheduling is not a significant bottleneck for executing i j .Execution i j beyond this point.

Next, we examine how the time required to halt a critical service on a compromised platform and the time required to repair the compromised platform affect the utilization of executing i j .Execution i j . Figure 7 shows that when less time is taken to repair a compromised platform (i.e., higher value of l), the probability that S j is executed on platform P i is higher. Similarly, the simulation shows that a shorter duration for halting S j on P i (i.e., higher value of h) and a shorter duration for migration scheduling to move S j to a new platform P k (i.e., higher value of st) both result in a higher value of p. However, both results indicate that the effects of h and l on p are not significant beyond certain points. This implies that further investments in halting and repairing mechanisms may not significantly increase the probability that critical services are executed on their normal platforms.

Passage-Time Analysis

We also conducted various passage-time analyses, i.e., the distribution of the probabilities that a second event occurs after a given event within a time duration. Figure 8 shows the passage-time analysis results of detecting abnormal symptoms (monitor abnormal) relative to service halting (halting i ). The results reveal that the occurrence probability of halting service S j on P i (i.e., halting i ) increases with time relative to the event where P i is detected as damaged.

The passage-time analysis results in Figure 9 show that the probability of P i being repaired (i.e., recovered i ) increases with time relative to the event that S j executes on the new platform P k (i.e., SU k j ). In particular, it is almost certain that the compromised platform P i will be repaired within about 30 time units after SU k j .

Conclusions

Service migration and relocation is an effective mechanism for dynamically transferring mission-critical services from a compromised platform to other clean, healthy platforms to ensure that mission-critical services are provided continuously. Service migration is crucial in situations where other security and fault tolerance approaches are infeasible or expensive. In these situations, service migration and relocation is a viable solution for minimizing the impact of malicious attacks and system failures. The process-algebra-based modeling framework presented in this paper provides a foundation for studying how important factors can influence the effectiveness and efficiency of service migration and relocation in mission-critical systems.

Figure 1 .

 1 Figure 1. Workflow of a service migration and relocation process.

Figure 2 .

 2 Figure 2. PEPA model of service migration and relocation.

Figure 3 .

 3 Figure 3. Utilization of executingi j .Executioni j (p1 and p3 values).

Figure 4 .

 4 Figure 4. Throughput of activity executingi j (p1 and p3 values).

Figure 5 .

 5 Figure 5. Utilization of executingi j .Executioni j (p5 values).

Figure 6 .

 6 Figure 6. Utilization of executingi j .Executioni j (p9 values).

Figure 7 .

 7 Figure 7. Utilization of executingi j .Executioni j (l values).

Figure 8 .

 8 Figure 8. Detection of abnormal symptoms relative to service halting.

Figure 9 .

 9 Figure 9. Service setup on a new platform relative to completion.

Table 1 .

 1 Parameter settings for the PIPA model. Execution i j had seventeen local states while Recovery M anager had four states.

	Parameter Value Explanation
	p1	0.001	Probability that an anomaly is detected on platform Pi
	al	0.5	Alarm on Pi is fired for two time units
	p2	1 -p1 Probability that the intrusion detection system reports
			normal activities
	it	0.1	Investigation of Pi takes ten time units upon triggering
			an alarm
	f	0.1	Sj is executed on Pi for ten time units before the next
			intrusion report
	p3	0.1	Probability that Pi is severely damaged
	tt	1	Repair notification to the Recovery M anager takes one
			time unit
	p4	1 -p3 Probability that the damage is not severe and Pi can
			contain the damage
	h	0.2	Service Sj takes five time units to be halted appropriately
	st	0.3	Migration scheduling takes about 3.3 time units
	p5	0.8	Probability that a new platform P k is identified for Sj to
			migrate
	p6	1 -p5 Probability that no suitable platform is available for Sj
			to migrate
	m1	0.25	Migration preparation takes four time units
	m2	0.5	Data and service transfer to the new platform P k takes
			two time units
	m3	0.2	Setting up service Sj on P k takes five time units
	p7	0.01	Probability that Pi has recovered while Sj is executing
			on P k
	p8	1 -p7 Probability that Pi still has to recover
	r1	0.25	Relocation preparation takes four time units
	r2	0.5	Data and service transfer back to the repaired Pi takes
			two time units
	r3	0.1	Setting up service Sj on Pi takes five time units
	dt	0.1	Diagnosing the nature of the damage to Pi takes ten time
			units
	l	0.001	Attempting to repair Pi takes 1,000 time units
	p9	0.6	Probability that Pi can be successfully repaired
	p10	1 -p9 Probability that Pi cannot be repaired (new diagnosis is
			necessary)
	rp	1	Sending a repair completion notification to P k takes one
			time unit
	global states. Since the model had two top-level PEPA processes, Execution i j
	and Recovery M anager, a global state had two elements, one for each local
	state of the corresponding top-level processes. The simulation revealed that

Acknowledgement

This research was supported by the U.S. Air Force Office of Scientific Research under Award No. FA9550-12-1-0131.


Antonio Di

Chiara Foglietta

Simone Palmieri

Stefano Panzieri

ASSESSING THE IMPACT OF CYBER ATTACKS ON INTERDEPENDENT PHYSICAL SYSTEMS

Keywords: Cyber attacks, SCADA systems, impact assessment, testbed

Considerable research has focused on securing SCADA systems and the physical processes they control, but an effective framework for the realtime impact assessment of cyber attacks on SCADA systems is not yet available. This paper attempts to address the problem by proposing an innovative framework based on the mixed holistic reductionist methodology. The framework supports real-time impact assessments that take into account the interdependencies existing between critical infrastructures that are supervised and controlled by SCADA systems. Holistic and reductionist approaches are complementary approaches that support situation assessment and evaluations of the risk and consequences arising from infrastructure interdependencies. The application of the framework to a sample scenario on a realistic testbed demonstrates the effectiveness of the framework for risk and impact assessments.

Introduction

The risk of cyber attacks that can compromise the operation of critical infrastructures such as electricity and water distribution systems has increased due to network connectivity and convergence, strong attacker motivation and expertise, and the use of general-purpose and open communication protocols for communications and control. Evaluating the impact of cyber attacks is a complex task due to intra-system interactions and interdependencies. Moreover, interactions between infrastructure components and the infrastructures themselves lead to cascading effects are difficult to model and evaluate.

Supervisory control and data acquisition (SCADA) systems are employed widely in the critical infrastructure to control physical processes. However, SCADA systems rely heavily on information and communications technologies (ICTs); these technologies exhibit numerous vulnerabilities that can be exploited by cyber attacks, especially those involving malware such as viruses and worms. The often-cited Stuxnet worm [START_REF] Falliere | Stuxnet Dossier, Symantec[END_REF] that targeted SCADA systems was able to alter the behavior of programmable logic controllers (PLCs). Indeed, despite the adoption of security policies, firewalls and intrusion detection systems across the critical infrastructure, SCADA systems and their networks remain vulnerable as a result on their ICT layer. For these reasons, all impact assessments of faults should also consider cyber attacks [START_REF] Digioia | Mixed holistic reductionistic approach for impact assessment of cyber attacks[END_REF].

Several research efforts have focused on developing simulation environments that evaluate the impact of malware on critical infrastructure systems. The possibility of modeling and performing cyber attacks in a controlled simulation environment allows SCADA operators to develop and test security standards with the aim of preventing and/or reducing the impact of attacks on physical processes. Due to the difficulty -and danger -involved in performing security tests on real-world SCADA systems [START_REF] Queiroz | Building a SCADA security testbed[END_REF], SCADA security researchers typically employ hybrid simulation environments that integrate commercial software used in real SCADA systems and simulated components that emulate SCADA networks and devices (e.g., routers and PLCs).

However, most SCADA security testbeds are incapable of modeling and simulating critical infrastructure interdependencies [START_REF] Foglietta | Online distributed evaluation of interdependent critical infrastructures[END_REF]. This paper attempts to overcome this limitation. It describes a SCADA security testbed that engages infrastructure interdependency models in performing impact assessments. The approach seeks to provide SCADA operators with qualitative and quantitative measurements of (near-term) future risk to reduce the decision-making time and effort, and to improve the outcome. The approach is based on the mixed holistic reductionist (MHR) model [START_REF] De Porcellinis | A holisticreductionistic approach for modeling interdependencies[END_REF][START_REF] De Porcellinis | Modeling critical infrastructure via a mixed holistic reductionistic approach[END_REF], a general formalism that can describe large, complex systems like critical infrastructures and with their interdependencies and the impact of faults. MHR employs CISIA [START_REF] De Porcellinis | Simulation of heterogeneous and interdependent critical infrastructures[END_REF], an agent-based system for modeling and simulating interdependencies. CISIA models each physical component as an agent that exhibits: (i) an operative level, which is defined as the ability to perform the required task; (ii) a set of resources needed by the component to operate; and (iii) a set of faults that can affect the component. The MHR approach has been validated by research conducted under the EU FP7 MICIE Project [START_REF]MICIE, Selex Communications[END_REF]. It is currently being used in the EU FP7 CockpitCI Project [START_REF]The CockpitCI Project, CockpitCI, Selex Systems Integration[END_REF] to investigate the real-time impact of cyber attacks on the quality of service (QoS) delivered by targeted critical infrastructure assets.

Related Work

This section discusses research efforts related to SCADA security testbeds and models for analyzing critical infrastructure interdependencies.

Queiroz, et al. [START_REF] Queiroz | Building a SCADA security testbed[END_REF] have designed a testbed for investigating attacks that affect system functionality. The testbed, which is based on a real SCADA network, incorporates a human-machine interface (HMI), remote terminal units (RTUs), and sensors and actuators connected to a corporate network over the Internet. McDonald, et al. [START_REF] Mcdonald | Cyber Effects Analysis Using VCSE, Promoting Control System Reliability[END_REF] have developed a testbed based on a customized simulation framework for analyzing the interactions between a physical process, control devices and a SCADA network. Genge, et al. [START_REF] Genge | Analyzing cyberphysical attacks on networked industrial control systems[END_REF] have developed a network emulator environment, which simulates the cyber layer of a SCADA system (e.g. RTUs and process control software) that controls a simplified water purification plant modeled using Matlab. The environment allows the evaluation of the consequences of cyber attacks on the physical process.

In the area of interdependency modeling, Ghorbani, et al. [START_REF] Ghorbani | The state of the art in critical infrastructure protection: A framework for convergence[END_REF] have presented a classification and comparison of interdependency modeling and simulation tools for critical infrastructures. The Interdependency Infrastructure Simulator (I2Sim) [START_REF] Rahman | I2Sim: A matrixpartition based framework for critical infrastructure interdependencies simulation[END_REF] provides a power simulation environment that models interdependencies between critical infrastructures based on resource requirements and distribution. The core component of I2Sim is a production cell, a functional unit that needs a certain quantity of one or more input resources to produce an output resource. The production cell is associated with a matrix called the human readable table, which encapsulates the behavior of the modeled component by associating input quantities with output quantities. Hierarchical holographic modeling (HHM) [START_REF] Haimes | A hierarchical-multiobjective framework for risk management[END_REF] facilitates the modeling of complex systems at different levels, including the physical, organizational and managerial levels. HHM has been applied to SCADA systems to evaluate the risk of cyber attacks on controlled critical infrastructures [START_REF] Ezell | Risks of cyber attack to water utility supervisory control and data acquisition (SCADA) systems[END_REF].

Agent-based models developed for analyzing complex systems can be applied to critical infrastructure protection. These include NetLogo [START_REF] Tisue | Netlogo: A simple environment for modeling complexity[END_REF], a multi-agent programming language and modeling framework used to analyze natural and social science phenomena. Another framework is RePast [START_REF] Collier | RePast: An extensible framework for agent simulation[END_REF], which uses genetic algorithms and neural networks to model the behavior of concurrent agents. Yet another is SimJADE [START_REF] Gianni | Bringing discrete event simulation concepts into multi-agent systems[END_REF], a multi-agent framework based on discrete event simulation that supports generic interaction protocols for agent communications.

Existing SCADA security testbeds have been employed to study the impact of cyber attacks on physical processes, but they do not employ infrastructure interdependency models to evaluate the real-time cascading effects. In contrast, our testbed specifically incorporates interdependency models. This helps evaluate how cyber attacks on SCADA systems can induce cascading effects on interdependent physical processes (e.g., physical and cyber [START_REF] Nieuwenhuijs | Modeling dependencies in critical infrastructures[END_REF]).

This work has been undertaken under the FP7 CockpitCI Project [START_REF]The CockpitCI Project, CockpitCI, Selex Systems Integration[END_REF]. The project seeks to improve the dependability and resilience of critical infrastructures by providing operators with efficient tools that help prevent cyber attacks and implement consequence containment strategies in the event of attacks. The CockpitCI Project is a follow-up to the MICIE Project [START_REF]MICIE, Selex Communications[END_REF] that focused on the creation of a distributed alert system for the early detection of cascading physical faults. The alert system to be developed under the CockpitCI Project will: (i) incorporate smart detection agents that monitor potential cyber threats in various networks (e.g., SCADA and IP networks); (ii) identify in real-time the critical infrastructure functionality that is impacted by cyber attacks and assess the degradation of the delivered services; (iii) broadcast alert messages to other critical infrastructures at different security levels; and (iv) support containment strategies that address the consequences of cyber attacks in the short, medium and long terms.

SCADA Testbed Architecture

The SCADA security testbed engages a typical client-server SCADA network architecture, which incorporates PLCs, RTUs, intelligent electrical devices (IEDs) and an HMI. Two key components are an integrated risk predictor system (IRP) and a set of intrusion detection systems (IDSs). These two components support the evaluation of the impact of cyber attacks on the physical components controlled by the SCADA system. The SCADA network spans two laboratories, one located at the University of Roma Tre and the other at ENEA, also in Rome, Italy. The distribution of SCADA network nodes over the Internet helps model the large geographic scale of real-world SCADA systems.

Figure 1 shows the reference architecture of the SCADA security testbed. The architecture incorporates the following components:

Process Control Network: This network serves as the connection layer for the SCADA equipment. A database (DB PCN) stores information about field equipment. An HMI provides operators with a facility for visualizing data and information. The data and information can be accessed by other operators via an open platform communications (OPC) server as well as by the IRP, which performs a situation assessment by computing the risk level associated with the state of the considered critical infrastructure and evaluating the impact of cyber attacks. Cyber attacks are detected using IDSs associated with the critical infrastructures and relayed to the network (IDS PCN) whose output is merged into the IRP.

Field Network: This network includes sensors, actuators (IEDs) and RTUs, and supports the acquisition of process field data and the execution of control actions. Two IDSs (IDS L1 and IDS L2), one at each laboratory, monitor traffic directed at the RTUs, perform local cyber attack detection and notify the IRP about possible malicious activity to enable it to support global risk assessments. An attacker is assumed to be located in this network and can launch attacks that compromise SCADA system functionality.

Communication Networks: This network uses the Internet to connect the process control and field networks.

4.

Integrated Risk Predictor Architecture Mixed Holistic Reductionist Unit: This unit performs the real-time impact analysis of faults and cyber attacks on a set of critical infrastructures through the execution of an agent-based model. The model represents a network of heterogeneous systems that exhibit interdependencies. The MHR model captures critical infrastructures at different hierarchical levels: holistic, reductionist and service layers. For each critical infrastructure, agents are used to model the production, supply and transportation (or consumption) of tangible or intangible resources: goods, policies, operative conditions, etc. The capability of each agent to provide the required resources depends on its operative condition, which is based on the availability of the resources that it requires and on the severity of the failures that affect it. The F-ACQ and T-ACQ units provide the MHR model with real-time information about failures and attacks, respectively.

Failure Acquisition Unit: This unit extracts information about physical device failures from the real-time data provided by the SCADA database. The set of failures and the measurement values are input to the MHR unit to help conduct real-time impact assessments of the considered critical infrastructures. The F-ACQ unit translates the data into an appropriate format for input to the MHR unit.

Threats Acquisition Unit: This unit collects real-time data from the set of IDSs that provide local and global cyber attack detection assessments. The data includes log data and alert messages produced when malicious attacks are detected. This unit, like the F-ACQ unit, translates data into an appropriate format for input to the MHR unit. Communications between the T-ACQ unit and the IDSs are handled using web service technology: each IDS hosts a web service that accepts requests from web clients hosted by the T-ACQ unit.

OPC Client: The OPC client queries real-time data from the SCADA database (DB PCN) at a fixed rate. This data, which includes equipment faults and failures and measurement values, is passed to the F-ACQ unit.

Impact Visualization Interface:

This unit provides the operator with a graphical user interface (GUI) that shows the real-time status and the predicted impact of failures and attacks on the considered critical infrastructures.

IRP Database: This unit stores the results of MHR model executions. The MySQL database incorporates a historian that maintains all the data for offline analyses.

MHR Modeling

The mixed holistic reductionist (MHR) approach supports the modeling and evaluation of interdependencies existing between critical infrastructures. Interdependency identification relies on the interaction of two different approaches, holistic and reductionist methods.

Holistic models focus on a single critical infrastructure and the evolution of an event within the critical infrastructure, ignoring events in other infrastructures. These models are usually created in collaboration with sector experts and embed complex dynamics related to the single infrastructure (e.g., transient behavior of a power grid when a breaker is opened). In contrast, reductionist models capture elements of multiple critical infrastructures in order to model interdependencies existing between the infrastructures.

Figure 3 shows the MHR modeling technique. The upper boxes represent the holistic approach for two interdependent infrastructures. A situation as- sessment at this level of abstraction is realized by considering several technological and organizational aspects and using techniques and methods specific to each infrastructure. In this context, important services directed towards customers are defined along with the possible impacts due to endogenous faults and threats. An example is the detection of possible cyber attacks on a telecommunications network and the evaluation of the effects on the network. The lower boxes model the reductionist approach, which evaluates interdependencies and propagates faults. At this level, the evaluation of cyber attacks on real equipment is considered, including the equipment responsible for interdependencies such as remote-controlled circuit breakers and switches in a power grid.

Attack Scenario

This section focuses on a scenario involving a cyber attack on the reconfiguration service of a power grid, which is controlled by a SCADA system. The scenario incorporates three infrastructures: a medium voltage power grid controlled by a SCADA system via a telecommunications network that connects the control center with the RTUs. Each RTU incorporates a modem connected to a switch; it receives and transmits data in order to open or close the switch. The Modbus/TCP protocol is used for RTU communications. Control actions are implemented by a PLC connected to the HMI. Figure 4 shows the data workflow starting from an attack occurrence to attack impact assessment.

The impact evaluation focuses on the effects of faults and cyber attacks on the services provided by the coupled infrastructures. Note that the services include those supplied to customers (e.g., electricity) as well as those that enable each critical infrastructure to be reconfigured.

Attack Execution

The scenario involves a man-in-the-middle attack by an attacker located in the process control network or at one of the two laboratories connected to the field devices (see Figure 1). The attacker can eavesdrop on the messages between the two hosts as well as modify messages to send fake data to a host. The man-in-the-middle attack exploits a vulnerability in the address resolution protocol (ARP). The attack is commonly referred to as ARP poisoning (spoofing). The attack was performed using Ettercap [START_REF]The Ettercap Project[END_REF], a packet injector that manipulates ARP tables, enabling the attacker to compromise an RTU (e.g., by manipulating a message or sending fake commands to the RTU).

Attack Identification

The TCP layer of the Modbus/TCP protocol provides a sequence number that is unique for each session. However, as described in [START_REF] Gao | On SCADA control system command and response injection and intrusion detection[END_REF], Modbus only accepts the first response received and discards additional responses.

We used Snort as an IDS to detect ARP attacks, unicast ARP requests and inconsistent Ethernet-IP address mappings. In particular, Snort was configured to detect changes in the mappings between valid MAC addresses and IP addresses in order to detect ARP poisoning attacks originating from the SCADA network.

The T-ACQ unit acquires data from the IDSs while the F-ACQ unit acquires data from the real equipment (e.g., HMI). Web service technology is used for connections between the T-ACQ unit and the IDSs: each IDS represents a server and the T-ACQ unit is the client that "polls" the servers to obtain updated information. The connections between the F-ACQ and the real equipment are realized using the OPC client/server architecture.

The T-ACQ and F-ACQ outputs are passed to the MHR model (Figure 5). The outputs of the two units are in the form of XML files with the same structure for both units. A specific XML element specifies the attack type and another element represents the severity of the attack.

MHR Model Execution

The MHR model was realized using the CISIA agent-based software [START_REF] De Porcellinis | Simulation of heterogeneous and interdependent critical infrastructures[END_REF]. The CISIA software models every element (equipment, service, policy or entity) as an agent using a common representation. Each agent is described by its inputs and outputs. Agents exchange resources, such as telecommunication packets, power flows and service levels. Agent behavior is affected by faults and failures. The internal representations of agents may be heterogeneous; however, the coupling of the agents with several internal models is achieved using a common exposed interface. Each agent is represented by its operative level or operativeness, the ability of the agent to produce goods and services.

The CISIA simulator uses triangular fuzzy numbers to handle uncertainty. A triangular fuzzy number is expressed using four (crisp) numbers: left, middle, right and height values.

Figure 5 shows the principal agents in the MHR model implementation. Three holistic nodes are shown, one for each critical infrastructure. The services are shown as purple boxes: the quality of service for customers of the telecommunications network and power grid, the automatic telecommunications reconfiguration procedure, and the reconfiguration of the power grid related to the SCADA network and the power reconfiguration topology. The reconfiguration of the power grid needs the SCADA network and the telecommunications network in order to send and receive messages to and from switches via the RTUs. The reconfigured topology of the electric grid is determined based on the ability of each line to feed customers after a power fault. The main objects in the reductionist layer are the telecommunications network routers, the SCADA control center and RTUs, and the switches, breakers and substations in the power grid. To simplify the presentation, Figure 5 does not show the other elements and agents.

Impact Evaluation

A man-in-the-middle attack can have several outcomes. Surveillance attacks collect information about the SCADA system and RTUs and the messages they exchange, or they read requests issued by the HMI to RTUs. More serious attacks modify reply messages (e.g., randomly or using a "NOT" operator, which would close a circuit breaker instead of opening it). Other attacks change messages transmitted between the HMI and RTUs. These attacks can compromise the functionality of the SCADA system by altering the control strategy and ultimately affecting the physical system.

The implemented attack changes the values of messages sent from the HMI to the RTUs, which are connected to circuit breakers and switches. Figure 6(a) shows the behavior of an RTU under attack (computed using CISIA). The behavior exhibits an exponentially-decreasing trend starting at the attack start time (t = 10). Note that the RTU should execute commands from the HMI only in the event of a fault in the power grid.

The reconfiguration service in the power grid involves operator-initiated procedures that change the topology of the power grid after a fault has occurred. Figure 7 shows the operator panels, which present the system behavior to operators in a simple and effective manner. The panels show system snapshots with the possible impact in the near future using colored circles to express the severity of equipment faults.

The operative level of each element is specified using a red cross if the element is not working (e.g., a load in Figure 7(b)). A circle near an element denotes the prediction of its operative level during the next iteration. Note that S denotes a small time prediction (during the next step), M a medium time prediction (during two time steps) and L a large time prediction (during three time steps).

Conclusions

The experimental testbed described in this paper supports real-time impact assessments of cyber attacks on interdependent critical infrastructures. The sample scenario focused on the evaluation of the impact on services provided by a SCADA system that controls a power grid. The physical layer and the services provided by the two infrastructures were modeled using the CISIA agent-based tool. The experimental results involving a man-in-the-middle attack on a SCADA RTU demonstrate the utility and effectiveness of the testbed as a means for providing infrastructure operators with the current status as well as the predicted impact on key infrastructure components and services.

Our future research will continue to refine the testbed and the modeling framework. Also, it will investigate more complex attacks on interdependent critical infrastructures, including stealth attacks that modify packet content in SCADA-RTU communications.

Figure 1 .

 1 Figure 1. SCADA testbed architecture.

Figure 2 .

 2 Figure 2. Integrated risk predictor architecture.

Figure 2

 2 Figure 2 presents the modular structure of the IRP. The IRP has six main components: (i) mixed holistic reductionist (MHR) unit; (ii) failure acquisition (F-ACQ) unit; (iii) threats acquisition (T-ACQ) unit; (iv) OPC client; (v) impact visualization (IMP-VIS) interface; and (vi) IRP database (DB IRP).

Figure 3 .

 3 Figure 3. Mixed holistic reductionist modeling technique.

Figure 4 .

 4 Figure 4. Attack scenario data workflow.

Figure 5 .

 5 Figure 5. Infrastructure interdependency model.

  (a) RTU involved in the attack. (b) Reconfiguration service in the power grid.

Figure 6 .

 6 Figure 6. CISIA operative levels.

Figure 7 .

 7 Figure 7. Operator panels for the SCADA network and power grid.

  These procedures are implemented by the HMI sending commands to selected RTUs to open or close switches. The reconfiguration procedures cannot be executed if one or more RTUs are affected by the attack. Figure 6(b) shows the operative level of the power grid reconfiguration service. Note that in Figures 6(a) and 6(b), three values (i.e., left, middle and right values) are used to represent triangular fuzzy numbers. The y-axis values are between 0.7 and 1.0; the height values are not shown because these values are always equal to 1.0.

Acknowledgement

This research was partially supported by EU Project Cockpit-CI FP7-SEC-285647/2012.


Richard Chow

Alvaro Cardenas

Emiliano De Cristofaro

DATA HANDLING IN THE SMART GRID: DO WE KNOW ENOUGH?

Keywords: Smart grid, data handling, privacy

Data privacy in the smart grid is an important requirement for consumers. Central to the data privacy issue is the handling of energyusage data, in particular, data retention, aggregation and anonymization. Government and industry groups have formulated various policies in this area, mostly based on fair information practice principles. This paper argues that the current policy-level work is insufficient -scientific work is needed to fully develop and implement privacy policies. A research agenda is proposed that balances the advantages of fine-grained energy-usage data with the associated privacy risks. For comparison purposes, the paper describes analogous policies and implementations related to telecommunications, web search and medical data.

Introduction

The smart grid is being designed to enable utilities, customers and thirdparty providers to monitor and control energy use. Data collected by the smart grid will provide several advantages to all parties, including better decisions regarding energy-usage, enhanced understanding of consumer demands and increased energy distribution efficiency.

The smart grid also raises the issue of data privacy -especially for consumers -because smart meters will allow large-scale data collection, making individual household data available at unprecedented levels of granularity. Monitoring energy consumption at low levels of granularity can facilitate the inference of detailed information about consumer behavior. The behavioral information is highly valuable to advertising companies, law enforcement and criminals. The potential for egregious invasions of personal privacy makes it imperative to ensure that proper controls are in place.

Responding to these concerns, governments and standards organizations are developing privacy standards and policies to guide smart grid deployments.

Recommendations for privacy controls in smart grid deployments have been provided by the North American Energy Standards Board (NAESB) [START_REF] Varela | NAESB is developing smart grid data privacy standards[END_REF], National Institute of Standards and Technology (NIST) [START_REF]Smart Grid Interoperability Panel -Cyber Security Working Group[END_REF], U.S. Department of Energy (DOE) [START_REF]Data Access and Privacy Issues Related to Smart Grid Technologies[END_REF], Texas Legislature and Public Utility Commission [START_REF]Public Utility Commission of Texas, Electric Substantive Rules -Chapter 25[END_REF] and California Public Utilities Commission (CPUC) [START_REF]Decision Adopting Rules to Protect the Privacy and Security of the Electricity Usage Data of the Customers of Pacific Gas and Electric Company, Southern California Edison Company and San Diego Gas and Electric Company[END_REF], among others. The Smart Grid Policy Framework [START_REF]A Policy Framework for the 21st Century Grid: Enabling Our Secure Energy Future[END_REF] released in 2011 by the Executive Office of the President specifically recommends that, as a starting point, state and federal regulators must consider methods to ensure that detailed energy-usage data is protected in a manner consistent with the fair information practice principles drafted by the Federal Trade Commission (FTC) [START_REF]Federal Trade Commission, Fair Information Practice Principles[END_REF].

Recent work in the area of smart grid privacy has been necessarily broad in its coverage of systems and use cases. This paper concentrates on the handling of energy-usage data. Data handling issues cut across multiple privacy use cases and include data retention, aggregation and anonymization. Gaps in existing work are highlighted and a roadmap is proposed for areas that require exhaustive research. In particular, this paper describes technical issues that must be addressed in order to implement government and industry policies.

Data handling in the smart grid is a relatively immature issue. Consequently, this paper considers precedents with regard to handling potentially sensitive telecommunications, web search and medical data. The analysis of privacy strategies in these domains provides useful lessons that can guide research efforts for securing smart grid data.

Related Work

This section describes data handling issues covered in existing standards, guidelines and regulations. Much of the relevant prior work focuses on policylevel issues. Although there appears to be general agreement on data handling principles and goals, little work has been done on concrete approaches to achieve the data handling objectives.

Standards Bodies and Industry Guidelines

NIST's NISTIR 7628 document [START_REF]Smart Grid Interoperability Panel -Cyber Security Working Group[END_REF] provides general, policy-level guidance on data handling. For instance, the guidance on data collection recommends:

"Limit the collection of data to only that necessary for smart grid operations, including planning and management, improving energy use and efficiency, account management, and billing."

The guidance on retention recommends: "Limit information retention. Data, and subsequently created information that reveals personal information or activities from and about a specific consumer location, should be retained only for as long as necessary to fulfill the purposes that have been communicated to the energy consumers."

The guidance on aggregation recommends:

"Energy data and any resulting information, such as monthly charges for service, collected as a result of smart grid operations should be aggregated and anonymized by removing personal information elements wherever possible to ensure that energy data from specific consumer locations is limited appropriately."

The guidance on deletion recommends:

"When no longer necessary, consistent with data retention and destruction requirements, the data and information, in all forms, should be irreversibly destroyed."

The general guidance is similar to the computer security principle of least privilege [START_REF] Saltzer | The protection of information computer systems[END_REF]. In practice, however, it may not be clear what privileges are actually required. Indeed, utilities are unable to turn policy to practice. For example, utilities are advised to collect "only . . . necessary [data] for smart grid operations, including planning and management." More efficient planning and management are possible with more data. Similarly, utilities are advised to retain data "only for as long as necessary." However, more data maintained for a longer period of time typically supports better trend analysis and forecasting.

The NAESB provides business practices to follow with respect to third-party access and disclosure of energy-usage data [START_REF] Varela | NAESB is developing smart grid data privacy standards[END_REF]. The guidelines apply to data access directly from utilities but, like NISTIR 7638 [START_REF]Smart Grid Interoperability Panel -Cyber Security Working Group[END_REF], the guidelines are at a high level.

The U.S. Department of Energy's Advanced Security Acceleration Project for the Smart Grid (ASAP-SG) has produced two formal documents that outline the security requirements that a third party should meet in order to access electricity-usage data: (i) Security Profile for Advanced Metering Infrastructure [START_REF]Advanced Security Acceleration Project for the Smart Grid (ASAP-SG), Security Profile for Advanced Metering Infrastructure[END_REF]; and (ii) Security Profile for Third Party Data Access [START_REF]Advanced Security Acceleration Project for the Smart Grid (ASAP-SG), Security Profile for Third Party Data Access[END_REF]. However, these documents primarily focus on general security principles rather than privacy concerns.

The document from the National Regulatory Research Institute entitled, Must There Be Conflict Between Energy Management and Consumer Privacy? [START_REF] Lichtenberg | Smart Grid Data: Must There Be Conflict Between Energy Management and Consumer Privacy?[END_REF], notes that categorizing usage data can reduce the potential for privacy compromise associated with personal information, billing data, operational data and event data. The document also mentions that aggregating data can make it safe to share; however, the method for aggregating data is not provided. Similarly, an early policy paper from the Office of the Information and Privacy Commissioner of Ontario [START_REF] Cavoukian | Data Mining: Staking a Claim on Your Privacy, Office of the Information and Privacy Commissioner of Ontario[END_REF] discusses the privacy implications of data mining and, in particular, fair information practices, but again, the guidance is at a high level. Privacy organizations such as the Electronic Privacy Information Center, Center for Democracy and Technology, and Electronic Frontier Foundation have also weighed in on data handling policies for the smart grid.

State and Utility Commission Regulations

The CPUC Rulemaking 08-12-009 document [START_REF]Decision Adopting Rules to Protect the Privacy and Security of the Electricity Usage Data of the Customers of Pacific Gas and Electric Company, Southern California Edison Company and San Diego Gas and Electric Company[END_REF] contains general rules for utilities, contractors and other third parties that are modeled on the FTC's fair information practice principles [START_REF]Federal Trade Commission, Fair Information Practice Principles[END_REF]. Like the work produced by the standards bodies, the guidance is policy-oriented rather than implementation-oriented.

Another example is the Colorado Public Utilities Commission's Decision No. R11-0922 [START_REF]Public Utility Commission of the State of Colorado, Proposed Rules Relating to Smart Grid Data Privacy for Electric Utilities[END_REF], which describes the so-called "15/15 Rule:" "In aggregating customer data to create an aggregated data report, a utility must take steps to ensure the report is sufficiently anonymous in its aggregated form so that any individual customer data or reasonable approximation thereof cannot be determined from the aggregated amount. At a minimum, a particular aggregation must contain: (i) at least fifteen customers or premises; and (ii) within any customer class, no single customer's customer data or premise associated with a single customer's customer data may comprise 15 percent or more of the total customer data aggregated per customer class to generate the aggregated data report (the "15/15 Rule"). Notwithstanding, the 15/15 Rule, the utility shall not be required to disclose aggregated data if such disclosure would compromise the individual customer's privacy or the security of the utility's system."

This is one of a few guidelines that define the meaning of safe aggregation. However, the reasoning and privacy guarantees underlying the 15/15 Rule are not clear. Other examples of high-level guidance are provided in Oklahoma HB 1079 [START_REF]House Bill 1079[END_REF], the Illinois Statewide Smart Grid Collaborative: Collaborative Report [START_REF]Illinois Statewide Smart Grid Collaborative: Collaborative Report[END_REF], and the National Association of Regulatory Utility Commissioners Resolution on Smart Grid Principles [START_REF]Resolution on Smart Grid Principles[END_REF].

Regulations have also considered other issues such as data ownership and third-party data access. While utility companies are responsible for protecting electricity consumption records from unauthorized use, the data may be shared with third parties by consumers who are most likely unaware of the privacy risks. While some regulations give consumers "ownership" of their electricity consumption data, others (e.g., Oklahoma HB 1079 [START_REF]House Bill 1079[END_REF]) stipulate that the utility company owns the smart meter data and that the utility company is "authorized to share customer data without customer consent with third parties who assist the utility in its business and services, as required by law, in emergency situations, or in a business transaction such as a merger" [START_REF]House Bill 1079[END_REF].

Research Literature

The research literature focuses on technical approaches that can improve privacy -examples include cryptographic mechanisms for facilitating data aggregation [START_REF] Shi | Privacy-preserving aggregation of time-series data[END_REF], differential privacy for sharing aggregated smart grid data with third parties (while preventing the identification of patterns about a single consumer) [START_REF] Taban | Privacy-preserving integrity-assured data aggregation in sensor networks[END_REF], and the use of batteries to mask electricity consumption [START_REF] Li | Secure information aggregation for smart grids using homomorphic encryption[END_REF]. While these mechanisms are promising, they do not answer the questions about data handling and data governance posed in this paper. In addition, most of these approaches are not yet ready for deployment. For example, the "zeroknowledge proofs of knowledge" that are required by the work on cryptographic commitments are computationally impractical. Similarly, using batteries to mask electricity consumption will pose challenges due to the additional costs and the operational requirements involved in managing battery lifetime.

The research literature related to data handling primarily focuses on the information that can be inferred from very fine-grained electricity consumption data in the scale of seconds. However, most advanced metering infrastructures will collect data at fifteen-minute intervals or longer. There is a need to understand the trade-offs existing between data collection intervals and the associated privacy risks.

Comparison with Other Domains

This section discusses the approaches used to implement similar privacy policies in other domains. The focus is on the treatment, disclosure and retention of user data in the context of: (i) telephone logs; (ii) web search data; and (iii) health data.

Telephone Logs

In the United States, privacy policies for telecommunications-related data (e.g., data about customer usage stored by carriers) have mainly been the responsibility of the Federal Communications Commission (FCC). In 1996, the FCC was granted the authority to regulate how customer proprietary network information (CPNI) is treated. In 2007, the FCC began to regulate how data collected by telecommunications companies about customer telephone calls may be used [START_REF]Federal Communications Commission, Report and Order and Further Notice of Proposed Rulemaking[END_REF]. The key points of the regulation are: (i) limiting information that carriers may provide to third parties without customer consent; (ii) defining how customer service representatives may share call details; and (iii) requiring notification obligations on the part of carriers. Like energy-usage data, telecommunications data has value beyond telecommunications companies (e.g., law enforcement and intelligence). This complicates the formulation and implementation of privacy policies.

At this time, there are no strict regulations governing the length of time that carriers may retain telephone logs. This has contributed to the variety of data retention policies that are implemented across the telecommunications industry [START_REF] Kravets | Which telecoms store your data the longest? Secret memo tells all[END_REF]. Some U.S. carriers store call activity logs for days, some for months, some even retain call and text message content. Data retention policies are supposed to be opaque; information about these policies is available to the public because of a recent leak from the U.S. Department of Justice.

Web Search Data

Most Internet providers maintain logs of user search queries. This practice has raised serious privacy concerns because search data contains potentially sensitive information about the interests and web behavior of Internet users. Anonymization is a natural solution, but historical examples highlight the pitfalls. For instance, when AOL released anonymized user search queries, researchers were able to reconstruct the identities of some users [START_REF] Kawamoto | AOL apologizes for release of user search data[END_REF]. Most Internet search engine providers have independently created the data retention policies they implement. According to a 2011 New York Times article [START_REF] Kopytoff | Yahoo! will keep search queries for 18 months[END_REF], Google maintains search records for nine months, Microsoft implements a sixmonth retention policy and Yahoo! has extended its retention time for detailed user records from three month to eighteen months. The privacy measures implemented by search engine providers are unclear because details about their anonymization techniques have not been released.

Another reason for implementing a data retention policy is to address liability issues. Because security breaches often result in the loss of user information, it is prudent for companies to minimize the financial risk they incur when handling sensitive data.

No U.S. legislation specifically addresses the control that users have over personal information related to their online activities, although guidelines are being developed. The FTC has encouraged the protection of online user privacy through several initiatives, such as through its report entitled, Protecting Consumer Privacy in an Era of Rapid Change [START_REF]Protecting Consumer Privacy in an Era of Rapid Change[END_REF]. Additionally, the FTC's fair information practice principles [START_REF]Federal Trade Commission, Fair Information Practice Principles[END_REF] help control personal information in the electronic marketplace by introducing notice, awareness, consent, access and security principles. The U.S. Department of Commerce's Internet Policy Task Force has released a report entitled, Commercial Data Privacy and Innovation in the Internet Economy: A Dynamic Policy Framework [START_REF]Commercial Data Privacy and Innovation in the Internet Economy: A Dynamic Policy Framework, Internet Policy Task Force Green Paper[END_REF], which describes policy guidelines and regulations regarding commercial data privacy. Another effort named Do Not Track Us [START_REF] Mayer | Do Not Track, Universal Web Tracking Opt Out[END_REF], which is spearheaded by academia, enables Internet users to opt out of website tracking.

Health Data

The sensitivity of health-related data has prompted privacy concerns that have been the focus of regulation as well as research efforts. In 1996, the U.S. Government enacted the Health Insurance Portability and Accountability Act (HIPAA) [START_REF]United States Congress, Health Insurance Portability and Accountability Act of 1996[END_REF], which establishes national standards for electronic health care transactions and addresses the security and privacy of health data. In 2003, the Privacy Rule was added, which requires companies and providers to notify individuals about the use of protected health information and to keep track of disclosures. HIPAA also grants an individual the right to file complaints with the Office for Civil Rights of the Department of Health and Human Services.

The extreme sensitivity of genetic information has also been recognized. Protection is provided by the Genetic Information Nondiscrimination Act (GINA) of 2008 [START_REF]United States Congress, Genetic Information Nondiscrimination Act of 2008, H.R[END_REF]. Among other points, GINA strictly regulates the retention, disclosure and treatment of data collected by genetic testing companies.

Privacy laws such as HIPAA and GINA provide much greater protection than laws and regulations associated with telephone calls and web search data. Indeed, the need to enforce health-related regulations is now almost universally recognized [START_REF] Hewlett-Packard | HIPAA goes hitech[END_REF].

Outlook for the Smart Grid

Based on the treatment, disclosure and retention of telephone logs, web search data and health data, we make some projections regarding energy-usage data. First, privacy regulations and policies for most electronic user data are specified at a high level, if at all. As a result, it is likely that implementation practices for handling smart grid data will be left to utilities and their meter data management partners and vendors. The concern is, of course, that data handling issues are subtle. For example, the implications of employing even seemingly simple anonymization and aggregation techniques need to be considered carefully.

Second, companies often self-regulate their data handling even in the absence of regulations. However, as seen with telephone logs and web search data, each company generally has different policies and procedures for data handling, most of which are opaque to the consumer. The same trend will likely be seen in the smart grid where utilities will implement their own policies and procedures for energy-usage data. Indeed, without proper guidance, privacy analysis would require case-by-case evaluation.

Open Issues Related to Data Handling

This section discusses important issues related to the handling of energyusage data in the context of the smart grid. These issues are excellent candidates for research in the area of smart grid privacy.

Safe Data Intervals

A key fair information practice is data minimization, which stipulates that data should not be collected unless it is needed and should not be kept longer than necessary. Many smart grid applications such as demand-response analysis will require the collection and storage of fine-grained data. However, any finegrained data that is collected could be coarsened after it is no longer needed. This coarse data could be preserved in long-term storage or it could be released in various contexts after first checking the privacy implications.

Releasing even "coarse" monthly energy-usage data can result in an invasion of privacy, as demonstrated by the controversy surrounding the public disclosure of Al Gore's utility bills for his 10,000-square-foot Nashville mansion [START_REF] Zeller | An inconveniently easy headline: Gore's electric bills spark debate[END_REF]. Perhaps more interesting is whether a two-hour collection interval or a fourhour interval would be considered safe. Clearly, this question depends on the perspectives of the end-users and the information that can be inferred from the collected data. Two-hour or four-hour data would not be safe if it reveals that the resident is on vacation. However, usage data at this level of granularity may not reveal specific appliance usage or other fine-grained usage patterns and could, therefore, be stored by utilities for the long term.

One of the key factors when considering safe data collection and retention policies is the ability to identify electricity appliances via non-intrusive load monitoring (NILM) [START_REF] Bergman | Distributed non-intrusive load monitoring[END_REF][START_REF] Hart | Nonintrusive appliance load monitoring[END_REF]. Most of the research in this field has considered residential electricity consumption monitors, such as The Energy Detective (TED) and Current Cost, instead of residential smart meters provided by electric utilities. The residential electricity consumption monitors collect and analyze consumption data at sub-second intervals. However, current smart meter deployments do not have these levels of granularity. The vast majority of smart meter deployments collect data in intervals of fifteen minutes or more.

CRITICAL INFRASTRUCTURE PROTECTION VII

In general, there is a notable lack of research on the types of inferences that can be made with different levels of data granularity. Figure 1 shows the perceived relationship between privacy and data interval size. Clearly, privacy increases as the size of the data interval increases, but very little is known about the precise nature of this tradeoff. Prudenzi [START_REF] Prudenzi | A neuron nets based procedure for identifying domestic appliances pattern-of-use from energy recordings at meter panel[END_REF] is one of a few researchers who has examined energy-usage data in intervals ranging from a few minutes to a few hours.

In order to implement the data minimization principle, it is important to understand exactly what can be inferred from smart meter data as a function of various data intervals. Further research is needed to explore the trade-off between data collection intervals and the associated levels of privacy that are attained.

Data Aggregation Across People

Aggregation of energy-usage date across people -instead of over time -must also be considered. The privacy risks associated with fine-grained electricityusage data can be reduced by computing aggregates across people (e.g., neighborhoods) and deleting individual usage data. However, the release of such aggregated data may still have some privacy implications. It is, therefore, important to conduct scientific studies on the conditions under which aggregations of energy-usage data could leak information about individual users and to devise appropriate strategies for mitigating the privacy risks. Figure 2 shows a conceptual plot of privacy versus aggregation size. In the representation, privacy increases as the size of the aggregate increases. However, the precise nature of the relationship has not been studied by the research community. Providing a scientific backing for Colorado's "15-15 Rule" [START_REF]Public Utility Commission of the State of Colorado, Proposed Rules Relating to Smart Grid Data Privacy for Electric Utilities[END_REF], which intuitively postulates a safe aggregation principle, would be highly desirable. More research is needed to identify sound aggregation rules instead of simply specifying rules based on intuition.

Another issue is that aggregation does not protect an individual when all the individuals whose data is aggregated are similar in some way. For example, usage metrics associated with high-income communities are likely to be different from low-income communities. While this particular example may not raise privacy concerns, there may be situations where aggregated data compromises the privacy of the individuals who are part of the aggregate. In-depth studies are needed that focus on the privacy properties of aggregated smart grid data.

Consequences of Latency for Data Access

One concern about real-time electricity consumption data is that it could facilitate burglaries -prospective burglars could tell whether or not residents are home. Latency can help mitigate this privacy threat. For example, consumption data could be released one week or one month later. While some data might be required in real-time, algorithms such as those used for energy disaggregation to identify faulty or inefficient devices or appliances can be performed days, weeks or months later instead of in real time or near real time.

Safe Anonymized Data

Simply removing identifying information, such as a name or address, is insufficient to anonymize many kinds of personal data. For example, location traces can easily reveal home and work locations from which the identities of individuals can be deduced [START_REF] Golle | On the anonymity of home/work location pairs[END_REF][START_REF] Krumm | Inference attacks on location tracks[END_REF]. As in the case of the AOL incident, user identities can be discerned from web search data [START_REF] Kawamoto | AOL apologizes for release of user search data[END_REF]. A linkage attack may also be used to de-anonymize data. For example, electricity-usage patterns could be de-anonymized by linking them to electricity-usage patterns of users in another database. An instantiation of this idea is discussed by Narayanan, et al. [START_REF] Narayanan | Robust de-anonymization of large sparse datasets[END_REF], where anonymized Netflix users were identified by matching their data to the IMDb database.

Conclusions

The vast majority of the work on handling energy-usage data has been at the policy level and is based primarily on fair information practices. Very little research has focused on strategies for implementing these policies and identifying the vulnerabilities that remain. Based on a comparison with other industries, it appears that implementation strategies for smart grid privacy will not be regulated in the near term. Thus, each utility will be forced to develop its own data handling strategy and architecture. Therefore, significant technical research is required in order to provide concrete guidance to designers. This guidance would bridge the gap between policy and implementation.

An important research agenda item is to understand the tradeoff between privacy and data interval size. Another is the development of safe anonymization, sanitization and aggregation strategies. Yet another is the examination of the privacy effects of data latency.

Clearly, all these issues are intertwined. A working system may very well involve the combination of a particular data interval, aggregation and latency strategy. Acquiring a sophisticated understanding of these concepts will be difficult as it will cover technical, legal and human factors issues; however, it is an important first step to enhancing privacy in the smart grid.

Figure 1 .

 1 Figure 1. Conceptual plot of privacy versus data interval size.

Figure 2 .

 2 Figure 2. Conceptual plot of privacy versus aggregation size.