Stand;irds Setting tile Standard for Al1itomation"'

Certification
Education & Training

Publishing

Confeten<es & Exh1biu

TECHNICAL REPORT

ISA-TR84.00.09-2017

Cybersecurity Related to the

Functional Safety Lifecycle

Approved 10 April 2017

NOTICE OF COPYRIGHT
This Is a copy•ight docuMent a.,d mav •ol be copied ot
<Mtt buted In anv fotm oi manner -.. thou: the permission of
ISA. -h.1 co';r(ol me dc>cume111 was made for !he sole u.se or
tN! person 10 .. hom tSA prov1ded It 3M! JS SJbject to t'1e
1es~tions stated ""151\'s ce<1se to tha: DerSOn.
It m.tv no: be p1ov <led to an·, other oe<>0n In Oflnt,
electronic, or a'ly o:~er 'orm. V10l1:.ons ol ISA' s copyr-ght
w1 be prosMtt:ed !O !he fullest n:ent o• t'1e law a"" may
1esult 11 substantla I clv1 and cr"l'llna oena ttles.
I SA·TR84.00.09-2017, Cybersecurity Re lated to the Functional Safety Lifecycle

ISBN: 978-1 -945541-49-0

Copyright © 2017 by ISA. All rights reserved . Not for resale. Printed in the United States of
America.

ISA
67 Alexander Drive
P. 0 . Box 12277
Research Triangle Park, NC 27709 USA
 -3- ISA-TR84.00.09-2017

PRE FACE
This preface, as well as all footnotes and annexes, is included for information purposes and is not
part of ISA-TR84 .00 .09-2017 .

T his document has been prepared as part of the service of ISA, the International Soc iety of
Automation , toward a goal of un iformity in the field of instrumentation . To be of real value , this
document should not be static but should be subject to periodic review. Toward this end , the
Society welcomes all comments and criticisms and asks that they be addressed to the Secretary,
Standards and Practices Board; ISA; 67 Alexander Drive; P. 0 . Box 12277; Research Triangle
Park, NC 27709; Telephone (919 ) 549-84 11; Fax (919) 549-8288; E-mail: standards@isa .org .

It is the policy of ISA to encourage and welcome the participation of all concerned individuals and
interests in the development of ISA standards, recommended practices and technical reports .
Participation in the ISA standards-making process by an individual in no way constitutes
endorsement by the employer of that individual , of ISA or of any of the standards, recommended
practices and technical reports that ISA develops.

CAUTION - ISA DOES NOT TAKE ANY POSITION WITH RESPECT TO THE EXISTENCE OR
VALIDITY OF ANY PATENT RIGHTS ASSERTED IN CONNECTION WITH THIS DOCUMENT,
AND ISA DISCLAIMS LIABILITY FOR THE INFRINGEMENT OF ANY PATENT RESULTING
FROM THE USE OF THIS DOCUMENT. USERS ARE ADVISED THAT DETERMINATION OF THE
VALIDITY OF ANY PATENT RIGHTS, AND THE RISK OF INFRINGEMENT OF SUCH RIGHTS,
IS ENTIRELY THEIR OWN RESPONSIBILITY.

PURSUANT TO ISA' S PATENT POLICY, ONE OR MORE PATENT HOLDERS OR PATENT

APPLICANTS MAY HAVE DISCLOSED PATENTS THAT COULD BE INFRINGED BY USE OF
THIS DOCUMENT AND EXECUTED A LETTER OF ASSURANCE COMMITTING TO THE
GRANTING OF A LICENSE ON A WORLDWIDE, NONDISCRI MllNATORY BASIS, WITH A FAIR
AND REASONABLE ROYALTY RATE AND FAIR AND REASONABLE TERMS AND
CONDITIONS. FOR MORE INFORMATION ON SUCH DISCLOSURES AND LETTERS OF
ASSURANCE, CONTACT ISA OR VISIT WWW.ISA. ORG/STANDARDSPATENTS.

OTHER PATENTS OR PATENT CLAI MS MAY EXIST FOR WHICH A DISCLOSURE OR LETTER
OF ASSURANCE HAS NOT BEEN RECEIVED. ISA IS NOT RESPONSIBLE FOR IDENTIFYING
PATENTS OR PATENT APPLICATIONS FOR WHICH A LICENSE MAY BE REQUIRED, FOR
CONDUCTING INQUIRIES INTO THE LEGAL VALIDITY OR SCOPE OF PATENTS , OR
DETERMINING WHETHER ANY LICENSING TERMS OR CONDITIONS PROVIDED IN
CONNECTION WITH SUBMISSION OF A LETTER OF ASSURANCE, IF ANY, OR IN ANY
LICENSING AGREEMENTS ARE REASONABLE OR NON- DISCRIMI NATORY.

ISA REQUESTS THAT ANYONE REVIEWING THIS DOCUMENT WHO IS AWARE OF ANY
PATENTS THAT MAY IMPACT IMPLEMENTATION OF THE DOCUMENT NOTIFY THE ISA
STANDARDS AND PRACTICES DEPARTMENT OF THE PATENT AND ITS OWNER.

ADDITIONALLY, THE USE OF THIS DOCUMENT MAY INVOLVE HAZARDOUS MATERIALS,

OPERATIONS OR PROCESS EQUIPMENT. THE DOCUMENT CANNOT ANTICI PATE ALL
POSSIBLE APPLICATIONS OR ADDRESS ALL POSSI BLE SAFETY ISSUES ASSOCIATED
WITH USE IN HAZARDOUS CONDITIONS . THE USER OF THIS TECHNICAL REPORT SHOULD
EXERCISE SOUND PROFESSIONAL JUDGMENT CONCERNING ITS USE AND
APPLICABILITY UNDER THE USER' S PARTICULAR CIRCUMSTANCES. THE USER SHOULD
ALSO CONSIDER THE APPLICABILITY OF ANY GOVERNMENTAL REGULATORY
LIMITATIONS AND ESTABLISHED SAFETY AND HEALTH PRACTICES BEFORE
IMPLEMENTING THIS TECHNICAL REPORT.

ISA (www.isa.org) is a nonprofit professional association that sets the standard for those who apply
engineering and technology to improve the management, safety, and cybersecurity of modern
ISA-T R84 .00.09-2017 -4 -

automation and control systems used across industry and critical infrastructure. Founded in 1945,
ISA develops widely used global standards; certifi es industry professionals; provides education
and training ; publ ishes books and technical articles; hosts conferences and exhibits; and provides
networking and career development programs for its 40,000 members and 400,000 customers
around the world .

ISA owns Automation.com , a leading online publisher of automation-related co,ntent, and is the
founding sponsor of The Automa tion Federation (www.automationfederation.org ), an association
of non-profit organizations serving as "The Voice of Automation ." Through a wholly owned
subsidiary, ISA bridges the gap between standards and their implementation with the ISA Security
Compliance Institute (www.isasecure.org ) and the ISA Wireless Compliance Institute
(www.isa100wci.org).

The fo llowing members of ISA84 Working Group 9 served as active contributors in the development
of this technical report revision :

NAME AFFILIATION
Kevin Arnold Phillips 66
Dave Bennett Phillips 66
Rahul Bhojani BP
John D. Day Air Products and Chemicals
David Deibert Air Products and Chemicals
Andrew Feben Eigen Ltd
David Gunter Air Products and Chemicals
Eric Hopp Rockwell Automation
Kevin Klein Chevron
Vic Maggioli Feltronics Corp
Marcelo Mollicone SYM PCS
Nagappan Muthiah Wood Group
Eric Persson ex id a
Jeff Potter Emerson
Richard Roberts Suncor Energy
Eloise Roche SIS-T ECH Solutions, LP
Byron Schneidau BP Pipelines & Logistics
Herm an Storey Herman Storey Consulting
Harold W Thomas (Hal) ex id a
Paulo Vergara Zavior Consulting

The following members of ISA84 and ISA99 are acknowledged for their peer review of this
technical report revision .
NAME AFFILIATION
Eric Cosman OIT Concepts , LLC
John Cusimano AE Solutions
Marc Baque Total
Dennis Holstein OPUS Consulting Group
Joe Weiss Applied Control Solutions LLC
John Ayuk Mustang Engineering
Scott Nielsen Mustang Engineering
Rahul Gupta Worley Parsons
Brad Bonnette Wood Group
David Dalke Mustang Engineering
Paul Gruhn AE Solutions
 -5- ISA-TR84 .00.09-2017

The following served as members of the Standards and Practices Board and approved the
document on 10 Apri l 2017 :
NAME AFFILIATION
M. Wilkins, Vice President Yokogawa
D. Bartusiak ExxonMobil Research & Engineering
D. Brandl BR&L Consulting
P. Brett Honeywell Inc.
E. Cosman OIT Concepts, LLC
D. Dunn Phillips 66
J . Federtein Federtein & Assoc. LLC
B. Fitzpatrick Wood Group Mustang
J . Gilsinn Kenexis Consulting
J.-P. Hauet KB Intelligence
D. Lee UCDS
G. Lehmann AECOM
K.-P. Lindner Endress+Hauser Process Solutions AG
T. McAvinew Consultant
V . Mezzano Fluor Corp.
C. Monchinski Automated Control Concepts Inc.
G. Nasby City of Guelph Water Services
M. Nixon Emerson Process Management
D. Reed Rockwell Automation
N. Sands DuPont
H. Sasajima Fieldcomm Group Inc. Asia-Pacific
H. Storey Herman Storey Consulting
K. Unger Consultant
I. Verhappen Industrial Automation Networks
D. Visnich Bums & McDonnell
W . Weidman Consultant
J. Weiss Applied Control Solutions LLC
D. Zetterberg Chevron Energy
This page intentionally left blank.
 -7- ISA-TR84 .00.09-2017

CONTENTS
FOREWORD .......................................................................................................................... 9
0 Introduction .................................................................................................................... 11
0.1 Executive summary ............................................................................................... 11
0.2 Integrated lifecycle ................................................................................................ 11
0.3 Safety versus cybersecurity considerations ........................................................... 13
Scope ............................................................................................................................ 17
2 References .................................................................................................................... 17
3 Terms, definitions, abbreviated terms, acronyms, and conventions ................................ 18
3.1 Terms and definitions ............................................................................................ 18
3.2 Abbreviated terms and acronyms .......................................................................... 20
4 Management of SCAI cybersecurity in the process sector .............................................. 23
4.1 Objective .............................................................................................................. 23
4.2 Guidelines ............................................................................................................. 23
5 Cyber risk assessment phase ... .. .................................................................................... 27
5.1 Overview ............................................................................................................... 27
6 Hazard and risk analysis ................................................................................................ 29
7 Allocation of Security Levels (SL) ................................................................................... 32
8 Cybersecurity Requirements Specification (CSRS) for the IACS ..................................... 33
9 Cybersecurity design and implement phase .................................................................... 35
9.1 Overview ............................................................................................................... 35
10 Design and engineering ........... .. .................................................................................... 37
10.1 Cybersecurity concept ........................................................................................... 37
10.2 Other means of cyber risk reduction ...................................................................... 40
10.3 Security level verification ...................................................................................... 40
10.4 Detailed design ..................................................................................................... 41
10.5 Detailed design verification ................................................................................... 42
10.6 System Integration ................................................................................................ 43
10.7 Cybersecurity FAT (CFAT) .................................................................................... 43
11 Installation, commissioning and validation ...................................................................... 44
11 .1 Overview ............................................................................................................... 44
11 .2 Cybersecurity Site Acceptance Test (CSAT) ......................................................... 44
11 .3 Initial validation of countermeasures ..................................................................... 44
11.4 Pre-Startup Safety Review (PSSR) ....................................................................... 44
12 Operate and maintain phase .......................................................................................... 45
12. 1 Overview ............................................................................................................... 45
12.2 Operation ............ ...... ...... ........................... .............. .... ....... ........... ... ......... ....... .... 47
12.3 Cybersecurity metrics ........................................................................................... 4 7
12.4 Physical security of a SCAI system ....................................................................... 47
12.5 Unauthorized access of a SCAI system ................................................................. 48
12.6 Authorized change management of a SCAI system ............................................... 48
12.7 Unauthorized communication with a SCAI system ................................................. 48
ISA-T R84 .00.09-2017 -8-

12.8 Cybersecurity threat events ... .................................................. .............................. 49

12.9 Normal maintenance ............................................................................................. 49
12.10 Mechanical integrity .............. ......................... ......................... ................... ........... 49
12.11 Inspection/Audit ....................................... ...... ................... ...... ................... ........... 49
12.1 2 Remote access ........................................ ......................... ...... ................... ........... 49
12.13 Bypasses ....................................................... ................... ...... ................... ...... ..... 51
12.1 4 Tools ...... ...... ................... ............ ......................... ............. ...... ................... ........ ... 51
12.1 5 Periodic assessments ........................................................................................... 51
13 Modification .......... ...... ......................... ............................................ ............... .... ........ ... 51
14 Decommissioning ........................................................................................................... 53
Annex A - Example SCAI interfaces ................................................. ........ ........... ................. 55
A. 1 Overview ...... ................... ........................... .... .. ................. ...... ............. ...... ...... ..... 55
A.2 Air-gapped (2 zones) ............................................................................................ 59
A.3 Interfaced (2 zones) .............................................................................................. 6 1
A.4 Integrated systems with isolated networks (2 zones) ............................................. 63
A.5 Integrated systems with shared network (partial 2 zone) ........................ ............... 65
A.6 Combined systems with strong dependency (1 zone) ............................................ 67
A. 7 Shared logic solver (1 zone) ...................... ......................... .... ............... ...... ...... ... 68
A.8 Supervisory control and data acquisition systems (SCADA) .................................. 70
Annex B - Cyber risk assessment example procedures ........................................................ 73
B. 1 High level cyber risk assessment procedure .......................................................... 73
B.2 Detailed cyber risk assessment procedure ..... ...................................... ................. 75
Annex C - Cyber vulnerability assessment ........................................................................... 8 1
C.1 Ongoing lifecycle vulnerability assessment ........................................................... 8 1
C.2 First time existing plant vulnerability assessment 16 .. ... ... .... .. .... ... ... ... ..... . ..... . .... .. .. 8 1
Annex D - Cybersecurity level verification example .............................................................. 83
D.1 Example cyber risk criteria ...... ................... ...... ................. ........ ............................ 84
D.2 Example results of high level cyber risk assessment ............................................. 85
D.3 Example countermeasure strength assessment ................... ................... .... ........... 88
D.3 .1 External denial of service (DoS) example SL verification ........................... 90
D.3 .2 Unintentional internal DoS example SL verification .................... ...... ......... 93
D.3 .3 External general virus example SL verification .......................................... 94
D.3 .4 External sophisticated intentional malware attack example SL
verification .......... ................... ................................................................... 95
D.4 SL verification planning ... ...... ......................... ................... ......................... ........... 97
Annex E - Cybersecurity metrics for IACS ............................................................................ 99
E. 1 Preface ................................................................................................................. 99
E.2 Introduction .. ................... ...................................................................................... 99
Annex F - Manufacturer cybersecurity manual ................................................................... 105
Annex G - Typical countermeasures ......................... ......................... ...... ............. ...... ....... 107
Annex H - ISA-TR84.00.09 / IEC 61511 cross references .................................................. 113
Bibliography ............ ...... ......................... ............................................................................ 114
 -9- ISA-TR84 .00.09-2017

FOREWORD
This technical report is part of a series of standards and technical reports that address the issue
of safety instrumented system security. It has been developed by Working Group 9 of the ISA84
committee in cooperation with the ISA99 committee.

This technical report provides gu idance on how to implement cybersecurity within the I EC-61511
and ISA-84 .00.01-2004 lifecycle. This is the second issue of this technical report. Members of the
ISA84 and ISA99 committees contributed to this effort.

Readers of this technical report are asked to send comments on the content and suggestions for
coverage in future revisions to the following email address:

standards@lsa.org
This page intentionally left blank .
 - 11 - ISA-TR84.00.09-2017

0 Introduction
0.1 Executiv e summary
Safety Instrumented Systems (SIS) represent one layer of protection that may be implemented in
order to reduce risk within the process industry. Other layers of protection may consist of
instrumented systems performing alarms, interlocks , permissive functions or controls using
devices within the basic process control system (BPCS), as well as non-instrumented systems
such as relief devices , check valves, etc. Traditional process hazard analysis (PHA). in the past,
has generally excluded the potential for cyber related attacks to cause process safety incidents.
Given that targeted attacks on industrial automation and control systems (IACS) , including the
systems executing safety controls, alarms , and interlocks (SCAI), have occurred and these
systems are increasingly being connected to other business systems, cyber vulnerabilities
represent a significant potential for common mode fa ilure . As a result, it is necessary in today's
world to include cyber risk in the overall PHA.

Without addressing cybersecurity throughout the entire safety lifecycle, it is not possible to
adequately understand the relative independence and integrity of the various layers of protection
that involve instrumented systems, including the SIS.

The underlying premise of this document is to help the reader understand how to integrate
cybersecurity into the safety lifecycle . Guidance is provided on how to implement, operate and
maintain safety controls, alarms , and interlocks (SCAI) in a secure manner. As part of this
integration, it should also be understood that achieving higher security levels may result in less
convenience to the end user. Addressing cybersecurity and functiona l safety of the SCAI systems
within the IACS requires that this document serve both the ISA84 series of standards as well as
the ANS l/I SA-62443 series of standards.

0.2 Integrated lif ecycle

The work process to ensure security of the IACS should account for the entire functional safety
lifecycle, including risk assessment , design, manufacture , factory acceptance testing (FAT), site
acceptance testing (S AT), commissioning, operation , maintenance, the ongoing mechanical
integrity program , modification and decommissioning . As part of the safety lifecycle (SLC). as
documented in ISA-84 .00 .01-2004 (see Figure 1), security should be addressed at all phases .

Figure 2 seeks to show, at a high level, how functional safety and cybersecurity could integrate
within the overall safety lifecycle , starting with a new process plant at the initial scope stage and
continuing throughout all phases of the lifecycle. Although the NIST (National Institute of Standards
and Technology) framework is not the only one that can be selected , it was used as a quality
assurance tool when developing this technical report to help ensure any potential gaps were
minimized . The overall result is an example of a single process safety management process,
incorporating IEC-61511 , ISA-84 .00 .01 , ANSl/ISA-84.91 .01 , Draft ISA-84 .'91.03, and the
applicable ANSl /I SA-62443 series of standards. Additional lifecycle details are provided
throughout this technical report. It is recognized that the lifecycle figures in this technical report
are an interpretation and that there may be other appropdate means to address the IEC 615 11
lifecycle with respect to functional safety and cybersecuri1ty. It should also be recognized that
different functional disciplines will of necessity be responsible for different aspects of the lifecycle .
This technical report is mainly targeted at process control , process safety, and operations
personnel so that the impact of cybersecurity regards process safety can be better understood as
well as to help understand the necessary relationship with i nformation technology (IT} personnel.
While not directl y targeted at IT personnel, they may find this document useful regards the
relationship between safety and cybersecurity in the process industry.
ISA-T R84 .00.09- 201 7 - 12 -

Manage· Safety Hazard & Risk Verlfic•-

ment of Llfecycle Analysis Clau1e 8 tlon
Functio nal StruclUra
Safety an d and
Func:tlonal Planning I

Safety A.location o' Safety Func:t.oos :

AIHSS· co Proteci:ion :
mentand ~ Layers Clause 9 •_ J
Allditlng

Safety Requirements
Specification for the
Safety I n1trvmented
System Clau&es
3 10 & 12

---------- ,--- ---------,

Design & Engineering of I Design and Development 1
1
Safety Instrumented of Other 1
Systems ClauHs : ll'eans ~ Rsk Reduc:!Jon :
L-4___1_1_&_1_2_ _ _ _ ~- - - <:~:· ! _- -- ~
Installation, Comm!n lonlng &
Validation
5 Clause 14 & 15

Operation & Maintenance

Clau1e 16
6

Clau11ts 7,
ClauH 5 Clause 6.2 12.4 &
12.7
Oec:ommlsslonlng
~ [j] 8 CiauH 18 [ID
Logond:
,---,
L__ ~ No guidance given in this tecmical report.

D Guidance LS provided n this tec:hnic:al report.

Figure 1 - Graphical r epresentation of the safety lifecyc le

NOTE The clause numbers w ithin tho olomonts of Figure above rofor to clauses in
ISA-84.00.01· 2004 Part 1 (IEC 61511 · 1 Mod).
 - 13 - ISA-TR84.00.09-2017

NIST Framework

Figure 2 - Cybersecurity lifecycle integrated w ith process safety management

0.3 Safety versus cybersecurity considerations

Traditionally, different disciplines have dealt with safety and cybersecurity with not much overlap .
In today's world, neither functional safety nor information technology are independent of one
another. It is important for both functional areas to understand the differences as well as the
overlaps so that j ointly, appropriate best practices can be employed and any culture of "Us versus
Them" can evolve into "We." As such , it is important to understand the typical differences in how
the IT professional views their requirements versus how a process control engineer views theirs.

Common differences between IT and IACS that typically exist today are included in Table 1:
ISA-T R84 .00.09-2017 - 14 -

Tab le 1 - Cu rrent snapshot comparison of IT versus IACS d isc ip li nes

IT IACS
Response time performance Limited knowledge of process Should be real time relati ve to the
response time requirements process dynamics. e.g., milli·
seconds, seconds.
Ava II ability Occasional outages tolerated Outages not tolerable
Data confidentiality Data privacy is critical Data privacy generally less critical
Data integrity I Configuration and/or Critical Critical
software integrity
Technology lifecycle 3 - 5 years 20• years
Outsourcing Common Less common
Patching Timely Less frequent I As required
Anti-virus Common Old legacy systems may not be
supported. Potential undesirable
side-effects with real-time process

Cybersecurity awareness
I Good
-
control software.
Poor I Improving
Process safety risk awareness Poor Good
Risk assessment granularity Coarse (e.g .. all control loops) Fine (e.g.. individual loop)
Changes Easy to implement Dif icult to implement
Sa' ety integrity awareness Poor Good
PHA revalidation No expl icit requirement No greater than 5 years

Successful cybersecurity programs consider the differences between traditional IT roles and
IACS to develop a cohesive program that delivers on the needs of both organizations.

Table 2 below contrasts cybersecurity versus functional safety as a functi on of the safety lifecycle .
 - 15 - ISA-TR84 .00.09- 2017

Table 2 - Comparison of functional safety and IT cybusecurity in IACS using a lifecycle

approach 12 1 1

Llfocyclo phase FuncU onal safoty IACS cybor socurl ty

Ta1get o' Equipment urder control (EUC) Systerr. under Considerat on (SuC)
evaluation

Random fa lures due to opere:ional and enwoomen:al Tiveal5: in:emal, extell'al or combnation
,tresses
Sys:Sr.iatc fa hites due to errors dunng sa'e:y llfecycle .
Vulrerab-1 ~ a\re to
=a1lure
'le!hood .. componen: or system aesign ~ws
malt ng non-vahda:ea changes
not following cybersecur ty practices and
procedures
. Th.rea:s explo t.og vulnerab h:1es leads to
'a ure
~IS'(
ian~)'s s
Conseqoence Im pact on environment, health and sa'e:y of personnel Loss of ava ab1I : y ana! or data 11tegn:y has d1ect
seven:y i3l'd the general publ c mpact, ano loss o' cool den:1al ty has rd1rect impact on
•unctJOnal sa!ety

Sasao on hkel rood and seventy; nsk may be a\Iantlf ed Based on likelihood ard seven:y; ris'( ~ currently
iaualitalve
Rls '( categonzation 'or every cybersecunty reqtrrer.i ent
~ISk
~'ufu..d11T1ens1onal problem
categoriza Lon
Assignee to zone wlh targets lor each zone/conduit

Relles on independent protection layers concep: Relies on cybe'5ecu;ty coun:Bfrleasures w:th.n zones,
Sa!eguatds reduce hketihood of conseouence lcondul\S nteroonneccing mres, and defense n aepth
ievaruateo iconcep:
~1sk mitigation Countermeas~es reduce li'(el.hood
ldenufles n:egr1tyrequ.1err.en:s for safeguards; for SIF
measures oentifes reauiremerls for c:ouitenneasures to meet
!assigns target S L
:he zone targets _ for each threat vector

Sa'e:y manual for corr ponents Cybersecurtty manual 'or components

Im plerr. en:a:ion of rreasures OuantitaLve S venfical.JOn for S F Verificato n through d "erent levels of tes!Jng for large:
ISL

Restrc: access to IACS corrponenlS to oorrpetent Restnct access to IACS components to competent
P>ersonnel w:h necessary access pr1Vleges Pelsonnel with necessary access privfeges
Perodic testrg of measures Pe1"0dic test ng of rr. easures
pPeratlOn and rr.antenance Derrana rate and oorr.ponent fa lures to be rr.oni:oreo Frequent reviews to i<lentifynew vulnerabill:iesano
Awareness and uainmg .ake appropriate acticm . ' necessary
Awareness and trallllllg
Cyber nsk reassessnent after each software or
~·are change

Management system Defines requirerrents for competency, training. Deines requirenenlS for COIT pe:ency, tra., ng,
rvenflcat10n, tesL1'9, audh, MOC. and docurr.en:a:ion r.-en'icaLJOn, testrg, aua11.. l.10C, ard docurr.en:a:lon
ISA-T R84 .00. 09-2017 - 16 -

This page intentionally left blank .

 - 17 - ISA-TR84.00.09-2017

1 Scope

This document is intended to address and provide guidance on integrating the cybersecurity
lifecycle with the safety lifecycle as they rela te to Safety Controls , Alarms, and Interlocks (SCAI),
inclusive of Safety Instrumented Systems (SIS). This scope includes the work processes and
countermeasures used to reduce the risk involved due to cybersecurity threats to the Industrial
Automation and Control System (IACS) network.

This scope provides recommendations to ensure SCAI are adequately secured due to the potential
for cyber attacks that can act like common mode failures that initiate a hazardous demand and
also prevent instrumented protection functions , including the SIS , from performing their intended
purpose. The scope is intended to address cybersecurity from both externa l and internal threats.
Although not directly within the scope , enterprise networks, business networks and process
information networks (demilitarized zones) that represent a threat vector to the SCAI systems, or
contain countermeasures that reduce the risk to the SCAI systems from external cyber threats, are
included .

