FaceTrust: Collaborative Threat Mitigation Using Social Networks

Michael Sirivianos Xiaowei Yang Kyungbaek KimDuke University Duke University University of California,Irvine

msirivia@cs.duke.edu xwy@cs.duke.edu kyungbaek@uci.edu

Abstract

Unwanted traffic mitigation can be broadly classifiedinto two main approaches: a) centralized security infras-tructures that rely on a limited number of trusted moni-tors to detect and report malicious traffic; and b) highlydistributed systems that leverage the experiences of mul-tiple nodes within distinct trust domains. The first ap-proach offers limited threat coverage and slow responsetimes. The second approach is not widely adopted, partlydue to the lack of guarantees regarding the trustworthi-ness of nodes that comprise the system.

Our proposal, FaceTrust, aims to achieve the trust-worthiness of centralized security services and the widecoverage and responsiveness of large-scale collaborativethreat mitigation. FaceTrust is a large-scale peer-to-peersystem designed to rapidly propagate behavioral reportsconcerning Internet entities (e.g., hosts, email signaturesetc.). A FaceTrust node builds trust for its peers by au-diting their behavioral reports and by leveraging the so-cial network of FaceTrust administrators. A FaceTrustnode combines the confidence its peers have in their ownreports and the trust it places on its peers to derive thelikelihood that the entity is malicious (e.g. being a spambot).

The simulation-based evaluation of our approach indi-cates its potential under a real-world deployment: duringa simulated spam campaign, FaceTrust nodes character-ized 71% of spam bot connections as such with confi-dence greater than75%.

1 Introduction

The majority of the currently deployed Internet threatmitigation techniques rely on centralized infrastructuresand place trust on a small number of security authorities.For instance, email systems and browsers rely heavily ona few centralized IP [7] and web site [4,5] reputation ser-vices. End-users rely on software vendors to update theiranti-virus/malware tools or to release updates that patchtheir systems’ vulnerabilities.

Unfortunately, centralized services are often found tomaintain out-dated blacklists [42] or respond slower thanthe worm infection rate [36, 37], offering a rather largewindow of opportunity to attackers. Moreover, the van-

tage points of centralized services are limited in num-bers, but attacks launched using large botnets are becom-ing increasingly surreptitious. In those attacks, one mali-cious host may attack multiple domains, each for a shortperiod of time [27,41], reducing the effectiveness of ma-licious traffic detection with a small number of vantagepoints.

Motivated by this problem, researchers have proposedcollaborative worm containment systems [17, 61] andpeer-to-peer spam filtering platforms [58, 59] to achieverapid and reliable detection and suppression of unwantedtraffic. These early systems assume compliant behaviorfrom all participating peers, which is hardly true giventhe heterogeneity of the Internet. Compromised hostscontrolled by attackers may join the system, polluting thedetection mechanisms. In addition, honest peers may be-come compromised after they join the system.

We propose a collaborative peer-to-peer threat mitiga-tion system (FaceTrust) that uses social trust embeddedin online social networks (OSN) to defend against ma-licious peers. Each FaceTrust node disseminatesbehav-ioral reports, i.e. security alerts regarding Internet enti-ties, such as IP addresses, packet fingerprints, and emailsignatures that it observes to its peers (Section 3). Thegoal of the system is to ensure that the behavioral reportsreach the destination nodes faster than the threat itself,and that they are credible enough to warrant action bytheir receivers. Each FaceTrust node associates a trustscore to another FaceTrust node and uses this score toassess the trustworthiness of the behavioral reports orig-inated by the other node.

FaceTrust is designed to be a peer-to-peer system com-prising of nodes across different trust domains. Thelarge scale of the Internet inhibits a node from directlyassessing the trustworthiness of all participating nodes.However, in order for the system to be effective inmitigating numerous, heterogeneous, and fast-spreadingthreats, it must enable a FaceTrust node to interact witha large number of other FaceTrust participants, while be-ing aware of their trustworthiness.

To address this challenge, FaceTrust uses social trustto bootstrap direct trust assessments, and then employs alightweight reputation system to evaluate the trustworthi-ness of nodes and their behavioral reports (Section 3.3).Our insight is that each FaceTrust node will be admin-

istered by human administrators (admins), and nodesmaintained by trusted admins are likely to disseminatetrustworthy reports. Therefore, a FaceTrust node mayobtain a direct trust assessment with a number of nodeswith whom its admin has social relationships. Social re-lationships between admins can be obtained from mas-sive Online Social Network (OSN) providers, such asFacebook and MySpace. FaceTrust then uses a reputa-tion management system [23,34] to aggregate the nodes’collective experiences in order to enable one node toform opinions of another node’s trustworthiness despitethe lack of past history of interactions.

Reputation systems are known to be vulnerable to theSybil attack [21]. Sybil attacks subvert distributed sys-tems by introducing numerous malicious identities un-der the control of an adversary. Through the use of theseidentities the adversary acquires disproportional influ-ence over the system. To mitigate this attack, FaceTrustagain uses the social network to assess the probabilitythat a node is a Sybil attacker, i.e. itsidentity trust(Section 3.2) Each FaceTrust node’s identity is asso-ciated with its admin’s identity. The latter is verifiedthrough the social network using a SybilLimit-like tech-nique [55], which is shown to be effective in identifyingsybils among social network users.

Our design enables a FaceTrust node to use both theidentity trust and the reputation of another node to as-sess the overall trustworthiness of the other node’s be-havioral report. The originator of a behavioral report it-self also assigns a confidence level to the report, as traf-fic classification has a level of uncertainty. The trust-worthiness of a node and its confidence level in a reportdetermines whether a node should trust a report or ig-nore it. Trusted reports can be used for diverse purposes,depending on the FaceTrust node’s function. For exam-ple, email servers can use them to automatically filter outemail messages that originate from IPs that have beendesignated as spammers with high confidence. IDS sys-tems can use them to block packets that originate fromsuspicious IPs or have signatures that have been desig-nated as malicious.

We evaluate our design (Section 4) using a100K-nodesample of the Facebook social network. We first evalu-ate the effectiveness of our SybilLimit-like technique inmitigating Sybil attackers. Our results show that honestnodes have∼ 0.89 average identity trust, whereas Sybilnodes in clusters with more than 200 nodes have less than0.05 average identity trust. We also show that it is prac-tical for a typical centralized social network provider tosupport the proposed identity trust primitive. In addi-tion, we demonstrate through simulation that collaborat-ing FaceTrust nodes are able to suppress common typesof unwanted traffic in a reliable and responsive manner.Our simulations show that in a100K-node FaceTrust

Figure 1: FaceTrust architecture.

network with only10% of nodes having spam classi-fication capability, nodes with no local spam detectioncapability are able to identify71% of connections fromspammers with greater than75% confidence. In a simi-lar setting, where only10% of the nodes are able to clas-sify worms, behavioral reports that carry worm signa-tures are disseminated faster than the rate at which theworm spreads.

2 System Overview

In this section, we provide a high-level description of oursystem and the security challenges it addresses.

2.1 FaceTrust Components

Figure 1 depicts FaceTrust’s architecture. At a high-level, the FaceTrust system comprises the followingcomponents: 1) human users that administer networkeddevices/networks (admins) and join a social network;2) end systems that are administered by specific adminsand participate in monitoring and reporting the behaviorof entities (FaceTrust nodes); 3) behavioral reports sub-mitted by FaceTrust nodes concerning entities they ob-serve; 4) direct trust updates made available by FaceTrustnodes reporting their perceived trustworthiness of theirpeers; and 5) a distributed repository that receives andstores behavioral reports and trust updates.

The same administrator that administers a FaceTrustnode also administers a group of applications that in-terface with the node. These applications may beequipped with Internet traffic monitoring and character-ization functionality, i.e., they are able to detect emailspam, port scanning traffic, DoS activity etc. Exam-ples of applications with such monitoring and charac-

terization functionality are honeypots [47,51], backscat-ter/darknet traffic detection infrastructure [13, 47] andworm detection and containment systems [19, 45, 50].They may also be applications that utilize concrete de-scriptions of unwanted traffic to filter it out, such as emailfilters or IDS systems.

2.2 Behavioral Reports

A traffic characterization application uses theReport(entityID, action, confidence) callof the FaceTrust node RPC API to feedback its observedbehavior of an entity. The first argument identifiesthe source of the threat (e.g. an IP address, a packetfingerprint etc.) The second argument determines thetype of security threat the report concerns (e.g. “is aworm”, “is a spam bot” etc), and the third argument isthe confidence with which the application is reportingthat the specified entity is performing the specified ac-tion. The latter takes values in0% to 100% and reflectsthe fact that in many occasions traffic classification hasa level of uncertainty. For example, a mail server thatsends both spam and legitimate email may or may notbe a spamming host.

In turn, the FaceTrust node submits a correspondingbehavioral report to the repository to share its experiencewith its peers. For example, if a nodei’s spam analysisindicates that half of the emails received from host withIP I are spam,i reports:

