Programmable15th

Proceedings, Devices
IFAC and Embedded
Conference on Systems
Proceedings,
Ostrava, 15th
Czech IFAC Conference
Republic, May 23-25,on
2018
Programmable
Proceedings, Devices
15th IFAC and Embedded
Conference on Systemsonline at www.sciencedirect.com
Available
Programmable
Proceedings, Devices
15th IFAC and Embedded
Conference Systems
Ostrava, Czech
Programmable Republic,
Devices May
and 23-25,on
Embedded 2018
Systems
Ostrava, Czech
Programmable Republic, May 23-25, 2018
Ostrava, Czech Devices and
Republic, Embedded
May Systems
23-25, 2018
Ostrava, Czech Republic, May 23-25, 2018 ScienceDirect
IFAC PapersOnLine 51-6 (2018) 214–219
Safety and Security Analysis of Control Chains in SCADA
Safety
Safety and Security Analysis of Control Chains in SCADA
Safety and
and Security
Using
Security
Using
Analysis
the NFR
Analysis
the NFR
of
of Control
Approach
Control
Approach
Chains
Chains in
in SCADA
SCADA
Safety and Security
Using Analysis
the NFR of Control
Approach Chains in SCADA
Using
Nary the NFR Janusz
Subramanian* Approach Zalewski**
Using the NFR
Nary Subramanian* 
Approach
Janusz Zalewski**
Nary Subramanian*
Subramanian* Janusz Janusz Zalewski**
Zalewski**

*Dept. of ComputerNary Science,
Nary University
Subramanian*  ofJanusz
Texas at Tyler, Tyler, TX 75799, USA
Zalewski**

*Dept.
*Dept. of
of Computer Science,
e-mail: University  of Texas at Tyler,
of Texas
nsubramanian@uttyler.edu at Tyler, TX 75799, USA
**Dept. *Dept. of Computer
of Software Computer Science,
Science,
Engineering, e-mail:
University
University of Texas
nsubramanian@uttyler.edu
Florida Gulf Coast at Tyler,
Tyler, Tyler,
University, Tyler,
Fort
TX
TX 75799,
Myers,75799, USA
USA USA
FL 33965,
*Dept. of Computer Science, e-mail:
e-mail: nsubramanian@uttyler.edu
University of Texas
nsubramanian@uttyler.edu at Tyler, Tyler, TX 75799, USA
**Dept.
**Dept. of
of Software
Software Engineering,
Engineering, Florida
email:
Florida Gulf Coast
zalewski@fgcu.edu
Gulf University, Fort Myers, FL 33965, USA
**Dept. of Software Engineering, email: e-mail: Gulf Coast University, Fort Myers, FL 33965, USA
Coast
nsubramanian@uttyler.edu
Floridazalewski@fgcu.edu University, Fort Myers, FL 33965, USA
**Dept. of Software Engineering, email: Floridazalewski@fgcu.edu
email: Gulf Coast University, Fort Myers, FL 33965, USA
zalewski@fgcu.edu
Abstract: The objective of this research email: zalewski@fgcu.edu
is to shed light on the applicability of the Non-Functional
Abstract:
Requirements The
The objective
(NFR)
objectiveApproach of
of this to research
the concept is toof shed
controllight on the
chains applicability
for applicability
the combinedof ofanalysis
the Non-Functional
of safety and
Abstract:
Abstract:
Requirements
security of The
SCADA objective
(NFR) Approach
systems of this
this
and,to
research
research
the
more concept
is
is to
toofshed
generally, shed
control
to
light
light on
on the
chains
computer the
for applicability
the
systems combined
used in of the
the Non-Functional
analysis
automation,Non-Functional
of safety
safety
includingand
Requirements
Abstract:
Requirements The(NFR)
objective
(NFR) Approach
Approach of thisto the
toresearch
the concept
concept is toof control
ofshed
control chains
light on the
chains for
for the
the combined
applicability
combined ofanalysis of
the Non-Functional
analysis ofpresents
safety and
and
security
functional
security of
of SCADA
safety
SCADA and systems
security and, more
standards. generally,
The paper to computer
discusses the systems
concept used
of in
controlautomation,
chains, including an
Requirements
security ofof (NFR) systems
SCADA Approach
systems and,
and,to themore
more generally,
concept
generally, to
of control computer
chains for
todiscusses
computer systems used
the combined
systems used in
in automation,
analysis of safety
automation, including
includingand
functional
overview
functional safety
the and
NFR security
Approach, standards.
and appliesThe paper
this approach to the
the concept
safety andof control
security chains,
analysis presents
of controlan
security ofsafety
functional SCADA
safety and security
and systems
security standards.
and,
standards. The
more generally,
Thethispaper
paper todiscusses
computer
discusses the concept
thesystems
concept of
used control chains,
in automation,
of security
control chains, presents
including
presents an
an
overview
chains
overview in aof
of the
case
the NFR
study
NFR Approach,
of the
Approach, automaticand
and applies
control of approach
the to
hydrocarbon the safety
tank and
pressure control analysis
system. of control
functional
overview
chains in
safety
in aaofcase
and security
the study
case NFR Approach,
of the automatic
automaticand applies
standards. appliesThethis
controlthis
paper
of the
approach
discusses
approach
the
to
to the
hydrocarbon
the safety
the concept
safety
tank
and
andof security
pressure security analysispresents
control chains,
controlanalysis
of control
system. of control
an
© 2018,
chains
overview
Keywords: IFAC
of (International
the
SCADA,study
NFR of the
Approach,
automation Federation
and
systems, of Automatic
control
applies of
this Control)
hydrocarbon
approach
cyberphysical
chains in a case study of the automatic control of the hydrocarbon tank pressure control system. Hosting
to the
systems, tankby
safety Elsevier
pressure
computerand Ltd.
security
safety, All
control rights
system.
analysis
computer reserved.
of control
security,
chains
Keywords: in a case
cybersecurity, SCADA,study
NFR of the automatic
automation
Approach, systems,
IECsystems,
61508,control of61511,
the hydrocarbon
cyberphysical
IEC systems,tank
ANSI/ISA pressuresafety,
computer
62443. controlcomputer
system. security,
Keywords: SCADA, automation cyberphysical systems, computer safety, computer security,
Keywords:
cybersecurity, NFR SCADA, automation
NFR Approach,
Approach, IEC systems,
IEC 61508,
61508, IEC cyberphysical
IEC 61511,
61511, ANSI/ISAsystems,
ANSI/ISA 62443. computer
62443. safety, computer security,
cybersecurity,
Keywords: SCADA, automation systems, cyberphysical
 systems, computer safety, computer security,
