Thesis Process Control Frameworks - VUrORE · which showed that the number of controls covered by...

1

Author: Wouter van Gils MSc (1608185) January 2012 Postgraduate study programme on EDP auditing VU University Amsterdam University counselor: Dr. ir. Abbas Shahim RE Company counselor: Drs. ing. Arnout. E. Ratelband RE RC & Anko van der Ziel Thesis No: 1078

Thesis:

Process Control Frameworks Which frameworks are available for PCS’s

and how do companies use these frameworks

2

Executive Summary Process controlling has existed for a long time and is essential for controlling industrial processes as in, for example, a nuclear power plant or on an oil rig. The process control domain (PCD) has always been the area of engineers and segregated from the other high IT involved business systems and used to be relatively secure for that reason. Recent developments have shown however that the of security has dropped due to increased consolidation with the Office IT domain and several incidents which have occurred. This has resulted in more regulation and legislation (driven by national security regulations) to which organizations must comply. In response, the industry created more standards, frameworks and good practices. In this connection, the main research question for this thesis is the following:

Which frameworks are available for the security of Process Control Systems and

how do companies experience these frameworks in practice? Information about PCD frameworks was collected from various literature sources, and from explorative expert interviews it appeared that the ISA99, NIST 800-82 and NERC CIP are currently the most commonly used frameworks. For these framework a comparison was made which showed that the number of controls covered by the frameworks were almost the same. However, the comparison also showed two differences; ISA99 does not describe controls regarding management systems for the controls. However, the ISA99 standard is still under development and will be added later to a related document within the standard. Another difference is that the NERC CIP does not cover filtering/blocking access control technologies. The reason for this may be that the control description in NERC CIP is often on a higher level. The interviews have shown that PCD frameworks are being used (and in some cases legally required), but mainly as a good practice in order to create a more complete/suitable PCD framework for the organizations. The use of ISO27001 (including the related ISO27002) is noticeable, as this framework covers most of controls of the PCD frameworks. However, specific controls and descriptions given in the framework are really different from those in the PCD frameworks. Next to that, the interviews have also revealed that a tier model is being used. One of the organizations interviewed is using this solution to customize the control to its own operations by matching controls with the level of criticality of the PCS. The interviews have also shown that the PCD frameworks are not used as is but that companies really need to customize the selected controls in order to make them consistent with how they intend to use and secure the PCD within their organizations. Summarizing the results of the framework analysis and the interviews, it can be said that it does not really matter in what sense a framework is the most complete or accurate or relevant for an organization, as most organizations in the end do not use the frameworks as is but rather as a good practice to compose their own framework. In addition, ISO27001 is still the leading framework for information security, but ISA 99, NIST 800-82, NERC-CIP and other PCD frameworks are used to create a more specific set of controls in a customized organization specific PCD framework.

3

Preface This document is the result of the thesis of the postgraduate study programme on EDP

auditing at VU University Amsterdam. The thesis covers a specific area that is still relatively

little known in the IT Auditing field: Process Control Domain.

Before writing this thesis, my work was mainly related to financial audits. This thesis raised my

interest in information security, not only in the process control domain but also in information

security in general. Both topics are still a much neglected topic, and this needs to be changed

in order to safeguard our businesses and critical infrastructure.

I would like to thank my supervisor at VU University Amsterdam, Abbas Shahim, and my

supervisors at Ernst & Young, Paul Schneider for the exploration part of this thesis and Arnout

Ratelband and Anko van der Ziel for their support and feedback. Also I wish to express my

sincere thanks to the interviewees for taking the time to do the interviews despite their busy

schedules.

Furthermore, I would like to thank my girlfriend and son for their patience during the many

evenings or afternoons that I spent working in my study without paying any attention to them.

W.G. (Wouter) van Gils MSc

4

Table of contents

Executive Summary 2

Preface 3

Table of contents 4

1 Introduction 6

1.1 Problem definition 6 1.2 Goal of the research & research questions 6 1.3 Research approach 7 1.4 Scope limitations 7 1.5 Layout of this thesis 8

2 What is the Process Control Domain? 9

2.1 PCD components 9 2.1.1 Field instruments 9 2.1.2 Programmable Logic Controller 9 2.1.3 Human Machine Interface 10 2.1.4 Remote Terminal Unit 11 2.1.5 Master Terminal Unit 11 2.1.6 Composition of these components 12

2.2 Office IT vs. PCD 13 2.3 Importance of PCD Security 15

2.3.1 Regulations 15 2.3.2 PCD Incidents 16

2.4 Recap of this chapter 18

3 Which frameworks can be identified 19

3.1 ISA99 19 3.1.1 About the framework 19 3.1.2 Purpose of the framework 21 3.1.3 Guidance within the framework 22

3.2 NIST 800-82 22 3.2.1 About the framework 22 3.2.2 Purpose of the framework 22 3.2.3 Guidance within the framework 23

3.3 NERC CIP standard 23 3.3.1 About the framework 23 3.3.2 Purpose of the framework 24 3.3.3 Guidance within the framework 24

3.4 Recap of this chapter 24

5

4 PCD Frameworks compared 26

4.1 Overview of controls 26 4.2 Recap of this chapter 28

5 Use of the PCD frameworks and lessons learned 29

5.1 Frameworks used as good practice 29 5.2 Use of ISO27001 30 5.3 Tier model 30 5.4 Management system of the frameworks 31 5.5 Recap of this chapter 31

6 Summary 32

6.1 Conclusion 32 6.2 Reflection and discussion 34

6.2.1 Research reflection 34 6.2.2 Result discussion 34

6.3 Further research 35 6.3.1 Tier models & the applicability 35 6.3.2 Who is responsible for the security of PCS‟s 35 6.3.3 Self assessment tools 35

APPENDIX A – Bibliography 36

APPENDIX B – Framework comparison 38

APPENDIX C – Unique characteristics of the Office IT versus PCD 42

APPENDIX D – Interview questions 43

6

1 Introduction

1.1 Problem definition

Process controlling has existed for a long time and is essential for controlling industrial processes in, for example, a nuclear power plant or on an oil rig, as well as in many day-to-day processes, e.g. controlling traffic lights, matrix shields on motorways or escalators in department stores. The Process Control Domain (PCD) has always been the area of engineers and segregated from other high IT involved business systems (e.g. IT systems for financial administration, payroll, sales etc.) which, for easy reference, will be named the Office IT Domain below. The past few years have seen increased integration between these two domains, due to the increasing use of the same technology, like UNIX or Windows servers, technology like TCP/IP or the use of wireless networks. As a result the vulnerabilities of process control systems in the PCD are more comparable with the well-known vulnerabilities in the Office IT Domain, like access violations, hacking, malware etc. In the Office IT Domain a lot of effort has been put into securing IT processes and this is still a hot issue: in all large companies cyber crime is on the agenda of the Board of Directors. For IT professionals, including IT auditors, well-known information security standards have been developed, of which the ISO27000-series is the most prominent. In the VU thesis “Process Control Network Security” (Peerlkamp & Nieuwenhuis, 2010) it was argued that security for the PCD is as vulnerable as it is in the Office IT Domain and that the impact of deficiencies can be disastrous to society. Think what may happen if hackers enter the processing systems of a nuclear plant! The question that rises now is whether there are specific frameworks for security in process control systems (PCS), i.e. for controlling specific risks in the PCD and, if so, how organizations make use of such frameworks.

1.2 Goal of the research & research questions

In their thesis Peerlkamp & Nieuwenhuis examined which controls should be added to the ISO/IEC 27001:2005 framework (referred to as „ISO 27001‟ below) in order to create one comprehensive framework. However, discussions with PCD engineers revealed that organizations already control their process control systems using (parts of) existing control frameworks from within the PCD. The goal of this research was to provide insight into the experiences and the use of specific PCD frameworks. In addition, a comparison with ISO27001 will be made to find out whether the security controls in the PCD are comparable to the security controls in the Office IT Domain (e.g. ISO27001). This research goal led to the following research question: Which frameworks are available for the security of PCSs and how do companies experience these frameworks in practice? In order to answer this main question, multiple sub-research questions were formulated:

7

1. What is the PCD? 2. Which frameworks are available for the security of PCSs? 3. What are the differences between the frameworks? 4. How do companies make use of these frameworks to secure PCSs? 5. What are the lessons learned regarding these frameworks?

1.3 Research approach

