Seungoh Choi

Yeop Chang

Jeong-Han Yun

Woonyon Kim

TRAFFIC-LOCALITY-BASED CREATION OF FLOW WHITELISTS FOR SCADA NETWORKS

Keywords: SCADA networks, intrusion detection, whitelists, traffic locality

The security of supervisory control and data acquisition (SCADA) networks has attracted considerable attention since the discovery of Stuxnet in 2010. Meanwhile, SCADA networks have become increasingly interconnected both locally and remotely. It is, therefore, necessary to develop effective network intrusion detection capabilities. Whitelist-based intrusion detection has become an attractive approach for SCADA networks. However, when analyzing network traffic in SCADA systems, general properties such as TCP handshaking and common ports are insufficient to create flow whitelists. To address the problem, this chapter proposes a methodology for locality-based creation of flow whitelists and conducts experiments to evaluate its effectiveness in seven SCADA systems. The experimental results demonstrate that the methodology generates effective whitelists for deployment in SCADA networks.

Introduction

Industrial control systems, especially supervisory control and data acquisition (SCADA) systems, are widely used in the critical infrastructure. SCADA networks were traditionally considered to be safe from cyber threats because they employed proprietary protocols and were generally isolated from information technology (corporate) networks. This situation has changed and, as Stuxnet has demonstrated, a highly protected and carefully isolated control network can be compromised by a simple USB drive. Malware targeting SCADA networks has proliferated in recent years with examples such as Duqu, Flame, Gauss, Mahdi, Shamoon and SkyWiper [START_REF] Sood | Targeted Cyber Attacks: Multi-Staged Attacks Driven by Exploits and Malware[END_REF].

According to the U.S. Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) [6], SCADA vulnerabilities and incidents are in-creasing rapidly. Meanwhile, SCADA networks are becoming interconnected with other networks, including the Internet, to link local and remote sites [7]; this greatly increases the ability of SCADA malware to propagate. Hence, it is necessary to develop effective intrusion detection schemes for SCADA networks used in the critical infrastructure.

Whitelisting has been recommended for intrusion detection in SCADA networks because of their stable structure and predictable traffic [START_REF] Barbosa | A first look into SCADA network traffic[END_REF][START_REF] Stouffer | Guide to Industrial Control Systems (ICS) Security[END_REF]. Several researchers have studied whitelisting and have proposed novel approaches [START_REF] Jang | Whitelisting for critical ITbased infrastructure[END_REF][START_REF] Kang | Whitelist generation technique for industrial firewalls in SCADA networks[END_REF][START_REF] Yun | Burst-based anomaly detection on the DNP3 protocol[END_REF]. However, a challenge when designing a whitelisting solution is to identify client-server relationships without requiring information from operators or manufacturers. Some whitelisting solutions (e.g., [START_REF] Jang | Whitelisting for critical ITbased infrastructure[END_REF]) assume that the relationships are known; other researchers (e.g., [START_REF] Kang | Whitelist generation technique for industrial firewalls in SCADA networks[END_REF][START_REF] Yun | Burst-based anomaly detection on the DNP3 protocol[END_REF]) simply ignore the problem. Moreover, comprehensive evaluations of whitelist generation techniques and their experimental results have not been performed.

Barbosa et al. [START_REF] Barbosa | Flow whitelisting in SCADA networks[END_REF] have developed a state-of-the-art intrusion detection technique for SCADA networks using flow whitelisting. They inferred client-server relationships from TCP handshaking information (TCP flags) and well-known ports. However, when traffic from a real-world SCADA network is analyzed, problems still exist. First, three-way handshaking relationships cannot be identified when TCP sessions are maintained throughout a traffic collection period. Second, different ports numbers may be used for well-known services to enhance security. Third, network flows may not provide adequate operational information because SCADA systems frequently use proprietary protocols for communications and port assignments on devices that may not be publicly documented.

This chapter focuses on flow whitelisting based on the determination of client-server relationships in a SCADA network. A flow whitelist, which corresponds to a permissible access list, comprises IP addresses, port numbers and transport protocol information such as client-server relationships. This chapter describes a methodology for constructing flow whitelists for SCADA networks based on traffic locality, including degree centrality and locally frequently-used ports. The experimental results demonstrate that the whitelists are very effective at securing SCADA networks.

Background

This section provides background information. In particular, it discusses two important characteristics of SCADA network traffic flow. These characteristics, degree centrality and locally frequently-used ports, form the basis of the proposed methodology for extracting flow whitelists from SCADA network traffic.

Network Flow and Flow Whitelists

A network flow is a directional edge between two network nodes that is represented by pairs of IP addresses and port numbers. A directional edge identifies the flow protocol and direction of flow.

The directed graph in Figure 1(a) shows network traffic flows: a bidirectional TCP traffic flow between Node 1 and Node 2, and a unidirectional UDP traffic flow from Node 3 to Node 1. A directed graph represents flows using five-tuples (i.e., source IP address, source port number, destination IP address, destination port number, protocol) as shown in Figure 1

(b).

A flow whitelist is a set of rules. A rule is also represented as a five-tuple (i.e., source IP address, source port number, destination IP address, destination port number, protocol). However, the source and destination ports are considered to be explicit ports or "ANY."

Traffic Summary

For the experimental evaluations, SCADA network traffic was captured using mirroring techniques from seven sites in two domains. The collection periods varied from 3 to 29 days. As shown in Table 1, there were distinct distribution differences between the TCP and UDP traffic from each site. A large proportion of traffic did not have many flows for both TCP and UDP communications, such as at Site A. However, Site B had an extremely large proportion of TCP traffic because Site B backed up the other sites using TCP.

All the flows were analyzed to extract a flow whitelist. The analysis revealed two key characteristics, degree centrality and locally frequently-used ports (LFPs), which are discussed below.

Degree Centrality

Degree centrality is the number of links associated with a node [START_REF] Freeman | Centrality in social networks: Conceptual clarification[END_REF]. Two types of degree centrality can be calculated for directional edges: (i) in-degree flow, which is the number of incoming links; and (ii) out-degree flow, which is the number of outgoing links. As shown in Figure 1, the degree centrality of Node 1 comprises an in-degree flow of two (incoming from Node 2 and Node 3) and an out-degree flow of one (outgoing to Node 2). Based on this observation, it appears that degree centrality could be used to identify client-server relationships. To help identify the nodes, the results were ranked in descending order of degree centrality as shown in Figure 3. Note that, in the figure, the node ID is a unique IP address and port number pair. Most server nodes (IP server , P ORT Server ) had degree centrality values of more than 1,000, which covered approximately half of the flows for both TCP and UDP. Upon analyzing the network traffic degree centrality, the fixed port numbers of each IP Server were readily identified. Rules were then extracted from the flows associated with the server nodes. For example, if a server node (IP Server , P ORT Server ) had TCP incoming edges from nodes using the same IP Client , the following rule could be extracted: (IP Client , AN Y , IP Server , P ORT Server , T CP ). In the case of TCP, there may be a counter rule, (IP Server , P ORT Server , IP Client , AN Y , T CP ), which is similar to the case of UDP.

Locally Frequently-Used Ports

Although degree centrality helps extract rules that cover a considerable amount of flows, it cannot help extract all the rules for a flow whitelist. Moreover, degree centrality may yield incorrect rules in two situations. One is when one client communicates with many servers and the other is when communications occur via the same port. One Client to Many Servers: A device, such as a front end processor (FEP), requires connections to other devices such as programmable logic controllers (PLCs) or remote terminal units (RTUs) with different IP addresses, but the same port number. The application of degree centrality does not yield rules in this case because no nodes have high degree centrality. As shown in Figure 4(a), TCP flows do not converge on a specific server IP address and server port pair. One port (3000) on the server side is frequently used, but no rules are generated due to the low degree centrality of every server.

This problem is more acute for UDP flows. As shown in Figure 4 To solve these problems, it is necessary to consider locally frequently-used server ports in SCADA networks.

