Michael Millian

Prashant Anantharaman

Sergey Bratus

Sean Smith

Michael Locasto

CONVERTING AN ELECTRIC POWER UTILITY NETWORK TO DEFEND AGAINST CRAFTED INPUTS

Keywords: Industrial control networks, input handling, language-theoretic parsers

This chapter proposes a roadmap that employs secure parsers to eliminate the possibility of input-handling vulnerabilities in industrial control systems. Industrial control systems are responsible for maintaining the integrity of power grids. Complex communications networks constitute the backbones of these systems. Communications in industrial control networks must be processed correctly and they should not crash devices or enable attackers to access networked devices. Language-theoretic security is the practice of comprehensive input handling using secure parsers. This chapter demonstrates that the existing collection of secure parsers for industrial control protocols can cover the communications needs of industrial control networks. It discusses the merits of guarding industrial control networks using secure parsers, proposes a triage procedure for implementation and summarizes the security benefits and lessons learned.

Introduction

Industrial control systems are increasingly connected to the Internet, either directly or via connections to Internet-connected devices. Industrial control protocols are used to interact with actuators and sensors that help operate important infrastructure assets such as the power grid. The risks posed by the cyber-physical nature of industrial control devices coupled with their network connectivity render the task of securing industrial control network communications a very high priority.

The principal goal of this research is to eliminate input-handling vulnerabilities in industrial control networks. Input-handling vulnerabilities are a class of vulnerabilities with a long history and many modern examples [START_REF] Ducklin | Anatomy of a "goto fail" -Apple's SSL bug explained, plus an unofficial patch for OS X! Naked Security (nakedsecurity[END_REF][START_REF] Durumeric | The matter of Heartbleed[END_REF][START_REF] Freeman | Exploit (& fix) Android "master key[END_REF][START_REF] Torpey | The DAO disaster illustrates differing philosophies in Bitcoin and Ethereum, CoinGecko Buzz[END_REF]. Previous work has shown that industrial control networks are not immune to these vulnerabilities -between 2013 and 2014 alone, more that 30 input-handling vulnerabilities were discovered in implementations of the DNP3 protocol in industrial control devices [START_REF] Bratus | Implementing a vertically-hardened DNP3 control stack for power applications[END_REF].

However, eradicating input-handling vulnerabilities presents some challenges. First, while a language-theoretic security approach has been applied to build secure parsers for industrial control protocols, the results have thus far been limited to academic research as opposed to production systems. Indeed, the adoption of these protocol implementations in real systems has been minimal. This research attempts to address the issue by clarifying the benefits and explaining how to use secure parsers.

In particular, a notional architecture of an industrial control network that employs secure parsers is presented. The notional architecture is a general network model that incorporates the components found in industrial control networks. The model loosely maps a real-world network without being tied to a single utility. It is shown that secure parsers cover the communications edges of this model. Indeed, all communications can be guarded using these parsers.

The second challenge is that industrial control networks employ a large variety of protocols. Securing a protocol implementation requires a careful examination of the protocol specification. Device manufacturers often subset or fork existing protocols, resulting in new protocols that must be analyzed thoroughly. Device manufacturers also implement proprietary protocols that significantly complicate protocol analysis. To address this challenge, best practices are proposed for creating new parsers and for subsetting or forking existing protocols.

The third challenge is updating industrial control devices. Because these devices perform vital operations, taking them offline or interrupting their ability to communicate are not viable options. Nevertheless, protocols that contain unsafe features must be made to meet language-theoretic security standards. This is accomplished by employing a triage procedure that enables industrial control devices to continue to operate during the transition.

The proposed approach focuses on subsetting existing industrial control protocols. A subset of a protocol is just the protocol with certain messages excluded. For example, an opcode is removed if the payload for the opcode is unsafe. No features are added to a protocol; rather, unsafe features are removed. As a result, all the industrial control devices that understand a protocol can understand the safe subset of the protocol.

Background and Prior Work

Input-handling vulnerabilities have plagued networked systems since their creation. Several well-known bugs -Heartbleed [START_REF] Durumeric | The matter of Heartbleed[END_REF], Shellshock [START_REF]ShellShock: All you need to know about the Bash Bug vulnerability, Symantec Security Response Blog[END_REF], Rosetta Flash [START_REF] Spagnuolo | Abusing JSONP with Rosetta Flash, Michele Spagnuolo Blog[END_REF] and Apple's goto bug [START_REF] Ducklin | Anatomy of a "goto fail" -Apple's SSL bug explained, plus an unofficial patch for OS X! Naked Security (nakedsecurity[END_REF] -involve input-handling vulnerabilities. Any program that accepts inputs must validate the inputs holistically to ensure that they comply with the protocol specifications. An input-handling vulnerability stems from a protocol violation. Typically this is due to a programmer error, such as forgetting to check a condition. Sometimes, an input-handling vulnerability may arise not from a protocol violation per se, but from a deeper flaw in the protocol.

Many bugs have parsing errors at their root. Some work has been done to demonstrate this in specific domains (e.g., USB [START_REF] Johnson | Protecting against malicious bits on the wire: Automatically generating a USB protocol parser for a production kernel[END_REF]), but no large-scale effort has been expended to label all parsing bugs as such. Another domain-specific work found more than 30 input-handling vulnerabilities in DNP3 protocol implementations [START_REF] Bratus | Implementing a vertically-hardened DNP3 control stack for power applications[END_REF]. In fact, only a few implementations were found to be free of vulnerabilities. They were immune because they employed very constrained subsets of DNP3 that significantly reduced their attack surfaces. This result supports the position that protocol subsetting can eliminate input-handling vulnerabilities.

The impacts of input-handling vulnerabilities range from device crashes to attackers gaining access to networks. Heartbleed enabled attackers to exfiltrate data; Apple's goto bug allowed man-in-the-middle attacks; Shellshock gave attackers direct access to systems. Given the ubiquity of input-handling vulnerabilities, it is imprudent to believe that industrial control networks, protocols and devices are immune to input-handling vulnerabilities. Device crashes may pose mild threats in information technology environments. Not so in industrial control networks where device crashes can disrupt critical infrastructure assets. Without question, it is imperative to ensure that industrial control networks are rendered immune to input-handling vulnerabilities.

Language-Theoretic Security

Language-theoretic security postulates that all inputs received by a program must be validated in their entirety by a parser developed from a formal grammar before any and all uses of the inputs by program internals. A program that receives an unanticipated input could be driven to a state that its developers did not anticipate. A language-theoretic-security-hardened parser ensures that input validation code is explicitly and clearly based on a formal grammar, that the validation code is logically separate from the code that processes the inputs, and that a program can never operate on inputs that have not been verified exhaustively. There is no room for inputs that are "almost correct" because these inputs cannot be meaningfully distinct from malicious crafted inputs.

In this work, a language denotes a set of allowed inputs. A protocol is specified using a grammar, a set of production rules that create the inputs that constitute the language. A parser is an implementation of the protocol in code.

A parser combinator is employed to construct a parser in a manner that clearly and explicitly represents the protocol. It is a toolkit or framework that produces code that visually resembles the formal grammar instead of multiple if-statements that check conditions. Parser combinators dramatically reduce the possibility of programmer errors (e.g., forgetting to check a condition).

In this research, the Hammer parser combinator tool [START_REF] Patterson | Parser combinations for binary formats[END_REF] was used to implement parsers. Hammer was developed with a security focus, which is measured against the Chomsky hierarchy that classifies languages according to their com-plexity [START_REF] Chomsky | Three models for the description of language[END_REF]. The language classes range from regular expressions that are recognized/generated by finite state automata to recursively-enumerable languages that are recognized/generated by Turing machines. Note that regex tools in Perl, Python and JavaScript are actually more complex than regular expressions. Grammars that are deterministic-context-free or simpler are considered safe; this limit is discussed by Momot et al [START_REF] Momot | The seven turrets of Babel: A taxonomy of LangSec errors and how to expunge them[END_REF]. Parser combinator toolkits are useful for building parsers for binary protocols and for specifying byte-level constraints about languages. They also provide a way to represent top-down grammars. The Hammer tool parses inputs into abstract syntax trees.

Industrial Control Systems Security

Industrial control systems differ from traditional information technology systems and, consequently, require different security approaches. Industrial control networks interact with physical devices such as sensors and actuators using short messages with extremely low latency. In contrast, information technology networks transfer data using much larger packets with longer latency. Additionally, industrial control networks are typically deeper than information technology networks.

Much work has focused on ensuring the security of industrial control systems and networks. The prevailing security paradigm is defense-in-depth where security features and tools are added at each layer of the system or network to provide compound protection against external threats [START_REF] Galloway | Introduction to industrial control networks[END_REF].

This research leveraging secure parsers complements the defense-in-depth model. Industrial control systems were originally designed for isolated, local use of analog equipment. Over the years, industrial control networks have been upgraded to support automation and remote access. New connections and capabilities pose new threats that industrial control systems were not designed to handle. The proposed approach is fundamentally about ensuring message security during the protocol design phase. It may require modifications of existing protocols if they do not meet the complexity-limitation requirements for security. Because protocol complexity is restricted rather than increased, the proposed approach dovetails with current defense-in-depth strategies. Existing security measures do not have to be replaced, they can work in concert with the proposed approach. Indeed, the approach can be used at every level of the defense-in-depth model to increase the security claims at a given level and between levels.

Notional Architecture

This section presents a notional architecture for a language-theoretic-security-compliant industrial control system at a utility. The notional architecture contains the general elements and components of a real-world network in an abstract representation that is not tied to a single utility.

First, the types of devices encountered in an electricity utility are specified, including the devices that are expected to communicate directly and the pro- tocols they use for communications. Next, it is shown how secure parsers can provide coverage of the communication needs in the model such that all the communications can be guarded by the parsers.

Figure 1 shows the Purdue model architecture [START_REF]), Recommended Practice: Improving Industrial Control System Cybersecurity with Defense-in-Depth Strategies[END_REF], which is annotated with the various paths that an attacker could use to access the industrial control network. The Purdue model has six levels: (i) enterprise network (level 5); (ii) business planning and logistics network (level 4); (iii) site manufacturing operations and control (level 3); (iv) area control (level 2); (v) basic control (level 1); and (vi) process devices (level 0). The levels are divided into several zones, where a zone corresponds to large-scale interconnectivity. Implementing clear boundaries between the zones is a best practice for enforcing multiple layers of defense.