The main research question of this thesis is of an explanatory nature while a substantial part of the research carried out is descriptive. This is visible in the sub-research questions: the first three are descriptive; the last two questions are explanatory. A gradual approach was used that consisted of five phases. Phase 1 was to set the scope and boundaries of the research and to define the research questions. In phase 2 a literature review was performed to gain the in-depth knowledge of the PCD required to answer the first and second sub-questions. In phase 3, the frameworks determined in the second phase were compared in order to answer the second sub-research question. Phase 4 consisted of the interview to discuss the frameworks that have been compared and the lessons learned which lead to an answer to the fourth and fifth sub-research questions. The goal of the last phase, phase 5, was to draw a conclusion for all previous phases and thus answer the main research question. The answer to the main research question will ultimately follow from the answers to all previous questions.

1.4 Scope limitations

This thesis only covers a comparison of PCD frameworks and their use by businesses. A reference is made to the ISO27001 framework, which is the most commonly used framework for security in the Office IT Domain. However, this ISO framework is only used because it is widely known and is a good reference point for the PCD frameworks. Any other frameworks regarding the Office IT Domain are beyond the scope of this thesis, and so are regulatory (including health & safety) issues that often are only relevant for the PCD. In addition, this thesis does not cover research into PCD risks, vulnerabilities and threats.

Figure 1- Research approach

Research questions

Literature review

Framework analysis

Result analysis

Conclusion

Interviews

8

1.5 Layout of this thesis

This first chapter now includes the introduction, the research question and the approach to answering the research question. The following chapters are related to the sub–questions. The second chapter discusses the first sub-question: What is the PCD? The components of the PCD are mentioned as well as its importance. This chapter also explains the differences between the Office IT Domain and the PCD. Chapter 3 covers the next two questions: What are the (major) security frameworks in the PCD frameworks, and how do these frameworks differ from each other and from ISO27001? The details of the differences are presented in a table in Appendix B. ISA99, NIST 800-82 and NERC CIP are selected as major frameworks. The next chapter, chapter 5, concerns two questions: How do companies make use of these frameworks to secure PCSs? and What are the lessons learned regarding these frameworks? This chapter presents the answers to these questions by experts from various organizations. Finally, chapter 6 describes the summary of my thesis including the conclusion, a reflection on and discussion of the research, the results and topics for further research.

9

2 What is the Process Control Domain? The PCD is a combination of different real-time industrial process control systems. Other names which often refer to this same topic are Supervisory Control and Data Acquisition (SCADA) systems, Distributed Control Systems (DCS), Industrial Control Systems (ICS), etc. All these systems serve the same goal: the central remote controlling of industrial equipment such as sensors, pumps, measurement, valves, etc. These are all types of equipment found in modern factories or plants and used in a variety of industries: oil and gas, electricity, water, chemicals, transport, food and beverage, etc. The infrastructure of a PCS tends to be quite complex (a PCS may consist of thousands of units) and in daily practice often consists of legacy systems. As a result, the PCD is difficult to control but also demands high availability. For example, think of a subway network with sensors, stations, cables, information signs and one main control room to set all track changes. The purpose of this chapter is to answer the first sub research question: What is the PCD?

2.1 PCD components

This section describes the most common components in a PCD environment. The structure of this chapter is based on the degree to which the component directly influences the actual process. This chapter also describes the relation between these components. To understand the components better and how they are used in practice, an example of a subway system is used.

2.1.1 Field instruments

The lowest level of process control is that of the field instruments. These instruments actually guide the process. A distinction can be made between field instruments which input data for the next level (a sensor which detects if a train is currently on a specific section of the track) and instruments which receive data and take action (e.g., a small engine operating a railway switch) (Peerlkamp & Nieuwenhuis, 2010). Figure 2 shows some examples of sensors which are typically used in the PCD (Google Images, 2012).

2.1.2 Programmable Logic Controller

“PLCs are computer-based solid-state devices that control industrial equipment and processes.” (NIST Special Publication 800-82, 2008). In other words, PLCs take care of controlling the field instruments. Within PLCs a program code is included that is specifically created for this specific purpose. The PLCs understand the data from the field instruments

Figure 2- Example of sensors

10

Figure 3- Example of PLCs

Figure 4- Example of a HMI

and act on it, which can mean passing it on to another system but also controlling other field instruments (Daneels & Salter, 1999). Figure 3 shows some examples of PLCs typically used in the PCD (Google Images, 2012). For example, a sensor (a field instrument) detects that a train has passed a certain railway section. The PLC understands and processes that information and communicates it to another field instrument (a light) to change the signal to green. This signal shows that it is safe for another train to move into that railway section.

2.1.3 Human Machine Interface

The Human Machine Interface (HMI) takes care of the interaction between a person and a PLC. Like a PLC, a HMI consists of software and hardware which allows human operators to monitor the state of a process and to act on that by modifying the settings or manually override the automatic control operations in the event of an emergency. HMI systems may be required to show information and process information from the human operator or only to show information (Peerlkamp & Nieuwenhuis, 2010). Formerly, HMI systems used to contain only some LEDs. HMI systems are now accessible from desktops/laptops and even on the Internet via a browser. Figure 4 shows an example of an HMI system typically used in the PCD (Google Images, 2012). In the case of a subway system, an HMI could take care of the information for passengers shown on the platform, telling them that their train will arrive in four minutes. If two trains are moving toward each other on the same track, an HMI would enable an operator (in a central location) to immediately switch off the power on those railway sections to prevent an accident.

11

Figure 5- Example of a RTU

Figure 6- Example of a MTU

2.1.4 Remote Terminal Unit

A Remote Terminal Unit (RTU) is an autonomous control system for (simple) logical processes. An RTU device is a kind of PLC, but is also designed to communicate with the Master Terminal Unit, using the most suitable communication network like Ethernet, Wi-Fi, GSM, Radio, etc. (NIST Special Publication 800-82, 2008). Figure 5 shows an example of an RTU typically used in the PCD (Google Images, 2012). An RTU also could receive information from a PLC and redirect it to the MTU. For example, an RTU can be placed at each station (and at each railway track near the station). The RTU would then communicate the locations of trains to the centrally located control room where it would become available to the operator via an HMI.

2.1.5 Master Terminal Unit

Master Terminal Units (MTUs) are remote central monitoring and control stations (for example, in an office) that control the components (e.g. RTU, PLCs, etc.) in the PCD. The Master Terminal Unit is usually defined as the master or heart of the PCD and is often located at the operator's central control facility office. MTU systems used to be equipped with custom/UNIX/Linux operating systems, but modern MTUs tend to use Microsoft Windows based operating systems. The MTU can monitor and control multiple RTUs at remote locations. Figure 6 shows an example of an MTU typically used in the PCD (Google Images, 2012). Within the subway system, the MTU can be the control room with a big screen which shows all railway tracks and the current locations of trains, as well as any disruptions or congestion.

12

2.1.6 Composition of these components

As shown by the scheme below, all these components are connected to each other. Multiple sensors are connected to a PLC. Note that their number may vary; there can be one just as well as twenty. In turn, multiple PLCs can be connected with an RTU. An RTU can be connected via a MTU to several HMI systems, resulting in the situation as shown in the example picture above. However, an HMI system can also be connected directly to a PLC or RTU (NIST Special Publication 800-82, 2008). The right side of the scheme shows which part of the subway system is done by which system as described in the examples above.

Figure 7- Components of the PCD composition

Sensor Sensor Sensor Sensor Sensor Sensor

PLC PLC PLC

RTU RTU

MTU

HMI

HMI

Sensor

Railway control room to show

the operators information

they can respond to

Located at the station to

communicate the train

locations to the control room

Receive information that a

train has left a certain rail

section and ensure that the

signal turns green

Sensor to detect the

location of a train

13

Figure 8 - Integration trend

Business

PCD Office IT

Business

PCD Office IT

2.2 Office IT vs. PCD

The Office IT (used for financial administration, accounting, reporting, asset management, payroll, etc. and more commonly combined in an ERP system) and PCD systems (used to control industrial IT systems) used to be on two separate Local Area Networks (LAN). PCSs, often built on specific hardware and software and, hence, not very vulnerable to cybercrime, does not change. More generic devices are replacing proprietary solutions, which also are more vulnerable to cyber security incidents. A good example of this is the Stuxnet attack, which focused exclusively on Siemens SIMATIC WinCC or STEP 7 SCADA systems (Matrosov, 2011). The PCS are also adopting more connectivity options, for example to connect via RTU to MTUs or directly to the Internet. Companies want to become more aware of the current state of processes within the company, for which purpose they need access to all information from all systems. For that reason, information from the PCS needs to be shared with the business applications. The business LAN and the PCD LAN are shared and also connected directly to the Internet. This development leads to more risks and threats. Figure 8 shows a schematic representation of this trend.

