## 3 Results and Discussion
### IDIVS and Information Security  
The security goals of any connected device that has sensor capabilities are to protect resources and information from potential attacks [33]. Naturally, this also applies to virtual sensors such as IDIVS and implies that the security requirements of IDIVS should be designed to safeguard the Confidentiality, Integrity, Authenticity and Availability (CIAA) of resources and information. We envisage a threat model consisting of an adversary, with a similar role and capacity to that of an interactive service user and system configurator, but with malicious motivation. The adversary can violate the CIAA security parameters, particularly by injecting malicious input content. Such input can be provided in the form of explicit user feedback, such as labels, when teaching the IDIVS. Consequently, the IDIVS may learn an incorrect model, misclassify data, and detect states that were not planned for at design time. We summarize and exemplify the main attacks targeting IDIVS as follows:  
1. [label=()]
2. Adversarial attacks. An adversary may trick the IDIVS ML components, e.g., the Online Incremental Learner, by furnishing malicious input that causes the system to make a false prediction. An example of this is having the adversary intentionally misclassify an activity type. 3. Data poisoning attacks. An adversary may manipulate the input data being used by the IDIVS in a coordinated manner, potentially compromising the entire system. An example of this is having the adversary tamper with the input data to impact the ability of the IDIVS to output correct predictions. 4. Online system manipulation attacks. An adversary may nudge the still-learning IDIVS, i.e., when operating using online learning, in the wrong direction. An example of this is having the adversary reprogram the IDIVS to capture environmental states that were not intended. 5. Transfer learning attacks. An adversary may be able to devise attacks using a pre-trained (full/partial) IDIVS model against a tuned task-specific model. An example of this is having the adversary reverse-engineer the transfer layer of the IDIVS to discover attributes, sensing modalities, and augmented target tasks from the original model. 6. Data confidentiality attacks. An adversary may be able to extract confidential or sensitive data that were used for training and teaching the IDIVS. An example of this is having the adversary observe data flows being exchanged between the IDIVS teacher and the learning components. We posit the importance of providing security-enhancing mechanisms for mitigating the aforementioned attacks, i.e., attacks (i)-(v). For mitigating attack (i), we propose the use of adversarial training to apply during the IDIVS training process; adversarial training can be conducted by the IDIVS teacher or a derivate of that role. Secure learning algorithms, e.g., algorithms that leverage obfuscation, are suggested as a strategy for mitigating attack (ii). The use of access control models, e.g., capability lists for each IDIVS, is suggested for mitigating attack (iii). To mitigate attack (iv), the transfer layer can be enhanced with functionalities that automatically alter the internal representation of the IDIVS source/target domain models. Finally, for mitigating attack (v), we suggest the use of data encryption. Data encryption is particularly useful when data is being exchanged between the user and the learning components for training the IDIVS. In addition to the identified attacks and suggested countermeasures, and similar to WSN, IoT, and traditional computer systems, the IDIVS may be prone to other attacks. These attacks may also compromise the CIAA requirements in different ways [34]. Hence, we suggest the deployment of the IDIVS, which offers as a capability (optional or otherwise) a security baseline. This baseline could implement some level of protocol and network security, identity management and access control, and fault tolerance to prevent and detect attacks.