IEEE INTERNET OF THINGS JOURNAL, VOL. 6, NO.

5, OCTOBER 2019 8005

Security Management Architecture for

NFV/SDN-Aware IoT Systems
Alejandro Molina Zarca, Jorge Bernal Bernabe , Ruben Trapero, Diego Rivera, Jesus Villalobos,
Antonio Skarmeta , Stefano Bianchi, Anastasios Zafeiropoulos, and Panagiotis Gouvas

Abstract—The Internet of Things (IoT) brings a multidisci- makes the IoT subject to new kind of vulnerabilities and cyber-
plinary revolution in several application areas. However, security threats. Traditional network protocols and security solutions
and privacy concerns are undermining a reliable and resilient are not suitable for IoT, as they do not cope with unforeseen
broad-scale deployment of IoT-enabled critical infrastructures
(IoT-CIs). To fill this gap, this paper proposes a comprehensive interoperability and adaptability problems and do not meet the
architectural design that captures the main security and privacy dynamic needs, responsiveness, and lightness required in IoT.
challenges related to cyber-physical systems and IoT-CIs. The The lack of automatized software updates, vendor support
architecture is devised to empower IoT systems and networks to as well as user’s misconfigurations make the IoT prone to
make autonomous security decisions through the usage of novel new kind of cyber-attacks. These problems and their conse-
technologies such as software defined networking and network
function virtualization, as well as endowing them with intelligent quences are aggravated in IoT-enabled critical infrastructures
and dynamic security reaction capabilities by relying on monitor- (IoT-CIs), like energy systems in smart buildings. In this con-
ing methodologies and cyber-situational tools. The architecture text, there is a need of advanced and adaptive mechanisms able
has been successfully implemented and evaluated in the scope of to ensure dynamically the proper security levels in the IoT
ANASTACIA H2020 EU research project. systems and providing system resiliency through self-healing
Index Terms—Architecture, cyber-security, Internet of Things and self-repair capabilities, thereby countering cyber-attacks
(IoT), software defined networking and network function virtu- and mitigate cyber-threats whenever occur in the managed IoT
alization (SDN/NFV). network.
In this sense, contextual and monitoring information
obtained from the surrounded IoT environments can be used
I. I NTRODUCTION as baseline for data analysis detect anomalous behaviors, and
in turn, infer smart control and management decisions through
HE INTERNET of Things (IoT) [1] is changing the
T industrial landscape by leveraging network capabilities
of heterogeneous, pervasive, and autonomous smart-objects.
different actuators, agents, and controllers deployed either at
the edge or in the core of the IoT network. Indeed, this contex-
tual and real-time monitoring can be also applicable to deal
IoT promotes a distributed global network with billions of with diverse kind of cyber-threats and IoT attacks, thereby
devices interacting using machine-to-machine (M2M) com- countering them by adapting the security policies and enforced
munications, which facilitates the creation of innovative smart configurations of the managed IoT system according to the
services and applications. context [2].
However, the constrained nature of IoT devices and Software-defined networking (SDN) brings forward new
networks as well as their distributed and pervasive conditions, network capabilities by decoupling the control and data planes,
Manuscript received October 12, 2018; revised January 25, 2019; accepted which can introduce novel security defense mechanisms in
February 28, 2019. Date of publication March 11, 2019; date of current ver- IoT such as managing malicious traffic or IoT devices iso-
sion October 8, 2019. This research was supported in part by the H2020 lation. Likewise, network function virtualization (NFV) can
EU project ANASTACIA, Grant Agreement N 731558 and in part by a
postdoctoral INCIBE grant within the “Ayudas para la Excelencia de los exploit virtualization to provide on-demand, dynamic, flex-
Equipos de Investigacíon Avanzada en Ciberseguridad” Program, with code ible, scalable, and elastic orchestration and deployment of
INCIBEI-2015-27363. (Corresponding author: Jorge Bernal Bernabe.) virtual appliances. NFV can enable the autonomous manage-
A. Molina Zarca, J. B. Bernabe, and A. Skarmeta are with the Department
of Information and Communications Engineering, University of Murcia, ment of virtual network security functions that can off-load
30003 Murcia, Spain (e-mail: [email protected]; [email protected]; the security of IoT networks to the network edge. In this
[email protected]). sense, Yu et al. [3] introduced virtualized versions of secu-
R. Trapero and J. Villalobos are with the Cybersecurity Laboratory,
ATOS Research and Innovation, 28037 Madrid, Spain (e-mail: rity hardware, e.g., firewalls, DPIs, as well as support mobile
[email protected]; [email protected]). IoT scenarios.
D. Rivera is with the R&D Department, Montimage, 75013 Paris, France Some researches are starting to define architectures aimed
(e-mail: [email protected]).
S. Bianchi is with the Research & Innovation Department, Softeco Sismat to deal with cyber-situational network and system manage-
Srl, Genoa, Italy (e-mail: [email protected]). ment by exploiting SDN and NFV features in dedicated
A. Zafeiropoulos and P. Gouvas are with the R&D Department, scenarios-environments, such as 5G network management [4]
UBITECH, 15231 Athens, Greece (e-mail: azafeiropoulos@
ubitech.eu; [email protected]). or cloud/fog computing [5] applications. However, unlike our
Digital Object Identifier 10.1109/JIOT.2019.2904123 proposed architecture, those ones have not been tailored for
2327-4662 c 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.
See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY WARANGAL. Downloaded on August 26,2024 at 12:26:22 UTC from IEEE Xplore. Restrictions apply.
 8006 IEEE INTERNET OF THINGS JOURNAL, VOL. 6, NO. 5, OCTOBER 2019

dealing with the security and privacy in SDN/NFV-enabled networks. Yu et al. [3] presented IoTSec, an IoT security archi-
IoT and critical cyber-physical systems (CPSs) scenarios. tecture that allows delivering micro-middleboxes, instantiated
This paper presents an architecture aimed to deal with the on demand over lightweight IoT systems. NFV enables scaling
security management of SDN/NFV-enabled IoT scenarios. The up/down security VNFs at the edge of the network, such as, for
architecture has been already implemented and evaluated in instance, vFirewalls and vIDS, according to the network and
critical infrastructures (CI) deployed in smart buildings, com- system status. SDN can be used along with NFV to steering
ing up with a policy-based cyber-situational security frame- the traffic toward VNFs, optimizing the chaining of virtualized
work that has demonstrated its benefits to adapt dynamically middleboxes and enhancing resource utilization.
the enforced security mechanisms of IoT networks. The auto- Yang and Fung [14] detailed the challenges, opportunities
matic reaction against IoT threats and attacks is done through as well as security issues in NFV. Similarly, other recent sur-
special purpose IoT agents, SDN and IoT controllers as well as veys [15], [16] recap the main benefits of adopting SDN and
NFV-based virtual security appliances, which enforce reaction NFV to increase security in IoT networks.
countermeasures needed to mitigate cyber-attacks and dynam- The aforementioned research works, unlike ours, do not pro-
ically adapt the system according to the context obtained vide a holistic cyber-security framework that relies on SDN
and analyzed by the integrated monitoring tools and security and NFV in order to enhance IoT security. The framework is
information and event management (SIEM) system. able to dynamically detect cyber-security incidents and react
The rest of this paper is structured as follows. Section II according to the actual status of IoT networks, systems and
studies the current state-of-the-art in this research field. deployed security policies.
Section III delves into the main IoT attacks/threats as well Regarding policy-based frameworks, Shankar et al. [17]
as detection and reaction mechanisms proposed. Section IV proposed a framework which relies on an extended model
details the proposed architecture whereas Section V describes of event-condition-action policies in order to include post
its main architectural processes. Section VI is devoted to the conditions to verify the successful completion of pol-
implementation of the proposed architecture, which is eval- icy actions. Rensing et al. [18] provided a policy-based
uated in Section VII. Finally, Section VIII concludes this architecture and framework specific for AAA services.
paper. Hadjiantonis et al. [19] adopted a policy-based network man-
agement together with context awareness for mobile ad hoc
networks and Shaw et al. [20] provided a policy-based frame-
II. R ELATED W ORK work management for securely deployment and configuring
SDN is starting to be exploited as mechanism to han- components which processes network traffic.
dle security threats [6], as it provides numerous advantages A first overview of ANASTACIA was presented at
such as dynamic flow control, IoT traffic, and devices isola- the beginning of the project in [21], which outlined the
tion, network monitoring to identify attacks (e.g., botnets) and main objectives, challenges, and foundations of the project.
flexibility to support deployment of virtual network security Similarly, a first insight about how SDN/NFV-based can be
functions. exploited to provide security features over IoT scenarios
In this sense, Rawat and Reddy [7] proposed diverse secu- was presented in [22]. The ANASTACIA policy enforce-
rity threats and attacks and how they can be mitigated using ment mechanism was recently detailed by Zarca et al. [23].
proper countermeasures based on SDN. An SDN architecture However, unlike in the research described herein, those
to strengthen the IoT is presented by Chakrabarty et al. [8]. previous publications did not present the whole final archi-
It aims to protect IoT communications by relying on the SDN tecture and did not deal with the entire autonomic loop for
centralized controller delivering secure routing and enhancing self-protection and self-healing of the IoT managed system.
system management. Bull et al. [9] used IoT traffic monitored Moreover, the monitoring, detection, and the reaction policies
from SDN gateway, for detecting misbehavior in the network to counter cyber-attacks were not addressed neither evaluated.
and reacting accordingly, either by blocking or forwarding
the traffic. Flauzac et al. [10] delivered an SDN security
solution for IoT wireless networks, that is intended to avoid III. S ECURITY H ANDLING IN NFV/SDN-E NABLED
compromising a security domain by deploying security rules I OT S CENARIOS
throughout different security controllers. Choi and Kwak [11] This section gives an overview of the main threats and
described software-defined security framework for IoT that vulnerabilities in IoT, enlightening how our proposed frame-
allows delivery of security appliances, e.g., access control or work detects, and reacts against those threats/attacks by using
channel protection, however, they do not exploit NFV. NFV/SDN-based security enablers. Table I summarizes those
On the other side, NFV can realize the security as a service concepts.
paradigm [12], abstracting security software from hardware, to IoT attacks can be split in two main categories: 1) active
achieve performance improvement on virtual network security where malicious attacker alters or injects messages to exploit
functions. Lightweight virtualization enables deployment of vulnerabilities and 2) passive where the attacker interacts
virtual network functions (VNFs) at the edge of IoT networks. actively within the network.
For instance, Al-Kaseem and Al-Raweshidyhamed [13] pro- Regarding active attacks, it is work mentioning the replay
vided a solution based on SDN, NFV, and cloud computing attack (retransmission of previous victim’s packets) that aims
that can enhance network management in 6LoWPAN IoT to perform a disservice or enable other more advanced attacks

Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY WARANGAL. Downloaded on August 26,2024 at 12:26:22 UTC from IEEE Xplore. Restrictions apply.
 MOLINA ZARCA et al.: SECURITY MANAGEMENT ARCHITECTURE FOR NFV/SDN-AWARE IoT SYSTEMS 8007

