SECURITY AND COMMUNICATION NETWORKSSecurity Comm. Networks (2016)

Published online in Wiley Online Library (wileyonlinelibrary.com). DOI: 10.1002/sec.1405

RESEARCH ARTICLE

Mitigating insider threat in cloud relational databasesQussai Yaseen1 *, Qutaibah Althebyan2, Brajendra Panda3 and Yaser Jararweh4

1 Computer Information Systems Department, Jordan University of Science and Technology, Irbid, Jordan2 Software Engineering Department, Jordan University of Science and Technology, Irbid, Jordan4 Computer Science Department, Jordan University of Science and Technology, Irbid, Jordan3 Department of Computer Science and Computer Engineering, University of Arkansas, Fayetteville, AR 72701 U.S.A.

ABSTRACT

Cloud security has become one of the emergent issues because of the immense growth of cloud services. A majorconcern in cloud security is the insider threat because of the harm that it poses. Therefore, defending cloud systemsagainst insider attacks has become a key demand. This work deals with insider threat in cloud relational database systems.It reveals the flaws in cloud computing that insiders may use to launch attacks and discusses how load balancing acrossavailability zones may increase insider threat. To mitigate this kind of threat, the paper proposes four models, whichare peer-to-peer model, centralized model, Mobile-Knowledgebases model, and Guided Mobile-Knowledgebases model,and it discusses their advantages as well as their limitations. Moreover, the paper provides experiments and analysis thatcompare among the proposed models, demonstrate their effectiveness, and show the conditions under which they workwith highest performance. Copyright © 2016 John Wiley & Sons, Ltd.

KEYWORDS

cloud computing; databases; insider threat; security

*Correspondence

Qussai Yaseen, Computer Information Systems Department, Jordan University of Science and Technology, Irbid, Jordan.E-mail: qmyaseen@just.edu.jo

1. INTRODUCTION

Cloud computing refers to the use of the internet to hostcomputer resources and applications instead of keepingthem on local computers. It delivers services (applica-tions) over the internet, and hardware and systems indata centers [1]. Resources on the cloud are fully man-aged by cloud providers and sold (leased) on demand.The management of such resources includes monitoring,provisioning, de-provisioning, workload balancing, andchanging requests [2]. The services provided by the cloudinclude Infrastructure-as-a-Service, Platform-as-a-Service,and Software-as-a-Service (SaaS). Moreover, cloud rela-tional database systems are offered by some providers suchas Amazon [3], which enable insiders to create and userelational databases.

Using virtual machines to run applications is one of themain features of using the cloud, where cloud platformshost many applications (tenants). Adopting multi-tenancyreduces the operating cost by allowing powerful resourcessharing among tenants. Managing virtual machines isrequired in order to achieve effective resources utilization.Load balancing is performed using live migration [4],

where virtual machines are migrated from overloadednodes to idle (or low-loaded) nodes. However, live migra-tion may pose a delay in delivering services because itlimits the availability during the migration process. Devel-oping methodologies for efficient and low cost live migra-tion has obtained a significant attention by researchers. Anumber of methods have been proposed for effective livemigration such as Albatross [4] and Zehpyr [5].

When talking about cloud computing, security raisesup as one major issue and concern. Proving the securityof data in the cloud is critical in gaining users’ trust oncloud providers. Multi-tenancy could be a vulnerabilitysource. For instance, an insider may use shared resources tobreach the security of other insiders’ tasks [6]. Moreover,the guarantee of protecting data stored in the cloud fromthe threat of cloud providers’ insiders is a main require-ment by customers. Encryption is considered as one ofthe means that are proposed to protect data. Namely, theencryption methods CryptDB, Homomorphic Encryption,and Encryption Deterministic can execute the operations ofrelational databases queries on encrypted data [7]. Thesemethods prevent the cloud providers’ employees fromexposing users’ data even when customers’ queries are

Copyright © 2016 John Wiley & Sons, Ltd.

Mitigating insider threat in cloud relational databases Q. Yaseen et al.

executed. Besides protecting data, authentication of usersis another major concern when moving to the cloud. Thus,the development of digital identity management systems iscrucial for cloud computing [8]. The agreements betweencloud customers and cloud providers regarding the securityand offered services are set using service level agreements,which should be maintained by cloud providers.

Insider threat is one of the major problems that worryboth organizations and individuals about cloud computing.Storing data in the cloud maximizes the number of insid-ers, which in turn, may increase insider threats. Moreover,securing data in the cloud against organizations’ insidersmay require new mechanisms different than those usedto protect data stored locally. According to different sur-veys, such as the Computer Security Institute (CSI) survey[9], Forrester Research [10], and the Information Secu-rity Breaches Survey (ISBS) survey [11], insider threatcauses huge harm to individuals and organizations. TheCSI survey [9] stated that the cost of data records lostto insider attacks is greater than those lost to outsiders.This is because that insiders are familiar with the sys-tem and attack the valuable records, while outsiders stealwhat they can access. In fact, little research has been per-formed on insider threat. Most of insider threat existingresearch focuses on the system level. Very little researchhas been conducted on insider threat at relational databaseslevel. Knowledgebase is a serious source for insider threat.The knowledgebase (discussed in Section 3) of an insiderrepresents the data items that the insider accessed andread their values. Insiders can combine the data itemsthat they accessed (in their knowledgebases) with otherdata items that they can request to infer sensitive informa-tion. Researchers in [12–16] have discussed this problemand introduced methods to mitigate it. However, clouddatabases have new flaws that may help insiders to bypassexisting security methods and pose threat using theirknowledgebases. One of these possible vulnerabilities isthe migration (live migration) of insiders’ requests acrossavailability zones and data centers because of load balanc-ing. The live migration of insiders’ tasks may move thoserequests from places where insiders’ knowledgebases arestored in new nodes that do not have the knowledgebases.Thus, systems on the new nodes are no longer able to checkknowledgebases to detect and prevent insider threat. Thispaper addresses this problem and suggests different mod-els to mitigate it. To the best of our knowledge, this is apremier work that tackles this problem at cloud relationaldatabase systems (RDBMS). We should mention here thatthis paper is an extended version of the paper published in[17]. The contribution of this paper is as follows.

(1) It demonstrates how knowledgebases-based exist-ing insider threat preventing mechanisms can bebypassed by insiders in cloud RDBMS.

(2) It proposes four models that can be used to miti-gate the threat of knowledgebases in cloud RDBMS.Moreover, it discusses the environment factors thataffect the performance of the models. In addition, itdiscusses how to manage the effect of updating data

