Int. J. Information Technology and Management , Vol. x, No.

x, xxxx

Designing Security Policies for Complex SCADA

Systems Management and Protection

Christophe Feltus* and Djamel Khadraoui

Luxembourg Institute of Science and Technology (LIST)
5 Avenue des Hauts-Fourneaux,
L-4362 Esch-sur-Alzette, Luxembourg
E-mail: christophe.feltus@list.lu
E-mail: djamel.khadraoui@list.lu
*Corresponding author

Abstract: Supervisory Control and Data Acquisition (SCADA) systems consists

in solutions which monitor, control and support the decision making related to
security issue of complexes and critical systems (and information systems) spread
out over disseminated areas. SCADA are required to deal with increasingly
sensitive and crucial situations for an economy or country (like the healthcare, the
power distribution, the telecom) and the management and protection of these
SCADA systems must constantly evolve towards integrated decision support and
policy driven by cyber security requirements. The current research stream in this
domain aims, accordingly, to foster the smartness of the field equipments and
management processes, which principally exist through the generic concept of
SCADA management and operation. Those components are governed by policies
which depend on the components roles as well as on the evolution of the crisis
which also confer to the latter the latitude to react based on their own perception
of the crisis evolution. Their latitude is calculated based on the component
smartness and is strongly determined by, and depending on, the cyber safety of the
component environment. Existing work related to crisis management tends to
consider that components evolve and are organized in systems but as far as we
know, no systemic solution exists which integrates all of the above requirements.
This paper extends the initial work presented at the 1st International Conference
on Information and Communication Technologies for Disaster Management. It
proposes an extension of the innovative version of ArchiMate for the SCADA
components modelling with a broaden description and explanation of the
behaviour endorsed in the cyber-policy. Our work has equally been illustrated in
the frame of a critical infrastructure in the field of petroleum supply and storage
networks.
Keywords: ArchiMate, metamodel, SCADA, multi-components system, trust,
petroleum supply chains, critical infrastructure.
Reference to this paper should be made as follows: Feltus, C. and Khadraoui, D.
(2015) Designing Security Policies for Complex SCADA Systems Management
and Protection, Int. J. Information Technology and Management, Vol. x, No. x,
pp.xxxxxx.
Biographical notes: Dr.-Eng. Christophe Feltus is graduated as an Electro-
mechanics Engineer from the Institut Suprieur Industriel des Art et Mtiers
Pierrard (Belgium) and Doctor of Science (Computer Science) from the University
of Namur (Belgium). He worked for several years in private companies as:
Production Head at Pfizer SA, Project Coordinator at Nizet Entreprise, and
Assessor for the Civil Belgium Aviation Administration. Afterwards, Dr.-Eng.

Copyright 200x Inderscience Enterprises Ltd.

 C. Feltus and D. Khadraoui