cybersecurity, NFR Approach, IEC 61508, IEC 61511, ANSI/ISA 62443.
cybersecurity, NFR Approach, IEC 61508, IEC 61511,  ANSI/ISA 62443.
1. INTRODUCTION  2. CONTROL CHAINS

1. INTRODUCTION  2. CONTROL CHAINS
Analysis of safety1. 1. INTRODUCTION
and security of SCADA systems
INTRODUCTION 2.
2. CONTROL
CONTROL CHAINS CHAINS
Analysis
(Radvanovsky of safety
and 1. INTRODUCTION
and
Brodsky, security
2016) has ofbeen SCADAusually systems
focused 2.1 Examples of Control
2. Chains CHAINS
CONTROL
Analysis
Analysis of
of safety
safety and
and security
security of
of SCADA
SCADA systems 2.1 Examples of Control Chains
(Radvanovsky
on components
(Radvanovsky and
and Brodsky,
and connections
Brodsky, 2016)
of the
2016) has
has been
system
been so that systems
usually
usually focused
we tend 2.1 Examples of Control Chains
focused
Analysis of safety and security of SCADA systems 2.1 Examples
Control chainsof Control Chainsrepresentation of the flow of
(Radvanovsky
on
to
on components
say
components
(Radvanovsky
that aand
and
and
and
Brodsky,
connections 2016)
safety-instrumented
connections
Brodsky,
of
of
2016)
has
the
the
has
been
system
component
system
been
usually
so
so
usually
that
that
focused
we
may
we tend
tend
focused
be 2.1 Examples ofare an abstract
Control Chains
on components
to say
considered that andsafety-instrumented
to aabe connections
safer than a of the system
component component so that
with nomay we tend
built-inbe Control
control
Control chains
in
chains are
automation
are an
an abstract
systems,representation
abstract representation of
with each implementation
of the flow of
to
on
to say
components
sayorthat
considered
that
to abe safety-instrumented
andsafety-instrumented
connections of the system
safer than a component
component
component so thatmay
with no
may
we tend
built-in
be
be beingControl
control a chains
in
specific are
automation an abstract
instance. systems,
For representation
with
example, each
the of the
the flow
flow
implementation
choice of vendor
of
of
safety
considered that
to wireless
be safer transmissions
than a component are less
with secure
no than
built-in control
Control in automation
chains are an systems,
abstract with each
representation implementation
of the flow of
to say
considered that a
to be safety-instrumented
safer than a component component with may
no built-in be control
being
for a
each in automation
specific
component instance.
and systems,
For
connection with
example, of each
the
a implementation
choice
control of vendor
chain, the
safety
wired
safety or
or that
transmissions.
that wireless
wireless This transmissions
approach
transmissions mayare
are beless
less secure
considered
secure than
thanan beingcontrol a specific
in instance.
automation For
systems, example,
with the
each choice of vendor
implementation
considered to be safer than a component with secure
no built-in being a specific instance. For example, the choice of vendor
safety
wired or that
transmissions.
“inventory”-based,
wired transmissions.
wireless This
since
This
transmissions
weapproach
seem tomay
approach
are be
develop
may
less categoriesthan
considered of for
an for
being
each
performance
each component
of each
component
a specific
and
and
instance.
connection
equipment
connection
For example,
of
in a control
of aa control
the control chain,
chain, embedded
choice chain,
of vendor
the
the
safety
wired or that wireless
transmissions. This transmissions
approach mayare bebelessconsidered
secure than
considered an
an for each
performance
firmware component
of each
versions, and connection
equipment
versions in aof of
controla control
chain,
different chain,
embedded
hardwarethe
“inventory”-based,
inventory that
“inventory”-based, can since
be putwe in seem
the to
safety develop
bucket categories
or security of performance
for each component of each equipment
and connection in a control chain,
of a control embedded
chain, the
wired transmissions.since
“inventory”-based, Thiswe
since we seem
approach
seem to
to develop
may
develop categories
be considered
categories of
an
of performance
firmware
components, of each
versions,
age of equipment
versions
different in aof
components,control chain,
different
and embedded
hardware
maintenance
inventory
bucket that
or those can be
in neither putof in the
these safety
two bucket
buckets. or security performance
inventory
inventory that
that can
“inventory”-based, can be
be put
since wein
putof in the
seem
thetwo safety
to develop
safety bucket
bucket or
ortosecurity
categories
security of firmware
firmware
components,
history, make
versions,
versions,
age
eachof
versions
of each equipment
versions
different
instance
in aof
ofcomponents,
a control
different
ofcontrol
different
and
chain
hardware
chain, embedded
hardware
maintenance
unique. Thus,
bucket
However,
bucket or
or those
current
those in
in neither
authors
neither of these
believe
these that
two buckets.
another
buckets. way loot at components,
firmware age
versions, of different
versions components,
of and
different maintenance
hardware
inventory
bucket or that
those can
in be
neither putof in the
these safety
two bucket
buckets. or security components,
history,
annotated make age
each
control of different
instance
chains can ofcomponents,
be a control
considered and
chain maintenance
unique.
specific Thus,
instances
However,
SCADA
bucket
However, current
orcontrol
those
current authors
insystem
neither
authors believe
exists,
of as sum
these
believe that
two
that another
of all chains
buckets.
another way
way to
of
to loot
control
loot at
at history,
components,
history, make
make each
age
eachof instance
differentof
instance of aa control
components,
control chain
andunique.
chain Thus,
maintenance
unique. Thus,
However,
SCADA current
control authors
system believe
exists, as that
sum another
of all chains way to
of loot
control at annotated
of a general
annotated control
control
control chains
chain
chains can
can be
between
be considered
a source
considered specific
and a
specific instances
destination.
instances
from
SCADA the source
control to the
system destination
exists, as of
sum each
of allchain;
chains we ofcall this
control history,
annotated make each
control instance
chains can of
be a control
considered chain unique.
specific Thus,
instances
However,
SCADA current
control authors
system believe
exists, asand that
sum another
of allchain;
chains way to loot
ofcall
control at of a general
Control control
chains chain
arechains
named, between
can a source
bea source
annotated,and a destination.
decomposed,
from
the
from the
control
the source
chain
source to
to the
for
the destination
command
destination of
of each
control.
each A we
control this
chain of a general
annotated control
control chain between
can be considered and a
specific destination.
instances
SCADA
from the control
source system
to the exists, as sum
destination of allchain;
of control.
each chainswe
chain; weofcall
call this
this of
control a general
Control
linked tochainscontrol
create are chain
named,
control between
can
workflows. bea Annotations
source
annotated,and adecomposed,
destination.
can be done
the
the control
captures
control thechain
flow
chain for
of command
for control
command and
information
and control. A
over
A control
components
control chain
chain of a general
Control control
chains are chain
named, between
can bea source
annotated,and adecomposed,
destination.
from
the the
control source
chain to the
for destination
command and of each
control. chain;
A we
control call this
chain Control
linked
by to chains
attributescreate
to are
each named,
controlelement can
workflows.
of a be annotated,
Annotations
chain or by decomposed,
can
capturingbe them
done
captures
and the
connections flow fromof control
the source information
to destination. Forover components
example, Control linked to create control workflows.
can be Annotations can
captures
the control
captures
and
the
connections
flow
thechain
flow from
of
for control
of command
control
the source
information
and control.over
information
to destination. over components
A control
components
For
chain by
example, linked
as tochains
attributes
metadata create
orto
are
each
by an
named,
control workflows.
element
accompanying of a Annotations
chain
XML or by can be
annotated, decomposed,
capturing
certificate.
done
be them
done
for
and a fluid
connections level sensor,
from the the
source control
to chain
destination. is: level
For sensor-
example, by attributes
linked to to
create each
controlelement of
workflows. a chain or
Annotationsby capturing
can be them
done
captures
and the flow of control information over components by
as attributes
metadata orto each
by an element
accompanying of a chain
XML or by capturing
certificate. them
for
for aaconnections
fluid
medium-control
fluid level
level
from
sensor,
master
sensor,
theand
source
the
the mayto even
control
control
destination.
chain
chain be is:is:
For
level
decomposed
level
example,
sensor-
sensor- as by as metadata
attributes orto by
eachan accompanying
element of a XML
chain or certificate.
by capturing them
and
for aconnections
fluid levelfrom sensor,the the
source to destination.
control chain For example, as metadata or by an accompanying XML certificate.
medium-control
level master
sensor-medium-control
medium-control and master
may even
- data busis:
be level
decomposed
- UI (Fig.sensor-
1).as as metadata or by an accompanying XML certificate.
for a fluid level master
medium-control sensor, and
master and may
the control
may even
even chain be
be decomposed
is: level sensor-
decomposed as
as
level
level sensor-medium-control
Consequently, themaster
sensor-medium-control objective master
ofmay
this even
master --research
data
data bus
bus is-- UI
to (Fig.
UI shed 1).
(Fig. light
1).
medium-control
levelthesensor-medium-control and master -researchbe
data bus decomposed
-the
UI (Fig. 1). as
Consequently,
on
Consequently, the
applicability
level sensor-medium-control
the objective
objective of
of control this
master
of this chains
-research
data bus to isis to
- UI
to shed
combined
(Fig.
shed light
1).
light
Consequently,
on the
analysis of safetytheand
applicability objective
of ofofthis
control
security research
chains
SCADA to isthe
systems to shed
combined
and, light
more
on the
Consequently,
on the of applicability
the objective
applicability of control chains
of thischains
of control research to
to isthe the combined
to shed
combinedlight
analysis
generally,
analysis safety
to and
computer security
systemsof SCADAautomation.systems and,
The more
paper
on the of
analysis of safety
applicability
safety and
and security
of control
security of
of SCADA
chains systems
SCADA to the and,
systems more
combined
and, more
generally,
describes
generally, to
the
to computer
application
computer systems
of controlautomation.
systems chains in an
automation. Theexamplepaper
analysis
generally, of safety and security
to application
computer systemsof SCADA automation.systemsThe and, paper
The more
paper
describes
Tank
describes the
Pressure
the Control
application of
System,
of control
and
control chains
evaluates
chains in
in thean
an example
safety
example and
generally,
describes to computer
thetheapplication systems
of control automation.
chains The
intheansafety paper
example
Tank
security
Tank Pressure
of
Pressure Control
control
Control System,
chains
System, and
and using evaluates
the
evaluates NFR Approach and Fig. 1. Example of a control chain for Level Sensor Display.
describes
Tank the application
Pressure Control of control
System, and chains inthe
evaluates theansafety
example
safety and
and
security
(Subramanian of the
and control
Zalewski, chains
2016). using the NFR Approach Fig.
security
Tank
security of
Pressure
(Subramanian
the
ofisthe control
Control
and control chains
System,
Zalewski, chains and
2016).
using
using the
evaluates
the NFR NFR the Approach
safety
Approach and Fig. 1.1. Example
Example of of aa control
control chain
chain for for Level
Level Sensor
Sensor Display.
Display.
The paper
(Subramanian
security of the structured
and Zalewski,
control as follows.
2016).
chains Section 2
using the NFR Approach For discusses the Fig. 1.
the Example
tank control of a control
system chain
shown for Level
in Level Sensor
Fig. 2,Sensor
one can Display.
identify
(Subramanian
The
concept paper is and Zalewski,
structured
of control chains,as 2016).
follows.
Section Section 22andiscusses
overviewthe Fig. 1. Example of a control chain for Display.
(Subramanian
The paper is and Zalewski,
structured as 2016).3 presents
follows. Section discusses of For
the For the
several
the tank
control
tank control
chains.
control system
system shown
In this
shown in
figure,
in Fig.
Fig. LS2,
2, one
stands
one can
can identify
for level
identify
The
concept
the NFRpaperof is structured
control
Approach, chains,
and as follows.
Section
Sections 3
4 Section
presents
and 5 2andiscusses
review overview
the the
safetyof For the
several
sensor, tank
Pcontrolcontrol
stands chains.
for system
pump, In shown
this
GV in
figure,
stands Fig.
for LS 2,
gas one
stands
valve, can identify
for
PS level
stands
concept
The
concept paperof control
is structured
ofApproach,
control chains,
chains, asSection
follows.33 presents
Section Section 2an
presents overview
andiscusses
overview of
the
of For several control
the tank chains.
control systemIn this
shown figure, LS2, stands
in Fig.LS one canforfor level
identify
the
and
the NFR
security
NFR requirements
Approach, and
and Sections
for control
Sections 4
4 and
chains,
and 5
5 review
including
review the
the safety
results
safety several
sensor,
for Pcontrol
pressure stands chains.
for
sensor, pump,
CP In this
GV
stands figure,
stands
for for
coolant gas stands
pump,valve,
and PST level
stands
concept
the NFR of control
Approach, chains, Section 3 presents an overview of sensor, P stands
several Pcontrol for pump,
chains. GV
InGV stands
thisstands
figure,for gas valve,
LS stands PS stands
forstands
level
and
of the security
case study ofand
requirements Sections
for
automatic control 4 and
control chains,5 review
of including
the the results
safety sensor,
hydrocarbon stands for pump, for
cangas be valve, PS
and
the
and security
NFR
security requirements
Approach,
requirements for
for control
and Sections control 4 andchains,
chains, including
5 review
including safety for
the results
results for pressure
temperature
pressure
sensor,
sensor,
sensor,
P stands
CP
CP stands
sensor.
for pump,
Thus for
stands for
GV for
coolant
there
coolant
stands for gas
pump,
pump, and
several
valve,andPST
Tcontrol
stands
of the
storage case
tank. study
This isof automatic
followed by a control
conclusion of the hydrocarbon
section. for pressure
temperature sensor, CP
sensor. stands
Thus coolant pump, and T stands
of
and the case
security study of
requirements automatic
for control control of
of the
chains, including results chains
hydrocarbon for
for the control
temperature
pressure sensor,
system
sensor.
CP standsThusin there
Fig. 2:can
there can be be several
several control
control
of the
storage
storage
case
tank.
tank.
study
This
This is
is
offollowed
automatic
followed by
by aacontrol
conclusion
conclusion
the hydrocarbon
section.
section. for
chainstemperature
for the sensor.
control systemThusinfor coolant
there
Fig. 2:can pump, and Tcontrol
be several stands
of the case study of automatic control
storage tank. This is followed by a conclusion section. of the hydrocarbon chains
for for the
temperature control system
sensor. Thus in Fig.
there 2:can be several control
chains for the control system in Fig. 2:
storage tank.
Copyright This
© 2018,
2018 is followed by a conclusion section.
IFAC 214Hosting
chains for the control
2405-8963 © IFAC (International Federation of Automatic Control) by Elsevier Ltd. system
All rightsinreserved.
Fig. 2:
Copyright
Peer review© 2018 responsibility
IFAC 214Control.
Copyright ©under
2018 IFAC of International Federation of Automatic
214
Copyright © 2018 IFAC
10.1016/j.ifacol.2018.07.156 214
Copyright © 2018 IFAC 214
 2018 IFAC PDES