items in knowledgebases using the aforementionedproposed models.

(3) The paper used the CloudExp Simulator [18], whichis an extended version of the CloudSim Simulator,to test the proposed models and provides results andanalysis that compare among the proposed models.The experiments show the performance of modelsunder different environments parameters.

The rest of the paper is organized as follows. Thenext section introduces some related work. Section 3 dis-cusses several issues about insiders and the threat that theymight pose to the system. It also gives brief descriptionabout knowledgebases and their threat. Section 4 intro-duces the four proposed models to solve the problem.Other issues related to insider threat in cloud RDBMS arediscussed in Section 5. Section 6 provides the experimentsand discusses the results. Finally, Section 7 concludesthe work.

2. BACKGROUND ANDRELATED WORK

Cloud computing is a promising technology that pro-vides large-scale and on-demand computing infrastructure.The spending of the US government on cloud comput-ing projects will pass $15bn by 2015 [19]. Achieving lowcost live migration is one of the goals of the research oncloud computing. Das et al. [4] introduced Albatross, anend-to-end technique for live migration in shared storagedatabases. Albatross maximizes the availability during amigration process by migrating the cache and the stateof active transactions instead of stopping transactions atsource nodes and restarting them at destinations nodes.Zephyr [5] minimized service interruption and increasedthe availability during live migration by using a synchro-nized dual mode. The proposed dual mode enables both thesource and destination nodes to execute transactions simul-taneously while the migration process is running. Zephyrtransferred the tenant’s (migrated application) metadata tothe destination to start executing new transactions; mean-while, the source node continues executing the transactionsthat were active before starting the migration process.

Assuring cloud security is a key demand to guaranteecustomers’ trust because there are many security concernsarising with cloud computing. Researchers in [6,20] intro-duced a survey about the common security concerns thatthreaten cloud computing. Multi-tenancy is one of theproblems discussed, where the data of many users reside atthe same location. This technique may enable the intrusioninto a user’s data by other users, which can be performedby exploiting applications bugs or injecting masked codeinto the Software-as-a-Service system. Takabi et al. [21]introduced a security framework for cloud computing envi-ronment. They tried to build a comprehensive model thatpreserves cloud security using identity management mod-els, access control models, semantic heterogeneity among

Security Comm. Networks (2016) © 2016 John Wiley & Sons, Ltd.

DOI: 10.1002/sec

Q. Yaseen et al. Mitigating insider threat in cloud relational databases

policies from different clouds, and others. The intru-sion problem in a cloud environment was also discussedby Arshad et al. [22] who proposed a methodology forintrusion detection based on clustering. Wang et al. [23]investigated the problem of data security in cloud data stor-age. They utilized the homomorphic token with distributedverification of erasure coded data to achieve storage cor-rectness insurance. Hwang et al. [24] addressed outlinesfor an integrated architecture to guarantee security and pri-vacy in cloud applications. Chow et al. [25] suggestedextending control measures in the cloud by using trustedcomputing and applied cryptography.

Research in cloud databases is still in its early stages.Little research has been conducted in this field. Hacigu-mus et al. [26] introduced CloudDB, a data managementplatform in the cloud. CloudDB has several features thatsatisfy cloud environments. It maintains three types of datastores, which are row store, key-value store, and analyt-ics store to satisfy different workload types. For instance,the analytics store is a read-optimized and a throughputoriented to efficiently handle OLAP workloads, while thekey-store is used to achieve higher levels of scalabilityfor read/write intensive workloads. Moreover, CloudDBuses both partitioning and replication techniques to achieveavailability and scalability. Curino et al. [7] introduced anew comprehensive framework for relational database onthe cloud, called Relational Cloud. It supports new mod-els for efficient multi-tenancy to minimize the resourcesneeded for a workload, an elastic scale-out model to satisfygrowing workloads, and models to preserve database pri-vacy. Furthermore, Relational Cloud involves techniquesfor efficient partitioning, replication, and migration toachieve maximum availability and reliability. Unlike othermulti tenant databases, Relational Cloud does not mixthe data of different tenants into a shared database ortable. Instead, databases belonging to different tenantsare run on the same database server. Hence, the cloudrelational database service has been introduced by somecloud providers such as Amazon (Amazon RelationalDatabase Service Amazon RDS [Seattle, WA, USA]) [3]and Microsoft (Microsoft SQL Azure [Redmond, WA,USA]) [27].

Most research that has been performed on insider threatfocused on system level such as the work by Spitzner[28] and Althebyan and Panda [29]. Fuchs and Pernul[30] proposed a comprehensive system of securing identitymanagement in order to minimize insider threat. Their pro-posed approach gathers cross-domain identity information,removes unnecessary accounts, and filters account data andaccess rights in order to prevent insiders from obtainingunauthorized information. Claycomb et al. [31] proposeda framework for directory virtualization in order to detectinsider attacks against directory services.

Very little research has dealt with insider threat inrelational databases. Yaseen and Panda [12–14] showedhow insiders use their knowledgebases and dependen-cies among data items to pose threat. Furthermore, theyproposed models to detect and prevent insider threatin relational database systems. Yaseen and Panda [15]

discussed the importance of organizing access privilegeswhen executing transactions in mitigating insider threat.They addressed the risky role of knowledgebases thatinsiders can exploit to cause harm to systems. To the bestof our knowledge, this paper is a premier research in thefield of insider threat in cloud relational databases.

3. INSIDER THREAT

The knowledgebases of insiders and dependencies amongdata items, play a major role in insider threat in rela-tional databases. The following section discusses howinsiders can use dependencies and knowledgebases tolaunch attacks.

3.1. The threat of knowledgebases

The knowledgebase of an insider consists of data itemvalues that she/he has previously accessed. That is, it rep-resents the history of accesses to data items by the insider.These data items might be risky because they can be aggre-gated along with other data items using dependencies toderive or deduce unauthorized information [15,16]. Forinstance, assume that a relational database that containsacademic staff information has the following dependency{Rank!Salary}. In addition, suppose that the data items(Name, Rank) or (Rank, Salary) are insensitive informa-tion, whereas (Name, Salary) is sensitive. Suppose thatan insider, say Bob, has accessed the information (Name,Rank) of an academic staff “Alice”, say (Alice, “Assis-tant Professor”). Now, suppose that Bob is requesting theinformation (Rank, Salary) of Alice. In this case, if Bobis granted his request, he can use the dependency to com-bine the information (Alice, Assistant Professor), which isin his knowledgebase, with (Assistant Professor, Salary) toobtain the sensitive information (Alice, Salary). Obviously,building and checking knowledgebases are necessary forinsider threat detection and prevention. Detecting and pre-venting insider threat by investigating knowledgebases ofinsiders and dependencies among data items have beenresearched extensively by many researchers such as Farkaset al. [16] and Yaseen and Panda [12–14]. Interestedreaders can refer to their research for more details. It isimportant to mention here that (Rank, Salary) is a commonknowledge, and one may not be given an access to Rank ifshe/he should not know Salary. However, there exist manysuch dependencies that are not this obvious. For simplicity,we have used (Rank, Salary) example in this paper.