The scope does not address physical plant protection (for example , fences, bollards, and
grounding) that has the intent of preventing unauthorized entry into the plant so as to prevent theft ,
vandalism , or physical damage, but does address physical access issues related to cybersecurity
of the IACS ( 12.4 of this technical report ). SCAI systems that are constructed exclusively of
electrical/electronic components without digital signal technology are not vulnerable to
cybersecurity attacks, and these technologies are not discussed in this technical report.

2 References

The fo llowing documents are important for understanding this technical report. For dated
references, only the ed ition cited applies . For undated references, the latest editi on of the
referenced document (including any amendments) applies . For information on obtaining ISA
standards and technical reports, visit: www.isa.org/findstandards

In addition, readers should be aware of the ongoing development of additional standards in the
ANSl/I SA-62443 series, Security for Industrial Automation and Control Systems , listed in the
Bibliography. For an update on the status of these standards , visit https://www.isa.org/isa99/ .

• IEC-61508-2010, Functional Safety of Electrical/ Electronic/Programmable Electronic Safety-

Related Systems

• IEC-61511-1 , Functional Safety: Safety Instrumented Systems for the Process Industry Sector
- Part 1: Framework, Definitions, System, Hardware and Software Requirements .

• ISA-84 .00.01-Part 1 (I EC 61511-1 ), Functional Safety: Safety Instrumented Systems for the
Process Industry Sector - Part 1: Framework, Definitions, System, Hardware and Software
Requirements.

• ANSI/I SA-84 .9 1.0 1-20 12, Identification and Mechanical Integrity of Safety Controls, Alarms,
and Interlocks in the Process Industry , 2012 .
ISA-TR84 .00.09-2017 - 18 -

3 Terms, defi n it i ons, abbreviated terms, acronyms, and conventi ons

3.1 Terms and defin it ions

Conduit 1) Logical grouping of communication assets that protects the security

[Al\S i'SA·62443· 1-1 & of the channels it contains.
ISA ·62•43·1 ·2 revised)
2) Logical grouping of communication channels , between connecting two
or more zones that share common security requirements .
Note to entry: Conduits are ana logous to 1he way th al a phys ical conduil protects cables
rom physi cal damage.

Countermeasure Action , device , procedure , or technique that reduces a threat, a

