Organizational security architecture for critical infrastructure

1. 1
Jonathan Blangenois‡†
, Guy Guemkam†Ґ
, Christophe Feltus†
, Djamel Khadraoui†
†
Public Research Centre Henri Tudor, Luxembourg-Kirchberg, Luxembourg
‡
University of Namur, Namur, Belgium
Ґ
Laboratoire LIP6, Université de Pierre et Marie Curie, Paris, France
christophe.feltus@tudor.lu
Abstract
The governance of critical infrastructures requires a
fail-safe dedicated security management organization.
This organization must provide the structure and mecha-
nisms necessary for supporting the business processes
execution, including: decision-making support and the
alignment of this latter with the application functions and
the network components. Most research in this field fo-
cuses on elaborating the SCADA system which embraces
components for data acquisition, alert correlation and
policy instantiation. At the application layer, one of the
most exploited approaches for supporting SCADA is
built up on multi-agent system technology. Notwith-
standing the extent of existing work, no model allows to
represent these systems in an integrated manner and to
consider different layers of the organization. Therefore,
we propose an innovative version of ArchiMate®
for
multi-agent purpose with the objective to enrich the
agent society collaboration and, more particularly, the
description of the agent’s behavior. Our work is has been
illustrated in the context of a critical infrastructure in the
field of a financial acquiring/issuing mechanism for card
payments.
Keywords: Critical infrastructure governance, ArchiMate®
,
Multi-agent System, Alignment, Case study, Financial
sector.
1. Introduction
Most research in the field of critical infrastructure
focuses on elaborating the SCADA system [18] [19]
which embraces the following three functions: data ac-
quisition at RTU level, alert correlation, policy instantia-
tion and deployment [20], each of the latter being opera-
tionalized with different technologies, protocols or
methods. These reaction tools are in practice operation-
alized at different layers of the management of the infra-
structure security, from the very technical layer, to the
application layer, up to the organizational layer. One of
the most exploited approaches for supporting critical
infrastructure is the use of agents [21]. Agents are indeed
perfectly adapted to operating in critical situation due to
their ability of being autonomous, open to all types of
technology. Most of the work related to agents tends to
consider that agents evolve and are organized in systems.
There exist some models for representing how these
agents are organized at a high level, models for repre-
senting how they are spread in the networks, models for
representing how they communicate with each other, and
so forth. As far as we know, there exist no model that
integrates all of the above dimensions and supports the
management and the governance of the MAS for crisis
situations. We do believe that such an integrated model
could have many advantages like e.g. a strong alignment
between the business processes that support crisis man-
agement and the technology that supports it, a knowledge
of the impact of actions from one layer to another, a de-
cision support that allows figuring out which action on a
component has the most influence on a set of other
components, to identify the most critical component for
an infrastructure, to align the agent system with the cor-
porate objective and to tailor it accordingly, and so on.
Enterprise architecture models are frameworks that allow
to represent the information system (IS) of companies in
(or on a set of) schemas. They underwent major im-
provements during the first decade of the 21st
century
and some outstanding frameworks were developed since,
such as ArchiMate®
[11], the Zachman framework [12],
or TOGAF [13]. These models are traditionally struc-
tured in layers that correspond to different levels of the
organizations’ IS. The business layer, for instance, mod-
els the concepts that exist at the business layer, such as
the processes, the employees, their business roles, etc.
and that are supported or represented by IT application
layers. At this application layer, the concepts of the IS
that are modelled are the applications, the databases, or
for instance, the application data. The advantages of
these models are that they allow improving the connec-
tions between the concepts from each layer and, thereby,
allow a better integration and an enhanced support of
decision making processes. Up to now, crisis manage-
ment has never been represented through the middle of
enterprise architecture. This representation could provide
many advantages, such as a better integration of the cri-
sis management functions, from their definition up to
their deployment. Notwithstanding the many advantages
Organizational Security Architecture for Critical Infrastructure

