Formal Security Framework for Agent Based Cloud ... - IEEE Xplore

2014 International Workshop on Advanced Information Systems for Enterprises

Formal Security Framework For Agent Based Cloud Systems Fatma Masmoudi ReDCAD Laboratory University of Sfax, Tunisia [email protected]

Monia Loulou ReDCAD Laboratory University of Sfax, Tunisia [email protected]

components of a cloud architecture and clarify the definition of each one. On the other hand, as a result of the different interactions and the increasing demands of consumers, providers are facing the challenge of security. They need to secure virtual environments, which enable them to execute and deliver separate services for different customers. Several surveys have attempted to identify the major problems concerning the security on cloud computing. For instance, Cloud Security Alliance (CSA) is a non-profit organization published its research findings on the top threats to cloud computing in March 2010. It opens up new avenues of attack and hence several security issues crop up in case of its adoption [11]. The top cloud security issues according to CSA are:

Abstract—The adoption of cloud computing becomes hampered by the emergence of security problems. We aim in this paper to define a framework which clarifies the concepts of security in a cloud environment and can afterwards check a number of security properties. To achieve this objective, we propose a three-level approach: Modeling, Specification and Verification. In the first step, we propose an agent based modeling of cloud architecture in order to leverage the capabilities of software agents and consequently to reduce complexity. In specification step, we formally specify the concepts evoked in the modeling step and enrich them by others related to security. In the last step, we proceed to verify the security level in cloud environments in order to better control their entities behaviour. Keywords-Cloud computing; security; formal methods; modeling; specification; verification; agent technology

•

I. I NTRODUCTION

• •

Leading to the revolutionary change in the computing services, the cloud computing is a new architecture in which dynamically scalable and often virtualized resources are provided as a service over the Internet. It provides on demand services based on a pay-as-you-go operational model. These services may be in layers ranging from Infrastructureas-a-Service (IaaS) at the base, to Platform-as-a-Service (PaaS), to Software-as-a-Service (SaaS) [1]. Indeed, cloud architectures are characterized by a large complexity and a strong interaction between the different entities (providers, consumers, brokers, etc) that communicate, negotiate and even federate to better satisfy customer needs. In order to master this complexity, it is necessary to use an efficient paradigm that is able to resolve such problem. A number of approaches exist to achieve this purpose using a variety of paradigms such as web services [2], software components [3] and agent systems [4]–[7]. Particularly, software agents can be used as basic components for the implementation of intelligence in the cloud systems and make them more adaptive, flexible, and autonomous. Moreover, research works have used Agent technology to tackle with service composition [4], [5], resource management [6], data migration [7], federation [8] and so on. However, these works have not been based on a standards. These standards such as NIST [9], DMTF [10], CSA and so on informally set the principle 978-1-4799-4299-2/14 $31.00 © 2014 IEEE DOI 10.1109/IWAISE.2014.15

Ahmed Hadj Kacem ReDCAD Laboratory University of Sfax, Tunisia [email protected]

• • • •

Abuse and nefarious use of cloud computing Insecure application programming interfaces Malicious insiders Shared technology vulnerabilities Data loss/leakage Account, service and traffic hijacking Unknown risk profile

Security challenge is the preoccupation of all cloud actors. For instance, consumers require securing their data and services that they are trying to use. And providers need to protect their services and resources from the misbehave of some consumers. In order to ensure security in cloud environments, it is essential to use techniques which offer enough flexibility and expressiveness, and provide a rigorous reasoning about the security of cloud systems. In this context, it is widely recognized that formal methods are useful and play an important role in the development of critical systems. They are among the techniques that ensure the credibility of systems and verify that their descriptions satisfy needs and requirements at an advanced stage. Existing formal security approaches have used formal methods to verify data integrity [12] in data level and Virtual machine migrations [13]– [15] in virtual level. Nonetheless, they are proposed to a specific security requirement and lack of abstraction that allows the satisfaction of any security requirement. Clearly, the approaches presented above have ensured the verification 15

