Detecting and mitigating cyberattacks using software defined networks for integrated clinical environments

The cybersecurity of medical devices and hospital network infrastructures is one of the most critical issues that current clinical environments have to deal with. As a recent example, in September 2020, a ransomware attack affecting a UK hospital caused the death of a patient who had to be moved to another hospital 30 kilometers away [9]. In this dramatic scenario, the authors of [10] identified critical shortcomings of ICE in challenging scenarios such as security, quality of service (QoS), and high availability. To improve the previous aspects, the authors of [11] presented an architecture, called ICE++, for the MEC paradigm that combined SDN/NFV. As an extension of ICE++, proposed ML-based solution able to classify several well-known families of ransomware affecting the medical devices of ICE. In addition, the proposed solution was able to detect anomalies produced by unseen families of ransomware and mitigate them by using SDN/NFV techniques. Reported experiments demonstrated a good performance in terms of detection precision and recall (92.32%/99.97%) in anomaly detection and accuracy (99.99%) in classification.

In terms of cybersecurity in ICE, the authors of [12] proposed a mechanism to protect the communication of the ICE framework by using the Data Distribution Service (DDS) standard. The authors achieved this protection through a middleware enabling critical aspects such as authentication and authorization mechanisms as well as confidentiality, integrity and non-repudiation capabilities. Experiments stated that transport-level security (TLS) does not provide enough security in scenarios were resilience against insider attacks is needed. In this sense, DDS addresses or mitigates disturb, eavesdrop, and denial of service (DoS) attacks. Another work protecting the security and privacy of architectures based on ICE was proposed in [13]. The authors proposed a cloud-based secure logger receiving data from medical devices with ICE Equipment Interfaces. Cypher mechanisms were used by the logger to operate in secure communication channels, non-trusted networks, and operating systems. Despite the added-value of the proposed solution to detect replay or injection attacks (among others), it is useless to detect attacks that do not modify network packets and messages. The authors of [14] designed and deployed an authentication architecture for medical systems compliant with ICE. The proposed architecture had three layers enabling a variety of authentication capabilities and requirements of ICE elements and networking infrastructure. Several tests demonstrated the usefulness of the authentication solution while device replacement and impersonation attacks on the OpenICE framework.

Finally, in terms of mitigation of cyberattacks using the SDN paradigm, the authors of [15] proposed the usage ovf deep packet inspection tools to analyze HTTP POST messages. The authors highlighted as relevant data the lengths of three consecutive HTTP POST messages. Later, they trained a ML classifier with samples coming from different ransomware families. The outputs of the performed experiments provided an FPR of about 4%. Another work was proposed in [16], where authors used SDN redirection capabilities and a blacklist of proxy servers to detect if infected devices communicate with proxy servers to obtain the public encryption key. They avoid this situation with the use of a flow filter to block the communication and hence the encryption of the files. The main drawbacks of this proposal are the need to keep updated the blacklist of proxy servers and the identification of those servers in advance.

SDN consists of three layers and two interlayer communication interface. In this section, we describe layer-wise SDN vulnerabilities and currently available solutions. Figure 1 presents the basic SDN architecture.

The ICE framework is a patient-centric architecture for ICS proposed in the ASTM F2761 standard. Among its benefits, it provides en interoperability of heterogeneous medical devices and applications belonging to a clinical scenario. The components making up the framework are the following ones:

This section provides an overview of the different cyberthreats affecting the ICE framework. The threat model shows a diverse range of attack surface for various types of attacks. Figure 2 shows the elements making up the ICE framework as well as their cyberthreats. In the figure, ICE Components are presented using blue blocks (filled in blue), the SDN controller and physical devices are presented using block with grey fillings. The threats surrounding a certain component in the architecture are labelled using dashed red-line.

Address Resolution Protocol (ARP) is an integral part of Internet Protocol (IP). The ARP protocol is used to resolve the network addresses of the devices connected to the network. To find neighbour devices, each device maintains a cache memory called ARP cache. In this cache, each device stores a mapping of the MAC addresses against the IP addresses of the neighbour devices (devices in the same network). This mapped helps any device to locate the nearest router and the communicating host. However, due to the lack of proper security mechanisms in the networking infrastructure, this cache can be manipulated by an adversary. This attack is known as ARP poisoning or ARP spoofing attack [28].

In our hospital room of the future, we assume that the medical device B has been infected and it acts in a malicious way to poison the ARP cache of the medical device A. To poison the ARP cache of the medical device A, the medical device B sends a legitimate flow request to the SDN Controller. The main objective of the previous action is to deploy a flow rule in the network infrastructure (switch) and establish a route to the victim device. Then, the medical device B forges a gratuitous ARP request to poison the victim APR cache. This packet contains forged header information which is used to poison the ARP cache mapping. Concretely, the modified header associates in the ARP Cache of the medical device A, the IP of the medical supervisor with the MAC address of the attacker.

