Distributed IoT security provisioning in Critical Infrastructures with Quality of Service (QoS)
This post has been written by Sarang Kahvazadeh, PhD Researcher from Polytechnic University of Catalonia
(Barcelona, Spain), Apr. 26th
This blog entry deals with the security risks on Critical Infrastructures (CI) when IoT devices are put into play, and the impact of these risks. We also propose a distributed and decoupled security architecture to address these security risks considering also the QoS.
Nowadays, IoT devices are present in different CI such as hospitals, transport systems, nuclear plants, etc. These sensors and actuators are utilized in CI to facilitate the collection of distributed information from different locations to be processed. For example, in a hospital we find temperature sensors which are used to collect environmental temperature information to provide comfortable environment to the patients. Another example, in nuclear systems, sensors a are used to collect information from the nuclear station to check the degree of radiation and prevent any radioactive leak. Hence, the CI depend on this IoT devices to bring safety and security, to a greater or lesser extent, to the people.
In this scenario, when growing the number of IoT devices playing a role in CI, the security and privacy risks get incremental. One of the reasons of these risks is the limited computing capacity of IoT devices. IoT devices, or more specifically the single computer board or gateways where are attached, have limited computational power to handle cryptography and security provision by themselves. Therefore, IoT devices can be used by attackers to launch an attack, in terms of passive and active attacks, or get access to the collected information. On the other hand, a new challenge question arises when also considering the distributed nature of IoT devices:
“Can the conceptually centralized cloud computing handle the security requirements for the huge number of distributed devices at the edge of the network? “.
According to different academics and industrial the answer is “Yes, cloud computing with its powerful data centers can handle the security of these devices” but then “Why do still CI suffer from attacks? As the attacks happened to many hospitals, universities, transport system, etc. during 2017. Just as an example, in 2017, one attack to a hospital in England stopped the hospital network system during 24 hours, in this case the consequences might have been so terrible due to the risk in human’s lives.
On the other hand, some researchers have argued that “Traditional, centralized and far away (from the IoT devices) cloud computing is not suitable for handling security to distributed devices”. Hence, another question arises: “If cloud computing is not suitable to provide security to such amount of IoT devices at the edge of the network, how we can provide security to them?” Some proposals rely on the new emerging “fog computing” concept that brings cloud computing closer to the users and to the edge of the network. The main idea is that security can be handled closer to users (and then increasing even the privacy) and in a distributed fashion. Although, it is worth to mention that in this idea of bringing the security closer to the IoT devices, fog do not come to compete with cloud, but it comes to be complementary with cloud. Therefore, the centralized cloud and the distributed fogs must coordinate to bring a safe and secure system. The fog computing, by using the distributed computational power of devices at the edge which are usually used for analyzing, aggregating and storing data, can provide the concept of “distributed security provisioning” by means of including security controllers (SC). The security controllers will be the responsible of providing security requirements to the devices at the edge; they can be embedded in these distributed fog devices and can act as distributed security providers. As illustrate in Figure 1, devices in the fog areas will be secured by security controller embedded in fog devices.
Figure1. Distributed security controllers embedded in fog devices
Usually, when running IoT services, the Fog devices are in charge of providing real-time processing and then of bringing low-latency in the tasks of processing, aggregating and storing data from IoT devices. In this scenario, the fact of embedding the security controllers inside the fog devices can impact on the Quality of Services (QoS) provided by these IoT services. These embedded security controllers handle devices security requirements and perform cryptographic processes, which may take huge computational power of fog devices. This computational power devoted to execute security processes could reduce the fog device capacity to execute important tasks related to IoT services, and even delay services execution and increase the latency, and then not providing enough quality of service (QoS). On the other hand, if a fog device fails or it is compromised, the edge devices in that fog area can lose their security due to the fact that the embedded security controller is inside fog device.
To address these two important drawbacks when embedding security controllers in fog devices, we propose the decoupling of security controllers from fog devices; and put security controllers as a decoupled transversal security architecture. This decoupled system can provide reasonable security levels beside efficient QoS. In the new proposed architecture (Figure 2), distributed security controllers are distributed security providers for their corresponding fog areas. Each one of the distributed security controllers gets authorization from the security controller in cloud.
In this decoupled security architecture, security in the whole system is provided in a hierarchical and distributed way. Security controllers provide security requirements for fog devices and IoT devices in their area. If any security controller fails, is compromised, or attacked; the secured nearest controller gets authorization from the security controller in cloud to be in charge for that area till a new controller can be selected. All the distributed security controllers with the centralized security controller have secure communication, and also, they have secure inter-communication. As shown in Figure 2, the centralized security controller and the distributed controllers (with secure communications with red-lines) provide the security requirements to the system as a decoupled and transversal security architecture.
Can this decoupled security architecture be applied into different CI? The answer is “Yes”, the architecture can be applied into dependable CI as another dimension to provide security in a distributed and decoupled way. The security architecture is capable to provide authentication, key management, intrusion detection, abnormal behavior detection, access control, etc. for low-computational IoT-devices and fog devices in a distributed way without impacting on QoS. In a first approach, we will show how this security architecture can be applied in a Smart City which may include different CI.
Figure2. Decoupled security architecture
Moving to a real CI scenario, in Smart Cities (Figure 3), the Smart City services collect information from IoT devices which is processed by different apps to ease the citizens’ lives. The growth in the number IoT devices used by these Smart City services is being a challenge in terms of security.
Then, the question is “How do we provide the security requirements for these IoT-devices with low computational power?” Here, we propose to distribute security controllers (SC) into the city, as it is shown in Figure 3. The proposed security architecture can be applied as a transversal architecture to provide security requirements in a distributed fashion. The distributed security controllers (SC) are capable of providing security requirements such as key management, authentication, intrusion detection, abnormal behavior detection, etc. for the distributed low-computational IoT devices in the Smart City. Therefore, the Smart City concept can be developed to “Smart Secured City” to ease people’s lives with safety and security.
These distributed security controllers may be embedded or not embedded (decoupled) in some Smart City components (fog devices). For example, in a distributed but not decoupled security architecture, a SC might be embedded inside one of the Smart City’s components (fog device) with highest computational power, in order of avoid the use of a specific device for implementing the security controller (SC). However, this Smart City component might have other critical responsibilities such as real-time service execution, real-time data processing, data aggregation and storing. Therefore, this Smart City component with the embedded security controller might not be fully available to execute IoT and Smart City Services, due to high security processing usages, which will impact on the whole QoS of the system. Hence, a decoupled transversal security architecture as another dimension with separated security components from the Smart City components should be applied to the system to bring safety and security without impacting on demanded QoS.
Figure 3. Smart Secured City
Following with this example of Smart Secured City, the distributed and decoupled security controllers (SC) can be specialized in certain type of Smart City services or even devoted to secure different CI, as it is shown in Figure 4. In this scenario, each smart component in the Smart City can use a different number and type of required security controllers. For example, the smart healthcare infrastructure (and services) might use a certain number of required security controllers, specialized in eHealth services, for handling the security of the huge number of IoT devices in their environment. Aligned with this idea of having different specialized security controllers (SC) and in the case of CI, there will be SC for each one of CI, as it is shown in Figure 4. For example, we have SC for the Smart Transportation, the Smart Factory and the Smart Health CI, as well as other specialized SC for other no-critical environments in Smart Cities, such as Smart Retail or Smart Home.
Figure 4 . Secure Smart City scenario
As a kind of summary, the CIPSEC framework has been conceived either as a centralized framework, where information collected from the different CIs is analyzed and processed at cloud, or as separate deployments located at the premises of each individual CI. It looks evident that whatever the solution will be, processing the collected information near where the information is collected and actually needed, will provide substantial benefits in terms of an efficient, easy and fast decision making process. Certainly, fog computing may ease the deployment of such a distributed approach, although some challenging issues may be sorted out by considering a decoupled architecture. Indeed, with the proposed approach of a distributed and decoupled security architecture, the CIPSEC framework may be deployed in a CI (for example a Smart City) as a distributed framework, where different security controllers, scattered around the city, implement the whole CIPSEC framework. Even assuming the last approach, based on specialized security controllers (SCs), the different SCs devoted to handle security in each one of the CIs, must only implement the security features required for such infrastructure, what eases the whole deployment.
CIPSEC project results receive funding from the European Union’s Horizon 2020 Research and Innovation Programme, under Grant Agreement no 700378.
The opinions expressed and arguments employed in this publication do not necessarily reflect the official views of the Research Executive Agency (REA) nor the European Commission.