of properties such as integrity, trust and reliability which are security generic properties. However, isolation has long been recognized as a complex class of security challenges in Cloud Systems. It can also be considered as a Cloud specific property. Indeed, we note the absence of formal approaches that aim to verify security properties in the service level. In this paper we propose a security framework for cloud systems. We start with agent based modeling aligning with concepts proposed in NIST reference architecture to obtain a clear view of a cloud system. Secondly, we proceed to specify the concepts evoked in the modeling step and enrich them by others related to security in cloud computing. This step is based on the specification of security policies in order to control the behaviour of cloud system entities and protect them, as far as possible, from attacks that may occur. On this basis, we carry on verifying the security level in a cloud computing environment. The remainder of this paper is organized as follows: Section 2 includes a global description of our proposed approach. Section 3 presents the modeling of cloud architecture based agent, Section 4 presents the formal specification of concepts proposed in the modeling step enriched with security requirements, Section 5 presents the verification of security properties. In section 6 we discuss some related works. The last section contains a short conclusion and tracks for future works.

Provider, Broker, Auditor and Carrier). In the rest of our approach, we are interested in the problem of security. For this, we limit ourselves to three actors: broker, provider and consumer since the security mission is focused especially on these actors. In the second step we rigorously specify the concepts defined in the first one, then we enrich them by other concepts related to security. To do this, we use formal methods to take advantage of their stringency and flexibility. In addition, we adopt a high level of abstraction which eliminates any useless detail to specify security policies in order to avoid attacks. We aim in the last step to check a number of security properties for the appropriate functioning of cloud systems. This consists in defining a number of theorems and proving them in order to measure the degree of security policy. Architecture components and concepts of security are specified rigorously using Z notation [16] and checked using the Z/EVES toolkit which ensures the syntax and type checking, schema expansion and general theorem proving. We choose the Z notation as it allows the specification of complicated and infinite systems states. Also, it covers a rich syntax and data types as propositional logic, predicates, sets, relations, functions and sequences.

II. P ROPOSED APPROACH

Given the complexity of cloud architecture, we focus on the agent paradigm to resolve this problem. We model the cloud system using several types of agents to take advantage of their adaptability, flexibility and autonomy as shown in Fig.2 (right). Agents forming cloud architecture should cooperate and coordinate together to achieve a suitable service delivery. We adopt NIST reference cloud architecture in this step as shown in Fig.2 (left) limiting ourselves to three actors: Consumer, Broker and Provider. • Cloud consumer: we propose to model it with a stationary agent. It acts for the benefit of consumers and interacts with providers and other consumers through brokers. The consumer agent (ConsAg) communicates with other consumers directly or via brokers. To establish this communication, it must have an acquaintance network that contains the list of most contracted agents and theirs capabilities. • Cloud broker: we propose to model it with a stationary agent. It is an intermediary between consumers and suppliers and facilitates the interaction between them and instantly discover services. The broker agent is a mediator that negotiates relationships between providers and consumers that has an acquaintance network of other providers. • Cloud provider: we suppose that this actor is managed by Stationary Service Provider Agent which communicates with several external entities. It sends/receives federation requests through brokers to/from other

III. M ODELING S TEP

In order to define a security framework for cloud systems, we propose a three level approach as shown in Fig.1

Figure 1: Three level Proposed approach In the first step, we adopt the NIST reference architecture and modeling it using agent paradigm. The latter is a suitable technology to reduce complexity, decision making and negotiation in cloud systems. It also ensures the mastering of complexity related to the richness of concepts and the diversity of actors. Indeed, the NIST cloud reference architecture describes five actors of a cloud system (Consumer,

16

Figure 2: Modeling Based Agent of Cloud Architecture

•

providers (to recover interrupted service, improve service quality, etc). According to NIST, the service provider is composed of three layers that communicate with each other: Interface layer for display and interaction with consumers, middle layer that offers both control and execution services, and physical layer for physical equipments. – Service layer is an interface to a resource or a cloud service, we propose to model it with a set of interface agents (IAg). In fact, the interface agent [17] is a simplifier for users to interact with the system. It is responsible for acquiring all user requests, forwarding them to appropriate agents and presenting results to users. The interface agent is an intermediary between the consumer and the execution environments. Indeed, it receives the consumer request, transfers it to the appropriate agent and sends results to consumer. To perform its mission, the interface agent is characterized by a list of services offered by its provider and an acquaintance network of contracted control and consumer agents. Middle layer is responsible for the execution of services, resource allocation, access control, etc. It is formed by one or many SEEs (Service Execution Environments), each one is composed of a control agent and one/many service agents. In each SEE, we propose that control functions are provided by control agents (CAg) and the executions of services is performed through service agents (SceAg). – Control agent (CAg in Fig.2) is a stationary agent that is responsible for performing control services. It receives the request from the consumer through the interface agent. It orchestrates a set of service agents in relation to the request. Indeed, it must

•

have the list of user requests, each one is composed of tasks and each task is assigned to a service agent. – Service agent (SceAg in Fig.2) is responsible of service execution. The latter is a mobile agent that can achieve service execution by communication with other service agents or by displacement from a cloud environment to another (in case of presence of a malicious service in the current environment, lack of resources, etc). Communication between service agents is obvious; hence, such an agent must have a view of the service agents of the current environment. One or more tasks form part of actions of the service agent. Physical layer is the set of physical resources (Resource in Fig.2) that a data center may include (CPU, GPU, servers, etc). IV. S PECIFICATION S TEP

In this section, we formally specify the architecture concepts proposed in the first step. Then, we propose a clear and concise specification of all laws and regulations governing how to manage and protect virtual environments. That is, we associate in our model the specification of numerous security policies for the purpose of ensuring security in cloud systems. A. Specification of system entities This section mentions some of the components of agent based cloud system during the process of specification: Control Agent and Service Agent. 1) Control Agent (ContAg): it is an agent that is responsible for receiving user requests and instantiate service agents which perform services. The schema corresponding to the control agent is follow:

17

ContAg Agent Id ContAg : Propriety Con Access : F1 (ConsAg → F1 Service) Req : F1 Requirement Miss ContAg : F1 (Task ↔ Propriety) resource : F1 CResource see : Propriety

SEE Name : Propriety cont : ContAg sceag : F1 SceMobileAgent Ress Phy : F1 CResource Cons : ConsAg Sces : F1 Requirement ...

∀ t : Task sceag : Propriety req : Requirement | req ∈ Req ∧ t ∈ req.tasks • {(t, sceag)} ∈ Miss ContAg [C1]

∀ sceMAg : SceMobileAgent t : Task sce : Requirement | sceMAg.CLocation SMAg = Name ∧ {(Name, {t})} ∈ sceMAg.Mission ∧ sce ∈ Sces • (sce, {t}) ∈ sceMAg.Actions [C3] For illustration, the execution environment is composed of: a name (Name), control agent (cont), finite set of service agents (sceag), finite set of physical resources (Ress), finite consumer agent (Cons) and finite set of under execution services (Sces). In the predicative part, we verify with [C3] that a service whose duties are performed by a service agent in SEE must belong to the actions of this agent.

This schema includes the characteristics of the agent and the constraints that must be met. Control agent is a stationary agent which inherits its properties from the stationary agent specified in a previous work [18]). It also has his own characteristics that consist of an identifier (Id ContAg), a finite set of most contracted consumer agents as their allowed services (Con Access), a finite set of requests treated (Req), a mission (Miss ContAg) which consists of affecting a task of a request to a service agent and a finite set of physical resources (resource) allocated by the control agent in favor of its SEE (see). In the predicative part, we verify with [C1]: For each request which is the responsibility of the control agent, its tasks are assigned to the appropriate service agents and are part of the mission of that agent.

B. Specification of security policies Defining security policies is a crucial stage for an efficient implementation of the security within distributed systems. In this section, we proceed to describe security requirements considered by the policy rule. We deal in this part with the need for access control and isolation. This description will lead to the generation of the provider side security policy that includes all laws that guarantee access control and isolation and are enforced in a cloud environment. Access control is a fundamental requirement in information systems. In fact, communications between agents should be secured and private data of an agent must be protected. For this, each unwanted access from an agent to another will be denied. On the other hand, separation is the key ingredient of any security mechanism. It is based on the ability to create boundaries between entities that must be protected and those that can not be trusted. Isolation is the responsibility of the VMM (Virtual Machine Manager) but there are gaps and weaknesses. Obviously, isolating a consumer from one another is, or should be, a major concern for cloud providers. No data of a consumer should be subjected to another, or the behaviour of a consumer to be visible to another. Those two security requirements are expressed as predicates in the specification of the security rule. Thus, to express various kinds of security rules, we define two basic constructs for : Authorization (Auth) and Prohibition (Prohb). They are presented formally as:

2) Service Agent (SceAg): it is a mobile agent which reacts alone or with other service agents to accomplish the desired service. The service agent schema is follow: SceMobileAgent ... Actions : Requirement → F1 Task Mission : F(Propriety ↔ F Task) {Id SMAg, CLocation SMAg, HLocation SMAg, TTL SMAg} ⊂ knowledge [C2]

