1

Scalable Distributed Service IntegrityAttestation for Software-as-a-Service CloudsJuan Du, Member, IEEE , Daniel J. Dean, Student Member, IEEE Yongmin Tan, Member, IEEE ,

Xiaohui Gu, Senior Member, IEEE , Ting Yu, Member, IEEE

Abstract—Software-as-a-Service (SaaS) cloud systems enable application service providers to deliver their applications viamassive cloud computing infrastructures. However, due to their sharing nature, SaaS clouds are vulnerable to malicious attacks.In this paper, we present IntTest, a scalable and effective service integrity attestation framework for SaaS clouds. IntTest providesa novel integrated attestation graph analysis scheme that can provide stronger attacker pinpointing power than previous schemes.Moreover, IntTest can automatically enhance result quality by replacing bad results produced by malicious attackers with goodresults produced by benign service providers. We have implemented a prototype of the IntTest system and tested it on aproduction cloud computing infrastructure using IBM System S stream processing applications. Our experimental results showthat IntTest can achieve higher attacker pinpointing accuracy than existing approaches. IntTest does not require any specialhardware or secure kernel support and imposes little performance impact to the application, which makes it practical for large-scale cloud systems.

Index Terms—Distributed Service Integrity Attestation, Cloud Computing, Secure Distributed Data Processing

1 INTRODUCTION

Cloud computing has emerged as a cost-effective re-source leasing paradigm, which obviates the need forusers maintain complex physical computing infrastructuresby themselves. Software-as-a-Service (SaaS) clouds (e.g,Amazon Web Service [1], Google AppEngine [2]) buildsupon the concepts of Software as a Service (SaaS) [3]and Service Oriented Architecture (SOA) [4], [5], whichenable application service providers (ASPs) to deliver theirapplications via the massive cloud computing infrastructure.In particular, our work focuses on data stream processingservices [6]–[8] that are considered to be one class of killerapplications for clouds with many real world applicationsin security surveillance, scientific computing, and businessintelligence.

However, cloud computing infrastructures are oftenshared by ASPs from different security domains, whichmake them vulnerable to malicious attacks [9], [10]. Forexample, attackers can pretend to be legitimate serviceproviders to provide fake service components and theservice components provided by benign service providersmay include security holes that can be exploited by at-tackers. Our work focuses on service integrity attacks thatcause the user to receive untruthful data processing results,illustrated by Figure 1. Although confidentiality and pri-vacy protection problems have been extensively studied byprevious research [11]–[16], the service integrity attestation

• Juan Du is with Amazon. Yongmin Tan is with MathWorks. Thework was done when they were PhD students at the North CarolinaState University. Daniel J. Dean, Xiaohui Gu, and Ting Yu are withDepartment of Computer Science, North Carolina State University.Their email addresses are duju@amazon.com, djdean2@ncsu.edu,yongmin.tan@mathworks.com, gu@csc.ncsu.edu, yu@csc.ncsu.edu

s1VM VM

s4VM VM

VM VM

VM VM

VM VM

s6

s3 s7s5

Sensor Networks

User

Data Storage

s2

Fig. 1. Service integrity attack in cloud-based dataprocessing. Si denotes different service componentand V M denotes virtual machines.

problem has not been properly addressed. Moreover, serviceintegrity is the most prevalent problem, which needs tobe addressed no matter whether public or private data areprocessed by the cloud system.

Although previous work has provided various softwareintegrity attestation solutions [9], [17]–[19], [19]–[23],those techniques often require special trusted hardware orsecure kernel support, which makes them difficult to be de-ployed on large-scale cloud computing infrastructures. Tra-ditional Byzantine fault tolerance (BFT) techniques [24],[25] can detect arbitrary misbehaviors using full timemajority voting over all replicas, which however incur highoverhead to the cloud system. A detailed discussion ofthe related work can be found in section 5 of the onlinesupplementary material.

In this paper, we presentIntTest, a new integratedservice integrity attestation framework for multi-tenantcloud systems. IntTest provides apractical service integrityattestation scheme that does not assume trusted entitieson third-party service provisioning sites or require ap-

2

plication modifications. IntTest builds upon our previouswork RunTest [26] and AdapTest [27] but can providestronger malicious attacker pinpointing power than RunTestand AdapTest. Specifically, both RunText and AdapTestas well as traditional majority voting schemes need toassume that benign service providers take majority inevery service function. However, in large-scale multi-tenantcloud systems, multiple malicious attackers may launchcolluding attacks on certain targeted service functions toinvalidate the assumption. To address the challenge, IntTesttakes aholistic approach by systematically examining bothconsistency andinconsistency relationships among differentservice providers within theentire cloud system. IntTest ex-amines both per-function consistency graphs and the globalinconsistency graph. The per-function consistency graphanalysis can limit the scope of damage caused by colludingattackers while the global inconsistency graph analysis caneffectively expose those attackers that try to compromisemany service functions. Hence, IntTest can still pinpointmalicious attackers even if they become majority for someservice functions.

By taking an integrated approach, IntTest can not onlypinpoint attackers more efficiently but also can suppress ag-gressive attackers and limit the scope of the damage causedby colluding attacks. Moreover, IntTest providesresultauto-correction that can automatically replace corrupteddata processing results produced by malicious attackerswith good results produced by benign service providers.

Specifically, this paper makes the following contribu-tions:

• We provide a scalable and efficient distributed serviceintegrity attestation framework for large-scale cloudcomputing infrastructures.

• We present a novel integrated service integrity at-testation scheme that can achieve higher pinpointingaccuracy than previous techniques.

• We describe a result auto-correction technique that canautomatically correct the corrupted results produced bymalicious attackers.

• We conduct both analytical study and experimentalevaluation to quantify the accuracy and overhead ofthe integrated service integrity attestation scheme.

We have implemented a prototype of the IntTest systemand tested it on NCSU’s virtual computing lab (VCL) [28],a production cloud computing infrastructure that operatesin a similar way as the Amazon elastic compute cloud(EC2) [29]. The benchmark applications we use to evaluateIntTest are distributed data stream processing services pro-vided by the IBM System S stream processing platform [8],[30], an industry strength data stream processing system.Experimental results show that IntTest can achieve moreaccurate pinpointing than existing schemes (e.g. RunTest,AdapTest, full time majority voting) under strategicallycolluding attacks. IntTest is scalable, and can reduce theattestation overhead by more than one order of magni-tude compared to the traditional full time majority votingscheme.

