Wendpanga Francis Ouedraogo
1
, Frederique Biennier
1
, Catarina Ferreira Da Silva
2
and Parisa Ghodous
2
1
Universit
´
e de Lyon, INSA-Lyon, Villeurbanne Cedex, France
2
Universit
´
e de Lyon, Universit
´
e de Lyon 1, LIRIS, CNRS, UMR 5205,
20 Avenue Albert Einstein, 69621 Villeurbanne Cedex, France
Keywords:
Context Aware Security, Execution Context, Security Patterns, Security Policy, Security as a Service.
Abstract:
Taking advantage of the agility and interoperability provided by Service Oriented Architecture (SOA), Web 2.0
and XaaS (Anything as a Service) technologies, more and more collaborative Business Processes (BP) are set
”on demand” by selecting, composing and orchestrating different business services depending on the current
need. This involves re-thinking the way information, services and applications are organized, deployed, shared
and secured among multi-cloud environment. Fitting this de-perimeterized and evolving execution context
requires organising the service protection in a dynamic way in order to provide an up to date and consistent
protection. To fit this goal, we propose to integrate the different protection requirements defined according
to the business environment in a single security policy. Then we plug a context-aware security deployment
architecture on the cloud service middleware to analyse both the security policy and the execution context
to select, compose and orchestrate the convenient protection means. A proof of concept built on Frascati
middleware is used to evaluate the impact of this ”on-line” security mediation.
1 INTRODUCTION
In a highly competitive environment, enterprises are
more and more involved in collaborative strategies to
provide complex services and outstanding products
fitting the customers requirements. Service-Oriented
Architecture (SOA) and Cloud platforms provide ag-
ile and interoperable supports to compose, share and
deploy on the fly complex service-based workflows.
The development of such a de-perimeterized and ag-
ile Information System challenges the development of
dynamic protection strategy, as threats and vulnerabil-
ities evolve continuously depending on to both orga-
nizational and deployment platforms contexts.
The security policy model provided by the OASIS
allows outsourcing security mechanisms from busi-
ness services. Nevertheless, this model may lead to
multiple security policies enactment as services are
”replicated” while they are composed to set a new
business process. This may lead to inconsistent pro-
tection compared to the up-to-date corporate protec-
tion strategy.
To overcome this limitation, we propose to extend
this security policy model to integrate context infor-
mation, avoiding replicating the policy depending on
the business and/or execution context. Then, this uni-
mediation service to select, compose and orchestrate
on the fly the security services deployment depending
on the business context and execution environment.
After presenting a motivation example and the
state of the art in section 2, we introduce our context-
aware security model focusing on the business re-
source protection in section 3. We detail its imple-
mentation in section 4 and evaluate its performance
in section 5.
2 CONTEXT AND MOTIVATION
EXAMPLE
Motivations for defining a unified security policy have
been found in previous projects in Collaborative Net-
worked Organisation (CNO) and Dynamic Supply
Chain environments. The reduced time-frame and the
fast changing environment of these CNOs call for an
opened and agile IT support. This is partly fulfilled
thanks to the composition / orchestration / elastic de-
ployment mechanisms provided by SOA, Web 2.0,
276
Ouedraogo W., Biennier F., Ferreira Da Silva C. and Ghodous P..
DOI: 10.5220/0005442502760283
In Proceedings of the 5th International Conference on Cloud Computing and Services Science (CLOSER-2015), pages 276-283
ISBN: 978-989-758-104-5
Copyright
c
 2015 SCITEPRESS (Science and Technology Publications, Lda.)