We kept the specification proposed in [18] and modified some attributes. We changed the attributes Actions and Mission to make them special in cloud context. Indeed, Actions (Actions) form the set of tasks specific treated by the current service agent, those tasks are part of a requirement. Also, Mission (Mission) is the set of tasks for each location visited. In the predicative part, we verify with [C2] that Id SMAg, CLocation SMAg, HLocation SMAg and TTL SMAg are among knowledge of the agent. Therefore, the specification schema of SEE is follow:

SConstruct ::= Auth |Prohb A security rule is composed of a Target (object to secure: resource, data or service), an Interested entity (concerned by

18

VIsol : SRule ↔ SceMobileAgent

the definition of the security policy), an Attaquer (entities are considered attackers as the presented cases), Actions that are authorized or prohibited and the Context of the security rule. The SRule schema is defined follow:

disabled rule Def VIsol  ∀ a : SRule agsce, agsce1 : SceMobileAgent • a VIsol agsce ⇔ (if agsce.see = agsce1.see ∧ a.Target = {data agsce.data} ∧ a.Interested = SSce agsce ∧ Sce agsce1 ∈ a.Attaquer ∧ a.Actions = {send receive data} then a.Type = Prohb else a.Type = Auth)

SRule Name : Propriety Type : SConstruct Target : F SObject Interested : SEntity Attaquer : F AEntity Actions : F1 Action Contexte : Condition

disabled rule Def VIsol states that a given rule (a) ensures virtual isolation only if there is no communication between service agents (agsce and agsce1) from two different SEEs while guaranteeing data protection of service agent (agsce) concerned by the rule. 2) Verification of physical Isolation: We defined a binary relation named (PIsol) between a rule and a control agent which, one of its functions, is responsible for allocating and controlling physical resources. Security rule should prohibit any unauthorized allocation of the physical resource specific to the current control agent (inaccessible resource, resource already allocated, etc.). We have attached, in the predicate part of PIsol relation, the label disabled rule Def PIsol :

∀ act : Action cont : ContAg | act = request response ∧ Attaquer = {Cont cont} • ∀ sceag : SceMobileAgent sce : Requirement t : Task | (sce, {t}) ∈ sceag.Actions • Target = {service sce} ∧ Interested = SSce sceag [C4] ...

In the predicative part, we verify that [C4] allows/prohibits the access control (Request’s Task sending from Control Agent to a Service Mobile Agent) between a control agent and a service agent. The service agent does not receive a task of the query only from the control agent of the same SEE. Accordingly, the specification of a Security policy is follow. It is formed of a set of security rules.

syntax PIsol inrel PIsol PIsol : SRule ↔ ContAg

disabled rule Def PIsol  ∀ b : SRule agcont, agcont1 : ContAg • b PIsol agcont ⇔ (if agcont.resource = agcont1.resource ∧ b.Target = {resource agcont.resource} ∧ b.Interested = SRes agcont.resource ∧ Cont agcont1 ∈ b.Attaquer ∧ b.Actions = {allocate ress} then b.Type = Prohb else b.Type = Auth)

SPolicy Subject : SEntity Rules : F SRule

V. V ERIFICATION S TEP To measure the security degree of an SEE, we propose in this section a verification of security properties on a cloud environment (SEE). In the following, we treat the proof of an SEE isolation. In fact, two types of isolation in cloud context are treated in our work:

This predicate states that a given rule (b) prohibits (Prohb) any illegal allocation of physical resources to control attacker agent (agcont1). We are talking about illegal allocation: any attempt of reserving a resource (agcont.resource) already allocated by a control agent (agcont) and is not part of the resources allowed for the attacker (agcont1). This rule ensures the physical resources protection of the control agent concerned by the rule (agcont). 3) Verification of global Isolation: As a conclusion, according to what has been specified, isolation is based on a security policy composed of non-contradictory rules and at least, one rule that ensures the isolation of virtual services and another for physical resource isolation. The global isolation is a binary relationship between a security

1) Verification of virtual Isolation: We defined a binary relation named (VIsol) between a rule and a service agent. Security rule must prohibit any unauthorized communication from a Service Agent (agsce) to another (agsce1) when they are not from the same Cloud environment (agsce.see). We have attached, in the predicate part of VIsol relation, the label disabled rule Def VIsol . This enables us to give an associated theorem that will be used in proof commands of global isolation. syntax VIsol inrel VIsol

19

policy and user execution environment (SEE). On that basis, we propose a definition of SEE isolation given by disabled rule Def Isolation