This research focuses mainly on levels 2 through 0, which is called the cell security zone or the SCADA (supervisory control and data acquisition) zone. This zone comprises devices found in an electricity substation as well as devices that are directly involved in managing the substation. Level 2 is concerned with monitoring and controlling physical devices. The devices in this level include control center operation workstations, human-machine interfaces (HMIs), engineering workstations, security event collectors, operations alarm systems, communications front ends, data historians and network/application administrator workstations. Level 1 is concerned with sensing and manipulating physical devices. Devices in this level include dedicated operator workstations, programmable logic controllers (PLCs), control processors, programmable relays, remote terminal units (RTUs) and process-specific microcontrollers. Level 0 contains physical devices such as sensors, actuators, motors, process-specific automation machinery and field instrumentation devices [START_REF] Lee | Detecting the Siemens S7 worm and similar capabilities[END_REF]. During the research, several real and development networks in the SCADA zone were examined. These networks are considered critical infrastructure assets, so detailed information about their network topologies cannot be published. In any case, large variances were observed in device types and layouts from substation to substation. Thus, it has been possible to develop a notional architecture that is not based on a single utility.

Figure 2 shows the notional architecture that is derived from previous models [START_REF] Hurd | A Survey of Security Tools for the Industrial Control System Environment[END_REF][START_REF]), Recommended Practice: Improving Industrial Control System Cybersecurity with Defense-in-Depth Strategies[END_REF][START_REF] Veitch | Microgrid Cyber Security Reference Architecture, Version 1.0[END_REF] as well as from real and development networks. The architecture is designed to be as generic as possible while still maintaining its utility.

The generic architecture enables the expression of coverage by focusing on a small set of protocols used at the edges (e.g., RTU-RTU, RTU-HMI and control-center-substation) without too much concern about the actual device models. While there are many protocols for a given edge (e.g., RTU-HMI), the notion of coverage means that at least one of the protocols is handled and, therefore, it is feasible to add the protection. Vendor-specific protocols exist, but many vendors provide devices that can handle multiple protocols (i.e., standard languages), so this concept of coverage is practical. Using popular protocols allows easier integration in existing ecosystems. The set of popular protocols considered in this work was determined using informal as well as published surveys [START_REF] Hurd | A Survey of Security Tools for the Industrial Control System Environment[END_REF].

Analysis

This section discusses the coverage provided by secure parsers and their benefits and trade-offs.

Protocol Coverage

At this time, the authors of this chapter have implemented secure input handling for the DNP3, MMS (Manufacturing Message Specification), Modbus, IEC 61850-8-1 (GOOSE), IEEE C37.118 [START_REF] Anantharaman | PhasorSec: Protocol security filters for wide-area measurement systems[END_REF], SEL Fast Message, HTTP and Telnet protocols. This section discusses how this selection of protocols offers adequate coverage of industrial control network communications needs.

DNP3, MMS and Modbus are the de facto industry communications standards. These protocols allow for communications between the human-machine interface of a master station and remote terminal units, programmable logic controllers and intelligent electronic devices (IEDs). SEL Fast Message is a vendor-specific protocol for SEL devices that handles much of the same communications. GOOSE is used to broadcast or multicast event data fast and reliably in substations; GOOSE messages have a maximum latency of 4 ms. IEEE C37.118 is used to transmit phasor data over wide-area networks. HTTP and Telnet are used for communications between workstations and for configuring devices.

To reiterate, communications from level 2 downwards are covered by the popular DNP3, MMS and Modbus protocols as well as by the vendor-specific SEL Fast Message protocol. Level 1 substation/physical devices are covered by the GOOSE and IEEE C37.118 protocols. Finally, workstation-workstation communications are covered by HTTP and Telnet. By implementing parsers for these industrial control system protocols, a large degree of protection is provided for the majority of low-level (Purdue model) operational technology traffic in most industrial control networks. In particular, secure parsing is provided for the protocols that are responsible for manipulating physical devices, a task that has very high priority.