Internet Internet

14

The PCD has some characteristics that differ from Office IT systems, including other risks, vulnerabilities and threats. While the risks incurred with an Office IT system include loss of time, money or data, the risks associated with a PCD potentially involve a loss of lives, environmental disasters, an outbreak of diseases, floods, etc. Furthermore, the goals of process safety and efficiency may conflict with security in the design and operation of systems. Table 1 presents a concise overview of the different risks.

Potential ineffective ramifications for critical infrastructure companies

Impacts Office IT PCD Revenue and profitability Yes Yes Reputation Yes Yes

Regulatory and fines Yes Yes Health and human safety No Yes Environmental damage No Yes National security No Yes Table 1 - Office IT vs. PCD risk overview (Ernst & Young, 2012)

Also, the vulnerabilities of the Office IT domains differ from those of the PCD. PCS are often very old legacy systems (some systems have a lifespan of 30 years) which need to be handled differently compared with “modern” Windows/Unix like servers. For example, while it is easy to install anti-virus applications on Office IT systems, this is a great deal more complicated for an MTU or RTU running a custom-made operating system and may not even be necessary as no viruses exist for those systems. Next to this, the PCD has some unique characteristics that distinguish it from the Office IT Domain (US-CERT, 2011). Some of these characteristics are also related to each other. PCD systems have a lifespan of 10-30 years; it will be difficult to find another vendor after that period due to the specific task that the system performed. An Office IT system has a lifespan of approximately 2-3 years and can be sourced from a lot of vendors (for example, laptops are sold by Dell, HP, IBM, Apple, Sony, etc. and the software can differ too (Windows or Linux)). Due to the legacy system within the PCD, some other processes are difficult to perform. One example is patch management. Firstly, it is difficult to find the right moment to update certain PCD systems. Secondly, the vendor should also create some patches and as he is the only vendor, the client will simply have to wait until a patch is released. Thirdly, testing is a completely different process than within the Office IT Domain. See Appendix C for a table with more control differences (US-CERT, 2011). Vulnerabilities are often detected via penetration tests. On a PCS this is slightly more complicated than on an Office IT system. A simple port scan would not have that much impact on an Office IT system. If the same port scan is performed on a PCD system, it might trigger an action (an actual vulnerability). For example, on one occasion a port scan resulted in a completely unexpected swing of a robotic arm in a factory. Fortunately the engineer was beyond the reach of the arm and was not harmed, but the risks are obvious (Duggan, 2005).

15

The last difference described in this chapter is the use of the well-known CIA triad. CIA stands for Confidentially, Integrity and Availability. Information systems are required to comply with the CIA triad. In general, for Office IT systems (compared with the PCD), confidentiality and integrity are more important than availability. However, in the PCD the CIA triad is reversed (AIC) (Fenrich, 2007): availability is by far the most important component of the AIC triad. For really critical systems a 99.99% uptime is required. Integrity is also important as the PCS will need to work with the right value. Confidentiality is less important (not counting exceptions).

CIA principles of information security, Office IT versus PCD Confidentiality Integrity Availability Office IT High importance High importance Low importance PCD Low importance Medium importance Very high

importance Table 2 - CIA of Office IT vs. PCD

2.3 Importance of PCD Security

2.3.1 Regulations

PCD security is rapidly becoming more important, not least because of intensified regulation. In May 1998, President Clinton signed Presidential Directive PDD-63 regarding “Critical Infrastructure Protection” (Moteff & Parfomak, 2004). In response to the terrorist attacks on 9/11, this Directive was updated in 2003 with the Homeland Security Presidential Directive HSPD-7 for Critical Infrastructure Identification, Prioritization, and Protection (Evans, 2009) signed by President Bush. A similar programme in Europe, the “European Programme for Critical Infrastructure Protection” (EPCIP), was introduced in 2006. The programme and directives resulted in the establishment of a number of organizations which regulated the critical infrastructure. Examples of critical infrastructure are nuclear or other power plants, water and drainage systems, transportation systems (public transport, airports, roads, tunnels) and information and communication systems (Moteff & Parfomak, 2004). All these systems (both in the US and in Europe) were marked as Critical Infrastructure and needed to be protected from emergencies, disasters, hacks, etc. The organizations were given the task to regulate this for specific systems, which included the security of information systems. As these systems are part of the PCD, this was also included. Since then, in the US, the North American Electric Reliability Corporation (NERC) has been responsible for enforcing reliability standards for the bulk power system. The NERC produced the NERC CIP PCD framework and also performed audits on these controls. The International Atomic Energy Agency (IAEA) and the US Nuclear Regulatory Commission also perform audits on the PCD systems at nuclear power plants all over the world (Glantz et al., 2005). Regarding oil and gas, the American Petroleum Institute (API) regulated this with the API Standard 1164, “Pipeline SCADA Security” (Evans, 2009).

16

Figure 9 - Increase in sophistication of attacks (Lipson, 2002)

2.3.2 PCD Incidents

In addition to the regulations, the actual or near incidents which have occurred over the last few years have made organizations more aware of the need for security within the PCD. The number of computer security incidents (generic, so particularly focused on the PCD) handled

by the CERT Coordination Center (CERT/CC) increased from 6 in 1988, to 137,529 in 2003 and after that, the CERT stopped counting incidents as the number was too high (CERT Historical Statistics, 2009). Not only did the number of attacks increase, but so did their level of sophistication. The use of widely available scripts and tools could even cause the actions of an inexperienced hacker to have devastating effects. The graph below shows the sophistication of attacks performed over the years (Lipson, 2002). It is difficult to mention an accurate amount of PCD incidents occurred so far. However, organizations are encouraged to track their PCD incidents in a Repository of Security Incidents (RISI). This repository contains accidental cyber-related incidents as well as incidents caused by illegal access, DDoS attacks, etc. For all the incidents registered, an investigation is done and rated according to the reliability to ensure that only real incidents are registered. Up to December 2009, 175 confirmed incidents have occurred (Number of Security Incidents Continues to Increase, 2010).

17

Table 3 shows a selection of recent PCD security incidents and the impact of these incidents. Repercussions from ineffective cyber security practices in the PCD Event Location Impact

Gasoline pipeline failure exacerbated by

control systems not able to perform control

and monitoring functions (Whatcom Creek)

North America Three fatalities, total property damage

> US$45m

Sewage spill caused by wireless hacking of

sewage discharge valves

Australia > 1m liters of sewage spilled

Substation communication failure from

Slammer work traffic

North America SCADA failed, resulting in loss of

control

Targeted SCADA hack from internet North America No SCADA servers for two weeks; no

mapping system for two weeks; four

man-months to recover

Control center communication failure from

unpatched Cisco router by worm

Europe Loss of communication to almost half

of the distribution substations for

almost three days; inability to diagnose

for 24 hours; approximately 40 man-

weeks to clean up

Aurora experiment at the Idaho National

Laboratory demonstrated a large diesel

generator malfunctioning due to a remote

attack

North America Remote destruction of a large diesel

generator

Control system workstation failures caused

by IT penetration testing

North America Slowdown or shutdown of all power

plant control system workstations

Loss of power plant control from hackers North America For a brief period of time, a hacker

played with the level control on a

deaerator control system

Stuxnet attack targeting Siemens SCADA

systems resulting in significant setbacks to

the Iran nuclear program

Iran Damage to the controllers handling the

centrifuges at Iran‟s Natanz facilities

Table 3- Recent PCD incidents (Weiss, 2010)

Local organization might think that PCD incidents only could happen at big companies because there are more incentives. However, regarding the critical infrastructure protection, no incentives are needed. Also small PCD systems need to be protected. Nowadays, the media and politicians are also getting knowledge about this topic. Like in The Netherlands were in the village Veere, a password of the systems pumping water out of the polders was actually “veere”. Regarding this incident, “kamervragen” were asked in the house of representatives of The Netherlands (Opstelten, 2012) which shows again the importance of this topic.

18

2.4 Recap of this chapter