The rest of the paper is organized as follows. Section 2

notation meaningpi service providerfi service functionci service componentdi application data tuplePu attestation probabilityr number of copies for a tupleK Max number of malicious service providersCG minimum vertex cover of graph GNp the neighbor set of node pG′

p the residual graph of GΩ the set of malicious service providers identified

by the global inconsistency graphMi the set of malicious service providers identified

by consistency graph in service functionfi

TABLE 1Notations.

presents our system model. Section 3 presents the designdetails. Section 4 provides an analytical study about theIntTest system. Section 5 presents the experimental results.Section 6 sumarizes the limitations of our approach. Finally,the paper concludes in Section 7.

2 PRELIMINARY

In this section, we first introduce the software-as-a-service (SaaS) cloud system model. We then describe ourproblem formulation including the service integrity attackmodel and our key assumptions. Table 1 summarizes all thenotations used in this paper.

2.1 SaaS Cloud System Model

SaaS cloud builds upon the concepts of Software asa Service (SaaS) [3] and Service Oriented Architecture(SOA) [4], [5], which allows application service providers(ASPs) to deliver their applications via large-scale cloudcomputing infrastructures. For example, both Amazon WebService (AWS) and Google AppEngine provide a set ofapplication services supporting enterprise applicationsandbig data processing. A distributed application service canbe dynamically composed from individual service com-ponents provided by different ASPs (pi) [31], [32]. Forexample, a disaster assistance claim processing applica-tion [33] consists of voice-over-IP (VoIP) analysis com-ponent, email analysis component, community discoverycomponent, clustering and join components. Our workfocuses on data processing services [6], [8], [34], [35]which have become increasingly popular with applicationsin many real world usage domains such as business in-telligence, security surveillance, and scientific computing.Each service component, denoted byci, provides a specificdata processing function, denoted byfi, such as sorting,filtering, correlation, or data mining utilities. Each servicecomponent can have one or more input ports for receivinginput data tuples, denoted bydi, and one or more outputports to emit output tuples.

3

In a large-scale SaaS cloud, the same service functioncan be provided by different ASPs. Thosefunctionally-equivalent service components exist because: i) serviceproviders may create replicated service components forload balancing and fault tolerance purposes; and ii) popularservices may attract different service providers for profit.To support automatic service composition, we can deploya set ofportal nodes [31], [32] that serve as the gatewayfor the user to access the composed services in the SaaScloud. The portal node can aggregate different servicecomponents into composite services based on the user’srequirements. For security protection, the portal node canperform authentication on users to prevent malicious usersfrom disturbing normal service provisioning.

Different from other open distributed systems such aspeer-to-peer networks and volunteer computing environ-ments, SaaS cloud systems possess a set of unique features.First, third-party ASPs typically do not want to reveal theinternal implementation details of their software servicesfor intellectual property protection. Thus, it is difficultto only rely on challenge-based attestation schemes [20],[36], [37] where the verifier is assumed to have certainknowledge about the software implementation or haveaccess to the software source code. Second, both the cloudinfrastructure provider and third-party service providersare autonomous entities. It is impractical to impose anyspecial hardware or secure kernel support on individualservice provisioning sites. Third, for privacy protection,only portal nodes have global information about whichservice functions are provided by which service providersin the SaaS cloud. Neither cloud users nor individual ASPshave the global knowledge about the SaaS cloud such asthe number of ASPs and the identifiers of the ASPs offeringa specific service function.

2.2 Problem Formulation

Given an SaaS cloud system, the goal of IntTest isto pinpoint any malicious service provider that offers anuntruthful service function. IntTest treats all service com-ponents as black-boxes, which does not require any specialhardware or secure kernel support on the cloud platform.We now describe our attack model and our key assumptionsas follows.

Attack model. A malicious attacker can pretend to bea legitimate service provider or take control of vulnerableservice providers to provide untruthful service functions.Malicious attackers can be stealthy, which means they canmisbehave on a selective subset of input data or servicefunctions while pretending to be benign service providerson other input data or functions. The stealthy behaviormakes detection more challenging due to the followingreasons: 1) the detection scheme needs to be hidden fromthe attackers to prevent attackers from gaining knowledgeon the set of data processing results that will be verifiedand therefore easily escaping detection; 2) the detectionscheme needs to be scalable while being able to capturemisbehavior that may be both unpredictable and occasional.

p1

p2

p3

portal

1. send d1

2. receive

f(d1)

f

3. send d1'