TABLE I
M AIN I OT T HREATS /ATTACKS AND O UR S UGGESTED P OTENTIAL D ETECTION AND R EACTION M ECHANISMS BASED ON NFV-SDN

such as masquerading attacks or impersonation, which in turn, the network traffic in the source, that is, by deploying vFire-
aims to get victims’ data and/or replicate nodes. In a tamper- walls that filter traffic coming from infected devices or just
ing attack, the attacker node makes an unauthorized/malicious stop the affected device if possible. Network traffic can be
action against the IoT device. In our framework, these kinds also filtered directly by the SDN controller in the virtual switch
of attacks can be detected by the AAA system and analyzing (that can be also deployed on demand in the edge as VNF). In
the logs, the applicable countermeasure might perform device addition, a virtual IoT honeynet deployed as VNF can emulate
flashing or its network isolation. vAAA and special agents the real IoT network, and the attacker can be redirected to such
can be dynamically deployed in the edge of the IoT network a controlled honeynet, thereby countering the potential dam-
to facilitate authentication, authorization and key management age. In any of the cases, the traffic is diverted to the vFirewall,
redistribution. or vIoTHoneyNet adding new flow rules using SDN.
IoT devices infected with malware, e.g., worms, trojans, and Malicious code injection in memory or in services, e.g.,
ransomware can be detected through vulnerability assessment SQL injection, can alter normal IoT and services behavior,
and the countermeasures. When it comes to the protection of and it can be detected through monitoring tools that identify
the rest of the IoT system/network, it lies on measures such unwanted network accesses, or unexpected queries/accesses in
as updating the firmware, isolate device, and block connection databases/services. Our architecture aims to mitigate this kind
attempts. of attack by isolating attackers traffic using SDN.
Zero-day vulnerabilities refer to exploitation of software On the other hand, regarding passive attacks such as traffic
vulnerabilities not seen before in the network. They are analysis or sniffing/eavesdropping private IoT communica-
extremely difficult to detect and mitigate. Our proposed frame- tions, our framework detects those problems through deep
work covers the detection and handling of this kind of attacks packet inspectors deployed as security VNFs that detect
by means of artificial intelligence-based (AI) anomaly detec- encrypted traffic. The SDN controller can mirroring the traf-
tion. For example, IoT devices malfunctioning and reporting fic toward the vDPI for analysis. The countermeasure can be
unusual sensors values can be detected through machine learn- deploying vChannelProtection VNFs, to facilitate rebootstrap-
ing of IoT data in context broker. The countermeasure is ping of encryption keys and establishing encrypted network
done through special-purpose IoT controllers that act directly tunnels (e.g., using DTLs), either, end-to-end or through
on the malicious IoT device, using protocols like CoAP vProxies.
or LWM2M. As identified by Gao et al. [25] there are other specific
Man-in-the-middle attacks allow malicious entities to inter- attacks such as, for instance, routing attack, sink node attack,
cept communications and impersonate endpoints, to spoof and black hole attack, flooding attack, trapdoor, and Sybil attack,
alter packets, e.g., modifying IoT sensors values to produce but they can be handled in a similar way that the ones
damages. Like in the previous case, it can be detected through summarized above.
AI-based anomalous detection tools, and counter through IoT
controllers actions over final devices and agents.
Distributed DoS attacks are perpetrated by infecting IoT IV. A RCHITECTURE
devices with malware which, in turn, make them become ANASTACIA is envisioned as a framework integrated on
part of botnets that launch massive and coordinated DoS top of an IoT infrastructure where IoT devices, physical and
attacks against external victims [24]. DoS can also target IoT virtual network elements interact in the data plane. On top
networks, flooding, and exhausting them, and causing ser- of that, a control plane manages the computing, storage, and
vice unavailability. In our proposed architecture, this can be networking resources in the data plane by leveraging SDN
detected by a vIDS and special IoT agents. The countermea- controllers, NFV orchestration platforms, and IoT controllers.
sures based on NFV/SDN can be manifold in this case, either The ANASTACIA architecture is shown in Fig. 1. It is
deploying vLoadBalancer next to the victim entity, or stopping comprised of diverse planes that provides the intelligence and

Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY WARANGAL. Downloaded on August 26,2024 at 12:26:22 UTC from IEEE Xplore. Restrictions apply.
 8008 IEEE INTERNET OF THINGS JOURNAL, VOL. 6, NO. 5, OCTOBER 2019

Fig. 1. ANASTACIA reference architecture.

dynamic behavior to the system. Namely, the security orches- the enforcement of the SDN traffic flow rules received as
trator plane, monitoring and reaction plane, security enforce- outcome of the policy refinement process.
ment plane, user plane, and seal manager. The following 2) NFV-Oriented Security Enforcement Plane Interface:
section details each plane and its domains. This allows to manage the security VNFs via the ETSI-
oriented NFV MANO modules. This is, the Security
A. Security Enforcement Plane Orchestrator maintains the knowledge about the VNF descrip-
The control and management domain oversees and con- tors, the network services (NSs) catalogue as well as the
trols the usage of resources and run-time operations of the current deployment. When a VNF management is required,
security enablers deployed either over virtualized or physical the security orchestrator requests it by sending the configura-
environment, including IoT networks. It connects the orches- tion to the NFV MANO through the NFVI. Then, the NFV
tration plane with the IoT platform (data and control planes), MANO uses the resource orchestrator (RO) in order to provide
managing the interactions among objects and components for the required resources to cope with the received configuration
the enforcement of the security policy defined at the user through a specific virtualized infrastructure manager. Finally,
plane. The SDN controllers are responsible of communicating the RO requests the VNF configuration enforcement to the
though southbound APIs with the network elements to manage VNF configuration and abstraction. More information on this
connectivity applying the networking flow rules. NFV ETSI topic can be found at [23].
MANO-compliant modules are responsible for management 3) IoT-Oriented Security Enforcement Plane Interface:
and orchestration of the virtual network and security vir- This manages the configuration of IoT nodes through the IoT
tual functions over the virtual infrastructure, e.g., Openstack. controllers. The security orchestrator can request the enforce-
Finally, IoT controllers provide different southbound interfaces ment of the security controls within the IoT nodes according to
in order to manage and control different kind of IoT devices the configurations generated by the policy refinement process.
depending on the IoT protocols. These IoT controllers are The infrastructure and virtualization domain comprises all
deployed at the network edge (e.g., gateways) to enforce secu- the physical machines capable of providing computing, stor-
rity functions in heterogeneous IoT domains. Regarding the age, and networking capabilities, as well as the virtualization
main interfaces in this domain it is important to highlight the technologies, to provide an infrastructures as a service layer.
following ones. This domain also includes the network elements responsible
1) SDN-Oriented Security Enforcement Plane Interface: for traffic forwarding, following the SDN controllers rules,
This allows to manage the SDN networking configuration via and a distributed set of security probes for data collection to
the SDN controller(s). The security orchestrator can request support the monitoring services.

Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY WARANGAL. Downloaded on August 26,2024 at 12:26:22 UTC from IEEE Xplore. Restrictions apply.
 MOLINA ZARCA et al.: SECURITY MANAGEMENT ARCHITECTURE FOR NFV/SDN-AWARE IoT SYSTEMS 8009