[Al\S i'SA·62443· 1·1J vulnerability, or an attack by eliminating or preventing it, by minimizing
the harm it can cause , or by discovering and reporting it so that
corrective action can be taken .
Note to en1ry: The term •control" is also used to describe this concept in some contexts.
The term countermeasure has been chosen 10 avoid confusion with the word control in
the contex1 of •process control".

Cyber asset Device contained within the system under consideration (SuC), e.g .,
controller, server, engineering work station , etc .

Cyber incident Communication with an E/E/PE device within a control system that
negatively impacts process safety, the environment, operations,
confidentiality, SCAI integrity, or IACS availability

Cybersecu rity Measures taken to protect a computer or computer system against

[ISA -62•43·1·21 unauthorized access or attack

Industrial Collection of personnel, hardware , software and policies involved in the

Automation and operation of the industrial process and that can affect or influence its
Control System safe, secure and reliable operation .
(I ACS) (1SA -62443-3·31

Risk A measure of human injury, environmental damage, economic loss, loss

of intellectual property or loss of privacy in terms of both the incident
likelihood and the magnitude of the loss or injury. A simplified version of
this relationship expresses risk as the product of the likelihood and the
consequences (i.e., risk = consequence x likelihood) of an incident.

Risk Reduction The measure of the degree of risk reduction required to achieve
Factor (RRF) - tolerable risk. RRF can be expressed as the ratio of unmitigated risk
Target divided by tolerable risk.

Risk Reduction The measure of the degree of risk reduction achieved by a safeguard ,
Factor (RRF) - countermeasure, or protection strategy. Achieved RRF can be
Achieved expressed as the ratio of unmitigated risk divided by mitigated risk
resulting from that safeguard, countermeasure, or protection
strategy. For an independent low demand safety function, this can be
expressed as the reciprocal of the average probability of failure on
demand.

Risk tolerance Willingness by authority having jurisdiction to live with a risk so as to

secure certain benefits in the confidence that the risk is one that is worth
..__ _ _ _ _ _ _ _..__ta_k_i_n....._a_nd that it is beina orooerlv controlled. However, it does not im ly_
g.
 - 19 - ISA-TR84 .00 .09-2017

that everyone would agree without reservation to take this risk or have it
imposed on them .

Risk tolerance A predeterm ined measure of risk used to aid decisions about whether
criteria (CCPS cr-cer•aJ further efforts to reduce risk are warranted.

Safety ( so11i:c Gulde Freedom from unacceptable risk.

51 1999, d el l nl Lo'\ 3.1]

Safety controls, Process safety safeguards implemented with instrumentation and

alarms and controls, used to achieve or maintain a safe state for a process, and
i nterlocks required to provide risk reduction with respect to a specific hazardous
(A'iS /ISA-84.91 .011 event.
Note 1 to entry: T here arc many types of safety controls. alarms. and interlocks. for
example: safety alarm. safety interlock. safety permissive. detection or suppress ion.
emergency shutdown. sa'cty critical control. and safety instrumented system. The terms
listed in the Illustration are not intended to be construed as the only terms app lied to
safety controls . alarms. and interlocks; neither should it be assumed that each type is
necessarily separate and independent.
Note 2 to entry: Refer to ISA-84.00.01 -2004 (IEC 6151 1 Mod) 'or addnional requirements
related to safety instrumented systems.
Note 3 to entry: Examples of non-instr umented sa' eguards include rupture disk s. relief
valves. dikes, etc.

Security level Level corresponding to the required effectiveness of countermeasures

(Al\S /ISA-62443-1-1) and inherent security properties of devices and systems for a zone or
conduit based on assessment of risk for the zone or conduit.

Security level 0 Security level with the following attributes:

(ISA -6241 43-3-21
• No specific requirements or security protection .
-
Security level 1 Security level 1 has the following attributes:
• Intended to protect against casual or coincidental violation
• Counterm easure and detection effectivenes s capable of
delaying or denying an attack for a period of 4 to 8 hour

Security level 2 Security level with the following attributes :

• Intended to protect against intentional violation using simple
means with low resources, generic skills and low motivation
• Counterm easure and detection effectiveness capable of
delaying or denying an attack for a period of days
• Order of magnitude improvement in ri sk reduction factor (RRF)
over a security level 1

Security level 3 Security level with the following attributes:

• Intended to protect against intentional violation using
sophisticated means with moderate resources, IACS specific
skil ls and moderate motivation
• Counterm easure and detection effectiveness capable of
delavina or den ing an attack for a eriod of da s to weeks
ISA-TR84 .00.09-2017 - 20 -

• Order of magnitude improvement in risk reduction factor (RRF)

over a security level 2

Security level 4 Security level with the following attributes :

• Intended to protect against intentional violation using
sophisticated means with extended resources, IACS spec ific
skills and high motivation
• Countermeasure and detection effectiveness capable of
delaying or denying an attack for a period of weeks to months
• Order of magnitude improvement in risk reduction factor (RRF)
over a security level 3 .
1) Potential for violation of security, which exists when there is a
Threat
circumstance, capability, action or event that could breach security
and cause harm .
2) Circumstance or event with the potential to adversely affect
organizational operations (e.g., mission, functions, reputation),
organizational assets , IACS, or personnel via means contrary to
security policy, intentionally or unintentionally cause the
destruction, disclosure, modification of data, control logic, SCAI
loqic, and/or denial of service.
Threat agent Method(s), individual(s) or organ ization(s) that could breach the
security of a facility, operation or system by exploiting a vulnerability

Threat vector Path or means by which a threat agent can gain access to an asset
[ISA -62443·1 · 21 resulting in a negative outcome

Unmitigated cyber Level of risk that is present in a system before any cybersecurity
risk countermeasures are considered

Vulnerability 1) Flaw or weakness in a system's design , implementation , or

[ISA -62443·1 · 2 s light revision operation and management that could be exploited to violate the
to no. 21 system's integrity or security policy.
2) Weakness in an IACS function, procedure, internal control or
implementation that could be exploited or triggered by a threat
source , either intentionally designed into computer components
(e .g., remote port access) or accidentally inserted at any time
during the lifecycle .

zone 11sA -s2••3·3·J I Grouping of logical or physical assets that share common security
requirements .
Noto to entry: A zone has a clear border. Tho security poli cy of a zono is typically
enforced by a combination of mechanisms both at tho zone odgo and within tho zone.

For additional definitions, see IEC-61511 121, ISA-84.00.01-2004 13 1, and ISA-62443-1-2 151

3.2 Abbreviated terms and acronyms

The abbreviated terms and acronyms used in this document are defi ned as follows :

ACL Access Control List

APT Advanced Persistent Threat
ALA RP As Low as Reasonably Practical
 - 21 - ISA-TR84 .00.09-2017

ANSI American National Standards Institute

BPCS Basic Process Control System
CCPS Center for Chemical Process Safety
CFAT Cybersecurity Factory Acceptance Test
CM Ml-SVC Capability Maturity Model Integration - Services
COM Communication Module
COTS Commercial off the Shelf
CSA Cybersecurity Assessment
CSAT Cybersecurity Site Acceptance Test
CSRS Cybersecurity Requirements Specification
DC Data Confidentiality
DEP Data Execution Prevention
Dos Denial of Service
DNP Distributed Network Protocol
EMC Electromagnetic Compatibility
FAT Factory Acceptance Testing
FR Foundational Requirement
FSA Functional Safety Assessment
H&RA Hazard and Risk Assessment
HAZID Hazard Identification Assessment
HAZOP Hazard and Operability Method
HIDS Host Intrusion Detection System
HMI Human Machine Interface
HSE Health and Safety Executive
HTTPS Hypertext Transfer Protocol Secure
IAC Identification and Authen tication Control
IACS Industrial Automation and Control Systems
IAMS" Instrument Asset Management System
IEC International Electrotechnical Commission
IP Internet Protocol
ISA International Society of Automation
ISO International Organization for Standardization
IT Information Technology
LOPA Layer of Protection Analysis
MOC Management of Change
Ml Mechanical Integrity
ISA-TR84 .00.09-2017 - 22 -

NIDS Network Intrusion Detection System

NIPS Network Intrusion Prevention System
NIST National Institute of Standards and Technology
NIC Networked Interface Card
OPC Open Platform Communications
OS Operating System
PCN Process Control Network
PE Programmable Equipment
PES Programmable Electronic System
PHA Process Hazard Analysis
PIN Process Information Network
PKI " Public Key Infrastructure
PSSR Pre-startup Safety Review
RA Resource Availability
RAGAGEP Recognized and Generally Accepted Good Engineering Practices
RFI Radio Frequency Interference
RDF Restricted Data Flow
SAT Site Acceptance Testing
SCAI Safety Controls , Alarms , and Interlocks
SI System Integrity
SIF Safety Instrumented Function
SIL Safety Integrity Level
SIS Safety Instrumented System
SL" Security Level
SL-A Security Level Achieved
SL-C Security Level Capability
SL-T Security Level Target
SLC Safety Lifecycle
SRS Safety Requirements Specification
SSH Secure Shell Protocol
sue System under Consideration
TRE Timely Response to Events
UC Use Control
USB Universal Serial Bus
NOTE Acronyms and associated terms marked with an asterisk do nOI appear In IEC 61511.
 - 23 - ISA-TR84.00.09-2017

4 Management of SCAI cybersecurity in the process sector

4.1 Obj ective
Successful management of safety includes a series of functional safety and cybersecurity related
management activities, all of which are necessary in order to ensure that functional safety
obj ectives are met. The functional safety management system is intended to ensure the assumed
performance is achieved by the SCAI. As such, for the remainder of this document, higher level
terms such as IACS and SCAI will be used when referring to the organizations associated with
those policies and strategies, including management of physical access relating to functional
safety and cybersecurity of SCAI .

4.2 Gu ideli nes

4.2.1 General
An organization's functi onal safety policy and strategy should be underpinned by an organizational
cybersecurity strategy, both of which will be supported by robust performance measurement
procedures. Cybersecurity countermeasures employed by an organization should consist of both
cybersecurity policies and procedure-level countermeasures as well as technical countermeasures.
Cybersecurity policies and procedure-level countermeasures may include staff training and
awareness programs, testing programs, change management programs, identification and
authorization procedures , and the like . The policies should be understood and supported by senior
management.

Any cybersecurity management system implemented within an organization should have included
in it conditions which dictate re-evaluating the risk assessment. These may include, but are not
limited to

• developing a new, or designing a modification to, an existing process con trol system or
SCAI system ;
• implementing a new or modified process control system or SCAI system ; and
• retiring/decommissioning a process control system or SCAI system .
4.2.2 Organ izati on and resources
Those responsible for the execution and/or measurement of the performance for each of the safety
lifecycle phases should be clearly identified and then communicated to applicable personnel so
that they understand their accountabilities and responsibilities therein . These roles and
responsibilities extend beyond the organization itself and includes product suppliers as well. There
are a range of potential requirements that may apply, requiring a breadth of applicable engineering
competencies , including process engineering , instrumentation and controls , cybersecurity,
physical security, legal and regulatory knowledge , functional safety engineering , etc .

The roles and responsibilities associated with cybersecurity should be aligned with both internal
roles as well as with external partners .

The complexities and potential shortfalls in individual, organizational , and product supplier
competency while maintaining cybersecurity and functional safety within the IACS are such that a
sustainable, auditable program of training, famili arization and assessment is recommended.

4.2.3 Competency
The achievement of functional safety and cybersecurity requires the implementation of the safety
lifecycle while ensuring that persons who are responsible for any safety lifecycle activities also
have the appropriate competency in cybersecurity. The following competence factors should be
addressed when assess ing as well as justifying the competency level of persons to carry out their
duties :
ISA-TR84 .00.09-2017 - 24 -

• Experience appropriate to the application area

• Experience appropriate to the information technology and have the ability to demonstrate
knowledge
• Experience appropriate to the IACS technology and have the ability to demonstrate
knowledge
• Functional safety engineering experience appropriate to the technology
• Knowledge of the legal and safety regulatory framework
• The consequences of failure of the safety-related system(s) due to a cyber incident
• The safety requirements of the safety-related system(s) process control network
• The novelty of the network design , design procedures or application
• Previous experience and its relevance to the specific duties to be performed and the
technology being employed
• The ability to recognize when specialist advice or assistance is needed
Personnel capable of performing the work should be identified through a documented competency
assessment process. Aspects of this may include :

• Attended appropriate level of training for duties to be performed

• Requirements for requalification
• Auditable records of training and qualification assessments
• External cybersecurity accreditation by a recognized professional body
• Witness of suitable performance by competent person
4.2.4 Risk management
Throughout the safety lifecycle , risk assessment and management should be accomplished with
respect to all identified process safety and cyber hazards or vulnerabilities . Clear documentation
of risk tolerance should be developed and made available as it relates to potential cyber attacks.
When considering process safety risk, the Center for Chemical Process Safety has released
several guidelines books on how to establish the risk criteria. In addition, IEC 61511 Part 3
provides examples of different criteria used to support the selection of SIL. Similar criteria and
methodologies can be used for cybersecurity risk assessments. Financial considerations should
specifically consider the cost as it relates to duration of downtime and degraded operability as well
as to damaged equipment, in addition to personal safety and environmental impact.

4.2.5 Saf ety I Cyber security p lannin g

A safety lifecycle plan should document all activities and resources necessary to sustain and
secure the IACS, including the SCAI systems , through the entire safety lifecycle . This plan should
include an appropriate level of detail regarding cybersecurity and be maintained throughout the
lifecycle.

Having access to the sensitive information contained in zone and conduit drawings and the
documents related to countermeasure design, verification , and validation would provide significant
assistance to a malicious attacker. For this reason , this information should be documented
separately from the remainder of the safety plan and consideration should be given in the safety
plan to identifying access restrictions that should be applied to this information duri ng all stages
of the lifecycle. Documents that are intended to be more widely available (e .g., safety plan and
safety requirement specification) should avoid providing countermeasure related details .

Within each organization, a chain of command should be established so that appropriate levels of
authority can have access to the information necessary to maintain a safe and cyber secure plant
 - 25 - ISA-TR84.00.09-2017

environment. The plant manager should not be the only person with access to the implementation
plan, however; it should also not be publicly available to those without a clear need to know.

4.2 .6 Organ ization procedures

In order to respond effectively to events and changing requirements throughout the lifecycle,
procedures should be in place to affect a timely resolution , particularly if these are instigated from
audits, investigations, risk I threat assessment or assurance activities.

Network and design information and attributes should be properly classified as to their sensitivity.
Distribution and access to the information should be controlled appropriately to prevent distribution
of confidential information that is vital to the cybersecurity of the system .

4.2 .7 Organizational performance measurement

Procedures should be developed to measure the performance of the cybersecurity
countermeasures against the cybersecurity requirements specification (CSRS) . The procedures
should consider key performance indicators (KPI), incident investigation, audits, testing, and
inspection in order to measure reliability, identify and prevent systematic fa ilures or vulnerabi lities,
and redress failure and/or demand rates where they exceed acceptable limits.

4.2 .8 Human resources

When hiring personnel who will have potential logical or physical access to the IT or IACS networks ,
it is important to screen prospective applicants to ensure a low likelihood of malicious motive or
intent to execute cyber attacks as well as to evaluate that they have sufficient technical skills .
Screening should not be a single exercise , as a person may change over time. As such ,
consideration should be given to periodic background checks.

Whenever a person is no longer associated with the SuC, all means of access should be eliminated
immediately.

4.2 .9 Su pply chai n cybersecurity

Any product supplier stating compliance with 61511 should have a functional safety management
system that suitably addresses cybersecurity. A product supplier with responsibilities for one or
more phases of the safety lifecycle should have a quality management system supported by
policies , procedures and countermeasures sufficient to provide the required security level
capability specified by the purchaser and ultimately the end user.

4.2 .10 Cybersecurity assessments (CSA)

A procedure should be defined and executed for a cybersecurity assessment in such a way that a
judgement can be made as to the cybersecurity SL achieved with respect to the IACS, including
the SCAI systems. Procedures should include an assessment team with the technical , application
and operations expertise appropriate for the particular installation. The CSA should be conducted
in conjunction or as a subset of the functional safety assessment (FSA).

Tile stages in the safety lifecycle at which the CSA activities are to be carried should be identified
during the safety planning. Consideration should be given to carrying out CSA activities at the
following stages :

• Stage 1 - After the detailed cyber risk assessment has been carried out, the required
countermeasures have be·en identified and the CSRS has been developed . Intent of this
assessment is to ensure that the conceptual design is complete and cons istent with the
intent of the risk assessment prior to detailed design engineering commencing.
• Stage 2 - After the IACS cybersecurity countermeasures have been designed . Intent of this
assessment is to ensure that the detailed design engineering is complete and consistent
with the intent of the conceptual design prior to issuing contracts for construction.
ISA-T R84 .00.09-2017 - 26 -

• Stage 3 - After the installation, pre-comm1ss1oning and final val idation of the IACS
cybersecurity countermeasures have been completed and operation, mai ntenance, and
emergency response procedures have been developed. This should be conducted as part
of the pre-startup safety review (PSSR) . Intent of this assessment is to ensure the plant is
secure and safe to begin operations.
• Stage 4 - After gaining experience in operating and maintenance. Intent is to validate
assumptions made and to correct risk assessment as applicable .
• Stage 5 - After modifications and prior to decommissioning . Intent is to ensure robust
management of change (MOC).
During the CSA, the team may also need to evaluate any development, production or tools used
to develop, support or maintain the systems in order to safeguard against negative impact on the
SCAI through the use, or misuse , of these tools .

Periodic or reactive CSA's may be performed throughout the lifecycle . These are used to review
existing procedures and performance or to evaluate the impact of a change. These are additional,
not replacement, activities which complement the scheduled FSA's embedded in the safety
lifecycle plan .

4.2.11 Cybersecurity audits

In order to validate the performance of the cybersecurity management system , an independent ,
scheduled audit process should be implemented to evaluate compliance and ensure that any
identified gaps are reviewed and, where appropri ate, rectified .

4.2.12 Cybersecurity configuration and change management

A rigorously controlled configuration management procedure addressing every lifecycle phase
should exist for the IACS software, hardware and procedures (and its directly affecting components)
that have potentia l to impact the cyber r isk analysis or the cybersecurity countermeasure design .
Modifications (not like for like) should be controlled through a management of change procedure
that is capable of identifying and managing changes to the IACS (including the S IS and other SCAI
systems) and cybersecurity countermeasures.

4.2.13 Phys ical security

Cybersecurity is a subset of overall security, with its concerns for potential material theft,
vandalism and physical attacks. Part of this physical securi ty overlaps with cybersecurity to the
extent that it prevents or mitigates the potential for unauthorized access to cyber assets and
subsequent malicious manipulation or theft of its data.

The roles and responsibilities of those responsible for physical security and those responsible for
cybersecurity should be identified and communicated so that the required security level is not
compromised .

4.2.14 Cybersecurity management maturity

ANSI/I SA-62443-1-1 introduced the concept of maturity models relative to the lifecycle and its
respective activities as well as to service providers, using information from Capability Maturity
Model Integration - Services (CMM l-SVC) . Companies should strive to achieve and maintain the
maturity level that is most appropriate for the specific situation. The actual maturity level for a
company today will depend upon how well they have addressed cybersecurity within their
organiza tion (see Table 3 ). Companies who have j ust recently identified cybersecurity as a concern
can expect to initially be at a lower level.
 - 27 - ISA-TR84.00.09-2017

Table 3 - Maturity levels

-Level Leve l Level attributes
description
1 Initial Activities typically performed in an ad-hoc and often undocumented (or
not ful ly documented) manner. Requirements for the activity are typically
specifi ed in a statement of work under contract with the asset owner. As
a result, consistency throughout the lifecycle and within projects may not
be able to be shown .
2 Managed At this level , the organization has the capability to manage the delivery
and performance of applicable lifecycle activities according to written
policies (including objectives). The organization also has evidence to
show that personnel have the expertise, are trained, and/or are capable
of following written procedures to perform the activity.
The organization's discipline reflected by Maturity Level 2 helps to
ensure that practices are repeatable, even during times of stress . When
these practices are in place, their execution will be performed and
managed according to their documented plans.
3 Defined The performance of a Level 3 organization can be shown to be
(Practiced) repeatable across the organ ization as well as being inclusive of its
service providers. Level 3 activities may be tailored for individual projects
based upon the contract and statement of work .
4 Improving Using suitable process metrics, organization controls the effectiveness
and performance of the lifecycle activities .

5 Optimizing Demonstrate continuous improvement in the effectiveness and

performance of lifecycle activities as well as security level effectiveness.

5 Cyber risk assessment phase

5.1 Overvi ew
Figure 3 shows a typical work process flow that integrates the assessment phases of the safety
and cybersecurity lifecycles. As part of any new proj ect involving process industry hazards, a scope ,
detailing what is to be included within the project shou ld be formulated. This should also address
cybersecurity and its relation to the IACS , such as what regulations and standards are to apply .

A requirement in ISA-62443-3-2 1131 is to perform a high level cyber risk assessment. Its purpose
is to help final ize the scope for the project.

In preparation for a high level cyber risk assessment, it is necessary to identify the system under
consideration (SuC). As part of this, initial system architecture drawings should be prepared based
upon corporate policies and standards. A complete inventory of cyber assets that is intended to
comprise the scope of the project also should be developed and documented .

Results from the high level cyber risk assessment should be used to modify initial architectural
drawings I zone and conduit drawings if necessary, once a better understanding of high level risk
is available . It is also important at this stage to consider and provide an initial definition of the
countermeasures to be implemented based upon known potential vulnerabilities. T he zone and
conduit drawings and planned countermeasures provide needed information in order to conduct
the detailed cyber risk assessment required by ISA-62443-3-2 113 1 that follows the traditional
process hazard analysis (PHA).
ISA-T R84 .00.09-2017 - 28 -

The traditional process hazard review , utilizing HAZID, HAZOP, LOPA or other applicable
methodologies , should be performed prior to the detailed level cyber risk review . This sequence
allows the traditional review to identify and analyze the major process hazards that should be
considered when conducting the detailed level cyber risk assessment.

Any major cyber risks identified may need a more rigorous evaluation. This can involve traditional
quantitative consequence analysis techniques and possibly quantita tive cyber threat analysis as
part of the likelihood analysis when determining risk in order to determine if the tolerable risk
criteria can be achieved. If the risk criterion is not met, then additional measures should be
considered until the risk criterion is met.

Once the risk criterion is determ ined to be achievable , a CSRS is documented in a similar manner
to the safety requirements specification (SRS) for SIS so detailed design can begin. Following
development of the CSRS, a stage 1 CSA can be performed as part of the FSA that is
recommended in IEC-61S11 .

Clause 6 addresses the high level and detailed level cyber risk assessments . Clause 7 addresses
the determination of security leve l targets (SL-T) for the zones and cyber assets . Clause 8
addresses the CSRS .

P~ c e' & Pr11ct.ces de:'1re11. e:_..,. re'11ote

.i::ce~ ·ecJ•rt~"11'-"Tll, bc..Jrd;uv cc-.· ce
Oefine Project Scope - - - --.. coif'J"olt OT' r1.e:s. lts.t of l 11
:iartv
coir.ectors.

l
Ide nt fy System Under U?a..atcd SVlte.,, Ater ~cct.1. ·e 01agra"11s.
Consideration [SuC) - - - -• 11rd lr•'"Cito-y v.· ti IACS ntcrr.1
Beg." P·o .,, De. g, ie-v-ce,./n. g:>ci-t 1cer~ "r:c

i
Hig'l Level Cyber R sk ,.or1"rv C· tc•lilv lb,k,rs /Ir:•
Sc.cur ty Lr>., tSLI Ta-geu
Assessment

P·oce~ Haard Ar~~1_,, w/Caraort1te

!
Update P rel mi !lary SuC design f
I" t • Zorc a,c Co•dc t D••w ,,,.
Ruk C: ler •, V• ,.,.~ ly for Assessed Vulne,ab. lities - - - -• •:t••les lc prc,«t .cooc :u reec«f
As..l.CU'T'lerts 11rd At.d lJ
i
l\c, Cy.ocr Comper..1 ig r.•e•1.ro> --+--~ D•o~~,":;:;,•» Rev3ed Zcl'\e ;1rd Cc"1CJ l Ouv.1r1w li
- - - - • SL Tar5eu. rC"CO"T"ll'l'lerd:1t cru a ieeccd

l
h l.,1Zc'1c .rd Co.,c, l Orov,,rp w/
ary re"'11ote 11«e:ss. ?ti -i:t:s 1rd1..ded

To er•b e R~k Ge do ne> Modify orocess des'gn, non

Cc·oo~e R.sk
P·occu Safel)-/Cybc:r R~k Cc :o· • cyber protection and/ or cyber
(· te·., l.l'ot1

Yes l COU'lte,measJres, etc.

Cyi>or Soc"· ty Roe ,,,o.,,.,,l> S:>oc tCSAS)

Oocume"lt Requ re en::s - - -- Cybc· R.><lwo,....,crl

CSA Contribution to FSA 1

Figure 3- Cybersecurity lifecycle assessment phase 1151

 - 29 - ISA-TR84.00.09-2017

6 Hazard and risk analysis

From a process safety perspective in the process industry, there are added concerns beyond data
confidentiality and degraded performance that much of the overall industries focus on . When SCAI
is involved, there are two overriding concerns that set these systems and functions apart when
considering security measures :

• Safety function fai lure to perform when needed . This concern is exacerbated as a cyber
attack poses as a potential common mode that may produce the demand and cause the
safety function failing to respond . This can directly relate to the functional safety
requirement specificat ion (SRS} requirement to identify dangerous combinations of output
states the SIS needs to avoid and to the requirement to assess all protection layers for the
impact of common cause failures with other protection layers and with the initiating source
of the hazard . As a result, when considering cybersecurity, the cyber risk analysis should
be extended to the overall IACS .
• Spurious operation. In this case , the potential goes beyond simply causing a safety function
to spuriously operate. As a cyber attack is more likely to affect multiple safety functi ons ,
the potential business interruption and equipment damage may be much more significant.
When performing the hazard and risk analysis, the methodology should facilitate not only the
identification of potential hazards and vulnerabilities, but also should provide the ability to make
practical recommendations for implementation as well as decisions.

The cybersecurity threat landscape is continually changing , but there are some general
classifications of potential threat agents or sources that an organization should consider, as each
of these could be a cause of cyber incidents .

• Malicious attacker- an individual or group whose objective is to penetrate without

authorization the cybersecurity defenses of a third party computer system or network.
[ISO/IEC-270021 (attacker may be funded by a large organization or a government}.
• Malicious insider-an individual (employee or contractor) who has authorized access to
systems and may be inclined to do harm resulti ng from their state of mind with regards to
the organization.
• Well-meaning insider - an individual (employee or contractor) who has authorized access
to systems and who , during the course of their work, circumven ts cybersecurity
countermeasures in order to · get the job done" and I or inadvertently initiates a cyber event.
• Third-party contractor - an individual or organization that may have privileged access to
the process control system, SCAI system, and/or other control-related systems through an
agreement in order to operate or maintain those systems .
These potential threat agents may exploit vulnerabilities that result in consequences. As with the
list of potential threat agents or sources, the potential vulnerabilities can be qu ite ex tensive. A few
examples of vulnerabilities are included below:

• Software bugs - errors introduced, either intentionally or unintentionally, while

programming the software and/or firmware on devices that allow a threat source to
circumvent cybersecurity countermeasures .
• Hardware fa ilures - failure of devices, for any reason , that results, in the potential
compromise of a system and/or circumvention of cybersecurity countermeasures .
• Cybersecurity countermeasure degradation - cybersecurity countermeasures whose
effectiveness degrades over time and are able to be circumvented due to new cybersecurity
techniques , additional computing performance, and the like, such as encryption techniques
that are broken or using short passwords (re: ANSl/I SA-62443-1-1 definition of password
strength).
ISA-TR84 .00.09-2017 - 30 -

• Credential reuse - using the same set of credentials at multiple locations allows a threat
source to potentially compromise multiple systems.
• Confidential information release - releasing confidential information to a potential threat
source, whether intentionally or unintentionally, that allows the threat source to circumvent
cybersecurity countermeasures. These vulnerabilities could be in both technical and
countermeasures specified by cybersecurity policies , such as by not securing credential
databases, sending passwords in clear text across a network, or targeted social
engineering of employees.
• Systematic errors leading to misconfiguration (for example, failure to change default
passwords) .
• · General Viruses• that are not created to target a particular host, but they may cause
hazards after penetrating into the plant network.
• · unintentional Deactivation of a Cybersecurity Countermeasure" where a cybersecurity
countermeasure is bypassed as an indirect result of an action that is taken for a different
purpose.

EXAMPLE Systematic errors in the design of the system , causing failure of a

cybersecurity measure wh ile working on another cybersecurity mechanism .
• · Designed Security Bombs" that might be implanted in the system during the design phase
to cause damages at later stages during plant operation .

The other aspect when conducting a cyber risk assessment that should be considered are threat
vectors that represent the pathways that various threat agents may use to exploit vulnerabilities
that exist for the system under consideration (SuC) . Additionally, common inadvertent actions that
result in degradation of the cybersecurity of the network, although non-malicious , should also be
considered . Some examples include :

• A well-meaning insider unwittingly introduces malware via a USB port using a flash drive
that had been compromised when using it on their personal computer connected to the
internet.
• A vendor or employee adding an unauthorized wireless access point because wireless was
not available.
• Attaching an unauthorized laptop to the process control network (PCN) to do work.
• Plugging in a cable that (bypasses the firewall) connects the PCN to the internet.
• Plugging both ends of a cable into the same switch or two switches wh ich already are
connected to the network thereby causing broadcast data (storm) to be fed directly back
into the network.
• Defective network interface card (NIC) card causing chatter.
• Equipment plugged in with duplicate IP Address creating IP Address conflict.
• Lab or test environment connected creating duplicate IPs, loops, duplicate HMI connections
etc .
• Modbus , Ethernet/IP, DNP3, and most other protocols having false master send commands
or data to slaves .
• Malware collects system data to be utilized later during an active attack .
• Unauthorized/Inadvertent switch/router/firewall change allows unauthorized , or blocks
necessary, traffic.
• Multi-homed computer gets compromised propagating malware or inadvertent routing
across NICs .
 - 31 - ISA-TR84 .00.09-2017

• Cross-connection of separate segments or zones or redundant network limbs .

• Cross-connection of IACS networks with business (IT}, telecomm or other service networks .
To address the additional contributions to risk posed by potential cybersecurity incidents, the
ANSl/ISA-62443 series of standards requires cyber risk assessments to be conducted . They
include a high level cyber risk assessment and a detailed level cyber risk assessment.

The high level risk assessment can usually be performed at a corporate level to determine in
general what high level risks exist for their various processes. A high level risk review can be
completed using brain storming sessions or a more methodical criticality assessment. These type
of risk assessments are particularly important for new process technology or when no past cyber
risk assessments have been performed. For plants using processes that have been previously
reviewed using a high level risk assessment methodology, a quick checklist approach to determine
if any significant changes exist in the new project scope is a more appropriate means to conduct
this review. If significant changes are found to exist in the new project scope, then a more rigorous
review of those changes and their potential impact would be appropriate.

The more detailed cyber risk assessment should contain aspects of both safety and cybersecurity
and reflect the possible consequences of a failure to provide adequate cybersecurity
countermeasures as well as non-cyber layers of protection where appropriate for a given facility
with a specific design. The major hazards identified during a traditional process hazard analysis
should be considered during the cyber risk assessment. As part of this consideration, some
scenarios may have safeguards that are not prone to cyber attack, e.g ., hard wired safety
instrumented functions , check valves, relief devices, etc. This level of understanding can assist
criticality ranking and prioritization of potential recommendations when conducting a detailed level
cyber risk assessment.

Safety risk assessments are, in general , much more quantitative in nature than those currently
performed for cybersecurity due to the different potential threat sources and relative maturity of
the current analysis techniques . Based upon industry cyber incidents, it should be possible to
create histograms that allow a relative estimate of probabilities for different types of cyber attack.
For instance, it would be expected to see external attacks involving non-targeted malware or
viruses on essentially a continuous basis that would be considered high demand wh ile a targeted
malware attack would be more likely to be seen as a low demand mode attack. This type of
information is necessary in order to estimate risk during a cyber risk assessment, even if it is only
semi-quantitative for the present.

Just as a process hazard analysis requires process safety information, equ ivalent base line
information is necessary to conduct a detailed level cyber risk assessment. This information
includes but is not necessarily limited to :

• Zone and conduit drawings

• Cybersecurity policies currently in place
• Cyber related standards and procedures currently in place
• Corporate risk criteria that can be related to cyber inducted consequences
• Inventory of cyber assets
• Manufacturer cybersecurity manuals
• Service provider cybersecurity capabilities
• List of third party connections
• Vulnerability assessment information that may exist and defined countermeasures to be
implemented
ISA-TR84 .00.09-2017 - 32 -

Just as there are multiple PHA methodologies , there is no single means to conduct a cyber risk
assessment. Example(s) are provided in Annex B.

7 Allocation of Security Levels (SL}

During the high level cyber risk assessment, a first pass may be taken to define security level
targets (SL-T) for cyber assets or cyber asset categories. See Annex B for an example(s)
methodology.

The specified SL for the cyber assets to support the zone security level should be confirmed and/or
modified as needed during the detailed level cyber risk assessment. The sophistication of the
attack and its associated likel ihood are greatly impacted by the specific threat agent and their
motivation at any given point in time. The potential worst case consequences are fixed once the
process (e.g ., chemical, means of electrical generation, etc.) is fixed heading into design. The SL
target should be determ ined as a function of risk, which in turn is a function of the potential
consequences and their likelihood.

Risk criteria for cyber incidents in the process industry should be aligned with risk criteria for
process safety, business interruption/financial loss, and environmental harm . When allocating
security levels, they should be such that reduction against worst case risk is afforded . This
generally includes consideration of worst case consequences . Once worst case risk reduction
requirements are established, as long as it is shown that recognized and generally accepted good
engineering practices (RAGAGEP) have been employed, it is generally not necessary to further
consider lesser risk events with respect to security level allocation and verification, unlike more
traditional safety hazard analysis.

It should be recognized that cybersecurity is necessary for the reliable function of the process
control and SCAI systems , however the reverse may not be true. 1171 SL-T are assigned to zones
and conduits that potentially encompass multiple logic solvers and other associated equipment
such as fire walls, engineering work stations, HMI , etc . This situation allows a targeted malware
attack to potentially cause a demand from instrumented controller(s), while preventing the function
of the alarm layer of protection as well as the SIS as part of a single attack. A lesser effort could
simply attack one of the three aforementioned layers, however, countermeasures that protect
against all three should provide risk reduction against this case as well. In contrast, safety integrity
levels (SIL) are assigned to specific safety instrumented functions. This is a significant contrast in
granularity between functional safety and cybersecurity. Security levels in effect are intended to
protect against the cumulative risks associated with the zone being compromised, while a SIF is
intended to protect against a specific hazard.

When demarcating zone security levels , it is important to take into consideration interdependency
between the zones to implement functional safety. Very often zones are demarcated on the basis
of hardware and software components within the zone without consideration of the safety
functionality. For example , consider a hydraulic valve that is closed on high pressure as part of a
SIF. The close signal for the hydraulic valve is connected to the SIS logic solver, while the hydraulic
system is controlled by a process control logic solver. This is an example of an energize-to-trip
SIF, where utilities should be available in order to take the valve to closed position , i.e ., safe state
in response to a SIF demand . When zone security levels are being demarcated, a typical approach
would to be place the SIS in a zone with a higher target security level than the process control
logic solver controlling the hydraulic system as shown on the left side in Figure 4. However from a
safety risk perspective, it would be sensible to include both the SIS and the process control log ic
solver for the hydraulic system in the same zone and thereby the same target security level as
shown on the right side in Figure 4. An alternative would be to keep them in separate zones, but
implement the same security level.
 - 33 - ISA-TR84.00.09-2017

Zone A Zones Zones

SIS SIS
PLC Logic PLC Log c
Solver Solver

1 0<->Z~•B > S. · ' ( -AI

l
Hyara ulic Hydraulic
Systen System

IL Interface-.....-----.
~ IL nterface - ----.~
.....

FLP Fp
S.-- - Target Security level FLP - Fa il i..ast Pos lion
F P - Fail Last Posit;on

Figure 4- Examples of zone security level demarcation

The likelihood part of risk is dependent on the threats and vu lnerabilities. In tine event different
threat vectors and associated vulnerabilities are evaluated separately from a risk perspective , it is
possible to define different security levels for each threat vector. The security level for each class
of threat vector should be selected based upon the worst case risk identified among the threat
vectors within that class . In such a case, it is possible to have more finely defined security level
requirements within a zone or conduit that results in greater or lesser need for each of the seven
foundational requirements described and defined in ANSl/ISA-62443-3-3 as they relate to the
different security levels.

8 Cybersecurity Requirements Specification (CSRS) for the IACS

A cybersecurity requirements specification (eSRS) should be developed as a separate document
or as part of the SRS with a section dedicated to cybersecurity countermeasure requirements. The
intention is to document what is required to achieve and maintain the necessary security level(s)
while not adversely impacting necessary IAeS funct ions . Selection of the cybersecurity
countermeasures should take into account the ability to support interoperability of different
manufacturers' devices without degrading the achieved risk reduction , the reliability (spurious trip
rate), or the communication speed of the SeAI. In some cases, the eSRS is necessary to support
a competitive bid .

The eSRS should address the following as a minimum :

• A high-level description and depiction of the Sue should include as a minimum :

- name;
- high-level description of the function and the intended usage of the Sue ;
- description of the equipment or process under control ;
- illustration of the Sue and associated data and process flows .
• Plant/Facility zone and conduit drawings .
• Description of all general cybersecurity countermeasures required for all zones and
conduits.
• Description of target cybersecurity level for each zone and conduit having a potential impact
on the IACS.
ISA-T R84 .00. 09-2017 - 34 -

• List of third parties with external interfaces and type of connection for each:
- Modbus ;
- Profi bus;
- OPC ;
- IEC-61850 ;
- DNP3;
- Wireless (ISA-100, WiHART, 802.11 );
- Other vendor system-specific protocols .
• Description of all cybersecurity countermeasures required for each documented third party
interface.
• Requirement that the cybersecurity countermeasures should not impact the performance of
the SCAI system .
• If the cybersecurity countermeasure(s) has the potential to impact the overall response time
of the safety functions , then the response time impact of the cybersecurity countermeasure
should be incorporated in the evaluation of the overall response time of the safety functions
(for example, the time from process deviation detection through the process response to
fina l element action).
• Definition of the safe state of the process for each identified countermeasure.
• Target security level to be achieved for each zone.
• Security level (SL) risk reduction expected to be achieved by each countermeasure as a
function of threat vector.
• Requirement for cybersecurity testing, e.g.:
- penetration testing ;
- vulnerability assessments;
- white hat.
• Cybersecurity countermeasure inspection and test frequencies .
• Response time requ irement for each countermeasure to bring the process to a safe state.
• Requirements for manual action as part of countermeasure, for example , physical isolation
of the control network from enterprise network/DMZs , etc.
• Disaster recovery requirements for restoring full functional ity following actuation of a
countermeasure.
• Remote access requirements, e .g ., safeguards for remote access.
• Description of system hardening measures to be implemented .
• Management support requirements for countermeasures .
• User access control strategy to be implemented for IACS, including SCAI systems .
• Physical access restriction requirements.
• Required virus prevention and detection measures to be employed on the control network ,
as well as frequency of scans .
• Patching strategy and requirements to be implemented where relevant to the IACS ,
including SCAI systems .
• Upgrade strategy to address emerging and future potential threats as they become known .
• Frequency of detailed cyber risk assessment revalidation.
 - 35 - ISA-TR84.00.09-2017

• Required network communications uptime (at all levels) with required need for high
reliability of network devices. Network specification should consider frequency of network
upgrades.

9 Cybersecurity design and implement phase

9.1 Overview
Figure 5 shows the various activities during the design and implement phase . Once the CSRS is
provided, an iterative design process between network, IACS, and process safety personnel should
take place to ensure that the planned layers of cybersecurity countermeasures, including policies,
procedures equipment, software capabilities, and level of rigor are appropriate for the
cybersecurity performance expectations.

The zone and conduit drawings coupled with the specification of cyber assets and the CSRS
comprise the conceptual design . The security levels recommended during the detailed cyber risk
assessment should be verified. Should the risk criteria not be met, alternate means of risk
reduction may need to be considered . Once security level verification has been completed and it
is determined that a tolerable risk level can be achieved with the proposed design , detailed design
can begin . In parallel with the detailed design , the procedures to test and validate the cybersecurity
countermeasures should be developed . Following completion of design , a stage 2 CSA can be
performed as part of the FSA that is recommended in IEC 61511 .

The test procedures should support the cyber portions of the factory acceptance test (CFAT) and
the site acceptance test ( CSAT), as well as the initial validation of the cybersecurity
countermeasures. This work parallels and should be conducted as part of the SCAI verification
and validation .

Following the CFAT, the IACS is delivered, installed and the commissioning begins . Once all
devices in the SuC have been installed, connected , and configured, a CSAT may be performed .
An initial validation of the cyber countermeasures should be conducted , just as an initial validation
of the SCAI is conducted.

Concluding this phase of the lifecycle is the pre-startup safety review (PSSR) that checks to make
sure the system is ready and capable of performing as it was defined and that all of the
recommendations made during the detailed level risk assessment have been appropriately
addressed. Ensuring that the cybersecurity countermeasures are in place and have been tested
and ready to go is part of the overall PSSR . The cybersecurity contribution to the PSSR would be
considered the stage 3 CSA and shou ld be performed as part of the FSA that is required in process
safety management industry standards as well as IEC 61511 .

Clause 10 covers the countermeasure design and engineering, security level verifica tion , and
activities up to and including the CFAT . In the event cybersecurity countermeasures alone cannot
achieve the necessary risk reduction, other means of risk reduction are also addressed in Clause
10. Clause 11 covers installation and commissioning, the CSAT and the initial validation. The
PSSR is addressed in Clause 12.
ISA-TR84 .00.09-2017 - 36 -

Detailed Cyber Risk

Assessment
From Assess Phase
Cyber Risk A5Sessment
Perform Conceptual
CSRS Cyber mplementation
Vendor Cyber Manual --+ Design, Establish Strategy
Alternate Means Risk Zone/Conduit Model
Software Platform OS
list of 3•d Party SW I
Enterprise Requiraments Reduction lntarfaces
Countarml!dSuras
'Ille tries
Security Level Tast Procedures
System Specs
Ve rification
~
Tolerable Risk Guidelines --+ No
Tolerable Risk7 ...._., or

Yes
•
•
Vendor Cyber Manual
Software Platform OS _.• .• Detailed Spec1fica1;ons
Final Zone and Condui t Model .....
• Enterprise
Raqulrements
___. Detailed Design &
Procedure Development 1 •
•
cyber Implementation Strategy
lnspect>On and Test Proced ures
Defined Metrics
QJ
.0
a-
"'c:0
Design
Meets Spacs?
~ '£
c:
::J
CSA Contribut:on to FSA 2 u..
Yes .....0
System Integration Phase
-c:
QJ
E
(Buy I Build I configure) QJ
1:11)

"'c:
nspactlon & Test
Procedures ---. Cyber Security FAT
"'
~

Installation I Commissioning

• Inspect. on & Test

Procedures
• Cuuent inventory, sw ___. Cyber Site Acceptance Test - - --. Updated SuC inventory
system versions, etc.

• •As Found. As Lah• Resu Its

Inspection &Tast Initial Validation of • Upddted Inspection & Test
Proced ures - - --. Procadures (if Req'd)
Countermeasures

Cyber secunty Checklist Pre Startup Safety Review

Questions CSA Contribution to PSSR & FSA 3
(PSSR}

End Design/Engineering/Implement Phase

Figure 5- Cybersecurity lifecycle design and implement phase 1151

 - 37 - ISA-TR84.00.09-2017

10 Design and engineering

10.1 Cybersecuri ty concept
The conceptual design is intended to document how the system under consideration is going to
satisfy the CSRS as well as all other functional needs . That is, the conceptual design describes
· how· a system is intended to come together to meet cybersecurity requirements while still
supporting the operability, safety, and overall reliability performance targets of the facility. From a
cybersecurity perspective, the countermeasures proposed in the conceptual design should protect
the IACS to the security levels required in the CSRS and be able to support the NIST elements
(reference Figure 2) of detection and metrics. At this stage, the product suppliers may or may not
be known . It is important to understand that if the equipment that is selected does not or cannot
fully align with what was reviewed in the detailed level cyber risk assessment, a reevaluation of
that risk assessment and associated lifecycle steps should occur.

Even when the equipment is fully known, countermeasure design will still most likely be an iterative
process. Balancing the needs of the specification(s) with the infrastructure of the plant I intended
architecture I enterprise integration that delivers the target operability, reliability, and safety that
is aligned with the maintainability and support objectives of the facility is a challenge. As changes
are proposed , they should be evaluated against the risk assessment and any revisions documented.

The following information are inputs necessary in order to fully develop the conceptual design:

Cyber risk assessment

• CSRS
• Vendor cybersecurity manual - See Annex F
• Enterprise requirements - The envisioned support I infrastructure components I ocated
outside the IACS. Examples include local or enterprise domain controllers for authentication ,
remote access servers, anti-virus management systems, etc. The choices made based on
these factors and how they play a role in the overall cybersecurity solution will affect th e
ongoing supportability, business cost model of the installation.
• Software platform OS - the PC based software operating system
• T he software platform OS version information is used to understand the vulnerabilities and
level of application within the IACS system(s) (server vs workgroup vs domain, remote
desktop vs alternative tools, etc .). This information also allows the user to j udge useful life
and sustainability of the platform . That is, is the platform current? Having this information
is essential to creating a baseline that allows the user to request additional data regards
future supported revisions. Finally, the operating system for the platform(s) on which the
IACS, SCAI , and cybersecurity countermeasures reside should be compatible with all
software components used over the lifecycle of the system . For example, the applications
should be compatible with the OS service pack level , the supported anti-virus software
version , and also the business enterprise anti-virus management console software. If the
scope for compatibility is not established in the conceptual design and verified in the
detailed design, the cybersecurity countermeasure strategy may have long term
supportability issues that degrade the level of cybersecurity envisioned .
Please note , that if the product supplier(s) is not yet chosen, then the prospective product
supplier(s) should be asked to provide the information that defines how their proposal fits into the
overall project goals (bid basis). The following tables show recommendations as to how these
components fit into the proposal and evaluation (conceptual design) process .
ISA-T R84 .00.09-2017 - 38 -

Table 4 - Conceptual design inputs when product supplier is unknown

Con ceptual design Inputs I Information avallablllty How used In co nceptu al design
Cyber risk assessment Should be known Internal document
CSRS Should be known Provided for product supplier proposal
Vendor cybersocurity manual Unknown Provided as a result o~ product supplier proposal
So'twaro platform OS Unknown Provided as o result o' product supplier proposal
Enterprise requirements Envisioned business Provided for product supplier proposal
requirements

If the product supplier is known, these documents are used to determine how the needs of the CSRS fit into the overall IACS architecture
and business enterprise .

Table 5 - Conceptual design inputs when product supplier is known

Conceptual desi gn Inputs Information availabili ty How used In conceptu al design

Cyber risk assessment Should be known Internal document
CSRS Should be known Itemizes safeguards to be employed
Vendor cyborsecurity manual Should be known Used to understand how tho proposed architecture I zones
!safeguards it Into the operability! reliability I maintainability
goals of the project
Software platform OS Should be known Used to understand additional vulnerabilities of the proposed
system and access solutions proposed
Enterprise requirements Should be known Used in conjunction with tho proposal to understand how tho
proposed architecture I zones I safeguards I boundary
devices impact to the enterprise I Infrastructure envisioned
 - 39 - ISA-TR84 .00.09-2017

Topics for consideration during the development of a conceptual design of cybersecurity

countermeasures include:

• How the IACS design will communicate and integrate with the business enterprise network
or remote support personnel .
• How the IACS countermeasure design will meet the CSRS performance requirements and
fit into the NIST framework (reference Figure 2) elements of protection and detection.
• How the countermeasure design will integrate with the plant goals for operability, reliability,
maintainability.
• How the day to day work processes of the plant operations and technical support staff will
be affected by the decisions made during this step. For instance, if the IACS Engineering
station login and authentication is based on accounts located in the domain server, the
domain server becomes an integral part of the IACS installation. There may be new roles
and effects that should be passed on to the operating team.
The items shown above emphasize why a collaborative and iterative process should be followed.
It would be a rare case where no compromise is necessary on the part of any stakeholder (IACS
engineer, network engineer, cybersecurity engineer, and operating I support staff).

The evaluation of a proposed conceptual design of countermeasures should also include :

• How the solution fits into the product suppliers' offering regarding warranty, performance,
and system responsibility.
• How the solution fits into the IACS technology roadmap. In concept, security level and the
lifecycle of the asset should be commensurate with the technologies proposed . An example
could include technology that is nearing their · end of life " or are noted to have vulnerabilities
inconsistent with the security level required by the CSRS .
• How the solutions fit into the plant business enterprise network and the resultant lifecycle,
MOC , and procedures managed by the classic IT organization .
• How the solution fits into project goals regards maintainability. Emphasis should be placed
on the architecture I implementation I software design choices so as to consider the impact
of sustaining the SL of the cybersecurity solution (for example, software upgrades in order
to maintain target performance levels with the overall plant maintenance schedules) .
In addition to refinement of many of the previous documents, the following documents are outputs
of the conceptual design of cybersecurity countermeasures :

• Cybersecurity implementation strategy - The intended path forward : Agreed upon details
regarding how the IACS will meet the requirements of the CSRS , intended elements and
strategies of detection.
• Zone and conduit model (revised).
• List of 3 rd party software interfaces (identified) .
• List of countermeasures necessary to meet risk targets .
• Metrics - Practices for threat frequency and countermeasure performance data capture and
evaluation, which may be passive (review of logs) or active (dynamically notified).
Conceptual procedures necessary to support the lifecycle performance measurement of the
cybersecurity system as installed (will be refined as the design and implement process
continues).
• Test procedures - Conceptual test plans to verify the cybersecurity strategy functions as
designed (will be refined as the design and implement process continues) .
ISA-T R84 .00.09-2017 - 40 -

NOTE It is important to conside r that what was described addressed a single platform in a typical plant. There may be
interaction among various platforms in the plant that also need to be addressed as a contig uous whole. Wh en multiple
s uppl iers arc use d on site, the end user should ensure that overall compatibility is achieved and to coordinate between
product suppliers as needed.
10.2 Other means of cyber r isk reduction
There are two aspects that should be considered regarding other means of risk reduction with
respect to cybersecurity. In the first case , it may not be possible to implement sufficient
cybersecurity countermeasures in a particular system that may be needed to satisfy a security
level target. This may be due to the inherent lack of capabilities in the components that make up
a system, or due to the potential weakness of administrative procedures and enforcement to
achieve a particular security level.

For significant process safety consequence severities , it is good practice to look at other
safeguards that are not subject to cyber attack. Consideration of these other means of risk
reduction is an iterative exercise between the traditional PHA and the cyber risk assessment .

Examples of other means of risk reduction that may be considered include but are not necessarily
limited to :

• safety c ontrols not vulnerable to cyber attack;

• hard wired interlock systems;
• pressure relief valves ;
• check valves .
In the second case , failures of cybersecurity countermeasures may occur during operation.
Examples include improper maintenance , zero day vulnerabilities, or purchased exploits. For this
reason, multiple countermeasures may be necessary. It is best to consider during the risk
assessment what types of failures may occur and to either include fau lt tolerant designs or have
temporary compensating measures pre-reviewed during the design phase and ready to go should
the need arise. These can be thought of as tools that are available for use until the situation is
repaired and brought back to the desired state.

Examples of compensating countermeasures include but are not necessarily limited to:

• fault tolerant boundary device designs ;

• removing access to the internet or network ;
• isolation of the IACS from the DMZ and/or business network;
• temporary barriers to access to non-essential personnel;
• temporary guards (that is, physical access limitations not normally required) .
10.3 Security level verif ication
When a security level verification is performed , it relies on the outputs of the conceptual design
and cyber risk assessments. This includes:

• zone/conduit drawing ;
• detailed cyber risk assessment report ;
• countermeasures as a function of threat vector;
• metrics ;
• test procedures.
 - 41 - ISA-TR84.00.09-2017

Currently, the suite of ANS l/ISA-62443 published and draft standards require security level targets
(SL-T) that have been established in the cyber risk assessments to be verified so that they can be
compared to a security level capability (SL-C). See annex B for examples of risk assessment
methodologies and annex D for examples of SL verification. In the event that the SuC does not
satisfy the SL defined necessary to satisfy the risk criteria defined by the end user, then the SuC
should be upgraded with suitable countermeasure(s) or other means of risk reduction. Design and
Development of Other Means of Risk Reduction is covered in 12.2.
These seven founda tional requirements are described as follows:

• FR-1 Identification and Authentication Control (IAC);

• FR-2 Use Control (UC);
• FR-3 System Integrity (SI);
• FR-4 Data Confidentiality ( DC};
• FR-5 Restricted Data Flow {RDF);
• FR-6 Timely Response to Events (TRE};
• FR-7 Resource Availability (RA}.
These foundational requirements are written as a combination of prescriptive and performance
based design and operations system requirements. In a number of cases the foundational
requirements do not fully describe the specific countermeasure implementation necessary to
achieve certain security levels. This is especially true when the requirements are performance
based. The foundational requirements do however provide a starting point from which
countermeasure design can begin to be documented by describing what system attributes are
necessary to obtain a specific security level.

Verification of a specific countermeasure design against these attributes will involve evaluating
the cybersecurity strength of any components in the zone to be defended . Where technically
possible, concepts such as mean time to compromise should be considered . If the zone consists
of components that have weak cybersecurity strength , and therefore can be compromised relatively
easily, then multiple countermeasures may be necessary to achieve the target security level.
Annex D is intended to provide some worked examples of security level verificat ion using a semi-
quantitative approach.

10.4 Detail ed design

This phase executes the plan set forth in the conceptual design document. Details of the IACS
operating system and the compatibility with the product supplier recommendations (vendor
cybersecurity manual) are questioned deeper.

At this point in the process, the product supplier, architecture , version, and all specifics are
chosen. As a result of the security level verification activities, input has been received from the
persons and organizations performing lifecycle activities so that the final strategy can be
documented , any "proof of concept" tests can be performed, and detailed design can commenc e.
Countermeasures hardware, device configuration programming, and procedures are designed to
support lifecycle management requirements, including countermeasure maintenance as well as
online (dynam ic alarm ) and offline (analysis of logs) detection and metric mechanisms. The
resulting countermeasure systems should also fit into the overall mission of the IACS and Safety
system . The goal is to final ize all aspects of the cybersecurity solution so that the next phases
may be conducted as efficiently as possible with minimal re-work. This includes the initial design,
the metrics, the work process and production impacts to operations, and the long term
sustainability plan of the system . All should work together to meet the intended level of
performance and draft the necessary documents for the sustainment of the system.
ISA-TR84 .00.09-2017 - 42 -

The input documents for this step i n the process are listed in Figure 5 . In addition , all the
conceptual design deliverables are additional inputs to this step.

Typical activities that may be included in this step:

• The cybersecurity implementation strategy, zone and conduit details and security level
targets are discussed with all stakeholders (network , IACS engineer, safety engineer,
operation , and maintenance personnel, and the product supplier). The design and
sustainment goals and strategies are agreed .
• Required policies , procedures , and mechanisms for sustaining the countermeasures are
developed and agreed . Examples include software upgrades, patches, maintenance
outages, etc.
• Detailed organizational requirements for implementing, operating and maintaining the
countermeasures are developed . Roles and responsibilities for administration of the system
are developed and agreed upon .
• Identification of any · proof of concept" lab testing that will be needed so that all aspects of
the design can be verified to function as specified .
• As new cybersecurity threats are always present, a review of technical currency should be
done (i.e ., IACS alerts, vendor identifi ed vulnerabilities and patches, etc .) at project
milestone reviews. T he design should include countermeasures to all known threats at the
time .
• Update conceptual inspection and test procedures .
Outputs from this step include:

• Detailed countermeasure specifications (regarding the specific applications, software,

versions, utilized in accordance with the final zone and conduit model, all necessary
sustainment documents identified above) .
• Final zone and conduit model.
• Updated cybersecurity implementation strategy (revised to include envisioned
authentication/ authorization policies including roles and responsibilities for those who will
maintain the system, e.g., passwords, administrators, software patching processes, all
necessary sustainment documents identified above, etc .).
• Updated inspection and test procedures, including necessary pass I fai l criteria and tests
necessary to assure the cybersecurity solutions. T his includes day to day work process
tests, intrusion detection protocols, metric inspection and testing protocols, any expected
degraded state failure tests, etc.
• Definition of metrics to be implemented with response and recover requi rements, including
any periodic analysis of data required by those metrics .
10.5 Detailed design verif ication
As part of the proj ect detailed design reviews, the fi nal countermeasure design is evaluated against
the CSRS to ensure the design meets the functional performance requirements and related IACS
cybersecurity standards. Failure to do so will result in correction of the detailed design so that the
verified security level will be achieved. The results of the detailed design review of cybersecurity
countermeasures is an input to the safety lifecycle detailed design verification (stage 2 functional
safety assessment).
 - 43 - ISA-TR84.00.09-2017

10.6 System Integrati on

(Buy I Build I Configure)

This stage executes the agreed upon designs while building and configuring the system in
accordance to the overall functional specifications. Focus shifts to execution , qualifications of the
integrator, and cybersecurity management during the build and configure phase . The goal during
this phase is to build an integrated system that meets the functiona l specifications and ensuring
that the system has not been compromised during this phase of work (such as insertion of malware}.
Proper handling of the equipment and adherence to cybersecurity principles during the integration
process are essential. The integration team should be trained and have demonstrated competence
to carry out work on the system . The training and demonstrated competence should be at least
equal to the design security level of the system being integrated . Some examples of specific items
for consideration in the competency review include :

• demonstrated competency by training on cybersecurity countermeasures and procedures ;

• proper handling of equipment protected by cybersecurity countermeasures ;
• understanding of applicable industry standards (ANSl/ISA-62443, ISA-84.00 .0 1, etc.};
• understanding of IACS and enterprise stewardshi p standards (NI ST framework) ;
• integrating company policies and procedures regard ing cybersecurity control of proj ects;
• recovery I return to out of box state procedures ;
• use of periodic logs I sampling ;
• past examples of enforcement I improvement of cybersecurity rules .
There may be a need to • turn off' some cybersecurity countermeasures during certain portions of
the buy I build I configure I install phase . It should be acknowledged that some cybersecurity
countermeasures may not be active in this phase, or are not available while performing certain
tasks. Some examples include account setup, times when disconnected from network
infrastructure, etc. During these times, special care (alternate means of risk reduction } should be
taken.

10.7 Cybersecurity FAT (CFAT)

The execution of a countermeasure test plan should take place during factory acceptance test or
other suitable offli ne laboratory environment. A realistic simulation of the enterprise environment
should be considered as well as all the actual component versions I applications under test. This
test can be after the traditional FAT , but it should be conducted prior to shipment to the site . This
is done to allow time to resolve any issues prior to commissioning and startup.

The CFAT confirms that cybersecurity countermeasures have been properly set-up and configured
in accordance with the CSRS and all other agreed documents .

As new cybersecurity threats are always present, and significant time may have passed since the
purchase of the equipment, a review of technical currency should be done (i.e ., IACS alerts ,
product supplier patches, etc .). The system's countermeasures should be current to all known
threats at the time of CFAT. If it is not possible to take the latest updates, a written understanding
between all parties should occur.

Inputs to this work are the inspection and test procedures and countermeasure detailed design
documents. The CSRS and all other documentation related to countermeasure identification or
design should be available for reference as the tests are conducted.

Test outputs include a signed (pass I fa il) response and any notes and observations for the purpose
of revising and improving the overall cybersecurity solution and work process.
ISA-T R84 .00.09-2017 - 44 -

11 Installation, commissioning and validation

11 .1 Overview
The cybersecurity requirements (e .g., CSRS, company policies and procedures, detailed design
documents, etc.) implemented during the design portion of the lifecycle should be continued during
insta llati on, commissioning and initial validation . The procedures used to validate the cybersecurity
of the SCAI systems should be used to provide a foundation for the ongoing mechanical integrity
program, such as inspecti on , preventive maintenance, and testing (re : ISA-TR84.00 .03-20 12, see
Bibliography) . Note that the installation, commissioning , and validation team should show the same
demonstrated competency as the integration team. It is critical for the system to remain
· uncompromised" (for example, no introduction of malware) , during this pre-operational phase .

11 .2 Cybersecurity Site Acceptance Test (CSAT)

Field activities should allow time to ensure that the cybersecurity countermeasures are
implemented, updated (if required ), and ready to test. A large portion of this test is to verify that
the system is up to the recommended level of technology currency. As at prior significant project
milestones, the technology currency of the countermeasures is reviewed.

Documents used in this phase are the system inventory along with inspection and test procedures .

The specific output of this phase is an updated system inventory with any updates shown as well
as any additional reference document revisions .
Anytime large changes are made to the system, there is potential for disruption in the
commissioning process due to system issues that may occur. Every change (e.g., firmware ,
software updated, network engineering integration , connectivity, patches , etc.) should be analyzed
for reliability and safety impacts to the plant and I or stability of the software platforms. Proposed
or discovered modifications tha t could impact achieved security levels should be reviewed for
impact on the cyber risk assessment before implementation or upon discovery.

11.3 In it ial validation of countermeasures

Similar to the initial validation of the IACS and safety systems, an initial validation of cybersecurity
countermeasures should also take place .

Essentially, this is a repeat of the inspection and test procedures under independent evaluation
plus any additional tests necessary to confirm the installed business enterprise connections
against the approved design .

At a minimum :

• Countermeasures are tested and practiced with plant support personnel pre sent.

• Access control hierarchy is setup and fi nalized .

• Typical support work processes and procedures are final ized and tested .

• Metrics collection systems are reviewed and tested in the production environmen t.

• Deviations are discussed and resolved following change management practices, including
the update of documentation .

11 .4 Pre-Startup Safety Review (PSSR)

A PSSR is a requirement within process safety management regulations. A stage 3 CSA should
be incorporated as part of the PSSR. It is intended to be conducted for new facilities and for modified
facilities when the modification is significant enough to require a change in the process safety information.
 - 45 - ISA-TR84.00.09-2017

The pre-startup safety review is supposed to confirm that prior to the introduction of highly hazardous
chemicals to a process:

• Construction and equipment is in accordance with design specifications .

• Safety, operating, maintenance, cybersecurity and emergency procedures are in place and
are adequate .
• A process hazard analysis (including cyber risk assessment) has been performed and
recommendations have been resolved or implemented before startup; and modified
facilities meet the requirements contained in management of change .
• Training of each employee involved in operating a process or responsible for the
cybersecurity countermeasures has been completed .

12 Operate and maintain phase

12.1 Overvi ew
Figure 6 shows the various activities during the operation and maintain phase . Once the PSSR
demonstrates the plant is safe to startup, transfer of ownership occurs between engineering and
operations. The operations personnel execute startup activities putting the plant into normal
operation .

Process safety risks once defi ned , can be relatively stable as long as the management of functional
safety is maintained. Cybersecurity is an ever-evolving environment which is highly dependent on
the motivation of the attackers as well as changing technology. Events such as political,
environmental, economic, and public image can change how a company may view risk of cyber
attacks or in some cases actually increasing the likelihood resulting in increased risk . As the
cybersecurity landscape changes , a plan of response should be put in action , as needed , to reduce
the risk to the tolerable criteria set by the authority having jurisdiction, e.g., end user.

As such, it is the end users' responsibility to ensure the continued useful life of the cybersecurity
countermeasures, i.e ., its technology currency. Procedures should be in place to measure
performance capability and make improvements shou ld they be determined to be necessary. This
is done on a routine basis as part of cybersecurity monitoring and measurement against metrics.
In some cases, this monitoring may require immediate action to respond to a threat.

Periodically, a validation of the countermeasures should be performed that is the equivalent of a

proof test or the mechanical integrity revalidation in accordance with process safety management
regulations. As part of this , performing a vulnerability assessment versus the most current
recognized and generally accepted good engineering practices (RAGAGEP) should be considered
in addition to measures against specific performance criteria established and documented in the
CSRS.
ISA-T R84 .00.09-2017 - 46 -

From
Design/Engineering/Implement Phase
Detailed Cyber
Risk Assessment

Startup

Operation

Monilonng Prooodures
Security Monitoring and
Evolving threat Metrics
Landscape Mitigate Attac
voe
Security Events mplement Upgrades
Immediate
Threat Assess men ls Threat?
...
QJ
Performance Indicators ..c
~
No ro
c:
Conditions requlnng 0
immediate?, Intermediate '€
c:

nspectlon & Test

Procedures
Cyber Security
Countermeasure
Maintenance
or long te?rm act.on

t
Maintenance? Records
-
::J
u..
0
.....
c:
QJ

'lew RAGAGEP _ . . , Vulnerability Assessment

E
QJ
(Mechanical Integrity Report tlD
ro
Evolving threat Program) c:
Landscape
ro
~
Vulnerability Assessment
Periodic Yes
Assessment?

CSA Contribution to FSA 4

No

\11anage?ment of Modifying
Yes
Chal'lge? Procedures ~ System Under Consideration
(SuC)?

No CSA Contribution to FSA 5

No Yes
Decommission?

Figure 6- Cybersecurity lifecycle operate and maintain phase 1151

 - 47 - ISA-TR84.00.09-2017

Process safety management regulations also call for periodic revalidations or reassessments to
ensure that the assumptions made in the process hazard review are still current and correct. For
cybersecurity, this means revalidation of the detailed cyber risk assessment based on what has
been learned in the interim and how the sophistication of cyber threats has evolved.

Just as the PHA should be periodically revalidated after gaining experience in operating and
maintenance, the revalidation work process should account for cybersecurity. The intent is to
validate assumptions made during the detailed cyber risk assessment and to correct the cyber risk
assessment as applicable.

Performing a cyber vulnerability assessment is a key part of this reval idation , which also serves to
fulfill a stage 4 CSA as part of the FSA that is required in IEC 61511 .

Any time there is a management of change, potential impacts on cybersecurity should be

considered.

After modifications and prior to decommissioning , a stage 5 CSA can be performed as part of the
FSA that is required in IEC 61511 .

Finally, if a portion of the facility is being decommissioned , the fu ll lifecycle , treating it as a new
project should be considered to ensure that the remaining plant and equipment are not adversely
impacted.

Clause 14 covers the management of cybersecurity during the operation and maintenance phase
of the lifecycle, including mechanical integrity, bypassing, and periodic assessments that should
be performed. Modification impacting cyber risk or cybersecurity countermeasure design is
addressed in Clause 15. Decommissioning is addressed in Clause 16 .

12.2 Oper ation

Following start-up , the plant continues with operation . During this time the plant is exposed to
potential cyber attacks . Metrics that were defined in the design phase should have been
implemented as well as the countermeasures that were determined to be necessary to achieve the
security level(s) documented in the CSRS .

12.3 Cybersecurity metrics

Cybersecurity for a SCAI system is a relatively new subject but, in fact, has always been an
inherent part of SIS design. For example , a SIS is by design independent and difficult to gain
unauthorized access . Cybersecurity and SIS's share much of the same design attributes . Both are
concerned with physical and logical access. Both are concerned with change management
authorization processes and making sure that only authorized people and authorized systems gain
access to the SIS . For this reason , it makes sense in the early stages of cybersecurity metrics
development to work on those metrics that benefit both the safety system i ntegrity and the
cybersecurity countermeasure SL. Subclauses 12.3 through 12.6 contain early stage metrics that
should be implemented without waiting on a risk assessment.
NOTE These metrics focus on sa'ety sysiems that do not have a shared network.
12.4 Phys ical security of a SCAI system
An owner operator that has not completed cybersecurity risk assessments for their SCAI systems
should start their cybersecurity program by managing physical access to the cyber systems
connected to the SCAI systems and logic solvers without waiting on a formal risk assessment.
Securing physical access help in minimize cyber intrusions. Any unauthorized physical access to
a SCAI system would be outside of acceptable limits. Example questions that might be used to
develop physical security metrics are:

• Are all SCAI l ogic Solvers in an access controlled environment?

ISA-T R84 .00.09-2017 - 48 -

• Are all SCAI Logic solvers in a locked cabinet?

• Is authorized access reviewed at documented intervals?
• Are there controls in place to remove access immediately to someone that has become
unauthorized?
• Are controls in place to prevent SCAI logic solvers from being programmed/configured
remotely from a different network segment?
• Are there exceptions to the above during a regularly occurring aud it?
12.5 Unauthorized access of a SCAI system
Once physical access is gained , a user typically has access to the SCAI logic. A simple
measurement, if it is available, is the number of failed user access attempts. Failed attempts should
be investigated by the user. Any attempts that cannot be validated or explained would be outside
of acceptable limits . Example questions that might be used to develop an unauthorized access
metrics are :

• Are roles and responsibilities for each type of account on the SCAI system defined and
documented?
• Are passwords changed at documented intervals?
• Are procedures followed to immediately remove access to users that no longer have
authorization?
• Are there exceptions to the above during a regular occurring audit?
12.6 Authorized change management of a SCAI system
Another cybersecurity mitigation that can be done without waiting on a risk assessment is to
confirm that all changes to a SCAI system are authorized . Unauthorized changes can affect the
integrity of the safeguard as well as the SL of the countermeasures . This metric can be as simple
as matching program changes in the SCAI applica tion program to an authorized change
management request. Any deviations to this would be outside of acceptable limits. Example
questions that might be used to develop an unauthorized user access metrics are :

• Are there changes in the SCAI system that are not authorized by an approved MOC
document that are discovered during a regul ar occurring audit? (yi n)
12.7 Unauthorized communi cation w ith a SCAI system
Contemporary cyber incidents have demonstrated that cyber attacks and malware associated with
portable media have the ability to bypass boundary countermeasures . The purpose of these
metrics are to measure the risk associated with portable media . Portable media includes USB flash
drives , external/removable hard drives , CDs, DVDs, Zip/Jazz disks, data tapes , floppy disks, etc.;
also known as "removable media". Any portable media used to communicate with a SCAI system
would be part of this metric . Example questions that might be used to develop an unauthorized
user access metrics are :

• Is all portable media scanned for malware prior to communicating with a SCAI system?
• Is all portable media used to communicate with a SCAI system authorized in a written
cybersecurity policy?
• Are all USB ports on a SCAI system physically or logically disabled?
• Are there exceptions to the above during a regular occurring audit?
Refer to Annex E for further deta ils on cybersecurity metrics.
 - 49 - ISA-TR84.00.09-2017

12.8 Cybersecurity t h reat events

Threats may or may not be immediate . A documented plan should be in place that specifies how
responses to intrusion demands are addressed and responded to considering their urgency. The
high level risk assessment should have provided a starting point for how to begin mitigation and
the procedures should have been fully developed during the design phase and implemented prior
to startup.

Following an attack that was or was not partially successful, it should be analyzed to determine
what upgrades should be considered to reduce the likelihood in the future.

12.9 Normal mai ntenance

The SCAI system software and the cybersecurity countermeasure software should be updated as
needed . Consider ation should be given to the management scheme such as a regular checking
procedure from the SLC point of view, and the technical scheme such as a regular audit of the
antivirus software and log.

As part of normal maintenance, patching should be performed as applicable . End users should
assure that all firmware upgrades have been implemented securely and that no unauthorized
firmware changes have been made . Additional guidance may be found in ANSI/I SA-TR62443-2-3-
2015.

Updates to antivirus/application/embedded software should be validated by the responsible party

and tested before implementation. Prior to actual installation on site, end users should consider
impacts of the changes.

When SCAI system workstations are updated , an authorized person should be present at the
workstation to either perform the work or monitor the work if being done remotely, with the ability
to terminate the session if problems arise .

Backup and restoration means and procedures of all the SCAI network configurations should be
provided and tested on a defined periodic basis.

12.10 Mechanical integrity

A mechanical integrity program should be developed for the cybersecurity countermeasures that
include inspection and testing on a defined basis. This should adopt applicable features of a
vulnerability assessment.

Following any changes to a cybersecurity countermeasure , it should undergo revalidation to ensure

it will provide the expected SL.

12.11 Inspection/Aud it
Diagnostics , remote access to calibration information , and on-board device description features
can provide an increased level of assurance that the corresponding device is in place and in
working order. The user should assure that the diagnostics, remote access to calibration
information , and on-board device description features have not been compromised.

Cybersecurity countermeasures should be non-intrusively inspected at defi ned regular intervals

and validated against CSRS requirements. They should also account for possible changes in a
network physical structure and software settings made between inspections. A report of an
inspection should be prepared and maintained .

12.12 Remote access

Allowing remote access to SCAI systems is a high risk task as it has the potential to create
significant cybersecurity vulnerabilities , especially when bypassing countermeasures that may be
present in higher network levels. Examples include allowing access for remote operation,
ISA-TR84 .00.09-2017 - 50 -

di1agnostics, and programming. Disabling or removing remote access capabilities should be

considered when possible.

Prior to allowing remote access :

• Management approval should be obtained following a risk assessment.

• The remote access should be for a limited duration.
Remote access should be provided with the minimum following controls:

• Authentication sufficient to ensure that an approved person is accessing the SCAI system
to perform programming .
• Confidentiality - all flows crossing public networks (for example , the internet) should be
encrypted; refer to ANS l/ISA-62443 for guidance .
• Integrity - adopt and implement visiting PC/laptop cybersecurity policies. External PCs
should have a supported antivirus protection program running , with a recent virus signature .
Refer to ANSl/ISA-62443 for guidance.
• Remote access and communication of application external to the SCAI system should not
be able to interfere neither with the operation of the SCAI nor the safety-critical
communications .
When remote access to the SCAI system is required , consideration should be given to having a
person that is competent in cybersecurity and SCAI systems on site who has primary
responsibility for any work being done and has:

• the ability to monitor activity that is being performed remotely ;

• permanent and full control of the remote access (initiation and stop);
• the ability to manually return the plant to a safe state independent of the SCAI system ;
• management practices for the approval of personnel and level of access to the SCAI system .

For example, this may be needed to have corporate personnel or vendor support personnel provide
needed work on the SCAI system . When this occurs, access to the SCAI system should go through
all of the boundary detection devices and safeguards (see the figures in Annex A) .

Whenever remote access to the SCAI system is allowed, sufficient cybersecurity controls should
be in place to ensure that:

• The host device that is used for remote access meets guidelines as set forth in the
cybersecurity policy, including installation of antivirus software with acceptable revision of
signature files.
• Use of host-based firewall s, and operating system/application software patches have been
applied per company and vendor guidelines .
• All activities of the remote session are maintained in a cybersecurity log fi le .
• Whenever remote access is permitted , there should be no potential for split tunnel ing.
• The data and the communication path between the authenticated remote user's computer
and the computer connected to the SCAI system should be implemented in a manner that
prevents unauthorized disclosure or modification of the data.
• Additional monitoring , such as intrusion detection techniques, should be used on all remote
connections to assure that no abnormal activity or actions occur while the connection is
established .
 - 51 - ISA-TR84 .00.09-2017

• Remote access should be for a limited time and remote access ports closed after the access
is complete .
12.13 Bypasses
B,ypassing (disabling) cybersecurity countermeasures should not in any way directly impact the
ability of any SCAI from performing its safety function . In addition, the cybersecurity
countermeasures should not compromise the SCAI bypass requirements.

In the event there is a need to bypass a cybersecurity countermeasure :

• The duration should be kept to a minimum .

• Diagnostics should alert appropriate personnel at repeated intervals.
• Dates and times of bypass should be recorded and reported to independent third-party
administrators within the company.
• Bypass should time out with automatic restoration where feasible .
• While the bypass is in place, compensating measures should be in place to ensure the
SCAI is not compromised . For example, disconnect the SCAI system from the network and
ensure that those engaged in interfacing to the SCAI system when in the bypass mode are
trusted , as well as to follow all the policies, procedures and countermeasurns
commensurate with the applicable security level.

12.14 Tools
Tools and procedures for updating cybersecurity countermeasures should be provided and tested .

Tools that can be compromised via viruses , malware, and the like and used while performing
configuration, test, or repair activities should be dedicated for that purpose and not be exposed to
other systems. This applies to all equipment within the SCAI system , sensor, logic solver and smart
final elements. Special consideration should be given to any intelligent device that may be used in
the testing , configuration, and commissioning of smart field devices (both point-to-point and
network-based devices) .

Any tool intended to be used for work on a SCAI system should be tested for malware , and
cybersecurity patches for all software components (operating system , client applications , vendor
tools, and the like) should be applied per vendor's recommendations prior to connection or use on
a SCAI system .

12.15 Periodic assessments

To comply with process safety management, periodic assessments should be performed that allow
the lessons learned from within the plant and industry to be compared versus the vulnerability and
detailed level risk assessments to revalidate that the security level targets are appropriate and
whether they are being achieved. The competency of personnel with SCAI lifecycle responsibilities
in related cybersecurity tasks is also part of the periodic assessment scope . Any deficiencies found
should be addressed .

13 Mod ification
Changes to the overall IACS and safety system may occur due to many reasons. First is the
process safety requirements, second, and perhaps more frequent, are the needs to maintain
technical currency and cybersecurity countermeasure risk reduction. Items such as system
obsolescence , product supplier and operating system patches and revisions, operating system
updates, and network system upgrades as well as accommodations for new business strategies
are typical reasons for the modifi cation(s).
ISA-TR84 .00.09-2017 - 52 -

Just as shown in the basic work process (Figure 2) and the operation and maintenance phase
detailed work prncess (Figure 6), modifications to the IACS, including the SCAI system,
cybersecurity countermeasures should follow a management of change program fu lly consistent
with the requirements of process safety management, ISA-84 .00.01 (IEC 6151 1-1 Mod), and the
cybersecurity work process. An analysis should be carried out to determine the impact on
functional safety and cybersecurity as a result of the proposed modification.

Any modification (see Figure 6) should trigger an analysis for impact. The change should be
evaluated against both the process safety information (safety lifecycle) and the cybersecurity
information (cybersecurity lifecycle) as developed and implemented .

In general , these changes should be in accordance with the conventions set forth in the project
documents and suggested adherence to:

• product supplier's safety manual;

• product supplier's cybersecurity manual;
• all business network integration agreements I policies I work process documents that
support the cybersecurity countermeasure implementation (as described in this report).
Examples of items that should undergo MOC include but are not necessarily limited to:

• Changes to access restriction to the maintenance/engineering interface (see Annex A).

Restriction of access can be procedural, designed and controlled via network, and I or
additionally controlled via local plant key locks with active monitoring metrics .
• Changes to administrative policies/procedures that define the conditions under which the
maintenance interface may be connected to the system during normal operation. This may
involve procedural , or designed and controlled via closed network access ports that require
MOC to open , creating online metrics and make available for use .
• Changes to written approval with reasons for access .
• Changes to documentation of persons allowed access and what work individuals are
permitted to perform via written approval process.
• Changes to documentation of required training and/or familiarity with the system before
access is permitted. (See section on competence and system integration (buy I build I
configure) competence .)
• Changes to documentation of the circumstances that allow access to be permitted ; this
includes the procedures that control the use of maintenance bypasses.
• Changes to the use of virus checking software and appropriate program and file handling
procedures in the engineering workstation or other components inside the safety zone (see
Annex A) to help avoid corruption of the embedded andlor appl ication logic. (See 10.6 on
competence and system integration (buy I build I configure) competence .)
• Changes to the use of metrics used in the SCAI system utility software that tracks revisions
in the application logic and allows the determination (after the fact) of when a change was
made, who made the change , and what the change consisted of.
• Changes t o methods dealing with unauthorized and authorized access (remote or local) to
the process control or safety system logic solvers and 1/0 (see Annex A).
• Changes to any logic that can affect the proper operation of the SCAI (time delays, set
point changes , maintenance bypasses , and SCAI device configuration changes) .
• Software and firmware patch updates .
Based on the evaluated impact of the proposed modification , the tasks performed by personnel
with SCAI lifecycl e responsibilities may change. Training should be performed when modifications
 - 53 - ISA-TR84.00.09-2017

are made to personnel responsibilities, work processes, procedures or tools prior to

implementation of the change .

14 Decommissioning

Decommissioning should undergo a full SLC analysis .

If decommissioning is intended to shut down or remove all the facilities at a site , then cybersecurity
analysis is necessary once the exact method and timing for each decommissioning step is defined.
The resulting cybersecurity analysis may require revisiting and modification of previously
established method and timing for each decommissioning step .

Since decommissioning is an infrequent event, lack of experience in this process is common . Thus,
an effort should be made to include all plant personnel familiar with the facility (for example,
operating, maintenance , management, engineering, controls, IT, safety) in the decommissioning
planning .

Before proceeding with decommissioning , all parties involved with this activity should fully
understand and implement as appropriate the cybersecurity issues addressed above in Clauses 4
through 14 inclusive. The following will only list typical cybersecurity issues resulting from
decommissioning in an effort to help the reader to develop a proper decommissioning cybersecurity
plan .

As-built information should be available before proceeding with any andl all aspects of
decommissioning so that existing security level (SL) and other cybersecurity-related
countermeasures, conduits, and zones are not compromised and decommissioning steps can be
planned properly.

While it is possible not all of the SLC phases apply for any given decommissioning , each phase
should be considered . Listed below are the SLC phases providing simple decommissioning issues
often encountered that are related to that phase .

• Hazard and Risk Assessment (H&RA) - The H&RA should identify risks related to
cybersecurity created through:
- improper decommissioning sequencing resulting in loss of, or reduction of,
cybersecurity;
- loss of protection in zones, conduits , process control systems, or SCAI systems;
- impact of decommissioning on utilities (for example , electrical, steam , instrument air)
that could impact the operability of programmable electronic devices used as
cybersecurity countermeasures (for example , overvoltage, under voltage , instrument air
pressure abnormality) ;
- the impact of new plant personnel and impact on existing plant personnel noted in the
introduction above.
• Allocation of security levels to countermeasures - The need for countermeasures will be
based on the results of the cyber risk analysis. This may include the addition of new
countermeasures or the modification of existing countermeasures .
• CSRS for the cybersecurity countermeasures - Assuming either of the above two bullets
results in modifications to existing specifications documented in the existing CSRS, the
CSRS should be updated.
• Design and engineering of cybersecurity countermeasures - While the previous three
bullets can result in the need for design and engineering , an additional consideration
includes the temporary construction design and engineering requirements that may be
needed to safely and securely maintain production of existing facil ities while
decommissioning is underway. T his temporary construction may induce new cybersecurity
ISA-T R84 .00.09-2017 - 54 -

issues that should be addressed in the cyber risk assessment and subsequent steps as
needed .
• Design and development of other means of risk reduction - Loss of existing
countermeasures, or need for additional countermeasures may require the design and
development of other means of cyber risk reduction .
• Installation, commissioning and validation - Any additional or modified cyber risk reduction
implementation should consider the need for installation , commissioning and validation .
• Operation and maintenance - Maintenance and operating procedures and training should
be implemented if the implementations of earlier bullets noted above are determined to be
necessary .
• Competence of the people involved in decommissioning work is necessary to confirm all
participants have the necessary training and knowledge of the cybersecurity impact of the
decommissioning prior to performing these tasks.
Based on the evaluated impact of the decommissioning , the tasks performed by personnel with
SCAI lifecycle responsibilities may change . Training should be performed when modifications
are made to personnel responsibilities, work processes, procedures or tools prior to the
decommissioning .
 - 55 - ISA-TR84.00.09-2017

Annex A -
Example SCAI interfaces
A.1 Overview

This annex presents a series of example IACS/SCAI network cybersecurity architectures. The
examples are conceptual and not intended as a template for every system . For example, the
firewall symbol in the diagrams could represent a number of network cybersecurity control devices.
The examples are intended to represent different approaches an end user might elect to
incorporate a safety controls , alarms and interlocks {SCAI) system into the overall control network
architecture . These are for illustration purposes only to promote more critical thinking when making
decisions and are not intended to indicate any type of approval by virtue of being included in the
comparison . The example figures do not fulfil the requirements of zone and conduit drawings. For
more information about zones and conduits, and details on the implementation requirements for a
variety of countermeasure devices and practices, please refer to the ANSl/ISA-62443 series of
standards.

None of the displayed examples are prohibited by IEC 61511-1 [2016] . However, in most of the
examples there are potential common mode or dependent mode failures created by the choice of
network architecture that may require advanced SCAI design and management techniques to
adequately address. These failure modes will impact the design, SIL verification, and systematic
error management systems for the safety systems , per the requirements of IEC 61511-1 [2016) .
The impacted requirements include, but are not limited to , subclauses 9.2.5, 9.4, 11 .2, and 12.2.4.
As the scope of this technical report is limited to the SCAI and related IACS cybersecurity related
aspects , other design and management system implications will not be discussed here . Further
guidance on the treatment of common mode and dependent mode failures between SCAI
protection layers, or between SCAI and the process control system , is provided in ISA-TR84 .00.02
and ISA-TR84 .00.04 .

While enterprise networks , business networks , and process information networks {demilitarized
zones) are not directly included in the scope of this technical report, these network zones may
represent a threat vector to the SCAI system or may contain countermeasures that impact the
integrity of the !ACS from external cyber threats. Therefore, these higher network levels are
considered to a limited extent in this annex.

The seven examples presented in this annex represent different levels of management rigor
necessary, based on differing degrees of interconnection between the SCAI zone(s) and other
zones in the architecture . What path and degree of integration an end user decides upon and may
be supported by good engineering practice is very much a function of their risk tolerance given the
relative severity hazards contained within their processes. This annex was developed simply as a
means of comparing a small subset of potential network architectures that are known to
conceptually exist within industry today. Each successive example represents substantially
increasing challenges to designing and maintaining SCAI cybersecurity against the following seven
foundational requirements defined in ANSl/ISA- 62443 - 1- 1 (99.01.01 ):

1) Identification and authentication control (IAC) - Identify and authenticate all users (humans,
software processes and devices) .
2) Use control (UC) - Enforce the assigned privileges of an authenticated user (human,
software process or device) to perform the requested action on the IACS and monitor the
use of these privileges .
3) System integrity (SI) - Ensure the integrity of the IACS to prevent unauthorized
manipulation
4) Data confidentiality (DC) - Ensure the confidentiality of information on communication
channels and in data repositories to prevent unauthorized disclosure .
ISA-T R84 .00.09-2017 - 56 -

5) Restricted data flow (RDF) - Segment the control system via zones and conduits to limit
the unnecessary flow of data .
6) Timely response to events (TRE) - Respond to cybersecurity violations by notifying the
proper authority, reporting needed evidence of the violation and taking timely corrective
action when incidents are discovered .
7) Resource availability (RA) - Ensure the availability of the control system against the
degradation or denial of essential services .
Table A.1 provides a comparison of relative network architecture resilience to some selected
typical cyber attacks on example SCA! systems as addressed in more detail in A.2 through A.7