Ostrava, Czech Republic, May 23-25, 2018
Nary Subramanian et al. / IFAC PapersOnLine 51-6 (2018) 214–219 215

1. C1: Level sensor communicates to the control
master: sense process level - convert sensed level to
electronic data - put data in a communication packet
- send comm packet to control master - wait for
confirmation of receipt - if received then end of
workflow - else timeout and resend comm packet.
8. C8: Control master communicates to the gas valve:
receive valve rotation signal from UI or timer -
convert rotation signal to motor rotation signal – etc.
There are three more control chains, omitted here for brevity:
9. C9: Pump receives command from master.
10. C10: Coolant pump receives command from master.
11. C11: Gas valve receives command from master.

2.2 Properties of Control Chains

Control chains may be composed (that is, sequenced) to

create new control chains, they may be linked to each other to
create workflows, and they may be decomposed. Sequenced
control chains are represented in Fig. 2 where control chains
C1 + C4 are sequenced to produce the display of level sensor
data on the UI (user interface). Control chains may be linked
in AND (all AND-linked control chains process information
Fig. 2. Tank pressure control system (Omeiri et al., 2015). in parallel) manner, or may be linked in OR (only one of the
OR-linked control chains processes information) manner.
2. C2: Pressure sensor communicates to the control Fig. 3 shows an example of AND-decomposition.
master: sense process pressure - convert sensed
pressure to electronic data - put data in a comm
packet - send comm packet to control master - wait
for confirmation of receipt - if received then end of
workflow - else timeout and resend comm packet.
3. C3: Temperature sensor communicates to the
control master: sense process temperature - convert
sensed temperature to electronic data - put data in a
comm packet - send comm packet to control master
- wait for confirmation receipt - if received then end
Fig. 3. AND linking of control chains.
of workflow - else timeout and resend comm packet.
4. C4: Control master receives data from sensor:
receipt of communication packet by Control Master Control chains may be decomposed as well, as shown in Fig.
(CM hardware) - check for packet integrity (CM 4. Level Sensor is decomposed into its components:
software) - if packet valid, obtain data from Transducer-Software-Transmitter. Transducer component in
communication packet (CM software) - compare turn is decomposed into Sensor-Electric Signal Generator; the
level data with threshold (CM software) - if Software is decomposed into A/D (Analog-to-Digital)
expected level or within expected boundaries send Converter-Create Packet-Send Packet. The Medium is
normal information to UI (CM software) - if decomposed to Wi-Fi, the Control Master into Receiver-
unexpected level or outside expected boundaries Software combination; and Software component has been
send alarm information to UI (CM software). further decomposed into Check Integrity-Process Packet-
Send UI (User Interface) combination.
5. C5: Control master raises alarm: compare input with
threshold value - if above/below generate alarm
signal - send signal to UI controller.
6. C6: Control master communicates to the pump:
receive pump activation signal from UI or timer -
convert activation signal to pump start signal - put
signal in a comm packet - send comm packet to the
pump - wait for confirmation - if received then end
of workflow - else timeout and resend comm packet.
7. C7: Control master communicates to the coolant
pump: receive coolant pump activation/stop signal Fig. 4. Decomposition of control chains.
from UI or timer - convert activation signal to
coolant pump start/stop signal - put signal in a
comm packet - send packet to the coolant pump - The next section discusses principles of the NFR Approach to
wait for confirmation of receipt - if received then prepare for the analysis of safety and security of the control
end of workflow - else timeout and resend packet. chains C1 through C11 for the tank pressure control system.

