698

698
FRAMEWORK FOR EPU OPERATORS

TO MANAGE THE RESPONSE
TO A CYBER-INITIATED THREAT
TO THEIR CRITICAL INFRASTRUCTURE
WORKING GROUP
D2.38
SEPTEMBER 2017
FRAMEWORK FOR EPU OPERATORS
TO MANAGE THE RESPONSE TO A
CYBER-INITIATED THREAT TO THEIR
CRITICAL INFRASTRUCTURE
WG D2.38
Members
D. HOLSTEIN, Convenor US T.W. CEASE, Secretary US
C. NEWTON US S. BUSCHI IT
A. STEFANNI IT J. WEISS US
F. HOHLBAUM CH C. POIRIER-GALMICHE FR
K. PANYIM TY P. SEDTHEETHORN TY
V. TAN AU D. BORDEA RO
J.P. MENNELLA FR T. WLODARCZYK PL
A. KOZAKIEWICZ PL M. FAUCHON CA
V. DISTEKRATH DE J. WACK US
M. RAAUM NO
Corresponding Members
I. PATRIOTA DE SIQUEIRA BR E. OHBA JP

S. VERGERIO FR H. FALK US
A. JOHNSON US A. GINTER CA
L. DELLIGATTI US D. KITTEY US
Copyright © 2017
“All rights to this Technical Brochure are retained by CIGRE. It is strictly prohibited to reproduce or provide this publication in
any form or by any means to any third party. Only CIGRE Collective Members companies are allowed to store their copy on
their internal intranet or other company network provided access is restricted to their own employees. No part of this
publication may be reproduced or utilized without permission from CIGRE”.
Disclaimer notice
“CIGRE gives no warranty or assurance about the contents of this publication, nor does it accept any responsibility, as to the
accuracy or exhaustiveness of the information. All implied warranties and conditions are excluded to the maximum extent
permitted by law”.
WG XX.XXpany network provided access is restricted to their own employees. No part of this publication may be
reproduced or utilized without permission from CIGRE”.
Disclaimer notice ISBN : 978-2-85873-401-6

“CIGRE gives no warranty or assurance about the contents of this publication, nor does it accept any responsibility, as to the
FRAMEWORK FOR EPU OPERATORS TO MANAGE THE RESPONSE TO A CYBER-INITIATED THREAT TO THEIR CRITICAL INFRASTRUCTURE
EXECUTIVE SUMMARY
INTRODUCTION
WG D2.38 built this technical brochure leveraging the extensive research by others – 67 references are
included in the bibliography and cited in the main body text and annexes of the brochure. Working group
subject matter experts then tailored the findings of thiss research for EPU applications.
The National Institute of Standards and Technology (NIST) published the “Preliminary
Cybersecurity Framework 1” October 29, 2013. NIST’s framework is compri sed of a Core, a Profile,
and Information Tiers. The Core contains standards and best practices that are common across all
sectors and industries. Reed Smith published an interesting article “NIST Cybersecurity Framework:
Is it going off the rails.” Smith’s article reached the following conclusions that reinforce the need
for this technical brochure.
1) The standards divide into five functions: Identify, Protect, Detect, Respond and Recover,
which are generally consistent with industry and international inform ation standards such as
ISO 27001.
2) The Profile section intends to be a tool for a company [EPU] to map its “Current” alignment
with the standards against a “Target” profile that will address identified cybersecurity risk.
3) The framework provides the concept of a profile but does not specify the templates for
creating one.
Thus, a tool set must provide the capability to receive, store, model, retrieve, and send cyberspace
information to all system components. Implementation of the tools must have the capability to receive
real-time information from various network components and operation overlay sources.
Such an automated response is needed to provide sufficient oversight information to manage the
response and recovery. Visualization of the situation and clar ity of response options is critical.
In response to a cyber-initiated attack, Lockheed Martin developed the concept “cyber kill chain”
to describe seven phases of an attack: 1) Reconnaissance, 2) Weaponization, 3) Delivery, 4)
Exploitation, 5) Installation, 6) Command and control (C2), and 7) Actions on objectives.
In the paper “Intelligence-Driven Computer Network Defense Informed by Analysis of Adversary

Campaigns and Intrusion Kill Chains,” Hutchins, Cloppert, and Amin describe the kill chain in detail
and provide a course of action matrix with recommended defensive measures for each phase. If
an attack is successful their approach can be used by the EPU response team both for forensic
and analysis because the needed data, or artefacts of the attack, shou ld be found in each of the
seven steps. For a defense mechanism, the mitigation can be implemented at any phase of the
chain because once that phase of the chain is protected the adversary hast to restart the attack.
A defense-in-depth strategy should implement mitigation at several stages of the chain.
The working group responsible for this technical brochure understood the need for the framework
to adapt easily to new requirements that evolve from local laws and regulations, changes in the
threat environment, and improvements in CERT process for information sharing and
responsiveness. This is a tall order, so this working group’s vision was to establish a few high -
priority specifications for the framework. Work by others will continue to build on the basic
framework so that future CIGRE working groups can issue updates to this technical brochure.
1 Improving Critical Infrastructure Cybersecurity – U.S. Executive Order 13636, issued February 12, 2013.
3
Based on feedback from the global survey patch management and ICS-CERT response applications
are the highest priority, and therefore are the topics in this technic al brochure.
SUMMARY OF FINDINGS AND RECOMMENDATIONS

Given the input from the survey respondents, this report focused attention on the following issues.
1) Commercial tools are available to collect, process and report cyber threat data. EPUs cannot
claim that lack of tools is why they don’t maintain and monitor logs of security data to
generate alarms created by abnormal access or use of protection and control (P&C) networks
and IEDs.
2) The major impediment to converting security data to actionable information i s the need for
personnel with specialized cybersecurity training.
3) Although teamwork is important, EPUs still rely mainly on IT personnel to lead investigative
teams with OT personnel playing a support role.
4) The preferred metric to measure impact is downtime per hour, but system average
interruption disruption index (SAIDI) and system average interruption frequency index
(SAIFI) are important supporting metrics.
5) EPUs generally use their own subject matter experts to build a consensus of the strength of
security needed to mitigate interference with, interruption of, or disablement of their P&C
operations. They find it too difficult to use the esoteric approaches described in emerging
standards and guidelines, and prefer to stay focused on the perceived impact to operations.
6) EPUs are most worried about cyber-attacks targeting control room or integrated security
operation centre (ISOC). They further believe that a compromised insider is needed to
execute an effective cyber-attack. However, the robustness and resilience (hot backup and
hot switch-over capabilities) built into their P&C architecture is very effective in thwarting a
cyber-attack.
7) In relation to remote services, the EPU’s security architecture needs meet the border and
edge security requirements, which have stricter requirements and controls than internal
networks. This is because security measures (both technical and non -technical) affecting
remote services are often first line of defense on the entry points of untrusted entities.
8) Staging of patches in a test or development environment is highly recommended for
assurance of the patches. It provides an early detection of compatibilit y issues with control
systems software and with host-based monitoring in the test environment, provides detection
of any behavior change of the system after applying patches. For example, sudden increase
in network traffic, previously unseen network traffi c and sudden high memory or CPU usage.
Unfortunately, there is no way to prevent or guard against cyber -attacks against EPU networks
and IEDs residing on those networks. The pace of threat development is too fast and too diverse
for EPUs to install protective measures to mitigate advanced persistent threats. Managing
responses to cyber-attacks in a timely manner will mitigate the potential consequences that result
from attempts to interfere with, disrupt, or disable mission critical EPU operations. Followin g are
recommendations that provide a foundation to effectively manage the response to cyber -attacks.
9) Maintain an up-to-date list of all critical EPU assets, configurations, and settings. Most
importantly, the interaction between automated IED initiated a ctions should be well
documented and be up-to-date.
10) EPU employees and support contractors should be periodically briefed on security threats,
security policies, procedures and organizational directives to maintain a heighted awareness
to the security situation. All such briefings should require a signature by the participants
4
indicating they understand the security issues and their individual responsibility to comply
with EPU security directives and local laws and regulations.
Security leaders can improve targeted attack detection capabilities using their security information
and event management tools, but it requires investments in expertise processes, and
complementary technologies.
11) Invest in the necessary expertise to define and implement continuous tu ning and operation
of the security information and event management (SIEM) and analysis tools, in “hunger
investigators” to proactively identify compromises.
12) Use forward-leaning technologies, like user and entity behavior analytics (UEBA), and
advanced threat defense solutions like end point detection and response (EDR) and network
traffic analyzer (NTA) to extend SIEM capabilities to detect advanced threats.
13) Monitoring to detect targeted attacks requires a balance of active SIEM administration and
tuning, visibility beyond security operations people and tools, and investment in
complementary detection technologies, and mature processes that cut across the IT and OT
organizations.
Managed by central management console, the data loss prevention (DLP) suite should provide the
visibility and control of critical assets over EPU segmented networks, endpoint, and off-premise.
Discovery and classification of EPU sensitive data stored in locally controlled systems is critical. The
following modules provide these capabilities.
Gateway inspector: Each EPU network segment should include a DLP gateway that monitors and
enforces DLP policy based on controls such as block, quarantine, route to encryption gateway, audit and
log, pass, alert and notify, severity block and severity quarantine, and redact over the network segment
covering all channels and ports on all protocols.
Endpoint protector: An agent that monitors and enforces automated DLP policy based controls for
data-in-motion to all endpoint and removable media. Controls such as block, encrypt, audit and log,
notify and alert on violations of confidentiality data, integrity data, and application data.
eDiscovery: An agent that discovers, classifies and remediates confidentiality data, integrity data and
application data stored in locally controlled repositories, file shares, etc. Remediation includes the
capability to “copy to”, “move to”, “delete”, or enforce digital rights management (DRM) policy in real
time.
Digital rights management: An agent that enforces automated DLP policy based controls for data-in-
use by controlling the entity (human or machine) that can access a file, where they can access the file,
and when or where the can be accessed.
EPU cybersecurity protection policies, procedures, and organizational directives should include any
function or location serving the edge (logical or physical) of their network. The edge includes
remote access virtual private network (VPN) and unmanned remote sites. Hence, the posture
validation of the devices accessing these edges of the network should be a requirement.
At the perimeter of each EPU network segment, reduce the threat footprint by blocking a wide
range of unwanted applications and then inspecting the allowed applications for threats – both
known and unknown. Key perimeter protection for t he next-generation firewall includes the
following enablement requirements 2.
2 Contributions from Palo Alto Networks (www.paloaltonetorks.com) were used to develop the tool suite for perimeter
defense.
5
Identify applications, not ports: Classify traffic, as soon as it arrives at the firewall, to
determine the application identity, irrespective of protocol, encryption or evasive t actic. Use
that identity as the basis for all EPU security policies.
Tie application usage to user identity, not IP address, regardless of location or device:
Employ user and group information from EPU managed directories or approved third -party
directories to deploy consistent enabling policies for all users, regardless of location or device.
Protect against all threats – both known and unknown: Prevent known vulnerability exploits,
malware, spyware, malicious uniform resource locators (URLs) while analysing traffic for
tunnelled traffic and automatically delivering protection against highly targeted and previously
known malware.
Simplify policy management: Enable EPU applications and reduce administrative efforts with easy-to-
use graphical tools, a unified policy editor, templates, and device groups.
Cyber threats can easily bypass a port-based firewall by hopping ports using SSL and SSH sneaking
across port 80, or by using non-standard ports. Port-based firewall vulnerabilities are discussed in
Annex D. Products such as AppID™ 3 address the traffic classification visibility limitations of
traditional firewalls by applying multiple classification mechanisms to the traffic stream to
determine the exact identity of the application traversing the EPU network seg ment. Unidentified
applications, typically a small percentage of traffic, yet high in potential risk, should for systematic
management based on control and inspection, threat forensics, etc. automatically be categorized.
Common threat evasion tactics such as port-hopping and tunnelling should be addressed by
executing approved EPU threat prevention policies using the application and protocol context
generated by decoders. EPU procurement should compare tool suites offered by the vendors to
evaluate how well their solution provides the following security capabilities.
Block known threats (IPS and network antivirus/anti-spyware: The capability to use a
uniform signature format and a stream-based scanning engine to enable the EPU to protect
the network segment from a broad range of threats.
14) Intrusion prevention system features block network and application -layer vulnerability
exploits, buffer overflows, denial of service (DoS) attacks, and port scans.
15) Antivirus/anti-spyware protection blocks malware variants, malware-generated command and
control traffic, PDF viruses, and malware hidden within compressed files or web traffic.
16) Policy-based SSL decryption across any application on any port protects against malware
moving across SSL encrypted applications.
Block unknown, targeted malware: The capability to identify and analyze unknown or targeted
malware, which directly executes and observes unknown files in a cloud -based, virtualized
environment.
Identify bot-infected hosts: The capability to classify all applications, across all ports, including
any unknown traffic to expose anomalies or threats to the EPU network or network segment.
17) The behavioral botnet report should correlate unknown traffic, suspicious DNS and URL
queries and a variety of unusual network behaviors to reveal devices that malware can likely
infect.
18) Display the results in the form of a list of potentially infected hosts to investigate possible
members of a botnet.
3 App-ID™, a patent-pending traffic classification system is only available in Palo Alto Networks firewalls. App -ID™
instantly applies multiple classification mechanisms to your network traffic stream, as soon as the device sees it, to
identify accurately applications.
6
Limit unauthorized file and data transfers: The capability to filter data based on EPU security
policies that will reduce the risks associated with unauthorized file and data transfers.
19) File transfers should be controlled by looking inside the file (as opposed to looking only at
the file extension), to determine if the transfer act ion should be allowed or not.
20) Unless sent from a well-authenticated and trusted source, executable files, typically found in
downloads from remote configuration tools to upgrade protection relays, can be blocked,
thereby protecting EPU networks and network segments from unseen malware propagation.
21) Enable data filters to detect and control the flow of sensitive data within the EPU network
and network segments. IEC 62443 offers guidelines to restrict such data flows in a federated
and segmented architecture.
Control web or cloud surfing: The capability to customize the filtering engine to apply EPU granular
browsing policies requires integration with the vendor’s tool suite.
The purpose of application whitelisting is to protect the host environment and applications from
unauthorized code (malware-based injection, remote-execution), thereby compromising the host
environment.
According to the US National Security Agency (NSA), application whitelisting is not a replacement
for traditional security software, such as antivirus and host firewalls(Agency). Using whitelists is
one layer in a defense-in-depth strategy. Table 4-1 shows the advantages and disadvantage listed
by NSA.
Table 1 Advantages and disadvantages of application whitelisting
Advantages Disadvantages
Blocks most current malware Requires performance overhead to enforce the whitelist
(varies greatly depending on implementation)
Prevents use of unauthorized applications Requires regular maintenance of the whitelist to add
new applications and remove ones that are no longer
approved
Does not require daily definition updates Causes some users to be annoyed because they cannot
download and run applications at will
Requires administrator installation and approval of new Requires additional time and manpower to maintain.
applications
Whitelisting provides a dramatic improvement in the level of visibility into files being introduced
into an environment. This can be extremely helpful for incident responders. To reduce significantly
the risk of today’s malware organizations [EPUs] can use the technology. This helps reduce the
likelihood of system compromise and reduces cost of staff to deal with malware related issues.
Considering the nature of application whitelisting, it is most useful in static environments, i.e. where there
is a very low rate of change, resulting in a reduced operational overhead in maintaining a valid whitelist.
These include systems that are updated less frequently (where availability is of the utmost priority),
undergoes fewer configuration changes and have little need to install additional software after
commissioning. Examples of such systems include SCADA servers, HMIs and Engineering Workstations.
IN CONCLUSION
This technical brochure offer an indepth view of the issues, benefits and concerns of proposed solutions
that should be considered by EPU security teams. These views focus on people, processes and
technologies that should be reflected in EPU security policies, procedures and organizational directives.
7
8
TABLE OF CONTENT
EXECUTIVE SUMMARY ................................................................................................................................ 3
INTRODUCTION ....................................................................................................................................................................................... 3
SUMMARY OF FINDINGS AND RECOMMENDATIONS .................................................................................................................. 4
IN CONCLUSION ..................................................................................................................................................................................... 7
1. SCOPE ............................................................................................................................................. 13
2. INTRODUCTION ............................................................................................................................ 14
2.1 BACKGROUND ........................................................................................................................................................................ 14
2.2 CRITICAL INFRASTRUCTURE DEPENDS ON THE USER AND SITUATION .................................................................... 15
2.2.1 The impact of European regulations .......................................................................................................................... 15
2.2.2 Leverage the NERC CIP definitions ............................................................................................................................ 16
2.2.3 OECD’s characterization of criticality ....................................................................................................................... 16
2.2.4 Classification method and key measures enforced by law .................................................................................. 17
2.3 STRONG PERIMETER DEFENSE SOLUTIONS ..................................................................................................................... 18
2.3.1 An example unidirectional architecture .................................................................................................................... 18
2.3.2 Advanced persistent threats on perimeter defense ............................................................................................... 19
2.3.3 How effective are unidirectional gateways? ........................................................................................................... 20
2.3.4 Protection against high networks ................................................................................................................................ 20
2.3.5 TCP/IP protocols ............................................................................................................................................................ 20
2.3.6 Clarification of 2.3.3 item 3) ...................................................................................................................................... 21
2.4 FOCUS ON THE INSIDER THREAT........................................................................................................................................ 21
2.4.1 Scenario assumptions .................................................................................................................................................... 21
2.4.2 High-level SysML collaboration model ..................................................................................................................... 22
2.4.3 Threat collaboration ...................................................................................................................................................... 23
2.4.4 Log action and security manager 24/7 data exploitation .................................................................................. 24
2.5 THE NEED TO ENFORCE SECURITY ROBUSTNESS ........................................................................................................... 24
2.5.1 Translating security robustness .................................................................................................................................... 24
2.5.2 Perimeter defense enables security robustness ....................................................................................................... 25
2.6 THE NEED FOR PLUG AND PLAY......................................................................................................................................... 25
2.7 NOTIONAL EPU CRITICAL INFRASTRUCTURE ARCHITECTURES .................................................................................... 25
2.8 CLOUD COMPUTING IS AN EVOLVING PARADIGM .................................................................................................... 26
2.8.1 The NIST framework ...................................................................................................................................................... 26
2.8.2 Shared responsibility and accountability ................................................................................................................. 26
3. SUMMARY OF FINDINGS AND RECOMMENDATIONS ......................................................... 27

3.1 HIGHLIGHTS FROM THE SURVEY ........................................................................................................................................ 27
3.2 RECOMMENDATIONS TO MANAGE RESPONSES TO CYBER-ATTACKS ................................................................... 27
3.3 RECOMMENDATIONS TO STRENGTHEN PERIMETER DEFENSE .................................................................................... 28
3.4 COMMERCIAL PLUG AND PLAY TOOLS ........................................................................................................................... 29
9
4. TOOL SET REQUIREMENTS .......................................................................................................... 31

4.1 WHAT CORE CAPABILITIES ARE REQUIRED TO PREVENT SENSITIVE DATA LOSS .................................................. 31
4.2 IT PERIMETER PROTECTION SUITE ....................................................................................................................................... 31
4.2.1 Focus on classifying traffic ........................................................................................................................................... 32
4.2.2 Protect EPU enabled applications .............................................................................................................................. 32
4.2.3 How effective is whitelisting? ...................................................................................................................................... 33
5. PLUG AND PLAY TOOLS SETS ................................................................................................... 35

5.1 INTRODUCTION ...................................................................................................................................................................... 35
5.2 COMMERCIAL/OPEN SOURCED TOOLS .......................................................................................................................... 35
6. PATCH MANAGEMENT APPLICATION ...................................................................................... 37
7. ICS-CERT RESPONSE APPLICATION .......................................................................................... 39

7.1 MANAGING RISK AND CREATING RESILIENCE ............................................................................................................... 39
7.2 INCIDENT HANDLING RESPONSE ....................................................................................................................................... 39
7.2.1 In near real time – detect and contain...................................................................................................................... 40
7.2.2 Post mortem analysis and closure – “How and why did the event (incident) occur?” ..................................... 40
7.3 COORDINATED VULNERABILITY DISCLOSURE ................................................................................................................. 41
7.4 EMERGENCY COORDINATION AND CRISIS MANAGEMENT....................................................................................... 42
7.5 EU PUBLIC POLICY, LAWS AND REGULATIONS.............................................................................................................. 43
7.6 EFFECTIVE REPORTING REQUIRES AN INTEGRATED SECURITY OPERATIONS CENTRE ......................................... 44
8. BIBLIOGRAPHY .............................................................................................................................. 47
ANNEX A. DEFINITIONS, ABREVIATIONS AND SYMBOLS ............................................................... 51

A.1. GENERAL TERMS ..................................................................................................................................................................... 51
A.2. SPECIFIC TERMS ...................................................................................................................................................................... 51
A.3. ACRONYMS AND ABBREVIATIONS .................................................................................................................................... 56
ANNEX B. SURVEY OF CYBER THREAT READINESS........................................................................ 59

B.1 BASELINE CAPABILITIES REQUIRED ..................................................................................................................................... 59
B.2 SURVEY QUESTIONS ............................................................................................................................................................. 59
B.3 SUMMARY OF SURVEY FINDINGS ..................................................................................................................................... 62
ANNEX C. SYSTEM DYNAMICS MODEL OF AN INSIDER ATTACK .............................................. 67

C.1 INTRODUCTION ...................................................................................................................................................................... 67
C.2 SECURITY LEVEL MANAGEMENT ENFORCEMENT ........................................................................................................... 67
C.3 SYSTEM DYNAMICS VIEW OF INSIDER INCIDENTS ON DOWNTIME ....................................................................... 67
C.4 RATE EQUATION TO MEASURE IMPACT OF INCIDENTS ............................................................................................... 68
C.5 RATE EQUATION TO MEASURE DOWNTIME RECOVERY ............................................................................................. 69
10
C.6 SYSTEM DYNAMICS VIEW OF SECURITY LEVEL REDUCTION ...................................................................................... 69
ANNEX D. FIREWALL VULNERABILITIES ............................................................................................. 71

D.1 FUNDAMENTAL LIMITATIONS OF FIREWALL TECHNOLOGY ...................................................................................... 71
D.2 WHY PORT-BASED FIREWALLS ARE NOT EFFECTIVE ..................................................................................................... 71
D.3 IDENTIFYING AND PREVENTING ROUTER, SWITCH, AND FIREWALL VULNERABILITIES ....................................... 72
D.3.1 Firewall dataflow model identifies vulnerability opportunities ........................................................................... 72
D.3.2 Firewalls are easy targets for hackers ..................................................................................................................... 73
D.3.3 Deep dive into an analysis of firewall vulnerabilities ........................................................................................... 74
ANNEX E. CHECKLIST OF MEASURES TO HELP MITIGATE CYBER-ATTACKS ON EPU

COMMUNICATION CONTROL CHANNELS......................................................................................... 77
E.1 COUNTERMEASURE OBJECTIVE .......................................................................................................................................... 77
E.2 DETECT KNOWN-BAD NETWORK ACTIVITY ................................................................................................................... 77
E.3 DETECT ANOMALOUS NETWORK ACTIVITY ................................................................................................................... 77
E.4 DENY CONTROL ACTIVITY ................................................................................................................................................... 78
ANNEX F. REQUIREMENTS COVERAGE ANALYSIS ........................................................................ 79