The communication system architecture should always be verified against the requ ired security
level for the zone with which it interacts. Increased flexibility or availability of communication
systems may lead to increased risk of cybersecurity being degraded or compromised . Achieving
the security levels 1-4 for each of the detailed sub-requirements within the seven foundational
requirements is largely dependent on the specific controller, networking , and countermeasures
chosen for a given application. Therefore, the analysis below focuses on the high level impact the
selection of architecture has on the ease or difficulty with respect to achieving the overall
cybersecurity objectives for the SCAI. In each example architecture, it is assumed that all safety
functions, including safety controls , safety alarms , and safety interlocks are executed on the safety
controller. As a result, the safety zone should include all the hardware {including the safety HMI)
necessary to execute the safety functions. For more information regarding implementation
requirements for each security level within the seven foundationa l requirements , refer to ANSl/I SA-
62443-3-3 (99 .03.03).

In addition to a high level risk analysis addressing the foundationa l requirements, a set of three
typical cyber threat vectors will be considered for their potential to compromise the SCA!
controller(s) in each example architecture. Al though not included in the examples , the same
ana lysis methodology can be applied to other zones , e .g. , process control zone, process
information network zone, etc. The following provides a short phrase that will be used within the
examples as well as a longer description of the intended cyber attack scenario:

External attack (i .e., malicious attacker) - An attack initiated by an external entity, entering the
overall control network from an internet connection to the enterprise level , with the intended
consequence of interfering wi th the functionality of the target control system . T his type of
attack can result from random malware propagati ng throughout the internet or be
specifically targeted . The more dangerous targeted attacks often result after a period of
intelligence gathering and the theft of authorization and authentication information followed
by actual modification of process control and I or SCAI logic or data.
Modification by remote user (e.g., authori zed third party support) - An attack resulting from a
modification , originating from a user that has authorization to make remote access to the
process control network, that has the unintended consequence of interfering with the
functionality of the target control system. This attack may enter the overall control network
from the internet connection to the enterprise level (the authorized user will be passed
through the outer levels of cybersecurity countermeasures), or may enter through a direct
connection (wireless , broadband or dial-up) incorporated into the PCN portion of the IACS
or directly into the target controller for the intended purpose of remote support.
Internal use of portable/mobile media - An attack resulting from the physical attachment by an
authorized person within the organization of portable/mobile media that inserts mobile code
or malicious code that can interfere with the functionality of the target control system .

