615

Security architecture principles for digital

systems in Electric Power Utilities

Working Group
D2.31

April 2015
 Security architecture principles for digital
systems in Electric Power Utilities

Working Group
D2.31

April 2015
Members

1
Jens Zerbst (Convener), Ludovic Piètre-Cambacédès (Convener ), Mathias Ekstedt (Secretary),
Giovanna Dondossola, Christophe Poirier, Pascal Sitbon, Åge Torkilseng, Dennis Holstein, John
McDonald, Robert Evans, Marc Tritschler, Simon Zimmermann, Iiro Rinta-Jouppi, Göran Ericsson,
Marc Scherer, Feven Zegai, Olivier Breton

In memory to Tor Aalborg

—————————

Copyright © 2015

“Ownership of a CIGRE publication, whether in paper form or on electronic support only infers right
of use for personal purposes. Are prohibited, except if explicitly agreed by CIGRE, total or partial
reproduction of the publication for use other than personal and transfer to a third party; hence circu-
lation on any intranet or other company network is forbidden”.

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

ISBN: 978-2-85873-317-0

1
from 2010-2012
 TABLE OF CONTENT
1 Introduction .................................................................................................................................. 4
1.1 Risk of digital systems ............................................................................................................... 5
1.1.1 Change of technology ................................................................................................... 5
1.1.2 Increased connectivity .................................................................................................. 5
1.1.3 Increase of threats ........................................................................................................ 6
1.2 Current assistance available to EPUs ........................................................................................ 7
1.2.1 Current development in standardization ........................................................................ 8
1.2.2 Governance and organizational initiatives ..................................................................... 8
1.2.3 Cigré’s role ................................................................................................................... 9
2 Working Group D2.31 ................................................................................................................. 10
3 Summary of findings and recommendations of Working Group D2.31 ........................................... 11
4 Work stream 1: Classification methods for security zone/level definition (graded approach) ......... 12
4.1 Graded approach for EPUs: Clarifying the security levels and zones concepts .......................... 13
4.1.1 Terms and definitions ................................................................................................. 13
4.1.2 Standards and Best Practices of graded security approaches (as per beginning
of 2012) ...................................................................................................................... 15
4.1.3 Example of an applied Graded Security approach to mitigate a state -of-the-art
Cyber attack ............................................................................................................... 19
4.1.4 Comparison of a typical IACS infrastructure by the considered attack processes .......... 19
4.1.5 Examples of protective measures in a graded security approach .................................. 19
4.1.6 Evaluation of the graded security approach efficiency .................................................. 20
4.1.7 Conclusion ................................................................................................................. 21
4.2 Towards an adapted classification methodology for graded security approaches in EPU
architectures ........................................................................................................................... 21
4.2.1 A methodology to implement a “graded security approach” .......................................... 22
4.2.2 Definition of relevant classification criteria ................................................................... 23
4.2.3 Discussion on existing standards and best practices ................................................... 23
4.2.4 Practical methodology to classify systems to dedicated zones ..................................... 24
4.2.5 Application of a traversing path to determine a possible target zone ............................ 26
4.2.6 Application of the methodology in an example ............................................................. 27
4.2.7 Conclusion ................................................................................................................. 27
5 Work stream 2: Characterization, categorization and modelling of threats .................................... 28
5.1 Conceptual model of key concepts of cyber risk ....................................................................... 29
5.2 Why attack modelling is central to risk assessment .................................................................. 31
5.3 An overview of graphical attack modelling techniques .............................................................. 32
5.4 Security analysis of voltage control in active distributions grids ................................................ 34
5.4.1 Reference architecture ................................................................................................ 34
5.4.2 An example of attack tree ........................................................................................... 36
5.4.3 Voltage control architecture in CySeMoL ..................................................................... 38
5.4.4 Security evaluation using CySeMoL ............................................................................ 42
5.5 Conclusion .............................................................................................................................. 45
6 Work stream 3: Remote services................................................................................................. 46
6.1 Scope and purpose .................................................................................................................. 46
6.2 Landscape of threats ............................................................................................................... 46
6.3 Contractual issues: security requirements in procurement for Electric Power Utilities ................ 47
6.4 Application to real world architectures ...................................................................................... 51
6.5 Checklist of Security Requirements and Management Controls to Consider for T P
Agreements ............................................................................................................................. 55
6.6 Conclusion .............................................................................................................................. 56
7 Conclusion and outlook of WG D2.31 .......................................................................................... 57
A.1 ACRONYMS AND ABBREVIATIONS ........................................................................................ 58
A.2 REFERENCES ........................................................................................................................ 59
A.3 TABLE OF FIGURES ............................................................................................................... 65
A.4 TABLE OF TABLES ................................................................................................................. 65
1 Introduction
Before the era of digitalization, Electric Power Utilities (EPUs) did not worry much about
threats from the Internet. They rely on the obscurity of their systems, and p hysical protection.
The systems weren’t connected with data communication protocols, but rather with relays and
physical switches.

Today electricity generation, transmission, and distribution operations are increasingly

dependent on digital systems, including Industrial Automation and Control Systems (IACS),
information systems and communication networks, e.g.:
 EPUs operate and increasingly control generation, distribution and transmission units
centrally utilizing digital systems instead of having units o perated locally and in a
decentralized way. In the world of cost-cutting and operational excellence, the
implementation of digital systems is an irreversible action, since the EPUs can’t afford to
move back to manual labor to do it.
 Requirements of the growing number of renewable energy sources are making operation
of grids more demanding, requiring more automated control and thus making it impossible
to operate them without digital systems.
 Smart Grids and their numerous new services will rely on distribut ed automation and new
customer participation requirements, and will therefore radically change network
accesses, core architectures and the use of digital systems . [1-1]

Figure 1—1 Vision Smart grid Europe of EDF [1-2]

This report is an outcome of the work of the working group D2. 31, which had the target to discuss
and develop “ Security architecture principles for digital systems in Electric Power Utilities”
for focus areas:
 Classification methods for security zone/level definition associated with a graded
security approach
 Characterization, categorization and modelling of threats
 Remote services
1.1 Risk of digital systems
This evolution of digital systems and the dependency of EPUs ’ core processes to digital
systems introduces new vulnerabilities to the reliability of electricity supply, based on the
introduction and exposure of vulnerabilities in digital systems, architectures, and
communications.

1.1.1 Change of technology

EPUs are accustomed to long lifespan for their technical infrastructure. Proprietary systems
were the norm; they were designed and built especially for their purpose. During the last ten
years technological development and the nature of the business has changed. Modern
equipment is built with Commercial Off the Shelf (COTS) products, standard hardware and
software that is designed for commodity and multiple purposes. In general the industry has
moved from specific hardware and software to generic operating systems and standard
applications that are also used for other purposes. The same development is happening to
Human Machine Interfaces (HMI), Programmable Logic Controllers (PLCs) as well as other
protection and automation equipment. Today a digital system with the same operating system
and vulnerabilities can be used in an office environment, in a control center for Supervisory
Control and Data Acquisition (SCADA), or in a substation to connect to protection relays.

The same is also true for data communication. Data communication links to c ontrol and
operate core processes of EPUs used to be “serial line” and “point -to-point” connections.
Today data communication in EPUs is based more and more on modern “routable”
communication protocols (e.g. IP protocols), which introduce a new level of co nnectivity with
new vulnerabilities and weaknesses. A return to older “serial” protocols would not allow the
bandwidth required to run advanced applications such as wide -area monitoring, and would
also not offer nearly as much capability as IP-based protocols.

1.1.2 Increased connectivity

A German newspaper article [1-3] [1-4] describing a real world example demonstrated the
increased connectivity between the commercial/business network and the digital systems
controlling critical infrastructures in a real worl d scenario. The article described a penetration
test targeting an EPU, which is located in Germany and supplies approximately 40,000
residents with electricity and water for the local region. According to the article in a short time
frame an IT security expert could get access to digital systems controlling critical
infrastructure by the penetration of the commercial and business network with a combination
of common attack methods, like social engineering and exploitation of vulnerabilities.

Although this might not be representative of all EPUs’ infrastructure and level of security, it
stresses a general fact that a total isolation of control systems from business systems is a
myth [1-5]. This myth has long prevented EPUs from adopting an adapted cybersecur ity
posture.

As another example of how system connectivity is used in real world attacks, one can study
the simplified example of a plant architecture showing different attack vectors of the “Stuxnet”
malware [1-6].

Commodity and business IT systems are already today connected to digital systems of critical
infrastructures.

Connectivity and integration are unstoppable trends for EPUs. They are embodied by an
increased use of remote accesses and of interoperable and open communications and
standard data models, like IEC 61850 [1-7]. The more interconnectivity and integration grow,
the more EPUs are exposed to cyber-attacks, with significant potential consequences.

New market requirements will drastically drive the need for this connectivity, electronic data
interchange, and integration, e.g.:
 24/7 support maintenance combined with cost pressure drives the need for remote
services, which have to be accessible from around the world and have increased need
for high bandwidth to satisfy new requirements of ever -increasing pace and size of
service packs, updates, and configurations.
 The energy branch is moving from demand driven control to demand response which
allows producers of renewable energy and the customers to interact in an automated
way in real-time, coordinating demand to flatten the peaks. Bi-directional energy flows
for distributed generation also need new communications. All this greatly increases
the number of market actors and needed communications.
 The energy system needs to include the introducti on of more renewable energy, which
is by nature less controllable than conventional energy generation. This needs to be
compensated by a higher degree of connectivity and integration.
 Smart metering is significantly enlarging communication needs compared t o before,
and adding controllability to the customers’ premises. At the same time as system
connectivity rises, criticality rises at the same pace. Suddenly the whole energy
system is very dependent on trustworthy communications. Without it, there is a ris k of
major black-outs [1-8].

Even if the systems are getting more complicated and open up new attack vectors, we still
need to remember the legacy systems. In an article of October 2013 [1-9], researchers report
on vulnerabilities found in devices that are used for serial and network communications
between servers and substations. These products have been largely overlooked as hacking
risks, because the security of power systems has focused only on IP communication and
hasn’t considered serial communication an important or viable attack vector (see [1-5]). But
the researchers say that breaching a power system through serial communication devices can
actually be easier than attacking through the IP network since it doesn’t require bypassing
layers of firewalls. A security breach is also represented by the later integration into existing
serial based devices of IP network interfaces supporting remote maintenance functions [1-10] .

1.1.3 Increase of threats

According to a recent ICS-CERT report [1-11], the energy sector is highlighted as a cyber-
target in the industrial sector. Also an antivirus software vendor confirms this picture of
increasing threats with a report in the beginning of 2014, that “the energy sector has become
a major focus for targeted attacks and is now among the top five most targeted sectors
worldwide” [1-12].

The increase of threats is also reflected on the technical level. Vulnerability reports on
SCADA have grown by 600% since 2010, with the number of disclosed vulnerabilities
doubling between 2011 and 2012 [1-13]. Even if for some operators, incident reporting
becoming mandatory explains partially those numbers, this illustrates the growing interest by
attackers. These vulnerabilities affect a wide range of devi ces and manufacturers and exceed
the number of Java or Flash vulnerabilities, a significant fact because Java and Flash are
often viewed as poor security designed IT softwar e [1-13].

To give a more differentiated picture of today’s threat 2 landscape against digital systems in
the area of EPUs, threats could be categorized into directed and undirected attacks [1-14].

—————————
2 Not exhaustive: A further differentiation e.g. into intentional / un -intentional threats is not conducted
Examples of directed attacks:
 Well financed nation state or organization attacks, like “Stuxnet” malware [1-15], which
quite likely disrupted the Iranian nuclear program, or the “Dragonfly Group” creating a
sabotage threat against western energy companies [1-16].
 Hackers with political or environmental agendas, like “Anonymous” activists who have
targeted nuclear energy companies like EDF, GE an d ENEL in Q2/2011 after the
Fukushima tragedy [1-17] or the “Shamoon virus attack” 3 which infected around
30,000 computers of an oil company in Saudi Arabia in 2012 [1-18].
 Disgruntled employees or third party support personnel with approved access rights
and knowledge of the intricacies of the EPU operation and storage facilities containing
sensitive data is a particular concern [1-19].

Examples of undirected attacks:

 Individuals just trying possibilities and technology, such as attempting to find Interne t-
facing SCADA with known vulnerabilities with the “Shodan computer search engine”
[1-20]
 Malicious code infections, like the “Slammer worm” impacting a US nuclear power
plant in Ohio [1-21] during its maintenance.

Even though not all of these attacks require sophisticated tools, nor do they necessarily
require extensive financing, attacks in general have become increasingly sophisticated
utilizing considerable capabilities and tactics.

A general projection is that these threats will increase in both sop histication and intensity with
the deployment of the Smart Grid’s Advanced Metering Infrastructure (AMI). This situation is
exacerbated when the AMI is connected to the public Internet and is not immune to threats
executed against EPU infrastructures using corporate or private intranets or by isolating the
systems.

EPUs need to be diligent in maintaining their awareness of rapidly evolving threats and
prepare accordingly to protect sensitive information and digital systems.

1.2 Current assistance available to EPUs

This situation calls for new security requirements for digital systems and the underlying
architectures used in EPUs. Security requirements have to be derived from appropriate risk
assessments and general architectural decisions.

The definition of the term Cyber-security, which is used in the context, tries to summarize as
following:

“Cyber-security strives to preserve the availability and integrity of the networks and
infrastructure and the confidentiality of the information contained therein.” [1-22]

Cyber-security is primarily about people, processes and technologies working together “ to

encompass the full range of threat reduction, vulnerability reduction, deterrence, international
engagement, incident response, resiliency, and recovery policies and activities, including
computer network operations, information assurance, law enforcement, etc.” [1-23]

—————————
3 After a post at Pastebin.com, there are speculations, that the “Shamoon virus attack” was a directed attacked by
a hacker group.
1.2.1 Current development in standardization

The growing awareness of cyber risks has pushed the EPUs to investigate into security
standards currently applicable to the digital systems [1-24]. Recently the reference
standardization committees started the analysis of the communication and security standards
mapping them over the control use cases of smart grids.

The US National Institute of Standards and Technology (NIST) provided a comprehensive

guideline analyzing the risk levels, security requirements and measures of the main logical
network interfaces [1-25]. In 2013, WG15 of IEC TC 57 published a collection of references
for smart grid cybersecurity [1-26]. The WG Set of Standards of the CEN/CENELEC/ETSI
Smart Grid Coordination Group started the analysis of such standards by mapping them in
relation to the domains and control zones of the main smart grid applications [1-27].
 With reference to the support provided to the EPUs for comprehensive security
governance, three distinguishing security frameworks are noteworthy. The ISA99
committee, originated from the process industry, is quite active in developing process
and product oriented specifications applicable to the industry at large, which could be
used for the power industry. Their advanced drafts are used as input for the IEC (the
TC65) to turn them into IEC standards or technical reports (IEC 62443 series) with
exceptions like the IEC 62443-2-4 which is based on WIB [1-28] documents.
 The ISO/IEC Technical Report 27019 complements the set of controls contained in the
ISO/IEC 27002 standard by providing further guidance to implement the controls due
the specific requirements of the energy industry sect or.
 The recently launched NIST Cybersecurity Framework [1-29] targeted to help Critical
Infrastructures operators improving their cyber security deserves special attention
from EPUs.

Besides these three generic initiatives, control system vendors are also active in targeting the
development and implementation of security technologies related to standard communication
protocols, such as the IEC 61351 series managed by IEC TC57 WG15. Additionally, the
nuclear power generation domain has its own framework and initiatives, both at the national
level (e.g. NEI 08-09 in the US [1-30]) and at the international level (IAEA document [1-31]
and IEC standards like IEC 62645 or IEC 62859 [1-32]).

1.2.2 Governance and organizational initiatives

The uptake in smart grid deployments has motivated the EU and US to create the most
comprehensive implementation programs. Both have developed and maintained energy sector
roadmaps to achieve energy delivery system cybersecurity.

The high representation of the Union for Foreign Affair s and Security Policy outlined the EU’s
vision and the actions required to achieve an open, safe and secure cyberspace for their
member states [1-33].

This vision is articulated in five strategic priorities:

1. Achieve cyber resilience
2. Drastically reduce cybercrime
3. Develop a cyber-defense policy and capability related to the Common Security and Defense
Policy (CSDP)
4. Develop the industrial and technological resources for cybersecurity
5. Establish a coherent international cyberspace policy for the EU and promote core EU values.
Implementing this strategy began in earnest near the end of 2013 and has been ramping up in
2014. The European Network and Information Security Agency (ENISA) was established in
2004 and a new regulation to strengthen ENISA and modernize its mandate is being
negotiated by Council and Parliament. With other agencies, ENISA plays a key role in the
implementation and deployment of the strategy.

For example the commission asked ENISA to:

 Assist the member states in developing strong natio nal cyber resilience capabilities,
notably by building expertise on security and resilience of industrial control systems,
transport and energy infrastructure.
 Develop, in cooperation with relevant national competent authorities, relevant
stakeholders, International and European standardization bodies, and the European
Commission Joint Research Centre (JRC), technical guidelines and recommendations
for the adoption of network information security (NIS) standards and good practices in
the public and private sectors.
 Identify emerging trends and needs in view of evolving cybercrime and cybersecurity
patterns so as to develop adequate digital forensic tools and technologies.

To facilitate and support the process of a European-wide Smart Grid roll-out, the European
Commission set up a Task Force on Smart Grids. The ultimate goal of this Work Program is to
identify and produce a set of regulatory recommendations to ensure European -wide
consistent and fast implementation of Smart Grids, while achieving the expected Smart Grids'
services and benefits for all actors involved. The key deliverable of the Expert Group 2 (EG2)
is to identify the appropriate regulatory scenario and recommendations for data handling, data
security and data protection. The aim is to establis h a data privacy and data security
framework that both protects and enables. Within the EG2 program ENISA recently published
a proposal for a list of security measures for Smart Grids [1-34]. Such a list is used as a basis
by the WG Information Security of the CEN/CENELEC/ETSI Smart Grid Coordination Group in
order to correlate the security standards and to identify the need for further developments
addressing uncovered requirements. The European project Security of Energy Systems
(SoES) is moving a step ahead towards the filling of gaps identified by the aforementioned
expert groups [1-35].

Starting in 2005 the US Department of Energy in cooperation with other US agencies and
Canada facilitated the development of the Roadmap to Secure Control Systems in the Energy
Sector to enhance cybersecurity across the energy sector. In 2011 the roadmap was updated
[1-36]] to include the changing landscape of Smart Grid technologies, building on new
priorities to enhance vulnerability disclosure, addressing the more inn ovative threats, and
emphasizing a culture of security that extends beyond the focus on compliance. The US goal
is by 2020 to realize resilient energy delivery systems that are designed, installed, operated,
and maintained to survive a cyber-incident while sustaining critical functions.

1.2.3 Cigré’s role

Cigré has a demonstrated commitment in past, present and future to support EPUs in dealing
with cybersecurity issues. This section summarizes the Cigré SC working groups associated
with the topic of Cyber security:

CIGRÉ Joint Working Group (JWG) D2/B3/C2-01, “Security for Information Systems and
Intranets in Electric Power Systems”. The work has been carried out between 2003 and 2006.
The JWG produced a technical brochure [1-37], whose purpose was to raise the awareness of
information and cybersecurity in electric power systems, and give some guidance on how to
solve the security problem by focusing on security domain modeling, risk assessment
methodology, and security framework building.

CIGRÉ Working Group D2.22, "Treatment of Information Security for Electric Power Utilities
(EPUs)". The work was carried out between 2006 and 2009 as a successor of the JWG
D2/B3/C2-01.The WG D2.22 has focused and deepened the study on the following three
issues: Frameworks for EPUs on how to manage information security; Risk assessment (RA)
common models and methods for treating vulnerabilities, threats and attacks; and security
technologies for SCADA including real time control networks [ 1-38].

CIGRÉ D2.38 “A framework for EPU operators to manage the response to a cyber-initiated
threat to their critical infrastructure”: When completed in 2015, this group’s Technical
Brochure will describe a framework for a tool set that EPU operators can use to automate
their response to cyber-initiated threats. Specific components of the tool set will be based on
the input received from a global survey of EPUs interested in a tool set that can be used to
automate their response to a cyber-initiated threat.

CIGRÉ B5-D2.46 “Application and Management of Cybersecurity Measures for Protection and
Control Systems”. This group’s Technical Brochure is nearing completion and focuses on
cyber security issues from the perspective of protection and control systems, including
discussions on threats, background information, standards, practical solutions and case
studies.

2 Working Group D2.31

In this context the Working Group D2.31 was founded as the successor of the Working Group
D2.22. The focus of the Working group D2.31 is to developing Security architec ture principles
for digital systems in Electric Power Utilities. The scope of this work cover the discussion of
general Security Architecture principles for digital systems, but will also study certain aspects
and solve specific questions. The working group was active from 2010 until 2014.

WG D2.31 has structured its activity in 3 working streams:

 Working stream 1: Classification methods for security zone/leve l definition (graded
approach)
 Working stream 2: Characterization, categorization and modelling of threats
 Working stream 3: Remote services

During the time working group D2.31 has done following publication and initiate following
activities:

 The paper “Graded approach to cyber security for EPUs: Clarifying the secu rity levels
and zones concepts” has been presented at the D2 Colloquium 2011 in Buenos Aires.
[2-1]
 The paper “Modelling of cyber-attacks for assessing smart grid security” has been
presented at the D2 Colloquium 2011 in Buenos Aires. [2-2]
 The paper “Cyber-attack modelling and security graded approach: key elements when
designing security architecture for Electric Power Utilities (EPUs)” has been presented
at the Cigré 2012 Paris Session 2012. [2-3]
 The paper “Towards an adapted classification methodology for graded security
approaches in EPU architectures” has been presented at the D2 Symposium 2013 in
Lisbon. [2-4]
 The paper “Application of a cyber-security assessment framework to smart grid ICT
architectures” has been presented at the D2 Colloquium 2013 Mysore, Karnataka,
India in 2013. [2-5]
 The working group held a “Cyber Security tutorial” at the Cigré International Tutorial &
Colloquium on SMART GRID at Mysore, Karnataka, India in 2013
 “Security in remote services used by EPUs” has been sent in to the Cigré Paris
Session 2014 [2-6]
  Publication of the invited paper “Status of Cyber security” in the Electra magazine
October 2014,[2-7]

3 Summary of findings and recommendations of Working Group

D2.31
Today electricity generation, transmission, and distribution operations are increasingly
dependent on digital systems including information systems and communication networks.
This evolution introduces new vulnerabilities to the reliability of electricity supply, based on
the introduction and exposure of vulnerabilities in digital systems, archite ctures, and
communications. Therefore it has become essential for EPUs to consider cybersecurity
threats and risks across all the organization and raise awareness from operational to
executive level, including vendors, partners, and third parties.

In this context WG D2.31 concluded its work in the following findings.

 Work stream 1 Classification methods for security zone/level definition (graded approach):
 EPUs face new challenges in terms of cybersecurity, driven by the tremendous
evolutions of their environment and their technical infrastructures. Numerous
standards, best practices and blueprint architectures push for a graded security
approach, and the implementation of security zones .

 The success of a Graded Security Approach depends on an effective implementation,

maintenance and operation. Practical methodologies, guidelines, template and reference
to standards and best practices are needed to ease the setup of a Graded Security
Approach and to ensure compliance. An effective practical methodology to introduce a
graded security approach in EPU architectures is to design and implement a classification
approach that is directly applicable to the business, technology and applications of the
EPU.
In addition to a quicker Graded Security Approach design, such methodology can remove
burden of the security review by pointing out critical allocation of systems that need some
dedicated controls. For more enforceability of the results, the next step could be the
building of a common definition of a Graded Security Approach and requirements set for
specific areas in the smart grid.

 Work stream 2 Characterization, categorization and modelling of threats:

Graphical attack modelling is both a relevant and viable method for cyber security
analysis of control system architectures for future smart grids. Attack modelling comes
in many flavors and in this work one of the simplest approaches, attack trees, has
been applied in an example. The work has indicated the value of this easy -to-use
approach as a means to obtain a first holistic understanding of the strengths and
weaknesses of a system architecture solution. A model such as this can be expanded,
both in detail and in scope, when needed.

Going more in depth, the application of modelling and evaluation tools supportin g the
security analysis of ICT architectures allows managing the complexity of correlating
component configurations with attack steps and security controls. Based on the
assumption that architecture configurations are the cornerstone of smart grid cyber
security, this work explored the application of an attack graph formalism, CySeMoL, to
the security analysis of architecture variants for the Voltage Control (VC) in active
distribution grids connecting DER. We have represented the VC architecture using the
CySeMoL meta-model and we have estimated the probability of attack successful
comparing three configuration variants.
 The work has also drawn attention to many of the challenges that still remain in the
use of graphical attack modelling by EPUs. Clearly, the use of graphical attack
modelling in practical applications requires a number of trade -offs, starting with the
selection of either a simple modelling method (such as attack trees) or the use of more
complex probabilistic and dynamic approaches availabl e. Furthermore, the level of
detail used to describe the smart grid scenarios has an impact. For a complete model,
more details need to be added both with regards to various (ICT) system components
and to the description of other smart grid control functio nalities. Likewise, other attack
processes and additional targets beyond the example presented may need to be
considered. Added to this, countermeasures may also need to be included. Finally, in
order for graphical attack modelling to become a practical su pport to EPU decision
making, the consequences of various attacks, on both the power system and the
business as a whole, need to be addressed. Many of these aspects remain for future
work.
 Work stream 3: Remote services

EPUs rely on remote access for several use cases like maintenance or monitoring.
While improving performance and the overall process, those connections come with
risks. In many cases remote access performed by third parties and inconsistencies
between security policies could weaken the EPU.

In order to support utilities efforts in this field, we have proposed a simplified checklist
applied to remote services. This checklist is expected to guide utilities deciding if they
need to use remote services provided by third parties and what requirem ents should
be included in their RFQ.

We have also discussed possible technical architectures and ways to mitigate the risk.

Further steps include integration of legacy devices for remote maintenance, overview
of different architectures for remote maintenance, technical comparison of
architectures, issues and controls for the use of mobility devices (e.g. tablets,
smartphones, etc.) for remote maintenance, and the analysis of the issues involved
with the extension of remote access to include remote contr ol purposes.

4 Work stream 1: Classification methods for security zone/level

definition (graded approach)
The objective of the working stream 1 is to discuss and develop:
 a general overview of known standards, best practices and blue print architectures
 a general evaluation of compatibility and correlations between the standards and best
practices
 practical considerations on classification cri teria and model to map systems.

Following persons have contributed to the work of working stream 1:

 Jens-Tobias Zerbst, Vattenfall, Sweden
 Ludovic Pietre-Cambacedes, Électricité de France, France
 Åge Torkilseng, SKS, Norway
 Olivier Breton, Alstom, France
 Simon Zimmermann, Vattenfall, Germany
 D. K. Holstein, OPUS Consulting Group, USA
 Christoph Poirier, Électricité de France, France
4.1 Graded approach for EPUs: Clarifying the security levels and zones
concepts
A growing number of industrial standards (e.g. [ 4-1], [4-2], [4-3], [4-4], [4-5]), regulations (e.g.
4-6]), best practices (e.g. [4-7]), and architecture blue prints, require or recommend graded
security approaches as a security architecture methodology. Unfortunately, the graded
security approach descriptions found in these different documents are not aligned and rely on
different taxonomies, scopes and objectives.

The wide variety of variations in standards, best practices and regulations can lead in practice
to challenges in regards to conformity, application and implementations.

The purpose of this chapter is to clarify the concept of graded security approach as a
fundamental security architecture principle for digital systems in EPUs, enabling efficient
mitigation of current and upcoming risks. The chapter is structured according to the following
objectives:
 to clarify the associated terminology and definitions associated with the concept of graded
security approach;
 to give a general overview about known standards and best practices architectures in the area
of graded security approaches;
 to discuss their characteristics, differences and limitations;
 to illustrate the effectiveness and the adaptability of a graded security approach in a real world
attack use-case.
4.1.1 Terms and definitions
Following definitions should clarify terms associated with the concept of graded securi ty approach.
 Graded security approach:
Graded security approach is a practical approach when dealing with large or
distributed computer architectures. In such a context, a uniform set of security
measures would not be adapted; and in fact, it would not be cost-effective to define
and implement security measures on a system by system basis. The graded security
approach involves grouping systems sharing similar needs for protection. From this
perspective, the graded approach implies the definition of a limit ed number of security
levels. Based on the grouping of diversified security controls and requirements in
different security levels, the graded security approach could be a base to introduce a
Defense-in-Depth (DiD) concept into an infrastructure. The initial focus of this work is
on the discussion of the graded security as the overarching approach.
 Security Level:
A Security level is assigned to a system or group of systems in order to reflect similar
needs for protection. A security level corresponds to a given set of high -level security
requirements. Each system is assigned a security level, based on assig nment criteria,
depending on each specific graded security approach implementation.
 Security zone and Security zoning:
A security zone is a “grouping of logical or physical assets that share common security
requirements. A zone has a clearly defined borde r (either logical or physical), which is
the boundary between included and excluded elements.” [ 4-7]
The principle of security zoning corresponds to the definition and implementation of
security zones (latter simply called “zones”): it is the architectural and implementation
side of the graded security approach defined earlier. Each zone has a given security
level assigned, indicating the protective measures to be applied for all digital systems
in that zone. The relationship between zones and security leve ls is not one-to-one:
there may be several zones with the same security level. The use of different zones
for digital systems having similar security levels may be needed for different reasons,
e.g., distinct administrative and organizational set -ups, different technological
environments calling for specific security control implementations, communications
 restrictions to be implemented between zones. In most implementations, different
systems belonging to one zone build a trusted area for communication wit hin that zone
whereas zone borders require control mechanisms for data flow between zones.
Zones can be hierarchical in the sense that they can be comprised of a collection of
sub zones [4-7]. The division of a zone into sub-zones can be needed to comply with
specific requirements, e.g. administrative/legal needs, technological flexibility, or
isolation of given systems, without compromising the concept of the overlaying zoning.
 Defense-in-Depth (DiD)
Defense-in-Depth (DiD) is often defined as an approach to security in which multiple
and independent security measures, covering organizational, technical and
operational aspects [4-8], are deployed in a security architecture, as no individual
measure can provide an appropriate level of security. In such approa ch, it is the set of
diversified and independent security measures which are able to bring the needed
detection, protection and response capabilities.
DiD is now considered as a fundamental principle in cyber securi ty, e.g. in the system
design [4-7], software design [4-9], security architecture, or security control design [ 4-
10]. In the NRC RG 5.71 [4-11], DiD is described as follows: “from a security
architecture perspective, it involves setting up multiple security boundaries to protect
Critical Data Assets and networks from cyber-attack.”
Finally, it should be stressed that the notion of DiD is closely linked, and sometimes
confused with the concept of graded security approach and the security zoning
principle. The notion of DiD overlaps the notion of graded security approach in the
sense that the security levels defined by the graded security approach call for security
controls respecting the DiD principle, and that the very definition of different security
levels is per se a way to diversify and establish multiple security layers of protection.
The initial focus of this work is on the discussion of the graded security approach as
the overarching approach.
 Security domains
The Cigré JWG D2/B3/C2 introduced a security domain concept for Electric Power
Utilities [4-12] which has been further elaborated by Cigré WGD2.22 [ 4-13] using a
framework definition of security domains [4-14]. A logical security domain model, that
requires different protection levels, is described in the WG D2.22 documentation [ 4-
13]. An example mapping security domains within a typical EPU data network is
provided as an illustration.
The term security domain is defined in this work as “environment or context that is
defined by a security policy, security model, or security architecture to include a set of
system resources and the set of system entities that have the right to access the
resources” as defined in the ISO 7498-2 [4-14].
The IEC Smart Grid Standardization Roadmap [4-15] is referring to the following
domains in its conceptual model: Markets, Operations, Service Provider, Bulk
Generation, Transmission, Distribution and Customer. These application domains are
examples of functional areas that could be mapped to a security domain model (“top-
down” approach) [4-13] or zone-based security architecture (“bottom-up” approach) [4-
7]. In this context security domains are defined by authorities to express their area of
responsibility and risk appetite. Security requirements are fulfilled by using a graded
security approach, security zoning principles and by implementing security controls in
electronic data networks.
4.1.2 Standards and Best Practices of graded security approaches (as per
beginning of 2012)

PERA defines the Control and Information Architecture as one of three basic
Architecture (PERA) and the ISA95, 99

components of any enterprise, (the other two are the Production Facilities, and
The Purdue Enterprise Reference

the People/Organization) [4-16]. Part of the PERA is a Control and Information

Architecture Diagram (CIAD), which describes a 6 level design, and a Purdue
Reference Model for Computer Integrated Manufacturing (CIM) which includes a
derived models

“functional hierarchical computer control structure for an industrial plant”, also

based on 6 levels.

The PERA does not describe a “Graded security approach”. However, it is the
base for different standards and best practices in this area and is therefore
mentioned in this context. The PERA model has been further refined and
standardized in ISA-95 [4-17]. This standard defines 5 levels identifying the
boarders of enterprise level, manufacturing and control level. The ISA -99
standard, described later on, provides also a 5 level functional model directly
derived from the PERA and ISA-95 models, with levels slightly re-named and
reorganized to better suit architectural discussion on security.
(also issued as IEC 62443-1-

The ISA-99 series “provides a current assessment of security tools and

ANSI/ISA-99.01.01–2007

technologies that apply to the Manufacturing and Control Systems environment”

[4-7]. The standard series leverages the ISA-95 division in terms of functional
levels, but introduces in its first part new security-oriented concepts, including
security levels and security zones (as defined in Section 3.2 and 3.3). In [4-7],
1)

there is no strict requirement fixing the number of security levels to define, nor
associated assignment criteria’s, but the standard provides examples based on a
simple 3 security level approach. A more detailed concept, named SAL (security
assurance levels), is presently discussed within ISA99, in order to move from
qualitative levels to more quantitative descriptions and metrics [4-18].

CIGRE WG D2.24 developed a common, world-wide vision for the next

generation of Energy related systems and primarily focuses on Energy
Management System (EMS) and Market Management System (MMS)
CIGRE WG D2.24

architectures, summarized in TB452 [4-19]. The specification outlines the

requirements that the next generation of systems should meet and proposes a set
(TB 452)

of architecture guidelines to comply with these requirements including security

guidelines (Section 9). The security architecture defines the security standards
and services, addressing several key areas, including Perimeter Protection with
policy enforcement point (PEP) at domain boundaries. According to CIGRE WG
D2.24 [4-19], new systems must reside in networks with perimeters clearly
defined by security zones. They can be grouped into security levels and color -
coded in this security architecture.

Cigré WGD2.22 developed a security domain model with generic protection levels
relative to operation (cf. Section 3.5). In an actual case the protection levels
should be defined as results of a risk management process. Examples are given
Cigré WGD2.22

with the view to provide practical guidance for deploying cyber security
technology within Electric Power Utility (EPU) data networks. A table summarizes
(TB 419)

a model that could be used by Electric Power Utilities and their application
domains like Generation, Transmission, Distribution and Markets. The security
domains should be mapped to a physical EPU data network. Since each security
domain prescribes specific security controls, specific security technologies can be
selected for deployment. Examples of security controls/technology are given for
the Corporate domain and the additional security controls/technology that are
needed for the Business Critical and Operation Critical domains.
 The National Institute of Standards and Technology (NIST) Special Publication
800-82 “Guide to Industrial Control Systems (ICS) Security” describes security
methods and security controls.
NIST SP800-82

The document describes in particular a “Defence In Depth architecture” [4-20]

referencing to the document of the Idaho National Laboratory “Control Systems
Cyber Security: Defence in Depth Strategies” [4-21]. The document “illustrates
the traditional separation of corporate architectures and control domains” and
introduces a zone model. Furthermore it describes and visualizes further attack
types and concludes with the illustration of different security controls. In October
2009, the document was updated [4-22] among others with the introduction of a
th
5 zone for safety Instrumental systems.
U.S. Nuclear Regulatory Commission
(NRC) Regulatory Guide (RG) 5.71

“RG 5.71 [4-5] describes a regulatory position that promotes a defensive strategy
consisting of a defensive architecture and a set of security controls based on
standards provided in NIST SP 800-53 and NIST SP 800-82, “Guide to Industrial
Control Systems Security” [4-20]. One part of the RG 5.71 is the definition of
defensive levels conceptually correspond to existing physical security areas and
describe an example defensive architecture as following: “This defensive
architecture includes five concentric cyber security defensive levels separated by
security boundaries, such as firewalls and diodes, at which digital
communications are monitored and restricted.” [4-5] “An example of such a
defensive architecture is one that inc ludes a series of concentric defensive levels
of increasing security which conceptually correspond to existing physical security
areas at a facility” [4-5 - C.3.2.1]

The Nuclear Energy Institute is a US-based policy organization, representing the

U.S. NEI (Nuclear Energy

US nuclear energy and technologies industry in both the US policy -making

Institute) 08-09

process. The NEI and its members develop policy on key legislative and
regulatory issues affecting the industry. The NEI plays an active role in the cyber
security area: in 2005, they issued the NEI 04-04 as guide for the cyber security
of US nuclear power plants. Following a new regulation on cyber security passed
in 2009 (10 CFR 73.54), NEI 04-04 has been replaced by NEI 08-09, issued
publicly in 2010 (as Revision 6) to be used by the US nuclear utilities as a
template when elaborating a cyber-security plan for their critical digital assets. Its
format aims at facilitate compliance with NRC regulations on cyber security.

The International Atomic Energy Agency (IAEA) has prepared a new document
Computer security at nuclear
IAEA reference manual on

dealing with computer security at nuclear facilities. After several years of debate,
it is in its last editorial stage before publication, at the moment of writing this
paper. The targeted audience is very wide, including regulators, policy -makers,
operators and vendors. The scope is also large, as the document provides
facilities

guidance on organizational and implementation issues, regarding the security o f

all types of digital systems found in nuclear power plant, including classical IT
systems and industrial control systems. In particular, it recommends the use of a
graded approach and of the zoning principles, in a very similar way as the
principles described in Section 3.1 and 3.3. The example implementation defines
five security levels, with growing security requirements, and a set of generic
requirements to be applied to all systems.
 The International Electro technical Committee (IEC) established standards for
