ABSTRACT
In Internet of Things (IoT), the main driving technologies are considered to be tiny sensory objects. These objects cannot host traditional preventive and detective technologies to provide protection against the increasing threat sophistication. Furthermore, these solutions are limited to analyzing particular contextual information, for instance network information or files, and do not provide holistic context for risk analysis and response. Analyzing a part of a situation may lead to false alarms and later to unnecessary and incorrect configurations. To overcome these concerns, we proposed an event-driven adaptive security (EDAS) model for IoT. EDAS aims to observe security events (changes) generated by various things in the monitored IoT environment, investigates any intentional or unintentional risks associated with the events and adapts to it autonomously.
It correlates different events in time and space to reduce any false alarms and provides a mechanism to predict attacks before they are realized. Risks are responded to autonomically by utilizing a runtime adaptation ontology. The mitigation action is chosen after assessing essential information, such as the risk faced, user preferences, device capabilities and service requirements. Thus, it selects an optimal mitigation action in a particular adverse situation. The objective of this paper is to investigate EDAS feasibility and its aptitude as a real-world prototype in a remote patient monitoring context. It details how EDAS can be a practical choice for IoT-eHealth in terms of the security, design and implementation features it offers as compared to traditional security controls. We have explained the prototype’s major components and have highlighted the key technical challenges.
PROPOSED ARCHITECTURE
Figure 1. Abstract diagram of event-driven adaptive security architecture (EDAS) architecture
EDAS is an autonomous risk-based event-driven adaptive security architecture for IoT. It monitors security changes, i.e., thing-generated events, in the IoT environment, analyzes the associated threat(s) and adapts appropriate and optimized security configurations against the risk faced. At the abstract level, EDAS complies with the IBM autonomic control loop that consists of the sensing, analyzing, planning and execution components. It consists of two major components: The EDAS platform and the event sources, as shown in Figure 1.
EDAS PROTOTYPE SPECIFICATIONS
Figure 3. Prototype environment
Encrypted patient body temperature values are collected using a wearable temperature sensor, which are communicated to the hospital site via a smartphone as a relay device. In the patient domain, an app on the smartphone receives, parses and directs temperature readings and any security event generated by the sensor to their respective event databases. The temperature values are extracted by the hospital health application, where they are decrypted and displayed as a continuous real-time graph for medical diagnosis. The security events are pulled by the EDAS platform to investigate and respond to any potential threats. The EDAS platform is a standalone system contained in the hospital-controlled domain. A context diagram of the environment is shown in Figure 3.
Figure 4. Event source abstraction
An event source, a thing in the EDAS context, can be visualized in functional layers, as shown in Figure 4. The application layer contains the actual application(s), temperature sensing in our case, along with the necessary security components, tools and protocols. The processing layer must have at least two components for EDAS to work efficiently, an event framework and a local adaptor. The Event Framework typically comes as an out-of-the-box service with most applications and includes an event handler and a logging utility.
CASE STUDY
Figure 13. Adapting security to low availability/confidentiality risks
The case study is based on a general phenomenon that encrypting messages consumes more energy if longer key lengths are utilized and vice versa. Pre-shared keys and respective indexes are used in the case study. A higher index corresponds to a key with increased length. The state transition diagram depicting the case study security adaptation is shown in Figure 13. Stable State 1 is assumed to be the initial state. Different cipher key lengths for encrypting medical data are adapted when the Low Battery or Charging Up events are generated by the temperature sensor.
Figure 14. Scenario 1: sensor screen: decreased key lengths are adapted when battery level drops
Low availability (context or directive) risk is raised when there is a Low Battery event with the level being less than X %, and the encryption is still done with an increased key length. The corresponding risk is reduced when a Key Changed event is generated by the event source (temperature sensor) after a reduced encryption key length is adapted. The corresponding screenshots are displayed in Figures 14 and 15.
FEASIBILITY AND EVALUATION
This section evaluates EDAS as an event-driven security concept and system architecture and will detail lessons learned from the prototyping activity. We will discuss how EDAS can be the right tool for ensuring real-time risk management in dynamic environments, such as IoT, and how it complements existing ICT infrastructure. Moreover, EDAS is compared with architectures corresponding to traditional security controls to investigate its feasibility as a viable solution for IoT.
RELATED WORK
Since IoT comprises diverse technologies with varying capacities, there is a need to design appropriate architectures and mechanisms, such that information sharing and communication can be made more efficient. Credible work has been concluded in this regard, while others are still under research. Below, we discuss a few of them. The Open IoT project details an open source architecture that aims to connect Internet-enabled things with cloud computing, thus enabling ICT companies to offer sensor-based solutions.
The architecture of consists of three layers, namely application, virtualization and physical plane. The cloud computing capabilities are placed in the virtualization plane. Sensor middlewares are placed in the physical plane, which collects, filters and normalizes sensors data and communicates them to the cloud. The application plane contains utilities that enable users to control and monitor the sensor. These utilities also control requests made from connected services.
DISCUSSION AND FURTHER WORK
Figure 18. EDAS utilization in Open IoT architecture
As an example, Figure 18 instantiates how EDAS can be utilized in the Open IoT architecture in the context of IoT-eHealth. The first row represents the Open IoT architecture itself and the distribution of different things, services, applications and utilities it employs at each plane it describes. The second row shows the IoT-eHealth and its corresponding elements as a possible application archetype of the Open IoT architecture. The last row specifies the possible implementation of EDAS and its components in the Open IoT. The physical plane will encompass the event sources, i.e., the monitored assets, such as sensors, smart devices and their event frameworks.
CONCLUSIONS
We have explained and evaluated the feasibility of an autonomous event-driven adaptive security prototype based on our proposed architecture. We have expressed how our proposed concept of event-driven security and adaptation ontology ensures context-aware adaptation and complies with device capabilities, as well as user, QoS and security preferences. In the evaluation, there is potential evidence that EDAS, with its event-driven concept and adaptation control loop, is satisfying the requirements needed for managing risk in a dynamic environment, such as the IoT. It provides a real-time risk management platform and ensures autonomous and context-aware adaptive security. We have suggested that traditional security controls are not feasible for IoT in terms of resources and security.
However, they can be still used in the traditional settings and can provide input to EDAS for security analysis, as they have a mature set of event frameworks. Hence, EDAS also motivates the merger of traditional enterprise architecture with the thing world: for instance, merging traditional eHealth systems with remote patient monitoring with wearable sensors to make the health system more reachable, accessible and efficient. Critical development and implementation issues, such as secure and reliable event communication, protecting the architecture and metrics required for adaptation, are highlighted, which can be further explored to make EDAS a more reliable solution for IoT-enabled services.
Source: Gjovik University
Authors: Waqas Aman | Einar Snekkenes
>> 200+ IoT Led Projects for Final Year Students
>> IoT Environmental Monitoring System for Smart Cities Projects for Students