F.1 OVERVIEW ............................................................................................................................................................................... 79
F.2 REQUIREMENT ELEMENTS ..................................................................................................................................................... 79
F.3 BASIC PRINCIPLES UNDERLYING RCA ............................................................................................................................... 80
F.3.1 Introduction ...................................................................................................................................................................... 80
F.3.2 Non-technical RCA ......................................................................................................................................................... 80
F.3.3 Technical RCA ................................................................................................................................................................. 81
F.4 SYSML FRAMEWORK EXTENSIONS ................................................................................................................................... 82
F.4.1 Packages and packable elements ............................................................................................................................. 82
F.4.2 Stereotypes to customize SysML notation ................................................................................................................. 83
F.4.3 Moving on to block definition diagrams ................................................................................................................... 83
ANNEX G. CLOUD COMPUTING SECURITY CHALLENGES ....................................................... 85

G.1 TAILORING GUIDELINES ....................................................................................................................................................... 85
G.1.1 Five essential characteristics of cloud computing .................................................................................................... 85
G.1.2 Service models................................................................................................................................................................ 85
G.1.3 Deployment models ....................................................................................................................................................... 86
G.1.4 Recommendations to evaluate a cloud access security broker ............................................................................ 86
G.2 AN OVERVIEW OF EPU SECURITY ISSUES FOR CLOUD COMPUTING ..................................................................... 87
G.2.1 Introduction to risk issues .............................................................................................................................................. 87
G.2.2 Summary of systematic review of security issues for cloud computing .............................................................. 87
G.2.3 EPU’s need to understand the relationships and dependencies between cloud service models .................. 88
G.2.4 Vulnerabilities in cloud computing .............................................................................................................................. 88
G.2.5 Threats in cloud computing ........................................................................................................................................... 89
G.2.6 Relationship between threats, vulnerabilities and countermeasures ................................................................... 90
G.3 POTENTIAL EPU USE OF CLOUD COMPUTING ............................................................................................................... 91
G.3.1 Introduction to potential EPU use of cloud computing ............................................................................................ 91
G.3.2 Potential P&C use of cloud computing ...................................................................................................................... 92
G.3.3 Potential applications for energy management (61)............................................................................................. 92
G.3.4 Potential Smart Grid use of cloud computing .......................................................................................................... 92
11
G.3.4.1 Smart Grid motivation for using cloud computing services .............................................................................. 92
G.3.4.2 Leveraging the cloud-based services for data protection ............................................................................... 93
G3.5 Potential use of cloud computing ................................................................................................................................ 93
G.4 RECOMMENDED SECURITY GUIDELINES FOR EPU USE OF CLOUD COMPUTING ................................................. 94
G.4.1 Common security recommendations ........................................................................................................................... 94
G.4.2 Security recommendation for the use of deployment models .............................................................................. 94
G.4.3 Security recommendations for the use of service models ...................................................................................... 94
TABLE OF TABLES
Table 1 Advantages and disadvantages of application whitelisting ..........................................................7
Table 4-1 Advantages and disadvantages of application whitelisting ..................................................... 33
Table B-1 Cyber threat capability survey questions .............................................................................. 59
Table B-2 Survey response summary .................................................................................................. 62
Table G- 1 Vulnerabilities in cloud computing ...................................................................................... 88

Table G- 2 Threats in cloud computing ............................................................................................... 89
Table G- 3 Relationships between threats, vulnerabilities and countermeasures .................................... 90
Table G- 4 Potential applications for energy management ................................................................... 92
TABLE OF FIGURES
Figure 1 Unidirectional reference architecture ................................................................................ 19
Figure 2 Trusted on-site technician ............................................................................................... 21
Figure 3 Threat collaboration model .............................................................................................. 23
Figure 4 Example Whitelisting Actions by Windows AppLocker Integrated into a monitoring solution . 34
Figure 5 Incident handling module ................................................................................................ 40
Figure 6 Model-Based Predictive Classification Concept: Incoming data processed to infer observations41
Figure 7 Typical coordinated disclosure process ............................................................................. 42
Figure 8 Emergency coordination and crisis management ............................................................... 43
Figure 9 EPRI’s high-level ISOC architecture .................................................................................. 44
Figure 10 Key technologies used at different layers in an ISOC ....................................................... 45
Figure 11 Effect of Insider incidents on system downtime ............................................................... 68
Figure 12 Security level reduction ................................................................................................. 70
Figure 13 Firewall operations and data flow ................................................................................... 73
Figure 14 EPU generating station system model ............................................................................. 83
Figure 15 - Security policy framework (66) .................................................................................... 95
12
1. SCOPE
This technical brochure describes a framework for a tool set that electric power utility (EPU)
operators can use to automate their response to cyber -initiated threats. Within this framework, a
priority is placed on the capability for EPU personnel and supporting e xpert contractors
(consultants, vendors, etc.) to create, model, simulate, and control the response to a cyber -
initiated threat. The three pillars of model-based system engineering (MBSE) are tailored for EPU
applications to establish a coherent framework (1).
Pillar #1: A formal modelling language to establish a standardized basis for communication and
collaboration. This technical brochure uses system dynamic language (SDL), business process
model notation (BPMN), and system modelling language (SySML) to define the grammar and a set
of rules that determines whether a given model is well-formed or ill-formed.
Pillar #2: A well-defined modelling method to create the model. This technical brochure uses an
object-oriented engineering method described by Friedenthal (2).
This is sometimes referred to as INCOSE’s object-oriented system engineering method (OOSEM).
Pillar #3: An integrated modelling tool that provides the capability to create different views of the
problem domain under consideration. This technical brochure uses several commercial tools:
VENSIM PLE for SDL based models, Cameo systems modeler by No Magic, and VISIO for simple
flat views of a selected process.
13
2. INTRODUCTION
2.1 BACKGROUND
Cyberspace is the collection of computer networks comprised of wired and wireless connections,
a multitude of protocols, and devices ranging from host machines to intelligent electronic devices
(IEDs). The response to the questions in the global survey ( 0) clearly shows that EPU operators
do not have sufficient tools to respond to a serious cyber -initiated threat to their critical
infrastructures.
The National Institute of Standards and Technology (NIST) published the “Preliminary
Cybersecurity Framework 4” October 29, 2013 (3). NIST’s framework is comprised of a Core, a
Profile, and Information Tiers. The Core contains standards and be st practices that are common
across all sectors and industries. Reed Smith published an interesting article “NIST Cybersecurity
Framework: Is it going off the rails (4).” Smith’s article reached the following conclusions that
reinforce the need for this technical brochure.
1) The standards divide into five functions: Identify, Protect, Detect, Respond and Recover,
which are generally consistent with industry and international information standards such as
ISO 27001.
2) The Profile section intends to be a tool for a company [EPU] to map its “Current” alignment
with the standards against a “Target” profile that will address identified cybersecurity risk.
3) The framework provides the concept of a profile but does not specify the templates f or
creating one.
Thus, a tool set must provide the capability to receive, store, model, retrieve, and send cyberspace
information to all system components. Implementation of the tools must have the capability to
receive real-time information from various network components and operation overlay sources.
Such an automated response is needed to provide sufficient oversight information to manage the
response and recovery. Visualization of the situation and clarity of response options is critical.
In response to a cyber-initiated attack, Lockheed Martin developed the concept “cyber kill chain”
to describe seven phases of an attack.
1) Reconnaissance
2) Weaponization
3) Delivery
4) Exploitation
5) Installation
6) Command and control (C2)
7) Actions on objectives
In the paper “Intelligence-Driven Computer Network Defense Informed by Analysis of Adversary
Campaigns and Intrusion Kill Chains,” Hutchins, Cloppert, and Amin describe the kill chain in detail
and provide a course of action matrix with recommended defensive measures f or each phase (5).
If an attack is successful their approach can be used by the EPU response team both for forensic
and analysis because the needed data, or artefacts of the attack, should be found in each of the
seven steps. For a defense mechanism, the mitigation can be implemented at any phase of the
4 Improving Critical Infrastructure Cybersecurity – U.S. Executive Order 13636, issued February 12, 2013.
14
chain because once that phase of the chain is protected the adversary hast to restart the attack.
A defense-in-depth strategy should implement mitigation at several stages of the chain.
The working group responsible for this technical brochure understood the need for the framework
to adapt easily to new requirements that evolve from local laws and regulations, changes in the
threat environment, and improvements in CERT process for information sharing and
responsiveness. This is a tall order, so this working group’s vision was to establish a few high -
priority specifications for the framework. Work by others will continue to build on the basic
framework so that future CIGRE working groups can issue updates to this technical brochure.
Based on feedback from the global survey (see 0) the following applications are the highest priority,
and therefore are the topics in this technical brochure.
1) Patch management
2) ICS-CERT response
2.2 CRITICAL INFRASTRUCTURE DEPENDS ON THE USER AND SITUATION

2.2.1 The impact of European regulations
information technology and control (IT&C) systems used by EPU automation syste ms, need to be
analysed from a critical infrastructure classification point of view. The analysis should be performed
by carefully considering the systems and entities they serve.
From this point of view, there is a fundamental difference between a public communications
infrastructure and one that is serving an EPU. A public communications infrastructure (e.g.
television or phone company network) can be analysed by its individual criticality perspective,
starting with its client count, offered services, fin ancial gains, financial and image losses in case
of service unavailability.
IT&C infrastructures that serve an EPU can only be evaluated and correlated with the entity they
serve, taking into consideration two factors:
1) EPU criticality;
2) How the EPU’s functionality depends on the availability of IT&C services.
Regarding the definition of critical infrastructures, there are a number of regulations on a European
level (On the 7th of February 2013, the European Commission released the Cybernetic Security
Strategy for the EU, and within it they proposed a directive regarding the needed measures to
assure the same level of security within the EU computer networks; the critical infrastructures
operators obligations for certain activity areas: finances, services, tra nsport, energy and
healthcare, IT services providers and public administrations; These operators need to implement
security measures accord with the services they provide). These regulations are transposed in the
EU member’s legislation (e.g. In Romania, one such law exists – HG 1198/2012 (6), regarding the
acknowledgement of national critical infrastructures and it is called “Romania’s Cybernetics
Security law”.
A review of current national rules and practices relating to risk preparedness in security of
electricity supply was published by the European Commission (7). The analysis of current national
rules and practices was primarily based on the twenty-eight national Country Reports, which were
drafted by (legal) experts based on their in-depth desk research and on stakeholder responses
received. Stakeholder engagement was achieved in all twenty -eight Member States, which is
reflected in the completeness of the reports and the study. The availability to share relevant
documents or information that the study team was not able to obtain through desk research,
15
varied across the Member States; when these data could not be shared, this was mainly due to
the confidentiality of the information.
Research shows a fragmented and diverse framework in relation to national risk preparedness
plans, measures and obligations concerning security of electricity supply. In general, it can be said
that all Member States consider risk preparedness consideratio ns. However, only ten Member
States set clear obligations to draw up risk preparedness plans. Eighteen other countries do not
have such an obligation, but take risk preparedness considerations into account in reports, plans
or measures. There is no specific obligation to submit a risk preparedness plan in the Electricity
Directive (2009/72/EC) and in the Security of Supply Directive (2005/89/EC), which partly explains
the fragmented framework of preparedness plans and measures.
There is no need to go into the methodology by which critical infrastructure are chosen since it
has it’s on own particularities in each member state. In general, it concerns possible material
damage, loss of human life, the losses that could affect a community or even other countri es.
By applying these criteria, we will obtain various levels of criticality for different EPU (whether we
are talking about system operators, producers – thermal, nuclear, hydro, wind, sun or biomass).
These classifications will depend on other factors su ch as the EPU’s own organising (whether they
separate the production, the distribution and the system operator activities or not) or the EPU’s
size.
To conclude, every analysis needs to start with different scenarios regarding the EPU being unable
to function and with the consequences of these dysfunctionalities.
The second phase of this analysis is related to the impact that the IT systems have on these
dysfunctionalities, using the following criteria:
1) The level of automatization of the EPU’s dispatching;

2) If the EPU has alternative dispatching systems or not;
3) The quantity and quality of information and their role in the decision -making process;
4) The possibility to minimize the effects of a fault with the help of IT systems;
5) The possibility of generating faults in the event of IT systems being targeted by a cyber -
attack.
2.2.2 Leverage the NERC CIP definitions
The NERC definitions applied to critical infrastructure protection for the electric power grid can be
found their glossary (8). This Glossary lists each term that was defined for use in one or more of
NERC’s continent-wide or Regional Reliability Standards and adopted by the NERC Board of
Trustees from February 8, 2005 Through August 17, 2016.
This reference is divided into two sections, and each section is organized in alphabetical order.
The first section identifies all terms that have been adopted by the NERC Board of Trustees for
use in continent-wide standards; the second section identifies all terms that have been adopted
by the NERC Board of Trustees for use in regional standards. (WECC, NPCC and RF are the only
Regions that have definitions approved by the NERC Board of Trustees. If other Regions develop
definitions for approved Regional Standards using a NERC -approved standards development
process, those definitions will be added to the Regional Definitions section of this glossary.)
2.2.3 OECD’s characterization of criticality

The Organization for Economic Cooperation and Development (OECD) report on critical
infrastructure has received special attention in recent changes to national investment policies in
16
some countries (9). This paper reviews the role of investment policies in broader national
strategies for protecting critical infrastructure. The k ey findings are:
1) Many countries have national plans or strategies for protecting critical infrastructure. These
strategies generally define “critical infrastructure” as physical or intangible assets whose
destruction or disruption would seriously undermin e public safety, social order and the
fulfilment of key government responsibilities. Such damage would generally be catastrophic
and far-reaching. Sources of critical infrastructure risk could be natural (e.g. earthquakes or
floods) or man-made (e.g. terrorism, sabotage).
2) The national strategies studied generally adopt a risk management approach to critical
infrastructure protection. This approach helps governments to identify key security assets,
assess risks and establish strategies and priorities for mi tigating these risks. Generally, the
risk management strategy involves measures to be taken in the following areas: prevention,
preparedness, response and recovery. The plans seek to improve coordination among
relevant agencies and with private sector operators of critical infrastructure facilities in order
to manage risks associated with critical infrastructure.
3) Information provided by notifications made under the OECD National Treatment Instrument
shows that all adhering countries have one or more invest ment measures that address
infrastructure. These are of three types: 1) blanket restrictions; 2) sectoral licensing or
contracting; 3) trans-sectoral measures such as investment review procedures. For some
countries, these discriminatory investment policie s are extremely limited in scope (e.g. they
concern cabotage or investments in vessels flying the national flag), whereas for others the
sectoral coverage of restrictive policies is broad.
4) The critical infrastructure policies reviewed here attempt to coord inate the role of private
operators of such infrastructure - be they domestic or foreign - in broader national efforts to
protect critical infrastructure. However, the role assigned to investment policies in critical
infrastructure protection varies. Many countries perceive the value added by investment
policy measures, relative to other policies (e.g. defense, law enforcement, sectoral), as
negligible and accordingly assign little or no role to investment policy. Others note that,
while their critical infrastructure protection policy adopts a broad approach to risk,
investment policy is used to address only a narrow range of these risks - those related to
national security - and only as a measure of last resort, i.e. only if other, less restrictive and
non-discriminatory, measures cannot adequately mitigate the identified risks.
2.2.4 Classification method and key measures enforced by law
The French Network and Information Security Agency published its description of classification
methods and key measures for industrial control systems (10). These documents will be used to
define the methods for applying the measures set out within the framework of French Law No.
2013-1168 of 18 December 2013, known as the Military programming law. The objective is to
subject all new critical ICSs to an approval process, thus ensuring that their cybersecurity level is
acceptable given the current threat status and its potential developments.
2.2.4.1 Cybersecurity classes for industrial control systems

Risks due to human negligence are considered as dependability issues, while risks due to malicious
acts fall in the domain of cybersecurity. Nevertheless, cybersecurity measures can address certain
negligence-related risks.
Cybersecurity levels are defined in terms of consequences for the Nation, rather than
consequences for responsible entities. Each class systematically includes the measures of the class
below it. Below is a brief description of the three cybersecurity classes for ICSs.
17
Class 1: ICSs for which the risk or impact of an attack is low. The measures recommended for
this class must be able to be applied in complete autonomy. This class mainly corresponds to rules
provided in the ANSSI Healthy Network Guide.
Class 2: ICSs for which the risk or impact of an attack is significant. There is no state control over
this class of ICS, but in the event of inspection or incident, the responsible entity must be able to
provide evidence that adequate measures have been implemented.
Class 3: ICSs for which the risk or impact of an attack is critical. In this class, the obligations are
heightened and the conformity of ICSs is verified by the state authority or an accredited body.
All functional or technical modifications to ICSs must trigger a review of the cybersec urity level.
Indeed, such modifications may have repercussions on the class that was previously estimated.
2.2.4.2 Measures
An infrastructure with dedicated resources leased from a telecommunications operator (such as a
MPLS network) is not considered a public network when resources are logically partitioned from
other traffic and the operator provides service guarantees. This type of solution does not
necessarily guarantee data stream confidentiality or integrity and does not in any case exempt the
responsible entity from implementing appropriate measures (such as a VPN) to ensure the
authenticity, integrity and confidentiality of data streams.
When imperatively justified by operational requirements, remote maintenance and remote

management may be authorised for class 3 industrial control system (ICS). However, in this case,
these operations should be performed from a site that is also class 3 and which should be included
in the risk analysis of the ICS.
The deployment of means of detection also implies the implemen tation of centralisation tools and
analysis tools to process the collected events. To avoid the proliferation of procedures,
cybersecurity approval can be integrated into the approval procedures that already exist in certain
sectors.
2.3 STRONG PERIMETER DEFENSE SOLUTIONS

2.3.1 An example unidirectional architecture
Over the past several years, interest in solutions that strengthen perimeter defense has gained
traction. Several published papers by Ginter, Frenkel, and others describe the mechanisms 5 used
to implement unidirectional security gateways (11) (12) (13) (14). This technology has gained
considerable traction for protecting EPU generation system s. One such reference architecture for
power generation is shown in Figure 1.
5 Readers interested in unidirectional gateway technology are directed to (11) L. Frenkel, D. Berko, and A. Ginter,
"Experience with Unidirectional Security Gateways Protecting Industrial Control Syst ems," ed: CRITIS, 2012.
18
Generation Remote
Vendor Dispatch Access Attack!
Firewall Firewall
Internet /
Telecomms Backbone
VPN VPN VPN
VPN Svr VPN Svr Corporate Firewall
Vendor ICCP EPU

DMZ DMZ IT Network
Unidirectional Gateway
Protection Layer
ADC
EPU
OT Network
Unit Firewall
Generating Unit
Control Network
Unidirectional Gateway
Protection Layer
Protective Safety
Relays Sytems
Figure 1 Unidirectional reference architecture
Reprinted with permission by Waterfall Security Solutions Ltd.
Ginter noted that “the architecture recognized that every computer, device or machine that
exchanges messages with the Internet is potentially compromised and therefore is untrustworthy
and every machine exchanging messages with an untrustworthy machine is similarly untrustworthy.
These networks are protected by unidirectional gateway technologies, whose stronger -than-
firewalls protection eliminate the threat of network attacks from untrusted networks, and eliminate
external network-connectivity cyber risks to protected, reliability-critical networks.”
2.3.2 Advanced persistent threats on perimeter defense

Advanced persistent threats (APTs) executed against perim eter defense systems need to be
addressed by improving the perimeter defense mechanisms 6. Unidirectional security gateways are
one solution that mitigates the following APTs by preventing malware from entering control
networks and by preventing any kind of remote control of control system networks (12). Some
examples of APTs are:
1) Penetrate firewalls by spear-phishing,

2) Defeat IDPS/SIEM systems by hiding covert communications in low -volume, legitimate-
seeming data streams,
6 Ginter, et al. summarized the threats from the MacAfee Night Dragon and Shady RAT reports, and the Mandiant APT1
report.
19
3) Evade anti-virus (AV) systems with custom malware deployed in volumes too low to trigger
AV signature creation,
4) Use professionals to operate sophisticated malware by interactive remote control,
5) Gather passwords and password hashes,
6) Create administrative accounts on domain controllers and remote access systems, and then
7) Log in to those accounts like any other user, and proceed to mis -operate control system
equipment.
2.3.3 How effective are unidirectional gateways?
Okhravi and Sheldon and others raised three issues regarding the effectiveness of unidirectional
gateways (15).
1) Protection is not provided against low networks 7.

2) Data diodes do not work with TCP/IP protocols.
3) In the situations when command in the process are necessary, Data diod es cannot be used
In the context of EPU operational technology (OT) applications, WG D2.38 addressed these issues
in the following clauses.
2.3.4 Protection against high networks

The low/high terminology applies to military applications, where diodes are oriente d from
unclassified "low" source networks into classified "high" networks. In EPUs, Unidirectional
Gateways are deployed most commonly at the IT/OT interface of industrial control systems,
breaking the chain of infection and interactive remote control from external attackers to internal
control systems. The most common source network in such deployments is the control system
network. The comment is accurate in that a Unidirectional Gateway oriented to replicate systems
from a control system network to an IT network addresses threats originating on the IT network,
not internal attack propagation within the control system network. However, Unidirectional
gateways are also deployed: (1) to protect safety systems and protective relays from attacks
propagating internally within control systems, (2) to protect energy management systems and
distribution management systems from attacks originating in substations or substation WANs, and
(3) in substations to protect substation equipment from attacks propagating within central control
networks and substation WANs. In these cases, the gateways, when deployed as the sole online
connection between networks, eliminating the risk of online attack propagation in one direction
within control system networks, and substantially reducing risks of propagation in the other
direction as well, due to server replication and device emulation functions.
2.3.5 TCP/IP protocols

Data diodes generally move data from “low to high” networks: generally moving data into
government and military networks, from less-trusted. Data diode manufacturers vary – some data
diodes are physically able to move data in only one direction, while other devices contain reverse
channels able to send acknowledgements or other information back to equipment on source
networks. Data diodes are generally poor fits for industrial control system environments because
of their inability to participate in true TCP -based, query-response dialogs Unidirectional gateways
are a combination of hardware and software. Unidirectional gatew ay hardware is true one-way
hardware comparable to the best data diode hardware. Unidirectional gateway software replicates
servers and emulates industrial devices.
7 High networks are enterprise networks and low networks are process control networks.
20
For example, unidirectional gateway software on the source network might connect to a rela tional
database and request to be notified by the database whenever data in the database changes.
When a change is signalled, the gateway software could query for the new data, and transmit the
data through the unidirectional hardware. On the receiving net work, unidirectional gateway
software would then insert the data into another relational database, thereby maintaining a faithful
replica of the source database on the destination network. Clients on the destination network that
require access to industrial data can then query the replica database and receive the same answer
as they would have received, had they been able to query the protected industrial database.
Similarly, unidirectional gateway software on the industrial network might periodically poll an
industrial device, such as a Modbus PLC. Periodic snapshots of PLC data can then be sent through
the unidirectional hardware to the destination network. Unidirectional gateway software on that
network emulates the original PLC, responding to Modbus requ ests from applications on the
destination network. For example, a historian database on the destination network might issue
such Modbus requests to the unidirectional gateway’s replicas of industrial Modbus devices, and
so populate the database with industrial data, without ever having the ability to issue a poll request
to the source Modbus devices.
In short, data diodes are unable to sustain true query/response TCP connections. Unidirectional
gateways do not need to sustain such connections through unidir ectional hardware. Instead, the
gateway software queries industrial systems on the source network, and replicates industrial
servers or emulates industrial devices to the destination network.
2.3.6 Clarification of 2.3.3 item 3)

This is a misconception. For example, in Figure 1 the ICCP connection illustrated must regularly
gather data from the industrial network for the generation dispatch centre, and must regularly
communicate commands from the generation dispatch centre to the power plant to produce power.
In this example, the ICCP server of the dispatch centre’s Energy Management System (EMS) is
emulated to the power plant, and the power plant’s Distributed Control System’s (DCS) ICCP
server is emulated to the dispatch centre. The real DCS polls the EMS ICCP replica, and the real
EMS polls the DCS ICCP replica. At no time are ICCP polls or commands forwarded from one
network to another, or responses forwarded back. Each replication is independent of the other.
In general, and unlike firewalls, unidirectional gateways do not forward network traffic from one
network to another. The gateways are endpoints of TCP and other connections on each network.
Connections on each network are independent of each other. This ma kes it very difficult for
malware on one network to reach out to a command and control centre in or beyond another
network, much more difficult than is the case with firewalled network connections that route traffic
from one network to another.
2.4 FOCUS ON THE INSIDER THREAT