Other general assumptions for the first six architecture examples:

• As shown in Figure A 1, the overall architecture of the network includes a process control
system and a SCA! system , such as a SIS. The facility mainta ins a level 3 process
 - 57 - ISA-TR84.00.09-2017

information network (PIN), sometimes referred to as a demilitarized zone (DMZ), to limit

the network traffic from the level 1 process control and SCAI systems and level 2 process
control network (PCN) from interacting directl y with the level 4 enterprise zones . The facility
also maintains a control center that monitors and has supervisory control , via the process
control network . For logistics purposes, the process control system interacts with the
enterprise zone , which eventually connects to the internet through the enterprise firewall.
• Other than the logic solver and network component sharing shown in some examples, other
components of the individual SCAI functions , including sensors , final elements, and
application programming, are independent from each other and from the control functions.
• All components in the SCAI zone for each of the examples shown in this annex are
assumed to be managed per ANSl/I SA-84 .91 .01 and, where applicable ,
ISA-84 .00.01-2004 Part 1 (IEC 61511-1 Mod) requirements.
• The overall failure of any communication interface designed to not adversely affect the
ability of the SCAI to bring the process to a safe state.
• Some interfaces allow an operator at the process control HMI to be able to send commands
to the SCAI (via communication link or hardwired) for the purpose of initiating safety
functions or resets while at the same time preventing changes to SCAI application software.
If an operator performs one of these commands, there is a repeat confirmation step to
protect against operator error.
• W ith any connected architecture, if programmable write access is required , it is called out
and addressed in the cybersecurity risk assessment.
• The goal of the cybersecurity risk assessment is to prevent unauthorized or malicious
changes to the SCAI application program(s).

'1'IM W-..1
" I 4

t..e.el
1

t..e.el
•
Figure A.1 1181- 0verall automation network showing hierarchical levels

As the level 3 and 4 networks do not differ among the following six examples, the associated
figures will not show these levels. In all of the examples , the other devices on the process control
network, such as the supervisory controller and the firewa ll leading to the process information
network, connects through the network switch associated with the process controller.
 ISA-T R84 .00 .09-2017 - 58 -

There are other architectures in the level 3 and 4 networks that can have significant implications
for cybersecurity. For example, if the process information network (P IN) functions are performed
on the enterprise level, then there w ill be fewer countermeasures available to the information
stored on data historians , domain controllers, etc. For this reason, all network components that
are essential to continued safe operation in the event of a network attack (e.g ., data historians
used to execute advanced control) should be located within the process control network zone or
lower within the architecture.

As in a traditional risk matrix, the colors in Table A.1 indicate increasing levels of risk. See Annex
D for example risk matrix .

Table A .1-Comparison of network architecture resilience to typical

SCAI system cyber threats
- SCAI• •process controller
I Summary SCAI SCAI cybersecurl ty from SCAI
-
network architecture cybersecurlty attack by authorized cybersecurl ty
from external remote user of process from Internal use
attacks v i a controller of Infected media
enterprise level
Internet
-
Air-gapped (2 zones ) Only No direct SCAI No SCAI exposure to Requires loca
hardwired 1/0 exposure to remote user access counterme asures
connections external attacks to prevent
exist via enterpnse unalJthorized
between internet access to SCAI
SCAI and connections and unintended
any other use o' in'octed
network media
-
Interfaced (2 zones ) Dedicated
--
Drooagation o'
-
COM to COM Requires loca
-
point-to-point attack from commun cations usually countermeasures
network orocess contro er cannot be used to provide to prevent
between to SCAI sys tem is remote user access from unalJthorized
SCAI system oossib c , but the proceu controller to access to SCAI
and process nvolvcs breaching the SCAI system. Loss of and unintended
controller the PCN and the proceu controller use o' in'cctcd
navigating the should not impair SCAI media
CO M to CO M action.
communication
orotocols as well
as tho intoroosing
' irowall between
the process
controller and the
SCAI system
Integrated systems with SCAI system SCAI HMI and Remo te access to modify Requires loca
isolated networks ( 2 zones) and process engineering con ' igurat1on I pa rameters countermeasures
controller are workstation are 1n SCAI is poss Ole Need to prevent
connected exposed to cyber to est ablish unalJthorized
via a networ attacks that countermea sures to access to SCAI
between breach the PC orcvcnt lJnintcndcd or and unintended
SCAI and network and unacceptable consequence use o' in'cctcd
process de'eat the of authori zed change as media
controller nterpos ng firewall well as remote user
network 10 a'fect the SCAI authc nt cation
switches network switch.
using
commercial
off the shel
(COTS)
device s
 - 59 - ISA-TR84.00.09-2017

SCAI • ·process controller Summary SCAJ SCAI cybersecurl ty from SCAI

network architecture cybersecurl ty attack by authorized cybersecurlty
from external remote user of process from internal use
attacks via controller of Infected media
enterpri se level
internet
Integrated systems wi th SCAI system o onger have SCAI Requires loca
shared network (panial 2 and process network switch providing countermeasures
zone) controller support of nterposong to prevent
(along with firewall, such as additional unauthorized
respective remote user authentication access to SCAi
HMls) share or countermeasures and unintended
a single aga nst unintended or use o' in' ccted
network unacceptable consequence media
switch of authorized change to the
SCAI

Combined systems with SCAI system Requires local

strong dependency (1 zone) and process countermeasures
controller to prevent
(along with unauthorized
respective access to SCAI
HMls) share and SCA.I 110
a single network and
network unintended use of
switch. an infected media
engineering
station, and
an 110
network

Shared logic solver One logic Requires local

solver countermeasures
performs to prevent
both process unauthorized
control and access to ttte
SCAI s ngle logic solver
functions. and unintended
Shared use o' infected
cngineermg media
workstation.
Potentially
independent
HMls.

A.2 Ai r-gapped (2 zones)

Figures A.2 and A.3 illustrate " a i r-gapped~ conceptua l designs for the SCAI system integration .
From an external threat perspective, this design represents the highest level of independence
between the process control system and the SCAI system. In this design , the SCAI system is both
logically and physically isolated from communicating with the rest of the zones . Hardwired
connections are maintained between the SCAI and process c ontrol systems for monitoring of
individual variables only and do not contain any digital communicatio n information. Separate
engineering workstations , IAMS and human machine interfac e (HMI ) systems are maintained for
the SCAI and process control zones .
ISA-TR84 .00.09-2017 - 60 -

__1n
_pu
_ 11__ • :=:.:=! •3 •'" •" "' •11

Input 2
''~""'· ,.. -~ '""""'""""''
Figure A.2- Block diagram of air-gapped systems (2 zones)

Lev 12

l ev•I 1

Lev I 0

Scntof Final Control