This chapter gave answer to the first research question: What is the PCD? This chapter described that a PCD consist of a collection of components (field instruments, PLC‟s, HMI‟s, RTU‟s and MTU‟s) which are all included in an industrial process. The composition of these controls is also described and an example of a subway system is used to make it more tangible. In addition, the differences between the Office IT domain and the PCD domain are explained and trend towards moving to each other. Vulnerabilities, risks and threats are different as well and need to be dealt with on another way. The CIA triad for the Office IT is not suitable to use for the PCD domain is also explained, this is because the availability for is much more important (what will happened if a systems controlling a nuclear power plant fails?). As last part in this chapter, the reason why PCD security becomes more important in the industry is explained. This is because the introduction of more regulation and legislation due to introduction of a couple of acts and programme started by the Presidents of the United States and the European parliament. The recent number of incidents also did lead to more relevance for the industry.

19

3 Which frameworks can be identified There are a large number of frameworks or best practices (which can be used as a framework) available to control the PCD. During the literature review, a scan was performed of relevant literature on various sources and a large number of PCD frameworks or good practices were identified which are stated below in this long-list:

Department of Homeland Security guidelines Department of Energy guidelines ISA99 NIST 800-82 Good practice guide process control and SCADA security (by the CPNI in the UK) NERC CIP Framework for SCADA Security Policy by Sandia CS2SAT DNPSec

As the list above contains too many PCD control frameworks, I raised a question during the interviews in the literature phase which frameworks were best-known and used. Three frameworks were identified as being most known and most used, which are outlined in the short-list below:

- ISA99 (ANSI/ISA-TR99.00.0X-2007) - NIST 800-82 - NERC CIP standard

This chapter continues with a description of the frameworks, the purpose of the frameworks and the form of guidance is described (e.g. how are the controls described)? Is this very descriptive or more strict (A password should consist of at least 8 characters)? The password authentication control is used as an example to describe these difference forms of guidance. This chapter gives an answer to the second sub-research question: Which frameworks are available for the security of PCS’s?

3.1 ISA99

3.1.1 About the framework

ISA99 is actually a set of standards (International Society of Automation, 2007). The ISA99 standard committee consists of members with different backgrounds which are working with PCS‟s (like Consultants, Hardware/software vendors, Security specialists, etc.). One of these standards is the technical report (ANSI/ISA99.00.01-2007) which provides an evaluation and assessment of many current types of electronic based cyber security technologies, mitigation methods, and tools that may apply to protecting the PCD against cyber attacks. The focus of this thesis is on this technical report (ANSI/ISA99.00.01-2007) as this document actually describes the controls. The ISA99 Series of Standards

20

In addition to this technical report, the ISA99 committee is developing a series of standards on cyber security for the industrial automation and control systems environment. This series includes:

1. ISA99.00.01 (General) – Security for Industrial Automation and Control Systems Part 1: Terminology, Concepts and Models (Published in 2007) Part 1 of this standard establishes the context for all of the remaining standards in the series by defining a common set of terminology, concepts and models for electronic security in the industrial automation and control systems environment.

2. ISA99.00.02(Policies & Procedures) – Part 2: Establishing an Industrial Automation and Control System Security Program (Published in 2009 under the name ANSI/ISA-99.02.01-2009) Part 2 describes the elements of a cyber security management system and provides guidance for their application to industrial automation and control systems.

3. ISA99.00.03 (System) – Part 3: Operating an Industrial Automation and Control System Security Program Part 3 will address how to operate a security program after it is designed and implemented. This part includes guidance for defining and applying metrics to measure program effectiveness.

4. ISA99.00.04 (Component) – Part 4: Technical Security Requirements for Industrial Automation and Control Systems Work began in mid-2007 on the Part 4 standard, which will define the characteristics of industrial automation and control systems that differentiate them from other information technology systems from a security point of view. Based on these characteristics, the standard will establish the security requirements that are unique to this class of systems.

21

Figure 10- ISA99 structure

3.1.2 Purpose of the framework

The purpose of the ISA99 framework (in specific the technical report focused on in this research paper: ANSI/ISA99.00.01-2007) is to categorize and define cyber security technologies, countermeasures, and tools currently available to provide a common basis for technical reports and standards to be produced later by the ISA99 committee. “The intent of this (ANSI/ISA99.00.01-2007) ISA99 framework is to document the known state of the art of cyber security technologies, tools, and countermeasures applicable to the IACS environment, clearly define which technologies can reasonably be deployed today, and define areas where more research may be needed.” (International Society of Automation, 2007). This statement means that the purpose and intent of the ISA99 framework is to provide some hands on knowledge on the actual availability of security technologies, tools and countermeasures which are relevant for the PCD. Next to that, with the knowledge of the available technologies, tools, etc., the ISA99 framework also provides some insight on what is missing and what topics require more research.

22

3.1.3 Guidance within the framework

The ISA99 standard describes the recommended controls in detail. It gives a general description of what the control is about, like the types of passwords (Passcode/PIN, password, passphrase) and also the characteristics of the different types of passwords (length, complexity, etc.). Next to the description of the control, the ISA99 standard also describes the security vulnerabilities, the typical deployment and the known issues and weaknesses of the controls. For that last topic (known issues and weaknesses), the standard describes the following issues for passwords (the example used throughout this paper): default passwords, known simple passwords (like “password” or “operator”), key loggers to detect the password, hashed passwords and access to the password file. The ISA99 standard also describes the assessment of the control in a PCD environment and the problems which could arise. For example, in times of crisis, an operator needs to login into a device very urgently; however due to the stress the operator types the password a couple of times wrong and his account may be blocked. The standard also describes the future direction of the control. For the password control example, the future direction of the control is to make more use of Role-Based Access (all operators with the same role use a generic role account). The control description ends with some recommendations, guidance and references to literature for more information. From a qualitative perspective, the level of guidance given by this framework for this thesis is evaluated as a 4 on a 1-5 scale.

3.2 NIST 800-82


The NIST 800-82 standard provides an overview of PCS‟s and typical system topologies, identifies typical threats and vulnerabilities to these systems and provides security countermeasures to mitigate the associated risks (NIST Special Publication 800-82, 2008). The document describes the generic overview of PCS‟s and next to that, it provides guidance on how to develop a PCD security program. In the last chapters of the document, a summary is given of the NIST 800-53 document (NIST Special Publication 800-53, 2009), which actually describes the controls and provides initial guidance on how these security controls apply to the PCD.


The purpose of the NIST 800-82 framework is to provide guidance for securing PCS‟s. The NIST 800-82 provides an overview of PCS and typical system topologies, identifies typical threats and vulnerabilities to these systems, and provides recommended security countermeasures to mitigate the associated risks. Because there are many different types of PCS with varying levels of potential risk and impact, the document provides a list of many different methods and techniques for securing PCS. The NIST 800-82 framework should not be used purely as a checklist to secure a specific system. Organizations which use the

23

framework are encouraged to perform a risk-based assessment on their systems and to customize the recommended guidelines and solutions to meet their specific requirements.


The NIST 800-82 describes the control a bit differently than the ISA99, however we have to note that the NIST800-82 is related very closely to the NIST 800-53 which describes the control at a more detailed level with less guidance than the NIST 800-82. For each set of controls, a (sub)chapter is created in the standard, like “6.3.1 Identification and Authentication” for the password authentication control. Within this chapter a generic introduction is given to all types of measures for the control, like pin code, password, biological identification, location based identification, etc. Also the relation to the NIST 800-53 control-section (IA, Identification and Authentication) and other related NIST documents are mentioned. Next the subchapters (6.3.1.1 Password Authentication in our example) describe a more specific formless version of the control. Within an outlined box, PCD specific recommendations and guidance are given. For the password example, NIST 800-82 also provides examples of mistakes during made during moments of stress and there is mention that “Organizations should carefully consider the security needs and the potential ramifications of the use of authentication mechanisms on these critical systems”. Within this box, the recommendations are also given like length, complexity, use of a master password, etc. From a qualitative perspective, the level of guidance given by this framework for this thesis is evaluated as a 3 on a 1-5 scale.

3.3 NERC CIP standard


The NERC CIP (Critical Infrastructure Protection) standard is created by the NERC (North American Electric Reliability Corporation). The NERC is a non-profit organization that defines and enforces reliability standards for the bulk power system in North America (NERC CIP Standard). This standard is made compulsory for all entities responsible for the reliability of the Bulk Electric Systems in North America. For its members, the NERC created a framework (as described in the CIP standard) on how the PCS‟s should be controlled. The controls are described on a very detailed level and do not give a lot of guidance and background information.