Benefits

The major benefit in using a parser combinator tool is the possibility of producing provably-correct code. A programmer implementing a parser should not have to worry about the correctness of a combinator just like a programmer typically does not worry about the correctness of a compiler.

Proofs of correctness of the combinators in Hammer remain to be done. However, as far as this work is concerned, only two possibilities exist -either every combinator is correct or there are bugs in one or more combinators. If a bug is found in a combinator, it can be corrected without having to rewrite the parsers built using the combinator (although they would have to be recompiled using the updated combinator library). This is because each combinator performs a function that is fully understood under formal computational theory, so the function signature of each combinator is set, only the internals may change. After this proof work is complete, every secure parser built with these combinators immediately derives the full benefits of provable security.

The other benefit of the parser combinator is that it reduces the effort undertaken by the programmer who works on a parser. A key observation is that attention should be paid to match the complexity of the parser to the complexity of the protocol and this attention must be baked in during development and implementation. Traditional parser programming involves a number of if-statements that check conditions. It is easy to miss a condition -as in Heartbleed and Apple's goto bug. However, even when a fix is provided, it is still difficult to compare the new parser against the protocol and demonstrate that they match completely [START_REF] Momot | The seven turrets of Babel: A taxonomy of LangSec errors and how to expunge them[END_REF].

Using a parser combinator simplifies the comparison task, and thus decreases the likelihood of errors, and simplifies the implementation of fixes should errors occur. A parser combinator tool produces code that visually matches the structure of the grammar, rendering the verification of equality trivial. Furthermore, a tool like Hammer does not have combinators that would allow the programming of complex constructions such as Turing machines. If a programmer cannot implement a protocol feature using a parser combinator, then it is an indication that, perhaps, the feature is unsafe and that a subset of the protocol without the feature should be used. Ideally, this practice of subsetting protocols leads to protocols being designed without unsafe features.

The end result of using a parser combinator is a parser that only accepts messages in the protocol specification. The task of implementing protocols safely can thus be broken down to designing protocols and designing parser combinator tools.

Previous work with DNP3 has demonstrated the practicality of the approach for industrial control system protocols [START_REF] Bratus | Implementing a vertically-hardened DNP3 control stack for power applications[END_REF]. Implementing the DNP3 parser revealed that the specification mentions that the transport layer payload contains at least one byte, but that a zero-length application layer message would cause unhandled exceptions in certain implementations. Each protocol that was implemented contained such features, which were usually handled by if-checks in the parser. The language-theoretic security approach to parser construction considers such packet structure features when writing the parser, significantly decreasing the likelihood that a check is omitted.

Trade-Offs

The major trade-off that comes with a language-theoretic-security-based parser is the need to subset a protocol when inherently unsafe features are discovered. The cost associated with this modification is the possibility that network devices regularly or occasionally transmit messages using the unsafe features. Experience has shown that such messages are a small, if any, fraction of actual traffic. However, there are situations where the trade-offs could be greater depending on the use cases.

Maintaining unsafe protocol features is dangerous. Unsafe features most often relate to message format as opposed to message content, especially in the case of industrial control networks. Of course, it may be necessary to use certain kinds of messages and there are always development costs involved in making changes. However, the real costs arise from the risks of an attacker crashing devices, exfiltrating data or seizing control of devices.

Triage Procedure

This section discusses the roadmap for incorporating language-theoreticsecurity-hardened parsers in industrial control networks so that electric utilities may realize the security benefits. The roadmap involves a three-step plan for engaging with utilities and vendors. The first step is to develop the secure parsers and incorporate them on a per-device basis in a laboratory setting. The second step is to create a virtual substation in the laboratory. The third step is to work with utilities and vendors to replace parser implementations in device firmware via their product refresh cycles.

Protocols and Devices

The first step is to write and test parsers for industrial control protocols. At this time, parsers have been implemented for eight protocols: DNP3, MMS, Modbus, IEC 61850-8-1 (GOOSE), IEEE C37.118, SEL Fast Message, HTTP and Telnet. Accomplishing this task in full requires the complete list of protocols used by utilities.

For each protocol of interest, the protocol specification is obtained and a secure parser is written and tested. At first, parser testing is performed using a bump-in-the-wire implementation. A key requirement is to ensure that the messages passed by each parser allow normal device operations.

However, some inherent difficulties exist. Obtaining documentation for industrial control protocols can be difficult. Many protocol specifications have to be purchased -their costs range from a few hundred dollars to several thousand dollars. A protocol specification may not cover the complete protocol; some protocols import other protocols to leverage existing work and offset the design burden (e.g., data encoding formats and protocol data units). The specifications of these embedded protocols might also have to be purchased.

Another challenge is that there is neither uniformity nor good practice when it comes to describing a protocol. Some specifications are all prose and the developer must create the protocol grammars. Even worse are situations where the specifications include state machines or grammars, but their functionalities do not match the prose [START_REF] Bratus | Implementing a vertically-hardened DNP3 control stack for power applications[END_REF]. This causes divergent implementations depending on how closely the developer reads the documentation. Until protocol specifications improve, close readings of the available specification are essential.

When a protocol has unsafe features, the correct subset of the protocol has to be determined before a parser can be developed. An example of an unsafe feature is nested length fields. Inclusion of nested length fields requires inner length agreement (e.g., the inner length should not exceed the outer length). This constraint cannot be described purely in terms of packet structure using a context-free language because it requires complete parsing of the outer and inner fields to determine agreement. If adherence to the protocol is not maintained by the packet structure of the packet, but left to after-the-fact checks, it is common for one or more checks to be forgotten [START_REF] Ducklin | Anatomy of a "goto fail" -Apple's SSL bug explained, plus an unofficial patch for OS X! Naked Security (nakedsecurity[END_REF][START_REF] Durumeric | The matter of Heartbleed[END_REF].

After the parsers are written and tested as bump-in-the-wire implementations to ensure that devices can operate as required, the native parsers must be replaced with security parsers on a per-device basis. This action is required because industrial control protocols have maximum latency requirements and parsing every message twice can be expensive. Incorporating a secure parser as the native parser provides security benefits beyond traditional intrusion detection. Intrusion detection systems have difficulty providing insights into encrypted messages, but every message must be decrypted and parsed. Thus, incorporating secure parsers as the only native parsers in a device adds precise security properties.

Virtual Substation

After implementing the full range of parsers for industrial control protocols and incorporating them in devices, the next step is to create and operate a virtual substation with hardened devices in a laboratory environment. Before deploying the parsers in real critical infrastructure assets, it is necessary to guarantee that the individual devices and the consequences on a network with these devices operating under normal and stress conditions are well understood.

The virtual substation would be a fully-functioning substation that runs in parallel with real-world networks but does not affect the operation of the networks. It could accept real-time data or replayed captures and would operate real or simulated devices. Developers would conduct analyses to ensure correct operations of the virtual substation with no risk to the larger network.

This step can motivate hardened devices via the list of vulnerabilities that the parsers would prevent. It would also demonstrate to utilities and vendors that hardened devices are viable in operational environments.

Deployment