In light of the previous discussion, knowledgebase playsa major role in insider threat, and checking it is a majorstep in any methodology that tackles insider threat inthis context. Building and checking knowledgebase of aninsider are not a hard problem in relational databases thatare local in nature. It is built by profiling the insider’saccesses to data items and used when necessary to pre-vent threat. However, building knowledgebase in cloudrelational databases and using it need new methodologies

Security Comm. Networks (2016) © 2016 John Wiley & Sons, Ltd.DOI: 10.1002/sec

Mitigating insider threat in cloud relational databases Q. Yaseen et al.

because cloud databases are replicated in many sites toassure availability and reliability. The next section explainsthis problem in more details.

3.2. Insider threat in cloudrelational databases

Cloud providers store data in multiple data centers that areboth geographically and logically separated. A data centerconsists of connected servers and storage systems. Storagesystems are aggregated into storage pools to form logicalstorage, which can be accessed from different computersystems that share the storage pool. A key benefit of this isthat the data can be replicated or moved to other locations(storage locations) transparently to servers using it [32].Availability zones in each data center are connected viainexpensive and low latency network. To achieve greaterperformance and fault tolerance, an application’s trafficmay be distributed across multiple availability zones anddata centers, which is called elastic load balancing [33].Figure 1 shows the structure of Amazon cloud services.The figure shows that Amazon has five data centers acrossthe globe. Each data center has more than one availabilityzone (AZ) [34].

Cloud relational databases are fragmented and repli-cated to increase the availability and reliability. The repli-cation of data across availability zones and data centersshould be consistent. Workloads on replicas’ nodes are bal-anced using live migration, where tenants (applications)are migrated from overloaded nodes to idle (or low-loaded)nodes to achieve load balancing. Users have no control onchoosing the location or the instance that they prefer. Cloudsystems choose the server, the location, and the storage thatare needed for executing a process depending on some cri-teria such as the amount of load on servers or availabilityzones. Thus, different user’s requests may be executedon different instances in the same availability zone or indifferent availability zones or data centers.

Replication and load balancing increase the perfor-mance of cloud relational database systems. However,they may increase the probability of insider threat, whicharises when a cloud relational database system fails touse the knowledgebase of insiders to detect the threat.In other words, an insider may combine data itemsshe/he obtains from database instances in different avail-ability zones to launch attacks. Figure 2 shows theproblem. The insider accesses the data item D1 in theavailability zone 1 (AZ1) (that may have the knowledge-base of the insider) and then accesses D2 in the availabilityzone n (AZn) (that may not have the insider’s knowl-edgebase). In this case, the system on the availabilityzone n fails to detect this threat and enables the insiderto access D2. Thus, the insider combines the two dataitems and obtains the sensitive information S1, which isa threat.

In addition, insiders are allowed to access the cloudfrom any site in the globe, which is one of the featuresthat the cloud offers. Cloud systems connect insiders to theclosest availability zone (if it is not overloaded) to executetheir queries in order to achieve the best performance. Thismeans that insiders may be connected to different availabil-ity zones when they travel and work from different sites.In this case, insiders may be able to launch attacks usingthe same scenario described in Figure 2. It is important tomention here that to the best of our knowledge, no researchhas discussed the threat of knowledgebase in cloud envi-ronment and no research has discussed how to manageknowledgebases in this new environment.

In light of the previous discussion, an up-to-date knowl-edgebase of an insider should be checked at each accessby the insider to prevent threats. Furthermore, the knowl-edgebase should be updated after each access the insiderperforms. Thus, cloud RDBMS need new methodolo-gies to build, store, and synchronize knowledgebase incloud environments because local knowledgebases are nolonger suitable.

Figure 1. Amazon’s cloud structure.

Security Comm. Networks (2016) © 2016 John Wiley & Sons, Ltd.

DOI: 10.1002/sec

Q. Yaseen et al. Mitigating insider threat in cloud relational databases

Figure 2. Insider threat in cloud relational database systems.

4. MODELS FOR MITIGATING THETHREAT OF INSIDERS’KNOWLEDGBASES

Securing cloud RDBMS against insider threat needs amethodology that monitors the activities of insiders in dif-ferent instances and locations of cloud relational databases.The knowledgebases of insiders should be monitoredand synchronized to achieve this purpose. In traditionalRDBMS, building, maintaining, and checking knowledge-bases are the responsibilities of organizations (owners).Nonetheless, when moving to the cloud, these operationsare transferred to cloud providers (Cloud RDBMS). Keep-ing these responsibilities for local systems when movingto the cloud violates the concept of cloud computing.Moreover, keeping the knowledgebase of an insider inlocal storage needs transferring it with every access by theinsider, which is infeasible because of the network over-head that it poses especially when knowledgebase obtainslarge. This section introduces four frameworks to maintainknowledgebases in a Cloud RDBMS and demonstrates thefeatures and limitations of each one.

4.1. Peer-to-peer model

In this model, the knowledgebase of each insider is builtand stored in all availability zones. At each access of aninsider to a data item in an AZ, the knowledgebase of theinsider in the availability zone is updated. Next, the updatesare sent to all other availability zones and data centerssimultaneously to keep knowledgebases consistent. Trans-actions are monitored locally at each availability zone ordatabase instance. Thus, insider threat monitoring is per-formed locally without a need to communicate with othernodes. Figure 3 shows the proposed framework, where AZdenotes an availability zone, LB denotes load balancingand U(KBs) denotes updating of knowledgebases.

As shown in Figure 3, an insider sends his/her queryto a cloud RDBMS. The cloud system sends the queryto the closest AZ. If the AZ has a high load, thequery is transferred to another AZ. In both cases, the

Figure 3. Peer-to-peer model.

insider’s knowledgebase is checked to ensure that there isno threat. Once the query is executed, the knowledgebaseof the insider is updated, and the knowledgebases in allother availability zones are updated as well.