nuclear power plant instrumentation and control system through its Subcommittee
45A (SC45A). This committee has already issued a widely used and recognized
series on safety systems, with at its top the IEC61513, and among differ ent
aspects and associated standards, a safety classification described in IEC61226.
More recently, IEC SC45A a starting to work on an international standard on
IEC 62645 (DRAFT)

cybersecurity of NPP I&C. Presently at an intermediate stage of drafting, it also

calls for a graded approach to security, with the definition of security levels and
associated graded requirements. In the present draft, three security levels (called
degrees) are defined; they are assigned based on the consequences on the
overall plant safety and performance of each system considered. Such
assignment leverages the existing safety classification based on IEC 61226. This
classification is a fundamental input when assigning security degree;
nevertheless, there is not a one-to-one mapping between security degree and
safety classes. This would not be relevant as other aspects than safety are
considered. Similarly, there’s no direct mapping between security degrees and the
ISA-95/PERA levels. Note that the security degree definitions may evolve during
the standardization process: we will not describe them further in this paper.
Safety (SeSa) report

The SINTEF Group is an applied research organisation in Scandinavia. “The

SINTEF Secure

SeSa (Secure Safety) project has developed a systematic and methodologica l

approach to assess whether a given technological solution for remote access to
SIS is acceptable.” [4-23] The systematic and methodological is summarized in
the SINTEF report [4-23]. The background of SINTEF is the offshore operation,
e.g. offshore oil production. The report defines a “layered model for remote
access” with 7 levels.
Infrastructure (AMI) system

“The purpose of the AMI Security Specification is to provide the utility industry
security requirements

along with supporting vendor communities and other stakeholders a set of

Advanced Metering

security requirements that should be applied to AMI implementations to ensure

the high level of information assurance, availability and security necessary to
maintain a reliable system and consumer confidence.” [4-24]. In the document, a
security domain model “was developed to boundary the complexity of specifying
the security required to implement a robust, secure AMI solution as well as serve
as a tool to guide utilities in applying the security requireme nts in this document
to their AMI implementation” [4-24]. The discussion of the AMI System Security
Requirements is based on the 1.01 version from the 17.12.2008

Table 4—1. Standard and best practices of graded security approach (as per beginning of 2012)

Short name Type / Document No. of Security Terminology Refers to Last

Objective security controls / based version
levels on

PERA Business Model 6 No Level - 1989

Architecture /
ISA95 Integration (PERA)

2000
(ISA95)

ISA99 Security for Internal 3+ Conduit, Levels, Risk 2007

IACS standard segmentat Zones, analysis
ions Sub-Zones,
Conduit
Cigré D2.22 EPU security Cigré 4 Yes Security CIGRE 2010
guidelines Technical domains,
Brochure (high JWG
level) Protection D2/B3/C
levels 2

Cigré D2.24 Security for Cigré 5 Yes Security INL 2011

IACS Technical zones
Brochure
TB 452 Security
levels

NRC Security for US 5 Yes Levels - 2010

IACS for regulatory
RG 5.71 nuclear guide
facilities

IEC 61645 Security for Internationa 3 - - - Draft

IACS for l standard
nuclear
facilities (draft)

NIST Security for US - Yes DiD, Zones PERA Final

IACS guidance Public
SP800-82 Draft
(final draft
publicly (2008)
available)

SINTEF Security Project 7 Yes Zones IEC 2007

SeSA architecture documentat 61508,
for IACS ion Common
(focus on Criteria
offshore)

NEI 08-09 Security for US 4 Yes Security RG5.71 2010

IACS for guidelines levels
nuclear (accepted (detailed)
facilities for
regulatory
compliance)

IAEA ref. Security for Guidance 5 Yes Security - Draft

Manual IACS for levels
nuclear (draft) (high
facilities level)

AMI system Security for Document 5 Yes Security - 2008

security AMI Domain
require.

Table 4—2. Comparison of standards and best practices (as per beginning of 2012)
4.1.3 Example of an applied Graded Security approach to mitigate a state -of-
the-art Cyber attack

To illustrate the effectiveness of a graded security approach, we evaluate in this section the
effect of an advanced but realistic multi-vector attack against a simplified architecture. This
architecture implements a graded security approach and security zoning principle, as
described in Section 3.1 and 3.3. The chosen attack processes correspond to the mal icious
framework “Stuxnet” [4-25].
In this purpose, this section provides:
 a short presentation of the attack vectors used by “Stuxnet”;
 an identification of possible attack points for these vectors in a simplified architecture,
designed along a graded security approach;
 examples of the associated protective measures; an explanation of the expected mitigation
effects of such an architecture in front of the considered attack vectors.

These elements are only given to illustrate the application and possible efficiency of a graded
security approach based on a specific example and implementation. They do not intend to
provide a detailed case or guideline, to be generic, complete or exhaustive
4.1.3.1 Attack processes
Referring to the current publicly available information, Stuxnet is based on the following propagation
methods [4-25]:
i. Network propagation routines: Infecting WinCC machines via a hardcoded database server
password
ii. Network propagation routines: Propagating through network shares
iii. Network propagation routines: Propagating through the MS08-067 Windows Server Service
Vulnerability
iv. Propagation routines: Peer-to-peer communication and updates4
v. Propagation routines: Propagating through the MS10-061 Print Spooler Zero-Day
Vulnerability²
vi. Removable drive propagation: LNK Vulnerability (CVE-2010-2568) or AutoRun.Inf
vii. Step 7 Project File Infections: S7 files, MCP files or TMP files

4.1.4 Comparison of a typical IACS infrastructure by the considered attack

processes

Figure 5-2 gives a high-level and simplified scenario of how the different attack processes
could affect an IACS infrastructure, divided into security zones. The scenario has no claim of
completeness or detailed visualisation, more over the scenario shows the basic effectiveness
of a graded security approach. The red numbers ref er to the methods listed in the previous
subsection. Due to clarity the scenario applies not all possible attack proce sses to all possible
instances

.
4.1.5 Examples of protective measures in a graded security approach
To evaluate the effect of a graded security approach, the following security controls are assumed to be
applied to the different zones.
i. Physical separation of systems, e.g. air gap, physical one-way restriction (Zone E)

—————————
4 No direct propagation routine
 ii. Logical separation of systems with functional connectivity based on application requirement,
e.g. firewall, deep packet inspection (Zone D)
iii. Restricted connection on public internet access (Zone B, C, D)
iv. System / Zone specific hardening based on requirement level (Zone A, B, C, D, E)
v. System / Zone specific patch management for system types / requirement level (Zone A, B, C,
D, E)
vi. Restriction on portable medias, e.g. organizational or technical restriction on USB or CD
usage (Zone D)
vii. Restriction on connection of portal workstation to network segments (Zone B,D)
rd
viii. Restriction on 3 party remote maintenance (Zone D)
ix. Application of antivirus scanner (Zone A,B)

3rd Party External

Maintenance Web Server Vendor
Workstation Fileserver
2,3,7 2,7
External /
Internet
2,3,4
Zone A : Office Automation
Zone A Zone B : Process planning
Wireless
Access File Office Office
Office Printer Zone C : Process control (Block 1)
Server Automation Mobile
Point
2,7 Workstation Workstation (ex: insufficient security controls)
Zone D : Process control (Block 2)
6 (ex: Sufficient security controls)
1,2,3,4 Zone E : Safety Systems
(Security control of seperation:
Application Process Zone B
Server Information Terminal e.g. air gap, data diode)
2,3 System Server Workstation

Zone E Application Zone D Application 3rd Party C

Server HMI Engineering Server Engineering Maintenance
HMI
Safety Workstation Workstation Workstation
System 1 6 2,3,6,7

Ethernet
1,2,3,4
3rd Party
Controller Controller
Maintenance
Workstation

Fieldbus PLC / IO Fieldbus PLC / IO

2,3,6

Figure 4—1. Simplified example of a plant architecture showing different attack processes with no claim of completeness

4.1.6 Evaluation of the graded security approach efficiency

Based on a simplified simulation of the attack processes against a simplified architecture the
following basic conclusions about graded approaches could be drawn:
 Isolation or network segmentation is an effective mitigation of infection ways between secure
zones, see e.g. segment D and E. Important is the efficiency of the implemented security
controls establishing the graded security approach, e.g. firewall/traffic control rules to separate
zones.
 The application of different security controls in different zones enables an adapted and
practical implementation with a sufficient security; see e.g. USB restriction in segment D and
 E, but not in A and B. In segment A and B, antivirus scanner (and not represented
organizational procedures) may be considered sufficient for USB-based attack processes.
 Graded security approach enables the use of best-of-breed security controls: see for example
the antivirus scanner in segment A and B, but due to system characteristic, or incomplete
implementation it is not in D and C.
 Infringements of the graded security approach could lead to direct failures of the overall
security posture; see for example the 3rd party maintenance in segment C.

4.1.7 Conclusion

EPUs face new challenges in terms of cybersecurity, driven by the tremendous evolutions of
their environment and their technical infrastructures. Numerous standards, best practices and
blueprint architectures push for a graded security approach, and the implementation of
security zones. Based on a survey of the different standards, best practices and blueprint
architectures dealing with graded security approach and security zoning principles, the
following conclusions could be drawn:
 Terminology and definitions related to the graded security approach differ partly in the
examined documents. This could lead in practice to challenges in regards to conformity,
application and implementations. Nevertheless, most of the examined documents share
common generic concepts and principles, which are identified and discussed in this paper.
 The development of a graded security approach for digital systems can’t be seen isolated. The
practical implementation and operation of a graded security approach should include and
connect to “non security” aspects like business integration, architecture, governance,
organization structure, physical environment, legal or safety regulations. All these aspects
have to feed in and be aligned with the graded security approach to ensure a successful and
efficient implementation and operation.
 It is essential to provide classification criteria to ensure a consistent mapping of digital
systems to different zones and ensure so a successful implementation of a graded security
approach. The examined documents provide only partly or not at all detailed classification
criteria.
Further could be stated, that security classification criteria should not lead to unidentified
conflicts with “non security” characteristics, like the ones previously mentioned.
 The effectiveness of a graded security approach relies on an appropriate selection,
implementation and operation of different security controls. Therefore security controls cannot
be reduced to network segmentation measures, but must integrate security controls of
different level like organizational, physical and technical, in a Defense-in-Depth approach.

4.2 Towards an adapted classification methodology for graded security

approaches in EPU architectures
The application of a “graded security approach” is today an acknowledge d and widely-used
architectural security principle to protect digital systems and critical IT infrastructure in
Electric Power Utilities (EPUs). Different industrial standards, regulations and best practices
apply the method of “graded security approach” b y the introduction of “zoning principles” or
“domain protection structure” and by clustering security requirements in security levels. (See
e.g. the standard IEC 62443 [4-26], the IAEA Technical guidance “Computer in Nuclear
facilities” [4-27], the NRC regulatory guide RG 5.71 [4-28], NERC: reliability considerations
from the integration of Smart Grid [4-29], etc.)
Unfortunately, an integrated classification methodology, classification criteria or a procedure
to successfully implement and maintain a “graded security approach” is to a large extend
missing, as the methodologies provided in the existing documents are not consistent, and
generally incomplete. A recent work from the CIGRE D2.31 working group has listed and
analyzed a large number of these references, and underlined such inconsistencies and
incompleteness [4-30].
This paragraph discusses a practical methodology to implement a “graded security approach.
Further the paper clusters relevant classification criteria and concludes with an example.

4.2.1 A methodology to implement a “graded security approach”

When a “graded security approach” is applied to an IT infrastructure of an EPU, technical,
organizational and physical controls have to be implemented, operated and maintained in a
sustainable way.
A lifecycle framework can be applied to structure the implementation of a “graded security
approach” and to ensure the close integration to the overarching lifecycle methodology in the
implementation and operation of a digital system. The following outline gi ves an overview of
the different phases of an implementation of a “graded security approach” in reference to
lifecycle frameworks like e.g. IEC 61508 Safety Life -Cycle [4-31] or the “security
management life cycle” described in the IAEA Technical guidance “Computer in Nuclear
facilities” [4-27, pp. 15].
a) Concept of a zone model as a base for digital system implementation: A zone model is
the architectural implementation of a “graded security approach” in a technical,
organizational and physical sense. A zone can be understood as a grouping of logical
or physical assets that share common requirements. (cf. [4-29], [4-26]). A zone
includes a set of specific controls, which are applied to all digital systems implemented
in a zone.
In established infrastructures (e.g. plant infrastructure, EPU infrastructure,
vendor/digital system implementations) an architectural concept generally exists. This
architectural concept could also include a zone model based on guiding characteristics
and constraints, like e.g.
 production/operation type (e.g. distribution, transmission, thermal production, nuclear
production, etc.)
 corporate policies and characteristics
 national or international requirements (e.g. NERC CIP [4-32])
 standards or best practices (e.g. IEC 62443-1 [4-26], NRC RG 5.71 [4-28], NISTIR 7628
Guidelines for Smart Grid Cyber Security [4-33], IT-Grundschutz-Standard [4-34])
 vendor blueprints (e.g. [4-35], [4-36])
An existing implementation of a zone model, if sufficient, should se t the fundamental
for a digital system implementation and is the base for the described phased approach
(b)-(f). If a sufficient zone model does not exist in an infrastructure or new
infrastructure is to be established (e.g. new build project) a zone model is to be
defined in phase (d) by grouping of logical or physical assets that share common
requirements and the definition of necessary zone controls. (cf. [4-26])
b) Definition of digital systems or functional scope, which is the object for analysis.
c) Analysis and assessment of digital system and function components: Function and
digital system components are analyzed and assessed to identify requirements and
determinate a possible security level (also sometimes referred as “System
Requirement Specification”). Classification criteria sup port the standardized way to
define requirements and ensure hereby the coverage of relevant parts, like identify
and estimate potential hazards and risks. Classification criteria cluster are for example
risk assessments, impact analysis, technical feasibil ity assessments, architecture etc..
d) Assignment of a digital system to dedicated zone or sub -zone 5 in a predefined zone
model: Based on the results of the analysis and assessment of digital system and
function components digital systems are classified to a dedicated zone to ensure the

—————————
5 “zone or sub-zone” later referred only as “zone”
 general fulfilment of requirements by technical, organization and physical controls
implicated by the specific control set and architecture of a zone. The mapping to a
zone could be described as a part of the high level system design and is therefore part
of the realization phase of the system development.
e) Dedicated digital system controls: Gaps between the identified digital system
requirements and the applied zone control set should be identified to ensure the
appropriate mitigation by dedicated systems controls. If a mitigation by dedicated
systems control is not possible (e.g. tolerable risk is not in the limit) among others
following methods could be applied:
 Re-assessment of systems or surrounding systems,
 adaptation of the specific zone control set,
 re-assessment of the system design, operational model,
 re-assessment of overarching zone model
The gap analysis and the definition of dedicated system control s could be described
as part of the detailed system design.
f) Other phases of a lifecycle, like parts of the realization phase (e.g. start -up
acceptance testing) or operational phase are not further discussed at this point.
Based on the phased implementation of a “graded security approach” this paper outlines key
areas to support a practical implementation of a “graded security approach”:
 definition of relevant classification criteria
 practical methodology to assign systems to dedicated zones
 application of the methodology in an example

4.2.2 Definition of relevant classification criteria

The core of a “graded security approach” is to establish different zones and to assign digital
systems or functions 6 to these different zones. The classification criteria characterize hereby
the requirements of digital systems and have theref ore significant impact on the applied
controls, overarching applied architecture, operation, maintenance, etc..

4.2.3 Discussion on existing standards and best practices

To enable a comparison and a further discussion of classification criteria in current stan dards
and best practices CIGRE WG D2.31 tried to cluster classification criteria. The assumed
clusters are derived from the three layered view of the ArchiMate 7 [4-37] language.
 The business layer is about business processes, services, functions and events of
business units. In the context of a “graded security approach” the business layer is
adapted to criteria like safety, operational relevance, impact to production and
business processes.
 The application layer is about software applications that support the components in
the business with application services. In the context of a “graded security approach”
the application layer is adapted to criteria like application categories, e.g. Data
Acquisition Server, Applications server, Historian, Database, HMI, etc.
—————————
6 “digital systems or functions” later referred only as “digital systems”

7 ArchiMate, an Open Group Standard, is an enterprise architecture methodology and framework to improve
business efficiency.
  The technology layer deals with the hardware and communication infrastructure to
support the application layer. In the context of a “graded security approach” the
technology layer is adapted to criteria like network categories, e.g. control system LAN
Based on these clusters CIGRE WG D2.31 analyzed selected standards and best practices to
classification criteria, zone criteria and/or controls to establish a “graded security approach”.
Figure 1 shows the summary of this analysis showing the focus area o f the different standards
and best practices.
The result concludes that standards and best practice covers and focus on different target
group, application areas and characteristics of a “graded security approach”. Further it could
be concluded, that an overarching normalization of classification criteria does not exist. This
could also apply to a common definition of a control set applied in a "graded security
approach” or common zone model.

Figure 4—2. Focus area of criteria cluster per standard

However, for specific architecture, operation or production areas such as the “smart grid” a
common definition of a "graded security approach” and requirements set could be conceivable
and would establish common security levels, interfaces or compliance rules (cf. “German
Protection Profile for the Security Module of a Smart Meter Gateway” [ 4-38], cf. [4-39])
comparable to other industries (cf. [4-40]).

4.2.4 Practical methodology to classify systems to dedicated zones

Classification criteria should consider all functional, technical, operational and security
requirements of a digital system, function or architecture. A reduction of classification criteria
to a pure security discussion without taking surrounding element s into consideration could
lead to constraints and contradiction of requirements and design principles. For instance,
safety and security requirements may conflict or reinforce each other depending on the
situations [4-41]. Experience has shown that these cause complications, time delay,
unnecessary high costs or technical workarounds in the implementation, operation or
maintenance phase of digital systems in a “graded security" implementation.
Example: Unlike today, where the distribution grid is a collec tion of islands of automation,
without ability to interoperate across their boundaries, the smart grid will enable system
wide integration. On the one hand, this integration is needed to better match energy supply
with demand and to increase self-healing capabilities for example, but on the other hand, by
relying on communication infrastructures and information technology, the power system is
more vulnerable to cyber-attacks. A careful balance between operational and security
requirements has to be met.
The application of classification criteria covering all relevant areas to implement, operate and
maintain a “graded security approach” should mitigate this risk. The framework in Figure 2
shows holistic classification criteria clusters building on a foundatio n of three principles:
technology, business and applications derived from the ArchiMate [ 4-37] modelling language.
The first overlay of these principles addresses behavior, information and structure. Based on
this overlay the outer shell shows eight categ ories covering emergent areas of the “graded
security approach”:

Figure 4—3. Classification criteria categories

 Regulation/Legislation: A digital system has to comply with different regulations and

legislations to comply with local, regional, national or international laws, standards.
 Impacts: Business impact analysis and risk assessments identify the consequences of
possible malfunction of at digital system (e.g. unavailability, unr eliability, data losses,
misuse, etc.) to a business or production process. Outcome of the impact analysis and
risk assessments are reflected in the requirements.
 Safety: A digital system can support safety function, activities and processes. Safety
