FRAMEWORK FOR EPU OPERATORS TO MANAGE THE RESPONSE TO A CYBER-INITIATED THREAT TO THEIR CRITICAL INFRASTRUCTURE

698
FRAMEWORK FOR EPU OPERATORS
TO MANAGE THE RESPONSE
TO A CYBER-INITIATED THREAT
TO THEIR CRITICAL INFRASTRUCTURE
WORKING GROUP
D2.38
SEPTEMBER 2017

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
WG D2.38
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
“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
ISBN : 978-2-85873-401-6

FRAMEWORK FOR EPU OPERATORS TO MANAGE THE RESPONSE TO A CYBER-INITIATED THREAT TO THEIR CRITICAL INFRASTRUCTURE
3
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 Framework1” October 29, 2013. NIST’s framework is comprised 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 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 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 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), 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, should 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.

4
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 technical 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 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 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 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.
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. Following 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 actions 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

5
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 tuning 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 the next-generation firewall includes the
following enablement requirements2.
2 Contributions from Palo Alto Networks (www.paloaltonetorks.com) were used to develop the tool suite for perimeter
defense.

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

7
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 action 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
applications
Requires additional time and manpower to maintain.
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.

8

9
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

10
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

11
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

12
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

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

14
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 Framework4” October 29, 2013 (3). NIST’s framework is comprised 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 (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 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 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 for 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.

15
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 systems, 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, financial 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, transport, 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,

16
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 considerations. 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 such 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

17
some countries (9). This paper reviews the role of investment policies in broader national
strategies for protecting critical infrastructure. The key 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 undermine 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 mitigating 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 investment 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 policies 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 coordinate 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.

18
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 cybersecurity 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 implementation 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 systems. 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 Systems," ed: CRITIS, 2012.

19
Generation
Dispatch
Internet /
Telecomms Backbone
Generating Unit
Control Network
EPU
OT Network
Safety
Sytems
Protective
Relays
Vendor
DMZ
EPU
IT Network
ICCP
DMZ
Corporate Firewall
Vendor
ADC
VPN SvrVPN Svr
FirewallFirewall
VPNVPN
Remote
Access
VPN
Attack!
Unit Firewall
Unidirectional Gateway
Protection Layer
Unidirectional Gateway
Protection Layer
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 perimeter defense systems need to be
addressed by improving the perimeter defense mechanisms6. 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.

20
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 networks7.
2) Data diodes do not work with TCP/IP protocols.
3) In the situations when command in the process are necessary, Data diodes 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 oriented 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 gateway 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.

21
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 network, 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 requests 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 unidirectional 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 makes 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
commercial off-the-shelf security protection mechanisms that
could be effective. 0 offers a checklist of mechanisms to help EPUs
to mitigate APT consequences.
Figure 2 Trusted on-site
technician

22
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 required 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 framework8. 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 (denoted 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 coordinated.
8 A summary of the SysML methodology and notation is described in APPENDIX F.

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

24
changes their value. The system operator monitors the changes and accepts the changed set point
values9.
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 downtime 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 robustness. 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 “Enforcing 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 EPU 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.

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

26
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 segmentation 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 Mitigation
Strategies11, US ICS-CERT 7 Strategies to Defend ICS12 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 taxonomy 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 the 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 services. 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

27
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 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 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 operations. 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 IED initiated actions should be well
documented and be up-to-date.

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

29
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 servers 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
of the security information and event management (SIEM) and analysis tools, in “hunger
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.

30

31
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 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.
4.2 IT PERIMETER PROTECTION SUITE
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 the next-generation firewall includes the
following enablement requirements15.
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 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.

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

FRAMEWORK FOR EPU OPERATORS TO MANAGE THE RESPONSE TO A CYBER-INITIATED THREAT TO THEIR CRITICAL INFRASTRUCTURE

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Similar to FRAMEWORK FOR EPU OPERATORS TO MANAGE THE RESPONSE TO A CYBER-INITIATED THREAT TO THEIR CRITICAL INFRASTRUCTURE

Similar to FRAMEWORK FOR EPU OPERATORS TO MANAGE THE RESPONSE TO A CYBER-INITIATED THREAT TO THEIR CRITICAL INFRASTRUCTURE (20)

More from Power System Operation

More from Power System Operation (20)

Recently uploaded

Recently uploaded (20)

FRAMEWORK FOR EPU OPERATORS TO MANAGE THE RESPONSE TO A CYBER-INITIATED THREAT TO THEIR CRITICAL INFRASTRUCTURE