Communications via a Fixed Port: A client can use a fixed port. To communicate with programmable logic controllers, the client and server sides are configured to use fixed ports. In particular, some protocols, such as NetBIOS and SUN RPC, force the same port to be used by the client and the server. Therefore, it is necessary to also discover locally frequently-used ports that primarily use local sites because client-side ports should not be mistakenly identified as server-side ports. A locally frequently-used port can be inferred by the usage count, which varies per port as shown in Figure 5. In the figure, it is evident that there are roughly ten TCP ports and three UDP ports that are locally frequentlyused ports when the usage count is greater than 1,000.

Flow Whitelist Creation

This section describes the methodology for creating a flow whitelist based on the observations discussed in the previous section.

Overview

The flow whitelist creation methodology, which is presented in Figure 6, has three phases: (i) preparation; (ii) generation; and (iii) inspection. The initial preparation phase divides raw traffic into a set of unique flows in each hourly interval without redundant flows. In addition, it lists the locally frequently-used ports based on all flows. The generation phase selectively identifies candidates for the flow whitelist using a generation algorithm. The final inspection phase analyzes the flow whitelist candidates and omits flows that do not match the results of the algorithm executed in the previous phase. Thus, it helps administrators decide whether or not candidates should be placed in the final whitelist.

Phase 1: Preparation

The preparation phase processes raw traffic to make it appropriate as an input to the second phase. It splits the raw traffic according to a timeline, creates a set of unique flows and lists the locally frequently-used ports.

Raw traffic is first separated by time because flow whitelist generation examines flows within a given period. Next, a set of unique flows is produced; this set includes essential traffic information (i.e., represented as five-tuples) to reduce the processing burden. Finally, the ports that are frequently used with different IP addresses at a local site are listed.

Figure 7 presents the locally frequently-used port extraction process. Two threshold values, θ Unit and θ F inal , are employed. The θ Unit threshold is used to filter specific ports that are rarely found in a given set of unique flows. During the filtering, the number of a used port is set to zero as long as the number does not exceed the threshold; otherwise, the value is retained until the end of the process. The θ F inal threshold is used in the second phase to obtain the final locally frequently-used port list. In Figure 7, the thresholds used for θ Unit and θ F inal are 5 and 25, respectively.

To overcome the lack of knowledge of flows in a SCADA network, the locally frequently-used ports serve as an informative reference to infer server-side ports without mistakenly identifying the client side as the server side for TCP and UDP traffic. Moreover, based on the observations in Section 2.4, it can be an opportunity to quickly generate a flow whitelist and accurately use the locally frequently-used ports because many uses of server IP addresses are converted in advance to a flow whitelist.

Phase 2: Generation

The generation phase creates the flow whitelist. The set of unique flows is input to Algorithm 1, which uses two indicators, degree centrality and locally frequently-used ports, as discussed in Section 2.

The algorithm initially checks if a unique flow matches an already-generated rule. When a flow is covered by a rule, the flow is ignored and a new rule is not generated. If a flow is not covered by a rule, then the locally frequentlyused port list is examined for a port associated with the source or destination IP address. Three cases exist: the locally frequently-used port list includes: (i) only a source-side port; (ii) only a destination-side port; or (iii) both. As mentioned above, a port is designated as "ANY" if it is not present in the locally frequently-used port list. Thus, the inference of the server side based on the locally frequently-used ports is prioritized when generating the flow whitelist.

Next, the degree centrality with direction is analyzed to handle nodes in which the flow is centralized. Node in-degree and out-degree centrality values are computed by counting the numbers of incoming and outgoing links, respectively. When the in-degree or out-degree centrality of a node exceeds the port threshold (θ P ort ) defined by an administrator, rule generation is triggered, which depends on the direction of flow at the node. For example, a rule is generated at Lines 14-17 of the algorithm if the node in-degree centrality exceeds the port threshold because many flows head to the destination. In the rule Algorithm 1 : Flow whitelist generation.

Main:

1: for each file in files do 2:

MakeUniqueFlows (...)

3:

for each flow in flows do

4:

RuleGeneration(protocol, dIP, dPort, sIP, sPort) Remove all flows matched with the rule 24: end if generation process, all flows that match a rule generated based on the locally frequently-used ports and degree centrality are eliminated.

Phase 3: Inspection

The inspection phase confirms if a generated (candidate) rule is whitelisted. Because of the use of the threshold in rule generation, remaining flows may exist. In fact, the inspection phase could generate rules flow by flow. However, not all flows in a SCADA network are legitimate; such flows arise due to link failures or problems with field devices. Therefore, guidelines are provided to serve as a graylist for the remaining flows as well as for the inspection of whitelist candidates. The following are some example guidelines: Unidirectional Rule: A unidirectional rule represents a one-way flow. It can result from the operational objective of a device or a problem situation. For example, a node may need to send or receive data from other nodes due to an operational objective. However, a packet may not reach its destination because of a problem in a SCADA device or network.

Usage Rule Frequency: It is possible to identify a small rule usage count when a flow is not created often. At times, an unpopular rule may be meaningful if the rule deals with an essential service in a device. Otherwise, it is necessary to inspect the rule to identify if it is normal and can be entered in the whitelist.

Dynamic Port: A port is dynamically assigned by a service such as FTP. In this case, the flow whitelist is not generated because the flows do not satisfy the degree centrality threshold. Therefore, a rule must be created with "ANY" for the source and destination ports if there are many flows between two nodes after inspecting the remaining flows.

Experimental Results

This section presents the results obtained during the preparation, generation and inspection phases of the experiments.

Phase 1: Preparation

Table 2 shows the results after processing raw traffic and running the locally frequently-used port (LFP) extraction procedure. As seen in the table, the volumes of the flows decreased dramatically compared with the raw traffic flow. In addition, several locally frequently-used ports were obtained when θ Unit and θ F inal were defined as 25 and 100, respectively.

Phase 2: Generation

The experimental results were analyzed in terms of two factors: (i) degree centrality threshold; and (ii) time. Figures 8 and9 present the numbers of generated rules and the hit ratios of generated rules for varying degree centrality thresholds for the seven sites. When the generated rule number was represented as in Figure 8, it was discovered that the number of rules decreased as the threshold increased. Although the extent of the decrease differed between sites, the numbers of rules for both TCP and UDP sharply decreased when the threshold rose from 10 to 20. Notably, all the hit ratios of the rules were close to one, as shown in Figure 9. The minimum hit ratios were 0.995 and 0.990 for TCP and UDP, respectively. However, unlike the UDP rules, the TCP rules were sensitive to an increasing threshold. The remaining hit ratios could possibly have been in the graylist, which must be inspected by an administrator. In summary, all the results decreased and nearly stabilized at particular values, regardless of the transport protocols and sites; only the amounts of the decreases differed. This enabled a reasonable threshold to be chosen so that a flow whitelist could be created for optimal performance with respect to protocol-specific or site-specific operations. For example, the appropriate threshold for TCP at Site C was 70 whereas it was 30 for UDP. In the case of TCP, the number of rules decreased to between 10 to 50 for the threshold, and the hit ratio noticeably decreased to 70 for the threshold. Thus, 70 was deemed to be the suitable threshold for TCP at Site C. Otherwise, the number of rules for UDP rapidly decreased until a threshold value of 30 was reached; however, the hit ratio did not change significantly over the range of thresholds. Consequently, it was determined that a threshold of 30 would be most appropriate for UDP at Site C.

Figure 10 shows the rule counts for varying thresholds for TCP and UDP at several sites. In particular, Figures 10(a) and 10(b) show that the number of generated rules for every threshold steadily increased, except for the marking period of P 1 at Site C because new services began during the period. On the other hand, during the marking period of Q 1 and Q 2 in Figures 10(c) and 10(d), the reason for a significant increase was different from that for P 1 . Specifically, the degree centrality during the period finally exceeded its threshold, causing a rule to be created. In fact, the percentage of flows for UDP (0.06%) was much lower than that for TCP at Site G. Thus, the number of flows for UDP was continuously maintained when the threshold was greater than or equal to 20.

Phase 3: Inspection

