Megan Leierzapf

Julian Rrushi

NETWORK FORENSIC ANALYSIS OF ELECTRICAL SUBSTATION AUTOMATION TRAFFIC

Keywords: electrical substation automation traffic Megan Leierzapf, Julian Rrushi Industrial control systems, malware, digital forensics

Introduction

As the recent BlackEnergy and Dragonfly malware campaigns have demonstrated, industrial control systems (ICSs) are continually targeted by malware that spies on or disrupts industrial processes, including those in the electric power grid. Digital forensic investigations of incidents involving industrial control systems are, therefore, of considerable importance [START_REF] Ahmed | SCADA systems: Challenges for forensic investigators[END_REF][START_REF] Wu | Towards a SCADA forensics architecture[END_REF]. This chapter focuses on investigations of intrusions in intelligent electronic devices (IEDs), which are control devices deployed in electrical substations.

The principal contribution is a network forensic approach that leverages graph theory and time series analysis to identify malicious packets in substation automation network traffic. A model graph is used to comprehensively model intelligent electronic devices, their monitoring and protection functions, state of the electrical substation and network traffic that the intelligent electronic devices exchange with each other while performing their functions. The time series analysis helps compute the weights of the edges in the model graph, which characterize the relationships of network traffic with time. The same graph modeling approach is employed to construct graphs that model real network traffic in a substation automation network. Custom Python scripts are used to analyze packet capture (pcap) files and help construct adjacency matricesspecifically, concrete graphs -based on captured network packets.

Concrete graphs developed from normal network traffic are subgraphs of the model graph, assuming, of course, that the vertices, edges and weights in all the graphs are computed accurately. Experiments with emulated exploits and malware, including samples used in the Dragonfly industrial control system malware campaign (Havex), demonstrate that concrete graphs developed from their network traffic do not correspond to subgraphs of the model graph. This feature is leveraged to discern malicious packets in large traffic captures from substation automation networks. The novel contribution is a network forensic approach that considers the topological and timing characteristics of intelligent electronic devices induced by the power system.

Problem Statement

The research problem involves the dissection and forensic analysis of network traffic from an electrical substation network in order to reliably separate network packets generated by malware from packets generated by intelligent electronic devices during their normal monitoring and protection functions.

The inputs comprise the following data:

A log file containing the physical parameter values of an electrical substation of interest over time as measured by various sensors. Examples of physical parameters include voltages, currents, temperatures, phases, frequencies and amplitudes.

A network capture file in pcap format that contains traffic captured from the electrical substation network. Each packet is timestamped, as it is commonly the case when network traffic is captured with a tool such as Wireshark.

The outputs comprise the following data:

A file in pcap format that contains all the network packets that the forensic analysis has determined to have been generated by malware.

A second pcap file that contains only the network packets that the forensic analysis has determined to have been generated by intelligent electronic devices as part of their normal operation.

The proposed network forensic approach leverages the logical coupling between intelligent electronic device functions and the state of the power system. This coupling is inherent in an electrical substation. The analysis is conducted based on the IEC 61850 network communications standard.

Intelligent electronic devices do not exercise a directional comparison protection function based on so-called PDIR logical nodes if the forward and reverselooking instantaneous directional overcurrent or distance elements at each line terminal do not activate the directional comparison scheme in use. If the directional comparison protection function is not exercised, then no network packets are exchanged, except for packets that carry periodic parameter measurements. Otherwise, if the parameters cause the activation of the directional comparison scheme, then the intelligent electronic devices generate network traffic that include commands that trip one or more circuit breakers.

A similar observation applies to the distance protection function for so-called PDIS logical nodes, directional overpower for so-called PDOP logical nodes and, in fact, all the other protection functions performed by intelligent electronic devices in an electrical substation.

Srivastav et al. [START_REF] Srivastav | Exploratory analysis of Modbus and general IT network flows in a water SCADA system[END_REF] have discussed the regularities existing in industrial control network traffic. Unlike conventional information technology network traffic that fluctuates at high values, industrial control network traffic is relatively stable and somewhat predictable. The proposed forensic approach deciphers the relationships between the power system state and the network traffic generated by intelligent electronic devices. It engages these relationships to distinguish between normal and malicious traffic.

Graph Construction

This section describes the construction of the model and concrete graphs.

Model Graph Construction

The model graph formally describes normal network traffic in a substation automation network. Each vertex in the graph represents a pair comprising an intelligent electronic device and its monitoring or protection function. The model graph is directed and weighted. An edge from vertex A to vertex B represents network traffic between the intelligent electronic devices represented by vertices A and B, respectively. An intelligent electronic device can be the source or destination of network packets. However, the intelligent electronic device represented by vertex A is the initiator of the network communications; specifically, this device should have initiated the TCP three-way handshake by transmitting a packet with the TCP SYN flag set. In another scenario, the intelligent electronic device represented by vertex B could initiate network communications with the intelligent electronic device represented by vertex A.

However, all the network traffic in the associated TCP session is represented by an edge from vertex B to vertex A, regardless of which devices are the sources and destinations of specific packets in the session.

When the device represented by vertex A sends a UDP packet to the device represented by vertex B as it begins to exercise a function and, thus, possibly trigger the exchange of other UDP packets, then the edge goes from vertex A to vertex B. Each edge in the model graph has a weight that is determined via time series analysis. Every intelligent electronic device in an electrical substation has a set of monitoring and protection functions that it can perform; this increases the number of vertices present in the model graph. For example, if an electrical substation has just three intelligent electronic devices, each with the ability to execute 200 functions, there would be a total of 600 vertices in the model graph corresponding to this rather small electrical substation. As discussed later, knowledge of the specific monitoring and protection functions performed by an intelligent electronic device is of utmost importance.

Exploits and malware that affect an intelligent electronic device can only send or receive network traffic associated with the monitoring and control functions performed by the device. Otherwise, their malicious network packets would stand out and be trivial to spot.

Consider a situation where an intelligent electronic device is supposed to exercise a transformer protection function (and no other function) at time t x for 4 ms. To conceal malicious network traffic, malware running on or targeting the intelligent electronic device could only send or receive traffic at time t x , and typically not longer than 4 ms. If the intelligent electronic device in question is not supposed to exercise any functions at time t x , then it would not send or receive any traffic at time t x . As a result, the malicious network traffic would stand out.

An intelligent electronic device is a real-time machine, meaning that its reaction time is almost instantaneous. However, there is a minuscule delay in the transmission of its response to an anomalous event. The time taken for the intelligent electronic device to exercise its monitoring and protection functions is known; the expected time may be expressed as a range (e.g., 1 to 4 ms). However, if the network traffic continues to flow for 5 ms or longer, there is a high likelihood that some of the traffic was generated by malware. The malware traffic may not exhibit the typical patterns of electrical substation traffic. Thus, small differences in network activity could be very useful in identifying malicious network traffic.