standards (e.g. IEC 61508 [4-31]) define requirements to these digital systems, which
are reflected in the requirements.
 IT Security: Based on a risk assessment security requirements (e.g. according to
Confidentiality, Integrity and Availability impact analyse s) are defined.
 Physical/Locality: Physical location of a digital system has to be considered and set
requirements to the overarching Zone model, but also to the digital system.
 Architecture: A digital system is based on technical system architecture. Howe ver, it is
also integrated and part of a landscape architecture, which technically enable, but also
put limitation to the digital system. Both common technical and unique technical
requirements are need be assessed.
 Operation/Maintenance: Operation and maintenance model of the digital system, the
technical landscape, or the surrounding infrastructure could set requirements to the
overarching zone model, but also to the digital system.
 Organisation: A digital system is not only integrated in an IT, business or production
landscape, but also into an organizational structure, which enables, but also put
constraints to the digital system.
4.2.5 Application of a traversing path to determine a possible target zone
A success factor to implement an all-embracing “graded security approach” integrated in an
organization, plant or scoped unit is to establish a common classification methodology, which
ensures consistency, give practical guidance, and covers the relevant requirements of the
digital system and the surrounding architecture. The outlined methodology shows a practical
way to implement a graded security approach in an EPU environment.
The basis of the described methodology is a question catalogue covering the relevant areas
of the classification criteria categories. The question catalogue can include multiple questions
per classification category to ensure the sufficient coverage.
Example: To cover the 4R’s of the PERA Enterprise model [ 4-42] the question catalogue
include questions to define the required “response time”, “resolution time”, “reliability” and
“reparability” of a digital system or function.
For every question a possible zone or a range of zones are defined based on the given
answer.
Example: If the required “response time”, “resolution time”, “reliab ility” and “reparability” of a
digital system “DAYS TO WEEKS” the target zone would be “5” by applying the PERA
Enterprise model. If the required “response time”, “resolution time”, “reliability” and
“reparability” “MILLISEC TO SECONDS” the target zone would be according to the PERA
model “1”.
Based on this information (answering of defined questions out of a question catalogue) a
traversing path (cf. [4-43]) can terminate a possible target zone (or range of multiple target
zones). If the result is a range of multiple zones, the “cheapest” zone could be selected. The
“cost” ranking of zones should be adapted to dedicated requirements and constraints. The
Figure 3 visualizes the application of a question catalogue (Q1, Q2, …, Qn), the proposed
target zone (range of multiple zones) based on the answer (A1, A2…, An) and application of a
traversing path.

Figure 4—4. Application of traversing path to determinate a target zone

Sometimes, based on the answers to the questionnaire, no zone can be automatically

proposed. In this case, the design has to be manually reviewed, either by changing the
constraints and hence the answers in the zone selection questionnaire or by choosing the
closest matching zone and applying dedicated system controls. In any case, as a
consequence out of the stringed definition, the result can give only an indication and has to
be manually verified.
4.2.6 Application of the methodology in an example

The example shows the classification of a digital system to a zone model with 4+n zones
based on sample non-exhaustive questions in the area of impact, IT security, safety, and
architecture. The questions and answers are hypothetical, but should give an insight as to
how the methodology can be applied in practice to determinate the proposed target zone.

Figure 4—5. Application of the approach by 6 example question

4.2.7 Conclusion
The success of a “graded security approach” depends on an effective implemen tation,
maintenance and operation. Practical methodologies, guidelines, template and reference to
standards and best practices are needed to ease the setup of a “graded security approach”
and to ensure compliance. An effective practical methodology to intr oduce a graded security
approach in EPU architectures is to design and implement a classification approach that is
directly applicable to the business, technology and applications of the EPU.
In addition to a quicker “graded security approach” design, suc h methodology can remove
burden of the security review by pointing out critical allocation of systems that need some
dedicated controls. For more enforceability of the results, the next step could be to building of
a common definition of a "graded security approach” and requirements set for specific areas
in the smart grid.
5 Work stream 2: Characterization, categorization and modelling of
threats
The objective of the working stream is to discuss and develop:
 graphical attack modelling approaches relevan t for EPUs contexts;
 help consequence analysis of implementing access solutions to the smart grid
networks, and support an optimal deployment of appropriate security
countermeasures;
 the connection between attack modelling and the comprehensive risk analy sis
frameworks to optimize countermeasure configurations.

Following persons have contributed to the work of working stream 2:

 Giovanna Dondossola, Ricerca sul Sistema Energetico, Italy
 Mathias Ekstedt, Royal Institute of Technology, Sweden
 Ludovic Piètre-Cambacédès, Électricité de France, France
 John McDonald, Électricité de France, France
 Matus Korman,Royal Institute of Technology, Sweden
 Roberta Terruggia, Ricerca sul Sistema Energetico, Italy
 Åge Torkilseng, SKS, Norway

The working stream 2 started with the modelling of cyber-attacks for assessing smart grid
security, as a basis for further evaluation of architecture principles.

Smart grid developments will enable numerous new services with new traffic patterns. These
developments will change radically both network accesses and core architectures and
technologies. A smart grid is likely to be topologically complex, to contain vast numbers of
heterogeneous endpoints, participants, interfaces, communication channels, operational
modes and will require operational policies encompassing different domains requiring the
know-how and expertise of IT personnel. These changes could result in a significant number
of new types of vulnerabilities. This will constitute a great challenge for network planners and
operators. It is highlighted in the IEC Smart Grid Standardization Roadmap [5-1], that cyber-
security in particular will play a key role in the efficient and reliable operation of smart grids.
Cyber security requirements have to be derived from risk assessments an d general
architectural decisions. A smart grid reference description (e.g. [5-2]) and security use-cases
are necessary bases for such a work, which will be accomplished in a continuous approach.

Focusing on a weak point of the ongoing cyber security stand ards [5-3], this working stream
initially addresses the characterisation, categorization and modelling of malicious cyber
threats, which represent key steps in a risk assessment process. Following this the work
focuses on the cyber security in smart applic ations for energy grid topologies characterised by
high penetration of distributed energy resources (DER) with renewable generation, storage
devices and controllable loads, and the involvement of multiple active actors across the smart
grid domains.
To illustrate this, a representative use case dealing with the Voltage Control (VC) of active
Medium Voltage (MV) distribution grids will be considered. The role of the VC function is to
adjust the voltage profile on the MV grid to optimise technical and economi c objectives,
sending set points to distributed energy resources and to the distribution grid devices.
The aim of the work is to demonstrate techniques for deriving justifiable estimations of the
difficulty of succeeding with different kinds of cyber-attacks to VC related communication
services within the substation automation system.
Starting with the description of a VC function architecture as a representative use case of
future smart grids, the work focusses on the application of CySeMoL (Cyber Securit y
Modelling Language) to the sample case aimed at the evaluation of the adequacy of the tool
to the smart grid sector. The CySeMoL methodology is applied to describe the grid ICT
architecture (networks, operating systems, services, protocols, data flows, a nd more), the
security measures and the source and the target of the attack. The CySeMoL modelling
approach is based on the attack graph formalism and provides justifiable quantitative
estimates on the likelihood that different attack paths will be success ful. In this work
CySeMoL will be used for estimating the likelihood of certain attack processes affecting the
VC functions, including attacks caused by the remote maintenance procedures on the VC
devices.
This work will start by presenting in Section 5.1 a conceptual model expressing the meaning
and the links between the key concepts of cyber security risks. Following this, the work
examines attack modelling, addressing some pertinent technical and architectural issues.
Section 5.2 explains why attack modelling is central to risk assessment, and subsequently
graphical approaches to attack modelling are presented in Section 5.3. In the second half of
the work, the significance of attack modelling for smart grids is demonstrated. A reference
architecture for smart grid use cases is presented in Section 5.4.1 as a basis for the
application of attack modelling, while in Sections 5.4.2 and 5.4.3 the connection between
attack modelling and security analysis is discussed by using attack tree and CySeMoL
formalisms. The work concludes in Section 5.5 by summarizing the work presented and the
issues still to be addressed.

5.1 Conceptual model of key concepts of cyber risk

The domain of cyber security risk is characterized by the use of complicated and sometime
confusing terminology and concepts. The domain makes use of abstract and conceptual
words such as threat, risk, impact, attack, vulnerability, exploit, countermeasure, intrusion,
mitigation, security, availability, integrity, confidentiality, and non -repudiation, and others.
These words are often mixed with somewhat more concrete and tangible words such as
spoofing, sniffing, distributed denial of service attack, firewall, intrusion detection system,
intrusion prevention system, patches, insider, cracking, phishing, a nd others. It is easy to get
confused by this mix of terminology. Although attempts have been made to unify the security
vocabulary, there is still no common single vocabulary or dictionary. Instead, several of these
words have changing or even overlapping meanings, depending on context. Furthermore,
implicit, unstated relationships can exist between these terms.

Conceptual models have been proposed in order to attempt to clarify such relationships.
Perhaps the most commonly cited is the one adopted in the ISO/IEC Common Criteria (CC)
standard [5-4]. The relationships between fundamental security concepts proposed by this
model are depicted Figure 5-1.

Figure 5—1. Conceptual model from Common Criteria [5-5]

The CC model has some limitations. Its purpose is not to be a common dictionary. Instead it
offers a method to specify functional security requirements and evaluate the assurance of
their fulfilment on a graded scale. Despite this, the CC conceptual model has gained
popularity for a wider purpose. For example, it is possible to use this conceptual model i n the
context of cyber security for power systems. In this context the “owners” are generation,
distribution, and transmission companies, or other actors s uch as markets and customers.
The term “assets” can describe primary equipment and the process itself (e.g., the
transmission and distribution of power). Likewise, secondary equipment such as IT
infrastructure and software are types of “assets” even if th ese components have a lesser
explicit value to the owners. The CC conceptual model separates “threats” and “threat
agents”. “Threat agents” refer to any type of potential attacker ranging from script kiddies to
eventually nation states posing targeted or untargeted threats. In contrast, “threats”
represents potential breaches in the confidentiality, integrity or availability requirements of
various assets. “Risk” is then the combination between the likelihood that threats are actually
realized (by some threat agent) and the associated consequences. The presence of
“vulnerabilities” in the system, such as implementation flaws as well as configuration flaws,
makes it more or less easy to realize the “threat”. Finally, “countermeasures” are any
functions that operate to mitigate vulnerabilities and thus reduce the risk, including IT security
equipment such as firewalls or intrusion prevention systems or non -IT security functions like
physical perimeter protection or staff security awareness education. Although u seful, the CC
conceptual model has been found to be insufficient. First of all it does not provide a complete
list of security related concepts. Moreover, even though it outlines relationships among the
different concepts, the relationships capture only very vaguely any causal dependencies. For
example, one can see that countermeasures reduce risks, but the CC model does not specify
which countermeasures are reducing what kind of risks or the effectiveness of the
countermeasure under different circumstances. These missing details, however, are crucial
for the implementation of cyber security risk assessment in an industrial and practical setting.

An alternative conceptual model has been developed to address some of those specific
shortcomings using the Cyber Security Modelling Language (CySeMoL) [5-5], cf. Figure 5-2.
CySeMoL is a domain specific language, a meta-model, which allows modelling of ICT
architectures. CySeMoL is aligned with CC model but in addition considers explicitly causal
dependencies between concepts in a probabilistic way. This is achieved by classifying the
security concepts in the forms of either explicit “entities” or as “attributes” of these entities (in
the same way as modelling languages such as Unified Modelling Language). The entiti es are
related with semantic entity relationships and the attributes are related with their causal
dependencies. The language CySeMoL is built up around “attack steps” that are targeting
“critical cyber assets”. “Attack steps” have some likelihood of being accomplished
successfully (Possible To Accomplish attribute) and the “assets” have certain value,
“expected loss”, to an “owner”. The owner value thus represents the relation to primary
equipment which makes a certain cyber asset worth while protecting . The product of that
value and the likelihood that an attack is successful yields an expected loss that corresponds
to the CC concept of risk. A distinction exists between the CC model and the CySeMoL
representation in the way that “threats” are characterize d. Within CySeMoL a “threat” is a
specific attack scenario consisting of a set of “attack steps”. “Threats” are raised by “threat
agents”. Importantly, as “attack steps” incorporate a probabilistic dimension, a “threat”
indicates the likelihood that a set of attack steps are successful given that they are attempted.
All the individual attack step probabilities are based on a combination of knowledge elicited
from domain experts and previously published academic research studies (where such exist).
The attacker is assumed to be a professional penetration tester with one week of preparation.
Finally, “attack steps” can be more or less effectively mitigated by “countermeasures”. The
representation used for “countermeasures” is a second key feature of CySeMoL. “ Counter-
measures” are a special kind of “assets” which have the purpose of protecting other “assets”.
CySeMoL differentiates between five different types of countermeasures:
 Contingency - which operate only after an attack is successful, e.g. back -ups;
 Preventive - which the attack harder to accomplish, e.g. firewalls and access control;
 Detective - which merely register attacks and set off alarms , e.g. intrusion detection
systems;
  Reactive - which are a mixture of detective and preventive countermeasur es and
incorporate sufficient intelligence to actively take precautions under attack; and finally
 Accountability – which do not mitigate an attack as such but it collects information
about it. This will have a causal impact on the attack success rate sinc e a good
accountability defense is expected to scare off threat agents who like to minimize their
risk of being caught.

0..* Association
Owner 1..*
0..*
Value
ExpectedLoss
ContingencyCountermeasure Asset
ExpectedLoss SUM

Functioning ExpectedLoss

Countermeasure
ExpectedLoss

Functioning

PreventiveCountermeasure OR
ExpectedLoss Threat
0..*
Target
Functioning
AttackStep IsRealized

ReactiveCountermeasure
ExpectedLoss PossibleToAccomplish AND PossibleToAccomplish

Functioning

Activated IsDetected IsAttempted

OR
DetectiveCountermeasure Leaves accountability
ExpectedLoss 0..* Includes

Functioning

1..*
AccountabilityCountermeasure
ExpectedLoss

Functioning
1
ThreatAgent

Resources GiveRiseTo

Figure 5—2. The Cyber Security Modelling Language

It is clear from the preceding discussion that CySeMoL represents an example of reference
models that is trying to establish a more rigorous terminology for communicating, modelling
and analyzing cyber security. That said, it will remain important in the short term to define a
clear conceptual framework for each work environment. While the following section focuses
on the clarification of attack processes, similar clarifying work may be needed for many other
concepts.

5.2 Why attack modelling is central to risk assessment

A key objective for a power grid operator is to reduce the impact of threats to the delivery of a
continuous supply of electricity. Threats to the grid operation include weather related events
such as storms or heavy snowfall, failures of primary equip ment and, due to the increasing
dependence on ICT, also the failures of secondary equipment due to, for example, software
bugs or failing communication equipment. A special kind of operational threat, often classified
as security risks, are antagonistic threats such as vandalism, terrorism or even acts of war.
The 2010 Stuxnet worm [5-6] incident has demonstrated undeniably the pertinence of
antagonistic threats originating from the cyber domain to industrial control systems. This
underlines the importance of considering cyber threats in the larger risk analysis and
management processes at power utilities.
Irrespective of the conceptual framework used, a cyber-security risk is generally formulated in
two parts. It consists of the evaluation of the consequenc e of a malicious threat and the
assessment of the likelihood of the realization of the threat. The evaluation of consequence is
often more straightforward and consequences are often translated into a monetary value
(although less quantifiable outcomes, such as death or lost trust in an organization, can also
be considered within a holistic view to risk). The evaluation of the likelihood of threat
realization is a more complex process depending on both the likelihood that an attack is
successful and the likelihood that the attack is attempted. In either case, these elements
depend on the properties of both the attacker and the ICT infrastructure.

This dependence is important. It highlights, from the perspective of cyber security decision
makers in utilities, what can be controlled through choice of the ICT infrastructure. For
example, the consequences of attacks, although affected by the countermeasures in the ICT
infrastructure, depend primarily on the operational conditions decided by the business of the
utility. Likewise, the skills and behavior of the threat agents, from the perspective of the cyber
security decision maker, are observable but no controllable. The likelihood of threat
realization, however, can be affected by the ICT infrastructure selection . Thus it is natural that
any decision support methodology or tool is focused on this aspect. Irrespective of whether
the decision maker is a TSO acting in a country facing the threat of a war, or a small DSO in
society with a low level of criminality, the decision process often focuses on how many
countermeasures are enough, in response to the likelihood of threat realization.

Unfortunately the dependence between different types of attacks and countermeasures in

various ICT infrastructures are not well covered in the many standards and compliance
documents in the field. Roughly they can be seen as a long list of individual good practices.

The key then to understand how to optimize the security of the ICT infrastructure lies in
understanding the different vulnerabilities in the system as a whole. An efficient approach to
this is to model and examine different attack scenarios to the system. Attack scenarios are, in
essence, the steps that an attacker needs to take to realize a threat. Their description can b e
textual, but also graphical. Originally, graphical attack modelling focused purely on technical
issues. The techniques have since been extended to include “softer” organizational aspects
since security is a system level property. E.g. a technically exce llent access control solution is
negated if anyone can call the helpdesk and get an account. In the next section we will now
look at methods for graphical representation and comparison of attack scenarios.

5.3 An overview of graphical attack modelling techniques

Graphical attack modelling formalisms enable the visual representation of the different
scenarios that an attack may follow to achieve their objective, thus supporting the analysis of
the scenarios. Attack trees can take the point of view of an attacke r, the system/organization
under attack, or that of a neutral party. Defensive aspects may also be integrated in order to
evaluate counter-measures efficiency. Model treatment may be only qualitative but may also
address quantitative aspects.

Numerous graphical attack modelling formalisms are available. The most known and widely
used formalism is probably the attack tree methodology [5-7]. Inspired by the fault-tree
formalism commonly used in dependability, attack steps and techniques are organized in a
Boolean logical tree, with the attack objective as the “top -event” (root) - cfr. Fig. 5-3. Attack
trees have been applied to a range of different kinds systems, including EPU -related ones,
like SCADA systems [5-8][5-9], smart metering systems [5-10] or safety automation in nuclear
power-plants [5-11].

Complementing attack trees are several more academic formalisms for attack modelling.
These include Petri-net based approaches [5-12][5-13], Bayesian network-based approaches
(see [5-14] for a SCADA-system oriented example) or UML-oriented ones like abuse cases [5-
15] or misuse cases [5-16].
Each of the available methods offers a different trade -off between readability, scalability,
modelling power and quantification capabilities. For instance, attack trees are ea sy to read
but are not very powerful, being a static formalism. On the opposite, Petri net -based
approaches are very powerful, but difficult to handle for non -specialists of these formalisms.

Considering such diversity, it comes as no surprise that each of the authors was more
particularly familiar with a specific method. For instance, RSE employs a state -diagram
approach for modelling attack experiments [5-17], illustrated by Fig. 5-4, which can be seen
as the horizontal explosion of an ordered goal-tree with timed transitions [5-18]. Alternatively,
EDF R&D has developed a formalism called BDMP [5-19] which, although visually close to
attack trees, enables the modelling of dynamic characteristics such as sequential attack
steps, detections and reactions. An example is given in Fig.5-5. The formalism has been
adapted from the dependability area [5-20], it supports diverse treatments which cannot be
made in classical attack trees. Finally, KTH has developed a Probabilistic Relational Model
(PRM) for cyber security risk analysis [5-5], shown in Figure 5-2, which enables attack step
representation while providing a broader framework supporting risk computations on an
instantiable UML-like class diagram.

