# A Survey on Cyber Risk Management for the Internet of Things
## 6 Recommendations
### Recommendations for IoT Cyber Risk Identification
For example, within organisations, healthcare, and smart grid domains, employees are held accountable for their security responsibilities, but insider threats could prevail due to employee attitude, intention and/or behaviour [102]. Meanwhile, smart homes do not contain the same vigorous regulation and training due to being private residential accommodations with increased freedoms. This means that user's have more choice in whether they ensure security and the extent to which they do so. For example, within an organisation, though two-factor authentication is not a option that must be used, it might be within a home. The approach within the work of [PERSON] et al. [67] identifies users that pose as a human vulnerability by identifying cyber hygiene components, such as high-risk behaviours and prevention abilities. Such freedoms make it harder for IoT domains to be secured, not being limited to smart homes, as smart cities rely on users to not misuse technology. How can suitable IoT threats be determined?The core difference between each IoT domain is the attack surface and type of threats that may be faced. An attack on one industry may not affect another, which is partly due to the motivations of attackers and the types of technologies typically used within them [100]. For example, within a smart home, the ease of successfully phishing and/or gaining system access [100] due to lacking cyber hygiene poses an easy reward for an attacker. In contrast, exploiting information from smart meters to smart grid operators can allow an attacker to steal energy for personal gain [103] When it comes to IoT threats, the commonly used threat modelling method is STRIDE, which is not IoT specific. The issue is that not all IoT threats are covered within the STRIDE model, thus researchers need to use additional methods to ensure that all threats are captured to fulfil the security objectives. Furthermore, applicable threats may vary within different IoT domains, which raises the question of _how suitable IoT threats can be determined_. While [PERSON] et al. [71] and [PERSON] et al. [73] use STRIDE combined with other threat models (DREAD and LINDDUN), another solution is the adoption of an existing taxonomy or threat repository that has been created for a specific IoT domain. A taxonomy useful for smart homes is given by [PERSON] et al. [22], who outline domain-specific threats, technologies, and impacts. Meanwhile, [PERSON] et al. [104] provide a taxonomy of attacks towards different types of smart grid networks. For healthcare, [PERSON] et al. [105] provide insight into the types of security risks faced by IoT health devices using layered architecture as leverage. In the context of smart cities, [PERSON] et al. [106] propose a method to classify smart city transport infrastructure threats since the implementation of smart cities is relatively new. Using taxonomies like the ones above, researchers could also assign threat attributes to explain how threats manifest, for example, threats that could propagate within an IoT domain. How can suitable IoT vulnerabilities be determined?Similar to IoT threats, IoT vulnerabilities vary within different IoT domains. IoT devices are subject to numerous weaknesses depending on manufacturing, exploits, and functionality. While vulnerabilities databases like CVE can aid in uncovering exploits, they are not IoT specific, making it a lengthy process to find and filter out suitable IoT vulnerabilities. However, vulnerability databases provide extensive data into threats, with new threats being quickly documented, thus being easy to monitor. To avoid lengthy processes, an IoT vulnerability and exploit database could be used, for example, VARIoT [107], which relies on existing databases and is not necessarily exhaustive but does allow for vendor and device model searches. Due to this, vulnerability classifications could also be used, which allows researchers to group applicable vulnerabilities for an IoT domain.