[behavioral report] I, is spam bot, 50%

In addition, FaceTrust nodes are able to revoke behav-ioral reports by updating them. If for example at alater time, i determines that no spam originates fromI, it sends a new behavioral report in which it updatesthe confidence value from50% to 0%. Each reportis signed by the reporting FaceTrust node’s public key(Section 3.1) for authentication and integrity.

2.3 Trusting an Entity

Each FaceTrust node assigns apeer trustvalue to each ofits peers in the network. This trust value determines thetrustworthiness of the peer’s behavioral reports. Thepeertrust is determined using two dimensions of trust: a)re-porter trust; and b)identity trust. We describe these twodimensions below. The receiver of a behavioral reportderives its confidence in the correctness of the receivedreport from the behavioral report’s confidence and thepeer trust.

FaceTrust nodes collectively computereporter trustvalues by employing a reputation management mecha-nism. This mechanism relies on FaceTrust nodes veri-fying each other’s behavioral reports to derive individual

direct trustvalues (Section 3.3). If a nodei is able toverify the behavioral reports of nodej it can determinea direct trust valuedij . The FaceTrust nodes share thesevalues with other FaceTrust nodes by exchangingdirecttrust updates. For reasons of scalability and efficiency,a node considers the behavioral reports of only a (possi-bly random) subsetV (including itself) of all the nodesin the FaceTrust network. Consequently, nodes submitand retrieve direct trust updates only for nodes inV . Werefer toV as a node’sview.

FaceTrust also relies on the fact that nodes comprisingInternet systems such as email servers, honeypots, IDSetc are administered by human admins. These humanusers maintain accounts in online social networks (OSN).FaceTrust leverages OSNs in the following two ways: a)it defends against Sybil attacks [21] by exploiting the factthat OSNs can be used for resource testing, where the testin question is a Sybil attacker’s ability to create and sus-tain acquaintances. Depending on the result of the test,the OSN provider assigns anidentity trustvalue to theadmin; and b) It initializes thedirect trustvalues in theabsence of prior interactions between FaceTrust nodes,by considering the trust that is inferred by associationsin the social network of administrators.

Finally, an application can use theGetTrust(entityID, action) call of the FaceTrustnode RPC API to obtain a trust metric that correspondsto the likelihood of an entityID performing the specifiedmalicious action. The FaceTrust node derives this metricby aggregating behavioral reports regarding entityID.These behavioral reports are weighted by the reportingnode’speer trust.

2.4 Security Challenges

FaceTrust is a collaborative platform aiming at suppress-ing malicious traffic. As such, it is reasonable to assumethat FaceTrust itself will be targeted in attempts to dis-rupt its operation. FaceTrust is an open system, mean-ing that any admin with a social network account and adevice can join. Due to its highly distributed and opennature, it faces the following challenges:False Behavioral Reports.Malicious FaceTrust nodesmay issue false or forged reports aiming at reducing thesystem’s ability to detect unwanted traffic or disruptinglegitimate Internet traffic.Behavioral Report Suppression or Alteration.We im-plement the distributed repository for behavioral reportsas a Distributed Hash Table (Section 3.5). Consequently,the system is vulnerable to attacks on DHT routing [18]aiming at preventing legitimate nodes from retrieving im-portant behavioral reports. In addition, since the reportsmay be stored by malicious nodes such nodes may at-tempt to alter their content.

False Direct Trust Updates.To address false behavioralreports, FaceTrust employs a reporter reputation systemto determine the amount of trust that should be placedon each user’s reports. However, the reputation systemitself is vulnerable to false reporting as malicious nodesmay send false or forged direct trust updates.Sybil Attack. An adversary may attempt to create mul-tiple FaceTrust identities aiming at increasing its abil-ity to subvert the system using false behavioral reportsand direct trust updates. Defending against Sybil attackswithout a trusted central authority is hard. Many decen-tralized systems try to cope with Sybil attacks by bind-ing an identity to an IP address. However, malicioususers can readily harvest IP addresses through BGP hi-jacking [41] or by commanding a large botnet.

3 FaceTrust Design

In this section we describe the design of our system.

3.1 OSN Providers as Certification Au-thorities

For an open system such as FaceTrust to operate reliably,node accountability in the form of node authenticationand prevention of Sybil attacks is of the utmost impor-tance.

Existing certification authorities are not suitable foropen, large scale P2P architectures because they requireusers to pay a certification fee (∼$20 for class 1 certifi-cate). In addition to CAs being expensive, they currentlyrepresent a monopoly for a very important Internet prim-itive, and we consider breaking this monopoly beneficial.

We propose to leverage existing OSN repositoriesas inexpensive, Sybil-mitigating certification authorities.OSNs are ideally positioned to perform such function be-cause using SybilLimit-like techniques (see Section 3.2)they can determine the amount of confidence one canplace on a node’s identity. We refer to this confidenceas identity trust. They are able to perform inexpensiveresource tests by analyzing the centrally maintained so-cial graph.

Each node that participates in FaceTrust is adminis-tered by human users that have accounts with OnlineSocial Network providers. The system needs to ensurethat each user’s social network identity is closely cou-pled with its FaceTrust node. To this end, FaceTrust usesan OSN application as a front-end to the social networkthat the human user has joined.

Every FaceTrust admin obtains a public/private keypair that is associated with its social network identity.It obtains its public key in the form of a public key cer-tificate that is signed by the trusted OSN provider (e.g.

signed with Facebook’s public key). This certificationmechanism closely resembles a typical X.509 PKI infras-tructure, in which the hierarchy of certificates is alwaysa top-down tree, with a root certificate at the top, repre-senting a CA that is so central to the scheme that it doesnot need to be authenticated by some trusted third party.

The certifying OSN provider can either be the providerof existing popular OSN (e.g. Facebook) or a third-party OSN application (e.g. Facebook application [3])provider. In the first case, the popular OSN provider hasaccess to the complete social network, and augments theOSN application API to allow applications to query theidentity trust of the OSN’s users. OSN providers areincented to provide this service because it adds valueto their service, making the service more attractive tosubscribers. In the second case, a third-party deploysFaceTrust as an OSN application and has access only tothe social network of users using FaceTrust. Althoughthe FaceTrust-only social network is not as complete asthe OSN provider’s one, the fact that it is smaller makesits analysis less computationally expensive. In addition,it does not require the adoption of the service by the OSNprovider. For ease of exposition, for the rest of the paperwe refer to both the popular OSN provider and the third-party OSN application provider asOSN provider.

To defend against forged or falsifiedbehavioral reportsand direct trust updates, FaceTrust nodes sign messagesthat originate from them using their private key. Whena nodei exchanges direct trust updates with a nodej, orreceives behavioral reports that are claimed to originatefrom j, i acts as follows. Ifi does not havej in its view,it obtainsj’s public key certificate fromj and verifiesit using the OSN provider’s certificate. After verifyingj’s public key,i verifies the signed direct trust update orbehavioral report that is claimed to originate fromj.

3.2 Determining the Identity Trust

There is typically one-to-one correspondence betweena real user’s social network identity and its real iden-tity. Although, malicious users can create many iden-tities, they can establish only a limited number of trustrelationships with real humans. Thus, groups of Sybilattackers are connected to the rest of the social graphwith a disproportionally small number of edges. Thefirst works to exploit this property was SybilGuard andSybilLimit [55, 56], which bound the number of Sybilidentities using a fully distributed protocol.

Based on a similar concept, FaceTrust’s Sybil detec-tion algorithm determines the strength of a FaceTrustuser’s identity. This algorithm is executed solely by theOSN provider over its centrally maintained social graphI. An admin’s i identity is considered weak if it hasnot established a sufficient number of real relationship’s

over the social network. Upon being queried by an adminv, the OSN provider returns a value in[0.0, 1.0], whichspecifies the confidence of the provider that a specificnodes is not participating in a Sybil attack, i.e. the prob-ability thats is not part of a network of Sybils.

First, we provide some informal background on thetheoretical justification of SybilGuard and SybilLimit. Itis known that randomly-grown topologies such as so-cial networks and the web are fast mixing small-worldtopologies [11, 25, 53]. Thus in the social graphI withn nodes, a walk ofΘ(

√n log n) steps containsΘ(

√n)

independent samples approximately drawn from the sta-tionary distribution. When we draw random walks froma verifier nodev and the suspects, if these walks remainin a region of the network that honest nodes reside, bothwalks drawΘ(

√n) independent samples from roughly

the same distribution. It follows from the generalizedBirthday Paradox [56] that they intersect with high prob-ability. The opposite holds if the suspect resides in aregion of Sybil attackers that is not well-connected to theregion of honest nodes.