2. 2
of this representation, we are confronted with the man-
agement of heterogeneous and distributed architecture
which calls for a rethinking of the distribution of the se-
curity procedures between both: human and software
autonomous entities [21]. Although having been handled
by human employees for a long time, the organisational
policies of complex systems, nowadays, need to be
shared with intelligent software items, often perceived as
being more adapted for action in critical situations. These
policies are deployed considering the responsibility [23]
of the agent for autonomous acting in open, distributed
and heterogeneous environments, whether in connection
or not with an upper authority. Acknowledging this situ-
ation, we are forced to admit that software agents are no
longer to be considered only as basic software compo-
nents deployed to support business activities, but that
they are responsible [17], such as the business actors, for
playing some kind of “business role”, and for performing
“business tasks” accordingly. In view of this, acquiring
an innovative enterprise architecture framework that al-
low to represent the behavioural policies of such agents
appears fully justified and required by the practitioners,
especially the ones engaged in the management of those
critical infrastructures.
In this paper, we propose to explore ArchiMate®
, an en-
terprise Architecture framework, and to redraw its struc-
ture in order to fit in with agent software actors’ specific-
ities. The main focus concerns the design and the con-
sideration of responsibility driven policies (RDP) [16]
which are centric concepts related to the activation of
agents’ behaviours. The paper is structured as follows,
after having sighted the related works concerning enter-
prise architecture models in Section 2, we review and
model the concept of policy that represents the engine of
the agent modelling framework in Section 3. Section 4
explains layer by layer the entire metamodel and illus-
trates the different components. In Section 5 we present a
case study which illustrates the exploitation of the en-
hanced ArchiMate®
for Multi-agent System. Finally,
Section 6 concludes the paper.
2. State of the art and related works
Literature explains methodologies for modelling
Multi-agent System (MAS) and environment as a one
layer model and gives complete solutions or frameworks.
Gaia[1] is a framework for the development of agent
architectures based on a lifecycle approach (require-
ments, analysis, conceptualization and implementation).
Furthermore, AUML[6] and MAS-ML[2] are extensions
of the UML language for the modelling of MAS but are
no longer existing following the release of UML 2.0 by
the OMG [14] supporting MAS. Prometheus[7] defines a
metamodel of the application layer and allows to gener-
ate organizational diagrams, roles diagrams, classes’
diagrams, sequences diagrams and so forth. It permits to
generate codes, but does not provide links between dia-
grams and therefore makes it difficult to use for align-
ment purposes or with other languages (e.g. MOF [3],
Dsml4mas[5]). Globally, we observe that these solutions
aim at modelling the application layer of MAS. CAR-
BA[15] provides a dynamic architecture for MAS similar
to the middleware CORBA, which is based on the role
played by the agent. This approach introduces a concept
of Interface and Service which is similar to the one in
ArchiMate®
that we reused in our proposal.
We observed that agent systems for critical infrastructure
(CI) are organized in a way close to the enterprises sys-
tem, our idea is to analyse how an enterprise architecture
model may be slightly reworked and adapted to MAS.
Therefore, we decided to use ArchiMate®
which has the
following advantage of being supported by the Open
Group1
which has a large community and proposes a
uniform structure for modelling enterprise architecture.
Another advantage of ArchiMate®
is its use of a clear
link to existing modelling languages like UML. With
regard to this, we think that it is relevant to provide a
lean and simple structure compliant with the new version
of UML to model any MAS. As a conclusion of our state
of the art, we acknowledge the many other models or
frameworks which provide solutions for modelling MAS
whether they are compliant with other modeling lan-
guages or not. As far as we know, no existing approach
provides a multiple layer view or an integrated view of
these layers.
3. Policy Concept and Metamodel Core
Our goal in modelling the multi-agent system into an
architecture Metamodel is to provide system architects
and developers with the tools for creating their own mul-
ti-agent system including the notions of Agents Policy.
As explained in Section 2, we have selected the Archi-
Mate®
language to gives multiple layered view of a mul-
ti-agent system using policies.
Figure 1 : Responsibility Driven Policy(RDP)
In order to create this Metamodel, we realized a spe-
cialization of the original ArchiMate®
Metamodel for
1
http://www.opengroup.org/archimate/

