Virtualized Security at the Network Edge: A

User-centric Approach
D. Montero∗ , M. Yannuzzi∗ , A. Shaw† , L. Jacquin† , A. Pastor‡ , R. Serral-Gracià∗ , A. Lioy§ , F. Risso§ , C. Basile§ ,
R. Sassu§ , M. Nemirovsky‡‡ , F. Ciaccia¶ , M. Georgiadesk , S. Charalambidesk J. Kuusijärvi ∗∗ , F. Bosco††
∗ Technical University of Catalonia (UPC), Spain
† Hewlett-Packard Laboratories, United Kingdom
‡ Telefónica I+D, Spain
§ Politecnico di Torino, Dip. Automatica e Informatica, Italy
¶ Barcelona Supercomputing Center (BSC), Spain
‡‡ ICREA Researcher Professor at BSC, Spain
k PrimeTel PLC, Cyprus
∗∗ VTT Technical Research Centre of Finland Ltd, Finland
†† United Nations Interregional Crime and justice Research Institute, Italy

Abstract—The current device-centric protection model against Let us assume for a moment that users would like to have
security threats has serious limitations. On the one hand, the the same security policy and exactly the same protection level
proliferation of user terminals such as smart-phones, tablets, enforced on all of their devices. In the context of this paper,
notebooks, smart TVs, game consoles and desktop computers
makes it extremely difficult to achieve the same level of protection we will call this the “uniform security aim”. To achieve this
regardless of the device used. On the other hand, when various goal, the user typically needs to understand the configuration
users share devices (e.g., parents and kids using the same devices details of each device, which typically involves the setup of
at home), the set up of distinct security profiles, policies, and different security applications on different platforms. For non-
protection rules for the different users of a terminal is far from technically savvy people, this turns out to be an impossible
trivial. In light of this, this paper advocates for a paradigm shift
in user protection. In our model, the protection is decoupled from hurdle to overcome. As a result, most Internet users suffer from
the users’ terminals, and it is provided by the access network wide variations in their protection levels, and this problem is
through a Trusted Virtual Domain (TVD). Each TVD provides exacerbated as the number of devices per user grows.
unified and homogeneous security for a single user, irrespective In this paper, we propose a paradigm shift from device-
of the terminal employed. We describe a user-centric model, centric protection to a user-centric model. The latter specifi-
where non-technically savvy users can define their own profiles
and protection rules in an intuitive way. We show that our cally addresses the two main drawbacks of the former, that is:
model can harness from the virtualization power offered by next- i) the need for dissimilar installations of security applications
generation access networks, especially, from Network Functions in different devices due to their different platforms; and ii)
Virtualization (NFV) in the Points of Presence (POPs) at the edge the problem of non-uniform protection due to the difficulties
of Telecom operators. We also analyze the distinctive features of in the configurations needed.
our model, and the challenges faced based on the experience
gained in the development of a proof-of-concept. To cope with the first problem, we propose a model in which
the protection and security policies are now unified and remain
Index Terms—Security, virtualization, offloading, NFV. homogeneous for each user, independently of the terminal
used. This is achieved by means of a user-specific Trusted
I. I NTRODUCTION
Virtual Domain (TVD), which is dynamically instantiated at a
The protection of users’ terminals against Internet threats secure place in the network edge. As we shall show, the TVD
is largely dominated by a device-centric model. This basically can be instantiated either on the user’s side (e.g., on a home
consists of installing a set of security applications on each gateway), or on the provider’s side (e.g., on a next-generation
terminal, such as anti-virus software, a personal firewall, etc. broadband access server handling the users’ connections).
An average user nowadays has multiple terminals, including a To cope with the second problem identified above, we
smart-phone, a smart TV, and a notebook, and in many cases, propose a user-defined security model that aims at ease of use
also a tablet, a desktop computer and even a games console. by design. We discuss the importance of exposing the selection
These devices usually have different architectures (e.g., Intel of high-level protection policies to the average user, and the
or ARM) as well as different capabilities and operating sys- necessity to enforce the configurations required transparently
tems (e.g., Android, Windows, or Linux), so the appropriate to the latter. This simple strategy detaches the definition of
protection tools may not be available for all platforms. As a the protection policies from their corresponding configura-
result, the most common practice is to install different security tions, thus allowing tailored protection even by non-technically
applications in the various terminals—or simply rely on the savvy users. It is worth highlighting that the virtualized
default protection means provided by the operating systems. security model described in this paper can be applied both to
residential and corporate scenarios. We describe its application capabilities that supports the instantiation of TVDs in a multi-
in the form of a multi-tenant platform, considering the main tenant fashion. If the TVD is placed on the user’s premises,
stakeholders involved, i.e., service providers, infrastructure then the NED could be either an enhanced home gateway or
providers, security application developers, and the users. a Customer Premises Equipment (CPE). Those devices may
The remainder of the paper is structured as follows. First, we need additional compute, storage, and networking resources,
outline the essentials of the paradigm proposed, including the and they could be managed by the ISP. If the TVD is placed
new protection model and the security policy approach. Next, in the ISP premises—as it will be the case with the upcoming
we introduce the general architecture and its main components. NFV-based access networks [1]—a pool of nodes belonging to
After that, we analyze the distinctive factors of our model, and the NFV infrastructure could be the NEDs devoted to host our
outline some of the main conclusions that can be drawn from TVDs. Note that this second deployment strategy leverages the
our prototype implementation. Finally, we conclude the paper. virtualization and processing power of commodity hardware,
and the unquestionable trend toward its ubiquity at the network
edge—though it does not exclude the adoption of the first
II. T OWARD A N EW P ROTECTION PARADIGM deployment strategy as well. It is worth highlighting that,
Figure 1a depicts the basic concepts, showing the evolution our model has a remarkable advantage versus Cloud-based
from device-specific security, to a common security framework protection [2]. Whereas in the latter case the virtualized
for all devices hosted in the access network. In our model, resources supporting the users’ security are rarely on the path
security applications that are commonplace today, such as anti- that would naturally be followed by the users’ traffic, in our
virus, firewalls, content inspection tools, etc., shall be called model, the TVD is always instantiated on the natural path. In
Personal Security Applications (PSAs). Observe that, under other words, our model avoids routing detours, which would
the current protection model, the heterogeneity of devices and occur if the NEDs were located off the path between the user
platforms requires the installation of various PSAs with similar terminal and its traffic destinations (e.g., in the Cloud).
roles and functions—actually four PSAs are required in the As its name indicates, the TVD must be trusted, since it
example shown on the left hand-side of Fig. 1a. Also observe will execute security applications on behalf of the user on one
that some devices may remain completely unprotected, such or more nodes that are typically owned and managed by a
as the case of smart TVs. third-party. Appropriate techniques, such as remote attestations
Under our paradigm, the heterogeneous set of PSAs protect- [3] or contractual agreements must be put in place, so as
ing the different devices are now moved and consolidated into to guarantee the appropriate level of trust according to the
a TVD. Each TVD will only need to host the minimum set security needs of a specific user. Also observe that the NEDs
of complementary PSAs required by the user (e.g., an anti- must be secure, since they will host the applications of several
virus and a firewall in the example). A TVD is a “logical users that could potentially affect each other. As we shall show,
container” that is instantiated per-user, and it is composed the NED must be connected with a secure channel to the user
of the following elements: i) the execution environments terminal, because this path may be subject to attacks that could
hosting the user’s PSAs; and ii) the required data, control, try to bypass the security controls performed at the NED.
and management plane interconnectivity in order to guarantee Each PSA within a TVD implements one (or possibly more)
the isolation between different users’ TVDs—we will delve security controls that need to be configured according to the
into this later in Section III (see Fig. 3). The right hand-side needs of a specific user. However, the configuration of security
of Fig. 1a shows that a user TVD can be instantiated in either applications is often complex and not well understood by the
end of the access link. Indeed, as a logical container, a TVD majority of the users. To simplify this task, we propose the
may run entirely within a single Network Edge Device (NED), model shown in Fig. 1b. The rationale behind it is that, to
or it may run in a distributed way involving several NEDs. build a real user-centric model, it is mandatory to allow users
In our terminology, a NED is a device with virtualization to specify their own security requirements, i.e., their security

