Organizational Security Architecture for Critical Infrastructure

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
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 representing 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 management and the technology that supports it, a knowledge
of the impact of actions from one layer to another, a decision 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 corporate 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 improvements 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 structured in layers that correspond to different levels of the
organizations IS. The business layer, for instance, models 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 connections between the concepts from each layer and, thereby,
allow a better integration and an enhanced support of
decision making processes. Up to now, crisis management has never been represented through the middle of
enterprise architecture. This representation could provide
many advantages, such as a better integration of the crisis management functions, from their definition up to
their deployment. Notwithstanding the many advantages

Abstract
The governance of critical infrastructures requires a
fail-safe dedicated security management organization.
This organization must provide the structure and mechanisms 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 focuses 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. Notwithstanding 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 agents 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 acquisition at RTU level, alert correlation, policy instantiation and deployment [20], each of the latter being operationalized with different technologies, protocols or
methods. These reaction tools are in practice operationalized at different layers of the management of the infrastructure 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
1

of this representation, we are confronted with the management of heterogeneous and distributed architecture
which calls for a rethinking of the distribution of the security 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 situation, we are forced to admit that software agents are no
longer to be considered only as basic software components 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 allow 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 enterprise Architecture framework, and to redraw its structure in order to fit in with agent software actors specificities. The main focus concerns the design and the consideration 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 enterprise 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 illustrates the different components. In Section 5 we present a
case study which illustrates the exploitation of the enhanced ArchiMate for Multi-agent System. Finally,
Section 6 concludes the paper.

