Fides aims to design and implement a trust model for sharing threat intelligence in global peer-to-peer networks where the peers are instances of intrusion prevention systems.
In this document, we propose a new trust model Fides. Fides was named after the ancient goddess of trust and good faith Fides.
The trust model utilizes modified SORT’s computational model with multiple modifications and extensions that allows it to work in highly adversarial global peer-to- peer networks effectively. Fides is a generic and heavily configurable trust model specializing in sharing threat intelligence. Thanks to its modular architecture, it can operate with any data and it is not limited only to threat intelligence. In the General Overview of Fides Section we describe our trust model design and explain how Fides works on a high level, the inputs and outputs, and how it behaves in which situation.
After outlining the general overview, we analyze the weaknesses of the trust models and how they apply to Fides. First, we start with the cold start problem in the Static Initial Trust Section, which describes how peers can gain trust when they are new in the network and how Fides tackles this issue. Then, In the Attack Vectors Section we analyze possible attack vectors on our trust model. Once all trust model requirements are explained, we dive deep into Fides’s computational model in the Computational Model of Fides Section and explain how it can uncover trust relationships in the network.
Because Fides specializes in sharing threat intelligence and integrates with Slips IPS, in the Network Intelligence Aggregation Section we explain how Fides aggregates the weighted threat intelligence from the network.
We use the following terminology to talk about the trust model:
-
Target: An identification of a resource for which is Slips able to generate threat intelligence. It can be, for example, either an IP address, a domain, or hashes.
-
Local Peer: The unique local instance of Slips that is connected to the global P2P network and runs Fides. In equations, we use i when referring to the local peer.
-
Remote Peer. A peer on the Internet is connected to the global Slips P2P network. In equations, we use j when referring to the remote peer.
-
Service Trust: How much does Fides trust a remote peer that it provides the local peer with good service. In other words, to what extent does Fides trust a specific peer that it provides correct and valuable threat intelligence. We denote it st and discuss it in detail in the Service Trust section
In this section we describe how Fides work from a high level perspective.
Fides operates in four general phases, which are visualized in Figure 3.1. In the first phase, a local Fides instance receives threat intelligence data from the remote peers in the network.
In the second phase, Fides aggregates the threat intelligence data using the trust data it has for each remote peer. In general, data from highly trusted peers have a higher impact on the final aggregated threat intelligence than the data from peers with low trust. How does Fides does that is described in the Network Intelligence Aggregation Section The aggregated threat intelligence is also sent to Slips IPS as an output of the trust model.
In the third phase, Fides evaluates the interactions with each peer. Fides computes how much it was satisfied with the threat intelligence it received from each remote peer. The evaluation does not depend on the content of the threat intelligence and therefore is a generic method. This satisfaction metric has then a direct influence on the trust relationship between the local and remote peers because it is used in the next step to compute trust data.
In the fourth step, Fides updates the trust data for each peer according to the satisfaction that is computed in step number three.
Computations that allow Fides to do that are described in detail in the Computational Model of Fides Section
All operations, including the data flow and the communication with other peers and Slips, can be found on the operational diagram shown in Figure 3.2 below.
A dynamic and global environment such as a global peer-to-peer network is open to anyone since any peer can freely join and leave. Because of that, the local peer will encounter many other peers that were not seen before. Therefore, the trust model does not have any information about their reliability or how much it can trust them. New benign peers need to be somehow trusted by the local peer in order to be a useful part of the network. However, the local peer also needs to be able to discover new malicious peers that are trying to gain its trust. The problem of how to know something about a new entity in order to quickly work better is called the Cold Start Problem. For Fides, it means how to compute a good initial trust for new unknown peers. We selected several solutions to this issue, which are all implemented in Fides. Fides also combines them according to a provided configuration with the aim to achieve the best result for the cold start problem with adversarial peers.
In this approach, whenever the trust model encounters a new peer, it assigns a static value as an initial trust. The value is assigned by pre- choosing some third-party trust models in the configuration.
For example, in the Dovecot trust model, every peer starts with trust 1 (highest possible), and various interactions can lower the trust in the peer to 0. In other words, the trust model considers new peers honest from the beginning, and only during this time their reputation can be lowered when they perform incorrect interactions or are discovered as a malicious peer. On the other hand, the Sality botnet uses a value called goodcount as a counter of good interactions with any other peer, the higher the goodcount, the greater trust the local peer has on the remote peer. The goodcount for each new peer starts with 0 in Sality. Meaning, that the botnet does not trust fresh peers at all and they can gain trust only by following the Sality protocol. The model of static initial trust is easy to implement, but it requires assumptions about the network. If the network is considered mostly benign, it might be safe to use an initial trust of 1, however, for highly adversarial networks using an initial trust of 1 might be dangerous and it is better to use 0. Using low initial trust and no mechanism to gain more trust fast
means that the benign peers that joined recently do not affect the final decisions of the model, even though they might have useful information about adversaries. Static initial trust is supported by Fides as a form of fallback when no
other cold start technique is used. The administrator provides a configuration that contains the initial reputation for each new peer.
Fedis is done as a part of a master thesis which was done simultaneously to the master thesis on global P2P security TI sharing by Bc. Martin Repa, called Iris, which implements the new idea of pre-trusted peers in organizations for the Slips IPS.
Therefore, Fides works with the concept of pre-trusted organizations which have pre-trusted peers. Iris implements the concept of pre-trusted organizations, and Fides uses this knowledge to assign a higher or lower trust to new peers.
The global P2P framework implemented by Repa supports these type of peers and provides a cryptographically-secure way how to identify a single peer in the network, and its membership in an organization. This allows Fides to pre-trust specific peers or all the peers from organizations by assigning them an initial value.
Fides can be configured to use pre-trust in two different ways. First, to assign the pre-trusted peers an initial reputation. This means that the peer will have an initial reputation, but it will be required to interact with the local peer and it will slowly change that initial reputation according to its interactions with others. All the interactions will be evaluated and Fides will compute a service trust for the peer.
Second, Fides can use the initial pre-trusted value read from the configuration as the final service trust. This effectively means that Fides will not evaluate any data received from the pre-trusted peer and this service trust will be kept forever.
This configuration for Fides is called enforceTrust. If it is enabled and
thus enforceTrust = False is set in the configuration, Fides uses the first
variant where the trust for the peer will move during the interactions. If the
administrator uses enforceTrust = True, Fides uses the second option and
fixates the service trust for the peer to a set pre-trust.
Both options help solve the cold start problem for specific peers and organizations, as they will start with a high reputation or fixed service trust. Which organization or peer to trust is completely left to the administrator of Slips. However, as the administrator needs to know the identity of the peers or organization, it does not solve the cold start problem globally for all peers.
As the local peer might have multiple remote peers that it trusts enough,
Fides uses these relationships to ask the remote peers about how much they
trust a new peer. Fides only asks for recommendations once: when the local
peer finds a new peer for the first time.
Using a recommendation system introduces new attack vectors that can
be exploited by adversaries, either by getting trust for the malicious peer or
by lowering trust in honest peers that might have some threat intelligence
about the malicious actor. These attacks are called bad-mouthing and unfair
praises and we need to consider them and implement countermeasures.
Because of the possible attacks, the local peer should not solely rely on
the network recommendations when computing the final service trust for the
fresh peer. In case when the recommending peers are malicious, it might
skew the decisions of the local peer for the time being. In order to solve
this, when computing the final service trust for the remote peer, the local
peer should take into account its own interaction with the peer as well as
the received recommendations.
Moreover, the local peer should request recommendations only if it has
enough trusted remote peers, otherwise, it can expose itself to bad-mouthing
and unfair praises attacks more easily.
Fides employs recommendation systems based on SORT
but with more strict rules when it is actually used and combines it with the
pretrusted peers
as well as with the static initial trust
as a fallback when no other option is available due to constraints such as having not
enough trusted peers. The algorithm used for the recommendation system
is explained in detail in Computational Model of Fides Section
Since Fides is a trust model that computes how much to trust peers, it is potentially open to attacks from adversarial peers. Adversarial peers are peers that know how to talk the protocol and manipulate the recommendations, or threat intelligence data in order to influence the final decisions.
Adversarial peers can try to:
- Send bad threat intelligence data
- Lie about a peer that is benign
- Lie about a peer that is malicious
This section describes how Fides determines to whom and how much it can trust other remote peers. Our trust model expresses trust in a specif peer with metrics called service trust. Service trust is a value that describes how much the local peer can trust a specific remote peer. Here, we describe the process top-down starting with the most important parts - service trust - and then breaking it down into bits. Note that there are two main ideas behind most of the equations.
The first one, is that we want to robustly capture the average behavior of the peers. In order to do that, we will be computing the average behavior of the peers and then approximating the deviations from said behavior.
The second part compares and weights first-hand experience with the remote experience. First-hand experience is what happened between local and remote peers during the time they interacted. This can be, for example, threat intelligence sharing, file-sharing, or the results of the recommendation protocol. Remote experience is what happened between one remote peer and another remote peer. In other words, first-hand experience for peer j are actions between j and z. Whenever j shares information about these actions with peer i, for i it is a remote experience.
Table 3.1 below describes the most important notation we use in the following sections.
As outlined previously, service trust is a value that describes how much peer i trusts that remote peer j will provide a good service.
We compute the st(i,j) in the Equation 3.1 by weighing local experience with peer's j service, with the reputation j got from the network when it was first seen by i. The used weight is the size of the service interaction history shi,j to global maximal history size sh(max).
Equation 3.1 implies that the more interaction there was between peers i and j, the bigger impact on st(i,j) it has. In other words, the more i and j interact the less i relies on the reputation that i computed from the values provided by the network, at the time when j was seen for the first time by the peer i.
The first part of the Equation 3.1 contains competence belief cb(i,j) , and integrity belief ib(i,j) . Both values are based solely on the history of the interactions that the peer i experienced with the peer j.
Competence Belief
Competence belief represents how much did peer j satisfied local peer i with the past interactions. We measure it as an average of interactions from the past.
Integrity Belief
Integrity belief ib(i,j) is a level of confidence in the predictability of future interactions. It is measured as a deviation from the average behavior cb(i,j) . Therefore, ib(i,j) is calculated as an approximation to the standard deviation of interaction parameters.
It holds that 0 ≤ ib(i,j) ≤ 1. The more consistent behavior peer j has, the lower the ib(i,j) is. Consistency is a highly desired property as the local peer then has more precise estimates about the future behavior of the remote peer.
s**k(i,j) is i’s satisfaction value with interaction with peer j in window k. (see the table here)
We outlined before, that each interaction between two peers is evaluated, s**k(i,j) is a result of this evaluation of a single interaction between peers i and j. Because our trust model is generic, the evaluation function can be implemented differently for different data. However, even with the computed interaction satisfaction value, not all interactions are the same. Some interactions are more important than others. Moreover, because peers can change their behavior, most recent interactions should be more important than the interactions that happened a long time ago. That is why we include the weight of the interaction and the fading effect.
Weight of the Interaction
Because each interaction is different and its importance is different, we have w**k(i,j) that measures the importance. The weight belongs to interval 0 ≤ w**k(i,j) ≤ 1 and Fides implements it as a discrete function of interaction type. For example, the weight of interaction when a remote peer shares the threat intelligence is higher than when the remote peer requests threat intelligence.
Fading Effect
Fading effect f**k(i,j) determines "how much does the algorithm forget" as the algorithm prefers most recent interactions over past interactions and thus f**k(i,j) reduces the weight of the past interactions. f**k(i,j) is a non-increasing function of interaction and time or an index of said interaction in history. The actual implementation of the fading effect depends on the data the trust model is processing. For example, SORT implements it as a decreasing linear function
However, in our case and after multiple iterations, we decided not to forget the interactions that the model remembers and rather have all interactions with the same impact.
The way Fides computes f**k(i,j) might be changed in the future and implemented as a function of time, we discuss this in more detail as a part of the future work.
In order to mitigate the cold start problem outlined in the Cold Start Problem Section and in the cases when there are no or few interactions between i and j, the algorithm relies on r(i,j) - reputation value. r(i,j) is the second part of the service trust Equation 3.1 that introduces remote experience to the service trust. The reputation value is computed from the recommendations received from the remote peers. This value represents what remote peers think about another remote peer. However, this value is calculated by the local peer with respect, to how much it trusts each peer, that provided the recommendation. When the local peer i encounters remote peer j for the first time and it does not have any data about its trustworthiness, i can request recommendations on peer j from i’s most trusted peers. We denote a set of remote peers, that provided the recommendations as Ti
Requesting a Recommendation
The recommendation system built into Fides cannot be used in every scenario. Because of the sensitive nature of the environment, the trust model was designed for, there are cases when it is dangerous to ask for recommendations. This is mainly the case when there are not enough peers that are trusted enough. SORT requests recommendations every time it encounters a new peer. The set of recommending peers is created by taking all known peers and selecting those that have higher than average service trust. However, those can also be peers with trust as low as 0.001. In a sensitive environment, which the peer-to-peer network of IPS definitely is, we do not want to get recommendations from peers, that have low trust at all. Moreover, given the nature of Slips, we decided to combine a recommendation system based on SORT with Static Initial Trust and with Pre-trusted peers. This approach provides a more robust basis for a trust-sensitive environment and it helps us to mitigate the Cold Start Problem If the peer is part of a pre-trusted organization or it is pre-trusted itself, it inherits the configured reputation r(i,j) from the configuration. In this case, Fides does not engage the recommendation protocol at all, because the peer already has reputation r(i,j) assigned from the configuration and it was recommended by the administrator. Moreover, the administrator can choose if this value is frozen, or not. Frozen Service Trust configuration means, that the peer j has in eyes of i static service trust st(i,j) it will never change and whatever data peer j sends to i will not influence the st(i,j) . On the other hand, when this configuration is not selected, the peer’s service trust is going to change during the time when it communicates with the local instance according to the data and interactions it provides. In the case where the peer is not pre-trusted, Fides evaluates if it has
enough well-trusted peers that can be trusted to provide the correct recommendation. This value as well as a number of maximal peers used for
recommendation is configurable. In addition, the administrator can enforce that for the recommendation protocol, only the pre-trusted peers or the peers from pre-trusted organizations are used.
Recommendation Response
A single recommendation response from peer z ∈ Ti about giving the recommendation to peer i about peer j contains the following data.
-
cb(z,j) , ib(z,j) - summary of z’s interactions with j, competence belief and integrity belief
-
sh(z,j) - service history size, number of interactions between z and j - the more interactions they had, then the z’s recommendation has more credibility
-
r(z,j) - summary of recommendations that z received on j
-
η(z,j) - number of peers that provided recommendations for j when j was new to z and their recommendation was used to compute r(z,j)
cb(z,j) , ib(z,j) are included in the recommendation in order to provide a view on what does z think about j. sh(z,j) and η(z,j) are included to indicate how much experience with j does z actually have. To determine to which extent is the z sure about correctness of cb(z,j) , ib(z,j) , r(z,j) in the recommendation. And also to protect the z’s recommendation trust in i’s eyes, if cb(z,j) , ib(z,j) , r(z,j) values are wrong, because i inspects sh(z,j) and η(z,j) and does not penalize z that much, if the history size or the number of original recommender are low.
Computing Reputation
When the local peer receives all recommendations, it computes the rep- utation value r(i,j) as a weighed expected local experience (ecb(i,j) , eib(i,j) -
estimates about competence and integrity) from the remote peers with their remote experience (er(i,j) - estimate about reputation of said peer).
The weight, used in the Equation 3.5, is the average of history sizes in all recommendations to sh(max), maximum interactions history size. We calculate μsh as follows.
Again, we are weighing local experience to remote experience. However, in this case, it is local for the remote peers that provided the recommendations.
Similarly, when we compute the service trust in Equation 3.1, we need to get competence and integrity belief. However, while creating reputation value in 3.5 where the values are coming from the remote peers, we are trying to estimate those values received from the network. For that reason, we call
them estimated competence belief - ecb(i,j) and estimated integrity belief - eib(i,j) .
Estimated Competence Belief ecb(i,j) is estimation about competence belief made by i about j. This value is computed from the received recommendations in combination with rt(i,z) - a recommendation trust that i has about z. Similarly, as for service trust, we have a normalization coefficient βecb that moves the resulting data to the correct interval. It holds that 0 ≤ ecb(i,j) ≤ 1.
Recommendation trust is described in detail in the following sections.
Estimated Integrity Belief
Following the ecb(i,j) , eib(i,j) is estimation about the integrity belief made by i about j. Equation 3.8 is almost similar, but we use ib(z,j) instead of eb(z,j) . This means that normalization coefficient βeib = βecb.
Going back to Equation 3.5 from the Reputation and Recommendations Section, we use estimated reputation value er(i,j) . This value represents information that was created
by the peers that are remote even for remote peer j. In other words, this information came from the second ring of trust - from acquaintances of an acquaintance.
Recommendation trust - rt(i,z) - is another metric that a peer calculates and stores. It expresses how much does i trust that z provides good recommendations. Even though one could theoretically use service trust st(i,z) for this, we have another trust metric because there are peers that can provide very good data (service), but they are surrounded by bad peers or the other way around. This also gives us the ability to have specialized nodes in the network that serves as a peers registry for organizations - a single node that only provides recommendations on peers. We calculate the recommendation trust in a similar way as the service trust and reputation, but we use recommendation competence belief rcb(i,z) , recommendation integrity belief rib(i,z) and reputation r(i,z) . This time, we use the weight rh(i,z) , which is the size of the history of the recommendations provided by z to i, and rh(max) , the maximal size of said history.
Recommendation Competence and Integrity Belief
Similarly for interactions, we use three different parameters for calculating the rcb(i,z) and rib(i,z) . We use satisfaction rs**x(i,z) , weight rw**x(i,z) and the fading effect rf**x(i,z). The parameters have the same background as described in the Interaction Satisfaction Section, but in this case, they are connected to recommendations instead of service. We calculate rcb(i,z) as follows:
And for recommendation integrity we compute rib(i,z) as:
One more time, the computational model is trying to approximate average behavior in recommendations - rcb(i,z) - and then the deviation from such behavior - rib(i,z)
Fading effect rf**x(i,z) has similar properties as the fading effect for service trust described in the Interaction Satisfaction Section. It is a non-increasing function of a number of recommendations or a time. For the recommendations, Fides implements it exactly the same as for the service interactions.
Evaluating Received Recommendation
As outlined in Recommendation Trust Metric Section, in order to evaluate a particular recommendation from remote peer z, we have satisfaction, weight, and the fading effect. We calculate the recommendation satisfaction rs**x(i,z) by comparing values from z’s recommendation r(z,j) , cb(z,j) , ib(z,j) , with values that are the results of the recommendation algorithm. In other words, we compare each recommendation, with the aggregated values - er(i,j) , ecb(i,j) and eib(i,j) . This gives us an estimate of how off was the peer z’s recommendation from the final result of the recommendation algorithm.
We calculate the weight of recommendation rw**x(i,z) as a weighed sum of the proportion of the size of the service history between z and j with maximal service history size. And a number of peers that provided the initial reputations η(z,j) divided by a maximal number of possible recommending peers.
Fides is a trust model designed for global peer-to-peer networks of Slips instances. It is designed to support Slips in detecting malicious actors on the network and enables threat intelligence sharing between peers of Slips instances. Because Slips was designed to be as modular as possible, Fides is effectively running as a module that provides aggregated threat intelligence to Slips. In other words, Fides provides a view of what the network thinks about some threat intelligence target. This is necessary so Slips can have a unique view of the network on a specific Threat Intelligence. Fides needs to aggregate elements of threat intelligence from remote peers into a single value that is then presented to Slips.
Fides needs to say that some reports are better than others, based on the service trust the local peer has in the remote peer (previously computed as st**k(i,j). Thus Fides needs to weigh every report based on this trust and come up with an aggregated score S**k(T) . Apart from the aggregated score, Fides needs to compute the aggregated confidence C**k(T) that expresses how confident i is about the aggregated score S**k(T) that was computed in the previous step. Once aggregated, the computed score and confidence (S**k(T) , C**k(T) ) are sent to Slips to report data on target T . Apart from sending to Slips, these same values can be also used to evaluate the interaction of the remote peers, depending on the selected interaction evaluation strategy.
We designed and implemented two different functions for aggregating threat intelligence and computing S**k(T) alongside with C**k(T) . Both of them are implemented in Fides under their respective names.
In this method, the aggregated score S**k(T) is the sum of S**k(j,T) which is the score sent by each peer j about target T in time window k; weighed with the normalized service trust that i computed for peer j, denoted wst**k(i,j) . The sum is done over the set of remote peers that provided a report to i for T in time window k, denoted R**k(i,T). We calculate it in Equation 3.22.
The normalized service trust wst**k(i,j) used as weight is computed as:
Equation 3.23 estimates the percentage that the service trust on j st**k(i,j) has relative to the total sum of service trust received by i for all peers, for this target T , in time window k. We compute the aggregated confidence C**k(T) for this strategy as:
Which is an average over all the peers that sent to i a report on T in time window k, of the weighted confidence sent by peer j on target T on time window k. The weight is done by the service trust that i has on j on time window k.
This strategy uses Equation 3.22 to compute the aggregated score S**k(T)
similarly to the AverageConfidenceTIAggregation.
However, the way how this strategy calculates C**k(T) is different. Instead of using
the service trust st**k(i,j) to determine the correct trust in the confidence C**k(j,T)
submitted by peer j and then diving it by the number of peers, it uses
the normalized service trust wst**k(i,j) computed in Equation 3.23 that already
contains the weight of the peers in the final decision.