24


The purpose of the Critical Infrastructure Protection (CIP) program and framework is to coordinate all of NERC‟s efforts to improve physical and cyber security for the bulk power system of North America as it relates to reliability. These efforts include standards development, compliance enforcement, assessments of risk and preparedness, disseminating critical information via alerts to industry and raising awareness of key issues. The Framework also recognizes the differing roles of each entity in the operation of the Bulk Electric System, the criticality and vulnerability of the assets needed to manage Bulk Electric System reliability, and the risks to which they are exposed.


The NERC CIP standard is described quite differently compared to the ISA 99 and NIST 800-82. Each control is divided into smaller (sub)chapters. The first one, A. Introduction, only describes that this control is part of the larger NERC CIP standard and who is responsible for this control and which types of companies are exempt for this particular control. Chapter, B. Requirements, describes the requirements to which the PCS should comply to. For example: for R5.3, the requirement is that a password should have a minimum length of 6 characters, should contain numbers, letter and special characters and that each password should be changed annually. Chapter, C. Measures, describes what the responsible entity should document for this control and chapter D. Compliance, describe how to be compliant to the framework. At last, chapter E. Regional Variances describes some control differences. For example, in the US when states have different laws which influence the control. Some controls also have an Appendix which is used as a Frequently Asked Questions section. From a qualitative perspective, the level of guidance given by this framework for this thesis is evaluated as a 3 on a 1-5 scale.


This chapter answered the following sub-research question: Which frameworks are available for the security of PCS’s? The question was answered by describing the different frameworks. Our focus is on the ISA99, NIST 800-82 and NERC CIP standards because the first explorative interviews revealed that these frameworks were best-known and most used. The ISA99 standard is actually a set of standards which are still under development. The framework consists of four parts each focused on a different topic (General, Policies & Procedures, System and Component). Only a few parts of this standard are already published. For this thesis, the particular ISA-TR99.00.01-2007 document is used. The standard gives guidance for each control in the form of a general description, known vulnerabilities, typical deployment, known issues and weaknesses of the control. The standard also describes the limitations of the control implementation in practice and it describes the future direction and recommendations and finally some literature references. From a qualitative perspective, the level of guidance given by this standard for this thesis is evaluated as a 4 on a 1-5 scale.

25

The NIST 800-82 framework describes a generic overview of the PCD and gives some guidance on how to develop a PCD control framework. The framework also describes the PCD controls as defined in the NIST 800-53. The framework gives guidance in the form of a description of the control and practical examples, there is no more extensive predefined structure of topics (which is available in the ISA99). From a qualitative perspective, the level of guidance given by this framework for this thesis is evaluated as a 3 on a 1-5 scale. The NERC CIP standard is made compulsory for all entities responsible for the reliability of the Bulk Electric Systems in North America. The controls are described in different sections. Starting with the Applicability of the control, the Requirements to which the company should comply to, Measurement rules on how the company should keep documentation, Compliance rules and Regional variances. From a qualitative perspective, the level of guidance given by this framework for this thesis is evaluated as a 3 on a 1-5 scale. The main difference in these standards is the way the NERC CIP describes the control, this is stricter with less flexibility in the guidance compared to the ISA99 and NIST 800-82 frameworks. Also the purpose of the frameworks is different: The ISA99 provides hands-on information about the availability of security technologies, tools and countermeasures and also what is missing and needs more research. The purpose of the NIST 800-82 is to provide an overview of PCS and typical system topologies, identify typical threats and vulnerabilities to these systems, and to provide recommended security countermeasures to mitigate the associated risks. The NERC CIP purpose is to coordinate all NERC‟s efforts to improve physical and cyber security for the bulk power system of North America.

26

4 PCD Frameworks compared As described in chapter 3, during the first explorative meetings many PCD control frameworks were identified but only a limited number of frameworks are widely spread used by organizations. Three frameworks were most known, as mentioned by the interviewees:

- ISA99 (ANSI/ISA-TR99.00.0X-2007) - NIST 800-82 - NERC CIP standard

Therefore the comparison in this chapter focuses on these three PCD control frameworks. It is also interesting to see how the PCD frameworks relate to the well known and office IT default security framework ISO 27001. This is especially interesting because it is often suggested that the security in the PCD is less developed than in the Office IT domain. See for example the recent article “Procesbesturing: onbewust onveilig” (Luiijf, March 2012). This chapter answers the sub-research question: What are the differences between the frameworks?

4.1 Overview of controls

As a starting point, the ISA99 standard has been selected as the index for the comparison. The motivation for that is that the ISA99 standard is the most explicit in describing the guidance categories and controls. Next step was to add the NIST800-82 framework to the overview, the related controls were mapped and controls which were not mentioned in the ISA99 standard were added to the list. Next the NERC CIP standard was added; we have mapped these standards controls to the ISA 99 and NIST800-82 standards. Controls which could not be mapped were added into the table in the appropriate category. For reference purposes, we also matched the ISO27001 standard but we did not add the controls which were not covered by the other frameworks. The reason for that is that the controls in the ISO 27001 standard cover a much broader area of information security, many of which have no relation with process control systems. A specific example is change management. In the office IT domain, this is one of the most important control areas, but in the PCD it is of less importance because the software is immediately written for the specific hardware. A change to that software is not very likely. It is mentioned that implementing changes is the most vulnerable activity in the PCD area and should be avoided as much as possible. Activities such as maintenance and patch management are of course also applicable in the PCD and also covered in the comparison. The controls were not always defined on exactly the same level. For example, a single control could exist in one framework, but exist as two separate controls in another framework. This resulted in an extensive list which is presented in Appendix B. Table 4, which shows a summarized overview of the table comparing the level of control/topic category between the four frameworks. The first number represents the number of controls that the framework covers and the second number represents the number of controls identified in total from the three PCD frameworks.

27

For the first category, security program development and deployment, 6 distinctive controls have been found (see appendix A for these 6 controls). The ISA99 standard does not cover this category, thus the score in this table is written as 0/6; the NERC CIP standard addressed 1 out of the 6 controls.

Control/topics ISA99 NIST 800-82 NERC CIP ISO 27001

Security Program Development and Deployment

0/6 6/6 1/6 2/6

Authentication and Authorization technologies

9/9 5/9 4/9 2/9

Filtering/Blocking/Access Control Technologies

3/3 3/3 0/3 3/3

Communication, Encryption Technologies and Data Validation

3/5 5/5 3/5 5/5

Management, Audit, Measurement, Monitoring, and Detection Tools

7/14 9/14 10/14 7/14

Industrial Automation and Control Systems Computer Software

3/3 1/3 1/3 1/3

Physical Security Controls

2/2 2/2 2/2 2/2

Table 4- Controls comparison summarized overview

When summing the number of controls covered by the frameworks, we can conclude that the frameworks are roughly balanced and that not a single framework consists of more topics than the others. An exception is for ISA99 for the first category. The explanation for this is that this is covered in another part of the framework, to be more specific in the ISA99.00.02 part which is not taken into account for this comparison. Another exception is for the NERC CIP that does not cover the filtering/blocking access control technologies. The reason for this may be that the control description in the NERC CIP is often on a higher level and only in the explanatory notes (which were not covered as controls in the comparison) more details are given in the form of examples or questions. The categories of controls which the frameworks cover is not the same, however a distinction that one framework covers the technical controls more than another framework could not be made. What is visible is that the Physical Security Controls are covered by all three frameworks.

28


This “PCD Frameworks compared” chapter explained the differences between the frameworks and gives answer to the sub-research question: What are the differences between the frameworks? For a number of controls, the frameworks described almost the same controls; however, some other differences were noted. The ISA99 does not describe controls regarding a management system for the controls. A second difference is that the NERC CIP does not cover the filtering/blocking access control technologies.

29

5 Use of the PCD frameworks and lessons learned The interview findings will be presented in this chapter. A total of three extended (or in-depth) interviews were conducted for the purpose of this study: The first interview was held with the Global Group IT Security Officer at a large

international energy company. The second interview was held with a professional PCD researcher at a large research

company in The Netherlands. The third interview was held with a security expert at a large international oil and gas