215
2018 IFAC PDES
216 Nary Subramanian et al. / IFAC PapersOnLine 51-6 (2018) 214–219
Ostrava, Czech Republic, May 23-25, 2018
3. PRINCIPLES OF THE NFR APPROACH
3.1 Basic Properties
The NFR Approach (Subramanian and Zalewski, 2016) is a
goal-oriented approach to determine the extent to which
objectives are achieved by a design. Objectives are defined as
achieving safety and security properties for control chains in
a SCADA system. The details have been discussed in a
previous paper, so here only the basic information is given.
NFR considers properties of a system such as reliability,
maintainability, flexibility, human factors, supportability, or
scalability, and could equally well consider functional
objectives and constraints for a system. The NFR Approach
uses a well-defined ontology for this purpose that includes
NFR softgoals, operationalizing softgoals, claim softgoals,
contributions, & propagation rules, described briefly below.
Since strictly quantitative assessment of vaguely defined
properties is difficult, the NFR Approach uses the concept of
satisficing, borrowed from economics, which indicates
satisfaction within limits instead of absolute satisfaction of
the goal. NFR softgoals represent NFR’s and their
decompositions. Elements that have physical equivalents are
represented by operationalizing softgoals and their
decompositions. Each softgoal is named using the convention
Type [Topic1, Topic2, …]
where Type is the name of the softgoal and Topic is the
context of the softgoal. Topic is optional for a softgoal; for a
claim softgoal, which is a softgoal capturing a design
decision, the name may be the justification itself.
Contributions (MAKE, HELP, HURT, and BREAK) are
usually made by operationalizing softgoals to NFR softgoals.
Reasons for these contributions are captured by claim
softgoals and, in this case, there is a contribution between a
claim softgoal and the contribution being justified. Each of
the four contributions has a specific semantic significance:
 MAKE contribution refers to a strongly positive
