Thesis:

Process Control Frameworks

Which frameworks are available for PCS’s
and how do companies use these frameworks

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

1
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.

2
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

3
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

4
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

5
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:

6
 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.

Research Literature Framework Result

Conclusion
questions review analysis analysis

Interviews

Figure 1- Research approach

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.

7
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.

8
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 Figure 2- Example of sensors
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

9
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 Figure 3- Example of PLCs
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
Figure 4- Example of a HMI
switch off the power on those railway sections to prevent an
accident.

10
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 Figure 5- Example of a RTU
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 Figure 6- Example of a MTU
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.

11
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.

Railway control room to show

HMI MTU
the operators information
they can respond to

Located at the station to

HMI communicate the train
RTU RTU
locations to the control room

Receive information that a

train has left a certain rail
PLC PLC PLC
section and ensure that the
signal turns green

Sensor Sensor Sensor Sensor Sensor Sensor Sensor

Sensor to detect the
location of a train

Figure 7- Components of the PCD composition

12
 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.

Business Business
Internet Internet

Office IT PCD Office IT PCD

Figure 8 - Integration trend

13
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).

14
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).

15
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

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

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).

16
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 North America Three fatalities, total property damage
control systems not able to perform control > US$45m
and monitoring functions (Whatcom Creek)
Sewage spill caused by wireless hacking of Australia > 1m liters of sewage spilled
sewage discharge valves
Substation communication failure from North America SCADA failed, resulting in loss of
Slammer work traffic 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 Europe Loss of communication to almost half
unpatched Cisco router by worm 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 North America Remote destruction of a large diesel
Laboratory demonstrated a large diesel generator
generator malfunctioning due to a remote
attack
Control system workstation failures caused North America Slowdown or shutdown of all power
by IT penetration testing 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 Iran Damage to the controllers handling the
systems resulting in significant setbacks to centrifuges at Iran‟s Natanz facilities
the Iran nuclear program
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.

17
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.

18
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

19
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.

20
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.

21
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

3.2.1 About the framework

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.

3.2.2 Purpose of the framework

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

22
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.

3.2.3 Guidance within the framework

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

3.3.1 About the framework

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.

23
3.3.2 Purpose of the framework
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.

3.3.3 Guidance within the framework

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.

3.4 Recap of this chapter

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.

24
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.

25
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.

26
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 0/6 6/6 1/6 2/6
Development and
Deployment
Authentication and 9/9 5/9 4/9 2/9
Authorization
technologies
Filtering/Blocking/Access 3/3 3/3 0/3 3/3
Control Technologies
Communication, 3/5 5/5 3/5 5/5
Encryption Technologies
and Data Validation
Management, Audit, 7/14 9/14 10/14 7/14
Measurement,
Monitoring, and
Detection Tools
Industrial Automation 3/3 1/3 1/3 1/3
and Control Systems
Computer Software
Physical Security 2/2 2/2 2/2 2/2
Controls
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.

27
4.2 Recap of this chapter
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.

28
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.

29
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.

Figure 11- Example of a six-tier model

30
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.

5.5 Recap of this chapter

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.

31
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.

32
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.

33
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.

34
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.

35
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.

36
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.

37
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
6.1.1 Security
Security Assessment Assessment and
and Authorization Authorization
Planning 6.1.2 Planning
6.1.3 Risk
Risk Assessment assessment
6.1.4 System and
System and service service
acquisition acquisition
6.1.5 Program A6.1 Internal
Program management management organization
6.2.9 Awareness CIP-004-3, CIP- A8.2.1 IS
and training 004-4 awareness,
Awareness and Personnel and education and
training training training

Authentication and
Authorization
technologies
5.1 Role-Based 6.3.2.1 Role- A11.2.2 Privilege
Role-Based Authorization Tools based access management
Authorization Tools control
5.2 Password 6.3.1.1 Password CIP 007-3 – A11.2.3 User
Password Authentication authentication System security password
Authentication management management
5.3 6.3.1.2.
Challenge/Response Challenge/Response Challenge/respon
Authentication Authentication se authentication
5.4 Physical/Token 6.3.1.3 Physical
Physical/Token Authentication Token
Authentication authentication
5.5 Smart Card CIP-006-3c –
Smart Card Authentication Physical
Authentication security

38
Control ISA99 NIST 800-82 NERC CIP ISO 27001
5.6 Biometric 6.3.1.4 Biometric CIP-006-3c –
Biometric Authentication authentication Physical
Authentication security
Location-Based 5.7 Location-Based
Authentication Authentication
5.8 Password CIP 007-3 –
Password Distribution Distribution and System security
and Management Management management
Technologies Technologies
Device-to-Device 5.9 Device-to-Device
Authentication Authentication