Christophe Feltus joined the Public Research Centre Henri Tudor in the Grand-
Duchy of Luxembourg in 1999 to work in the field of Service Science and
Innovation. There he has taken part in projects related to IT security, IT
governance, SCADA system modelling and enterprise architecture modelling and
has been Industrial Program Chair of the 6th International Conference on Security
of Information and Networks (ACM SIN'13). In 2015, the Public Research Centre
Gabriel Lippmann and the Public Research Centre Henri Tudor have merged to
become the Luxembourg Institute of Science and Technology.
Dr. Djamel Khadraoui received his PhD in Vision for Robotics (1996) from
University Blaise Pascal (France). He is currently (since 01/2015) Head of Unit
composed of 38 collaborators in the domain related to Trusted Service Systems
at LIST (Luxembourg Institute of Science and Technology). The main focus of
the TSS research unit is on thematic areas: Service Supply Chain, Trust and
Security, Quality Assessment and Process Improvement, Enterprise Engineering.
He was at CRP Henri Tudor since 2002 as a Program and Lead R&D Manager of
active in the areas of eMobility and Critical Infrastructures Protection. His main
scientific interests are: intelligent and real-time systems, cyber-physical systems,
software engineering, trust and security.

1 Introduction

Supervisory Control and Data Acquisition (SCADA) systems consists in solutions which
monitor, control and support the decision making related to security issue of complexes and
critical systems (and information systems) spread out over disseminated areas. SCADA are
required to deal with increasingly sensitive and crucial situations for an economy or country
(like the healthcare, the power distribution, the telecom) and consists in complex,
sophisticated and integrated systems which support people in governing and monitoring a
plethora of knowledge generated by critical infrastructures (CI in military, energy,
transport, industries, and healthcare) (Briesemeister et al., 2010). In our previous work, we
have defined a metamodel for the components of the SCADA architecture (Feltus et al.
(2014)). This metamodel has been elaborated acknowledging traditional enterprise
architecture metamodel (EAM) and it allows modelling each component according to a
similar structure.
Enterprise architecture models are frameworks that allow representing the information
system (IS) of companies in (or on a set of) schemas called views. Those models have
undergone major improvements during the first decade of the 21st century and some
significant frameworks have been developed since, such as ArchiMate (The Open Group,
2012), the Zachman framework (Zachman, 2003), or TOGAF (The Open Group). The layers
of these models traditionally correspond to different levels of the organizations IS structure.
Eg. The business layer represents the concept that exists at the business layer such as the
contracts, the functions, processes, the actors, their business roles, the collaboration among
parties, and so forth. This business layer is afterwards supported and represented by IT
application layers. At this application layer the concepts of the IS that are structured around
the concepts of applications, of application objects, of application function, the application
collaboration, of interface, and so forth. Finally, this application is equally supported and
sustained by the technical layer which is composed of elements such as the network, the
server, the router, the firewall, the technical platform, and so forth. The advantages of these
 Security Policy Design for Complex SCADA System Management

enterprise architecture models are that they allow enhancing the relationship among
elements from each layer and, thereby, allow a better integration, collaboration and an
enhanced support for the decision making processes.
Up to date, elements modelled at the business layer (Feltus et al., 2014, Zambonelli et
al., 2003, Feltus et al., 2012a) are perceived as human entities assigned to business roles at
the enterprise level and, in the current context, at the SCADA configuration level.
Whatsoever, arriving security needs for the management of complex, heterogeneous and
distributed architectures ask for a rebuilding of distribution and handling of the security
procedures in both: human and software autonomous entities. Although having been
handled by human entities for decades, the management of complex systems, nowadays,
requires to be shared with intelligent software components, often perceived as more suited
to behave according to critical environment. This statement is enforced by the ability and
the capability of these component to act autonomously in open, distributed and
heterogeneous context, in connection or not with an upper committed authority.
Acknowledging this situation, we are forced to admit that SCADA (Choi et al., 2009)
elements are no longer to be considered only as basic stand-alone approach deployed to
sustain business activities, however they are part of crisis reaction strategy (Gateau et al.,
2009). Since then, acquiring an innovative enterprise architecture solution to represent the
comportment of such components sounds completely and fully motivated in regard with of
the arising cyber protection principles and rules dictated by the practitioners, especially the
ones engaged in the management of those critical infrastructures security protection. By
doing so, the paper will provide innovative approach based on SCADA architecture design
for solving the problems related to the management of the critical and highly sensitive
infrastructures and this, in accordance with the arising requirements related to the sustain
and visualization of the decision mechanisms issues at the managerial and tactical point of
view.
In this research, we propose a complement to (Feltus et al. (2014)) to explore
ArchiMate and to redesign its structure in order to comply with component software actors
characteristics, specificities and domain constraints. The principal focus concerns the design
and the consideration of the policies that are centric concepts related to the activation of
components comportment. All along the modeling of the SCADA system platform and the
definition of the policies according to these models, we will illustrate the corresponding
theory with a case study addressing the petroleum supply chain, and more specially the
specific functions of Crude Oil Supply and Crude Oil Storage and Distribution. This
extended case is explained in Section 2. In Section 3, we will review the SCADA
components metamodel and the SCADA layers for crisis management and we will model
the concept of policy (Gateau et al (2008a), Neiro et al. (2004)) that represents the engine
of the component modeling framework in Section 4. Section 5 provides related works and
Section 6 concludes the paper.

2 Complex oil distribution test case motivations

To represent the modelling of SCADA components metamodel and policy generation, we

are going to illustrate this paper with the reference case study presented in Neiro et al.,
2004:
 C. Feltus and D. Khadraoui

The case study represents the real world petroleum supply chain planning
problem of Petrobras (Neiro et al., 2004). Petrobras has 59 petroleum exploration
sites among which 43 are offshore, 11 refineries that are located along the
countrys territory and a large number of facilities such as terminals and pipeline
networks. Refinery sites are concentrated mainly in southern [of the country]
where 7 sites are found, 4 of which represent 47% of the companys processing
capacity. These refineries are located in the most important and strategic
consumer markets. Therefore, the present work addresses the supply chain
comprised of these 4 refineries, namely: REVAP, RPBC, REPLAN and RECAP
(Figure 1). Five terminals compose the storage facilities, namely: SEBAT,
SEGUA, CUBATAO, SCS and OSBRA; and a pipeline network for crude oil
supply and another for product distribution compose the transportation facilities.

Figure 1 Petroleum architecture plan (extracted from Neiro et al., 2004)

Figure 2 Products storage and distribution SCADA (extracted from Neiro et al., 2004)

Figure 1 includes two separate functions on the same infrastructure, the Crude Oil
Supply and the Product Storage and Distribution part. The crude oil supply (COS) function
aims at acquiring crude oil from a variety of suppliers. The oil has different properties,
depending on these suppliers, and therefore, requires specific distribution properties and
storage tanks. Crude oil is delivered through SEBAT and from there, is equally distributed
to RECAP and REVAP, RPBC and REPLAN. Regarding the product storage and
distribution, two types of oil are deal with: oil destined to the local market (black tanks on
 Security Policy Design for Complex SCADA System Management

Figure 2) and for other regions (grey tanks). The product at the destination of regional
market is transferred either by vessels (through CUBATAO or SEBAT) or by pipeline
(through OSBRA).Both function security is managed by dedicated and integrated SCADA
systems. Their behavioral and technical policies are hence inter-independents
(Prometheuse Technology, 1991).

3 SCADA metamodel backgrounds

This section recalls our previous work in the field of SCADA system modelling and policy
engineering. We first introduce the SCADA metamodel as an extension of ArchiMate,
then the SCADA modelling layers and finally, based upon the SCADA system models, the
SCADA policy engineering approach.
3.1 SCADA metamodelling insights
The SCADA metamodel has been largely, and with many details, presented in Feltus et al,
2014. This Section 3.1 recalls and summarises the theoretic foundation and premise of our
research in this area. The goal in modelling the SCADA system into a layered architecture
metamodel is to furnish CI (Feltus, 2010) actors with solution for governing SCADA
platform (monitoring and decision making support mechanism). In our previous works
(Feltus et al., 2014, Feltus, 2014, Guemkam et al., 2013), extended SCADA metamodel
using the ArchiMate metamodel was elaborated to provide and support the use of a
multiple layered approach of a SCADA component based on dynamic and autonomous
policies.
To generate the latter, we realized a specialization of the original ArchiMate
metamodel for SCADA components. First, we redefined and structure the Core of the
metamodel in order to figure out the semantic of the Policy (Figure 3.). The Core represents
the handling of Passive Structures by Active Structures along the realization of Behaviors.
Concerning the Active Structures and the Behavior, the Core differentiates between
external concepts which represent the way in which the architecture is being perceived by
the external elements (as a Service Provider attainable by means of an Interface), and the
internal elements which is composed of Structure Elements (Roles, Components) and
linked to a Policy Execution concept. Passive Structures contains Object (eg, data or
organizational object) which represents architecture knowledge. Secondly, the concept of
Policy has been defined in accordance to the SCADA metamodelling approach. The
proposed representation is composed of three elements whish allow defining the Policy
structure: (1) the Event that is defined as a trigger generated by a Structural component
that generates the realization of a Policy. (2) the Context whish symbolizes a
configuration of Passive Structure that allows the Policy to be realized. (3) the
Responsibility (Neumann et al., 2002, Zachmann, 2003) which is the more rich semantic
concept and which is defined as a state assigned to a component (human or software) to
specify obligations and rights in a specific context (Feltus, 2014).
Thereby, the responsibility corresponds to a set of behaviors that have to be realized by
means of Structure Elements. That behavior may also use Objects of y type Passive
Structure or modify values. With these three elements, we generate an auxiliary Policy
artefact that mirrors the fulfilment of a set of Responsibilities (Feltus et al., 2009a), Feltus
et al., 2009b) in a specific SCADA Context and in response to a predefined Event. Through
the Policy Concept, we show that each operation done by the SCADA components can be
 C. Feltus and D. Khadraoui