4. receive f(d1')

5. f(d1) == f(d1')?

benign service

provider

malicious service

provider

Fig. 2. Replay-based consistency check.

In a large-scale cloud system, we need to considercolluding attack scenarios where multiple malicious attack-ers collude or multiple service sites are simultaneouslycompromised and controlled by a single malicious attacker.Attackers couldsporadically collude, which means anattacker can collude with an arbitrary subset of its colludersat any time. We assume that malicious nodes have noknowledge of other nodes except those they interact withdirectly. However, attackers can communicate with theircolluders in an arbitrary way. Attackers can also changetheir attacking and colluding strategies arbitrarily.

Assumptions.We first assume that the total number ofmalicious service components is less than the total numberof benign ones in the entire cloud system. Without thisassumption, it would be very hard, if not totally impossible,for any attack detection scheme to work when comparableground truth processing results are not available. However,different from RunTest, AdapTest, or any previous majorityvoting schemes, IntTest does not assume benign servicecomponents have to be the majority for every servicefunction, which will greatly enhance our pinpointing powerand limit the scope of service functions that can be com-promised by malicious attackers.

Second, we assume that the data processing services areinput-deterministic, that is, given the same input, a benignservice component always produces the same or similaroutput (based on a user defined similarity function). Manydata stream processing functions fall into this category [8].We can also easily extend our attestation framework to sup-port stateful data processing services [38], which howeveris outside the scope of this paper.

Third, we also assume that the result inconsistencycaused by hardware or software faults can be marked byfault detection schemes [39] and are excluded from ourmalicious attack detection.

3 DESIGN AND ALGORITHMS

In this section, we first present the basis of the IntTestsystem: probabilistic replay-based consistency check andthe integrity attestation graph model. We then describethe integrated service integrity attestation scheme in detail.Next, we present the result auto-correction scheme.

3.1 Baseline Attestation Scheme

In order to detect service integrity attack and pin-point malicious service providers, our algorithm re-lies on replay-based consistency check to derive the

4

consistency/inconsistency relationships between serviceproviders. For example, Figure 2 shows the consistencycheck scheme for attesting three service providersp1, p2,and p3 that offer the same service functionf . The portalsends the original input datad1 to p1 and gets back theresultf(d1). Next, the portal sendsd′1, a duplicate ofd1 top3 and gets back the resultf(d′

1). The portal then compares

f(d1) andf(d′1) to see whetherp1 andp3 are consistent.The intuition behind our approach is that if two service

providers disagree with each other on the processing resultof the same input, at least one of them should be malicious.Note that we do not send an input data item and itsduplicates (i.e., attestation data) concurrently. Instead, wereplay the attestation data on different service providersafter receiving the processing result of the original data.Thus, the malicious attackers cannot avoid the risk of beingdetected when they produce false results on the originaldata. Although the replay scheme may cause delay in asingle tuple processing, we can overlap the attestation andnormal processing of consecutive tuples in the data streamto hide the attestation delay from the user.

If two service providers always give consistent output re-sults on all input data, there exists consistency relationshipbetween them. Otherwise, if they give different outputs onat least one input data, there is inconsistency relationshipbetween them. We do not limit the consistency relationshipto equality function since two benign service providersmay produce similar but not exactly the same results. Forexample, the credit scores for the same person may varyby a small difference when obtained from different creditbureaus. We allow the user to define a distance function toquantify the biggest tolerable result difference.

Definition 1: For two output results,r1 andr2, which comefrom two functionally equivalent service providers respec-tively, Result Consistency is defined as eitherr1 = r2, orthe distance betweenr1 and r2 according to user-defineddistance functionD(r1, r2) falls within a thresholdδ.

For scalability, we proposerandomized probabilistic at-testation, an attestation technique that randomly replays asubset of input data for attestation. For composite dataflowprocessing services consisting of multiple service hops,each service hop is composed of a set of functionallyequivalent service providers. Specifically, for an incom-ing tuple di, the portal may decide to perform integrityattestation with probabilitypu. If the portal decides toperform attestation ondi, the portal first sendsdi to a pre-defined service pathp1 → p2... → pl providing functionsf1 → f2... → fl. After receiving the processing result fordi, the portal replays the duplicate(s) ofdi on alternativeservice path(s) such asp′1 → p′2... → p′l, wherep′j providesthe same functionfj as pj. The portal may perform datareplay on multiple service providers to perform concurrentattestation.

After receiving the attestation results, the portal com-pares each intermediate result between pairs of functionallyequivalent service providerspi andp′i. If pi andp′i receivethe same input data but produce different output results,

we say thatpi andp′i are inconsistent. Otherwise, we saythat pi and p′i are consistent with regard to functionfi.For example, let us consider two different credit scoreservice providersp1 andp′

1. Suppose the distance function

is defined as two credit score difference is no more than10. If p1 outputs 500 andp′1 outputs 505 for the sameperson, we sayp1 and p′

1are consistent. However, if

p1 outputs 500 andp′1 outputs 550 for the same person,we would considerp1 and p′

1to be inconsistent. We

evaluate both intermediate and final data processing resultsbetween functionally equivalent service providers to derivethe consistency/inconsistency relationships. For example,if data processing involves a sub-query to a database, weevaluate both the final data processing result along withthe intermediate sub-query result. Note that although we donot attest all service providers at the same time, all serviceproviders will be covered by the randomized probabilisticattestation over a period of time.

With replay-based consistency check, we can test func-tionally equivalent service providers and obtain their con-sistency and inconsistency relationships. We employ boththe consistency graph and inconsistency graph to aggre-gate pair-wise attestation results for further analysis. Thegraphs reflect the consistency/inconsistency relationshipsacross multiple service providers over a period of time.Before introducing the attestation graphs, we first defineconsistency links and inconsistency links.

Definition 2: A consistency link exists between twoservice providers who always give consistent output forthe same input data during attestation. Aninconsistencylink exists between two service providers who give at leastone inconsistent output for the same input data duringattestation.

We then construct consistency graphs for each functionto capture consistency relationships among the serviceproviders provisioning the same function. Figure 3(a) showsthe consistency graphs for two functions. Note that twoservice providers that are consistent for one function arenot necessarily consistent for another function. This is thereason why we confine consistency graphs within individualfunctions.

Definition 3: A per-functionconsistency graph is an undi-rected graph, with all the attested service providers thatprovide the same service function as the vertices andconsistency links as the edges.

We use a global inconsistency graph to capture incon-sistency relationships among all service providers. Twoservice providers are said to be inconsistent as long asthey disagree in any function. Thus, we can derive morecomprehensive inconsistency relationships by integratinginconsistency links across functions. Figure 3(b) showsan example of the global inconsistency graph. Note thatservice providerp5 provides both functionsf1 and f2. Inthe inconsistency graph, there is a single nodep5 with itslinks reflecting inconsistency relationships in both functions

5

f1

p1

p3 p4

p2

p5

f2

p6

p7 p8

p5

benign service provider

malicious service provider

consistency link

(a) Per-function consistency graphs.

p1

p2p3

p4

p5

p6

p7

p8

benign service provider

malicious service provider

inconsistency link

(b) Global inconsistencygraph.

Fig. 3. Attestation graphs.

f1 andf2.

Definition 4: The global inconsistency graph is an undi-rected graph, with all the attested service providers in thesystem as the vertex set and inconsistency links as theedges.

The portal node is responsible for constructing and main-taining both per-function consistency graphs and the globalinconsistency graph. In order to generate these graphs, theportal maintains counters for the number of consistencyresults and counters for the total number of attestation databetween each pair of service providers. The portal updatesthe counters each time when it receives attestation results.At any time, if the counter for consistency results has thesame value with that for the total attestation data, there isa consistency link between this pair of service providers.Otherwise, there is an inconsistency link between them.

3.2 Integrated Attestation Scheme

We now present our integrated attestation graph analysisalgorithm.

Step 1: Consistency graph analysis.We first examineper-function consistency graphs to pinpoint suspicious ser-vice providers. The consistency links in per-function consis-tency graphs can tell which set of service providers keepconsistent with each other on a specific service function.Given any service function, since benign service providersalways keep consistent with each other, benign serviceproviders will form a clique in terms of consistency links.For example, in Figure 3(a),p1, p3 andp4 are benign ser-vice providers and they always form a consistency clique.In our previous work [26], we have developed a clique-based algorithm to pinpoint malicious service providers. Ifwe assume that the number of benign service providersis larger than that of the malicious ones, a benign nodewill always stay in a clique formed by all benign nodes,which has size larger than⌊k/2⌋, wherek is the number ofservice providers provisioning the service function. Thus,we can pinpointsuspicious nodes by identifying nodesthat are outside of all cliques of size larger than⌊k/2⌋.For example, in Figure 3(a),p2 and p5 are identified assuspicious because they are excluded from the clique ofsize 3.

ppp

ppp

pp pp

pp

Graph G

benign service providermalicious service providerinconsistency link

Residual graph after removing p and it’s

neighbors p, p, and pFig. 4. Inconsistency graph G and its residual graph.

However, strategically colluding attackers can try totake majority in a specific service function to escapethe detection. Thus, it is insufficient to examine the per-function consistency graph only. We need to integrate theconsistency graph analysis with the inconsistency graphanalysis to achieve more robust integrity attestation.

Step 2: Inconsistency graph analysis.Given an incon-sistency graph containing only the inconsistency links, theremay exist different possible combinations of the benignnode set and the malicious node set. However, if we assumethat the total number of malicious service providers in thewhole system is no more thanK, we can pinpoint a subsetof truly malicious service providers. Intuitively, given twoservice providers connected by an inconsistency link, wecan say that at least one of them is malicious since anytwo benign service providers should always agree witheach other. Thus, we can derive the lower bound aboutthe number of malicious service providers by examiningthe minimum vertex cover of the inconsistency graph. Theminimum vertex cover of a graph is a minimum set ofvertices such that each edge of the graph is incident to atleast one vertex in the set. For example, in Figure 3(b),p2 and p5 form the minimum vertex cover. We presenttwo propositions as part of our approach. The proofs forthese propositions can be found in section 1 of the onlinesupplementary material.

Proposition 1: Given an inconsistency graphG, let CG be aminimum vertex cover ofG. Then the number of maliciousservice providers is no less than|CG|.

We now define the residual inconsistency graph for anodepi as follows.

Definition 5: The residual inconsistency graph of nodepi

is the inconsistency graph after removing the nodepi andall of links adjacent topi.

For example, Figure 4 shows the residual inconsistencygraph after removing the nodep2. Based on the lowerbound of the number of malicious service providers andDefinition 5, we have the following proposition for pin-pointing a subset of malicious nodes.

Proposition 2: Given an integrated inconsistency graphGand the upper bound of the number of malicious serviceprovidersK, a nodep must be a malicious service providerif and only if

|Np| + |CG′

p| > K (1)

6

where|Np| is the neighbor size ofp, and|CG′

p| is the size

of the minimum vertex cover of theresidual inconsistencygraph after removingp and its neighbors fromG.

For example, in Figure 3(b), suppose we know thenumber of malicious service providers is no more than 2.Let us examine the malicious nodep2 first. After we removep2 and its neighborsp1, p3, andp4 from the inconsistencygraph, the residual inconsistency graph will be a graphwithout any link. Thus, its minimum vertex cover is 0.Sincep2 has three neighbors, we have3 + 0 > 2. Thus,p2 is malicious. Let us now check out the benign nodep1.After removingp1 and its two neighborsp2 and p5, theresidual inconsistency graph will be a graph without anylink and its minimum vertex cover should be 0. Sincep1

has two neighbors, Equation 1 does not hold. We will notpinpoint p1 as malicious in this step.

Note that benign service providers that do not serve samefunctions with malicious ones will be isolated nodes inthe inconsistency graph, since they will not be involvedin any inconsistency links. For example, in Figure 5,nodesp4, p5, p6 and p7 are isolated nodes since they arenot associated with any inconsistency links in the globalinconsistency graph. Thus, we can remove these nodes fromthe inconsistency graph without affecting the computationof the minimum vertex cover.

We now describe how to estimate the upper bound of thenumber of malicious service providersK. Let N denotethe total number of service providers in the system. Sincewe assume that the total number of malicious serviceproviders is less than that of benign ones, the number ofmalicious service providers should be no more than⌊N/2⌋.According proposition 1, the number of malicious serviceproviders should be no less than the size of the minimumvertex cover|CG| of the global inconsistency graph. Thus,K is first bounded by its lower bound|CG| and upperbound⌊N/2⌋. We then use an iterative algorithm to tightenthe bound ofK. We start from the lower bound ofK,and compute the set of malicious nodes, as described byProposition 2, denoted byΩ. Then we gradually increaseK by one each time. For each specific value ofK, wecan get a set of malicious nodes. With a largerK, thenumber of nodes that can satisfy|Ns|+|CG′

s| > K becomes

less, which causes the setΩ to be reduced. WhenΩ = ∅,we stop increasingK, since any largerK cannot givemore malicious nodes. Intuitively, whenK is large, fewernodes may satisfy Equation 1. Thus, we may only identifya small subset of malicious nodes. In contrast, whenKis small, more nodes may satisfy Equation 1, which maymistakenly pinpoint benign nodes as malicious. To avoidfalse positives, we want to pick a large enoughK, whichcan pinpoint a set of true malicious service providers.

Step 3: Combining consistency and inconsistencygraph analysis results.Let Gi be the consistency graphgenerated for service functionfi, and G be the globalinconsistency graph. LetMi denote the list of suspiciousnodes by analyzing per function consistency graphGi (i.e.,nodes belonging to minority cliques), andΩ denotes the listof suspicious nodes by analyzing the global inconsistency

f1

p1

p3

p8

p2p9

f2

p4

p6 p7

p5

benign service provider

malicious service provider

consistency link

(a) Consistency graphs.

p1

p2p3p4p5p6p7

p8

p9

benign service provider

malicious service provider

inconsistency link

(b) Inconsistency graph.

Fig. 5. Isolated benign service providers in the globalinconsistency graph.

f1

p1

p3

p8

p2p9

f2

p4

p6 p7

p5

p9

consistency graphs inconsistency graph

p1

p2p3p4p5p6p7

p8

p9

benign service provider

malicious service provider

consistency link

inconsistency link

Fig. 6. An example for integrated graph analysis withtwo malicious nodes.

graphG, given a particular upper bound of the number ofmalicious nodesK. We examine per-function consistencygraphs one by one. LetΩi denote the subset ofΩ thatserves functionfi. If Ωi ∩ Mi 6= ∅, we add nodes inMi

to the identified malicious node set. The idea is that sincethe majority of nodes serving functionfi have successfullyexcluded malicious nodes inΩi, we could trust theirdecision on proposingMi as malicious nodes. Pseudo-codeof our algorithm can be found in section 1 of the onlinesupplemental material.

For example, Figure 6 shows both the per-functionconsistency graphs and the global inconsistency graph. Ifthe upper bound of the malicious nodesK is set to 4,the inconsistency graph analysis will capture the maliciousnodep9 but will miss the malicious nodep8. The reason isthat p8 only has three neighbors and the minimum vertexcover for the residual inconsistency graph after removingp8

and its three neighbors is 1. Note that we will not pinpointany benign node as malicious according to Proposition2. For example, the benign nodep1 has two neighborsand the minimum vertex cover for the residual graph afterremovingp1 and its two neighborsp8 and p9 will be 0since the residual graph does not include any link. However,by checking the consistency graph of functionf1, wefind Ω1 = p9 has overlap with the minority cliqueM1 = p8, p9. We then inferp8 should be malicious too.

Note that even if we have an accurate estimation of thenumber of malicious nodes, the inconsistency graph analy-sis scheme may not identifyall malicious nodes. However,our integrated algorithm can pinpoint more malicious nodesthan the inconsistency graph only algorithm. An example

7

p1

p2

p3portal

Send dto

original path

f1

Send d’ to attestation path 1p4

p5

p6

p7

p8

f2

p9

p10

p11

p12

p13

f3

p14

p15

Benign node Suspicious node

Send d” to

attestation path 2

f3(f2(f1(d)))

f3(f2(f1(d’)))

f 3(f 2(f 1(d”)))

Fig. 7. Automatic data correction using attestation dataprocessing results.

showing how our algorithm can pinpoint more maliciousnodes than the inconsistency graph only algorithm can befound in section 1 of the online supplemental material.

3.3 Result Auto-Correction

IntTest can not only pinpoint malicious service providersbut also automatically correct corrupted data processingresults to improve the result quality of the cloud dataprocessing service, illustrated by Figure 7. Without ourattestation scheme, once an original data item is manip-ulated by any malicious node, the processing result of thisdata item can be corrupted, which will result in degradedresult quality. IntTest leverages the attestation data andthemalicious node pinpointing results to detect and correctcompromised data processing results.

Specifically, after the portal node receives the resultf(d)of the original datad, the portal node checks whether thedata d has been processed by any malicious node thathas been pinpointed by our algorithm. We label the resultf(d) as “suspicious result” ifd has been processed by anypinpointed malicious node. Next, the portal node checkswhetherd has been chosen for attestation. Ifd is selectedfor attestation, we check whether the attestation copy ofd only traverses good nodes. If it is true, we will use theresult of the attestation data to replacef(d). For example, inFigure 7, the original datad is processed by the pinpointedmalicious nodes6 while one of its attestation datad′′ isonly processed by benign nodes. The portal node will usethe attestation data resultf(d′′) to replace the original resultthat can be corrupted ifs6 cheated ond.

4 SECURITY ANALYSIS

We now present a summary of the results of our ana-lytical study about IntTest. Additional details along withaproof of the proposition presented in this section can befound in section 2 of the online supplemental material.

Proposition 3: Given an accurate upper bound of thenumber of malicious service providersK, if maliciousservice providers always collude together, IntTest has zerofalse positive.

Although our algorithm cannot guarantee zero false posi-tives when there are multiple independent colluding groups,it will be difficult for attackers to escape our detection withmultiple independent colluding groups since attackers willhave inconsistency links not only with benign nodes butalso with other groups of malicious nodes. Additionally, ourapproach limits the damage colluding attackers can cause ifthey can evade detection in two ways. First, our algorithmlimits the number of functions which can be simultaneouslyattacked. Second, our approach ensures a single attackercannot participate in compromising an unlimited numberof service functions without being detected.

5 EXPERIMENTAL EVALUATION

In this section, we present the experimental evaluation ofthe IntTest system. We first describe our experimental setup.We then present and analyze the experimental results.

5.1 Experiment Setup

We have implemented a prototype of the IntTest systemand tested it using the NCSU’s virtual computing lab(VCL) [28], a production cloud infrastructure operating ina similar way as Amazon EC2 [29]. We add portal nodesinto VCL and deploy IBM System S stream processingmiddleware [8], [30] to provide distributed data streamprocessing service. System S is an industry-strength highperformance stream processing platform that can analyzemassive volumes of continuous data streams and scale tohundreds of processing elements (PEs) for each application.In our experiments, we used 10 VCL nodes which run64bit CentOS 5.2. Each node runs multiple virtual machines(VMs) on top of Xen 3.0.3.

The dataflow processing application we use in our ex-periments is adapted from the sample applications providedby System S. This application takes stock information asinput, performs windowed aggregation on the input streamaccording to the specified company name and then performscalculations on the stock data. We use a trusted portal nodeto accept the input stream, perform comprehensive integrityattestation on the PEs and analyze the attestation results.The portal node constructs one consistency graph for eachservice function and one global inconsistency graph acrossall service providers in the system.

For comparison, we have also implemented three alterna-tive integrity attestation schemes: 1) theFull-Time MajorityVoting (FTMV) scheme, which employsall functionally-equivalent service providers at all time for attestation anddetermines malicious service providers through majorityvoting on the processing results; 2) thePart-Time MajorityVoting (PTMV) scheme, which employsall functionally-equivalent service providers over a subset of input datafor attestation and determines malicious service providersusing majority voting; and 3) theRunTest scheme [26],which pinpoints malicious service providers by analyzingonly per-function consistency graphs, labeling those serviceproviders that are outside of all cliques of size larger than⌊k/2⌋ as malicious, wherek is the number of service