Security   Policy  DefiniGon   Policy  Enforcement  Hierarchy  

User’s  Trusted    
Virtual  Domain  (TVD)  
HSPL  
TV   TV   Government  
End-­‐Users   Policies  
       

       Current   H2MPT   Policy   Addi8onal  

       Access     Reconcilia,on     Policies  
ISP  Policies  
           Networks                                      
       Virtualized         MSPL  
Access  
switch/router  
       Access     Security    
Admin  
           Network   User’s    
Instan8a8on   Policies  
M2LPT  
Network  Edge  Devices  (NEDs)   HSPL   High-­‐level  Specifica8on  Policy  Language  
Low   MSPL   Medium-­‐level  Specifica8on  Policy  Language  
Heterogeneous  Personal  Security   Uniform  Personal  Security   Level   H2MPT   High  to  Medium-­‐level  policy  transforma8on  
M2LPT   Medium  to  Low-­‐level  policy  transforma8on  

(a) Offloading security to the virtualized access network. (b) Policy definition and the policy enforcement hierarchy.
Fig. 1. The two main objectives of our user-centric model, i.e., uniform protection and ease of configuration.
policy, in a straightforward way. Our design principle aims to packet filter, or to configure the options of a general anti-virus.
meet the expectations both of non-technically savvy users, and An illustrative example of MSPL outlining the translation from
also of experts in the field, such as security administrators. For HSPL up to Low Level configurations will be sketched later
the former, the goal is to allow them to specify their security in Section II-A (cf. Fig. 2).
policy without needing to deal with the technicalities. For the Overall, writing policies in MSPL demands the same se-
latter, the goal is to allow them to fine tune their policies, while curity awareness and level of expertise as for specifying the
simplifying the configuration of the security applications under configurations directly in the PSAs. The advantage, however,
their administration. is that MSPL avoids experts the burden to master several se-
To achieve these goals, our model is composed of three mantically equivalent security controls and syntaxes. Observe
policy abstraction layers, and two translation services between that PSA developers will need to provide their plug-ins jointly
them (see the left hand-side of Fig. 1b). The first abstraction with their PSAs, in the form of a Medium to Low-level Policy
layer is supplied by the High-level Security Policy Language Translation service (M2LPT) (cf. Fig. 2). Also note that the
(HSPL), a user-oriented authorization language suitable for complexity mainly resides in the language definition, so these
expressing concepts related to users’ protection. HSPL allows translators fundamentally perform syntax adaptation. Thanks
users to express general protection requirements by means to this approach, a security policy written in MSPL can be
of sentences that are very close to natural language, such as embodied by different PSAs, provided that the candidate PSAs
“do not permit access to war content”, “block my son from offer the capabilities required by the user. In addition, the
accessing gambling sites”, or “allow email scanning”. In our PSAs can be replaced without impacting on the security policy
model, HSPL policies can be selected from a set of candidate specified by the user (e.g., replacing a Cisco packet filtering
policies that can be then customized and grouped (e.g., “block application by one provided by Checkpoint). For further details
access to gaming sites” + “only during week days”). The on MSPL, the reader is referred to [5].
policy sentences are internally mapped to a subject-verb- As shown in Fig. 1b, the binding between HSPL and MSPL
object-attribute authorization language that is currently under is supplied by the High to Medium-level Policy Translation
definition as an XACML profile [4]. For instance, the policy service (H2MPT). Differently from the M2LPT translation,
“block my son from accessing gambling sites” is interpreted as which is provided by the PSA developer, the H2MPT rep-
“block” (verb) “my son” (subject) “from accessing gambling resents a translation service that is natively provided by our
sites” (the object). Predefined lists of subjects, verbs and architecture. H2MPT uses formal ontologies to provide the
objects are made ready to the users, so they can easily compose semantics implied by the high-level policy statements. Our
their own sentences. Available attributes depend on the verb- ontology is based on [6], and it models the high-level concepts
object pair. Moreover, users can extend the predefined fields (subjects, objects, verbs and attributes) as well as the medium-
without being experts. The specific details of HSPL are out level concepts (rules, conditions, actions, resolution strategies),
of the scope of this paper, so for additional information the and the capabilities. The ontology also contains information
reader is referred to [5]. on how predefined HSPL concepts are expanded into useful
The lowest layer in the policy abstraction stack is what we information for building MSPL rules. The translation process
call the “Low Level” in Fig. 1b, as it is the one that deals first identifies a set of applications that can enforce the security
with the configuration details of the PSAs. This configuration policies (e.g., a Web Filter and a Firewall), and then generates
procedure is clearly application-specific, and hence is not the MSPL for the selected applications. The HSPL verb-
under our control. object pairs are used to match the capabilities needed for
With the aim of abstracting the specific configuration pro- policy enforcement, while the capabilities per se are used to
cedures while meeting the experts’ needs, we have created determine the PSAs and their interactions. Moreover, a meta-
an intermediate abstraction layer that allows the specification model defines how HSPL sentences are mapped into MSPL
of PSA configurations using a PSA-independent format. The concepts, and how these concepts must be assembled to build
security policies in this abstraction layer are specified by valid rules. This meta-model is used by a set of Enrichment
means of the Medium-level Security Policy Language (MSPL). Modules and by a standard ontology reasoner, to gather all the
The effort in the definition of the MSPL is not trivial. Indeed, information needed to create MSPL policies that enforce the
depending on the heterogeneity of the different security con- HSPL policy [5], [6]. Finally, an H2MPT component combines
trol languages, the mappings can be arbitrarily complex. We this information into MSPL policies. This translation is done
address this complexity by means of an MSPL model that transparently for non-technically savvy users (i.e., for those
defines the main concepts (like policies, rules, conditions, and users specifying their policies through HSPL). We contend
actions), and it is organized by capabilities. In this context, that, by having a high-level policy specification language, our
capabilities are defined as basic features that can be configured model provides far more flexibility and expressiveness than
to enforce a security policy (e.g., channel protection, filtering, approaches based on profiles or templates. This is because
anti-virus, parental control, etc.). Our approach also allows these latter basically wrap under a common name a set of low
to group families of languages with similar concepts (e.g., level settings, which are basically applied for a fixed set of
attributes, actions, or condition types), which can be captured security controls.
by specific sub-models built by analyzing several languages In the model that we conceive, the PSAs can be selected by
of controls sharing the same capability. For instance, through the users themselves or by a provider. If the user only specifies
MSPL, it is possible to write the configuration of a general the HSPL, then the PSAs are automatically selected from a
catalog of available applications, based on the PSAs that meet (e.g. the ISP PSAs). The user must not necessarily own the
the functionality required by the policies. In our model, the PSAs in other domains when chaining is performed. This is
capabilities of a PSA are specified through a “PSA manifest”. useful when more sophisticated controls are required by the
In this context, the selection may be straightforward—when entities that specify the higher policies in the stack.
only one PSA is available with the required capabilities—or it
may be based on various criteria if multiple PSAs could offer A. An Example of Policy Translation and Enforcement
those capabilities (e.g., on the PSA reputation, its cost, etc.).
To better describe our new paradigm, we present an example
Another important aspect is that, according to recent stud-
that illustrates the step-by-step process, starting from the
ies, human mistakes are the major cause of breaches and
definition of High Level policies up to the configurations made
vulnerabilities [7]. Thus, our model provides analytics that
to guarantee their enforcement. Figure 2 depicts a simplified
help reducing the likelihood of such mistakes. These include:
but complete example of the policy definition process for
a) contradictions among policies in different PSAs; b) policy
a non-technically savvy user. It is comprised of four basic
contradictions within a PSA; or c) cases leading to suboptimal
steps. First, the user is requested to define its policies using
performance (e.g., rules that are never matched and that simply
the High Level Policy Language (HSPL). This user-oriented
increase the processing time). Our model identifies this type
authorization language allows to express and customize a set
of anomalies by means of state of the art techniques [8]. We
of general security rules, by means of sentences that are very
represent clauses as hyper-rectangles, so that anomalies can
close to natural language, i.e., “block phishing sites”.
be detected by using geometric intersections. Anomalies are
Next, the HSPL policy sentences are mapped to a subject-
classified by evaluating geometric relations among conditions
verb-object-attribute authorization language aiming to extract
(e.g., inclusion, intersecting conditions but no one includes the
the different security capabilities required by the user, (see
other), as well as relations between actions (e.g., same action,
step 2 on the figure). As a result, a service graph is built,
equivalent actions, conflicting actions). The resolution is dealt
where the nodes represent generic applications (PSAs) capa-
with formally modeled strategies, which cover a set of existing
ble of fulfilling the security requirements. Observe that two
security control resolution mechanisms. Upon detection, we
applications are required in the example, i.e., Web Filtering
provide hints on how to resolve them, and notify the effects
and a Firewall. The selection of the PSAs is based on the
of each decision.
manifest provided along with each PSA, which indicates its
Moreover, the model that we envision should support mul-
specific capabilities. Third, by using the ontology and the
tiple actors, which could simultaneously operate on the same
service graph information, the security policies are translated
traffic (see the right hand-side of Fig. 1b). Each of these actors
to MSPL, obtaining the application-independent definition of
may possibly impose its potentially conflicting security policy.
policies requested by the user (step 3 on the figure). The
For instance, a user can decide the level of protection that he
representation of MSPL policies will be stored and managed
needs, but the ISP may impose other limitations in order to
in XML format. Fourth, specific PSAs are selected satisfying
guarantee the integrity of its network. In turn, the Government
the capabilities and requirements of the user. As mentioned
may impose additional restrictions. In case of conflict between
above, the specific PSAs can selected either by the user or
the different policies in the hierarchy, our approach is to
by the provider. For each PSA, the configurations are created
automatically resolve such anomalies, and inform the user
by using an application specific translation plugin. These
about the issue and its outcome.
plugins convert the generic MSPL rules to application-specific
In order to resolve such conflicts, a “Reconciliation” [9]
configurations (see step 4). These configurations will be the
process is performed. The latter takes the policies of the
inputs once the PSAs are instantiated and linked.
different actors that must be reconciled, and obtains a single
Finally, once the PSAs configurations are created, an or-
MSPL policy to be enforced by the user’s PSAs. The core
chestration system instantiates each PSA, and enforces its
of this process is the resolution of contradictions among rules
particular configuration, hence providing the security policies
from different policies. Priorities and hierarchies are some of
defined by the user.
the simplest forms to resolve contradictions (i.e., rules from
higher priority policies/actors prevail), and they typically map
well to contractual frameworks. However, custom reconcili- III. T HE SECURED A RCHITECTURE
ation strategies can be defined. The Reconciliation process This section introduces the envisioned architecture, which
copies non-conflicting rules in the reconciled policy, while we call SECURED [5]. As explained in Section II, SECURED
each resolved contradiction generates a new rule. The latter provides a system where users can offload their PSAs to their
have higher priority than the original ones, and the correct nearest compatible Network Edge Device (NED). The archi-
action is decided by the selected reconciliation strategy. More tecture is specifically devised to be heavily multi-tenanted,
details on our reconciliation approach can be found in [10]. and flexible enough to be used in scale-out systems. From
Observe that, actors may decide not to disclose their policies a use case point of view, it can be expanded and deployed
to other actors. In that case, reconciliation strategies that in a variety of ways, ranging from small set-top boxes or
require full access to the policy set are not possible. An home gateways, up to deployments at a much larger scale in
alternative approach is to use policy chaining. This consists of a distributed environment (e.g., in localized datacenters at the
redirecting the output of one set of PSAs in an administration edge of ISP’s networks). Our focus in this section is on the
domain (e.g. the user PSAs) to a set of PSAs in another domain main architectural components.
 1 High Level Policy Definition HSPL