company. On request of the interviewees, all information obtained during the interviews is processed and noted anonymously, to maintain the confidentiality of the sources. At the end of this chapter, the answers to the following sub-research questions are presented: How do companies make use of these frameworks to secure PCS’s? and What are the lessons learned regarding these frameworks?

5.1 Frameworks used as good practice

The first important finding of the interviews is that the PCD specific frameworks are known and used. However, the frameworks were not implemented as is, rather, these frameworks were used in terms of good practice. In one organization, a dedicated new PCD security framework was created. The interviewee indicated that the source of this framework were the PCD-specific frameworks; the ISA99 and NIST 800-82. Another interview showed that a generic Information Security framework was created based on ISO27001. All systems within the organization should comply with this information security framework. This framework was applicable for the Office IT systems and also the PCD systems. For the PCD systems, an add-on framework was added to the generic Information Security framework. This add-on framework is a company-specific framework that is composed of controls as described in the ISA99, NIST 800-82 (and 800-53 for the details) and VGB R175e framework. This last framework is developed in Germany. One of the organizations defined the controls per criticality of the application: for very critical systems (often PCD systems) more severe security controls were needed than for less critical systems. This is further explained in the chapter 5.3 Tier model. Furthermore, the controls mentioned in the frameworks were always adjusted to organizations‟ specific needs, or policies, to avoid too restrictive rules. A practical example that is given was that many standards prescribe that a password should have a minimum length of 8 characters. Yet, an interviewee stated that a password should have a sufficient minimum length, while it was up to the designer of the system/application owner to motivate what the minimum should be. Likewise, as described in the previous chapter, in case of emergencies PCD systems should be accessible at a moment‟s notice. In that case, other rules apply in comparison to an outgoing payment application, which has stricter rules.

30

Figure 11- Example of a six-tier model

In addition, one of the interviewees indicated that in general, a security officer lacks detailed knowledge of all the different systems within the organization to be able to prescribe a certain level of detail to the systems.

5.2 Use of ISO27001

During the interviews, a remarkable finding was that the PCD specific frameworks are initially composed of controls in the ISO27001. Moreover, as noted in the previous subchapter, one interviewee indicated that the PCD systems should also comply with the (organization specific made) ISO27001 controls. This shows that the ISO27001 is still by default the major overall security framework for all systems, including the process control systems. The PCD frameworks are used for additional PCD controls compared to the ISO27001.

5.3 Tier model

One of the interviewees showed the PCD control framework of that organization, which includes a tier model. The difference with the classification in the NERC CIP standard is that the NERC CIP is referring to a control and the applicability of that control to a complete industry (e.g. nuclear plants). The interviewees‟ organization used the tier model to refer to a system category (or zone as called in that framework). The organization of the interviewee has a list of all PCD IT Assets and classified these into six tiers/zones (The Vattenfall group uses a similar model which is showed in Figure 11, (Zerbst, Hjelmvik, & Rinta-Jouppi, 2009)). For all of the controls within their PCD framework it is determined to which tiers/zones this control is applicable. For example, the organization has a control in place about connections to the internet. In their case, from a zone 5, a system is allowed to have a connection to the internet and a zone 2 system is not allowed to have a direct internet connection. However, a zone 2 system is allowed to have a connection to a secured system in zone 3 only. When using the secured internal route via a zone 3 and then a zone 5 systems (the proxy server), a zone 2 systems could have access to the information retrieved from the internet in a secure way. Suppliers often make use of this kind of connection but have to identify themselves on each zone within the network. In this case, the zone 3 is used as gate and DMZ zone for the PCD systems which are usually identified in the zones 1, 2 and 3. Office IT systems, including proxy servers to the Internet, are normally located in zones 4, 5 and 6.

31

5.4 Management system of the frameworks

One of the interviewee also indicated that the management process for implementation and maintenance is very important, and should be part of the framework itself. In itself, this is insufficient for the prescription of the controls, without having a management process in place for the plan-do-check-act cycle. The ISO 27001 standard is a part of a series of security standards, sometimes referred to as the ISO 2700x series. The complete series do not only define the detailed controls, but also include guidelines for a management system for Information Security process, called Information Security Management System (ISMS). Specifically, the NERC CIP framework merely describes the controls. The ISA99 framework describes the controls, while the ISMS is described in another part of the ISA99 framework (called the ANSI/ISA-99.02.01-2009). The NIST 800-82 framework itself also does not describe the ISMS, as this is covered in other frameworks of the NIST. With all the related publications NIST created a complete Security Life Cycle consisting of the NIST 800-37, NIST 800-53, NIST 800-53A, NIST800-60 and NIST 800-82 special publications. For the interviewee the different descriptions of ISMS‟s were a good reason to promote the ISO2700x as the core information security framework, and to have additions from the PCD frameworks on specific topics.


This chapter answered the following research questions: How do companies make use of these frameworks to secure PCS’s? and What are the lessons learned regarding these frameworks? This chapter primarily focused on the results of the expert interviews. Outcomes are that the PCD frameworks are used, however, in terms of good practice in order to create a more complete and suitable PCD framework for the organizations. The use of the ISO27001 is also remarkable, as this framework covers most of controls of the PCD frameworks. However the ISO27001 describes controls on a different level than the PCD frameworks do. The use of the tier model is also discussed, which enables organizations to make certain systems more secure than other systems, therefore, enabling organizations to work towards more efficient information security.

32

6 Summary The final chapter of this thesis presents the conclusion that answers the main research question of this study. Finally, a reflection upon the research, a discussion of the results, and suggestions for further research are offered.

6.1 Conclusion

For this study, the following main research question was defined: Which frameworks are available for the security of PCS’s and how do companies experience these frameworks in practice?

Many frameworks are available for the security of PCS‟s, for this research, we did a scan among various sources and we already identified 9 different commonly referred to PCD frameworks. The most known and widely used framework that we also applied in this study to determine the experiences in practice, are the ISA99, NIST 800-82 and the NERC CIP. To determine how organizations are using the PCD frameworks in practice, we first compared the frameworks in order to understand the choices of organizations for a certain framework. The comparison led to an overview which, shows that the three PCD frameworks cover a similar number of controls. However, the comparison also showed two differences; the ISA99 does not describe controls regarding a management system for the controls. This ISA99 standard is still under development, and this will be added later to a related document within the standard. Another difference is that the NERC CIP does not cover the filtering/blocking access control technologies. A reason for this may be that the control description in the NERC CIP is often on a higher level. During the interviews, these differences were confirmed, but were not classified as having a positive or negative effect on the framework when missing one of the set of controls. The practical use of frameworks became clear in the interviews that were conducted. The PCD frameworks are mainly used as good practice. According to the interviewees this is not a positive development as the use as good practice implicates that the frameworks are not mature enough to use them as leading practice. Currently, as leading practice, the interviewees make use of the “classic” ISO 27001, which is a negative development as well, because of the different angle the standard should be used. ISO 27001 is used for information security, instead of the PCD framework which focuses on infrastructure/process security. Currently, the organizations of the interviewees alternatively select a set of controls from the ISO 27001 and use PCD specific controls as an add-on to the information security framework.

33

In support of the conclusion of the main research questions, the following sub-research questions were answered;

1. What is the PCD?

The PCD is a combination of different real-time industrial process systems also known

as SCADA systems. The PCD consists of different connected components which all

have their own specific task in the process. The infrastructure of a PCD is often very

complex (a PCD could consist of thousands of units) and often consists of old legacy

systems. As a result, the PCD is difficult to control and the systems also demand high

availability.

2. Which frameworks are available for the security of PCS’s? Many security frameworks for PCS‟s could be identified. During the explorative interviews, the interviewees mentioned the ISA99, NIST 800-82 and NERC CIP as most known and widely used, therefore, we limited the scope in this thesis to these specific frameworks.

3. What are the differences between the frameworks? Differences in the three PCD frameworks, which were selected for this study, were identified in the form of guidance. However, no clear signs were found that one is better than the other. Differences were also found in the controls of the selected frameworks. However, the control comparison has shown that the PCD frameworks cover about the same amount of controls, and also a special focus on some topics by the PCD frameworks that are not shown in the comparison overview.

4. How do companies make use of these frameworks to secure PCS’s? As first, organizations make use of the PCD frameworks, but they are used as a good practice (instead of a leading practice) to create a complete/suitable PCD framework in combination with the ISO 27001 framework for the organizations. In addition, the use of a tier model is one of the solutions that one of the interviewed organizations had added to their PCD frameworks to match controls to the level of criticality of the PCS.