Similar results were observed during the inspection phase regardless of the sites. An interesting result was obtained for Site C, which was much more indicative in terms of what can be discovered via inspection. Figure 11 lists the usage of the rules, including the number of rules used during each hourly interval and the total hours for each rule over 281 hours at Site C. The total number of generated rules was 447. For convenience, each rule was arranged in descending order according to the rule usage frequency. A dot denotes at least one flow that matches the rule at the given time, the top polygonal graph represents the number of rules used in the time interval and the right polygonal graph represents the number of hours during which the rule was used.

Flow Whitelist: As shown in the upper graph of Figure 11, 203 rules (Rule ID 1 to Rule ID 203) were used during all the time intervals; the subsequent 140 rules (Rule ID 204 to Rule ID 343) were frequently used in 89% of the entire timeline. More than 84% of the rules were always active after 30 hours. This was explained in Section 4.2 as being due to new services that began during the period. Therefore, most generated rules were recommended for inclusion in the flow whitelist.

Graylist: All the generated rules may not be included in a flow whitelist. In the experiments, some generated rules were rarely or ever used within one hour. In addition, there were one-way TCP rules between some IP addresses. These rules were determined to be graylist rules. The graylist could be processed without any assistance from a vendor: it was easy to identify unusual rules; moreover, the number of rules was adequate for inspection. Administrators are encouraged to use graylists to investigate SCADA networks and devices.

Left Flows: Analysis revealed 1,062 left flows for TCP and 20 flows for UDP. In the case of TCP, 790 flows (approximately 53%) were identified; they were inferred as a dynamic port and twelve unidirectional TCP flows. Thus, 260 TCP flows and 20 UDP flows remained.

Discussion

Rules in a flow whitelist have interesting characteristics, correlations and periodicities. As shown at the bottom of Figure 11, a deactivation of Rule Group A and an activation of Rule Group B occurred at hour 209. The rules in the two groups were compared to ascertain the reason for the rule transition. The conclusion was that the transition was due to the service port assigned at the time. Although the two rule groups were both valid, the simultaneous appearance of Rule Groups A and B may have been abnormal. If the switchover from Rule Group A to B was sufficiently informative, an intrusion detection system that employs the flow whitelist could be programmed to alert an administrator.

In addition, periodicity was discovered in the flow whitelist. The rules in Rule Group C matched the flows for two hours. If these rules were to relate to an important regular activity (e.g., data backup), the disappearance of matched flows could be reported to an administrator, even if the issues were not securityrelated.

Conclusions

SCADA networks are often interconnected with other networks, including corporate networks and the Internet, greatly increasing the risk of intrusions by malicious entities. Whitelist-based intrusion detection is an attractive network security solution, but flow whitelist extraction from SCADA network traffic is a challenging task. The proposed methodology for creating flow whitelists using degree centrality and locally frequently-used ports addresses the challenges. Experimental results involving seven SCADA systems demonstrate that the methodology generates effective whitelists for deployment in SCADA networks. Indeed, the whitelists can be deployed in a variety of network devices, including switches, firewalls and intrusion detection systems. The approach also supports rule updating because a flow whitelist can indicate the services that have been added or removed by repeatedly updating itself; this enables administrators to easily handle the tasks of flow whitelist extraction and updating. Future research will focus on the deep inspection of SCADA network traffic to address non-disclosure characteristics.

  graph. (b) Flows as five-tuples.

Figure 1 .

 1 Figure 1. Flow representation.

Figure 2 .

 2 Figure 2. Graphs of network flows during a five-hour period at Site C.

Figure 2

 2 Figure 2 presents graphs of TCP and UDP flows seen during a five-hour period at Site C. Note that most of the flows are concentrated at specific nodes.Based on this observation, it appears that degree centrality could be used to identify client-server relationships. To help identify the nodes, the results were ranked in descending order of degree centrality as shown in Figure3. Note that, in the figure, the node ID is a unique IP address and port number pair. Most server nodes (IP server , P ORT Server ) had degree centrality values of more than 1,000, which covered approximately half of the flows for both TCP and UDP.

Figure 3 .

 3 Figure 3. Degree centrality during a five-hour period at Site C.

Figure 4 .

 4 Figure 4. Limitations of degree centrality.

Figure 5 .

 5 Figure 5. Port number usage during a five-hour period at Site C.

Figure 6 .

 6 Figure 6. Flow whitelist creation.

FinalFigure 7 .

 7 Figure 7. Locally frequently-used port extraction.

Figure 8 .

 8 Figure 8. Numbers of rules for varying degree centrality thresholds.

Figure 9 .

 9 Figure 9. Hit ratios of overall rules for varying degree centrality thresholds.

  (a) TCP at Site C. (b) UDP at Site C. (c) TCP at Site G. (d) UDP at Site G.

Figure 10 .

 10 Figure 10. Numbers of rules for varying degree centrality thresholds in a time series.

Table 1 .

 1 Summary of captured SCADA network traffic.

	Site	Size of Traffic (Proportion)	No. of Flows (Proportion)
		TCP	UDP	TCP	UDP
	A	4 5 0G B	3G B	2 7 , 4 0 2 , 0 6 2	2 5 , 3 8 5 , 0 5 1
		(0.9934)	(0.0066)	(0.5191)	(0.4809)
	B	3 7G B	0 . 1G B	3 7 1 , 9 0 8	7
		(0.9973)	(0.0027)	(0.99998)	(0.00002)
	C	4 0 9G B	8 3G B	4 , 4 0 5 , 0 0 6	4 , 7 9 3 , 9 3 2
		(0.8313)	(0.1687)	(0.4789)	(0.5211)
	D	1 3 1G B	7 6G B	2 , 0 8 7 , 7 4 0	2 , 7 7 3
		(0.6329)	(0.3671)	(0.9987)	(0.0013)
	E	3 7 0G B	5 5G B	1 , 4 7 9 , 0 1 1	1 , 1 1 3 , 9 3 8
		(0.8706)	(0.1294)	(0.5704)	(0.4296)
	F	2 , 4 2 9G B	1 9 3G B	4 7 , 4 1 2 , 4 1 0	2 6 , 8 3 2 , 0 8 0
		(0.9264)	(0.0736)	(0.6386)	(0.3614)
	G	2 7 7G B	3G B	3 5 7 , 3 9 9	2 4 , 7 2 9
		(0.9893)	(0.0107)	(0.9353)	(0.0647)

Table 2 .

 2 Preparation phase results.

	Site	Volume of	Volume of	Number of LFPs
		Raw Traffic Unique Flows (θUnit = 25, θ F inal = 100)
	A	4 5 3G B	3 . 9G B	4 9
	B	3 7 . 1G B	0 . 0 2 7G B	1 1
	C	4 9 2G B	0 . 6 5G B	3 9
	D	2 0 7G B	5 . 8G B	2 1 5
	E	4 2 5G B	0 . 1 8G B	6
	F	2 , 6 2 2G B	0 . 2G B	7 7
	G	2 8 0G B	0 . 0 2 8G B	1 9

Figure 11. Usage of rules at Site C with varying times and rule IDs.


Jonathan Butts

Michael Glover

How Industrial Control System Security Training is Falling Short

Keywords: Industrial control systems, training, facilities, curricula

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

Introduction

Industrial control systems (ICSs) monitor and manage critical infrastructures such as the electric power grid, water treatment systems, oil and gas pipelines, and chemical and nuclear plants. In recent years, industrial control systems have increasingly become interconnected with enterprise networks and the Internet to take advantage of cost savings and operational benefits. This trend, however, has introduced myriad attack entry points associated with the networking environment. As a result, formerly isolated critical infrastructure assets are now susceptible to a wide range of threats that previously did not exist. Exacerbating the concern is that approximately 85% of the U.S. critical infrastructure is privately owned and operated [START_REF]Critical Infrastructure Sector Partnerships[END_REF].

Unfortunately, the majority of infrastructure owners and operators -especially private entities and municipalities -do not understand the risks and have minimal capabilities to respond to sophisticated cyber attacks that target industrial control systems. Training programs are primarily focused on information and communications security rather than industrial control system security.

This chapter evaluates government and industry training programs that specifically focus on industrial control system security professionals. The results indicate that deficiencies exist with respect to training facilities and curricula. Additionally, the training programs do not incorporate coordinated efforts for responding to targeted attacks against critical infrastructure sectors. To overcome the deficiencies, regional facilities are recommended that would support industrial control system security training that utilizes real-world systems. Due to the significant costs and coordination that will be involved, active federal government sponsorship and participation will be required. However, these investments are needed to ensure that adequate numbers of trained personnel are available to prevent and respond to cyber attacks that target industrial control systems and, by extension, the critical infrastructure.