XaaS (Anything as a Service) technologies. Develop-
ing such cloud-based business service reusing ability
requires to-rethink the way business service and data
are protected to fit their a priori unknown execution
context.
2.1 Motivation Example
This CNO dynamic protection context can be illus-
trated with a use case picked from a previous project
where a mechanical engineering SME is involved
in different CNOs. This SME uses a key business
service to validate mechanical specifications of new
products. This business service may be invoked in
different business processes (BPs):
• The corporate Computer Aid Design (CAD) mod-
elling system can invoke this service to check
the intermediate specification consistency (75%
of the invocations),
• The Product Lifecycle Management (PLM) sys-
tem can invoke the service to check the product
information before integrating data in its database
(10% of the invocations),
• The service can also be used by some of the part-
ners to validate the engineering requirements they
send. In such case, authorized partners can invoke
the service from their own CAD system (15% of
the invocations).
As the data produced and acceded by the valida-
tion service has a high patrimonial value for the
enterprise, different protections must be deployed:
– Strong authentication to support specification
traceability, i.e., knowing who has achieved/-
worked on the specifications.
– Restricted access control to allow only people
from the enterprise or some authenticated part-
ners to accede the service.
– Exchanged data protection with cryptographic
algorithm.
These protection requirements lead to identify 3 exe-
cution contexts related to the validation service:
• Context 1 - Internal specification checking: This
service is invoked by the corporate CAD services
under the control of members of the enterprise in
a safe environment. In this context, no extra pro-
tection is required as the calling service can be
identified.
• Context 2 - Certified requirement checking: This
service is invoked by the PLM service under the
control of members of the enterprise to check
engineering data validity before storing them.
As it is used to implement a certification, non-
repudiation mechanism is required, involving to
capture user identity, check input and output in-
formation integrity.
• Context 3 - Collaborative specification checking:
This service is invoked by a partner from its CAD
system to validate the specifications sent as en-
gineering requirements. Due to business con-
straints, authentication, authorization and non-
repudiation are necessary, whereas the open ex-
ecution platform requires data encryption.
Most of the time, the business service and the pro-
tection means are orchestrated before being deployed,
without checking the global consistency of the differ-
ent policies on a given asset. To overcome this limita-
tion, we propose to adapt the security policy dynami-
cally so that the protection means fit the (may be new)
business context.
2.2 State of the Art
To overcome the ”lack of trust” and ”unsuitable secu-
rity policy deployment” pointed out by different sur-
veys (Heiser and Nicolett, 2008) (Ban et al., 2010)
regarding Web-based collaborative organizations, se-
curity requirements must be integrated in process
models. Some annotation-based solutions have been
developed to integrate security services in BPMN
(Business Process Model and Notation)
1
descriptions
(Rodr
´
ıguez et al., 2007) (Ouedraogo et al., 2013).
As these annotations are related either to a particular
BPMN object or connector, extensions are required to
define a global and consistent end to end process pro-
tection.
More recently, the OASIS Service Reference Ar-
chitecture
2
provides a set of models to ”outsource”
the security services (namely Confidentiality, In-
tegrity, Availability, Authentication, Authorization,
Non-Repudiation) from the business service. More-
over, security protocols and standards such as WS-*,
XACML
3
or SAML
4
have been defined to support in-
teroperable implementation of the necessary security
mechanisms.
Different works are based on the OASIS out-
sourced security policy model to integrate security is-
sues in services composition. Some use security re-
quirements as constraints while selecting and com-
1
http://www.omg.org/spec/BPMN/2.0/
2
http://docs.oasis-open.org/soa-rm/soa-
ra/v1.0/cs01/soa-ra-v1.0-cs01.html
3
http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-
spec-os-en.html
4
http://docs.oasis-open.org/security/saml/Post2.0/sstc-
saml-tech-overview-2.0-cd-02.html
Context-aware[e-mail]Deployment
277