HSPL 2
Capabilities Mapping and Service Graph
NED
Allow all but: Service Graph creation
block phishing sites
Internet
block access to the web during school
and homework time User
Traffic
Weekday: Mon,Tue,Wed,Thu,Fri Web Filtering Firewall
Time: 09:00-13:00,15:00-18:00
block access to blacklisted and
gambling sites Ontology-based translation to
PSA 3
Medium Level
HSPL  MSPL
Plugin

Web Conf. Ƌ MSPL

Ě XML
# RULE 1
acl User1 <ConfigurationRule> XML
http_access block gambling.com <FilteringAction> DENY
<ApplicationLayerCondition> <ConfigurationRule>
<URL>gambling.com</URL> <packetRuleAction>DENY
Ƌ … <packetFilterCondition>
ß <ConfigurationRule> <DestinationPort> 80
FW Conf. <FilteringAction>DENY <timeCondition>
iptables -A INPUT <ApplicationLayerCondition> Mon,Tue,Wed,Thu,Fri
PSAs --dport 80 <URL>socialnetwork.com</URL> 09:00-13:00,15:00-18:00
Configurations -j ACCEPT PSAs selection and … …
Translation to Low Level Confs.
4 MSPL  Apps Confs.

Fig. 2. Example of policy definition and enforcement, going from HSPL to MSPL and then to Low level configurations.