SybilGuard replaces random walks with “randomroutes” and a verifier node accepts the suspect if randomroutes originating from both nodes intersect. In randomroutes, each node uses a pre-computed random permu-tation as a one-to-one mapping from incoming edges tooutgoing edges. We refer to this random permutation asrouting table. As a result, two random routes entering anhonest node along the same edge will always exit alongthe same edge (“convergence property”). This propertyguarantees that random routes from a Sybil region that isconnected to the honest region through a single edge willtraverse only one distinct path, further reducing the prob-ability that a Sybil’s random routes will intersect witha verifier’s random routes. SybilLimit [55] is a near-optimal improvement over the SybilGuard algorithm. InSybilLimit, a node accepts another node only if randomroutes originating from both nodes intersect at their lastedge. For two honest nodes to have at least one inter-sected last edge with high probability, the required num-ber of the random routes from each node should be ap-proximatelyr = Θ(

√m), wherem is the number of

edges inI. The length of the random routes should bew = O(log n).

With FaceTrust’s SybilLimit-like technique the OSNprovider computes an identity trust score for each nodes in the social graphI. At initialization time, the OSNprovider selectsl random verifier nodes. It also creates2r independent instances of pre-computed random per-mutation as a one-to-one mapping from incoming edgesto outgoing edges (routing table). The firstr routing ta-bles are used to draw random routes from suspect nodess and the restr routing tables are used to draw randomroutes from the verifier nodesv. SybilLimit uses dis-

tinct routing tables for verifiers and suspects in order toavoid undesirable correlation between the verifiers’ ran-dom routes and the suspects’ random routes. For eachs,the OSN provider runs the SybilLimit-like algorithm isas follows:

1. For each of thel verifiersv, it picks a random neigh-bor of v. It draws along the random neighborsrrandom routes of lengthw = O(log n), for each in-stance of ther routing tables, wheren is the numberof nodes inI. It stores the last edge (tail) of eachverifier random route.

2. It picks a random neighbor ofs and draws along itr random routes of lengthw = O(log n), for eachinstance of the nodes’ routing tables. It stores thelast edge (tail) of each suspect random route. Werefer to steps(1) and(2) of the algorithm asrandomrouting.

3. For each verifierv, if one tail froms intersects onetail from v, that verifierv is considered to “accept”s. We refer to this step asverification.

4. It computes the ratio of the number of verifiers thataccepts over the total number of verifiersl. Thatratio is the computed identity trust scoreids.

Nodes query the OSN provider for the identity trustof their peers. The OSN provider performs the abovecomputations periodically and off-line to accommodatefor topology changes. The OSN provider stores the resultof this computation for each node as a separate attribute.

3.3 Determining the Reporter Trust

Malicious nodes may issue false behavioral reports tomanipulate the trust towards entities. In addition, mis-configured nodes may also issue erroneous reports.FaceTrust can mitigate the negative impact of incorrectbehavioral reports by assigning higher weights to reportsobtained from more trustworthy FaceTrust nodes. Con-ceptually, each FaceTrust nodei maintains a reportertrust valuertij to every other FaceTrust nodej in itsview, j ∈ Vi. This trust score corresponds to nodei’sestimation of the probability that nodej’s reports are ac-curate. It is obtained from three sources: trust attainablefrom online social networks, direct behavioral report ver-ification, and transitive trust.

First, FaceTrust relies on the fact that FaceTrust nodesare administered by human users. Competent and benignusers are likely to maintain their nodes secure, and pro-vide honest and truthful reports. The trust on the compe-tency and honesty of human users could be obtained viasocial networks. FaceTrust admins maintain accounts in

online social networks. An admini tags her acquain-tance adminj with a social trust scorestij in [0.0, 1.0]based on her belief onj’s ability to manage her FaceTrustnode(s). This value is used to initialize a direct trust scorebetween two FaceTrust nodesi andj: dij = stij .

Second, a FaceTrust nodei dynamically updates thedirect trustdij by comparing behavioral reports submit-ted by the nodej with its own reports. A nodei mayverify a report from a nodej for an entitye, if i hasalso generated a recent report with respect to the sameentity. i may also probabilistically choose to observee solely for the purpose of verifying reports of anothernodej. The portion of the received behavioral reportsthat the FaceTrust nodes verify is a tunable parameter.Intuitively, if i andj share similar opinions one, i shouldhave a high trust inj’s reports. Letvk

ij be a measure ofsimilarity in [0, 1.0] betweeni andj’s kth report. A nodei may updates its direct trust toj using an exponentialmoving average:

dk+1

ij = α ∗ dkij + (1 − α) ∗ vk+1

ij (1)

As i verifies a large number of reports fromj, the di-rect trust metricdk

ij gradually converges to the similarityof reports fromi andj.

By updatingdij and making it available for retrievalto other nodes,i enables its peersj ∈ Vi to build theirFaceTrust reporter trust graphTj(Vj , Ej). The reportertrust graph of a nodei consists of only the nodes in itsviewVi, and its directed edge setEi consists of the directtrustduv for eachu, v ∈ Vi. If a nodeu has not releaseda direct trust update for a nodev, duv is treated as beingequal to0.0.

Third, a FaceTrust nodei incorporates direct trust andtransitive trust to obtaini’s overall trust toj: rtij . Dueto the large number of FaceTrust nodes, the admin of aFaceTrust nodei may not tag a social trustsij to theadmin of a nodej. Moreover, due to the variety andlarge number of observed entities, nodesi andj may nothave encountered the same entities and are therefore un-able to directly verify each other’s reports. Furthermore,i can further improve the accuracy of its trust metricfor j by learning the opinions of other FaceTrust nodesaboutj. The overall reporter trustrtij can be obtained asthe maximum trust path in nodei’s reporter trust graphTi(Vi, Ei), in which each edgeu → v is annotated bythe direct trustduv. That is, for each pathp ∈ P , whereP is the set of all paths between nodesi andj:

rtij = maxp∈P (Πu→v∈pduv) (2)

We use the maximum trust path because it can be effi-ciently computed with Dijkstra’s shortest path algorithmin O(|E| log |V |) time for a sparseT . In addition, ityields larger trust values than the minimum or average

trust path, resulting in faster convergence to high confi-dence regarding the actions entities perform. Last, it mit-igates the effect of misbehaving nodes under-reportingtheir trust towards honest nodes.

If Ti is very sparse (e.g.|Ei| being smaller or slightlylarger than|Vi|), a nodei may not be able to derivemeaningful trust values for its peers inVi using the re-port trust graphTi(Vi, Ei). To remedy this situation,Vi

includes the nodes with whichi is socially acquaintedand has assigned social trust values to. In addition, thenode augmentsTi with directed edges from itself towardsa pre-trusted setN of reliable nodes. The size of thepre-trusted and is almost the same for all nodes in theFaceTrust network. Nodes become aware of those reli-able nodes either via word of mouth over the social net-work or by querying the OSN provider. Nodes do notsend direct trust updates for these pre-trusted nodes.

3.4 Determining the Trust for an Entity

As mentioned above, a FaceTrust nodei may receivemultiple behavioral reports originating from multiplenodesj ∈ V and concerning the same entitye for thesame actiona. Each report is marked with a level of con-fidencecj of the reporterj. Thus,i needs to aggregatethe behavioral reports to determine an overall confidenceGetTrust(e,a) thate will perform the actiona.

When an admini receives multiple reports concern-ing the same entity and action pair(e, a), it derives theoverall trustGetTrust(e,a) weighing the behavioralreports’ confidence by the peer trust of their reporters.

GetT rust(e, a) =Σj∈Vi

rtij idj cj(e, a)

Σj∈Virtij idj

(3)

3.5 FaceTrust Repository

A node can exchange behavioral reports and direct trustupdates with any other node in the FaceTrust network re-gardless of whether the admins of the nodes are acquain-tances in the social network. With this design choice,we ensure that behavioral reports and direct trust updatesreach the interested nodes on time, improving the threatcoverage of our system. We also enable users that are notwell-connected in the social network to peer with othertrustworthy nodes.

Under typical deployment scenarios and for varyingtypes of unwanted traffic, nodes often exchange behav-ioral reports about many malicious entities. The fre-quency with which behavioral reports and trust updatesare submitted and retrieved would impose a significantscalability challenge to a centralized FaceTrust reposi-tory. Therefore, although we maintain the FaceTrust so-cial network in a centralized manner, we design a dis-

Figure 2:Example of the operation of a small FaceTrust network.

tributed repository to which nodes submit to and retrievefrom behavioral reports and direct trust updates.

Our distributed repository consists of two portions,one for behavioral reports and one for direct trust up-dates. The portion of the repository tasked with main-taining behavioral reports is implemented as a a Dis-tributed Hash Table, e.g Chord [48]. Nodes form a DHTto store and retrieve behavioral reports updates concern-ing nodes in their view. When a node queries for Be-havioral reports it is interested on the reports for a sin-gle entity/action pair. These reports are sent by multiplenodes, thus for efficiency it is reasonable to index(key)them based on the hash of the concatenation of the en-tity’s ID (e.g IP) and the action description. When aFaceTrust nodei encounters a specific entity, it queriesthe DHT for all the behavioral reports that involve theentity and the action. Once it locates the node that storesthose behavioral reports it asks the node for those reportsthat originate from nodes inVi.

