On Security in Safety-Critical Process Control

(1)

Mälardalen University Press Licentiate Theses No. 110

ON SECURITY IN SAFETY-CRITICAL PROCESS CONTROL

Johan Åkerberg

2009

(2)

ISBN 978-91-86135-42-3

Printed by Mälardalen University, Västerås, Sweden

(3)

Abstract

This Licentiate thesis is about security in automation networks with empha-sis on ﬁeldbus communication. In the process industry, network and system security have become even more important since the introduction of Ethernet-based ﬁeldbus protocols. As an example, a successful attack on a power plant, supporting large cities with energy, could result in a temporal but total power loss. Such attacks could be devastating for the society. The security threats are real, and motivations for attacking industrial communication systems may be political or economical.

The visions of autonomous systems, which can be supervised, diagnosed and maintained from remote is not far from reality, but stress the need for security and safety measures. Wired ﬁeldbus protocols are mature when it comes to safety and there are existing standards for safe communication. In a setup like an autonomous system security measures over safe communication has to be taken into account.

The state-of-the-art in automation security is to use firewalls to restrict incoming and outgoing traffic to the networks. Firewalls can be deployed between different automation networks, i.e. server, control, and fieldbus net-works, and even protect a single automation cell with a dedicated firewall. If an adversary can penetrate the perimeter defenses, no other security countermea-sures exist in process automation to protect the safety-critical communication from sabotage.

In this thesis we initially explore the possibilities of security attacks on the automation protocols PROFINET IO and PROFIsafe. We show that it is pos-sible to attack safety-related communication to take control of safety-critical ﬁeldbus nodes. We propose the concept of Security Modules in combination with PROFINET IO and PROFIsafe to achieve safe and secure real-time ﬁeld-bus communication.

(4)

(5)

Sammanfattning

Denna Licentiatavhandling handlar om informationssäkerhet i automationsnät-verk med fokus p˚a fältbusskommunikation. Inom processindustrin har behovet av informations- och systemsäkerhet ökat markant sedan Ethernet-baserade fältbussprotokoll började användas i automationsutrustningar. En lyckad at-tack mot till exempel ett kraftverk som genererar elektricitet till stora städer skulle kunna resultera i ett temporärt strömavbrott. S˚adana attacker skulle kunna vara förödande för samhället. Hotbilden existerar och motiven kan vara s˚aväl ekonomiska som politiska.

Visioner om autonoma system som kan övervakas, diagnostiseras och un-derh˚allas fr˚an avlägsna platser kan snart realiseras, men detta kräver tillförlitli-ga lösnintillförlitli-gar för informations- och personsäkerhet. Tr˚adbundna fältbussproto-koll är utvecklade med hänseende p˚a personsäkerhet och det finns standarder för säkerhetskritisk kommunikation. Dessa används för att minimera risken för skada p˚a person, egendom och miljö. När exempelvis autonoma system ska fjärrövervakas krävs det ytterligare ˚atgärder för att garantera informationssä-kerhet, speciellt om det är säkerhetskritisk kommunikation.

Brandväggar används för att begränsa inkommande och utg˚aende trafik mellan automationsutrustning och Internet. Brandväggar kan appliceras mellan olika automationsnätverk, t.ex. mellan server-, controller- och fältbussnätverk. Till och med en enskild automationscell kan skyddas med en egen brandvägg. Om skalskyddet kan kringg˚as in till processautomationsnätverken, finns det inga andra medel för att skydda automationsutrustningarna mot sabotage.

I den här avhandlingen utforskar vi möjligheterna till attacker mot automa-tionsprotokollen PROFINET IO och PROFIsafe. Vi visar att det är möjligt att attackera säkerhetskritisk kommunikation för att ta kontroll över säkerhetskri-tiska fältbussnoder. Vi föresl˚ar konceptet med Säkerhetsmoduler tillsammans

med PROFINET IO och PROFIsafe för att ˚astadkomma säker realtidskommu-nikation med avseende p˚a informations- och personsäkerhet.

(6)

(7)

(8)

(9)

Preface

I have many people to thank for making my industrial PhD studies and this licentiate thesis possible. It has been an intensive, educating, challenging, and stimulating journey since the summer of 2008 when it all began. First of all I would like to thank my supervisors Mats Bj¨orkman (MDH), Maria Lind´en (MDH), and Kai Hansen (ABB Corporate Research) for all inspiration, en-couragement and valuable discussions and advices.

I also have to thank Peter Löfgren, Dagfin Brodtkorb, Mirka Mikes-Lind-bäck, Tomas Edström, and Helena Malmqvist from ABB Corporate Research for believing in me, and made it possible for me to start as an industrial PhD student. The work in this thesis has in part been financed by Industriforskarsko-lan RAP.

Furthermore I have to thank all of my colleges at ABB Corporate Research for all discussions, reviewing, encouragement, support, and all the laughs. I especially have to thank Tiberiu Seceleanu, Mikael Gidlund, Tomas Lennvall, Krister Landern¨as, Jimmy Kjellsson, Dacfey Dzung, Daniel Grandin, Frank Reichenbach, Jan Endresen, Erik Carlson, Ewa Hansen, Jonas Neander, and P˚al Orten.

I dedicate this licentiate thesis to my wife Anna and my daughters Tindra and Alva.

Johan ˚Akerberg V¨aster˚as, October 14, 2009

(10)

(11)

I

Thesis

(16)

(17)

Chapter 1

Introduction

Automation is a broad area, which is commonly broken down in

∙ Process Automation ∙ Substation Automation ∙ Factory Automation ∙ Building Automation ∙ Home Automation.

The requirements differ in real-time performance such as, allowed jitter, cost, availability, maintainability, and also in safety and security in the various au-tomation disciplines. The thesis is limited to the process auau-tomation domain, but work already done in other domains is evaluated if it is feasible to reuse or adapt for process automation.

The importance of network- and system security are increasing in the cess industry since the introduction of Ethernet-based ﬁeldbus protocols in pro-cess automation. As an example, a sucpro-cessful attack to a power plant, support-ing large cities with energy, could result in a temporal but total power loss. Such attacks could be devastating for the society. The security threats are real, and motivations for attacking industrial communication systems may be polit-ical or econompolit-ical [1].

The operational requirements are different for automation and ofﬁce IT. In automation the most important requirement is the safety of person, equipment,

(18)

4 Chapter 1. Introduction

Figure 1.1: Example of an architecture from a closed automation system

and environment. Security violations might affect the safety of the plant and its personnel. Availability, that is, to be in safe operation over long periods of time is the second most important requirement. Office IT security require-ments focus on authorization, confidentiality, and integrity issues. If security vulnerabilities are identified, installation of software-patches and rebooting to address security problems is difficult if using IT system administration prac-tices in automation [2].