AND
RAS compromised

OR
Wardialing RAS access granted

OR AND
Authentication with password Vulnerability_found_and_exploite
Vulnerability found and exploited

Bruteforce Social engineering Find vulnerability Exploit vulnerability

Figure 5—3. Attack tree on a dial-up Remote Access Server (RAS)

Figure 5—4. Typical RSE attack state-diagram

 RAS compromised

AND

Logged into the RAS

OR

Wardialing RAS access granted

OR AND

Authentication with password Vulnerability found and exploited

Force brute
Social engineering Find vulnerability Exploit vulnerability

Figure 5—5. BDMP modelling of the RAS attack (with sequences represented by the red arrows)

For qualitative evaluations, the simple process of making use of graphical modelling approach
enables a simpler evaluation of likelihood, which can then be based on tangible and visual
representations. Expert discussion and debates are easier, and the diversity of the potential
attack paths is more clearly understandable. For complementary quantitative analysis,
different numerical parameters can be added to the model s, including probabilistic ones,
depending on the attack modelling technique chosen. More globally, attack modelling can also
help further in the risk assessment process and in particular aid the identification of the
vulnerable part of the security architecture and overall organization: Specific attack steps or
techniques may appear in many scenarios and for different attacker goals, pointing priority
weaknesses for treatment. Automatic model processing can in some cases help the analyst in
this task, depending on the modelling approach adopted.

In complement to the above discussion, more detailed examples of the use of attack trees are
available. Several risk assessment methodologies (mainly from the USA) explain in details the
use of attack trees in the risk evaluation process. Concrete examples include the case of
SQUARE (Security Quality Requirements Engineering), developed by Carnegie Mellon
University [5-21], or MORDA (Mission Oriented Risk and Design Analysis), defined by the US
National Security Agency, and mainly used in the Defense industry [5-22][5-23]. Coming to a
more EPU-related domain, a recent US regulatory guide on cyber security of nuclear power
plants also mention the use of attack trees in risk analysis [5-24].

As a first step, the attack tree formalism will be used to represent attack scenarios on the
reference architecture of the voltage control function described in Section 5.4. Such a choice
has been made, not for a hypothetical superiority with respect to the other formalisms, but
because attack trees provide the most readable and accessible representation in the context
of this work. As a second step the usage of the CySeMoL tool is presenting showing the kind
of evaluations from its underlying modelling method.

5.4 Security analysis of voltage control in active distributions grids

5.4.1 Reference architecture

The operation of active distribution grids with high penetration of DER, connected to MV bars
and feeders, requires the implementation of a new VC function (cf. Use Case WGSP -0200 in
[5-25]). In MV feeders including distributed generation, the power injected by DERs can lead
the voltage beyond the limits in some parts of the grid, mainly due to uncontrollable
generation from renewable sources. Control actions limited to the OLTC (On Line Ta p
Changers) of the substation transformers and compensation measures, as usually operated in
passive grids, may be not sufficient to meet the supply requirements established by the norm
EN 50160. Voltage profiles in the MV grids may be adjusted acting also on DERs connected
to the MV feeders and substation devices as capacitor banks and storage devices.

Figure 5-6 presents the main components of the grid control architecture involved in the VC
function. By focusing on the HV/MV substation, the figure highli ghts the need of a new VC
function performed by a station level control system (called Substation SCADA). The main
control loop of the VC function is based on substation – centre, intra-substation and
substation-DER communications. Given the grid topology, field measurements, market prices
and resource operation costs, the VC function optimises the voltage profile computing and
sending appropriate set points to the third party distributed energy resources (generators,
flexible loads and storages) and distributor's devices (i.e. capacitor banks and OLTCs). The
algorithm is based on an AC Optimal Power Flow where grid losses and integral constraints
are taken into account. The status of the grid, required by the control algorithm, is computed
by a State Estimator function, based on actual measurements and grid topology.

Figure 5—6. ICT architecture of the Voltage Control function

The management and the security administration of the centre and substation ICT
components and networks are performed by the DSO ICT Control Centre. It has direct access
to network and control components, except substation IED elements and DER components.
The data flows for the remote management of communication and control devices are based
on secure operations using, e.g. HTTPS and SSH protocols.

According to the architectural layout in Figure 5-6, the supply chain of the VC function
depends on several communication links involving remote accesses from systems outside the
perimeter of the DSO organisation. In particular the VC application in the substation has
communication links with third party DERs, possibly deploying heterogeneous communication
technologies available in different geographical areas. From the operation stand point, the
optimization function has to receive voltage regulation requests by the TSO (Transmission
System Operator) whenever a transmission grid contingency needs to apply preventive
measure to voltage collapse. Load and generation forecasts are used to optimize the
operation of distributed devices, while the economic optimization is based on market prices
and DER operation costs.
The information exchanges of the VC function would map onto the IEC 60870 -5-104 protocol
(for centre-substation communications) and the MMS profile of the IEC 61850 standard (for
the intra-substation and substation-DER communications).

By focusing on the core of the MV regulation scheme, it results evident that the correct
elaboration of the optimal set points depends on the provision of correct operation and
economic data from the above communication channels [5-26]. A malicious attack to one of
the above communication links may cause the loss of generation forecasts, economic data
from the market, TSO requests, topological changes, oper ational data from the DMS, the
introduction of faked generation forecasts, economic data from the market, TSO requests,
topological changes, operational data from the DMS, monitoring data or set points. The
effects of communication attacks may lead the regulation function either to diverge from
optimum set points or, even worse, to produce inadequate set points with cascading effects
on connected generators. The objective of the security countermeasures integrated in the
architecture is to meet the VC availability and integrity communication requirements, i.e. to
undo data losses and to avoid injection of spurious messages.

5.4.2 An example of attack tree

Typical cyber security risk analysis requires the identification and the hierachization of critical
functions and associated supporting systems to protect. Such results take into account both
the potential consequences and the likelihood of disruption to the functions and associated
systems. Previous work done in Cigré WG D2.22 have already described and reviewed
different risk analysis methodologies, ref. [5-27] while a generic framework can be found in
ISO/IEC 27005 on an information security standpoint [5-28]. With respect to the smart-grid
use-case presented previously, it is assumed that a preliminary risk an alysis process has led
us to focus on the substation automation and in particular the correctness of the VC bay -level
function.

The role of the VC function is to adjust the voltage profile on the MV grid to optimise the
stated technical and economic objectives, sending the respective commands to the distributed
energy resources and to the distribution grid devices (e.g., capacitor banks, OLTC switches,
MV feeders). Several information flows are required consisting of the exchange of grid
topology, field measures and market prices. The limited measurements available from the
field mean that there is a need to complete actual measures with measurements computed by
a state estimator function. The function also takes into account the forecasts of distributed
generation production and consumption by intelligent loads. In the hypothesised architecture,
the generation forecasts are assumed to be provided by an external system communicating
with the central DMS, whilst the load forecasting is a function provided by t he DMS itself.
Finally, the Transmission System Operator (TSO) may also send signals to the VC control
system in order to implement defense actions dealing with a general stability of the
interconnected grid.

The following Figure 5-7 provides a generic input/output view of the VC function. This figure is
complementary to and coherent with the arc hitectural diagram shown in Figure 5-6. The
information flows have been simplified to assist the development of the attack model.
 DMS / SCADA
TSO Information
State Estimation

Market Data
VPC Function Local measurements
Generation
Forecasts

DER / OLTC

Figure 5—7. A generic input/output view of the Voltage Control function

Consider now the characterisation of the likelihood of attacks targeting such a function. In this
process, graphical attack modelling techniques such as described in Section 5.3 can provide
precious support. This is achieved on a qualitative point of view by enhancing the analysis
coverage regarding the attack scenarios and techniques and also by clarifying the potential
vulnerabilities taken into account. Depending on the selected technique, quantitative analysis
can also complement and feed in the likelihood evaluation process in order to compare and
classify likelihoods of other scenarios in the overall risk analysis. Starting from the gener al I/O
representation of the VC function in Figure 5-7, attack scenarios leading to incorrect VC
function results can be grouped in three categories, each of which will be reflected in the
graphical attack model. The attack scenarios include:
 attacks on inputs of the VC function, either on the source or the messages
themselves;
 attacks on the system processing the function;
 attacks on the output of the function.

Fig. 5-8 gives a high-level attack tree representation following such a break -down. The top-
level branches and gates correspond to the high-level categories of attacks previously
described, plus a gate accounting for attacks on legitimate remote entities. Detailed sub trees
should be elaborated and connected to this structure, in order to represent c oncrete attack
techniques and vulnerability exploitation. These lower level decompositions require a vision of
the communication infrastructure, such as is shown in Figure 5-6. Figure 5-8 presents some
initial stages in the decomposition of an attack proce ss leading to the on-line corruption of
needed input messages of the VC function. Under the OR gate “input messages modification”,
Figure 5-8 illustrates a possible approach to the corruption of the information sent by the
TSO. Such network-centric attacks may include specific spoofing and forge techniques, as
well as gaining access to the actual communication channels. Alternatively, an intrusion
process might be used to attack the system processing the function. The intrusion process, in
turn, could be broken down into intermediate steps such as: violation of the local access
control measures, interception and then use of remote access credentials and finally
corruption of process. As indicated on the figure, the modelling of the specific attacks requires
greater technical details of the communication architecture (c.f. Figure 5-6). In either case,
the hierarchical nature of the Boolean tree notation enables different depths of representation
for these elements. Moreover, if the dynamic aspects of the attac ks (i.e. the order and timing
of the different attack steps) are deemed important, the simple attack tree representation may
be substituted by dynamic modelling techniques (cf. Section 5.3).
 High level attacker
objectives/targets VPC dangerous results
(cf. Fig. 7)
OR
VPC corruption (bad results)

OR OR OR
Attacks on legitimate
Attacks on I/O communication messages VPC function direct modification
remote entities
(substation attack)

OR OR OR AND
Output messages Input messages
modification modification

[Attack tree cut for space reasons] [Attack tree cut for space reasons]
AND

TSO Router attack

OR
Attack step 1
Attack step 2

Technical attack steps, […]

Close to architecture
(cf. Fig. 6) Admin pwd bruteforce Social engineering Alt. attack technique

Figure. 5—8. Attack tree fragment

5.4.3 Voltage control architecture in CySeMoL

The main concepts modelled in CySeMoL are the following. First, each local area network
(e.g., DSO area control centre) is modelled as a network zone, assuming full reachability
between arbitrary hosts (e.g., services, applications or operating systems) located within the
network zone. Network zones are interconnected through gateways, with which firewalls and
intrusion detection systems can be associated. Second, within each of the network zone s and
across them, there are services, applications and operating systems (i.e., software
installations), each corresponding to a software product. Third, services, applications and
other software installations can connect to and communicate with each othe r. This is
modelled by data flows and protocols, while data possession is modelled by data stores.
Fourth, there are human users having access to systems, which can be protected through
authentication – access control points, authentication mechanisms and user accounts. Finally,
network zones can be associated with physical zones and zone management processes. For
a more elaborate description of CySeMoL, cf. [5-29]. CySeMoL with its related software tool
can be downloaded 8 online.

In order to reduce the scope of the analysis, this work covers the DSO Area Control Centre,
DSO Substation, DER and DSO ICT Control Centre, together with their interconnections and
related information flows. As for the security measures, the capability of firewalls in
interconnecting gateways, gateway-to-gateway network layer VPN and end-to-end transport
layer security, as prescribed by the Part 3 of the IEC 62351 standard [5-30], are
comparatively evaluated by means of CySeMoL runs.

Regarding the attack scenarios, this work focuses on attack processes exploiting
vulnerabilities in the remote ICT maintenance accesses to the substation SCADA and
—————————
8 http://www.ics.kth.se/cysemol
targeting the generation of faked set points. The tool will evaluate the success probability of
the possible attacks sorting them by decreasing probability. The vulnerabilities/actions
exploited/performed by the attack process getting the highest scores will be then considered
for further protection of residual risks.

The ICT architecture under evaluation is separated into four logical zones: D SO ICT control
centre; DSO area control centre; DSO substations; and DERs (see Figure 5-9). Each of these
logical zones corresponds to a network zone (local area network) and a physical zone in
CySeMoL.

We model and evaluate three variants of implementing substation communication briefly

depicted in Figure 5-2. In all of the variants, there is a single gateway in each substation,
which connects the substation’s local area network (LAN) with all other immediate networks.
The variants differ by use of different configuration of virtual private networks (VPN) for
protection of communication. They are described in the next section.

Figure 5—9. Services and applications in the ICT architecture

From the DSO ICT control centre, ICT technicians maintain the ICT infrastructure of the DSO.
The centre also hosts a few services that support the ICT infrastructure and maintenance
activities. We therefore assume that the centre hosts the following systems: (1) asset
management system; (2) time server; (3) domain directory service; and (4) update and
configuration management server. In addition, applications for remote access and
maintenance are used from the centre. The DSO area control centre, from which the power
grid is supervised and controlled, hosts SCADA system and its components: SCADA server;
historian; front end; and a human-machine interface (HMI). At each of the substations, there
is a local SCADA service, intelligent electronic devices (IEDs), and a local HMI (fo r
maintenance purposes). At each of the DERs there is an IED and a local HMI, too. Each of
the centres connects to their respective outside networks through a gateway with firewall.
Figure 5-9 provides an overview of the ICT architecture with regards to se rvices and
applications run in/from their respective networks. Each of the systems is modelled as
consisting of a service or an application client, and an operating system, on which it runs.
These are connected to their respective network zones.
The systems mentioned above interconnect and interoperate, even across their respective
network zones. We therefore model data flows and corresponding protocols as follows. Time
synchronization is done using the network time protocol (NTP). All of the operating syst ems
used within DSO synchronize with the time server placed in the DSO ICT control centre. The
time server, as well as the operating systems in DERs, synchronizes directly with an Internet
source. Directory services are used for hostname resolution and acc ess control within the
DSO domain. Interconnected applications, services, and their underlying operating systems
use directory services from all of DSO’s networks (thus excluding DERs). The protocol suite
used is X.500. Process automation happens between the substations and the DERs (DER IED
vs. substation SCADA), within the substations (substation IED vs. substation SCADA),
between the substations and the DSO area control centre (substation SCADA vs. control
centre SCADA frontend), and within the DSO area control centre (SCADA server vs. SCADA
frontend, historian and HMI). Intra-substation communications and those between substations
and DERs use the IEC 61850 standard (MMS and GOOSE profiles). The central SCADA
system interoperates with the substation-level SCADA using the IEC 60870-5-104 protocol.
Process maintenance at substations is performed by operators from the DSO area control
centre, as well as technicians directly at the substations. The former happens through the
central SCADA, and uses the IEC 60870-5-104 protocol. The latter happens through the
substation HMI, which communicates with the substation SCADA. ICT maintenance is done by
ICT administrators at the DSO ICT control centre. The administrators can log in to arbitrary
operating system equipped with a remote access service. Remote access takes place using
the SSH protocol and SSH-tunnelled VNC protocol. Update operations are performed through
the update and configuration management server, to which most of DSO’s operating systems
connect. Although some systems are configured to update automatically (e.g., workstations,
and some ICT management servers) while others need administrative intervention (e.g.,
servers hosting process-sensitive services), all of the systems download update lists and
updates from the update server using either Microsoft Windows Update (MS -WUSP protocol),
or HTTPS based access to update lists and update packages (Linux systems). Finally, the
SCADA HMIs both at the DSO area control centre and the substations interoperate w ith the
asset management system located in the DSO ICT control centre, to seamlessly provide
product information to operators and technicians upon need. This interoperation uses web
services based on the HTTPS protocol.
Regarding access and authentication, we have assumed that there are three users – an
operator (at the DSO area control centre), a technician (at substation level), and an ICT
administrator (at the DSO ICT control centre). The account details and access credentials of
these are stored in the domain directory service, as well as locally at the computers they use,
where the authentication usually takes place.
All of the above described parts of the ICT architecture were modelled in CySeMoL. An
excerpt of a part of the total CySeMoL model is pro vided in Figure 5-10.
To model the configuration and properties of the ICT architecture, we made numerous
assumptions and choices in attempt to reflect typical configurations of networks, protocols
and systems. For most of the modelled entities mentioned a bove (e.g., services, operating
systems, gateways, zone management processes, etc.) there are a number of parameters,
based on which CySeMoL also evaluates cyber -security dispositions. Our assumptions are
briefly described in table 5-1.
 Figure 5—10. Supervision data flow between the SCADA frontend in the control centre and a substation-level
SCADA (together with a few surrounding entities) as modelled in CySeMoL

Subject Assumptions
Both workstation and server On many systems (but not all) a host firewall is present and
operating systems functioning. In particular substations and DERs devices could not be
equipped with a well configured firewall
Workstation operating In centre domain they are generally up to date, and use recent
systems operating systems (i.e., Windows 7 as compared to Windows XP or
older). Although workstation systems are proprietary (as opposed to
open-source), binaries are obtainable by antagonists, since the
systems are well known and widely used (e.g., Windows). Substations
and DERs components could not be updated
Server operating systems Systems are usually well patched and use recent operating systems
(usually Linux based, thus open-source). Systems sensitive for control
of the electrical process (including those at substations) are an
exception, since frequent regular updating of systems sensitive for
process control poses high verification demands and
stability/compatibility risks, based on which such updates are seldom
performed.
Switches and gateways In the control centres, gateways use static ARP tables and switches
(network infrastructure) use port security, which disallows unknown network interface units to
connect.
Remote access client They are generally up to date (having recent patches applied).
 Subject Assumptions
applications
Enterprise-level systems They are proprietary, and thus source code is not available to the
(e.g., asset management attacker.
system) and SCADA
systems.
Infrastructure systems (e.g., They are open-source, as well as using on open-source protocol
NTP server, remote access implementations (e.g., SSH).
services)
Services and applications Applications and services such as those for remote access, similarly to
operating systems, have undergone considerable cyber securit y
scrutiny and improvements within their development life cycle. This is
not the case for process control services and applications, which are
heavily verified regarding baseline functional correctness and process -
robustness, rather than cyber security.
Network management Network management is generally working according to best practice in
the DSO ICT control centre. Somewhat less so in the DSO area control
centre, where regular updating is not present for all systems, and
regular security audits also are uncertain. On the substation level,
regular log reviews do not take place, in addition.
Security awareness Security awareness program takes place for ICT maintenance
program personnel and the control operators. For technicians working on
substation level, it is uncertain.
Communication protocols Remote access protocols and protocols based on SSH, TLS or SSL,
such as HTTPS, are both encrypted and cryptographically
authenticated, as well as freshness indicated. Process control protocols
are neither encrypted nor cryptographically authenticated. Network time
synchronization protocol does not use any cryptographic techniques.
Domain services (X.500) and Windows Update (MS-WUSP) use
cryptographic authentication, but not obfuscation (communication
encryption). Process control communication protocols are neither
encrypted nor cryptographically authenticated.