2.4.1 Scenario assumptions
Gardiner, Cova and Nagaraja addressed the issues of
understanding, denying and detecting advanced persistent threats
(APTs) conducted by adversaries with access to sophisticated
tools (16). Hutchins and others developed an intelligence-driven
computer network defense by analysis of intrusion kill chains (5).
Specifically, WG D2.38 adopted their approach to first address
high-risk EPU groups. Then identify viable solutions using
Figure 2 Trusted on-site
commercial off-the-shelf security protection mechanisms that
technician
could be effective. 0 offers a checklist of mechanisms to help EPUs
to mitigate APT consequences.
21
Although not directly applicable to cybersecurity, the insider threat as demonstrated by the German
Wings aircraft crash on March 24, 2015 is real and should be taken seriously.
WG D2.38 narrowed their focus of the cyber-induced threat to attacks executed by insiders. We
assumed that insiders had detailed knowledge of EPU operations, protection and control (P&C)
system settings, and authorized cyber-access to mission critical communication nodes and to P&C
intelligent electronic devices (IEDs). Furthermore, D2.38 assumed that sufficient collaboration with
compromised EPU employees and contractors occurred to effectively plan, practice, and to execute
the attack.
Trusted employees and contractors are typically on-site to perform various configuration and
maintenance tasks. Figure 2 shows a direct connection between a test set and the bay level
equipment. The technician also has direct access to the front panel of the equipment under test.
Other sets of tools allow P&C engineers to remotely manage, configure, and test protective relays
at a system level. These test sets reduce the amount of time re quired to create complex logic
schemes. A disgruntled employee or contractor has the knowledge and access privileges to modify
these logic schemes to achieve the planned attack objectives.
2.4.2 High-level SysML collaboration model

Serious threat execution requires both internal and external collaboration. Figure 3 describes a
SysML (system modelling language) view of the threat collaboration model used by WG D2.38 to
develop the response model framework 8. Each block defines a unique name in the top row, the
values (value types) of the block are shown in the middle row, and the operations are shown in
the bottom row. RelatedThreat and Precursor blocks are “part of” threat (de noted by association
with a diamond head). The threat includes no (0) or many (*) instances of RelatedThreat and
Precursor. For the attacker to effectively execute the threat, pointOfAttack and entityID are the
values that need to be well established and c oordinated.
8 A summary of the SysML methodology and notation is described in APPENDIX F.
22
Figure 3 Threat collaboration model
2.4.3 Threat collaboration

Two specializations of the “Threat” are Internal and External. Depending on the scenario there
may be no (0) or many (*) instances of either internal or external collaboration. For example, the
cyber-attack on the Ukrainian power grid was executed with no collaboration. But, the E -ISAC
report (17) strongly inferred that future attacks may include such col laboration.
Continuing with a hypothetical future attack, this scenario assumes that a relay engineer and a
system operator are willing to collaborate to ensure effective execution of the cyber -initiated attack.
They have agreed to alter mission-critical protection and control set points to levels that, in
response to a minor disturbance, will cause the multiple distribution breakers to trip and disrupt
services to selected first-responder customers. The relay engineer selects the set points and
23
changes their value. The system operator monitors the changes and accepts the changed set point
values 9.
2.4.4 Log action and security manager 24/7 data exploitation

All actions are logged on one or more P&C log servers. Each log entry is date/time stamped and
includes the ID of the host machine used to perform the action, the person logged on to the host
machine, and the change action performed.
An automated security manager reads all logged data, then it initiates the procedures to filter the
data, and associates the changes to define a risk profile. As a minimum, the automated security
manager should execute the following steps.
1) A report is generated describing the event and supporting data,

2) An alarm is issued to notify humans with management responsibility, and
3) One or more commands are issued to initialize actions to safe the operational system, and if
possible continue operations in a degraded state.
Correlation of logs is important, and the collection of logged artefacts of the attack should not be
limited to syslog. The paper SANS and E-ISAC defense use case “Analysis of the Cyber Attack on
the Ukraine power grid” stresses the fact that abnormal behaviour should be monitored (17). For
example, uploading firmware outside of a scheduled d owntime should be observable in near real-
time. Moreover, the operational communication networks where traffic patterns are predictable,
firmware modifications should cause a spike in network traffic that EPU monitors can be looking
for. Even without knowing the baseline of normal activities, which the EPU monitor should have,
it can be trivial to detect and identify firmware update traffic.
Correlation of connections established by the access control system is needed. For example, when
the same ID is seen in a Paris substation at 12PM, and then in a Lyon substation at 13PM, there
is a problem because this is not possible and should be flagged.
Lastly, the finely-tuned analysis of business use cases and correlation of information between
services should be the basis for a well-formed security management policy, procedure, and
organizational directives.
2.5 THE NEED TO ENFORCE SECURITY ROBUSTNESS

2.5.1 Translating security robustness
A useful term commonly used to characterize and enforce security is security robustne ss. Security
robustness is a measure that links the measures of availability, confidentiality, and integrity for
EPU computing systems. Decentralized robustness is the subject of a paper by Chong and Myers
(18). It is possible to characterize one or more attackers by their ability to modify elements of
EPU’s computing systems. Chong and Myers characterized this by using a pair of security levels
that describe a configuration that an attacker can read, and a security level of con figuration
elements that an attacker can influence to modify its behaviour. A configuration may consist of
memory, code, data or other elements, which are unique to a specific EPU computing system.
Myers, Sabelfeld and Zdancewic published a paper “Enforcin g Robust Declassification.” WG D2.38
translated and mapped the declassification approach into the framework described in this technical
brochure (19). Unlike access controls, information flow controls track the propagation of E PU OT
9 For this scenario, WG D2.38 assumed the EPU’s operational policy requires the system operator to confirm and accept
or reject changes to mission-critical P&C set points. If accepted (confirmed) the set point change is in effect enabled.
If the change is not accepted, the set point change will default to the previous value.
24
and IT messages. Tracking can be used to impose an end -to-end requirement on the behaviour of
the EPU system under consideration (SuC). The translation of the following definition is particularly
interesting.
The SuC is secure if an active (insider) attacker (who can observe and modify a part of the SuC
state) may not learn more sensitive information than a passive attacker (who can merely observe
visible data). For example, within a substation, IEC 62351 emphasis on GOOSE message integrity
is a good application of this definition.
As a preamble to attacking the system (and after attacking a system), the attacker observes the
subsequent execution of the system. If the EPU has installed a secure intelligent monitoring
(IntelligentCorrelator) system, it is possible to capture the preamble attack data. The Precursor
agent shown in Figure 3 then processes these data. Correlating the observations to generate an
actionable intelligence report is critical to the discovery of the insider attack team.
2.5.2 Perimeter defense enables security robustness

Ginter described several means to protect control systems from advanced threats (14). With some
modification WG D2.38 addressed the basic problems with firewalls that are commonly used for
EPU perimeter defense. Ginter noted that “firewalls are software artefacts that examine each
incoming message and decide whether to let the message through, or to chan ge the message, or
to drop it. All complex software has defects, and some of those defects are manifest as
vulnerabilities which make the firewall software vulnerable to attack.”
2.6 THE NEED FOR PLUG AND PLAY

One-size does not fit all applications nor does one-size satisfy the needs of all EPUs. Some EPU
have the resources and trained staff to exercise all the capabilities of the tool. Other EPUs have
either limited resources or trained staff, or they depend on the capabilities offered by consortiums
to which they belong, such as the Electric Power Research Institute (EPRI). For this reason, the
tool set must be adaptable to serve these various customers. The answer lies in developing a
modular tool set framework.
Strictly controlling such modularity requires each module functional capability and its interface
specification. WG D2.38 selected the universal modelling language (UML) for this project because
it provides the needed specification construct and visualization 10.
2.7 NOTIONAL EPU CRITICAL INFRASTRUCTURE ARCHITECTURES

Various EPU critical infrastructure architectures exist, originated from manufacturers and vendors,
standards and best practice publications, with the differing focus areas such as network
architectures and application architectures.
Further to the above, there are different functional focus areas such as substation control
architectures, transmission-specific or distribution-specific architectures, and edge remote access
architectures.
It may not be realistic to have a unifying general architecture that encompasses all areas of
concern to the EPU. However, any critical infrastructure architecture should address the following
areas:
10 MagicDraw by No Magic is the tool used to develop the constructs presented in this technical brochure. Magic draw
may be downloaded from www.magicdraw.com.
25
1) Organizational aspects – i.e. the “human and organizational architecture” surrounding an

effective implementation of any technical architectures, as highlighted by standards such as
ISO 27001:2013 (20), the importance of an information security management system (ISMS).
2) Fundamental technical control such as appropriate zoning and se gmentation as highlighted is
62443-3-2 to develop effective segmentation architecture.
3) Standards-based and regulatory requirements approach to architecture design (for example,
based on NERC-CIP requirements, Australian Signals Directorate (ASD) Top 35 Mit igation
Strategies 11, US ICS-CERT 7 Strategies to Defend ICS 12 and ANSSI Cybersecurity for
Industrial Control Systems, Classification Method and Key Measures, and ANSSI
Cybersecurity for Industrial Control Systems, Detailed Measures .
In relation to remote services, its security architecture needs meet the border and edge security
requirements, which have stricter requirements and controls than internal networks. This is
because security measures (both technical and non-technical) affecting remote services are often
first line of defense on the entry points of untrusted entities.
2.8 CLOUD COMPUTING IS AN EVOLVING PARADIGM

2.8.1 The NIST framework
The NIST definition (21) characterizes important aspects of cloud computing and is intended to
serve as a means for broad comparison of cloud services and deployment strategies, and to provide
a baseline for discussion from what is cloud computing to how to best use cloud computing. The
service and deployment modes defined by NIST form a simple tax onomy that is not intended to
prescribe or constrain any method of deployment, service delivery or EPU operation.
Given the future adoption of cloud computing to support EPU operations and related business
functions, response to a wide-variety of security threats must be integrated into deployment
strategies to protect the use of cloud-based services.
2.8.2 Shared responsibility and accountability

Service level agreements must be closely reviewed. A large majority offer Shared Security
Responsibility in the public cloud, a key to being secure is a solid understanding of the shared
security model that exists between the EPU (the customer) and the cloud provider. Without this,
an EPU may make assumptions that the cloud provider is protecting the EPU, when in fact t he EPU
is responsible for security functions. The cloud provider is responsible for securing the foundational
services, such as computer power, storage, database and networking services, but the EPU will be
responsible for the configuration of those servic es. At the network layer, the service provider is
responsible for network segmentation, perimeter services, some distributed denial of service
(DDOS) and spoofing. But, the EPU is responsible for network threat detection, reporting and any
incident reporting. At the host layer, the EPU is responsible for access management, patch
management configuration hardening, security monitoring and log analysis. The application
security components of the EPU’s site are 100% EPU responsibility.
11 Australian Signals Directore, www.asd.gov.au/infosec/mitigationstrategies.htm

12 US ICS-CERT, https://ics-cert.us-cert.gov/Seven-Steps-Effectively-Defend-Industrial-Control-Systems
26
3. SUMMARY OF FINDINGS AND RECOMMENDATIONS

3.1 HIGHLIGHTS FROM THE SURVEY
0 describes the survey and summaries the response to the questions. Given the input from the
survey respondents, this report focused attention on the following issues.
1) Commercial tools are available to collect, process and report cyber threat data. EPUs cannot
claim that lack of tools is why they don’t maintain and monitor logs of security data to
generate alarms created by abnormal access or use of protection and control (P&C) networks
and IEDs.
2) The major impediment to converting security data to actionable information is the need for
personnel with specialized cybersecurity training.
3) Although teamwork is important, EPUs still rely mainly on IT personnel to lead investigative
teams with OT personnel playing a support role.
4) The preferred metric to measure impact is downtime per hour, but system average
interruption disruption index (SAIDI) and system average interruption frequency index
(SAIFI) are important supporting metrics.
5) EPUs generally use their own subject matter experts to build a consensus of the strength of
security needed to mitigate interference with, interruption of, or disablement of their P&C
operations. They find it too difficult to use the esoteric approaches described in eme rging
standards and guidelines, and prefer to stay focused on the perceived impact to operations.
6) EPUs are most worried about cyber-attacks targeting control room or integrated security
operation centre (ISOC). They further believe that a compromised insid er is needed to
execute an effective cyber-attack. However, the robustness and resilience (hot backup and
hot switch-over capabilities) built into their P&C architecture is very effective in thwarting a
cyber-attack.
7) In relation to remote services, the EPU’s security architecture needs meet the border and
edge security requirements, which have stricter requirements and controls than internal
networks. This is because security measures (both technical and non -technical) affecting
remote services are often first line of defense on the entry points of untrusted entities.
8) Staging of patches in a test or development environment is highly recommended for
assurance of the patches. It provides an early detection of compatibility issues with control
systems software and with host-based monitoring in the test environment, provides detection
of any behavior change of the system after applying patches. For example, sudden increase
in network traffic, previously unseen network traffic and sudden high memory or CPU usage.
3.2 RECOMMENDATIONS TO MANAGE RESPONSES TO CYBER-ATTACKS

Unfortunately, there is no way to prevent or guard against cyber -attacks against EPU networks
and IEDs residing on those networks. The pace of threat development is too fast and too diverse
for EPUs to install protective measures to mitigate advanced persistent threats. Managing
responses to cyber-attacks in a timely manner will mitigate the potential consequences that result
from attempts to interfere with, disrupt, or disable mission critical EPU operat ions. Following are
recommendations that provide a foundation to effectively manage the response to cyber -attacks.
1) Maintain an up-to-date list of all critical EPU assets, configurations, and settings. Most
importantly, the interaction between automated I ED initiated actions should be well
documented and be up-to-date.
27
2) EPU employees and support contractors should be periodically briefed on security threats,
security policies, procedures and organizational directives to maintain a heighted awareness
to the security situation. All such briefings should require a signature by the participants
indicating they understand the security issues and their individual responsibility to comply
with EPU security directives and local laws and regulations.
3) Abnormal operations should be logged and reported in a timely manner. Given the nature of
these data, automated processing of reports is critical to ensure the proper fusion of related
data to provide actionable information to the proper authority. Well understood metri cs 13
should be used to trigger response alerts.
4) Persistent protection of data by encryption, throughout the data lifetime, is the ideal
objective. Practical limitations involving less capable devices and legacy systems will enter
here as restraints to the objective. However, encryption of the data itself, independent of the
protocol involved, at point of origination, makes the secure use of any available transmission
or storage mechanism plausible and practical using Internet engineering task force (IETF)
request for comment (RFC) 5652 or ANSI X9.73 both entitled Cryptographic Message Syntax.
5) Information sharing is more difficult in the EU because defense and public order are
sovereign duties of member states, whereas welfare of people and economy are the
responsibility of European agencies like European Union Agency for Network and Information
Security (ENISA) for cybersecurity. Member states are individually passing cybersecurity laws
for defense and public order. For example, in France vulnerability disclos ure should be kept
secret and only be shared with the French cybersecurity agency. EPUs whose activities are
related to public order must comply with this regulation. It is a serious offence and a criminal
sanction if they do not comply. Even direct sector ial cooperation or direct vendor notification
is non-compliant with this regulation.
3.3 RECOMMENDATIONS TO STRENGTHEN PERIMETER DEFENSE

The Nuclear Energy Institute guidelines for cybersecurity of reactor control networks give two
choices: either no connections across the perimeter of the most sensitive networks, or
unidirectional connections only. EPU perimeter defense schemes should focus on the latter
guideline for sensitive networks. Specifically, a perimeter defense solution properly configured
should provide:
1) Complete isolation from untrusted sources. Nothing – not data, commands, or even protocol
signalling from the outside should enter a protected network.
2) Complete protection from external untrusted sources. When an untrusted external source on
attempts access though a security gateway to a protected network to take remote control of
IEDs; that attack will probably fail, but is not 100% guaranteed. Additional defense in depth
is needed to counter such attacks.
3) Complete protection from external denial of service attacks against protected assets. When
an untrusted source on an external network tries to transmit traffic through the gateway to
impair the operation of control system assets, none of those packets arrive on the control
system network. The gateway hardware should be incapable of transmitting anything back to
the control system.
4) Complete protection from sophisticated worms and other malware which can propagate
across networks. No set of unpatched, zero-day, or other vulnerabilities can cause the
13 Metrics should conform to the Jaquith requirements (67) A. Jaquith, Security metrics : Pearson Education, 2007.
28
receiving gateway hardware to transmit malware or other information into the protected
network.
5) Protection from malware which takes instructions from servers over the public networks.
Gateway appliances should make it impossible to receive commands from ser vers on
untrusted networks.
3.4 COMMERCIAL PLUG AND PLAY TOOLS

Security leaders can improve targeted attack detection capabilities using their security information
and event management tools, but it requires investments in expertise processes, and
complementary technologies.
1) Invest in the necessary expertise to define and implement continuous tuning and operation
investigators” to proactively identify compromises.
2) Use forward-leaning technologies, like user and entity behaviour analytics (UEBA), and
advanced threat defense solutions like end point detection and response (EDR) and network
traffic analyser (NTA) to extend SIEM capabilities to detect advanced threats.
3) Monitoring to detect targeted attacks requires a balance of active SIEM administration and
tuning, visibility beyond security operations people and tools, and investment in
complementary detection technologies, and mature processes that cut across the IT and O T
organizations.
29
30
4. TOOL SET REQUIREMENTS

4.1 WHAT CORE CAPABILITIES ARE REQUIRED TO PREVENT SENSITIVE DATA LOSS14
Managed by central management console, the data loss prevention (DLP) suite should provide the
visibility and control of critical assets over EPU segmented networks, endpoint, and off-premise.
Discovery and classification of EPU sensitive data stored in locally controlled systems is critical.
The following modules provide these capabilities.
Gateway inspector: Each EPU network segment should include a DLP gateway that monitors and
enforces DLP policy based on controls such as block, quarantine, route to encryption gateway,
audit and log, pass, alert and notify, severity block and severity quarantine, and redact over
the network segment covering all channels and ports on all protocols.
Endpoint protector: An agent that monitors and enforces automated DLP policy based controls
for data-in-motion to all endpoint and removable media. Controls such as block, encrypt, audit
and log, notify and alert on violations of confidentiality data, integrity data, and application
data.
eDiscovery: An agent that discovers, classifies and remediates confidentiality data, integrity data
and application data stored in locally control led repositories, file shares, etc. Remediation
includes the capability to “copy to”, “move to”, “delete”, or enforce digital rights management
(DRM) policy in real time.
Digital rights management: An agent that enforces automated DLP policy based controls for
data-in-use by controlling the entity (human or machine) that can access a file, where they
can access the file, and when or where the can be accessed.
4.2 IT PERIMETER PROTECTION SUITE

EPU cybersecurity protection policies, procedures, and organizationa l directives should include any
function or location serving the edge (logical or physical) of their network. The edge includes
remote access virtual private network (VPN) and unmanned remote sites. Hence, the posture
validation of the devices accessing these edges of the network should be a requirement.
At the perimeter of each EPU network segment, reduce the threat footprint by blocking a wide
range of unwanted applications and then inspecting the allowed applications for threats – both
known and unknown. Key perimeter protection for the next-generation firewall includes the
following enablement requirements 15.
Identify applications, not ports: Classify traffic, as soon as it arrives at the firewall, to
determine the application identity, irrespective of pr otocol, encryption or evasive tactic. Use
that identity as the basis for all EPU security policies.
Tie application usage to user identity, not IP address, regardless of location or device:
Employ user and group information from EPU managed directories or approved third-party
directories to deploy consistent enabling policies for all users, regardless of location or device.
14 Contributions from GTB Technologies (www.gtbtechnologies.com) were used to develop the tool set for data loss
prevention.
15 Contributions from Palo Alto Networks (www.paloaltonetorks.com) were used to develop the tool suite for perimeter
defense.
31
Protect against all threats – both known and unknown: Prevent known vulnerability exploits,
malware, spyware, malicious uniform resource locators (URLs) while analysing traffic for
tunnelled traffic and automatically delivering protection against highly targeted and previously
known malware.
Simplify policy management: Enable EPU applications and reduce administrative efforts with
easy-to-use graphical tools, a unified policy editor, templates, and device groups.
4.2.1 Focus on classifying traffic
Cyber threats can easily bypass a port-based firewall by hopping ports using SSL and SSH sneaking
across port 80, or by using non-standard ports (22) (23). Port-based firewall vulnerabilities are
discussed in Annex D. Products such as AppID™ 16 address the traffic classification visibility
limitations of traditional firewalls by applying multiple c lassification mechanisms to the traffic
stream to determine the exact identity of the application traversing the EPU network segment.
Unidentified applications, typically a small percentage of traffic, yet high in potential risk, should
for systematic management based on control and inspection, threat forensics, etc. automatically
be categorized.
4.2.2 Protect EPU enabled applications

Common threat evasion tactics such as port -hopping and tunnelling should be addressed by
executing approved EPU threat prevention policies using the application and protocol context
generated by decoders, such as those found in App-ID (see footnote 5). EPU procurement should
compare tool suites offered by the vendors to evaluate how well their solution provides the
following security capabilities.
Block known threats (IPS and network antivirus/anti-spyware: The capability to use a
uniform signature format and a stream-based scanning engine to enable the EPU to protect
the network segment from a broad range of threats.
1) Intrusion prevention system features block network and application-layer vulnerability
exploits, buffer overflows, denial of service (DoS) attacks, and port scans.
2) Antivirus/anti-spyware protection blocks malware variants, malware -generated command and
control traffic, PDF viruses, and malware hidden within compressed files or web traffic.
3) Policy-based SSL decryption across any application on any port protects against malware
moving across SSL encrypted applications.
Block unknown, targeted malware: The capability to identify and analyse unknown or targeted
malware, which directly executes and observes unknown files in a cloud -based, virtualized
environment.
Identify bot-infected hosts: The capability to classify all applications, across all ports, including
any unknown traffic to expose anomalies or threats to the EPU network or network segment.
1) The behavioural botnet report should correlate unknown traffic, suspicious DNS and URL
queries and a variety of unusual network behaviours to reveal devices that malware can
likely infect.
2) Display the results in the form of a list of potentially infected hosts to investigate possible
members of a botnet.
16 App-ID™, a patent-pending traffic classification system is only available in Palo Alto Networks firewalls. App-ID™
instantly applies multiple classification mechanisms to your network traffic stream, as soon as the device sees it, to
identify accurately applications.
32
Limit unauthorized file and data transfers: The capability to filter data based on EPU security
policies that will reduce the risks associated with unauthoriz ed file and data transfers.
1) File transfers should be controlled by looking inside the file (as opposed to looking only at
the file extension), to determine if the transfer action should be allowed or not.
2) Unless sent from a well-authenticated and trusted source, executable files, typically found in
downloads from remote configuration tools to upgrade protection relays, can be blocked,
thereby protecting EPU networks and network segments from unseen malware propagation.
3) Enable data filters to detect and control the flow of sensitive data within the EPU network
and network segments. IEC 62443 offers guidelines to restrict such data flows in a federated
and segmented architecture.
Control web or cloud surfing: The capability to customize the filtering engine to apply EPU
granular browsing policies requires integration with the vendor’s tool suite.
4.2.3 How effective is whitelisting?
The purpose of application whitelisting is to protect the host environment and applications from
unauthorized code (malware-based injection, remote-execution), thereby compromising the host
environment (24).
According to the US National Security Agency (NSA), application whitelisting is not a replacement
for traditional security software, such as antivirus and host firewalls (25). Using whitelists is one
layer in a defense-in-depth strategy. Table 4-1 shows the advantages and disadvantage listed by
NSA.
Table 4-1 Advantages and disadvantages of application whitelisting
Advantages Disadvantages
Blocks most current malware Requires performance overhead to enforce the whitelist
(varies greatly depending on implementation)
Prevents use of unauthorized applications Requires regular maintenance of the whitelist to add
new applications and remove ones that are no longer
approved
Does not require daily definition updates Causes some users to be annoyed beca use they cannot
download and run applications at will
Requires administrator installation and approval of new Requires additional time and manpower to maintain.
applications
Jim Beechey concludes in his report that whitelisting provides a dramatic improvement in the level
of visibility into files being introduced into an environment (26). This can be extremely helpful for
incident responders. To reduce significantly the risk of today’s malware organizations [EPUs] can
use the technology. This helps reduce the likelihood of system compromise and reduces cost of
staff to deal with malware related issues.
Considering the nature of application whitelisting, it is most useful in static environments, i.e.
where there is a very low rate of change, resulting in a reduced operational overhead in
maintaining a valid whitelist. These include systems that are updated less frequently (where
availability is of the utmost priority), undergoes fewer configuration changes and have little n eed
to install additional software after commissioning. Examples of such systems include SCADA
servers, HMIs and Engineering Workstations.
Figure 4 shows an example of Application Whitelisting using Microsoft AppLocker which is a