After the first stage of the cyberattack, the ARP Cache of the medical device A is poisoned. Now, the attacker (medical device B), perform the same steps to poison the ARP cache of the medical supervisor. After poisoning both ARP caches, the network packets of both devices always go through medical device B (adversary). This essentially allows the adversary to view, copy or modify any data contained in network packets sent or received by both devices. At this point, the adversary can use any packet capturing tool to intercept the flow communication, for instance, Wireshark. Hence, medical device B will be able to intercept any valuable information of medical device A and medical supervisor.

To describe the impact of this stage we present the following use case. In our scenario, the medical device A uses an embedded credential to log data to the medical supervisor. The target of the adversary is to steal this embedded credential. After the devices are compromised in stage 1, the adversary uses Wireshark to capture the communication going through it. Once the device posts the credential towards the server, the flow is captured by the adversary. Even if the Apps server uses HTTPS, it is possible to decrypt the traffic to recover the credentials. Figure 4 shows the scenario and the changes after (in red) and before (in green) the attack.

In the last stage of the attack, the service disruption in the ICE network infrastructure is achieved. Stages 1 and 2, discussed above, are the prerequisites for exploiting this cyberattack. After performing stages 1 and 2, a phantom storm attack is executed to create a fake host (ghost) and fool the SDN and ICE controller [23].

Following our scenario, to launch the phantom storm attack, the adversary (medical device B) uses the ARP cache poisoning attack to introduce a fake medical device, the medical device C. To achieve it, the ARP caches of the medical device A and the medical supervisor will be updated to make them believe that there exists the medical device C. Then, the adversary sends forged packets to each medical device within the network domain. The purpose of the forged packets is to send a response to the fake medical device. The legitimate medical devices send the respective responses as packet_in messages. As the destination medical device is fake and SDN & ICE network controller is unaware of the network connection node of the fake medical device, it will start to flood packets looking for this device. The adversary will keep on sending such packets, and the controller will keep flooding the whole ICE network domain. Such a situation will cause a distributed denial of service and the disruption of regular operation of the ICE infrastructure. Figure 5 shows the scenario and the changes after the attack (in red).

The schema of the policies managed by our architecture to detect and mitigate cyberattacks affecting the SDN plane in ICE is defined as follows:

Device is the medical device managed by the policy; Metric is the parameter considered by the policy to detect the attack; Location is the geographical position in which the policy is applied; Date is optional and establishes the moment when the policy will be implemented; Result determines the countermeasures to mitigate the detected attacks; ∧ means “and”; and → means “then”. It is worthy to note that the consequent of the policy is the Result, while the rest of fields are the antecedent. In terms of results (countermeasures), for the hospital of the future hospital we point out the management of the SDN plane and ICE elements such as medical supervisors, equipment interfaces, or loggers.

The hospital room of the future (detailed in Section 4) has been emulated over VMware NSX cluster at the Advanced Cyber Security Engineering Research Centre (ACSRC), University of Newcastle. The cluster uses three Dell Power Edge M640 Server, each server consisting of two Intel Xeon Gold 6126 @ 2.6 GHz processors and 384 GB(6x64) of RAM. We have used ONOS as the SDN Controller which runs over an Ubuntu 18.04 VM and mininet to create and manage the data plane infrastructure. The ICE supervisor and ICE Equipment Interfaces devices are created using OpenICE and are mapped into the mininet virtual hosts. In this experimental set-up, the medical supervisor and two medical devices indicated in Section 4 have the following names, IP and MAC addresses:

Once having the scenario set-up, the MDB (attacker) executes the attack by using the SDNPWN script. On top of Fig. 7 it is shown the console of MDB when the ARP cache poisoning attack is executed against the MDA. On the bottom, it can be seen how before the attack the content of MDA ARP cache is right (highlighted in green) and after the attack, the target IP 192.168.56.101 in MDA was mapped to the MDB MAC address (highlighted in red).

To detect this ARP cache poisoning attack and the first concern of Section 4, the network administrator defines the next network management policy. This policy gets the catalogue of the SDN controller to obtain the IP address of the medical supervisor (MS), which was registered during the scenario set-up. After that, the policy inspects the ARP Cache of the medical device A (MDA) and checks if the IP address of the medical supervisor stored in the catalogue is the same as the one stored in the ARP cache. If not, an ARP cache poisoning attack is on-going and the policy replaces the ARP cache of the infected medical device A (MDA).

The next mitigation policy specifies the steps required by our architecture to replace the ARP Cache of MDA and mitigate the ARP cache poisoning attack.

To deploy the mitigation action, the Orchestrator module receives the notification and looks at the deployed instances to find the VM where the MDA has been deployed and the VNF implementing the ARP Cache of MDA. After finding them, the orchestrator looks at its catalog to find the descriptor of a generic VNF ARP Cache. Once detected, it checks if the VM has enough computing, storage and networking resources to allocate the new VNF (not included in the policy for simplicity sake). If so, it deploys the VNF implementing the new ARP cache and dismantle the old ARP cache (the infected one). The action is communicated to the Orchestrator component, which updates the catalogues with the information of the new VNF.