Monitoring and protection functions are exercised by intelligent electronic devices under a specific set of physical parameter values in order to protect electrical substation equipment. The reporting of the parameter values by sensors is time critical because the intelligent electronic devices must perform their tasks in a timely manner [START_REF] Brand | How to use IEC 61850 in protection and automation[END_REF]. An example protection function is the redirection of power. If a tree were to fall on a power line and cause a power outage, the protection function would redirect the power around the fallen line to deliver power to the affected customers. The power transformer protection function switches off a power transformer in an electrical substation when an internal fault is detected. Switching off the transformer has the effect of protecting it; if the power transformer were to be unprotected, it would explode in the worst-case scenario.

An internal fault is detected by comparing the primary and secondary currents. If the currents exceed the computed thresholds, then a fault is assumed and the transformer is switched off. Rahman and Jeyasurya [START_REF] Rahman | A state-of-the-art review of transformer protection algorithms[END_REF] have experimented with several power transformer protection function algorithms; the curve fitting, rectangular transform, Fourier and finite impulse response algorithms were determined to be feasible for implementation in microprocessorbased transformer differential relays. For the power redirection and power transformer protection functions mentioned above to be exercised by intelligent electronic devices, it is necessary for the relevant sensors to report anomalous power system states, namely certain ranges of physical parameter values that characterize the physical processes of the substation.

The two protection functions are exercised by intelligent electronic devices only when the sensor values are in the stipulated ranges. This consideration applies to all monitoring and protection functions. Clearly the physical parameter values are not important to malware; as a result, malware does not adhere to the same structural and time restrictions that the substation protection functions must satisfy. Knowledge of some essential characteristics of the electrical substation of interest helps identify information that is used to create the model graph. Two pieces of critical information are the intelligent electronic devices and the specific functions they can exercise. These enable the determination of the vertices and edges in the model graph.

Two methods may be used to determine the model graph vertices and edges. The first method is to examine the configuration files of the intelligent electronic devices. The configurations indicate the functions that are exercised by the devices and the other intelligent electronic devices with which the devices exchange network traffic while exercising their functions. The drawback of this method is that significant manual effort is required to develop the vertices and edges corresponding to all possible functions exercised by all the intelligent electronic devices in a substation.

The second method is to write code that observes normal substation automation network traffic and learns the vertices and edges. The drawback of this method is that some functions are exercised very infrequently; thus, observing normal network traffic even for long periods of time may not be enough to discern the rarely-implemented functions. The proposed approach combines the two methods; it applies machine learning to network traffic only to compute the weights of the edges in the model graph.

Fiigure 1 shows a small portion of a model graph associated with an electrical substation. The edge weights are integer values to simplify the presentation. The substation has three intelligent electronic devices, 1, 2 and 3, each with two functions, A and B. Decisions about when to exercise the functions are made based on the reported values of ten physical parameters. Six vertices are required to develop this portion of the model graph, one for each (intelligent electronic device, function) pair.

It was decided to construct the model graph in this manner because the intelligent electronic devices and functions had to be expressed explicitly. Using a single vertex for each intelligent electronic device was not an option because there can only be one directed edge from an origin vertex to a destination vertex. If this approach had been employed, the time series analysis would have represented all the network packets from an origin device to a destination device relative to all the monitoring and protection functions implemented by the two devices. As a result, it would not be possible to discern which functions were exercised and when they were exercised, making it exceedingly difficult to identify malicious network traffic.

In the model graph, physical parameters are directly used when defining each vertex; in fact, the monitoring and protection function modeled by a vertex depends entirely on the physical parameters. The reasoning is as follows: if the physical parameter values of a power system warrant a specific monitoring and control function being exercised by an intelligent electronic device, then a vertex exists and this vertex has an edge with a weight that connects it with another vertex. The model graph covers all the possible states of a power system where the states are expressed in terms of physical parameter value ranges. This is one more reason why the model graph can be extremely large.

Concrete Graph Construction

A concrete graph is constructed from the network packets contained in a pcap file. It is not known a priori whether the network packets are normal or malicious. Furthermore, if the pcap file contains malicious network packets, it is not known which packets are malicious and which packets are normal. The forensic analysis involves the construction of the concrete graph and the use of subgraph isomorphism search to determine the malicious and normal packets.

The vertices of the concrete graph are determined by examining the headers of the packets for the source and destination IP addresses. The IP addresses help identify the intelligent electronic devices that were senders or receivers of network traffic. The pcap files are timestamped, which enables the determination of the times when network traffic began to flow in the substation automation network.

The concrete graph is constructed by referring to a log file that contains the physical parameter values over time as measured by the sensors. The pcap file containing network traffic is then examined. The physical parameter values are used to determine the monitoring and protection functions that the addressed intelligent electronic devices exercised at specific times that the network traffic was recorded. The vertices in the concrete graph are marked based on the identified monitoring and protection functions and the IP addresses observed in the network traffic. The source and destination IP addresses identify the two intelligent electronic devices involved in a TCP session and the specific device that started the TCP session or initiated UDP communications. This information is sufficient to define all the edges of the concrete graph. The weights of the edges are computed via time series analysis as in the case of the model graph.

A concrete graph is compared against the model graph using subgraph isomorphism search. Checking for isomorphism between the concrete graph and a subgraph of the model graph relies on a graph theoretic technique (see, e.g., [START_REF] Ullman | An algorithm for subgraph isomorphism[END_REF]). Graph isomorphism is a topic that has been researched for decades; a number of algorithms and library implementations for subgraph isomorphism search have been developed.

Figures 2 and3 show two concrete graphs constructed from traffic in the same network as the partial model graph shown in Figure 1. The edge weights were again chosen to be integer values to simplify the presentation. The concrete graph in Figure 2 was determined to be a subgraph of the model graph; therefore, the captured network traffic represented by the concrete graph was not malicious.

On the other hand, in the case of the concrete graph in Figure 3, the weight of the edge from the origin vertex (1, A) to the destination vertex (2, B) is 5, which is not the same as in the partial model graph in Figure 1. This implies that the concrete graph is not a subgraph of the model graph and the network traffic is, therefore, determined to be malicious. The physical parameter values when intelligent electronic devices exercise their monitoring and control functions provide additional clues to whether or not traffic is malicious. Specifically, if the physical parameter values are within the normal ranges and monitoring and control functions are still exercised (i.e., unnecessarily), then malicious network activity has occurred.

Time Series Analysis

This section demonstrates how time series analysis is used to compute the weights of the edges in the model and graphs.

Intelligent electronic devices in an electrical substation perform computations and send/receive network traffic in a manner that exhibits strong dependencies on time and the power system state. The logical nodes in intelligent electronic devices do not act randomly. Each possible state of the power system demands that specific intelligent electronic devices exercise specific functions (i.e., manifest specific logical nodes) and these functions are carried out within specified time thresholds. The time constraint (threshold) imposed on a function demands that a logical node in an intelligent electronic device distributes all its function computations and I/O processing (and the traffic it transmits to other intelligent electronic devices) over time such that it satisfies the time threshold.