The measures against security attacks in the process automation standards are simply to keep the networks closed, i.e. no connections to the outside. If the control system must be connected to the outside, i.e. the Internet, a perimeter defense protects the entrance. Figure 1.1 illustrates a typical closed automation system. On the other hand, the visions of autonomous systems, which can be followed, diagnosed and maintained from remote is not far from reality, but stress the need for security and safety solutions. Wired ﬁeldbuses are mature when it comes to safety and there are existing standards for safe communica-tion, for example PROFIsafe [3]. In a setup like an autonomous system that is supervised, maintained and diagnosed from remote, security measures over safe communication has to be taken into account.

(19)

5

IEC 62280-1 [4] deals with safety-related communication in closed trans-mission systems. PROFIsafe is based on the Black Channel concept from IEC 62280-1, where the standard transmission system can be used for both safety-related and non safety-safety-related messages. The main benefit with the Black Channel concept is that the standard transmission system can be excluded from the functional safety certification. In the railway domain, especially in railway signaling, it is difficult, or economically infeasible, to have closed transmission systems. In railway signaling, where safety-relevant messages has to be trans-mitted on non-trusted networks, i.e. security attacks can not be neglected, IEC 62280-2 [5] applies. IEC 62280-2 recommend cryptographic techniques to be used, in addition to the safety layer, to ensure integrity, authorization and con-fidentiality. Following the recommendations of IEC 62280-2, safety-relevant data is allowed to be transmitted over non-trusted networks, i.e. open networks. The latest advancements in wireless networks, fieldbus systems and as-set management systems contribute to the efficiency of process systems [6]. Seamless horizontal and vertical integration of communication and information throughout the complete organizations are necessary to master the complexi-ties of production and business operations in process automation [6]. Using Ethernet-based protocols at the fieldbus level simplifies vertical integration as the real-time protocols can co-exist with non real-time automation protocols. Vertical integration and wireless communication has unfortunately a negative effect on security, and the risks of security attacks at fieldbus level are increas-ing as the level of integration increases.

In wireless networks, security is a very important topic and is addressed thoroughly in the standards, e.g. IEEE 802.11 [7], IEEE 802.15 [8], and Wire-lessHART [9], since there is no possibility to keep the networks closed. On the other hand, safety is sparsely addressed, if at all addressed in the stan-dards. Even if safe communication is not a hard requirement today, developing a certifiable safety solution would probably decrease the skepticism for wire-less communication in industry with reduced efforts compared to a certified solution. Another aspect is if you choose wireless equipment from different suppliers, one that has not addressed safety at all, the other has a safety imple-mentation but not formally certified, whom would you choose? This is not only limited to safety, it is equally important with an overall security mechanism.

There is a strong focus to replace or complement the various fieldbuses with field-networks in the industry to gain bandwidth, functionality and flexibility during plant lifetime. As an example PROFINET IO [10] is starting to replace PROFIBUS [10] as the Ethernet successor in the process industry. By using PROFINET IO as a backbone, different proxies can be used to interconnect

(20)

different ﬁeldbuses such as FF [10], HART [10], and PROFIBUS. Wireless communication is also possible at sensor level or even at network level, thus expanding the communication effectively into areas where wired communica-tion has challenges with respect to cost, mobility, or mechanical wear.

1.1 Research Problem

Today’s increase of Ethernet and wireless communication demands more at-tention in the area of safety and security. The problem is that,

1. in the safety certified fieldbuses, security is not fully handled today. For example the PROFIsafe standard states that there are no additional se-curity layers necessary. It tries to keep safety sub-networks as “closed systems” and protect network entries via “security boxes”. The research problem is: How do we develop secure fieldbus communication? 2. in wireless fieldbuses, e.g. WirelessHART and ISA100 [11], security

is well addressed and mature but safety is barely addressed at all. The research problem is: How do we develop safe wireless ﬁeldbus commu-nication?

The main focus of this thesis is on the security aspects of safe wired ﬁeld-bus communication based on Ethernet technology. The safety aspects of wire-less sensor networks and the integration of wirewire-less sensor networks and wired ﬁeldbuses are future work.

1.2 Research Approach

Ideally, to protect the return of investment on existing automation equipment, the security problem in process automation should be solved by retrofitting se-curity without any changes with respect to infrastructure, standards, and prod-ucts. Therefore the approach taken is not to develop new solutions from the beginning, but rather to improve existing solutions with respect to network se-curity. Compared to office IT, automation has different requirements with re-spect to security, i.e. integrity and authentication is more important compared to confidentiality. In process automation it is more important that for example a command to a machine is not tampered with, than the risk of exposing the content of the command to an adversary.

(21)

1.3 Thesis Contributions 7

The work is based on an experimental approach, where the possibilities of dangerous security vulnerabilities are evaluated, on existing automation equip-ment, using standardized fieldbus protocols such as PROFINET and PROFI-safe. The goal of this thesis is to propose solutions that can be retrofitted to existing products without changes in the standards, with respect to integrity, authentication, and optionally confidentiality. Proof-of-concept implementa-tions on existing automation equipment have been used to validate and evaluate the feasibility of the solutions.

1.3 Thesis Contributions

The main contributions of the thesis are:

1. It is shown that it is possible to take control of PROFINET IO nodes in shared and packet switched networks, and that attacks can be done without any of the peers detecting the attack

2. The concept of security modules, to retroﬁt security in PROFINET IO, is presented as a solution towards a security proﬁle

3. It is shown that the concept of security modules can be implemented in existing products to retroﬁt security in PROFINET IO without violating the standards

4. It is shown that the concept of security modules prevents man-in-the-middle attacks on PROFINET IO

5. It is shown that it is possible to take control over PROFIsafe nodes, and that attacks can be done without any of the peers detecting the attack 6. The concept of security modules can be used to retroﬁt security to

PRO-FIsafe when using PROFINET IO

1.4 Thesis Outline

The thesis is organized in two parts. In Part I the research problems are de-scribed. Moreover Part I gives an overview of the research areas and related work. Part II includes three peer-reviewed scientiﬁc papers presented and pub-lished at international conferences.

(22)

Chapter 2: This chapter introduces safety and security in general to give a basic understanding for readers not already familiar with the domains. The chapter also addresses the similarities and differences between safety and se-curity.

Chapter 3: In this chapter the background, motivation and state-of-the-art of automation networks are presented with respect to safety and security. Chapter 4: In this chapter the related work is presented.

Chapter 5: This chapter presents the included papers in this thesis and the main contributions.

Chapter 6: The last chapter presents the conclusions of the thesis and future work towards a PhD degree.

(23)

Chapter 2

Security and Safety

Safety is concerned with reducing risk of danger to health of person, equip-ment, and property with respect to accidental errors. Security mainly concerns conﬁdentiality, integrity, and authentication with respect to intentional misuse. Both safety and security are all about risk reduction, and are based on a risk assessment. The main difference, due to the fundamental differences, is that safety can in most of the cases be based on statistical observations, while in security the risk has to be based on losses in comparison to the efforts of de-ploying countermeasures. In the case of safety, requirements can be quantiﬁed with an error probability per hour, while security is a trade-off between the cost of potential damage and the cost of security countermeasures.