degree of satisficing of objectives by artifacts (could
be design decisions as well) under consideration.
 HELP contribution refers to positive satisficing.
 HURT contribution refers to negative satisficing.
 BREAK contribution refers to a strongly negative
degree of satisficing.
NFR Operationalizing
Softgoal Softgoal
Strongly Positively Satisficing or
++
MAKE Contribution
+ Positively Satisficing or
HELP Contribution
- Negatively Satisficing or -- Strongly Negatively Satisficing or
HURT Contribution BREAK Contribution
AND Decomposition OR Decomposition
Labels: + -
Satisficed, W Weakly Satisficed, W Weakly Denied, X Denied
Fig. 5. Partial Ontology of the NFR Approach.
Due to these contributions, some of the softgoals acquire
labels that capture the extent to which a softgoal is satisficed:
satisficed, weakly satisficed, weakly denied (or weakly not
satisficed), denied (or not satisficed), or unknown (indicated
by an absence of any label attribute). The graph that captures
the softgoals, their decompositions, and the contributions is
called the Softgoal Interdependency Graph (SIG). The partial
ontology of the NFR approach is shown in Fig. 5.
3.2 Propagation Rules
Propagation rules propagate labels from a child softgoal to
its parent across decompositions, from operationalizing
softgoals to NFR softgoals across contributions, and from
claim softgoals to contributions; propagation rules aid in the
rationalization process of the NFR Approach. Here we only
show examples of 3 propagation rules due to limited space.
Details are discussed in (Subramanian and Zalewski, 2016).
R1. Determine labels for all operationalizing softgoals,
claim softgoals, and contributions: each is either satisficed,
denied, weakly satisficed, weakly denied, or unknown.
R2. If a softgoal/contribution label is satisficed (denied)
and it has a MAKE-contribution to its parent, then the
softgoal propagates its label to the parent.
R3. If a softgoal/contribution label is satisficed (denied)
and it has a HELP-contribution to its parent, then the
softgoal/contribution propagates weakly satisficed (weakly
denied) label to the parent.
The rule R1 states that a softgoal can have one of five labels
– satisficed, weakly satisficed, weakly denied, denied, and
unknown. Rules R2 and R3 state the label propagated by a
softgoal to its parent via MAKE or HELP contributions.
3.3 Applying the NFR Approach
There are five iterative steps for applying the NFR Approach
for evaluating safety and security:
1. Decompose NFR Safety
2. Decompose NFR Security
3. Decompose the architecture of a system into its
constituent operationalizing softgoals
4. Determine the contributions made by the
operationalizing softgoals to the NFR softgoals
5. Evaluate the overall safety and security by applying
the propagation rules and observing the labels propagated to
the safety and security softgoals.
In a SIG represented graphically, the NFR softgoals and their
decompositions are shown at the top of the figure, the
Claim
Softgoal operationalizing softgoals and their decompositions are
shown in the bottom, while the contributions between the
operationalizing softgoals and the NFR softgoals are in the
middle. Therefore, contributions are received by the leaf NFR
softgoals that are at the bottom of NFR softgoal hierarchy.
Upon applying corresponding propagation rules, if the root
! Criticality (or topmost) NFR softgoals are satisficed then the goals for
the domain of interest have been met to a large extent. In this
paper the root NFR softgoals are safety and security and
therefore the SIG will help determine the extent to which a
particular design for the SCADA or any other computer
system is safe and secure.
216
 2018 IFAC PDES