Experimental research in a laboratory environment has determined that the distribution of computations and I/O processing of a logical node in an intelligent electronic device over time is predictable. Certain fluctuations are observed in the times that network traffic sent by an intelligent electronic device on behalf of a logical node or logical device; however, the fluctuations are within predictable ranges. If this were not the case, intelligent electronic devices would send network traffic to each other too late, failing to meet the time thresholds of the overall monitoring and protection functions represented by the logical nodes. The relationship between network traffic and time for each monitoring and protection function exercised by an intelligent electronic device helps increase the granularity of the graph representation of substation automation network traffic. Thus, the crucial knowledge includes not only the direction and structure of the communications between one intelligent electronic device and another, but also the time characteristics of the network communications between the devices involved in a monitoring and protection function.

The weight of an edge from an intelligent electronic device A to another intelligent electronic device B is computed by developing a time series of all the network traffic that A sends to B and all the network traffic that B sends to A in response when a monitoring and protection function is exercised. If B is the initiator of the traffic that it sends to A, then this traffic and the traffic that A sends B in response are associated with a different time series. This is because, there is an edge from vertex A to vertex B and another edge from vertex B to vertex A.

The time series comprises the observations of network payloads sent at time t and excludes the packet headers. In other words, the observed data corresponds to a set of data of size x t sent at time t. Note that these observations are made of network traffic sent by intelligent electronic devices over a substation automation network that is not under attack.

Thus, the proposed network forensic approach has anomaly detection characteristics in that there is a learning phase involving normal network communications between intelligent electronic devices. This learning phase requires a network capture file in the pcap format that is obtained by passively -and thus safely -sniffing substation automation network traffic (e.g., using Wireshark). The choice of timestamp precision is critical to the construction of the time series. Since the time window of most monitoring and protection functions ranges from zero to the time thresholds set for the functions (e.g., 4 ms), the timestamp precision in the proposed approach was set in the order of microseconds and the time unit was set to 100 ms. Thus, the time series of a monitoring and protection function would typically go from t = 0 to at most t = 40.

Time series with longer time windows may be constructed if there is enough network traffic. This is rarely the case for normal substation automation network traffic, but it is more likely for malware traffic. The time series constructed are discrete in that the sets of times t at which observations are made of packet payloads x t are discrete.

The observations of network traffic over time are cumulative. If device A sends 500 bytes of data to device B at time a and device B responds with 300 bytes of data at time b, then x a = 500 and x b = 800. The time series is viewed according to the classical decomposition model:

x t = w t + s t + y t (1)
where the w t component of the observed x t is the trend in the time series terms and is the factor that is leveraged by the proposed approach; s t corresponds to the seasonality, which was noticeably absent in the time series encountered in the experiments; and y t is the residual component in the time series terms.

The trend w t is deterministic and is characteristic of a specific time series. This makes the trend a desirable differentiator. Given that the trend is specific to the time series representing normal network traffic for a monitoring and protection function, its value over time would differ from the trend in a time series representing malicious network traffic. Note that the trend w t of the time series representing normal network traffic is computed during the learning phase. The weight of the edge that goes from device A to device B is set to be a vector of trend values w t , namely [w 1 , w 2 , ..., w n ] where n is the end of the time window. During actual network forensic analysis, the time series of the unknown traffic to be analyzed is computed, the trends of each of the time series are calculated and the weight of the corresponding edge is then determined. The trend of a time series is computed using the least-squares estimation method. The model trend is first expressed as a quadratic function of time:

w t = β 0 + β 1 t + β 2 t 2 (2)
Next, the quadratic function of time is fit to the network traffic and the values of the parameters β 0 , β 1 and β 2 are determined by minimizing the following equation:

n t=1 (x t -(β 0 + β 1 t + β 2 t 2 )) 2 (3)
The optimal values of β 0 , β 1 and β 2 are used to compute the trend w t at each t according to Equation (2), yielding the final edge weight. Note that perfect matches between edge weights in the model and concrete graphs are neither sought nor desired. This is because fluctuations are normal and are, indeed, expected. In fact, the subgraph isomorphism search algorithm looks for weights that deviate substantially from those in the model graph.

Experimental Evaluation

The experiments leveraged a testbed with protective relays that emulated a real-world electrical substation. Table 1 summarizes the main components of the testbed along with their functions and communications protocols. The SEL-487E-3 device is a protective relay designed to monitor and protect a power transformer from electrical faults; it runs intelligent algorithms that detect various types of faults and take actions in timely manner by operating electrical circuit breakers and disconnect switches. The SEL-421-4 device performs industrial automation functions; it comprises 32 programmable elements for local control, remote control, automation latching and protection latching. It also performs various functions that protect overhead electrical transmission lines and underground cables. The SEL-3355 device performs multiple substation functions; it has an integrated human-machine interface (HMI) with a local display port. In the experiments, the SEL-3355 device was used as a real-time automation controller. The SEL-3355 polled the SEL-487E-3 and SEL-421-4 for substation data. The network communications between these industrial control devices employed the IEC 61850 protocol.

The experimental testbed incorporated a Windows platform hosting an Object Linking and Embedding (OLE) for Process Control (OPC) server [START_REF] Lange | OPC: From Data Access to Unified Architecture[END_REF], which executed an IEC 61850 protocol driver to obtain substation data (including decoy data) from the protective relays. The IEC 61850 protocol driver subsequently stored the substation data in the OPC server. The testbed also incorporated an OPC client running under Windows; the OPC client application provided a graphical user interface for a human operator to enter OPC commands. Another Windows machine was used for development and testing. All the machines and devices in the experimental testbed were connected via a local area network.

The experiments validated the proposed approach using malware samples involved in the Dragonfly cyber espionage campaign. Several versions of the Dragonfly malware exist; the malware samples used in the experiments were obtained from public malware research repositories. Versions of the Havex industrial control system malware were also used; these were of particular interest because they use the OPC protocol.

The experiments emulated malware propagation and execution in a substation automation network. The experiments used the nmap tool to scan for the IP addresses of intelligent electronic devices and their network services. The vulnerability exploitation phase involved code that targeted several memory vulnerabilities using shellcode injection and heap spraying on intelligent electronic devices. Two exploitation scenarios were implemented, one where the malware had no prior knowledge of the power system state and the other where the malware was able to obtain complete knowledge about the power system state before launching its attacks.

The experiments also emulated the malware installation phase, which involved the injection and execution of a dropper on a compromised intelligent electronic device. As with traditional malware, the dropper was responsible for installing malware modules on the compromised intelligent electronic device. Single-stage and dual-stage dropper were emulated. The single-stage dropper incorporated the emulated malware modules that were installed on the compromised intelligent electronic device whereas the dual-stage dropper downloaded the modules from another compromised machine over the network.

