## 8 Conclusions and Future Work
While _Bark_ is just a single approach in the filtering-based domain, as it contains basic functionality to filter inbound and outbound directions as well as local and remote devices (see Section 2.4), we deem our observations to be valid for network filtering ingeneral. To check this, we have contrasted the Smart Home in this work with a very different smart device, a modern car. Technically, the filtering--as showcased by existing works [39; 40]--also enables in this domain a fine-grained ingress and egress filtering of messages between the vehicle's inside and the outside that can withhold or mask the real values and as such limit the information that leaves the car through an OBD dongle. Looking at the results in Figure 12 for both an Intrusion Detection System (IDSys) and filtering (_Bark_), it is visible that there are many vectors and threat impacts for which _no or only low_ or only _some_ influence has been found. This suggests that many threats cannot or not sufficiently be targeted by network security approaches in the Smart Home and require security and privacy by design incorporated into Smart Home Devices (e.g., if data sent or received by the control device are disclosed due to missing encryption (_CDD_)) and deployed on external servers (e.g., to mitigate that a server makes wrong actions (SWA)). However, the results also show that filtering has a _medium_ or even _high_ influence on threats such as the extraction of private information from a device (_EPI_) or that someone executes malicious commands on a device to turn it into a bot or damage it (_RCD_). Neither Intrusion Detection Systems (IDSys) nor filtering dominates the other regarding every threat category. However, privacy filtering overall shows a larger influence than the other approaches. Overall, the results suggest that filtering-based approaches cannot prevent all threats but have an impact on many of the threats that arise in the Smart Home. Future WorkSince this topic is quite broad, many potential directions for future work can be identified; we believe that the following ones may be the most interesting:  
* **Improve the STRIDE and LINDDUN analysis**: Taking the weight of the different threat impacts or attack vectors into account when determining the influence of the filtering was out of our scope. Therefore, future work could extend the existing set of impacts with such weights, e.g., through a risk assessment or user study. Figure 12: The number of influenced impacts per influence level across all four scenarios for Virtual Private Networks (VPNs), an Intrusion Detection System (IDSys) and filtering using _Bark_. Rating the possible improvement: no/only low (grey), some (red), medium (yellow) and high (green). * **Improve the filtering rule-set generation**: Developing a filtering approach that allows for broad coverage of Smart Home Devices and their usage in everyday situations. We have briefly touched on some ideas on how to assist the end user in generating rules in Section 2.5. This could be further extended. As mentioned, the user could be assisted by allowing more dynamic, as e.g., proposed in [47], and more playful interactions with the rule set, leading to potentially temporarily bounded rule-set and thus hopefully a further reduction in threats and their impacts, for example, allowing devices only to connect to specific servers at specific times to download updates, instead of potentially pulling updates from anywhere on the Internet. This can be achieved through improved flexibility in visualisation for the manual configuration of filtering rules or by automatically generating filtering rules by the constant observation of user behaviour. Further, an automated recognition of device types, as e.g., proposed in [17], could be a desirable functionality to automatically infer the type of a new device. Rules could also be provided by a third party, allowing users to download them, facilitating a yet-to-be-designed modular rule package format.