VNF domain represents the VNFs enforcing the security Namely, performs the refinement processes from high-level
within NSs. Anastasia currently considers diverse kind of security policy language (HSPL) to medium-level security
network security functions deployed as VNFs in order to policy language (MSPL). These security policy models have
provide the defense mechanisms and threat countermeasures, been extended from [26]. Finally, the MSPLs are translated to
including vFirewall, vIDS/IPS, vAAA, vChannelProtection, enablers/VNFs configurations or tasks.
and vIoTHoneyNet. The high to medium interface allows to request a policy
IoT domain refers both, to the final IoT devices as well as refinement from an HSPL to an MSPL. The medium to lower
the the security enablers and actuators required to apply the interface allows to request a policy refinement from an MSPL
security directives within the IoT devices. To this aim, the to a specific enabler configuration/task.
orchestration plane (either as proactive policy enforcement by Security enabler provider plugin interface allows to request
the admin, or as reaction), will apply, over the IoT controller for a plugin which implements the MSPL to enabler
the appropriate security service, which, in turn, will contact translation.
the final IoT device or actuator by using specific IoT protocols. Currently, the framework provides security policy models
for authentication, authorization, channel protection (validated
in [27]), filtering, traffic divert, monitoring, IoT management,
B. Security Orchestration Plane IoT honeynet, anonymity, privacy (identity-based, attribute-
The security orchestrator plane organizes the resources that based, and PKI-based), QoS, data aggregation, and policy for
support the enforcement plane, carrying out activities such as orchestration. In order to prevent conflicts between the security
the transformation of security properties to configuration rules policies, the framework provides a policy conflict detection
(through a policy interpreter) and aligning the security poli- engine which verifies that the security policy will not gen-
cies defined by the policy interpreter with the provisioning erate conflicts like redundancy, priorities, duties (e.g., packet
of relevant security mechanisms (through a security enabler inspection versus channel protection), dependencies, or contra-
providers). It has the whole vision of the underlying infrastruc- dictions. To this aim, the security policy is processed against
ture in order to orchestrate (through the security orchestrator) the rule engine which extracts context information from the
resources and interfaces available at the security enforcement policy repository and the system model in order to perform
plane. the verification.
The security enabler provider is able to identify the list of Regarding the policy for orchestration, the framework
security enablers which can provide specific security capabil- allows the security administrator to define multiple security
ities to meet the security policies requirements. Besides, this policies related between themselves and with the already
component will be endowed with an interface for delivering deployed ones by establishing priorities and dependencies.
medium-to-low translation plugins for technology dependant This is, the security administrator can establish different level
policy translations into low-level configurations. In this way of priorities depending on the magnitude or relevance of the
any kind of software or hardware could be supported as secu- policy. On the other hand, since the enforcement of a security
rity enabler by implementing the corresponding translator plu- policy can be conditioned by the deployment of another pol-
gin. Currently, the framework provides plugins focused on the icy or even by the triggering of any kind of event, the security
current experimentation phase, encompassing network filter- administrator is able to specify different kind of dependen-
ing and forwarding through SDN and virtual router, XACML cies depending on the deployment requirements (e.g., an
authorization, IoT management through the IoT controller, IoT authorization policy could depend on a success authentication
honeynet configuration, and DTLS configuration. event).
A security orchestrator is responsible for selecting the secu-
rity enablers to be used in the policy refinement process. To
choose the proper security enabler to apply in a particular C. Monitoring and Reaction Plane
situation (e.g., after a reaction), it oversees the security capa- The monitoring and reaction plane connects to the IoT plat-
bilities, the available resources in the underlying infrastructure, form through the security enforcement plane in order to col-
and the policy requirements. Once received the configuration lect, through monitoring agents, security-focused information
of the security enablers by the policy interpreter, the security related to the system behavior. This plane also evaluates the
orchestrator interacts with relevant SDN/NFV/IoT control and fulfilment of the security policy by checking security models
management components, so to enforce the required features and threats signatures, performing filtering activities and data
in the IoT devices and in the physical/virtual network elements analysis for the detection of anomalies. At this plane, and
of the underlying infrastructure. based on the anomalies detected, reactions are designed to
The SMI interface (security orchestrator system model) mitigate such anomalies through the mitigation action service
allows to request a system model of the underlying architec- (MAS) that is directly connected to the service orchestration
ture. This information will be used by the security orchestrator plane. Reactions are designed based on the security model
in order to make decisions like what could be the best security analysis of the IoT/CPS infrastructure—which determine the
enabler for a specific policy enforcement. set of possible actions to enforce, and the capabilities of the
The policy interpreter transforms the security policy (closer network that is being monitored. The specific reaction chosen
to a human readable policy) to a machine-readable policy is based on a decision support system that evaluate the con-
that is able to represent lower configurations parameters. venience of the reaction depending on the available resources.

Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY WARANGAL. Downloaded on August 26,2024 at 12:26:22 UTC from IEEE Xplore. Restrictions apply.
 8010 IEEE INTERNET OF THINGS JOURNAL, VOL. 6, NO. 5, OCTOBER 2019

Additionally, alerts and other reports are available for system plan. On the other hand, the reactive approach rises the policy
administrators through a security alert service. enforcement as part of an automated security countermeasure.
The monitoring and reaction plane acts the security-enabling Our previous work [23] already showed the main flow
member of the architecture, providing monitoring and self- for the policy-based security enforcement in the proactive
reaction capabilities to the platform. To this end, the plane approach. In this case, the security administrator defines an
needs to communicate with other modules, using different HSPL through a user-friendly interface using the policy editor
interfaces. tool and once the policy has been properly defined, the secu-
1) Monitoring Configuration Interface: This allows config- rity administrator requests the policy enforcement. The policy
uring the monitoring module from the security orches- editor tool then sends the HSPL policy to the policy interpreter
trator. It is intended to provide the required parameters to which identifies the main capabilities of the security policy and
refine the detection of potential threats on the network. obtains a list of security enablers which could enforce the secu-
2) Reaction Security Configuration Interface: This enables rity policy. When there is at least one security enabler capable
the security orchestrator to provide the security model- of enforcing the security policy (otherwise, the administrator
related data to the reaction module. In general terms, is notified), the policy interpreter performs a high-to-medium
this information will be composed by the capabilities of level policy refinement, generating an MSPL policy, still inde-
the security policy and the applied countermeasures on pendent of the underlying technology, but filling some required
the network as a reaction to a detected security issue. context information like real IP addresses or endpoints. This
3) Monitoring Verdicts Interface: This interface is intended refinement is registered in the policy repository, allowing trace-
to provide the required monitoring information from ability among policy abstraction levels. Once the MSPL has
the monitoring to the reaction module. The transferred been generated, the policy interpreter requests the MSPL pol-
data is mainly composed of the verdicts of the security icy enforcement to the security orchestrator, providing, not
properties tested on the network. only the policy, but also the candidate’s security enablers.
4) Countermeasures Suggestions Interface: It was con- The security orchestrator receives the request and its resource
ceived to transmit the set of suggested countermeasures planner makes the decision concerning the most suitable secu-
from the reaction module to the security orchestrator in rity enabler to enforce, according to its knowledge about the
form of MSPL files. architecture. Then, the security orchestrator requests a secu-
rity policy translation to the policy interpreter in order to
D. User Plane get a security enabler specific configuration from the MSPL
The policy editor tool allows administrators to model security policy. The policy interpreter downloads the proper
security policies with a high/medium-level of abstraction. security enabler translator plugin from the security enabler
1) Security Alerts and Warnings Interface: This interface provider and the policy interpreter performs the policy transla-
will transfer the alerts and warnings from the reaction module tion, generating the specific security enabler configuration and
to the end-user interfaces. It is designed as a communication registering the relationship among the MSPL and the enabler
channel between the reaction module and the ANASTACIA configuration in the policy repository. Finally, the configu-
user plane. ration is returned to the security orchestrator, who enforces
it through the specific technology, deploying if required new
E. Seal Manager Domain resources, and updating the new status of the security policy
in the policy repository.
Using security and privacy standards, the dynamic security
and privacy seal monitors in real time the security and privacy,
verdict and decision support system (VDSS). It provides a B. Monitoring and Attack Detection
graphical representation of the system status to the end-user,
The architecture has been conceived as a security-enabling
through different GUIs for user and data controller, and data
framework that allows an autonomic detection of the security
bases to hold privacy policies and logs.
incidents and computation of the countermeasures. To enable
1) Seal Manager Metadata Interface: This provides the
these features, the architecture comprises a monitoring module
requested information to evaluate the security and the pri-
that will actively observe the network and ensure its security.
vacy in a real-time fashion. The security and privacy policies
Fig. 2 shows the design of the monitoring component that
defined by the user are stored inside the policies repository
is composed of four principal components.
and an interface is available to retrieve and set them from the
1) Data preprocessing and filtering (DPF) is an
seal manager.
intermediate layer between the incident detector
and the network agents. It is intended to perform an
V. M AIN A RCHITECTURAL F LOWS
initial filtering and reformatting of the information cap-
A. Proactive Policy Deployment tured by the network agents and feed it in a normalized
The framework features two different policy enforcement format to the incident detector.
approaches, depending on the entity initiating the enforce- 2) Incident detector is the core component of the monitor-
ment process. Concretely, the proactive (or set-up) approach ing module. This unit analyses the processed data form
and the reactive one. In the first approach, the security pol- the network agents and executes the security analysis,
icy is enforced as part of a preventive or by-default security searching for security issues and attacks.

Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY WARANGAL. Downloaded on August 26,2024 at 12:26:22 UTC from IEEE Xplore. Restrictions apply.
 MOLINA ZARCA et al.: SECURITY MANAGEMENT ARCHITECTURE FOR NFV/SDN-AWARE IoT SYSTEMS 8011

