The Use of Attack Trees in Assessing Vulnerabilities in SCADA Systems

Protocol standards, particularly those for critical control systems in the petroleum and power industry, have traditionally been designed to address a specific application with little regard for security. At best, there has been only passing concern for security issues that may arise in deployment; at worst, protocol designers assume a closed (and therefore secure) environment, which, in many cases, no longer exists. Where security has been a consideration, there has been no clear methodology to assess the security risks in the protocol specification. This paper describes the application of the attack tree methodology to the common SCADA protocol MODBUS/TCP. The authors identify eleven possible attacker goals and identify security vulnerabilities inherent in both the specification and in typical deployments of SCADA systems. These are then used to suggest possible best practices for SCADA operators and improvement to the MODBUS protocol. 1. SCADA protocols and security Supervisory Controls and Data Acquisition (SCADA) protocols are communications protocols designed for the exchange of control messages on industrial networks. Over the past three decades, several hundred of these protocols have been developed for both serial, LAN and WAN based communications in a wide variety of industries including petrochemical, automotive, transportation and electrical generation/distribution. Approximately 10 protocols currently dominate the industrial marketplace and include protocols such as MODBUS, DNP3, EtherNET/IP, PROFIBUS and Foundation Fieldbus. The choice of protocol is typically a function of the operating requirements, industry preference, vendor and the design history of the system. For example, in an oil refinery an operator workstation might use the MODBUS/TCP protocol to communicate with a control device such as a Programmable Logic Controller (PLC). Alternatively, in power utility’s SCADA system, a master located in a central facility could use the DNP3 protocol to query and control slave Remote Terminal Units (RTU) distributed in remote sub-stations. Most SCADA protocols were designed long before network security perceived to be a problem. The traditional SCADA system was a closed serial network that contained only trusted devices with little or no connection to the outside world. As control networks evolved, the use of TCP/IP and Ethernet became common place and interfacing to business systems became the norm. The result was that the closed trust model no longer applied and vulnerabilities in theses systems began to appear [1]. In particular, network security problems from the business network and the world at large could be passed onto process and SCADA networks, putting industrial production, environment integrity and human safety at risk. One of the primary weaknesses exploited in attacks against the Internet and business information systems are vulnerabilities in the communications protocols and their implementations. SCADA systems are no exception to this rule, but little is known about the specific vulnerabilities in SCADA protocols. To address this, the Group for Advanced Information Technology (GAIT) at BCIT and the Cisco Systems’ Critical Infrastructure Assurance Group (CIAG) chose to investigate possible vulnerabilities in the SCADA protocol MODBUS/TCP. This protocol was selected as a starting point since it is both one of the simplest and most widely used of all SCADA protocols in critical infrastructures. 2. The MODBUS protocol The MODBUS communications system was created in the late 1970’s by the Modicon Corporation (now Schneider Electric) to allow communications to its line of industrial PLCs. The protocol’s simplicity and efficiency, combined with the publishing of its specifications by Modicon [2], caused it to become widely adopted throughout the industrial controls and SCADA world as a common industrial standard. The original MODBUS system was a simple twolayer communication stack running on top of a serial EIA-232 link. As different physical layer options became available, it was subsequently marketed as a number of different of network products, the best known of which are MODBUS, MODBUS+ and MODBUS/TCP. The common element in all of these MODBUS networks is a client-server command structure commonly known as the MODBUS Application Protocol (MBAP), a layer-7 protocol in the Open Systems Interconnection Reference Model (OSI/RM) as illustrated in Figure 1. Figure 1 – The MODBUS protocol family OSI stack representation A simple request-reply scheme is used for all MBAP transactions. The client (also known as master) device initiates a request and the server (also known as slave) replies. For example, when a Human Machine Interface (HMI) workstation requires a value from a PLC it sends a request message to start the data transfer process. The PLC then sends a response providing the requested information. In this situation, the device running the HMI is acting as the client/master and the PLC is acting as the server/slave. Each message contains a function code is that is set by the client/master and indicates to the server/slave what kind of action to perform. Function codes are the same for requests and responses since the server simply reflects the function code back to the client. There are 127 possible function codes that fall into three general categories: Public function codes, User Defined function codes and Reserved function codes. Sub-codes are added to some function codes to define multiple actions or to allow future enhancements. 3. Using attack trees to model system threats and vulnerabilities Over the past few years the information technology world has seen exponential growth in the number of security vulnerabilities being reported for common networked systems. For example, the Carnegie-Mellon CERT “Vulnerabilities Reported 1995-2002” reports cyber vulnerabilities have grown from less than 300 per year in 1998 to over 4000 only four years later [3]. The overwhelming growth of vulnerabilities has become one of the key challenges facing operational security personnel who must not only consider an increasing number of attacks, but how these attacks can be combined in complex ways. Clearly a methodology is needed to organize attack possibilities, understand their inter-relationships and rank them according to risk. The approach selected in this paper is the “Attack Tree” technique as initially described by Bruce Schneier [5]. This technique provides a structured yet flexible means of conducting security analyses of protocols, applications, and networks. Although “fault trees” have long been an accepted system analysis technique, this methodology was first applied to the domain information security a Dr Dobb’s Journal article in 1999. Subsequently, CERTC/CC developed a more formal application of the technique, introduced standardized notation and provided more complex examples. The first published application of attack trees to a network protocol was “An Attack Tree for the Border Gateway Protocol” [4], which is currently under consideration by the IETF Routing Protocol Security working group. Building on these approaches, the project team relied heavily on attack trees to support our vulnerability analysis and testing of MODBUS/TCP with the goal of identifying flaws that could result in the greatest damage to SCADA systems. One of the primary benefits of using attack trees is that they focus analysis on measurable goals that can ultimately be translated into specific tests against real-world devices, networks, and protocol implementations. This helps avoid the trap of overly-academic security research that often fails to consider the difficulty of conducting the attacks and cannot measure the impact on targeted systems. Attack trees also encourage a structured elaboration of events (i.e. specific attack goals) that must occur for a successful intrusion to take place. This promotes the consideration of all reasonable avenues of approach for an attack and also facilitates the identification and optimal deployment of countermeasures. Furthermore, since each node (a discrete attacker goal) may be decomposed into subordinate nodes (sub-goals, or a means of achieving the parent goal), attack trees allow security analysis to be conducted at multiple layers of abstraction, allowing researchers to focus on areas of interest while acknowledging other intrusion paths. Lastly, using attack trees allows common attacks to be referenced as reusable modules that apply to multiple network scenarios. The clearest way to demonstrate this is by example, as illustrated by Schneier in his original article on the attack tree methodology [5]. For instance, consider an individual trying to gain unauthorized physical access to a building. An attack tree for such an act might look like this: Goal: Gain unauthorized physical access to building Attack: OR 1. Unlock door with key 2. Pick lock 3. Break window 4. Follow authorized individual into building This simple tree should be read as follows: to gain unauthorized physical access to a building, the adversary must unlock the door with a key, pick the lock, break a window, or follow an authorized individual into the building. The "OR" operator defines that only one is required. In the same tree, replacing the "OR" with "AND" would require that all subordinate goals be achieved to realize the parent goal. Attack trees at this level of detail are of limited use. Their true value comes in understanding how an adversary can execute one of the listed subordinate goals. This requires the following, more detailed, attack tree: Goal: Gain unauthorized physical access to building OR 1. Unlock door with key OR 1.1. Steal Key 1.2. Social Engineering OR 1.2.1. Borrow key 1.2.2. Convince locksmith to unlock door 2. Pick lock 3. Break window 4. Follow authorized individual into building AND 4.1 Wear appropriate clothing for the location OR 4.2.1. Act like you belong and foll