Windows built-in feature, integrated into the Splunk monitoring system.
33
Figure 4 Example Whitelisting Actions by Windows AppLocker Integrated int o a

monitoring solution
34
5. PLUG AND PLAY TOOLS SETS

5.1 INTRODUCTION
According to the Gartner report, security leaders can improve targeted attack detection capabilities
using their security information and event management tools, but it requires investments in
expertise processes, and complementary technologies (27). Furthermore, the Gartner report states
that targeted attacks are particularly challenging because there are human agents behind the
attack who are able to change their tactics, techniques, and procedures (TTPs) to outwit defenders.
5.2 COMMERCIAL/OPEN SOURCED TOOLS

Commercial and open sourced off-the-shelf tools are available to monitor potential cybersecurity
vulnerabilities. These tools are plug and play because they do n ot need to be modified for EPU
use. They do need to be configured for the task to be performed. A few of the tools, there are
many more, are listed below.
1) Train defenders on using tools such as YARA (which is open sourced) to scan digital images
and evidence collected from the environment, but do not perform scans in the production
environment itself (17). YARA is a popular tool that provides a robust language, which is
compatible with Perl-based Regular Expressions, and is used to examine the suspected
files/directories and match strings as is defined in the YARA rules with the file – see
http://resources.infosecinstitute.com/yara -simple-effective-way-dissecting-malware/.
2) Commercially available tools provide the ability to perform penetration testing. Howev er,
penetration testing is largely an art form that requires specialized skills. One example of the
skills needed is describe by the INFOSEC Institute – see
http://resources.infosecinstitute.com/category/pen-testing-1/.
3) Phishing can take many forms and can be achieved with many tools and techniques. The
most common tools and techniques that are used to carry out phishing scams are described
by the INFOSEC Institute – see
http://resources.infosecinstitute.com/category/enterprise/phishing/phishing -tools-
techniques/.
4) The INFOSEC Institute describes the procedure and tools need ed for forensic investigation.
One such tool is Redline – see http://resources.infosecinstitute.com/forensic-investigation-
with-redline/.
5) Wurldtech Technologies offers the Achilles Test Platform to test the robustness of
communication for industrial and automation devices (PLCs, DCS and others) . Such tests are
used to discover known and unknown vulnerabilities for remediation. A fact sheet d escribes
the Achilles Test platform – see
https://www.wurldtech.com/sites/default/files/achilles_test_platform_fact_sheet.pdf .
6) Invest in the necessary expertise to define and implement continuous tuning and operation
investigators” to proactively identify compromises. Focus attention on two areas:
a) Use SIEM to monitor privileged users and user activity.
b) Monitor changes to identity and access policies
7) Use forward-leaning technologies, like user and entity behaviour analytics (UEBA), and
advanced threat defense solutions like end-point detection and response (EDR) and network
traffic analyser (NTA) to extend SIEM capabilities to detect advanced threats.
35
One of the commercial tools available is the Fortinet FortiSIEM threat and security intelligence
product (28). Some of the services provided by FortiSIEM:
1) Statistical Anomaly Detection: Leverages machine-learning algorithms to profile traffic

and metrics for all devices on the network, detecting anomalies while learning behaviors.
2) Threat Intelligence Centre: Enables organizations to aggregate, validat e, and share
anonymous threat data gathered from data repositories, providing benchmark and threat
detection intelligence in real time.
3) External Threat Feed: An open API allows users to integrate public and private threat
feeds and cross-correlate the data with network and security data collected internally.
4) File Integrity Monitoring: A Window’s agent provides file integrity monitoring and simple
deployment to the entire network.
5) Synthetic Transaction Monitoring: Transactions are recorded and then replayed to
simulate real user input and activity. This process allows applications to be tested and
monitored the way they are used, and to identify problems before they occur.
36
6. PATCH MANAGEMENT APPLICATION

Patch management has been identified as one of the top strategies in security cyber assets (ICS-
CERT 7 Strategies to defend ICSs, ASD Top 35 Mitigation Strategies).
The integrity of patches should be assured with the following methods:
1) Out-of-band patch verification methods such as hash correctness of patch pa yload.

2) Patch-source validation by ensuring patches are sourced from the intended manufacturers’
servers via DNS reputation, IP validation and digital signatures.
Staging of patches in a test or development environment is highly recommended for assurance of
the patches. It provides an early detection of compatibility issues with control systems software
and with host-based monitoring in the test environment, provides detection of any behaviour
change of the system after applying patches. For example, sudden increase in network traffic,
previously unseen network traffic and sudden high memory or CPU usage.
37
38
7. ICS-CERT RESPONSE APPLICATION

7.1 MANAGING RISK AND CREATING RESILIENCE
Collier’s research (29) concludes, “a risk-based cybersecurity framework must continuously
assimilate new information and track changing stakeholder [EPU] priorities and adversarial
capabilities, using decision analysis tools to link technical data with expert judgement.” This
challenge is a core topic for CIGRE SC D2 cybersecurity working groups. The challenge is difficult
because there is very little guidance in three areas:
1) Framing and evaluating multiple-threat scenarios at various scales: Is a complete inventory

possible when threats evolve so rapidly? No sooner does an EPU detect or become aware of
a cyber threat and implement defense, when new threat arises.
2) Quantifying vulnerability against intelligent and adapting adversaries: In the cyber domain,
an adversary learns, anticipates, and adapts, which requires a far more complex assessment
that that for natural phenomena or accidents in EPU operational control systems.
3) Understanding a threat’s consequences: With traditional assessment approaches, it is
impractical and difficult to quantify risk as the probability of threat occurrence and
consequence of failure across the cyber domain and its interdependent EPU infrastructure
systems.
Given this guidance, WG D2.38 addressed the ICS-CERT response application.
7.2 INCIDENT HANDLING RESPONSE

Incident handling requires an automated response in near real time that detects the incident and
contains the incident by bringing the power system to a safe configuration. For near real time, this
can vary from a few milliseconds required for relay trips, to several minutes for other applications
such as metering. For either case, the emphasis is on automated response with operator oversight.
Well after the event, the post-mortem analysis begins by gathering the evidence collected during
the incident and performing detailed analysis to determine the cause of the incident, the corrective
action and the procedure to mitigate a future occurrence that closes the incident. Figure 5 shows
the framework for the incident-handling module and the sub-modules.
39
Figure 5 Incident handling module
7.2.1 In near real time – detect and contain

By design, electric power transmission and distribution systems include an extraordinary degree
of resilience. This resilience includes the capability to detect and contain in near real time any
event, regardless of its cause. Protection and control (P&C) system parameter s in each subsystem
and component are set to respond to anomalies to safe the system and provide for timely
reconstitution of services. This requires 1) unaltered measurement data used by these components
and 2) valid (unchanged) P&C settings. If the attac ker changes either the measurement data or
the settings, the P&C system will not effectively operate as designed. For this reason, designs
include redundant P&C systems and communication links with hot switchover. Models of both the
primary system and the hot backup system in the automated response framework are part of this
technical brochure.
7.2.2 Post mortem analysis and closure – “How and why did the event (incident) occur?”
Frank L. Greitzer (30) describes the combination of traditional cybersecurity audit data with
psychosocial data to support a move from an insider threat detection stance to one that enables
prediction of potential insider presence. Data fusion specialist commonly refer to the approach
shown in Figure 6 as “connecting-the-dots.” The precise algorithms needed to implement this
approach are well-beyond the scope of this technical brochure.
Instead, WG D2.38 defines a system dynamics model that focuses attention on the need to collect
automatically the data for post mortem analysis and describes a list of the technical parameters
for effective data fusion.
40
Figure 6 Model-Based Predictive Classification Concept: Incoming data processed to

infer observations
Adapted from Combining Traditional Cyber Security Audit Data with Psychosocial Data: Towards Predictive Modelling for
Insider Threat Mitigation, F. Greitzer and D. Frincke, PNNL-SA-67978, 2010. Adapted with permission.
7.3 COORDINATED VULNERABILITY DISCLOSURE

Coordinated vulnerability disclosure refers to a reporting methodology. Coordination includes a
party (“reporter”) privately disclosed information relating to a discovered vulnerability to a product
vendor or service provider (“affected party”). This allows the affected party time to investigate
the claim, and identify and test a remedy or recourse before coordinating the release of a public
disclosure of the vulnerability with the reporter (31). Figure 7 illustrates 17 a typical coordinated
disclosure process practiced by the Internet Corporation for Assigned Names and Numbers (ICANN).
The methodology ICANN describes for vulnerability reporting also applies to reporting threats, the
security, stability or resiliency of EPU systems.
17 Graphic notation conforms to OMG’s Business Process Model and Notation (BPMN) [33] P. Wohed, W. M. van der
Aalst, M. Dumas, A. H. ter Hofstede, and N. Russell, On the suitability of BPMN for business process mode lling :
Springer, 2006.
41
Supporting Evidence NO Status Reports

Well-supported Conclusion
Identify
Coordination YES Assist Investigation Resolution
Vulnerability
Notify Vendor Notify Public
Unresponsive Unresponsive
Turn Report over to Coordinator (CERT)
Figure 7 Typical coordinated disclosure process
Adapted from Coordinated Vulnerability Disclosure Reporting at ICANN , Version 2, Updated 5 August 2013. Reprinted
with permission.
Except for the last step, disclosure, notify public, the process described in Figure 7 applies to each
stage of the incident described in Figure 5. At each stage, the quality of information varies from
very preliminary (first look) to a well-supported conclusion leading to the resolution of the incident
and its closure. Disclosure of the public notification requires reaching a well -supported conclusion.
Certain vulnerabilities – for example, where the consequences of an event may (indirectly) affect
parties too numerous to contact directly, or where the potential for power deliver service
interruption is imminent or high – may require activation of broader crisis management handling
measures than are available within the EPU. In this case, the report and supporting da ta need to
be turned over to an entity with a wider reach to the stakeholders (e.g., international, inter -
governmental).
EPU reporters should include as much of the following documentation as possible in a vulnerability
or threat report. The tool set, which is the subject of this technical brochure, should provide the
means to collect automatically the data and, with human annotation of the findings, should provide
a coherent picture of the vulnerability or threat.
1) A summary of the vulnerability or threat,

2) Technical details,
3) Where applicable, a description of how to reproduce the vulnerability,
4) The reporter’s analysis and perceived severity of the vulnerability or threat, and
5) An addition information that may assist in the investigating the matter.
7.4 EMERGENCY COORDINATION AND CRISIS MANAGEMENT

If a vulnerability or event requires activation of broader crisis management handling than is
available within the EPU, the EPU should follow the emergency coordination and crisis management
processes shown in Figure 8. The color-coding in Figure 6 identifies the changes to the process
shown in Figure 8
42
Figure 8 Emergency coordination and crisis management
Adapted from Coordinated Vulnerability Disclosure Reporting at ICANN , Version 2, Updated 5 August 2013. Adapted with
permission.
7.5 EU PUBLIC POLICY, LAWS AND REGULATIONS

In the European Union, the situation is a bit different. Defense and public order are sovereign
duties of Member States, whereas welfare of people and economy are the responsibility of
European agencies like ENISA for cybersecurity. Member States are in dividually passing
cybersecurity laws for defense and public order. For example, in France vulnerability disclosure
should be kept secret and only be shared with the French cybersecurity agency. EPUs whose
activities are related to public order must comply with this regulation. It is a serious offence and
a criminal sanction if they do not comply. Even direct sectorial cooperation or direct vendor
notification is non-compliant with this regulation.
For other cybersecurity incidents, the European Commission has passed a directive called NIS
(Network and Information Security) that will be enforced in 2018. The directive leverages the
capabilities and authority of existing computer security incident response team (CSIRT) and
member states cybersecurity agencies (called national coordination point in the directive).
Breaches should be reported to national cybersecurity agencies that cooperate with the other
Member States under the ENISA association.
ENISA is seeking a sectorial coordination at the EU level. Some associations are emerging; e.g.,
European Network for Cyber Security (ENCS) 18. This is a new initiative that has some overlap of
responsibilities and authority with the TSO-DSO 19. It is too early to have a clear view on which
18 See https://www.encs.eu.
19 TSO-DSO has a broader role for the energy market and not just for cybersecurity.
43
associations will have control over sectorial cybersecurity, sectorial for a broader role, or European
wide. Moreover, as for any directive it must be translated into national laws for every Member
State, and some states may choose to enforce stricter incident disclosure rules.
7.6 EFFECTIVE REPORTING REQUIRES AN INTEGRATED SECURITY OPERATIONS CENTRE