Filtering/Blocking/Ac
cess Control
Technologies
6.1 Network Firewalls 5.1 Firewalls A11.4.6 Network
connection control
A11.4.7 Network
Network Firewalls routing control
6.2 Host-based 5.3 Network A11.4.6 Network
Firewalls Segregation connection control
A11.4.7 Network
Host-based Firewalls routing control
6.3 Virtual Networks 5.2 Logically A11.4.5
separated control Segregation in
network networks
6.3.2.3 Virtual
local area
Virtual Networks network

Communication,
Encryption
Technologies and
Data Validation
7.1 Symmetric (Secret) 6.3.4.1 A12.3
Symmetric (Secret) Key Encryption Encryption Cryptographic
Key Encryption controls
Public Key Encryption 7.2 Public Key 6.3.4.1 A12.3
and Key Distribution Encryption and Key Encryption Cryptographic
Distribution controls
Virtual Private 7.3 Virtual Private 6.3.4.2 Virtual CIP-005-03 – A10.6 Network
Networks (VPNs) Networks (VPNs) private network Electronic security
security management
perimeters

39
Control ISA99 NIST 800-82 NERC CIP ISO 27001
Dial-up modems 6.3.2.4 Dial-up CIP-005-03 – A11.7 Mobile
modems Electronic computing and
security teleworking
perimeters
Wireless 6.3.2.5 Wireless CIP-005-03 – A11.7 Mobile
Electronic computing and
security teleworking
perimeters

Management, Audit,
Measurement,
Monitoring, and
Detection Tools
8.1 Log Auditing CIP-005-03 – A10.10.1 Audit
Utilities Electronic logging
security
Log Auditing Utilities perimeters
Virus and Malicious 8.2 Virus and Malicious 6.2.6.1 Malicious CIP 007-3 – A10.4.1 Controls
Code Detection Code Detection code detection System security against malicious
Systems Systems management code
8.3 Intrusion Detection 6.2.6.2 Intruder CIP-006-3c –
Systems detection and Physical
prevention security
Intrusion Detection CIP007-3 -
Systems System Security
6.2.8 Incident CIP 008-03 13.1.1 Reporting
response Incident information
reporting and security events
Response
Incident response planning
8.4 Vulnerability CIP-005-03 – A12.6 Technical
Scanners Electronic vulnerability
security management
perimeters
CIP007-3 -
Systems
Vulnerability Scanners Security
Forensics and Analysis 8.5 Forensics and
Tools (FAT) Analysis Tools (FAT)
Host Configuration 8.6 Host Configuration
Management Tools Management Tools
8.7 Automated
Automated Software Software Management
Management Tools Tools

40
Control ISA99 NIST 800-82 NERC CIP ISO 27001
6.2.3 CIP 009-03 – A14 Business
Contingency Recovery plans continuity planning
Planning for critical cyber
Contingency Planning assets
6.2.4 CIP 003-04
Configuration Security
Configuration management Management
management Controls
6.2.5 CIP 003-04
Maintenance Security
Management
Maintenance Controls
6.2.6.3 Patch CIP 007-3 –
management System security
Patch management management
6.2.7 Media CIP 007-3 – A10.7 Media
protection System security Handling
Media protection management
6.3.3 Audit and A15.3 Information
Audit and accountability systems audit
accountability considerations

Industrial Automation
and Control Systems
Computer Software
Server and 9.1 Server and CIP 007-3 – A11.5 Operating
Workstation Operating Workstation Operating System security system access
Systems Systems management control
Real-time and 9.2 Real-time and
Embedded Operating Embedded Operating
Systems Systems
9.3 Web Technologies 6.3.2.2 Web
Web Technologies servers

Physical Security
Controls
10.1 Physical 6.2.2 Physical CIP-006-3c – A9.1 Secure areas
Protection and Physical
environmental security
Physical Protection protection
10.2 Personnel 6.2.1 Personnel CIP-004-3, CIP- A8.1.2 Screening
Security security 004-4
Personnel and
Personnel Security training

41
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 Can be very difficult due to
and updated impact on PCD; legacy systems
cannot be fixed

Patch management Easily defined, enterprise-wide Very long runway to successful

remote and automated patch install; OEM-specific, may
impact performance

Technology support lifetime 2-3 years, multiple vendors; 10-30 years, same vendors
(outsourcing) ubiquitous upgrades

Cyber security testing and audit Use modern methods Testing has to be tuned to
(methods) system; modern methods
inappropriate for ICS; fragile
equipment breaks

Change management Regular and scheduled; aligned Strategic scheduling; nontrivial

with minimum-use periods process due to impact

Asset classification Common practice and done Only performed when obligated,
annually; results drive cyber critical asset protection
security expenditure associated with budget costs

Incident response and forensics Easily developed and deployed, Uncommon beyond system
some regulatory requirements, resumption activities; no
embedded in technology forensics beyond event re-
creation

Physical and environment Easily developed and deployed, Excellent (operations centers,
security some regulatory requirements, guards, gates, guns)
embedded in technology)

Secure systems development Integral part of development Usually not an integral part of
process systems development

Security compliance Limited regulatory oversight Specific regulatory guidance

(some sectors)

42
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

43
 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?

44