A key benefit of this model is that there is no singlepoint of failure. Moreover, transactions and threat detec-tion are executed fast because all processing are performedwithin a single availability zone and no communicationsare needed with other parts of the cloud system. In addi-tion, the manipulating of knowledgebases is distributedamong all availability zones, which balances their load.

The challenge that arises when using this model is theprofiling of activities (building knowledgebases) for eachinsider. Local profiling is faster in processing transactions,but it imposes synchronization problems. Knowledgebasesin all database servers should be updated simultaneously.Otherwise, insiders may access different data items in dif-ferent sites (because of load balancing) and combine themusing dependencies to pose a threat as discussed earlier.Keeping knowledgebases updated needs a lot of immediateprocessing, which is time and resources consuming, andit causes delays in processing transactions. In summary,using this model poses high network traffic and delaystransactions processing especially in the case of large num-ber of replicas. Therefore, this approach is suitable whenthe number of instances is small.

To enhance the performance of this model, updatingknowledgebases in some availability zones can be post-poned when the processing load or network traffic is high.In this case, new processing requests by insiders should bedistributed among up-to-date AZs only. Other AZs can beupdated when traffic is low. This helps in increasing trans-actions’ processing performance and decreasing the delaythat may be caused in case of high network traffic.

4.2. Centralized model

This model uses a coordinator site that builds, stores, andmanages the knowledgebases of all insiders. Furthermore,the query of an insider is sent to the coordinator first.Then, the coordinator inspects the query against insiderthreat using the insider’s knowledgebase, which the coor-dinator has. If there is no threat found, the coordinatortransmits the query to one of the cloud RDBMS nodes

Security Comm. Networks (2016) © 2016 John Wiley & Sons, Ltd.DOI: 10.1002/sec

Mitigating insider threat in cloud relational databases Q. Yaseen et al.

Figure 4. Centralized model.

(in an availability zone), considering the load balancing.After executing the query successfully, the cloud RDBMSsend back an acknowledgement to the coordinator so thatit updates the knowledgebase of the insider. The model inthis state has a bottleneck. Strictly speaking, if the coor-dinator becomes unavailable because of some reason, theentire system of insider threat prediction and preventionfails. Figure 4 shows the modified model. The modifiedmodel uses a secondary coordinator to mitigate the bot-tleneck problem, which is similar to the idea used indamage recovery in distributed systems by Panda and Zue[35].The secondary coordinator is used only in case offailure. However, the secondary knowledgebase should beupdated to keep both knowledgebases consistent as shownin Figure 4, where U(KBs) indicates updating the knowl-edgebases, LB indicates load balancing, and Ackn denotesan acknowledgement.

The advantages of this model include the relativelysmall amount of network traffic compared with the previ-ous model. Thus, this model is more scalable than peer-to-peer model. Moreover, the synchronization is performedamong the instances of knowledgebases only (the primaryand secondary sites). That is, there is no delay occurringbecause of the synchronizing process among knowledge-bases instances. However, the delay may happen becauseall requests are inspected and filtered at the central unit.Therefore, the central unit should be equipped with highperformance capabilities to serve this job.

4.3. Mobile-knowledgebases model

This model has the advantages of peer-to-peer model andmitigates its disadvantages. In this model, an AZ in adata center stores the knowledgebases of insiders who aregeographically close to it instead of storing the knowledge-bases of all insiders. For example, Figure 5 shows howknowledgebases of insiders in the USA may be stored,where Arkansas insiders’ knowledgebases can be stored

in AZ4 and Washington insiders’ knowledgebases can bestored in AZ1. Hence, the AZs may belong to differentdata centers. This model depends on the assumption thatinsiders are highly probably performing most of their workin one location (i.e., a company complex). However, aninsider may perform his/her work from different (geo-graphically) locations, which is a key advantage of cloudcomputing. In this case, the cloud system should send acopy of the knowledgebase of the insider to the new loca-tion to check his/her queries against insider threat. In thefigure, Send KBs stands for sending a copy of a knowledge-base of an insider, which may be needed when balancing aload or when an insider accesses an AZ that does not havehis/her knowledgebase.

To show how the model works, suppose that an insider,say Bob, works for a company in Arkansas, which belongsto AZ4. Assume that Bob traveled to Washington, whichbelongs to AZ1, and he wants to perform some work forhis company. Figure 6 shows how the model works inthis case. Bob sends his query to the cloud system, whichforwards his request to AZ1. The cloud system in thisAZ checks whether Bob’s knowledgebase exists or not.

Figure 5. An example of Mobile-Knowledgebases model.

Figure 6. Executing queries in a Mobile-Knowledgebasesmodel.

Security Comm. Networks (2016) © 2016 John Wiley & Sons, Ltd.

DOI: 10.1002/sec

Q. Yaseen et al. Mitigating insider threat in cloud relational databases

Because the knowledgebase is not available, the cloudsystem in AZ1 reaches other AZs asking for Bob’s knowl-edgebase. AZ4, which has the knowledgebase, respondsand sends back a copy of Bob’s knowledgebase to AZ1.Then, the cloud system in AZ1 checks whether there is athreat posed by Bob. If there is no threat, AZ1 runs Bob’srequest and sends the updates on the Bob’s knowledge-base to AZ4. Algorithm 1 shows how this model worksin details.

Mobile-Knowledgebases model does not need to storethe knowledgebases of all insiders in every availabilityzone as in peer-to-peer model. Moreover, it has less trafficthan peer-to-peer model because the updates of knowl-edgebases are sent to host AZs only in case of "moving"insiders. Therefore, the Mobile-Knowledgebases model ismore scalable than peer-to-peer model. Furthermore, thefailure of an availability zone does not affect the queriesof other insiders in other AZs. That is, it does not havea bottleneck as in the centralized model (more reliable).In addition, in most cases, the model needs to processthe transactions and manage the knowledgebases of someinsiders only, which means it has less processing overheadthan other models.

This model can be further optimized in order to elim-inate the need of sending messages to all AZs lookingfor the knowledgebase of a “moving insider”. This can beachieved by using a directory that stores the hosting AZaddress of all insiders at an organization. Therefore, whenan insider’s query is sent to an AZ other than his/her host-ing one, the cloud system at the new AZ looks up the