5. What are the lessons learned regarding these frameworks? The lessons learned are that PCD frameworks are used within organizations but as input for extra controls above the security controls from the ISO 27001, which is negative for the PCD frameworks. The interviewees also have mentioned that the PCD frameworks are not used as is, rather their organizations customized the controls (in description as in form and example controls) in order to fit the organizational use of the PCD.

34

6.2 Reflection and discussion

This chapter reflects my personal opinion on the process of writing this thesis; I will also discuss the subject related results of the thesis.

6.2.1 Research reflection

When having thoughts about the subject of the thesis, it became clear at an early stage to do research on a topic in the PCD but on which topic exactly was not directly clear. As the topic is relatively new and, there was hardly any prior research available, a lot of topics were hard to research in the short time I had. After three failed research plans, the plan for this research was accepted. Next time, I should try to make the topic more realistic to perform. What I did well was to set a clear scope and also defining the boundaries at an early stage in this research. When I started with the actual research, the most difficult part of the literature research was to find the right literature that could help me elaborate more on the research questions. It was also a challenge to arrange meetings with companies for the interviews. I made a lot of phone calls and after a few weeks of talking to voicemails, leaving messages, etc. I managed to have enough interview partners. The last challenge was to combine all information gathered in this thesis, which was good enough for submission. It took a lot of evenings and it wasn‟t fun all time but I managed it!

6.2.2 Result discussion

When looking back at the results of the thesis, one of the things that surprised me is that that many companies are still using the ISO 27001 as leading practice for their PCS as well, while the ISO 27001 is explicitly created for information security instead of infrastructure/process security. What also astonished me was that there are that many different frameworks that I identified in the relatively short time of this study. The industry should consider creating one leading practice (which also eliminates the use of the ISO 27001) instead of the many different frameworks. The last thing that surprised me (not completely related to the research topic) was what action was taken on PCD incidents. For example; the incident that happened at the water pump station in Veere. The password was that easy (it was just “veere”) so anyone could have access to these pumps. Upon discovering that, a letter was sent to the authorities regarding the safety related issues. It was simply replied to that it would be investigated and that the safety was not in danger. That was all we heard about that incident in the media. We expected that an audit would be announced on similar systems but this was not the case. This shows that the PCS security does not have a high priority (yet) and the possible danger is not recognized enough by the regulators.

35

6.3 Further research

During this study, a number of topics were identified during the interviews that could be used for future research, three of these topics are discussed below:

6.3.1 Tier models & the applicability

In this study, a small paragraph was dedicated to tier models that are used at one of the organizations interviewed for this study. The question that came up after the interviews to which an answer could not be found (yet) is, if these models could contribute to a more secure PCD domain, and could provide cost savings, due to the fact that not all controls would need to be implemented and audited.

6.3.2 Who is responsible for the security of PCS’s

Given the way in which controls are described, the question was raised who is responsible for the security of the PCD? As an interview showed that the strictness of controls which were described is low, and that the security specialist should decide what the actual control should be. The relevant question here is who is the security specialist? Is this an engineer directly working with the systems and could assess the risks of it probably the best or an IT security specialist who knows everything about security.

6.3.3 Self assessment tools

During one of the interviews, the discussion reached the topic of audit and how these are/should be performed. One of the things mentioned that some self-assessment tools are available for download (some even for free). Further research is needed to identify these self-assessments tools, specifically design for the PCD domain and if the results of a self- assessments can be used in practice, as support to an audit.

36

APPENDIX A – Bibliography The following literature is used in this thesis:

CERT Historical Statistics. (2009, 02 12). Retrieved 04 02, 2012, from http://www.cert.org/stats/

Culter, T., & Barber, A. (2001). Gasoline Pipeline Rupture and Explosion at Whatcom Creek: A Focus on Response Management.

Daneels, A., & Salter, W. (1999). What is SCADA? International Conference on Accelerator and Large Experimental Physics Control Systems, (p. 5). Trieste, Italy.

Duggan, D. P. (2005). Penetration Testing of Industrial Control Systems. Sandia Report .

Ernst & Young. (2012). Insights on IT risk - Bringing IT into the fold.

Evans, R. P. (2009). Control Systems Cyber Security Standards Support Activities.

Fenrich, K. (2007). Securing Your Control System.

Glantz, C., Bass, R., Cash, J., Coles, G., Gower, D., Heilman, J., et al. (2005). An Examination of Cyber Security at Several U.S. Nuclear Power Plants.

Google Images. (2012). Retrieved from http://www.google.com/images/

Igure, V. M., Laughter, S. A., & Williams, R. D. (2006). Security issues in SCADA networks. Charlottesville: University of Virginia.

International Society of Automation. (2007). ANI/ISA-TR99.00.01-2007. ISA.

Landau, S. (2008). Security and Privacy Landscape in Emerging Technologies. IEEE Security & Privacy , 74-77.

Lipson, H. F. (2002). Tracking and Tracing Cyber-Attacks: Technical Challenges and Global Policy Issues.

Luiijf, E. (March 2012). Procesbesturing: onbewust onveilig. Beveiliging Managementblad .

Matrosov, e. a. (2011). Stuxnet under the microscope.

Moteff, J., & Parfomak, P. (2004). Critical Infrastructure and Key Assets: Definition and Identification.

37

NERC CIP Standard. (n.d.). CIP Standard. Retrieved March 12, 2012, from North American Electric Reliability Coorporation: http://www.nerc.com/page.php?cid=2%7C20

NIST Special Publication 800-53. (2009). NIST 800-53; Recommended Security Controls for Federal Information Systems and Organizations. NIST.

NIST Special Publication 800-82. (2008). NIST 800-82; Guide to Industrial Control Systems (ICS) Security. NIST.

Number of Security Incidents Continues to Increase. (2010, 04 29). Retrieved 04 02, 2012, from ControlDesign.com: http://www.controldesign.com/industrynews/2010/023.html

Opstelten, I. (2012). Brief - Beveiliging van SCADA-systemen.

Peerlkamp, S. F., & Nieuwenhuis, M. B. (2010). Process Control Network Security. VU Thesis.

Poulsen, K. (2003, 08 19). Slammer worm crashed Ohio nuke plant network. Retrieved May 26, 2011, from SecurityFocus.com: http://www.securityfocus.com/news/6767

Simonsson, M., & Hultgren, E. (2005). Administrative systems and operation support systems – A comparison of IT governance maturity. Sweden: Colloquium SC D2.

US-CERT. (2011). Recommended Practice: Improving Industrial Control Systems Cybersecurity with Defense-In-Depth Strategies.

Weiss, J. (2010). Protecting Industrial Control Systems from Electronic Threats. Momentum Press.

Zerbst, J.-T., Hjelmvik, E., & Rinta-Jouppi, I. (2009). Zoning principles in electricity distribution and energy producten environments. 20th International Conference on Electricity Distribution. Prague.

38

APPENDIX B – Framework comparison This table shows a mapping of the ISA99, NIST 800-82 and NERC CIP frameworks. In addition, controls which were mentioned in the ISO 27001 are mentioned next to this for reference purposes.

Control ISA99 NIST 800-82 NERC CIP ISO 27001

Security Program

Development and

Deployment

Security Assessment

and Authorization

6.1.1 Security

Assessment and

Authorization

Planning 6.1.2 Planning

Risk Assessment

6.1.3 Risk

assessment

System and service

acquisition

6.1.4 System and

service

acquisition

Program management

6.1.5 Program

management

A6.1 Internal

organization

Awareness and

training

6.2.9 Awareness

and training

CIP-004-3, CIP-

004-4

Personnel and

training

A8.2.1 IS

awareness,

education and

training

Authentication and

Authorization

technologies

Role-Based

Authorization Tools

5.1 Role-Based

Authorization Tools

6.3.2.1 Role-

based access

control

A11.2.2 Privilege

management

Password

Authentication

5.2 Password

Authentication

6.3.1.1 Password

authentication

CIP 007-3 –

System security

management

A11.2.3 User

password

management

Challenge/Response

Authentication

5.3

Challenge/Response

Authentication

6.3.1.2.

Challenge/respon

se authentication

Physical/Token

Authentication

5.4 Physical/Token

Authentication

6.3.1.3 Physical

Token

authentication

Smart Card

Authentication