The final step involves field deployments of the hardened devices. This step must address all the real-world constraints that were not considered in the previous two steps. In particular, industrial control networks are slow to incorporate changes and the changes made may be expected to last for decades. Nevertheless, existing refresh cycles can be leveraged to push language-theoreticsecurity-based parsers to devices in the form of firmware updates.

Current Status

The project is currently in the first step in the roadmap. Eight protocol parsers have been developed and tested as bump-in-the-wire implementations in confidential field trials [START_REF] Newman | The Hail Mary plan to restart a hacked US electric grid[END_REF]. Parsers for a proprietary JSON-based protocol have also been incorporated in General Electric devices [START_REF]Energy Security and Emergency Response, From Innovation to Practice: Re-Designing Energy Delivery Systems to Survive Cyber Attacks[END_REF].

The parsers will be made available as open source or under similar licenses. Instead of each developer having to implement a parser to read input in a specific format, the project goal is to create a standard library for each parser. It would be very useful if the crypto-idiom "don't roll your own crypto" could be extended to parsers -"don't roll your own parsers." The number of vulnerabilities that have arisen from poor parser code supports this point of view.

Code for the DNP3 and C37.118 parsers is available on GitHub [START_REF]Dartmouth's PKI/Trust Lab, C37.118PMU and dnp3[END_REF]. The remaining parsers will be added to the master repository in the near future.

Conclusions

This chapter has presented the design and implementation of an industrial control network that exclusively employs language-theoretic-security-compliant parser implementations. The collection of secure parsers for industrial control protocols cover the communications needs of industrial control networks while eliminating input-handling vulnerabilities that could be exploited by denial-ofservice and remote code execution attacks. The roadmap described in this chapter describes how electric utilities could deploy the security-hardened parsers in their industrial control networks via standard product refresh cycles, reaping the associated security benefits in a cost-effective manner.

Any opinions, findings, conclusions or recommendations expressed in this chapter are those of the authors and do not necessarily reflect the views of the U.S. Air Force, DARPA, United States Government or any agency thereof.

Figure 1 .

 1 Figure1. Purdue model architecture (adapted from[START_REF]), Recommended Practice: Improving Industrial Control System Cybersecurity with Defense-in-Depth Strategies[END_REF]).

Figure 2 .

 2 Figure 2. Notional architecture.

Acknowledgement

This research was supported by the U.S. Air Force and DARPA under Contract No. FA8750-16-C-0179 and by the U.S. Department of Homeland Security under Award No. DE-OE0000780.


Matthew Jablonski

Yongxin Wang

Chaitanya Yavvari

Zezhou Wang

Xiang Liu

Keith Holt

Duminda Wijesekera

AN ATTACK-FAULT TREE ANALYSIS OF A MOVABLE RAILROAD BRIDGE

Keywords: Cyber-physical systems, movable bridges, attack-fault tree analysis

Mechanical and electrical components of movable bridges are engineered to move heavy concrete and steel structures in order to allow water traffic and rail and/or vehicular traffic to pass many times a day despite harsh weather conditions, storm surges and earthquakes. The bridge spans must also support varying rail and/or vehicular traffic loads.

This chapter considers known and theoretical risks posed by movable bridge system attacks and faults in a single stochastic model based on attack-fault trees. Risks associated with railroad swing bridges are presented, along with the attack-fault tree model and the analysis results.

Introduction

Movable bridges constructed over waterways are specifically designed to allow traffic flows on and over waterways. Most movable bridges, which are called "heavy movable structures," maneuver many tons of steel and concrete under the control of modern controllers even under difficult weather conditions.

Bridges have been targets of attacks since ancient times. From castle drawbridges to supply line bridges in Europe during World War II, pitched battles have been fought over bridges. In this post-Stuxnet era, new risks are posed by attacks on programmable logic controllers and networked industrial control systems -the cyber-physical components that control movable bridges. Consequently, securing a modern movable bridge requires the consideration of faults in the physical, mechanical and control aspects of the bridge as well as the cyber security of electro-mechanical components that actuate the movements of physical components. Faults and vulnerabilities in a system are typically studied by collecting and analyzing data about failure modes. Design corrections are then instituted and the resulting reports are shared with the community to mitigate hazards and risks. Unfortunately, a repository of reports pertaining to movable bridges does not exist for three reasons. First, although they may share some common components, no two movable bridge systems are built the same and operate under the same environmental conditions. Second, the faults and the methods for handling outages vary, but this information is not recorded in a centralized public repository. Third, no cyber attacks have as yet been reported against movable bridges, although attacks against other control systems could be repurposed to target similar components in movable bridges. To address the lack of data, this chapter models the impacts of failures on movable bridges with a focus on railroad swing bridges (Figure 1).

A literature review indicates that intentional attacks and accidental faults cause movable bridge failures; therefore, a comprehensive model of attacks and faults that result in failures is needed. This work employs the combined attack-fault tree model of Kumar and Stoelinga [16]. This model was built on previous work on attack trees and fault trees to support qualitative and quantitative analyses of combined system security and safety properties. The model is leveraged to create an attack-fault tree for a swing bridge, following which each node in the model is translated to a stochastic timed automaton used by the UPPAAL Statistical Model Checker [START_REF] David | UPPAAL SMC tutorial[END_REF]. A qualitative analysis of the attack-fault tree can be used to identify the root causes of swing bridge system failures whereas a quantitative analysis allows for the incorporation of likelihood values, costs and impacts of disruptions; these two types of analyses are important components of a risk analysis. The utility of the attack-fault tree model in movable swing bridge risk assessments is also discussed. This research has two main contributions. The first contribution is a thorough security and safety analysis of a movable swing bridge using an attackfault tree model. Although the focus is on cyber attacks, physical attacks are also considered because bridges, by their very nature, have open physical access. The second contribution is the application of the attack-fault tree model to a real-world system.

Open

Functionality and Failures

This section presents a model of swing bridge functionality and potential system failures. The discussion clarifies the risks of attacks and faults that impact railroad swing bridge operations.

Functionality Model and Usage Scenarios

A swing bridge is considered to be open when the bridge is rotated parallel to the navigable water traffic direction, enabling water traffic to flow and halting overland traffic. The bridge is considered to be closed when it is aligned with the overland tracks, halting water traffic while enabling overland traffic to flow. These operational states and their transitions are modeled as a finite-state machine shown in Figure 2. It is assumed that a railroad swing bridge is open by default to favor water traffic, and is closed when needed to accommodate passing trains.

When a bridge in the open state needs to transition to the closed state, an operator signals a close request to the bridge control system. At this point, marine craft are alerted via radio, lighting and/or alarms and given time to steer clear of the bridge. Gates may be lowered to prevent the flow of overland traffic. The control system also checks overland traffic control sensors to avoid unsafe operations. After all the sensor checks are completed, the drive system mechanically walks the pinions around the curved rack, rotating the pivot pier and bridge span 90 degrees. End lifts are then secured, wedges are pushed into place (in the case of center bearing systems), the centering device is engaged and the track is locked on both ends of the bridge [START_REF] Koglin | Movable Bridge Engineering[END_REF].

The bridge is now closed, and lights and signals are used to inform operators to permit overland traffic to flow. After overland traffic has passed over the bridge for some time, the process is reversed to move the bridge back to the default open state.