2.1 Security

Security is a broad topic, and most security problems are intentionally caused by malicious people trying to gain some beneﬁt, get attention, or to harm some-body. As stated by Table 2.1 from Tanenbaum [12], it is clear that security involves much more than keeping the software free from programming errors.

Security is a process trying to outsmart often intelligent, dedicated, and even well funded adversaries. Therefore, countermeasures that stop ordinary people, will have little impact on the serious ones. One have to keep in mind that deploying security countermeasures that could protect information relevant for national security, makes no sense in all applications [12]. A risk assessment, where the consequences are evaluated with respect to the threats, will be good

(24)

10 Chapter 2. Security and Safety

Adversary Goal

Student To have fun snooping on people’s e-mail Cracker To test out someone’s security system; steal data Sales rep To claim to represent all of Europe, not just Andorra Businessman To discover a competitor’s strategic marketing plan Ex-employee To get revenge for being ﬁred

Accountant To embezzle money from a company

Stockbroker To deny a promise made to a customer by e-mail Con man To steal credit card numbers for sale

Spy To learn an enemy’s military or industrial secrets Terrorist To steal germ warfare secrets

Table 2.1: Examples of people who cause security problems and why [12]

basis for selection and evaluation of security countermeasures [13, 14]. How-ever, security is an ongoing process, not a state you enter after the initial risk assessment.

A security risk exists if there is a vulnerability and a threat. A vulnerability can be caused by a badly designed protocol, an implementation mistake or us-ing weak passwords or cryptographic keys. A threat exist if an attacker exploits the vulnerability in order to gain information, make damage or sabotage [2].

2.1.1 Objectives

The security objectives are summarized in different forms and detail in both books and papers, [12, 15, 16], to mention some. The security objectives ex-plained below can be used as a framework for categorizing and comparing security mechanisms amongst systems [2]:

∙ Conﬁdentiality: The conﬁdentiality objective refers to preventing

disclo-sure of information to unauthorized persons or systems

∙ Integrity: The integrity objective refers to preventing undetected

modiﬁ-cation of information by unauthorized persons or systems

∙ Availability: Availability refers to ensuring that unauthorized persons or

systems can not deny access or use to authorized users

∙ Authentication: Authentication is concerned with the determination of

(25)

2.1 Security 11

∙ Authorization: The authorization objective is concerned with preventing

access to the system by persons or systems without permission

∙ Auditability: Auditability is concerned with being able to reconstruct the

complete history of the system behavior from historical records

∙ Nonrepudiability: The nonrepudiability objective refers to being able to

provide proof to a third party of who initiated a certain action in the system, even if the actor is not cooperating

∙ Third-party protection: The third-party protection objective refers to

ad-verting damage done to third parties via the system.

2.1.2 Types of Attacks

An intentional violation of a security objective is called an attack. Various kinds of attacks exist and can be categorized in two types: targeted and untar-geted attacks. The later tend to explore known vulnerabilities on any network or system, while the former intend to harm a speciﬁc system. Some common types of attacks are presented in Table 2.2.

2.1.3 Cryptography

Cryptography has a long history going back thousands of years and origins from the Greek words for “secret writing”. Historically, the military had the most important role over the centuries. The messages to be encrypted were traditionally given to poorly-paid code clerks for encryption, transmission and decryption. The volume of messages to be transmitted prevented this work from being done by a few specialists [12]. It is fundamental that the cryptoan-alyst know the algorithms in detail for encryption and decryption. The idea of using known algorithms and that the secrecy lies exclusively within the keys is called Kerckhoffs’ principle [17]. The main motivation for not keeping the algorithms of encryption and decryption a secret, is mainly due to the difﬁcul-ties to roll out new algorithms if the current one’s have been compromised, or suspected to be compromised. In contrast, trying to keep the algorithm secret, is called security by obscurity.

Modern cryptography uses the same basic ideas as traditional cryptogra-phy; transposition and substitution. As cryptography was a manual process in the beginning, it required simple and secret algorithms. Today, when cryptog-raphy can be automated, the algorithms tend to be as complex as possible and

(26)

Security Attack Goal

Denial-of-service The goal of the attacker is to decrease the avail-ability of the system

Eavesdropping The goal of the attacker is to violate the conﬁden-tiality of the communication

Man-in-the-middle The goal of the attacker is to violate the conﬁden-tiality and integrity of the communication Replay-attack The goal of the attacker is to violate

authentica-tion and authorizaauthentica-tion

Breaking into a system The goal of the attacker is to violate authentica-tion and authorizaauthentica-tion. In the next step conﬁden-tiality and integrity can be violated

Virus The goal of the virus is to execute malicious code, after violation of authentication and authorization Trojan The goal of a Trojan is to hide a virus in behind functionality that is desired by the user, to violate conﬁdentiality or authorization

Worm The goal of a worm is to automatically explore vulnerabilities in systems without involvement of any users. Worms might carry malicious code, to execute a distributed attack from infected systems and hosts

(27)

2.1 Security 13

public, to maximize the efforts to deduce the key out of several messages, and still remain efﬁcient [12].

Cryptography is central in security, both in system- and network security. The topic of this research is not to invent new cryptographic algorithms, but there are many possible pitfalls using cryptography. As an example, even if the best and strongest cryptographic algorithm is used in an authentication proto-col, it could be completely useless if the risks of a replay, or a man-in-the-middle attack, are not foreseen. Cryptography is based on a secret key, if the key is compromised, security is compromised, and overall security is not bet-ter than the weakest link. Furthermore, cryptography will not help in all cases. In case of for example a denial-of-service attack, other techniques have to be used.

Before introducing any algorithms and details, a notation and deﬁnitions are needed. A message to be encrypted is known as plaintext𝑃 , and is trans-formed by a function𝐸 that is parametrized by a key 𝐾. The result of the en-cryption process is called ciphertext𝐶. We will use the notation 𝐶 = 𝐸_𝐾(𝑃 ) from Tanenbaum [12] to represent the encryption of𝑃 , using 𝐾, giving 𝐶. In the same way,𝑃 = 𝐷_𝐾(𝐶) means the decryption 𝐷 of 𝐶, using 𝐾, to get 𝑃 again. From this it follows that

𝐷𝐾(𝐸𝐾(𝑃 )) = 𝑃

Many different cryptographic algorithms exist, and the rest of this section will cover some of the most commonly used.

Symmetric-Key Algorithms

Cryptographic algorithms that use the same key for both encryption and de-cryption, are classiﬁed as symmetric-key algorithms. The key has to be dis-tributed in advance to the communicating peers, and the key has to be kept secret. Two different ciphers exist, stream ciphers and block ciphers. The stream cipher algorithms work on bits or bytes of arbitrarily length, and the block cipher algorithms work on a ﬁxed size block of data.