Fig. 2. Design of the monitoring module (from ANASTACIA architecture).

Fig. 3. ANASTACIA monitoring phase workflow.

3) Attack signatures is a database containing the set of

attacks that are being monitored in the network. Despite This design also allows to connect the architecture to any IoT
this component is shown as module from the incident system by deploying the monitoring agents on the network to
detector, it is usually embedded in the latter. be protected. Moreover, since the whole architecture has been
4) Data analysis is an AI-based module that applies conceived in a distributed way, the analysis of the extracted
machine-learning techniques on the extracted data to data can be done in external premises, minimizing the impact
detect behavior anomalies. on the monitored network.
The aforementioned components rely on the data extracted 1) Security Monitoring Process: The design of the mod-
by the monitoring agents of our architecture, which can be ule allows actively monitoring IoT networks by following the
seen at the bottom of Fig. 2. Considering their position in process depicted in Fig. 3.
the whole architecture, the monitoring agents take the role of The architecture is devised to employ passive monitor-
directly interacting with the monitored network, continuously ing techniques to continuously extract information form the
extracting information from the data plane that will be used network and then put it in the DPF component. This module
by the components mentioned above to perform the security performs an initial processing of the extracted data in order
analysis. to harmonize it in a common format. Once the information
Monitoring IoT-based CPS networks introduced a particu- has been normalized, it is sent to the data analysis module
lar constraint on the monitoring agents: the challenge arose and the incident detector modules. The functionality of these
when using traditional monitoring techniques in state-of-the- modules is intentionally different to guarantee a deep security
art networks. The proposed framework tackles this challenge analysis. The former, on one hand, is in charge of perform-
by adapting the traditional tools to the particular requirements ing a behavioral analysis using machine learning techniques
of the IoT networks. to detect any abnormal behavior. The latter, on the other hand,
1) Low Energy Consumption Monitoring Agents: Since performs a signature-based security analysis, ensuring lower
IoT devices are restrained in energy, the implemented detection times on known attacks.
monitoring agents efficiently use the available energy, Once the data analysis component has performed the behav-
relegating any complex task to more capable devices. ioral analysis, the result is returned to the preprocessing
2) Restricted Computation Capabilities: As a consequence component, which sends the normalized results to the incident
of the restricted energy, the devices that act as moni- detection module. Finally, this module uses all the available
toring agents for IoT network have limited computation information (raw data extracted from the network and the
capability. In this sense, any complex task (such as the behavioral analysis results) to perform the security analysis.
analysis of the data) has to be delegated to devices with Afterward, the incident detector generates the security alerts
more capacity. that are sent to the reaction component. This process con-
Fig. 2 shows how the IoT monitoring agents interact with cludes the monitoring phase and triggers the reaction on the
the monitoring module. This design allows to use modified IoT platform, according to the security issues and attacks detected
devices to extract information directly from the IoT network by the incident detector.
(e.g., capture digital packets from IoT networks or extract ana- 2) Monitoring Potential: The monitoring process has been
logue data from sensors) and send it into the DPF module. conceived to be agnostic of the underlying attack to keep the

Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY WARANGAL. Downloaded on August 26,2024 at 12:26:22 UTC from IEEE Xplore. Restrictions apply.
 8012 IEEE INTERNET OF THINGS JOURNAL, VOL. 6, NO. 5, OCTOBER 2019

generality of the security analysis. All the connected mon-

itoring agents deliver the extracted information in the DPF
component, which makes it available for both data analysis and
incident detector components. This design decision delegates
the attack detection functionalities on the latter components
allowing the detection of any attack on the monitored network.
Fig. 3 shows that, despite the generic workflow of the mon-
itoring process is complex, it has been designed to have a low
latency in whole detection process, as shown in Section VII.
The implemented instance of our architecture takes advan-
tage of this feature by using multiple monitoring agents such
as Montimage Monitoring Tool (MMT)-probe, IoT brokers,
IDS instances (e.g., Snort), multiple incident detectors (like
MMT-security), and AI data analysis modules, such as [28]. Fig. 4. ANASTACIA reaction process.
The AI data analysis based on machine learning techniques
allows dealing with anomaly-based intrusion detection, by ana-
lyzing deviations from the historical a normal data reported by enforced and information about the cost associated to their
devices. The detection can be done using statistical methods, enforcement. The cost is understood here as the amount of
such as correlation of time series, or supervised machine learn- resources required to enforce certain countermeasure, either
ing techniques such as, for instance, one class support vector in terms of time, human, computation, or monetary resources.
machine. This set-up process is to be triggered mainly at the starting
This features empower the architecture to detect a wide vari- point, although updates of the security model can be pushed
ety of attacks detailed in Table I. Additionally, the monitoring into the VDSS in case of updates of the security policy that
agents also take advantage of the NFV and SDN techniques, entail any modification of the security capabilities.
allowing a dynamic deployment of them on the monitored For every incident detected at the monitoring module, a risk
network. Using these techniques, the monitoring and reaction evaluation is carried out. The risk analysis is performed at
plane can determine to deploy new instances of monitor- the VDSS, which evaluates the severity of the incident with
ing agents to harden the security levels. These instructions the criticality of the assets affected by the incident (which
(expressed in MSPL language) will be translated by policy is received from the security model analysis) and evaluating
interpreter upon demands from the security orchestrator, which the relevance of the threat in terms of potential propagation,
will deploy the new monitoring agents—as virtual security number of devices exposed to the threat or vulnerabilities
functions—and use SDN to perform the modifications on the exploited. The risk assessment uses statistical models for its
network and deploy the new instances. analysis, which feeds from several sources of input.
Despite the recommended countermeasures are the general 1) Current incident (type of threat, severity, etc.).
guidelines to mitigate the detected security issues, the frame- 2) Characteristic of the system affected (number of assets,
work is designed to dynamically analyze the enforced security whether they are exposed to vulnerability exploits, how
policy and the security capabilities deployed in the network to critical these devices are).
compute the most appropriate countermeasure in the detected 3) Information about past incidents (past effects of similar
case. This empower the framework with highly reactive and incidents, costs associated to their mitigation or about
dynamic security capabilities to cope with a wide variety of damages caused).
attacks. Once the level of risk associated to the incident has been
evaluated, the VDSS evaluates the available counter measures
that the IoT infrastructure supports. This evaluation uses the
C. Self-Healing and Self-Protection Processes information received from the security model analysis, which
The reaction process described in Fig. 4 uses the verdicts also notifies about the cost associated to every mitigation. A
on ongoing incidents to infer the possible countermeasures potential human intervention is also considered here as the
to mitigate them. The decision depends on the reactions system admin can fine tune values related to costs and miti-
that are possible to be enforced in the infrastructure and on gations or evaluate the severity of the incident and criticality
the resources needed to be executed. The available reactions of the asset affected, providing with additional input to the
depend on the security model of the infrastructure, which also DSS when proposing the most appropriate countermeasure to
depends on the security capabilities available at the platform. mitigate the ongoing incident. The selected countermeasure
During the reaction set-up, the security model of the IoT is notified to the MAS, which is in charge of notifying to
infrastructure is received by the VDSS of the reaction module the security orchestrator by adding the information about the
from the security model analysis component, which receives selected countermeasure to an MSPL policy.
this information from the security orchestrator. This security In parallel to the exchange of reaction information
model is directly related to the security policy being enforced, between the reaction and the orchestrator modules, additional
as it contains information about the security capabilities avail- information is exchanged with the dynamic security and pri-
able, the potential countermeasures that are possible to be vacy seal module through the security alert service. A real

Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY WARANGAL. Downloaded on August 26,2024 at 12:26:22 UTC from IEEE Xplore. Restrictions apply.
 MOLINA ZARCA et al.: SECURITY MANAGEMENT ARCHITECTURE FOR NFV/SDN-AWARE IoT SYSTEMS 8013

Fig. 5. ANASTACIA reactive policy enforcement process.

is mainly conceived for the threat intelligence exchange and it