8

10 20 30 40 50 60 70 80 90 1000

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

Percentage of attacked service functions (%)

Ave

rage

acc

urac

y

AD

-IntTest

AF-IntTest

AD

-Majority Voting/RunTest

AF-Majority Voting/RunTest

(a) Aggressive attackers

10 20 30 40 50 60 70 80 90 1000

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

Percentage of attacked service functions (%)

Ave

rage

acc

urac

y

AD

-IntTest

AF-IntTest

AD

-Majority Voting/RunTest

AF-Majority Voting/RunTest

(b) Conservative attackers

Fig. 8. Malicious attackers pinpointing accuracy com-parison with 20% service providers being malicious.

providers that take participate in this service function. Notethat AdapTest [27] uses the same attacker pinpointing algo-rithm as RunTest. Thus, AdapTest has the same detectionaccuracy as RunTest but with less attestation overhead.

Three major metrics for evaluating our scheme arede-tection rate, false alarm rate, and attestation overhead.We calculate the detection rate, denoted byAD, as thenumber of pinpointed malicious service providers overthe total number of malicious service providers that havemisbehaved at least once during the experiment. Duringruntime, the detection rate should start from zero andincrease as more malicious service providers are detected.false alarm rateAF is defined asNfp/(Nfp +Ntn), whereNfp denotes false alarms corresponding to the numberof benign service providers that are incorrectly identifiedas malicious;Ntn denotes true negatives corresponding tothe number of benign service providers that are correctlyidentified as benign. The attestation overhead is evaluatedby both the number of duplicated data tuples that areredundantly processed for service integrity attestation andthe extra dataflow processing time incurred by the integrityattestation.