One of the most important block cipher algorithm is Rijndael [18], that was voted and selected for Advanced Encryption Standard (AES), out of 15 candidates. The criteria for submission to the AES was [12]:

∙ symmetric block cipher ∙ design must be public

(28)

∙ key lengths of 128, 192, and 256 bits

∙ possible implementations in both hardware and software

∙ the algorithm must be public or licensed on nondiscriminatory terms.

AES, with the Rijndael cipher from Joan Daemen and Vincent Rijmen, was in-troduced as the successor of (Triple) Data Encryption Standard (DES) [19], in 2000 [12]. Rijndael uses substitution and permutations in multiple rounds. The number of rounds, iterations, depends on the block size and key size. All op-erations involve entire bytes to allow efﬁcient implementation in both software and hardware.

To encrypt an arbitrary length plaintext, the plaintext has to be divided into chunks of the same size as the block size of the cipher. Then each chunk of plaintext has to be encrypted, and the last chunk has to be padded to the block size if necessary. This is called the Electronic Code Book (ECB) Mode, and is the simplest method [12]. This method has a weakness if the plaintext contains repeated patterns. To overcome this weakness, methods that use infor-mation from the previous encrypted block as additional input to the next block of encryption exists. These are Cipher Block Chaining (CBC) Mode, Cipher Feedback Mode (CFB), and Counter Mode (CTR) [2, 12].

Public-Key Algorithms

The weakest link in cryptography has always been the distribution of the keys. The keys have to be distributed and also be kept secret over time. No matter how strong the algorithm is, it becomes useless if the key is compromised.

In 1976, Difﬁe and Hellman proposed a new kind of cryptosystem, where different keys are used for encryption and decryption. There are three require-ments to meet, using previous deﬁnitions of𝐷 and 𝐸:

1. 𝐷(𝐸(𝑃 )) = 𝑃

2. extremely difﬁcult to deduce𝐷 from 𝐸

3. 𝐸 cannot be broken by a chosen plaintext attack.

Cryptographic algorithms that use different keys for encryption and decryp-tion, where one key is secret and the other is public, are called public-key algorithms.

One of the most known public-key algorithms is RSA (Rivest, Shamir, Adleman) [20]. It is based on some principles from number theory, the dif-ﬁculty of factoring large numbers.

(29)

2.1 Security 15

“Mathematicians have been trying to factor large numbers for at least 300 years, and the accumulated evidence suggests that it is an exceedingly difﬁcult problem.” [12]

Compared to symmetric-key algorithms, public-key algorithms are slower by an order of magnitude, since longer keys are required to achieve the same level of security [2].

Message Digest Algorithms

So far we have only covered cryptography to deal with authentication and con-fidentiality. When only authentication is necessary, encryption is a waste of resources. Message Digests (cryptographic checksums) can be used to ensure authentication and integrity, but not confidentiality, and are based on the idea of one-way hash functions. The hash function𝑀𝐷, takes an arbitrary length of plaintext and computes a fixed-length bit string. A message digest has four important properties [12]:

1. given𝑃 , it is easy to compute 𝑀𝐷(𝑃 )

2. given𝑀𝐷(𝑃 ), it is extremely difﬁcult to ﬁnd 𝑃

3. given𝑃 , no one can ﬁnd an altered plaintext 𝑃′ such that𝑀𝐷(𝑃′) =

𝑀𝐷(𝑃 )

4. a change to the input of even 1 bit produces a very different output. To verify for example the integrity of the plaintext, the receiver can calculate the message digest and compare it with the received one. If they match, the plaintext has not been altered. Computing a message digest from plaintext is much faster than encrypting plaintext with a public-key algorithm. Thus, plaintext can be signed much more efﬁciently for digital signatures. At least message digests of 128 bits length should be used [2].

The most common message digest functions are Message Digest algorithm 5 (MD5) [21] and Secure Hash Algorithm-1 (SHA-1) [22]. MD5 is not longer recommended since many collisions,𝑀𝐷(𝑃′) = 𝑀𝐷(𝑃 ), are found [2]. Message Authentication Code Algorithms

The Message Authentication Code (MAC) is used to ensure the integrity and authentication of a message. The main difference between MAC and MD is that the MAC algorithm uses a secret key𝐾 in addition to the plaintext message

(30)

𝑃 as input. The goal with message authentication codes is that it should be very

difﬁcult to generate a valid pair(𝑃′, 𝑀𝐴𝐶_𝐾(𝑃′)) even after eavesdropping one valid pair(𝑃, 𝑀𝐴𝐶_𝐾(𝑃 )).

Some of the most important message authentication codes are [23] Ci-pher Block Chaining Message Authentication Code (CBC-MAC) [24], CiCi-pher- Cipher-based Message Authentication Code (CMAC) [25] and keyed-Hash Message Authentication Code (HMAC) [26].

2.1.4 System Security

More and more sensitive and conﬁdential information is stored in computer systems and it is important to protect the information stored against unautho-rized usage. The information stored can be for example business plans, market plans, or technical design documents [27]. The systems also have to incorpo-rate third-party protection, i.e. own equipment is captured by adversaries and used to deploy some other kind of attack against other systems. The main focus of this thesis is not on system security, but the overall security is not better than the weakest link, therefore system security has to be considered. Deploying only communication security countermeasures will only make ad-versaries focus on system security, since there is no countermeasures there to defeat. With this in mind, the defense-in-depth strategy should be followed, and provide sufﬁcient security at many layers instead of placing all efforts in one place [13, 14]. The defense-in-depth strategy is recommended since the adversaries will most probable try to attack where the probability of success is the best [28]. Designing secure systems is not a trivial matter, and research on secure systems has not advanced much in the last decades [27].

User Authentication

The most used type of user authentication is to require the user to type a login name and a password. Password protection is simple to understand and fairly easy to implement. However, there are many important aspects to consider when designing an implementing password protection. One very important aspect is that the login procedure should reveal as little as possible for an ad-versary. For example if a login fails, the system should not reply with detailed information why the login failed. Secondly, passwords should not be stored in plaintext, they should be protected with cryptography. Guessing login names and passwords are amazingly simple, if there are no guidelines or limitations when selecting a name and a password. Adversaries compile dictionaries with

(31)

2.1 Security 17

possible names and passwords, and automate the process of ﬁnding a success-ful pair. As an alternative, biometrics are also a common and important tech-nique used for user authentication [27].

Access Control

Verifying access rights is referred to as access control, and authorization is about granting access rights. A computer system contains many software and hardware objects that need to be protected. To be able to limit processes from accessing objects that they are not authorized to, access control is used. Nor-mally the access rights are initially set up to access as little as possible for each user of the system. Some examples of objects that could be protected by access controls are memory segments, semaphores, or ﬁles [27].

