# A Game-Theoretic Approach for Network Security Using Honeypots
## 4 Results  
### Modeling the System  
Let us consider some notations to help us understand the model. On every host, there were multiple running services which can be real (\(\lambda_{real}\)) or honeypot (\(\lambda_{honeypot}\)) services. In our model, we took several hosts, which could be considered as servers, on top of which were configured running services such as web services, database services, file host services, etc. Among the real services, there were honeypots that served as decoys for attackers.  
The model is presented in Figure 2 where the access to the cloud (outside) is made through a router, firewalls protect the inside network with applied rules, and on every physical machine, there are running multiple virtual machines (hosts). These hosts can be real ones or honeypots, but the mirroring is made for the ones with high interest.  
Figure 2: System model representation.  
In our system, we used notations to describe the services which could be in three states at any time:  
**State 1.**: The service \((\lambda)\) is running/opened (\(\lambda_{real}\)).
**State 2.**: The service is a honeypot (\(\lambda_{honeypot}\)).
**State 3.**: The service is a closed (\(\lambda_{closed}\)).  
The multitude of services in every state that is on a host or server can be noted with  
\[\Lambda=\{\lambda_{1},\lambda_{2},\ldots,\lambda_{n}\} \tag{14}\]  
but because of the honeypots, the services become  
\[\Lambda=\{\lambda_{11},\lambda_{12},\ldots,\lambda_{1n}\} \tag{15}\]  
In our system, there were several services provided which could be in the four states:  
**State 1.**: \(\lambda_{10}\) the service is closed;
**State 2.**: \(\lambda_{11}\) the service is opened;
**State 3.**: \(\lambda_{20}\) the user from the network cannot access the service;
**State 4.**: \(\lambda_{21}\) the user from the network can access the service.  
To define a simple strategy, let us take into consideration that a service can be real, a honeypot or closed, then from (15), we can decide when the attacker can access the services  
\[\lambda=\{\lambda_{111},\lambda_{121},\ldots,\lambda_{1n1}\} \tag{16}\]  
and when the attacker cannot access the services  
\[\lambda=\{\lambda_{110},\lambda_{120},\ldots,\lambda_{1n0}\} \tag{17}\]  
From (16) and (17), it results that the simple strategy \(\alpha\) is  
\[\alpha=\{\lambda_{111},\lambda_{110}\} \tag{18}\]  
To calculate the attacker's and defender's payoffs, we must define the following parameters with conditions  
\(G^{d}>0\);  
\(C^{a}\) is the cost of the attacker and has the relation \(G^{d}\geq C^{a}>0\);  
\(G^{h}>0\) is the honeypot's payoff;  
\(\gamma\geq 1\) the damage factor of the attacker;  
\(\eta\geq 1\) is the deceive factor of using a honeypot.  
We can calculate the payoffs for the two cases:  
**Case 1.** The defender is providing a real service on a host and the attacker can access it; then, the payoffs are  
\[G^{a}=\gamma G^{d}-C^{a} \tag{19}\]  
and  
\[G^{d}=-\gamma G^{a} \tag{20}\]  
**Case 2.** The defender is providing a fake service and the payoffs are  
\[G^{a}=-\eta G^{h}-C^{a} \tag{21}\]  
and  
\[G^{d}=\eta G^{h} \tag{22}\]  
Having a system with \(s\) services/hosts can result in the payoff matrix in Table 2.  
Using the payoff matrix described in Table 2, we can state that we have a \(m*m\) matrix \(X=(x_{ij})_{mm}\) where \(x_{ij}\) is represented by the row player's payoff when the \(i\)th strategy is picked while the column player chooses the \(j\)th strategy, and in general, we can write the following payoff matrix  
\[\begin{bmatrix}-\gamma G^{d}/s&\gamma G^{d}/s-C^{a}&0&0\\ 0&-C^{a}&0&0\\ \eta G^{h}/s&-\eta G^{d}/s-C^{a}&0&0\\ 0&0,-C^{a}&0&0\end{bmatrix} \tag{23}\]