We assume that the colluding attackers know our attes-tation scheme and take the best strategy while evaluatingthe IntTest system. According to the security analysis inSection 4, in order to escape detection, the best practicefor attackers is to attack as a colluding group. Colludingattackers can take different strategies. They mayconser-vatively attack by first attacking those service functionswith less number of service providers where they caneasily take majority, assuming they know the number ofparticipating service providers for each service function.Alternatively, they mayaggressively attack by attackingservice functions randomly, assuming they do not know thenumber of participating service providers. We investigatethe impact of these attack strategies on our scheme in termsof both detection rate and false alarm rate.

5.2 Results and Analysis

We first investigate the accuracy of our scheme in pin-pointing malicious service providers. Figure 8(a) comparesour scheme with the other alternative schemes (i.e., FTMV,PTMV, RunTest) when malicious service providersaggres-sively attack different number of service functions. In this

0 50 100 150 200 250 3000

0.2

0.4

0.6

0.8

1

Time (ms)

Det

ectio

n R

ate

IntTestFTMVPTMVRunTest

Fig. 9. Detection rate timeline results.

set of experiments, we have 10 service functions and 30service providers. The number of service providers in eachservice function randomly ranges in [1,8]. Each benignservice provider provides two randomly selected servicefunctions. The data rate of the input stream is 300 tuplesper second. We set 20% of service providers as malicious.After the portal receives the processing result of a newdata tuple, it randomly decides whether to perform dataattestation. Each tuple has 0.2 probability of getting attested(i.e., attestation probabilityPu = 0.2), and two attestationdata replicas are used (i.e., number of total data copiesincluding the original datar = 3). Each experiment is re-peated three times. We report the average detection rate andfalse alarm rate achieved by different schemes. Note thatRunTest can achieve the same detection accuracy resultsas the majority voting based schemes after the randomizedprobabilistic attestation covers all attested service providersand discovers the majority clique [26]. In contrast, IntTestcomprehensively examines both per-function consistencygraphs and the global inconsistency graph to make thefinal pinpointing decision. We observe that IntTest canachieve much higher detection rate and lower false alarmrate than other alternatives. Moreover, IntTest can achievebetter detection accuracy when malicious service providersattack more functions. We also observe that when maliciousservice providers attack aggressively, our scheme can detectthem even though they attack a low percentage of servicefunctions.