Background

Coordinated cyber attacks target two primary categories of computing systems: (i) traditional information and communications technology (ICT) systems; and (ii) cyber-physical systems [START_REF] Zhu | A taxonomy of cyber attacks on SCADA systems[END_REF]. Note that, although the fundamental principles for exploiting the two categories of computing systems may overlap, the effects of cyber-initiated actions on these two types of systems are quite different. Information and communications technology includes systems and applications associated with computer and network hardware, software and communications media [START_REF]Protection of Mission Critical Functions to Achieve Trusted Systems and Networks[END_REF]. The technology encompasses computers, enterprise software, middleware and data storage that enable users to access, manipulate, store and transmit information. The exploitation of information and communications systems can result in the loss of sensitive or proprietary information, degraded communications, loss or unavailability of data processing and computing systems, and data manipulation. Cyber-physical systems comprise embedded devices and are system-of-systems that are typically associated with the critical infrastructure. Cyber-physical systems, such as industrial control systems, are designed for the "seamless integration of computational algorithms and physical components" [START_REF]Cyber-Physical Systems, Program Solicitation[END_REF]. Attacks on these systems can achieve direct kinetic effects that could result in equipment damage and the loss of human life.

Due to the extensive private ownership of the critical infrastructure, the government must largely rely on civilian personnel to protect these national assets. It is imperative that these personnel are adequately trained to protect against, respond to and recover from cyber-initiated attacks on critical infrastructure systems.

Due to the increased threats to the critical infrastructure, myriad courses have been developed to help train control system security professionals in government and industry. In this discussion, only training courses that are publicly available to security professionals are considered.

Government training on industrial control system security is primarily offered by the Department of Homeland Security (DHS) and the Department of Energy (DoE) National Laboratories [START_REF]SCADA Training Courses, Albuquerque[END_REF]8]. The courses incorporate lectures and hands-on training focused on how attacks are launched, why they work and how to develop mitigation strategies. The topics include reviews of industrial control system security, comparative analysis of information and communications system and industrial control system architectures, security vulnerabilities and mitigation strategies. The DHS ICS-CERT advanced training course uses a representative industrial control system to demonstrate how exploits can affect process systems and the utility of mitigation solutions. The training culminates in a red team/blue team exercise that divides students into teams of attackers and teams of defenders. Students are expected to have a strong understanding of industrial control networks and information and communications networks in order to register for the course. The hands-on course is offered only at specific locations in the United States and students must to travel to one of the sites to take the course.

Industry training is primarily offered in the form of one-week courses conducted by vendors. Although a number of vendors offer industrial control system security training, the curricular outlines and training environments are quite similar. The topics covered include industrial control system fundamentals, assessing and managing risk, auditing and assessing systems, defense strategies and implementing security controls. The majority of training courses offer hands-on laboratory assignments that incorporate components such as programmable logic controllers (PLCs) that may be networked in a simulated operational environment. Instructors typically travel to various locations to conduct the training courses, although on-site training tailored to individual organizations is also available. Some vendors offer training at facilities that incorporate simulation testbeds and table-top experimental set-ups that are representative of real industrial control systems. Trainees have a wide range of backgrounds and typically no prerequisites are required to attend the courses.

Gap Analysis

A gap analysis was performed to examine industrial control system security training requirements and existing capabilities. The following shortfalls were identified:

Training Facilities: The primary shortfall is the lack of appropriate training facilities. A training facility must incorporate real-world systems that adequately prepare students to deal with the situations encountered in industrial environments. Current training facilities either engage simulations or systems that are scaled-down models of physical processes. A real-world, high-fidelity training facility is often overlooked or is considered to be impractical due to the extensive costs associated with incorporating full-scale systems and physical processes. As a result, the courses only provide an abstract understanding of the systems and the associated attacks and defensive strategies. It is imperative that training programs offer hands-on experience and immersion in actual industrial control environments. Without the incorporation of actual physical processes and full-scale systems in training programs, it is impossible for trainees to acquire the skills needed to operate industrial processes in the face of attacks and failures that emanate from the cyber domain.

Training Curricula: The primary gap in training curricula is the lack of emphasis on physical processes. Current training programs focus primarily on defending and exploiting traditional information and communications systems; they do not adequately incorporate the physical components and processes that are encountered in industrial environments. As a result, the courses do not provide a strong understanding of the implications of cyber-physical correlations and the effects that cyber actions have on physical controls and instrumentation. Although the curricula may offer foundational training, they are not tailored to provide the advanced skills required to detect and mitigate attacks on critical infrastructure assets.

Training Facility Evaluation

A robust training facility is the key to developing industrial control system security specialists. The training facility must incorporate real-world process systems and control systems and provide hands-on experience. Testbeds and simulation environments may be used to supplement real-world learning experiences, but it is important to be cognizant of the fact that they do not adequately reflect real-world system implementations.

One of the primary challenges when creating a training facility is the integration of a full-scale industrial control system. Real-world industrial control systems comprise equipment from a number of vendors and use diverse protocols, configurations and instrumentation. As a result, the costs associated with designing and implementing a realistic training facility are significant. However, training on real-world industrial control systems exposes personnel to the configuration and deployment intricacies encountered in industrial environments. Additionally, the use of real-world systems emphasizes the importance of physical-safety-override systems and how they affect functionality.

Requirements.

A training facility that incorporates real-world industrial control systems is needed to ensure that trainees acquire an in-depth understanding of industrial control systems and the effects that cyber-initiated actions have on physical processes. Simulated environments and small-scale testbeds simply do not provide the required functionality, processes or physical components.

Analysis of Existing Capabilities. Several leading government and industry training facilities were evaluated to assess their ability to support industrial control system training objectives. Table 1 summarizes the findings. Note that "A" indicates that training facilities adequately cover the requirement while "P" indicates that the requirement is partially covered.

Current training facilities lack real-world systems and the ability to manipulate physical processes and measure effects. To meet industrial control system training requirements, personnel must be exposed to hands-on training that incorporates real physical systems. Current training facilities primarily use individual components, simulated environments or small-scale testbedsthe vast majority of facilities use only individual subcomponents. Some of the more advanced training facilities incorporate simulations for traffic generation and provide notional targets for practicing exploitation and defense. A few training facilities offer small-scale testbeds that model real-world systems and provide opportunities to manipulate physical devices and observe minor effects. It is important to note, however, that the testbeds provide only a fraction of real-world functionality and do not adequately replicate the processes, interactions and sophistication associated with fully operational systems. Even at the most basic level, trainees must be exposed to functioning systems to observe the physical processes and control systems in operation and to gain insight into their complex behavior. Unfortunately, it is often the case that trainees never get to see, let alone experiment with, operational industrial control systems.

The majority of training courses use control system subcomponents and virtualized applications for training. For example, trainees are often assigned programmable logic controllers for the duration of a course, but the controllers typically have limited or no interconnections to other control system components. Additionally, the training may not incorporate a remote control center, which is a core component of industrial control systems and one that is frequently targeted by attackers. In many instances, the training facility fails to incorporate key components such as human-machine interfaces, historians and input/output servers. A training facility should incorporate a variety of common access points to expose trainees to methods for gaining unauthorized access to industrial control systems. For example, a primary training requirement should be the ability to identify industrial control system subcomponents from within a corporate network, understand how to pivot and then gain access to the control network.

Communications infrastructures provide different attack vectors and can also alter the operating characteristics of industrial control systems. A training facility should incorporate the range of communications infrastructures that are likely to be encountered in operational environments. The training facility should provide modularity to create the different configurations that meet training objectives, advance student skills and replicate the myriad environments encountered in real-world infrastructures. Most training courses use simulations or testbeds that focus on single, isolated instances of systems. It is important that training courses provide professional with opportunities to work on multiple types of systems used in the various infrastructure sectors.