A. General Overview A derived requirement posed by multi-tenancy is network

isolation. The SECURED architecture must ensure the isola-
The architecture must support the dynamic allocation and tion of traffic amongst different users. More precisely, each
instantiation of users’ security. The security functionality of tenant will be configured with a dedicated and private virtual
each user can be comprised of different PSAs in a defined network. This network connects the different PSAs with the
arrangement through service chaining, and these PSAs can be end user on one side, and the Internet on the other side.
deployed within the same physical host or in a distributed Furthermore, the architecture defines a private management
manner. As a result, two general requirements are imposed network that sets up, controls and manages the different TVDs.
on the architecture: i) massive multi-tenancy, which implies Both the Compartmentalization and Containment Layers have
isolation of users, their applications, and network traffic; and a Control and Management component, which aims to estab-
ii) a secure and verifiable infrastructure and environment, lish a separation between the technology independent part and
which users can trust to host their security applications. A the implementation-dependent technology.
general view of the basic architecture is depicted in Fig. 3. The second requirement is related to the establishment of
The figure shows a generic deployment (e.g., on an NFV POP trust between the end user and SECURED. This requirement
of an ISP). It is worth noting that, in simpler deployments is vital, since users would like to establish a certain level
(e.g., when the NED is a home gateway), the functionality of trust with SECURED prior to requesting the instantiation
provided by some of the systems on top of Fig. 3 could be of security applications and sending their traffic. We address
simplified and embedded in the NED itself, or they could not this requirement by using the concept of Remote Attestation
be needed, such as the case of the NFV Orchestrator. (RA). SECURED leverages trusted computing mechanisms to
Overall, the first requirement is to guarantee complete measure the system software upon component startup, where
isolation between different users. In light of this, the TVD resulting measurement digests are held by a secure root of
was designed as an isolated environment which will hold the trust, e.g. a hardware device like a Trusted Platform Module
security applications of a user, and will in turn process the (TPM) [11]. These measurements can be cryptographically
user traffic. A TVD is comprised of one or more Execution signed by the device and sent to the users whenever they
Environments (EEs). An EE is a lightweight and heavily send an attestation request. The process of RA poses a major
controlled environment that contains and executes one or challenge for SECURED, and preliminary insight on a proof-
more user PSAs—each one operating on the principle of least of-concept implementation will be described later in Section
privilege. Thus, within SECURED, two levels of isolation IV-B.
are defined (cf. Fig. 3): i) the Compartmentalization Layer,
which is mainly responsible for the isolation between user B. Main components
TVDs; and ii) the Containment Layer, which handles isolation Security Module: This module is the front end, which is
between PSAs within an EE. Thus, an EE could be either a contacted during the connection establishment. It is comprised
Compartment or a Containment layer, respectively. of two elements, the Attestation Agent and the Authentication
 Trusted