directory it has to retrieve the insider’s hosting AZ. Next, amessage is sent to the latter AZ only to retrieve the knowl-edgebase of the insider. Keeping a directory for all insidersneeds more storage, but it greatly minimizes the networktraffic overhead, especially when the number of AZs anddata centers becomes larger. We call this enhanced versionGuided Mobile-Knowledgebases Model. Figure 7 showsthe model.

Figure 7. Executing queries in the Guided Mobile-Knowledgebases model.

Security Comm. Networks (2016) © 2016 John Wiley & Sons, Ltd.DOI: 10.1002/sec

Mitigating insider threat in cloud relational databases Q. Yaseen et al.

5. MANAGING DEPENDENCYGRAPHS AND THE LIFETIMES OFDATA ITEMS

Knowledgebases and dependency graphs are major partsin insider threat prediction and prevention models. Wesuggest using the dependency graphs proposed by Yaseenand Panda [12,13], which are Neural Dependency andInference Graph (NDIG) and Constraint and DependencyGraph (CDG), in insider threat mitigation models in cloudRDBMS. Figure 8 shows an example of NDIG; interestedreaders can refer to the aforementioned research for moredetails about dependency graphs in relational database sys-tems. In traditional insider threat mitigation models (intraditional RDBMS), dependency graphs are stored locallyas a part of the models. In cloud RDBMS, the locationof NDIG and constraint and dependency graph dependson which model we would adopt to manage knowledge-bases. In peer-to-peer and Mobile-Knowledgebases mod-els, dependency graphs should be stored in each AZbecause insider threat prediction and prevention are per-formed at each one. However, in centralized model, depen-dency graphs need to be stored on the coordinators sitesonly. Checking the lifetimes of data items in knowledge-bases is crucial. Not all data items in knowledgebasescan be used for inference; only up-to-date data items arerisky ones. For instance, recall the example mentionedbefore about the dependency (Rank ! Salary). Supposethat Alice has read the (Name, Rank) of Professor Jim,say (Jim, Assistant Professor), which adds this data item toAlice knowledgebase. Now, if Alice obtains an access tothe data item (Assistant Professor, Salary), she will inferthe Salary of Jim, which is a threat. Thus, the system pre-vents her from accessing the latter data item. However,assume that another insider updated the Rank of Jim afterAlice had accessed it. In this case, we say that the life-time of the data item (Jim, Assistant Professor) has expiredbecause the inference based on it will be incorrect. Thus,the data item (Assistant Professor, Salary) can be grantedto Alice if she requests it because no threat could be posedin this case. We should mention here that the lifetime ofa data item is expired if the inference based on its valueis incorrect. Not every update process leads to lifetimeexpiration. The lifetimes of data items and updates werediscussed in [16], and the conditions of considering a data

Figure 8. Part of the dependency and inference graph of facultystaff database.

item as expired or not due to an update process werediscussed in [13,15]. Interested readers can refer to the pre-vious research for more details about this issue. Clearly,checking the lifetimes of data items is crucial in insiderthreat mitigation. Checking knowledgebases and depen-dencies without checking the lifetimes of data items maylimit the availability when no threat could be posed.

In light of the previous discussion, knowledgebasesin cloud RDBMS should be managed with taking intoaccount the lifetimes of data items such that expired dataitems are marked or deleted. Managing the lifetimes ofdata items in cloud RDBMS depends on the model usedfor managing knowledgebases. Two possible ways can beused to manage the lifetimes of data items cloud RDBMS,which are Exhaustive-Updating and Updating-on-Use.

(1) Exhaustive-Updating Approach: In this approach, ateach write access of a data item by an insider, allknowledgebases of insiders are investigated search-ing for the data item. If the data item exists in oneof knowledgebases, the value of the data item ischecked against expiration. If the value is expired,the data item is either deleted or marked as expired.After completing this process, all instances ofaffected knowledgebases should be updated. Noticethat, in this approach, a threat prediction model needsto investigate knowledgebase only to search for arisky data item and to check whether its lifetime isexpired or not.

Using this approach in peer-to-peer model is timeconsuming and causes network traffic and process-ing overhead because the peer-to-peer model main-tains knowledgebases at each availability zone. Oncea knowledgebase is updated, the updates shouldbe sent through networks to other cloud RDBMSnodes. Therefore, this approach can be used in smallsystems that have small number of insiders anddata items and when the number of cloud RDBMSinstances is small.

In centralized model, updating knowledgebaseswhen using the Exhaustive-Updating approach isperformed on the coordinators site only. Moreover,the network traffic occurs between the primary siteand the secondary site only. Thus, less network traf-fic is resulted in comparing with the previous model,which means that it is more scalable. However,because all the processing of threat prediction andprevention is performed at coordinators site, usingthis approach adds more load to the coordinatorsnode, which may overload it. Therefore, powerfulcapabilities should be guaranteed and maintained atthe node.

The workload of using this approach in Mobile-Knowledgebases model is distributed among avail-ability zones. Clearly, because the knowledgebasesof a group of insiders are stored in the closestavailability zone, updating a knowledgebase is per-formed locally, and no update is sent out through

Security Comm. Networks (2016) © 2016 John Wiley & Sons, Ltd.

DOI: 10.1002/sec

Q. Yaseen et al. Mitigating insider threat in cloud relational databases

networks. That is, no network overhead is resulted asin peer-to-peer model, and contrarily to the central-ized model, the processing overhead of maintainingknowledgebases is distributed among all availabilityzones. Thus, the best performance of the Exhaustive-Updating approach is achieved when it used withMobile-Knowledgebases model.

(2) Updating-on-Use Approach: Contrarily to theExhaustive-Updating approach, this method doesnot update knowledgebases immediately after eachwrite operation. Instead, the lifetime of a data item(in a knowledgebase) is updated when it is checkedagainst insider threat only and found expired. Thisprocess is performed as follows. At each read accessto a data item by an insider, say Bob, if the dataitem can be used with a another data item, say F,in Bob’s knowledgebase to pose a threat, the times-tamp of F (in Bob’s knowledgebase) is comparedwith the write timestamp of F in the cloud RDBMS.If F was updated after the last access to it by Bob,F is called P-Expired, which indicates PossiblyExpired. Next, the value of F is investigated to checkwhether F is expired or not. If it is expired, thedata item is removed from Bob’s knowledgebase ormarked as expired. This two-phase checking pro-cess eliminates the need to check the value of F (tocheck it against expiration) in case it has not beenoverwritten after the last access by Bob. Strictlyspeaking, if F has not been overwritten, there is noneed to go further and check its value because itis not expired in this case. However, if F has beenupdated, it might be expired (P-Expired). There-fore, F’s value needs to be checked to ensure that itis expired.