The functional use cases of a swing bridge are modeled as a Moore finite state machine with four states -open, closing, closed and opening -as shown in Figure 2. Failure states are introduced when the bridge is in these states or transitioning between the states.

Classification of Failures

A movable swing bridge is a "binary dynamic and repairable system" [START_REF] Chaux | Towards a unified definition of minimal cut sequences[END_REF]. It is binary because its failures are modeled using Boolean variables, dynamic because the order of component failures impacts the system failures and repairable because faulty, degraded and failed components can be replaced. According to this classification, a swing bridge may also be in a failure state, which is defined as a stopped and dysfunctional state, where it remains for a period of period until repairs have occurred and normal functionality can resume. If the bridge fails in the open or closed states, then the passage of overland or water traffic, respectively, is halted.

Attack-Fault Tree for a Movable Swing Bridge

Attacks and faults can result in failure states. The swing bridge attack-fault tree segments in Figures 3 and4 show both types of failures in a single model. As a top-down failure analysis formalism, an attack-fault tree is a directed acyclic graph that analyzes the top-level safety or security goal and refines it into smaller sub-goals. In the case of the bridge model, the top-level goal [G 0 ] is "prevent bridge movement," which corresponds to the definition of failure.

An attack-fault tree comprises gates and leaves. Figure 5 shows the five standard, dynamic fault tree gates: (i) AND. (ii) OR; (iii) FDEP (functional dependency); (iv) SAND (sequential AND); and (v) SPARE (spare inputs). The leaves in an attack-fault tree are either basic attack steps or basic component failures, corresponding to attacks and faults, respectively. The leaves are represented as stochastic timed automata (described later in this chapter). Interested readers are referred to [START_REF] Kumar | Quantitative security and safety analysis with attack-fault trees[END_REF] for details about attack-fault trees and their use in quantitative security and safety analyses.

It is assumed that a generic swing bridge uses programmable logic controllers for control automation; wireless networks and manual overrides for interconnections and operator control, respectively; an AC-powered electric motor and motor brake; a simple mechanical miter rail system that does not require separate electronic controls; and modern power systems.

Attacks or faults can take any one of the following five paths to realize the top-level goal [G 0 ]:

[G 2 ]:
Communications failures prevent local or remote operators from moving the bridge.

[G 32 ]: Stuck electric motor brake prevents bridge movement.

[G 68 ]: Support system failure prevents the motion system from functioning.

[G 54 ]: Substructure failure causes a major bridge outage.

[G 64 ]: Pivot pier failure causes a major bridge outage.

Movable Swing Bridge Components

This section describes the basic components and subsystems of a movable swing bridge [START_REF] Koglin | Movable Bridge Engineering[END_REF]. An overview of swing bridge subsystems is provided in order to discuss the attacks and faults in the attack-fault tree. Certain basic attack steps and basic component failures are highlighted during the discussion. Note that swing bridges are falling out of style in favor of lift bridges because their central piers cut waterways in half, which can prevent the passage of large ships.

Superstructure and Substructure

A swing bridge superstructure consists of a pivot pier [G 64 ], which is centered in a navigable water channel (Figure 1). The pivot pier is typically fixed in the middle of the rotating span, enabling it to remain balanced as it rotates. Fires [G 70 ], vehicular collisions [G 74 ] and environmental forces [G 66 , G 67 ] are some of the primary causes of failures in a bridge superstructure system [START_REF] Cook | Bridge Failure Rates, Consequences and Predictive Trends[END_REF]. Additionally, between World War I and the Vietnam War, bridge destruction [G 76 , G 77 ] was an effective measure used by local populations to limit large armed force movements into their territories [START_REF] Douthit | The Use and Effectiveness of Sabotage as a Means of Unconventional Warfare -An Historical Perspective from World War I through Viet Nam[END_REF].

A swing bridge substructure [G 54 ], which includes the foundation for the pivot pier (a round or square concrete base that vertically stretches above the water line), is designed to withstand horizontal loads and keep the bridge centered. Hydraulics issues, such as bridge scour [G 55 ] resulting from water scooping out the soil and sediment that support the bridge pier, caused 60% of complete bridge failures in the United States between 1950 and 1990 [START_REF] Cook | Bridge Failure Rates, Consequences and Predictive Trends[END_REF]. A timber or crib fendering system [G 57 ] is often installed to prevent ships from striking the center pier or to guide them away from the pier. Allisions [G 58 ] that result from marine vessels striking the pier base are the second greatest risk to the substructure and foundation of the bridge [START_REF] Cook | Bridge Failure Rates, Consequences and Predictive Trends[END_REF]. Concrete stress [G 60 ] causes cracks that could be further weakened by chloride from sea water [G 62 ] or by spills [G 63 ].

Mechanical and Electrical Systems

This subsection describes the mechanical and electrical systems that work together in modern swing bridge systems to control bridge movement. Potential attacks and faults are also identified.

Support Systems. Modern swing bridges use mechanical bearing designs

from the mid-nineteenth century, such as the center bearing, rim bearing and combined bearing designs. This research focuses on bearing systems because they are the most common. A system that uses a center bearing [G 53 ] has a circular disk with a convex spherical surface fixed to the bottom of the pivot pier, which supports the weight of the bridge while sitting on top of a fixed convex disk on which the bridge rotates. When the bridge is rotated on top of the disk, it moves along a circular track around the inside base of the pivot pier that distributes the weight and balances the structure when the bridge turns; this requires regular lubrication. Wedges [G 69 ] or some other support system are used to prop up the bridge when supporting live traffic loads; these often require additional electro-mechanical components.

Drive Systems. The support system is rotated using a drive system [G 52 , F DEP ], which is engineered to reduce friction, limit the impact of resistance during movement and reduce the amount of torque output generated by the motor. A shaft [G 50 ] is used to connect the support system to the drive system; it is generally connected to the rack and pinion system via a grid-type coupler The electric motor and electric brakes, which connect mechanical and electric components [G 18 , G 33 ] in the bridge system, could be exploited via logical or physical attacks [G 29 , G 30 , G 36 , G 37 ]. The electrical drive control system in a modern movable bridge is designed to handle the sequencing of all the moving components to ensure proper bridge control. Programmable logic controllers (PLCs) are connected to a control network that gives local and/or remote operators the ability to instruct the bridge to open or close. Each electric motor typically has a dedicated drive controller that controls variables such as speed and torque for bridge rotation. The sequencing involves instructing the networked drive controllers used to manage the electric motor(s) and motor brake(s), controlling the bridge lighting and instructing interlocking system actuators.

Local operators may open and close the bridge using radios [G 15 , G 16 ] or a control panel [G 17 ] in the bridge operator's house, which is generally located in the middle of the swing bridge span. Remote network access is typically provided via a wide-area network to a back office controlled by the transportation authority. A bridge without remote access is considered to be in "dark territory." Networked components [G 2 ] in the bridge system could be attacked logically [G 8 , G 9 , G 11 , G 12 ] or physically [G 5 , G 6 ] and should, therefore, be carefully designed and installed with security in mind.