posing services (Bartoletti et al., 2005) whereas other
define various calculus algebra to decide if a right can
be granted or not (Bartoletti et al., 2006). Paying at-
tention on Business Process (BP) protection require-
ments, (Lang and Schreiner, 2009) has proposed a
Model-Driven Security approach (MDS) to generate
security policies.The generation process is achieved
according to a static environment vision (perimeter-
ized process and well-known deployment platform),
leading to define different policies depending on the
business context. This makes the policy manage-
ment complex and limits a consistent protection evo-
lution as modifications are achieved locally. Further-
more, while some earlier works focus mostly on ac-
cess control (Wolter et al., 2009), extensions are now
defined to capture protection requirements while de-
signing BP (Lucio et al., 2014). In former works,
we have proposed a simplified risk analysis knowl-
edge base to capture protection requirements used to
generate the convenient policy assertions (Ouedraogo
et al., 2013). Even if this user-oriented security engi-
neering strategy allows to identify protection require-
ments and mitigation means adapted to the collabora-
tion context, it can lead to inconsistent protection as
each context-dependent protection policy is defined
separately. To overcome this limitation, the different
protection strategies must be gathered in a single ref-
erence policy attached to each business service and
deployed in a business context-aware mode to miti-
gate the security risks associated to contextual vul-
nerabilities and threats.
3 CONTEXT AWARE SECURITY
SPECIFICATION
We focus on business service protection while cloud-
based deployment allows reusing these protections in
different business contexts. To avoid inconsistent pro-
tection specification, we extend the resource model
introduced in the MDS approach to integrate context
related information so that a unique security policy
can be set. To maintain up-to-date protection, secu-
rity patterns associated to risks mitigation best prac-
tices are also introduced.
3.1 Resource Model
A resource may be a service, some information used
by the service or even a part of a process. Each re-
source (Res
k
) can be characterized by a name (ResN),
a type (ResT) which can be business service/service
data or a data, a resource application layer (ResL)
(business, service, or infrastructure). A resource can
include sub resources (SubResN) (for e.g. a business
service can include set of others business services
(sub services) and each sub service handles a set of
data (see eq. (1)). As a consequence resource are de-
fined in a recursive way.
Res
k
= (ResN;ResT ; ResL; {SubRes
s
}) 0 < s <= Ns;
(1)
Where ”Res
k
” is the resource, ”k” the resource
number, ”SubRes
s
” the name of the sub resource, ”s”
the sub resource number, and ”Ns” the total of the sub
resources.
We enrich this traditional resource definition with
a ”use case” part related to a particular business ex-
tension context. This allows to define the different
mitigation means associated to a particular business
context (see Fig. 1).
Figure 1: Security concepts associated to business service
protection.
3.2 Execution Context Specification
We define the execution context (ExCtx) as a set
of functional (FntCtx), organizational (OrgCtx) and
technical (TecCtx) specifications, which determine the
choice of security countermeasures to perform (see
eq. (2)).
ExCtx = (FntCtx, OrgCtx, TecCtx) (2)
The Functional Context (FntCtx) describes the re-
source set of Functional Requirement (FntReq) i.e.
the type of information (strategic, personal, finan-
cial...) used or handled by the resource and the re-
source information sensitive level (top secret, secret,
confidential, restricted, unclassified) related to its im-
portance (see eq. (3)).
FntCtx = {FntReq
f
} 0 < f <= N f (3)
Where ”FntReq
f
” is a functional requirement, ”f” re-
quirement number, and ”Nf ” the total of the func-
tional requirements. Each FntReq is defined as a tuple
(eq. (4)):
CLOSER2015-5thInternationalConferenceonCloudComputingandServicesScience
278

• FntReqId: is the id of functional requirement,
• FntReqT: is the information type (strategic, per-
sonal, financial...) used or handled by the re-
source,
• FntReqV: is the sensitive level (top secret, secret,
confidential, restricted, unclassified) indicating its
importance based on the risk analysis method.
FntReq = (FntReqId, FntReqT, FntReqV ) (4)
The Organizational Context (OrgCtx) is mostly fo-
cused on access control (authentication and autho-
rization), availability and non-repudiation. It allows
defining the obligations and the restriction constraints
in terms of access control, providing answers to the
following questions: Who can access and interact
with the resource? From which locality and at which
time? This Organizational Context (OrgCtx) includes
a set of organizational requirement (OrgReq) (see
eq. (5)).
OrgCtx = {OrgReq
o
} 0 < o <= No (5)
Where OrgReq
o
is an organizational requirement, ”o”
the requirement number, and ”No” the total of the or-
ganizational requirement. Each OrgReq has a tuple
(see eq. (6)):
• OrgReqId: is the organizational requirement id,
• OrgReqT: is the type of organizational require-
ment (Who, When, FromWhere).
• OrgReqW: defines the way that the requirement
is defined (”UserGroup” or ”individually” for
the ”who” requirement, ”date” or ”dateTime” for
”when”, and ”country” or ”region” or ”IPAd-
dress” for ”FromWhere”).
• OrgReqV: is the value related to OrgReqW, i.e.
the specific user or service which can invoke the
resource, its localization and the period the re-
source can be invoked.
OrgReq = (OrgReqId, OrgReqT, OrgReqT, OrgReqV )
(6)
The Technological Context (TecCtx) includes a set of
Technical Requirements (TecReq) related to the net-
work, devices and deployment platform involved in
the user / resource interaction at runtime (see eq. (7)).
TecCtx = {TecReq
t
} 0 < t <= Nt (7)
Where TecReq
t
is a technical requirement, ”t” the re-
quirement number, an ”Nt” the total of the technical
requirement.
Each TecReq
t
defines which technical mean (net-
works, devices) is used to access the resource. It is
defined as a Tuple including (eq. (8)):
• TecReqId: is the technical requirement id.
• TecReqT: is the type of technical element (device,
network, protocol, etc.) authorized to access or
interact with the resource.
• TecReqV: is the value (Smartphone, PC, IP ad-
dress) related to type of technical element.
TecReq = (TecReqId, TecReqT, TecReqV ) (8)
To support a context-aware security deployment, we
integrate this context information in the resource
model (see eq. (9)):
Res
k
= (ResN;ResT ; ResL; {SubRes
s
},
{ExCtx
e
}) 0 < e <= Ne
(9)
Where ExCtx
e
is a particular execution context, ”e” is
the execution context number, and ”Ne” the total of
the execution number.
Based on this model, listing 1 presents the Val-
idateSpec resource associated to the specification
checking service from our motivation example.
Listing 1: XML-based syntax representation of the vali-
dateSpec resource from our motivation example.
1 <r e s resN = ” / M e c h a n i c a l S y s t e m S p e c / v a l i d a t e S p e c ” r e s T = ”
S e r v i c e ” r e s L = ” S e r v i c e ”>
2 <ex Ctx i d = ” 1 ”>
3 <f n t C t x>
4 <fn t R e q f n t R e q I d = ” 2 ” f n t R e q T =” s t r a t e g i c ”
fntReqV =” S e c r e t ” />
5 </ fn t C t x>
6 <orgC t x>
7 <orgReq o r g R e q I d = ” 1 ” orgReq T = ” who ” orgReqW=”
UserGroup ” orgReqV =” { CAD Service } ” />
8 </ o r gCtx>
9 <t e c C t x>
10 <te c R e q t e c R e q I d = ” 2 ” t e c Req T =” N etwork / DNS”
tec R eqV =” { mechani c a l C o m pagny . com}” />
11 </ te c C t x>
12 </ exCt x>
13 <ex Ctx i d = ” 2 ”>
14 <f n t C t x>
15 <fn t R e q f n t R e q I d = ” 2 ” fn t R e q T =” s t r a t e g i c ”
fntReqV =” S e c r e t ” />
16 </ fn t C t x>
17 <orgC t x>
18 <orgReq o r g R e q I d = ” 1 ” orgReq T = ” who ” orgReqW=”
UserGroup ” orgReqV =” { PD MService } ” />
19 </ org C tx>
20 <te c C t x>
21 <te c R e q t e c R e q I d = ” 2 ” t e c Req T =” N etwork / DNS”
tec R eqV =” { mechani c a l C o m pagny . com}” />
22 </ t e c C t x>
23 </ e xCtx>
24 <exC t x i d =” 3 ”>
25 <f n t C t x>
26 <fn t R e q f n t R e q I d = ” 1 ” fn t R e q T =” s t r a t e g i c ”
fntReqV =” S e c r e t ” />
27 </ fn t C t x>
28 <orgC t x>
29 <orgReq o r g R e q I d = ” 1 ” orgReq T = ” who ” orgReqW=”
UserGroup ” orgReqV =” !{ CADService ,
CA DService } ” />
30 </ o r gCtx>
31 <t e c C t x>
32 <te c R e q t e c R e q I d = ” 2 ” t e c Req T =” N etwork / DNS”
tec R eqV =” ! { m e c hanica l C o m p a g ny . com} ” />
33 </ t e c C t x>
34 </ e xCtx>
35 </ r e s>
This listing describes the validateSpec resource
(Line 1) and its different execution contexts: Lines 2-
13 for Context 1, Lines 14-25 for Context 2 and Lines
Context-aware[e-mail]Deployment
279

26-37 for Context 3. Access control features are de-
fined for each context (see line 7 for Context 1, line
19 for Context 2 and line 31 for Context 3).
3.3 Context Aware Pattern Model
To generate the adapted protection means, the adapted
countermeasures are selected from the OASIS secu-
rity taxonomy. Our countermeasure pattern model is
a tuple (eq. (10)):
Pat
p
= (PatN, PatG, PatL, PatM, {PatCtx
c
},
PatR, {PatSet
s
}, PatCsq)
where 0 < (p, c, s) <= (N p, Nc, Ns)
(10)
• Pattern Name (PatN) is a unique name that refers
to one element of our security taxonomy.
• Pattern Goal (PatG) defines the reason for using
the pattern.
• Pattern layer (PatL) defines the layer of the pat-
tern (Business, Service, Technique).
• Pattern Metric (PatM) is the protection level pro-
vided by pattern (Very High, High, Medium, and
Lower) to fit risk sensitivity level (Top Secret, Se-
cret, Confidential, Restricted).
• Pattern Context (PatCtx
c
) defines the set of con-
texts in which the pattern is applicable. Each
PatCtx
c
includes a set of optional conditions
split into functional conditions (FntCdt), or-
ganizational conditions (OrgCdt) and technical
conditions (TecCdt) related to this context (see
eq. (11)).
PatCtx
c
= ({FntCdt
f
}, {OrgCdt
o
}, {TecCdt
t
})
0 < (c, f , o, t) <= (Nc, N f , No, Nt)
(11)
The FntCdt includes the information type
(FntCdtT) that the resource has to handle and sen-
sitive level value (FntCdtV) of this information for
which the pattern will be useful (eq. (12)).
FntCdt = (FntCdtT, FntCdtV ) (12)
For example data encryption pattern can be used if
the information sensitive level is secret, requiring
a high protection security. The OrgCdt (eq. (13))
defines among 3 organizational conditions which
type of conditions (OrgCdtT) are necessary to
make the pattern applicable:
– The ”who” condition defines the type of user
authorized to access the resource.
– The ”where” condition defines the authorized
location of the user.
– The ”when” condition defines time constraints
to accede to the resource.
Condition applicability (OrgCdtW) specifies the
control strategy. For example the XACML proto-
col can be used if the organizational condition is
defined and the access control mode is by ”User-
Group”.
OrgCdt = (OrgCdtT, OrgCdtW ) (13)
The technical condition (TecCdt) (eq. (14)) refers
to platform-dependent protection constraints. It
is used to select a pattern according to the type
of the technical component that is implemented
(TecCdtT) and the related value (TecCdtV).
TecCdt = (TecCdtT, TecCdtV ) (14)
• Pattern related (PatR) defines a set of related pat-
terns. For e.g., Authentication pattern can require
a set of different patterns (integrity and encryption
patterns) to secure authentication token.
• Pattern Setting (PatSet) (eq. (15)) describes the
set of parameters (Set) necessary to use a pattern.
These parameters are initialized according to the
execution context.
PatSet = {Set
s
} 0 < s <= Ns (15)
Where ”s” is the parameter number and ”Ns” the
total number of parameters. Each parameter (Set
k
)
is defined as a tuple (eq. (16)):
Set = (Setkey, SetValue) (16)
Where Setkey is the parameter name and SetValue
the value of the parameter.
• Pattern Consequence (PatCsq) describes the re-
sults or actions implemented by the pattern. The
set of patterns is defined by (eq. (17)):
Pats = {Pat
j
} where 0 < j <= N
j
(17)
Where ”j” is the pattern number and ”Nj” the total
number of patterns.
Based on the protection requirement to fulfill and
on information on the current deployment context,
the convenient mitigation pattern can be selected
to generate a security policy rule.
3.4 Reference Security Policy Model
Our formal security policy model, defined as a tuple
(eq. (18)), extends the OASIS policy model. For each
security criteria defined in the OASIS model, a set of
policy rules is defined and related to policy context.
By this way, the security mechanisms that must be de-
ployed to provide a consistent protection can be tuned
depending on the execution context.
Pol
x
= (PolR, PolT, PolG, PolL, PolRls) 0 < x <= Nx
(18)
Where
CLOSER2015-5thInternationalConferenceonCloudComputingandServicesScience
280

• Policy Resource (PolR): is the resource (Business
service, data, etc.) involved in the policy.
• Policy type (PolT): refers to the security ser-
vice taxonomy (Authentication, Confidentiality,
Integrity, Non-repudiation, Availability, etc.)
• Policy Goal (PolG): defines the policy aims.
• Policy Layer (PolL): is the layer (Business, Ser-
vice or Infrastructure) of the involved resource for
this policy.
• Policy Rules (PolRls): is a set of policy rules
(eq. (19)). Each policy rule (PolRl
r
) defines the
security mechanism to apply according to the re-
source execution context.
PolRls = {PolRl
r
} 0 < r <= N
r
(19)
Where PolRl
r
is a policy rule, ”r” the policy rule num-
ber, and ”Nr” the total of policy rules. Each policy
rule is also defined as a tuple (eq. (20)):
PolRl = (RlId, RlP, RlM, RlCtx, {RlSet}) (20)
Where:
• Policy Rule Id (Rlid): is the policy rule id,
• Policy Rule Pattern (RlP): is the name of the pat-
tern which matches the resource execution con-
text.
• Policy Rule Metric (RlM): is the pattern associ-
ated metric which matches the resource execution
context. It is the protection level provided by the
pattern.
• RlCxt: includes the part of the pattern context
which matches the resource execution context.
• RlSet: is the initialized pattern settings allowing
to invoke the security mechanism.
Then all the policies associated to a resource are gath-
ered in a single set (eq. (21)):
Pols = {PolR
x
} where 0 < x <= N
x
; (21)
Where ”x” is the policy number and ”Nx” the total
number of policy (for all resources).
Lastly, policy attached to any resource Rk can be
defined by selecting (σ) the policy in the Pols set
where the policy resource (PolR) matches with re-
source ”R
k
”:
Pols(R
k
) = σ
(Pols.PolR=R
k
)
(Pols) (22)
This security policy is used to generate a secu-
rity policy file attached to the resource description
(WSDL
5
or WADL
6
file) that contains all the secu-
rity assertions and their application context. Listing 2
5
http://www.w3.org/TR/wsdl
6
http://www.w3.org/Submission/wadl/
shows the security policy of the specification valida-
tion operation (validateSpec) of the Mechanical Sys-
tem specification business service, namely authenti-
cation (Lines 2-14) if the calling service is not the cor-
porate CADService, authorization (Lines 27-39), non
repudiation (Line 15-26) and communication channel
protection (Lines 40-54).
Listing 2: validateSpec service security policy expressed
using XML syntax.
1 <p o l s>
2 <p o l p o l I d = ” 1 ” polR = ” / m e c h a n i c a l S y s t e m S p e c /
v a l i d a t e S p e c ” p o l T =” A u t h e n t i c a t i o n ”>
3 <polR r l I d =1 RlP = ” LoginPWD” , rlM = ” 0 . 5 ”>
4 <r l C t x>
5 <orgCdt org ReqT = ” who ” orgReqW= ” UserG r o u p ”
orgReqV = ” !{ CADS erv ice } ” />
6 <te c C d t t e cReq T =” N e twork ” tecReq V =” N etwork /
DNS” t ecReqV =” ! { m echanic a l C o m p a gny . com}
” />
7 </ r l C t x>
8 <r S e t s> <rS e t s e t k e y =” u s e r R e g i s t r y ” s e t V a l u e = ”
d a t a / U s e r R e g i s t r y . xml ” />
9 </ r S e t s>
10 </ polR>
11 </ po l>
12 <p o l p o l I d = ” 2 ” polR = ” / m e c h a n i c a l S y s t e m S p e c /
v a l i d a t e S p e c ” p o l T =” No n R e p u d i a t i o n ”>
13 <polR r l I d = ” 1 ” RlP=” Log ” , rl M = ” 0 . 5 ”>
14 <r l C t x>
15 <orgCdt org ReqT = ” who ” orgReqW= ” UserG r o u p ”
orgReqV = ” !{ CADS erv ice } ” />
16 <te c C d t t e cReq T =” N e twork ” tecReq V = ” IP ” />
17 </ r l C t x>
18 <r S e t s>
19 <r S e t s e t k e y = ” l o g F i l e ” v a l u e = ” l o g . l o g ” />
20 </ r S e t s>
21 </ polR>
22 </ po l>
23 <p o l p o l I d = ” 3 ” polR = ” / m e c h a n i c a l S y s t e m S p e c /
v a l i d a t e S p e c ” p o l T =” A u t h o r i z a t i o n ”>
24 <polR r l I d = ” 1 ” RlP=”ACL” , r lM=” 0. 5 ”>
25 <r l C t x>
26 <orgCdt org ReqT = ” who ” orgReqW= ” UserG r o u p ”
orgReqV = ” !{ CADService , PDMSer vice } ” />
27 <te c C d t t e cRe q T =” N e twork ” tecReq V = ” Netw o rk /
DNS” t ecReqV =” ! { m echanic a l C o m p a gny . com} ”
/>
28 </ r l C t x>
29 <r S e t s>
30 <r S e t s e t k e y = ” ACL File ” v a l u e = ” a c l /
A c c e s s C o n t r o l L i s t . xml ” />
31 </ r S e t s>
32 </ polR>
33 </ po l>
34 <p o l p o l I d = ” 4 ” polR = ” / m e c h a n i c a l S y s t e m S p e c /
v a l i d a t e S p e c ” p o l T =” C o n f i d e n t i a l i t y ”>
35 <polR r l I d = ” 1 ” RlP=” En c r y p t i o n A E S 1 2 8 ” , rlM = ”
0 . 7 5 ”>
36 . . . .
37 . . . .
38 </ polR>
39 </ po l>
40 <p o l s>
4 CONTEXT AWARE SECURITY
DEPLOYMENT
Taking advantage of the loosely coupled strategy,
we use the middleware online interception capability
to intercept each service/middleware interaction and
routes this interaction to our context aware architec-
ture (Fig. 2) built as an add-on component. It consists
in:
Context-aware[e-mail]Deployment
281

• a Context Aware Deployment composite which is
the core component to achieve the dynamic se-
curity deployment. This component is split into
three sub components:
– The Context Aware Security component analy-
ses the calling service requests intercepted by
the middleware and encapsulated into a Re-
quest object. It invokes the policy manager and
the context manager to get the security policy
rules associated to the business services fitting
the context before invoking the required secu-
rity services.
– The Context Manager analyses security poli-
cies associated to the services and identifies the
different policies to be applied according to the
current context.
– The Policy Manager identifies the list of poli-
cies fitting the context from the global policy
file associated to the resource.
• The Security as a Service (SecaaS) composite
gathers implementation of various security ser-
vices (authentication, authorization, integrity con-
trols, etc.) such as:
– The SecaaS component is the composite en-
try point. It analyses the policies sent by the
Context Manager component to identify the se-
curity services (authentication, authorization,
etc.) to call.
– The security components (Authentication,
Authorization, Integrity, Encryption, Non-
Repudiation Availability) invoke the security
service depending on the pattern and parame-
ters specified in the policy.
Figure 2: Context aware security architecture.
5 EVALUATION
To evaluate the impact of our Context Aware Deploy-
ment, we implement a Proof of Concept plugged on
the Frascati middleware (Merle et al., 2011) extend-
ing our Model Driven Policy generator presented in
(Ouedraogo et al., 2013). We then use this prototype
to support various experiments on BP protection poli-
cies specification depending on shared collaborative
context.
5.1 Performance Evaluation
We assume that the cloud oriented service middle-
ware provides a unified environment to invoke busi-
ness services dispatched on a multi-cloud platform.
As a consequence, we set a test on a single machine
environment using Frascati version 1.6 with Oracle
Java Virtual Machine 1.7.0 51 on Microsoft Windows
7 Professional (32 bit) using a 2,54GHz processor In-
tel(R) Core(TM) 2 Duo CPU with 4Go of memory to
compare the dynamic security deployment execution
time with the business service and the protection ser-
vice execution times.
In our example, the ”validateSpec” of the ”me-
chanicalSystemSpec” service and the related informa-
tion must be protected in the different contexts. The
confidentiality requirement impacts both application
layer, which is in charge of the access control, trace-
ability, and transport layer. The systematic composi-
tion of the authorization, traceability and confidential-
ity services may be costly (see the different execution
times reported in Table 1).
Table 1: ValidateSpec Service execution time according to
the three contexts.
Context Security services involved mechanical Specifi-
cation
Execution
time (ms)
Context 1 No security mechanism is required 64
Context 2 Authentication and Non Repudiation 80
Context 3 Context 2 security services + Authorization and
Confidentiality
84
The contextualized security service orchestration
allows invoking only the necessary security mech-
anisms according to the context, avoiding both the
costly over protection and the risky under protection.
This dynamic protection does not impact the daily
used BP and simplifies the security policy consis-
tency controls as new protection requirements are in-
troduced once in the service policy specification and
implemented for the different collaborative BP with-
out impacting the business process deployment.
Other performance simulations have first been
conducted in order to evaluate the performance over-
head involved by the context analysis at run time. We
extend this benchmark to different services (see Ta-
ble 2) to compare the cost of our context-aware ar-
chitecture with the business service execution time.
We set two reference execution contexts, one requir-
ing no security deployment (Context 1) whereas the
other requires the maximum protection (i.e system-
atic protection required in Context 3 from our moti-
vation example). Total execution times are measured
CLOSER2015-5thInternationalConferenceonCloudComputingandServicesScience
282

Table 2: Execution times for a panel of 1000 invocations of business services where the ”no protection” rate evolves from 0%
to 100%.
Systematic
protection
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
S1 (10ms) 32000 38000 35800 33600 31400 29200 27000 24800 22600 20400 18200 16000
S5 (50ms) 72000 78000 75800 73600 71400 69200 67000 64800 62600 60400 58200 56000
S10(100ms) 122000 128000 125800 123600 121400 119200 117000 114800 112600 110400 108200 106000
for 1000 invocations split among different occurrence
rate for context 1 (see Table 2). The ratio comparing
the context-aware secured business service execution
time with the systematically secured business service
execution time presents a maximum of 4,92% over-
head for the bigger service to 18,75% for the small-
est one when these services invocation requires the
highest protection (0% of occurrence of the ”no pro-
tection context”). On the opposite, our context aware
security deployment can save from 50% up to 86,89%
of execution time when all invocation do not need
any protection. These results show that the overhead
involved by our architecture can be rather neglected
(from 4,92% to 18,75% of the service execution time
overhead when the highest protection is always re-
quired) compared to the large overhead introduced by
the systematic invocation of (often) useless security
services provided that the ”no protection” invocation
context rate is greater than 30% as shown in Fig. 3.
Figure 3: Variation of context aware security execution cost
for three business services.
6 CONCLUSION
To secure business services used in collaborative envi-
ronment, enterprises have to adapt the protection ac-
cording to the execution context. To this end, we pro-
pose a context aware security model and architecture
used to select and orchestrate security services at run-
time. This architecture, tested on the Frascati middle-
ware, shows that the dynamic security mediation has
a rather low impact on the performance level com-
pared with a systematic deployment of costly over-
protection.
Further works will focus on the integration of
more detailed platform models and on vulnerabilities
monitoring loops so that our coarse-grained vision of
the execution context will be refined to increase the
protection efficiency.
REFERENCES
Ban, L. B., Cocchiara, R., Lovejoy, K., Telford, R., and
Ernest, M. (2010). The evolving role of it managers
and cios.
Bartoletti, M., Degano, P., and Ferrari, G. (2005). Enforc-
ing secure service composition. In Computer Security
Foundations, 2005. CSFW-18 2005. 18th IEEE Work-
shop, pages 211–223.
Bartoletti, M., Degano, P., and Ferrari, G. (2006). Secu-
rity issues in service composition. In Gorrieri, R.
and Wehrheim, H., editors, Formal Methods for Open
Object-Based Distributed Systems, volume 4037 of
Lecture Notes in Computer Science, pages 1–16.
Springer Berlin Heidelberg.
Heiser, J. and Nicolett, M. (2008). ssessing the security
risks of Cloud Computing. Technical report, Gartner.
Lang, U. and Schreiner, R. (2009). Model Driven Security
Management: Making Security Management Man-
ageable in Complex Distributed Systems. In Work-
shop on Modeling Security (MODSEC08) - Interna-
tional Conference on Model Driven Engineering Lan-
guages and Systems (MODELS).
Lucio, L., Zhang, Q., Nguyen, P. H., Amrani, M., Klein, J.,
Vangheluwe, H., and Traon, Y. L. (2014). Chapter 3 -
Advances in Model-Driven Security. In Memon, A.,
editor, Advances in Computers, volume 93, pages 103
– 152. Elsevier.
Merle, P., Rouvoy, R., and Seinturier, L. (2011). A Re-
flective Platform for Highly Adaptive Multi-Cloud
Systems. In International Workshop on Adaptive
and Reflective Middleware (ARM’11) - 12th ACM/I-
FIP/USENIX International Middleware Conference,
pages 14–21. ACM.
Ouedraogo, W. F., Biennier, F., and Ghodous, P. (2013).
Model driven security in multi-context. In Interna-
tional Journal of Electronic Business Management,
volume 11 No. 3, pages 178–190.
Rodr
´
ıguez, A., Fern
´
andez-Medina, E., and Piattini, M.
(2007). A BPMN Extension for the Modeling of Se-
curity Requirements in Business Processes. IEICE -
Trans. Inf. Syst., E90-D(4):745–752.
Wolter, C., Menzel, M., Schaad, A., Miseldine, P., and
Meinel, C. (2009). Model-driven business process se-
curity requirement specification. Journal of Systems
Architecture (JSA), pages 211–223.
Context-aware[e-mail]Deployment
283