Eltlll(!nt 1

Fi gure A .3 1181 - Ai r-gapped systems (2 zones)

Evaluating the safety (SCAI ) zone in the air-gapped architecture against the seven foundational
requirements for cybersecurity and three attack scenarios:

IAC - Air-gapped SCAI network will have physically separate identification and authentication
control from the process controller portions of the network. Passwords or tokens used as a
means of SCAI network user authentication should be different from those used for the
process control network. SCAI network human user identification and authentication
features should only recognize the individuals specifically trained to interact with the SCAI
system .
UC - A ir-gapped SCAI network will have physically separate use control protocols from the
process controller portions of the network. Human user authorization to the SCAI network
should be limited to the individuals specifically trained to interact with the SCAI system .
SI - Communication to an air-gaped SCAI network, and hence the potential to impact data
integrity, will require physical access. Physical access countermeasures can reduce
unmitigated cyber risk to SCAI network data integrity. If implemented per the SCAI
standards, corrupted signals hardwired to the SCAI logic solver from the process controller
will have no capability to interfere with the functiona lity of the SCAI.
DC - Accessing air-gapped SCAI network data will require physical access, with the possible
exception of the few points of SCAI data hardwired to the process controller, which is
typically connected to the higher levels in the network. Physical access countermeasures
can reduce unmitigated cyber risk to the confidentiality of data that is res tricted to the SCAI
network.
 - 61 - ISA-TR84.00.09-2017

RDF - Air-gapped SCAI network is physically segment ed from all other networks within the
overall control system . Zone boundary or other data flow is physically controlled.
Portable/mobile media are a threat to the zone boundary and should be rigorously managed .
TRE - Timely response to cybersecurity violations of an air-gapped SCAI network is largely
dependent upon the physical access control monitoring. SCAI network will need local
access logging to provide forensic evidence once any insufficiencies in portable/mobile
media management are revealed through SCAI performance problem upon demand or
periodic testing.
RA - Air-gapped SCAI network exposure to a distributed denial of service attack is highly
unlikely as it is not connected to the internet. Denial of service however would be possible
should an internal person intentionally or accidently violate the air-g1apped zone and
connect it to the internet. In addition , a communication fa ilure within the zone will result in
some measure of denial of service. Internal communication failures are just as likely in any
of the zone architectures.
External attack - A fully air-gapped SCAI network installation will have no permanently
connected exposure to external attacks
Modification by remote user - A fully air-gapped SCAI network installati on will have no remote
user access capability.
Internal use of portable/mobile media - An air-gapped SCAI network remains vulnerable to this
cyber attack. General physical access countermeasures will not be effective against the
human users that are authorized to interact with the system . Physical interactions with air-
gapped SCAI networks should be eva luated for necessity and rigorously controlled .
Resources and technology should be provided to test portable/mobile media prior to use on
air-gapped SCAI networks for malicious and mobile code that may have been introduced to
the media during the manufacturing process or through previous connections to other
networks or devices.

A.3 Interfaced (2 zones)

Figures A .4 and A .5 illustrate an "interfaced" conceptual design . In this example, the SCAI system
and process control system are still connected using hardwired connections, but they now include
a direct point-to-point communication connection. This point-to-point connection does not travel
over the same network interface that is used for other communications (for example , to the
engineering workstations or HMI). These types of point-to-point communications may use either
serial or Ethernet connections depend ing on the specific protocol being used .

In an interfaced design , the process controller outputs to the SCAI system (for example, shutdown
commands via discrete output card) should be communicated via hardwired connections.

J r::i-F l-' ~= t· Umltoct ,

Flrt1w11ll S1trl, I nr £ llll'fO I]
Ou1p1111 • Fin I lorn nt 1

Umltad

Sen'IOr 2 Input 2 ~.r= ~= l . Outpu12

Figure A.4- Block d iagram of i nterfaced systems (2 zones }

ISA-TR84 .00.09-2017 - 62 -

Level 2

Level 1

Com Types

S . - FiMI
1~1·
LevelO
ser- Fftll
2 a..-.&2
Control Safety J
Figure A .5 11111 - Interfaced systems (2 zones)

Evaluating the safety (SCAI) zone in the interfaced architecture against the seven foundational
requirements for cybersecurity and three attack scenarios:

IAC - Interfaced SCAI network will have physically separate identification and authentication
control from the process controller portions of the network. Passwords or tokens used as a
means of SCAI network user authentication should be different from those used for the
process control network. SCAI network human user identification and authentication
features should only recognize the individuals specifically trained to interact with the SCAI
system . Device to device identification and authentication at the border between the
interfaced zones is limited to only the connection between the controller COMs.
UC - Interfaced SCAI network will have physically separate use control protocols from the
process controller portions of the network. Human user authorization to the SCAI network
should be limited to the individuals specifically trained to interact with the SCAI system .
SI - Interfaced SCAI network is exposed to digital communications through the controller CO Ms
or physical access. The COM to COM communications is often stringently limited in format
and may be using communication protocols not commonly present in commercial off the
shelf (COTS) networking systems. This provides some degree of cyber risk reduction.
DC - COM to COM communication can typically pass much more information than can be
achieved by point to point hardwiring. Data communicated from the SCAI to the process
controller will be exposed to the same degree of cybersecurity data confidentiality risk as
the data that is native to the process controller.
RDF - Interfaced SCAI zone is logically segmented from the other networks within the overall
control system , with the boundary being the interposing fi rewall between the two COMs .
Restriction of data flow between the zones is achieved by the interposing firewall, the COM
protocols of each controller, and any data validation programming within the controllers.
TRE - A cybersecurity violation alert, where supported by the SCAI controller and process
controller technologies and application, may be passed to the process controller and
communicated further up the network levels to a monitoring organization.
RA - No significant change in denial of service risk is created in changing from an air-gapped
to an interfaced architecture. If implemented per the SCAI standards, the degradation of
communication performance from the process controller will not prevent the execution of
the SCAI functions.
 - 63 - ISA-TR84.00.09-2017

External attack - While now possible, an external attack against an interfaced SCAI controller involves navigating past the higher
level countermeasures (which address the vulnerabilities of the COTS hardware and communication protocols used up to and
including the process controller network switch), passing the limitations of the process controller operating system, the process
controller output COM limitations, the interposing firewall, and the SCAI input COM and then being able to affect the SCAI
controller operating system . Attacks against the SCAI HMI include passing the SCAI network switch.
Modification by remote user - COM-COM information communications normal ly cannot be used to perform remote support
modifications to the SCAI itself. No significant change in denial of service risk to the safety zone (SCAI) is created in changing
from an air-gapped to an interfaced architecture. If implemented per the SCAI standards, the communication of data from the
process controller will not be essential to the execution of the SCAI functions.
Internal use of portable/mobile media - No significant change in risk against portable/mobile is created in changing from an air-
gapped to an interfaced architecture.

A .4 Integrated systems with isolated networks (2 zones)

Figure A. illustrate an "integrated with isolated networks (2 zones)" conceptual design. In this example, the process control and SCAI
systems are fully integrated and provide direct, real-time communication between the systems. Information from the SCAI zone can be
communicated to the process controller and higher-level systems for monitoring purposes. This information should be read-only flowing
from the SCAI zone out to other systems.

This example also allows for systems in the SCAI zone to pull information from other systems on the network (for example, ope rating
system or software updates) in a controlled way over the network instead of using physical media. Information pulled into the SCAI zone
should not come directly from the Internet, but some intermediate location from within the PCN or lower-level system.

J s..or1 """"'

<
< Process Conlro Network

SCAI Network

Oulp•ll2 • ,.... t - 2

Figure A.6- Bl ock diagram of integrated systems w ith isolated networks

ISA-TR84 .00.09-2017 - 64 -

l 2

l 0

Control Safety

Figure A.7 1191 - Integrated systems w ith isolated networks (2 zones)

Evaluating the safety (SCAI) zone in the integrated with isolated network architecture against the
seven foundational requirements for cybersecurity and three attack seen arios :
IAC - Integrated systems with isolated networks, where the communication is usually taking
place between COTS network switches , are more likely to have very similar if not identical
identification and authentication methodologies. The achieve ment of the objectives
discussed in the interfaced example will be more dependent upon the expertise of the
personnel configuring the two switches and interposing firewall. The device-device IAC
controls at the zone boundary now address all components in the two networks.
UC - Use control at the zone interface firewall and network switches in an integrated system
with isolated networks typically address the intended separation of use control between the
two networks, with possible support by host-based countermeasures.
SI - Communication integrity between the two zones is generally exposed to the same level of
cyber risk as is data for the process controller, due to the COTS nature of the network
communication across the zone boundary. Proper implementation of the firewall and
network switch monitoring is critical to limiting exposure between the zones.
DC - Data confidentiality for SCAI network information is generally exposed to the same cyber
risk as is data for the process controller, due to the COTS nature of the network
communication across the zone boundary. Proper implementation of the firewall parameters
is critical to limiting exposure between the zones .
RDF - The SCAI zone is logically segmented from the other networks within the overall control
system , with the boundary being the interposing fi rewall between the two network switches .
Physical segregation is still possible, so long as the communicated data is not essential to
process control or SCAI operation . Restriction of data flow between the zones is achieved
by the interposing firewall and any data validation programming within the controllers . RDA
may be supported by rules implemented within the network switches, but the COTS nature
of this component increases the vulnerability beyond COM to COM communications.
TRE - Cybersecurity violation alerts can be communicated from the SCAI network to the
process control network.
RA - A denial of service attack that reaches the SCAI network switch now has the potential to
affect the SCAI human machine interface (HMI). This has the potential to directly impair the
display or annunciation of safety alarms used as process safety protective layers as well
as any safety alerts used to maintain the SCAI performance.
 - 65 - ISA-TR84.00.09-2017

External attack - An external attack against the SCAI controller can now approach the SCAI HMI and engineering station directly
through attacks against typically COTS hardware and communication protocols.
Modification by remote user - Remote access to perform modifications of the SCAI logic/parameters is possible in this architecture.
Countermeasures should be established to prevent unintended or unacceptable consequences of intentional modification (e.g.,
a controller version upgrade initiated by remote support causing a system shutdown).
Internal use of portable/mobile media - Malicious or mobile code inserted into the process controller network now has a path to
impact the SCAI network. Countermeasures should be established to prevent propagation of malicious or mobile code from the
initially infected network.

A.5 Integrated systems with shared network (partial 2 zone)

Figure A. illustrate an "integrated with shared network (partial 2 zone)" conceptual design. This example is similar to the integrated 2
zone example in A.4. The SCAI and process control systems share one network, which may provide greater ease of communication
between those systems and higher-level systems in the architecture. However, the SCAI system and process controller can no longer
be isolated from each other at the interposing firewa ll without impairing some SCAI function (i.e., loss of the SCAI HMI used to annunciate
safety alarms). In this case, the standard process control components of the system should be designed and maintained at the higher
cybersecurity requiremen ts necessary for the zone (i.e., there is one effective zone with respect to cybersecurity in practice).

In some commercial integrated systems, there may be only a single HMI and engineering workstation . These systems are able to
communicate and control bot h the SCAI system and the process controller. This type of situation can exist when an organization
decreases capital expenditures by reducing the duplication of equipment. From a cybersecurity basis, such a design would approach
the increased risk of a "combined systems with strong dependency' architecture (see A.6).

PrDc ~
Outiul 1 • F.W Flllmfont 1

< Shared Contra lor ctwork

:.

f S-W2 } ll>olA 2 PnlC J

L
(Mpoa2 r FNI Element 2

Figure A .8- Block diagram of integrated systems with some shared network SCAI functions (1 zone)
ISA-T R84 .00.09-2017 - 66 -

Level 2

L v&l 1

Com Typos

S.1'llOI' nn•
1 l!.lement 1
LevelO
2
SeMor F......,
2 E._, 1112

S.1"$0<"
1
F..,
Element 1
Control Safety J
Figure A .9 1181 - Integrated systems w ith some shared network SCAI funct ions (partial 2
zone)

Evaluating the safety (SCAI ) zone in the integrated with shared network architecture against the
seven foundational requirements for cybersecurity and three attack scenarios:
IAC - Integrated systems with a shared network can only operate as a single cybersecurity
zone, as the SCAI functionality (e .g ., safety alarm annunciati on) and process controller
functionality (e.g ., operator interaction with control loops) pass through the single network
switch .
UC - The separation of access to the SCAI engineering station and controller are performed
by the interposing firewa ll or host- based countermeasures.
SI - Communication integrity to the SCAI controller has one fewer opportunity to monitor, due
to the elimination of a separate SCAI network switch . Physical network isolation between
process controller and SCAI is no longer possible , as this would isolate the SCAI controller
from the SCAI HM I.
DC - Data confi dentiality for SCAI information being passed to the SCAI HMI is exposed to
identical cyber risk as is data for the process controller
RDF - There is no segmentation between the SCAI and process controller zones, due to the
common network shared between the two. Physical segmentation is no longer possible
without impact to data communication essential to process controller and SCAI functionality.
TRE - Cybersecurity violation alerts can be communicated from the shared network.
RA - A denial of service attack that reaches the shared network switch now has the potential
to affect the SCAI human machine interface (HMI ). This has the potential to directly impair
the display or annunciati on of safety alarms used as process safety protective layers as
well as any safety alerts used to maintain the SCAI performance .
External attack - An external attack against the SCA I controller can now approach the SCAI
HMI and engineering station directly through attacks against typically COTS hardware and
communication protocols, with one fewer network switch to support cybersecurity
countermeasures (and no additional firewall in the case of the SCAI HMI ).
Modification by remote user - Risk is not significantly increased against this attack through
change from isolated to shared networks, as access for authorized remote support
personnel will be provided through the switches and fi rewalls.
 - 67 - ISA-TR84.00.09-2017

Internal use of portable/mobile media - One fewer switch to provide countermeasures against propagation of malicious or mobile
code from the initially infected network.

A.6 Combined systems with strong dependency (1 zone)

Figure A.10 illustrates a "combined systems with strong dependency (1 zone)" conceptual design . Going beyond the common data
communication and human interfaces of the shared network example of A.5, this architecture involves sharing communication
components that are even more directly involved in performing the safety and control functions. In this case , a shared bus collects the
process data and is used to send commands to the field devices. This type of architecture is generally proposed to reduce fie Id instrument
wiring costs. The shared 1/0 bus becomes a common cause failure between process control and safety functions, to be designed to the
overall performance requirements and managed following safety protocols . Because there is effectively only one zone , the standard
process control components of the system should be designed and maintained at the higher cybersecurity requirements necessary for
the SCAI zone. For example, the shared engineering workstation should be managed per SCAI cybersecurity requirements.

lh.. 1

.. levelO
-
2 ~-2
~1!111

11 Sen- I t Romote IJO

Bua I
i1
Proc
Rerno19 1/0
Bue I

<
Flnal~11 I
Shared Contro lcr ct\llork

13 Proc

b) Blod< !Mgrwn
Re,_e
Bus 2
llO iF~~l21

Figure A.10 c1 a1 - Combined systems w ith strong dependency (1 zone)

ISA-T R84 .00.09-2017 - 68 -

Evaluating the safety (SCAI) zone in the combined systems with strong dependency architecture
against the seven foundational requirements for cybersecurity and three attack scenarios:

IAC - IAC cybersecurity protocols address identification and authentication of all 1/ 0 signals to
the controllers. This is likely to add latency and creates vulnerabilities in the information
essential to both process control and SCAI functionality.
UC - Use control protocols and countermeasures are expanded to address the intended routing
of 1/0 communication to the correct controller(s).
SI - Use of networked 1/0 exposes process control and SCAI functionality to loss of
communication integrity on the signals used to directly perform control algorithms .
Countermeasures should be established.
DC - Loss of confidentiality of the raw process data is typically of lower risk than loss of refi ned
information at higher levels within the overall control system architecture. Depending on
technology (e.g. , wireless) used to create the 1/0 network, physical access
countermeasures may not be effective in reducing the unmitigated cyber risk.
RDF - T here is limited segmentation between the SCAI and process controller zones, due to
the common networks shared between the two . Physical segmentation is no longer possible
w ithout impact to data communication essential to process controller and SCAI functionality.
TRE - Cybersecurity violation alerts can be communicated from the shared communication
network. Monitoring of the 1/0 networks should also be established.
RA - A denial of service attack against the 110 network switch will directly affect the process
controller and SCAI functionality. Countermeasures shou ld be established . Depending on
technology (e.g. , wireless) used to create the 1/0 network, physical access
countermeasures may not be effective in reducing the unmitigated cyber risk.
External attack - No significant change in risk from the integrated architecture with shared
network against this attack .
Modification by remote user - No significant change in risk from the integrated architecture
with shared network against this attack.
Internal use of portable/mobile media - Malicious or mobile code exposed to one smart fie ld
device (e.g., via a hand-held instrument communicator) might use the 1/0 network to move
into other smart devices on the network.

A .7 Shared logic solver (1 zone)

Figure A. illustrates a · shared logic solver (1 zone)" conceptual design. At the opposite end of the
spectrum from the air-gapped architecture , the shared logic solver represents the highest degree
of common cause failure potential between process control and SCAI, with both being executed
by fully shared processor and 1/0 cards. Rigorous analysis and testing are required to ach ieve the
overall integrity and reliability necessary for such a system , as are robust management systems.
For example, all field components and the appli cation code of the control system fall under the
safety management system change management requirements , unless the system configuration
provides adequate functional separation . The cybersecurity of this logic solver is required by IEC
6151 1-1 to follow the practices applied to safety systems.
 - 69 - ISA-TR84.00.09-2017

Lovol 2

Lev.. I

Com lype11

lovol O

JI ..,,~, I ~ final Element 2

! I s"""" 1
~lnput____J ·E E • F'"" Elomcot 1
b) Block Diagram

Figure A.11 1181 - Shared log ic solver (1 zone)

Evaluating the safety (SCAI) zone in the shared logic solver architecture against the seven
foundational requirements for cybersecurity and three attack scenarios :

IAC - There is only one network and one controller. IAC protocols appl icable to SCAI controller
apply to the network.
UC - Use control between process control and SCAI portions of the controller can only be
performed by host-based protocols. Zone boundary use control protocols applicable to
SCAI zone apply to the network.
SI - There is only one network and one controller. Communication integrity protocols applicable
to SCAI network apply.
DC - There is only one network and one controller. Most stringent data confidentiality protocols
between process control and SCAI networks apply.
RDF - There is only one network and one controller. Restricted data flow protocols applicable
to SCAI network apply.
TRE - Cybersecurity violation alerts can be communicated from the one network.
RA - There is only one network and one controller. Denial of service countermeasures
applicable to SCAI network apply.
External attack - An external attack that reaches the combined controller will impact both
process control and SCAI functionality simultaneously.
Modification by remote user - Unintended consequence of modification by an authorized
remote user will impact both process control and SCAI functional ity simultaneously.
Internal use of portable/mobile media - Effect(s) of malicious or mobile code injected from
portable/mobile media will impact both process control and SCAI functionality
simultaneously.
ISA-TR84 .00.09-2017 - 70 -

A.8 Supervisory control and data acqu is it ion systems {SCADA)

Figure A. illustrates the conceptual design of a typical SCADA control system . Unlike the previous
six examples, in this architecture components essential to the ongoing normal control of the
process equipment are present at all levels of the network hierarchy. In many cases,
communication between the upper and lower levels take place over untrusted networks through
wireless, broadband or dial-up communication media . In addition, SCADA installations are more
frequent users of wireless instrumentation technology. Physical security countermeasures are not
feasible for all segments of the process control network in this architecture . This can expose the
overall process control system to higher levels of unmitigated cyber risk than when all components
essential to process control are contained within one geograph ic area and are connected directly
to each other. The safety functions within these systems are more commonly implemented on the
process control logic solver (with necessary compliance to I EC 61511-1 Subclause 9.2 .5), although
they could also be implemented on physically separate SCAI systems (e .g ., local hi-hi level tank
interlocks using trip amplifiers).

r---- -- ,.;;-- _ :;.- 1