Traffic associated with the network scans and test exploit that operated without any prior knowledge of the power system state produced visible struc- tural deviations from the model graph. The target selection was random as were the times when the network probes and test exploit were launched. Even when the launch time coincided (by chance) with the time that a protection function was exercised by an intelligent electronic device, the structural deviations from the model graph caused the subgraph isomorphism search algorithm to fail. Thus, no further time series analysis was necessary in the subgraph isomorphism search.

The time series analysis became necessary when the network scans and test exploit operated with full knowledge of the power system state. The network probes and test exploit were launched at the time that a power transformer protection function was exercised by the intelligent electronic devices. Furthermore, the probes and exploit were launched from a compromised intelligent electronic device to another intelligent electronic device, both of which were exchanging network traffic when the power transformer protection function was exercised. The graph structure of the network traffic matched that of the model graph. However, as shown in Figure 4, time series analysis detected deviations in the trend. This was due to the test exploit generating large quantities of network traffic when performing its heap sprays. Its time window also extended beyond the maximum 4 ms time window of the power transformer protection function. The subgraph isomorphism search failed because the edge weights in the concrete network traffic graph deviated substantially from those in the model graph.

When malware installation was performed without any knowledge of the power system state, the network traffic caused by the dropper did not match a valid power system protection function (unless a coincidence occurred). The mismatch of the network traffic and substation protection function caused the subgraph isomorphism search to fail, resulting in the immediate detection of the malicious network packets.

A challenging situation for a defender occurs when the network traffic caused by the dropper is interwoven with the network traffic of a valid protection function. If the dropper were to be downloaded on a compromised intelligent electronic device with a high degree of mimicry, then the structural properties of the concrete graph would match those in the model graph. Since the network traffic would appear to be consistent with the substation protection function, the subgraph isomorphism search would have to rely on the time series analysis of the network traffic.

The weights in the concrete graph corresponding to the single-stage dropper deviated considerably from the weights in the model graph. The single-stage dropper incorporated several malware modules and, thus, its downloading on the compromised intelligent electronic device was characterized by heavy network traffic and the higher trend shown in Figure 5. In contrast, because the dual-stage dropper was a thin client module that downloaded the malware modules over the network at a later time, much less traffic was observed than in the case of the single-stage dropper. Nevertheless, the time series in Figure 5 shows large deviations for the single-stage dropper and dual-stage dropper network traffic from the network traffic corresponding to a power transformer protection function.

The nmap tool and Havex malware generated network traffic with strong deviations in the trends, which caused the subgraph isomorphism searches to fail. The deviations in the trends were similar to the trends shown in Figures 4 and5. The concrete graphs constructed from nmap and Havex network traffic as well as those constructed with the majority of the emulated malicious activities also demonstrated structural deviations from the model graph, which again caused the corresponding subgraph isomorphism searches to fail. Typical failures resulted from network traffic being sent to intelligent electronic devices that were not supposed to participate in the exercising of a function; this created additional vertices and edges in the concrete graphs, causing the subgraph isomorphism searches to fail. Figures 6 and7 present portions of concrete graphs corresponding to normal traffic and malicious traffic, respectively. In general, the concrete graphs constructed from normal network traffic were easily determined to be subgraphs of the model graph.

Conclusions

The proposed network forensic approach treats an electrical substation as a cyber-physical system and explores its strong interrelations to develop a model graph that deeply characterizes the structural and timing properties of normal network traffic in the substation automation network. A similar concrete graph is constructed for unknown (potentially) network traffic. Unlike authorized code that executes on intelligent electronic devices, exploit code and malware generate network traffic that deviates from the monitoring and control tasks performed in an electric power system. In particular, the traffic generated by malicious code has structural and timing properties that differ from those of normal traffic. Thus, the problem of determining whether or not unknown network traffic is malicious involves a subgraph isomorphism comparison of the concrete graph against the model graph. Normal network packets yield a concrete graph that is a subgraph of the model graph whereas malware-generated network packets produce a graph that is not a subgraph of the model graph. Experiments involving real industrial control system malware demonstrate that the resulting approach can reliably identify malicious packets in large traffic captures from a substation automation network.

Figure 1 .

 1 Figure 1. Sample model graph.

Figure 2 .

 2 Figure 2. Sample concrete graph of normal activity.

Figure 3 .

 3 Figure 3. Sample concrete graph of malicious activity.

Figure 4 .

 4 Figure 4. Time series trend comparison results for a test exploit.

Figure 5 .

 5 Figure 5. Time series trend comparison results for a test malware installation.

Figure 6 .

 6 Figure 6. Excerpt topology of a concrete graph of normal network activity.

Figure 7 .

 7 Figure 7. Excerpt topology of a concrete graph of malicious network activity.

Table 1 .

 1 Testbed device functions and communications protocols.

	Machine	Function	Protocol
	SEL-487E-3	Transformer protection relay IEC 61850
	SEL-421-4	Automation, protection	IEC 61850
	SEL-3555	Automation, data, HMI	IEC 61850
	Windows Server	OPC server	OPC, IEC 61850
	Windows Client	OPC client	OPC
	Windows Machine Development, testing	OPC, IEC 61850

Acknowledgement

This research was supported in part by Defence R&D Canada and by the U.S. Office of Naval Research under DURIP Contract No. N00014-15-1-2891.


Joshua Lubell

Timothy Zimmerman

Challenges to automating security configuration checklists in manufacturing environments

Keywords: Manufacturing environments, control systems, security, checklists 1

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.

Introduction

Information technology is essential to today's manufacturing systems. Microprocessors, software, data repositories, networking protocols and the Internet improve product quality, increase throughput and reduce production costs. But the increased reliance on information technology makes manufacturing environments more vulnerable to cyber security threats than ever before. A cyber attack can cause a loss of confidentiality, data corruption and costly downtime. An additional consequence for manufacturing systems -as with Stuxnet [START_REF] Byres | How Stuxnet Spreads -A Study of Infection Paths in Best Practice Systems[END_REF] and the German steel mill cyber attacks of 2014 [START_REF] Lee | German Steel Mill Cyber Attack, ICS CP/PE (Cyber-Physical or Process Effects), Case Study Paper[END_REF] -is extensive physical damage to equipment and the surrounding environment. Physical and environmental damage can, in turn, result in personal injury or death as well as large financial losses.

Proper security configurations reduce the likelihood of a cyber attack compromising a system, with the added benefit of protecting against incidents caused by (non-malicious) human errors. Configuration settings such as password and remote access policies, authorizing only the minimum access needed by users or processes to accomplish assigned tasks (least privilege principle) and restricting communications between subsystems and external systems (boundary protection principle) help improve the security posture [START_REF] Creery | Industrial cybersecurity for power system and SCADA networks[END_REF]. The least privilege and boundary protection principles are included in the hundreds of security controls specified in National Institute of Standards and Technology (NIST) Special Publication 800-53, Recommended Security Controls for Federal Information Systems and Organizations [START_REF]Security and Privacy Controls for Federal Information Systems and Organizations[END_REF].