3. 3
agent architecture. Firstly, we redefined the Core of the
metamodel (Figure 1) in order to figure out the concept
of Policy. The Core represents the handling of Passive
Structures by Active Structures during the realization of
Behaviours. For the Active Structures and the Behaviour
the Core differentiates external concepts which represent
how the architecture is being seen by the external con-
cept (as a Service provider attainable by an Interface),
and the internal concept which is composed of Structure
Elements (Roles, Components) and linked to a Policy
Execution concept. Passive Structures contains Object
(Data Object, Organizational Object, Artefacts …) that
represents information of the architecture.
Secondly, the concept of Policy was defined in ac-
cordance with our specialization of the ArchiMate®
Metamodel. The proposed representation is composed of
three concepts defining the Policy (Figure 2):
Figure 2 : Policy concept
1. Event: Events are defined as something done by a
Structure Element that generates an execution of a Policy.
2. Context: Context symbolises a configuration of
Passive Structure that allows the Policy to be executed
(e.g. a security level, value for an object, and so forth).
3. Responsibility: Responsibility [9][17] is defined as a
state assigned to an Agent (human or software) to signify
him its obligations and rights in a specific context.
Thereby, responsibilities correspond to a set of behav-
iours that have to be performed by Structure Elements.
This behaviour can use Object from Passive Structure or
modify their values.
With these three concepts, we structured the Respon-
sibility driven Policy as an execution of a set of Respon-
sibilities in a specific Context and in response to an
Event.
Compared to the original ArchiMate®
language model,
we modified the headline of the Business Layer into Or-
ganizational Layer. The organizational view corresponds
more to our vision of an agent and allows the considera-
tion of multi-agent systems as an organization which is
relevant to policy rules.
Concepts and colours were taken from the original
ArchiMate®
Metamodel, except for Organizational
Function and the Application Function which were re-
placed by the Organizational Policy concept and the
Application Policy concept. Through the Policy concept
we show that each operation done by the agent can be
transferred into a Policy execution. Although in Archi-
Mate®
there is a semantic difference between the appli-
cation and the user who exploits the application, in our
model and in the agent world, there is an exact corre-
spondence between both. This results in the fact that the
concept of agent is not managed at the organizational
layer, thus by human operators, but that the latter tends
to consider the role as a set of entities managed by an
existing application. Hence, the metamodel ArchiMate®
for multi-agent system is structured in three layers:
1. The Organizational Layer offers products and ser-
vices to external customers, which are realized in the
organization by organizational processes performed by
Organizational Roles according to Organizational Poli-
cies.
2. The Application Layer supports the organizational
layer with Application Services which are realized by
Applications according to Application Policies.
3. The Technology Layer offers Infrastructure Ser-
vices needed to run applications, realized by computer and
communication hardware and system software.
Figure 3 represents the different domains covered by the
metamodel in relation to these layers.
Figure 3 : Metamodel structure
Based on this analysis, we defined the Organizational
Policy as:
The set of rules that defines the organizational
Responsibilities and governs the execution, by
the Organization domain, of behaviours that
serve the Product domain in response to a Pro-
cess domain occurred in a specific context, sym-
bolized by a configuration of the Information
domain.
And we defined the Application Policy as:
The set of rules that defines the application Re-
sponsibilities and governs the execution, by the
Application domain, of behaviours that serve the
Data domain to achieve the application strategy.
4. Agent System Metamodel
As explained in the previous Section, the metamodel
is a specialization of the original ArchiMate®
Metamod-
el. The next paragraphs delineate the concept from Ar-
chiMate®
illustrating each layer of the metamodel while
considering in parallel the concept of Policy.
Event Context Responsibilities