Table 5—1: Brief description of assumptions made for the CySeMoL model

We hereby present the evaluation of three variants of the ICT architecture presented above, as
summarized in table 5-2.

Variant Configuration specifics

Variant 1 An IPsec based network-to-network VPN protection is handled by gateways, and only
covers communication flowing through the intermediary networks.
Variant 2 As in variant 1, except that the VPN only covers DSO control network and DSO ICT
management network, not the DER control network.
Variant 3 A TLS-based VPN is following a host-to-host scheme, and so protects communication
flowing through the intermediary networks, as well as the local networks.

Table 5—2: Description of the evaluated variants of the ICT architecture

5.4.4 Security evaluation using CySeMoL

For each variant of the ICT architecture we analysed seven attack targets. The targets were
chosen according to their assumed sensitiveness to the potential of cyber -sabotaging the
electrical process in the smart grid. The attack targets are listed in table 5-3. There are two
types of attack sources. First, we modelled outsider attacks. The outsider -attacker was
modelled as someone equipped with a computer and able to access in a malicious manner to
an intermediary network (i.e., DSO control network, DSO ICT management network, and DER
control network). Second, we modelled insider attacks. The insider -attacker was modelled as
someone able impersonating an ICT administrator, who had access to the remote access
application and a respective workstation operating system in the DSO ICT maintena nce
network.

For every single pair of source and target of the attack there exist a large number of potential
paths. For every scenario we are only considering the most likely attack (the easiest attack
according to CySeMoL). In Fig. 5-11 one such attack scenario is visualized. In this particular
example the starting point of the attack is assumed to be the DSO Control Network (framed
with a yellow rectangle), where the attacker has gained access. The target is the DSO Control
Center SCADA Front End (red rectangle). According to the calculations the most probable
path in would be that there first is a poorly configured firewall in the DSO Area Control Centre
(which assumes that we don’t have full understanding of its actual state) (step 8 – there is a
35% chance that this attack step is reached). After that it is assumed to be able to connect to
the SCADA front end without any problem (steps 9 and 10 – still a 35% chance to succeed).
Next, there is a chance that there exists a high severity vulnerability (ac cording to the CVSS 9
[5-31]) in the Front End service to which it also exists an exploit readily available that the
attacker gets hold of (steps 11 through 14 – there is a 32% chance that the attacker has such
an exploit). (Again this assumes that we do not have the exact knowledge about such
vulnerability and exploits exist for the Front End.) Finally, the attacker launches an arbitrary
code execution attack and by doing this achieves full control over the operating system
hosting the Front End (steps 15 through 17 – the final probability of reaching this state is 5%.
It is assumed that if the arbitrary code attack is successful, which in itself is quite low
probability, it also gets full access to the operating system.).