The U.S. Department of Homeland Security 2016 Industrial Control Systems Assessment Summary Report [START_REF]/Industrial Control Systems Cyber Emergency Response Team[END_REF] underscores the importance of proper configurations of control systems in manufacturing and industrial environments. According to the report, among the most common areas of weakness are the lack of adherence to the least privilege and boundary protection principles, poor authentication mechanisms and weak passwords. The right configuration settings can mitigate these vulnerabilities.

The U.S. National Checklist Program [START_REF] Quinn | National Checklist Program for IT Products -Guidelines for Checklist Users and Developers[END_REF] defines a security configuration checklist -also referred to as a hardening guide or security benchmark -as "a series of instructions or procedures for configuring an information technology product to a particular operational environment, for verifying that the product has been configured properly and/or for identifying unauthorized changes to the product." Because such checklists provide guidance that is both concrete and actionable, they are especially useful to smaller companies and organizations that lack in-house cyber security expertise. A checklist may be automatable so that it can be used as digital input to a software tool that reports how well a system is configured with respect to the checklist's guidance. Automated security configuration checking is highly desirable because it reduces the costs of maintaining security and documenting the extent of compliance with a security policy.

To facilitate automation, a checklist should contain structured, computerinterpretable digital data. Furthermore, the tool that interprets the checklist should implement the data models used in the checklist. In other words, in order for a tool to automate a checklist, the tool should parse and process the data structures used in the checklist's digital representation. In this manner, the structured information in an automatable checklist serves as a "digital thread" [START_REF] Hedberg | Testing the digital thread in support of model-based manufacturing and inspection[END_REF] for cyber security [START_REF] Lubell | Extending the cybersecurity digital thread with XForms[END_REF] that integrates configuration guidance with system-specific settings. Additionally, the digital thread can associate a configuration setting with a specific security control or requirement, thereby linking the setting to its rationale. An automatable checklist with data structures that provide computer-interpretable configuration instructions and traceability to security requirements is extremely useful. Such a checklist enables a longer and broader cyber security digital thread than a checklist that lacks these items.

This chapter discusses the challenges to developing automatable checklists for manufacturing environments using the Security Content Automation Protocol (SCAP -pronounced "ess-cap") family of standards [START_REF] Quinn | Guide to Adopting and Using the Security Content Automation Protocol (SCAP), Version 1.2[END_REF][START_REF] Radack | Managing security: The Security Content Automation Protocol[END_REF]. The standards specify a means for representing checklist information in a manner that an SCAP-conforming software tool can determine how well the system configuration complies with the checklist. SCAP is widely used in government [START_REF]The United States Government Configuration Baseline (USGCB)[END_REF] as well as by private sector enterprises to manage configuration compliance of common operating systems and software applications. Greater use of SCAP in manufacturing environments can reduce security vulnerabilities and the likelihood of damaging cyber attacks on manufacturing systems.

Manufacturing Environments

Modern manufacturing environments use industrial control systems to safely and reliably operate industrial processes. At the front line of these operations are programmable logic controllers (PLCs), which are computers developed specifically to monitor and control industrial processes [START_REF] Mclaughlin | The cybersecurity landscape in industrial control systems[END_REF]. Early generations of programmable logic controllers were intended to operate in isolated environments with custom operating systems and proprietary communications protocols. In contrast, modern programmable logic controllers incorporate information technologies such as TCP/IP and Ethernet for communications, USB ports for file transfers and commodity operating systems for efficiency, flexibility and convenience. The technologies enable greater visibility of manufacturing processes, the incorporation of real-time manufacturing data in corporate business systems, interoperability with existing networking infrastructures and remote monitoring capabilities [START_REF] Sadeghi | Security and privacy challenges in the industrial Internet of Things[END_REF]. However, the technologies also expose programmable logic controllers to greater cyber security risks.

Programmable logic controllers must be able to audit their configurations in order to detect potential vulnerabilities before they are exploited as attack vectors. Many attack vectors are introduced by enabled-by-default programmable logic controller features and services (e.g., embedded web servers, terminal servers and remote access servers). These features and services may only be detected after a thorough review of cyber-security-hardening guidance from vendors or discovery through active-scanning techniques employed by penetration testers.

The integration of information technologies directly in industrial control systems and manufacturing environments is now a normal occurrence. This is exemplified in the NIST ICS Cybersecurity Testbed [START_REF] Candell | An Industrial Control System Cybersecurity Performance Testbed[END_REF][START_REF] Zimmerman | Metrics and Key Performance Indicators for Robotic Cybersecurity Performance Analysis[END_REF]. The testbed contains two robotic arms that emulate a material handling application; the robots are integrated into simulated manufacturing machines to perform repetitive tasks normally performed by a human operator (e.g., insert raw parts, remove finished parts, operate machine guarding and start and stop the machining cycle). The manufacturing machines communicate with the robot controllers via TCP/IP and Ethernet to coordinate the loading and unloading of parts. Figure 1 shows an image of the robotic portion of the NIST testbed.

Software executing in dedicated external controllers controls each robot. The controllers, which are high-performance servers typically found in information technology environments, run the Robot Operating System (ROS) on top of Ubuntu Linux, enabling the robots to collaborate in performing machine tending tasks. Ubuntu is the most common deployment environment for ROS, a software framework that is widely used in robotics research projects and increasingly in commercial robotic applications [START_REF] Fairchild | ROS Robotics by Example[END_REF]. ROS-Industrial, a variant of ROS tailored for commercial applications, accelerates ROS deployment by augmenting its advanced manipulation capabilities with better support for reliability and safety [START_REF] Munaro | RGB-D human detection and tracking for industrial environments[END_REF][START_REF]ROS-Industrial[END_REF].

A motivating example is used to demonstrate the relationships between rules, security controls and a high-level security objective for an Ubuntu Linux server running ROS. Figure 2 shows two rules: one rule stipulates that a firewall should be set by default to deny all traffic (with all exceptions explicitly provided) and the other states that an AppArmor Linux kernel enhancement [START_REF] Bauer | Paranoid Penguin: AppArmor in Ubuntu 9[END_REF] should be enabled to restrict program access to system resources. AppArmor is commonly used in Ubuntu systems with stringent security requirements and its namespaced access control mechanism is a good match for the ROS data model [START_REF] White | SROS: Securing ROS over the wire, in the graph and through the kernel[END_REF]. The first rule supports boundary protection while the second rule supports least privilege. Both these security controls, in turn, support the highlevel "protect" security function specified in the Cybersecurity Framework [START_REF]Framework for Improving Critical Infrastructure Cybersecurity, Version 1.0[END_REF] -a methodology for managing cyber risk, describing an organization's current security posture and target state, and communicating and assessing progress toward meeting goals. Below each rule are shell commands for checking compliance.

Each level in Figure 2 is less general and more implementation-specific than the level above it. The top two levels describe security objectives and are independent of system-specific and implementation details. They provide the rationale for the rules in the checklist rule level. The checklist rule level applies to Linux systems, but it does not assume a particular Linux distribution. The shell command level applies only to Linux systems with the iptables package (pre-installed by default in Ubuntu distributions); iptables is an application that can be used to configure a Linux kernel firewall.