Ostrava, Czech Republic, May 23-25, 2018
Nary Subramanian et al. / IFAC PapersOnLine 51-6 (2018) 214–219 217
4. SAFETY ANALYSIS FOR CONTROL CHAINS USING
THE NFR APPROACH
There are a couple of well known safety standards for
SCADA equipment manufacturers to follow: IEC 61508
(2010) and IEC 61511 (2016). While 61508 safety
recommendations are applicable to electronic systems, 61511
is more specific in that it relates to safety requirements for
electronic systems used in the process industry. Similarly, the
IEC 62443 standard (ANSI/ISA 2013) prescribes minimum
security requirements for electronic and programmable
equipment for the process industry. While 61508, 61511, and
62443 suggest safety and security requirements for individual
elements of a SCADA system, from an integrated SCADA
viewpoint where the system consists of several connected
components, an important guideline seems to be the NIST
800-82 (2015). While 800-82 is primarily a security guide for
SCADA systems, it offers several safety recommendations as
Fig. 6. SIG for Safety analysis of control chains.
The NFR Approach can be used to evaluate the achievement
of safety requirements (Fig. 6). The safety requirement (cloud
shape) is decomposed into several others (sub-softgoals):
Emergency Shutdown, Interlocks, Alarms, Availability, Data
Integrity, Leak Detection, Good HMI, and Logging; this is an
AND-decomposition (indicated by a single arc connecting
lines between Safety NFR softgoal and its sub-softgoals), as
all sub-softgoals need to be satisficed for the parent softgoal
(Safety) to be satisficed. The Availability softgoal is further
OR-decomposed (the double arc) into two softgoals: Low
Failure Rate and Redundancy; OR-decomposition means
satisficing any of the child softgoal satisfices the parent. We
consider Low Failure Rate important since SIL, which
depends on the failure rate, is important as per 61511 and to
indicate this fact the ‘!’ symbol appears next to this softgoal.
The contributions made to the different leaf NFR softgoals
(the bottom-most NFR softgoals) by the Level Sensor
Display control chain are shown in this Figure; this control
chain is the operationalizing softgoal since it indicates an
217
well for such systems. For SCADA systems used in the oil
and gas industry, the NTSB study (2005) can also apply.
IEC 61511 offers the requirements (Section 10.3.1) that a
safety instrumented system should satisfy, including: well-
defined safe states, demand rate, response time, relationship
between inputs and outputs, requirements for manual
shutdown, requirements for restart, prescribed safety integrity
level (SIL) for each function, good interfaces, and application
software safety requirements (Section 12.2.2). From an
integrated system point of view, the 800-82 guide prescribes
the following safety requirements: emergency shutdowns and
restarts, interlocks, and redundancy (for high availability).
NTSB study has recommended the following safety
requirements as important: alarms, leak detection, high
availability, high quality human-machine interface, logging
of information, ability to perform standard control functions,
and employing qualified individuals in the control function.
operational artifact. Each contribution can be MAKE
(indicated by ‘++’), HELP (indicated by ‘+’), HURT
(indicated by ‘-’), and BREAK (indicated by ‘--’), and each
indicates the extent to which the parent softgoal (or
contribution) is satisficed either by child operationalizing
softgoals or by claim softgoals.
The claim for the satificing of the contribution to the
Interlocks softgoal is that the control chain uses Wi-Fi in
point coordination mode (PCF), which means that the access
point coordinates medium access (so no collisions); also, the
automatic repeat requests (ARQ) are used by the receiver
(Control Master) in case the transmission is incorrect.
Similarly, Redundancy softgoal is denied (BREAK
contribution) because there is no redundancy in the level
sensor (1oo1 configuration). Other leaf softgoals are
satisficed (MAKE contributions) because we assumed that
the components used in the Level Sensor Display control
chain conform to the 61511 and/or 62443; this became the
justifications (claim softgoals) for these satisficing.
2018 IFAC PDES
218 Nary Subramanian et al. / IFAC PapersOnLine 51-6 (2018) 214–219
Ostrava, Czech Republic, May 23-25, 2018
We can now evaluate the safety satisficing of the control
chain Level Sensor Display, and in a similar manner safety
satisficing for other control chains can be determined. These
steps, however, have to be omitted here due to lack of space.
5. SECURITY ANALYSIS OF CONTROL CHAINS AND
JOINT ANALYSIS WITH SAFETY
The primary standards for security for SCADA seem to be
IEC 62443 (2013) and NIST 800-82 (2015). The main
security requirements in these standards are availability, data
integrity, confidentiality, access control, auditability, and
redundancy. These requirements become the NFR sub-
softgoals for the NFR softgoal Security as shown in Fig. 7.
Fig. 7. SIG for Security analysis of control chains.
The SIG in Fig. 7 shows decomposition of the NFR Security.
The contributions to the leaf NFR softgoals by the Level
Sensor Display control chain operationalizing softgoal is also
shown. Low Failure Rate, Data Integrity, Network
Segregation, and Auditability, all receive MAKE
contributions due to (claims softgoals being), respectively:
conformance to 61511 and 62443 standards, conformance to
62443, SCADA being on a separate network from the
enterprise network (there is an air-gap), and the fact that
control master keeps logs of all transactions.
Authentication and Authorization softgoals receive HELP
contributions since authentication is done implicitly (“Device
information sent” by the Level Sensor, configured to do so)
and so is authorization (“Device knows network” using
network for transmission) - both are not strong and do not
merit MAKE labels. Data Confidentiality and Redundancy
receive BREAK contributions due to unencrypted Wi-Fi and
there is no standby in case of failure (1oo1 configuration).
218
Since they are all needed for Security to be achieved they are
related by AND-decomposition (single arc).
Availability is closely related to reliability (Section 2.3.1 of
800-82) so Low Failure Rate can be considered as a child
softgoal of the NFR softgoal Availability. Confidentiality has
two parts: data confidentiality and network confidentiality;
both of these are child softgoals of the Confidentiality
softgoal; since both these child softgoals are needed for
satisficing the parent (Confidentiality) these two are in an
AND-decomposition. Access Control softgoal has been
AND-decomposed into Authentication and Authorization
softgoals since these two are important for Access Control
according to the standards.
We can now evaluate the satisficing of Security softgoal by
the Level Sensor Display control chain. As before, we
assume all claim softgoals are satisficed (indicated by check
marks in the Figure); since all claim softgoals contribute
MAKE to their parent contributions, all claim softgoals
propagate satisficing labels to their parent contributions.
Therefore, we can now focus on the labels propagated by the
contributions between the operationalizing softgoal and NFR
softgoals. Since the Level Sensor Display operationalizing
softgoal is satisficed (because this control chain exists in the
tank control system) and since it contributes MAKE to Low
Failure Rate, Data Integrity, Network Segregation, and
Auditability, all these NFR softgoals get satisficed labels by
propagation rule R2 (and indicated by check marks within
these leaf NFR softgoals). Since the operationalizing softgoal
contributes HELP to Authentication and Authorization NFR
softgoals, both these softgoals get weakly satisficed labels by
rule R3 (indicated by ‘W+’ marks inside these softgoals).
Since the operationalizing softgoal contributes BREAK to
 2018 IFAC PDES