To effectively analyse and report cyber-initiated incidents, each EPU should plan and implement
an integrated security operation centre (ISOC) that includes corporate systems, control systems
and physical security. EPRI’s guideline describes an approach to build and maintain an ISOC (32).
These guidelines build the framework described in this technical brochure.
Figure 9 shows EPRI’s view of a potential architecture for an ISOC. The ISOC also includes
vulnerability and threat information from external sources, such as information sharing and
analysis centres (ISACs), computer emergency readiness teams (CERTs), and law enforcement.
Figure 9 EPRI’s high-level ISOC architecture
Adapted from Guidelines for Planning an Integrated Security Operations Center, by G. Rasche, December 2013, EP RI .
Adapted with permission.
Derived from several sources are EPRI’s guideline (including but not limited to sources (33) (34)
(35) (36). Commensurate with Figure 5, EPRI identified the key technologies used in an ISOC.
Figure 10 shows EPRI’s view of these technologies.
44
Figure 10 Key technologies used at different layers in an ISOC
Adapted from Guidelines for Planning an Integrated Security Operation Center, by G. Rasche, December
2013, EPRI. Adapted with permission.
45
46
8. BIBLIOGRAPHY
1. Deligati, L. SysML distilled Abrief guide to the system modeling language. s.l. : Addison-Wesley, 2013.
2. S. Friedenthal, A. Moore, and R. Steiner. A practical guide to SysML: the system modelling language. s.l. : Morgan Kaufman,
2015.
3. "Preliminary Cybersecurity Framework," Guideline. 2013.
4. Nagle., R. Smith and T. NIST Cybersecurity Framework: Is It Going Off The Rails? JD Supra Business Advisor.
Available: www.dsupra.com/legalnews/. 2013.
5. E. M. Hutchins, M. J. Cloppert, and R. M. Amin. "Intelligence-driven computer network defense informed by
analysis of adversary campaigns and intrusion kill chains,". Leading Issues in Information Warfare & Security
Research. 2011, Vol. vol1 p. 80.
6. Stanisteanu, A. I. "CRITICAL INFRASTRUCTURE ANALYSIS MODEL-ENERGY CRITICAL INFRASTRUCTURE,". The
International Annual Scientific Session Strategies XXI. 2015, Vol. vol 1 p 498.
7. Network, VVA Europe and Spark Legal. "Review of current national rules and practices relating to risk
preparedness in the area of security of electricity supply,". s.l. : European Commission, Luxermbourg: Publications
Office of the European Union, 2016.
8. Council, North American Electric Reliability. "Glossary of Terms Used in NERC Reliability Standards,". 2016.
9. Dion, K. Gordon and M. "Protection of'Critical Infrastructure'and the role of investment policies relating to
national security,". 2008.
10. A. D. a. S. Actemium, Arkoon-Netasq, A.R.C. Informatique, Atos Worldgrid, Hirschmann, Cassidian Cybersecurity,
et al. "Cybersecurity for Industrial Control Systems - Classification Method and Key Measures," French Network and
Information Security Agency. 2013.
11. L. Frenkel, D. Berko, and A. Ginter. "Experience with Unidirectional Security Gateways Protecting Industrial
Control Systems," ed: CRITIS, 2012. s.l. : ed: CRITIS, 2012.
12. Ginter, A. "Securing Power Generation with Unidirectional Security Gateways," ed: Waterfall Security Solutions
Ltd., August 2015. s.l. : ed: Waterfall Security Solutions Ltd., 2015.
13. —. "Introcution to Waterfall Unidirectional Security Gateways: True unidirectionality, True Security,". August
2012.
14. "Protecting Control Systems from Advanced Threats," in AFPM Annual Meeting 2012, 2012, p. 8. Ginter, A. s.l. :
in AFPM Annual Meeting 2012, p. 8., 2012.
15. "Data diodes in support of trustworthy cyber infrastructure,". Sheldon, H. Okhravi and F. T. s.l. : in Proceedings
of the Sixth Annual Workshop on Cyber Security and Information Intelligence Research, 2010, p. 23., 2010.
16. "Command & Control : Understanding, Denying and Detecting," . J. Gardiner, M. Cova, and S. Nagaraja. s.l. :
University of Birmingham, February 2014.
17. "Analysis of the cyber attack on the Ukrainian power grid - Defense use case,". Robert M. Lee, Michael J.
Assante, and T. Conway. s.l. : Electricity Information sharing and analysis center (E-ISAC), Washington, DC 20005,
Report, March 18, 2016.
18. "Decentralized robustness,". Myers, S. Chong and A. C. s.l. : in Computer Security Foundations Workshop, 19th
IEEE, 2006, pp. 12 pp.-256., 2006.
19. "Enforcing robust declassification," in Computer Security Foundations Workshop, 2004. Proceedings. 17th IEEE,
2004, pp. 172-186. A. C. Myers, A. Sabelfeld, and S. Zdancewic. s.l. : in Computer Security Foundations Workshop,
2004. Proceedings. 17th IEEE, pp. 172-186., 2004.
20. International Standards Organization, "ISO/IEC 27001:2013 - Information technology - Security techniques -
Information security management systems - Requirements,". Organization, International Standards. s.l. : ed:
ISO/IEC, 2013.
21. "The NIST definition of cloud computing," in National Institute of Standards and Technology vol. 53, ed, 2009, p.
50. Grance, P. Mell and T. s.l. : in National Institute of Standards and Technology vol. 53, ed, 2009, p. 50., 2009.
22. "Detection of illicit traffic based on multiscale analysis,". E. Rocha, P. Salvador, and A. Nogueira. s.l. : in
Software, Telecommunications & Computer Networks, 2009. SoftCOM 2009. 17th International Conference on, pp.
286-291., 2009.
23. Next-Generation Firewalls for Dummies. . Miller, L. C. s.l. : Hoboken, NJ: Wiley Publishing, Inc., 2011.
47
24. Raising the bar for Cybersecurity: Center for Strategic and International Studies. Lewis, J. A. 2013.
25. "Application Whitelisting,". Agency, National Security. s.l. : ed, 2013.
26. Beechey, J. "Application Whitelisting: Panacea or Propaganda," SANS Reading Room.[online] http://www. sans.
org/reading_room/whitepapers/application/application-whitelisting-panacea-propaganda_33599. Retrieved on
January, vol. 26, p. 2012, 2010. SANS Reading Room.[online] http://www. sans.
org/reading_room/whitepapers/application/application-whitelisting-panacea-propaganda_33599. Retrieved on
January, vol. 26, p. 2012, 2010. [Online] http://www. sans.
org/reading_room/whitepapers/application/application-whitelisting-panacea-propaganda_33599..
27. "Use SIEM for targeted attack detection,". Toby Bussa, Kelly M. Kavanagh, and O. Rochford. s.l. : Research from
Gartner, Fortinet, 30 June 2016.
28. "Fortinet FortiSIEM: Actionable Threat and Security Intelligence,". Palmer, T. s.l. : Enterprise Stategic Group
(ESG)July 2016., July 2016.
29. "Cybersecurity Standards: Managing risk and creating resilience," Computer, pp. 70-76. I. L. Zachary A. Collier,
Daniel DiMse, Steve Walters, Mark (Mohammad) Tehranipoor, James H. Lambert. s.l. : Computer, pp. 70-76,,
September 2014.
30. "Combining Traditioanl Cybersecurity Audit Data with Psycho-Social Data: Towardspredictive Modeling for
Insider Threat Mitigation," . Frincke, F. L. Greitzer and D. A. s.l. : Richland, WA PNNL-SA-67978, 2010.
31. Coordinated Vulnerability Disclosure Reporting at ICANN. https://www.icann.org/en/about/staff/security/.
[Online] (2013, August 5). https://www.icann.org/..
32. "Guidelines for Planning an Integrated Operations Center,". Rasche, G. s.l. : Palo Alto, CA, Update Report
3002000374, December 2013.
33. "Critical Infrastructure Protection (CIP) standards". Corporation, North American Electric Reliability.
34. Security, Department of Homeland. Recommended Practice: Creating Cyber Forensic Plans for Control Systems.
http://ics-cert,us-cert.gov/sites/default/files/forensics_RP.pdf. [Online]
35. "Recommended Practice: Developing an Industrial Control System Incident Response Capability,". Security,
Department of Homeland.
36. "Security and Privacy Controls for Federal Information Systems and Organizations,". Technology, National
Institute of Standards and. s.l. : I. T. L. Computer Security Division, Ed., Revision 4 ed. Gaithersburg, MD, April 2013,
p. 460., 2013.
37. "A System Dynamics Model of an Insider Attack on an Information System," . C. Melara, J. M. Sarriegui, J. J.
Gonzalez, A. Sawicka, and D. L. Cooke. s.l. : in Proceedings of the 21st International Conference of the System
Dynamics Society, July 20-24, 2003.
38. "Preliminary System Dynamic Maps of the Insider Cyber-threat Problem,". D. Andersen, D. M. Cappelli, J. J.
Gonzalez, M. Mojtahedzadeh, A. P. Moore, E. Rich, et al. s.l. : in System Dynamics Modelling for Information
Security: An Invitational Group Modeling Works.
39. "Security Requirements for Cryptographic Modules,". Technology, National Institute of Standards and. 2002.
40. On the suitability of BPMN for business process modelling. P. Wohed, W. M. van der Aalst, M. Dumas, A. H. ter
Hofstede, and N. Russell. s.l. : Springer, 2006.
41. Booz Allen Hamilton report. (August 25, 2016). Industrial companies in the Middle East facing risk of cyber-
attacks (September 2016 ed.). Available: http://www.bi-
me.com/main.php?id=71639&t=1&c=34&cg=4&mset=1011. Industrial companies in the Middle East facing risk of
cyber-attacks (September 2016 ed.). s.l. : Available: http://www.bi-
me.com/main.php?id=71639&t=1&c=34&cg=4&mset=1011, 2016.
42. Luene, G. Farnham and K. "Tools and Standards for Cyber Threat Intelligence,". s.l. : Technical Paper2013-10-
13.
43. Y. Zhang, Y. Xiang, and L. Wang. "Reliability Analysis of Power Grids with Cyber Vulnerability in SCADA
System,". s.l. : in IEEE Power & Energy Society General Meeting, Washington D.C., July 27-31, 2014.
44. Y. Xiang, L. Wang, and Y. Zhang. "Power System Adequacy Assessment with Probabilistic Cyber Attacks Against
Breakers,". s.l. : in IEEE Power & Energy Society General Meeting, Washington D.C., July 27-31, 2014.
45. I. Parvez, A. Islam, and F. Kaleem. "A Key Management-Based Two-Level Encryption method for AMI,". s.l. : in
IEEE Powwer & Energy Society General Meeting, Washington D.C., July 27-31, 2014.
46. Ginter, Andrew. Cyber-Physical Security pp 71. Switzerland : Springer, 2016.
48
47. S. Kamara, S. Fahmy, E. Schultz, F. Kerschbaum, and M. Frantzen. "Analysis of vulnerabilities in internet
firewalls," . s.l. : Computers & Security, vol. 22, pp. 214-232,, 2003.
48. M. Frantzen, F. Kerschbaum, E. E. Schultz, and S. Fahmy. "A framework for understanding vulnerabilities in
firewalls using a dataflow model of firewall internals,". s.l. : Computers & Security, vol. 20, pp. 263-270, 2001.
49. Casey, B. Identifying and preventing router, switch and firewall vulnerabilities. Available:
http://searchsecurity.techtarget.com/tip/Identifying-and-preventing-router-switch-and-firewall-vulnerabilities.
[Online] 2013.
50. "A SysML Extension for Security Analysis of Industrial Control Systems,". L. Lemaire, J. Lapon, B. De Decker, and
V. Naessens. 2014.
51. "An analysis of security issues for cloud computing,". K. Hashizume, D. G. Rosado, E. Fernández-Medina, and E.
B. Fernandez. s.l. : Journal of Internet Services and Applications, vol. 4, pp. 1-13, 2013.
52. "Security analysis in the migration to cloud environments," . D. G. Rosado, R. Gómez, D. Mellado, and E.
Fernández-Medina. s.l. : Future Internet, vol. 4, pp. 469-487, 2012.
53. "Security guidance for critical areas of focus in cloud computing v3. 0,". Alliance, Cloud Security. s.l. : Cloud
Security Alliance, 2011.
54. "OWASP Top-10 2013," . Wichers, D. s.l. : OWASP Foundation, February, 2013.
55. "Towards Trusted Cloud Computing,". N. Santos, K. P. Gummadi, and R. Rodrigues. s.l. : HotCloud, vol. 9, pp. 3-
3, 2009.
56. "Security for the cloud infrastructure: Trusted virtual data center implementation," . S. Berger, R. Cáceres, K.
Goldman, D. Pendarakis, R. Perez, J. R. Rao, et al. s.l. : IBM Journal of Research and Development, vol. 53, pp. 6: 1-
6: 12, 2009.
57. "An empirical study into the security exposure to hosts of hostile virtualized environments,". Ormandy, T. s.l. :
ed: Citeseer, 2007.
58. "Network security for virtual machine in cloud computing,". H. Wu, Y. Ding, C. Winer, and L. Yao. s.l. : in
Computer Sciences and Convergence Information Technology (ICCIT), 2010 5th International Conference on, pp.
18-21., 2010.
59. "On Cloud Now: Cloud Technologies are Here for Utilities," . Utilities, O. s.l. : ed,, 2016.
60. "Cloud computing applications for smart grid: A survey," . S. Bera, S. Misra, and J. J. Rodrigues. s.l. : Parallel and
Distributed Systems, IEEE Transactions on, vol. 26, pp. 1477-1494, 2015.
61. "Monitoring Requirements in Systems of Systems,". Rabiser, M. Vierhauser and R. s.l. : IEEE Software, vol. 33,
pp. 22-24, 2016.
62. "A requirements monitoring framework for enterprise systems,". Robinson, W. N. s.l. : Requirements
engineering, vol. 11, pp. 17-41, 2006.
63. "Monitoring our requirements," . Maiden, N. s.l. : IEEE software, vol. 30, pp. 16-17, 2013.
64. "Critical capabilities for identity and access management as a service worldwide," . Wynne, G. K. Neil. s.l. :
Gartner, Inc. ID: G00299338., 29 September 2016.
65. Standards for hybrid clouds. Sill, Alan. s.l. : Computing Edge. pp 30-33. , June 2016.
66. "Security Policy Transition Framework for Software Defined Networks," . J. Jacob H. Cox, R. J. Clark, and H. L.
Owen. s.l. : presented at the 2nd IEEE NFV-SDN conference, Palo Alto, CA USA, 2016.
67. Security metrics: Pearson Education. Jaquith, A. 2007.
49
50
ANNEX A. DEFINITIONS, ABREVIATIONS AND SYMBOLS

A.1. GENERAL TERMS
App.1 Definition of general terms used in this TB

Acronym Phrase Definition
TB Technical Brochure A publication produced by CIGRÉ representing the
state-of-the-art guidelines and recommendations
produced by an SC WG. Hardcopy TBs can be
purchased Erreur ! Source du renvoi introuvable., or
Individual Members, or staff of a Collective Member
can download the PDF for free using their login
credentials (copyright restrictions for use within
their own CIGRE Membership only)
SC Study Committee One of the 16 technical domain groups of CIGRE
WG Working Group A group formed by a SC to develop a TB on a
particular subject of interest
A.2. SPECIFIC TERMS
App.2 Definition of technical terms used in this TB

Phrase Definition
application proactive security technique to allow a limited set of approved
whitelisting programs to run
Note to entry: Block all other programs (including most malware) from running
by default. Application whitelisting enables only the administrators, not the users,
to decide which programs to run.
best practice a superior method or innovative practice that contributes to the

improved performance of an organization, usually recognized as
“best” by EPU peer organizations
Note 1 to entry: Peer organization membership is a local matter determined by

the EPU’s security policies and procedures.
Note 2 to entry: Peer membership should include membership of all
stakeholders with an interest in protecting protection and control system assets
51
Phrase Definition
cabotage transport of goods or passengers between two places in the same
country by a transport operator from another country
Note 1 to entry: It originally applied to shipping along coastal routes, port to

port, but now applies to aviation, railways, and road transport as well.
Note 2 to entry: Cabotage rights are the right of a company from one country
to trade in another country. In aviation, it is the right to operate within the
domestic borders of another country. Most countries do not permit aviation
cabotage, and there are strict sanctions against it, for reasons of economic
protectionism, national security, or public safety. One nota ble exception is the
European Union, whose members all grant cabotage rights to each other.
cloud computing model for enabling ubiquitous, convenient, on-demand network

access to a shared pool of configurable computing resources
Note 1 to entry: NIST cloud computing model is composed of five essential

characteristics, three service models, and four deployment models (21).
Note 2 to entry: Computing resources include networks, servers, storage,
applications, and services.
Note 3 to entry: Essential characteristics are on-demand self-service, broad
network access, resource pooling, rapid elasticity, and measured service.
Note 4 to entry: Service models are software as a service (SaaS), platform as a
service (PaaS), and infrastructure as a service (IaaS).
Note 5 to entry: Deployment models are private cloud, community cloud, public
cloud, and hybrid cloud.
efficacy the ability to produce a desired or intended result
formal controls business structures and process that ensure the correct general
conduct of business and reduce the probability of an incident or
attack
EXAMPLE Separating the security organization from other IT or OT departments,

designing correct segregation of security duties (therefore access right s and
privileges), designing and controlling the appropriate employee -supervisor
relationship, routine risk evaluations (37).
hypervisor virtual machine monitor (VMM) is a piece of computer software,

firmware or hardware that creates and runs virtual machines
Note to entry: A computer on which a hypervisor is running one or more virtual

machines is defined as a host machine. Each virtual machine is called a guest
machine.
incident [cyber- unplanned interruption to a service, a reduction in the quality of a

induced] service or an event that has not yet impacted the service to the
customer
[SOURCE: ISO/IEC 20000-1:2011]
informal controls culture, value, and belief system of the organization
EXAMPLE A culture in which it is possible to understand management’s

intentions, which is conducive to developing a shared vision and other informal
objective; e.g., education, awareness and training programs (37).
information security location where enterprise information systems are monitored, assessed,
operation centre and defended
(ISOC)
52
Phrase Definition
intrusion device or software application that monitors a network or systems
detection/protection for malicious activity or policy violations
system (IDPS)
Note 1 to entry: Intrusion prevention systems, also known as intrusion
detection and prevention systems, are network security appliances that monitor
network and/or system activities for malicious activity. The main functions of
intrusion prevention systems are to identify malicious activity, log information
about this activity, attempt to block/stop it, and report it.
Note 2 to entry: In general IDPS are perimeter defense solutions

implemented at critical access points. Encryption is recommended for data
flowing in/out of the security perimeter. The message packet header is not
encrypted, so the header data is available for IDPS analysis. If the IDPS needs
to interrogate the encrypted message payload it needs to have the
cryptographic keys to decrypt the payload and encrypt the payload before
sending it on.
insider threat any information system, network, or data compromise where the
suspect has, or used to have, legitimate access to the network/data
compromised [adopted in (38) from the United States Secret Service
Coordination Centre]
EXAMPLE 1 Current or former employees of the company whose network was

compromised.
EXAMPLE 2 Former contractors of the company whose network was
compromised.
Note to entry: Information system, network, and data compromises include any
incidents where there is a manipulation of, unauthorized access to, exceeding
authorized access to, tampering with, or disabling any information system,
network, or data.
intelligent electronic microprocessor-based devices for protection and control

device (IED)
kill chain a systematic process to target and engage an adversary to create
desired effects
Note to entry: The steps of this process are find, fix, track target , engage,
assess: find adversary [EPU] targets suitable for engagement, fix their location,
track and observe, target with a suitable cyber-based asset to create the desired
effects, engage the EPU assets, assess the effects. This is an integrated, end -to-
end process described as a “chain” because any on deficiency will interrupt the
entire process.
logic bomb piece of code intentionally inserted into a software system that will
set off a malicious function when specified conditions are met
EXAMPLE 1 Software that is inherently malicious, such as viruses and worms,

often contain logic bombs that execute a certain payload at a pre-defined time or
some other condition. Virus or worm to gain momentum and spread before being
noticed use this technique.
EXAMPLE 2 Trojans that activate on certain dates are often called “time bombs.
Note to entry: A logic bomb requires the payload should be unwanted and
unknown to the user of the software. As an example, trial programs with code
that disables certain functionality after a set time are not normally logic
bombs.
53
Phrase Definition
record of action documentation of the results developed from the analysis of a
specific action
Note 1 to entry: Documentation requirements are a local matter that may

include a weighting factor based on risk assessment.
Note 2 to entry: A specific action may include, but is not limited to, one or more
combinations of documentation review, analysis of procedures to determine
effectiveness, and analysis of test results.
 Applicable documentation includes, but is not limited to, completion of
cybersecurity awareness training, test/demonstration plans and
procedures, configuration specifications, and conformance analysis.
 Applicable testing includes, but is not limited to supplier hosted testing,
maintenance testing, and decommissioning and disposal testing.
requirement need or expectation that is stated, generally implied or obligatory
[SOURCE ISO/IEC 27000-2014]
Note 1 to entry: “Generally implied” means that it is custom or common practice

for the organization and interested parties that the need or expectation under
consideration is implied.
Note 2 to entry: A specified requirement is one that is stated, for example in

documented information.
requirement context specification of intended use
Note to entry: A common security intended use state as a requirement context

is the service provider shall have the capability to implement a requirement
objective.
requirement specification of the goal to be achieved

objective
Note to entry: A common security goal stated a requirement objective is a
segmentation requirement.
resilience Ability of an organization, process entity or system, to resist being
affected by disruptions
[SOURCE: modified from ISO/IEC 27031]
54
Phrase Definition
spear-phishing an email that appears to be from a known or trusted individual or
business
Note to entry: But it isn’t, it’s from the same hacker or criminal.
SSL/TLS transport layer protocol that provides session-based encryption and

authentication
stateful inspection maintains the status of active connections through the firewall to
dynamically allow inbound replies to outbound connections
Note to entry: Also known as dynamic packet filtering.
technical controls mechanisms that protect the system from incidents or attacks
EXAMPLE Anti-virus software, access controls, backups, recovery and audit

software (37).
technical security quantitative index of the enabling mechanisms that are appropriate
level (TSL) for the security requirements of the application and environment
[modify FIPS SP 140-2 (39) usage]
Level 1: lowest level – basic security requirements are implemented and

maintained. Such implementations may be appropriate for some low -level
security applications when other controls, such as physical security, network
security, and administrative procedures are limited or nonexistent.
Level 2: adds tamper-resistant requirements to level 1 that are implemented and
maintained. Security Level 2 requires, at a minimum, role-based authentication
control (RBAC) for the authorization of a user (operator, engineer, technician,
etc.) to assume a specific role and perform a corresponding set of services.
Level 3: adds detection and prevention requirements to level 2 that are
implemented and maintained.
1) Security level 3 requires have a high probability of detecting and responding to
attempts at physical or cyber access, and use or modification of control system
configurations, settings, etc.
2) Security level 3 requires identity-based authentication mechanisms, enhancing the
security provided by the role-based authentication mechanisms specified for Security
Level 2.
3) Security Level 3 requires the entry or output of plaintext (using split knowledge
procedures) be performed using ports physically separated from other ports, or
interfaces logically separated using a trusted path from other interfaces.
Level 4: highest level – adds physical security and cybersecurity requirements
that provide a complete envelope of protection around the system under
consideration with the intent of detecting and responding to all unauthorized
attempts at physical or electronic access.
1) Security Level 4 implementations are useful for operation in physically unprotected
environments.
2) Security Level 4 also protects against a security compromise due to environmental
conditions or fluctuations outside of the systems operating ranges for voltage and
temperature. An attacker to thwart cyber defense may use intentional excursions
beyond the normal operating ranges.
trust assured reliance on the character, ability, strength, or truth of an

entity (person, place, or device)
Note to entry: “assured” requires some means to verify and

authenticate the entity.
55
Phrase Definition
unidirectional a combination of hardware and software whose hardware is
gateway physically able to transmit information in only one direction, and
whose software replicates servers and emulates devices.
usability specification of the fitness for use of a Solution for its users and
requirement other actors
virtual machine an emulation of a particular computer system
Note to entry: Virtual machines operate based on the computer

architecture and functions of a real or hypothetical computer, and
their implementations may involve specialized hardware, software,
or a combination of both.
A.3. ACRONYMS AND ABBREVIATIONS

ANSSI French Network and Information Security Agency,
APT advanced persistent threat
ADS Australian Signals Directorate

ASN autonomous system number
AV anti-virus
BPMN business process model and notation (40)

C2 command and control
CERT computer emergency response team

CSIRT computer security incident response team
CTI cyber threat intelligence
DHS Department of Homeland Security [US]

DLP data loss prevention
DNS domain name system
DoS denial of service
DRM digital rights management
EDI electronic data interchange
EDR event detection and response

ENCS European Network for Cyber Security
ENISA European Union Agency for Network and Information Security
EPRI Electric Power Research Institute
EPU electric power utility
EVM ethereum virtual machine
FOR forced outage rate
FTP file transport protocol
HTTP hypertext transfer protocol

HTTPS hypertext transfer protocol over SSL/TLS
56
IaaS infrastructure as a service
IDaaS Identity and access management as a service
IANA Internet Assigned Number Authority
ICANN Internet Corporation for Assigned Names and Numbers
ICS industry control system
IDS intrusion detection system
IEC International Electrotechnical Committee
IED intelligent electronic device
IEEE Institute of Electrical and Electronic Engineers
IPS intrusion protection system
ISA The International Society of Automation
ISO International Standards Organization
ISAC information sharing and analysis centre

ISMS information security management system
ISOC integrated security operation centre
ISP Internet Service Provider
IT information technology
MPLS multiprotocol label switching
NERC North American Electric Reliability Corporation
NIS network and information security
NIST National Institute for Standards and Technology
NFV network function virtualization
NSA National Security Agency (US)
NTA network traffic analyser

NZ New Zealand
OOSEM object-oriented systems engineering method
OMG Object Management Group
OT operational technology
P&C protection and control
PaaS platform as a service
RIR Regional Internet Registry
SAIDI system average interruption disruption index
SAIFI system average interruption frequency index
SCADA system control and data acquisition
SaaS software as a service
SDN software defined networking
SDL system dynamic language
SIEM security information and event management

SLM security level management
57
SMTP simple mail transfer protocol
SNMP simple network management protocol
SoS systems of systems
SP special publication
SSH secure shell
SSL secure socket layer
SuC system under consideration
SysML system modelling language
TCP transmission control protocol
TLS transport layer security
TSL technical security level
TTP tactics, techniques, and procedures
UDP user datagram protocol

UML universal modelling language
URL uniform resource locator
VM virtual machine
VMM virtual machine monitor
VPN virtual private network
WAN wide area network
58
ANNEX B. SURVEY OF CYBER THREAT READINESS

B.1 BASELINE CAPABILITIES REQUIRED
In a 2015 survey of 314 organisations operating ICS around the world, 20 per cent of whom are
based in the Middle East, over 100 respondents indicated that their control systems were breached
more than twice in the last 12 months (41).
The SANS Institute published a paper describing the effective use of cyber threat intelligence (CTI)
data (42). The authors describe a set of nine capabilities to process cyber threat intelligence data
obtained internally and from external sources. CIGRE WG D2.38 used the SANS capabilities to
develop the questions for the global survey. Shown below is WG D2.38’s description of the required
capabilities.
R1 – Capability to import/export indicator details to/from other systems in a standard format.

R2 – Capability to import/export structured incident data to/from other systems in a standard format.
R3 – Capability to query, import, export and manage CTI data through a user interface.
R4 – Capability to enforce data sharing based on an attribute attached to CTI data.
R5 – Capability to automate the import and export of CTI data.
R6 – Capability to provide authentication and confidentiality when sharing data.
R7 – Capability to export data for detective and preventive controls.
R8 – Capability to select data for export based on creation dates of CTI data.
R9 – Capability to measure the efficacy of CTI feeds.
B.2 SURVEY QUESTIONS
Table B-1 lists the questions asked in the survey of EPU organizations responsible for cyber -
protection of their critical infrastructure systems and communication network components. The
first column is the question ID provides a cross -reference to related questions. The next two
columns are the question asked and the response options. The last co lumn is WG D2.38’s objective
or purpose of the question. The “objective” in the survey questionnaire is not distributed.
Table B-1 Cyber threat capability survey questions
Question
Question asked Response options Objective
ID
Do you have the tools needed to

Establish landscape
1 collect, process, and report cyber YES, NO, PLAN TO by year-end 2017
of capabilities
threat data?
Do the tools require specialized

2 knowledge and training in YES, NO
cybersecurity analysis? Establish maturity
Are the tools automated to level of deployed
facilitate data collection, sorting, capabilities
3 YES, NO
and use of standard report
templates?
What are the major difficulties that

Rank order (1=most important to n=
impact the efficacy of collecting, Prioritize
4 least important) the difficulties listed
processing, and reporting cyber challenges
below.
threat data?
Within your EPU is IT or OT the IT, OT, or either depending on the Describe
5
cybersecurity team leader? cyber-physical incident. separation of
59
Question
ID
Does your EPU form a single duties &
cybersecurity team or are the team information
6 Single team or Separate team sharing issues.
structure separated between IT
and OT?
If separate teams, is information

7 sharing a significant impediment to YES, or NO
reach consensus?
Local area networks including edge

devices (routers, gateways, switches):
Within your EPU does IT or OT IT or OT
have the responsibility for cyber- Wide area networks including edge
8 physical incident management devices (routers, gateways, switches):
resulting from operational network IT or OT
intrusions? Wireless networks including edge
devices (routers, gateways, switches,
modems): IT or OT
Downtime per hour
What measure of downtime is used Downtime per day
9 to evaluate impact or severity of a Measure of severity
fault regardless of its cause? Downtime per week
Downtime per month
Group discussion with consensus based
on expert opinions
What methodology is used to Follow a logical sequence of events and
assess the adequacy of your decisions as outlined in an assessment
10
system to protect against cyber- flow chart
initiated attack? Use power system reliability modelling
and simulation to quantify downtime
impact of cyber-initiated attacks
In-depth knowledge of system

operations and settings is required to
effectively execute the cyber-attack
Using the methodology in question Collaboration with authorized
5, do you normally have consensus operational people is required to
11
on the following factors? Check all effectively execute the cyber-attack
that apply. The cybersecurity systems adequately
thwart probing of the operational Measure of cyber-
networks (wireless networks, local area robustness
networks, wide area networks)
Attack in the computer room or control

centre
Insider attack
Intrusion through corporate LAN to
substation LAN
Rank order (1=highest, 6=lowest) Malicious code in substation network
the impact of security breach (including edge devices – routers,
12
scenarios on your utility’s switches, gateways, modems)
operation.
Intrusion in protective relay
Access to RTU
Man-in-the-middle attack between
control centre and substation
Intrusion in the substation HMI
60
Question
ID
Do you use a forced outage rate
(FOR) model to forecast the YES, NO
occurrence of forced outage on a Cyber-robustness
13 If NO, describe how the impact is
component which indicates the metric
unavailability status and the impact assessed.
of the cyber-attack?
Do you use a standard template YES, NO

and format for electronic data If YES, identify the standard template
14
interchange with your integrated used.
Standardize the
security operations centre (ISOC)?
electronic data
exchange
Do you use an open system YES, NO
15 program to populate the data for If YES, identify the open system
electronic data exchange? program used.
Do you encrypt the data-at-rest in YES, NO

16
your ISOC?
Physical access to ISOC data Means to protect

repositories is controlled (locked doors, data
Do you provide protection by either cabinets, etc.)
17
of the following means?
Cameras monitor ISOC activity 24/7.
None of these are used.
Does your protection and control
(P&C) architecture include a hot
18 YES, NO
backup system with hot switch-
over for critical functions? Real-time detection
Does your backup P&C system use and response
separate communication systems
19 YES, NO
that are not part of the primary
P&C system
Does your EPU follow the

guidelines security assurance
20 requirements defined in NIST YES, NO
Special Publication 800-53 Revision
4[14]?
NIST 800-53 Revision 3 or earlier

IEC 62443-2-1 (ISA 62443-2-1)
Which of the document(s) do you IEC 62443-3-3 (ISA 62443-3-3)
21 use to establish security assurance
requirements? ISO 27000
None of the above
Use of recognized
standards,
guidelines, or best
Other. practices
Not clear how to select requirements
Which of the following may have based on security level.
22 discouraged your use of NIST 800- None of these are a problem for us.
53 Revision 4?
Cross-coupling or interdependency of
requirements is not clearly described.
Missing parts or early drafts of related
IEC 62443 parts.
Do you use FIPS Pub 200[11] and
FIPS PUB199[15] as guide to
23 YES, NO
identify the minimum-security
requirements?
61
Question
ID
None of the above
ISO 27000
Which of the documents (if any) do NIST 800-53 Revision 3 or earlier
24 use to establish security assurance Other
requirements? IEC 62443-3-3 (ISA 62443-3-3)
IEC 62443-2-1 (ISA 62443-2-1)
NIST 800-53 Revision 4
What method was used to identify Our own subject matter expert.
25 the minimum-security
requirements? Developed our own method.
High-impact: At least one security