A corollary to the observation regarding levels and generality is that information in the higher levels is more reusable than information in the lower levels. For example, many rules in a wide variety of checklists support the least privilege security control. This is because least privilege is a universal principle that applies to many deployment situations. The AppArmor rule, however, is more specific. It applies only to Linux systems where the security benefit of AppArmor outweighs the convenience of programs having less-restrictive access to system resources. However, several Linux systems have specialized security limited functionality (SSLF) requirements [START_REF] Quinn | National Checklist Program for IT Products -Guidelines for Checklist Users and Developers[END_REF], including the robot controller server that runs ROS. These systems have especially stringent security requirements because of the threats they face and the potential consequences of incidents. Thus, the rule is reusable in many specialized security limited functionality contexts. However, the shell command that implements the rule is less reusable because it assumes the presence of iptables instead of an alternative firewall configuration application.

SCAP Background

An automated checklist has limited value if it is hardwired to a particular configuration tool or scripting language. Standards for representing rules, system settings, vulnerabilities, platforms and other relevant information enable checklists to be interoperable. Interoperable checklists can be used with any standards-compliant tool. Interoperability standards save checklist developers the trouble of having to learn multiple proprietary formats and lower the barriers to automated configuration checking. To address the need for interoperability, the cyber security research, development and user communities have created several Extensible Markup Language (XML) [START_REF]World Wide Web Consortium, Extensible Markup Language (XML) 1.0 (Fifth Edition), W3C Recommendation[END_REF] data representation and exchange standards for software weaknesses and vulnerabilities, naming conventions, system state, configuration checklists, asset identification and severity measurement of software and configuration issues [START_REF] Mcguire | The State of Security Automation Standards -2011[END_REF]. SCAP provides the recommended practices for using these standards together [START_REF] Quinn | Guide to Adopting and Using the Security Content Automation Protocol (SCAP), Version 1.2[END_REF][START_REF] Radack | Managing security: The Security Content Automation Protocol[END_REF].

SCAP is commonly used to automate security configuration compliance checking, which is the focus of this research. The following SCAP languages and taxonomies are especially relevant to the example in Figure 2 and the upcoming discussion:

Extensible Configuration Checklist Description Format (XC-CDF):

This language is used to express security checklists, benchmarks and other configuration recommendations. XCCDF can represent the highly structured data needed for automated configuration checking as well as the semi-structured data needed to produce human-readable documentation of a checklist and the results of checking a system configuration.

Common Platform Enumeration (CPE):

This naming scheme provides unique identifiers for hardware, operating systems and applications.

Common Configuration Enumeration (CCE):

This registry maintains unique identifiers for operating system and software security configurations. SCAP checklists can use mappings from common configuration enumeration values to taxonomies of security principles or business objectives, providing traceability from configuration settings to higher-level requirements.

Open Vulnerability and Assessment Language (OVAL):

This language is used to express system configuration information, assess machine state and report assessment results. OVAL is widely used in the cyber security community as part of SCAP as well as with other standards [START_REF] Kampanakis | Security automation and threat information-sharing options[END_REF]. Many hardware and software vendors produce OVAL content, which they make available to their customers directly and through third-party online repositories. The OVAL data model is versatile and complex; interested readers are referred to [START_REF] Oval | [END_REF] for details about the data model

The XCCDF data model [START_REF] Waltermire | Specification for the Extensible Configuration Checklist Description Format (XCCDF)[END_REF] represents a checklist document as a Benchmark object. A Benchmark is a collection of Rule, Value and Group objects. A Rule specifies a single item to check, such as the default setting of a firewall. A Rule also specifies how the checking should be done, such as with an implementationspecific scripting language or with the OVAL standard. A Value represents a named quantity that can be used in a rule and is tailored to a particular configuration scenario. A Group collects Rule, Value and other Group objects into an aggregation that is meaningful to a checklist user (e.g., a collection of firewall configuration settings). An XCCDF Benchmark also contains one or more Profile objects. A Profile is a named collection that references Group, Rule and Value objects. For example, an XCCDF Ubuntu checklist may have three profiles: one for single-user desktop systems, another for file servers and a third for specialized security limited functionality systems. Figure 3 shows an example of an XCCDF checklist, which is based on an example from the XCCDF specification [START_REF] Waltermire | Specification for the Extensible Configuration Checklist Description Format (XCCDF)[END_REF]. The Unified Modeling Language (UML) [START_REF]Object Management Group, OMG Unified Modeling Language (OMG UML), Version 2.5[END_REF] object notation is employed. The checklist applies to the Debian Linux distribution version 8.0, as indicated by the common platform enumeration value assigned to the platform attribute of the Benchmark object. The checklist has two profiles, p1 and p2, each of which references a subset (omitted from Figure 3 for simplicity) of groups g1, g2 and g3 and values v1, v2 and v3. In the figure, g1 aggregates rules r3 and r4; g2 aggregates rules r1 and r2; and g3 aggregates value v4 and rules r5 and r6.

The UML object model in Figure 4 shows how XCCDF is used to express the rules for checking that AppArmor is configured correctly in the Ubuntu scenario shown in Figure 2. Since the actual XCCDF rule representation would have more objects and would be harder to understand, Figure 4 Each Check-Content object references a specific Ubuntu Linux OVAL definition in an external location. SCAP-conforming configuration scanner tools must support OVAL as a checking system. Support for other checking systems, such as those based on Linux shell command languages, is optional. To facilitate interoperability, the use of OVAL in checklists is preferable to non-SCAP checking systems.

The example in Figure 4 also illustrates the complexity of SCAP content. Each rule requires multiple OVAL definitions. Each OVAL definition, in turn, requires additional OVAL objects that are not shown in Figure 4.

SCAP Reuse in Manufacturing Environments

A major benefit is that an SCAP-expressed checklist can be used with multiple software tools and can be presented in multiple ways to users depending on their desire for details or need to know. Furthermore, XCCDF enables checklist developers to modularize content into groups and profiles, and enables checklist users to create tailoring files based on profiles. These capabilities, along with various online XCCDF and OVAL repositories, benefit SCAP checklist developers and users.

However, SCAP is not as helpful at facilitating the reuse of content applicable to multiple platforms. Consider, for example, the firewall rule in Figure 2, which uses iptables to check that the default policy is configured properly. The rule assumes the presence of iptables and, therefore, requires another rule to verify that iptables is installed. For Ubuntu Linux, the shell command dpkg -s iptables could implement such a rule. The dpkg package manager -s command option determines the status of a package (i.e., whether or not it is installed). However, dpkg is not universal across Linux distributions. Linux distributions based on the Debian Linux distribution, such as Ubuntu, use dpkg. Other Linux distributions use different package managers. For example, Fedora and CentOS use rpm for package management. Figure 5 shows the relationships between the Debian, Ubuntu, Fedora and CentOS Linux distributions in terms of their shared kernel and package manager components.