On the other hand a node needs to retrieve all the directtrust updates involving all the nodes in its view. Thus itis reasonable to index the updates by the node that issuesit and store them at the issuing node. A nodei needs toexplicitly query for the existence of an update involvingall node pairs in its view. Thus every time intervalD, anodei directly requests from each nodej ∈ Vi to replywith its current non-zero direct trust valuesdjv towardsother nodes in the network. If the difference between thecurrent direct trust metricdjv and the lastdjv i retrievedfrom j is greater thanǫ, j includes this update in his replyto i’s request for direct trust updates. The constantǫ is

used to ensure that the nodes do not incur the overhead ofcommunicating the update if it is not sufficiently large.

Employing a DHT in an adversarial environmentposes several security challenges [18, 46]. One of thesechallenges is the “secure node ID assignment”, which isaddressed in our system by the randomized generation ofpublic/key pairs. This results in nodes not being able todecide what their Chord identifier is. The Sybil attack isaddressed through the use of our OSN Certification Au-thorities; nodes with very low identity trust are barredfrom participating in the DHT. Nodes with high identitytrust exclude nodes with low one from their finger tables,e.g. nodes with identity trust below 0.1 cannot join thering.

Chord’s inherently constraint routing table and securenode ID assignment ensures secure routing table main-tenance [18]. This means that each constrained rout-ing table (and neighbor set) has an average fraction ofonly f random entries that point to nodes controlled bythe attacker, wheref is the fraction of compromisednodes. To further counter attacks on DHT routing weemploy a form of redundant routing [18]. We use multi-ple DHT map functions (e.g. multiple Chord rings usingdistinct hash function seeds). A node stores behavioralreports that correspond to its ID under all map functions.It also maintains a distinct forwarding(finger) table foreach map function. This technique defeats behavioralreport suppression attacks (Section 2.4) through redun-dancy. The attacker is unlikely to control all the nodesthat store the behavioral reports or at least one node inthe forwarding path for all rings.

A nodei can retrieve the random subset of nodes inits viewVi either from the OSN provider which may actas a tracker of online FaceTrust nodes, or by exchangingcontact lists with other nodes.

3.6 FaceTrust Operation Example

Figure 2 depicts an example of the operation of a smallFaceTrust network. The network includes a node taskedwith checking incoming packets for malicious code,FaceTrust node 3. That node has no inherent packetclassification functionality, thus it relies on the othertwo nodes, 1 and 2, for early warning about malicioustraffic coming his way. Node 1 is an EarlyBird [45]network-layer worm detector, which in this example isable to identify and generate the fingerprint (sl) of ob-served Slammer worm packets and report that this finger-print is worm (wm) with confidencec1(sl, wm) = 50%.Node 2 is a Vigilante [19] end-to-end worm detector,which is able to run the malicious code within a sandboxand analyze it. Thereby, node 2 reports with confidencec1(sl, is wm) = 100% confidence that the fingerprint ofthe slammer packet is a worm.

Node 3 maintains the depicted reporter trust graph, de-rived from his5-node view. This view includes nodes 1and 2, which send the depicted behavioral reports. It alsoincludes nodes 4 and 5, which do not send any reports inthis example. The weighted directed edges in the graphcorrespond to the direct trust between the peers in node3’s view. From the reporter trust graph and Equation 2,the maximum trust path between nodes 3 and 1 traversesnodes 5 and 1 yieldingrt31 = 0.4. The maximum trustpath between 3 and 2 traverses nodes 5, 4 and 2 andyields reporter trustrt32 =∼ 0.65. The identity trust ofnodes 1 and 2 has been computed by the OSN providerto beid1 = 0.9 andid2 = 0.8, respectively. We can nowuse Equation 3 to compute the trustGetT rust(sl, wm)that the IDS beside node 1 places on FaceTrust to cor-rectly identify the slammer packet as worm:

c1(sl, wm)rt31id1 + c2(sl, wm)rt32id2

rt31id1 + rt32id2

= 0.82

4 Evaluation

In this section we evaluate FaceTrust’s ability to mitigateunwanted traffic under varying threat scenarios. First,we evaluate our identity trust mechanism in terms of itsability to mitigate Sybil attacks and its computationalcost. Second, we simulate the operation of a FaceTrustP2P network that aims at proactively identifying spamsources. Third we proceed with simulating the opera-tion of a FaceTrust P2P network charged with the taskof identifying a containing the Slammer worm. Last

we demonstrate the significance of FaceTrust admins ap-propriately setting the social trust towards their acquain-tances for rapid convergence of the system to correct trustvalues for reporters and entities.

4.1 Sybil-Resistance Evaluation

We experimentally evaluate our identity trust metric. Wecrawled Facebook [2] to gain an initial insight on howeffective SybilLimits is in detecting Sybil attacks in so-cial networks that are likely to resemble the network ofFaceTrust admins. Unlike other online social networkingsites, Facebook may more closely resemble the networkof trust between FaceTrust admins: users do not tend toestablish an excessive number of friend relationships andidentities are stronger: a) initially it was open only tocollege and high school students with verifiable emails;and b) its EULA states clearly that they consider creatingfake identities as violation of their terms of use.

Our crawled Facebook graph consists of more than51 million nodes, and we scaled it down to a100K-node single connected component graph using the “forestfire” [29] sampling technique. The average hop count ofthis graph is 6.11 and the diameter of the graph is 19.The number of total undirected edges is 930680 and theaverage degree of node is 18. We assume that the currentFacebook graph does not include a substantial number ofSybils, therefore we consider those 100K nodes to repre-sent the honest region of the social graph.

4.1.1 Identity Trust Evaluation

0

0.01

0.02

0.03

0.04

0.05

0.06

0.07

0.08

0 200 400 600 800 1000 1200 1400

Avg S

ybil

ide

ntity

tru

st

# of nodes in Sybil cluster

Figure 3:Average identity trust of all Sybil nodes as a function of thenumber of nodes in the Sybil cluster with one attack edge. In contrast,the average identity trust of honest nodes nodes is∼ 0.89.

We now evaluate the effectiveness of FaceTrust’sSybilLimit-like technique in assigning low identity trustvalues to Sybil nodes. In our evaluation, Sybil attack-ers form a single well-connected cluster. This cluster hasa random graph topology under which Sybil nodes haveaverage degree14. The Sybil cluster is connected to the

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

0 50 100 150 200 250 300

Avg

Syb

il id

en

tity

tru

st

# of attack edges from the 1000-node Sybil cluster

Figure 4: Average identity trust score of all Sybil nodes as a func-tion of the number of attack edges in the Sybil cluster with 1000 Sybilnodes.In contrast, the average identity trust of honest nodes nodes is∼ 0.89.

honest region throughattack edgesbetween a Sybil nodeand an honest node. We vary the number of nodes in theSybil cluster from 100 up to 1500, as well as the numberof attack edges from 1 up to 300. We set the lengthw ofrandom routes equal to17, the number of routing tablesr at each node equals2600 and the number of verifiersl equal to100. With these settings, the average identitytrust of 1000 randomly chosen honest nodes is0.89 with0.10 standard deviation.

In Figure 3, we observe that as the number of nodesin a Sybil cluster increases, the average identity trust ofSybil nodes decreases and stabilizes at around0.01. Thereason is that as the Sybil cluster increases in size, theprobability that random routes from Sybil nodes crossattack edges decreases. Figure 4 shows that when thenumber of attack edges increases, the average identitytrust of Sybil nodes in the cluster increases logarithmi-cally. The reason is that the probability that randomroutes from Sybil nodes and honest nodes cross attackedges increases.

The above results demonstrate that the SybilLimit-like technique assigns much lower identity trust to Sybilnodes than to honest nodes, when the number of attackedges is not too high. The low identity trust for Sybilnodes renders substantially less effective Sybil attacks inwhich the misbehaving nodes are not well-connected tothe social graph.

4.1.2 Cost of Identity Trust Computation

The identity trust of nodes is computed centrally by theOSN provider, and it is critical for the scalability ofthe system that the cost of this computation is not pro-hibitively expensive. Table 1 shows the required compu-tation time to derive the identity trust for each node inour 100K-node sample of the Facebook social network.We profile the identity trust computation implementedin C++ on a Intel Pentium D, 3.40GHz CPU, 2048KB

Creating one permutation table 0.815699Random Routing from an honest suspect0.049568Random Routing from a Sybil suspect 0.027517Random Routing froml verifiers 5.199869Verification for an honest suspect 0.093293Verification for a Sybil suspect 0.237826

Table 1:Times (sec) for computing the identity trust of a suspect ina 100K node social network with the SybilLimit-like technique.

cache and 2GB RAM machine, running Linux 2.6.25-2-68. The identity trust computation consists of three parts,all of which are performed off-line: a) the cost of creat-ing the routing tables at each node; b) the cost of drawingrandom routes from the suspect and the verifiers (randomrouting); c) the cost of determining intersections betweenthe verifiers’ and the suspects’ tails(verification).