agent paradigm to resolve problems in cloud systems. In [4], Garcia and Sim have proposed a based agent model for service composition in the cloud computing. Each component in the cloud has been represented by an agent: consumer, provider, broker, resource. Those agents and their behaviour have been specified using Petri nets. In [5], authors have added the concept of acquaintance network for each agent called: ”Self-organizing”. Acquaintance networks are lists of existing or recently contracted agents as well as their skills. Moreover, service dynamic selection is based on Contract Net Protocol. The use of the agent paradigm has been proposed also for the autonomous management of cloud resources. In [6], Garcia and Sim proposed an estimation method based on genetic algorithm where broker agents predict the sub-optimal set of resources to run applications ”Bag of tasks” on the cloud. Agents have also been used for data migration [7], federation [8] and so on.Agents integration and their capabilities into cloud were certainly beneficial, but we notice the lack of standards adoption in these works.

syntax Isolation inrel Isolation Isolation : SPolicy ↔ SEE

disabled rule Def Isolation  ∀ p : SPolicy See : SEE r1, r2 : SRule agcont : ContAg agsce : SceMobileAgent | r1 ∈ p.Rules ∧ r2 ∈ p.Rules ∧ r1 = r2 ∧ agcont.see = See.Name ∧ agsce.see = See.Name • p Isolation See ⇔ r1 VIsol agsce ∧ r2 PIsolv agcont ∧ r1 NotContradictory r2 To illustrate our verification framework, we take the example of a policy P, consisting of three security rules R1, R2 and R3. P has at least one rule R1 that ensures virtual isolation and another R2 that ensures physical isolation of the execution environment SEE Alice of a consumer Alice. R1 is responsible for protecting the service agent data of SEE Alice from any communication from another SEE (SEE Bob in our example). R2 is responsible for protecting the physical resources managed by control agent of SEE Alice from any unauthorized allocation (see [19]). To prove that the policy named P satisfies the isolation of SEE Alice, we must prove the following theorem:

Concerning formal methods and their adoption in cloud computing, we note in [12], Shi et al. have focused on data integrity concept for SaaS data storage security which includes durable integrity, correct integrity and provenance integrity. Relying on the meta-data driven data storage model and data chunking technology, SaaS data integrity verification can be realized based on the integrity verification of data chunks. Also, many schemes are proposed under different systems and security models in order to perform security verifications [13] [14] and migrations [15] of Virtual Machines. Formal methods have been also employed in [20] where Zic and Liu proposed a specification language to model the internal organization of the cloud, named Cloud. It enables the cloud users to understand more on how services are delivered inside cloud. Therefore, service users have more confidence to move their business-critical applications to cloud. Cloud sharp has a formal syntax that addresses only specification phase.

theorem verif Isolation P Isolation See Alice Fig.3 shows traces of theorem proof Isolation. After running the proof command list we have obtained the predicate “true”. Thus, the theorem verif Isolation is proved and therefore P ensures isolation of SEE Alice.

Throughout these related works outlined above, we note that they deal with the verification of security generic properties (integrity, access control, etc). We have presented in this paper a framework that can deal, in a high level of abstraction, with a variety of security properties. Isolation property is a case study and a specific security property to the cloud. Moreover, security is not only the mission of the provider as mentioned in the related work, but also other actors such as consumer, broker and so on. We showed in this paper different relationships between actors, their components and their role in ensuring security in cloud environments. In comparison to works already presented, we proposed in this paper abstract concepts that are suitable for any kind of service (SaaS, PaaS or IaaS) unlike the associated works that are designed to a specific level.

Figure 3: Isolation proof window

VI. R ELATED WORK We proposed in this paper, a formal framework for the specification and verification of security in agent based cloud systems. There are some works that have benefited from the

20

VII. C ONCLUSION In this paper, we are interested in treating security in cloud systems. To achieve this goal, we have defined a three level approach for Modeling, Specification and Verification. Firstly, we focused on the agent approach to model cloud architecture as they are autonomous entities. They have proven their effectiveness in many areas, especially in large scale distributed systems. This step reduces the complexity of cloud system and clarifies the interactions between the various actors. Then, we took advantage of formal methods to specify and rigorously describe entities, their relations and all laws and regulations that govern and manage virtual environments of cloud providers. Finally, we have proposed a formal verification of agent based cloud systems to measure the security degree in a cloud system. It treated the property of isolation where security rules must guarantee virtual and physical isolation of an SEE. We used the proof tool Z/EVES to check whether the specified system respects isolation. Future works include the definition of an operational framework on top of the proposed approach. This means the generation of security code from a security policy that satisfies isolation property. We can also cover other security properties verification such as: data recovery, data duplication and so on.