objective (i.e. confidentiality, integrity,
or availability) is assigned a potential
impact value of high. Technical approach
to establish
Moderate-impact: At least one security
security
objective (i.e. confidentiality, integr ity,
Which impact level was used as the requirements.
or availability) is assigned a potential
26 target for your protection and
impact value moderate, and no security
control system?
objective is assigned a potential impact
value of high.
Low-impact: All three security objectives
(i.e. confidentiality, integrity, or
availability) are assigned a potential
impact value of low.
B.3 SUMMARY OF SURVEY FINDINGS

The findings presented in Newton-Evans report 20 are based on the completion of detailed surveys
received from 53 utilities located in 26 countries representing each world region.
For most questions, findings and observations for the two major subgroupings (North America and
International) were quite similar. However, when international regions were placed in smaller
subgroups, the North American and European responses were strikingly similar, while th ere were
substantial differences observed for the responses to some key questions from utilities in Latin
America, Africa and the Middle East, and the Asia -Pacific countries.
Table B-2 is a summary of the survey responses.
Table B-2 Survey response summary
Question
Question asked Response summary
ID
Approximately half of all respondents reported that they do

Do you have the tools needed to currently have tools needed to collect, process and report
1 collect, process, and report cyber cyber threat data. About 1 in 5 of the respondents not having
threat data? such tools in mid-2015 expect to acquire or develop such tools
by year-end 2017.
20 The full report may be obtained from cnewton@newton-evans.com
62
Question
ID
Nearly 70% of the subset of utility officials responding to this
Do the tools require specialized
question indicated that specialized knowledge and training in
2 knowledge and training in
cybersecurity analysis is required to effecti vely operate the
cybersecurity analysis?
cyber tools.
Are the tools automated to Nearly three quarters of the responding subset of utility
facilitate data collection, sorting, officials (who had earlier indicted having cyber tools) reporte d
3
and use of standard report that cyber threat tools are automated to facilitate data
templates? collection, sorting and use of standard report templates.
The most important difficulty reported was the “inability to

What are the major difficulties that
correlated data to establish a reasonable hypothesis regarding
impact the efficacy of collecting,
4 the source of a cyber-threat and objective of the cyber-induced
processing, and reporting cyber
attack. Next in importance was concern about the lack of
threat data?
confidence in the validity of the data collected.
The findings from this question clearly indicate that IT

Within your EPU is IT or OT the departments take the leadership role as a cybersecurity team
5
cybersecurity team leader? leader. In some cases, it depends on the facts surrounding the
incident itself.
Does your EPU form a single

cybersecurity team or are the team
6 The responses were evenly divided.
structure separated between IT
and OT?
Among the subset of utilities that have separate cybersecurity

If separate teams, is information
teams, information sharing was identified as a significant
7 sharing a significant impediment to
impediment to consensus in nearly one-half of the utilities
reach consensus?
responding.
Within your EPU does IT or OT

IT and OT share responsibilities for cybersecurity incident
have the responsibility for cyber-
management resulting from operational network intrusions,
8 physical incident management
whether those intrusions occur on wireless networks, wide-
resulting from operational network
area networks or local area networks.
intrusions?
Downtime per hour was cited more frequently than other listed
measures. SAIDI and SAIFI were also important measures.
SAIDI is the average outage duration for each customer
What measure of downtime is used served. SAIDI is measured in units of time, often minutes or
9 to evaluate impact or severity of a hours.
fault regardless of its cause?
SAIFI is the average number of interruptions that a customer
would experience. In other words, SAIFI is measured in units of
interruptions per customer.
“Having group discussions with consensus based on expert

What methodology is used to opinion” was reported as the principle method being used to
assess the adequacy of your assess the adequacy of utility systems to protect against
10
system to protect against cyber- cyber-initiated attacks. Less importance was attached to
initiated attack? “follow a logical sequence of events and decisions as outlined
in an assessment flow chart.
Using the methodology in question Sixty-one percent cited “in-depth knowledge of system and
5, do you normally have consensus settings is required to effectively execute a cyber -attack.”
11
on the following factors? Check all Fifty-eight percent indicated “the cybersecurity systems
that apply. adequately thwart probing of the operational networks.”
The most important operational impact of the eight listed
Rank order (1=highest, 6=lowest)
security breach scenarios based on the replies from utility
the impact of security breach
12 officials would be an attack in the control room or control
scenarios on your utility’s
centre, followed closely by an insider attack. All eight scenarios
operation.
were viewed as having significant impact on operations.
63
Question
ID
Do you use a forced outage rate One quarter of the 30 respondents to this question were using
(FOR) model to forecast the a FOR model to forecast the occurrence of a forced outage on
occurrence of forced outage on a a component indicating unavailability status and the impact of
13
component which indicates the the associated cyber-attack. North American officials were
unavailability status and the impact much more likely to use a FOR model than were their
of the cyber-attack? international counterparts (46% to 12%).
Nine of 30 responses to this question cited use of a standard

Do you use a standard template
template and format for electronic data interchange (EDI) with
and format for electronic data
14 the utilities ISOC. International utility officials were more likely
interchange with your integrated
to report using this approach than were North American
security operations centre (ISOC)?
respondents (35% to 23%).
Only four of 30 respondents indicated any use of open system

Do you use an open system
programs to populate the data for EDI. Two of the four
15 program to populate the data for
officials that were using open system programs were from
electronic data exchange?
major Asia-Pacific utilities.
Importantly, nearly one-half (45%) of the respondents to this

Do you encrypt the data-at-rest in question were encrypting data-at-rest in their ISOC. European
16
your ISOC? respondents were somewhat less likely than other regional
replies to be encrypting data-at-rest in their ISOC
About three quarters of the subset of 20 respondents reported

Do you provide protection by either providing protection via control of physical access to ISOC data
17
of the following means? repositories. About one third indicated use of camera
monitoring of ISOC activities on a 24/7 basis.
Nearly 80% of the respondents indicated that the utility’s

protection and control architecture did include a hot backup
Does your protection and control system with hot switch-over for critical functions. The use of
(P&C) architecture include a hot hot backup systems was particularly strong among the
18
backup system with hot switch- international respondents (including all five major Asia -Pacific
over for critical functions? utilities). Nearly two-thirds of North American respondents did
indicate the use of a hot backup system with hot switch -over
for critical functions.
Just about two-thirds of the officials reported using separate

communication methods for their backup protection and
Does your backup P&C system use
control systems that are separate from the primary protection
separate communication systems
19 and control systems. While 56% of North American
that are not part of the primary
respondents indicated use of separate communications, 71% of
P&C system
international officials concurred this this separation of
communication networks and systems.
Does your EPU follow the

This question was only asked of North American electric utility
guidelines security assurance
respondents. Of the 10 responding officials, six were unfamili ar
20 requirements defined in NIST
with 800-53. Four reported that they did follow the guidelines
Special Publication 800-53 Revision
for security assurance requirements defined in 800 -53.
4[14]?
Which of the document(s) do you This question was only asked of North American e lectric utility
21 use to establish security assurance respondents. Four responded and none used any of the
requirements? documents listed.

Which of the following may have respondents. Five responded. Two responded with comments:
22 discouraged your use of NIST 800- “not aware of” and “cannot stay current on revisions.” Two
53 Revision 4? were not clear how to select requirements based on security
level.
Do you use FIPS Pub 200[11] and

FIPS PUB199[15] as guide to
23 respondents. Four responded and none used any of the
identify the minimum-security
documents listed.
requirements?
64
Question
ID
More than one-half of the replies indicated no use of any of
Which of the documents (if any) do
the five listed documents, while two officials cited “other”
24 use to establish security assurance
documents: NERC CIP and the New Zealand’s (NZ) draft
requirements?
cybersecurity standard.
Two methods were listed on the survey form for respondents

to select either response. Important and substantial
differences were observed based on the world region of the
What method was used to identify utility. International respondents were very likely (75%) to
25 the minimum-security “develop their own method to identify minimum security
requirements? requirements with 44% also using their own subject matter
experts. North American officials strongly favoured use of their
own subject matter experts to determine their minimum-
security requirements, as cited by 88% of that s ubgroup.
61% of the 18 respondents indicate use of a high-impact level

Which impact level was used as the
to serve as the target of their protection and control system.
26 target for your protection and
One third of this subgroup reported using a moderate-impact
control system?
level, and only one reply cited used of a low -impact level.
65
66
ANNEX C. SYSTEM DYNAMICS MODEL OF AN INSIDER

ATTACK
C.1 INTRODUCTION
In 2003 Carlos Melara and his colleagues developed a system dynamics model 21 of an insider
attack on an information system to gain insight into the dynamics of the problem and to
minimize the risk of security failures should an insider attack occur (37). In the paper, they
adopted three kinds of security controls for their model: technical controls, formal controls, and
informal controls. Implemented, they claim, effectively secures an information system.
The following year, 2004, twenty-five researches from eight institutions continued the work
and published system dynamics models of insider and outsider cyber -attacks with the objective
to improve organizational security and survivability by suppression of dynamic triggers (38).
They noted that the distinction between insider and outsider is possibly dynamic in that a
partner for one activity may be a competitor or adversary for another. WG D2.38 applied this
guideline to the requirement specification for tools.
Of particular interest to WG D2.38 is their view of how well targeted actions can reduce the
technical security level of the system. Furthermore, the model illustrates how the lack of formal
controls manifests in the way management perceived the security level of the system in terms
of downtime instead of in terms of security audits or other established formal controls.
Logic bombs used to gain control over the system introduce “time delays” which must be
considered to correlate accurately time-tagged status data for precursor analysis and impact of
downtime. Additional insight into quantifying time delays can be derived from examining other
models that focus attention on specific targets of opportunity; e.g., SCADA system (43), breaker
tripping (44), and advanced metering infrastructure (45).
C.2 SECURITY LEVEL MANAGEMENT ENFORCEMENT

Security level management (SLM) comprises a quality assurance system for EPU IT and OT
security. SLM design should display security status transparentl y across organizations at any
time. Transparency is essential to measure IT and OT security. WG D2.38 considered
transparency and measurability as the prerequisites for automating all processes to collect,
monitor, correlate, and to generate recommended actions in a timely manner. This foundation
provides the means to improve continuously the EPU’s security posture.
With adequate SLM capabilities, the security level is continuously checked against current
performance of the security systems (malware scanner, patch systems, etc.). With proper
awareness training, early on deviations are recognized and adjustments made to the security
systems.
Author’s Note: at the time of this report, the following clauses identify global survey questions
and to interpret responses to the questions. In the future, WG D2.38 may use the equations to
generate parametric data to evaluate cyber -physical sensitivity issues. For now, the clause and
equations are preliminary, rough draft thoughts. However, before running simulations WG
D2.38 needs to establish proper scenarios, targets of opportunity, and time scales.
C.3 SYSTEM DYNAMICS VIEW OF INSIDER INCIDENTS ON DOWNTIME

What factors have a strong influence on downtime?
WG D2.38 examined Melara’s (37) view of downtime, replicated in Figure 11, to identify these
factors. In accordance with this view, WG D2.38 focused attention on tool set requirements,
21 This technical brochure uses Vensim PLE for Windows is to develop the system dynamics model. The notation
used in the model is readily available in the Vensim user’s guide available from
http://vensim.com/docs/#user8217s-guide.
67
which if properly implemented provide the means to effectively manage the technical security
level. Two rate parameters (impact of incidents and downtime recovery) automate SLM.
Time Bomb
Severity Effect of Technical Severity
<Technical Level on Time Bomb
Security Level> Severity
Precursor Incident
Severity
Effect of Technical Security Downtime

Level on Precursor Incident Impact of Downtime
Severity Incidents Recovery
Impact Time Downtime
Recovery Time
Insider Precursor Time Bomb
Incidents
<Time Bomb
Trigger>
Start of Problematic <Insider Decision
Behavior to Attack>
Figure 11 Effect of Insider incidents on system downtime
Adapted from A System Dynamics Model of an Insider Attack on an Information System, by C. Melara, et.al. Adapted with
permission.
C.4 RATE EQUATION TO MEASURE IMPACT OF INCIDENTS

Quantified impact of incidents is downtime per week.
Precursor Incident Severity∗Insider Precursor Incidents+Time Bomb∗Time Bomb Severity
Impact of Incidents = Eq. 1
Impact Time
Where
Precursor Incident Severity = (1 − Technical Security Level) ∗

Effect of Technical Security Level on Precursor Incident Severity Eq. 2
NOTE Measured in Incident
Insider Precursor Incidents = IF THEN ELSE (Start of Problematic Behavior = 1, (1 −

Insider Decision to Attack) ∗ PULSE TRAIN (0, 1, 6, 500), 0) ∗ Incident Unit Eq. 3
NOTE Measured in Incident
Time Bomb Incident = DELAY FIXED (3 ∗ Incident Unit ∗ Preparing Time Bomb, 6, 0) Eq. 4
Time Bomb Severity = (1 − Technical Security Level) ∗

Effect of Technical Security Level on Time Bomb Severity Eq. 5
NOTE Measured in DS/Incident
Effect of Technical Security Level on Time Bomb Severity = 1
NOTE Set 1/Incident
Technical Security Increment −

Technical Security Level = INTEG ( ) Eq. 6
Technical Security Reduction, Init TSL
NOTE Measured in DS
Desired Technical Security−Management Perception of Technical Security

Technical Security Increment = Eq. 7
Time to Increment Technical Security
68
NOTE Measure in DS/Week
Insider Actions to Reduce Technical Security ∗Insider Actions Severity

Technical Security Reduction = Eq. 8
Time to Reduce Technical Security Level
NOTE Measured in DS/Week
INIT TSL = 0.8
NOTE Set as DS
Desired Technical Security = 0.8 Eq. 9
NOTE Set as DS
Management Perception of Technical Security

= SMOOTH(Init TSL − Downtime
∗ Fractional Effect of Downtime on Management Perception of Technical Security,
Time to Perceive Techncial Security) Eq. 10
NOTE Measure in DS
Insider Actions Severity = Insider Desired Technical Security Reduction ∗

Insider Capacity to Reduce Techncial Security Eq. 11
NOTE Measure in DS/Action
Time to Reduce Technical Security Level = 1 Eq. 12
NOTE Set as Week
Fractional Effect of Downtime on Management Perception of Technical Security = 20 Eq. 13
Time to Perceive Technical Security =

Fractional Effect of Formal Controls on Mgmt Time to Perceive Technical Security
Eq. 14
Formal Controls
NOTE Measure as Week
Insider Desired Technical Security Reduction = 0.1 Eq. 15
NOTE Measured in DS/Action
Insider Capacity to Reduce Technical Security = 1 − Formal Controls Eq. 16
Fractional Effect of Formal Controls on Mgmt Time to Perceive Technical Security = 4 Eq. 17
NOTE Measured as Week
Formal Controls = 0.1 Eq. 18
C.5 RATE EQUATION TO MEASURE DOWNTIME RECOVERY

The downtime recovery is quantified as downtime per week.
Downtime
Downtime Recovery = Eq. 19
Downtime Recover Time
NOTE Measured in DS/Week
Downtime Recovery Time = 4 Eq. 20
NOTE Set as Week
C.6 SYSTEM DYNAMICS VIEW OF SECURITY LEVEL REDUCTION

What factors degrade the level of security when vulnerabilities are exploited by an insider?
69
WG D2.38 examined Melara’s view (37) of security level reduction, replicated in Figure 12, to
identify these factors. These factors and those in clause C.3 were used to formulate the
questions for the global survey outlined in Annex B, and then to understand the respondent’s
answers to the survey. Examination of Figure 10 identified five important factors for this
purpose.
1) Desired level of technical security enforced by policy and organizational directives.

2) EPU management commitment to security.
3) Fractional effect of formal controls on management time to perceive technical security
with an emphasis on downtime or dropped load.
4) Time (and cost) to increment technical security.
5) Effectiveness of formal controls to counter insider’s capacity to reduce technical security.
Insider Decision to
Attack
Insider Actions to
Reduce Technical
Technical
Security Security
Technical Security Level Technical Security
Desired Technical Increment Reduction
Security
Init TSL
Insider Capacity to
Reduce Technical
Insider Actions Security Formal
Severity Controls
Fractional Time Management Perception
Increment Time to Increment
Technical Security of Technical Security
Time to Reduce
Technical Security Insider Desired
Technical Security
Reduction
Pressure to Grow
Fractional Effect of Downtime
Mgmt Commitment on Management Perception of Time to Perceive
to Security <Downtime> Technical Security Techncial Security
Fractional Effect of Formal

Controls on Mgmt Time to
Perceive Technical Severity
Figure 12 Security level reduction
Adapted from A System Dynamics Model of an Insider Attack on an Information System, by C. Melara, et. al . Adapted
with permission.
70
ANNEX D. FIREWALL VULNERABILITIES

D.1 FUNDAMENTAL LIMITATIONS OF FIREWALL TECHNOLOGY
Firewalls are important parts of IT network security programs, and important for internal
segmentation of control system networks. Firewalls have fundamental limitations though, and
an appreciation of these limitations is essential to deploying firewalls effectively within a
defense-in-depth program. Ginter (46) explains fundamental limitations and intrinsic
vulnerabilities of firewalls, including:
1) Firewalls are routers with filters, forwarding some subset of network traffic from one
network to another. For attack packets to penetrate a firewall, the packets must be
crafted to contain attack information and defeat the firewall filter software.
2) All firewalls are software, and all software has vulnerabilities – firewalls are no exception.
Firewall firmware update programs should promptly apply security updates for known
vulnerabilities. Even with such programs though, f irewalls are always vulnerable to so-
called zero-day vulnerabilities.
3) Firewalls are configurable, and so stolen administrator credentials for a firewall can
generally be used to reconfigure the firewall into an insecure state. In the worst case, a
compromised or otherwise mis-configured firewall is no more than a router.
D.2 WHY PORT-BASED FIREWALLS ARE NOT EFFECTIVE
Lawrence Miller described in simple terms why port -based firewalls are no longer effective (23).
Port-based firewalls (and their variants) use source/destination IP addresses and TCP/UDP port
information to determine whether to allow a packet to pass between networks or network
segments. The firewall inspects the first few bytes of the TCP header in an IP packet to
determine the application protocol – for example, SMTP (port 25) and HTTP (port 80).
Most firewalls configurations allow all traffic originating from the trusted network to pass
through to the untrusted network, unless specifically blocked by a rule. For e xample, the Simple
Network Management Protocol (SNMP) might be explicitly blocked to prevent certain network
information from being inadvertently transmitted to the internet [or from the operations
network to the business network]. This would be accomplished by blocking UDP port 161 and
162, regardless of the source or destination IP address.
Static port control is relatively easy. Stateful inspection firewalls address dynamic applications
that use more than one well-defined port (such as FTP ports 20 and 21). When a computer or
server on the trusted network originates a session with a computer or server on the untrusted
network, a connection is established. For stateful packet inspection firewalls, create a
temporary dynamic rule to allow responses or replies from the computer or server on the
untrusted network. Otherwise, explicitly permit the return traffic, or manually create firewall
access rules (which usually is not practical).
IT organization have tried to compensate for deficiencies in traditional port-based firewalls by

surrounding them with proxies, intrusion prevention systems, URL filtering, and other costly
and complex devices, all of which are equally ineffective in today’s application and threat
environment.
Malicious intent hidden by way of tunnelling within well-known protocols. For example, malware
propagates, extract information and issue control and command instructions via tunnelling
within HTTP or other commonly used protocols that seem harmless and willingly passed by the
traditional port-based firewall. However, when used in combination with application -aware
controls such as App-ID (see 4.2.2), traffic flows that are suspiciously out of the pr otocol norm,
such as tunnelled traffic, can be identified.
71
D.3 IDENTIFYING AND PREVENTING ROUTER, SWITCH, AND FIREWALL

VULNERABILITIES
D.3.1 Firewall dataflow model identifies vulnerability opportunities
EPUs commonly implement perimeter defense by installing firewalls to protect critical IT and
OT networks. Firewalls are software and hardware systems the protect these networks from
attacks originating outside the protected network or network segment by filtering and managing
traffic. Currently a diverse set of firewalls are being used. As discussed in (47) (48) it is
infeasible to examine each firewall vulnerabilities in the context of firewall operations.
The firewall dataflow model, shown in Figure 13, gives an overall description of firewall by
detailing the operations they perform 22 . When a packet is received by a firewall, it first
undergoes link layer filtering. Then it is checked against a dynamic rule set. The packet then
undergoes packet legality checks and IP and port filtering. Finally, network/port address
translation is performed. Sophisticated firewalls also reassemble packets and perform
application level analysis. After a routing decision is made on the packet, out -bound filtering
may also be performed. Each of these operations is optional, and the order in which a traverse
them may also differ in different firewalls.
22 BPMN notation is used to modify the figure extracted from [47] S. Kamara, S. Fahmy, E. Schultz, F.
Kerschbaum, and M. Frantzen, "Analysis of vulnerabilities in internet firewalls," Computers & Security, vol. 22,
pp. 214-232, 2003.
72
Packet receipt by firewall
Start firewall packet flow
Link layer filtering
Dynamic rule set (static)
Packet may be dropped

Packet legality checks
(bypass on match)
Packet may be dropped

IP and port filtering
(bypass on match)
NAT/PAT (header rewite)
Packet reassembly
Application level analysis Stream may be dropped
Routing decision
Dynamic rule set (static)
Packet sanity checks Optional outbound filtering
IP and port filtering
Packet release
End firewall packet flow
Figure 13 Firewall operations and data flow
Figure and accompanying text is extracted from (47).

D.3.2 Firewalls are easy targets for hackers
Brad Casey published an interesting article on why firewa lls are easy targets for hackers (49).
Casey concludes that “remote connectivity to network resources has become a staple for many
employees of modern enterprises [e.g. EPUs]. Whether the connection is conducted via VPN,
remote desktop or Secure Shell (SSH), it will unavoidably transverse a network path laden with
routers switches and firewalls, many of which can easily be compromised.”
Casey continues with the threat of border gateway protocol (BGP) redirection. “Another
potential danger in utilizing networked equipment is data loss. While attacks can be
accomplished several diverse ways, a method known as BGP redirection has become
increasingly troubling. BGP exchanges the routing information and unique identifiers known as
autonomous system numbers (ASNs) that are assigned by either the Internet Assigned Number
73
Authority, or IANA, or Regional Internet Registries, or RIRs. When packets cross an ISP’s
gateway, the gateway can identity which ISP an individual packet came from by e xamining the
ASN in the packet’s header.”
Casey concludes with the following recommendations to prevent compromises.
1) Frequent auditing should be the rule of the day.