The cost of creating one permutation table increaseslinearly with the number of nodes, because the systemneeds to explore all nodes generating permutation tables.The number of permutation tables for the SybilLimit-like technique isr which should beΘ(

√m), wherem is

the number of edges in the social graph. Consequently,the total cost of creating all permutation tables for theSybilLimit-like technique isΘ(n ∗ √

m). Because ofthe linear increase in computation time, we need to pre-compute all required permutation tables for the target so-cial network. If we assume that the size of the target so-cial network is 40 million with average node degree20,r has to be approximately 55KB and 8.8MB storage pernode is required. Generally, the social network updatesslowly, thus this type of precomputation is practical.

The number of traversed edges during random routingfrom a node isΘ(w ∗ r) and its cost isΘ(log(n) ∗√m),wheren is the number of nodes in the social graph. Interms of scalability, as the size of social network in-creases toR ∗ n from n, this cost increasesΘ(log(R ∗n)/log(n) ∗

√R) times. With a 40-million-node so-

cial network, the random routing from an honest sus-pect takes approximately 1.4 seconds. We can also pre-compute the random routing and store2r tails, r for asuspect and anotherr for a verifier. The precomputationof random routing for a 40-million-node social networkneeds 440KB storage per node.

The verification comparesr tails of a suspect withrtails of l verifiers and its cost in our implementation isΘ(l ∗ log(

√m) ∗ √

m). Similar to random routing, thecost of the verification increasesΘ(log(r∗

√R)/log(r)∗√

R) times, when the size of the social network increasesR times. With a 40-million-node social network the costof the verification for an honest node and a Sybil nodewould be approximately 2.6 seconds and 6.6 seconds, re-spectively. In the case of an honest node, there are manypossible intersections and a verifier can find one of them

relatively promptly. But a Sybil node has very few inter-sections and the system typically exhausts all tails with-out finding any.

Since the computation of identity trust is performedoff-line and consists of simple computing jobs, its costcan be greatly reduced by standard parallel computingtechniques. From the above, we conclude that OSNproviders that have the computational and hosting ca-pability to host million of users are also capable of ef-ficiently performing this computation using their highlyscalable infrastructure.

4.2 Reporter Trust Evaluation

We now evaluate FaceTrust’s effectiveness in managingthe trustworthiness of reporters and their behavioral re-ports.

We use the SimPy 1.9.1 [38] simulation package tosimulate FaceTrust’s operation under spam email andworm attack scenarios. We simulate all the protocol op-erations described in Section 3 as well as an iterativeChord DHT with 3 rings for redundancy. We do not sim-ulate any physical, network or transport layer events (e.g.congestion and packet loss). We repeat each simulation3 times and we average results over the repetitions.

Nodes verify each other’s behavioral reports and up-date their direct trust using the exponential moving av-erage (Equation 1). We compute the similarity betweenreports in this evaluation as follows. Nodei receives thekth behavioral report from nodej that involves an en-tity action pair(e, a) that both nodes have observed andto which nodei andj have assigned confidenceci(e, a)andcj(e, a) respectively. Nodei computes the similarityvk

ij with nodej as follows:

vkij =

min(ci(e, a), cj(e, a))

max(ci(e, a), cj(e, a))(4)

E.g. if nodei has sent a behavioral report concern-ing a packet signature being a worm with50% confi-dence and nodej has sent a behavioral report concerningthe same signature being a worm with60% confidence,vij = 50/60.

We evaluate our technique for varying view sizes|V |.The view of a node is a subset of the 100K-node sam-pled Facebook network described in Section 4.1. A nodesets its direct trust towards nodes with which it is con-nected in the sampled Facebook network equal to a ran-dom value in[0.0, 1.0]. In addition, the size of the pre-trusted set|N | (Section 3.3) is set equal to20 and the so-cial trust assigned to the pre-trusted nodes is equal to0.9.The view of a node consists of its social acquaintances,the pre-trusted set and a random subset of the samplednetwork.

4.2.1 Spamming Bots Simulation

0

20

40

60

80

100

200 400 600 800 1000

De

tecte

d s

pa

m c

on

ne

ctio

ns (

%)

View Size (number of nodes)

>50% confident is spam>75% confident is spam

Figure 5: The percentage of spam connections that are detected inthe absence of misbehaving FaceTrust nodes as a function of|V |. Con-nections for which a node is50% or 75% confident that are spam areconsidered detected.

0

20

40

60

80

100

200 400 600 800 1000

De

tecte

d s

pa

m c

on

ne

ctio

ns (

%)

View Size (number of nodes)

>50% confident is spam>75% confident is spam

Figure 6:The percentage of spam connections that are detected in thepresence of misbehaving FaceTrust nodes as a function of|V |. Con-nections for which a node is50% or 75% confident that are spam areconsidered detected.

With this evaluation, we demonstrate FaceTrust’s abil-ity to suppress one of the most prevalent types of Internetunwanted traffic: spam email. We simulate the behaviorof a spamming botnet as it spams100K nodes (emailservers) that belong in a FaceTrust network. The goal ofthe simulated FaceTrust network is to promptly identifyspamming IPs and reject connections from them.10Knodes in the FaceTrust network have the ability to char-acterize spam upon receiving it, e.g. by subscribing toa commercial email reputation service such as TrendMi-cro [8]. We refer to these10K nodes ashonest nodes.We refer to the rest90K nodes asregular nodes. Regularnodes cannot detect spam and cannot verify the behav-ioral reports of other nodes. They rely on honest nodesto warn them about spamming bots.

We draw the simulated spamming botnet behavior par-tially from [41] and [54]. 1000 spamming bots senduniformly to all IP addresses over the course of1200sec. All spamming bots start to send emails at ran-dom instances within the first10 minutes of the simu-

0

200

400

600

800

1000

1200

0 200 400 600 800 1000 1200

Sp

am

co

nn

ectio

ns p

er

se

c

time (sec)

total spam connections>50% confident is spam>75% confident is spam

Figure 7:The number of spam connections per second that are char-acterized as such (true positives) as a function of time, in the presenceof misbehaving FaceTrust nodes. We also depict the total number ofspam connections. Connections for which a node is50% or 75% con-fident that are spam are considered detected.

lation, since spam campaigns are found to be clusteredin time [42]. Spamming bots establish 3 connections persecond [54]. The parameterα of Equation 1 is set equalto 0.4. The parameterǫ (Section 3.3) is set equal to0.2.The size of the pre-trusted set is equal to20. Lastly,FaceTrust nodes retrieve direct trust updates regardingnodes in their view everyD = 20 secs. (Section 3.5).

750 of the spamming bots connect to randomly se-lected nodes for120 sec. We call these spammersephemeral.The rest of the bots persist for until the end ofthe simulation, and we refer to them as persistent. Spam-mers never attempt to connect to an already visited node.

A node that receives an SMTP connection issues aGetTrust() call, which entails the retrieval of rele-vant behavioral reports submitted by nodes in its view,and computing the trustworthiness of those nodes (Sec-tions 3.3, 3.4). Honest nodes update the direct trust oftheir peers as soon as they verify their behavioral reports(Equation 1). They issue aReport() call to submit a be-havioral report about a spamming host with100% confi-dence as soon as they receive an SMTP connection fromthat host. Nodes use the maximum trust path to deter-mine their transitive trust with other nodes in their view(Equation 2).

Figure 5 reports the percentage of spam connectionsthat are perceived as such by the regular FaceTrust nodesthroughout the duration of the spam campaign. It is pre-sented as a function of the FaceTrust nodes’ view sizeV .A spamming connection is considered detected if the reg-ular node that receives it considers the requesting node aspam bot with greater than50 or 75% confidence.

In our simulation, on average a node is spammed byapproximately12 distinct spam hosts. We observe thatfor view size|V | = 1k, the network is able to reject71%of the spam connections if nodes reject connections fromnodes that are perceived as spam bots with75% confi-dence. The speed with which confidence regarding spam

bots propagates through the network depends on the sizeof the view: the more nodes a nodei has in its view,the larger is the probability that a node that has detectedand reported a spam bot earlier is includedi’s view. Onaverage for|V | = 1K, at the end of the simulation aFaceTrust node has0.81 trust towards honest nodes.

We also observe that for small-sized views, e.g.|V | =100, the system is ineffective in rejecting spam becausethe probability that another node in the view has encoun-tered the same threat (spamming bot) and is able to offeran early warning is substantially reduced. This obser-vation motivates our design choice not to limit a node’sview to comprise only its social acquaintances.

In Figure 6, spamming bots are also misbehavingFaceTrust nodes, which claim1.0 direct trust for mis-behaving nodes in their view. Misbehaving FaceTrustnodes discover honest nodes for which to report nega-tive direct trust by receiving their behavioral reports onknown spammers. In addition, misbehaving FaceTrustnodes send behavioral reports for all the spam sources,claiming 0% confidence that they are spammers. Fur-thermore, misbehaving FaceTrust nodes refuse to storenegative behavioral reports regarding spamming hosts orforward DHT queries that involve them.

