You are on page 1of 8

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

Abstract their ability of being autonomous, open to all types of


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

1
of this representation, we are confronted with the man- generate codes, but does not provide links between dia-
agement of heterogeneous and distributed architecture grams and therefore makes it difficult to use for align-
which calls for a rethinking of the distribution of the se- ment purposes or with other languages (e.g. MOF [3],
curity procedures between both: human and software Dsml4mas[5]). Globally, we observe that these solutions
autonomous entities [21]. Although having been handled aim at modelling the application layer of MAS. CAR-
by human employees for a long time, the organisational BA[15] provides a dynamic architecture for MAS similar
policies of complex systems, nowadays, need to be to the middleware CORBA, which is based on the role
shared with intelligent software items, often perceived as played by the agent. This approach introduces a concept
being more adapted for action in critical situations. These of Interface and Service which is similar to the one in
policies are deployed considering the responsibility [23] ArchiMate that we reused in our proposal.
of the agent for autonomous acting in open, distributed We observed that agent systems for critical infrastructure
and heterogeneous environments, whether in connection (CI) are organized in a way close to the enterprises sys-
or not with an upper authority. Acknowledging this situ- tem, our idea is to analyse how an enterprise architecture
ation, we are forced to admit that software agents are no model may be slightly reworked and adapted to MAS.
longer to be considered only as basic software compo- Therefore, we decided to use ArchiMate which has the
nents deployed to support business activities, but that following advantage of being supported by the Open
they are responsible [17], such as the business actors, for Group 1 which has a large community and proposes a
playing some kind of business role, and for performing uniform structure for modelling enterprise architecture.
business tasks accordingly. In view of this, acquiring Another advantage of ArchiMate is its use of a clear
an innovative enterprise architecture framework that al- link to existing modelling languages like UML. With
low to represent the behavioural policies of such agents regard to this, we think that it is relevant to provide a
appears fully justified and required by the practitioners, lean and simple structure compliant with the new version
especially the ones engaged in the management of those of UML to model any MAS. As a conclusion of our state
critical infrastructures. of the art, we acknowledge the many other models or
In this paper, we propose to explore ArchiMate, an en- frameworks which provide solutions for modelling MAS
terprise Architecture framework, and to redraw its struc- whether they are compliant with other modeling lan-
ture in order to fit in with agent software actors specific- guages or not. As far as we know, no existing approach
ities. The main focus concerns the design and the con- provides a multiple layer view or an integrated view of
sideration of responsibility driven policies (RDP) [16] these layers.
which are centric concepts related to the activation of
agents behaviours. The paper is structured as follows, 3. Policy Concept and Metamodel Core
after having sighted the related works concerning enter-
prise architecture models in Section 2, we review and Our goal in modelling the multi-agent system into an
model the concept of policy that represents the engine of architecture Metamodel is to provide system architects
the agent modelling framework in Section 3. Section 4 and developers with the tools for creating their own mul-
explains layer by layer the entire metamodel and illus- ti-agent system including the notions of Agents Policy.
trates the different components. In Section 5 we present a As explained in Section 2, we have selected the Archi-
case study which illustrates the exploitation of the en- Mate language to gives multiple layered view of a mul-
hanced ArchiMate for Multi-agent System. Finally, ti-agent system using policies.
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
Figure 1 : Responsibility Driven Policy(RDP)
no longer existing following the release of UML 2.0 by
the OMG [14] supporting MAS. Prometheus[7] defines a In order to create this Metamodel, we realized a spe-
metamodel of the application layer and allows to gener- cialization of the original ArchiMate Metamodel for
ate organizational diagrams, roles diagrams, classes
diagrams, sequences diagrams and so forth. It permits to 1
http://www.opengroup.org/archimate/
2
agent architecture. Firstly, we redefined the Core of the to consider the role as a set of entities managed by an
metamodel (Figure 1) in order to figure out the concept existing application. Hence, the metamodel ArchiMate
of Policy. The Core represents the handling of Passive for multi-agent system is structured in three layers:
Structures by Active Structures during the realization of 1. The Organizational Layer offers products and ser-
Behaviours. For the Active Structures and the Behaviour vices to external customers, which are realized in the
the Core differentiates external concepts which represent organization by organizational processes performed by
how the architecture is being seen by the external con- Organizational Roles according to Organizational Poli-
cept (as a Service provider attainable by an Interface), cies.
and the internal concept which is composed of Structure 2. The Application Layer supports the organizational
Elements (Roles, Components) and linked to a Policy layer with Application Services which are realized by
Execution concept. Passive Structures contains Object Applications according to Application Policies.
(Data Object, Organizational Object, Artefacts ) that 3. The Technology Layer offers Infrastructure Ser-
represents information of the architecture. vices needed to run applications, realized by computer and
Secondly, the concept of Policy was defined in ac- communication hardware and system software.
cordance with our specialization of the ArchiMate Figure 3 represents the different domains covered by the
Metamodel. The proposed representation is composed of metamodel in relation to these layers.
three concepts defining the Policy (Figure 2):