transferred into a Policy Execution.

Although there is a clear semantic difference in ArchiMate between the business user
(human or machine) which exploits an application, and the application itself, in the
SCADA field, we consider that actors and roles are played by components that we define
as being a specific Structure Elements acting in Critical Infrastructure environment. As a
result, three level are necessary to structure the metamodel for the SCADA domain: (1)
The Organizational Layer offers services and products to external customers that are
represented in the organization by organizational processes performed by Organizational
Roles according to Organizational Policies. (2) The Application Layer supports the
Organizational Layer with Application Services which are realized by Applications
according to Application Policies. (3) The Technology Layer which offers Infrastructure
Services needed to run applications, performed by system software, computer and
communication hardware.
Concepts and colors were taken from the original ArchiMate language, except for
Organizational Function and the Application Function which were switched with the
Organizational Policy component and the Application Policy component. Based on the
following analysis, we have defined the Organizational Policy as the rules which define
the organizational responsibilities and govern the execution of behaviours, at the
organization domain, that serve the product domain in response to a process domain
occurring in a specific context, which is symbolized by a configuration of the
information domain.
And we have defined the Application Policy as the rules that define the application
responsibilities and govern the execution, at the application domain, of behaviours that
serve the data domain to achieve the application strategy.
3.2 SCADA metamodel layers
The three layers which structure the SCADA metamodel (Figure 3) are from down to top:
the technical level, the applicative level and the organisation or business level.
The Technical Layer is used to represent the structural aspect of the system and
highlights the links between the Technical Layer and the Application Layer and how
physical pieces of information called Artefacts are produced or used. The main concept of
the Technical layer is the Node which represents a computational resource on which
Artefacts can be deployed and executed. The Node can be accessed by other Nodes or by
components of the Application Layer. A Node is composed of a Device and a System
Software (Beydoun et al., 2005). Devices are physical computational resources where
Artefacts are deployed when the System Software represents a software environment for
types of components and objects. Communication between the Nodes of the Technology
Layer is defined logically by the Communication Path and physically by the Network.
An Organizational Object defines unit of information which relates to an aspect of the
organization. At the Application layer, this is used to represent the Application Components
and their interactions with the Application Service derived from the Organizational Policy
of the Organizational Layer. The concept of the components in the metamodel is very
similar to the components concept of UML (UML 2) and allows representing any part of
the program. Components use Data Object which is a modelling concept of objects and
object types of UML. Interconnection between components is modelled by the Application
Interface in order to represent the availability of a component to the outside (Feltus, 2014)
(implementing a part or all of the services defined in the Application Service). The concept
of Collaboration from the Organizational Layer is present in the Application Layer as the
 Security Policy Design for Complex SCADA System Management

Application Collaboration and can be used to symbolize the cooperation (temporary)

between components for the realization of behavior. Application Policy represents the
behavior that is carried out by the components.
The Organizational Layer highlights the organizational processes and the associations
with the Application Layer. Firstly, the Organizational Layer is defined as an
Organizational Role (eg. Alert Detection Concept). This role, accessible from outside the
SCADA behavioral structure through an Organizational Interface, performs behavior
based on and according to organization's policy (Organizational Policy component) which
are associated with the role. Afterwards, the components are able (depending on their roles
but also function1 is some cases) to interact with other roles to perform behavior; this is
symbolized by the concept of Role Collaboration outside (Feltus, 2014). Organizational
Policies are behavioral components of the organization whose goal is to achieve an
Organizational Service to a role following Events. Organizational Services are contained
in Products accompanied by Contracts. Contracts are formal or informal specifications of
the rights and obligations associated with a Product. Values are defined as an appreciation
of a Service or a Product that the Organization attempts to provide or acquire.
The complete SCADA metamodel is the union of the three layers. As shown below,
new connections between the layers have appeared. For the Passive Structure we observe
that Artefact of the Technical Layer realizes Data Object of the Application Layer which,
itself, realizes Organizational Object of the Organizational layer.
The Behaviour concept association shows that the Application Service uses the
Organizational Policy to determine the services that it sustain. In the same manner, the
Technical Layer bases its Infrastructure Service upon the Application Policy of the
Application Layer. Concerning the Active Structure connections, the Role concept
determines, together whit the Application Component, the Interface provided in the
Application layer. The Interface of the Technical Layer is also based on the components of
the Application Layer.
The modelling language related to the above artefact is available in The Open Group.
3.4 SCADA model instance for Crude oil RTU network
The crude oil distribution presented at the Section 2 includes both the oil supply and
product distribution SCADA systems. Interconnection amongst RTU (Remote Terminal
Unit) (Bailey et al., 2003) of those SCADA is achieved using MTU (Gateau et al., 2009).
The acronym MTU stands for Master Terminal Unit and its main purpose is to accept the
different inputs from the remotely connected devices and to transmit these inputs over the
rest of the network.
Using the ArchiMate for SCADA system theory introduced in previous sections, the
SCADA RTU of the crude oil distribution SCADA from the distributed plants may be
modeled as illustrated on Figure 4. As illustrated in this figure, both layers of the RTU are
represented, the COS SCADA RTU Networks Organization (RTU-COSNO) and the
COSSCADA RTU Networks Application (RTU-COSNA).
At the COSNO layer, the crude oil network SCADA is composed of Crude oil portfolio
that is assigned to Call for IN (aka Organizational alert IN), of application RTU monitoring
services (eg. Moni SEGUA and Moni SEBAT (Figure 4)), of RT information that impacts
the generation of RTU behavioral policies.