Ostrava, Czech Republic, May 23-25, 2018
Nary Subramanian et al. / IFAC PapersOnLine 51-6 (2018) 214–219 219
Data Confidentiality and Redundancy softgoals, both these
softgoals get denied labels due to another rule and indicated
by ‘X’ marks inside the softgoals. Now we can propagate the
labels of the NFR softgoal up the SIG.
The combined Safety and Security SIG, shown in Figure 8,
can be developed by combining diagrams in Figures 6 and 7.
Fig. 8 SIG for Joint Safety and Security analysis of control chains.
Another addition in Fig. 8 is that we have now considered
several control chains for the Tank Pressure Control system.
There are eleven control chains but we show only three for
clarity. Moreover, the contributions from C2 + C4 and C3 +
C4 are identical to C1 + C4 considered earlier, so we show
only C1 + C4 (Level Sensor Display control chain);
contributions from C6 + C9 are identical to C7 + C10 and C8
+ C11, thus, we show only the C6 + C9 combination.
6. CONCLUSION
The traditional view of a SCADA system has been to look
upon the system as an interconnection of components. Safety
and Security of a SCADA system directly depended on the
safety and security of these components and connections.
However, this view often tends to mask the fact that there are
several different sequences of activities amongst these
components and connections that together contribute to the
overall functioning of a safe and secure SCADA system.
In this paper we introduced the concept of control chains that
capture control flow between any two points: these control
chains can be annotated, composed, decomposed, and
chained to each other to create workflows. We considered an
example tank pressure control system and identified eleven
control chains in this system. We then analyzed the safety
and security of these control chains using the NFR Approach.
The analysis led us to the conclusion that this pressure system
is safe but not secure due to lack of data confidentiality.
However, the control chains view allows us to study a
complex SCADA system more easily at different levels of
abstraction; the more we know about a particular chain the
219
Here, the NFR softgoal Low Failure Rate, originally part of
the Safety SIG of Fig. 6, has been directly connected to the
Security NFR softgoal - this still preserves the original
decomposition of the Security SIG since impact of the refined
NFR softgoal Low Failure Rate is directly transmitted to the
Security NFR softgoal.
better do we understand its safety and security properties.
Overall, we believe control chains will help us analyze,
design, and build safer and more secure SCADA systems.
REFERENCES
International Standard ANSI/ISA 62443:2013 (2013)
Security for Industrial Automation and Control Systems.
American National Standard Institute, Washington, DC.
International Standard IEC 61508:2010 (2010) Functional
safety of electrical/electronic/programmable electronic
safety-related systems. IEC, Geneva, Switzerland.
International Standard IEC 61511:2016 (2016) Functional
safety - Safety instrumented systems for the process
industry sector. IEC, Geneva, Switzerland.
National Institute of Standards and Technology SP 800-82
Rev. 2 (2015) Guide to Industrial Control Systems (ICS)
Security, NIST, Gaithersburg, Maryland.
National Transportation Safety Board (2005) Supervisory
Control and Data Acquisition (SCADA) in Liquid
Pipelines, NTSB/SS-05/02. NTSB, Washington, DC.
Omeiri, H., F. Innal, and B. Hamaidi (2015). Safety Integrity
Evaluation of a Butane Tank Overpressure Evacution
System According to IEC 61508 Standard. Journal of
Failure Analysis and Prevention, Vol. 15, pp. 892-905.
Radvanovsky, R., and J. Brodsky (2016). Handbook of
SCADA/Control Systems Security, CRC Press, Florida.
Subramanian, N. and J. Zalewski (2016). Quantitative
Assessment of Safety and Security of System
Architectures for Cyberphysical Systems Using NFR.
IEEE Systems Journal, Vol. 10, No. 2, pp. 397-409.