1
I
I
°"""~··
rtn.• :..
'--•• :
I
LMiw 4
I
I -!>: 1-i-1 :
I I
!.--w-•~w·•~-
----------- ,
r --------

!
I
oc#....
# I '" •
___________________
C..1 JI
t WO..
~· ~
L...-1
"~
I
I
:
I

------
I
, ----- ,
.,
-----------· # . --------------------,
I I
I P • lew 1 I
I ...1'Qf•lo0n l"CJ< :
: 4111 flt'' Ui t ' I "!.'.::,. II
I ~ ~' Ir.-.':: ' f~~~
----.,-------&;.--
w 7'
. "" ''f.t~- -----------·
#

,-------~------ ,-------- --~------------ ----------------,

l • 0

·-·
I • ~ ' ; t I
I I

:
I : I

,----------------------------------·
I ---------------------------------- -----------2 I
I '
I
I
I
I
....
y.. '--lD
I
I
:
I
I ~ ,........
'••• ___, I
I

Figure A.12 11111 - SCADA conceptual architectu re

Evaluating the SCADA architecture against the seven foundational requirements for cybersecurity
and three attack scenarios:

IAC - As the overall process control system is spread across all levels, with multiple channels
of exposure to the internet, identification and authorization control is significantly more
complex. Secure channeling/tunneling countermeasures are typically used to manage risk
for portions of the system where communication over public networks is required .
UC - Similarly, use control countermeasures should address the distributed nature of the
SCADA control system components.
SI - Communication integrity is fundamenta l to the continued performance of a SCADA system .
Countermeasures should be designed to not insert so much latency that control
performance is compromised .
DC - Data confidentiality is typically at higher unmitigated cyber risk due to the inclusion of
public or long distance networks in SCADA systems.
 - 71 - ISA-TR84 .00.09-2017

RDF - Segmentation between process control and SCAI is often achieved by having the SCAI
physically separated from the SCADA control system, using locally wired devices to protect
individual unit operations .
TRE - Cybersecurity violation alerts can be communicated within the SCADA network .
RA - A denial of service attack at one of a number of points within the SCADA network will
impact system control performance throughout the SCADA system.
External attack - Attacks to the upper levels will generally be against COTS technologies no
different than the typical personal computer.
Modification by remote user - Remote modification to different levels of the SCADA system
may not be responsive to the same countermeasures.
Internal use of portable/mobile media - There are many more points of access to
portable/mobile media within a SCADA network. These may be through devices that a re
outside any physical access control by the operating organization .
This page intentionally left blank.
 - 73 - ISA-TR84.00.09-2017

Annex B -
Cyber risk assessment example procedures
The following examples in 8 1 and 82 of high level and detai led level cyber risk assessment
procedures have been adapted from the paper by Thomas H. W and Day J .; Integrating
Cybersecurity Risk Assessments into the Process Safety Management Work Process , 11th Global
Congress on Process Safety, April 2015.

B.1 High level cyber r isk assessment procedure

Purpose

According to ANSl/I SA-62443-2-1 the purpose of a high level cyber risk assessment is to
understand the fi nancial and HSE risks in the event that availability, integrity or confidentiality of
the IACS is compromised . The fo llowing details what should be expected from a high level cyber
risk assessment:
1. Assist the establishment of scope for new projects.
2. Provide a determination of the criticality based on severity of potential worst case
consequences should a cyber attack be successful on various devices with respect t o
cybersecurity for new or existing plants . Provide an initial security level target for
devices that provides an input when establishing zone and conduit security levels .
3. Provide an initial definition of expected response should a device be compromised .
4. Provide input to the detailed level cyber risk assessm ent.
5. Review of the risk criteria to be used in a detailed level risk assessment to ensure it is
suitable for cyber risk management.

Procedure 1

Step 1A: Create an inventory lis t of all the types of cyber assets that will be used within each
specific process or utility unit where different process safety, environmental or fi nancial hazards
exist. Use of process block flow diagrams can be useful when considering potential hazards and
organization of cyber asset types that apply to each block. Typical types of cyber asset types within
a system under consideration include but are not limited to :
• business servers ;
• historian;
• personal computers ;
• eng ineering work station ;
• operator consoles for human machine interface (HMI );
• distributed control system;
• programmable logic controller;
• safety instrumented system controller;
• smart field instruments;
• printers .

Step 18: In parallel with step 1A, the PHA should be reviewed to excerpt potential worst case
consequences that exist in the various process units and utilities . A relatively quick means to
id1e ntify major hazards within a facility is to review their layer of protection analysis ( LOPA)
documentation . Major hazard scenarios that have appropriately d1esigned protection not vulnerable
to cyber attack (e.g. relief valves, check valves, etc .) should be excluded . A process block diagram
can be used to align the worst case consequences against the process and utilities as well as
listing the cyber devices that are associated with each block area . Any block area that has the
same consequences and same devices can be aggregated .
ISA-T R84 .00.09-2017 - 74 -

Step 2: Organize the cyber asset types by process/utility areas using a table similar to below.

Proce~~b~onsequence Criticality
-
Security Ease of
- Recommended
I utility asset to process I level propagation response if
area type util ity area if comprom ised
I comprom ised
I r
I I

Step 3: Conduc t the workshop using the table above to determine the criticality if the device were
compromised . The criticality of the device is determined first by the worst case consequence and
then the hazard potential or consequence severity that could occur if the asset under consideration
within the defi ned process/utility area were compromised .
NOTE Risk Is a function o' consequence severity and likelihood. As the high level ri sk assessment is evaluating
unmitigated worst case consequences . estimating likelihood is somewhat problematic. One would expect worst ca se
consequences to bo a low demand rate, however. lower consequences that are unmitigated would be expected to be
high or continuous demand. To deal with this issue in the high level risk assessment, the likelihood in procedure is
assumed to be a probability of 100% as referenced in A Sl/ISA-62443· 2· 1. Annex C.

Step 4: Document the relative ease of propagation to other asse t(s) if the asset under consideration
were compromised .

EXAMPLE For instance, should something like a historian server be compromised, it would
generally be more appropriate to isolate whil e the rest of the process continues to operate.
However, should it be determ ined a SCAI system is compromised , it may be difficult to j ustif y not
shutting down the process. A more interesting question comes about should the process c ontrol
system be compromised . If the SCAI systems are still functional, a case can be made to try and
fix on line if it can be determined that the threat is not fatal.

This last example raises an important point when selecting a control system at the beginning of a
project. As the degree of integration between control systems and safety systems increases, there
is less latitude as to the potential responses. In additi on, as the level of integration increases,
common failure resulting from a cyber attack can lead to a situa tion where it is not possible to
satisfy corporate ri sk criteria . U nderstanding these issues as soon as possib le is the best way to
minimize the cost and potential schedule impact to a proj ect. When making the determination of
what system and level of integration to use, it is advised to reference the 7 core attributes as
described in the CCPS Guidelines for Safe and Reliable Instrumented Protecti ve Systems to help
make an appropriate decision based on the relative level of risk inherently posed by the process.
Refer to Annex A to see the analysis of examples of systems with varying leve ls of integration.

With the potential consequences and ease I difficulty of propagation information documented, each
asset should be assigned to a zone and the security level rec ommended to prevent propagation
across zones should be established. Using industry recognized and generally accepted good
eng ineering practice as documented in the ANSl/ISA-62443 series of standards should be the
starting point. Finally, forma l zone and conduit drawings should be developed . These drawings
can be considered required process safety information input to the detailed cyber risk assessment.

Step 5 : Considering both the consequence severity and the relative ease of propagation , assign a
security level target (SL-T)

Step 6 : Document expected response to the asset under consideration being compromised . The
selection of recommended responses for this workshop include:
 - 75 - ISA-TR84 .00.09-2017

keep operating I fix when convenient;

isolate asset and quarantine until threat has been removed ;
shutdown or implement alternate means of risk reduction until fixed ;
either shutdown local process or continue to operate as means to operate without
controller exist;
shutdown the process .

Step 7: Review risk criteria to ensure it is appropriate for the detailed level cyber risk assessment.

Procedure summary

• List cyber assets .

• Identify worst case potential consequences as a function of process/utility area .
• Document potential consequences if asset is compromised .
• Document ease of propagation with open communication .
• Select target security level for each asset category as a function of process/utility area .
• Verify risk criteria are adequate for cyber risk management.

B.2 Detail ed cyber risk assessment procedure

Purpose

A detailed cyber risk assessment is intended to rigorously evaluate the instrument and control
system (IACS) and ensure the proposed design and procedures are capable of satisfying the
corporate risk criteria. To do this, identification of the potential threat vectors and associated
countermeasures is essential.

Methodology overview

This methodology is similar to a HAZOP, however, the methodology evaluates cyber nodes that
represent the cyber assets that are part of the zone and conduit design. Although the concern is
with the instrumented control and safety systems, the entire plant network including all internet
and wireless access points, including 3rd party connections , networks , and devices should be
addressed in so far as they can be pathways to compromise the IACS, or provide some level of
risk reduction via the defense in depth strategy.

It should be understood that the typical process hazard analysis (PHA) has a much greater degree
of granularity than a cybersecurity PHA. In a PHA, individual control loops are considered as
potential cause of a hazard whereas in a cyber PHA, an entire process control system consisting
of multiple loops would be considered all at once. Non-cyber causes are more predictable as the
common mode failure of an entire controller would result in all outputs failing the same way,
whereas a cyber attack is insidious as it can cause different outputs to respond so as to result in
the worst case consequence .

The final difference is that the PHA will consider safeguards that may or may not be vulnerable to
cyber attack. A cyber PHA generally has no practical means to consider safeguards that are not
vulnerable to cyber attack during the hazard identification portion of the cyber PHA due to the
different levels of granularity of what is being reviewed. For instance, if a control fai lure resulted
in high pressure , a relief valve might be listed as a safeguard in a HAZOP. In a cyber PHA it is not
practical to consider this as it does not look at individual loops, but all of the loops, alarms,
interlocks that may be contained in a single process control system . Once the major hazards have
been identifi ed, it would be reasonable to consider some safeguards that are not vulnerable to a
cyber attack on an exception basis.
ISA-T R84 .00.09-2017 - 76 -

Procedure

1. Leverage the PHA

After the traditional PHA has been performed, it is recommended to consider whether initiating
causes and safeguards are potentially vulnerable to cyber attack. Those that are not vulnerable
do not need to be considered in the cyber risk assessment. For those that are vulnerable, the
ultimate consequence should be noted. These consequences can be ranke d into appropriate
categories to be considered in the detailed cyber risk assessment.

The exercise to determine these consequences of concern can be performed by reviewing the
HAZOP or by preferentially going through the exercise with the layer of protection analysis (LOPA)
if performed. If an adequate level of LOPA has been performed, it is more efficient to use these as
they typically cover the major hazards of concern. It is not necessary to evaluate every hazard in
a detailed cyber risk assessment as once the process control and SCAI systems are protected
against major hazards, they would also be protected against the lesser hazards. Tables B.1 and
B.2 show detailed procedures to leverage the PHA in this manner for HAZOP and LOPA
respectively.
 - 77 - ISA-TR84 .00.09-2017

Table B.1- Pr ocedure for leverag ing the PHA- HAZOP

Major procodural stop Dotallod s top Common ts

Perform traditional PHA. Use company HAZOP procedures.
Excerpt high risk cause Filter worksheet data to only include high There 1s no credit for any
consequence pairs. risk consequence seventies . safeguards at this point.
Export tho following data ields:
• Cause
• Consequence
• Severi ty
• Safeguards
• PHA recommendations
• Comments
• Sort the report by descending
consequence severities
Discard those causes not Review each cause.
susceptible to cyber If it can be caused by a cyber attack indicate
influence. •yes"
If it is not vulnerable to cyber attack,
indicate "no"
Filter the report to only show those cause
consequence pairs that arc susceptible to
cybcr attack.
Identify safeguards not Review the safeguards for remaining causes
susceptible to cyber as to susceptibility to cyber attack.
influence. If it can be manipulated by a cyber attack
indica te •yes•.
If it is not vulnerable to cyber attack,
indicate "no"
Filter the report to only show those
sa cguards that arc not susceptible to cybor
attack.
Per'orm revised rls ranking. Update likelihood of cause . Only take credit for safeguards
Update likelihood with safeguards . not susceptible to cyber attack.
Update risk ranking .
Sort revised worksheet by risk in descending Risk ranking Is based on
order. like lihood o' cyber threat being
perpetrated and failure of the
safeguards not susceptible to
cyber attack for the specific nsk
receptor category.
Provide sorted worksheet to The risk ranked worksheet is to
cyber risk assessment team . be used by the cyber nsk
assessment team to :
• Improve estimate of actual
consequences and seven ty.
• Achieve improved granularity
of risk when credit for
cybersecurity
countermeasures arc
assessed.
ISA-TR84 .00.09-2017 - 78 -

Table B.2- Procedure for leverag ing the PHA- LOPA

Major procod ural ste p Dotalled stop Comments

Perform traditional PHA. Use company LOPA procedure.
Evaluate all high Company to define what constitutes a high There is no credit for any
consequence severities. consequence severity safeguards at this point.

Discard those initiating events Review each initiating event. Treat high demand as 1 per year
(IE) not susceptible to cyber If it can be caused by a cyber attack assume as a matter of convenience .
influence. high demand
If 11 is not vulnerable to cyber attack. then IE
frequency = O/year.

l dentt~y safeguards not Review the IPLs for remaining Initiating

susceptible to cybcr events as to susceptibility to cyber attack.
influence. If it can be manipulated by a cyber attack
assume PFD =1.
If it is no1 vulnerable to cyber attack. use
PFD for that safeguard.

Recalcul ate hazard Perform LOPA calcula tions with applicable Only take credit for safeguards
rcquency. IE frequency and safeguard PFDs. not susceptible to cyber attack.

Provide sorted hazard Categorize LOPAs by consequence severity Tho sorted information is to be
rcquoncics to cybor risk in descending order. i.e. highest seven ty to used by tho cybor risk
assessment team . lowest seventy. assessment team to :
• Improve focus of cybor
Within each category, list hazard review with respect to most
frequencies in descending order. i. e. highest significant risks.
frequency to lowest 'rcqucncy. • Achieve Improved granular ity
of risk assessment whe n
credit for cyborsccurity
countermeasures arc
evaluated.
 - 79 - ISA-TR84.00.09-2017

2. Risk assessment preparation

Prior to the start of the detailed cyber risk assessment, key process safety information should be
obtained. This information includes :
• Results from the traditional PHA as leveraged in step 1.
• Complete list of cyber assets (should be available from the high level cyber risk
assessment or a vulnerability assessment).
• Zone and conduit drawings that show:
o Zone location for each cyber asset.
o Means of communication cybersecurity between zones .

Once the requisite information is available the tool/worksheet being used to conduct the review
should be organized to list the zones and assets within each zone before the fu ll team meets.
Figure 8 .1 shows a conceptual example of a zone and conduit drawing using the hierarchy
approach from ANSl/ISA-95.00 .01 .

Figure 8 .1- Zones and cyber nodes

Excorptod f rom CCPS Guldollnos for Safo Aut omation of Chemica l Procossos [ 18)

(Poor rovlow copy)

3. Perform the detailed level cyber risk assessment

Utilize a qualitative HAZOP type approach to perform the cyber risk assessment. A summary of
the method is included below:

1. Select a zone
2. Select cyber node, e .g., a cyber asset.
3. Identify and record a cyber threat.
4. Identify and record causes.
5. Identify and record qualitative cause likelihood (without any credit for countermeasures) .
6. Identify and record consequences (without any credit for countermeasures).
7. Determine and record qualitative severity of consequences .
ISA-TR84 .00.09-2017 - 80 -

NOTE Conscquonccs may have boon idcntifiod and I or quantified in the traditional PHA. If this is tho case, this
information should bo used as applicable.

8. Identify and record countermeasures applicable to the cyber threat and cause .
9. Document the security level requirement for the threat vector .
10. Determine and record qualitative likelihood (with existing countermeasures) .
11 . Determine if risk is tolerable per risk criteria . If not make recommendation(s) .

NOTE Socurity lovcl vorification is not part o the risk assessment methodology, but should be porformod
subsoqucnt to tho review for high scvori ty haza rds to ensure that tho idonti icd countormcasurcs arc sul'ficicnt to
provide the risk reduction needed to satisfy corporate risk criteria.
 - 81 - ISA-TR84 .00.09-2017

Annex C -
Cyber vulnerability assessment

C.1 Ongoing lifecycle vulnerability assessment

A vulnerability assessment, which is based on the elements contained in ANS l/ISA-62443· 2·1 , is
intended to provide a review of the cybersecurity environmen t for the control and instrumented
safety systems at the facility. It identifies vulnerabilities and then develops recommendations for
possible improvements. It is best done in concert with a detailed cyber risk assessment per the
lifecycle. During a vulnerability assessment, the following is accomplished:
• Existing facility cybersecurity practices and policies is reviewed versus current industry
practice , including current industry based alerts .
• IACS network architecture is reviewed and validated versus CSRS .
• Sample confi guration data for fac ility network equipment and control system devices is
collected and compared against documented expectations .
• Penetration testing is performed when the plant is offline .
• Findings are documented and compared against CSRS and with current industry best
practices.
• Gaps that show corporate ri sk criteria not being met should be further evaluated in
accordance with company policies.

C.2 First time existing plant vulnerability assessment 16

In today's world , not many existing facilities have had the benefit of going through the complete
lifecycle in sequence as described in the body of this technical report. In order to implement the
full lifecycle , the starting point by necessity in this case is during the operation and maintain phase.
The vulnerability assessment essentiall y accomplishes the same as one perform ed during the
ongoing lifecycle as described above . The difference is that when it is performed at this stage, the
benefits that would have been gleaned from other lifecycle activities either do not exist or are more
deficient.

Once the vulnerability assessment has been performed , it provides valuable feedback to the
company, helping them to develop appropriate policies, standar ds, and procedures. Once the
policies , standards, and procedures are in place, training for employees and contractors may begin .
In addition, segmentation of the network, access con trol and hardening of the assets can also
begin based upon recommendations that come out of the vulnerability assessment.

There is still the need to perform the cyber risk assessments , which in turn, will most likely fine
tune initial recommendations that emanated from the vulnerability assessment. After the
recommendations have been fully implemented , the plant should monitor and mainta in the system
cybersecurit y. At this point, the facility should be fully following the lifecycle .

Figure C.1 illustrates the path for an existing facility to ultimately be fully integrated with the
lifecycle described in this technical report.
ISA-T R84 .00.09-2017 - 82 -

Yes
Implement IACS Perform Vulnerability Vulnerability
__. Assessment Report
Cyber Security? Assessment

Assessment Phase

l Harden System
Components
-~

Design Phase

l l
Control Access to the
System
Start Operation Phase

l l
Segment the Network ~

Monitor and Maintain

System Security
l
Train Personnel &
Contractors

l
Develop Policies and
Procedures

Fig u re C. 1- Existing fac ili ty i mplementation of life cycle

 - 83 - ISA-TR84.00.09-2017

Annex D - Cybersecurity level verification example

Given what people read , many think that all cyber attacks are ever present. Depending upon the
threat agent/source/motivation etc., this may or may not be true. Table D.1 below has a list of
potential threat agents/sources listed in a qualitative descending order of likelihood . There are so
many general viruses and malware present in cyber space that from an unmitigated threat
perspective, they certainly fall into a high or continuous demand category, i.e ., as soon as the anti-
virus protection were to fail, it can be assumed the cyber attack would be successful. These
general purpose viruses/malware, however, are also generally non-specific and as illustrated in
Table D .2 can be assumed to cause a relatively low consequence if the attack were successful.

At the other end of the spectrum , a sophisticated intentional attack occurs at a much lower
frequency, takes much more time to conduct, and would be considered low demand per IEC 61511-
1. Should one of these attacks be successful however, the consequences could be catastrophic
as illustrated in the Table D.2.

Table 0 .1

Throat agont (hl ghost to lowost llkollhood) Ll kollhood qualltatlvo oxamplo

I
External - General High I Continuous demand
Internal - Unintended action High demand
Internal - Intentional unsophisticated Low demand
External - Intenti onal unsophisticated Low demand
External - Intenti onal sophisticated Low demand
Internal - Intentional sophisticated Low demand
-
Table 0 .2

Throat agont (hlghost to lowest llkollhood) Consoquonco potontlal quallt atlvo oxamplo
External - General Operational disruption
Internal - Unintended action Operational disruption
Internal - Intentional unsophisticated Operational disruption I Plant damage
External - Inte ntional unsophisticated Operational disruption I Plant damage
,_
External - Intentional sophisticated
- Major operational disruption. major plant damage
-
and I or personnel inj ury or fatality
Internal - Intentional sophisti cated Major operational disruption , maj or plant damage
and I or personnel inj ury or fatality
ISA-TR84 .00.09-2017 - 84 -

0.1 Example cyber risk criteria

Example Company XYZ conducted a HAZOP and subsequent LOPAs as part of their PHA. They
decided to perform a detailed cyber risk assessment as part of the overall PHA. During a prior high
level risk assessment, they reviewed their risk criteria for suitability to cyber risk management in
a way that meshed with the risk criteria as applied to their HAZOP and LOPA procedures. Their
resulting risk criteria are shown below:

NOTE The risk criteri a in this exam ple is contrived solely for 1he purpose of facilita ting the SL verifica1ion example. It
was created based upon knowledge of several risk criteria used by di ferent compa nies. Anyone looking to create their
own risk criteria may refe r to CCPS Guidelines or Developing Quantitative Safety Risk Cri1eria 10•

Risk matrix

Consequence Likelihood
severity
6
5
4
3
2
1
NOTE Numbers resulting f rom the intersection of consequence severny and likelihood within the risk ma1rix represent
levels of increasing risk as determined by company XYZ.

Level Severity
B E s
1 Negligible Negligible impact Negl igible impact
impact
- 2 SS0,000 - Temporary release and Recordable injury
$500,000 cleanup within weeks
3 SS00,000 - Temporary damage to the Lost time inj ury
$5 million facility and cleanup within
- 4 -- - SS million -
months
Temporary damage to the
,_

Irreversible injury (e.g.,

$50 million facility and cleanup within blindness, loss of limb, etc.) or
years sinQle on-site fatal ity
- 5 SSO million - Temporary damage to the On-site fatalities
$250 million facility and cleanup greater
than a decade
6 > 5250 million Permanent damage to Off-site fatal ities
environment rendering land
unusable

Level Likelihood
L
-
- 1
2 - 10- ear
- 3
- 10- ear
- 4
- 10- ear
- -
- 5
 - 85 - ISA-TR84.00.09-2017

D.2 Example results of high level cyber risk assessment

Included in Table D .3 is a sample subset of the threat vectors that the risk assessment team
identified based upon a high level cyber r isk assessment of the drawing illustrated in Figure D .1.
The detailed cyber risk assessment used the methodology described in Annex 8 , 8 .2.

Figure 0 .1
ISA-T R84 .00.09-2017 - 86 -

Table 0 .3

Example threat vectors and unmitigated risk

(Excerpted sample of informat ion from prior detailed level r isk assessment)

Th r oat agont Th roat typo Targotod Llkollhood Consoquonco

assot{s)

External - Targeted Process 10- 1 to 1 0-3 per On-site fatalities

Intentional malware control and year
sophisticated attack SCAI systems
Internal · Targeted Process 10- 1 to 1 O· 3 per On-site atalities
Intentional malware control and year
sophisticated attack SCAI systems
Exter nal Targeted Process 10- 1 to 1 O· 3 per Plant shutdown. 16
- Intentional malware control year equipment damage.
unsophisticated attack systems financial losses
between SS million •
SSO million as well as
poten tial personnel
injury
~

Internal · General All systems > 10-1 per year Potential or 8

Unintended mistake virus I degraded response or
Malware relatively short
duration shutdown
resulting in SS0.000 •
SS00,000 losses
External • General General Process > 10-1 per year Potential or 8
virus I control degraded response or
Malware systems relatively short
duration shutdown
resulting in SS0.000 •
SS00,000 losses
Internal· Denial of Process > 10· 1 per year Potential for 8
Intentional service control degraded response or
unsophistacated attack on systems relati11ely short
process duration shutdown
control DCS resulting in SS0.000 •
SS00,000 losses
External Denial of Process > 10-1 per year Potential or 8
• Intentional service control degraded res ponse or
unsophisticated attack on systems relati11ely short
any process duration shutdown
control or resulting in SS0.000 •
SCAI system SS00,000 losses

As a result of recommendations made during the high level cyber risk assessment, proposed
improvements were made in the design . Currently the proposed zone and conduit design is as
shown in Figure D.2 . Other countermeasures w ere proposed that would not appear as a physical
element on a zone and conduit drawing .
 - 87 - ISA-TR84 .00.09-2017

l'Ctd

1
l'\\ 1RCo'\t"'O
I P'~C4" :::tr

SCA EW 5

SCA!
PLC

'"'"

Fi gure 0.2
ISA-TR84 .00.09-2017 - 88 -

0.3 Example countermeasure strength assessment

SL verification was performed to help assess whether the conceptual design was believed to be adequate or whether further changes
needed to be made for the detailed countermeasure design . In preparation for the SL verification , the streng ths of countermeasures
were assessed and documented versus their attributes as documented in Annex G. Examples of these coun termeasures as used in
the SL verifica ti on examples is shown in Table D.4 .
Table 0 .4

Example countermeasure attributes versus security level

Countormoaauro Attributes Assossod

socurlty
lovol
Firewall .. Industrial conttol system statoful firewall 2

. Access control li st (AC L) managed by PCN group

Minimum rule sot defin ed
Firewall .. Industrial control system stateful firewall 3

...
Access control list (AC L) managed by PCN group
Minimum rule sot defin ed
Deep packet inspection capability
No irmwaro encoded rules .
Firewall .. Industrial conttol system stateful firewall 3

..
Access control list (AC L) managed by PCN group
Rules encoded in firmware

Firewall .. No deep packe t inspection capability

Industrial conttol system stateful firewall 4

..
Access control list (AC L) managed by PCN group
Rules encoded in firmware. I.e.• no external configuration ability
Deep packet inspection capability
Administrative work
process and awareness
.. Procedur es designed to suppon human error probability of less than 1% 2
Periodic validation supports proven in use for assumed value
training
Portable media . Ports do not exist 2
Anti-virus (AV) so'twarc .. Installed and updated per formal procedures when revisions arc made available
Updated within less than a week when now updates available
2
 - 89 - ISA-TR84 .00.09-2017

Cou ntormoasuro Attributes Assossod

socurlty
lovol
Authentication and
access controls
.. System use notification message is displayed before authenticating .
Identification and authentication onrorccd for all software processes and devices where interfaces provide
2

.. access to the control systom

Least privilege in accordance with applicable cybcrsccurity policies and procedures is applied .

. Application software receiving authorization request provides obscure feedback (e.g. , asterisks).
All accounts arc managed by authorized users. including adding, activating, modifying, disabling and removing

.. accounts.
Default user names and passwords arc changed from defaults prior to use .
Administrative controls and audits in place to ensure passwords are not divulged (e.g. , sticky notes on PC or on

.. tho wall)
Secure protocol in place to encrypt password when submitted (e.g . . HTTPS. SSH)

. Password with minimum 8 characters with combination of upper caso. lower case, number and symbol
Number or consecutive Invalid login attempts limited and enforced (human, software process or device) during a
configured time period and access is denied ror a specified period of time or until unlocked by an administrator

..
when this limit is reached
Authorized users or roles arc defined and permissions mapped to roles for all human users .
Control system enforces authorizations assigned to all users (humans, software processes and devices) for
conttolling use of tho control system to suppon segregation of duties and least privilege on all Interfaces
Authentication and
access controls .. System use notification message is displayed before authenticating
Unique identification and authentication enforced for all human. software processes and devices whore
4

...
interfaces provide access to the control system
Multifactor authentication employed for human user access to the control sys tem for all networks
Least privilege in accordance with applicable cyborsecurity policies and procedures is applied .

. App lication software receiving authorization req uest provides obscure feedback (e.g. , asterisks)
All accounts utilize unified account management by authorized users . including adding, activating. modifying,

.. disabling and removing accounts.

Account management implements separation of duties to perform .

.
.
Access requests via untrusted networks arc denied unless approved by an assigned role .
Default user names and passwords are changed from defaults prior t o use .
Administrative controls and audits in place to onsure passwords arc not divulged (e.g. , sticky notes on PC or on

.. tho wall)
Secure protocol in place to encrypt password when submitted (e.g. , HTTPS. SSH)

. Hardware mechanisms in place to protect relevant authenticators for so'twaro processes and device users
Password with minimum 8 characters with combination of upper caso. lower case. number and symbol
ISA-T R84 .00.09-2017 - 90 -

Countormoasuro Attributes Assossod

socurlty

. Number of consecutive invalid login attempts limited and enforced (human. software process or device) during a
configured limo period and access is denied for a specified period of time or unlil unlocked by an administra tor
lovol

. when this limit is reached

Password management system prevents any given human user account from rousing a password for a

.. configurable number of generations and prompts user to change.

Authorized users or roles arc defined and perm issions mapped to roles for all human users

. Dual ap proval is required for authorization .

Control system enforces authorizations assigned to all users (humans, software processes and devices) for

..
controlling use of tho control system to support segregation of duties and least privilege on all interfaces.
Intrusion detection and Comparison diagnostics employed with alarm 3
response
. Procedure requires immediate response to investigate and respond to anomalies .
Periodic drills to validate prove n in use for assumed value

In performing the SL verification , the countermeasures would be evaluated for each threat vector. A limited number of example SL
verifications have been documented below, based on the threat vectors identified in Table D.3. Basic event tree analysis was used to
perform the SL verification . Selected countermeasure assumed security levels and their attributes were taken from Table D.4.
A somewhat more in depth listing of example countermeasures is documented in Annex G. The reader should in no way assume this
represents a complete listing.

D.3.1 External den ial of service (DoS) example SL verification

In Figure D.3, the as found network was analyzed lo determine security level achieved against an external DoS attack. Multiple process
control and SCAI PLCs were connected directly to a network. In this case the demand rate was determined from the plant maintenance
records that recorded when PLCs needed lo be power cycled . The frequency was determined by evaluati ng work orders that required
restart of a controller due to poor or erratic performance. As can be seen, the SL capability for this threat vector is SL 0. Due to the high
frequency of maintenance and frequency of shutdowns, the financial severity was upgraded to a risk of 16.
 - 91 - ISA-TR84.00.09-2017

Detection & Recovery prior to

P C' s require power cycling
plant shutdown 95" Operability Issue
to be a ble to be returned to
9.5 per yeu
service
External Denial of Service
Attac (10 per ycarj

Plant shutdown S" Pl•nt Shutdown

0.5 peryur

Figure 0 .3

Subsequently, a firewall was added as a countermeasure. A firewall was proposed with attributes that were deemed to be capable of
SL3 with the feature that the configuration was embedded in firmware was proposed. This firewall did not have deep packet inspection
capability. The resulting SL verification was performed using an event tree as shown in figure D.4.
ISA-TR84 .00.09-2017 - 92 -

External communication to I
T9111ponry from PLC slowed down.
Openbllty Issue. Resumes as normal as soon
Neallslble lmlJlld. as broadcast storm subsides.
No impact on PLC primary
mission.

firewall(Sl3) in Service 99.9%

No PLC lmp11d

External Denial of Se rvice Detection & Recovery prior t o

PLC's require power cycling
Attack (10 per year) - plant shutdown 95%
Openbllty · - to be able to be returned to
9.5e-J per yur

Firewall not in in Service 0.1%

- -
service

Plant shutdown 5% Pllint Shutdown

Se-4peryar

-
Figu re 0 .4

Although the firewall provided has no deep packet inspection capability that does not prevent the firewall from providing the needed
risk reduction for a denial of service attack from an external source . Applicable monitoring and administrative controls were added to
the facility operations plan .
 - 93 - ISA-TR84.00.09-2017

D.3.2 Un intentiona l internal DoS example SL verif icat ion

With only reliance on what an employee would do relative to their own personal computer at home, it was felt that there would be a
relatively high incidence of mistakes. The initial result is shown in Figure D.5.

UnlntentJonal lntemal
OoS, humn etro~ (e.g. Po tent al for degraded
Plu.g tn two e.nds of cable Temporary response or relative y s~ort
creating a loop, bad ------~ 01>«abllily ls.sue durat on shutdown resulting
network interlace card. in SS0.000 - 5500.000 losses
lnfttted pona ble media
(1 oe1vear)

Figure D.5

With implementation of training and documentation of prescribed work procedures, the likelihood of occurrence is reduced and the
resulting risk moved from yellow to green as shown in option 1. Option 2 looks at additional risk reduction possibilities. If the media
ports are removed from the process control systems, that threat vector is removed , however, a DoS attack could originate elsewhere
within the PCN . In those cases, risk reduction can be provided by a fi rewall. A SL 2 firewall as described in Table D.4, with
corresponding monitoring and administrative controls , was assumed in this example.

--
S. 2 Ad...,lr"ll";lltvework
:ire-i:eu ard awrerus
1·a.r-ia:suc:uuh. !19Jlo

Urrcerttan:tl lnteru Po1u.:11e -neaJa !M>rts :invs•:a1¥ relT'ow.C

___ --
DoS,"l\11".:.ll"Ctrotle1. f-cM :irouuc:arttal~~ a"!d
'lusntvio'OercsofWc (.O°lneaea ~"t1cir1o of L')C ~
<ROIL"ll:l~, b.ld protMtec CV a SL 1 f "'"""-a 9W
networt Interface Q"C,
tnfuted :i1uub.e ~d.a
1:~·vn1

Optonl ....... Po!ential for degraced

re•pan•e OI r ~lativtt y
shct'l ch.irat.JOn shl.tdown
resi..ltin; In $SO,OOO -
$500,000 klllt!S
=>otCtnlJal fot dogradoc Ootion2
r11 spon&11 oc relatN~ly
short c1.ra~ion lhutdown
rH1. :inp In $50.000 -
S500,000 k>$HI

Figure D.6
ISA-T R84 .00.09-2017 - 94 -

D.3 .3 External genera l virus example SL verification

General viruses are ubiquitous within the cyber world. As such, with no countermeasures as shown in Figure D.7, it can be assumed
that the system will be infected. Although the consequences of a single untargeted virus might be considered to be small , with no
cybersecurity countermeasures , the situation can become untenable and the consequences would increase from the cumulative effects.
Although a SL verification example for a general virus was provided for illustration, due to the relatively low consequences in most cases ,
it would most likely not be a candidate for quantitative SL verification . Rather the qualitative review and assessment versus RAGAGEP
during the cyber detailed risk assessment would typica lly be deemed sufficient in most cases. More quanti tative techniques for SL
verification are typically performed for the high level consequences where RAGAGEP forms a fundamental foundation upon which to
build.

Potontial for dogradod

General Virus Virus lnfKtJon rosponso or rotat voty short
Continuous Atta-ck r.qu1rH recovery duration sh utdown resulting 1n
sso.ooo - ssoo.ooo lossos

Figure 0 .7

Figure D.8 adds anti-virus protection as a countermeasure for those devices and software applications that are prone to attack. The
addit ion of anti-virus protection has moved the risk from yellow to green . In addition , whereas in the unmitigated case , one would assume
the consequences to be at the high end of the range, in the mitigated case, one would assume the consequences were at the lower end
of the range . It should be recognized that maintenance of the anti -virus protection is essential, it the anti-virus protection were to fail or
be out of date, it becomes inevitable that the incidence or becoming infected would occur and at an ever increasing rate.
 - 95 - ISA-TR84 .00.09-2017

SL2 ant i·virus p rotection mainta ined

and updat ed on regular basis is
successful. 99%
No Issue

General Virus
Continuous Anack

New virus defeats Sl2 anti·virus Per reduced likel ihood, t he

financ ial damages would be on
protection. l %
t he lower end of r ange.
likelihood reduction move s ris
int o t he green zone.

Figure D.8

D.3.4 External soph isticated intent iona l malware attack examp le SL verificat ion

Should there be no mitigation ava ilable to defend against external sophisticated intentional malware attacks, the likelihood would strictl y
be a function of a suitable party wanting to do harm. There have been reports in the industry of both knowledgeable disgruntled
employees and nation states having success in these endeavors . Knowledgeable terrorists would raise the stakes even higher. The
in itiating cause frequency depends upon the specific entity. For a disgruntled employee , it is a function of how often an emp loyee
deviates beyond reasonable society norms . For a nation state the likelihood goes up or down as a funct ion of gee-politics and the
likelihood of a real war. For terrorists , headli ne news would be the driver as well as how much damage can be done at the regional or
national level due to an attack. As shown in Figure D.9, the demand rate was assumed to be once in a hundred plant years for a
catastrophic consequence with loss of on-site personnel due to the process control and the SCAI systems being compromised . This
represents a red risk.

Extern al • Intentional
Sophisticated malware
attack (le-2 per year)

Figure D.9
ISA-TR84 .00.09-2017 - 96 -

Figure D.10 shows the improvements to risk afforded by the improved zone and conduit design. Two different attack vectors were
considered, access to the engineering work stations (EW S) and an attack that would bypass the EWS. Cyber risk reduction for the EWS
is provided by authentication and access controls as well as intrusion detection and response. It was assumed that together the strength
of the cybersecurity countermeasures would provide risk reduction 90% of the time. This results in a frequency of harm of Se-4 per year,
which moved the risk from red to yellow.

For the attack path bypassing the EWS, there is still credit for the authentication and access controls as well as the intrusion detection.
In this case however, unlike when the attacker has control of the EWS, there is a SL 4 firewall protecting the SCAI system . Since the
red risk is predicated on both the process control and SCAI systems being compromised, the firewall has reduced this threat vector to
a green risk.

As a result, the process control systems are still at risk with a likelihood of Se-4 per year, however the consequences are no longer
safety but financial , as indicated in Figure D. 10. The resulting risk has been moved from red to yellow.
 - 97 - ISA-TR84.00.09-2017

Sl 2 Authentication & Access

Controls coupled w ith Sl 3
dynamic Intrusion detection &
response fails. 10%
.--------------------------------t Potential On site
fatalities Sc-4 per year
Attack via
access to EWS
50%
Sl 2 Authentication & Access
Controls coupled wi th Sl 3
dynamic Intrusion detection &
response Successful. 90%
Noluue

External - Sl 2 Authentication & Access Sl 4 SIS firewall successful. SIS protected I

Intentional Controls coupled w ith Sl 3 BPCS Compromised 99% $500 .000 - SS
Sophisticated dynamic Intrusion detection & million Financial Sc-4 per year
malwarc attack response falls. 10% losses
(lc-2 per year)

Sl 4 SIS firewall fails, SIS and

Attack
BPCS both compromised, 1%
bypassing EWS Potentl1I On-she
L - - - - - - - - - - - - - - - - - - --1 f1t1lhle1 Se-6 per year
SO%

Sl 2 Authentication & Access

Controls coupled w ith Sl 3
dynamic Intrusion detection &
response Successful. 90%

Figure 0.10

D.4 SL verification planning

The purpose of the example was to further understanding of the methodology. As a result, simpler scenarios were addressed before
more complicated scenarios. When performing SL verifications on a facility, it is often more efficient to concentrate on the major risks
first as opposed to how the example in this annex was laid out. One of the reasons for starting with the high risks first is that once they
are protected , many of the lesser risks are automatically covered, potentially by better countermeasures than what would have otherwise
been required.
T his page intentionally left blank.
 - 99 - ISA-TR84.00.09-2017

Annex E - Cybersecurity metrics for IACS

E.1 Preface
As of this technical report publication there are a number of referenced documents that are in draft,
some of which have major revisions under consideration. Conformance metrics by definition are
metrics that measure how well a system or set of systems · conform" to a set of standards or
guidance documents . Because key documents in the ANSl/ISA-62443 document series and in the
IEC 61511 document series are in draft or are under major revision, this document by necessity is
written at a high level and the metrics described are based on current practices and consensus of
the authors .