Figure 8(b) shows the malicious service provider de-tection accuracy results under theconservative attack sce-narios. All the other experiment parameters are kept thesame as the previous experiments. The results show thatIntTest can consistently achieve higher detection rate andlower false alarm rate than the other alternatives. In theconservative attack scenario, as shown by Figure 8(b), thefalse alarm rate of IntTest first increases when a smallpercentage of service functions are attacked and then dropsto zero quickly with more service functions are attacked.This is because when attackers only attack a few servicefunctions where they can take majority, they can hidethemselves from our detection scheme while tricking ouralgorithm into labeling benign service providers as mali-cious. However, if they attack more service functions, theycan be detected since they incur more inconsistency linkswith benign service providers in the global inconsistencygraph. Note that majority voting based schemes can alsodetect malicious attackers if attackers fail to take majority

9

0.2 0.4 0.6 0.80

0.2

0.4

0.6

0.8

1

Misbehaving probability

Re

su

lt q

ua

lity

without auto-correctionwith auto-correction, Pu=0.2with auto-correction, Pu=0.4

(a) 20% non-colluding attack-ers

0.2 0.4 0.6 0.80

0.2

0.4

0.6

0.8

1

Misbehaving probability

Re

su

lt q

ua

lity

without auto-correctionwith auto-correction, Pu=0.2with auto-correction, Pu=0.4

(b) 40% colluding attackers

Fig. 10. Result quality detection and auto-correctionperformance under non-colluding attacks.

0

20

40

60

80

100

IntTest/RunTest

(Pu=0.2, r=3)

PTMV (Pu=0.2) FTMV

Ra

tio

of

du

plica

ted

tup

les t

o o

rig

ina

l

tup

les (

%)

400

Fig. 11. Attestation overhead comparison.

in the attacked service function. However, majority votingbased schemes have high false alarms since attacks canalways trick the schemes to label benign service providersas malicious as long as attackers can take majority in eachindividual service function.

The results of increasing the percentage of maliciousservice providers to 40% can be found in section 3 of theonline supplemental material.

We now show one example of detection time comparisonresults during the above experiments, shown by Figure 9.In this case, malicious service providers use a small prob-ability (0.2) to misbehave on an incoming data tuple. Forprobabilistic attestation schemes such as IntTest, PTMV,and RunTest, the attestation probability is set at a smallnumber (0.2) too. For IntTest and RunTest, two attestationdata replicas are used (r = 3). Here, the attackers mayattack different service functions with different subset oftheir colluders. As expected, the FTMV scheme needs theleast time to detect malicious service providers becauseit attests all service components all the time. AlthoughPTMV has the same attestation probability with IntTestand RunTest, it has shorter detection time since it usesall service components for each attestation data. IntTestcan achieve shorter detection time than RunTest. Similar toprevious experiments, IntTest achieves the highest detectionrate among all algorithms. RunTest, FTMV and PTMVcannot achieve 100% detection rate since they cannot detectthose attackers that only misbehave in service functionswhere they can take the majority.

We also conducted sensitivity study to evaluate theimpact of various system parameters on the effectivenessof our algorithm. Those results can be found in Section 3of the online supplementary material.

We now evaluate the effectiveness of our result auto-