Interlocking Systems. The rotational movement requires a separate interlocking system that aligns the swing span with the connecting spans in order to fully close the bridge. The interlocking system has three functions: (i) ensure that the opening bridge does not become unbalanced and remains stable; (ii) ensure that the closed bridge does not become unbalanced due to a live load; and (iii) center the bridge and ensure that it does not over-rotate. The first two functions are performed by an end lift system, which relieves the dynamic stresses caused when the bridge begins to move and helps withstand the static stresses caused by passing traffic when the bridge is closed. The third function is performed by centering devices that ensure that the bridge does not over-rotate in the horizontal plane.

After the bridge is in the proper horizontal position, the railroad tracks are closed to enable a train to pass. Miter rails are most commonly used to lock the tracks; they are lowered at the end of each side of the span via a joint when the bridge is being locked into place and they are lifted when the bridge begins to open. Depending on the bridge design, the interlocking system may have electrical requirements similar to the drive control system. Electrical Power System. Modern movable bridges are controlled by solid-state electrical power systems that incorporate silicon-controlled rectifier (SCR) technology made up of power distribution panels, switches, circuit breakers, fuses, ground fault relays, over-current protection relays, cabling, etc. Specialized submarine cables run underwater to the center pier to bring power to the operator's house located in the swing span. Modern bridges use AC and DC motors. Due to their complexity, power systems have the highest failure rates [G 20 ] of any swing bridge system [START_REF] Eacker | Electrical reliability analysis for transit applications[END_REF]. Consequently, the American Railway Engineering and Maintenance-of-Way Association (AREMA) mandates an emergency auxiliary power supply such as a generator [G 21 ].

Quantitative Analysis Methodology

The quantitative analysis employed the UPPAAL Statistical Model Checker (64-bit v4.1.19) [START_REF] David | UPPAAL SMC tutorial[END_REF] to transform the leaves of the attack-fault tree to stochastic automata that simulate failures [START_REF] Kumar | Quantitative security and safety analysis with attack-fault trees[END_REF]. This section describes the automaton parameters for the basic attack steps (BAS) and basic component failures (BCF) used in the simulation.

Attack Leaf Automata

Each basic attack step leaf in an attack chain is modeled as a stochastic timed automaton. When an attack is activated, the attacker waits until (s)he is able to afford a cost f to proceed. After the attacker proceeds, the attack is undetected with probability w 1 /(w 1 + w 2 ) or detected with probability w 2 /(w 1 + w 2 ). The attack stops if it is detected; otherwise, the attack is either ongoing or activated. An ongoing attack is detected over time with an exponential probability rate λ 1 at a cost v per day to the attacker. An activated attack is detected over time with an exponential probability rate λ at a cost v per day to the attacker.

After an attack is executed, it succeeds with probability p/(p + q) and causes damage d to the bridge or the attack fails with probability q/(p + q). These probabilities are based on the attacker's skills, which are specified in an attacker profile. The advantage of this approach is that it is possible to determine the ratio of cost to the attacker against the damage done to the bridge.

Table 1 provides information about each basic attack step leaf in the attackfault tree segments in Figures 3 and4. The w 1 and w 2 detection rates in the table are configured to be high (discussed later in the What-If scenario). The configuration assumes that detection occurs at a higher rate when an attacker is attempting to gain access but at a lower rate after access is gained. The attack labels and their categorizations as logical and physical attacks are relevant to the attack profiles.

The security analysis modeled the attacks in UPPAAL using the As-Is and What-If scenarios [START_REF] Kumar | Quantitative security and safety analysis with attack-fault trees[END_REF]. In the As-Is scenario, detection capabilities were eliminated to establish a baseline for a successful attack based on an attacker profile. In the What-If scenario, the w 1 and w 2 detection rates were set to high. This enabled the determination of the effectiveness of the detection mechanisms at preventing attacks.

Fault Leaf Automata

Exponential probability distributions with means λ are used to model the failure rates, where the probability of a failure at time t is P (t) = 1e -λt . A stochastic automaton is employed to simulate each basic component failure as described in [START_REF] Kumar | Quantitative security and safety analysis with attack-fault trees[END_REF]. Each automaton has a λ-value that expresses the exponential failure rate of the failing node (component). After a period of time, damage d occurs to the system, which transitions to the failed state and sends a message to a higher attack-fault tree gate that the component has failed. Each fault leaf in Figures 3 and4 has its own automaton and the gates are stepped through during the UPPAAL simulation. Table 2 lists the sources of the λ-values corresponding to the basic component failures. All the failure rates are eventually expressed in terms of days so that the faults and attacks in the simulation have consistent time units. Note that the MTBF acronym in Table 2 denotes the mean time between failures.

[G66], [G67], [G70] [G72], [G73], [G74] [G79], [G80] [G60], [G62], [G63] [8]
Assume failure rate is 1.09 × 10 -7 per year based on concrete stress and corrosion data

[G69] -Assume failure rate is 20 per million hours

Attack-Fault Tree Analysis

Simulations were conducted to quantify the impacts of attacks and faults on swing bridge operations. During each test, UPPAAL stepped through a number of runs until the results became statistically significant (or insignificant) to provide feedback on the results. A run was stopped and considered to be a hit if the goal [G 0 ] was reached within a specified time frame. If the time expired before the goal [G 0 ] was reached, then the run was considered to be a miss. Statistical significance was assessed using 95% confidence intervals.

Critical Fault Path Analysis

The first set of simulations was conducted to analyze the probability of disruption over time. Figure 6 shows the probabilities of disruption over time for five scenarios. This helps identify the paths that result in maximum disruption to the railroad bridge over a ten-year period. After one year, the Only Faults scenario yielded a fault probability P (t ≤ 365) of 0.75. After two years, the The next set of simulations sought to identify the critical path in the attackfault tree. This involved repeated simulations while disabling each basic component failure leaf in the attack-fault tree for a one-year period, where the Only Faults scenario yielded a fault probability P (t ≤ 365) of 0.75. After considering all the leaves, the percentage differences between the new results and the baseline value were computed.

Table 3 shows the results for all the basic component failure leaves. The results demonstrate that the power-related leaves pose the greatest risk to bridge failure. The G 33 leaf corresponding to motor brake power failure yielded the greatest difference of -25.200% at P (t ≤ 365) = 0.561, followed by G 21 corresponding to generator failure with a difference of -21.730% and G 20 corresponding to power outage with a difference of -19.870%. Note that G 20 and G 21 share the same critical failure path because the power generator should take over in the event of a power failure. Generators are not built to last forever, but they have low exponential failure rates (λ = 0.0042). This may indicate a weakness in the model. Without some power system repair capabilities, the purpose of having a backup power system is defeated if its uptime (reliability) is less than the time between power failures.

Attacker Profile Analysis

Attacker profiles based on the attack-fault tree were created to evaluate various strategies against simulated adversaries. In particular, three attacker profiles were created to evaluate the effectiveness of adding security controls: Nate: Nation state attacker; Budget = $10, 000 × 10 3 ; Success rate for logical attacks p = 90%; Success rate for physical attacks p = 90%.

Mallory:

Hacker; Budget = $5, 000×10 3 ; Success rate for logical attacks p = 80%; Success rate for physical attacks p = 60%. Chuck: External attacker; Budget = $3, 000×10 3 ; Success rate for logical attacks p = 60%; Success rate for physical attacks p = 80%. Table 4 compares the results obtained for the As-Is and What-If scenarios by running the three attack profiles against the attack-fault tree over a ten-year time period.