is used here to formalize the information received by the seal
manager from the monitoring and reaction modules.
It is worth noticing that, although this process is designed
to be executed in an automatic way, it is also considered
the possibility of requiring explicit consent from the system
administrator, which might also entail the modification of the
security policy. The enforcement of the selected reaction is
enforced at the orchestrator, using virtual network interfaces
and SDN/IoT controllers available at the enforcement plane.
Listing 1. Except of MSPL file for representing a reaction.
D. Reactive Policy Deployment
time push mechanism is used to notify the security alert ser-
vice about the incidents detected, the alerts generated, and the Fig. 5 shows the main flow for a security policy enforce-
mitigations chosen. Such information is transformed by the ment as part of an automatic countermeasure. In this case
security alert service into structured threat information expres- the policy enforcement process is initiated by the reaction
sion messages, whose format was designed by OASIS1 for the module which is able to generate reactions depending on the
description of cyber-security information in a standard way. It threats [Fig. 5 (step 1)]. As part of the reaction, it can be
included one or several MSPL policies. These security poli-
1 [Online]. Available: https://oasis-open.github.io/cti-documentation/ cies are sent to the security orchestrator who identifies the
stix/intro main capabilities required by the policy [Fig. 5 (step 3)] and

Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY WARANGAL. Downloaded on August 26,2024 at 12:26:22 UTC from IEEE Xplore. Restrictions apply.
 8014 IEEE INTERNET OF THINGS JOURNAL, VOL. 6, NO. 5, OCTOBER 2019

requests information to the system model in order to get the architecture. The XL-SIEM provides a correlation engine that
available resources, as well as requesting a list of security is able to detect incidents by analyzing events from different
enablers able to cope with the aforementioned capabilities to sources. The design of the XL-SIEM allows to attach dif-
the security enabler provider [Fig. 5 (steps 4 and 5)]. Once ferent sources just by implementing new plugins that adapt
the security orchestrator has gathered relevant information and interpret new sources. Furthermore, the format used for
about the underlying architecture, the resource planner (in the plugins uses a compatible format with open source SIEM
the security orchestrator) decides who is the best security solutions such as OSSIM,3 which increases the compatibility
enabler according to its knowledge of the architecture [Fig. 5 and flexibility of the model. The data retrieved by the Kafka
(step 6)]. Then, it requests a policy translation to the policy broker, once normalized in rsyslog, is processed by the plugins
interpreter, providing the MSPL policies and the selected secu- of the XL-SIEM which prepares the received data for its cor-
rity enablers for each one. When the policy interpreter receives relation at the core of the XL-SIEM. The architecture of the
the request, it obtains the specific plugin from the security XL-SIEM permits to decouple plugins and the XL-SIEM core.
enabler provider for each security enabler and it performs the Since correlation activities can require a lot of computational
policy translation by executing the plugin for each received resources, the XL-SIEM core allows to distribute the correla-
MSPL [Fig. 5 (steps 8–12)]. Afterward, the policy interpreter tion activities among different instances, which increases not
sends the result to both, the policy repository for traceabil- only efficiency but also robustness.
ity purposes, and the security orchestrator, in order to trigger The correlation activities carried out by the XL-SIEM
the policy enforcement [Fig. 5 (steps 13 and 14)]. Finally, core generates alarms for the security incidents detected. The
the security orchestrator enforces the enabler configuration alarms are labeled with a certain level of criticality, which are
through different components of the framework depending on used by the MAS to decide on the most suitable counter mea-
the nature of the countermeasure. In case the countermeasure sure to react to the security incident. The orchestration engine
requires a VNF which is not already deployed, the secu- is notified about the proposed reaction, along with specific
rity orchestrator deploys it through the NFV MANO [Fig. 5 information about the devices to receive the countermeasure
(step 15)]. Otherwise, it can use an existent VNF and enforce (IPs of the devices affected, incidents to mitigate, etc.).
the configuration without a previous deployment. At this point,
the configuration can be enforced through the NFV MANO, A. Mobile Edge Computing Scenario
the SDN controller or the IoT controller depending on whether Smart security cameras send recorded video to nearby MEC
the countermeasure is a networking or IoT related configura- servers which can realize operations before sending the data to
tion [Fig. 5 (steps 16–18)]. Finally, once the policies have been the cloud. These kind of scenarios are attractive to the hackers
enforced, the security orchestrator notifies the new policies at different levels such as gain access to some security camera
status to the policy repository [Fig. 5 (step 19)]. in order to get real time video, capture the data between the
camera and the MEC server, compromise the MEC server in
VI. A RCHITECTURE I NSTANTIATION AND D EPLOYMENT order to get or manipulate the data or the standard behavior, or
This section describes the implementation of the architec- even just take control of the IoT cameras in order to use them
ture explained above as well as its deployment for validation as an army with the aim of performing some kind of DDoS
in two main scenarios: 1) mobile edge computing (MEC) and attack. In this scenario, a ping flooding attack is considered.
2) building management system (BMS). 1) MEC Testbed: The testbed emulates several IoT devices
Regarding the implementation, the monitoring information inside a Cooja environment, which will attack with ICMP ping
is obtained from three main sources. packets a victim outside the simulation—a server specifically
1) Sensors Attached to the IoT Network: We include here deployed to act as the victim.
sensors such as IDS (such as Suricata/Snort sensors), To detect the ongoing attack, an instance of the MMT mon-
honeypots, access control logs, etc. itoring tool is deployed inside the IoT network, including a
2) MMT [29]: Carrying out deep packet inspection for specially developed sniffer that allows extracting packets from
the detection of incidents, instantiating the monitoring an IoT network. The extracted flows will be analyzed using the
module of the architecture. DPI-enabled MMT-probe tool, which is loaded with specific
3) Operational Data Extracted From IoT Devices: It is rules to detect ICMP ping bursts on IoT traffic. This detec-
analyzed by data analysis tool, which applies machine tor will send events to the Kafka broker—containing the IP
learning techniques for identifying anomalous behav- of the affected device and the detected attack among other
ior of IoT devices (for example, very high temperature data—once the threat has been identified.
detected by climate sensors). In the Kafka broker, an Apache Storm4 class will process
A Kafka broker2 is provided to gather the information from these events and reformat the information using rsyslog, mak-
the different sources, normalizing it and getting it ready to be ing them ready to be sent to the XL-SIEM tool for further
sent to the monitoring components. analysis. Once the events have been read by the SIEM, the
The normalized data is sent, by using rsyslog, to latter processes the information and produces an attack alert
the anomaly detection reasoner based on the Atos’ XL- that is sent to the MAS by using a RabbitMQ channel.
SIEM engine implementing the VDSS functionality of the
3 OSSIM. [Online]. Available: https://www.alienvault.com/products/ossim
2 [Online]. Available: https://kafka.apache.org/ 4 Apache Storm. [Online]. Available: http://storm.apache.org/

Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY WARANGAL. Downloaded on August 26,2024 at 12:26:22 UTC from IEEE Xplore. Restrictions apply.
 MOLINA ZARCA et al.: SECURITY MANAGEMENT ARCHITECTURE FOR NFV/SDN-AWARE IoT SYSTEMS 8015

