July 2007
Svein Johan Knapskog, ITEM Martin Gilje Jaatun, SINTEF Kai Hansen, ABB
Master of Science in Communication Technology
Submission date:
Supervisor:
Co-supervisor:
Norwegian University of Science and Technology Department of Telematics
Security in Industrial Networks
Jan Tore Sørensen
Problem Description
A major trend in the automation and power industries is the transition from closed proprietary network solutions to open TCP/IP protocols running on Ethernet and also on wireless media. The new requirements on the security of the devices as a consequence of this, is a major challenge for the industry. It is necessary to create an overall security system for an industrial plant, spanning from corporate level access management systems, firewalls and update of Windows security patches to robustness of stack implementation on controllers, motor starters and instruments.
This assignment is focused around how the industrial protocols are implemented and the security level they offer vs. what is needed. A selection of protocols/devices will be examined in detail and tested with open source tools (e.g. Nessus) and the purchased tool MuSecurity at the ABB
communication lab in Billingstad (Oslo). This entails analyzing real OPC/SCADA equipment and examining what damage a hacker could do in a plant.
The outcome of this assignment will be a brief survey on state-of-the-art in SCADA security, a detailed description of security properties of the examined protocols, and suggested
improvements.
Part of the work will be performed at the ABB global lab for industrial Ethernet located in Billingstad. The majority of the work will however still be performed in Trondheim under the supervision of SINTEF ICT.
Assignment given: 21. January 2007 Supervisor: Svein Johan Knapskog, ITEM
Abstract
A major trend in the automation and power industries is the transition from closed pro- prietary network solutions to open TCP/IP protocols running on Ethernet technologies.
As these industries converge on an all IP platform, new challenges and requirements on the security level of the devices arise. The introduction of integrated operations in the oil and gas industry has provided many benefits for the industry, but it has also opened up the information flow between Distributed Control System (DCS), corporate and subcontractor’s networks. These developments increase the posibility of cyber se- curity vulnerabilities and incidents in DCS networks. This thesis focus on information security of DCS devices. We pressent and discuss state of the art technologies for pro- tecting DCS networks. We analyse a DCS protocol and assume the role of an attacker, using this knowledge to direct attacks against the DCS protocol and devices. We also perform vulnerability testing on industrial switches and controllers at ABB’s Corporate Research Center in Oslo, using vulnerability scanner and ”hacker” tools known in the IT world. We identify security vulnerabilities in these devices and propose mitigation paths to remove these vulnerabilities.
i
Preface
The work on this project has been a learning experience on many levels. I have been introduced to the automation world and gained an understanding of how network tech- nology is utilized in Distributed Control System (DCS) networks and industry plants. I was not aware of the challenges this industry face with regard to information security.
I especially appreciated the practical approach of this thesis and the many challenges it provided when it came to understanding DCS protocols and equipment.
There are several people that in various ways have contributed to the process of writing this thesis and the outcome of it.
I would like to thank ABB Corporate Research for allowing me to write this thesis and providing me with access to their equipment and laboratory in Oslo. I especially thank Kai Hansen for sharing his insight and expertise, helping me to understand the automation world and introducing me to ABB.
I would also like to thank SINTEF IKT for providing an office, workspace and laboratory in Trondheim and for including me socially in their working environment. I address a sin- cere thanks to Martin Gilje Jaatun for his enthusiasm, guidance and support throughout this thesis. His door has always been open for me.
Professor Svein Johan Knapskog has also contributed to the outcome of this project, in particular in the design and structure of the report.
iii
Contents
1 Introduction 1
1.1 Problem Description and Limitation . . . 2
1.2 Research Methodology . . . 2
1.3 SCADA and DCS . . . 3
1.4 Outline of the Thesis . . . 3
2 Background 5 2.1 Definitions . . . 5
2.1.1 Security . . . 5
2.2 Dependability . . . 6
2.3 Survivability . . . 7
2.4 Means of Network Protection . . . 7
2.4.1 Intrusion Detection System (IDS) . . . 8
2.4.2 Firewalls . . . 8
2.4.3 Anti-Virus . . . 10
2.5 Concepts and Architecture of DCS Systems . . . 10
2.6 Industrial Network Protocol . . . 13
2.6.1 The MMS . . . 13
2.7 Related work . . . 27
3 State of the Art 28 3.1 DCS Networks and Firewalls . . . 28
3.2 Securing DCS Communication . . . 31
3.2.1 Enhanced DCS Protocols . . . 31
3.2.2 Enhancing the DCS Application . . . 33
3.2.3 Wrapping and Tunneling . . . 33
3.2.4 Key Management in DCS Networks . . . 36
3.3 IDS for Distributed Control System (DCS) . . . 36
3.4 DCS Honeynet . . . 37
3.5 Recommended Network Topology . . . 38
4 Analysis of Manufacturing Message Specification (MMS) 42 4.1 ASN.1 . . . 42
v
4.2 BER . . . 42
4.3 Analysis of MMS Communication . . . 44
4.4 Decoding MMS Communication . . . 46
4.4.1 The First PDU . . . 49
4.4.2 The Second PDU . . . 55
4.4.3 The Third PDU . . . 58
4.4.4 The Fourth PDU . . . 62
4.4.5 The Fifth PDU . . . 65
4.4.6 The Sixth PDU . . . 66
4.4.7 The Seventh and Eighth PDU . . . 67
4.5 Security in MMS . . . 68
4.6 MSS Plugin for Wireshark . . . 70
5 Test Methodology and Tools 71 5.1 Test Methodology . . . 71
5.1.1 Blackbox vs Whitebox Testing . . . 72
5.1.2 Validation Criteria and Result Classification . . . 73
5.2 Tools . . . 73
5.2.1 Nmap . . . 74
5.2.2 Nessus . . . 76
5.2.3 IP Stack Integrity Checker . . . 76
5.2.4 Hydra . . . 76
5.2.5 Protos Project Test Suite . . . 77
5.2.6 Scapy . . . 78
5.2.7 MuSecurity’s Mu-4000 . . . 78
5.2.8 Achilles Security Test Device . . . 78
6 Equipment 79 6.1 Moxa EDS-508 . . . 79
6.2 Hirschmann MM3-4TX1-RT . . . 80
6.3 Ontime Networks T200 Fieldswitch . . . 80
6.4 ABBs AC 800 M PM 860 . . . 81
7 Test Results 83 7.1 Test for switches. . . 83
7.2 Moxa EDS-508 . . . 84
7.2.1 Summary of Moxa test results . . . 84
7.2.2 Nmap scan . . . 84
7.2.3 Nessus Scan . . . 86
7.2.4 Hydra . . . 87
7.2.5 Mu-4000 Scan . . . 88
7.2.6 Moxa Discussion . . . 89
7.3 Hirschmann MM3-4TX1-RT . . . 91
7.3.1 Summary of Hirschmann MM3 Test Results . . . 91 vi
7.3.2 Nmap . . . 91
7.3.3 Nessus Scan . . . 92
7.3.4 Protos Project Test Suite . . . 93
7.3.5 Mu-4000 . . . 94
7.3.6 Hirschmann Discussion . . . 95
7.4 Ontime FS200 . . . 97
7.4.1 Summary of Ontime FS200 Test Results . . . 97
7.4.2 Nmap . . . 98
7.4.3 FTP Service . . . 99
7.4.4 Telnet Service . . . 100
7.4.5 Nessus with Hydra Plugin Scan . . . 100
7.4.6 IP Stack Integrity Checker . . . 102
7.4.7 Protos Project Test Suite . . . 103
7.4.8 Mu-4000 Report . . . 105
7.4.9 Ontime Discussion . . . 105
7.5 AC 800 M . . . 108
7.5.1 Summary of AC 800 M Test Results . . . 108
7.5.2 Nmap . . . 108
7.5.3 RPC Services . . . 110
7.5.4 Nessus . . . 110
7.5.5 Consequences of a Long URL Attack . . . 111
7.5.6 Achilles Security Scan . . . 114
7.5.7 Mu-4000 Reports . . . 114
7.5.8 AC 800M Discussion . . . 115
8 A Packet Crafting Attack 118 8.1 First Packet Crafting Attack . . . 118
8.1.1 Test Setup . . . 118
8.1.2 Establishing a TCP Connection . . . 118
8.1.3 The Connection Oriented Transport Protocol (COTP) Connection 120 8.1.4 MMS Communication Context Establishment . . . 122
8.1.5 MMS Data Request . . . 125
8.2 Replay of MMS PDUs . . . 126
8.3 Setting a Value on the AC 800 M . . . 127
8.4 A Simple Buffer Overflow Attempt . . . 128
8.5 Discussion of the Packet Crafting Attack . . . 129
9 Discussion 132 9.1 Plant Security . . . 132
9.2 Improvements . . . 138
9.3 Comment on Tools . . . 138
10 Further Work 141 10.1 Analysis of DCS Protocols . . . 141
vii
10.2 Testing of DCS Devices. . . 142
10.3 Protecting DCS Networks . . . 143
10.4 Constructing MMS Packets . . . 143
10.5 Adapting IT Security Tools to DCS Equipment . . . 144
11 Conclusion 145 Bibliography 147 Web Resources 155 Appendices A MMS 156 A.1 Table of MMS Objects with Description . . . 156
A.2 ASN.1 MMS . . . 159
A.2.1 The MMSPDU Module . . . 159
A.2.2 The ConfirmedServiceRequest Module . . . 160
A.2.3 The MMS Data Module . . . 162
A.2.4 The MMS DataAccessError Module . . . 163
A.3 The MMS initiate-Request/Response PDU . . . 164
B Nessus Report on 193.75.73.3, Moxa Switch 167 B.1 Open ports (TCP and UDP) . . . 167
B.2 Details of the Vulnerabilities . . . 167
B.2.1 Problems Regarding : General/TCP . . . 167
B.2.2 Problems Regarding : HTTPS (443/TCP) . . . 169
B.2.3 Problems Regarding : Telnet (23/TCP) . . . 170
B.2.4 Problems Regarding : www (80/TCP) . . . 171
B.2.5 Problems Regarding : SNMP (161/UDP) . . . 172
B.2.6 Problems Regarding : General/UDP . . . 174
B.2.7 Problems Regarding : General/ICMP . . . 174
B.3 Mu 4000 Summary Report . . . 174
C Nessus Report on 193.75.73.8, Hirschmann Switch 178 C.1 Open Ports (TCP and UDP) . . . 178
C.2 Details of the Vulnerabilities . . . 178
C.2.1 Problems Regarding : General/TCP . . . 178
C.2.2 Problems Regarding : NTP (123/UDP) . . . 181
C.2.3 Problems Regarding : General/ICMP . . . 181
C.2.4 Problems Regarding : General/UDP . . . 182
C.3 Mu 4000 Summary Report . . . 182
D Nessus Report on 193.75.73.20, Ontime FS 200 188 D.1 Open Ports (TCP and UDP) . . . 188
viii
D.2 Details of the Vulnerabilities . . . 188
D.2.1 Problems Regarding : General/TCP . . . 188
D.2.2 Problems Regarding : FTP (21/TCP) . . . 190
D.2.3 Problems Regarding : SNMP (161/UDP) . . . 193
D.2.4 Problems Regarding : Telnet (23/TCP) . . . 195
D.2.5 Problems Regarding : general/ICMP . . . 197
D.2.6 Problems Regarding : General/UDP . . . 198
D.3 Mu 4000 Summary Report . . . 198
E Nessus Report on 172.16.0.20, ABB AC 800 M 201 E.1 Open ports (TCP and UDP) . . . 201
E.2 Details of the Vulnerabilities . . . 201
E.2.1 Problems Regarding : General/TCP . . . 201
E.2.2 Problems Regarding : HTTP (80/TCP) . . . 203
E.2.3 Problems Regarding : General/ICMP . . . 207
E.2.4 Problems Regarding : General/UDP . . . 208
E.2.5 Problems Regarding : NTP (123/UDP) . . . 208
E.3 Mu 4000 Summary Report . . . 208
F AC 800 M Stack Vulnerability Summary Report 213 F.1 Test Configuration Summary . . . 214
F.1.1 Vendor Control System . . . 214
F.2 Device Under Test . . . 215
F.3 Test Case ResultSummary . . . 215
F.3.1 ARP Flood . . . 215
F.3.2 TCP SYN Flood . . . 216
F.3.3 TCP/IP Land Attack . . . 217
F.3.4 TCP Fragmentation Fuzzer . . . 218
ix
List of Figures
2.1 Laprie‘s Taxonomy of dependability [29] . . . 6 2.2 An abstract view of an automation network process . . . 11 2.3 An example of a Distributed Control System implementation [45]. . . 12 2.4 The VMD model depicting communication between an control builder
with an MMS client and a device running an MMS server [48] . . . 15 2.5 A Confirmed Service state machine as seen by the MMS server (Service
Responder) using the PDUs numbered in the list above [7]. The Reject- PDU is not included in this figure. . . 18 2.6 The MMS communication stack specified according to all seven layers of
International Standards Organizations (ISO)s OSI communication stack . 19 3.1 Comparison chart for the enumerated DCS segregation architectures listed
above as proposed by the NISCC. . . 29 3.2 U.S Department of Homeland security Control Systems security programs
recommendation for Defense in depth architecture for SACDA networks from the NIST guide [45]. . . 40 3.3 The various networks are depicted as clouds to provide simplified view of
the architecture depicted in figure 3.2 . . . 41 4.1 The MMS communication stack as Wireshark detects it. The figure does
not show the payload of COTP, which is the BER encoded ASN.1 struc- tures of MMS. . . 44 4.2 The picture illustrates MMS communication between an ABB AC 800 M
controller and a client workstation enumerating the intercepted PDUs. As seen in the picture the packet sequence repeats itself. . . 47 4.3 Screendump from ABB’s Control Builder application depicting the pro-
gram tree hierarchy. We wish the reader to note theApplication 1 string in the program hierarchy. . . 48 5.1 The rack mountable Mu-4000 device manufactured by MuSecurity . . . . 74 6.1 A collection of three Moxa Industrial Ethernet switches. The EDS-508 is
the leftmost switch . . . 79 6.2 A Hirschmann MM3-4TX1-RT industrial ethernet switch. . . 80
x
6.3 An Ontime industrial ethernet switch. . . 81 6.4 ABB’s AC 800 M controller with two power supplies and an I/O unit. . . 82 7.1 The lab setup for testing the primary service of switches. . . 84 8.1 The lab setup for ”proof-of-concept” packet crafting attack. . . 119 9.1 A general DCS plant network [28]. . . 133 9.2 A workstation on the corporate network is accessing information stored
inside the DCS network [28]. . . 135 9.3 A redundant network and controller architecture [28]. . . 137
xi
List of Tables
2.1 The basic methods (services) inherited from the VMD object [21]. . . 17 2.2 Mapping of ACSE primitives to the ISO presentation layer services [5]. . . 20 3.1 The network layers and common security protocols [19]. . . 34 4.1 Description of the BER identifier. The seventh and sixth bits are com-
bined to denote the class of the ASN.1 tag. The sixth bit of the identifier indicates whether the represented data type is a primitive or constructed one. The remaining X’ed bits of the identifier represent a class number which is associated with a specific data type. . . 43 7.1 The table summarizes the test results from the Moxa EDS-508 switch
using the classification defined in section 5.1.2. . . 85 7.2 The table displays an overview of which tools detected which services and
also indicates if a service is consider vulnerable by the tools. . . 89 7.3 The table summarizes the test results from the Hirschmann MM3-4TX1-
RT switch using the classification defined in section 5.1.2. . . 92 7.4 The table displays the timeout- and delay parameters used in the Mu-4000
test of the Hirschmann switch. . . 94 7.5 The table displays an overview of which tools detected which services and
also indicates if a service is consider vulnerable by the tools. . . 96 7.6 The table summarizes the test results from the Ontime FS200 switch using
the classification defined in section 5.1.2. . . 97 7.7 The table displays an overview of which tools detected which services
and also indicates if a service is consider vulnerable by the tools. The abbreviation TN is a abbreviation for the Telnet and SNMP is a label for both the SNMP community name test and the Protos test suite. . . 106 7.8 The table summarizes the test results from the AC 800M controller using
the classification defined in section 5.1.2. . . 109 7.9 The table displays how the timeout, delay parameters relate to the number
of errors reported by the Mu-4000 on the AC 800 M. . . 115 7.10 The table displays an overview of which tools detected which services and
also indicates if a service is consider vulnerable by the tools. . . 116 xii
11.1 The table displays test results from all device tests in this thesis using the
classification defined in section 5.1.2. . . 145
A.1 The 15 MMS Objects and a description of their intended use . . . 158
F.1 The Configuration of the VCS’s Network Interface Cards. . . 214
F.2 Monitored OPC Tags and Event Conditions. . . 214
F.3 The Configuration of the Achilles Server’s Network Interface Cards. . . . 215
F.4 Device Under Test Definition. . . 215
F.5 The Configuration of the DUT’s Network Interface Cards. . . 215
xiii
Acronyms
ACSE Association Control Service Element ACSE is the OSI method for establishing a call between two application programs. ACSE checks the identities and contexts of the application entities, and could apply an authentication security check.
ASN.1 Abstract Syntax Notation One ASN.1 is a formal language for the abstract (platform-independent) description of messages exchanged between machines. It is used to encode and decode messages in a wide range of applications, including SNMP. Objects such as integers are encoded in a manner called tag- length-value (TLV) that is independent of any processor architecture, such as big or little endian.
The tag indicates the object type, the length is the object size, and the value is the encoded object. ASN.1 also allows structured (or nested) definitions
ARP Address Resolution Protocol ARP is the standard method for finding a host’s hardware address when only its network layer address is known. Due to the over- whelming prevalence of IPv4 and Ethernet, ARP is primarily used to translate IP addresses to Ethernet MAC addresses.
BER Basic Encoding Rules BER is a set of rules for encoding ASN.1 objects into a sequence of octets. It is a self-identifying and self-delimiting transfer syntax for data structures described in ASN.1 notations.
COTP Connection Oriented Transport Protocol COTP is the International Standards Organizations (ISO) connection oriented transport protocol in the Open System Interconnection (OSI) modell. COTP is packet oriented, it transports packets of data from one user to the other, so the receiver will get exactly the same data boundaries as the sender transmitted. COTP uses the concept of TSAPs instead of ports.
DCS Distributed Control System DCS is a big Progammable Logic Controller (PLC) that is typically networked to other controllers, PLCs or field devices. It is de- signed to have a series of decentralised control centres which have some degree of autonomy, but are still integrated into a whole system (except in an emergency shutdown). DCS typically has a workstation to interface with the controller and can be very expensive due to built-in safty and fail-over features.
xiv
DMZ De-Militarized Zone DMZ is a network area or subnetwork that sits between an organization’s internal network and an external network, usually the Internet. The point of a DMZ is that connections from the internal and the external network to the DMZ are permitted, whereas connections from the DMZ are only permitted to the external network-hosts in the DMZ may not connect to the internal network.
The DMZ is typically used for connecting servers that need to be accessible from the outside world, such as e-mail, web and DNS servers.
DNP3 Distributed Network Protocol DNP3 is a set of communications protocols used between components in process automation systems. it was developed to facilitate communications between various types of data acquisition and control equipment (e.g. SCADA systems). DNP3 provides multiplexing, data fragmentation, error checking, link control, prioritization, and layer 2 addressing services for user data.
DOS Denial-Of-Service DOS is a type of attack on a network that is designed to bring the network to its knees by flooding it with useless traffic.
FTP File Transfer Protocol FTP is used on the Internet for exchanging files. FTP uses the Internet’s TCP/IP protocols to enable data transfer. FTP is most commonly used to download a file from a server using the Internet or to upload a file to a server
HTTP HyperText Transfer Protocol HTTP is the protocol used to transfer data over the World Wide Web. That’s why all Web site addresses begin with ”http://”.
Whenever you type a URL into your browser and hit Enter, your computer sends an HTTP request to the appropriate Web server. The Web server, which is designed to handle HTTP requests, then sends to you the requested HTML page.
ICCP Inter-Control Center Communications Protocol ICCP provides data exchange over wide area networks (WANs) between control centers in process automation systems.
ICMP Internet Control Message Protocol ICMP an extension to the Internet Protocol (IP) defined by RFC 792. ICMP supports packets containing error, control, and informational messages. The PING command, for example, uses ICMP to test an Internet connection.
ICS Industrial Control System ICS is a general term that encompasses seceral types of control systems, including supervisory control and data acquisition (SCADA) systems, distributed control systems (DCS) and other smaller control system con- figurations such as skip-mounted programable Logic controllers (PLC) often found in the industrial sector and critical infrastructures.
IDS Intrusion Detection System IDS monitors any network traffic and logs any possi- ble malicious activity. Unlike a standard Firewall, IDS can differentiate between friendly and unfriendly activity.
IP Internet Protocol IP specifies the format of packets, also called datagrams, and the xv
addressing scheme. Each entity is assigned a unique 32-bit number, an IP address, which identifies a computer in an IP network. Most networks combine IP with a higher- level protocol called Transport Control Protocol (TCP), which establishes a virtual connection between a destination and a source.
ISO International Standards Organizations ISO is a worldwide federation of national standards bodies from some 140 countries, one from each country. It does not create standards but provide a means of verifying that a proposed standard has met certain requirements for due process, consensus, and other criteria by those developing the standard.
LAN Local Area Network LAN is a computer network that links personal computers and workstations within a limited geographic area, such as a building or several contiguous buildings. Linked by cables such as coaxial cables or twisted pair, the computers connected to the LAN can access resources on other computers and shared peripheral devices. If there is a central network device, it is a file server that includes resources of use to all. To keep two workstations from accessing the LAN at the same time, LANs employ a Medium Access Control (MAC) protocol;
ethernet is one such protocol.
MAP Manufacturing Automation Protocol MAP is used interchangeably when describ- ing three aspects of a General Motors effort to develop a multi-vendor Local Area Network for communication among intelligent devices in a factory environment.
Map is: 1. A multi-vendor task force addressing the problems of a plant floor computer communications; 2. The specification recommended by the task force;
3. An AES project team whose goal is to implement networks that adhere to the MAP specifications.
MMS Manufacturing Message Specification MMS is an application level protocol that provide ’peer to peer’ real-time communications over a TCP/IP network. It is an ISO 9506 standard. Control Networks uses the MMS protocol above the TCP/IP protocol in the transport/network layer, and Ethernet and/or RS-232C as phys- ical media. The protocol defines communication messages transferred between controllers as well as between the engineering station and the controller (e.g. down- loading an application or reading/writing variables).
NTP Network Time Protocol NTP is an Internet standard protocol running on top of TCP/IP.It assures accurate synchronization, to the millisecond, of computer clock times in a network of computers by querying NTP Servers.
OLE Object Linking and Embedding OLE is a distributed object system and protocol developed by Microsoft. Its primary use is for managing compound documents, but it is also used for transferring data between different applications using drag and drop and clipboard operations.
OPC OLE for Process Control OPC is an open connectivity standard for industrial automation and the enterprise systems that support industry standards. OPC
xvi
specifies the communication of real-time plant data between control devices from different manufacturers. It was designed to bridge Windows based applications and process control hardware and software applications.
OSI Open System Interconnection OSI is an ISO standard for worldwide communi- cations that defines a networking framework for implementing protocols in seven layers. Control is passed from one layer to the next, starting at the application layer in one station, proceeding to the bottom layer, over the channel to the next station and back up the hierarchy. Except for the OSI-compliant X.400 and X.500 e-mail and directory standards, what was once thought to become the universal communications standard now serves as the teaching model for all other protocols.
Most of the functionality in the OSI model exists in all communications systems, although two or three OSI layers may be incorporated into one.
PDU Protocol Data Unit PDU is a generic definition of a protocols basic communication unit.
PLC Programmable Logic Controller PLC is a highly reliable special-purpose computer used in industrial monitoring and control applications. PLCs typically have pro- prietary programming and networking protocols, and special-purpose digital and analog I/O ports.
RPC Remote Procedure Call RPC is designed for programs to make subroutine calls on other systems. It is ssentially a request-reply protocol, RPC usually makes heavy use of UDP datagrams, adding its own facilities for insuring data transfer.
RPC implementations generally do not yield TCP-quality performance, so its use is mostly limited to local area networks. Its most important application is the file sharing via the NFS protocol.
SCADA Supervisory Control and Data Acquisition SCADA systems are used in in- dustrial and civil engineering applications to control distributed systems from a master location. It is used to provide real-time instructions to plant automation equipment such as programmable logic controllers (PLC). SCADA is a very broad umbrella that describes solutions across a large variety of industries, including but not limited to the following: Electric power generation, Oli installations, process plants and Manufacturing systems.
SNMP Simple Network Management Protocol SNMP is an IETF protocol used for network management and the monitoring of network devices and their functions.
Even though SNMP is one of the TCP/IP protocols, it is not restricted to use in TCP/IP networks. SNMP uses ASN.1 for encoding of messages. The managed objects supported by a given device are encoded in its MIB (Management Infor- mation Base) or schema description. SNMP entities include managers and agents (both proxy and non-proxy), and a simple messaging protocol is used between these entities. Operations from the manager side include set (modify) and get (retrieve), and agents can respond these with reference to a security framework. Agents can
xvii
also issue notifications or traps to manager in order to indicate important events SSL Secure Sockets Layer SSL is used by most commercial servers on the World Wide
Web today. This high-level security protocol protects the confidentiality and se- curity of data while it is being transmitted through the internet. Based on RSA Data Security’s public-key cryptography, SSL is an open protocol that has been submitted to several industry groups as the industry security standard. SSL is denoted by the letters HTTPS in the URL.
TCP Transport Control Protocol TCP is one of the main protocols in TCP/IP net- works. Whereas the IP protocol deals only with packets, TCP enables two hosts to establish a connection and exchange streams of data. TCP guarantees delivery of data and also guarantees that packets will be delivered in the same order in which they were sent.
TLS Transport Layer Security TLS is a layer providing encryption and authentication services that can be negotiated during the startup phase of many Internet protocols (eg SMTP, LDAP, IMAP, POP3). TLS is derived from SSL and uses the same certificates but does not require each service to be given a new port number.
TPKT Transport packet Transport packet (TPKT) is a packet format decribed in RFC 1006. It is used to emulate International Standards Organizations (ISO) connection oriented transport protocol service as described in the Open System Interconnec- tion (OSI) modell on top of Transport Control Protocol (TCP).
UDP User Datagram Protocol UDP is defined in RFC 768. UDP offers a limited amount of service on top of IP and provides a procedure for application programs to send messages to other programs with a minimum of protocol mechanism. The protocol is transaction oriented, and delivery and duplicate protection are not guaranteed. UDP provides two services not provided by the IP layer. It provides port numbers to help distinguish different user requests and, optionally, a checksum capability to verify that the data arrived intact.
VMD Virtual Manufacturing Device VMD is a software model of the functionality of a real deviee. The model maps directly onto the real device. It is a part of the Manufacturing Message Specification (MMS).
VPN Virtual Private Network VPN (VPN) is a service to communicate through a dedicated server securely to a corporate network over the internet. VPNs are useful when a field operative needs to securely connect to a corporate server but only has general access to the internet. VPNs are defined by a network of secure links over a public IP infrastructure. These includes technologies such as Point-to- Point Tunnelling Protocol, Layer 2 tunnelling protocol and IP Security.
xviii
Chapter 1
Introduction
Supervisory Control and Data Acquisition (SCADA) or Distributed Control System (DCS), particularly those used in critical control systems in the petroleum and power industry, have traditionally been designed to address the issues of performance, depend- ability, flexibility and safety, with little regard to security. These industries are known to focus on health, environment and safety procedures, but similar practices informa- tion security seem to be have been neglected or ignored. The use of tools like Telnet, which are discontinued and considered insecure in the information technology world are still used in industrial networks. Ignoring security issues might have an acceptable risk when each network was a sealed system running proprietary protocols, but lately these systems are mirroring the changes in the IT world. They are converging on an Internet Protocol (IP) platform and as a result their DCS networks are directly connected to their company’s corporate network.
By using common networking technologies these systems now play an important part in Integrated Operations in the oil and gas industry. The drawback of allowing these systems to connect to corporate networks, is that they become exposed to the threats of the Internet.
There are several documented cases of intentional attacks against these systems. In march 1998, a teenager in Worchester, Massachusetts disabled part of the public switch- ing network using a dial up modem connected to the system. This knocked out the phone services at the control tower on the local airport as well as their main radio transmitter and the system that monitors flight progress [CNN98]. Another incident occurred in au- gust 2003 when the Microsoft SQL server worm, Slammer, infected a private computer network at the idled Davis-Besse nuclear power plant in Oak Harbor, Ohio, disabling a safety monitoring system for nearly five hours. The worm caused a failure in the plant’s process control computer. It also affected communications on the control networks of at least five other utilities by propagating so quickly that control system traffic was blocked [Hig03] [sec03]. These examples demonstrate the importance of integrating information security in these systems that control critical infrastructure in today’s society.
1
2 CHAPTER 1. INTRODUCTION On the demarcation line where Information Technology (IT) meets automation systems two different paradigms collide. The automation world must integrate the concept of information security throughout the entire DCS life-cycle including design, installation, operation maintenance and retirement. Here lies the challenge of making the two worlds cooperate.
1.1 Problem Description and Limitation
In this thesis we will study the security of industrial networks. We will focus on how the industrial protocols are implemented and the security level they offer vs. what is needed.
We will examine a selection of protocols and devices at ABB Communication’s lab in Billingstad (Oslo) where we will use tools analyze the security of these devices. We will in this thesis not focus on firewalls and other technologies used to secure networks, but we will mention these technologies where we find it natural. Instead, we will focus on device security in industrial devices such as switches, controllers and also look at security in industrial protocols. We do not focus on identifying the characteristics of an attacker as we feel this is outside the scope of this thesis.
1.2 Research Methodology
The title of this thesis isSecurity in industrial networks, and in an attempt to formalize our work, we feel that we must include a brief discussion of research methodology. We feel that the scientific methodology of classical research, where we define a hypothesis and then conduct tests to support our hypothesis, does not apply to our technological specialization field. According to Merriam-Webster’s thesaurus [Mer07] research is “a systematic search for the truth or facts about something”. Therefore we turn to [41] to define our work. There they define technology research as “scientific technology involving the production of new or improved devices especially in the fields of electronics and computers”. We feel that this is a much more adequate definition of our work. Glass [24] presents possible four models for use in scientific research:
1. The Scientific Method Observe the world, propose a model or theory of be- havior, measure and analyze, validate hypotheses of the model or theory and if possible repeat.
2. The Engineering MethodObserve existing solutions, propose better solutions, build or develop, measure and analyze, repeat until no further improvements are possible.
3. The Empirical MethodPropose a model, develop statistical or other methods, apply to case studies, measure and analyze, validate the model, repeat.
1.3. SCADA AND DCS 3 4. The Analytical Method Propose a formal theory or set of axioms, develop a
theory, derive results, and if possible compare with empirical observations.
In our work we will mainly follow the engineering method, but there may be elements from the other models involved in our work. We will preform a series of experiments on equipment provided by ABB CRC and analyze those results and propose improvements to the equipment and their intended use. We have not focused on finding quantifiable results in this thesis, but rather use qualitative means to assess the security of the protocols and equipment in question. We will also attempt to verify specific statements from other scientist’s work through a ”proof-of-concept” attack. These statements relate directly to the main subject addressed in this thesis and we feel therefor that such experiments fall directly under theThe Engineering Method.
1.3 SCADA and DCS
The abbreviations Supervisory Control and Data Acquisition (SCADA) and Distributed Control System (DCS) both describe and relate to the same type of industrial control system. The abbreviation SCADA is used in American journals and in the power pro- ducing industry. DCS is the equivalent European abbreviation and is used by the oil and gas industry and other process industries. As both terms describe the function of using industrial control systems to control a production process in an industrial plant through IT and automation techniques, and the only thing separating these functions are geographical and inter-industrial naming issues we have chosen to include this section where we clarify the use of these terms throughout the rest of this thesis.
To avoid any potential misunderstandings, we have been advised by our supervisors to use the term DCS for both Supervisory Control and Data Acquisition (SCADA) and Distributed Control System (DCS) systems, as this is the most common term used by the intended readers of this thesis. Therefor, in this thesis we will use the abbreviation DCS even though most scientific papers we use as references use the term SCADA. The only exception from this rule is when the term SCADA is present in the title of a paper or when we are quoting directly from another written source. We will always revert to the term Distributed Control System (DCS) after such a passage.
1.4 Outline of the Thesis
In this section we present the outline of this thesis and some remarks regarding textual conventions and formatting used in this thesis. The remaining part of this thesis are organized as follows:
In chapter two we give an introduction of important terms and background information on the Manufacturing Message Specification (MMS) discussed in this thesis. Chapter two
4 CHAPTER 1. INTRODUCTION also present relevant related work. Chapter three discusses ”state of the art” technologies related to DCS network, mainly focusing on security issues. In chapter four we preform a complete analysis of the implemented MMS stack and intercepted MMS communication.
We also show how the implemented MMS stack differ from the original Manufacturing Message Specification (MMS) defined by International Standards Organizations (ISO).
In chapter five we discuss test methodology used in our tests and provide a short descrip- tion of the tools utilized in testing industrial switches and controllers for vulnerabilities.
In chapter six we present the industrial devices we are testing. Chapter seven presents the test results for each device, followed by a discussion of the detected vulnerabilities and suggested mitigation paths. In chapter eight we perform a ”proof-of-concept” packet crafting attack on the MMS by attacking one industrial controller. In chapter nine we discuss the consequences of our findings from a network point of view and give a short evaluation of the tools used in this thesis and how well they adapt to testing industrial devices. Chapter ten presents further work, identifying areas we feel should be examined further. In chapter eleven we present our concluding remarks.
All Abstract Syntax Notation One (ASN.1) keywords in this thesis are italicized and printed in capital letters for easy identification. Excerpts from ASN.1 module definitions will be printed in the text for easy reference, but we have chosen to omit the whole module definitions from the text as they tend to be very large. We have included these ASN.1 module definitions in the appendices. ASN.1 object names are italicized and by ASN.1 convention written as a mixed case with a lowercase first letter and capital first letters for internal words, e.g, authentificationFailure.
All reports generated form security scanners and other relevant tools are included in the appendices. We have removed all service fingerprints for unknown services from Nmap report to save space and improve the overall readability of these reports.
All numbers in this thesis, except decimal numbers will have their base indicated in front of them, we use 0b for binary numbers and 0x for hexadecimal numbers. The exception from this is printouts and analysis of Protocol Data Unit (PDU) which always are encoded as hexadecimal octets.
We have distinguished printed references from their web-based counterparts to clarify the origin of the references used in this thesis. The printed references are cited us- ing numerical values (e.g. [1]), while web resources are cited using citation style (e.g.
[CNN03]). All web references have been verified and are available as of today (July 17, 2007). Additionally, we emphasize that the usage of first person plural (i.e we), is only due to common convention and is therefore to be interpreted asthe author. This thesis is written in LaTeX.
Chapter 2
Background
In this chapter we will present some important background information on security and protocols used in industrial networks.
2.1 Definitions
Before we can look into the security of industrial networks, it is important to have a com- mon understanding of the underlying concepts, protocols and technical terms describing such networks. We will not dwell on details of these definition, but we will clarify the meaning of these terms and how they are used in this thesis.
2.1.1 Security
We observe that the term “security” sometimes is used in the semantic context of “safety”
in the automation world. Security and safety are not two disjoint sets as a malicious attack by an adversary on the DCS network, may cause a safety incident. Not all security incidents relate to safety and there are many safety incidents that have nothing to do with security, so the sets intersect only partially. A Denial-Of-Service (DOS) attack on a plants network, resulting in a controlled shutdown of the plant is a serious security incident and it may cost millions to restore production to normal, but unless the DOS attack had consequences for the environment or user(s), it is not a safety incident. We therefore stress at in this thesis the term security will always refer to information security, and safety will be used for mechanisms that prevent undesirable consequences for the environment or user(s).
There exist numerous definitions of security, all varying slightly in wording. To define security we will use the definition given by Shirey in RFC 2828 [40]:
1. Measures taken to protect a system.
5
6 CHAPTER 2. BACKGROUND 2. The condition of a system that results from the establishment and maintenance of
measures to protect the system.
3. The condition of a system’s resources being free from unauthorized access and from unauthorized or accidental change, destruction, or loss.
We also include the definition from Laprie[8], who defines security as the “composite of the attributes of confidentiality, integrity, and availability”. We will use the definition of Laprie as it is shorter and more to the point, but have included the more wordy definition from [40] to stress the difference from “safety”.
2.2 Dependability
The dependability of a system is defined by Helvik in [27] as the trustworthiness of a system such that reliance can justifiably be placed on the service it delivers. Laprie has a different definition in [8], which we find more suitable in this thesis. He defines dependability as the ability of a system to avoid service failures that are more frequent or more severe than is acceptable. Dependable systems often rely on redundancy and diversification to achieve high levels of system availability and reliability. We wish to use Laprie’s Taxonomy of dependability to formalize the concepts later used in this project. As we can see in figure 2.1, Laprie classifies the concepts of dependability in three attribute classes.
Figure 2.1: Laprie‘s Taxonomy of dependability [29]
The possible “down conditions” that can effect a system’s dependability are classified under impairments in figure 2.1.
2.3. SURVIVABILITY 7 The means to achieve a dependable computing system include a set of methods that can be classified into four categories [29]:
• Fault-avoidance: means to prevent the occurrence or introduction of faults.
• Fault-tolerance: means to avoid service failures in the presence of faults.
• Error-removal: means to reduce the number and severity of faults.
• Error-forecasting: means to estimate the present number, the future incidence and the likely consequences of faults.
To survey a system’s dependability one uses the measures of reliability and availability.
2.3 Survivability
Survivability has to be defined in the correct context. The old term of survivability was a measure of how many nodes the enemy had to destroy before bringing the network down. We define all actions that are potentially damaging to the system as threats.
A successful attack termed an incident. We use the term survivability, as described in [19] by Ellison et al., to describe the systems ability to resist or tolerate incidents.
Ellison et al. defines survivability as the capability of a system to fulfill its mission, in a timely manner, in the presence of attacks, failures, or accidents. An attack is a potentially damaging event orchestrated by an intelligent adversary whereas failures are incidents caused by deficiencies inside the system and accidents are incidents with a random external cause.
We observe that Ellison et al. [19] focus on the impact of the incident rather the the cause, because of the difficulty in separating an attack from a random system failure.
Laprie et al. concludes that the concepts of dependability and survivability are essentially equivalent [29]. Ellison et al. argues that survivability describes a slightly different concept than survivability [19]. They differ on the point of how they define a system. In classical survivability thinking, the system is either capable of fulfill its mission (up) or in a failed state (down). There are no intermediary states where the system is degraded or partially working as we find in dependability thinking. Ellison et al also states that survivability focus on man-made faults caused by malicious attacks, while dependability mainly focus on the statistical probability of one or more accidental faults. We tend to agree with Ellison et al. and will in this thesis use survivability in the context the ability to resist malicious activity and attacks.
8 CHAPTER 2. BACKGROUND
2.4 Means of Network Protection
We will in this section provide a brief introduction to the tools used to protect a network and its hosts from malicious network traffic.
2.4.1 IDS
To date, it seems unlikely that we ever will be able to completely prevent security breaches. Therefore we must try to detect these intrusions as they occur and take action to prevent the attackers from doing further damage. There are many ways of detecting and classifying attacks. Due to the enormous amount and diversity of attacks this is clearly a task for a computer. The standard way of detecting attacks today is by using an IDS. There are two types of IDS systems; Host based and network based IDS systems.
The network based IDS monitor network traffic to determine if an intrusion has occurred.
It can use two basic methods of detection, signature- and anomaly-based detection [16].
All network traffic is scanned by the IDS looking for specific features or patterns that might indicate an attack or intrusion. Signature based methods, also known as misuse detection [15], looks for a specific signature to match, which would signal an intrusion.
A misuseIDS uses a database of traffic and activity patterns related to known attacks to identify and categorize malicious activity on the network. This is somewhat similar to virus detection since it can only can detect known patterns and thus leave the system open for “zero day exploits”. The default setup of Snort [Sno07] uses signature-based detection.
Another approach to intrusion detection is called anomaly detection. Anomaly-based systems attempt to map events to the point where they “learn” what is normal and then detect behavior that diverge from this norm. Anomaly detection techniques assume that all intrusive activities are necessarily anomalous. The greatest challenge in such systems is to select thresholds levels that avoid false positives. DeLooze proposes to use Self- organizing maps and unsupervised learning techniques to categorize attacks. Her results shows that she generated a very low amount of false positives using this technique with a overall detection rate of 97.31 % [15].
A host based IDS use a more general strategy, it detects unwanted changes in the system state. The idea is that intruders, in order to perform some action on the system, will change the system state by leaving traces of their actions. By monitoring key parameters such as binary signatures and size of files that should not change a program can detect intrusions through changes in data integrity. The program generates a database with signatures of important files using some hash-function and detect discrepancy between the actual file and the database signature. In most cases this requires the database to be located on a physically different location. One such host based IDS is SAMHAIN [SAM07].
2.4. MEANS OF NETWORK PROTECTION 9 2.4.2 Firewalls
When designing a network the Firewall often represent the first line of defense in any network. A firewall control and monitor the flow of network traffic between internal network employing different security measures and the Internet It compares the traffic passing through it to a set of predefined security criteria/rules, discarding messages that do not match the security criteria’s requirements. Normally several layers of firewalls are deployed to restrict network traffic between network segments with different security postures. We normally distinguish between host-based and network based firewalls.
Network based firewalls are often standalone hardware devices or a hardware/software combination with an OS-based firewall such as IPTables.
Host-based firewalls reside at an endpoint, at one (specific IP address on a host). Host- based firewall will often have less strict rule setts as their primary objective is to provide a service to other hosts such as database access or printing service. Host based firewall solutions are to our knowledge only available for computers, not embedded devices such as controllers and other process equipment. Therefor the firewall technology, can only act as a perimeter defense against network threats, as the embedded devices do not have the processing power or memory to preforms such tasks.
Based on [26] we have chosen to classify packet filtering firewalls into three classes. We will provide a brief description of these classes:
• Header inspection Firewalls: The most basic type of firewall is often referred to as a Header inspection firewalls. Header inspection firewalls are essentially routing devices containing an access control functionality for combinations of IP addresses and port numbers. The access control functionality is defined in a set of actions referred to as a rule set Header inspection firewalls limit their inspection to layer 3 and 4 of the Open System Interconnection (OSI) model. The firewall will match fields and flags in the IP and Transport Control Protocol (TCP) header, such as IP source and TCP SYN flags, against the firewall rule set and, depending on the rule set, drop or forward the packet or in some cases send a message back to the packet source [26].
• Stateful Inspection Firewall: While simple firewalls make filtering decisions based on each packet, stateful inspection firewalls are packets filters that incor- porate added awareness of data streams. Stateful inspection keeps track of active sessions and uses that information to determine if packets should be forwarded or blocked. This allows the firewall to keep state tables that link the individual packet to a connections and make more intelligent decisions based on this information.
This allows the firewall to deal with fragmented IP packages and User Datagram Protocol (UDP) streams. Early stateful inspection firewalls used a static rule set, but now modern firewalls may change the rule set based on input to the filter. This is known asdynamic packet filtering [26].
10 CHAPTER 2. BACKGROUND
• Application and Proxy-Gateway Firewalls: Even though there are some dif- ferences between an application-gateway and a proxy-gateway firewall we have chosen to describe both under the same heading as they both operate on the same layer. An application gateway firewall examines packets at the application PDU layer and filters traffic based on specific application rules, such as allowing spec- ified applications (e.g., browsers) or denying certain protocols (e.g., File Transfer Protocol (FTP)). An application gateway might also buffer several lower layer PDUs to examine a whole application layer PDU and match it against known virus signatures [26]. It performs per packet inspection on data streams passing through the firewall, but does not alter a legal connection. The proxy gateway re- move the possibility of a host directly interacting with the Internet, instead a host must connect to the proxy gateway and it will initiate a connection to the requested host [26]. The proxy gateway acts as a relay for requests maybe by the internal network to the outside world. This is also the strategy used in De-Militarized Zone (DMZ).
2.4.3 Anti-Virus
Anti-virus software are computer programs that attempt to identify, quarantine or elim- inate computer viruses and other malicious software. To detect a virus the anti-virus software may use different techniques. It may use a signature database and match known viral code patterns to identify viruses, either in real-time or on scheduled scans. Virus authors try to thwart the use of signature databases by writing oligomorphic, polymor- phic or metamorphic viruses. These viruses permutate or encrypt parts of their code to disguise themselves as legitimate files. To detect such viruses other approaches are used.
One approach is to monitor the system for suspicious behavior. This type of software aims at detecting e.g., write operations to an executable file. Using a heuristic analysis or a sandbox system is yet another way of detecting a virus. The sandbox emulates primary function of a operating system and simulate the execution of any program prior to the actual execution. After the simulation has terminated, the anti-virus software analyzes the sandbox for any changes that might indicate a virus.
As the malware issue is a vast field of research on its own and not limited to DCS systems we will not discuss this topic further in this thesis.
2.5 Concepts and Architecture of DCS Systems
To explain on an abstract level what a DCS network does we use figure 2.2. At the core we find the controlled process, it takes an input and produces an output. The process it self can be a number of industrial processes occurring at any plant nearby, e.g., producing hydro electricity or pumping and refining natural gas from the seabed. To monitor this process the DCS network collects data from sensors through controllers. This might be
2.5. CONCEPTS AND ARCHITECTURE OF DCS SYSTEMS 11 pressure from a valve or the amount of oxygen left inside a sealed gas tank. These values are reported back to human operators at the Human-Machine Interface (HMI)1. Based on these reports human operators or computerized processes give input to the process through the controller. The input may be to control parameters for some device used in the process e.g., valves, pumps or motor drives. In addition to the entities depicted in figure 2.2 there are remote diagnostics and maintenance utilities connected to all devices, to prevent, identify and recover from failures.
Figure 2.2: An abstract view of an automation network process [45]
As the automation industry is converging on an IP platform, more and more embedded devices contain an ethernet interface and use IP based industrial protocols to communi- cate. This poses new risks to DCS networks as many of the industrial protocols are not designed to cope with information security issues. The introduction of integrated opera- tions in the oil and gas industry has provided many benefits such as reduced costs, longer life for petroleum fields, reduced environmental loads, and improved safety measures and recovery rates. But it has also changed the information flow between DCS, corporate and subcontractor’s networks. The information inside the DCS is accessed to support various analysis ranging from statistical process control to enterprise level planning as
1The HMI is software and hardware that allow human operators to monitor the state of the process, modify control settings and manually override automatic control operations. The location, interface and platform may vary a great deal. For example a an HMI could be an application running on an MS Windows XP host, a dedicated platform or a browser on any system connected to the Internet.
12 CHAPTER 2. BACKGROUND
Figure 2.3: An example of a Distributed Control System implementation [45].
2.6. INDUSTRIAL NETWORK PROTOCOL 13 a part of the integrated operations paradigm. As a result the data historian inside the DCS is often queried for information from the corporate network. A data historian is a centralized database for logging all process information within a DCS. To provide an example of a DCS network we have included figure 2.3 from [45].
2.6 Industrial Network Protocol
In this section we will introduce the Manufacturing Message Specification (MMS), a pro- tocol used in industrial networks. We will focus on the basic architecture and functions of this protocol and wish to provide the reader with relevant background information needed in the rest of this thesis.
2.6.1 The MMS
MMS is declared an international standard, named ISO 9506, and is currently developed and maintained by the ISO Technical Committee 184 (TC184). As the ISO standards format tends to be overwhelming, we will give a overview of the specification here, but for a more detailed description we refer to the standard [7] and a collection of white-papers from SISCO [48] [21] [20].
MMS is an application layer protocol which specifies services for exchange of real-time data and supervisory control information between networked devices and/or computer applications. It is designed to provide a generic messaging system for communication between heterogeneous industrial devices. The specification only describes the network visible aspects of communication. By choosing this strategy, the MMS does not spec- ify the internal workings of an entity, only the communication between a client and a server, allowing vendors full flexibility in their implementation. In order to provide this independence, the MMS defines a complete communication mechanism between entities, composed of:
1. Objects: A set of standard objects which must exist in every conformant device, on which operations can be executed (examples: read and write local variables, signal events).
2. Messages: A set of standard messages exchanged between a client and a server station for the purpose of controlling these objects
3. Encoding Rules: A set of encoding rules for these messages (how values and parameters are mapped to bits and bytes when transmitted)
4. Protocol: A set of protocols (rules for exchanging messages between devices).
[21]
14 CHAPTER 2. BACKGROUND MMS composes a model from the definition ofobjects,services andbehavior named the Virtual Manufacturing Device (VMD) Model. The VMD model uses an object oriented approach to represent different physical industrial (real) devices in a generic manner.
Some of these objects are variables, variable type definitions, programs, events, historical logs (called journals) and semaphores. Along with the definition of these objects, MMS defines a set of communications services that an application can use to manipulate these objects.
We observe that in the literature the terms services, service primitives and messages are all used to describe the functions that manipulate objects or their attributes. We will therefore in this thesis use the term service primitive as this is used in the ISO 9506 standard, unless we are citing directly from a written source, in which case the quote will be evident in the text. The standard also refers to physical industrial devices as “real devices” and we will continue to use this terminology to avoid confusion when referring to [7].
As MMS is based on an object oriented approach, we will give a brief introduction to the addressing and object hierarchy of MMS, before focusing on the network communication.
Architecture and Addressing
The MMS architecture is based on a common client-server model. Real devices used in industrial networks often contain an MMS server allowing the device to be monitored and managed from an MMS client. An MMS client is typically part of an Control Builder application, Human - Machine Interface (HMI) or an MMS to OLE for Process Control (OPC) gateway (MMS/OPC GW). The ABBControl Builder is an application used to program and monitor industrial controllers such as ABB’s AC 800 M. The AC 800 M controller will be further discussed in section 6.4. Both the control builder and the MMS/OPC GW uses service primitives provided in the MMS to manage devices containing MMS servers. This is depicted in figure 2.4.
As MMS does not specify how to address clients and servers, an entity containing an MMS client or server must rely on the addressing scheme of underlying protocols in the process of establishing an application association to support the MMS environment [7].
In practice, clients and servers are addressed by their IP address and the MMS server uses TCP port number 102. The addressing allows for an MMS context to be negotiated between two peer applications.
To address an MMS object variable, MMS provides several different address modes.
MMS allows an address to have different syntax, based on the implementer’s choice of what is most appropriate for that device. The specification separates between named andunnamed variables. The unnamed variables are identified by a fixed physical address in the VMD, expressed by either:
2.6. INDUSTRIAL NETWORK PROTOCOL 15
Figure 2.4: The VMD model depicting communication between an control builder with an MMS client and a device running an MMS server [48]
• Numeric: A numeric address is represented by an unsigned integer number (e.g., Unsigned32 173).
• Symbolic: A symbolic address is represented by a character string (e.g., Visi- bleString ”C076”).
• Unconstrained: An unconstrained address is represented by a untyped string of bytes (e.g., An OCTET STRING ”0x57AB”).
[48]
Named variables are identified by an object name (e.g., a string of characters), which is VMD specific, domain specific or Association-specific. An MMS server may declare an MMS object variable that does have a specific address, but choose not to reveal this address to MMS clients. If this is the case the object variable shall be defined locally and with a specific access method other than public [7]. Access control in MMS is enforced through the use of access control list objects containing access methods for objects and appurtenant object variables. The concept ofaccess control listswill be further discussed in section 4.3. Once an MMS communication context is established between a client and a server, the standard specifies details for the MMS objects, variables, object hierarchy and service primitives.
16 CHAPTER 2. BACKGROUND MMS Objects, Services Primitives and Access Control
Associated with each object is a set of variables that describe values in a given instance of the object. For each object there are corresponding MMS service primitives that allow client applications to access and manipulate those objects. The top level object in the MMS is the VMD which has at least one network-visible address [7].
Each real device is represented by a real object with vendor specific features associated with them. The VMD model maps the real object and devices onto virtual objects and devices, described in a generic manner which is in conformance to the VMD model.
In other words a real variable is an element of typed data that is contained within a VMD object. An MMS variable is part of a virtual object that represents a mechanism for the MMS client to access the real variable. The MMS server containing the virtual MMS object can be understood as a communication driver which hides the specifics of a real device from the client. From the client’s point of view the virtual MMS variable represents a pointer or an access method to the real variable and it is only the MMS server with its objects and its behavior that is visible to the client. The MMS client can never interact with real device variables directly.
All MMS objects contain an access method variable. This attribute contains the infor- mation which a device needs to identify the real variable as described above. It contains values which are necessary to find the memory location of the real variable with the contents that lie outside MMS. A special method, the methodPUBLIC, is standardized for accessing the real variables.
In table A.1 we present the name of MMS objects together with a short description.
This table can be found in appendix A.1.
For each object there are corresponding MMS service primitives that allow client appli- cations to access and manipulate those objects. The MMS defines the service primitives of both clients and servers, but the VMD focuses only on specifying the network visible behavior of MMS servers. And thus, each vendor of an MMS server device is responsible for hiding vendor specific details of the real objects and devices by providing anexecutive function which maps the real entities up to the virtual level, which shall comply with the VMD model definitions. To ensure vendor implementation compliance with the VMD model, it specifies how MMS devices containing a MMS server shall provide a consistent and well defined view of the object contained in the VMD. And thus, MMS provides a common interface for communication with different devices through the generic virtual objects.
All MMS objects listed in table A.1, except the Operator Station object inherit six abstract services from the VMD object. These are depicted and described in table 2.1.
E.g. service primitivesread and RequestDomainUpload for the objects Named Variable List and Domain respectively inherit from the abstract service primitive get.
2.6. INDUSTRIAL NETWORK PROTOCOL 17
MMS General methods Description
Get This method is used to obtain the value of a specified object.
Set This method is used to write/put value or contents into a specified object.
Query Attributes This method is used to obtain structure or capability information of a specified object.
Create This method allows objects of particular classes to be instanti- ated.
Rename This method allows instantiated objects to be renamed.
Delete This method allows instantiated objects to be destroyed.
Table 2.1: The basic methods (services) inherited from the VMD object [21].
MMS uses access control lists to provide explicit control of the ability to access or alter MMS objects. Protection requirements for an MMS variable are inherited from the underlying real variable in the real device. These requirements are established by the access method in the MMS object. ISO 9506 [7] states that each object within an MMS implementation must contain a reference to an Access Control List object that specifies the conditions under which services directed at the named object may succeed. For the purposes of specifying the control conditions, services are grouped into six classes as described in table 2.1. Access control is enforced through special mechanisms provided by MMS. These mechanisms include possession of a semaphore, identity of user (Application Reference), and the submission of a password (which may be arbitrarily complex) [7].
Network Services
As we have stated earlier MMS is not by itself a communication protocol, as it only defines messages that have to be transported by an unspecified network. MMS was originally developed as a part of the Manufacturing Automation Protocol (MAP) speci- fication and is therefore specified on all seven OSI layers as depicted in figure 2.6. MAP was originally created by General Motors as an internal standard for communications in industrial automation networks. It is now a public, multivendor communications stan- dard for industrial automation equipment. For more information about MAP we refer to [22]. MMS supports the use of both confirmed and unconfirmed services, but we will in this thesis focus on the confirmed services as it seems like all the equipment we will be studying run this service type. The MMS defines the following PDUs for a confirmed service exchange [7]:
1. Confirmed-RequestPDU 2. Confirmed-ResponsePDU
18 CHAPTER 2. BACKGROUND 3. Confirmed-ErrorPDU
4. Cancel-RequestPDU 5. Cancel-ResponsePDU 6. Cancel-ErrorPDU 7. RejectPDU
These messages will be used in the communication between a client and a server when a client wishes to invoke a service primitive. A normal MMS request between client and server follows the pattern depicted in figure 2.5 using the enumerated list above.
Figure 2.5: A Confirmed Service state machine as seen by the MMS server (Service Responder) using the PDUs numbered in the list above [7]. The RejectPDU is not included in this figure.
Before a service primitive is called through aConfirmed-RequestPDU, the server is in a Responder Idle state as seen figure 2.5. Upon receipt of a Confirmed-RequestPDU for any of the confirmed services, the MMS-provider issues an indication primitive specifying the particular service being requested and aninvoke ID that specifies the service instance and enters the stateService Pending. Upon receipt of a response service primitive con- taining a result parameter specifying the service previously indicated and aninvoke ID that specifies the service instance, the MMS-provider sends aConfirmed-ResponsePDU which specifies the service type and the invoke ID from the response primitive. Then a state transition into the Responder Idle state occurs. Upon receipt of a response service primitive containing a Result parameter specifying the service previously indi- cated and an invoke ID that specifies the service instance, the MMS-provider sends a Confirmed-ErrorPDU specifying the service type and theinvoke ID from the response primitive. A state transition into the Responder Idle state then occurs. Upon receipt