1
The function is defined in [40] as as a behavior element that groups behavior based on a chosen
set of criteria (typically required business resources and/or competences)
 C. Feltus and D. Khadraoui

Figure 3 Three layers of SCADA system metamodel extracted from Feltus, 2014.

On the other side, the SEGUA and the SEBAT RTU (for instance) are represented as
actor of the RTU organization and are composed of RTU network console dedicated to the
SCADA management (Kato et al., 1992). Both later are associated to the artifact modelled
by the orange box that correspond to a collaboration between both SCADA functions, the
crude oil supply and the product storage and product distribution. At the COSNA layer,
four RTU/technical layer are modelled, respectively the SEGUA, SEBAT, RPBC and
REVAP. The structure of this RTU/Technical layer is naturally always quite the same and
is composed of the technical monitoring service (corresponding to the core of the RTU
such as commonly addressed by the literature (Yorozu et al., 1892), and of the interface
named in-[RTU/network location] which aims at connection the monitoring service with
the RTU application itself. As illustrated at the level of the SEBAT model, the RTU
application is potentially connected with the others RTUs applications artefacts (cf. two-
ring symbol).
As summary, in this section we have presented a metamodel for SCADA systems. This
metamodel allows representing all the component of the SCADA following three layers:
the organization, the application and the technical layers. Those models offer the
advantages to easily figure out the structure of the concepts and their interconnections and
 Security Policy Design for Complex SCADA System Management

thereby, to easily capture the interconnection between the components within a SCADA
and among two or many SCADAs or SCADA functions. Given those advantages, the next
section explains how management policies may be designed and defined according to
instance of this SCADA metamodel. Concretely, the usage of the metamodel has been
illustrated through a crude oil supply and distribution plan SCADA and connections have
been depicted among the crude oil supply and the crude oil storage and distribution
function of the SCADA system.
Figure 4 Crude oil SCADA MTU-RTU instance

4 SCADA policy management

Based on ArchiMate SCADA metamodel presented in Section 3 and illustrated by the

Crude Oil Supply SCADA, this section introduces the artefact of policy model by
ArchiMate. Two types of Policy are depicted: the Cognitive and the Permissive (Jiao et
al., 1999).
4.1. Policy family
At the Organizational Layer, Policy can be represented as an UML Use Case (UML 2)
where concepts of Roles represent the Actors which have Responsibilities in the Use
Case, and the Collaboration concepts show the connections between them. Concepts of
Products, Value and Organizational Service provide the Goal of the Use Case. Pre- and
Post-conditions model the context of the Use Case and are symbolized in the metamodel
by the Event concept (pre-condition) and the Organizational Object (pre-/post-
condition).
In the Application Layer, Application Policy is defined as the realization of
 C. Feltus and D. Khadraoui

Responsibilities by the Application Domain in a configuration of the Data Domain. UML

provides support for modelling the behavior performed by the Application Domain as
Sequence Diagram. Configuration of the Data Domain can be expressed as Pre-conditions
of the Sequence Diagram and symbolized by the execution of a test-method on the lifeline
of the diagram. The metamodel designed in Section 3 has allowed providing the SCADA
operators and managers with a holistic and integrated view of the SCADA architecture
building blocks. In practice and to have policy extracted according to the metamodel
concepts interconnections, this SCADA metamodel firstly needs to be instantiated for each
architecture components.

Figure 5 Example of policies among SCADA components artefacts

This step is achieved by shaping the component according to the three abstractions
typically advocated by the enterprise architecture paradigm (UML 2, Jiao et al., 1999,
Feltus et al., 2012b). This allows discovering the building artefacts of the components as
well as the connections amongst the components artefacts. An example of this instantiation
is represented in Figure 4. The representation of each component implies paramount
outcomes for the SCADA operator since it confers to the latter a global functional insight
of each component irrespective of any implementation or vendors influence. The unitary
SCADA component models are than used in the second step to picture out the global
structure of the SCADA architecture and of the connections, in terms of policies, amongst
the components of the architecture. Figure 5 highlights the two families of policies
recovered in SCADA: Permissive policies and Cognitive policies.
Cognitive Policies are represented in blue in Figure 5. They represent policies which
govern the behavior of one artefact of the component architecture. This policy specifies the
rule that the Responsible artefact needs to follow to execute a defined activity in a specific
 Security Policy Design for Complex SCADA System Management

context. This rule is dictated by the artefact which exists in the same component or in
another one. The artefact which generates the policy is the Master and the one which
execute it is the Slave. The Cognitive Policy morphology is articulated on the following set
of attributes (Feltus et al., 2012b): Master artefact, Slave artefact, Master component, Slave
component, Behaving rule, Trigger item, Usage context, Priority extension (Table 1).
The application schema of a CP, as presented in Figure 2, obeys the two following
controls: (1) the communication path is from a Master structural concept to a Slave
behavioral concept or (2) the communication path is from a Master behavioral artefact to
another Slave behavioral artefact.
Table 1 Cognitive policy attributes name and attributes ID
Attribute Name Attributes ID
Master artefact CP-Ma-art
Salve artefact CP-S-art
Master component CP-Ma-Com
Slave component CP-S-Com
Behaving rule CP-Ru
Trigger item CP-TI
Usage context CP-UC
Priority extension CP-prior

Permissive Policies are represented in red in Figure 2. They represent policies which
govern the knowledge acquisition rules from the Master to the Slave artefact (Sabater et
al.) This knowledge acquisition traditionally takes the form of SCADA states data accessed
or provided in order to provide the Responsible with the access (of in, out, in_out
types (Eason et al., 1955) to successive Cognitive Policies in case of occurring events. The
Permissive Policies morphology is articulated on the following set of attributes [(perceived
by Eason et al., 1955). Master artefact, Slave artefact, Master component, Slave
component, Permission rules, Pre-permission conditions, Master permission cardinality,
Slave permission cardinality, and Cognitive constraints (Table 2) - sustained by Cognitive
Policy.
Table 2 Permissive Policy attributes name and attributes ID
Attribute Name Attribute ID
Master artefact PP-Ma-art
Slave artefact PP-S-art
Master component PP-Ma-Com
Slave component PP-S-Com
Permission rules PP-Ru
Permission conditions PP-Condi
Master permission cardinality PP-Ma-Car
Slave permission cardinality PP-S-Car
Cognitive constraints PP-Co. con

The application schema of a CP, as highlighted in Figure 2, obeys the two following
controls: (1) the communication path is from a Master structural artefact to a Slave
informational artefact or (2) the communication path is from a Master behavioural artefact
to a Slave informational artefact.
 C. Feltus and D. Khadraoui

4.2 Policy identification method

Designing automatic management strategy requires a rigorous two phases policy
elaboration mechanism, respectively the policy scheme identification and the policy
scheme formalization.
4.2.1 Policy scheme identification step
The first step is itself structured in three phases. The first one aims at identifying the
structure of the CI architecture in terms of unitary modules (components), including their
three layers of abstraction build upon the SCADA metamodel (ie.: organization,
application, and technical). The second phase aims at identifying the external parameters
of the CI such as potential threat probes and indicators that may impact the CI normal
functioning (flood, hijacking, etc.), the physical environment, and/or the contractual SLA
(service level agreement). The third phase aims at identifying the reaction policies which
may be of two types: Cognitive (artefact of a CI component which needs information from
succeeding artefacts Blue connections on Figure 1) or Permissive (artefact of a CI
component which needs permission upon the succeeding lower layer artefacts Red
connections on Figure 1). Both types of policies are explained in Feltus et al., 2013b.
4.2.2 Policy scheme formalization step
After policies being identified, the second step of the method aims at formalizing policy
scheme using a three phases approach. The first one aims at depicting the Master-Slave
communication artefacts (organization-organization, organization-technical, and technical-
technical), the second aims at identifying the cognitive and permissive behaviour based on
the automatic reaction strategy, and the last one aims at formalizing the policies
accordingly. This latter is function of the policy type and is achieved, on one hand, with
the inter-artefacts knowledge requirement, external probes and monitoring tools in case of
cognitive policy and with the reaction strategy with the requirement of access to artefacts
in case of permissive policy.
4.3 Inter Critical Infrastructures Study Case
This second part of the case study aims at defining cognitive and permissive security
policies supported by the MTU-RTU model from Figure 4. In Beaver et al, 2002, authors
argue that SCADA system network is different from general network environment due to
its operational environment in national infrastructure. Therefore, in such a context, the
SCADA system needs important broadcast capability which must be highly protected.
Among these protection mechanisms are the key management schemes (Beaver et al., 2002,
Dawson et al., 2006) that also have to support the multicasting messages protection. Figure
6 illustrates the modelling of permissive and cognitive policies related to the Key
Management Exchange such as expressed by (Beaver et al. 2012) among the MTU
dedicated to the crude oil supply function and the RTU from this function and from the
storage and distribution function. This field has already been tackled by many researches
such as (Beaver et al. 2012). (Beaver et al. 2012) has been preferred for this case illustration
provided that it reduces consistently the number of keys to be stored and provides
multicasting and broadcasting communication for efficient and stable operation of SCADA
systems. Hence, the policies dedicated to the management of this broadcasting will be
defined in the following.
Three constraints related to the key management broadcasting mechanism related to the
 Security Policy Design for Complex SCADA System Management

SCADA architecture have been defined by Bailey et al., 2003 and need to be considered
along the modelling of the policies: (1) the computational capacity limit which may be
represented as an artefact of a type data object at the application layer of the MTU, (2) the
low data transmission rate which is also a concept related to the MTU by means of a data
object, and (3) the real-time processing that needs to be consider to prevent data processing
delay and which may be represented as a data object from the RTUs structures. From Figure
6, we observe the following list of policies.
Firstly at the organization layer: the MTU Management policy (1), and secondly at the
application layer: the crude oil supply policy /MTU S1 (2) and /RTU S1 (3) and the crude
oil storage /RTU Sto1 (4). (1) is existing at the organizational layer and is realized by (2)
at the technical layer. This first family of policies (1) accesses the key exchange
value that represents the real encryption parameter introduced by the SCADA operator
through the dedicated interface (aka MTU screen). The later aims at supporting the key
management service which is represented by the key management unit artefact. It
has the right of a type in, out, in/out on the key set MTU, key set S1 and
key set sto1 data objects. This policy is a permissive policy provided that it gives an
authorization. This policy is defined in Table III.
The second family of policies depicted through the RTU-MTU model concerns the
application layer policies named MTU S1, RTU S1 and RTU Sto1. These policies
are directly assigned and dictate the expected behavior of the application function (in this
case, the selection of the encryption ID and system).
These policies correspond to Cognitive policies and are defined in Table 4. They
express that 1 of the MTU S1, RTU S1 or RTU sto1 policy (master artefact) may
Select key Encryption ID, May enforce Key Encryption ID and
Algorithm (Donghyun et al., 2009) related to the application MTU S1, RTU S1 and
RTU sto1 (slave artefact) if there exist at least one permission of a type Comp.-
capa.-Limit, trans.-rate, real-ti.-proc.To process the above
Cognitive policies, the MTU S1, RTU S1 and RTU Sto1 policies required to collect
information related to the key by directly accessing the respective key set data object
artefact, to know: Key Set MTU, Key Set S1 and Key Set Sto1.This collect
of information is possible if the appropriate permissive policies are defined and deployed
in the SCADA. For the sake of clarity, the later have not been represented in the MTU-
RTU model.
Table 3 Permissive policy for attributes name and attributes ID
Attribute Name Attributes ID
Master artefact Organisational service
Salve artefact Data objects
Master component Key management unit
Slave component key set MTU, key set S1 and key set sto1
Permission rules In/Out/In-Out
Permission conditions of set of Master-Slave Associations
Master permission cardinality 1
Slave permission cardinality 1..n
Cognitive constraints Key exchange values
 C. Feltus and D. Khadraoui

Table 4 Cognitive Policy attributes name and attributes ID

Attribute Name Attribute ID
Master artefact Application service
Slave artefact Application
Master component Policy MTU S1, Policy RTU S1, Policy RTU
Sto1
Slave component MTU S1, RTU S1, RTU Sto1
Permission rules Select key Encryption ID Enforce Key
Encryption ID and Algorithm
Permission conditions Comp.-capa.-Limit, trans.-rate, real-ti.-
proc
Master permission cardinality 1
Slave permission cardinality 1
Cognitive constraints of Technical MTU S1, RTU S1, STU Sto1.
Figure 6 MTU-RTU Key distribution case

Although the MTU S1 and RTU S1 are SCADA artefacts from the same SCADA
(crude oil supply SCADA), RTU Sto1 is an artefact from another function, ie.: crude oil
storage and distribution. The later consists in an alternative SCADA system. Using the
ArchiMate metamodel for modelling SCADA policies of a type cognitive or permissive
at both the organizational and the technical layers has allowed representing heterogeneous
SCADA policies from two different SCADA using the same language (ie.: ArchiMate for
SCADA systems).
 Security Policy Design for Complex SCADA System Management

5 Evaluation

The metamodel for cognitive and semantic policies deployment, design in our previous
work (Feltus et al., 2014), and the method for managing these policies (design, deployment
and update) has been evaluated within the frame of a laboratory case and the feedback from
the users during the modelling of the solution and the exploitation of both types of policies
has been collected and analysed.
Globally, this lab case has consisted in modelling the case study proposed in Neiro et
al., 2004, using the ArchiMate extension for SCADA system proposed in Feltus et al.,
2014 and recalled in this paper, in expressing semantic and cognitive policies based upon
some the instances of the metamodel, and in defining a set of view for expressing different
aspects related to the management of cognitive and semantic parameters to be considered
along the management of the critical and sensitive infrastructures (ie.: petroleum supply
chain).
The objective of these view being the management of specific aspects related to critical
(and petroleum supply chain) infrastructures. To model the infrastructure, the software tool
Archi1 has been adopted and three dedicated view have been modelled: The complete
architecture of the petroleum supply critical infrastructure, the related semantic policies
and the related cognitive policies. Based on the view, an analysis has been achieved in
order to understand to what extend the metamodel whish sustain the elaboration of these
views is complete and accurate enough in order to express critical security issues and
policies for counter-measure deployments, related to the latter. Globally, the observations
made during this lab case have revealed that the metamodel basic concepts have been
designed at the appropriate abstraction layer to model real case instances. Indeed, all the
concerns identify within the Petrobra case have been represented through existing concepts
or through extensions of these concepts.
At a policy layer, the semantic and cognitive policies have been analyzed following an
enhancement perspective, in order to move to a dynamic auto-regulation of the
infrastructure. This evaluation has proved the advantages of the view-based approach,
sustain by ArchiMate, for the decision making mechanism related to cognitive policies
deployment.
The pros of our contribution, as a result, consists in a real support for the management
of policies related to critical infrastructures and, hence, a sound contribution to sustain
the managers of these infrastructure in defining and deploying the semantic and cognitive
policies. This support is mainly due to the add value generated by the view-based
management sustained by the proposed SCADA metamodel presented in Feltus et al.,
2014, and exploited and enriched in this paper.
The cons of our contribution relate to the level of deployment of the solution proposed
which for the moment lacks of concrete links with others SCADA management tools. An
improvement of this problem should be possible based on our futures work and considering
complementary evaluations and deployments.
The review of the related works in Section 6 open the door for some arising
opportunities in that matter.

1http://www.archimatetool.com/ - A free and open source modelling tool to create ArchiMate

models and sketches.
 C. Feltus and D. Khadraoui

6 Related Works

Literatures explain methodologies to model Multi-Agent System (MAS) and their

environments as a one layer model and give complete solutions or frameworks. Gaia
(Zambonelli et al., 2003) is a framework for the development of agent architectures based
on a lifecycle approach (requirements, analysis, conceptualization and implementation).
AUML and MAS-ML (Torres da Silva et al., 2004, are extensions of the UML language
for the modelling of MAS but do no longer exist following the release by the OMG of
UML 2.0 supporting MAS. Prometheus defines a metamodel of the application layer and
allows generating organizational diagrams, roles diagrams, classes diagrams, sequences
diagrams and so forth. It permits to generate codes but does not provide links between
diagrams and therefore makes it difficult to use for alignment purposes or with other
languages (eg. MOF, DSML4MAS). CARBA provides a dynamic architecture for MAS
similar to the middleware CORBA based on the role played by the agent.
Globally, we observe that these solutions aim at modelling the application layer of
MAS. CARBA goes one step further introduces the concept of Interface and Service. This
approach is closed to the solution based on ArchiMate that we design in our proposal but
offers less modelling features. As we have notice that agent systems are organized in a way
close to the enterprises system, our proposal analyses how an enterprise architecture model
may be slightly reworked and adapted for MAS. Therefore, we exploit ArchiMate which
has the following advantages to be supported by The Open Group. It has a large community
and proposes a uniform structure to model enterprise architecture. Another advantage of
ArchiMate is that it uses referenced existing modelling languages like UML.
As a conclusion of the related work, we may consider that our approach may be
used in parallel to existing solutions while, in the same time, complete their added value in
a set of business driven dimensions like the visualisation of the system or the elaboration
of integrated and self-contain two types of policies. The evolution of our approach may
also be regarded following the performance generated at the metric level. Indeed, contrarily
to solutions presented through the state of the art, our proposal fit fully with the
measurement theory requirement and, hence, may be more pragmatically devoted to
performance based design of critical and highly sensitive infrastructures.

7 Conclusions

SCADA systems are important solutions to secure critical infrastructures against traditional
and cyber-attacks threats. Those systems need to be accurately managed and protected in
terms of interconnection, homogeneity and real time reaction. Therefore, the paper
proposes an integrated approach for modelling the SCADA based on the enterprise
architecture modelling language and more specially ArchiMate which has been
particularly tailored for SCADA systems. Based on a dedicated metamodel, the paper has
demonstrated how technical, application and organization policies could be designed and
metamodeled, especially regarding the policy management for interconnected SCADA
systems for two of its functions. All along the modelling of the SCADA model and the
definition of the policies according to these models, we have illustrated the theory with a
business case study related to the petroleum supply chain, and more specially the specific
functions of crude oil supply and crude oil storage and distribution.
 Security Policy Design for Complex SCADA System Management

Acknowledgement
This research is supported by European FP7-Security project CockpiCI.

References
AUML (Component UML), http://www.auml.org/
Bailey, D., and Wright, E. (2003). Practical SCADA for industry. Elsevier, 2003 - 288
pages.
Beaver, C., Gallup, D., Neumann, W. and Torgerson, M. (2002), Key management for
SCADA Technical report, Sandia.
Beydoun, G., Gonzalez-Perez, C., Low, G. and Henderson-Sellers, B. (2005) Synthesis
of a generic MAS metamodel SIGSOFT Softw. Eng. Notes 30, 4, pp. 1-5.
Briesemeister, L., et al. (2010) Detection, correlation, and visualization of attacks against
critical infrastructure systems, Proceedings of the 8th PST, Canada.
Chan, M. L. (1991). Interrelation of distribution automation and demand-side
management. In Rural Electric Power Conference Papers Presented at the 35th
Annual Conference (pp. B1-1). IEEE.
Choi, D., Kim, H., Won, D., and Kim, S. (2009). Advanced key-management architecture
for secure SCADA communications. Power Delivery, IEEE Transactions on, 24(3),
pp. 1154-1163.
Clerk Maxwell, J. (1892) A Treatise on Electricity and Magnetism, 3rd ed., vol. 2.
Oxford: Clarendon, 1892, pp. 68-73.
Dawson, R., Boyd, C., Dawson, J., Manuel G. Nieto, (2006) SKMA A Key Management
Architecture for SCADA Systems In Proc. Fourth Australasian Information
Security Workshop, Vol. 54, pp. 138-192.
Donghyun, C.I, Hakman, K., Dongho, W., and Seungjoo, K. (2009) "Advanced Key-
Management Architecture for Secure SCADA Communications" Power Delivery,
IEEE Transactions on , vol.24, no.3, pp. 1154,1163, July 2009
Eason, G., Noble, B., and Sneddon, I. N. (1955) On certain integrals of Lipschitz-Hankel
type involving products of Bessel functions Phil. Trans. Roy. Soc. London, vol.
A247, pp. 529-551, April 1955.
Feltus, C. (2008b) Preliminary Literature Review of Policy Engineering Methods -
Toward Responsibility Concept, International Conference on Information &
Communication Technologies: from Theory to Applications (IEEE ICTTA2008),
Damascus, Syria.
Feltus, C. (2010a) Conceptual Trusted Incident-Reaction Architecture, The 6th
International Network Conference 2010, June 2010, Heidelberg, Germany
Feltus, C., Dubois, E., Proper, E., Band, I. and Petit, M. (2012a) Enhancing the
ArchiMate standard with a responsibility modeling language for access rights
management. In Proceedings of the Fifth International Conference on Security of
Information and Networks (SIN '12). ACM, New York, NY, USA, pp. 12-19.
Feltus, C., Khadraoui, D., and Aubert, J. (2012b) A Security Decision-Reaction
Architecture for Heterogeneous Distributed Network 7th Int. Conference on
Availability, Reliability and Security. IEEE.
Feltus, C., Khadraoui, D., de Rmont, B., and Rifaut, A. (2007) Business Governance
based Policy Regulation for Security Incident Response, International Conference
on Risks and Security of Internet and Systems, Marrakech, Morocco.
Feltus, C. and Khadraoui, D. (2013b) On Designing Automatic Reaction Strategy for
Critical Infrastructure SCADA System 6th ACM International Conference on
Security of Information and Networks (ACM SIN 2013), Aksaray, Turkey.
 C. Feltus and D. Khadraoui

Feltus, C., Ouedraogo, M., and Khadraoui, K. (2014) Towards Cyber-Security Protection
of Critical Infrastructures by Generating Security Policy for SCADA Systems,
Proceedings of the 1st International Conference on Information and Communication
Technologies for Disaster Management, Algiers, Algeria.
Feltus, C., Petit, M. and Dubois, E. (2009a) Strengthening employee's responsibility to
enhance governance of IT: COBIT RACI chart case study. In Proceedings of the
first ACM workshop on Information security governance (WISG '09). ACM, New
York, NY, USA, pp. 23-32.
Feltus, C., Petit, M., (2009b) Building a Responsibility Model Including Accountability,
Capability and Commitment, Availability, Reliability and Security, 2009. ARES '09.
International Conference on , pp.412-419, March 2009.
Feltus, C., Petit, M. and Sloman, M., (2010b) Enhancement of Business IT Alignment by
Including Responsibility Components in RBAC, 5th International Workshop on
Business/IT Alignment and Interoperability (BUSITAL 2010), Hammamet, Tunisia.
Gteau, B., Feltus, C., Aubert, J., and Incoul, C. (2008a) An Agent-based Framework for
Identity Management: The Unsuspected Relation with ISO/IEC 15504, IEEE
International Conference on Research Challenges in Information Science (RCIS
2008), June 2008, Marrakech, Morocco
Gateau, B., Khadraoui, D. and Feltus, C. (2009c) "Multi-agents system service based
platform in telecommunication security incident reaction," Information Infrastructure
Symposium, GIIS '09. pp. 23-26, June 2009, doi: 10.1109/GIIS.2009.5307083
Gomez-Sanz, J. J., Pavon, J., and Garijo, F., (2002) Metamodels for building multi-
component systems, Proceedings of ACM symposium on Applied computing. ACM,
New York, NY, USA, pp. 37-41.
Guemkam, G., Blangenois, J., Feltus, C., and Khadraoui, D. (2013a) Metamodel for
Reputation based Agents System - Case Study for Electrical Distribution SCADA
Design, 6th ACM International Conference on Security of Information and Networks
(ACM SIN 2013), November 2013, Aksaray, Turkey.
Guemkam, G., Feltus, C., Schmitt, P., Bonhomme, C., Khadraoui, D., and Guessoum, Z.
(2011a) Reputation Based Dynamic Responsibility to Agent Assignement for
Critical Infrastructure In Proceedings of the IEEE/WIC/ACM International
Conferences on Web Intelligence and Intelligent Agent Technology - Vol. 2. IEEE
Computer Society, Washington, DC, USA, 272-275. DOI=10.1109/WI-
IAT.2011.194
Jacobs, I.S. and Bean, C.B. (1963) Fine particles, thin films and exchange anisotropy, in
Magnetism, vol. III, G.T. Rado and H. Suhl, 1963, pp. 271-350.
Jiao, W. and Shi; Z. (1999) A dynamic architecture for multi-component systems,
Technology of Object-Oriented Languages and Systems TOOLS 31. pp. 253-260.
Kato, K., and Fudeh, H. R. (1992). Performance simulation of distributed energy
management systems. Power Systems, IEEE Transactions on, 7(2), pp. 820-827.
Neiro, S.M.S. and Pinto, J. M. (2004) A general modeling framework for the operational
planning of petroleum supply chains, Computers & Chemical Engineering, Volume
28, Issues 67, pp. 871896.
Neumann, S., and Strembeck, M., (2002) A scenario-driven role engineering process for
functional rbac roles In SACMAT '02, USA, 2002. ACM.
Patel, S. C., Bhatt, G. D., & Graham, J. H. (2009). Improving the cyber security of
SCADA communication networks. Communications of the ACM, 52(7), pp. 139-
142.
Prometheus Methodology, http://www.cs.rmit.edu.au/agents/SAC2/methodology.html
 Security Policy Design for Complex SCADA System Management

Sabater, J. and Sierra, C. (2003) Review on computational trust and reputation models
Artificial Intelligence Review, vol. 24, no. 1, pp. 3360.
The Open Group, http://pubs.opengroup.org/architecture/archimate2-doc/
The Open Group (2012) ArchiMate 2.0 Specification. Van Haren Publishing, The
Netherlands.
The Open Group (TOGAF), http://pubs.opengroup.org/architecture/togaf9-doc/arch/
Torres da Silva, V., Choren, R. and de Lucena, C. J. P. (2004) A UML Based Approach
for Modeling and Implementing Multi-Component Systems In Proceedings of the
Third AAMAS, Vol. 2. IEEE Computer Society, Washington, DC, USA, pp. 914-921.
UML 2, http://www.uml.org/
Yorozu, Y., Hirano, M., Oka, K. and Tagawa, Y. (1892) Electron spectroscopy studies on
magneto-optical media and plastic substrate interface, IEEE Transl. J. Magn. Japan,
vol. 2, pp. 740-741, August, p. 301.
Zachman, J:A: (2003) The Zachman Framework For Enterprise Architecture : Primer for
Enterprise Engineering and Manufacturing By. Engineering, no. July, pp. 1-11.
Zambonelli, F., Jennings, N. R., and Wooldridge, M. (2003) Developing multicomponent
systems: The Gaia methodology. ACM Trans. Softw. Eng. Methodol. 12, 3 pp 317-
370.