In this stage of the attack, the adversary (MDB) launches a MiTM attack towards MS and MDA. To implement it, MDB executes the ARP Cache Poisoning attack and modifies the ARP Cache of MDA and MS. After the successful attack, MDB uses Wireshark to intercept the network packets exchanged by both devices and obtain sensitive data (as shown in Fig. 8).

Regarding the second concern, which focuses on the detection and mitigation of a MiTM attack, the administrator defines the following policy to detect medical devices receiving and sending the same network packets in a short period of time. For that reason, the SDN controller gathers the packages sent and received by the medical device B (MDB) and compares the sizes and timestamps of the received and sent network packets. If their values are in a given range (predefined by the administrator), the MiMT attack is detected, and the policy replaces the MDB

The next mitigation policy specifies the steps required by our architecture to mitigate the MiMT, and replace and configure the VM and VNF implementing MDB.

To enforce the rule to replace the MDB, once notified the Orchestrator, it interacts with the VIM to deploy the new ICE Equipment Interface in the available hardware (steps 1 and 2 of Fig. 9). When the VIM gets the demand, it dismantles the VM hosting the MDB. Once the Orchestrator component receives the confirmation (step 4), it interacts with the VIM to create a new VM to host the new MDB (step 5). When the VIM receives the notification, it creates a new VM with the MDB (ICE Equipment Interface) on top of the existing infrastructure (step 6). The action is confirmed (step 7) and the Orchestrator component updates the instances and catalogues. Once the new MDB is deployed, the Orchestrator sends the configuration of the virtual medical device to the VFM (step 8). THe IP address of the medical supervisor or the frequency of communication are some of the parameters exchanged during the previous communication. After that, VFM configures the MDB with those parameters and when the configuration is finished, the FVM and the Orchestrator receives the confirmation (steps 10 and 11).

In this attack, the adversary (MDB) uses the SDNPWN toolkit to launch a phantom-storm attack. As described in Section 4.3, the malicious script creates a fake or phantom host, which IP address is 192.168.56.104. This fake host sends a fake communication request to the medical supervisor and the MDA device. After that, both the medical supervisor and MDA requests the SDN controller to establish a communication with the phantom host. However, in this scenario, there does not exist any legitimate device with the IP 192.168.56.104. Hence, the controller is unaware of the physical connection point of this particular device. Finally, the SDN controller floods the network with packets searching for 192.168.56.104. Figure 10 presents a successful Phantom-storm attack. In the GUI interface, it is visible that a single host has two IPs assigned in the same interface. This behaviour is due to ONOS GUI classifying the hosts, based on the packet source.

To demonstrate the impact of this attack, we have measured the average delay between the MS and MDA before and after the attack. The average delay before the attack was 0.042ms and after the attack became 0.296ms, more than 500%. It is important to note that we have considered a small network with four hosts and having a larger network with much more devices, the delay will increase.

To address the third and last concern of Section 4, the administrator of our architecture defines the following policy able to detect and mitigate the phantom storm cyberattack.

This policy obtains the network topology through the SDN controller, after that it monitors the network packets traveling across the network to check if destination device belongs to the network, or in contrast it is a ghost. If so, the policy detects the phantom storm attack and discard the network packets with the IP of the ghost medical device. To discard those network packets a OpenFlow rule drooping the network packets to MDB.

The aim of this section is to measure the performance of the proposed solution when replacing an infected medical device due to the cyberattack detailed in Section 4. With that goal in mind, we performed several experiments measuring the time required by our architecture to deploy and launch a VM. Previously, the VM has been configured with different operating systems and an instance of OpenICE that simulates the behaviour of a medical device (steps 5 and 6 of Fig. 9).

In order to measure the architectural performance, we have considered the following two different hardware configurations:

Considering the two previous hardware configurations, we have followed the next steps to measure the performance of our solution:

Table 1 shows the times obtained for the deployment and initiation of the ICE Equipment Interface running on top of different software and hardware configurations.

The main conclusions obtained after performing the previous experiment is that the time required to deploy the ICE Equipment Interface is inversely proportional to the amount of computational resources needed. As can be seen in Table 1, the selection of the operating systems is also an important decision. Specially in integrated clinical environments where the time is critical to ensure the patients’ safety.

In conclusion, this section has demonstrated that the proposed architecture and its associated policies are able to detect the different phases of a relevant cyberthreat affecting the SDN paradigm. Furthermore, the mitigation mechanism adopted by our architecture is able to replace an infected medical device in a time ranging from 6.864 s to 15.946 s depending on the underlying hardware and operating system. Also, it is important to keep a trade-off between the purpose of the clinical scenario and the selection of hardware and software to virtualize medical equipment.