[9] B. R. B., M. John, L. Fang, T. Jin, and M. Jian, “NIST cloud computing reference architecture,” in Proc. IEEE World Congress on Services, 2011, pp. 594–596. [10] Interoperable Clouds: A White Paper from the Open Cloud Standards Incubator, Dsp-iso101 ed., DMTF, Sep 2011. [11] H. Dan and S. Michael, “Top threats to cloud computing,” Cloud Security Alliance, Mar 2010. [12] S. Yuliang, Z. Kun, and L. Qingzhong, “A new data integrity verification mechanism for saas,” in Proc. International Conference on Web Information Systems and Mining, 2010, pp. 236–243. [13] Y. Jarraya, A. Eghtesadi, M. Debbabi, Y. Zhang, and M. Pourzandi, “Formal verification of security preservation for migrating virtual machines in the cloud,” in Proc. Stabilization, Safety, and Security of Distributed Systems, 2012, pp. 111–125. [14] Q. Y. R. J. W. P. D. Yue-hua, Sh. Yi, “Design and verification of a lightweight reliable virtual machine monitor for a manycore architecture,” Frontiers of Computer Science, vol. 7, pp. 34–43, 2013.

R EFERENCES

[15] S. Kikuchi and Y. Matsumoto, “Performance modeling of concurrent live migration operations in cloud computing systems using prism probabilistic model checker,” in Proc. IEEE International Conference on Cloud Computing (CLOUD), 2011, pp. 49–56.

[1] P. Mell and T. Grance, “The NIST definition of cloud computing,” National Institute of Standards and Technology, Tech. Rep., Jul 2009. [Online]. Available: http://www.csrc.nist.gov/groups/SNS/cloud-computing/

[16] J. Woodcock and J. Davies., Using Z: Specification, Refinement and Proof. International Thomson Computer Press, 1996.

[2] C. Zeng, X. Guo, W. Ou, and D. Han, “Cloud computing service composition and search based on semantic,” in Cloud Computing. Springer Berlin Heidelberg, 2009, pp. 290–300.

[17] N. B. Seghir and K. Okba, “Une architecture bas´ee agents mobiles pour la recherche d’information dans des sources h´et´erog`enes et r´eparties,” in Proc. 2nd Conf´erence Internationale sur l’Informatique et ses Applications, vol. 547, 2009.

[3] C.-E. Yen, J.-S. Yang, P. Liu, and J.-J. Wu, “Roystonea: A cloud computing system with pluggable component architecture,” in IEEE 17th International Conference on Parallel and Distributed Systems (ICPADS), 2011, pp. 80–87.

[18] M. Loulou, A. Hadj-Kacem, and M. Jmaiel, “Formalization of cooperation in mas: Towards a generic conceptual model,” in Proc. 9th Ibero-American Conference on AI, 2004, pp. 43– 52.

[4] J. O. G. Garcia and K. M. Sim, “Agent-based service composition in cloud computing,” Grid and Distributed Computing, Control and Automation, vol. 121, pp. 1–10, 2010.

[19] Z specification. https://drive.google.com/file/d/0BsKGOkMIAo9QVZleXFJQlpkRzQ/edit?usp=sharing.

[5] ——, “Self-organizing agents for service composition in cloud computing,” 2nd IEEE International Conference on Cloud Computing Technology and Science, pp. 59–66, 2010.

[20] D. Liu and J. Zic, “Cloud sharp: A specification language for modeling cloud,” in Proc. IEEE International Conference on Cloud Computing (CLOUD),, 2011, pp. 533–540.

[6] ——, “Ga-based cloud resource estimation for agent-based execution of bag-of-tasks applications,” Information Systems Frontiers, vol. 14, pp. 925–951, Sep 2011. [7] R. Aversa, B. D. Martino, M. Rak, and S. Venticinque, “Cloud agency: A mobile agent based cloud system,” in Proc. International Conference on Complex, Intelligent and Software Intensive Systems (CISIS), 2010, pp. 132–137. [8] Z. Zhang and X. Zhang, “Realization of open cloud computing federation based on mobile agent,” Intelligent Computing and Intelligent Systems, pp. 642–646, 2009.

21