In the As-Is scenario, Nate had a 36% chance of conducting a successful attack compared with 12.7% for Mallory and 10.2% for Chuck. Although Nate spent twice as much money on average in conducting a successful attack in the average case as Mallory ($4, 158.215 × 10 3 versus $2, 388.666 × 10 3 ), they caused roughly the same amount of average damage per attack ($1, 066.595 × 10 3 versus $1, 058.763 × 10 3 ). This similarity suggests that logical attacks were likely to be more successful because Mallory had a higher probability of successful attacks. Meanwhile, Chuck spent an average of $1, 706.83 × 10 3 per successful attack, resulting in an average of $442.77 × 10 3 in damage per successful attack. This also confirms that logical attacks are more likely to occur given the resources because Chuck is more likely to succeed with physical attacks. Time comparisons show that Nate (828.469 days) took longer on average than Mallory (606.163 days) and Chuck (410.418 days).

In the What-If scenario, the detection values for w 1 and w 2 were reconfigured as shown in Table 1. The percentages of successful attacks declined for Nate by -37.22%, Mallory by -64.25% and Chuck by -49.51%, demonstrating the utility of implementing detection mechanisms for all three attacker profiles. Nate's average time for attacks increased by 18.56% and cost increased by 6.04%, but he presumably took greater risks with his additional resources because the damage inflicted also increased by 27.66%. The simulation for Nate was executed ten additional times and similar results were obtained, confirming that the results were not anomalous. In contrast, Mallory saw an increase in the average time required to conduct successful attacks of only 3.76%, but decreases in cost of -30.88% and damage of -28.8%. Chuck saw a very large increase in the average time required to conduct successful attacks of 136.79%, only a slight increase in the average cost of 4.06%, but a large increase in damage of 51.35%. These results indicate that additional detection mechanisms would be more useful against strictly logical attackers (Mallory) than adversaries who are stronger at physical attacks (Nate and Chuck).

Critical Attack Path Analysis

The observation that attackers with strengths in logical attacks may be at a disadvantage influenced the identification of critical attack paths in the attack-fault tree that might provide an explanation. This was accomplished by re-executing the No Attack Detection scenario discussed in Section 6.1 with Nate as the attacker.

The executions were configured to run for ten years without any detection mechanisms in place. After running through a baseline test with all the basic attack step leaves enabled, the differences in the new results with probability P (t ≤ 3, 650) = 0.341 were computed.

Table 5 shows the results for all the attack paths. The physical attack A 1 , which physically cut network links, is critical because it has the highest difference: a -19.365% drop in the probability of successful attacks. This explains why physical attackers fared better in the What-If scenario. Upon applying detection methods of similar strength to both logical and physical attacks, adversaries who were stronger at physical attacks (Nate and Chuck) were still able to increase the amount of damage caused. This was due to their ability to perform attack A 1 that cut bridge network links with higher success rates.

Related Work

Previous work [START_REF] Wang | Safety and security analysis for movable railroad bridges[END_REF] introduced the security and safety risks facing movable railroad bridges and leveraged dynamic attack trees and fault trees to map possible vulnerabilities. Two separate models, one involving security and the other involving safety, were developed after researching control systems for a specific swing bridge. The previous work also revealed that many of the attacks and faults tended to overlap.

In contrast, the research described in this chapter integrates attacks and faults in a single model. The integrated attack-fault tree model was recently introduced by Kumar and Stoelinga [START_REF] Kumar | Quantitative security and safety analysis with attack-fault trees[END_REF], who used it to analyze a number of example systems. However, this chapter describes the first real-world application of the integrated attack-fault tree model, as well as the first application to a bridge system.

Historical Swing Bridge Failures

As discussed in the introductory section, data about swing bridge failures is limited due to a variety of factors. This research began by compiling data about swing bridge failures that was used to create the attack-fault tree.

The following additional information, categorized by the impacted swing bridge subsystems, is highly relevant to the faults considered in the model: Superstructure System: In 2014, a fire at a 104-year-old portal swing bridge in New York City cut power to the bridge. The resulting 70-minute outage delayed or cancelled 52 trains [START_REF] Mcgeehan | 104-year-old portal bridge presents °900 million problem for rail commuters[END_REF].

Substructure System: The Gasparilla Island Swing Bridge in Charlotte County, Florida was recently replaced because its concrete girders from 1958 were structurally deteriorating, leading to high risks of failure due to storm surges and vehicular impacts [START_REF] Sinson | Gasparilla Island Swing Bridge replacement[END_REF]. Incident data about bridge allisions by marine vessels is posted by the U.S. Coast Guard [26].

Support System: Older swing bridge center bearing designs are prone to instability when the bridges are unbalanced. As a result, a number of swing bridge renovation projects have been undertaken recently to address the problem, including the Court Street Bridge in Hackensack, New Jersey [START_REF] Burgos | Machinery rehabilitation of the Court Street Bridge over the Hackensack River[END_REF] and the East Haddam Swing Bridge in Connecticut [START_REF] Dewolf | History of Connecticut's Short-Term Strain Program for Evaluation of Steel Bridges[END_REF]. In 2010, the Somerleyton Swing Bridge in Norfolk, England suffered a catastrophic failure due to a bearing system failure [START_REF] Rimmer | Somerleyton Swing Bridge, Report by Waterways Strategy Officer, Navigation Committee[END_REF].

Wedge faults have led to several prolonged swing bridge outages. In 2017, degraded wedges impacted operations of the Little Current Swing Bridge in Ontario, Canada [START_REF] News | Delays at swing bridge in Little Current due to repairs says MTO[END_REF]. In 2014, a complete wedge failure resulted in significant downtime of the Walk Bridge in Norwalk, Connecticut [START_REF]Emergency Repair and Reliability Report FINAL[END_REF].

Drive System: In 2010, a gearbox failure in the Whitby Swing Bridge in North Yorkshire, England terminated bridge operations for one week [START_REF]Swing bridge reopens in Whitby after gearbox failure[END_REF].

Interlocking System: In 1996, Amtrak Train No. 12 derailed on the Portal Bridge near Secaucus, New Jersey due to defective miter rails [G 72 , G 73 , G 74 ] [START_REF]Derailment of Amtrak Train No. 12 and Sideswipe of Amtrak Train No. 79[END_REF]. In 2014, the Walk Bridge in Norwalk, Connecticut was closed due to an interlocking problem with its miter rails [START_REF]Emergency Repair and Reliability Report FINAL[END_REF].

Electrical System: An interesting story from 2002 about the Old Saybrook Bridge is recounted in [START_REF] O'neill | Failure and quick recovery of movable bridge on the Acela Line[END_REF]. This bascule bridge had electrical components dating back to its original design and construction in 1907. Troubleshooting the failed electrical system was an extremely complex task.

Rules and Regulations

Several rules and regulations govern the management of movable bridges in the United States. The U.S. Coast Guard oversees movable bridge operations on navigable waterways. Organizations such as the American Association of Railroads (AAR) and the American Association of State Highway and Transportation Officials (AASHTO) promulgate national standards and requirements for movable bridge construction, maintenance and inspection. In addition, the following federal regulations govern movable bridge operations: Movable Bridge, Interlocking of Signal Appliances with Bridge Devices (49 CFR 236.312 [START_REF][END_REF]): This section specifies rules and restrictions governing the passage of trains over movable bridges.