Well-trained industrial control system professionals should be knowledgeable about how cyber actions can manipulate physical processes and how altering physical processes can affect the cyber components. For example, several cyber options may be available to achieve a desired effect such as shutting down power to a targeted area -these include the available access, types of field devices, operating systems and applications, available exploits and system configurations. It is also critical that a specialist understands and can identify the various risks to individual system components as well as the system as a whole.

Training Curricula Evaluation

Industrial control system training curricula must prepare professionals for the range of threats that are likely to be encountered when operating critical infrastructure assets. The research results indicate that that training programs are generally inadequate -they primarily focus on exploiting and defending conventional information and communications systems and do not sufficiently incorporate physical components and process systems. A well-designed training program must emphasize the physical aspects and effects associated with industrial control systems.

A professional with strong expertise in process systems and cyber capabilities has the ability to identify the range of threats, comprehend their implications, articulate the strengths and weaknesses of mitigation options and perform the appropriate actions. Indeed, understanding the many ways in which a cyber attack can alter a physical process provides the insight needed to develop and apply strategies to protect against system manipulation. If a physical process has been altered, an experienced operator should be able to discern if the physical effect was cyber-initiated, identify attack vectors, determine the risks to other components and systems, modify configurations and parameters to minimize operational impact and eliminate the threat.

Requirements. Industrial control system security training must provide comprehensive knowledge of the cyber components and physical processes. It is woefully inadequate to understand just the cyber components or physical processes when defending against targeted attacks. In industrial environments, cyber professionals and control engineers have historically been segregated, with each group focusing on its specific area of expertise [3]. The separation of duties and responsibilities has resulted in a lack of understanding of the holistic functionality of industrial control systems. The incorporation of sophisticated automation technologies in industrial environments means that definitive lines cannot be drawn between the engineering aspects of the physical processes and the cyber aspects. This is similar to the case of an automobile technician who, due to advancements in technology, must have knowledge of and the ability to work on the mechanical and electrical systems of modern automobiles.

Industrial control system security specialists must have the ability to analyze a system, understand its functionality, comprehend the risks, evaluate potential secondary effects and articulate mitigation strategies. The core knowledge areas for training curricula that would meet these requirements are: (i) industrial control system principles; (ii) cyber manipulation; and (iii) response coordination. The knowledge areas corresponding to the three core areas are: The knowledge areas were derived from the skill-set required to defend against targeted attacks on industrial control systems. A specialist should understand: system operating principles; components and functionality; underlying physical processes; cyber-physical correlations; means for gaining access to cyber-physical systems; implications of cyber actions on physical processes; how cyber capabilities are leveraged to achieve physical effects; how to evaluate second-order and cascading effects; limitations of cyber capabilities; and how cyber-kinetic actions are incorporated into requirements, planning and operations. The findings revealed little variance in the training courses with regard to industrial control system fundamentals and cyber manipulation. The primary gaps for all the training courses include the lack of emphasis and material relating to physical systems, instrumentation, safety systems and system effect analysis. From the knowledge and skills perspective, the course material ranged primarily from the beginner level to the intermediate level.

Industrial
A common theme identified during the curriculum analysis was the traditional information and communications system penetration testing (assessment) mentality. Traditional information and communications system assessments involve a network focus, freedom to maneuver to discover vulnerabilities, a known environment (e.g., Windows operating system) and common vulnerabilities discovered via network assessment tools. Although industrial control systems comprise traditional information and communications systems, understanding how targeted physical effects are achieved requires an evaluation of the overall system-of-systems architecture beyond just the cyber aspects. Current training programs examine individual subcomponents in isolation and do not adequately consider the holistic system. It is imperative that programs cover the interactions between subcomponents and how manipulating parameters in one subsystem or device can cascade throughout a system.

Current training programs rarely go beyond the basic programming and functionality of industrial control system subcomponents. Also, communications protocols are analyzed at a functional level and only a few protocols are incorporated in the training regimens. As a result, there is a major gap related to the implications of the cyber-physical correlations and the effects that cyber actions have on physical controls and instrumentation. Indeed, most training programs are geared towards information and communications technology professionals and primarily expose them to control system functionality and security threats. Although the curricula do help develop awareness and provide basic knowledge, they are not tailored to impart advanced knowledge and skills. As a result, the training programs mainly prepare individuals to protect against attacks directed at information and communications systems instead of preparing them to address sophisticated, targeted attacks on control systems and the infrastructures they operate.

Recommendations

The recommendations are focused on delivering training programs that meet the requirements associated with securing critical infrastructure assets across the various sectors. As an initial step, investments must be made to develop realistic training facilities. Curricula should also be developed, ideally through government sponsorship and public-private cooperation, that would provide the best possible training.

Training Facilities

The primary obstacle to providing adequate training is a sufficient number of facilities that incorporate real-world control systems and processes. These facilities would support the delivery of intense hands-on courses that would enable trainees to observe and learn from the effects of real attacks on industrial control systems. To truly understand the security implications and response strategies, real-world environments are required that comprise multiple interconnected systems (e.g., oil and gas, electric power, water/wastewater and building automation systems).

To overcome the deficiencies, it is recommended to construct several regional facilities that would support industrial control system security training on real-world systems. The primary challenges are the significant costs and coordination that will be required to deploy and operate these facilities. To address these challenges, active federal government sponsorship and participation is required (it would be exceedingly difficult for private entities to independently fund and operate large-scale facilities). Indeed, the Departments of Homeland Security, Energy and Defense, the Government Accounting Office and other government organizations have a vested interest in industrial control system security. The federal government can leverage critical infrastructure assets at legacy sites (e.g., closed military bases) to develop real-world training environments. The various regional training facilities could focus on different combinations of critical infrastructures.

Training Curricula

Intense training courses that incorporate actual physical systems are required. The proposed training curriculum should cover three core areas: (i) industrial control system principles; (ii) cyber manipulation; (iii) and response coordination. The industrial control system principles and cyber manipulation areas are divided into specific training blocks aligned to the required knowledge and skill sets. The response coordination core area focuses on the practical application of knowledge gained from the industrial control system principles and cyber manipulation core areas. Table 3 lists the recommended course topics.

Industrial Control System Principles. The industrial control system principles core area focuses on physical system attributes and cyber-physical relationships. System functionality includes operating principles, the common vernacular and implementation details in the various sectors. Control theory provides the fundamental knowledge of processes, control systems, systems dynamics and systems engineering required to understand system function and design specifications. System architecture and operating requirements detail the types of configurations and parameters that support system functionality. Note that system functionality is dependent on the underlying physical process. For example, a liquid pipeline has strict timing requirements because liquid is incompressible and an increase in pressure due to a blockage could result in a pipeline rupture, whereas a gas pipeline has less restrictive timing requirements because gas is compressible [START_REF] Couper | Chemical Process Equipment: Selection and Design[END_REF]. Deep knowledge about such system properties is critical to understanding and mitigating the effects of attacks.

Instrumentation devices measure physical system properties such as temperature, pressure, flow and level. It is important to understand how the current and voltage input/output signals to/from field devices impact sensors and actuators that instantiate the physical changes in the process system. Under-standing the programming languages and field device system architecture (i.e., hardware, firmware and software) provides the ability to manipulate system control via device exploitation. Control and data acquisition covers system interaction and how data is processed and used throughout the system. Applications includes programs for managing system functionality, providing process visualization and enabling operator interfaces. Knowledge of communications protocols, network design and topology are critical to determining access capabilities and how network traffic is routed.

Cyber Manipulation. The cyber manipulation core area emphasizes the ability to defend against exploitations of cyber vulnerabilities that affect a physical process. It is important to understand the differences between traditional information and communications systems and industrial control systems. Fundamentally, the methods for identifying vulnerabilities in hardware, software or system configurations do not change; however, the exploitation of a vulnerability and the resulting impact are highly dependent on the targeted system. For example, scanning a traditional IP network can identify and provide details of the workstations in the network. On the other hand, performing a similar scan on an industrial control network can cause field devices to malfunction and potentially render them inoperable [START_REF] Stouffer | Guide to Industrial Control Systems (ICS) Security[END_REF]. It is important to know how to obtain system configuration data and parameters, as well as to understand the capabilities and limitations of available tools.