The1K misbehaving nodes correspond to misconfig-ured honest nodes or nodes that were compromised aftertheir users joined the social network and established trustrelationships. Thus, they are well-connected in the so-cial network, being trusted by their pre-existing acquain-tances. They do not correspond to a botnet that joins theoverlay and attempts to manipulate it, as such bots wouldbe unable to establish friend links, resulting in them hav-ing very low identity trust. Thus, their influence wouldbe substantially diminished (Section 4.1.1).

In this simulation, a misbehaving node is able to iden-tify all honest nodes in its view, the number of which ison average∼ 100 for |V | = 1K. ForV = 1K, a noderetrieves on average∼ 3 behavioral reports that originatefrom honest nodes in its view and∼ 9 behavioral reportsoriginating from misbehaving nodes. At the end the sim-ulation, a FaceTrust node has0.81 average trust towardshonest nodes and0.04 average trust towards misbehav-ing ones.

We observe that the effectiveness of the system is sub-stantially reduced in the presence of misbehaving nodes.However, forV = 1K it is still able to block54% of thespam when nodes reject connections that they are75%confident to be spamming.

In Figure 7 we report the number of spam connec-tions per second that are characterized as such by theregular nodes (true positives), throughout the spam cam-paign. This is the same experiment as the one in Figure 6.Spamming hosts also act as misbehaving FaceTrustnodes reporting1.0 trust for misbehaving nodes and0%

0

200

400

600

800

1000

1200

0 200 400 600 800 1000 1200

De

tecte

d s

pa

m c

on

ne

ctio

ns p

er

se

c

time (sec)

appropriate social trustinappropriate social trust

Figure 8: The rate with which spam connections are detected as afunction for appropriate and inappropriate social trust values. Connec-tions for which a node is 75% confident that are spam are considereddetected by that node.

confidence that spamming nodes are spammers. At eachinstance, the rate is derived as the number of detectedconnections over the last10 seconds. We observe thatas time progresses and the trust of the spam bots propa-gates in the network, the rate with which spam bots suc-cessfully establish connections decreases. In addition, astime progresses the trustworthiness of honest reportersincreases resulting in nodes trusting their reports faster,resulting in more effectively blocking of spam connec-tions. Furthermore as time progresses, the reputation ofdishonest FaceTrust nodes decreases resulting in less ef-fective manipulation of the trust, and enabling more ef-fective spam detection. Persistent bots are the easiest toblock as they get blacklisted early in their lifetime. Con-sequently, after the first 600 sec, as the ephemeral botsdie out, the effectiveness of the system in blocking spamis drastically improved.

The above results demonstrate that FaceTrust offers aplausible spam blocking primitive. If it is used in con-junction with existing email classification mechanisms ithas the potential for very wide threat coverage.

4.2.2 Significance of Social Trust

With this evaluation, we demonstrate the importance ofusing the social network of FaceTrust admins to initial-ize the direct trust between nodes to an appropriate value.The settings for this simulation are the same as for Fig-ure 7, except that all the direct trust values between so-cially acquainted nodes are set equal to0.1, and the di-rect trust is set to0.9 for only 5 instead of20 pre-trustednodes.

Figure 8 illustrates that appropriately initializing thetrust graph with proper social trust values yields moreeffective blocking of spammers than not initializing thetrust graph. On average when the social trust is not ap-propriately used, at the end of the simulation a FaceTrustnode has only0.11 trust towards honest nodes and0.01

0

10000

20000

30000

40000

50000

60000

70000

80000

90000

0 50 100 150 200 250 300 350

Nu

mb

er

of

ho

sts

time (sec)

>50% confident is worm>75% confident is wormSlammer-infected hosts

Figure 9: The number of nodes that are50% or 75% confident ofslammer packets being a worm upon encountering them. We alsoplotthe number of nodes that are infected as a function of time in the ab-sence of a containment mechanism.

trust towards misbehaving ones. Had regular FaceTrustnodes not leverage social trust, they would be discon-nected from the rest of their trust graph and derive0.0trust towards their peers. Consequently, they would beunable to consider the behavioral reports of their peersand reject spam connections.

This result motivates our design choice to tap into thesocial trust between acquainted FaceTrust admins. So-cial trust is important because it allows new nodes toform a sufficiently connected reporter trust graph, whichthey can use to derive appropriate transitive trust valuestowards their peers. These trust values can be derivedwithout prior report verifications. Social trust also con-tributes in trust values converging to correct ones faster(given that the social trust values are appropriate), evenin the case report verifications are infrequent.

4.2.3 Internet Worm Simulation

To further demonstrate FaceTrust’s utility, we now eval-uate our system’s ability to contain epidemically self-replicating malicious code. We simulate the behaviorof the Slammer worm. We derive the Slammer epi-demic parameters from [36], with the distribution of scanrate among infected hosts being normal with mean 4000scans/sec,N(4000, 20002). The parameterα of Equa-tion 1 is set equal to0.3, and the parameterǫ (Section 3.3)is set equal to0.1. Lastly, the parameterD (Section 3.5)is set equal to3 sec.

Out of the 100K total simulated FaceTrust nodes,10K nodes are able to detect worms with100% certaintyand not get infected (e.g. Vigilante [19] nodes). We re-fer to these 10K nodes ashonest nodes. We refer to therest90K nodes asregular nodes. Regular nodes rely onhonest nodes to warn them about worm-carrying pack-ets. The rest of the nodes cannot detect worms and donot verify the behavioral reports of other nodes, there-fore they do not generate behavioral reports and do not

send direct trust updates. Another1K nodes are misbe-having FaceTrust nodes. These misbehaving nodes claim0% confidence that slammer packets are worms. Theyalso claim1.0 direct trust for misbehaving nodes in theirview. In addition, misbehaving nodes refuse to store orforward DHT queries regarding behavioral reports thatwould help regular nodes to contain the worm. Slammerrandomly generates target IP addresses to scan, while theIPs FaceTrust nodes are picked uniformly randomly inthe 32-bit IP space.

FaceTrust nodes retrieve behavioral reports for theSlammer packet when their IDS application callsGetTrust(packet signature,‘‘is worm’’). Theysubmit behavioral reports as soon as their applicationclassifies a packet as being the slammer worm. Theyupdate their direct trust as soon as the node verifies thebehavioral reports of another node.

Each node has a1K-node view of the FaceTrust net-work. Depending on the threshold of confidence for de-ciding whether a packet is worm, nodes that are> 50%or > 75% confident that a packet is worm do not get in-fected. Nodes that are not as confident about the packetbeing worm get infected upon being scanned and startscanning themselves. The epidemic originates from asingle infected host at the start of the simulation. Infectednodes do not act as misbehaving FaceTrust nodes.

Figure 9 shows the number of regular nodes that are> 50% or > 75% confident of slammer packets beinga worm as time progresses. In addition, it shows thenumber of hosts that become infected in the absence ofa defense mechanism. Our results show that FaceTrustconverges fast towards all honest FaceTrust nodes hav-ing greater than50% confidence that the worm packet ismalicious. The rate of convergence is faster than the rateof worm propagation. This result implies great potentialfor containment of self-replicating malicious code.

5 Related Work

We now discuss prior work pertinent to FaceTrust’s de-sign.

5.1 Reputation Management Systems

FaceTrust is inspired by prior work on reputation andtrust management systems [14, 23, 32, 34]. Well-knowntrust and reputation management systems include the rat-ing scheme used by the eBay on-line auction site, objectreputation systems for P2P file sharing networks [26,52]or schemes to incent seeding in P2P content distribu-tion systems [12, 39]. Some reputation systems claimresilience to false reports and collusions [16, 20], how-ever the Sybil attack if successful enables an adversaryto defeat these defenses. In contrast to these systems,

FaceTrust applies to a broad range of entities, rangingfrom data objects to end systems. second, FaceTrustincorporates social trust to mitigate false reporting andSybil attacks; other systems typically rely on a centralcertification authority, e.g. [52].

In EigenTrust [26] nodes converge to the same trustvalue because a node learns about all the interactions be-tween peers in the system, while in FaceTrust nodes learnonly about the interactions involving nodes in their view.FaceTrust aims at enabling nodes to have a reliable es-timate of the probability that a peer is trusted and notin system-wide trust convergence. Therefore, FaceTrustis a more lightweight reputation management protocol,which does not require multiple iterations. EigenTrustreputation values are normalized so that the sum of thereputation values for all hosts is1.0. The rationale is thatno peer should be able to disproportionately affect thereputation ranking of a peer by sending a highly skewedreputation update. EigenTrust’s normalized reputationvalues do not map to the probability that a host’s report isvalid, while FaceTrust trust values in[0, 1.0] do. Eigen-Trust values can be used for ranking hosts, but cannotbe used to derive the probability that a host’s reports aretrustworthy.