Discretionary Access Control

The policy of discretionary access control allows users to determine who may read and write to their ﬁles and objects. In some cases this protection is too weak and these environments need mandatory access control, to ensure that the security policies are enforced by the system, in combination with discretionary access control. In the latter case, there are general rules stating who might read and write what information along with special permissions [27].

Sandboxing

The address space is divided into equal size regions, and each region is called a sandbox. A sandbox tries to conﬁne mobile code, for example downloaded from the Internet, in a limited address range in the memory. The mobile code is given two sandboxes, one for the code and one for the data. A sandbox should guarantee that mobile code cannot jump or access memory outside its own sandboxes. The reason for having two sandboxes is that the code should not be able to modify itself during runtime to get around the restrictions of the sandbox. Using sandboxes the code cannot damage other code, plant viruses, or damage memory [27].

2.1.5 Communication Security

The rest of the chapter will focus on how to ensure authentication, authoriza-tion, integrity, and conﬁdentiality in practice from an IT perspective. The cov-ered topics are not the only ones, but among the most important.

(32)

Figure 2.1: ESP in transport and tunnel mode

IPsec

Experts were debating in the 1990s how to secure communication on the Inter-net, and different approaches on how to do this were proposed. Most security experts could agree upon the fact that to be really secure, integrity and conﬁ-dentiality checks have to be end-to-end, i.e. in the application layer. Another view is that users do not want to bother with security in their applications and will not be able to add security countermeasures in existing applications. The other suggested approach was that security should be in the network layer and authenticate, and/or encrypt packets without the users being involved. After some years, the approach with a network security layer won enough support and Internet Protocol security (IPsec) [29] was deﬁned. The main reason for a network security layer, was that security-aware users could still implement end-to-end security and it would help security-unaware users [12].

The complete IPsec design is a framework of services, even if one particular algorithm is broken IPsec will survive since it is algorithm independent. The reason for multiple services is that everyone is not willing to pay the price of all services, when only one is needed. Of all services, confidentiality, integrity, and protection from replay-attacks, are some of the most important. IPsec has two modes, transport mode and tunnel mode, see Figure 2.1. In transport mode, the IPsec header is linked in after the IP header. In tunnel mode the entire IP packet is encapsulated in the body of the new IP header. Tunnel mode is especially useful when the tunnel ends at another location than the final destination, for example a firewall encapsulating and decapsulating packet as they pass through.

(33)

2.1 Security 19

There are two different headers in IPsec, Authentication Header (AH) and Encapsulating Security Payload (ESP). Originally AH handled only integrity and ESP handled only conﬁdentiality. Later, integrity protection was added to ESP. As ESP is capable of everything that AH can, AH is likely to the phased out in the future [12].

IPsec uses symmetric-key cryptography since packet must be processed very rapidly for conﬁdentiality. For integrity, IPsec uses HMAC, which is much faster to compute than ﬁrst running SHA-1 and then running RSA on the result [12].

Firewalls

Firewalls are a modern adaption of medivial security, forcing every message entering or leaving to pass one single entry, thus protecting a local network. At this point, inspection of messages are done, and are accepted or rejected depending on certain criteria. This kind of protection is called perimeter de-fense [12].

The firewalls normally inspect incoming and outgoing messages on both network layer and application layer. On the network layer, the firewalls inspect the source and destination IP addresses and ports. The firewall is configured to accept certain IP addresses and ports in both directions. If IP addresses or ports found during inspection of messages do not meet the configured criteria, they are dropped. In addition to this, the application layer can also be inspected and messages will be dropped if they do not match the criteria. An example of an application gateway is one that inspect e-mails for their size or content, and reject e-mails failing the success criteria [12].

Virtual Private Networks

To connect different sites together without compromising security, firewalls are just not enough. Then possibly confidential information might pass the Internet on its way to the final destination in plaintext. If a company is scat-tered in many locations, the company and the employees must provide security countermeasures by themselves. By using a Virtual Private Network (VPN) messages can be tunneled by using IPsec in tunnel mode between the differ-ent sites, and IPsec is transpardiffer-ently providing confiddiffer-entiality and integrity [12]. Thus the name virtual private network, it is “private” and it is virtual since it is using the same physical network. The main advantage of VPN is that it is completely transparent to the users, since the secure tunneling is done between

(34)

Figure 2.2: Virtual Private Network connecting two sites with IPsec in tunnel-ing mode between the ﬁrewalls

the ﬁrewalls via the Internet, see Figure 2.2 for an illustration. Wireless Security

Even if the setup with ﬁrewalls and VPN seems secure, as in Figure 2.2, it could be completely open if unsecured wireless communication is used on ei-ther of the Local Area Networks (LANs). Wireless access points are normally shipped without security enabled, to work out-of-the-box. Security unaware users, will most probably not think about enabling security. If no security is enabled, possible conﬁdential information will be available for every one. Or the attacker can use the wireless network to access the wired network.

The Wired Equivalent Privacy (WEP) security protocol is part of the 802.11 standard and was originally designed to make the security of a wireless LAN as good as a wired LAN [12]. The problem is that WEP can be broken in less than a minute [30] and it is therefore recommended to use Wi-Fi Protected Access 2 (WPA2) from 802.11i when deploying wireless LANs [3].

2.2 Safety

According to IEC, the deﬁnition of safety is freedom from unacceptable risk

(35)

in-2.2 Safety 21

directly as a result of damage to property or to the environment [31].

Func-tional safety is part of the overall safety, freedom from unacceptable risk, that depends on a system or equipment operating correctly in response to its

in-puts [31]. A system which fails and could cause loss of human life, damage

of property, environment or health of humans is regarded as a safety-critical

system.

2.2.1 Functional Safety

The IEC 61508 standard aims to provide a risk-based approach for determin-ing the required performance of safety-related systems and is a generic stan-dard that can be used directly by industry and can also help the developing sector or product standards [31]. The aim is also to provide means for users and regulators to gain confidence when using computer-based technology, and with sufficient flexibility for the future. IEC 61508 contains requirements to reduce the probability of the occurrence of dangerous failures during the com-plete life-cycle, from project start to product decommissioning, and applies for applications ranging from fly-by-wire to decision support tools.

Generally, the top level hazards for equipment and any associated control system in its intended environment have to be identified by the specifier or developer via a hazard analysis. The analysis determines whether functional safety is necessary to ensure adequate protection against each significant haz-ard. If so, then it has to be taken into account in an appropriate manner in the design. Functional safety is just one way of dealing with hazards, and other means for their elimination or reduction, such as inherent safety through design, are of primary importance [32]. The term safety-related is used to de-scribe systems that are required to perform a specific function or functions to ensure that the risks are kept at an accepted level. Such functions are, by def-inition, safety functions. Two types of requirements are necessary to achieve functional safety [32]:

∙ safety function requirements (what the function does) and

