The proposed HTMS tries to take the advantages of both the Role based and Reputation-based TMSs by enhancing RBTM with RS. In HTMS, each entity is assigned a role beforehand by an administrative authority. However, all entities belonging to the same role do not necessarily have the same access rights. Within each role, a range of access rights is defined from a minimum privilege level, to a maximum privilege level. For instance, minimum privilege level access could mean that a soldier can only receive communications. Soldiers with higher privilege levels could receive as well as send communications, whereas soldiers with maximum privilege levels could access battle plans.
Privilege levels are real values between 0 and 1, with 0 being the least privileged, and 1 being the most privileged. Nodes with 0 privilege level cannot access any resource on the network, whereas nodes with privilege level 1 have full access to all the resources on the network. When the administrative authority assigns a role to a new node, it defines a minimum and a maximum privilege level that the node can possess. At any point of time, the exact privilege level of the node is determined by its reputation score, but it will always fall within this range. The administrator then issues a digitally signed certificate to the node, with the following credentials:
where Node ID is the ID of the node, and Role is the role title, such as private, major, colonel, or general, and is only meant for human consumption.
MinPL and MaxPL are the numbers between 0 and 1, and where MinPL ≤ MaxPL, respectively, denote the minimum and maximum privilege levels of a given role. Expiration time is the time when the certificate becomes invalid and must be renewed.
This certificate is signed by the administrator and given to the user, say John, who is assigned a role of major. All the majors have the same maximum and minimum privilege levels. John can carry this certificate on a smart card, or this certificate can be linked to John's login credentials so that it becomes active whenever John logs in to a machine. That machine then becomes a node with the Node ID given by John's certificate. In this way, the certificate is not linked with any particular machine, rather with the user himself who is free to switch machines in the network.
Whenever the node needs to access any service on the network, it will present this certificate to the server. The server will check what is the minimum privilege level required to access that particular service. This required privilege level is decided beforehand by the server administrator. Then, the server will proceed as follows:
-
(1)
Verify the signature to ensure that the certificate originated from the administrative authority.
-
(2)
If the required privilege level for the service is greater than the maximum privilege level on the certificate, then deny service.
-
(3)
If the required privilege level for the service is less than the minimum privilege level on the certificate, then grant service.
-
(4)
If the required privilege level for the service is in between the minimum and the maximum privilege on the certificate, then obtain the reputation score of the node and compute its privilege level at that point of time (explained below).
-
(5)
If node's privilege level is greater than or equal to the required privilege level, then grant service; otherwise, deny service.
A. Determining the Exact Privilege Level
As mentioned before, the exact privilege level of a node at a given point of time is determined by its reputation score, which is computed based on the feedbacks obtained from other nodes through the underlying RS. In general, we can summarize existing RSs [33–38] within the general framework shown in Figure 1. According to this framework, each node that interacts with another node stores some feedback about the interaction. The interaction is either classified as legitimate or suspicious (or some value in between). If, for instance, the interaction consisted of downloading a file, the client could determine if the downloaded file was indeed the one requested, or it was a Trojan or a worm. Based on the feedback of various nodes, a new node can decide whether to transact with a given node or not, even though they may never have interacted before. The underlying principle is that a node that has behaved well in the past is likely to behave well in the future, and so it gets high reputation score. On the other hand, a node that has misbehaved in the past is likely to misbehave in the future, and so it gets low reputation score. For example, eBay utilizes this form of RS where previous buyers leave feedback about the seller so that prospective buyers can decide whether to buy from the seller or not [39].
HTMS can actually use any RS [4, 34, 35, 37]. However, we chose to use our previously proposed Machine Learning-based RS [22, 40] for our experiments. The reasons for this choice are mentioned in Section V. In any case, whichever RS the network administrator decides to use, the only requirement is that the RS outputs a reputation score between 0 and 1, with 0 being the least reputable. The RS needs to guard against the possibility of malicious nodes giving incorrect feedback to malign another node. In case the node has no history, the RS outputs a preset default score, for example, 0.5.
Suppose a client wants to interact with a server. In HTMS, the server needs to first obtain the reputation score of the client. Accordingly, the server broadcasts a feedback request throughout the network. Any node that has transacted with the client before responds to the request and sends back encrypted and digitally signed feedbacks to the server. The server decrypts and verifies the signature of the feedback, and then computes a reputation score using any RS implementation. Once the reputation score is obtained, the final privilege level is computed using the following equation:
(1)
where PL is the current privilege level, MaxPL and MinPL are the maximum and minimum privilege levels respectively in the given role certificate. RScore is the reputation score, as outputed by the RS. Equation 1 simply normalizes the privilege level between the minimum and maximum levels. An RScore of 0 yields the minimum privilege level, whereas an RScore of 1 yields the maximum privilege level. A server will grant access to the requested service if PL ≥ MinPL for that service.
B. Merits of HTMS
Thwarting Global Attacks
The rationale behind HTMS is to find a solution to the problem where a privileged node is compromised by an attacker and then used to damage the network in some way. This could be by trying to attack other nodes, or by conducting malicious transactions with servers. One transaction on its own may not seem malicious, but when a combination of potentially harmful transactions occur globally throughout the network, the results could be disastrous. For instance, one update by a colonel to battle plans may not seem harmful, but a series of small updates over time may change the battle plans entirely. HTMS aims to thwart such attacks by collecting data from multiple parties that have transacted with the node before, and then deciding whether to grant access to this node using a global picture.
For this to be effective, each server assigns a feedback score between -1 and 1 to every transaction that takes place on the server. Potentially harmful transactions, such as updates to battle plans, or changes to passwords are assigned a negative feedback score, whereas harmless transactions, such as reading or printing non-classified files, are assigned positive feedback scores. Similarly, transactions deemed to be malicious, such as uploading viruses or worms, or trying to initiate a buffer overflow attack, will be given negative feedback scores. All of these feedbacks are then used by the RS to compute the overall reliability of the node, which in turn is used to determine access rights. A node that has conducted many potentially harmful transactions in the recent past will have a low reputation score, and service will be denied to it, even if it possesses a privileged role, thus thwarting any potential global attacks. At the very least, the attacker will have to slow down the attack, giving more time to the authorities to detect and defeat the attacker.
There might be some roles that routinely need to make mission-critical updates and these updates might give the role a bad reputation. Therefore, such crucial roles will have high minimum privilege levels so that they can do their job even with low reputation scores. However, extra precautions have to be taken to protect such roles from compromise.
Modeling Real World Scenario
The scheme models the real-world where an employee is given access rights based on his or her job title. At first, he or she is given a certain level of privilege. If he or she is observed to abuse his or her rights, some of his or her privileges are revoked. On the other hand, if he or she behaves well and gains the trust of he or her colleagues, he or she is rewarded with progressively higher access rights. This increase in rights may also be based on the fact that he or she will become more experienced over time and less likely to abuse the system inadvertently. Eventually, he or she may gain more and more trust and be promoted to a better position. Our scheme follows this model, and it is therefore intuitive.
Defense Against False Evidence
By maintaining a RS, we can deter a malicious node, M, from continuously presenting false evidence against X. Because the RS is based on evidence presented by several nodes, no single node can falsely incriminate X to significantly reduce its access rights. In any case, X's rights can never go below the minimum level within its role. Furthermore, if M repeatedly gives a low score to other nodes, it will hurt M's own reputation and diminish its own access rights.
Decentralized System
No single node holds all the evidence regarding any node. Therefore, if any one or a few nodes go offline then the system can still function well. The RS may be marginally affected since the contribution from the offline nodes will be missing, but it will usually not be critical if only a few nodes are offline.
Updating Roles
Periodically, the administrators responsible for role assignment can look at a node's past behavior and reconsider the role assigned to it. They could demote or promote a node to a different role (or job title) based on the behavior. Since each role credential carries an expiry date and time, temporary roles could also be assigned to guest entities for a predetermined amount of time.
Historical Record Keeping
This will encourage each node to always behave well so that it may retain or upgrade its access rights. This is similar to the credit score system maintained by credit agencies for individuals in the United States.