Event Context 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. Figure 3 : Metamodel structure
Thereby, responsibilities correspond to a set of behav-
iours that have to be performed by Structure Elements. Based on this analysis, we defined the Organizational
This behaviour can use Object from Passive Structure or Policy as:
modify their values.
With these three concepts, we structured the Respon- The set of rules that defines the organizational
sibility driven Policy as an execution of a set of Respon- Responsibilities and governs the execution, by
sibilities in a specific Context and in response to an the Organization domain, of behaviours that
Event. serve the Product domain in response to a Pro-
Compared to the original ArchiMate language model, cess domain occurred in a specific context, sym-
we modified the headline of the Business Layer into Or- bolized by a configuration of the Information
ganizational Layer. The organizational view corresponds domain.
more to our vision of an agent and allows the considera-
tion of multi-agent systems as an organization which is And we defined the Application Policy as:
relevant to policy rules.
Concepts and colours were taken from the original The set of rules that defines the application Re-
ArchiMate Metamodel, except for Organizational sponsibilities and governs the execution, by the
Function and the Application Function which were re- Application domain, of behaviours that serve the
placed by the Organizational Policy concept and the Data domain to achieve the application strategy.
Application Policy concept. Through the Policy concept
we show that each operation done by the agent can be 4. Agent System Metamodel
transferred into a Policy execution. Although in Archi-
Mate there is a semantic difference between the appli- As explained in the previous Section, the metamodel
cation and the user who exploits the application, in our is a specialization of the original ArchiMate Metamod-
model and in the agent world, there is an exact corre- el. The next paragraphs delineate the concept from Ar-
spondence between both. This results in the fact that the chiMate illustrating each layer of the metamodel while
concept of agent is not managed at the organizational considering in parallel the concept of Policy.
layer, thus by human operators, but that the latter tends
3
4.1. Organizational Layer Application layer. A Node is composed of a Device and a
System Software. Devices are physical computational
The Organizational layer highlights the organizational resources, where Artefacts are deployed when the System
processes and their links to the Application layer. At first Software represents a software environment for types of
the Organizational layer is defined by an Organizational components and objects. Communication between the
Role (e.g. Alert Detection Agent). This role, accessible Nodes of the Technology layer is defined logically by the
from the outside through an Organizational Interface, Communication Path and physically by the Network.
performs behaviour on the basis of the organization's
Policy (Organizational Policy) associated with the role. 4.4. Inter-Layer Link
Then, the agent is able to, depending on its role interact
with other roles in order to perform behaviour; this is The complete Metamodel (Figure 6) is the union of the
symbolized by the concept of Role Collaboration. Or- three layers. As shown below, new connections between
ganizational Policies are behavioural components of the the layers have appeared. For the Passive structure (Fig-
organization whose goals are to achieve an Organiza- ure 4) we see that Artefact of the Technical Layer realiz-
tional Service to a role depending on Events. Organiza- es Data Object of the Application Layer which realizes
tional Services are contained in Products accompanied Organizational Object of the Organizational layer.
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- Figure 4 : Passive structure connections
tion. Behaviour element (Figure 5) layers show that the
Application Service uses the Organizational Policy to
4.2. Application Layer determine the services it proposes. In the same way, the
Technical layer bases his Infrastructure Service on the
The Application layer is used to represent the Applica- Application Policy of the Application layer.
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 Figure 5 : Behaviour element connections
program. Components use Data Object which is a mod-
elling concept of objects and object types of UML. In- Concerning the Active Structure connection (Figure 7),
terconnection between components is modelled by the the Role concept determines, along with the Application
Application Interface in order to represent the availabil- Component, the Interface provided in the Application
ity of a component to the outside (implementing a part or layer. Also, the Interface of the Technical layer is based
all of the services defined in the Application Service). on the components of the Application layer.
The concept of Collaboration from the Organizational
layer is present in the Application layer as the Applica- 4.5. Policy modelling
tion Collaboration and can be used to symbolize the co-
operation (temporary) between components for the real- The organizational and the application policies
ization of behaviour. Application Policy represents the may, afterwards, be modelled as follows:
behaviour that is carried out by the components. 4.5.1. Organizational Policy
In the Organizational Layer, Organizational Pol-
4.3. Technical Layer icy can be represented as an UML Use Case [14] where
concepts of Roles represent the Actors which have re-
Technical layer is used to represent the structural as-
sponsibilities in the Use Case, and the Collaboration
pect of the system and highlights the links between the
concepts show the connections between them. Con-
Technical layer and the Application layer and how phys-
cepts of Products, Value and Organizational Service
ical pieces of information called Artifacts are produced
provide the Goal of the Use Case. Pre and Post condi-
or used. The main concept of the Technical layer is the
tions model the context of the Use Case and are sym-
Node which represents a computational resource on bolized in the Metamodel as the Event concept (Pre-
which Artefacts can be deployed and executed. The Node condition) and the Organizational Object (Pre/Post
can be accessed by other Node or by components of the condition).