Understanding access vectors provides insights into leveraging communications systems and other access points to gain entry to industrial control systems. Asset enumeration and identification helps discern the components that comprise a system, including their technical details and network interconnections. This information is used to analyze field devices, applications, operating systems, communications and protocols and determine system configuration and software/firmware information. A vulnerability analysis reveals weaknesses in system configuration, design and implementation for exploitation and implanting malware. Confidentiality, integrity and availability considerations help determine how attacks can manipulate physical processes. Pivoting involves leveraging access gained to one system to compromise other systems. In the case of industrial control systems, pivoting enables attackers to access appropriate subcomponents to achieve their desired effects. Defensive capabilities ensure appropriate configurations and that safeguards are implemented to prevent compromise or minimize damage to the physical process should an attack occur. Forensic capabilities help determine how an attack occurred, the extent of damage and preventive measures to prevent future compromises, as well as obtain intelligence about the attack.

Response Coordination. Knowledge of response coordination is best obtained through mission-oriented training that immerses trainees in environments that mirror real-world operations and scenarios. The response coordination core area involves the application of industrial control system and cyber manipulation knowledge to tailored missions that emphasize the consideration of combined effects, determination of second-order effects and communications with internal and external agencies.

Defending systems against attacks and recovering from attacks require the prioritization of assets to ensure that the physical processes continue to operate as intended. Safeguards should be in place prior to attacks and routine assessments should be performed to identify weaknesses. After an attack is identified, the system impact should be analyzed to prevent or minimize further damage. Recovering from an attack requires the ability to determine the root cause, eradicate malware if it is present and prevent the recurrence of the attack. Digital forensic capabilities are required to understand the details of an attack and its impact as well as gain intelligence about the attack and attacker.

The recommended training curriculum is tailored specifically to meet industrial control system requirements. Each training module should combine classroom lectures with significant hands-on laboratory projects. The training should begin with modules that cover industrial control system principles and provide exposure to actual systems and subcomponents. The next set of modules should cover control engineering principles and control theory, system design, instrumentation and the programming and configuration of field devices, applications and interfaces. Following this, the training should cover the intricacies associated with cyber attacks on industrial control systems and how targeted effects are achieved through cyber-initiated actions that manipulate physical processes. The training should also cover the prioritization of assets, defense strategies and recovery. The training should culminate in missionoriented activities that apply the knowledge gained in real-world scenarios tailored to industrial control operations.

Conclusions

Advanced training is required to ensure that cyber security and industrial control professionals can respond appropriately to sophisticated cyber attacks on industrial control systems and the critical infrastructure assets they monitor and operate. The evaluation of existing government and industry training courses has revealed shortfalls with regard to training facilities and training curricula. Current industrial control system security training relies on individual components, simulated environments or small-scale testbeds. Although these may be effective for beginner and intermediate levels of training, they are inadequate for advanced training, which must provide strong hands-on experience with real industrial control systems and physical processes. Unfortunately, current training facilities have few, if any, real-world systems and do not provide the ability to manipulate physical processes and measure attack impact.

To overcome the deficiencies, regional facilities are recommended that would support industrial control system security training that utilizes real-world systems. The training curricula should cover industrial control system principles, cyber manipulation and response coordination in learning environments that blend classroom lectures with hands-on projects involving real control systems and physical processes. Due to the significant costs and coordination that will be involved, active federal government sponsorship and participation are recommended. These investments are needed to ensure that adequate numbers of trained personnel are available to prevent and respond to cyber attacks that target industrial control systems and, by extension, the critical infrastructure.

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

-

  Control System Principles: -System functionality -Control theory -System architecture and operating requirements -Instrumentation devices -Field device components -Control and data acquisition -System applications -Communications and interconnections -Real-world configuration and deployment Cyber Manipulation: -Industrial control systems versus information and communications systems -Access vectors -Asset enumeration and identification -Field device, application and operating system analysis -Communications and protocol analysis -Recovering from attacks -Determining the root cause -Implementing safeguards to prevent recurrence -Analyzing attacks to obtain intelligence and insights -Evaluating defense strategies

Table 1 .

 1 Industrial control system (ICS) training environments.

	Government Industry

Table 2 .

 2 Industrial control system (ICS) training curricula.Analysis of Existing Capabilities. Several government and industrytraining programs for industrial control system security were evaluated. The training curricula were mapped to the core knowledge areas to identify shortfalls. Table2summarizes the findings. Note that "B" indicates that training is available that covers the requirements at a basic level with no practical applications; "I" indicates that training is available that covers the requirements at an intermediate level with practical applications; and "A" indicates that training is available that covers the requirements at an advanced level with in-depth practical applications.

	Government Industry

Acknowledgement

This research was partially supported by the Office of the Under Secretary of Defense for Personnel and Readiness.


Salima Benbarche

Catherine Strassel

Catherine Angénieux

Lea Mallo

Monique Freund

Christian Gachet

François Lanza

Henri De

La Salle

Dual role of IL-21 in megakaryopoiesis and platelet homeostasis

à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

1

MATERIALS AND METHODS

Antibodies. A PE-conjugated mouse anti-human CD34 antibody and its isotype control were purchased from Miltenyi Biotec and a PE-Cyanine7-conjugated anti-human CD34 antibody from eBioscience. Mouse anti-human CD41/CD61 (ALMA.17), CD42b (ALMA.12) and CD42d (V.1) and rat anti-mouse and human CD42c (RAM.1) antibodies were produced, purified and fluorochrome-conjugated in our laboratory [24][25][26][27]. Isotype controls, mouse IgG1 and rat IgG1 (R3-34), were from Sigma-Aldrich and BD Bioscience respectively. An APCconjugated mouse anti-human IL-21Rα antibody (17A12) and its isotype control were from

Biolegend. An unconjugated mouse anti-human IL-21Rα antibody (152504) was from R&D Systems. Alexa Fluor® (Alexa) 647-conjugated mouse anti-phospho-Stat3 (4/P-STAT3) and Alexa488-conjugated mouse anti-phospho-Stat5 (Clone 47) antibodies were from BD Bioscience. A biotinylated goat anti-mouse IgG antibody was from Beckman Coulter. The humanized and neutralizing anti-IL-21R monoclonal antibody ATR-107 was kindly provided by Pfizer Inc.

Human CD34 + cell isolation. Adult human peripheral blood cells were obtained with informed consent from healthy blood donors of the Etablissement Français du Sang-Alsace. The cells were recovered by elution from leukocyte depletion filters as previously described [28]. After 15 min incubation with RosetteSep® Human Granulocyte Depletion Cocktail (StemCell Technologies), mononuclear cells were isolated by Histopaque®-1077 (Sigma-Aldrich) density gradient separation for 30 min at 400g. CD34 + cells were separated from mononuclear cells using a CD34 MicroBead Kit and an AutoMACS™ device (Miltenyi Biotec). The purity of the CD34 + cells was greater than 85% as measured by flow cytometry. The cells were counted and their viability was determined using an automatic cell counter and propidium iodide exclusion (ADAM, Digital-Bio, Korea).

In vitro differentiation of MKs from human CD34 + cells. Adult human peripheral blood cells were obtained with informed consent from healthy blood donors of the Etablissement Français du Sang-Alsace. The cells were recovered by elution from leukocyte depletion filters as previously described [28]. CD34 + cells were separated from mononuclear cells using a CD34 MicroBead Kit and an AutoMACS™ device (Miltenyi Biotec). Batches of 40,000 viable CD34 + cells/mL were cultured for 7 days in StemSpan™ Serum-Free Expansion Medium, supplemented with 20 µg/mL human LDL and recombinant human (rh) cytokines (CC220 cocktail, containing TPO, IL-6, IL-9 and SCF), or when indicated rhTPO alone (all from StemCell Technologies). On day 7, aliquots of 50,000 viable cells/mL were seeded and differentiated for 6 days in fresh serum-free medium, supplemented with human LDL and rhTPO (30 ng/mL). rhIL-21 (PeproTech) was added at the indicated times and concentrations (see Results section). For experiments with JAK/STAT inhibitors, on day 7 the cells were washed and preincubated for 1 h in the culture medium containing the STAT3 inhibitor Stattic (300 nM) or JAK3 inhibitor Tofacitinib (1500 nM), or 0.25% DMSO vehicle (all from Sigma-Aldrich). Afterwards, rhTPO (30 ng/mL) or rhTPO + rhIL-21 (100 ng/mL) was added and the cells were cultured for a further 5 days.