Third Party Orchestration System Authentication System Security Policy Manager Policy and PSA repositories
(TTP)

User1 TVD User2 TVD

End Users Remote Attestation Security Module
User1 PSAs User1 PSA User2 PSAs
Authentication EE

Attestation
Agent

CTRL &

CTRL &
CTRL &

MGMT

MGMT
MGMT

PSA3

PSA1

PSA4
PSA1

PSA2
MGT

CTRL
Device

User NED CTRL &

App SECURED
MGMT Containment Layer
App
Operating System
Trusted Channel
End Devices Compartmentalization Layer

Underlying Hardware and Network Infrastructure

TVD Trusted Virtual Domain
PSA Personal Security App. SECURED Point Of Presence (POP)
NED Network Edge Device
EE Execution Environment SECURED Control and Management Data path

Fig. 3. The basic SECURED architecture showing a multi-tenant scheme on a Point of Presence (POP).

module. Prior to authenticating, the end user first contacts In addition, this module also manages the extension of the
SECURED in an attempt to establish a secure connection user data path so as to connect the user’s device to the newly
whilst also performing the remote attestation protocol. To this created TVD.
end, the SECURED system receives a challenge request to Orchestration System: In the case of an NFV POP, the
perform an attestation of its software configuration. A mutually NED Control and Management module will be assisted by the
Trusted Third Party (TTP) system is involved in the attestation NFV Orchestration system. However, in simpler scenarios, the
process. The TTP is responsible to keep a copy of known- former could entirely handle all the configurations required.
good measurements, and provide a secure verification service In other words, when the NED is embodied in the home
to the user for verifying remote attestation responses. After gateway of a residential user, the orchestrations needed will be
a successful check, a secure channel is created and the user handled locally without requiring any external orchestrator. In
safely sends his credentials to the Authentication module. general terms, the Orchestration system should deal with the
Authentication System: The authentication of users is a key instantiations and configurations in large distributed systems
component of SECURED. This can be implemented either (e.g., an NFV POP), and preferably, in a “technology-agnostic”
using a local (standalone) authentication system, or relying way. The “technology-dependent” part could be managed by
on an existing external authentication infrastructure (e.g., an the Control and Management module embedded in the NED.
AAA+ system). The result of the authentication process is In our model, the Attestation Agent keeps track of the different
to obtain tokens allowing the interplay between the main components during the instantiation phase (i.e., compartments,
components within a NED, and external subsystems, such containments, and PSAs), and manages the corresponding
as the PSA repositories. Once the user is authenticated, the measurements in order to present an attestation proof back
instantiation of his security must be enforced. to the user concerning his TVD.
NED Control and Management: Once the user is authen- Security Policy Manager: This module is in charge of
ticated, this module retrieves the user policies and metadata handling the users’ policies and the reconciliation process prior
related to the composition of the required security applications. to performing the configuration of the user’s PSAs.
After that, the Control and Management module drives the PSA Repositories: The applications are retrieved from these
instantiation of the user TVD, including its applications and repositories with their respective MSPL plugins, which then
the setup of the virtual network. More specifically, this module need to be loaded in one or more TVD containments.
determines the resources required for the user TVD, and com- SECURED App: This is the only application that needs to
mands the instantiations required as well as the deployment be installed in a user device. Its role is basically to support
and interconnection of the PSAs. This computation encom- the secure communications with the NED, and handling the
passes an analysis of the required compartments, containments Remote Attestations and its outcomes.
and virtual networks to be allocated in order to instantiate Overall, the architecture introduced in this section allows
the security applications. This analysis considers the PSA the dynamic creation of trusted and virtualized execution
requirements along with the availability of resources, and the environments throughout the access network. In this frame-
required configuration on the network (physical and virtual). work, several actors such as users, corporate ICT managers,
infrastructure providers, security service providers, and soft- abstraction layers involved. This allows users and even experts
ware developers, can interplay and benefit from our user- in the field, to focus on their security policies rather than on the
centric protection model. An important remark about the configuration details of specific security applications. Another
proposed architecture is its alignment with the emerging NFV important aspect is that, conversely to many of the offloading
technology. NFV is an enabler for SECURED, and it will be solutions available today, which are typically deployed in the
essential for guaranteeing its scalability. Cloud, our solution admits a rich variety of deployments on
either edge of an access link. Cloud-based solutions provide
IV. A NALYSIS OF SECURED compelling protection schemes while avoiding several of the
overheads for end-users (e.g., for corporate customers). The
The security model proposed in this paper has several downside, however, is that: a) they require routing detours; b)
distinctive factors that make it unique. To show this, we they are not really user-centric (at least not yet); c) they do
position SECURED in the current spectrum of protection not provide essential trust means, such as remote attestation;
techniques, and highlight its main differences with state-of- and d) they do not support advanced features such as anomaly
the-art solutions. In addition, we present and discuss our initial verification and policy reconciliation techniques. These latter
evaluations of a proof-of-concept implementation, with special two are precisely a couple of distinctive aspects in SECURED,
focus on performance aspects related to the security, trust, and and therefore, are the center of our assessment and analysis at
service verification offered by SECURED. this stage. We proceed to provide insight about these aspects,
and the challenges that we foresee based on a proof-of-concept
A. Positioning SECURED within the security panorama implementation.
The spectrum of solutions designed to counter security
threats is really broad. The solutions available today can be B. Remote Attestations
reasonably categorized according to the table shown in Fig. 4. Trust establishment between an end user and the protection
As it can be observed, there are solutions that are focused on platform is a critical step towards security offloading. In our
protecting the end user device, while others propose different model, we use Remote Attestations (RAs) and verification
forms of security offloading. Moreover, current protection techniques for the trust establishment process. Let us assume
schemes can be classified based on whether they are user- the following scenario: a user connects through an insecure
centric, device-centric, network-centric, or corporate-centric. channel and requests protection from SECURED. Prior to
In a nutshell, Fig. 4 presents a high-level comparison of starting exchanging traffic, the user is requested to create a
different security protection schemes according to two general trusted channel toward a NED. A trusted channel is an instance
criteria: i) the targeted protection model; and ii) where the of a secure channel (e.g., a VPN), where the endpoints are
security is enforced. attested before any data exchange. In SECURED, the trusted
As far as our knowledge, SECURED is the only solution channel protects users against a potentially compromised
available nowadays that proposes a true user-centric model, NED. However, enabling these security countermeasures in-
which specifically addresses the need for device-independent troduces overhead. On the one hand, users may experience
security. As described in Section II, the user-centric approach delay during the establishment of the connection with the
is achieved thanks to the HSPL and MSPL languages, and the NED. This is due to the integrity check needed, which is
H2MPT and M2LPT translation services between the three issued only once per user during the connection. On the