PageRank [15] leverages the link structure of the webto rank the popularity and significance of web search re-sults. The PageRank of a web page corresponds to theprobability that a web surfer will eventually visite thissite by randomly following links. It is similar in prin-ciple to EigenTrust, with the main difference being thattrust in PageRank is derived by incoming links, while inEigenTrust by explicit trust assignments between nodesderived by direct observations of each other’s behavior.

5.2 Exploiting Social Networks to DeriveTrust

Several works exploit the trusted relations that form so-cial networks to reliably assess the trustworthiness of en-tities [22,24,33,40,43,44,60]. Unlike FaceTrust, they donot use tagged social links both to bootstrap trust valuesbetween socially acquainted nodes and to defend againstSybil attacks.

5.3 Collaborative Unwanted Traffic Miti-gation

FaceTrust is a generic collaborative threat mitigationframework that can be used to defend against a large va-riety of attacks against the Internet infrastructure. Vigi-lante [19] and Sweeper [50] are also collaborative threatmitigation platforms. However, they are purpose-builtfor worm containment through malicious code detection

and distribution of antibodies. Vigilante employs dy-namic taint analysis within an isolated virtual machinesandbox. Sweeper uses lightweight monitoring tech-niques and lightweight checkpointing to detect and re-cover from attacks during normal execution. Vigilanterequires that a host is equipped with a sandbox in order toverify the antibody-carrying Self Certifying Alerts sentby other Vigilante nodes. In Sweeper, it is assumed thatthe consumers of antibodies produced by other nodes inthe system fully trust the producers. Since FaceTrust em-ploys reliable trust metrics, nodes in our system are ableto determine the validity of alerts and antibodies withouthaving to verify them themselves.

In [17] distributed monitors use heuristics to detectworms and report there fingerprints using a DHT. Zouet al. propse a system [61] in which distributed monitorsreport worm signatures to a centralized server.

Prior work also includes proposals for collabora-tive spam filtering [1, 58, 59]. Unlike these systems,FaceTrust explicitly addresses the issue of trustworthi-ness of the collaborating spam reporters through a dis-tributed reporter reputation management system. Konget al. [28] consider non-compliant behavior, using Eigen-trust for reporter reputation. Nodes exchange emailsignatures,filter email based on content Besides beingthreat-specific, the aforementioned solutions only enableclassifying the contents of emails and not the source ofspam. This requires email servers to waste resources onemail reception and filtering. FaceTrust can assign trustmetrics to sources, thereby rejecting unwanted emailtraffic on the outset.

TrustedSource [6] employs a centralized repository towhich more than 7000 globally distributed submit behav-ior reports. Applications query the repository which re-turns the reputation for the specified IPs,domain namesor URLs. The reputation can be one of the five trusted,neutral, unverified, suspicious, and untrusted. A sim-ilar infrastructure is used by the SpamHaus [7] andTrend Micro [8], which rely on worldwide sensors toreport the IP address of spam senders. Based on thesensor’s feedback SpamHaus publishes blacklists of IPsknown to send spam. Unlike FaceTrust, the reputationfor IPs/domains/URLs or the blacklists depend only onthe reported values of the sensors/honeypots and not onthe trustworthiness of the sensors themselves. Thesesensors are deployed by TrustedSource, SpamHaus andTrendMicro or are assumed to be trusted. We envisionFaceTrust to consist of a much larger number of sen-sors/reporters as it is going to be a P2P system installedby bot system administrators and casual Internet userswithin large numbers of distinct trust domains. In ad-dition, centralized reputation services incur a delay be-tween the first reception of report of misbehavior and thetime the reputation of the entity is publicly available, of-

fering a rather large window of opportunity to attackers.This delay can be attributed to the fact that these servicesdetermine the reputation of an entity once the numberof reports exceeds a predetermined threshold in order toavoid incorrect classifications. FaceTrust does not needto incur this delay because it leverages the history of pastinteractions to readily determine trust values.

Zang et al.’s Highly Predictive Blacklisting [57] com-pares blacklists submitted by distinct distributed contrib-utors. They rank blacklist reports based on similarity.The intuition is that if two contributors have been at-tacked by the same attackers in the past they are morelikely to be attacked by the same attackers in the future.Thus, reports from a contributor that had similar experi-ences in the past should weigh more.

Behavioral blacklisting [42] combines spamming ac-tivity across multiple spam target domains. It identi-fies spamming IP addresses based on the observationthat spamming botnets tend to send large amounts ofemails from many IP addresses, to relatively small num-ber of domains over a short period of time. The sys-tem is able to capture this behavior and cluster offend-ing IP addresses based on spam target domains and timeframes. FaceTrust can be used to assign trust values toemail sender behaviors based on spam content, sendingfrequency, time patterns etc as reported in [42,54].

Ostra [35] leverages social networks to tackle un-wanted communication and is inherently resilient to theSybil attack. It bounds the total amount of unwantedcommunication a user can produce based on the num-ber of trust relationships the user has and the amount ofcommunication that has been flagged as wanted by itsreceivers. In our setting, Ostra could be used to regu-late the amount of behavioral reports that each FaceTrustnode can send. However, Ostra assumes that all com-munication is verifiable and can be flagged as wanted.However, this is not always the case in FaceTrust wherenodes do not always have the ability to verify behavioralreports. Thus, instead of limiting the number of behav-ioral reports a node can produce, we chose to assigns lev-els of trustworthiness to each report that depend both onthe node’s reporting history and the social relationshipsof the node’s administrators.

Sybil Attack Defenses The most common strategyagainst Sybil attacks is perhaps relying on a central au-thority that establishes a Sybil-free identity domain bybinding each entity to a single cryptographic identifier(e.g. public key certificate). Douceur [21] states thatthis approach is the only one fully capable of preventingSybil attacks. The challenges of this approach includethe cost of deployment, privacy and anonymity issues,cryptographic identifier revocation etc. In addition, thisapproach relies on the fact that the trusted authority is

fully capable to distinguish unique identities, which maynot always be true.

Another common defense against Sybils is resourcetesting of computing or storage capability. The under-lying assumption is that a Sybil attacker does not pos-sess enough resources to perform the additional tests im-posed on each Sybil node. Some drawbacks with re-source testing are listed in [21], such as the fact thatattackers subvert this defense by tricking humans intosolving CAPTCHAS [10] posted on their website or pre-sented by malware on infected machines.

FaceTrust’s design is inspired by SybilGuard andSybilLimit [55, 56]. These systems defend against Sybilattacks [21] by exploiting the fact that OSNs can be usedfor resource testing, where the test in question is a Sybilattackers ability to create and sustain acquaintances.