2) Use public key infrastructure (PKI) between autonomous systems. A word of caution:
a) Public key or asymmetrical key is correctly used here. The “I” part (infrastructure) is
not.
b) Third party certificates cannot be trusted as there is no validation of accuracy or
correctness only that the certificate was issued by someone to someone.
3) At the network level, monitor the routes of incoming packets and search for anything
anomalous in them.
4) To avoid firewall compromise, strongly consider blocking all inbound and outbound traffic
by default, and encourage the user to justify why certain traffic should be allowed
through the firewall.
5) Strictly enforce control over who has out -of-band management access to the firewall, and
from where each administrator can access management functions.
D.3.3 Deep dive into an analysis of firewall vulnerabilities
Seny Kamara, et al, from Purdue University published a deep dive into an “Analysis of
Vulnerabilities in Internet Firewalls (47)” that should be of interest to EPU security experts.
This paper describes a novel methodology for analysing vulnerabilities in Internet firewalls. The
analysis methodology generates a set of matrices that illustrate the distribution of firewall
vulnerability causes and effects over firewall operations. These matrices are useful in avoiding
and detecting unforeseen problems during both firewall implementation and firewall testing.
This paper lists the most common vulnerability causes.
1) Validation error: A validation error occurs when the program interacts with the
environment without ensuring the correctness of the environmental data. There are three
types of environmental data that need validation: input, origin, and target.
a. Input validation ensures that the input is as expected. This includes the number, type
and format of each input field.
b. Origin validation ensures that the origin of data is what it is claimed to be, e.g.
checking the identity of the IP source.
c. Target validation ensures that the information goes to the place it is supposed to. This
includes ensuring that the protected information does not go to an untrusted target.
2) Authorization error: An authorization error permits a protected operation to be invoked
without sufficient checking of the authority of the invoking agent.
3) Serialization/Aliasing error: A serialization error permits the asynchronous behaviour of
different system operations to be exploited to cause a security violation. Many time -of-
check-to-time-of-use flaws fall into this category. An aliasing flaw occurs when two names
for the same object can cause its contents to change unexpected ly, and, consequentially,
invalidate check already applied to it.
4) Boundary checking error: A boundary checking error is caused by failure to check
boundaries and ensure constraints. Not checking against excessive values associated with
table size, file allocation, or other resource consumption, leads to a boundary checking
error. Buffer overflow is the result of a boundary checking error.
5) Domain error: A domain error occurs when the intended boundaries between protection
environments have “holes.” This causes the information to implicitly leak out.
6) Weak/Incorrect design error: A design error occurs can be traced to the system design
phase. For example, a weak encryption algorithm falls into this category.
74
Vulnerability effects include:
1) Execution of code: This occurs when a vulnerability can lead to code being illegitimately
executed. This includes, but is not limited to code written by an attacker.
2) Change of target resource: This occurs when a vulnerability allows the state of a resource
to be illegitimately changed by an attacker. A resource can be a host, a firewall rule table,
or any entity that should be protected by the firewall.
3) Access to target resource: This occurs when a vulnerability allows an attacker illegitimate
access to a target resource. Examples of this vulnerability effect include allowing an
attacker to read the firewall rule tables, of to find out which services are available on a
protected host.
4) Denial of service (DoS): This occurs when a vulnerability is exploited to disrupt a service
provided to legitimate users. Services in this context may range from packet forwarding or
network address translation to administration.
75
76
ANNEX E. CHECKLIST OF MEASURES TO HELP MITIGATE

CYBER-ATTACKS ON EPU COMMUNICATION CONTROL
CHANNELS
E.1 COUNTERMEASURE OBJECTIVE
A promising approach to mitigate cyber-attacks on EPU communication control channels is to
detect and disrupt the use of those channels by attackers to effectively limit the damage
suffered because of a success attack (16). To make channel detection and blocking more
difficult, attackers also use covert communication mechanisms that mimic regular EPU control
traffic patterns. Described in this annex are the checklist of measures that EPU should consider.
E.2 DETECT KNOWN-BAD NETWORK ACTIVITY

EPUs should systematically, and to the maximum extent possible, automatically collect and
analyse network traffic to identify activity by an active control channel.
1) In accordance with EPU policy, procedures and organizational directives, responsible

organizational units should monitor domain name system (DNS) traffic to identify internal
devices that attempt to contact domains known to be involved in control activity. This
method involves collection of DNS traffic information ( either through a passive DNS
collector or via the named server logs) and matching of requests against one or more
black lists of malicious domain names.
2) In addition, the responsible organization unit should monitor IP traffic to identify internal
devices that attempt to connect to endpoints known to be involved in control activity. This
measure involves collection of IP traffic information (for example enabling NetFlow 23 and
sFlow 24 collection in routers) and matching of communication against one or more
blacklists of malicious IP addresses.
3) Lastly, the responsible organizational unit should monitor traffic content to identify
content that matches known control traffic (e.g., specific network request/response
signatures). This measure involves collection of fu ll traffic content (for example, enabling
a network sniffer) and matching of the collected data against traffic signatures.
E.3 DETECT ANOMALOUS NETWORK ACTIVITY
EPUs should systematically, and to the maximum extent possible, automatically collect and
analyse network traffic to identify activity that deviates from the expected, normal traffic profile
of the monitored network.
1) In accordance with EPU policy, procedures and organizational directives, responsible

organizational units should establish traffic ba selines to determine the “normal” profile of
the network (normal communication patterns, data exchange volumes, etc.). By
determining baselines for different time windows (e.g., hour, day) internal devices, and
network services implementation of this measure is possible.
2) The responsible organizational unit should evaluate current network activity against the
established baselines to identify deviations that may be indicative of control activity. Issue
alerts to trigger management action when anomalies such as a surge exchanged traffic or
when observing suspicious network behaviors.
23 Netflow is a feature introduced on Cisco routers that give the ability to collect IP network traffic as it enters or
exits an interface. By analyzing, the data provided by NetFlow a network administrator can determine things such
as the source and destination of the traffic, class of service, a nd the cause of congestion. NetFlow consists of
three components: flow caching, flow collector, and data analyzer.
24 sFlow, short for "sampled flow", is an industry standard for packet export at Layer 2 of the OSI model. It provides
a means for exporting truncated packets, together with interface counters. The sFlow.org consortium, the
authoritative source of the sFlow protocol specifications, performs maintenance of the protocol. The current
version of sFlow is v5.
77
E.4 DENY CONTROL ACTIVITY

EPUs should design and operate the network in such a way to effectively deny or greatly impair
improper control activity.
1) The responsible organizational unit should segment the network to separate devices with
different trust and risk values (e.g., front -facing, public servers vs. internal hosts storing
sensitive data). Consult IEC 62443-3-2 to develop effective segmentation architecture.
Other references are the ANSSI Cybersecurity for Critical Infrastructure standards.
2) The responsible organizational unit should enforce rate -limit policies to slow down traffic
directed to disreputable or un-trusted endpoints.
3) The responsible organizational unit should enforce the means to block unwanted or
unused communication mechanisms that may be used to piggyback control activity.
78
ANNEX F. REQUIREMENTS COVERAGE ANALYSIS

F.1 OVERVIEW
Security analysis of EPU control systems is an important topic because the perceived re sults of
a successful cyber-initiated attack could seriously interfere with, disrupt, or disable the critical
infrastructures (50). EPU OT components have become more complex to provide multifunction
capabilities. This increasing complexity requires sophisticated tools to configure and maintain
the operational system. Security requirements imposed on the design and use of these tools
are specified in multiple standards, guidelines and local laws and regulation. Understanding
these requirements and the relationship between requirements is a significant challenge. To
address this issue, this technical brochure introduces a formal methodology to perform a
requirements coverage analysis (RCA) that can be applied to all phases of a sy stem’s life cycle.
RCA modelling constructs are intended to provide a bridge between traditional requirement
management tools and system models.
Requirements specified in one or more standards, or derived by EPU experts are constrained
by the unique scope and focus of the operational environment and mission objective. To
exacerbate this situation several years separate the deployment of EPU operational systems,
subsystems and components. Thus, it is necessary to examine the relationship between
requirement objectives specified in all applicable sources. Such examination requires a coherent
methodology and tool set 25 to facilitate importing requirement objectives and subsequently
depicting these objectives in graphical, tabular, matrix, or tree structure format 26. The key
features used to develop conformance metrics include:
1) Diagramming to create views of the relations hip between requirement objectives to

identify the common means to determine conformance criteria – the records of action.
2) Table to organize text-based requirement objectives specified in each source in
spreadsheet-like tabular format.
3) Specify and verify matrices of coupling between requirement objectives to provide
traceability of requirement objectives with the ability to quickly add a new relationship.
4) Provide the ability to import, export, synchronize, and reference text -based requirement
objectives.
Tool features for on-diagram editing, automatic completion of attributes, operations, and
parameter type, pick lists for types and names are used to develop the normative specifications
for records of action that provide traceability to requirement objecti ves.
F.2 REQUIREMENT ELEMENTS

A requirement specifies a capability or condition that must (or should) be satisfied.
Requirements are used to establish a contract between the customer (or other stakeholders)
and those responsible for designing and implement ing the system. A requirement can also
appear on other diagrams to show its relationship to other modelling elements.
When a requirement nests other requirements, all nested requirements apply as part of the
container requirement (the requirement that contains all nested requirements. Deleting the
25 Many commercial tools are available to support RCA. The tool used to develop IEC 62443 -1-3 is MagicDraw® and
the Cameo Systems Modeler™ plugin that are available from No Magic, Inc. For more information about Cameo
Systems Modeler go to http://www.nomagic.com/products/cameo-systems-modeler.html.
26 SysML is the system modeling language. More information about SysML is found in [2] S. Friedenthal, A. Moore,
and R. Steiner, A practical guide to SysML: the systems modeling language : Morgan Kaufmann, 2015. A concise
description of the SysML notation is found in[1] L. Delligatti, SysML distilled: A brief guide to the systems
modeling language : Addison-Wesley, 2013.Model-based system engineering language (MBSE) is used to visualize
complexities introduced by integrating cybersecurity functionality into the functional requirements for industrial
control systems.
79
container requirement will thus delete all the nested requirements it contains; a functionality
inherited from UML. This technical brochure makes use of several requirement subtypes:
Extended requirement: A SysML extended requirement is a standard requirement subtype,

which adds some properties to a requirement element. These properties such as source, risk,
and verify methods are important for requirement management. Specific projects should add
their own properties.
Functional requirement: a functional requirement is a requirement that specifies a behaviour

that a system or part of a system must perform.
Interface requirement: An interface requirement is a requirement that specifies the ports

for connecting systems and parts of a system. Optionally, it may include the items that flow
across the connector and/or the interface constraints.
Performance requirement: A performance requirement is a requirement that quantitatively

measures the extent to which a system or system part satisfy a required capability or condition.
Physical requirement: A physical requirement specifies the physical characteristics and/or

physical constraints of a system, or a system part.
Design constraint: A design constraint is a requirement that specifies a constraint on the

implementation of a system or on part of it.
Business requirement: A business requirement is a requirement that specifies characteristic

of the business process that must be satisfied by the system.
Usability requirement: A usability requirement specifies the fitness for use of a system for
its users and other actors.
F.3 BASIC PRINCIPLES UNDERLYING RCA

F.3.1 Introduction
This technical brochure includes non-technical requirement objectives for security policy,
procedures and organizational directives, and technical requirement objectives for operational
management and control of security mechanisms. Business use case models and workflow
structure of activity diagrams are used to define the scope and to specify features of a ctors,
and flow of events (activity, sequence, communication diagrams) to analyse the evidence
required to show or demonstrate conformance to one or more requirement objective. Such use
cases tend to conflate the requirements derived from non -technical considerations and those
derived for technical control of the security mechanisms.
F.3.2 Non-technical RCA

Business process modelling notation (BPMN) provides a graphical notation that is used to
capture IEC 62443 non-technical requirements. BPMN 2.0 standard has three major parts:
1) Process – shows the business process, events, and messages.

2) Collaboration – describes how the process is implemented between collaborators.
3) Choreography – provides view of the messages/information flow between participants.
The BPMN process diagram shows activities and events/data that trigger or feed business
activities that form the framework for security organizational directives imposed on IACS
operations. These diagrams are similar to UML’s activity diagrams, with a much richer set of
default message types and business style of notation.
80
Collaboration diagrams are like UML’s activity diagrams with swim lanes to segregate
organizational roles and responsibilities 27.
Choreography formalizes the following concepts:
choreography task – A task that defines a set of participants that exchanges messages to
complete a task. These are connected to each other and to events that trigger or are
generated by the task and other BPMN symbols as needed.
multiple participants’ marker – Applied to one or both choreography task participant
identifiers to show there’s a set of participants of the same kind.
sub-choreography – This is a plus symbol annotating the sub-choreography showing that it
contains a refined choreography with several interactions.
expanded sub-choreography – Looks like a big sub-choreography showing detailed
interactions in the diagram’s bounding box. The diagram is a detail of interactions (message
exchange) between participants.
F.3.3 Technical RCA
Unified modelling language (UML) structures form the basic building blocks for technical
requirements coverage analysis. Two model structures are integrated to develop conformance
specifications for technical requirement objectives: 1) capability model and 2) information (data)
model. “Profiles” provide the facility for adding specificity to basic UML concepts. The capability
model is used to define a UML shape as a capability rather than a class. The data model makes
the abstract more tangible, turning concepts from the information m odel into a format that can
be used for analysis. Three diagrams provide the facility for this analysis.
1) Requirements diagram – a diagram specifically used in the system modelling language

(SysML) in which requirements and relations between them and their relationship to other
model elements are shown for derived requirements, namespace containment, and
verification.
a. Containment (sometimes referred to as ‘flow down’) is used to show where
requirement objectives are decomposed into sub -requirement objectives.
b. The «deriveReqt» and «copy» relationships can only exist between requirement
objectives. «trace», «refine», «satisfy» and «verify» can exist between a requirement
objective and any other model element.
c. The «verify» relationship only exist between a req uirement objective and a behavioural
model element stereotyped as a «testCase».
d. An alternative to these direct relationships is to use the callout notation – only one
example of the callout notation is shown here. «problem» and «rationale» comments
can be added as required to any model element to capture issues and decisions.
2) Internal block diagram – block diagrams are like the UML class diagram and composite
structural diagram respectively, but have extensions and omissions.
a. Provides a unifying concept to describe the structure of an element or system
(hardware, software, data, procedure, facility, or person).
b. Multiple compartments can define the block characteristics (properties, operations,
constraints, allocations to the block, and requirements the bloc k satisfies).
3) Parametric diagram – parametric diagrams enable integration of engineering analysis
based on different views of the SuC.
a. Used to express constraints (equations) between value properties (performance,
reliability).
b. Constraint block language can be formal or informal.
27 The description of business modeler diagrams implemented in Cameo™ is provided by No Magic, Inc.
81
c. Parametric diagram represents the usage of the constraints by binding the constraint
usage to the value properties of the block.
F.4 SYSML FRAMEWORK EXTENSIONS
F.4.1 Packages and packable elements
The model used to describe the conformance metrics in this document is derived using SysML
techniques. The model elements contained within a package 28 are called packable elements,
examples of which are blocks, use cases, and activities.
1) In addition to having a place in the containment hierarchy, each model element with a
name (called a named element) must also be a member of a namespace.
2) A namespace enables its members to be uniquely identified within it by name.
3) A package is a namespace for the packable elements it contains.
4) A packable element has a fully qualified name to locate it in the package hierarchy of a
model.
5) Elements contained in one package can be imported into another package by simply
referencing their name within that package.
6) Dependency is a relationship between named elements that can be specialized as need to
reflect specific semantics.
Containment is used to represent how a compound requirement can be partitioned into a set
of simple requirements. For example, the high-level cybersecurity requirements specified in a
package called the "Owner/Operator" package. The industrial control system (ICS) is viewed as
a system-of-systems. For example, consider a power plant (see Figure 1) that requires a safety
instrumented system (SIS) as one system that is part of the IACS.
Corresponding to Figure 1, Figure 14 shows the SysML Owner/Operator system model

comprised of multiple packages, or elements of the system model. The packages coloured blue
are perimeter defense elements containing cybersecurity mechanisms design ed to protect
against attack over the communication network. Specifically, the DMZ, Firewall, and
Unidirectional Gateways import the Cybersecurity package and are contained in the
Communication Network package. Such perimeter protection is needed to ensure secure use of
the communication network for generation dispatch to operate, for vendors to support system
maintenance, and for protection and control system components to interoperate. Usually, but
not always a dedicated communication segment is used betw een the safety system and other
components. In the case of an emergency the safety system depends on the protection and
control system to trigger the appropriate action.
28 Packages are best used to describe the organization of the system model. See chapter 10 in [1] L. Delligatti,
SysML distilled: A brief guide to the systems modeling language : Addison-Wesley, 2013. Also, this technical
brochure follows Delligatti’s recommendation on when to use packages and when to use block definition diagrams
(BDD) – See section 10.8.
82
Figure 14 EPU generating station system model
F.4.2 Stereotypes to customize SysML notation

A stereotype defines a new kind of element by customizing an existing model element. This
customization may be implemented by adding properties, constraints or semantics. To gain a
deeper understanding of stereotype development, see (2). As shown in clause 0, stereotypes
are indicated by enclosing the name of the stereotype within a set of double c hevrons; e.g.
<<testCase>>. The more advanced tools, such as the Cameo tools by No Magic, contain a rich
set of predefined model elements that can be used to develop customized stereotypes.
F.4.3 Moving on to block definition diagrams

The most common kind of SysML diagram to build out the system model is the block definition
diagram (BDD). The model elements include blocks, actors, value types constraint blocks, flow
specifications, and interfaces. These elements are then used on other kinds of SysML diagra ms.
Elements defined in BDDs are elements of definition . The structural relationship between
these elements of definition, associations, generalizations, and dependencies, are extremely
important.
One could easily argue that EPU analysts should examine the system model (see 0) and use
the BDD tools to develop a workable model of their domain of interest. Delligatti (1) and others
(2) strongly recommend this as the first step to effectively visualizing the relationship between
system components, and by extension in this technical brochure the seamless integration of
cybersecurity controls and their management systems.
A few clarifications are in order.
1) There is a distinction between definition and instantiation. Some elements (e.g. blocks,
value types, constraint blocks) represent definitions of types; other elements (e.g. part
properties, value properties, constraint properties) represent instances of those types.
Thus, a block represents a type of entity, not an instance. For example, a block named
Workstation represents a type that defines a set of properties that are common to all
instances. Each workstation EPU deploys is a distinct instance of that Workstation block.
2) Features come in two varieties: structural features (also known as properties) and
behavioural features.
83
84
ANNEX G. CLOUD COMPUTING SECURITY CHALLENGES

G.1 TAILORING GUIDELINES
This technical brochure tailors the NIST descriptions (21) to reflect the context of EPU
operations and related business functions. Care was taken to ensure that these modifications
are commensurate with common, well-defined, security policies, procedures and organizational
directives.
G.1.1 Five essential characteristics of cloud computing

NIST defined five essential characteristics of the cloud model.
1) On-demand self-service.
EPU organizations can unilaterally provision computing capabiliti es such as server time and
network storage, as needed to automatically update the information without requiring human
interaction with each service provider. The underlying assumption is that each EPU organization
may be free to select a cloud computing service provider that best serves their requirements
and constraints.
2) Broad network access.

Capabilities are available over the network and accessed through standard mechanisms that
promote use by heterogeneous thin or thick client platforms (e.g. mobile pho nes, tablets,
laptops, and workstations). The ability for an EPU organization to use approved heterogeneous
platforms provides the capability for technicians to seamlessly perform tasks by remote access
or onsite access to substation and field intelligent electronic devices.
3) Resource pooling.
The cloud provider’s computing resources are pooled to serve multiple EPU consumers using a
multi-tenant model, with different physical and virtual resources dynamically assigned and
reassigned per consumer demand. Examples of resources include storage, processing, memory,
and network bandwidth. For example, access to historical records, topology configurations, and
settings data provides the information needed to reconfigure a protection scheme.
4) Rapid elasticity.
Capabilities can be elastically provisioned and released, in some cases automatically, to scale
rapidly outward and inward commensurate with demand.
5) Measured service.
Resource usage can be monitored, controlled, and reported, providing transparency for both
the provider and consumer of the utilized service. Such transparency satisfies a basic security
requirement to actively monitor all activity to identify anomalous behaviour.
G.1.2 Service models

NIST defined three service models for cloud computing.
1) Software as a service (SaaS)

An EPU organization can use the cloud computing applications running on a cloud infrastructure.
The applications are accessible from various client devices through either a thin client interface,
such as a web browser (e.g. web-based email), or a program interface. The EPU organization
does not manage or control the underlying cloud infrastructure including network, servers,
operating systems, storage, or even individual application capabilities, except for limited user -
specific application configuration settings.
2) Platform as a service (PAAS)

An EPU organization can deploy onto the cloud infrastructure their created or acquired
applications using programming languages, libraries, services, and tools supported by the EPU’s
85
supplier. The EPU organization does not manage or control the underlying cloud infrastructure
including network, servers, operating systems, or storage, but has control over the deployed
applications and possibly configuration settings for the application -hosting environment.
3) Infrastructure as a service (IAAS)

An EPU organization can provision processing, storage, networks, and other fundamental
computing resources where they are able to deploy and run arbitrary software, which can
include operating systems and applications. The EPU does not manage or control the underlying
cloud infrastructure but has control over operating systems, storage, and deployed applications;
and possibly limited control of selected networking components (e.g. host firewalls).
G.1.3 Deployment models

NIST defined four deployment models for cloud computi ng.
1) Private cloud
Private cloud infrastructures are provisioned for exclusive use by a single EPU organization
comprising multiple departmental units within the organization. It may be owned, managed,
and operated by the EPU host organization, a third part y, or some combination of them, and it
may exist on or off the premises.
2) Community cloud
Community cloud infrastructures are provisioned for exclusive use by a specific community of
EPU organizations that have shared concerns (e.g. mission, security requir ements, policy, and
compliance considerations). It may be owned, managed, and operated by one or more of the
organizations in the community, a third party, or some combination of them, and it may exist
on or off the premises.
3) Public cloud
Public cloud infrastructures are provisioned for open use by the public. They may be owned,
managed, and operated by a business, academic, or government organization, or some
combination of them. It exists on the premise of the cloud provider.
4) Hybrid cloud
Hybrid cloud infrastructures are composed of two or more distinct cloud infrastructures (private,
community, or public) that remain unique entities, but are bound together by standardized or
proprietary technology that enables data and application portability (e.g. cloud bursting for
load balancing between clouds).
G.1.4 Recommendations to evaluate a cloud access security broker

G.1.4.1 CASB overview and EPU challenges
Using the Gartner framework (51), this technical brochure offers a recommendation to evaluate
a cloud access security broker (CASB). Gartner’s framework is modified to focus attention on
EPU security requirements. CASBs provide the EPU security team a control point for cloud
service visibility, security, and compliance. This technical br ochure recommends that EPUs use
their customization of this framework to support continuous cloud service discovery, adaptive
access, verification, protection and prioritization of CASB evaluation criteria.
To adapt the framework, EPUs need to address seve ral challenges:
1) Develop the expertise (in-house or purchased service) to understand the cloud services
they consume and the risks they represent, which makes compliance to local laws and
regulations difficult.
2) Develop a process supported by security policies, procedures, and organizational
directives to consistently verify compliance or the secure handling of sensitive data within and
across these disparate services.
86
3) Implement a standardized way to detect whether (and when) compromised credentials or

unmanaged devices are used to access cloud services.\
4) Implement a well-defined combination of access-centric and threat-centric (based on
consequence assessment) capabilities.
G.1.4.2 Analysis to understand the risks
To understand the risks represented using cloud services, EPU organizations need visibility into
what cloud services are already in use, by which people, the sensitivity of data being handled,
which operational devices are used to access that data, and from where it is accessed.
To manage risk, each organization with membership in the EPU security team, needs to plan
for adaptive access. For example, restricting access based on the location, time of day or
whether the device is EPU managed. For this reason, it is important that CASB providers either
provide identity services, or they can link to the EPU’s identity repositories for the application
of policy.
When applicable, EPUs should use a CASB solution that support the optional encryption and/or
tokenization of data (at the field- or the file-content/object level) to comply with local laws and
regulations. Implemented properly, data protection using encryption/tokenization can be a
powerful way to protect sensitive data in the cloud. It can also prevent the cloud service
provider from seeing it. However, when implemented as an in-line proxy, this may
create a single point of failure for the cloud service being accessed . Because of this
issue, external cloud data protection should only be considered when it is demanded by
regulatory requirements. When this approach is used:
1) The EPU security team should acknowledge and design for the limitations of encryption or
tokenization performed outside the cloud service provider.
2) Don’t encrypt all SaaS data; choose only specific individual fields or files that requir ed to
be tokenized or encrypted.
Risk mitigation requires the EPU security team to continuously verify secure and compliant
usage of cloud services. The team should investigate and respond to exceptions using such
tools as security information and event ma nagement (SIEM).
G.2 AN OVERVIEW OF EPU SECURITY ISSUES FOR CLOUD COMPUTING