Figure 5—11. An example of an attack path visualized in CySeMoL. Attack steps are ordered according to
numbers on the arrows and the cumulative likelihood of succeeding the attack is visualized after the
attack step (attack steps 1-7 have been omitted for the sake

In table 6-3 the end results (attack probabilities) for all scenarios are displayed – both for
outsider and insider attacks (in parentheses). For clarity, they are also plotted in figure 5 -12.
We explain the results below.
—————————
9 http://www.first.org/cvss/cvss-guide.pdf
 Probability of the conditional success of
the attack for outsider (insider) in:
Attack target Variant 1 Variant 2 Variant 3
SCADA HMI in the DSO area control centre .15 (.4) .41 (.4) .08 (.4)
SCADA frontend in the DSO area control centre .05 (.4) .47 (.4) .09 (.4)
Substation-level SCADA .11 (.38) .13 (.38) .11 (.38)
Substation gateway .17 (.19) .21 (.19) .21 (.19)
Control communications between the area control .33 (.38) .99 (.38) .17 (.05)
centre and substations
Control communications within substations .32 (.37) .98 (.37) 0.0 (.05)
Control communications between substations and .32 (.37) 1.0 (.37) 0.0 (.05)
DERs

Table 5—3: Results of the CySeMoL evaluation

Figure 5—12. Plotted summary of results of the CySeMoL evaluation

The results show that variant 2, which does not use a VPN protection for communication
across the DER control network (i.e., between substations and DERs), appears by far least
secure. As the outsider attack initially propagates through the process control data flows, the
process communications appear highly exposed, resulting in almost certainty of being
compromised (if an attack is attempted). Consequently, the SCADA frontend and the SCADA
HMI at the DSO area control centre become notably easier targets. The substation -level
SCADA also appears more exposed. The second worst scoring variant is variant 1, which on
the other hand appears considerably more secure than variant 2 – thanks to no major
shortcoming such as a missing communication protection on an untrusted network. Realizing
the VPN protection in a host-to-host fashion (as is the case for TLS VPN), which normally
protects the communication anywhere outside the source, the destination host and the VPN
concentrator (gateway), appears to lead to the attacker’s inability to compromise such data
flows from positions other than the two hosts themselves. All in all, the evaluations show that
VPN protection is an important countermeasure in s uch architecture, and that the protection
of TLS VPN is superior to that of IPsec VPN, since it protects larger parts of the
communication.

5.5 Conclusion

The purpose of the working stream has been to demonstrate that graphical attack modelling is
both a relevant and viable method for cyber security analysis of control system architectures
for future smart grids. Attack modelling comes in many flavours and in this work one of the
simplest approaches, attack trees, has been applied in an example. The work has i ndicated
the value of this easy-to-use approach as a mean to obtain a first holistic understanding of
strengths and weaknesses of a system architecture solution. A model such as this can be
expanded, both in detail and in scope, when needed.
Cyber security analysis of ICT architectures is becoming more and more relevant in future
smart grid applications, characterised by multiple and heterogeneous communication links for
critical grid control systems. The application of modelling and evaluation tools suppor ting
security analysis allows managing the complexity of correlating component configurations with
attack steps and security controls. Based on the assumption that architecture configurations
are the cornerstone of smart grid cyber security, this work expl ored the application of an
attack graph formalism, CySeMoL, to the security analysis of architecture variants for the
Voltage Control (VC) in active distribution grids connecting DER.

We have represented the VC architecture using the CySeMoL meta -model and we have
estimated the probability of attack successful comparing three configuration variants.
CySeMoL evaluation has shown a few differences among the configuration variants of the
examined ICT architecture. From these preliminary evaluations we can conclude that the
confidence in the output probability values increases with the adequacy of the architecture
and attack models captured by the tool knowledge base, while decreases with the uncertainty
in architecture configurations that is reflected by the am ount of assumptions used in the
evaluation. However having a real and more detailed architecture at hand, more certain
results could have been obtained from the evaluation. Moreover, CySeMoL is a simplified
although comprehensive meta-model, which integrates a number of different topics within the
domain of cyber security. As such it can be a powerful tool for an IT architect, who considers
or develops different alternatives of a Smart Grid securement, and who might appreciate
guidance with roots in established models of cyber security, research experiments and
knowledge elicited from experts in the domain of cyber security.

The application of the current CySeMoL version to the Voltage Control architecture variants
has also allowed identifying specific aspects that are not covered by the current version of
CySeMoL, e.g. details on communication protocols and security measures. The further
application of CySeMoL to smart grid architectures will provide results about the adequacy of
this formalism to the smart grid sector.

The work has also drawn attention to many of the challenges that still remain in use of
graphical attack modelling by EPUs. Clearly, the use of graphical attack modelling in practical
applications requires a number of trade-offs, starting with the selection of either a simple
modelling method (such as attack trees) or the use of more complex probabilistic and dynamic
approaches available. Furthermore, the level of detail used to describe the smart grid
scenarios has an impact. For a complete model, more details need to be added both with
regards to various (ICT) system components and to the description of other smart grid control
functionalities. Likewise, other attack processes and additional targets beyond the example
presented may need to be considered. Added to this, countermeasures may also need to be
included. Finally, in order for graphical attack modelling to become a practical support to EPU
decision making, the consequences of various attacks, on both the power system and the
business as a whole, need to be addressed. Many of these aspects remain for future work.
6 Work stream 3: Remote services
The objective of the working stream is to discuss:

rd
risks of 3 party maintenance and information transfer to/from partners;
 rules and best practices for maintenance support of 3rd parties as well as information
transfer to/from external partners.

Following persons have contributed to the work of working stream 3:

 Pascal Sitbon, Électricité de France, France
 Christophe Poirier, Électricité de France, France
 Jens-Tobias Zerbst, Vattenfall, Sweden
 Marc Scherer, Alstom Grid, France
 Robert Evans, Snowy Hydro, Australia
 Marc Tritschler, PA Consulting, UK
 D. K. Holstein, OPUS Consulting Group, USA

6.1 Scope and purpose

EPUs rely on remote access for several use cases like maintenance or monitoring. While
improving performance and the overall process, those connections come with risks. In this
chapter, we focus on remote access by Third Parties (TP). We scope in this context remote
access as the use of Information Communication Technology (ICT) resources (computer,
network, etc.) not controlled by the EPU to access to internal resources while being outside of
the physical EPU boundaries in order to provide a service.

This chapter proposes guidelines to EPUs to choose the most relevant standards or best
practices, provides a checklist to support the process, and discusses generic architectures. A
further step could involve more technical guidance and the extension of the discussion to
remote control of critical infrastructure.

6.2 Landscape of threats

Industrial Control Systems (ICS) are more and more exposed through their remote
maintenance access. Shodan has shed the light on ICS vulnerabilities as a 2012 Washington
Post article shows [6-1]. The threats depend on the type of remote access and on the
architecture implemented. Here are some weaknesses or vulnerabilities frequently tied to
remote maintenance ([6-2] gives a more detailed analysis on the threats for ICS
infrastructures):
 Permanent connection to the internet and / or connection of trusted systems to
systems of a lower trust level (these systems are likely to appear on Shodan and
Google dorks)
 Default or weak passwords (known worldwide)
 Vulnerabilities in login interfaces (more com monly known with the extensive use of
Commercial Off The Shelf (COTS) equipment.
 Underlying operating systems not regularly updated
 No logging of actions
 People in charge of remote maintenance systems not aware of security problems or
not trained
  Lack of intrusion detection/ automatic alerting of security incidents.

The exploitation of vulnerabilities on a remote maintenance system can lead to intrusions in

ICS and have an impact on the entire EPU operations.

The major risks tied to remote maintenance syste ms are:

 Intrusion of a non-authorized user in the system (use of a weak password, a backdoor
or a vulnerability of the software) with more or less impact, depending on the
motivations of the attacker and its skills not to be detected (this is the biggest t hreat
according to BSI in [6-3]).
 Unavailability of the system that can lead to global unavailability of the whole
information system
 Breach in confidentiality or integrity of data on the information system
 Unauthorized upgrade of the rights for a remote t echnician during an update operation

This type of breach is not new: one of the first publicly known successful attack dates back
2000. An Australian, bitter from not being hired by Maroochydore Shire Council remotely
opened wastewater valves, resulting in pollution and death of marine life. One of the last
major public known breaches was due to pr0f, a 22 year old American that hacked into the
Springfield water treatment system that served 16.000 people in Texas and had broken a
th
pump on November 17 2012. These attacks are growing every day and many organizations
share interest on ICS hacking as the Trend Micro reports suggest [ 6-4], [6-5].

In order to mitigate these growing threats, we have worked on two types of security controls:
on the one hand by providing an actionable checklist against contractual issues and on the
other hand by highlighting technical controls given by some state of the art remote access
architectures.

6.3 Contractual issues: security requirements in procurement for Electric

Power Utilities
In practice, it is often difficult to implement common security techniques in an EPU’s ICS,
because of field constraints like real-time and available resources. Another essential issue is
the contractual one. Remote access by a TP could be difficult by nature because EPUs and
TPs have different liabilities, different risk management approaches, and sometimes not
consistent security policies. For example the owner/operator is not always free to choose
what techniques it could implement without the explicit agreement by the solution provider.
Cybersecurity procurement requirements must address the full life cycle of the solution,
beginning with design, unit testing, factory acceptance testing, site acceptance testing,
maintenance and support, and decommissioning and disposal.
 Figure 6—1. Life Cycle Phases taken from US Department of Justice
(redrawn by Eugene Vincent Tantog for Wikipedia)

There are many cybersecurity standards, guidelines, and best practic es. They address to a
great extent cybersecurity requirements for an EPU operator to design a strong cybersecurity
program, efficiently operate the program, and specify security controls to mitigate known
threats to their essential resources. These requirements commonly address access control
(identification, authentication, and authorization), data confidentiality and integrity, restricting
network domains and data flows, detection systems, incident management, and ensuring
availability of key resources. They are more and more taking into account the specifics of
industrial systems such as safety first, primacy of availability and integrity over confidentiality,
architecture and system constraints, etc. Examples include DHS and DOE [ 6-6,6-7], EPRI
cybersecurity procurement language [6-8,6-9], WIB M2784X10 [6-10] or ISO/IEC 27036 [6-
11], NISTIR 7628 [6-12], ISO/IEC 62443 [6-13], ISO/IEC 27019 [6-14], and the NERC CIP [6-
15]. Some of them are positioned on the figure 7-2.

Figure 6—2. Existing standards and best practices

Some standards (like IEC 62351) include security interoperability requirements for selected
communication protocols. Other standards address legacy systems using serial
communication protocols (IEEE P1689 [6-16]). All resources provide an excellent source to
help EPU for different needs, e.g.:
 Technical controls, e.g. ISO/IEC 27002
  Procurement requirements such as the DHS Procurement Language, e.g. to include in
a Request For Quotation (RFQ) [6-6]
 Risk analysis or organizational controls, e.g. ISO/IEC 27001
 Specific controls related to EPUs, e.g. ISO/IEC 27019 or IEC 62443

Related efforts aiming at future proofing procurement security requirements are ongoing,
defining grading scheme, and making it easier to compare and rate the security maturity
offered in a proposed solution. They also discuss different contract types and the related
incentive to support security [6-17]. This approach has been successfully tested on electric
power delivery substation gateway and further work could be done to adapt it to TP remote
access.

We propose in Table 6-1 a simplified checklist for EPUs to help them quickly identify essential
aspects before setting up a remote access by a TP. This checklist is not exhaust ive: Its aim is
not to replace existing standards and best practices but to provide an actionable support to
ensure that security has been addressed during the process.
Business needs and requirements

 Describe the business needs (e.g. monitoring, maintenance, etc.) and scope

 Describe business continuity needs

 Describe the connectivity needs (e.g. permanent/on-demand, throughput, latency)

 Describe the assets and their classification / sensitivity

 Consider alternative solutions to remote access by a third party (internal personnel, local access)

 Perform / update the risk assessment on the considered scope

 Include all Utility’s interested parties in the loop (e.g. CISO, Process, IT, Purchase departments)

Organizational security requirements

Define organizational security requirements, e.g.

 Compliance/relevance to existing Utility organizational policies,

 Incident management and reporting,
 Contractor’s certification requirements

 Define how security requirements could be revised o ver time and periodicity

Define how Contractor’s security posture could be controlled (e.g. internal/external review,

logging)

 Define the roles and responsibilities of every actor

Request Contractor to describe its security posture and strategy (e .g. supply chain, incident

management)

Human Resources requirements

 Define security requirements (e.g. background checks, NDA, accounts removal)

 Define credentials requirements (e.g. certifications, education, experience)

 Define relevant procedures (e.g. training, awareness)

Technical security requirements

 Define network security requirements (e.g. network perimeters, protocols, access control)

Define operating system and application requirements, e.g.


 Hardening strategy (e.g. restrict services, accounts)
  Access control
 Update / patch policy
 Media handling

 Include physical security requirements if applicable (e.g. building entrance, visitor policy)

Table 6—1: Summary of the checklist for an EPU before setting up third party remote
access

We also propose in Section 6.5 an extended list of security requirements with associated
controls for consideration by an EPU before contracting with third parties for remote access.
The EPU could select the relevant requirements/controls for their case and include it in their
RFQ.

6.4 Application to real world architectures

Manufacturers frequently access and manage their systems remotely. This remote
maintenance increases the exposure of the systems and that’s why one should restrict it to
the minimum and prefer local maintenance, at least for planned and not urgent activities.

We can think of three types of systems to be maintained remotely: Critical systems, small
systems and all the other. Even if it is neither a cost effective nor a practical approach for a
critical system, it is up to the security posture of the EPU to choose to allow remote access to
critical systems. It has to be a management decision, but some standards [ 6-14] and national
recommendations [6-18], [6-19], [6-20] tend to prevent utilities from remotely maintaining
safety systems by imposing a high burden with technical controls. The architecture chosen
has to support the management decision and provide security and safety.

As shown in Figure 7-3, the remote access architecture has several components:
 TP Subject is the population inside the TP who will get access to the resources;
 TP ICT Resources used to perform the remote access activities;
 Access Network which could be a public network;
 EPU Access Architecture zone which is itself composed of the Resources that are
made available but also security components to isolate and protect the different zones
and provide access to the EPU Accessible Resources;
 EPU Internal Resources zone which usually remains not accessible to the Third Party.

Depending on the contract, the responsibilities could be different as illustrated by the arrows.
Several implementations are of course also possible, e.g. using a public access network like
Internet or dedicated one, using different authentication schemes, using an IPSec VPN,
managing a strict isolated zone on the EPU side for third party accessible resources, etc.
 Figure 7-3 Remote Access generic architecture

The architecture choice is based on EPU constraints, needs and risk management. An
essential criterion is the direction of information flow. An outbound -only flow from the EPU to
the TP could be enough for some use cases like gathering logs for further analysis (examples
include fault records from DFR or protection relays, asset management information, etc.) .
The remote access could be restricted to an isolated zone which can reside in the EPU
Access Architecture with no access to EPU Internal Resources.

The green arrow on figure 7-4 (independent file extraction) gives a good example of an
architecture with this outbound-only flow. Sensitive devices export their data to a data
extraction platform inside a DMZ. No communication is made possible from these platforms to
sensitive devices (even acknowledgment), thanks to the firewall between the substation and
the office. Firewall could be replaced by a diode (at layer 1 of the OSI model) for more
effective security in this case.

For vendor’s proprietary protocols extraction, when bi-directional network connection is

needed (which is denoted by the red arrow on figure 7-4), additional care is required.
 Figure 7-4: Remote Access Architecture (Source: EPRI [17])

Here are some best practices and reference architecture tak en from available standards ([6-
14], [6-15], [6-13], [6-19]) and guidelines ([6-18], [6-20], [6-21], [6-22], [6-23], [6-24], [6-25],
[6-26], [6-27]).

The main goals of the architecture are:

 Strict access control on all relevant levels, inter alia network, system, function, data
level
 Prevent the exploitation of vulnerabilities or backdoors on the remote maintenance
device
 Keep confidentiality and integrity of data
 Ensure logging of any action done remotely by third party technician
 Ensure that remote maintenance will be harmless to the rest of the system
(particularly in terms of availability)
 Prevent leakage of data

Direct dial-in connections on systems should not be possible or apply same security controls
as for the security gateway. If remote maintenance should be applied, the following se curity
controls should be applied:
 Keep logs for access and connections and use only nominative accounts in order to
keep track of individual actions. An inactivity timer and maximum time of connection is
required to ensure that no session sharing is done.
 Keep logs of activities
 Use cryptography for external data flows
 Use 2 factor authentication
  The remote access should come from a dedicated computer in a dedicated DMZ and
all administered systems should only allow configuration from this dedicated compu ter.
 The Utility should ensure segmentation on its internal network so that the contractor
has only access to systems he has to connect to. This should be enforced by Utility -
controlled devices, particularly when the access architecture is controlled by th e TP.
 Remote management from the TP should only occur when local knowledgeable staff is
available and watching (4 eyes principle in order to be able to prevent unwanted
action). Any action should be recorded for further analysis or forensics.

The direct connection of the system to the internet is not a recommended practice, but could
be done only if the enterprise has no enterprise wide internet access and/or for small systems
installed remotely from offices like DER (small solar panels farms, isolated win d turbine, etc.)

Components EPU internal EPU Access Access TP ICT TP Subject

Objectives resources architecture Network Resources
− Prefer − Set up a single − No direct − Nominative
Strict access outbound- DMZ for ease connection / access
control on all only flows of auditing to internet
− Account
relevant levels,
− Segmentation removal
inter alia
by contractor
network, − 2 factor
system, authenticatio
function, data n
level
− Prefer − Hardening of − No direct − Use − Employee
outbound- management connection dedicated screening
Prevent the only flows station to internet devices
− Education
exploitation of
− Remote
vulnerabilities
management
or backdoors
by a single
on the remote
station
maintenance
device − 4 eyes
principle
− Segmentation − Use − Use − Employee
/ by contractor cryptography dedicated screening
devices
− Network − Handling
Keep segmentatio procedures
confidentiality n by
and integrity of contractor
data
− Prefer
private
networks
− Remote − Set up a single − Nominative
Ensure logging management DMZ for ease / / access
of any action by a single of auditing
done remotely station
by third party
technician
− Remote − Physical − Test on − Employee
Ensure that management / separation pre- screening
remote by a single between production
station substation platforms − Account
maintenance
network and before removal
will be
− 4 eyes remote deployment
harmless to the
principle access
rest of the
network − Prefer
system
automated
(particularly in
scripts
terms of
 availability)
− Remote − Hardening of − Use − Use − Handling
management management cryptography dedicated procedures
by a single station devices
Prevent data station − Education
leakage
− Employee
screening

Table 6—2: Security objectives on each remote access architecture component

In addition to the previously discussed best practices, Table 6-2 shows how the main security
goals of the architecture are supported by both contractual and technical controls which
complement each other. It illustrates good practices on each component of the remote access
architecture.

6.5 Checklist of Security Requirements and Management Controls to

Consider for TP Agreements

Security Requirements Management Controls

TP Corporate IT Security Policy Applicable to EPU Remote Access (RA)
Exemptions to EPU requirements documented
Compliance assurance framework
Security Roles and Responsibilities Staff, roles, responsibilities defined for RA.
Confidentiality for all TP staff with Confidentiality agreements– non disclosure of EPU information,
RA security controls and vulnerabilities.
Obligation to Inform TP must inform EPU of security issues, vulnerabilities and
incidents
Network Segregation and Electronic Maintained network design document detailing physical and
Security Perimeter logical segregation
Configuration and Asset Management
Electronic security perimeter identification
Access points identification and controls
Hardening Disable unused ports
Remove/ Disable unused services
Minimal configuration
Secure Communications Encrypt traffic between TP and EPU
Disable non-secure access such as TELNET
Systems Security Maintain up to date AV and malware prevention
Patch management of OS and applications
Configuration management
Remote Access use limited to supported system
New equipment to be verified for security
Mobile systems (e.g. laptops) Hard drive encryption
require additional controls
Local firewall
Limited use policy
Ongoing Vulnerability Assessment Assessment processes, records, remediation
Personnel Security Checks TP to maintain Personnel Register (PR) and carry out security
 checks of staff (Check country laws)
Logical Access Control and User Use individual accounts and record in PR
Account Management
Strong passwords / two-factor authentication better.
Approved , recorded and reviewed user privileges
Segregation of duties for user account management
Logging and review of user access, failed attempts
Physical Security Remote access equipment securely located
Segregation of duties for access approval
Logging and Review of physical access
Training Regular security awareness training of TP staff
Systems Management Patch and configuration management
Systems Security Testing Security test scripts and records
Security Incident Handling Maintained procedure regularly tested.
Disaster Recovery/Business Maintained procedure regularly tested.
Continuity

Table 6—3: Checklist of Security Requirements and Management Controls to Consider

for TP Agreements

6.6 Conclusion
EPUs rely on remote access for several use cases like maintenance or monitoring. While
improving performance and the overall process, those connections come with risks. In many
cases remote access performed by third parties and inconsistencies between security policies
could weaken the EPU.

In order to support utilities efforts in th is field, we have proposed a simplified checklist applied
to remote services. This checklist is expected to guide utilities deciding if they need to use
remote services provided by third parties and what requirements should be included in their
RFQ.

We have also discussed possible technical architectures and ways to mitigate the risk.

Further steps include integration of legacy devices for remote maintenance, overview of
different architectures for remote maintenance, technical comparison of architectures , issues
and controls for the use of mobility devices (e.g. tablets, smartphones, etc.) for remote
maintenance, and the analysis of the issues involved with the extension of remote access to
include remote control purposes.
7 Conclusion and outlook of WG D2.31
Operational Technology and Information Technology convergence is here to stay.
Communication infrastructure and information flows are getting even more critical for EPUs.
At the same time the industry is getting more interesting as a target for malevo lent actors and
foreign governmental agencies. Therefore it has become essential for EPUs to consider
cybersecurity threats and risks across all the organization and raise awareness from
operational to executive level, including vendors, partners, and thi rd parties.
SCD2 Working Group WG D2.01 conducted a global survey [7 -1] in 2013 to determine the
priority of operational and business information systems issues for EPUs. This information is
then used to help with the formation of new working groups and p referential study topics from
2014 onwards. In the survey the highest priority issue was determined to be “Cybersecurity
for evolving EPU business and operational practices and risks” – driven by the business
needs of remote control and use of mobility de vices. This information has helped to set a
strategy of forming new working groups charged with covering these topics when WGD2.31
has completed its tasks. Thus SCD2 plans to continue to support EPUs in the future study on
cybersecurity issues.
A.1 ACRONYMS AND ABBREVIATIONS
Acronym/abbreviation Definition
AMI Advanced Metering Infrastructure
European Committee for Standardization/European
CEN/CENELEC/ETSI Committee for Electro technical Standardization/European
Telecommunications Standards Institute
CySeMoL Cyber Security Modelhing Language
DER Distributed Energy Resources
DMS Distribution Management System
DSO Distribution System Operator
EMS Energy Management System
EPU Electric Power Utility
EV Electric Vehicle
GOOSE Generic Object Oriented Substation Events
HMI Human-Machine Interface
HTTPS HyperText Transfer Protocol over Secure Socket Layer
HV High Voltage
ICT Information Communication Technology
IEC International Electro technical Commission
IED Intelligent Electronic Device
IEEE Institute of Electrical and Electronic Engineers
IP Internet Protocol
LAN Local Area Network
LV Low Voltage
MMS Manufacturing Message Specification
MV Medium Voltage
NERC North American Electric Reliability Corporation
NIST National Institute of Standards and Technology
OLTC On-Load Tap Changer
PLC Programmable Logic Controller
SCADA Supervisory Control and Data Acquisition
SSH Secure Shell
SSL Secure Socket Layer
TLS Transport Layer Security
TSO Transmission System Operator
UML Unified Modeling Language
VC Voltage Control
VPN Virtual Private Network
A.2 REFERENCES
[1-1] J.-T. Zerbst, S. Zimmermann, D.K. Holstein, and C. Poirier, "Towards an adapted
classification methodology for graded security approaches in EPU architectures" CIGRE
Symposium, Lisbon, 2013
[1-2] Source: Électricité de France (EDF), Smart grid Europe 2009 presentation at SmartGrids
Europe conference, Barcelona, 2009
[1-3] Christiane Grefe,“Blackout”, Die Zeit 16/2014
http://www.zeit.de/2014/16/blackout-energiehacker-stadtwerk-ettlingen
[1-4] Felix Lindner, ”Licht aus!”, c’t magazin 09/2014 http://heise.de/-2165153
[1-5] L. Pietre-Cambacedes , M. Tritschler and G. Ericsson, "Cyber security myths on power
control systems: 21 misconceptions and false beliefs," IEEE Transactions on Power
Delivery, Vol. 26, Issue 1, pp. 161-172, January 2011.
[1-6] R. Langer, “Robust Control System Networks - How to achieve reliable control after
Stuxnet”, Momentum Press, New York, 2012
[1-7] ABB white paper: “Security in the Smart Grids”, 2009
http://www02.abb.com/db/db0003/db002698.nsf/0/832c29e54746dd0fc12576400024ef16
/$file/paper_Security+in+the+Smart+Grid+%28Sept+09 %29_docnum.pdf
[1-8] Jacobs, Mike. "10 Years After Record Blackout, Is U.S. Any Better Prepared? (Op -Ed)."
LiveScience. TechMedia Network, 14 Aug. 2013. Web. 17 Apr. 2014.
http://www.livescience.com/38905-is-nation-better-prepared-to-prevent-blackouts.html
[1-9] Kim Zetter, “Researchers Uncover Holes That Open Power Stations to Hacking”,
wired.com, 2013 http://www.wired.com/2013/10/ics/
[1-10] G. Dondossola, F. Garrone, J. Szanto “Cyber Risks in Energy Grid ICT Infrastructures”
in Critical Infrastructure Protection and Resilience in the ICT Sector, Paul Theron and S.
Bologna Ed., IGI Global, 2013
[1-11] ICS-CERT Monitor “Incident Response Activity - October, November, December 2013”,
2013 http://ics-cert.us-cert.gov/sites/default/files/Monitors/ICS-CERT_Monitor_Oct-
Dec2013.pdf
[1-12] C. Wueest, Symantec, “Targeted Attacks Against the Energy Sector”, 2014
[1-13] Stefan Frei, “ Vulnerability Threat Trends: A DECADE IN REVIEW, TRANSITION ON
THE WAY ”, NSS Labs, Inc., 2013
[1-14] J. Zerbst, M. Schaefer, I. Rinta-Jouppi, "Zone principles as Cyber Security architecture
element for Smart Grids", Innovative Smart Grid Technologies Conference Europe (ISGT
Europe), 2010 IEEE PES
[1-15] Nicolas Falliere, Liam O Murchu, Eric Chien, “W32.Stuxnet Dossier”, 2011
http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers
/w32_stuxnet_dossier.pdf
[1-16] Symantec Security Response: Dragonfly: Western Energy Companies Under Sabotage
Threat http://www.symantec.com/connect/blogs/dragonfly-western-energy-companies-
under-sabotage-threat-energetic-bear
[1-17] François Page, McAfee Labs, ”Hacktivism Cyberspace has become the new m edium for
political voices”, 2012
[1-18] Heather MacKenzie, „Shamoon Malware and SCADA Security“, 2012
http://www.isssource.com/shamoon-malware-and-scada-security/
[1-19] Marshall Abrams, Joe Weiss “Malicious Control System Cyber Security Attack Case
Study Maroochy Water Services, Australia”, 2008
http://csrc.nist.gov/groups/SMA/fisma/ics/documents/Maroochy-Water-Services-Case-
Study_report.pdf
[1-20] Ryan Naraine, ” Shodan search exposes insecure SCADA systems”, 2010
http://www.zdnet.com/blog/security/shodan -search-exposes-insecure-scada-
systems/7611
[1-21] Kevin Poulsen, ”Slammer worm crashed Ohio nuke plant net”, 2003
http://www.theregister.co.uk/2003/08/20/slammer_worm_crashed_ohio_nuke/
[1-22] European Commission, „Cybersecurity Strategy of the European Union: An Open, Safe
and Secure Cyberspace“, Brussel, 2013
[1-23] Cyberspace policy review: Assuring a Trusted and Resilient Information and
Communications Infrastructure
http://www.whitehouse.gov/assets/documents/Cyberspace_Policy_Review_final.pdf
[1-24] L. Piètre-Cambacédès, T. Kropp, J. Weiss, R. Pellizzoni “Cybersecurity standards for the
electric power industry – a survival kit”, Paper D2-217, CIGRE Paris Session 2008,
France
[1-25] The NIST Smart Grid Interoperability Panel Cyber Security Working Group, “Introduction
to NISTIR 7628 - Guidelines for Smart Grid Cyber Security”, September 2010.
http://www.nist.gov/smartgrid/upload/nistir-7628_total.pdf
[1-26] F. Cleveland, “List of Cybersecurity for Smart Grid Standards and Guidelines”, May
2013.
http://iectc57.ucaiug.org/wg15public/Public%20Documents/List%20of%20Smart%20Grid
%20Standards%20with%20Cybersecurity.pdf
[1-27] Smart Grid Coordination Group Set of Standards Working Group “First set of standards”
version 2.0, November 2012.
http://ec.europa.eu/energy/gas_electricity/smartgrids/doc/xpert_group1_first_set_of_stan
dards.pdf
[1-28] see “Working-party on Instrument Behaviour” (WIB) web site at www.wib.nl
[1-29] NIST Cybersecurity Framework
http://www.nist.gov/cyberframework/upload/cybersecurity-framework-021214-final.pdf
[1-30] Nuclear Energy Institute, NEI 08-09 Cyber Security Plan for Nuclear Power Reactors
(rev. 6), April 2010
[1-31] IAEA Nuclear Security Series No. 17, Reference Manual, C omputer Security aAt Nuclear
Facilities, 2011
[1-32] L. Pietre-Cambacedes, T. Quinn, L. Hardin "Cyber Security of Nuclear Instrumentation
and Control Systems - Overview of the IEC Standardization Activities" IFAC conference
on Manufacturing, Management and Control (MIM 2013), Invited session on
Cybersecurity of Control and Safety systems, St. Petersburg, Russia, June 2013
[1-33] European-Commission, "Cybersecurity strategy of the European Union: An open, safe
and secure cyberspace," European Commission, Joint Communication JOIN (2013) 1
final, 7 February 2013
[1-34] European Network and Information Security Agency (ENISA), “Smart Grid Security,
Recommendations for Europe and Member States”, 2012 -07-01
[1-35] SoES Project, “International Standards and Policies – Map and Analysis”, Security of
Energy Systems Project, Deliverable D2, 2014. http://www.soes-project.eu
[1-36] ECSWG, "Roadmap to Achieve Energy Delivery Systems Cybersecurity," US Department
of Energy, September 2011
[1-37] Cigré JWG D2/B3/C2-1 Technical Brochure TB 317 on “Security for Information Systems
and Intranets in Electric Power Systems”, 2007
[1-38] Technical Brochure 419 of the WG D2.22 " Information Security for Electric Power
Utilities (EPUs) — CIGRÉ Developments on Frameworks, Risk Assessment, and
Technology", 2010
[2-1] J. Zerbst et al, “Graded approach to cyber-security for EPUs: Clarifying the security levels and
zone concepts”, Paper D2-02-B09, 2011 SC D2 Colloquium, Buenos Aires – Argentina.
[2-2] G. Dondossola et al, “Modelling of cyber-attacks for assessing smart grid security”, Paper D2-
02-B10, 2011 SC D2 Colloquium, Buenos Aires – Argentina.
[2-3] J. Zerbst et al, “Cyber-attack modelling and security graded approach: key elements when
designing security architecture for Electric Power Utilities (EPUs)”, Paper D2-07, 2012 SC D2
Session, Paris - France.
[2-4] J. Zerbst et al, “Towards an adapted classification methodology for graded security approaches
in EPU architectures”, Paper D2-02-B09, 2013 Cigre Symposium, Lisbon– Portugal.
[2-5] M. Ekstedt et al, “Application of a cyber-security assessment framework to smart grid
architectures” Paper D2-02-11, 2013 SC D2 Colloquium, Mysore - India.
[2-6] P.Sitbon et al, “Security in remote services used by EPUs”, Paper D2-203-2014, 2014 SC D2
Session, Paris - France.
[2-7] J. Zerbst et al, “Status of Cybersecurity”, Electra 276, October 2014.

[4-1] IEC 62443-1, 2008, “Industrial communication networks - Network and system security
Part 1 Terminology, concepts and models”, 7 et sqq.
[4-2] IEC 62254-1, 2003, “Enterprise-control system integration – Part 1: Models and
terminology”, 185 et sqq.
[4-3] IEC 61226, 2005, “Nuclear power plants - Instrumentation and control systems important
to safety - Classification of instrumentation and control functions”
[4-4] NIST 800-60 Volume II Revision 1, 2008, “SECURITY CATEGORIZATION OF
INFORMATION AND INFORMATION SYSTEMS
[4-5] U.S. Nuclear Regulatory Commission (NRC), 2010, “Regulatory Guide 5.71 - Cyber
Security programs for Nuclear Facilities”, pp. 35
[4-6] Idaho National Laboratory, 2006, “Control Systems Cyber Security: Defense in Depth
Strategies”, online
http://csrp.inl.gov/Documents/Defense%20in%20Depth%20Strategies.pdf
[4-7] American National Standards Institute (ANSI), International Electro technical
Commission (IEC), International Society of Automation (ISA), ANSI/ISA -99.00.01-2007,
2007, IEC 62443-1 Security for Industrial Automation and Control Systems Part 1:
Terminology, Concepts, and Models
[4-8] NSA, Defense in Depth. US National Security Agency
[4-9] International Standard Organisation (ISO), International Electrotechnical Commission
(IEC), 1994, “ISO/IEC 7498-1 Information Technology – Basis Reference Model: The
Basic Model
[4-10] Trusted Information Sharing Network for Critical Infrastructure Protection, 2008,
“Defense in depth”, Available at:
http://www.tisn.gov.au/www/tisn/tisn.nsf/Page/Publications_e-SecurityPublications (last
visited 5th May 2010)
[4-11] U.S. NUCLEAR REGULATORY COMMISSION, 2010, REGULATORY GUIDE 5.71 -
CYBER SECURITY PROGRAMS FOR NUCLEAR FACILITIES
[4-12] Cigre JWG D2/B3/C2-1, 2007, Technical Brochure TB 317 on “Security for Information
Systems and Intranets in Electric Power Systems”
[4-13] Cigre WG D2.22, Technical Brochure TB 419 on “Treatment of Information Security for
Electric Power Utilities”, June 2010.
[4-14] ISO 7498-2: Information processing systems, 1989, Open System Interconnection –
Basic Reference Model – Part 2: Security Architecture
[4-15] IEC Smart Grid Standardization Roadmap, Edition 1.0, 2010
[4-16] PERA Enterprise Model, Gary Rathwell
[4-17] American National Standards Institute (ANSI), International Society of Automation (ISA),
“ANSI/ISA-95.00.01-2000, Enterprise-Control System Integration, Part 1: Models and
Terminology”
[4-18] J. D. Gilsinn, R. Schierholz, "Security Assurance Levels: A Vector Approach to
Describing Security Requirement," Oct. 2010, Available at:
http://www.nist.gov/manuscript-publication-search.cfm?pub_id=906330 (last visited 14th
May 2011)
[4-19] CIGRÉ Working Group WGD2.24 “EMS for the 21st Century - System Requirements”
Technical Brochure 452, February 2011.
[4-20] National Institute of Standards and Technology (NIST), 2008, “Guide to Industrial
Control Systems (ICS) Security (NIST 800-82)”
[4-21] Department of Homeland Security (DHS),2006, “Control Systems Cyber Security:
Defense in Depth Strategies”
[4-22] US Department of Homeland Security, 2009, Recommended Practice: Improving
Industrial Control Systems Cybersecurity with Defense -In-Depth Strategies”. Control
Systems Security Program, National Security Division.
[4-23] SINTEF report, 2007, "The SeSa Method for Assessing Secure Remote Access to Safety
Instrumented Systems", Available at:
http://www.sintef.no/upload/Teknologi_og_samfunn/Sikkerhet%20og%20p%C3%A5litelig
het/Rapporter/SINTEF%20A1626%20-%20SeSa%20report-final.pdf (last visited 25th
April 2011)
[4-24] AMI-SEC Task Force and AMI Security Acceleration Project (ASAP), 2009, “AMI Security
Implementation Guide V1.01”
[4-25] W32.Stuxnet Dossier, 2011, Nicolas Falliere, Liam O Murchu, Eric Chien Available at:
http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers
/w32_stuxnet_dossier.pdf
[4-26] IEC 62443-1, 2008, “Industrial communication networks - Network and system security
Part 1 Terminology, concepts and models”, 7 et. sqq.
[4-27] IAEA Nuclear Security Series No. 17: Technical Guidance, Computer Security at Nuclear
Facilities, 2011
[4-28] U.S. Nuclear Regulatory Commission (NRC), 2010, “Regulatory Guide 5.71 - Cyber
Security programs for Nuclear Facilities”, pp. 35
[4-29] NERC: reliability considerations from the integration of Smart Grid available at
http://www.nerc.com/files/SGTF_Report_Final_posted.pdf in particular see defense in
depth p 89
[4-30] J.-T. Zerbst, L. Pietre-Cambacedes, Å. Torkilseng and O. Breton, "Graded approach to
cyber security for EPUs: Clarifying the security levels and zones concepts," 2011
CIGRE D2 Colloquium, Buenos Aires, Argentina, October 2011
[4-31] IEC 61508 edition 2.0, 2010, “Functional safety of electrical/electronic/programmable
electronic safety-related systems”
[4-32] NERC CIP-002 to NERC CIP-009, “Cyber Security Standard of NERC”, 2006,
http://www.nerc.com (last visited 27th December 2012)
[4-33] "Introduction to NISTIR 7628 Guidelines for Smart Grid Cyber Security", 2010, NIST
[4-34] "IT-Grundschutz-Standards", 2008, Federal Office for Information Security of Germany
(BSI)
[4-35] "ABB White Paper: Security for Industrial Automation and Control Systems", 2010, ABB
[4-36] "Cyber Security Compliant Architecture for the Nuclear Industry" 2011, Invensys
[4-37] ArchiMate® 2.0, 2012, The Open Group
[4-38] “Protection Profile for the Security Module of a Smart Meter Gateway (Security Module
PP)”, Bundesamt für Sicherheit in der Informationstechnik, 2012, Available at:
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/SmartMeter/PP_Security_%20
Module.pdf?__blob=publicationFile (last visited 27th December 2012)’
[4-39] "Zone principles as Cyber Security architecture element for Smart Grids", 2010, Jens
Zerbst, Martin Schaefer, Iiro Rinta-Jouppi
[4-40] Payment Card Industry (PCI) Data Security Standard 2.0, 2010, PCI Security Standard
Council
[4-41] L. Pietre-Cambacedes and M. Bouissou, "Modeling safety and security
interdependencies with BDMP (Boolean logic Driven Markov Processes)," Proceedings
of the IEEE International Conference on Systems, Man, and Cybernetics (SMC 2010),
Istanbul, Turkia, pp. 2852-2861, October 2010
[4-42] PERA Enterprise Model, Gary Rathwell, Available at:
http://www.pera.net/Pera/PERA_Papers/Levels-4Rs/4r_pres.htm (last visited 27th
December 2012)
[4-43] "Data Structures And Algorithms", 1983, A.A. Puntambekar