SybilGuard and SybilLimit are decentralized proto-cols that operate over a distributed social network. Givena request for connection, the protocol decides whetherthe request is accepted or rejected. SybilLimit restrictsa Sybil attacker that managed to socially associate withO(

√

(n)/ log(n) nodes in the social network to perform-ing collaborative tasks with onlyO(

√

(n) legitimate net-work nodes, regardless of how many Sybils it deploys.In SybilGuard/Limit, a verifier either accepts a suspectas a node with which to establish a social edge with ornot. However, in real social network large clusters oflegitimate social network nodes are frequently not well-connected with other clusters, meaning that nodes fromone cluster may reject collaboration requests from legit-imate nodes in other clusters. FaceTrust Sybil defensesare designed for centrally maintained online social net-works (e.g. Facebook). They are conceptually simplerbecause they leverage information available to the OSNprovider (i.e. the complete social graph topology), andintend to not completely ignore input from not well-connected nodes, but instead assign low weight (identitytrust) to it.

A SybilGuard-like technique is used by Leshniewskiet al. [30] to limit the Sybil attack in one-hop DHTs.

5.4 Social-network-based Applications

Instant messaging networks such as Google Talk, Ya-hoo IM, and MSN are prime examples of Internet ap-plications that form online social networks. The re-search community and the industry has also createdsocial-networking-basedapplications for file-sharing andbackup [9,31,49]. FaceTrust extends the utility of socialnetworks to providing a trust layer for Internet entities,aimed at mitigating unwanted traffic.

6 Conclusion

We have presented FaceTrust, a scalable peer-to-peersystem for the rapid propagation of reports concerningthe behavior of Internet entities (hosts, email signatures,packet fingerprints etc). FaceTrust nodes use each other’sreports and the social network of their human users toprovide to applications a quantitative measure of an en-tity’s trustworthiness: the likelihood that an entity is as-sociated with a specified malicious action. Applicationscan in turn use this measure to make informed decisionson how to handle traffic associated with the entity inquestion.

Our simulation-based evaluation demonstrated our de-sign’s potential for the suppression of two common typesof unwanted traffic. FaceTrust nodes were able to iden-tify 71% of spam connections with greater than75% con-fidence. In addition, FaceTrust nodes became aware of aworm fingerprint at a faster rate than the worm propa-gated.

References[1] Cloudmark.http://www.cloudmark.com/en/home.html.[2] Facebook.http://www.facebook.com.[3] Facebook developers.http://developers.facebook.com/.[4] Google Safe Browsing API.code.google.com/apis/safebrowsing.[5] McAfee SiteAdvisor.http://www.siteadvisor.com.[6] Secure Computing, TrustedSource.http://www.securecomputing.

com/index.cfm?skey=1671.[7] The spamhaus project.http://www.spamhaus.org/.[8] TrendMicro Email Reputation Services.http://us.trendmicro.com/

us/products/enterprise/network-reputation-services.[9] Wuala, the social online storage.http://wua.la/.

[10] L. V. Ahn, M. Blum, N. Hopper, and J. Langford. Captcha: Using Hard AIProblems for Security. InEurocrypt, 2003.

[11] R. Albert, H. Jeong, and A.-L. Barabasi. Internet: Diameter of the world-wide web. InNature, 1999.

[12] N. Andrade, M. Mowbray, W. Cirne, and F. Brasileiro. When can anAutonomous Reputation Scheme Discourage Free-riding in a Peer-to-peerSystem? InCCGRID, 2004.

[13] M. Bailey, E. Cooke, F. Jahanian, J. Nazario, and D. Watson. The InternetMotion Sensor: A Distributed Blackhole Monitoring System.2005.

[14] M. Blaze, J. Feigenbaum, and J. Lacy. Decentralized Trust Management.In IEEE S&P. Oakland, CA.

[15] S. Brin and L. Page. The Anatomy of a Large-scale Hypertextual WebSearch Engine. 1998.

[16] S. Buchegger and J. L. Boudec. A Robust Reputation System for Mobilead hoc Networks. 2003.

[17] M. Cai, K. Hwang, Y. Kwok, S. Song, and Y. Chen. Collaborative InternetWorm Containment. InIEEE Security and Privacy Magazine, 2005.

[18] M. Castro, P. Druschel, A. Ganesh, A. Rowstron, and D. Wallach. SecureRouting for Structured Peer-to-peer Overlay Networks. InUSENIX OSDI,2002.

[19] M. Costa, J. Crowcroft, M. Castro, A. Rowstron, L. Zhou,L. Zhang, andP. Barham. Vigilante: End-to-end Containment of Internet Worms. InACMSOSP, 2005.

[20] C. Dellarocas. Immunizing Online Reputation Reporting Systems AgainstUnfair Ratings and Discriminatory behavior. InACM conference on Elec-tronic commerce, 2000.

[21] J. R. Douceur. The Sybil Attack. InIPTPS, 2002.[22] S. Garriss, M. Kaminsky, M. Freedman, B. Karp, D. Mazieres, and H. Yu.

Re:Reliable Email. InNSDI, 2006.[23] K. Hoffman, D. Zage, and C. Nita-Rotaru. A Survey of Attack and Defense

Techniques for Reputation Systems. InACM Computing Surveys, 2008.[24] T. Hogg and L. Adamic. Enhancing Reputation Mechanismsvia Online

Social networks. InACM conference on Electronic Commerce, 2004.[25] J. Kaiser. It’s a Small Web After All. InScience, 1999.[26] S. D. Kamvar, M. Schlosser, and H. Garcia-Molina. The EigenTrust Algo-

rithm for Reputation Management in P2P Networks. InWWW, 2003.

[27] S. Katti, B. Krishnamurthy, and D. Katabi. Collaborating Against CommonEnemies. InACM IMC, 2005.

[28] J. S. Kong, B. A. Rezaei, N. Sarshar, V. P. Roychowdhury,and P. O. Boykin.Collaborative Spam Filtering Using e-mail Networks. InIEEE Computer,2006.

[29] J. Leskovec and C. Faloutsos. Sampling from large graphs. In ACMSIGKDD, 2006.

[30] C. Lesniewski-Laas. A Sybil-proof One-hop DHT. InWorkshop on SocialNetwork Systems, 2008.

[31] J. Li and F. Dabek. F2F: Reliable Storage in Open Networks. In IPTPS,2006.

[32] J. Li, N. Li, X. Wang, and T. Yu. Denial of Service Attacksand Defensesin Decentralized Trust Management. InACM CCS, 2006.

[33] J. Li, Y. Sovran, and A. Libonati. Pass it on: Social Networks StymieCensors. InIPTPS, 2008.

[34] S. Marti and H. Garcia-Molina. Taxonomy of Trust: Categorizing P2PReputation Systems. 2006.

[35] A. Mislove, A. Post, P. Druschel, and K. P. Gummadi. Ostra: LeveragingSocial Networks to Thwart Unwanted Traffic. InUSENIX NSDI, 2008.

[36] D. Moore, V. Paxson, S. Savage, C. Shannon, S. Staniford, and N. Weaver.Inside the slammer worm. InIEEE S&P, 2003.

[37] D. Moore, C. Shannon, G. Voelker, and S. Savage. Internet Quarantine:Requirements for Containing self-propagating Code. InIEEE INFOCOM,2003.

[38] K. Mller and T. Vignaux. Simpy (simulation in python).http://simpy.sourceforge.net/.

[39] M. Piatek, T. Isdal, A. Krishnamurthy, and T. Anderson.[40] J. M. Pujol and R. S. J. Delgado. Extracting Reputation in Multi Agent Sys-

tems by Means of Social Network Topology. InInternational Conferenceon Autonomous agents and Multiagent systems, 2002.

[41] A. Ramachandran and N. Feamster. Understanding the Network-level Be-havior of Spammers. InACM SIGCOMM, 2006.

[42] A. Ramachandran, N. Feamster, and S. Vempala. Filtering spam with Be-havioral Blacklisting. InACM CCS, 2007.

[43] J. Sabater and C. Sierra. Reputation and Social NetworkAnalysis in Multi-agent Systems. InInternational Conference on Autonomous agents andMultiagent systems, 2002.

[44] J. Sabater and C. Sierra. Social Regret, a Reputation Model Based on SocialRelations. 2002.

[45] S. Singh, C. Estan, G. Varghese, and S. Savage. Automated worm finger-printing. InUSENIX OSDI, 2004.

[46] E. Sit and R. Morris. Security Considerations for Peer-to-peer DistributedHash Tables. InIPTPS, 2002.

[47] L. Spitzner. The Honeynet Project: Trapping the Hackers. In Security &Privacy Magazine, IEEE, 2003.

[48] I. Stoica, R. Morris, D. Karger, M. Kaashoek, and H. Balakrishnan. Chord:A Scalable Peer-to-peer Lookup Service. InACM SIGCOMM, 2001.

[49] D. N. Tran, F. Chiang, and J. Li. Friendstore: Cooperative Online BackupUsing Trusted Nodes. InSocialNets, 2008.

[50] J. Tucek, S. Lu, C. Huang, S. Xanthos, Y. Zhou, J. Newsome, D. Brumley,and D. Song. Sweeper: a Lightweight End-to-end System for DefendingAgainst Fast Worms. InEuroSys, 2007.

[51] M. Vrable, J. Ma, J. Chen, D. Moore, E. Vandekieft, A. C. Snoeren,G. M. Voelker, and S. Savage. Scalability, Fidelity, and Containment inthe Potemkin Virtual Honeyfarm. InACM SOSP, 2005.

[52] K. Walsh and E. G. Sirer. Experience with an Object Reputation Systemfor Peer-to-Peer Filesharing. InUSENIX NSDI, 2006.

[53] D. J. Watts and S. H. Strogatz. Collective dynamics of ’small-world’ net-works. InNature, 1998.

[54] Y. Xie, F. Yu, K. Achan, R. Panigrahy, G. Hulten, and I. Osipko. SpammingBotnets: Signatures and Characteristics. InACM SIGCOMM, 2008.

[55] H. Yu, P. Gibbons, M. Kaminsky, and F. Xiao. A near-optimal social net-work defense against sybil attacks. InIEEE S&P, 2008.

[56] H. Yu, M. Kaminsky, P. B. Gibbons, and A. Flaxman. SybilGuard: De-fending Against Sybil Attacks via Social Networks. InACM SIGCOMM,2006.

[57] J. Zhang, P. Porras, and J. Ullrich. Highly Predictive Blacklists. InUSENIXSecurity, 2008.

[58] Z. Zhong, L. Ramaswamy, and K. Li. ALPACAS: A Large-scale Privacy-Aware Collaborative Anti-spam System. InIEEE INFOCOM, 2008.

[59] F. Zhou, L. Zhuang, B. Zhao, L. Huang, A. Joseph, and J. Kubiatowicz.Approximate Object Location and Spam Filtering on Peer-to-Peer Systems.In ACM/IFIP/USENIX Middleware, 2003.

[60] P. Zimmerman. PGP Users Guide. December 1992.[61] C. Zou, L. Gao, W. Gong, and D. Towsley. Monitoring and Early Warning

for Internet Worms. InACM CCS, 2003.