E.2 Introduction
This section uses the core principle of ISO 14253-1 · oecision rules for proving conformance or
non-conformance with specifications" to differentiate whether conformance or non-conformance is
determined .

Conformance metrics should be developed for the cybersecurity policies and practices specific to
the systems under consideration. This section describes general principles, for developing
conformance metrics for systems under consideration and should not be used as prescriptive
metrics .

This section defines the high-priority cybersecurity countermeasure conformance metrics related
to an IACS, including SCAI systems . High-priority metrics focus attention on the performance of
the IACS . The underlying management governance policies, procedures, and organizational
directives conforming to this document are assumed to be enforced by the IACS owner/operator.
These conformance metrics are defined to:

• measure conformance with this document;

• manage the development of secure IACS products and services;

• monitor and manage the user-specified quality of service throughout the deployed life of
the system ;

• verify secure disposal of system , subsystem and components when they are removed from
service ; and

• provide system measurements to be used by compliance authorities.

This section will follow the metrics development checklist as described in Table E.1 below. This
checklist guides the development of a prioritized set of metrics that are measurable, actionable ,
associated with performance criteria in this technical report, mapped to primary users of the metric
and provide the necessary extensions to provide the proper context for cybersecurity
countermeasure conformance metrics .
ISA-T R84 .00.09-2017 - 100 -

Table E.1 - Metric deve lopment check li st

- Pri or ity Doscrl pt lon Romar ks
Metrics should satisfy the criteria Measurable. consistently measured with objective criteria
specified in I SO 14253-1 Context specific: relevant to the user (asset owner. system
integrator. product provider, service provider, and
compliance authority)
NOTE 1 The criteria require metrics to be actionable.
Con ormancc metrics: cx:prcsscd as a cardinal number or
percentage
NOTE 2 Quali tative labels like high, medium and low arc
not acceptable.
NOTE 3 Expressed using at least one unit of measure.
Collection and processing. automated to the maximum cx:tent
possible
NOTE 4 In order to avoid intensive labor and ensure
timeliness, the criteri a recommends the use o automation
where possible.
NOTE 5 Special attention should be given to unknown
vulnerabilities, sometimes referred to as zero-day events.
2 Metrics should be actionable Action trigger values arc informative breakpoints that can be
used or changed by the uscr.
If triggcred. action requircd should bc takcn.
3 Metrics should be associated with Format should prov1dc the capability to relate metrics to the
requirements (basc requirements relevant documents m tho ANSI/I SA 62443 series or IEC
and requirement enhancements) 61511 series.
NOTE 1 Mctrics arc not associated with securi ty level per
SC.

4 Metrics should be mapped to Owner/operator. product supplier, scrvicc provider, system

primary users of the metric integrator. compliance authority
5 Metrics and associated models There arc several challenges to satisfying this requlrcmcnt.
and terminology should adopt the ANSl/ISA 62443 1 1 is currently undergoing major
govcrning requirements in
revisions.
ANSl/ISA 62443 1· 1 and include
the necessary extensions to The modcls and terminology in th is document need to be
provide tho proper contcxt for aligned with ANSl/ISA 62443 · 1 · 1.
system conformance metrics.
 - 101 - ISA-TR84.00.09-2017

High-priority cybersecurity countermeasure conformance metrics are defined in Table E.2 that
satisfy the criteria in Table E.1.

Tab le E.2 - Cybersecurity conformance metri cs

- CMID Conformanco motrlc Common data sourco Rolatos to rollablllt y of SIF

-
CM. 1 Number of access anempts Local logs and intelligent electronic Successful user access attempts
associated with a source address device IEO memory re gisters should be recorded· successful
recorded lby each access point network connections should be
recorded (source/destination) and

CM. 2
I
Number of rej ected access tries and
I Use certificate logs generated by
compared against expected
source/ d est in ation
Re1ected user access attempts
use-certificates requested by each the authenticator should be recorded , investigated
supplican' address from each at some frequency. rejected
legitimate authenticator network attempts should be
I I recorded and investigated

I CM. 3 Percentage of 1ra'fic that fail

authentication verification
Firewall logs, network device (smart
routers and switches) logs. and
This is a way of trending CM 1 and
CM2 - applies to network tra'fic.
IEDs with embedded
challenge/ response authentication
capabilities
ISA-T R84 .00.09-2017 - 102 -

Information on shared product supplier and operator responsibilities is provided in T able E3 below.

Table E.3 - Shared product supplier and operator responsib ilit ies

Metric Metri c Pass/Fall Product s upplier Operator Relation to rellablllty

ID Cri teria Rosponslblll ty Rosponsl blllty of safety function
(Value)
CCM1 Number of program changes >O represents a NIA Respond to and Number of program
witho ut valid change mismatch investigate all changes should relate
authorization (MOC) between actual unauthorized changes , directly to the number o'
NOTE The MOC provides program changes remodiate risks. and approved MOCs:
change authorization, not the and change recover normal
IACS user credentials . authorizations operation.
(MOCs). Unauthorized changes
can compromise the
safety function .
ccm1 -a Number of program changes NIA - IACS program and Program changes arc
measurement configuration ch anges matched to proper
used to calculate are automatically authorization.
primary metric . recorded by tho IACS:
IACS req uires
authorization Identifier
input rom user prior to
change.
ccm1 -b Number of change NIA - NIA Change authorizations
authorizations (MOCs). measurement (MOCs) are recorded:
used to calculate authorization identifier
primary metric. Is recorded in IACS
when change is made.

CCM2 Porcontago of IACS user > 5% roprosents IACS provides Respond to and A high rate o' failed
access attempts that fail situation that percentage of failed investigate high rates IACS user access
authen tication verification should be user access attempts of failed IACS user attempts can Indicate a
Investigated access attempts. situation whore
romodiato risks. and unauthorized users are
recover normal attempting to access to
op oration. tho IACS in a manner
that ca n compromise the
safety function.
ccm2-a Successful IACS usor access NIA - Successful IACS user NJA
attempts measuromonr access attempts are
used to calculato automatically recorded
primary motric. by IACS.
 - 103 - ISA-TR84.00.09-2017

Metri c Metri c Pass/Fall Product supplier Operator Relation to rellablllty

ID Crit eria Res ponslblllty Res pon slblllty of safety funct ion
(Value)
ccm2-b Unsuccessful (failed ) IACS NI A - Unsuccessful IACS N/A
!!!.!!! access attempts measurement user access attempts
used to calculate arc automatically
primary metric. recorded by IACS.

CCM3 Percentage of~ traffic > 1% represents

that is blocked from delivery to situation that
the IACS should be
NOTE For networked /ACS investigated
architectures whore the
network traffic has tho /ACS
identified as tho destination .
ccm3-a Number of successful IACS NI A ·
network traffic connections measuromont
used to calculato
primary metric.
ccm3-b Number of unsuccessful NI A -
(rejected) IACS network traf ic moasur omont
connections (attempted) - for usod to ca/culato
connected systems primary metric.
This page intentionally left blank
 - 105 - ISA-TR84.00.09-2017

Annex F - Manufacturer cybersecurity manual

For IACS components that use technologies that could be subj ect to a cyber attack, designing an
installation that can achieve cybersecurity performance levels without impacting the IACS
performance depends on having clear guidance from the device manufacturer. This guidance
should explain any host-based countermeasure options ava ilable with the device and any
cybersecurity countermeasures that should be applied in the network around the device to address
the device cyber vulnerabilities to achieve SL-T. For standard COTS components used in process
control systems, this information should be considered part of the device operating manual,
whether it is embedded in that document or provided separately. For a cyber vulnerable device
that has been approved for use in safety systems, a manufacturer cybersecurity manual should be
considered part of the safety manual . The cybersecurity manual may be directly incorporated into
the safety manual or it may be a stand-alone document.

The cybersecurity manual should contain the product supplier's recommended I tested I supported
architectures and subsequent cybersecurity instructions that are required to achieve and maintain
cybersecurity SL-T without affecting proper operation of the IACS , including the SCAI systems.
Refer to IEC 62443-2-4 for add itional guidance .

Recommended minimum contents:

• Recommended system architectures with associated recommended enterprise integration
architectures .
• Recommendations for anti -virus protection, remote access, backup, whitelisting, etc.
• Reference to manufacturer's bulletin or support web page providing the current
recommended/tested antivirus or other third party software.
• Position including the user's role regards non-supported third party software .
• Recommended system hardening rules.
o Network naming I IP address structure .
o Services to be disabled per role (HMI, ES, etc .).
• Recommended system network segregation rules.
o Placement of boundary devices (firewalls I encryption I DMZ) per functional role
(HMI , ES, web server, historian , etc.).
o Ports I protocols to be configured (default firewall configuration is to deny all traffic} .
• Recommended authentication I authorization rules.
o Password I default I webserver settings I complexity I rules.
o Domain I local account setup I requirements .
o Role based authentication/ authorization rules I examples.
• Recommended operating system requirements.
o PC settings I BIOS settings I etc .
• Recommended physical access restrictions to be employed by end user.
• Recommended human resource management systems for persons authorized to access
device .
• Any other items required for the user to implement the strategies included in the manual.
Such as , but not limited to:
o Configuration requirements .
o External countermeasures that should be implemented (e .g ., specific quality
firewa ll, administrative procedures , etc .) .
o What diagnostic countermeasures should be implemented (e.g ., intrusion detection
alarms, intrusion prevention, etc.) .
o Periodic inspection and testing that should be performed .
o Any requirements necessary to facilitate recovery following an attack .
This page intentionally left blank .
 - 107 - ISA-TR84.00.09-2017

Annex G - Typical countermeasures

Security levels are intended to apply to zones and conduits rather than individual hardware devices .
There is a need, however, to be able to assess hardware for their robustness regards specific
cyber threats which can either by themselves or in combination with other countermeasures
provide the desired risk reduction.

Table G.1 includes a sampling of potential countermeasures that in general can be expected to
provide increasing risk reduction for threats where they are applicable . Their attributes as shown
help to guide the user as to their applicability with respect to threats . It is in no way a
comprehensive listing. In many cases other countermeasures must be in place to allow credi t for
the countermeasure listed. At a minimum, the personnel security and physical access security
countermeasures must be commensurate with the desired risk reduction for the zone or conduit.

Tab le G.1

Count erm easu re d escrlptlon(s)

Firewall
• General purpose firewall with rulcset known to PC group
Firewall
• Industrial control system stateful firewall

~
Access control list (ACL) managed by PCN group
Minim"m rule ••t defined
ewall
• Industrial control system state'ul firewall
• Access control list (ACL) managed by PCN group
• Minimum rule set defined
• Deep pac ct inspection capability
• No firmware encoded r ules .
I Firewall
• Industrial control system stateful firewall
I· •
Access control list (ACL) managed by PCN group
Rules encoded in irmwarc
• No deep packet inspection capability
Firewall
• Industrial control system state ul firewall
• Access control list (ACL) managed by PCN group
• Rules encoded in irmware, i.e. no external con iguration ability
• Deep packet inspection capability
Router between enterpri se and PCN
• Rules unknown or PCN has no control
Router between enterpri se and PCN
• Rules known by PCN group but not under PCN control
Switch
• Configured to segment network into VLA s
Switch
• Switch configured to segment network into VLANS
I. Incorporates access control hst (ACL) to restrict communications and protocols
ISA-TR84.00.09-2017 - 108 -

Countermeasure description(•)
Vigilant user
Patch management conducted on ad hoc basis
Patch management formal procedures in place
Patch management
• Centrally managed
• Updates in accordance with documented procedure
Patch management
• Centrally managed
• Updates in accordance with documented procedure
• Whitclistlng implemented and updated in accordance with documented procedure
• Formal procedure in place to investigate whitelisting d iscrepancies identified
Anti-virus (AV) so tware
• Installed and periodically updated
Anti-virus (AV) so tware
• Installed and updated per formal procedures when revisions arc made available
~ Updotod w" hln le" than a week whoo oow "pdate• a"llablc
Anti-virus (AV) so tware
• Centrally managed and updated in accordance with documented procedure .
• Updated wnhin less than a week when now updates available
Anti-virus (AV) so tware
• Centrally managed and updated in accordance with documented procedure
• Updated wnhin less than a week when now updates available
• Whitclisting implemented and updated in accordance with documented procedure
• Formal procedure in place to investigate whitelisting d iscrepancies identified
Audit log
• Audit records relevant to cybcrsecurity arc generated or access control, request errors .
operating system events, control system events, backup and restore events, configuration
changes. potential reconnaissance activity and audit log events.
• Individual audit records include the timcstamp , source (originating device, software process
or human user account), category, type, event ID and event result. Suf icicnt audit record
storage capacity exists or log management and system configuration.
• Audit mechanisms arc in place to ensure the capacity is not exceeded .

I. Personnel are alened in tho event of audit processing ailuro wnh appropriate actions in
response de'ined in operating procedures.
 - 109 - ISA-TR84 .00. 09-2017

Countermeasure descrlptlon(s)
I Audit log
Audit records relevant to cybcrsocurity arc generated for access control, request errors.
operating system events. control system events. backup and restore events. configuration
changes , potential reconnaissance activity and audit log events.
Individual audit records include the timcstamp. source (originating device. so twaro process
or human user account), category, typo, event ID and event result.
Internal system clocks synchronize at a configured frequency.
Audit events arc centrally managed.
Audit records arc compiled from multi ple components th roughout the control system into a
system -wide (logical or physical). timo-corrolatod audit tra il.
Audit records arc produced in industry standard formats for analysis by standard commercial
log analysis tools.
Compiled audit records arc periodically analyzed within a timcframc suf icicnt to mitigate the
potential identi fied risk.
Sufficient audit record storage capacity exists for log management and system confi guration.
Audit mechanisms arc in place to ensure the capacity is not exceeded. Warning is
automatically issued when tho allocated audit record storage volume reaches a configured
percentage of maximum audit record storage capacity allowing sufficient time to respond.
Personnel arc alerted in tho event of an audit processing 'ailuro and appropria to actions In
response arc defined in operating procedures.
Audit log
Audit records relevant to cybcrsocurity arc generated or access control, reques t errors.
operating system events. control system events. backup and restore events. configuration
changes , potential reconnaissance activity and audit log events.
Individual audit records include the timostamp, source (originating device. software process
or human user account) , category, typo. event ID and event result.
Internal system clocks synchronize at a configured frequency and timostamp source is
protected from unauthonzed alteration. All alterati ons cause an audn event.
Audit events arc centrally managed.
Audit records arc compiled from multi ple components throughout the control system into a
system -wide (logical or physical), timo-corrolatod audit tra il.
Audit records arc produced in industry standard formats for analysis by standard commercial
log analysis tools.
Compiled audit records arc periodically analyzed within a timeframo sufficient to mitigate tho
potential identi fied risk.
Sufficient audit record storage capacity exists for log management and system configuration .
Audit mechanisms arc in place to ensure tho capacity is not exceeded. Warning is
automatically issued when tho allocated audit record storage volume roaches a configured
percentage of maximum audit record storage capacity allowing suf icicnt time to respond.
Personnel arc alerted in tho event of an audit processing 'ailuro and appropriate actions in
response to an audn processing failure arc defined rn operating procedures.
Portable media

- Controlled via administrative controls

Portable medi a
Ports disabled via software
Control system prevents tho execution of mobile code, requiring proper authentication and
authorization or origin of the code , restricts mobile code transfer to/ rom the control system.
and monitors tho use of mobile code.
Contro l system automatically en orcos configurable usage restrictions that include preventing
tho use o' portable and mobile devices, requiring conte xt specific authorization, and
restricting code and data transfer to/'rom portable and mobile devices.
-
ISA-TR84 .00.09-2017 - 11 0 -

I
Countermeasure deacrlptl on (s)
I Portable media
• Ports disabled via hardware means
• Contrnl system prevents the execution of mobile code. requiring proper authentication and
authorization for origin of the code. restricts mobile code transfer to/ rom the control system,
and monitors the use of mobile code.
• Control system automatically en'orces configurable usage restrictions that include preventing
the use 0 1 portable and mobile devices. requiring context speci'ic authorization. and
restricting code and data transfer to/ rom portable and mobile devices.
Portable media
• Ports disabled via hardware means
Control system automatically en'orces configurable usage restrictions that include preventing
1· the use 0 1 portable and mobile devices. requiring context specific authorization. and
restricting code and data transfer to/ rom portable and mobile devices.
• Portable or mobile devices attempting to connect to a zone are verified to be in compliance
with tho cybersocurity requirements o that zone .
Portable media
• Ports do not exist
Personnel security

-• Standard background check

Personnel security
• Background check looks at social media for terrorist connections as well checking for past
criminal behavior
Personnel security
• Background check looks at social media for terrorist connections as well checking for past
criminal behavior and financial history
• Annual revalidation of background checks
• Access permissions removed at SAME time employee discharged from service
Physical access
• Equipment located in controlled access building
Physical access
• Managed door loc
• Locked enclosure procedure
Physical access
~ Eq,;pmoot loc"od ;n koy " ' ' '°""""°' ooco" mom
Entry limi ted to pre-approved personnel
ysical access
• Equipment located in key card controlled access room
• Entry limi ted to pre-approved personnel
• Unauthorized entry alarm with formal response procedure
Intrusion detection
• Comparison diagnostics employed
• Procedure in place to periodically review diagnostics and investigate anomalies
Intrusion detection
• Comparison diagnostics employed with alarm
• Procedure requires immediate response to investigate and respond to anomalies
Intrusion detection
• Comparison diagnostics employed with alarm
• Procedure requires immediate response to investigate and respond to anomalies
I. Periodic drills to validate proven in use for assumed value
 - 111 - ISA-TR84 .00.09-2017

In designing an IACS cybersecurity monitoring organization , and in evaluating the combined

effectiveness of the countermeasures and associated monitoring activities in deferring a
successful attack, it is important to understand where the coun term easures are effective in the
attack sequence . An example method that can be used to demonstrate this is the Lockheed Kill
Chain Phases [2 1 1. Table G .2 shows the progression of activities an attacker would have to take
for a targeted malware attack according to the Lockheed Kill Chain Model 121 1 for Advanced
Persistent Threats (APT). Table G.3 then provides a sample list of countermeasures and what
phase of the Lockheed Kill Chain Phase [21 1 they are believed to be effective .

Table G.2

Kiii Chain Ph ase 12·1 Descri ption

-
Reconnaissance
-- ..-
Research performed to identify and select target
Weaponization Means o' coupling a Trojan and an exploit designed to accomplish attacker's

Delivery
Exploitation
-- obj ective
Transmission o' the we apon into the targeted system
Attacker's code triggered
-

Installation Allows attacker to maintain a presence within the system. e.g .. remote access

Command and control

-- - Trojan or backdoor
Allows attacker access to the programming I confi guration keyboard
-
-
Actions on obj ectives Attacker can now achieve their objecti ve

Table G.3

Countermeasure type Kiii Chain Ph ase 121 1

Web analytics Reconnaissance

Firewall Reconnaissance
Command and control
Router between enterprise and PCN Reconnaissance
Delivery
Switch Delivery
Network Intrusion Detection System (NIDS) Reconnaissance
Delivery command and
control
Network Intrusion Prevention System ( IPS) Reconnaissance
Delivery
Command and control
Vigilant user Delivery
Proxy filter Reconnaissance
Delivery
In-line anti-virus (AV) Delivery
Exploitation
Host Intrusion Detection System (HIDS ) Exploitation
Installation
Patch management Exploitation
Data Execution Prevention (DE P) Exploitation
ISA-TR84 .00.09-2017 - 112 -

I Kiii Chai n Phase 12 1 1

Count ermeasure t ype
Antt.virus (AV) so'tware lnstalla1ion
Tarpit Reconnaissance
Command and control
Audit log Actions on objec1ives
Qualily of service metri cs Actions on objec1ives
Honeypo1 Actions on objec1ives
Portable media protection Reconnaissance
Delivery
Exploitation
Personnel security Reconnaissance
Delivery
Physical access protection Weaponization
Reconnaissance
Delivery
Exploitation

T his information can be used in evaluating the potential effectiveness of counterm easures to
protect against threats being made through different attach vectors or paths . Table G.4 provides
an example analysis showing a small sample of threats and vectors , the countermeasures that
may provide some level of risk reduction against those attacks, and the kill c hain phase(s ) where
each countermeasure would be effective .
Table G.4
I I !
Threat Vector Potenti al counterm easures K iii Chain Phase 121 1

Denial of Portable Ponable media protection

service media
Via interne1 Firewall Reconnaissance
Command and cont rol
General Portable Ponable media protection
viru s media
Personnel security
Physical access protection Weapon ization
Patch management Exploita tion
In-Imo an ti -virus (AV) Delivery
Exploitation
Anti-virus (AV) software Installation
V ia interne1 Patch management Exploitation
In-line an ti-virus (AV) Delivery
Exploitation
Anti-virus (AV) software Installation
 - 113 - ISA-TR84.00.09-2017

Annex H - ISA-TR84.00.09 / IEC 61511 cross references

CroH reference t•ble between ISA-TR 84.00.01 end IEC 81511

Clausos IS A· TR 84.00.09 IEC 61511 Commonts

Integrated lifecycle Clause 0.2 Clause 6 Safety lifecyclo requirements

Management of IACS cybersocurity Clause 4 Clause 5

Cybersecurity assessment phase Clause 5 Clause 5 5.2.6. 1

Cybor risk ana lysis Clause 6 Clause 8

Allocation of security levels (SL) Clause 7 Clause 9

Cybersecurity requ irements specification
(CSRS) for tho IACS Clause 8 Clause 10. 12

Cyborsecurity design and implement phase Clause 9 Clause 11 . 12

Design and engineering Clause 10 Clause 11 . 12

Installation. commissioning and validation Clause 11 Clause 14. 15

Operation and mainten ance Clause 14 Clause 16

Modification Clause 15 Clause 17

Decommissioning Clause 16 Clause 18

ISA-TR84 .00.09-2017 - 114 -

Bibliography
NOTE. Draf t b ibliography items referenced in the body of the report refer to the draft copy current as of the date of
ISA-TR84 .00.09.

(1 ) ANSl/ISA-62443-1-1 (99.01 .01 )-2007, Security for Industrial Automation and Control Systems Part
1: Terminology, Concepts. and Models.

(2) DRAFT ISA-TR62443-1-2, Security for Industrial Automation and Control Systems Part 1-2: Master
Glossary. Unpublished.

(3) DRAFT ISA-62443-1-3, Security for Industrial Automation and Control Systems Part 1-3: Cyber
Security System Conformance Metrics . Unpublished.

(4) DRAFT ISA-TR62443-1-4, Security for Industrial Automation and Control Systems Part 1-4:
Security Life Cycle and Use Cases . Unpublished.

(5) ANSl/ISA-62443-2-1 (99.02.01 )-2009, Security for Industrial Automation and Control Systems Part
2-1 : Establishing an Industrial Automation and Control Systems Security Program .

(6) DRAFT ISA-TR62443-2-2, Security for Industrial Automation and Control Systems Part 2-2:
Implementation Guidance for and /ACS Security Management System . Unpublished.

(7) ANSl/ISA-TR62443-2-3-2015, Security for Industrial Automation and Control Systems Part 2-3:
Patch Management i n the /ACS Environment.

(8) IEC 62443-2-4. Security for Industrial Automation and Control Systems Part 2-4: Requirements for
IACS Solution Providers.

(9) ANSl/ISA-TR99.00.01 -2007. Security Technologies for Industrial Automation and Control Systems.

(1 OJ DRAFT ISA-62443-3-2, Security for i ndustrial automation and control systems Part 3-2: Security
risk assessment for system design . Unpublished .

[11] ANSl/ISA-62443-3-3 (99.03.03)-2013, Security for Industrial Automation and Control Systems Part
3-3: System Security Requirements and Security Levels.

[12] DRAFT ISA-62443-4-1, Security for Industrial Automation and Control Systems Part 4-1 : Secure
product development lifecycle requirements. Unpublished.

[13] DRAFT ISA-62443-4-2, Se curity for Industrial Automation and Control Systems Part 4-2: Technical
Security Requirements for IACS Components . Unpublished.

(14 J ISO/I EC 27002, Information technology - Security techniques - Code of practice for information
security controls.

(15] ISA-TR84.00.03-2012, Mechanical Integrity of Safety Instrumented Systems (SIS) .

[16] Thomas H. W & Day J .; Integrating Cyberse curity Risk Assessments into the Process Safety
Management Work Process, 11th Global Congress on Process Safety, April 2015.

(17] Bhojani. R.; IT Security and Functional Safety in Industrial Automation and Control Systems (/ACS) ,
Automation Conference, Baden-Baden, German y, 2010.

[18] CCPS, Guidelin es for Safe Automation of Chemical Processes . peer review copy, 2015.

(19] CCPS, Guidelines for Developing Quantitative Safety Risk Criteria, 2009.

[20] NIST, Framework for Improving Critical Infrastructure Cybersecurity, Version 1.0, 12 February 2014 .
 - 115 - ISA-TR84 .00.09-2017

[21] Hutchins. E.M; Cloppert, M. J .; and Rohan, A. M.; Intelligence-Driven Computer Network Defense
Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains , Lockheed Martin
Corporation.

[22] DRAFT A Sll lSA-84 .91 .03, Functional Safety: Safety Controls, Alarms, and Interlocks for the
Process Sector. Unpubl ished .

[23) ANSl/ISA-95.00.01-2010 (IEC 62264-1 Mod), Enterprise-Control System Integration - Part 1:

Models and Terminology.

[24 J ANSlllSA-18.2-2016, Management of Alarm Systems for the Process Industries.

This page inten tionally left blank.
Developing and promulgating sound consensus standards, recommended practices, and technical
reports is one of ISA's primary goals. To achieve this goal the Standards and Practices
Department relies on the technical expertise and efforts of volunteer committee members,
chairmen and reviewers.

ISA is an American National Standards Institute (ANSI) accredited organization. ISA administers
United States Technical Advisory Groups (USTAGs) and provides secretariat support for
International Electrotechnical Commission (IEC) and International Organization for
Standardization (ISO) committees that develop process measurement and control standards. To
obtain additional information on the Society' s standards program , please write:

ISA
Attn : Standards Department
67 Alexander Drive
P.O . Box 12277
Research Triangle Park , NC 27709

ISBN: 978-1-945541-49-0