[5-1] IEC Smart Grid Standardization RoadMap, SMB Smart Grid Strategic Group SG3,
Edition 1.0, June 2010.
[5-2] NIST Internal Report 7628, “Guidelines for Smart Grid Cyber Security”, 3 Volumes, The
Smart Grid Interoperability Panel – Cyber Security Working Group, August 2010.
[5-3] L. Piètre-Cambacédès, T. Kropp, J. Weiss, R Pellizzoni: “Cybersecu¬rity standards for
the electric power industry – a survival kit” – Paper D2-217, CIGRÉ Paris Session 2008,
France, August 2008.
[5-4] ISO/IEC 15408-1, Information technology — Security techniques — Evaluation criteria
for IT security — Part 1: Introduction and general model, Second edition, 2005.
[5-5] T. Sommestad, M. Ekstedt, P. Johnson, “A probabilistic relational model for security risk
analysis,” Computers & Security, vol. 29, no. 6, pp. 659 –679, 2010.
[5-6] N. Falliere, L.O. Murchu, E. Chien “W32.Stuxnet Dossier”, Symantec Security Response,
Version 1.4, February 2011.
[5-7] B. Schneier, “Attack trees: Modeling security threats”, Dr. Dobb's Journal, vol. 12, no.
24, pp. 21-29, 1999.
[5-8] C.-W. Ten, C.-C. Liu, M. Govindarasu, “Vulnerability assessment of cybersecurity for
SCADA systems using attack trees,” in Proceedings of the IEEE Power Engineering
Society General Meeting, pp. 1–8, Tampa, USA, June 2007.
[5-9] S. C. Patel, J. H. Graham, P. A. Ralston, “Quantitatively assessing the vulnerability of
critical information systems: A new method for evaluating security enhancements,”
International Journal of Information Management, vol. 28, no. 6, pp. 483 –491, December
2008.
[5-10] S. McLaughlin, P. McDaniel, D. Podkuiko, “Energy theft in the advanced metering
infrastructure,” in Proceedings of the 4th International Workshop on Critical Information
Infrastructure Security (CRITIS’09), Bonn, Germany, 2009.
[5-11] G.-Y. Park, C. K. Lee, J. G. Choi, D. H. Kim, Y. J. Lee, K.-C. Kwon, “Cyber security
analysis by attack trees for a reactor protection system,” in Proceedings of the Korean
Nuclear Society (KNS) Fall Meeting, Pyeong Chang, Korea, October 2008.
[5-12] J. P. McDermott, “Attack net penetration testing,” in Proceedings of the 2000 Workshop
on New Security Paradigms (NSPW’00), pp. 15–21, Cork, Ireland, September 2000.
[5-13] S. Pudar, G. Manimaran, C. Liu, “PENET: a practical method and tool for integrated
modeling of security attacks and countermeasures,” Com puters & Security, vol. 28, no.
8, pp. 754–771, May 2010.
[5-14] T. Sommestad, M. Ekstedt, L. Nordström, “Modeling security of power communication
systems using defense graphs and influence diagrams,” IEEE Transactions on Power
Delivery, vol. 24, no. 4, pp. 1801–1808, October 2009.
[5-15] J. McDermott, C. Fox, “Using abuse case models for security requirements analysis,” in
Proceedings of the 15th Annual Computer Security Applications Conference
(ACSAC’99), Phoenix, USA, Dec. 1999, pp. 55–64.
[5-16] G. Sindre, A. L. Opdahl, “Eliciting security requirements with misuse cases,”
Requirements Engineering, vol. 10, no. 1, pp. 34–44, 2005.
[5-17] G. Dondossola, F. Garrone, J. Szanto “Experimental Evaluation of Cyber Intrusions into
Highly Critical Power Control Systems” Proceedings of the CIRED 2011 - International
Conference on Electricity Distribution, Paper n. 0440, Frankfurt, June 2011.
[5-18] M.-Y. Huang and T. M. Wicks, “A large-scale distributed intrusion detection framework
based on attack strategy analysis,” in Proceeding of the 1st International Workshop on
the Recent Advances in Intrusion Detection (RAID’99), pp. 2433 –248, Louvain-la-Neuve,
Belgium, Sep. 1998.
[5-19] L. Piètre-Cambacédès, M. Bouissou, “Attack and defense dynamic modeling with
BDMP”, in Proceedings of the 5th International Conference on Mathematical Methods,
Models, and Architectures for Computer Networks Security (MMM-ACNS-2010), pp. 86–
101, LNCS 6258, St Petersburg, Russia, September 2010.
[5-20] M. Bouissou, J.-L. Bon, “A new formalism that combines advantages of fault-trees and
Markov models: Boolean logic driven Markov processes,” Reliability Engineering &
System Safety, vol. 82, no. 2, pp. 149–163, November 2003.
[5-21] N. Mead, E. Hough, T. Stehney, “Security quality requirements engi neering (SQUARE)
methodology,” Carnegie Mellon University, Tech. Rep. CMU/SEI -2005-TR-009, 2005.
[5-22] S. Evans, D. Heinbuch, E. Kyule, J. Piorkowski, and J. Wallner, “Risk -based systems
security engineering: stopping attacks with intention,” IEEE Securit y and Privacy, vol. 2,
no. 6, pp. 59–62, 2004.
[5-23] Buckshaw, D. L.; Parnell, G. S.; Unkenholz, W. L.; Parks, D. L.; Wallner, J. M. &
Saydjari, O. S. Mission Oriented Risk and Design Analysis of Critical Information
Systems, Military Operations Research, Vol. 10 No. 2, pp. 19-38, 2005,
http://www.innovativedecisions.com/documents/Buckshaw-Parnelletal.pdf.
[5-24] U.S. Nuclear Regulatory Commission (NRC), “Cyber security programs for nuclear
facilities,” Regulatory Guide 5.71, January 2010.
[5-25] CEN/CENELEC/ETSI “Use Case Management Process — Use Case Collection,
Management, Repository, Analysis and Harmonization”, Draft Report of the Working
Group Sustainable Processes to the Smart Grid Coordination Group - Mandate M/490,
November 2012
[5-26] G. Dondossola, F. Garrone, G. Proserpio, C. Tornelli, 2012, “Impact of DER integration
on the cyber security of SCADA systems – the Medium Voltage regulation case study”.
CIRED 2012 Lisbon (PT), 29-30 May 2012
[5-27] G. Dondossola: “Risk Assessment of Information and Communication Systems - Analysis
of some practices and methods in the Electric Power Industry”, CIGRÉ Electra, No. 239,
August 2008.
[5-28] ISO/IEC 27005:2008, Information technology -- Security techniques -- Information
security risk management
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=4210
7.
[5-29] T. Sommestad, M. Ekstedt, H. Holm, 2012, “The Cyber Security Modeling Language: A
Tool for Assessing the Vulnerability of Enterprise System Architectures”. IEEE Systems
Journal, 2012
[5-30] IEC/TS 62351-3 ed1.0 Power systems management and associated information
exchange - Data and communications security - Part 3: Communication network and
system security - Profiles including TCP/IP, 22 June 2007
[5-31] P. Mell, K. Scarfone, S. Romanosky, 2007, ”A complete guide to the common
vulnerability scoring system version 2.0”. Forum of Incident Response and Security
Teams (FIRST), 2007

[6-1] Robert O’Harrow Jr “Cyber search engine Shodan exposes industrial control systems to
new risks” [Washington Post, June 03, 2012] - http://articles.washingtonpost.com/2012-
06-03/news/35459595_1_computer-systems-desktop-computers-search-engine
[6-2] An Undirected Attack Against Critical Infrastructure: A case study for improving Your
control system Security, http://ics-cert.us-
cert.gov/sites/default/files/documents/CaseStudy-002.pdf
[6-3] BSI – aperçu des menaces cybersécurité - https://www.allianz-fuer-
cybersicherheit.de/ACS/DE/_downloads/angriffsmethoden/statistiken/BSI -CS_029.html
[6-4] Trend Micro: Who's really attacking your SCADA, https://media.blackhat.com/us-13/US-
13-Wilhoit-The-SCADA-That-Didnt-Cry-Wolf-Whos-Really-Attacking-Your-ICS-Devices-
Slides.pdf
[6-5] Trend Micro: The SCADA That didn't Cry Wolf, Who's really attacking your SCADA part
2): https://media.blackhat.com/us-13/US-13-Wilhoit-The-SCADA-That-Didnt-Cry-Wolf-
Whos-Really-Attacking-Your-ICS-Devices-Slides.pdf
[6-6] DHS Cybersecurity Procurement language, http://ics-cert.us-
cert.gov/sites/default/files/Procurement_Language_Rev4_100809.pdf
[6-7] DOE Cybersecurity procurement language, http://energy.gov/oe/downloads/cyber-
security-procurement-language-control-systems-version-18
[6-8] EPRI Cyber Security Procurement—Application of the Methodology
http://www.epri.com/abstracts/Pages/ProductAbstract.aspx?ProductId=00000000300200
1735
[6-9] EPRI Cyber Security Procurement Methodology
http://www.epri.com/abstracts/Pages/ProductAbstract.aspx?ProductId=00000000000102
6562
[6-10] WIB M2784X10 (PCS requirements for vendors)
[6-11] ISO/IEC 27036: Information security for supplier relationships (International standard)
[6-12] NISTIR 7628: Guidelines for Smart Grid Cyber Security – Introduction
[6-13] ISO/IEC 62443-3-3:2013: System security requirements and security levels.
[6-14] ISO/IEC TR 27019:2013 Information technology Security techniques - Information
security management guidelines based on ISO/IEC 27002 for process control systems
specific to the energy utility industry
[6-15] Critical Infrastructure Protection (CIP), (NERC, US) and particularly: NERC-CIP-005,
NERC-CIP-006, NERC-CIP-007
[6-16] IEEE P1689, Trial Use Standard for Cyber Security of Serial SCADA Links and IED
Remote Access
[6-17] D. K. Holstein, P. Sitbon, “Security requirements in procurement for Electric Power
Utilities”, C&ESAR conference, Rennes, France, October 2013.
[6-18] NERC: Guidance for Secure Interactive Remote Access, July 2011
[6-19] VGB S-175 standard
[6-20] ANSSI: méthode de classification et mesures principales pour les installations
industrielles (french national guideline to be published)
[6-21] ANSSI - Externalisation des systèmes d’information – maîtriser les risques de
l’infogérance http://www.ssi.gouv.fr/IMG/pdf/2010-12-03_Guide_externalisation.pdf
[6-22] CPNI Good Practice Guidelines for Process Control and SCADA Security:
http://www.cpni.gov.uk/ProtectingYourAssets/scada.aspx
[6-23] DHS/CPNI: Configuring and Managing Remote Access for Industrial Control Systems,
November 2011.
[6-24] DoE: 21 Steps to Improve Cyber Security of SCADA Networks
[6-25] EXERA M3958X10 - Cybersécurité des systèmes de contrôle commande
[6-26] CIGRE Electra ELT_244_2 “Security Technologies Guideline - Practical Guidance for
Deploying Cyber Security Technology within Electric Utility Data Networks”, June 2009
[6-27] CIGRE Technical Brochure TB419 - ”Treatment of Information Security for Electric
Power Utilities (EPUs)”, D2.22, June 2010.

[7-1] CIGRÉ Working Group WGD2.01 “Strategic Priorities for Information Systems Issues”,
Electra 274, pp 30-33, June 2014.

A.3 TABLE OF FIGURES

Figure 1—1 Vision Smart grid Europe of EDF [1-2] ............................................................................. 4
Figure 5—1. Simplified example of a plant architecture showing different attack processes with no
claim of completeness ............................................................................................................... 20
Figure 4—2. Focus area of criteria cluster per standard .................................................................... 24
Figure 4—3. Classification criteria categories ................................................................................... 25
Figure 4—4. Application of traversing path to determinate a target zone ........................................... 26
Figure 4—5. Application of the approach by 6 example question ....................................................... 27
Figure 5—1. Conceptual model from Common Criteria [5-5] .............................................................. 29
Figure 5—2. The Cyber Security Modelling Language ....................................................................... 31
Figure 5—3. Attack tree on a dial- up Remote Access Server (RAS) .................................................. 33
Figure 5—4. Typical RSE attack state-diagram ................................................................................. 33
Figure 5—5. BDMP modelling of the RAS attack (with sequences represented by the red arrows) ..... 34
Figure 5—6. ICT architecture of the Voltage Control function ............................................................ 35
Figure 5—7. A generic input/output view of the Voltage Control function ........................................... 37
Figure. 5—8. Attack tree fragment .................................................................................................... 38
Figure 5—9. Services and applications in the ICT architecture .......................................................... 39
Figure 5—10. Supervision data flow between the SCADA frontend in the control centre and a
substation-level SCADA (together with a few surrounding entities) as modelled in CySeMoL ...... 41
Figure 5—11. An example of an attack path visualized in CySeMoL. Attack steps are ordered according
to numbers on the arrows and the cumulative likelihood of succ eeding the attack is visualized after
the attack step (attack steps 1-7 have been omitted for the sake ................................................ 43
Figure 5—12. Plotted summary of results of the CySeMoL evaluation ............................................... 44
Figure 6—1. Life Cycle Phases taken from US Department of Justice (redrawn by Eugene Vincent
Tantog for Wikipedia) ................................................................................................................ 48
Figure 6—2. Existing standards and best practices ........................................................................... 48

A.4 TABLE OF TABLES

Table 4—1. Standard and best practices of graded security approach (as per beginning of 2012) ...... 17
Table 4—2. Comparison of standards and best practices (as per beginning of 2012) ......................... 18
Table 5—1: Brief description of assumptions made for the CySeMoL model ...................................... 42
Table 5—2: Description of the evaluated variants of the ICT architecture .......................................... 42
Table 5—3: Results of the CySeMoL evaluation ................................................................................ 44
Table 6—1: Summary of the checklist for an EPU before setting up third party remote access ........... 51
Table 6—2: Security objectives on each remote access architecture component ............................... 55
Table 6—3: Checklist of Security Requirements and Management Controls to Consider for TP
Agreements .............................................................................................................................. 56
 Security architecture principles for digital
systems in Electric Power Utilities

Working Group
D2.31

April 2015
Members

1
Jens Zerbst (Convener), Ludovic Piètre-Cambacédès (Convener ), Mathias Ekstedt (Secretary),
Giovanna Dondossola, Christophe Poirier, Pascal Sitbon, Åge Torkilseng, Dennis Holstein, John
McDonald, Robert Evans, Marc Tritschler, Simon Zimmermann, Iiro Rinta-Jouppi, Göran Ericsson,
Marc Scherer, Feven Zegai, Olivier Breton

In memory to Tor Aalborg

—————————

Copyright © 2015

“Ownership of a CIGRE publication, whether in paper form or on electronic support only infers right
of use for personal purposes. Are prohibited, except if explicitly agreed by CIGRE, total or partial
reproduction of the publication for use other than personal and transfer to a third party; hence circu-
lation on any intranet or other company network is forbidden”.

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

ISBN: 978-2-85873-317-0

1
from 2010-2012