generate codes, but does not provide links between diagrams and therefore makes it difficult to use for alignment 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. CARBA[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 system, 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
Group 1 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 languages 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 multi-agent system including the notions of Agents Policy.
As explained in Section 2, we have selected the ArchiMate language to gives multiple layered view of a multi-agent system using policies.

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 (requirements, 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 generate organizational diagrams, roles diagrams, classes
diagrams, sequences diagrams and so forth. It permits to

Figure 1 : Responsibility Driven Policy(RDP)

In order to create this Metamodel, we realized a specialization of the original ArchiMate Metamodel for
1

http://www.opengroup.org/archimate/

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 concept (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 accordance with our specialization of the ArchiMate
Metamodel. The proposed representation is composed of
three concepts defining the Policy (Figure 2):
Event

Context

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 services to external customers, which are realized 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 offers Infrastructure Services 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.

Responsibilities

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 behaviours 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 Responsibility driven Policy as an execution of a set of Responsibilities 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 Organizational Layer. The organizational view corresponds
more to our vision of an agent and allows the consideration 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 replaced 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 ArchiMate there is a semantic difference between the application and the user who exploits the application, in our
model and in the agent world, there is an exact correspondence 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

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 Process domain occurred in a specific context, symbolized by a configuration of the Information
domain.
And we defined the Application Policy as:
The set of rules that defines the application Responsibilities 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 Metamodel. The next paragraphs delineate the concept from ArchiMate illustrating each layer of the metamodel while
considering in parallel the concept of Policy.

4.1. Organizational Layer

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.

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. Organizational Policies are behavioural components of the
organization whose goals are to achieve an Organizational Service to a role depending on 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 Organizational Objects define units
of information that relate to an aspect of the organization.

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 (Figure 4) we see that Artefact of the Technical Layer realizes 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.

4.2. Application Layer

The Application layer 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 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 (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 Application Collaboration and can be used to symbolize the cooperation (temporary) between components for the realization of behaviour. Application Policy represents the
behaviour that is carried out by the components.

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 Policy can be represented as an UML Use Case [14] 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 as the Event concept (Precondition) and the Organizational Object (Pre/Post
condition).

4.3. Technical Layer

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 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
4

previous work [8], a MAS architecture was proposed in

order to support risk assessment for real time decision-making processes. The clearing mechanism associated 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 (customer/issuer, acquiring/issuing processing, see Figure 8 and
Figure 9) and they retrieve information from probes located at the network layer and representing different
values: network traffic, DoS attack (denial-of-service
attack, an attempt to make a computer resource unavailable to its intended users), suspicious connection attempts, 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 decisions. This set of agents is composed of:
The ACE Agents 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 Engine (PIE).
The PIE Agents 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 messages which have to be deployed. Finally, the high level
alert messages are transferred to the Reaction Deployment Point (RDP).
The RDP Agents 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 received 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 second module, the Component Configuration Mapper, selects the appropriate communication channel. In this
Section, we instantiated the metamodel related to an
ACE Agent as is it defined in previous work [8].

4.5.2. Application Policy

The Application Policy from the Application
Layer is defined in Section 3 as the realisation of Responsibilities by the Application domain in a configuration 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 Sequence 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 according to the banks interface whenever an alert occurs. This
mechanism is judged extremely critical for financial institutions since the corruption of card payment mechanisms may paralyze an entire State if fraud happens. In

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.

Figure 8 : Acquiring/Issuing process and association with the agents reaction architecture

We called a transaction a communication of information 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.

For the Application layer of the ACE Agent (Figure 10)

we distinguished between the transaction and the monitoring. Application Services for transactions and monitoring 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 Administration and show that this collaboration is constituted of the
Components of the ACE and the Components of the Device. Devices components use the Application Monitoring Interface to communicate with the ACEs components, and the ACEs components are composed of the
Application Monitoring Interface. We used the same
approach for the transaction part and rapidly pointed out
that the ACEs components are composed of two interfaces that serve the two Application Services. Again the
Application layer contains Data Object as Transaction
Messages, and Monitoring Messages used by the different Application Components of the layer.

Figure 9 : Detailed agents architecture

Firstly, the Organizational Role of the ACE was represented as a Collaboration of the PIE Role and the Device Role. Each Role of the Collaboration communicates
with the ACE through a proper Organizational Interface,
one for the monitoring and another one for the transaction. 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 applied to the Organizational Object for monitoring information and transaction information.

5.2. ACE Application layer

5.3. ACE Technical layer

We found in the Technical layer of the ACE Agent
(Figure 10) another representation of the two collaborators. Transaction and Monitoring Infrastructure are separated from each other. Both of them have Infrastructure
Service connected to the ACE agents Node and an Infrastructure Interface where the collaborators can interact with it. Each Node is respectively connected to a
Communication Path (represented by a logical Event
Queuing) and uses different Artefacts for communication. 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 operating system. Also, the Network concept is not defined in
our instantiation for the same reason. For example, Monitoring Event Queue between the ACE agent and the Device can be represented as a Network concept, by an
USB, and for the Transaction Event Queue, by an RJ45.

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 execution of its behaviour.

Figure 12 : Perform Detection High level Sequence Diagram

6. Conclusions
Figure 10 : ACE agent model

Aligning crisis management business processes with the

supportive application and technical layers is a crucial
governing activity. Despite the arising need for an integrated alignment between enterprise layers, to date,
SCADA are supported by increasingly used multi-agent
which are particularly appropriate in the context of critical architecture. Indeed, MAS technology allows enhancing 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 modelling these MAS. Therefore, our work focused on adapting ArchiMate for a MAS usage. This ArchiMate adaptation allowed the structuring of the policy concept
and, thereby, allowed synchronizi the behaviour between
many types of agents, spread over different types of critical architecture management components such as the
alert correlation engine, the intrusion detection tools, and
so forth. In order to illustrate the possibility of modelling

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 Perform 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 responsibilities performed by the Application Domain of the
ACE Agent for the Application Policy: Perform Detection (Figure 12).
7

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

IEEE/WIC/ACM International Conferences on Web Intelligence 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 Michal Petit. 2012. 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, 12-19. DOI=10.1145/2388576.2388577
[11] Gustaf Neumann and Mark Strembeck. 2002. A scenario-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 Systems, 1999. TOOLS 31. pp.253-260, 1999
[16] Cedric Bonhomme, Christophe Feltus, and Michal Petit.
2011. Dynamic Responsibilities Assignment in Critical Electronic Institutions - A Context-Aware Solution for in Crisis
Access Right Management. In Proceedings of the 2011 Sixth
International Conference on Availability, Reliability and Security (ARES '11). IEEE Computer Society, Washington, DC,
USA, 248-253. DOI=10.1109/ARES.2011.43
[17] Christophe Feltus and Michal Petit, Building a Responsibility Model Including Accountability, Capability and Commitment, Fourth International Conference on Availability, Reliability and Security (ARES 2009 The International Dependability 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 System. ECSIS Symposium on Bio-inspired, Learning, and Intelligent Systems for Security, IEEE, Washington, USA, 29-34.
[22] Tomomichi Seki, Hideaki Sato, Toshibumi Seki, Tatsuji
Tanaka, and Hadime. Watanabe. 1997. Decentralized Autonomous 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, Michal 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

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 infrastructures 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. Metamodels 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. Henderson-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, Cdric Bonhomme,
Pierre Schmitt, Benjamin Gteau, Djamel. Khadraoui, Zahia.
Guessoum, Financial Critical Infrastructure: A MAS Trusted
Architecture for Alert Detection and Authenticated Transactions, 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 Assignement for Critical Infrastructure. In Proceedings of the 2011