∙ safety integrity requirements (the probability of a safety function being

performed satisfactorily).

The safety function requirements are derived from the hazard analysis, and the

safety integrity requirements are derived from a risk assessment. The higher

the level of safety integrity, the lower the probability of dangerous failure. Any system, implemented in any technology, which carries out safety func-tions, is a safety-related system. A safety-related system may be separate from

(36)

any control system or the control system may itself carry out safety functions. In the latter case, the control system will be a safety-related system. Higher lev-els of safety integrity necessitate greater rigor in the engineering of the safety-related system [32].

Safety functions are increasingly being implemented in electrical, elec-tronic or programmable elecelec-tronic (E/E/PE) systems. These systems are usu-ally complex, making it impossible in practice to fully determine every failure mode or to test all possible behavior. It is difﬁcult to predict the safety perfor-mance, although testing is still essential. The challenge is to design the system in a way that prevents dangerous failures or to control them when they arise. Dangerous failures may arise from:

∙ incorrect speciﬁcations of the system, hardware or software

∙ omissions in the safety requirements speciﬁcation (e.g. failure to develop

all relevant safety functions during different modes of operation)

∙ random hardware failure mechanisms ∙ systematic hardware failure mechanisms ∙ software errors

∙ common cause failures (a failure, which is the result of one or more

events, causing coincident failures of two or more separate channels in a multiple channel system, leading to system failure)

∙ human errors

∙ external inﬂuences (e.g. electromagnetic, temperature, mechanical

phe-nomena)

∙ supply system voltage disturbances (e.g. loss of supply, reduced

volt-ages, re-connection of supply).

IEC 61508 contains requirements to minimize the above mentioned failures from occurring [32].

2.2.2 Safety Integrity Levels

IEC 61508 speciﬁes 4 levels of safety performance for a safety function. These are called Safety Integrity Levels (SIL). Safety integrity level 1 (SIL1) is the lowest level of safety integrity and safety integrity level 4 (SIL4) is the highest

(37)

2.2 Safety 23

level. The standard details the requirements necessary to achieve each safety integrity level. These requirements are more rigorous at higher levels of safety integrity in order to achieve the required lower probability of dangerous failure [32]. There are two modes of operation deﬁned [33]:

∙ low demand mode: where the frequency of demands for operation made

on a safety-related system is no greater than one per year

∙ high demand or continuous mode: where the frequency of demands for

operation made on a safety-related system is greater than one per year. Table 2.3 shows the relation between the safety integrity level and the probabil-ity of dangerous failure/hour in high demand or continuous mode of operation. Table 2.4 shows the relation between the safety integrity level and the proba-bility of dangerous failure in low demand of operation.

SIL High demand or continuous mode of operation (probability of dangerous failure/hour)

4 ≥ 10−9to< 10−8

3 ≥ 10−8to< 10−7

2 ≥ 10−7to< 10−6

1 ≥ 10−6to< 10−5

Table 2.3: Safety integrity levels and the probability of dangerous failure per hour in continuous, or high demand mode [32]

SIL Low demand mode of operation (probability of dangerous failure)

4 ≥ 10−5to< 10−4

3 ≥ 10−4to< 10−3

2 ≥ 10−3to< 10−2

1 ≥ 10−2to< 10−1

Table 2.4: Safety integrity levels and the average probability of dangerous fail-ure in low demand mode [32]

An E/E/PE safety-related system will usually implement more than one safety function. If the safety integrity requirements for these safety functions differ, the requirements applicable to the highest relevant safety integrity level shall apply to the entire E/E/PE safety-related system, unless there is sufﬁcient

(38)

independence of implementation between them. If a single E/E/PE system is capable of providing all the required safety functions, and the required safety integrity is less than that speciﬁed for SIL1, then IEC 61508 does not apply [32].

2.2.3 IEC 61508 Safety Life Cycle

In order to achieve the required SIL for the safety-related system, IEC 61508 adopts an overall safety life cycle to deal with activities in a systematic man-ner. The IEC 61508 safety life cycle deﬁnes several life cycle phases, with objectives, requirements, required inputs, and outputs to comply with for each phase. Each phase shall be documented such that all decisions taken can be followed and analyzed. The safety life cycle phases are illustrated in Figure 2.3 [32].

All phases shall be assessed with respect to functional safety, and depend-ing on the aimed SIL, assessment has to be carried out by a certiﬁcation body. That can either be an independent person, department, or organization [32].

2.2.4 Hardware Safety Integrity

In the context of hardware safety integrity, the highest safety integrity level that can be claimed for a safety function is limited by the hardware fault tolerance and safe failure fraction of the subsystems that carry out that safety function. A hardware fault tolerance of𝑁 means that 𝑁 +1 faults could cause a loss of the safety function. The safe failure fraction of a subsystem is deﬁned as the ratio of the average rate of safe failures𝜆_𝑆 plus dangerous detected failures𝜆_𝐷𝐷 of the subsystem to the total average failure rate (safe failures plus dangerous failures)𝜆_𝑆+ 𝜆_𝐷of the subsystem giving the safe failure fraction [34]:

∑

𝜆𝑆+∑𝜆𝐷𝐷 ∑

𝜆𝑆+∑𝜆𝐷

Subsystems are categorized as either type A or B according to the follow-ing: A subsystem can be regarded as type A if, for the components required to achieve the safety function [34]

1. the failure modes of all constituent components are well deﬁned; and 2. the behavior of the subsystem under fault conditions can be completely

(39)

2.2 Safety 25

(40)

3. there is sufﬁcient dependable failure data from ﬁeld experience to show that the claimed rates of failure for detected and undetected dangerous failures are met.

If the above requirements do not hold, the subsystem shall be regarded as type B. Table 2.5 and 2.6 specify the highest safety integrity level that can be claimed for a safety function which uses a subsystem, taking into account the hardware fault tolerance and safe failure fraction of that subsystem [34].

Safe failure fraction Hardware fault tolerance

1 2 3

< 60% SIL1 SIL2 SIL3

≥ 60%− < 90% SIL2 SIL3 SIL4

≥ 90%− < 99% SIL3 SIL4 SIL4

≥ 99% SIL3 SIL4 SIL4

Table 2.5: Hardware safety integrity: architectural constraints on type A safety-related subsystems [34]

Safe failure fraction Hardware fault tolerance

1 2 3

< 60% - SIL1 SIL2

≥ 60%− < 90% SIL1 SIL2 SIL3

≥ 90%− < 99% SIL2 SIL3 SIL4

≥ 99% SIL3 SIL4 SIL4

Table 2.6: Hardware safety integrity: architectural constraints on type B safety-related subsystems [34]

Detection of a dangerous fault by diagnostic tests, proof tests or by any other means, shall result in a speciﬁed action to achieve or maintain a safe state, or isolate the faulty part to allow continued safe operation. The IEC 61508 standard recommends and encourages use of different techniques and measures to detect faults and to master them depending on the aimed SIL [35].