Obviously, using this approach reduces the pro-cessing overhead needed to investigate the knowl-edgebases and update them at each write access.However, it adds more processing time to transac-tions because it needs checking both knowledgebasesand cloud RDBMS in order to check the lifetimes ofdata items during transactions processing.

Adopting this approach in peer-to-peer modeldoes not pose great network traffic overhead becauseupdates to knowledgebases are sent gradually (whenan expired data item is discovered), which isgreatly less than the overhead that is posed whenusing the Exhaustive-Updating approach. How-ever, the processing time needed for transactions isgreater than that needed in the Exhaustive-Updatingapproach as mentioned earlier. Similarly, in central-ized model, using this approach reduces the net-work traffic between the primary and secondarycoordinators in comparing with the Exhaustive-Updating approach but adds more processing timeto transactions. In Mobile-Knowledgebases model,no extra network traffic is resulted as in theExhaustive-Updating approach. However, similarly

to the other models, more processing time is neededfor transactions.

6. EXPERIMENTS AND ANALYSIS

To compare between the proposed models, we used Cloud-Exp Simulator [18], which is an extended version ofthe CloudSim Simulator. The host specifications are fullydescribed in Table I, where every host has one virtualmachine. In addition, Table II shows the properties of theAZs used in the simulations.

The simulations were conducted using five AZs and50 data items. In the case of Mobile-Knowledgebase andGuided Mobile-Knowledgebase models, the percentage ofrequests that were sent to non-hosting availability zones(the availability zones that do not have the knowledgebaseof the requesting insiders) was set to 5%. The work-load was randomized for all the models. For the restof the paper, the abbreviations P2P, CENT, MOBILE,and G-MOBILE indicates peer-to-peer model, central-ized model, Mobile-Knowledgebases model, and GuidedMobile-Knowledgebases model, respectively. In addition,the HOST-AZ indicates the AZ that has the knowledgebaseof the requesting insider.

6.1. Variable number of queries per insider

This simulation was performed to show the effect of thenumber of queries sent by insiders on the performance ofthe system and the network in each model. In this simu-lation, the percentage of accessible data items per insider,which are the data items that the insider is allowed toaccess, was set to 80%, and the percentage of dependencyamong data items was set to 9%. The number of insiderswas set to 100 insiders.

Table I. Host properties.

Item Description

Host ID ID (0- number of hosts)Storage capacity 1 TBMIPS for CPU 1024Memory capacity 2 GBNetwork bandwidth 10 MbpsVirtual machine scheduler Space shared

CPU, central processing unit; MIPS, million instructions per second.

Table II. Availability zone properties.

Part Availability Zone property

Ram (MB) 2048CPU(MIPS) 1000 single coreBandwidth 10,000Storage(MB) 1,000,000

MIPS, million instructions per second.

Security Comm. Networks (2016) © 2016 John Wiley & Sons, Ltd.DOI: 10.1002/sec

Mitigating insider threat in cloud relational databases Q. Yaseen et al.

Figure 9. Number of queries versus network overhead. P2P, peer-to-peer model; CENT, centralized model; MOBILE, Mobile-Knowledgebases model; G-MOBILE, Guided Mobile-Knowledgebases model.

Figure 10. Number of queries versus system overhead. P2P, peer-to-peer model; CENT, centralized model; MOBILE, Mobile-Knowledgebases model; G-MOBILE, Guided Mobile-Knowledgebases model.

6.1.1. Network overhead.

Figure 9 demonstrates the effect of the number ofqueries per insider on the network overhead when using thefour models, which is measured by the number of packetssent through the network. Basically, increasing the numberof queries, which an insider sends, increases the networkoverhead. However, the effect of increasing the numberof queries is the largest when using the P2P model, andthe overhead is the smallest when using the G-MOBILEmodel. As seen in Figure 9, the overhead that the G-MOBILE model poses is very small in comparing withother models.

In P2P model, when the number of queries increases,the synchronization messages that are sent among avail-ability zones increase. This leads to a great overhead inthe P2P model as shown in the figure. In CENT model,the synchronization messages are sent between the pri-mary and secondary units, and between the primary unitand one AZ only for a specific request. Therefore, thenumber of messages sent to network is less than thosesent when using the P2P model. In the case of MOBILEmodel, when increasing the number of queries an insiderrequests, the probability that a request is sent to a distantAZ increases. This clarifies the result in the figure, whichshows that the network overhead increases as the numberof queries increases when using the MOBILE and the G-MOBILE models. However, the overhead is less than thatposed by P2P and CENT models, because in MOBILEmodel the availability zones exchange messages when an

AZ does not have the knowledgebase of the requestinginsider. Obviously, the G-MOBILE model poses less over-head than MOBILE model because it does not broadcastrequests searching for the Host-AZ as MOBILE model.Instead, it communicates a directory to find the HOST-AZ,which reduces the network overhead as the figure shows.One more observation to raise, the growth of MOBILEmodel is larger than the growth of the CENT model. Thisis clear when we increase the number of queries per insiderto 30. Clearly, as discussed before, when increasing thenumber of requests per insider, more requests are sent tonon-hosting AZ (not a HOST-AZ) because of load bal-ancing. This process increases the number of exchangedmessages between the availability zones that receive therequest and the HOST-AZ, which increases the networkoverhead because of transferring the knowledgebase of therequesting insider and the updates that are sent back tothe HOST-AZ. This clarifies why the growth in MOBILEmodel is greater than the growth in CENT model.

6.1.2. System Performance.

Figure 10 shows the effect of increasing the number ofqueries that are sent by insiders on the system performance.As shown in the figure, the processing time needed to fin-ish all workload when using the CENT model increasesgreatly as the number of queries increases. However, theprocessing time is very close to other models.

Security Comm. Networks (2016) © 2016 John Wiley & Sons, Ltd.

DOI: 10.1002/sec

Q. Yaseen et al. Mitigating insider threat in cloud relational databases

The CENT model has a processing unit that dealswith all insiders requests and performs all insider threatdetection. Clearly, as the load increases, the time neededto serve requests increases because of delay. However,in other models, the requests are distributed among allavailability zones. Therefore, a small increase in the num-ber of requests per insider that were performed in thissimulation does not affect the performance of the pro-cessing units. The simulation in this part shows that theG-MOBILE model has the best performance when thenumber of queries is large in the cloud system.

6.2. Variable number of insiders

