The proposed solution detects and classifies in real time well-known and unseen ransomware attacks in ICE by analysing the network flows generated during their spreading phase. In addition, once the ransomware has been detected and classified, the proposed mechanism automatically mitigates it by using NVF/SDN techniques to isolate and replace infected devices, avoiding the ransomware spreading across the clinical network. Specifically, we isolate infected medical devices though the SDN paradigm as well as replace their software controllers using NFV techniques. Both the detection and mitigation mechanisms are fully integrated into our previous work, the ICE++ architecture. The ICE++ architecture combines the MEC paradigm with the SDN and NFV techniques to deploy and control in a flexible and efficient way the components making up the hospital room of the future.

Another relevant contribution of this article is a set of experiments that demonstrate the effectiveness of our solution detecting some of the most recent and dangerous malware (namely, WannaCry, Petya, BadRabbit and PowerGhost). In this sense, the selected techniques for both anomaly detection (One-Class Support Vector Machine) and ransomware classification (Naïve Bayes) obtained a high precision with known and unseen ransomware samples. Additional experiments demonstrated the viability of the proposed solution in terms of time. In the worst case, our solution detected and mitigated a ransomware attack in less than 30 seconds, which is an acceptable time because the fastest ransomware required more than 1 minute to spread and infect ICE devices. Additionally, as a final contribution, below we provide a publicly available labelled dataset containing the netflows acquired from our ICE configuration for both clean and ransomware propagation traffic.

The following tables provide relevant information about the configuration of our hospital room of the future scenario. Table 1 provides the dataset files containing the network traffic of our clinical environment (clean and infected with )in different formats: pcap and labelled binetflow generated with Argus 3.0.8 (https://qosient.com/argus/argusnetflow.shtml). Table 2 shows information about our scenario configuration in terms of IPs, operating systems, and infected machines. Finally, Table 3 shows the different configuration files needed to generate the binetflow from the pcap file using Argus. The file argus.conf is used to generate the binary argus file and ra.conf is used to generate the binetflow file. In this sense, the argus.conf file is configured to periodically report flow activity every 10 seconds.