For ATR-107 blocking experiments, CD34 + cells were cultured in the presence of TPO (30 ng/mL) +/-IL-21 (100 ng/mL) and 100 µg/ml human IgGs (for intravenous administration, Privigen). ATR-107 (100 ng/ml) was added on day 1 and 3 of the culture. Preliminary experiments showed that the addition of the IgG did not impact the differentiation of the cells into MKs (index of proliferation and % of CD41 + cells), as assayed on day 7 of the culture (data not shown).

All cultures were maintained at 37°C in a humidified 5% CO2 atmosphere.

CFU-MK assays. For human cells, CFU-MK assays were performed using a MegaCult™-C Complete Kit with cytokines (StemCell Technologies) according to the manufacturer's instructions. Briefly, 2,500 CD34 + cells were cultured in 750 µL of collagen-based medium containing TPO, IL-3 and IL-6, supplemented or not with rhIL-21 (100 ng/mL), in a humidified 5% CO2 atmosphere for 10 days. After methanol/acetone fixation, megakaryocytes were visualized with an anti-human CD41a antibody using alkaline phosphatase staining. Nuclei were counterstained with Evans blue. The stained colonies were counted under a Leica DMLB inverted microscope and 3 independent experiments were performed in quadruplicate.

For mouse cells, bone marrow cells were flushed from the femora, tibia and iliac crests with 2 mL of Iscove's 2% FBS medium, dissociated with a 23 gauge needle and filtered through a 40 μm cell strainer. CFU-MKs were grown on quadruplicate chamber slides in collagen-based MegaCult-C medium supplemented with rhTPO, rhIL-6 and rmIL-3 (StemCell Technologies) according to the manufacturer's recommendations. After 7 days, the cells were fixed in ice cold acetone and MK colonies were stained for acetylcholinesterase activity and counted under a Leica DMLB inverted microscope.

RT-PCR analyses. CD41/CD61 + cells were isolated on days 4, 7 and 10 of culture using the antibody ALMA.17 and magnetic beads (EasySep® "Do-It-Yourself" Selection Kit, StemCell Technologies). The purity of the CD41/CD61 + cells was greater than 90%, as measured by flow cytometry. Total RNA was extracted from freshly isolated CD34 + progenitors and cultured CD41/CD61 + cells using an RNeasy® Mini kit (QIAGEN). Aliquots containing 250 ng were reverse transcribed with SuperScript III Reverse Transcriptase (InVitrogen) in a final reaction volume of 30 μL. Samples (1 µL) of cDNA were amplified using iProof High Fidelity DNA polymerase (BIORAD) in a reaction volume of 20 μL, containing 0.2 mM dNTPs and 0.5 µM of each primer. The sense primers were 5'-GCTTTCTCAGACCCTCATCTGTC-3', 5'-CCTCTTATTCCTGCAGCTGCC-3' and 5'-GACTCAACACGGGGAAACT-3' and the antisense primers were 5'-CGTCCTTCAGCTCTTCATACTGG-3', 5'-TTGCATCTGTGTGGCCTGTCT-3' and 5'-ATTCCTCGTTGAAGAGCA-3' for IL21R, IL2RG and 18S respectively. The PCR products (5 µL) were separated on 2% (wt/vol) agarose gels and stained with 1/10,000 (v/v) GelRed Nucleic Acid Stain (BIOTIUM). Images of the stained gels were acquired using an ImageQuant 350 system and analyzed using ImageQuantTL software (GE Healthcare). The numbers of cycles were empirically determined so that the PCR products were generated during the linear phase of amplification; in practice 14, 31 and 28 cycles were used to amplify 18S rRNA and IL21R and IL2RG cDNAs, respectively. The identities of the RT-PCR products were confirmed by DNA sequencing.

Immunofluorescence microscopy. Human bone marrow specimens having a normal megakaryocytic lineage were obtained with informed consent from individuals undergoing bone marrow aspiration from the iliac crest. The samples were fixed in 2% paraformaldehyde for 4 h, cryoprotected in 10% and then 20% sucrose solutions overnight at 4°C, embedded in OCT medium and cryosectioned at 8 µm. Cultured megakaryocytes at day 13 of culture were fixed in 2% paraformaldehyde for 15 min and cytospun onto poly L-lysine-coated slides. The samples were blocked for 1 h in PBS containing 100 mM glycine, 10% normal goat serum (Vector Laboratories) and 5% human FcR blocking reagent (Miltenyi) and then with an avidin/biotin blocking reagent according to the manufacturer's instructions (Vector Laboratories). After incubation for 1 h at room temperature (RT) with an unconjugated antihuman IL-21Rα antibody or its isotype control, the sections were washed and incubated with biotinylated goat anti-mouse IgG for 30 min. After further washing and fixation with 1% paraformaldehyde for 10 min, endogenous peroxidases were inhibited by incubation for 30 min in methanol containing 3% hydrogen peroxide (Sigma-Aldrich). Peroxidase-labeled streptavidin (Immunotech) was added for 15 min and the staining was revealed by incubation with FITC Tyramide for 3 min (TSA PLUS Fluorescence Kit, Perkin Elmer). The sections were washed, blocked in PBS containing 2% normal rat serum (StemCell Technologies) and counterstained with an Alexa 555-conjugated anti-CD42c antibody in the same buffer at RT for 1 h. The slides were mounted using ProLong® Gold Antifade Reagent containing DAPI (Life Technologies) and examined under a confocal microscope (TCS SP5, Leica Microsystems).

Mice were sacrificed and the murine femora, spleens and livers were harvested and fixed overnight in 4% paraformaldehyde. Femora were decalcified in 10% EDTA in water (wt/vol, pH 7.4) at 4°C. The organs were cryoprotected overnight at 4°C in 10% and then 20% sucrose solutions and embedded in OCT medium and 8 µm thick cryosections were prepared. The sections were fixed in ice cold acetone for 2 min, blocked for 1 h in PBS containing 100 mM glycine, 10% normal goat serum (Vector Laboratories) and 5% mouse FcR blocking reagent (Miltenyi), labeled for 1 h with an F4/80 mAb in PBS 0.05% Tween containing 5% normal goat serum and revealed with Alexa 647-conjugated goat anti-rat IgG for 30 min. The washed sections were blocked for 30 min in PBS containing 2% normal rat serum (StemCell Technologies) and counterstained overnight with an Alexa 555-conjugated anti-CD42c antibody. The slides were mounted in ProLong® Gold Antifade Reagent containing DAPI (Life Technologies) and examined under a confocal microscope. Three 120 µm spaced sections from each organ were labeled and three immunofluorescence micrographs were taken from each section. Mosaic scans of transversal sections of the entire bone marrow were obtained using Leica Application Suite AF software. Quantitative analysis of the micrographs using ImageJ software enabled measurement of the CD42c and F4/80 positive areas in the spleen and liver and the density of MKs in the bone marrow.

Flow cytometry. Cultured cells were labeled with an Alexa 488-conjugated anti-CD41/CD61 mAb and an APC-conjugated anti-IL-21Rα mAb. The washed cells were resuspended in PBS containing 7-AAD and analyzed by flow cytometry. Washed human platelets were prepared from acid-citrate-dextrose anticoagulated blood obtained from healthy volunteers as previously described [29]. The platelets, in the resting state, activated with 1 U/mL thrombin for 10 min at 37°C, or fixed with 2% paraformaldehyde and permeabilized with 0.1% triton, were labeled with an APC-conjugated anti-IL-21Rα mAb and PE-conjugated anti-P-selectin or anti-CD63 antibodies for 15 min at RT. Signal transduction. After 7 or 12 days of culture, cells were washed, starved of cytokines for 5 h in a serum-free medium and then stimulated with 30 ng/mL TPO and/or 30 ng/mL IL-21 for 15 min at 37°C. Afterwards, the cells were fixed in 1.5% formaldehyde for 10 min, washed twice, permeabilized in ice-cold methanol and labeled with anti-CD41/CD61-ECD (PE-Texas Red), anti-phospho-STAT3-Alexa 647 and anti-phospho-STAT5-Alexa 488 antibodies for 30 min at RT. The washed cells were analyzed by flow cytometry. To measure their ploidy, anti-CD41/CD61-Alexa 488 and anti-phospho-STAT3-Alexa 647 labeled cells were stained in 50 μg/mL propidium iodide solution in the presence of 100 μg/mL RNAse A for 30 min at 37°C.