2.2.5 Software Safety Integrity

Since it is not possible to calculate the error probability of software, a proper life-cycle process is mandatory to minimize systematic errors [36]. The

(41)

soft-2.3 Reﬂections on Safety versus Security 27

Figure 2.4: Software safety integrity and the development life-cycle (the V-model) [36]

ware development life-cycle used is based on the V-model [36] and is illus-trated in Figure 2.4.

Many different techniques and reduced sets of programming languages are recommended to reduce the probability of a not detected dangerous error, and to achieve the ﬁnal SIL requirements. For the higher safety integrity levels, formal or semi-formal methods are highly recommended1_{in combination with} supporting tools, programming languages, as well as coding standards. As an example, see Table 2.7 for the recommendations for the software veriﬁcation phase. For examples of techniques and measures for the complete software development life-cycle, see IEC 61508 [35, 36].

2.3 Reﬂections on Safety versus Security

In the development and design of safety-critical systems all possible error cases which can lead to a dangerous situation are identiﬁed in a structured way before the system is put into service. The design and development of secure systems are executed in a similar way. Even if it is extremely difﬁcult or practically

(42)

Technique/measure SIL1 SIL2 SIL3 SIL4

Formal proof - R R HR

Probabilistic testing - R R HR

Static analysis R HR HR HR

Dynamic analysis and testing R HR HR HR

Software complexity metrics R R R R

Table 2.7: Software veriﬁcation where R is Recommended and HR is a Highly Recommended measure or technique for the aimed SIL [36]

impossible to design a 100% safe system today, the identified risks are not changing over time as the IEC 61508 cycle model covers the complete life-cycle of the safety-critical system from initial design to decommissioning and disposal. In security the risks will change over time, for example if a weakness in a specific crypographic algorithm is discovered, the security countermeasure might not be sufficient any longer. In safety-critical systems the manufacturer can specify under what circumstances and operational conditions the system can be used. It is not that simple to specify that a security countermeasure should not be broken or weakened by adversaries.

To generalize, the main difference with safe and secure communication is the use of Cyclic Redundancy Checksums (CRC) and cryptographic check-sums (MAC or Message Integrity Code, MIC) [37]. The CRC’s are designed to detect unexpected and randomized transmission errors and are not strong enough to withstand intentional misuse by adversaries. However, the MAC and MIC protecting the payload data units are designed to make it troublesome for an adversary to change the payload without any detection by the commu-nicating peers. Thus the MAC and MIC are based upon the use of pre-shared secret keys, while the CRC does not rely on any secret keys.

There are many commonalities and differences with safe and secure com-munication. However, some of the measures taken in the safety protocols can be exchanged with countermeasures from the security domain to make it more difﬁcult for an adversary to manipulate the payload without detection [37]. In the work of Novak et al. [37] the IEC 61508 life-cycle model is extended with security related phases in the life-cycle model to address both safety and secu-rity.

Security countermeasures can also be used as safety measures. The sand-boxing technique from the security domain could be used to isolate safety-related applications from errors caused by other (non) safety-safety-related

(43)

applica-2.3 Reﬂections on Safety versus Security 29

tions. Using sandboxing would increase the conﬁdence of programming lan-guages such as assembler, C, and C++ in safety-critical systems, instead of recommending for example ADA for mission-critical safety systems [35, 38].

(44)

(45)

Chapter 3

Automation Networks

In the automation domain, many different communication protocols exist on various media such as ﬁber, copper cables, radio, or even power-line carrier communication. Since the automation equipment ranges from high-end server hardware from the IT domain, down to small tailored embedded systems with 8 bit processors and just a few kilo bytes of memory, it is a challenging task to solve all needs with one single protocol. From an automation application point of view, communication is for example used for

∙ interconnection of automation equipment distributed over large

geograph-ical areas

∙ interconnection of dedicated real-time automation systems with operator

work-places for control and supervision

∙ closed loop control, ranging from slow processes such as tank level

con-trol, to fast processes such as motion control

∙ condition monitoring, where large amount of data is transmitted and

evaluated to predict and avoid interruption of production.

Some of the most important properties of industrial communication are

∙ high availability, avoid a single-point-of-failure that can compromise the

plant production. The production should be able to continue without major degradation in the case of a single failure

∙ safety, failures in communication should not affect the health of persons,

equipment, or environment

(46)

32 Chapter 3. Automation Networks

∙ low latency and jitter, data must be transmitted with low latency and

jitter for motion control

∙ deterministic, data must be delivered within given time constraints for

example to be able to stop a conveyor belt before any material trans-ported on the conveyor will cause long time of production loss or affect safety

∙ high throughput, plant operators will request production statistics from

the control system that will be presented as a trend curve displaying dif-ferent key performance indexes or to monitor the current production and react before any disturbances in production will occur

∙ simple deployment and maintenance, the life time of automation

equip-ment is expected to be longer than 10 years. In case of malfunctioning equipment the on-site maintenance staff should be able to replace faulty equipment and restore plant production without help from automation system experts. Another reason is that plants can be at inconvenient ge-ographic locations and it would take a long time for an expert to reach the site, for example an offshore oil-rig or deep down in a distant mine

∙ ﬂexible topology, the owners of the plants constantly seek new methods

to improve the production speed and quality, and rearrangement or addi-tion of automaaddi-tion equipment is not uncommon due to new discoveries in the production methodology.

As illustrated in Figure 1.1 the automation networks are divided into several different networks, with different demands and importance of various proper-ties. Typically, the higher levels of the automation networks, i.e. server net-work, has more relaxed constraints on for example latency and real-time prop-erties, compared to the ﬁeld networks. On the other hand, the ﬁeld networks have in general relaxed constraints with respect to throughput, as real-time be-havior, low latency, and low jitter are more important for process control.

On the higher levels of the automation network, Server Network in Figure 1.1, one of the most common protocols are Object Linking and Embedding (OLE) for Process Control [39], or OPC for short. OPC is based upon Mi-crosoft’s Component Object Model (COM) and Distributed COM (DCOM) [40]. Another common protocol, mainly residing on the Control Network from Fig. 1.1 is the Manufacturing Message Speciﬁcation [41] (MMS). MMS is using TCP/IP for transportation as well as OPC. For historical reasons there exist many proprietary protocols on both the server and control network, the

(47)

3.1 Secure Communication 33

main reason is that the equipment on both server and control network are pro-vided from one vendor, and the proprietary protocols remain due to backwards compatibility issues.

On the field network level, the IEC 61784-1 standard specifies 9 different communication profiles [10]. Additional protocols, based on Real-Time Eth-ernet are specified in IEC 61784-2 [42]. In Table 3.1 the protocols from IEC 61784 are listed. Many other protocols exist as well and the aim is not to make this a complete list, but an overview of the multitude of different protocols on the market.

IEC 61784-1 IEC 61784-2