5.5 Smart Card

Authentication

CIP-006-3c –

Physical

security

39


Biometric

Authentication

5.6 Biometric

Authentication

6.3.1.4 Biometric

authentication

CIP-006-3c –

Physical

security

Location-Based

Authentication

5.7 Location-Based

Authentication

Password Distribution

and Management

Technologies

5.8 Password

Distribution and

Management

Technologies

CIP 007-3 –

System security

management

Device-to-Device

Authentication

5.9 Device-to-Device

Authentication

Filtering/Blocking/Ac

cess Control

Technologies

Network Firewalls

6.1 Network Firewalls 5.1 Firewalls A11.4.6 Network

connection control

A11.4.7 Network

routing control

Host-based Firewalls

6.2 Host-based

Firewalls

5.3 Network

Segregation

A11.4.6 Network

connection control

A11.4.7 Network

routing control

Virtual Networks

6.3 Virtual Networks 5.2 Logically

separated control

network

6.3.2.3 Virtual

local area

network

A11.4.5

Segregation in

networks

Communication,

Encryption

Technologies and

Data Validation

Symmetric (Secret)

Key Encryption

7.1 Symmetric (Secret)

Key Encryption

6.3.4.1

Encryption

A12.3

Cryptographic

controls

Public Key Encryption

and Key Distribution

7.2 Public Key

Encryption and Key

Distribution

6.3.4.1

Encryption

A12.3

Cryptographic

controls

Virtual Private

Networks (VPNs)

7.3 Virtual Private

Networks (VPNs)

6.3.4.2 Virtual

private network

CIP-005-03 –

Electronic

security

perimeters

A10.6 Network

security

management

40


Dial-up modems 6.3.2.4 Dial-up

modems

CIP-005-03 –

Electronic

security

perimeters

A11.7 Mobile

computing and

teleworking

Wireless 6.3.2.5 Wireless CIP-005-03 –

Electronic

security

perimeters

A11.7 Mobile

computing and

teleworking

Management, Audit,

Measurement,

Monitoring, and

Detection Tools

Log Auditing Utilities

8.1 Log Auditing

Utilities

CIP-005-03 –

Electronic

security

perimeters

A10.10.1 Audit

logging

Virus and Malicious

Code Detection

Systems

8.2 Virus and Malicious

Code Detection

Systems

6.2.6.1 Malicious

code detection

CIP 007-3 –

System security

management

A10.4.1 Controls

against malicious

code

Intrusion Detection

Systems

8.3 Intrusion Detection

Systems

6.2.6.2 Intruder

detection and

prevention

CIP-006-3c –

Physical

security

CIP007-3 -

System Security

Incident response

6.2.8 Incident

response

CIP 008-03

Incident

reporting and

Response

planning

13.1.1 Reporting

information

security events

Vulnerability Scanners

8.4 Vulnerability

Scanners

CIP-005-03 –

Electronic

security

perimeters

CIP007-3 -

Systems

Security

A12.6 Technical

vulnerability

management

Forensics and Analysis

Tools (FAT)

8.5 Forensics and

Analysis Tools (FAT)

Host Configuration

Management Tools

8.6 Host Configuration

Management Tools

Automated Software

Management Tools

8.7 Automated

Software Management

Tools

41


Contingency Planning

6.2.3

Contingency

Planning

CIP 009-03 –

Recovery plans

for critical cyber

assets

A14 Business

continuity planning

Configuration

management

6.2.4

Configuration

management

CIP 003-04

Security

Management

Controls

Maintenance

6.2.5

Maintenance

CIP 003-04

Security

Management

Controls

Patch management

6.2.6.3 Patch

management

CIP 007-3 –

System security

management

Media protection

6.2.7 Media

protection

CIP 007-3 –

System security

management

A10.7 Media

Handling

Audit and

accountability

6.3.3 Audit and

accountability

A15.3 Information

systems audit

considerations

Industrial Automation

and Control Systems

Computer Software

Server and

Workstation Operating

Systems

9.1 Server and

Workstation Operating

Systems

CIP 007-3 –

System security

management

A11.5 Operating

system access

control

Real-time and

Embedded Operating

Systems

9.2 Real-time and

Embedded Operating

Systems

Web Technologies

9.3 Web Technologies 6.3.2.2 Web

servers

Physical Security

Controls

Physical Protection

10.1 Physical

Protection

6.2.2 Physical

and

environmental

protection

CIP-006-3c –

Physical

security

A9.1 Secure areas

Personnel Security

10.2 Personnel

Security

6.2.1 Personnel

security

CIP-004-3, CIP-

004-4

Personnel and

training

A8.1.2 Screening

42

APPENDIX C – Unique characteristics of the Office IT versus PCD This table describes the unique characteristics of the Office IT domain and what the relevance of that topic is within the PCD domain. Unique characteristics of ICS devices that increase the challenge in securing the environment

Security topic Office IT PCD

Antivirus and mobile code Very common; easily deployed

and updated

Can be very difficult due to

impact on PCD; legacy systems

cannot be fixed

Patch management Easily defined, enterprise-wide

remote and automated

Very long runway to successful

patch install; OEM-specific, may

impact performance

Technology support lifetime

(outsourcing)

2-3 years, multiple vendors;

ubiquitous upgrades

10-30 years, same vendors

Cyber security testing and audit

(methods)

Use modern methods Testing has to be tuned to

system; modern methods

inappropriate for ICS; fragile

equipment breaks

Change management Regular and scheduled; aligned

with minimum-use periods

Strategic scheduling; nontrivial

process due to impact

Asset classification Common practice and done

annually; results drive cyber

security expenditure

Only performed when obligated,

critical asset protection

associated with budget costs

Incident response and forensics Easily developed and deployed,

some regulatory requirements,

embedded in technology

Uncommon beyond system

resumption activities; no

forensics beyond event re-

creation

Physical and environment

security

Easily developed and deployed,

some regulatory requirements,

embedded in technology)

Excellent (operations centers,

guards, gates, guns)

Secure systems development Integral part of development

process

Usually not an integral part of

systems development

Security compliance Limited regulatory oversight Specific regulatory guidance

(some sectors)

43

APPENDIX D – Interview questions

Research on the use of PCD frameworks and the lessons learned of those frameworks Overview of questions for the research with <EXPERT> of <ORGANIZATION> When we are discussing the PCD (acronym of SCADA), we are discussing: A collection of process control systems that are used in myriad applications, including manufacturing, communications, distribution (water, gas, power) and heating, cooling and security in buildings. PCD systems collect data from sensors in local and remote locations and send them to central computers to control local machinery. Goal of this interview is to discuss the way how PCD frameworks are used and what according to the business the lessons learned were of these frameworks. The results of this interview will be used, together with the interview at other organizations, in qualitative analyses. This analysis is a (part of the) result of the thesis of the postgraduate study program on EDP auditing at VU University Amsterdam. As a token of appreciation for the willing to cooperate in an interview, a copy of the final thesis will be send to the interviewee. All information gathered from the interview will be treated confidentially and in the thesis will be working with the data anonymously. This interview is 'open' in nature. Which means, that the subjects are fixed but the questions are not, the questions are only indicative. Subject 1; Information about the interviewee and the company:

1. Could you describe shortly on your (professional) background?

2. Could you describe on how your organization makes use of the PCD and how dependent the organization is of the PCD?

Subject 2; Information about the PCD framework of the organization (or organization related frameworks):

1. Within your organization, do you make use of a specific PCD framework?

2. What is this framework based on? a. A generic PCD framework (like ISA99, NIST 800-82, NERC CIP) or b. A generic Office IT framework (like ISO27001, CobiT, etc.) or c. Something else?

3. How do you use this framework?

a. As a good practice b. For regulation/legislation purposes

44

4. Do you have experience with generic frameworks like ISA99, NIST 800-82 or NERC CIP?

Subject 3; Comparison of the PCD frameworks:

1. I created a comparison between the PCD frameworks ISA99, NIST800-82 and NERC CIP. Are there any components which stand-out?

2. Are there any components of which is know which are not (or almost not) relevant for controlling the PCD systems?

3. Are any components missing? Subject 4; PCD General:

1. Are there any topics in the PCD of which you think they still are underexposed?

Thesis Process Control Frameworks - VUrORE · which showed that the number of controls covered by...

Documents

Transcript of Thesis Process Control Frameworks - VUrORE · which showed that the number of controls covered by...