To inhibit IL-21R mediated signal transduction, ATR107 antibody (100 ng/ml) was added during the last 30 min of cytokine starvation. Cells were washed, stimulated with IL-21, then STAT3 phosphorylation was assessed using the same protocol.

Analysis of the phenotype of MKs. On days 7 and 12 of culture, cells were incubated for 2 h at 37°C with Hoechst 33342 and then stained with anti-CD34-PE-Cy7, -CD41-PE, -CD42c-Alexa 488 and -CD42d-Alexa 647 mAbs. The washed cells were resuspended in PBS containing 7-AAD and analyzed by flow cytometry.

Quantification of platelet release. On day 13 of culture, 1 µmol/L prostaglandin E1 (Sigma-Aldrich) and 0.02 U/mL apyrase, purified from potatoes as previously described [29], were added to the culture medium and the cells were subjected to repetitive pipetting as previously described [30]. The cells were then labeled with anti-CD41/CD61-Alexa 647 and anti-CD42c-Alexa 488 antibodies for 15 min at RT before direct analysis by flow cytometry. Platelets released during culture were identified as CD41/CD61 and CD42c double positive events having the same scattering properties as human blood platelets.

Analysis of murine bone marrow MK progenitors. Bone marrow cell suspensions were stained with biotinylated rat antibodies against mouse Ly76, Ly6G, CD11b, CD45R (B220), CD3e, CD5, CD4, CD8a, Ly6A and IL7Rα chain (all from eBioscience), counterstained with streptavidin-APC-Cy7 and then directly labeled with rat anti-mouse CD9-FITC, CD16/32-PE, CD150-PE-Cy7, CD105-PerCP 5.5 and cKit-APC. The cells were resuspended in PBS containing 0.4 ng/mL DAPI (Invitrogen) and analyzed by flow cytometry.

Samples were analyzed on a Gallios cytometer or a BD LSRFortessa cytometer and the acquired data were analyzed with respectively Kaluza software (Beckman Coulter) or BD FACSDiva software (BD Biosciences).

Quantification of proplatelet-bearing human MKs and of platelet release. On day 13 of culture, cells were examined under an inverted microscope (Axio Vert A1, Zeiss) coupled to a camera (AxioCam ERc 5c, Zeiss). Images of ten different wide fields in the culture wells (24 well plates) were acquired and round and proplatelet-bearing MKs were counted. On day 13 of culture, 1 µmol/L prostaglandin E1 (Sigma-Aldrich) and 0.02 U/mL apyrase were added to the culture medium and the cells were subjected to repetitive pipetting as previously described [30].

In vivo experiments in mice. Wild type C57BL/6J mice were obtained from Charles River Laboratories, while the HR35 mouse strain (C57BL/6J background) ubiquitously expressing EGFP under the control of the beta-actin promoter was kindly provided by P Chambon (Strasbourg).

For in vivo expression, murine IL-21 cDNA was cloned into the pLIVE expression vector under the albumin promoter (Mirus Bio LLC). For hydrodynamic transfection, 2 mL of TransIT®-EE Delivery Solution (Mirus Bio LLC) containing empty or recombinant plasmids (10 µg/mL) were intravenously injected into 18 to 20 g male C57BL/6J mice (Liu et al., 1999). At the indicated times, plasma samples were prepared from EDTA-anticoagulated blood and stored at -80°C.

The plasma concentration of IL-21 was measured by enzyme-linked immunoadsorbent assay (Mouse IL-21 ELISA Ready-SET-Go!®, eBioscience).

Mouse platelets. Blood samples were collected into EDTA anticoagulant (6 mM) from the tail of isoflurane-anesthetized mice. Platelet counts were determined using a Scil Vet abc Plus+ analyzer (HORIBA Medical). The blood samples were labeled with anti-IL-21Rα-PE and anti-CD42c-Alexa 488 in the presence of an Fc blocking reagent. The percentage of reticulated platelets was determined by adding 2 µL of whole blood to 50 µL of PBS containing 6 mM EDTA, 1 µg/mL Thiazole Orange (Sigma-Aldrich) and 0.5 µg/mL anti-CD42c-Alexa 647. After incubation for 15 min, the cells were fixed in 500 µL of 1% paraformaldehyde and immediately analyzed by flow cytometry (a representative analysis is shown on Supplementary Figure 7).

To measure platelet survival, washed EGFP + platelets (1.2x10 6 platelets/μL) were prepared from HR35 mice as previously described (Cazenave et al., 2004) and retro-orbitally injected into isoflurane-anesthetized mice, 5 days after hydrodynamic transfection (100 µL per mouse).

The ratio of EGFP + transfused to EGFP -endogenous platelets was determined by flow cytometric analysis of EDTA-anticoagulated blood samples drawn at the indicated times. adding 1 ml 1% paraformaldehyde and analyzed by flow cytometry within 45 min. (B) A mix containing thiazole orange, Alexa 647-conjugated anti-P-Selectin or JONA-PE antibody (anti-activated GpIIbIIIa) was added to platelet suspension (10 µL each). Then, 5 µL 5 times concentrated agonist (AYPGKF peptide and U46619, PAR4 and thromboxane receptor agonist, respectively) in plain Tyrode buffer or the buffer alone were added. Platelets were incubated for 15 min at 37°C, then the reaction was stopped by adding 50 µL PAF 1.5% containing RAM1 mAb (anti Gp1bβ) conjugated to Alexa 555 (used in combination with anti-P-selectin labeling) or to Alexa647 (used in combination with JONA-PE mAb).

Statistics

The percentages of activated platelets were determined by flow cytometry within 45 min. Mean ± SD values are reported, n=3.

.

  All values are reported as the mean ± SEM. Statistical analyses were performed with GraphPad software (Prism Version 5.0) using Student's t test, or 1-way or 2-way ANOVA and a Bonferroni post-test. The level of statistical significance was set to P<0.05. Study ethics. The human studies were performed according to the Helsinki Declaration. Experiments were performed using residue of samples from individuals who had given their written informed consent. Mice were housed and murine experiments were performed according to the French regulations and, was approved by the Regional Ethic Committee for Animal Experimentation of Strasbourg, C.R.E.M.E.A.S.(CEEA 35). the detection, i.e. <64 pg/ml, thus were not depicted. Mean ± SEM values are reported, n=7.

Supplementary Figure 1. Expression of IL-21R on in vitro differentiated megakaryocytes

or blood platelets. A, CD34+ progenitors were differentiated into megakaryocytes under standard conditions (Figure 1A, Scheme 1, without IL-21). On day 13 on the culture, cells were cytospun, fixed and then immunostained as described for bone marrow megakaryocytes (left, anti-IL-21R, right anti-CD42c). Scale bar, 20 µm. B, Freshly isolated human blood platelets were immunolabeled with anti-IL-21Rα-APC and anti-P-selectin-PE antibodies, in the resting state or after thrombin stimulation, and with an anti-CD63-PE antibody after fixation and permeabilization. The flow cytometry histograms are representative of three independent experiments. were fixed in cold ethanol, treated with RNase, stained with propidium iodide, as described in the method section for human MKs. Values are reported as the mean ± SEM (n=4 or 5). (B)

Supplementary

Bone marrow Lin -cells (2 10 6 cells/ml) were cultured for 3 days in the same conditions, with or without IL-21 and/or ATR-107 (1µg/mL) and analyzed as in A (n=4). ATR-107 was used at a higher concentration to compensate for the 8 fold higher value of its KD with respect to mouse IL-21R, as compared to human IL-21R.

Supplementary