To compute the countermeasures, our MAS implementation of the building. As explained in [28], the monitoring mod-
receives the SIEM alert and extracts the information contained ules are able to discern a regular situation of a abnormal
within. This information is used to create the countermeasures one based on a previous training, so once the monitoring
defined in MSPL policies. The MAS uses a generates an MSPL modules receive the tramped temperature, these analyze and
with the the countermeasures for an ICMP flooding attack. The correlate the information against its knowledge and them gen-
MSPL defines a filtering rule for the ICMP protocol, instan- erates an alert to the reaction module (MAS). This reaction
tiated with context such as the IP addresses contained in the module computes the countermeasures based on the received
SIEM alert. The MSPL is sent to the security orchestrator that information and determines that it is necessary to turn off the
starts the deployment process of the countermeasures, retriev- IoT device until a physical verification has been performed.
ing the list of available security enforcers capable of enforcing The countermeasure is modelled by a new MSPL policy,
the specified countermeasures. sent to the security orchestrator, that analyzes the security pol-
To enforce the filtering policies, open source MANO icy and obtains the required capability for the countermeasure.
(OSM)5 together with ONOS6 are suitable security enforcers, Since it is an IoT-related management operation, the secu-
and the security enablers provider returns this as a single rity orchestrator decides to use the IoT controller and requests
security enforcer. Using this output, the orchestrator selects a the policy translation to obtain the IoT configuration from the
set of security enforcers and transforms the countermeasures, MSPL. Then, it gathers information from the system model in
expressed in MSPL, into a lower-level configuration; the set of order to decide through which component it will enforce the
ONOS/OSM specific configurations that will be used to deploy configuration, that is sent to IoT controller. Finally, the IoT
the countermeasure. With this final translation, the orchestrator device receives the IoT message by the IoT controller to be
deploys the countermeasures, creating a new virtual firewall turned off.
using OMS and ONOS and deploying specific rules to redirect 1) BMS Testbed: The policy interpreter, policy repository,
the traffic of the affected devices and filter the ICMP traffic. security enabler provider, security orchestrator, and IoT con-
The detection part of the instance described above is com- troller have been developed from scratch in python using
posed of three machines: 1) a Cooja machine (for emulating Django7 rest framework and Falcon for the rest APIs and
an IoT network); 2) an MMT-IoT-probe machine (to run the Mysql as main database engine. The MSPL policy models
incident detector); and 3) a MAS machine (for executing the are an extended version of [26], that has been extended to
mitigation service). These instances were virtualized using consider additional requirements imposed by IoT. The IoT
VMs with the following features: two vCPUs @ 2.40 GHz, domain security enabler plugin also has been developed from
2-GB RAM, and 20 GB of HDD. scratch in order to translate the extended MSPL into IoT con-
troller configuration. The policy interpreter implements four
B. Building Management System different HTTP APIs to only translate and enforce the two dif-
Nowadays, it is very common to find a lot of sensors scat- ferent security policy levels. The policy repository implements
tered in buildings. In fact, there are usually several sensors by two different APIs to store the policy translations as well as
room or dependencies measuring temperature, humidity, pres- the policy enforcement status. The security enabler provider
ence, and luminosity among others. These measurements can implements two different APIs to get the security enabler can-
be sent to a SCADA management system which usually imple- didates as well as to get the selected plugin code. The security
ments different behaviors depending on the received measures orchestrator implements three APIs to receive the reactions,
(e.g., if the system receives a measurement beyond the con- to perform the policy translations and to gather information
figured threshold it could generate an alarm). Sometimes, this from the system model as well as the APIs for the infrastruc-
kind of reactions are really expensive to deploy, or just alter ture management. Finally, the IoT controller implements two
the standard behavior. On the other hand, if there is a real APIs to receive the IoT devices configuration and to send the
emergency but the sensors have been manipulated, the absence configuration using the specific IoT protocol implementation.
of reactions could be fatal. With this in mind, a malicious In this case, the IoT controller uses CoAP as IoT protocol.
attacker could try to exploit the system in order to take some Regarding the equipment used in this scenario, the moni-
kind of advantage, to waste the resources of the target or toring and reaction modules has been deployed in the same
harm in somehow to the target. This scenario permits to eval- premises as the previous scenario. The policy interpreter, pol-
uate the benefits provided by the architecture to deal with the icy repository, security enabler provider, and security orches-
security challenges in IoT-CI that can be affected by the sen- trator have been virtualized and dockerized in a Intel Core
sor’s manipulation. Instantiating this scenario, the architectural i7-2600 CPU at 3.4 GHz, using three vCores, 3.5 GB of RAM,
framework has been deployed in a real building where several and 30 GB of HDD. The IoT controller has been virtual-
IoT devices, including temperature, humidity, and presence ized and dockerized in a Intel Core Processor (Haswell) at
sensors deployed. 1.5 GHz using two vCores, 2 GB of RAM, and 15 GB of
In our testbed, one of these IoT devices is compromised HDD. IoT devices: they are MSP430F5419A-EP at 25 MHz,
by an attacker, who gain access to it in order to manipu- 128-kB ROM, and 16-kB RAM, running a customized ver-
late the temperature sensor value to trigger the fire alarm sion of Contiki OS 2.7 and erbium CoAP server. The 6lowPAN
bridge: it is an MSP430F5419A-EP at 25 MHz, 128-kB ROM,
5 OSM. [Online]. Available: https://osm.etsi.org/
6 ONOS. [Online]. Available: https://onosproject.org/ 7 Django. [Online]. Available: https://www.djangoproject.com/

Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY WARANGAL. Downloaded on August 26,2024 at 12:26:22 UTC from IEEE Xplore. Restrictions apply.
 8016 IEEE INTERNET OF THINGS JOURNAL, VOL. 6, NO. 5, OCTOBER 2019

Fig. 6. DDoS attack detection performance in MEC scenario.

and 16-kB RAM, running a customized version of Contiki OS the alert as soon as this condition is met. The second contrib-
2.7 in order to allow the communication between 802.15.4 and utor to the total time is the XL-SIEM server, with an average
802.3. of 57 ms. This includes the risk analysis performed, aimed to
enrich the data received from the detection engines and deter-
VII. P ERFORMANCE E VALUATION mine the best set of countermeasures to the ongoing attack.
A. Monitoring Performance On the contrary, the XL-SIEM agent and the MAS add con-
stant times to the whole process (3.4 and 8.4 ms, respectively)
To measure the performance of the monitoring phase we due to their high parallelism. The average time for the four
have conducted different experiments in order to determine analyzed components is 514 ms, counting from the moment
the detection time of a ping flooding attack in an IoT sce- the attack is triggered until the reaction is computed.
nario. We have setup an emulated IoT network (using Cooja)
that contains a compromised device which will perform a ping
DoS attack toward another device. In addition, we have setup B. Incident Handling Performance
the MMT-IoT solution to extract the IoT packets and detect To evaluate the performance of the Incident handling in both
the ICMP flooding using MMT-probe. The test script analyzed MEC and BMS scenarios we have increasing number of events
the logs of two tools: the Cooja logs to identify the timestamp that are sent to the incident detector at different pace. The inci-
when the attack was triggered and the logs of MMT-probe in dent detector (XL-SIEM), is an Apache Storm-based incident
order to identify the timestamp when the attack was detected detector that uses an complex event processing engine, namely
by the incident detector. The test script triggered the attack in Esper,8 to correlate events. Events received by the incident
the (emulated) compromised device. The verdicts generated detector are filtered, processed and correlated to generate secu-
by MMT are then sent to the monitoring module, composed rity alarms, which are then sent to the reaction module via the
by two components of the XL-SIEM tool: 1) the XL-SIEM Kafka broker. The MAS collects these alarms and generates
agent and 2) the XL-SIEM server, measuring the processing an MSPL file which is sent to the security orchestrator.
time on both components. The former will receive, process To perform the tests, we have sent a burst of 100 events at
and filter the events from the MMT-probe sensor, while the different frequencies: 20, 10, and 4 Hz. In order to test the
latter will perform the risk analysis and generate a detailed performance of the components involved in the monitoring,
attack report. Finally, this attack report is sent to the MAS detection, and reaction, we have forced the generation of a
which will generate the respective MSPL containing the reac- security alert per event sent. Therefore, the incident detector
tion. The processing time is also measured in this last step. has generated 100 alarms at the pace indicated above. It is
This experiment was run 100 times, in order to compute the worth noticing that, in a normal operation environment, events
average detection and reaction times for the ICMP flooding from the same source IP will trigger just one alarm every 60 s
attack (MEC) at each component of the platform. or several minutes (depending on the rule configured at the
Fig. 6 depicts the measured times in each component. For Esper engine). This would allow to filter large amounts of
each iteration, the processing times have been stacked to show events and to avoid unnecessary overload to the system. In this
the total processing time of the ANASTACIA platform. The performance evaluation, we have simulated one of the worst
principal contributor of the platform’s reaction time are the cases in terms of workload, both for the incident detector,
analysis and detection components—MMT in this case—with VDSS, MAS, and orchestrator.
an average of 445 ms. The MMT needs to test a security
property: observe different ICMP packets per second, raising 8 Esper. [Online]. Available: http://www.espertech.com/esper

Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY WARANGAL. Downloaded on August 26,2024 at 12:26:22 UTC from IEEE Xplore. Restrictions apply.
 MOLINA ZARCA et al.: SECURITY MANAGEMENT ARCHITECTURE FOR NFV/SDN-AWARE IoT SYSTEMS 8017

Fig. 7. Incident handling performance, bursts of 100 events at different frequencies.

Fig. 8. Incident handling performance, bursts of 100 combined attacks (1100 events) at different frequencies.