Movable Bridge Locking (49 CFR 236.387 [START_REF]Code of Federal Regulations[END_REF]): This section mandates that movable bridges shall be inspected once a year.

Bridge Lighting and Other Signals (33 CFR Chapter 1, Sub-Chapter j, Part 118 [START_REF]Code of Federal Regulations, Title 33 -Nav[END_REF]): This section mandates the lighting requirements required for signaling the status of movable bridge operations on navigable waters.

Conclusions

Movable bridges have been used for hundreds of years, but they continue to evolve in their designs and implementations. Numerous movable bridges are being upgraded by automating and networking their components, which adds a new layer of risk to these vital transportation infrastructure assets. The research described in this chapter has leveraged the attack-fault tree model to integrate the physical risks involved in operating railroad swing bridges in the face of risks posed by physical attacks on bridge subsystems and cyber attacks on control systems.

The attack-fault tree approach integrates attacks and faults in a single model that supports the use of stochastic timed automata to identify the critical failure paths for a movable swing bridge. In particular, the integrated model reveals that physical network attacks and power faults are the best ways to disrupt movable swing bridge operations. Moreover, by stepping through the model, it was determined that superstructure and substructure system faults are statistical anomalies as far as the integrated attack-fault model is concerned. Thus, future research should focus on the attack surfaces and mechanical and electrical system failures.

The principal conclusion of this research is that the attack-fault tree approach is effective at identifying critical attack and fault paths at a high level. However, the swing bridge analysis reveals that the model falls short in some ways. In the case of a swing bridge, many faults can only occur only while the bridge is moving and other faults can occur only when the bridge is closed. The state of the system is, therefore, important, but the attack-fault tree model does not take the system state into account. For example, components such as electric motors and gears have failure rates that are established only when the system is in use. A movable bridge is in motion only for a few minutes at a time and these components spend the majority of their time at rest. Additionally, the attack-fault tree allows for the incorporation of attack chains, but it does not necessarily consider the specific system configurations included in previous attack tree models. The attack-fault tree model also abstracts security control solutions as simple detection mechanisms, which reduces its applications in real-world environments.

Note that the views and opinions expressed herein are those of the authors and do not necessarily state or reflect the views and opinions of the Federal Railroad Administration or U.S. Department of Transportation, and shall not be used for advertising or product endorsement purposes.

Figure 1 .

 1 Figure 1. An open BNSF railroad swing bridge [18].

Figure 2 .

 2 Figure 2. Finite-state machine model of a movable bridge.

Figure 3 .Figure 4 .Figure 5 .

 345 Figure 3.Attack-fault tree for the mechanical and electrical subsystems.

Figure 3

 3 Figure 3 shows paths [G 2 ], [G 32 ] and [G 68 ]. Figure 4 shows paths [G 54 ] and [G 64 ]. All five paths could result in [G 0 ].

  [G 50 ]. Additional force on the bridge span caused by overweight vehicles could result in damage to a worn shaft or rack and pinion system [G 79 , G 80 ]. Gear drives [G 40 ] may have open or enclosed gearing for rotating the shaft [G 47 , F DEP ]. Possible gearbox faults are water seepage [G 42 ] and poor lubrication [G 43 ]. The drive system [G 31 , F DEP ] is powered by an electric motor [G 27 ] that produces the torque needed to drive the system. Motor brakes [G 32 , G 38 ] are spring set and electrically released.

Table 2 .

 2 Basic component failure leaf sources and computation notes.

	Failures	Source Computation Notes
	[G15], [G16], [G17]	-	Assume MTBF is 20,000 hours based on a product
			review
	[G20], [G33]	[11]	Assume annual failure rate is 0.4
	[G21]	[14]	Assume MTBF is 500 hours
	[G27], [G38]	[20]	Assume failure rate is ten per million hours
	[G40], [G42], [G43]	[1]	Assume MTBF is 40,000 hours based on L10 life
			at the rated torque
	[G50]	[20]	Assume failure rate is eight per million hours at a
			15-year renewal interval
	[G51]	[20]	Assume failure rate is 14 per million hours at a
			15-year renewal interval
	[G53]	[20]	Assume failure rate is 20 per million hours at a
			15-year renewal interval
	[G55], [G57], [G58],	[6]	Assume or derive an annual failure rate

years) Only Faults No Attack and Fault Detection No Attack Detection Low Attack Detection Rate High Attack Detection Rate Figure

	1.00000
	0.90000
	0.80000
	0.70000
	0.60000
	0.50000
	0.40000
	0.30000
	0.20000
	0.10000
	0.00000
	1	2	3	4	5	6	7	8	9	1 0
					Time t (

6.

Probability of disruption at time t (95% confidence interval).

Only Faults scenario yielded a higher fault probability P (t ≤ 730) of 0.942. Scenarios with No Attack Detection, Low Attack Detection Rate and High Attack Detection Rate yielded two-year probabilities of 0.175, 0.147 and 0.0631, respectively.

Table 3 .

 3 Fault disruption percentages measured for all leaves (0.750).

	Leaf P(t ≤ 365) Difference Leaf P(t ≤ 365) Difference
	G15	0.720	-4.000%	G57	0.748	-0.270%
	G16	0.693	-7.600%	G58	0.734	-2.130%
	G17	0.724	-3.470%	G60	0.749	-0.130%
	G20	0.601	-19.870%	G62	0.716	-4.530%
	G21	0.587	-21.730%	G63	0.748	-0.270%
	G27	0.702	-6.400%	G66	0.758	1.070%
	G33	0.561	-25.200%	G67	0.728	-2.930%
	G38	0.699	-6.800%	G69	0.689	-8.130%
	G40	0.718	-4.270%	G70	0.749	-0.130%
	G42	0.731	-2.530%	G72	0.737	-1.730%
	G43	0.724	-3.470%	G73	0.724	-3.470%
	G50	0.722	-3.730%	G74	0.752	0.270%
	G51	0.708	-5.600%	G79	0.722	-3.730%
	G53	0.697	-7.070%	G80	0.735	-2.000%
	G55	0.735	-2.000%

Table 4 .

 4 As-Is versus What-If scenario results over ten years.

	Nate	Mallory	Chuck

Table 5 .

 5 Analysis of attack disruptions measured against P (t ≤ 3, 650) = 0.341.

	Attack P(t ≤ 3, 650) Difference Attack P(t ≤ 3, 650) Difference
	A1	0.275	-19.365%	A6	0.347	1.858%
	A2	0.343	0.8072%	A7	0.349	2.38%
	A3	0.343	0.8072%	A8	0.358	5.234%
	A4	0.341	0%	A9	0.339	-0.5234%
	A5	0.330	-3.244%

Acknowledgements

This research was supported by Grant No. DTFR5317C00018 from the Federal Railroad Administration, U.S. Department of Transportation. The authors thank Mr. Francesco Bedini Jacobini and Mr. Jared Withers from the Federal Railroad Administration for their advice and assistance.

Table 1. Basic attack step leaf information.

Attack

Label Path Type Description