New Protection Solutions Current Enterprise New Enterprise

network edge, or the Cloud)
Outside user

Security Solutions
(e.g., on an network box,

Cloud Protection Solutions

premises
Security Offloading

ACLs Antivirus Viptela

Security Enforcement Model

SECURED Cloud … ACLs

Professional
Firewall Corporate Bitglass
Firewall
Firewall
Proxy
VPN
premises
In user

NAT … IDS/IPS PaloAlto MobileIron

… …
Current Network
Protection Solutions
Legacy
Legacy
Protection McAfee
(e.g., laptop,

Parental Enterprise
User Device
On an End

Enterprise
tablet …)

Control tools Avast McAfee

… Protection
iOS Norton
… Personal Enterprise tools
Android Firewall Symantec

User-centric
Model Device-centric Model Network-centric Model Corporate-centric Model
Personal Protection

Targeted Protection

Fig. 4. Positioning SECURED considering some of the most common tools as well as some of the most recent and compelling solutions in the area.
other hand, administrators may face scalability problems, since These initial results show that smartly performing RA does
a portion of the network and the computational resources not incur in a noticeable overhead for the end user, as all
will be dedicated to the security checks as users connect. the heavy lifting is asynchronously performed behind the
Normally, solutions offering this feature use a cryptographic scenes. The analysis also sheds light on the feasibility of
chip—the Trusted Platform Module (TPM) [11]—that may enabling end users to remotely verify the status of a NED. It is
pose a performance bottleneck while issuing the required worth highlighting that, the interval between two consecutive
verifications. SECURED overcomes this issue by introducing attestations can be configured, thereby offering the possibility
a Trusted Third Party (TTP) system (cf. Fig. 3). This is an of defining convenient trade-offs depending on the case. So
entity that is trusted by users and infrastructure administrators, far, we have seen that the RA of a single NED will introduce
which asynchronously attests a set of controlled NEDs in a negligible overhead.
configurable time interval. The advantage of this approach is However, performing the RA over a distributed infrastruc-
twofold. First, the workload for the attestation process does not ture poses complex challenges, and remains an open problem.
increase with the number of connecting users, since the NED These challenges increase when we also include in the picture
is common to all users. Second, end users will get a response multi-domain scenarios, or requirements such as user mobility
regarding the integrity of the NED almost immediately. and roaming. Furthermore, the assessment of time bounds for
We have developed a prototype that uses strongSwan [12] dynamic service deployment, as well as the appraisal of the
for the creation of a trusted channel with IPsec. To this end, multi-tenant isolation model will need to be deeply analyzed
strongSwan has been adapted to generate remote attestation in the near future. We plan to develop a comprehensive
requests to the TTP, and either continue or drop the connection prototype that will address these issues. Our research and
depending on the result of the integrity verification. The TTP future evaluations will prioritize the following aspects: a)
has been implemented with OpenAttestation [13], a framework security and isolation; b) easy-of-use; c) deployment and
for attesting large infrastructures. Our initial results show that service provisioning in relatively short time scales; and, related
the establishment of an IPsec connection without attestation is to the latter, d) support for user mobility.
very fast (around 76 ms), and that the asynchronous attestation
with the TTP in the same setting does not introduce noticeable C. User-Centric Policy Framework
delays (around 217 ms). Unlike our solution, performing Our policy-based framework also needs an in-depth per-
synchronous remote attestation adds a significant delay on the formance assessment to evaluate if the policy services can
creation time of the tunnel (around 4.119 seconds). be actually used in real scenarios. To this purpose, we tested
Another source of overhead is due to the size of the integrity the performance of the reconciliation, anomaly analysis, and
reports. Figure 5 shows the size of the reports exchanged translation with an off-the-shelf computer equipped with an
between the NED and the TTP. The results were obtained Intel processor i7-3630QM (2.4 GHz), with 16 GB of RAM,
from a ten minute period, where a user repeatedly connected running OpenJDK RE 1.7.0 55 on top of a Linux operating
to the NED. While the first report generated is near 300 KB, system. We performed two different rule processing experi-
subsequent reports are very small (between 4 and 8 KB), ments: 1) average case with a realistic amount of rules; and
due to the fact that OpenAttestation sends only new integrity 2) a higher bound worst case scenario with thousands of rules.
measurements—these are performed on the NED with the In both cases, we have considered two types of filtering within
Integrity Measurement Architecture (IMA) [14] software. Note the PSAs, namely, a Packet Filter, and an L7 Filter. During
that the first report contains all the measurements performed at the experiments, we measured the time required to process
boot time. Furthermore, new reports will be generated only if and validate the filtering rules. As discussed in Section II,
new measurements are produced on the NED, i.e., when new such validation is composed of three parts, anomaly analysis,
software is executed. reconciliation, and M2L translation.
The first tests evaluate the performance of a small/medium
scenario, where the number of rules per user are on average
Integrity Report Generation in the range of tens or hundreds. This estimation was derived
350
from a use case with four actors, where policies included 10 to
300 50 rules for each PSA, amounting to an average of 100 rules
to be processed. We consider that these numbers per user are
250 representative of a reasonable average, since in a user-centric
Report Size (KB)