4. 4
4.1. Organizational Layer
The Organizational layer highlights the organizational
processes and their links to the Application layer. At first
the Organizational layer is defined by an Organizational
Role (e.g. Alert Detection Agent). This role, accessible
from the outside through an Organizational Interface,
performs behaviour on the basis of the organization's
Policy (Organizational Policy) associated with the role.
Then, the agent is able to, depending on its role interact
with other roles in order to perform behaviour; this is
symbolized by the concept of Role Collaboration. Or-
ganizational Policies are behavioural components of the
organization whose goals are to achieve an Organiza-
tional Service to a role depending on Events. Organiza-
tional Services are contained in Products accompanied
by Contracts. Contracts are formal or informal specifica-
tions of the rights and obligations associated with a
Product. Values are defined as an appreciation of a Ser-
vice or a Product that the Organization attempts to pro-
vide or acquire. The Organizational Objects define units
of information that relate to an aspect of the organiza-
tion.
4.2. Application Layer
The Application layer is used to represent the Applica-
tion Components and their interactions with the Applica-
tion Service derived from the Organizational Policy of
the Organizational layer. The concept of the components
in the metamodel is very similar to the components con-
cept of UML and allows representing any part of the
program. Components use Data Object which is a mod-
elling concept of objects and object types of UML. In-
terconnection between components is modelled by the
Application Interface in order to represent the availabil-
ity of a component to the outside (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 Applica-
tion Collaboration and can be used to symbolize the co-
operation (temporary) between components for the real-
ization of behaviour. Application Policy represents the
behaviour that is carried out by the components.
4.3. Technical Layer
Technical layer is used to represent the structural as-
pect of the system and highlights the links between the
Technical layer and the Application layer and how phys-
ical pieces of information called Artifacts 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 Node or by components of the
Application layer. A Node is composed of a Device and a
System Software. 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.
4.4. Inter-Layer Link
The complete Metamodel (Figure 6) is the union of the
three layers. As shown below, new connections between
the layers have appeared. For the Passive structure (Fig-
ure 4) we see that Artefact of the Technical Layer realiz-
es Data Object of the Application Layer which realizes
Organizational Object of the Organizational layer.
Figure 4 : Passive structure connections
Behaviour element (Figure 5) layers show that the
Application Service uses the Organizational Policy to
determine the services it proposes. In the same way, the
Technical layer bases his Infrastructure Service on the
Application Policy of the Application layer.
Figure 5 : Behaviour element connections
Concerning the Active Structure connection (Figure 7),
the Role concept determines, along with the Application
Component, the Interface provided in the Application
layer. Also, the Interface of the Technical layer is based
on the components of the Application layer.
4.5. Policy modelling
The organizational and the application policies
may, afterwards, be modelled as follows:
4.5.1. Organizational Policy
In the Organizational Layer, Organizational Pol-
icy can be represented as an UML Use Case [14] where
concepts of Roles represent the Actors which have re-
sponsibilities in the Use Case, and the Collaboration
concepts show the connections between them. Con-
cepts of Products, Value and Organizational Service
provide the Goal of the Use Case. Pre and Post condi-
tions model the context of the Use Case and are sym-
bolized in the Metamodel as the Event concept (Pre-
condition) and the Organizational Object (Pre/Post
condition).

5. 5
4.5.2. Application Policy
The Application Policy from the Application
Layer is defined in Section 3 as the realisation of Re-
sponsibilities by the Application domain in a configura-
tion of the Data domain. UML provides support for
modelling the behaviour performed by the Application
domain as Sequence Diagram. Configuration of the Data
domain can be expressed as Preconditions of the Se-
quence Diagram and symbolized by the execution of a
test-method on the lifeline of the diagram.
Figure 6 : ArchiMate®
metamodel for MAS
Figure 7 : Active structure connections
5. Case study in Financial CI
The case study concerns the reaction mechanism (Fig.
8) that aims at adapting the ciphering of the data accord-
ing to the bank’s interface whenever an alert occurs. This
mechanism is judged extremely critical for financial in-
stitutions since the corruption of card payment mecha-
nisms may paralyze an entire State if fraud happens. In
previous work [8], a MAS architecture was proposed in
order to support risk assessment for real time deci-
sion-making processes. The clearing mechanism associ-
ated to this architecture denotes all activities from the
time is a transaction is made until it is settled. This
Section introduces the core components of the reaction
mechanism. Agents are disseminated on three layers
corresponding to the clearing mechanism (custom-
er/issuer, acquiring/issuing processing, see Figure 8 and
Figure 9) and they retrieve information from probes lo-
cated at the network layer and representing different
values: network traffic, DoS attack (denial-of-service
attack, an attempt to make a computer resource unavail-
able to its intended users), suspicious connection at-
tempts, and so forth.
The architecture introduced and adapted from [16] is
composed of a set of agents with coordinated goals for
crisis management. Their roles were created to define the
architecture of agents with the ability to monitor devices
and report warnings to intelligent agents who make deci-
sions. This set of agents is composed of:
• The ACE Agent’s responsibilities are to collect,
aggregate and analyse network information coming from
probes deployed over the network and customer node.
Confirmed alerts are sent to the Policy Instantiation En-
gine (PIE).
• The PIE Agent’s responsibilities are to receive a
confirmed alert from the ACE, set the severity level and
the extent of the network response (depending on the
alert layer). The PIE instantiates high level alert messag-
es which have to be deployed. Finally, the high level
alert messages are transferred to the Reaction Deploy-
ment Point (RDP).
• The RDP Agent’s responsibilities is composed of
two modules. The Cryptography Analysis (CA) is in
charge of analysing the keys previously instantiated by
the PIE. Therefore, the Crypto Status stores required
properties for a secure asymmetric key so that the CA
module is able to check the eligibility of the newly re-
ceived key which will be deployed. Concretely, the CA
checks the key strength to see if the key has not been
used or revoked and tests if the cryptographic key is not
badly generated (modulus-factorization, etc.). The sec-
ond module, the Component Configuration Mapper, se-
lects the appropriate communication channel. In this
Section, we instantiated the metamodel related to an
ACE Agent as is it defined in previous work [8].
5.1. ACE Organizational layer
In the Organizational layer of the ACE Agent (Figure 10)
we represented the monitoring aspect separately from the
transaction aspect.

6. Figure 8 : Acquiring/Issuing process and association with the agents’ reaction architecture
We called a transaction a communication of infor-
mation from one agent to another (e.g. ACE sends alert
to PIE), and then we considered the monitoring as the
representation of information from an external device.
Figure 9 : Detailed agents architecture
Firstly, the Organizational Role of the ACE was rep-
resented as a Collaboration of the PIE Role and the De-
vice Role. Each Role of the Collaboration communicates
with the ACE through a proper Organizational Interface,
one for the monitoring and another one for the transac-
tion. ACE Role provides two Organizational Services
depending on only one Organizational Policy which is
dealing with two Events respectively for the monitoring
and the transaction. Secondly, the two Organizational
Services provided by the ACE agent were regrouped into
a correlation service symbolized by the Product concept.
This Product has the objective Value to reduce a crisis
by giving a guarantee of short reaction time represented
by the Contract concept. Finally the Contract was ap-
plied to the Organizational Object for monitoring infor-
mation and transaction information.
5.2. ACE Application layer
For the Application layer of the ACE Agent (Figure 10)
we distinguished between the transaction and the moni-
toring. Application Services for transactions and moni-
toring are, as in the Organizational Policy, linked to only
one Application Policy. To bring afore the collaboration
between the ACE and the Monitored Device, we created
a Collaboration concept named Monitoring Administra-
tion and show that this collaboration is constituted of the
Components of the ACE and the Components of the De-
vice. Device’s components use the Application Monitor-
ing Interface to communicate with the ACE’s compo-
nents, and the ACE’s components are composed of the
Application Monitoring Interface. We used the same
approach for the transaction part and rapidly pointed out
that the ACE’s components are composed of two inter-
faces that serve the two Application Services. Again the
Application layer contains Data Object as Transaction
Messages, and Monitoring Messages used by the differ-
ent Application Components of the layer.
5.3. ACE Technical layer
We found in the Technical layer of the ACE Agent
(Figure 10) another representation of the two collabora-
tors. Transaction and Monitoring Infrastructure are sep-
arated from each other. Both of them have Infrastructure
Service connected to the ACE agent’s Node and an In-
frastructure Interface where the collaborators can inter-
act with it. Each Node is respectively connected to a
Communication Path (represented by a logical Event
Queuing) and uses different Artefacts for communica-
tion. We have intentionally not instantiated Nodes for
readability, but it can easily be understand that an ACE
agent can be deployed on a computer who runs an oper-
ating system. Also, the Network concept is not defined in
our instantiation for the same reason. For example, Mon-
itoring Event Queue between the ACE agent and the De-
vice can be represented as a Network concept, by an
USB, and for the Transaction Event Queue, by an RJ45.

7. 7
Figure 10 : ACE agent model
5.4. ACE Organizational Policy
To illustrate the Organizational Policies of the ACE we
chose to represent the monitoring part of the ACE Role
as an UML Use Case (Figure 11). Monitoring Events are
illustrated in the Use Case as Extension Points and show
their impacts on the responsibilities realized in the Per-
form Monitoring Policy. Roles are presented as Actors,
and Collaborations are highlighted by the different links
between the behaviours.
5.5. ACE Application Policy
Sequences Diagrams were used to represent the respon-
sibilities performed by the Application Domain of the
ACE Agent for the Application Policy: Perform Detec-
tion (Figure 12).
Figure 11 : ACE Monitoring Organizational Policies Use Case
In the Sequence Diagram, the responsibilities of each
component are indicated on its lifeline, and in/out Events
are presented as inter-component methods call. Context
analysis is performed by the component during the exe-
cution of its behaviour.
Figure 12 : Perform Detection – High level Sequence Diagram
6. Conclusions
Aligning crisis management business processes with the
supportive application and technical layers is a crucial
governing activity. Despite the arising need for an inte-
grated alignment between enterprise layers, to date,
SCADA are supported by increasingly used multi-agent
which are particularly appropriate in the context of criti-
cal architecture. Indeed, MAS technology allows en-
hancing the connections between heterogeneous, open
and distributed components which are distributed around
the globe in infrastructure networks. In the state of the
art, we observed a lack of global architecture for model-
ling these MAS. Therefore, our work focused on adapt-
ing ArchiMate®
for a MAS usage. This ArchiMate®
ad-
aptation allowed the structuring of the policy concept
and, thereby, allowed synchronizi the behaviour between
many types of agents, spread over different types of crit-
ical architecture management components such as the
alert correlation engine, the intrusion detection tools, and
so forth. In order to illustrate the possibility of modelling

8. 8
one of these architectures with this enhanced ArchiMate®
for MAS, we modelled a critical architecture for the
management of financial infrastructures dedicated to
credit card management. The modelling brought forth a
clarification of the connection between the synchroniza-
tion of the event that is generated at the level of one
component policy and the one that triggers policies to
another component. Associations between modelling
policies and UML language were also illustrated by the
representation of the Organizational Policy as Use Case
and the representation of Application Policy as Sequence
Diagram.
7. Acknowledgements
The research described in this paper is funded by the
CockpitCI research project within the 7th framework
Programme (FP7) of the European Union (EU) (topic
SEC-2011.2.5-1 – Cyber-attacks against critical infra-
structures – Capability Project).
REFERENCES
[1] Franco Zambonelli, Nicholas R. Jennings, and Michael
Wooldridge. 2003. Developing multiagent systems: The Gaia
methodology. ACM Trans. Softw. Eng. Methodol. 12, 3 (July
2003), 317-370. DOI=10.1145/958961.958963
[2] Viviane Torres da Silva, Ricardo Choren, and Carlos J. P.
de Lucena. 2004. A UML Based Approach for Modeling and
Implementing Multi-Agent Systems. In Proceedings of the
Third International Joint Conference on Autonomous Agents
and Multiagent Systems - Volume 2 (AAMAS '04), Vol. 2.
IEEE Computer Society, Washington, DC, USA, 914-921.
DOI=10.1109/AAMAS.2004.36.
[3] J. J. Gomez-Sanz, J. Pavon, and F. Garijo. 2002. Meta-
models for building multi-agent systems. In Proceedings of the
2002 ACM symposium on Applied computing (SAC '02). ACM,
New York, NY, USA, 37-41.
[4] G. Beydoun, C. Gonzalez-Perez, G. Low, B. Hender-
son-Sellers. 2005. Synthesis of a generic MAS metamodel.
SIGSOFT Softw. Eng. Notes 30, 4 (May 2005), 1-5.
[5] C. Hahn. 2008. A domain specific modeling language for
multiagent systems. In Proceedings of the 7th international joint
conference on Autonomous agents and multiagent systems –
Vol. 1 International Foundation for Autonomous Agents and
Multiagent Systems, Richland, SC, 233-240.
[6] AUML (Agent UML), http://www.auml.org/
[7] Prometheus Methodology. http://www.cs.rmit.edu.au/
agents/SAC2/methodology.html
[8] Guy Guemkam, Christophe Feltus, Cédric Bonhomme,
Pierre Schmitt, Benjamin Gâteau, Djamel. Khadraoui, Zahia.
Guessoum, Financial Critical Infrastructure: A MAS Trusted
Architecture for Alert Detection and Authenticated Transac-
tions, Sixth IEEE Conference on Network Architecture and
Information System Security, La Rochelle, France
[9] Guy Guemkam, Christophe Feltus, Pierre Schmitt, Cedric
Bonhomme, Djamel Khadraoui, and Zahia Guessoum. 2011.
Reputation Based Dynamic Responsibility to Agent As-
signement for Critical Infrastructure. In Proceedings of the 2011
IEEE/WIC/ACM International Conferences on Web Intelli-
gence and Intelligent Agent Technology - Volume 02 (WI-IAT
'11), Vol. 2. IEEE Computer Society, Washington, DC, USA,
272-275. DOI=10.1109/WI-IAT.2011.194
[10] Christophe Feltus, Eric Dubois, Erik Proper, Iver Band,
and Michaël Petit. 2012. Enhancing the ArchiMate® standard
with a responsibility modeling language for access rights man-
agement. In Proceedings of the Fifth International Conference
on Security of Information and Networks (SIN '12). ACM, New
York, NY, USA, 12-19. DOI=10.1145/2388576.2388577
[11] Gustaf Neumann and Mark Strembeck. 2002. A scenar-
io-driven role engineering process for functional RBAC roles. In
Proceedings of the seventh ACM symposium on Access control
models and technologies (SACMAT '02). ACM, New York,
NY, USA, 33-42. DOI=10.1145/507711.507717 M.
[12] Lankhorst. ArchiMate language primer, 2004.
[13] Zachman, John A. 2003. The Zachman Framework For
Enterprise Architecture : Primer for Enterprise Engineering and
Manufacturing By. Engineering, no. July: 1-11.
[14] UML 2 ( http://www.uml.org/)
[15] W. Jiao, Z. Shi, A dynamic architecture for multi-agent
systems, Technology of Object-Oriented Languages and Sys-
tems, 1999. TOOLS 31. pp.253-260, 1999
[16] Cedric Bonhomme, Christophe Feltus, and Michaël Petit.
2011. Dynamic Responsibilities Assignment in Critical Elec-
tronic Institutions - A Context-Aware Solution for in Crisis
Access Right Management. In Proceedings of the 2011 Sixth
International Conference on Availability, Reliability and Secu-
rity (ARES '11). IEEE Computer Society, Washington, DC,
USA, 248-253. DOI=10.1109/ARES.2011.43
[17] Christophe Feltus and Michaël Petit, Building a Respon-
sibility Model Including Accountability, Capability and Com-
mitment, Fourth International Conference on Availability, Re-
liability and Security (“ARES 2009 – The International De-
pendability Conference”), DOI=10.1109/ARES.2009.45
[18] John D. Fernandez and Andres E. Fernandez. 2005.
SCADA systems: vulnerabilities and remediation. J. Comput.
Sci. Coll. 20, 4 (April 2005), 160-168.
[19] B. Miller and D. Rowe. 2012. A survey SCADA of and
critical infrastructure incidents. In Proceedings of the 1st Annual
conference on Research in information technology (RIIT '12).
ACM, New York, NY, USA, 51-56.
[20] J. Lloyd Hieb. 2008. Security Hardened Remote Terminal
Units for Scada Networks. Ph.D. Dissertation. University of
Louisville, Louisville, USA. AAI3308346.
[21] H.-M. Kim, D.-J. Kang, and T.-H. Kim. 2007. Flexible
Key Distribution for SCADA Network using Multi-Agent Sys-
tem. ECSIS Symposium on Bio-inspired, Learning, and Intel-
ligent Systems for Security, IEEE, Washington, USA, 29-34.
[22] Tomomichi Seki, Hideaki Sato, Toshibumi Seki, Tatsuji
Tanaka, and Hadime. Watanabe. 1997. Decentralized Autono-
mous Object-Oriented EMS/SCADA System. In Proceedings of
the 3rd International Symposium on Autonomous Decentralized
Systems (ISADS '97). IEEE Computer Society, Washington,
DC, USA.
[23] Christophe Feltus, Michaël Petit, and Eric Dubois. 2009.
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, 23-32.
DOI=10.1145/1655168.1655174