# \"Network Sentiment\" Framework to Improve Security and Privacy for Smart Home
## 4 Network Sentiment  
The _Network Sentiment_ should not be confused with a simple reaction to an ongoing threat. On the contrary, the Network Sentiment is something that affects each user in a different way, and it should be built according to a number of parameters that are inherently user-specific.  
As an example, a user with no computers or devices of type \(X\) will not have his _Network Sentiment_ changed if there is an ongoing threat specifically targeted toward this kind of devices.  
The Network Sentiment is also aimed at evaluating and reacting to threats that are spatially or socially correlated. As an example, a port scan detected over a particular wireless network means that the attacker is physically close to the target network. As a consequence, the physically nearby networks must activate proper countermeasures.  
However, the Network Sentiment protection can be extended to non-physical spaces, such as participation in groups, e.g., social media, common interests, etc. An attack spreading through social engineering and/or social media interactions can be actively mitigated.  
As a matter of fact, the _Network Sentiment_ must:  
* Evaluate the presence of an attack (or the attack probability),
* Evaluate the means of the attack spreading, and
* Use the users similarities to strengthen the protection of the potential victims, where the users similarities refers to the attack type, network kind (e.g., devices, topology), users' behviour (e.g., use of Internet services, online social relationships), network location, etc. In order to evaluate the _Network Sentiment_, the SLU must collect several SH information e.g.,:
* The OS type and version being used in the Smart Home. This is necessary to evaluate the presence of vulnerabilities in the devices.  
Figure 3: SLU logic.  
* The user's location--to evaluate the likeliness of \"geographical correlated\" attacks (e.g., Wi-Fi password cracking attempts)
* The user's social behavior--to predict the spread of social-spreading malware, e.g., malware carried by a social platform, such as Facebook.
* Ongoing attacks (low confidence, high confidence, confirmed),
* Attack type (e.g., DDoS, fault data injection),
* Attack effectiveness (i.e., if there are infected hosts in the user network),
* Number of blocked attacks,
* etc.  
These informations can be organized in an Intrusion Detection Message Exchange Format (IDMEF) message [31] and sent to the ISP. The exact message encoding is not important in this context, but it should be standardized to allow the interoperability between different vendors. Moreover, the SLU must evaluate (CVE) reports [32] to properly block potential or ongoing threats and to suggest possible actions to the users (e.g., system upgrades).  
Thanks to the users reports, the ISP can compute different types of metrics. Some alert reports (e.g., a confirmed ongoing attack) will result in an immediate response by the system. The reaction will still be dependent on the attack type, e.g., a phishing attack could result in an alert to the 'friends' of the attacked used (measured by the mail messages, social media connections, etc.). Other attacks will need more reports, possibly by different users, to trigger a response. This is particularly true for suspicious activities that could be simply an unexpected, albeit normal, user behavior. In this case, a consensus-based algorithm can be used to evaluate the threat.  
The feedback from the SLU to the SH can be performed by IDMEF messages or, as in the previous case, any other standard message type.  
Summarizing, the exchange of the _Network Sentiment_ informs both the SH and the SCN about the ongoing attacks in the network. In this way, the whole ISP network is treated as one whole network, without the distinction between (CN) and users \(\,\)s (LANs).