approach, the size of the rule set will not raise to thousands—
200
Report Size which is typically the case found on border firewalls of large
Cumulative
150 companies. As reported in the first row of Table I, all the three
measured policy-related tasks were completed in less than one
100
millisecond.
50 The second experiment aims to assess the scalability on
large scale policy scenarios. This means scenarios that, as
0
1 2 3 4 5 6 stated on [8], statistically satisfy significant parameters of
# Report the policies that can be found in practice. This experiment
provides two different results. On the one hand, we compute
Fig. 5. Size of the integrity reports generated with OpenAttestation.
 Filtering level Anomaly analysis Reconciliation M2L translation
Packet filter <1 ms <1 ms <1 ms
Average case (time to process 100 rules)
L7 filter <1 ms <1 ms <1 ms
Packet filter 12 s 74 s <1 s
Worst case (time to process 5000 rules)
L7 filter 90 s 364 s <1 s
Packet filter 2000 1500 > 5000
Number of rules processed in 1 s
L7 filter 1000 1000 > 5000
TABLE I
R ESULTS OF THE TESTS FOR POLICY- BASED TASKS .

the necessary processing time for a very large amount of rules. Despite this, several of the issues addressed in this paper
On the other hand, we compute the amount of rules that can require significant efforts in terms of research. The list is
be processed in 1 second—reasonable amount for interactive large and includes aspects such as: remotely attesting dis-
purposes. Both results are reported in Table I. We observe tributed systems, multi-domain scenarios (i.e., the interplay
that, for the Anomaly Analysis, our prototype can process among different ISPs), user mobility and roaming scenarios,
5000 rules in 12 s for the Packet Filtering case. In contrast, scalability analysis, assessment of upper bounds for dynamic
L7 Filtering requires 90 s to perform the same task, due to the service deployment, isolation assessment, development of a
massive usage of regular expressions. In terms of the number comprehensive threat model, constraints and deeper analysis
of rules processed in less than a second, we obtained 2000 of corporate scenarios, and more.
rules for the Packet Filter case, and 1000 for L7 Filtering.
Regarding the reconciliation part, we were able to process ACKNOWLEDGMENT
1500 Packet Filter policies and 1000 L7 Filter policies in less The research described in this paper is part of the SE-
than a second. However, the worst cases for the 5000 rules CURED project [5], co-funded by the European Commission
considered yielded reconciliation times of 74 s, and 364 s, for under the ICT theme of FP7 (grant agreement no. 611458).
the Packet Filter, and the L7 Filter, respectively. Finally, the
translation of MSPL into low-level configurations is a linear
R EFERENCES
problem that took approximately one second with 5000 rules
both with an XSLT-based approach and with a SAX-based [1] ETSI, “Network Functions Virtualisation (NFV) Architectural Frame-
work,” http://www.etsi.org/deliver/etsi gs/NFV/001 099/002/01.02.01
Java program. All these results are summarized in Table I. 60/gs NFV002v010201p.pdf, December 2014.
Given that these computations are performed at infrastruc- [2] J. Sherry, S. Hasan, C. Scott, A. Krishnamurthy, S. Ratnasamy, and
ture elements, wherein computational power can be adjusted V. Sekar, “Making Middleboxes Someone Else’s Problem: Network
Processing as a Cloud Service,” in Proceedings of the ACM SIGCOMM
as needed, we consider that our approach can reasonably scale 2012 Conference on Applications, Technologies, Architectures, and
in several real scenarios. For instance, the average cases are Protocols for Computer Communication, 2012, pp. 13–24.
representative of residential scenarios, and all computations [3] K. Goldman, R. Perez, and R. Sailer, “Linking Remote Attestation to
Secure Tunnel Endpoints,” in Proceedings of the First ACM Workshop
can be resolved online. We also consider that the processing on Scalable Trusted Computing, 2006, pp. 21–24.
of 5000 rules is quite representative of a corporate user case [4] OASIS, “eXtensible Access Control Markup Language (XACML) Ver-
(e.g., an SME), and that the worst cases are highly unlikely sion 3.0,” http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-
en.pdf, January 2013.
that occur in practice. Anyway, the bounds found indicate that [5] “Security at the Network Edge (SECURED),” http://www.secured-
there are cases in which the reconciliation cannot be handled fp7.eu/.
online, and therefore, this analysis serves as a starting point [6] C. Basile, A. Lioy, S. Scozzi, and M. Vallini, “Ontology-based Security
Policy Translation,” Journal of Information Assurance and Security
for investigating new strategies and optimizations. (JIAS), vol. 5, no. 1, pp. 437–445, 2010.
[7] IBM Global Technology Services, “IBM Security Services 2014 Cyber
Security Intelligence Index,” http://media.scmagazine.com/documents/
V. C ONCLUSION 82/ibm cyber security intelligenc 20450.pdf, June 2014.
[8] C. Basile, A. Cappadonia, and A. Lioy, “Network-Level Access Con-
trol Policy Analysis and Transformation,” IEEE/ACM Transactions on
In this paper, we have argued that for the large majority Networking, vol. 20, no. 4, pp. 985–998, 2012.
of Internet users, the current protection model against secu- [9] P. McDaniel and A. Prakash, “Methods and Limitations of Security
rity threats is broken. Users typically have multiple devices, Policy Reconciliation,” ACM Transactions on Information and System
Security, vol. 9, no. 3, pp. 259–291, Aug. 2006.
but achieving the same level of protection irrespective of [10] C. Basile, A. Lioy, C. Pitscheider, and S. Zhao, “A formal model of pol-
the device used has become “mission impossible”. We have icy reconciliation.” in Proceedings of the 23th Euromicro International
proposed a paradigm shift in user protection, through a user- Conference on Parallel, Distributed, and Network-Based Processing
(PDP 2015), March 4–6, 2015.
centric model that also decouples the security from the user [11] H. Zhang, Z. Qin, and Q. Yang, “Design and Implementation of the
terminals. The protection model that we envision is based on TPM chip J3210,” in Proceedings of the 2008 Third Asia-Pacific Trusted
the setup of a Trusted Virtual Domain (TVD) per-user, placed Infrastructure Technologies Conference (APTC ’08), 2008, pp. 72–78.
[12] A. Steffen, “strongSwan - IPsec for Linux,” https://www.strongswan.org.
in the access network. Our approach facilitates security policy [13] Intel, “OpenAttestation SDK: A SDK for Remote Attestation,”
configuration, and enables uniform protection independently https://github.com/OpenAttestation/OpenAttestation.
of the terminal used. We have also shown that the trust [14] R. Sailer, X. Zhang, T. Jaeger, and L. van Doorn, “Design and Im-
plementation of a TCG-based Integrity Measurement Architecture,” in
and security verification mechanisms offered by a prototype Proceedings of the 13th Conference on USENIX Security Symposium,
implementation can be applied in many practical scenarios, 2004, pp. 223–238.
such as the case of residential users.