The results of the tests are represented in the following chart Alarms generated by the incident detector are sent to a
(Fig. 7). The y-axis represents the time taken by the incident RabbitMQ message queue, where the MAS is attached to
detector to process each event, from the time it is received to receive these alarms. There’s a transfer time of approximately
the time when it is sent to the messaging queue to be consumed 40–50 ms. This time may vary depending on the network con-
by the MAS. As it can be seen, the response time of incident ditions and on the sync difference between the machines where
detector is stable, although some peaks are present in all tests. the time-stamps are measured.
The higher peak is present at 10 Hz (in event #79), with a In addition, some extra tests have been done to evaluate the
response time of 307 ms. Despite those anomalies the incident XL-SIEM server performance in a different stressing scenario.
detector recovers the normality quickly. It must be observed, In this case, the alerts are triggered when detecting differ-
however, that at 20 Hz it takes longer to recover the stability ent combined attacks, mixing up to 11 events to generate an
(e.g., from event #38 to #45). alarm. Once again, the attacks have been generated at differ-
To understand those delays we have to consider the XL- ent frequencies: 4, 10, and 20 Hz. This scenario stresses the
SIEM architecture. It is implemented in Apache Storm which correlation engine, creating a bottleneck in this component at
uses multiple threads in order to process several processes higher frequencies. The tests results are represented in Fig. 8,
simultaneously. Each thread (or bolt, as Apache Storm names where the processing time increases constantly at 20 Hz and
a singular thread or process) is in charge of a singular task, the bottleneck effect can be appreciated. These tests demon-
like storing events in database, correlate events, send alarms strate how the complexity of the alarm rules can impact the
to RabbitMQ, store alarms in database, etc. As long as there XL-SIEM performance.
are more threads than cores, the cores are shared by differ-
ent threads. The execution order of the different tasks can be
different in some cases, consequently the measured process- C. Reaction Enforcement Performance
ing time may fluctuate. Furthermore, some tasks use shared Fig. 9 shows the performance for the reactive policy trans-
resources (like databases), hence mutual exclusion situations lation. It measures along 100 iterations the time required by
may occur and increase the processing time. Those variations the policy interpreter to translate the reactive MSPL into both,
are appreciated in the charts as peaks. filtering SDN and power management IoT configurations. As

Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY WARANGAL. Downloaded on August 26,2024 at 12:26:22 UTC from IEEE Xplore. Restrictions apply.
 8018 IEEE INTERNET OF THINGS JOURNAL, VOL. 6, NO. 5, OCTOBER 2019

part takes around 460 ms, the incident handling takes around
58 ms, the policy translation is close to 36 ms, and finally,
the policy enforcement shows results around 370 ms. If we
consider the whole cycle, the framework is detecting and
enforcing the countermeasures in less than 1 s. It is important
to highlight that this result depends largely on the complexity
of the countermeasure as well as the kind of attack, i.e., in
general, the more complex countermeasure, the longer it will
take its deployment.

VIII. C ONCLUSION
This paper has presented ANASTACIA security manage-
ment architecture aimed to deal with the security and privacy
in NFV/SDN-enabled IoT scenarios, detailing the different
planes of the architecture as well as the main architectural
Fig. 9. Reactive policy translation.
flows. In addition, the main IoT thread/attacks and their sug-
gested potential detection and reaction mechanisms based on
NFV-SDN has been presented. The architecture has been suc-
cessfully instantiated and tested in two different scenarios:
1) the MEC and 2) IoT-CI in BMSs. In these scenarios we
tested DDos and IoT malware attacks, respectively, detailing
the autonomic reaction processes to mitigate them. The accom-
plished performance evaluation demonstrated the feasibility of
the solution to automatically monitor, detect, react, and miti-
gate IoT cyber-attacks, enforcing proper security policies, in
reasonable times (depending on kind of attack and reaction
countermeasure), accounting the latency and delays incurred
in IoT networks.
As future work, we envisage to extend the supported cyber-
threats detection and mitigation possibilities by addressing
reactive VNF orchestration and deployment at the edge of IoT
constrained systems and networks.

R EFERENCES
Fig. 10. Reactive policy enforcement.
[1] L. Atzori, A. Iera, and G. Morabito, “The Internet of Things:
A survey,” Comput. Netw., vol. 54, no. 15, pp. 2787–2805,
2010. [Online]. Available: http://www.sciencedirect.com/science/article/
it can be seen, the measurements obtained for the policy trans- pii/S1389128610001568
[2] J. L. H. Ramos, J. B. Bernabe, and A. F. Skarmeta, “Managing context
lation are quite similar, with an average time close to 36 ms information for adaptive security in IoT environments,” in Proc. IEEE
taking into account the variations that the system may suffer 29th Int. Conf. Adv. Inf. Netw. Appl. Workshops, Mar. 2015, pp. 676–681.
during execution. This is due to the extension and complexity [3] T. Yu, V. Sekar, S. Seshan, Y. Agarwal, and C. Xu, “Handling a
trillion (unfixable) flaws on a billion devices: Rethinking network
of the filtering policies for both scenarios are similar. security for the Internet-of-Things,” in Proc. 14th ACM Workshop
Fig. 10 shows the performance for the reactive policy Hot Topics Netw. (HotNets-XIV), 2015, pp. 1–5. [Online]. Available:
enforcement, which measures along 100 iterations the time http://doi.acm.org/10.1145/2834050.2834095
[4] J. P. Santos et al., “SELFNET framework self-healing capa-
taken by the security orchestrator to enforce the configurations. bilities for 5G mobile networks,” Trans. Emerg. Telecommun.
It covers since the security orchestrator receives the MSPL Technol., vol. 27, no. 9, pp. 1225–1232. [Online]. Available:
policy until it receives the enforcement confirmation from the https://onlinelibrary.wiley.com/doi/abs/10.1002/ett.3049
[5] P.-O. Östberg et al., “Reliable capacity provisioning for distributed
security enabler. In this case it is not taking into account cloud/edge/fog computing applications,” in Proc. Eur. Conf. Netw.
the policy translation since it has been shown previously. Commun. (EuCNC), Jun. 2017, pp. 1–6.
In the results we can see that the policy enforcement though [6] S. T. Ali, V. Sivaraman, A. Radford, and S. Jha, “A survey of securing
networks using software defined networking,” IEEE Trans. Rel., vol. 64,
the SDN controller takes approximately half the time of the no. 3, pp. 1086–1097, Sep. 2015.
enforcement through the IoT controller. It can be explained [7] D. B. Rawat and S. R. Reddy, “Software defined networking architecture,
as the enforcement against the IoT devices is sent through a security and energy efficiency: A survey,” IEEE Commun. Surveys Tuts.,
vol. 19, no. 1, pp. 325–346, 1st Quart., 2017.
6LowPAN network while the SDN enforcement is performed [8] S. Chakrabarty, D. W. Engels, and S. Thathapudi, “Black SDN for the
through Ethernet. Internet of Things,” in Proc. IEEE 12th Int. Conf. Mobile Ad Hoc Sensor
If we look at the full life-cycle of the framework detec- Syst., Dallas, TX, USA, Oct. 2015, pp. 190–198.
[9] P. Bull, R. Austin, E. Popov, M. Sharma, and R. Watson, “Flow based
tion and reaction processes in terms of average times, taking security for IoT devices using an SDN gateway,” in Proc. IEEE 4th Int.
as example the first scenario, we can see that the detection Conf. Future Internet Things Cloud (FiCloud), Aug. 2016, pp. 157–163.

Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY WARANGAL. Downloaded on August 26,2024 at 12:26:22 UTC from IEEE Xplore. Restrictions apply.
 MOLINA ZARCA et al.: SECURITY MANAGEMENT ARCHITECTURE FOR NFV/SDN-AWARE IoT SYSTEMS 8019