G.2.1 Introduction to risk issues
Although cloud computing is a flexible, cost -effective, and proven delivery platform for EPUs,
it represents an added level of risk because essential services are often outsourced to a third
party, which make it harder to maintain data security and privacy, support data and service
availability, and demonstrate compliance with local laws and regulations (51). Specifically, there
is a great deal of uncertainty about how all security at all levels (e.g. network, host, application,
and data levels) can be achieved and how applications security is moved to cloud computing
(52).
For these reasons, moving critical EPU applications and sensitive data to public cloud
environments must be addressed. As a minimum, a cloud solution provider must ensure that
EPU organizational units using these services will continue to have the same security and
privacy controls over their applications and services, provide evidence to demonstrate their
organization are secure and they can meet their service -level agreements, and that they can
proved compliance to auditors.
G.2.2 Summary of systematic review of security issues for cloud computing

Hashizume and his colleagues performed a systematic review of security issues for cloud
computing (51). The results, summarized in their paper, shows most of the approaches classify,
analyse, and list many vulnerabilities and threats applicable to EPU operations.
1) With SaaS, the burden of security lies with the cloud provider.
87
2) By contrast, with the PaaS model, a greater extensibility and EPU control is available.
3) IaaS offers even greater EPU control over security than do PaaS or SaaS.
The challenge EPU’s face is if the security maturity of their organizational units is sufficient to
manage the increased security complexities introduced by the PaaS and IaaS models. If they
lack the necessary security maturity, they may either defer using cloud-computing services or
place their trust in a SaaS cloud provider.
G.2.3 EPU’s need to understand the relationships and dependencies between cloud
service models
The Cloud Security Alliance described the relationships and dependencies between cloud service
models (53). It is important for EPUs to understand these relationships and dependencies
before deciding how best to use cloud computing services. PaaS as well as SaaS are hosted on
top of IaaS; thus, any breach in IaaS will impact the security in both PaaS and SaaS services,
but also it may be true on the other way around.
EPUs decision makers should consider that PaaS offers a platform to build and deploy SaaS
applications, which increases the security dependency between them. Because of these deep
dependencies, any attack to any cloud service layer can compromise the upper layers 29.
G.2.4 Vulnerabilities in cloud computing

This technical brochure tailored the list of cloud computing vulner abilities developed in (51) to
focus on EPU operator requirements to manage the threats to their critical infrastructure. Their
first challenge is to establish a baseline of how cloud computing influences established security
policies, procedures and organizational directives. A key factor here is security vulnerabilities:
cloud computing makes certain well-understood vulnerabilities more significant as well as adds
new ones to the mix.
Table G- 1 provides an initial check list for EPU analysis. The last column identifies the cloud
service model layer exposed to these threats; e.g., SPI is all three layers (SaaS, PaaS, and IaaS)
and I is IAAS. The authors of (51) concluded that data storage and virtualization are the most
critical and an attack on them can do the most harm.
Table G- 1 Vulnerabilities in cloud computing
ID Vulnerabilities Description Layer
V01 Insecure interfaces Cloud providers offer services that can be accessed through APIs SPI
and APIs (SOAP, REST, or HTTP with XML.HSON). The security of the cloud
depends upon the security of these interfaces. Some problems are:
a) Weak credential
b) Insufficient authorization checks
c) Insufficient input-data validation
V02 Unlimited allocation of Inaccurate modelling of resource usage can lead to overbooking or SPI
resources over-provisioning.
V03 Data related a) Data can be collocated with the data of unknown owners with we ak SPI
vulnerabilities separation.
b) Data may be in different jurisdictions which have different local
laws and regulations.
c) Incomplete data deletion – data cannot be completely removed.
d) Data backup done by untrusted third-party providers
e) Information about location of data usually is unavailable or not
disclosed to the responsible EPU organization.
f) Data is often stored, processed and transferred in plain text.
29 For a more in-depth understanding of these relationships, see[51] K. Hashizume, D. G. Rosado, E. Fernández -
Medina, and E. B. Fernandez, "An analysis of security issues for cloud computing," Journal of Internet Services
and Applications, vol. 4, pp. 1-13, 2013.
88
ID Vulnerabilities Description Layer
V04 Vulnerabilities in a) Possible covert channels in the colocation of VMs. I

virtual machines b) Un restricted allocation and deallocation of resources with VMs.
(VMs)
c) Uncontrolled migration – VMs can be migrated from one server to
another server due to fault tolerance, load balance, or hardware
maintenance.
d) Uncontrolled snapshots – VMs can be copied in order to provide
flexibility, which may lead to data leakage.
e) Uncontrolled rollback could lead to reset vulnerabilities – VMs can
be backed up to a previous state for restoration, but patches
applied after the previous state disappear.
f) VMs have IP addresses that are visible to anyone within the cloud –
attackers can map where the target VM is located within the cloud.
V05 Vulnerabilities within a) Uncontrolled placement of VM images in public repositories. I

VM images b) VM images are not able to be patched since they are dormant
artefacts.
V06 Vulnerabilities in a) Complex hypervisor code. I

hypervisors b) Flexible configuration of VMs or hypervisors to meet EPU
organization needs can be exploited.
V07 Vulnerabilities in Sharing of virtual bridges by several virtual machines. I
virtual networks
G.2.5 Threats in cloud computing

Continuing with the analysis of the security issues, the threats in cloud computing are tailored
to focus on EPU operations. Table G- 2 provides the threat data for EPU analysis. Again, the
emphasis is placed on threats that are associated with data being stored and remotely
processed, sharing resources, and the usage of virt ualization.
Table G- 2 Threats in cloud computing
ID Threats Description Layer
T01 Account or service An account theft can be performed by diverse ways such as social SPI
hijacking engineering and weak credentials. If an attacker ga ins access to a user’s
credentials, they can access sensitive data, manipulate data, and
redirect any transaction.
T02 Data scavenging Since data cannot be completely removed unless the device is destroyed, SPI
attackers may be able to recover this data.
T03 Data leakage Data leakage happens when the data is retrieved by an entity (person SPI
or device) not authorized to receive that data. Data leakage may occur
when data is being transferred (data in transit) or when data is stored
(data at rest). Data leakage may occur when data is audited or
processed.
T04 Denial of service Denial of service happens when an attacker takes control of all available SPI
resources. Thus, the system cannot satisfy any request from other
legitimate EPU users due to resources being unavailable.
T05 EPU data A web cloud application falls into two parts: an application component S
manipulation operated somewhere in the cloud, and a browser component running
within the EPU user organization. Web applications are attacked by
manipulating data sent from the cloud-based application component to
the server’s application. For example, metering and billing data
manipulation and billing evasion are high-priority targets.
T06 VM escape The object of this threat is to exploit the hypervisor to take control of I
the underlying infrastructure
T07 VM hopping When a VM can gain access to another VM by exploiting some hypervisor I
vulnerability, which allows remote attacks and malware to compromise
the VM’s separation and protections, making it possible for an attacker
to gain access to the host computer, the hypervisor and other VMs, in
addition to being able to jump from one VM to another.
89
ID Threats Description Layer
T08 Malicious VM An attacker who creates a valid account can create a VM image I
creation containing malicious code such as a Trojan horse and store it in the
cloud provider’s repository.
T09 Insecure VM Live migration of virtual machines exposes the contents of the VM state I
migration files to the network. Given this exposure, an attacker can:
a) Access data illegally during migration,
b) Transfer a VM to an untrusted host, and
c) Create and migrate several VM causing disruptions or denial of
service.
T10 Sniffing/spoofing A malicious VM can listen to the virtual network or even use add ress I
virtual networks registration protocol spoofing to redirect packets from/to other VMs.
G.2.6 Relationship between threats, vulnerabilities and countermeasures

For the EPU to complete the analysis the relationship between the threats and vulnerabilities is
needed to identify the appropriate countermeasures. One approach that an EPU analyst can
use is described in Table G- 3.
Table G- 3 Relationships between threats, vulnerabilities and countermeasures
Threat Vulnerabilities Incidents Countermeasures
T01 V01 An attacker can use a Identity and access management guidance
stolen account to get including dynamic credentials and ABAC/RBAC
access to the target’s management.
resources NOTE Dynamic credential changes its value once
an EPU user changes its location or when a
certain number of data packets have been
exchanged.
T02 V03a, V03c Data from shared cloud- Specify destruction strategies on service-level
based hard drives cannot agreements.
be completely removed.
T03 V03a, V03c, V03d, Coherent data is Known as fragmentation-redundancy-scattering,

v03f, V04a-f, V05, captured while it is being this technique first breaks down sensitive data
V07 transferred, stored, into insignificant fragments, so any fragment does
audited or processed. not have a significant information itself. Then the
fragments are scattered in a redundant fashion
across different sites the distributed system.
Encryption can be used to secure data while it is
being transferred in and out of the cloud or stored
in cloud repositories.
T04 V01, V02 Attacker requests more Cloud providers can force policies to offer limited
computational resources, computational resources.
so other legal EPU users
are not able to get
additional capacity.
T05 V01 Tricking an application Web application scanners.

into including unintended NOTE see (54) for an expanded discussion of
commands in the data possible incidents and countermeasures.
set to an interpreter.
T06 V06a, V06b Zero-day exploit in the TCCP trusted cloud computing centre and trusted
hyperVM virtualization virtual data centre. TCCP adds a trusted virtual
application. machine monitor and a trusted coordinator. A
trusted virtual data centre insures isolation and
integrity in cloud environments.
NOTE see (55) (56) for an expanded discussion
of possible incidents and countermeasures.
T07 V04b, V06b Security flaws in most Future research is needed to develop an effective
virtual machine monitors. countermeasure.
NOTE see (57) for an expanded discussion of
possible incidents and countermeasures.
90
Threat Vulnerabilities Incidents Countermeasures
T08 V05a, V05b An attacker can create a One countermeasure approach is to include the
VM image containing following security features: access control
malware and publish it in framework, image filters, a provenance tracking,
a public repository. and repository maintenance services.
NOTE 1 filters may not be able to scan all
malware or remove all sensitive data from the
images.
NOTE 2 running these filters may raise privacy
concerns because they have access to the content
of the images which can contain EPU’s
confidential data.
T09 V04d Attacks against VMware Use a secure migration framework that preserves
virtualization products. integrity and privacy during and after migration.
NOTE assess the impact of added downtime and
migration time due to encryption and decryption.
T10 V07 Attackers sniff and spoof Implement a virtual network model composed of
virtual networks. three layers: routing layers, firewall, and shared
networks, which can prevent VMs from sniffing
and spoofing.
NOTE see (58) for and expanded discussion of
incidents and countermeasures.
G.3 POTENTIAL EPU USE OF CLOUD COMPUTING

G.3.1 Introduction to potential EPU use of cloud computing
A recent survey of 100 North American electric, water and gas utility executives completed by
Zpryme and Oracle Utilities shows that utilities are embracing the cloud (59). This report shows
that 45% are currently using the cloud in some form and another 52% are planning to use the
cloud. Nearly 97% indicated they have become involved with cloud technologies, or applications
and computing resources delivered as services over a network connection instead of th rough
in-house resources at the utility. Reference (59) describes the reasons behind why utilities are
already investing in the cloud, challenges they had to overcome, and recommendations for
building out cloud strategies.
Utilities are finding a variety of business areas and applications that are strong candidates for
cloud technologies:
1) A need for low-cost solutions

2) A need for customization
3) Lack of internal expertise
4) Changing business models
Many of the technologies that utilities are currently taking to the cloud revolve around smart
grid efforts and next generation technologies; e.g. meter data management (MDM), big data
analytics, and distribution automation and network management. Nearly 90% of the
respondents to the survey indicated that they are using or plan to use the cloud for MDM within
the next three years.
Respondents to the survey identified their top concerns on the way to using the cloud.
Beginning with the highest concern, the top five are:
1) Privacy (privacy is limit of usage vs. confidentiality which is limit of access)

2) Control
3) Security
4) System integration
5) Cost
91
G.3.2 Potential P&C use of cloud computing

G.3.3 Potential applications for energy management (61)
Table G- 4 shows some uses of cloud computing to support energy management functions.
Table G- 4 Potential applications for energy management
Potential Energy Recommended Issues to be Recommended Reference

Management Use Deployment Model addressed service model for
details
Demand response for fast Data-centric communication Develop a demand SaaS & PaaS (62)
response times in large model, or a topic-based group response model that
scale deployment; known as communications model will facilitate both large
cloud-based demand and small-scale
response (CDR) networks.
Peak demand and dynamic Incoming jobs are scheduled to Unknown SaaS & PaaS (63)
pricing be executed according to the
available resources, job priority,
and other applicable
constraints using cloud
applications
Micro-grid management Infrastructure and power Unknown IaaS, SaaS & PaaS (64)
management modules are used
for task scheduling and micro-
grid power management,
respectively.
Real-time monitoring Rapidly integrate and analyse Requires an effective IaaS, PaaS & SaaS (65)
information streaming from privacy policy,
multiple smart meters procedures, and
simultaneously, in order to organizational
balance the real-time demand directives.
and supply curves
Power monitoring and early Perform resource Requires a proactive SaaS (66)
warning system management, task cloud energy
management, and security management method
management using SaaS that will give an early
applications. warning system to the
micro-grids
Information interaction using In a heterogenous power Unknown SaaS (67)

mobile agent system environment, use data
mobile agent (DMA) and state
mobile agent (SMA) to fulfil
user requests for storage
capacity and stronger
processing capability.
Dynamic demand response Perform intelligent demand- Unknown SaaS (68)

side management to relieve
peak-load.
G.3.4 Potential Smart Grid use of cloud computing

G.3.4.1 Smart Grid motivation for using cloud computing services
Smart Grid requirements for energy management, information management, and security are
currently the prime candidates for using cloud computing services (60). Smart metering is a
good example of the potential benefits that can be gained from using cl oud computing services.
92
G.3.4.2 Leveraging the cloud-based services for data protection

EPUs must address a wide-range of functional, cybersecurity, and business requirements to
ensure that their systems of systems (SoS) complies with local laws and regul ations, and with
well-defined company policies, procedures, and organizational directives. EPU management
recognizes that these requirements are owned by diverse stakeholders and exist at different
levels, for different systems, and in different artefacts. They often overlap, cross-cut, or even
conflict, and allocating them to specific systems or components is not always possible (61).
Thus, EPU engineers and technicians must monitor if and how the SoS meets its requirements
at runtime (62). For the most part IEDs and communication network devices provide the
information to verify components’ correct timing or measure performance and resource
consumption. These devices can provide data that can be use d to test for requirements
compliance (63). Collecting and interpreting these data is vital, and thus requires cybersecurity
mechanisms to protect the data. One approach is to leverage the cloud computing resources
to ensure the data is adequately protected and available to all who need it.
Too many external cybersecurity threats are beyond the EPU’s control. Nevertheless, EPU
stakeholders must have the means to visualize and explain requirement violations to facilitate
diagnosis and provide timely corrective action. In most cases this requires the ability to support
cross-system and cross-technology instrumentation and analysis of event data. If these data
are securely stored in cloud computing repositories, they can be downloa ded and replayed
using existing simulators to re-enact what happened. Multiple stakeholders and support
contractors (particularly those who are not co -located) have a crucial role in this analysis, and
a secure means must be provided to facilitate their co llaboration.
One critical capability is the need for identity and access management as a service (IDaaS). In
September 2016, Gartner published a list of commercially available products that provide these
capabilities (64). They evaluated 18 solution providers using 11 critical capabilities and three
common use cases: workforce to service SaaS, business -to-consumer, and tradition/legacy
workforce. Simulators used for playback must be configured for specific applications. Therefor e,
the solution provider must provide dedicated support for on -premise applications. On-premise
applications are installed and run on computers on the premises (in the building) of the person
or organization using the software, rather than at a remote faci lity.
Hybrid cloud architecture scenarios arise when an EPU decides for cost, security, and other
reasons to keep some portion of its operations physically housed on site, while making use of
resources provide outside of the organization for other features (65). Thus, for most EPU
operations, (e.g., simulators for replay) the solution must support a cyber -secure hybrid cloud-
based architecture.
G3.5 Potential use of cloud computing

In the future, blockchain is the new cloud opt ion. is a distributed database that maintains a
continuously-growing list of records, called “blocks.” Each block contains a timestamp and a
link to a previous block. The data in a block cannot be altered retrospectively. Blockchains are
an example of a distributed computing system with high byzantine fault tolerance.
One example use case is the Brooklyn (US) microgrid project, where the neighbours use the
ethereum 30 version of blockchain to sign smart contract and trade solar energy directly among
them to increase the resiliency and efficiency of the grid. In their model end users interact
directly with the grid and calculations are allocated across all participating member devices.
30 Ethereum is a public blockchain-based distributed computing platform, featuring smart contract functionality. It
provides a decentralized virtual machine, the Ethereum Virtual Machine (EVM), that can execute peer-to-peer
contracts using a cryptocurrency called ether.
93
This is an incentive-based approach based on market values of energy 31. With the transposition
of transactive energy concepts in the energy market, interaction of the operational technology
components in the energy grid will have to interact through cloud -based services.
G.4 RECOMMENDED SECURITY GUIDELINES FOR EPU USE OF CLOUD COMPUTING

G.4.1 Common security recommendations
Persistent protection of data by encryption, throughout the data lifetime, is the ideal objective.
Practical limitations involving less capable devices and legacy systems will enter here as
restraints to the objective. However, encryption of the data itself, independent of the protocol
involved, at point of origination, makes the secure use of any available transmission or storage
mechanism plausible and practical using IETF RFC 5652 or ANSI X9.73 both entit led
Cryptographic Message Syntax.
G.4.2 Security recommendation for the use of deployment models

The interest in Software Defined Networking and Network Function Virtualization (SDN/NFV)
and cloud computing is well underway within IEEE and CIGRE. Currentl y IEEE has 4 working
groups developing standards. EPRI is closely tracking these activities with active participation
and will provide detailed reports in the future.
1) Within the IEEE Communication Society:

a. IEEE P1915.1 “Standard for SDN and NFV security.”
b. IEEE P1916.1 “Standard for SDN and NFV performance.”
c. IEEE P1917.1 “Standard for SDN and NFV reliability.”
2) Within the IEEE Computer Society:
a. IEEE P2303 “Standard for adaptive management of cloud computing environments.”
3) Within the IEEE Power Engineering Society:
a. The new technical committee on communications and cybersecurity has a approved a
Task Force (P11) to write a report on “Transition strategy to leverage cloud -based
services.”
4) Within CIGRE:
a. Study Committee D2 (telecommunications and security) will st art a new working group
D2.43 in 2017 “Enabling software defined networking for EPU telecom applications.”
b. Study Committee B5 (protection and control) will start a new working group B5.60 in
2017 “Protection and control architectures with functionality in dependent of
hardware.”
G.4.3 Security recommendations for the use of service models
The Georgia Institute of technology addressed a security policy transition framework for
software defined networks (66). The primary motivation for this work is to reduce network
operator involvement with repeated network reconfigurations. Although the approach is focused
on software defined networking (SDN) architectures, including network function virtualization
(NFV), it can be applied to non-SDN architectures.
The basic idea is that Client violates an access control security policy, which requires that
access control privileges should be denied. When the issue is resolved, the access control
privileges need to be reinstated. Automation of th e process to detect, deny access, and
reinstate access is the objective. A high-level overview of the framework and access control
process is shown in Figure 15.
31 See www,gridwiseac.org/pdfs/te framework report pnni -22946.pdf.
94
Figure 15 - Security policy framework (66)
95

698 - Web

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

698 - Web

Uploaded by

Copyright:

Available Formats

FRAMEWORK FOR EPU OPERATORS

I. PATRIOTA DE SIQUEIRA BR E. OHBA JP

Disclaimer notice ISBN : 978-2-85873-401-6

In the paper “Intelligence-Driven Computer Network Defense Informed by Analysis of Adversary

SUMMARY OF FINDINGS AND RECOMMENDATIONS

Table 1 Advantages and disadvantages of application whitelisting

3. SUMMARY OF FINDINGS AND RECOMMENDATIONS ......................................................... 27

4. TOOL SET REQUIREMENTS .......................................................................................................... 31

5. PLUG AND PLAY TOOLS SETS ................................................................................................... 35

6. PATCH MANAGEMENT APPLICATION ...................................................................................... 37

7. ICS-CERT RESPONSE APPLICATION .......................................................................................... 39

ANNEX A. DEFINITIONS, ABREVIATIONS AND SYMBOLS ............................................................... 51

ANNEX B. SURVEY OF CYBER THREAT READINESS........................................................................ 59

ANNEX C. SYSTEM DYNAMICS MODEL OF AN INSIDER ATTACK .............................................. 67

C.6 SYSTEM DYNAMICS VIEW OF SECURITY LEVEL REDUCTION ...................................................................................... 69

ANNEX D. FIREWALL VULNERABILITIES ............................................................................................. 71

ANNEX E. CHECKLIST OF MEASURES TO HELP MITIGATE CYBER-ATTACKS ON EPU

ANNEX F. REQUIREMENTS COVERAGE ANALYSIS ........................................................................ 79

ANNEX G. CLOUD COMPUTING SECURITY CHALLENGES ....................................................... 85

Table G- 1 Vulnerabilities in cloud computing ...................................................................................... 88

2.2 CRITICAL INFRASTRUCTURE DEPENDS ON THE USER AND SITUATION

1) The level of automatization of the EPU’s dispatching;

2.2.3 OECD’s characterization of criticality

2.2.4.1 Cybersecurity classes for industrial control systems

When imperatively justified by operational requirements, remote maintenance and remote

2.3 STRONG PERIMETER DEFENSE SOLUTIONS

Vendor ICCP EPU

Figure 1 Unidirectional reference architecture

Reprinted with permission by Waterfall Security Solutions Ltd.

2.3.2 Advanced persistent threats on perimeter defense

1) Penetrate firewalls by spear-phishing,

1) Protection is not provided against low networks 7.

2.3.4 Protection against high networks

2.3.5 TCP/IP protocols

2.3.6 Clarification of 2.3.3 item 3)

2.4 FOCUS ON THE INSIDER THREAT

2.4.2 High-level SysML collaboration model

8 A summary of the SysML methodology and notation is described in APPENDIX F.

Figure 3 Threat collaboration model

2.4.3 Threat collaboration

2.4.4 Log action and security manager 24/7 data exploitation

1) A report is generated describing the event and supporting data,

2.5 THE NEED TO ENFORCE SECURITY ROBUSTNESS

2.5.2 Perimeter defense enables security robustness

2.6 THE NEED FOR PLUG AND PLAY

2.7 NOTIONAL EPU CRITICAL INFRASTRUCTURE ARCHITECTURES

1) Organizational aspects – i.e. the “human and organizational architecture” surrounding an

2.8 CLOUD COMPUTING IS AN EVOLVING PARADIGM

2.8.2 Shared responsibility and accountability

11 Australian Signals Directore, www.asd.gov.au/infosec/mitigationstrategies.htm

3. SUMMARY OF FINDINGS AND RECOMMENDATIONS

3.2 RECOMMENDATIONS TO MANAGE RESPONSES TO CYBER-ATTACKS

3.3 RECOMMENDATIONS TO STRENGTHEN PERIMETER DEFENSE

3.4 COMMERCIAL PLUG AND PLAY TOOLS

4. TOOL SET REQUIREMENTS

4.2 IT PERIMETER PROTECTION SUITE

4.2.2 Protect EPU enabled applications

Table 4-1 Advantages and disadvantages of application whitelisting

Figure 4 shows an example of Application Whitelisting using Microsoft AppLocker which is a

Figure 4 Example Whitelisting Actions by Windows AppLocker Integrated int o a

5. PLUG AND PLAY TOOLS SETS

5.2 COMMERCIAL/OPEN SOURCED TOOLS