correction scheme. We compare the result quality withoutauto-correction and with auto-correction, and also investi-gate the impact of the attestation probability. Figure 10(a)and Figure 10 show the result quality under non-colludingattacks with 20% malicious nodes and colluding attackswith 40% malicious nodes respectively. We vary the attes-tation probability from 0.2 to 0.4. In both scenarios, IntTestcan achieve significant result quality improvement withoutincurring any extra overhead other than the attestation over-head. IntTest can achieve higher result quality improvementunder higher node misbehaving probability. This is becauseIntTest can detect the malicious nodes earlier so that it cancorrect more compromised data using the attestation data.

Figure 11 compares the overhead of the four schemes interms of the percentage of attestation traffic compared tothe original data traffic (i.e., the total number of duplicateddata tuples used for attestation over the number of originaldata tuples). The data rate is 300 tuples per second. Eachexperiment run processes 20,000 data tuples. IntTest andRunTest save more than half attestation traffic than PTMV,and incur an order of magnitude less attestation overheadthan FTMV. Additional overhead analysis details are avail-able in section 3 of the online supplemental material.

6 LIMITATION DISCUSSION

Although we have shown that IntTest can achieve betterscalability and higher detection accuracy than existingschemes, IntTest still has a set of limitations that requirefurther study. A detailed limitation discussion can be foundin Section 4 of the online supplementary material. We nowprovide a summary of the limitations of our approach. First,malicious attackers can still escape the detection if theyonly attack a few service functions, take majority in all thecompromised service functions, and have less inconsistencylinks than benign service providers. However, IntTest caneffectively limit the attack scope and make it difficult toattack popular service functions. Second, IntTest needs toassume the attested services are input deterministic wherebenign services will return the same or similar resultsdefined by a distance function for the same input. Thus,IntTest cannot support those service functions whose resultsvary significantly based on some random numbers or time-stamps.

7 CONCLUSION

In this paper, we have presented the design and imple-mentation of IntTest, a novel integrated service integrityattestation framework for multi-tenant software-as-a-servicecloud systems. IntTest employs randomized replay-basedconsistency check to verify the integrity of distributedservice components without imposing high overhead to thecloud infrastructure. IntTest performs integrated analysisover both consistency and inconsistency attestation graphsto pinpoint colluding attackers more efficiently than exist-ing techniques. Furthermore, IntTest provides result auto-correction to automatically correct compromised results toimprove the result quality. We have implemented IntTest

10

and tested it on a commercial data stream processingplatform running inside a production virtualized cloudcomputing infrastructure. Our experimental results showthat IntTest can achieve higher pinpointing accuracy thanexisting alternative schemes. IntTest is light-weight, whichimposes low performance impact to the data processingprocessing services running inside the cloud computinginfrastructure.

ACKNOWLEDGMENTS

This work was sponsored in part by U.S. Army ResearchOffice (ARO) under grant W911NF-08-1-0105 managed byNCSU Secure Open Systems Initiative (SOSI), NSF CNS-0915567, and NSF IIS-0430166. Any opinions expressed inthis paper are those of the authors and do not necessarilyreflect the views of the ARO, NSF or U.S. Government.

REFERENCES

[1] “Amazon Web Services,” http://aws.amazon.com/.[2] “Google App Engine,” http://code.google.com/appengine/.[3] “Software as a Service,”http://en.wikipedia.org/wiki/Software as a

Service.[4] G. A. amd F. Casati, H. Kuno, and V. Machiraju, “Web Services

Concepts, Architectures and Applications Series: Data-Centric Sys-tems and Applications,”Addison-Wesley Professional, 2002.

[5] T. Erl, “Service-Oriented Architecture (SOA): Concepts, Technology,and Design,”Prentice Hall, 2005.

[6] T. S. Group, “STREAM: The Stanford Stream Data Manager,”IEEEData Engineering Bulletin, 26(1):19-26, Mar. 2003.

[7] D. J. Abadi and et al, “The Design of the Borealis Stream ProcessingEngine,” Proc. of CIDR, 2005.

[8] B. Gedik, H. Andrade, and et. al., “SPADE: the System S DeclarativeStream Processing Engine,”Proc. of SIGMOD, Apr. 2008.

[9] S. Berger, R. Caceres, and et. al., “TVDc: Managing security in thetrusted virtual datacenter,”ACM SIGOPS Operating Systems Review,vol. 42, no. 1, pp. 40–47, 2008.

[10] T. Ristenpart, E. Tromer, H. Shacham, and S. Savage, “Hey, you, getoff my cloud! exploring information leakage in third- partycomputeclouds,” in Proceedings of the 16th ACM Conference on Computerand Communications Security (CCS), 2009.

[11] W. Xu, V. N. Venkatakrishnan, R. Sekar, and I. V. Ramakrishnan, “Aframework for building privacy-conscious composite web services,”in IEEE International Conference on Web Services, Chicago, IL,Sep. 2006, pp. 655–662.

[12] P. C. K. Hung, E. Ferrari, and B. Carminati, “Towards standardizedweb services privacy technologies,” inIEEE International Confer-ence on Web Services, San Diego, CA, Jun. 2004, pp. 174–183.

[13] L. Alchaal, V. Roca, and M. Habert, “Managing and securing webservices with vpns,” inIEEE International Conference on WebServices, San Diego, CA, Jun. 2004, pp. 236–243.

[14] H. Zhang, M. Savoie, S. Campbell, S. Figuerola, G. von Bochmann,and B. S. Arnaud, “Service-oriented virtual private networks for gridapplications,” inIEEE International Conference on Web Services,Salt Lake City, UT, Jul. 2007, pp. 944–951.

[15] M. Burnside and A. D. Keromytis, “F3ildcrypt: End-to-end protec-tion of sensitive information in web services,” inISC, 2009, pp.491–506.

[16] I. Roy, S. Setty, and et. al., “Airavat: Security and privacy forMapReduce,” inNSDI, April 2010.

[17] J. Garay and L. Huelsbergen, “Software integrity protection usingtimed executable agents,” inProceedings of ACM Symposium onInformation, Computer and Communications Security (ASIACCS),Taiwan, Mar. 2006.

[18] T. Garfinkel, B. Pfaff, and et. al., “Terra: A virtual machine-basedplatform for trusted computing,” inProceedings of the 19th ACMSymposium on Operating Systems Principles (SOSP), Oct. 2003.

[19] A. Seshadri, M. Luk, E. Shi, A. Perrig, L. van Doorn, and P. Khosla,“Pioneer: Verifying code integrity and enforcing untampered codeexecution on legacy systems,” inProceedings of the 20th ACMSymposium on Operating Systems Principles (SOSP), Oct. 2005.