This example illustrates the problem of platform fragmentation. Platform fragmentation occurs when the same operating system, software application and/or hardware component are bundled by multiple entities, with each bundler providing different customizations [START_REF] Vecchiato | The perils of Android security configuration[END_REF]. A real-world example that demonstrates how Linux platform fragmentation complicates SCAP checklist development is the SCAP Security Guide (SSG) Project [START_REF] Openscap | SCAP Security Guide[END_REF]. The project goal is to produce SCAP content (security guides) for a variety of Linux platforms. The SCAP Security Guide developers deal with platform fragmentation by splitting their source code into pieces that can be shared by multiple security guides versus pieces that are specific to a security guide. Building security guides from the source requires running scripts that perform XML transformations, macro substitutions and merging of source files into larger files. The build process is complicated and requires the SCAP Security Guide developers to understand not only SCAP, but also the one-off manner in which the source files are organized and structured [START_REF] Preisler | Contributing to SCAP Security Guide -Part 1 (martin[END_REF].

The SCAP platform fragmentation problem is not just limited to Linux. For example, consider the effort needed to develop a checklist for a programmable logic controller. A programmable logic controller may include an operating system (developed by a third party but customized by the vendor) in addition to automation software. Each of these components may be vulnerable to cyber attacks. The NIST ICS Cybersecurity Testbed has a Beckhoff CX9020 programmable logic controller [START_REF] Automation | Embedded PC[END_REF] that runs the Windows Embedded Compact operating system (which Beckhoff licenses from Microsoft and has customized) and Beckhoff's TwinCAT automation software. It is actually less challenging to automate the security configuration of a Beckhoff programmable logic controller than that of many other programmable logic controllers with hardwareoptimized, vendor-accessible-only operating systems. For these programmable logic controllers, there is no way for even an advanced user to deploy an automated configuration compliance checker. Indeed, only the vendor can alter the operating-system-level configuration settings.

A security professional tasked with developing an SCAP checklist for a Beckhoff CX9020 programmable logic controller might begin by reviewing the ICS-CERT Advisory ICSA-16-278-02 [START_REF]Industrial Control Systems Cyber Emergency Response Team (ICS-CERT), Advisory (ICSA-16-278-02), Beckhoff Embedded PC Images and TwinCAT Components Vulnerabilities[END_REF]. This document provides guidance for mitigating the vulnerabilities associated with the Windows Embedded Compact operating system and TwinCAT components of the programmable logic controller. Since it is easier to reuse existing SCAP XML content than to create new content from scratch, the security professional could search for XC-CDF and OVAL content that is applicable to Windows Embedded Compact and TwinCAT. Unfortunately for the security professional, no registered common platform enumeration identifiers exist for Windows Embedded Compact and TwinCAT. However, SCAP content may exist for a third-party software library used by TwinCAT and Windows Embedded Compact has a number of components in common with Windows 7 (for which a great deal of SCAP content exists). In such a situation, it would be beneficial if the security professional could determine which, if any, of the existing SCAP content could be easily repurposed to automate the ICSA-16-278-02 guidance. Unfortunately, the existing SCAP content lacks the metadata needed to make such a determination.

Relevant Research and Standards

In addition to the SCAP Security Guide Project, other recent and ongoing research, implementation and standardization efforts have proposed solutions for coping with fragmentation and promoting reuse. The solutions can be categorized as employing: (i) information modeling; (ii) document-focused; (iii) centralized; or (iv) content-focused approaches.

Fitzgerald and Foley [START_REF] Fitzgerald | Avoiding inconsistencies in the Security Content Automation Protocol[END_REF] have analyzed SCAP content from several repositories, classified the types of inconsistencies that create ambiguity and impede reuse and provided examples of implicit relationships. Their analysis focused on the OVAL language and common platform enumeration and common configuration enumeration taxonomies, but did not include XCCDF content. They then developed an SCAP ontology employing semantic threat graphs and demonstrated how the SCAP ontology addresses inconsistency challenges by making implicit relationships explicit.

Other researchers have pushed the envelope of SCAP deployment by developing checklists for platforms beyond the usual SCAP realm of desktop operating systems, Internet browsers and office applications. Hlyne et al. [START_REF] Hlyne | SCAP benchmark for Cisco router security configuration compliance[END_REF] have developed a configuration checklist for Cisco routers, which uses OVAL content developed by Cisco and is deployed using the jOval SCAP configuration scanning tool. Kuo and Yang [START_REF] Kuo | Security design for configuration management of Android devices[END_REF] have created an SCAP configuration checklist for Android devices and a configuration management tool using the jOval scanning engine; the tool runs on a server and performs remote scanning and remediation of misconfigurations. Kuo and Yang have used as their information source prose text (without SCAP content) benchmark documentation from the Center for Internet Security (CIS) [START_REF] Fritz | CIS Google Android, Android 4 Benchmark V1.0.0[END_REF]. CIS benchmarks [5] are available for a variety of operating systems, software environments and network devices. Although many CIS benchmarks are in prose form and not expressed using SCAP, an increasing number are now available to CIS members in the XCCDF and OVAL formats.

Vecchiato et al. [START_REF] Vecchiato | The perils of Android security configuration[END_REF] have studied configuration assessment data from more than 500 Android smartphones and have found several recurring misconfigurations, the most common being weak passwords and overly-permissive network settings. Android device configuration compliance is an interesting SCAP use case because its platform fragmentation challenges parallel those encountered in manufacturing environments. In comparing Android with common desktop and laptop operating systems, Vecchiato and colleagues characterize Android smartphones as being more personalized to consumer preferences and having lesser capabilities due to their reduced size and other physical constraints. These characteristics are similar to those in manufacturing environments, where hardware and information technology capabilities have to meet requirements unique to the production scenarios and environmental conditions. Furthermore, as in the case of the programmable logic controller example in Section 4, smartphone vendors customize Android devices with their own applications and carrier-specific settings. As a result, Android smartphone vulnerabilities and configuration issues can be hardware-vendor-dependent.

Vecchiato et al. [START_REF] Vecchiato | The perils of Android security configuration[END_REF] have also proposed an intriguing approach for reducing the fragmentation problem -that vendors and researchers work together to transition some Android device capabilities currently available only through vendors to services available through Google Play. The anticipated result of this approach is that vendors could leverage Google Play's automatic update mechanism, enabling third-party software developers and end users to receive new Android features and patches without having to wait for less-frequent Android updates from their carriers. The approach of Vecchiato and colleagues appears to be appealing in manufacturing environments because it addresses a significant obstacle to automating configuration checking of industrial control devices such as programmable logic controllers -the lack of software interfaces for third-party access to the underlying operating system information. Of course, vendor-provided tools employed to program the devices may enable users to issue queries required to support the auditing of programmable logic controllers, but it is currently not possible to use these tools to conduct automated audits.

An adaptation of the idea of Vecchiato and colleagues could help mitigate the fragmentation problem in manufacturing environments. Specifically, vendors of programmable logic controllers, switches and routers could make their firmware, operating system and other software updates available through centralized trusted digital distribution services. However, unlike Android smartphones, automatically updating industrial control devices raises significant concerns. The availability of the devices and the safety of their operations are paramount. Enabling a third-party developer to update a device automatically without end-user intervention could have catastrophic consequences, especially if the update occurs during production or software bugs are present in the update. However, with the right modifications to address industrial control system availability and safety requirements, an adapted approach might be acceptable. Indeed, the increasing use of commodity operating systems in programmable logic controllers and other devices provides new opportunities for developers to implement automatic software updates as part of centralized services.

Software identification (SWID) tags [START_REF] Waltermire | Guidelines for the Creation of Interoperable Software Identification (SWID) Tags, NIS-TIR 8060[END_REF], an international standard for describing software products, offer another potential solution to platform fragmentation. SWID tags use an XML format that allows for better-structured and information-richer content than provided by a common platform enumeration identifier. The common platform enumeration naming scheme is syntactic and does not provide explicit semantics, which leads to ambiguity [START_REF] Fitzgerald | Avoiding inconsistencies in the Security Content Automation Protocol[END_REF]. In contrast, SWID tags can explicitly represent the unique identifier of a product as well as information about its versioning scheme, patch level, relationships to other software and a host of other useful metadata. Because they enable better software inventory management, SWID tags can also help detect system misconfigurations. Indeed, current SCAP recommended practices provide guidance for replacing common platform enumeration identifiers in SCAP content with SWID tags [START_REF] Waltermire | Forming Common Platform Enumeration (CPE) Names from Software Identification (SWID) Tags[END_REF].

Another standard that could promote the reuse of SCAP content is the Darwin Information Typing Architecture (DITA) [START_REF]Darwin Information Typing Architecture (DITA) Version 1.3 Part 0: Overview (Plus Errata 01), OASIS Standard (Incorporating Approved Errata)[END_REF]. As the SCAP Security Guide Project's complicated build system illustrates, producing an SCAP checklist from a collection of components poses XML publishing and content management problems. However, as discussed in Section 4, the source code version control systems that projects such as the SCAP Security Guide typically use are file-based and inadequate for managing relationships between objects within a source XML file or relationships between files. Multiple publications (checklists) can share the same XCCDF or OVAL component. Additionally, a publication can use the same component in more than one context. Kimber [START_REF] Kimber | Hyperdocument authoring link management using Git and XQuery in service of an abstract hyperdocument management model applied to DITA hyperdocuments[END_REF] Table 1. Research and development approaches, objectives and proposed solutions.

Approach Objective Solutions

Information Mitigate platform fragmentation by improving Fitzgerald and Modeling the ability of SCAP to represent platform Foley [START_REF] Fitzgerald | Avoiding inconsistencies in the Security Content Automation Protocol[END_REF]; dependencies and relationships within and SWID tags [START_REF] Waltermire | Guidelines for the Creation of Interoperable Software Identification (SWID) Tags, NIS-TIR 8060[END_REF]. between XCCDF rules and OVAL definitions. Document-Use XML-based methods to make SCAP DITA [START_REF] Kimber | Hyperdocument authoring link management using Git and XQuery in service of an abstract hyperdocument management model applied to DITA hyperdocuments[END_REF][START_REF]Darwin Information Typing Architecture (DITA) Version 1.3 Part 0: Overview (Plus Errata 01), OASIS Standard (Incorporating Approved Errata)[END_REF]; Focused authoring and content reuse easier. SSG ad hoc build system [START_REF] Preisler | Contributing to SCAP Security Guide -Part 1 (martin[END_REF].

Centralized Reduce the likelihood of misconfigurations by Vecchiato et al. [START_REF] Vecchiato | The perils of Android security configuration[END_REF]. centralizing software distribution and updates.

Addresses the root cause of platform fragmentation instead of putting the onus on checklist authors. Requires coordination and trust between stakeholders and tailoring to meet the stringent operational and safety requirements of manufacturing environments.

Content-Develop more XCCDF checklists, particularly SSG [START_REF] Openscap | SCAP Security Guide[END_REF]; Focused for platforms where SCAP content is in short Hlyne et al. [START_REF] Hlyne | SCAP benchmark for Cisco router security configuration compliance[END_REF]; supply. Kuo and Yang [START_REF] Kuo | Security design for configuration management of Android devices[END_REF]; CIS benchmarks [5].

has implemented a content management and publishing system that combines the capabilities of the Darwin Information Typing Architecture with the Git version control system to generate publications from a collection of interrelated version-controlled XML components. Such a standards-based strategy, if feasible for the SCAP Security Guide Project, would be less ad hoc and brittle than the current approach, which uses a mix of scripts, makefiles and manual searches within files [START_REF] Preisler | Contributing to SCAP Security Guide -Part 1 (martin[END_REF]. Table 1 summarizes the objectives and the solutions of the research and development approaches discussed above.

Conclusions

This chapter has investigated the challenges to reusing existing SCAP content for checking configuration compliance of information technology components in manufacturing environments. An illustrative example using an Ubuntu Linux configuration checklist scenario demonstrates that platform fragmentation complicates the reuse of SCAP content. The same platform fragmentation exists in the industrial control system and Android device domains as well. A review and classification of related research and development approaches and the relevant standards reveal promising solutions that ameliorate platform fragmentation and encourage more SCAP deployments.

The need for cyber security solutions in manufacturing environments is growing. Although platform fragmentation is a barrier to SCAP deployment in the manufacturing sector, other areas -most notably Android mobile devicesshare a number of the same issues. Recent and ongoing research and development results could lead to concrete gains in SCAP adoption in the manufacturing sector and in other areas, especially if the stakeholder communities work together and learn from each other.

Disclaimer

This chapter is a contribution of the National Institute of Standards and Technology (NIST). Certain commercial and third-party products and services are identified in this chapter to enhance understanding. Such identification does not imply any recommendation or endorsement by NIST, nor does it imply that the materials or equipment identified are necessarily the best available for the purpose.

Figure 1 .

 1 Figure 1. Robotic portion of the NIST ICS Cybersecurity Testbed.

Figure 2 .

 2 Figure 2. Checklist example.

Figure 3 .

 3 Figure 3. Example of an XCCDF benchmark XML document.

Figure 4 .

 4 Figure 4. Example AppArmor rule in XCCDF.

  shows a simplified version of the rule representation. Interested readers are referred to [5, 27] for details about an actual XCCDF XML representation. The CCE object in the upper-right corner of Figure 4 maps to two NIST Special Publication 800-53 security controls from the Access Control (AC) family, AC-3(3) and AC-6, both of which support the least privilege principle. The two Rule objects that support the CCE each reference Boolean expressions involving Check-Content objects.

Figure 5 .

 5 Figure 5. Shared components of Linux distributions.