[10] O. Flauzac, C. González, A. Hachani, and F. Nolot, “SDN based archi- Jorge Bernal Bernabe received the M.Sc., master’s,
tecture for IoT and improvement of the security,” in Proc. IEEE 29th and Ph.D. degrees in computer science from the
Int. Conf. Adv. Inf. Netw. Appl. Workshops, Mar. 2015, pp. 688–693. University of Murcia, Murcia, Spain.
[11] S. Choi and J. Kwak, “Enhanced SDIoT security framework models,” He is currently a Post-Doctoral Researcher
Int. J. Distrib. Sensor Netw., vol. 12, no. 5, May 2016. with the University of Murcia. He has authored
[12] V. Varadharajan and U. Tupakula, “Security as a service model for several book chapters and over 35 papers in
cloud environment,” IEEE Trans. Netw. Service Manag., vol. 11, no. 1, international conferences and journals. He has
pp. 60–75, Mar. 2014. been involved with research on several European
[13] B. R. Al-Kaseem and H. S. Al-Raweshidyhamed, “SD-NFV as an energy projects such as DESEREC, Semiramis, Inter-Trust,
efficient approach for M2M networks using cloud-based 6LoWPAN SocIoTal, ARIES, OLYMPUS, ANASTACIA, and
testbed,” IEEE Internet Things J., vol. 4, no. 5, pp. 1787–1797, CyberSec4Europe. His current research interests
Oct. 2017. include security, trust, and privacy management in distributed systems and
[14] W. Yang and C. Fung, “A survey on security in network functions virtu- Internet of Things.
alization,” in Proc. IEEE NetSoft Conf. Workshops (NetSoft), Jun. 2016, Dr. Bernabe has been involved on the scientific committees of numerous
pp. 15–19. conferences and has served as a Reviewer for multiple journals.
[15] F. A. Alaba, M. Othman, I. A. T. Hashem, and F. Alotaibi, “Internet of
Things security: A survey,” J. Netw. Comput. Appl., vol. 88, pp. 10–28,
Jun. 2017. [Online]. Available: http://www.sciencedirect.com/
science/article/pii/S1084804517301455
[16] I. Farris, T. Taleb, Y. Khettab, and J. S. Song, “A survey on emerging
SDN and NFV security mechanisms for IoT systems,” IEEE Commun.
Surveys Tuts., vol. 21, no. 1, pp. 812–837, 1st Quart., 2019. Ruben Trapero received the Ph.D. degree from the
[17] C. S. Shankar, A. Ranganathan, and R. Campbell, “An ECA-P policy- Universidad Politécnica de Madrid, Madrid, Spain,
based framework for managing ubiquitous computing environments,” in 2010.
in Proc. 2nd Annu. Int. Conf. Mobile Ubiquitous Syst. Netw. Services, He was a Research Engineer with the Universidad
San Diego, CA, USA, 2005, pp. 33–42. Politécnica de Madrid, until 2011. He has been a
[18] C. Rensing, M. Karsten, and B. Stiller, “AAA: A survey and a Telecommunication Engineer since 2004. From 2012
policy-based architecture and framework,” IEEE Netw., vol. 16, no. 6, to 2014, he was an Assistant Professor with the
pp. 22–27, Nov./Dec. 2002. Universidad Carlos III of Madrid, Getafe, Spain.
[19] A. M. Hadjiantonis, A. Malatras, and G. Pavlou, “A context-aware, In 2015, he joined the DEEDS Group, Technische
policy-based framework for the management of MANETs,” in Proc. 7th Universität Darmstadt, and where he became the
IEEE Int. Workshop Policies Distrib. Syst. Netw. (POLICY), 2006, p. 10. Head of the Security Laboratory focused in cloud
[20] “D2.3.1—Specification of the SECURED architecture,” SECURED security. Since 2016, he has been a part of the Cyber Security Group,
Consortium, SECURED FP7 EU Project no. 611458, Sep. 2014. ATOS Research and Innovation, Madrid. His current research interests
[21] S. Ziegler, A. Skarmeta, J. Bernal, E. Kim, and S. Bianchi, include identity management, privacy and security management, and service
“ANASTACIA: Advanced networked agents for security and trust assess- engineering.
ment in CPS IoT architectures,” in Proc. Glob. Internet Things Summit
(GIoTS), Jun. 2017, pp. 1–6.
[22] I. Farris et al., “Towards provisioning of SDN/NFV-based security
enablers for integrated protection of IoT systems,” in Proc. IEEE Conf.
Stand. Commun. Netw. (CSCN-2017), 2017, pp. 169–174.
[23] A. M. Zarca et al., “Enhancing IoT security through network soft-
warization and virtual security appliances,” Int. J. Netw. Manag., Diego Rivera received the bachelor of computer sci-
vol. 28, no. 5, 2018, Art. no. e2038. [Online]. Available: ences and computing engineering degree from the
https://onlinelibrary.wiley.com/doi/abs/10.1002/nem.2038 University of Chile, Santiago, Chile, in 2011 and
[24] E. Bertino and N. Islam, “BotNets and Internet of Things security,” 2013, respectively, and the Ph.D. degree focused
Computer, vol. 50, no. 2, pp. 76–79, Feb. 2017. [Online]. Available: on the analysis of the quality of experience for
doi.ieeecomputersociety.org/10.1109/MC.2017.62 OTT services from the Université Paris-Saclay, Paris,
[25] Y. Gao et al., “Analysis of security threats and vulnerability for cyber- France, in 2016.
physical systems,” in Proc. 3rd Int. Conf. Comput. Sci. Netw. Technol., From 2012 to 2013, he was a Research Assistant
Oct. 2013, pp. 50–55. with NIC Chile Research Labs, University of Chile,
[26] C. Basile, A. Lioy, C. Pitscheider, F. Valenza, and M. Vallini, “A where he was involved with research on concur-
novel approach for integrating security policy enforcement with dynamic rency issues in Linux UDP sockets. He is currently a
network virtualization,” in Proc. 1st IEEE Conf. Netw. Softwarization Research and Project Engineer with Montimage, Paris, where he is involved in
(NetSoft), Apr. 2015, pp. 1–5. the development of security monitoring solutions for Internet of Things-based
[27] A. M. Zarca et al., “Enabling virtual AAA management in SDN-based cyber-physical systems.
IoT networks,” Sensors, vol. 19, no. 2, p. 295, 2019. [Online]. Available:
http://www.mdpi.com/1424-8220/19/2/295
[28] D. Mehta, A. E.-D. Mady, M. Boubekeur, and D. M. Shila, “Anomaly-
based intrusion detection system for embedded devices on Internet,” in
Proc. 10th Int. Conf. Adv. Circuits Electron. Micro Electron., Venice,
Italy, 2018, pp. 16–20.
[29] B. Wehbi, E. M. de Oca, and M. Bourdelles, “Events-based security Jesus Villalobos received the master’s degree in
monitoring using MMT tool,” in Proc. IEEE 5th Int. Conf. Softw. Testing computer science and the master’s degree in cyberse-
Verification Validation, Apr. 2012, pp. 860–863. curity from the University of Seville, Seville, Spain,
in 2012 and 2016, respectively.
Alejandro Molina Zarca received the M.Sc. and He also studied computer forensics with the
master’s degrees in computer science from the University of Granada, Granada, Spain, in 2017.
University of Murcia, Murcia, Spain, in 2012 and He has been a Software Engineer since 2012.
2017, respectively, where he is currently pursuing From 2012 to 2017, he was a Full-Stack
the Ph.D. degree at the Department of Information Developer and a Project Lead with 4A-SIDE GmbH,
and Communication Engineering. Braunschweig, Germany. From 2017 to 2018, he was
He is currently a Researcher with the Department a Cybersecurity Consultant with AndaluciaCERT,
of Information and Communication Engineering, Seville, as part of the Computer Emergency Response Team. Since 2017,
University of Murcia. His current research interests he has been a part of the Cybersecurity Laboratory, ATOS Research and
include Internet of Things security and network Innovation, Madrid, Spain, where he is involved in several projects for the
virtualization and softwarization. Horizon 2020 European Commission Program.

Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY WARANGAL. Downloaded on August 26,2024 at 12:26:22 UTC from IEEE Xplore. Restrictions apply.
 8020 IEEE INTERNET OF THINGS JOURNAL, VOL. 6, NO. 5, OCTOBER 2019

Antonio Skarmeta received the B.S. degree Anastasios Zafeiropoulos received the Dipl.-Ing.
(Hons.) in computer science from the University degree from the School of Electrical and Computer
of Murcia, Murcia, Spain, the M.S. degree Engineering, National Technical University of
in computer science from the University of Athens, Athens, Greece, the M.Sc. degree in
Granada, Granada, Spain, and the Ph.D. degree public policy and management from the Athens
in computer science from the University of University of Economics and Business, Athens, and
Murcia. the Ph.D. degree from the School of Electrical
Since 2009, he has been a Full Professor with and Computer Engineering, National Technical
the Department of Information and Communications University of Athens.
Engineering, University of Murcia. He has been He is currently the Head of the 5G/IoT Research
involved with research on different projects in Group, UBITECH, Athens, focusing mainly on the
the national and international areas in the networking, security, and design and implementation of innovative technical solutions on the fields of
Internet of Things (IoT) area, like Euro6IX, ENABLE, DAIDALOS, 5G, SDN/NFV, Internet of Things, data mining and analytics, and green IT
SWIFT, SEMIRAMIS, SMARTIE, SOCIOTAL, IoT6 ANASTACIA, and solutions. He has co-authored over 40 scientific publications in high-level
CyberSec4Europe. He has been the Head of the Research Group ANTS since international journals and conferences.
its creation in 1995. He has authored or co-authored over 200 international
papers and being member of several program committees. His current research
interests include integration of security services, identity, IoT, and smart cities.

Stefano Bianchi received the biomedical engineer-

ing degree from the University of Genoa, Genoa,
Italy.
He is Research and Innovation Manager with
Softeco Sismat Srl, Genoa. He is the Head
of the Research and Innovation Business Unit,
Softeco, Geneva, Switzerland. His over 16 years
of experience in Research and Innovation projects
include European projects, such as eContent-
Worksafe, eContent-ERDDS, eTEN-EuOrphan, IST- Panagiotis Gouvas received the Dipl.-Ing. and
K-Wf Grid, eTEN-EuroWorksafe, eContentPlus- Ph.D. degrees from the School of Electrical
AquaRing, IST-Accessibile, HEALTH-Hypergenes, ICT-TELL ME, and ICT- and Computer Engineering, National Technical
ANASTACIA and national projects, such as CCSE RSE-SmartGen, FIMSER- University of Athens, Athens, Greece.
GLIMS, CSEA-Podcast, and CSEA-VIRTUS. His experience ranges from He is the co-founder and Research and
user requirements analysis to system architecture design and technical soft- Development Director of UBITECH, Athens. He
ware development (Web application in particular) with an emphasis on has authored or co-authored over 35 international
complementary activities, such as market analysis and business model plan- papers. He is also active in relevant standardization
ning, dissemination, communication and exploitation, and project technical communities. His current research interests include
and administrative coordination. He is currently coordinating the H2020 cloud computing, security, big data analytics, and
ANASTACIA project on IoT/CPS cybersecurity, CSEA PODCAST project autonomic networking. He has actively participated
on Automated Metering Infrastructure integration in smart grids, and CSEA in many research and commercial projects in the above areas.
VIRTUS on Virtual Power Plant. Dr. Gouvas has been a member of several Program Committees.

Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY WARANGAL. Downloaded on August 26,2024 at 12:26:22 UTC from IEEE Xplore. Restrictions apply.