[20] E. Shi, A. Perrig, and L. V. Doorn, “Bind: A fine-grained attestationservice for secure distributed systems,” inProceedings of the IEEESymposium on Security and Privacy, 2005.

[21] “Trusted computing group,” Trusted Computing Group,https://www.trustedcomputinggroup.org/home.

[22] “TPM Specifications Version 1.2,” TPM,https://www.trustedcomputinggroup.org/downloads/specifications/tpm/tpm.

[23] J. L. Griffin, T. Jaeger, R. Perez, and R. Sailer, “Trusted virtualdomains: Toward secure distributed services,” inProceedings of FirstWorkshop on Hot Topics in System Dependability, Jun. 2005.

[24] L. Lamport, R. Shostak, and M. Pease, “The byzantine generals prob-lem,” ACM Transactions on Programming Languages and Systems,4(3), 1982.

[25] T. Ho, B. Leong, R. Koetter, and et. al., “Byzantine modificationdetection in multicast networks using randomized network coding,”in IEEE ISIT, 2004.

[26] J. Du, W. Wei, X. Gu, and T. Yu, “Runtest: Assuring integrity ofdataflow processing in cloud computing infrastructures,” in ACMSymposium on Information, Computer and Communications Security(ASIACCS), 2010.

[27] J. Du, N. Shah, and X. Gu, “Adaptive data-driven serviceintegrity at-testation for multi-tenant cloud systems,” inInternational Workshopon Quality of Service (IWQoS), San Jose, CA, 2011.

[28] “Virtual Computing Lab,” http://vcl.ncsu.edu/.[29] “Amazon Elastic Compute Cloud,” http://aws.amazon.com/ec2/.[30] N. Jain and et al., “Design, Implementation, and Evaluation of the

Linear Road Benchmark on the Stream Processing Core,”Proc. ofSIGMOD, 2006.

[31] B. Raman, S. Agarwal, and et. al., “The SAHARA Model for ServiceComposition Across Multiple Providers,”Proceedings of the FirstInternational Conference on Pervasive Computing, August 2002.

[32] X. Gu, K. Nahrstedt, and et. al., “ QoS-Assured Service Compositionin Managed Service Overlay Networks,”Proc. of ICDCS, 194-202,2003.

[33] K.-L.Wu, P. S. Yu, B. Gedik, K. Hildrum, C. C. Aggarwal, E. Bouil-let, W. Fan, D. George, X. Gu, G. Luo, and H. Wang, “Challengesand Experience in Prototyping a Multi-Modal Stream Analytic andMonitoring Application on System S,”Proc. of VLDB, 1185-1196,2007.

[34] J. Dean and S. Ghemawat, “MapReduce: Simplified Data Processingon Large Clusters,”Proc. of USENIX Symposium on OperatingSystem Design and Implementation, 2004.

[35] M. Isard, M. Budiu, Y. Yu, A. Birrell, and D. Fetterly, “Dryad:Distributed data-parallel programs from sequential building blocks,”Proc. of European Conference on Computer Systems (EuroSys),Lisbon, Portugal, 2007.

[36] A. Seshadri, A. Perrig, L. V. Doorn, and P. Khosla, “Swatt: Software-based attestation for embedded devices,” inIEEE Symposium onSecurity and Privacy, May 2004.

[37] A. Haeberlen, P. Kuznetsov, and P. Druschel, “Peerreview: Practicalaccountability for distributed systems,” inACM Symposium onOperating Systems Principles, 2007.

[38] J. Du, X. Gu, and T. Yu, “On verifying stateful dataflow processingservices in large-scale cloud systems,” inACM Conference onComputer and Communications Security (CCS), Chicago, IL, 2010,pp. 672–674.

[39] I. Hwang, “A survey of fault detection, isolation, and reconfigurationmethods,”IEEE Transactions on Control System Technology, 2010.

Juan Du is a software engineer at Amazon.She received her PhD degree from the De-partment of Computer Science, North Car-olina State University in 2011, and her BSand MS degrees from the Department ofComputer Science, Tianjin University, China,in 2001 and 2004 respectively. She has in-terned at Ericsson, Cisco Systems, and IBMT. J. Watson Research center when she wasa PhD student.

11

Daniel J. Dean is a PhD student in theDepartment of Computer Science at NorthCarolina State University. He received a BSand MS in computer science from StonyBrook University, New York in 2007 and 2009respectively. He has interned with NEC LabsAmerica in the summer of 2012 and is astudent member of the IEEE.

Yongmin Tan is a software engineer in Math-Works. He currently focuses on modelingdistributed systems for Simulink. His generalresearch interests include reliable distributedsystems and cloud computing. He receivedhis PhD degree in 2012 from the Departmentof Computer Science, North Carolina StateUniversity. He received his BE degree andME degree, both in Electrical Engineeringfrom Shanghai Jiaotong University in 2005and 2008 respectively. He has interned with

NEC Labs America in 2010. He is a recipient of the best paper awardfrom ICDCS 2012.

Xiaohui Gu is an assistant professor inthe Department of Computer Science at theNorth Carolina State University. She receivedher PhD degree in 2004 and MS degreein 2001 from the Department of ComputerScience, University of Illinois at Urbana-Champaign. She received her BS degreein computer science from Peking University,Beijing, China in 1999. She was a researchstaff member at IBM T. J. Watson ResearchCenter, Hawthorne, New York, between 2004

and 2007. She received ILLIAC fellowship, David J. Kuck Best MasterThesis Award, and Saburo Muroga Fellowship from University ofIllinois at Urbana-Champaign. She also received the IBM InventionAchievement Awards in 2004, 2006, and 2007. She has filed eightpatents, and has published more than 50 research papers in inter-national journals and major peer-reviewed conference proceedings.She is a recipient of NSF Career Award, four IBM Faculty Awards2008, 2009, 2010, 2011, and two Google Research Awards 2009,2011, a best paper award from IEEE CNSM 2010, and NCSU FacultyResearch and Professional Development Award. She is a SeniorMember of IEEE.

Ting Yu is an Associate Professor in the De-partment of Computer Science, North Car-olina State University. He obtained his PhDfrom the University of Illinois at Urbana-Champaign in 2003, MS from the Universityof Minnesota in1998, and BS from PekingUniversity in 1997, all in computer science.His research is in security, with a focus ondata security and privacy, trust managementand security policies. He is a recipient of theNSF CAREER Award.