4
previous work [8], a MAS architecture was proposed in
4.5.2. Application Policy order to support risk assessment for real time deci-
The Application Policy from the Application sion-making processes. The clearing mechanism associ-
Layer is defined in Section 3 as the realisation of Re- ated to this architecture denotes all activities from the
sponsibilities by the Application domain in a configura- time is a transaction is made until it is settled. This
tion of the Data domain. UML provides support for Section introduces the core components of the reaction
modelling the behaviour performed by the Application mechanism. Agents are disseminated on three layers
domain as Sequence Diagram. Configuration of the Data corresponding to the clearing mechanism (custom-
domain can be expressed as Preconditions of the Se- er/issuer, acquiring/issuing processing, see Figure 8 and
quence Diagram and symbolized by the execution of a Figure 9) and they retrieve information from probes lo-
test-method on the lifeline of the diagram. 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 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 En-
gine (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 messag-
es which have to be deployed. Finally, the high level
alert messages are transferred to the Reaction Deploy-
ment 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
Figure 6 : ArchiMate metamodel for MAS
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-
Figure 7 : Active structure connections
lects the appropriate communication channel. In this
Section, we instantiated the metamodel related to an
5. Case study in Financial CI ACE Agent as is it defined in previous work [8].
The case study concerns the reaction mechanism (Fig.
5.1. ACE Organizational layer
8) that aims at adapting the ciphering of the data accord-
ing to the banks interface whenever an alert occurs. This In the Organizational layer of the ACE Agent (Figure 10)
mechanism is judged extremely critical for financial in- we represented the monitoring aspect separately from the
stitutions since the corruption of card payment mecha- transaction aspect.
nisms may paralyze an entire State if fraud happens. In

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

We called a transaction a communication of infor- For the Application layer of the ACE Agent (Figure 10)
mation from one agent to another (e.g. ACE sends alert we distinguished between the transaction and the moni-
to PIE), and then we considered the monitoring as the toring. Application Services for transactions and moni-
representation of information from an external device. 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. Devices components use the Application Monitor-
ing Interface to communicate with the ACEs compo-
nents, 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 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.
Figure 9 : Detailed agents architecture

Firstly, the Organizational Role of the ACE was rep- 5.3. ACE Technical layer
resented as a Collaboration of the PIE Role and the De-
vice Role. Each Role of the Collaboration communicates We found in the Technical layer of the ACE Agent
with the ACE through a proper Organizational Interface, (Figure 10) another representation of the two collabora-
one for the monitoring and another one for the transac- tors. Transaction and Monitoring Infrastructure are sep-
tion. ACE Role provides two Organizational Services arated from each other. Both of them have Infrastructure
depending on only one Organizational Policy which is Service connected to the ACE agents Node and an In-
dealing with two Events respectively for the monitoring frastructure Interface where the collaborators can inter-
and the transaction. Secondly, the two Organizational act with it. Each Node is respectively connected to a
Services provided by the ACE agent were regrouped into Communication Path (represented by a logical Event
a correlation service symbolized by the Product concept. Queuing) and uses different Artefacts for communica-
This Product has the objective Value to reduce a crisis tion. We have intentionally not instantiated Nodes for
by giving a guarantee of short reaction time represented readability, but it can easily be understand that an ACE
by the Contract concept. Finally the Contract was ap- agent can be deployed on a computer who runs an oper-
plied to the Organizational Object for monitoring infor- ating system. Also, the Network concept is not defined in
mation and transaction information. our instantiation for the same reason. For example, Mon-
itoring Event Queue between the ACE agent and the De-
5.2. ACE Application layer vice 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 exe-
cution 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
5.4. ACE Organizational Policy governing activity. Despite the arising need for an inte-
grated alignment between enterprise layers, to date,
To illustrate the Organizational Policies of the ACE we SCADA are supported by increasingly used multi-agent
chose to represent the monitoring part of the ACE Role which are particularly appropriate in the context of criti-
as an UML Use Case (Figure 11). Monitoring Events are cal architecture. Indeed, MAS technology allows en-
illustrated in the Use Case as Extension Points and show hancing the connections between heterogeneous, open
their impacts on the responsibilities realized in the Per- and distributed components which are distributed around
form Monitoring Policy. Roles are presented as Actors, the globe in infrastructure networks. In the state of the
and Collaborations are highlighted by the different links art, we observed a lack of global architecture for model-
between the behaviours. ling these MAS. Therefore, our work focused on adapt-
ing ArchiMate for a MAS usage. This ArchiMate ad-
5.5. ACE Application Policy aptation allowed the structuring of the policy concept
and, thereby, allowed synchronizi the behaviour between
Sequences Diagrams were used to represent the respon- many types of agents, spread over different types of crit-
sibilities performed by the Application Domain of the ical architecture management components such as the
alert correlation engine, the intrusion detection tools, and
ACE Agent for the Application Policy: Perform Detec-
so forth. In order to illustrate the possibility of modelling
tion (Figure 12).
7
one of these architectures with this enhanced ArchiMate IEEE/WIC/ACM International Conferences on Web Intelli-
for MAS, we modelled a critical architecture for the gence and Intelligent Agent Technology - Volume 02 (WI-IAT
management of financial infrastructures dedicated to '11), Vol. 2. IEEE Computer Society, Washington, DC, USA,
credit card management. The modelling brought forth a 272-275. DOI=10.1109/WI-IAT.2011.194
[10] Christophe Feltus, Eric Dubois, Erik Proper, Iver Band,
clarification of the connection between the synchroniza- and Michal Petit. 2012. Enhancing the ArchiMate standard
tion of the event that is generated at the level of one with a responsibility modeling language for access rights man-
component policy and the one that triggers policies to agement. In Proceedings of the Fifth International Conference
another component. Associations between modelling on Security of Information and Networks (SIN '12). ACM, New
policies and UML language were also illustrated by the York, NY, USA, 12-19. DOI=10.1145/2388576.2388577
representation of the Organizational Policy as Use Case [11] Gustaf Neumann and Mark Strembeck. 2002. A scenar-
and the representation of Application Policy as Sequence io-driven role engineering process for functional RBAC roles. In
Diagram. 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.
7. Acknowledgements [12] Lankhorst. ArchiMate language primer, 2004.
The research described in this paper is funded by the [13] Zachman, John A. 2003. The Zachman Framework For
Enterprise Architecture : Primer for Enterprise Engineering and
CockpitCI research project within the 7th framework Manufacturing By. Engineering, no. July: 1-11.
Programme (FP7) of the European Union (EU) (topic [14] UML 2 ( http://www.uml.org/)
SEC-2011.2.5-1 Cyber-attacks against critical infra- [15] W. Jiao, Z. Shi, A dynamic architecture for multi-agent
structures Capability Project). systems, Technology of Object-Oriented Languages and Sys-
tems, 1999. TOOLS 31. pp.253-260, 1999
[16] Cedric Bonhomme, Christophe Feltus, and Michal Petit.
REFERENCES 2011. Dynamic Responsibilities Assignment in Critical Elec-
tronic Institutions - A Context-Aware Solution for in Crisis
[1] Franco Zambonelli, Nicholas R. Jennings, and Michael
Access Right Management. In Proceedings of the 2011 Sixth
Wooldridge. 2003. Developing multiagent systems: The Gaia
International Conference on Availability, Reliability and Secu-
methodology. ACM Trans. Softw. Eng. Methodol. 12, 3 (July
rity (ARES '11). IEEE Computer Society, Washington, DC,
2003), 317-370. DOI=10.1145/958961.958963
USA, 248-253. DOI=10.1109/ARES.2011.43
[2] Viviane Torres da Silva, Ricardo Choren, and Carlos J. P.
[17] Christophe Feltus and Michal Petit, Building a Respon-
de Lucena. 2004. A UML Based Approach for Modeling and
sibility Model Including Accountability, Capability and Com-
Implementing Multi-Agent Systems. In Proceedings of the
mitment, Fourth International Conference on Availability, Re-
Third International Joint Conference on Autonomous Agents
liability and Security (ARES 2009 The International De-
and Multiagent Systems - Volume 2 (AAMAS '04), Vol. 2.
pendability Conference), DOI=10.1109/ARES.2009.45
IEEE Computer Society, Washington, DC, USA, 914-921.
[18] John D. Fernandez and Andres E. Fernandez. 2005.
DOI=10.1109/AAMAS.2004.36.
SCADA systems: vulnerabilities and remediation. J. Comput.
[3] J. J. Gomez-Sanz, J. Pavon, and F. Garijo. 2002. Meta-
Sci. Coll. 20, 4 (April 2005), 160-168.
models for building multi-agent systems. In Proceedings of the
[19] B. Miller and D. Rowe. 2012. A survey SCADA of and
2002 ACM symposium on Applied computing (SAC '02). ACM,
critical infrastructure incidents. In Proceedings of the 1st Annual
New York, NY, USA, 37-41.
conference on Research in information technology (RIIT '12).
[4] G. Beydoun, C. Gonzalez-Perez, G. Low, B. Hender-
ACM, New York, NY, USA, 51-56.
son-Sellers. 2005. Synthesis of a generic MAS metamodel.
[20] J. Lloyd Hieb. 2008. Security Hardened Remote Terminal
SIGSOFT Softw. Eng. Notes 30, 4 (May 2005), 1-5.
Units for Scada Networks. Ph.D. Dissertation. University of
[5] C. Hahn. 2008. A domain specific modeling language for
Louisville, Louisville, USA. AAI3308346.
multiagent systems. In Proceedings of the 7th international joint
[21] H.-M. Kim, D.-J. Kang, and T.-H. Kim. 2007. Flexible
conference on Autonomous agents and multiagent systems
Key Distribution for SCADA Network using Multi-Agent Sys-
Vol. 1 International Foundation for Autonomous Agents and
tem. ECSIS Symposium on Bio-inspired, Learning, and Intel-
Multiagent Systems, Richland, SC, 233-240.
ligent Systems for Security, IEEE, Washington, USA, 29-34.
[6] AUML (Agent UML), http://www.auml.org/
[22] Tomomichi Seki, Hideaki Sato, Toshibumi Seki, Tatsuji
[7] Prometheus Methodology. http://www.cs.rmit.edu.au/
Tanaka, and Hadime. Watanabe. 1997. Decentralized Autono-
agents/SAC2/methodology.html
mous Object-Oriented EMS/SCADA System. In Proceedings of
[8] Guy Guemkam, Christophe Feltus, Cdric Bonhomme,
the 3rd International Symposium on Autonomous Decentralized
Pierre Schmitt, Benjamin Gteau, Djamel. Khadraoui, Zahia.
Systems (ISADS '97). IEEE Computer Society, Washington,
Guessoum, Financial Critical Infrastructure: A MAS Trusted
DC, USA.
Architecture for Alert Detection and Authenticated Transac-
[23] Christophe Feltus, Michal Petit, and Eric Dubois. 2009.
tions, Sixth IEEE Conference on Network Architecture and
Strengthening employee's responsibility to enhance governance
Information System Security, La Rochelle, France
of IT: COBIT RACI chart case study. In Proceedings of the first
[9] Guy Guemkam, Christophe Feltus, Pierre Schmitt, Cedric
ACM workshop on Information security governance (WISG
Bonhomme, Djamel Khadraoui, and Zahia Guessoum. 2011.
'09). ACM, New York, NY, USA, 23-32.
Reputation Based Dynamic Responsibility to Agent As-
DOI=10.1145/1655168.1655174
signement for Critical Infrastructure. In Proceedings of the 2011

You might also like