This simulation was conducted to demonstrate the effectof the number of insiders on the performance of the sys-tem and the network. In this simulation, the percentage ofaccessible data items per insider, which are the data itemsthat the insider is allowed to access, was set to 80%, andthe percentage of dependency among data items was set to9%. The number of insiders was set to 100 insiders.

6.2.1. Network overhead.

This simulation shows how increasing the number ofinsiders affects the network when using the proposed mod-els. Figure 11 shows that the G- MOBILE model has theleast effect on the network when increasing the numberof insiders. Meanwhile, the P2P model has the largestnetwork overhead as the number of insiders increases.

Increasing the number of insiders means more knowl-edgebases that have to be stored. In case of P2P, all theknowledgebases have to be stored and synchronized inall AZs, which explains the huge impact on the networkoverhead as the number of knowledgebases increases.However, when using G-MOBILE model, knowledgebasesare stored locally and are not synchronized in other loca-tions. Furthermore, because only 5% of requests are sentto non-hosting AZs (not a HOST-AZ), few messages aresent to the network. In MOBILE model, it has more traf-fic than G- MOBILE model because broadcast messagesare sent searching for the HOST-AZ. In P2P model, theadded traffic is medium because the synchronization is per-formed between the primary and the secondary units only.In addition, updates on knowledgebases are sent back tothe primary unit through network.

6.2.2. System overhead.

This simulation shows the effect of increasing the num-ber of insiders on the system performance. Figure 12demonstrates similar results to what we discussed inFigure 11. Obviously, the most affected model is theCENT model because it is increasingly overloaded asthe number of insiders increases. Therefore, the delayin serving requests increases as shown in the figure.However, the increase in processing delay when usingother models is small. As discussed before, the requestsare distributed among all AZs because the increase ininsiders is distributed in all AZs. Therefore, a small

Figure 11. Number of insiders versus network overhead. P2P, peer-to-peer model; CENT, centralized model; MOBILE, Mobile-Knowledgebases model; G-MOBILE, Guided Mobile-Knowledgebases model.

Figure 12. Number of insiders versus system overhead. P2P, peer-to-peer model; CENT, centralized model; MOBILE, Mobile-Knowledgebases model; G-MOBILE, Guided Mobile-Knowledgebases model.

Security Comm. Networks (2016) © 2016 John Wiley & Sons, Ltd.DOI: 10.1002/sec

Mitigating insider threat in cloud relational databases Q. Yaseen et al.

Figure 13. Percentage of accessible data items/insider versus system overhead. P2P, peer-to-peer model; CENT, centralized model;MOBILE, Mobile-Knowledgebases model; G-MOBILE, Guided Mobile-Knowledgebases model.

increase in the processing time is added as the number ofinsiders increase.

This simulation proves that increasing the number ofinsiders has a little effect on the G- MOBILE model andit is the best model to use when the cloud system has verylarge number of insiders.

6.3. Variable percentage of accessibledata items

Accessing more data items by insiders increases the sizeof their knowledgebases, which in turn, increases thesynchronization process among replicas when exist. There-fore, we conducted this simulation to show to what extentthe aforementioned argument is correct. In this simula-tion, the percentage of dependency among data itemswas set to 9%, and the number of insiders was set to100 insiders.

Figure 13 demonstrates the effect of increasing the per-centage of accessible data items. As shown in the figure,increasing the allowable data items has a great effect onthe P2P model and has a considerable effect on the CENTmodel. That is, increasing the percentage of accessible dataitems increases the network overhead in P2P and CENTmodels. However, the effect is negligible on the MOBILEand G- MOBILE models.

The P2P model synchronizes the knowledgebases inall availability zones. Therefore, increasing the accessibledata items expands the knowledgebases of insiders, andas a result, it increases the synchronization process. Theaforementioned process greatly maximizes the networkoverhead as shown by the figure. However, in the cen-tralized model, the synchronization is performed betweenthe primary and the secondary units, which is much lessthan the synchronization in the P2P model. Therefore, thegrowth in the network overhead when using the CENTmodel is greatly less than the growth in the P2P model. InMOBILE and G- MOBILE models, the size of knowledge-bases has a negative effect on the network overhead whenthe receiving AZ does not have the knowledgebase of therequesting insider (not a HOST-AZ). In this case, transfer-ring large knowledgebases increases the network overhead.

Nonetheless, the aforementioned process occurs in 5%of the cases, which explains the negligible growthin the network overhead when using those models.Hence, the growth in the network overhead will begreater when requests are largely sent to non-hostingAZs (not HOST-AZs).

In light of the previous discussion, using the G-MOBILE model has the least network overhead among allmodels despite the percentage of accessible data items.

7. CONCLUSIONSCloud security is among the major issues that worry bothindividuals and organizations when moving data to thecloud. One of the riskiest issues is the insider threatbecause of the extreme harm that it may pose. Thispaper has investigated insider threat in cloud relationaldatabases. It has demonstrated how workload balanc-ing across AZs and data centers may help insiders tobypass security mechanisms and launch attacks. To mit-igate insider threat, the paper has proposed new insiderthreat prediction and mitigation models that are suitablefor the cloud environment, which are peer-to-peer model,centralized model, Mobile-Knowledgebases model, andGuided Mobile-Knowledgebases model. In these models,the paper has shown how to manage and synchronizeknowledgebases, dependency graphs, and updates on dataitems to defend cloud RDBMS against insider threat. Thepaper has tested the proposed models to show their effec-tiveness under different environments such as large numberof insiders, large number of queries, and large numberof accessible data items. The experiments have comparedamong the proposed models regarding the overhead thatthey may add to the network and processing systems.In addition, the experiments have shown that the GuidedMobile-Knowledgebase model has the best performance.

REFERENCES

1. Armbrust M, Fox A, Griffith R, Joseph A, Katz R,Konwinski A, Lee G, Patterson D, Rabkin A, StoicaI, Zaharia M. Above the Clouds: A Berkeley Viewof Cloud Computing. Technical Report, University ofCalifornia, Berkeley, CA, USA, 2009.

Security Comm. Networks (2016) © 2016 John Wiley & Sons, Ltd.

DOI: 10.1002/sec

Q. Yaseen et al. Mitigating insider threat in cloud relational databases

2. Boss G, Malladi P, Quan D, Legregni L, Hall H.Cloud Computing, IBM White Paper. Available from:http://download.boulder.ibm.com/ibmdl/pub/software/dw/wes/hipods/Cloud_computing_wp_final_8Oct.pdf[Accessed on 24 August 2015].