Foundation Fieldbus CIP

CIP PROFIBUS & PROFINET

PROFIBUS & PROFINET P-NET

P-NET INTERBUS

WorldFIP Vnet/IP

INTERBUS TCnet

CC-Link EtherCAT

HART Ethernet Powerlink

SERCOS EPA

MODBUS RTPS SERCOS

Table 3.1: Standardized ﬁeldbus protocols from IEC 61784

3.1 Secure Communication

For historical reasons, security has got little or no attention in the automation domain. The reason is that the automation equipment has initially been placed in a central physical location. The automation equipment, i.e. controllers, I/O, and ﬁeld devices are connected in a marshaling room. The marshaling room is a central place, where all “ﬁeld communication” is passing through, com-pare with old telephone systems. The communication between the controllers and operator stations were based on proprietary solutions with no connections outside the physical location, where only authorized personnel may enter. In a way, security was based on security-by-obscurity and physical security.

Over time, the demand for more information from the ﬁeld equipment was necessary to reﬁne the control algorithms and to improve the quantity and

(48)

qual-34 Chapter 3. Automation Networks

ity of the ﬁnal products. The control systems went from central controllers to distributed control systems (DCS). The latest advancements in wireless tech-nology and condition monitoring allow and demand even further vertical and horizontal integration, or even connections to the Internet. Today, security in the automation domain has gained a lot of attention and the next paragraphs will describe the state-of-the-art in process automation.

The server network communication protocols are security aware. For ex-ample OPC relies heavily on the user conﬁguration of the security. As OPC re-lies on DCOM the security also rere-lies on the limited set of operating systems. MMS have no security countermeasures by deﬁnition, but provides mecha-nisms for access control.

The closer to the sensors and actuators we get, the less aware of security the protocols get. The main reason for this is due to the history of ﬁeldbus com-munication and the initial proprietary protocols. As the ﬁeldbus protocols have emerged to Ethernet-based communication, security is still lacking, mainly due to restricted resources and lack of feasible countermeasures to deploy.

To add further security countermeasures, ﬁrewalls are used to limit the communication to and from the server networks when connecting them to en-terprise networks or the Internet. Also VPN is used to tunnel trafﬁc between different sites over the Internet.

At fieldbus level, the state-of-the-art is to protect even single production cells with a dedicated network protected by a firewall [43]. With this approach each communication segment is protected by a firewall and an adversary has to penetrate several firewalls to reach the field equipment. The horizontal commu-nication below a firewall is based on trust, and all nodes can communicate with each other without any restrictions. The concept of different security zones is also covered in the ANSI/ISA standards [13, 14]. ISA have ongoing standard-ization activities in the area of safety and security for industrial automation and control systems (ISA99 WG7).

3.2 Safety Critical Communication

While secure communication has got little attention in automation in the past, safe communication has got lot of attention and is standardized and mature. However, many proprietary protocols still exist. The main reason for the pro-prietary safety protocols are that not all available safety protocols could be included in the standards. The ones that did not make it to the standard, had an installed base before the ﬁnal selection for standardization and need to be

(49)

3.2 Safety Critical Communication 35

Figure 3.1: Using the black channel to avoid functional safety certiﬁcation of the standard transmission system

maintained for years to come.

The IEC 61784-3 [44] standard specifies general rules and functional safety profiles for the fieldbus profiles specified in IEC 61158, IEC 61784-1, and IEC 61784-2 according to the general functional safety standard IEC 61508. The safety profiles specified in the IEC 61784-3 standard are all based upon the

Black Channel approach from the experiences from the train signaling domain,

IEC 62280-1 [4]. The Black Channel approach simplifies the overall safety certification process, as the standard transmission system does not have to be part of the safety certification, see Figure 3.1 for an illustration of the Black Channel. Using the Black Channel approach, a safety layer is added on top of the standard transmission system that will detect all errors in a deterministic way without relying on any measures of the standard transmission system.

Safety profiles are specified in IEC 61784-3 for the following fieldbus pro-files

∙ Foundation Fieldbus (FF-SIS) ∙ CIP (CIP-Safety)

∙ PROFIBUS & PROFINET (PROFIsafe) ∙ INTERBUS (INTERBUS Safety)

in addition, several proprietary safety protocols exist as well, but these are not considered here.

The possible types of communication errors related to functional safety and IEC 61784-3 are presented in Table 3.2. All safety-proﬁles have to deploy measures to handle the possible communication errors in a deterministic way.

(50)

Error Description

Corruption Messages may be corrupted due to errors within a bus participant, due to errors on the transmission medium, or due to message interference

Unintended repetition

Due to an error, fault, or interference, old not updated messages are repeated at an incorrect point in time Incorrect

sequence

Due to an error, fault, or interference, the predeﬁned sequence associated with messages from a particular source is incorrect

Loss Due to an error, fault, or interference, a message is not received or not acknowledged

Unacceptable delay

Messages may be delayed beyond their permitted ar-rival time window, for example due to errors in the transmission medium, congested transmission lines, interference, or due to bus participants sending mes-sages in such manner that services are delayed or de-nied

Insertion Due to a fault or interference, a message is inserted that relates to an unexpected or unknown source entity Masquerade Due to a fault or interference, a message is inserted that relates to an apparently valid source entity, so a non-safety relevant message may be received by a safety relevant participant, which then treats it as safety relevant

Addressing Due to a fault or interference, a safety relevant mes-sage is sent to the wrong safety relevant participant, which then treats reception as correct

(51)

Chapter 4

Related Work

The security threats to automation systems have been researched, and exist-ing IT security solutions for use in automation networks [2, 16, 45] have been evaluated as well. In the work of Dzung et al. [2] and Treytl et al. [45] ex-isting security protocols, such as Transport Layer Security (TLS) [46], Secure Sockets Layer (SSL) [47] and IPsec, are evaluated for use in the automation domain.

Different attempts and methods to attack PROFINET IO nodes were exe-cuted by Baud et al. [48] without any successful attack. It was stated that if standard Ethernet switches are used, it should be possible to deploy a success-ful man-in-the-middle attack, where an attacker can get in a position between the nodes, relaying and manipulating messages.

A Denial-of-Service (DoS) attack, draining network and CPU resources to reduce the availability or deny service completely, is a non-trivial security threat that cannot be prevented with cryptography. A generic approach how to deal with DoS attacks in automation systems is presented by Granzer et

al. [49].

The weakest point of encryption and cryptographic checksums are nor-mally not the algorithms themselves, but the way the “secret keys” are dis-tributed, since the keys have to be exchanged at some point in time and might be exposed. Implementation of such key distribution schemes are a bigger challenge than to ﬁnd resources for the execution of the security algorithms. One such key distribution scheme has been presented for building automation by Granzer et al. [23].

In the work of Novak et al. [37] the use of MACs, cryptographic

On Security in Safety-Critical Process Control