3. Amazon Relational Database. Available from: http://aws.amazon.com/rds/ [Accessed on 24 August 2015].

4. Das S, Nishimura S, Agrawal D, Abbadi AE. Alba-tross: lightweight elasticity in shared storage databasesfor the cloud using live data migration. PVLDB 2011;4(8): 494–505.

5. Elmore AJ, Das S, Agrawal D, Abbadi AE. Zephyr:live migration in shared nothing databases for elasticcloud platforms. Proceedings SIGMOD Conference,Athens, Greece, 2011; 301–312.

6. Takabi H, Joshi JBD, Ahn G. Security and privacychallenges in cloud computing environments. IEEESecurity & Privacy 2010; 8(6): 24–31.

7. Curino C, Jones EPC, Popa RA, Malviya N, Wu E,Madden S, Balakrishnan H, Zeldovich N. Relationalcloud: a database service for the cloud. ProceedingsCIDR, Asilomar, CA, USA, 2011; 235–240.

8. Bertino E, Paci F, Ferrini R, Shang N. Privacy-preserving digital identity management for cloud com-puting. IEEE Data Engineering Bulletin 2009; 32:21–27.

9. Richardson R. 15th Annual 2010/2011 ComputerCrime and Security Survey. Available from: http://gatton.uky.edu/faculty/payne/acc324/CSISurvey2010.pdf [Accessed on 12 July 2015].

10. The Value of Corporate Secrets. Available from:https://www.nsi.org/pdf/reports/The Value of Corpo-rate Secrets.pdf [Accessed on 12 July 2015].

11. InforSecurity Europe and PwC. Information SecurityBreaches Survey. Technical Report. Available from:http://www.pwc.co.uk/eng/publications/isbs_survey_2010.html [Accessed on 12 July 2015].

12. Yaseen Q, Panda B. Knowledge acquisition andinsider threat prediction in relational database sys-tems. Proceedings CSE (3), Vancouver, Canada, 2009;450–455.

13. Yaseen Q, Panda B. Predicting and preventing insiderthreat in relational database systems. ProceedingsWISTP, Passau, Germany, 2010; 368–383.

14. Yaseen Q, Panda B. Malicious modification attacksby insiders in relational databases: prediction and pre-vention. Proceedings IEEE SocialCom/PASSAT, Min-neapolis, MN, USA, 2010; 849–856.

15. Yaseen Q, Panda B. Organizing access privileges:maximizing the availability and mitigating the threatof insiders knowledgebase. Proceedings NSS’2010,Melbourne, Australia, 2010; 312–317.

16. Farkas C, Toland TS, Eastman CM. The inferenceproblem and updates in relational databases, Proceed-ings DBSec, Ontario, Canada, 2001; 181–194.

17. Yaseen Q, Panda B. Tackling insider threat incloud relational database systems. Proceedings of 5thIEEE Conference on Utilities and Cloud Computing,Chicago, IL, 2012; 215–218.

18. Jararweh Y, Jarrah M, Alshara Z, Alsaleh M, Al-Ayyoub M. CloudExp: a comprehensive cloud com-puting experimental framework. Simulation ModellingPractice and Theory 2014; 49: 180–192.

19. Kaufman LM. Data security in the world of cloud com-puting. IEEE Security & Privacy 2009; 7(4): 61–64.

20. Subashini S, Kavitha V. A survey on security issues inservice delivery models of cloud computing. Journalof Network and Computer Applications 2011; 34 (1):1–11.

21. Takabi H. SecureCloud: towards a comprehensivesecurity framework for cloud computing environment.Proceedings IEEE COMPSACW10, Seoul, SouthKorea, 2010; 393–398.

22. Arshad J, Townend P, Xu J. An automatic intrusiondiagnosis approach for clouds. Journal of Automationand Computing 2011; 8(3): 286–296.

23. Wang C, Wang Q, Ren K, Lou W. Ensuring data stor-age security in cloud computing, Proceedings of the17th IWQoS, Charleston, SC, USA, 2009; 1–9.

24. Hwang K, Kulkarni S, Hu Y. Cloud security with virtu-alized defense and reputation-based trust management.Proceedings IEEE DASC09, IEEE CS Press, Chengdu,China, 2009; 717–722.

25. Chow R, Golle P, Jakobsson M, Shi E, Staddon J,Masuoka R, Molina J. Controlling data in the cloud:outsourcing computation without outsourcing control.Proceedings ACM CCSW ’09, Chicago, IL, USA,2009.

26. Hacgm H, Tatemura J, Chi Y, Hsiung W, JafarpourH, Moon H, Po O. CloudDB: A Data Store for allSizes in the Cloud. Available from: http://www.nec-labs.com/research/ clouddb-a-data-store-for-all-sizes-in-the-cloud/85 [Accessed on 24 August 2015].

27. SQL Azure. Available from: http://azure.microsoft.com/en-us/services/sql-database/ [Accessed on 24August 2015].

28. Spitzner L. Honeypots: catching the insider threat.Proceedings ACSAC, Las Vegas, NV, USA, 2003;170–181.

29. Althebyan Q, Panda B. A knowledge-base model forinsider threat prediction. Proceedings of the IEEEIAW07, West Point, NY, 2007; 239–246.

30. Fuchs L, Pernul G. Minimizing insider misuse throughsecure identity management. Journal of Security andCommunication Networks 2012; 5(8): 847–862.

Security Comm. Networks (2016) © 2016 John Wiley & Sons, Ltd.DOI: 10.1002/sec

Mitigating insider threat in cloud relational databases Q. Yaseen et al.

31. Claycomb W, Shin D, Ahn G. Enhancing direc-tory virtualization to detect insider activity. Journal

of Security and Communication Networks 2012; 5(8): 873–886.

32. Stryer P. Understanding Data Centers and Cloud

Computing. White Paper. Available from: http://www.

globalknowledge.be/content/files/documents/386696/386790 [Accessed on 24 August 2015].

33. Amazon Elastic Compute Cloud. Available from:http://aws.amazon.com/ec2/ [Accessed on 24 August2015].

34. Amazon Web Services: Overview of Security Pro-cesses. Available from: http://aws.amazon.com/security/ [Accessed on 24 August 2015].

35. Zuo Y, Panda B. Damage discovery in distributeddatabase systems. Proceedings DBSec, Catalonia,Spain, 2004; 111–123.

Security Comm. Networks (2016) © 2016 John Wiley & Sons, Ltd.

DOI: 10.1002/sec