Christophe Rouzaud

Fabrice Gatuingt

Olivier Dorival

Hervé Guillaume

Louis Kovalevsky

A new methodology for assessing the global dynamic response of large shell structures under impact loading

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

1,2,3 1 4,5 2 6 m m m m 1 m 2 k 1 k 2 m 1 ẍ1 (t) + k 1 [x 1 (t) -x 2 (t)] = 0 m 2 ẍ2 (t) -k 1 [x 1 (t) -x 2 (t)] + k 2 x 2 (t) = 0 x 1 (t) x 2 (t) F (t) = k 1 x 1 (t) m 1 ẍ1 (t) + k 1 x 1 (t) = 0 m 2 ẍ2 (t) + k 2 x 2 (t) = F (t) F (t) F (t) = R cr (x cr ) + m c (x cr )
dx cr dt 0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 1

Impact force / Max. impact force Time / Max. time

f ω Ω Ω i i Γ x y z e α e β e 3 r(α, β) B R ∂Ω i n t k r k t η r η t U u w σ K N M h ρ η K CP E D ν S ad U h σ h U n C n X P ϕ θ C R E tot E d T n l λ c c c n f = ω 2π h i ρ i U i U i (x,
y, z) = u i (x, y) + w i (x, y) e 3 i + zθ i θ i (x, y) = -grad w i (x, y) -B i u i (x, y)

u i w i B i α i β i r i (α i , β i ) Ω i r i (α i , β i ) ∂r i ∂αi = A i e α i ∂r i ∂βi = B i e β i e α i e β i e 3 i e 3 i = e α i ∧ e β i α i β i α i → r i (α i , β 0i ) β i → r i (α 0i , β i ) e α i , e β i , e 3 i B i =   -1 Rαi 0 0 0 -1 R βi 0 0 0 0   eα i ,e β i ,e3 i R αi R βi Ω n Ω i Γ Ω i ∂ w Ω i ∂ u Ω i ∂ w,n Ω i ∂ K Ω i ∂ N Ω i ∂ M Ω i Ω i Ω j (u i , w i , K i , N i , M i ) u i - 1 k tbi (1+iη tbi ) N i = u id ∂ u Ω i w i - 1 k tbi (1+iη tbi ) K i = w id ∂ w Ω i w i,n + 1 k rbi (1+iη rbi ) n i .M i .n i = w i,nd ∂ w,n Ω i u i .n i = -α ij u j .n j + (1 + α ij ) w j - 1 ktij (1+iηtij ) (-N i .n i -α ij N j .n j + (1 + α ij ) K j ) Γ ij w i = -α ij w j + (1 + α ij ) u j .n j - 1 ktij (1+iηtij ) (-K i -α ij K j + (1 + α ij ) N j .n j ) Γ ij u i .t i = -β ij u j .t j - 1 ktij (1+iηtij ) -N i .t i -β ij N j .t j Γ ij w i,n = β ij w j,n - 1 krij (1+iηrij ) n i M i n i -β ij n j .M j .n j Γ ij α ij = n i .n j β ij = t i .t j k rbi k tbi η rbi η tbi Ω i k rij k tij η rij η tij Γ ij Ω i Ω j Ω i N i -B i div M i = -ρ i ω 2 h i u i Ω i div div M i + T r N i .B i = -ρ i ω 2 h i w i Ω i N i = N i .n i -B i .M i .n i = N id ∂ N Ω i K i = n i .div M i + t i .M i .n i ,t = K id ∂ K Ω i n i .M i .n i = M id ∂ M Ω i t i .M i .n i ∂Ωi = 0 Γ ij N i .n i = α ij N j .n j -(1 + α ij ) K j Γ ij K i = α ij K j -(1 + α ij ) N j .n j Γ ij N i .t i = β ij N j .t j Γ ij n i .M i .n i = -β ij n j .M j .n j Γ ij n i=1 (n i .M i .n i )t i = 0 n i=1 (N i .n i -K i ) = 0 M i = hi 3 12 K CPi : X (w i ) Ω i N i = h i K CPi : γ (u i ) Ω i K CPi = (1 + iη i )K 0i ρ i η i X γ K CPi = (1 + iη i )     Eαi 1-ναiν βi ναiEαi 1-ναiν βi 0 ν βi E βi 1-ναiν βi E βi 1-ναiν βi 0 0 0 √ EαiE βi 2(1+ √ ναiν βi )     eα i ,e β i ,e3 i X (u i ) = (θ i ) - B i . (u i + w i e 3 i ) γ (u i ) = (u i + w i e 3 i ) E α,βi ν α,βi e α i e β i h i st (U i , σ i ) = (u i , w i , K i , N i , M i ) ∈ S ad,i A   s 1 . . . s n , δs 1 . . . δs n   = L   δs 1 . . . δs n   A   s 1 . . . s n , δs 1 . . . δs n   =Re -iω n i=1 ∂uΩi δσ i .n i .U * i dS + n i=1 ∂ F Ωi σ i .n i .δU * i dS + Γij    n-1 n n i=1 δσ i .n i .(U i ) * + 1 n i =j δσ i .n i . U j * + 1 n n i=1 σ i .n i .(δU i ) * -1 n i =j σ i .n i . δU j *    dS      L   δs 1 . . . δs n   = Re -iω n i=1 ∂uΩi δσ i .n i .U * id dS + n i=1 ∂ F Ωi F id .δU * i dS ∂ u Ω i Ω i ∂ F Ω i Ω i Γ ij Γ ij Re S 0 ad,i Ω i f d,i = 0 i = 1, . . . , n S 0 ad,i ≡ S ad,i i = 1, . . . , n S ad,i K CP i η i > ∀ i = 1, . . . , n ∀ j = i        k ri η ri ≥ 0 k ti η ti ≥ 0 k rij η rij ≥ 0 k tij η tij ≥ 0 (U i h , σ h i ) U i (X i , P i ) = P i Ci U n i (P i ) .e P i .X i Ω i σ i (X i , P i ) = P i Ci C n i (P i ) .e P i .X i Ω i X i U n i C n i n P i C i U i , σ i S ad,i P i w i Ω i hi 3 12 div div K CPi : X (w i ) + h i T r K CPi : γ (u i ) .B i = -ρ i ω 2 h i w i Ω i P i (P T i .P i ) 4 = 12(1 -ν αi ν βi )ρ i ω 2 (1 + iη i )E α,βi h 2 i (P T i .P i ) 2 - 12(1 -ν αi ν βi ) h 2 i (P T i .R.B i .R.P i ) 2 R = 0 -1 1 0 R T = -R B i (P T i .P i ) 4 = 12(1 -ν αi ν βi )ρ i ω 2 (1 + iη i )E α,βi h 2 i (P T i .P i ) 2 u 1 i w 0i = w i w i P i R.P i u 1 i u 1 i = AP i + BR.P i A = w 0i 1-ναiν βi E α/βi P T i .K CP i .B i .P i (P T i .P i ) 2 B = w 0i 2E α/βi 1+ √ ναiν βi P T i .K CP i .B i .R.P i (P T i .P i ) 2 u 0 i = 0 w i γ (u i ) = (u i + w i e 3 i ) P i    w h interior,i X i , P int,i = W h interior,i P int,i .e P int,i .X i Ω i w h edge,i X i , P edg,i = W h edge,i P edg,i .e P edg,i .X i Ω i w h corner,i X i , P cor,i = W h corner,i P cor,i .e P cor,i .X i Ω i P int,i (ϕ int,i ) = -ip int,i (ϕ int,i ) cosϕ int,i sinϕ int,i eα i ,e β i = -i p α,int,i (ϕ int,i ).cosϕ int,i p β,int,i (ϕ int,i ).sinϕ int,i eα i ,e β i p α/β,int,i (ϕ) p α/β,int,i 4 (ϕ int,i ) = p plate,α/β,i 4 - (p shell,α,i .sinϕ int,i ) 2 + (p shell,β,i .cosϕ int,i ) 2 2 p plate,α/β,i = 12ρiω 2 (1-ναiν βi ) (1+iηi)E α/βi h 2 i 1 4 p shell,α/β,i = 12ρiω 2 (1-ναiν βi ) R 2 α/βi h 2 i 1 p int,i (ϕ int,i ) C int,i C int,i p int,i ϕ int,i = 0 45 90 p int,i (ϕ int,i )
P edg,i (ϕ edg,i ) = P t,edg,i (ϕ edg,i )t + P n,edg,i (ϕ edg,i )n Re(P n,edg,i ) Im(P n,edg,i )

t n P n,edg,i (ϕ edg,i ) = (1 + iη i ) 1 4 1 + sin 2 (ϕ edg,i ) -i ηi 4 . 1 √ 1+sin 2 (ϕ edg,i ) p plate,α,i p plate,β,i eα i ,e β i P t,edg,i (ϕ edg,i ) = i(1 + iη i ) 1
u i Ω i u i h i K CPi : γ (u i ) -hi 3 12 B i .div K CPi : X (w i ) = -ρ i ω 2 h i u i Ω i (u h , N h i ) u i (X i , P i ) = P i Ci u n i (P i ) .e P i .X i Ω i N i (X i , P i ) = P i Ci N n i (P i ) .e P i .X i Ω i X i P i C i u n i N n i n X i P i (u i , N i ) S ad,i          N i -B i div M i = -ρ i ω 2 h i u i Ω i M i = hi 3 12 K CPi : X (w i ) Ω i N i = h i K CPi : γ (u i ) Ω i 0 u 0 i = u i N 0 i = N i u 0 pres,i P pres,i
u pres,i X i , P pres,i = u 0 pressure,i P pres,i .e P pres,i .X i Ω i u 0 pressure,i P pres,i = u 0pres,i cosθ pres,i sinθ pres,i eα i ,e β i P pres,i (θ pres,i ) = ip pres,i (θ pres,i ) = i(p α,pres,i .cos(θ pres,i )e α i + p β,pres,i .sin(θ pres,i )e β i )

p 2 α/β,pres,i = ρ i ω 2 (1 -ν αi ν βi ) E α/βi (1 + iη i ) p pres,i (θ pres,i ) C pres,i C pres,i
C pres,i u 0 shea,i P shea,i e 3 i u shea,i X i , P shea,i = u 0 shear,i P shea,i .e P shea,i .X i Ω i u 0 shear,i P shea,i = u 0shea,i -sinθ shea,i cosθ shea,i eα i ,e β i P shea,i (θ shea,i ) = ip shea,i (θ shea,i ) = i(p α,shea,i .cos(θ shea,i )e α i + p β,shea,i .sin(θ shea,i )e β i )

p 2 α/β,shea,i = 2ρ i ω 2 (1 + √ ν αi ν βi ) E α/βi (1 + iη i ) p shea,i (θ shea,i ) C shea,i C shea,i E tot = E d + T E tot E d T U h i (P i ) ϕ int/edg/cor,i θ pres/shea,i
C int/edg/cor/pres/shea,i C int/edg/cor/pres/shea,i ) .e P pres,i (θpres,i).x i dθ pres,i

w h i (x i ) = ϕint,iCint,i W h interior,i (ϕ int,i )e P int,i (ϕint,i).x i dϕ int,i + ϕ edg,i C edg,i W h edge,i (ϕ edg,i )e P edg,i (ϕ edg,i ).x i dϕ edg,i + ϕcor,iCcor,i W h corner,i (ϕ cor,i )e P cor,i (ϕcor,i).x i dϕ cor,i                              P int,i (ϕ int,i ) = -i p α,int,i (ϕ int,i ).cosϕ int,i p β,int,i (ϕ int,i ).sinϕ int,i eα i ,e β i P edg,i (ϕ edg,i ) =      (1 + iη i ) 1 4 1 + sin 2 (ϕ edg,i ) -i ηi 4 . 1 √ 1+sin 2 (ϕ edg,i ) p plate,
+ θ shea,i C shea,i u 0 h shear,i (θ shea,i
) .e P shea,i (θ shea,i ).x i dθ shea,i

                   u 0 h pressure,i (θ pres,i ) = u 0pres,i cosθ pres,i sinθ pres,i eα i ,e β i
P pres,i (θ pres,i ) = i(p α,pres,i .cos(θ pres,i )e α i + p β,pres,i .sin(θ pres,i )e β i )

u 0 h shear,i (θ shea,i ) = u 0shea,i -sinθ shea,i cosθ shea,i eα i ,e β i P shea,i (θ shea,i ) = i(p α,shea,i .cos(θ shea,i )e α i + p β,shea,i .sin(θ shea,i )e β i ) S ad,i p i S ad,i S h ad,i U h (P i (ϕ i )) n i l α/βi Ω i n i = 2l α/βi λ α/βi = ωl α/βi πc α/βi = l α/βi √ ω π 4 ρ i h i D α/βi λ α/βi e α i e β i ω c α/βi = √ ω 4 D α/βi ρihi ρ i h i D α/βi D α/βi = E α/βi h 3 i 12(1-ναiν βi ) n i c α/βi = E α/βi ρi(1-ναiν βi ) c α/βi = √ EαiE βi 2ρi(1+ √ ναiν βi ) ϕ mn w analytical (x, y) = ∞ m=1 ∞ n=1
a mn ϕ mn (x, y) Frequency VTCR approach (6000 DOFs) Temporal FEM approach (25 elements per wavelength)

a mn = F sin( mπx F Lx )sin nπy F Ly Lx Ly 4 ρh(w 2 mn -w 2 ) ϕ mn = sin mπx Lx sin nπy Ly w h analytical (x, y) = M m=1 N n=1 a mn ϕ mn (x, y) M N M Lx π 4 12ω 2 ρ(1-ν 2 ) Eh 2 N Ly π 4 12ω 2 ρ(1-ν 2 ) Eh 2 k 3 h 2 k h w F,inf inite (x, y) = -iF 8 Eh 3 12(1-ν 2 ) 12ω 2 ρ(1-ν 2 ) Eh 2 J 0 ( 4 12ω 2 ρ(1 -ν 2 ) Eh 2 r) -iY 0 ( 4 12ω 2 ρ(1 -ν 2 ) Eh 2 r) - 2i π K 0 ( 4 12ω 2 ρ(1 -ν 2 ) Eh 2 r) r x F J 0 Y 0 K 0 ≈ X Load ≈ P 2 P 1 w P 1 (t) =100 sin (2π10t +
P 2 A   s 1 . . . s n , δs 1 . . . δs n   = Re                                                                                      -iω                                            n i=1 ∂w ,n Ωi δn i M i n i . w i,n + 1 kri(1+iηri) n i M i n i * dl - n i=1 ∂wΩi δK i . w i - 1 kti(1+iηti) K i * dl - n i=1 ∂uΩi δN i . u i - 1 kti(1+iηti) N i * dl + n i=1 ∂ M Ωi n i M i n i .δw * i,n dl- n i=1 ∂ K Ωi K i .δw * i dl- n i=1 ∂ N Ωi N i .δu * i dl - n i=1 ∂Ωi (t i M i n i ).δw * i + n-1 n n i=1 Γij δn i M i n i . w i,n + 1 krij (1+iηrij ) n i M i n i * dl -1 n i =j Γij δn i M i n i . β ij w j,n - 1 krij (1+iηrij ) -β ij n j M j n j * dl + 1 n n i=1 Γij δw i,n * . n i M i n i dl + 1 n i =j Γij δw j,n * . β ij n i M i n i dl -n-1 n n i=1 Γij (δK i ) . w i + 1 ktij (1+iηtij ) (-K i ) * dl -1 n i =j Γij (δK i ) . α ij w j -(1 + α ij ) u j n j + 1 ktij (1+iηtij ) (-α ij K j + (1 + α ij ) N j n j ) * dl -1 n n i=1 Γij (δw i ) * . (K i ) dl -1 n i =j Γij (δw i ) * . -α ij K j + (1 + α ij )N j n j dl -n-1 n n i=1 Γij (δN i n i ) . u i n i + 1 ktij (1+iηtij ) (-N i n i ) * dl -1 n i =j Γij (δN i n i ) . α ij u j n j -(1 + α ij ) w j + 1 ktij (1+iηtij ) (-α ij N j n j + (1 + α ij ) K j ) * dl -1 n n i=1 Γij (δu i n i ) * . (N i n i ) dl -1 n i =j Γij (δu i n i ) * . -α ij N j n j + (1 + α ij )K j dl -n-1 n n i=1 Γij (δN i t i ) . u i t i + 1 ktij (1+iηtij ) (-N i t i ) * dl -1 n i =j Γij (δN i t i ) . β ij u j t j + 1 ktij (1+iηtij ) -β ij N j t j * dl -1 n n i=1 Γij (δu i t i ) * . (N i t i ) dl -1 n i =j Γij (δu i t i ) * . -β ij N j t j dl                                                                                                                                 L  

  10) -200 sin (2π20t + 20) + 300 sin (2π30t + 30) -400 sin(2π40t + 40)

  Re(P cor,i ) Im(P cor,i )

	P cor,i (ϕ cor,i ) = p cor,i	cosϕ cor,i sinϕ cor,i	eα i ,e β i	=	p plate,α,i .cosϕ cor,i p plate,β,i .sinϕ cor,i	eα i ,e β i
			4 sinϕ edg,i	p plate,α,i p plate,β,i	eα i ,e β i


Aline Bousquet
email: aline.bousquet@insa-cvl.fr

Jérémy Briffaut
email: jeremy.briffaut@insa-cvl.fr

Eddy Caron

Eva María Dominguez
email: eva.dominguez@ikusi.com

Javier Franco
email: jfranco@vicomtech.org

Arnaud Lefray
email: arnaud.lefray@ens-lyon.fr

Oscar López

Saioa Ros

Jonathan Rouzaud-Cornabas
email: jonathan.rouzaud-cornabas@inria.fr

Christian Toinard
email: christian.toinard@insa-cvl.fr

Mikel Uriarte
email: muriarte@nextel.es

Enforcing Security and Assurance Properties in Cloud Environment

Keywords: Security, Cloud, Assurance, Enforcement, Use-case

Before deploying their infrastructure (resources, data, communications, ...) on a Cloud computing platform, companies want to be sure that it will be properly secured. At deployment time, the company provides a security policy describing its security requirements through a set of properties. Once its infrastructure deployed, the company want to be assured that this policy is applied and enforced. But describing and enforcing security properties and getting strong evidences of it is a complex task.

To address this issue, in [1], we have proposed a language that can be used to express both security and assurance properties on distributed resources. Then, we have shown how these global properties can be cut into a set of properties to be enforced locally. In this paper, we show how these local properties can be used to automatically configure security mechanisms. Our language is context-based which allows it to be easily adapted to any resource naming systems e.g., Linux and Android (with SELinux) or PostgreSQL. Moreover, by abstracting low-level functionalities (e.g., deny write to a file) through capabilities, our language remains independent from the security mechanisms. These capabilities can then be combined into security and assurance properties in order to provide high-level functionalities, such as confidentiality or integrity. Furthermore, we propose a global architecture that receives these properties and automatically configures the security and assurance mechanisms accordingly. Finally, we express the security and assurance policies of an industrial environment for a commercialized product and show how its security is enforced.

I. INTRODUCTION

In security, three main concepts commonly known as the CIA-triad (not to be confused with the US agency) has been widely used for decades: Confidentiality, Integrity and Availability. Both the Departement Of Defense guidelines (TCSEC/Orange Book) [START_REF]Trusted Computer System Evaluation Criteria (Orange Book)[END_REF] edited in 1985 and the more recent Common Criteria (ISO/IEC 15408) international standard define security as an integration of availability, confidentiality and integrity.

In a survey [START_REF]Cloud Adoption Practices and Priorities Survey Report[END_REF] on Cloud adoption practices, the Cloud Security Alliance (CSA) indicates that 73% of the participating industries are concerned about the security of their data. Thus, while many companies are transitioning to Cloud computing, they are also worried about the security risk. But Cloud platforms lack of reliable security [START_REF] Jaeger | Outlook: Cloudy with a Chance of Security Challenges and Improvements[END_REF]. Furthermore, Halpern et al. [START_REF] Halpern | Using first-order logic to reason about policies[END_REF] state that security policies described in a natural language have quite ambiguous semantics. To answer these problems, we need to provide a way (a language) to let the Cloud tenants (e.g., companies) express their security requirements i.e., through a security policy. This security policy must them be enforced on the Cloud platform and assurance reports (i.e., proofs) of this enforcement must be given to the tenants.

A single security mechanism cannot protect a heterogeneous and multi-layer system such as a Cloud [START_REF] Sandhu | Towards a Discipline of Mission-Aware Cloud Computing[END_REF]. Consequently, it is a set of uncoupled (and already existing) mechanisms that will be used to enforce the security. However, even if the mechanisms are uncoupled, it is mandatory to carefully take into account their capabilities (i.e., what they are able to enforce) and configure all of them at once to provide the wanted security. But, each of these mechanisms also comes with its own configuration language.

In [START_REF] Bobelin | An advanced securityaware cloud architecture[END_REF], we have defined a specification language for global security properties (i.e., properties that involve distributed resources). We have shown how these global properties can be automatically cut into a set of local properties. These local properties can be used to automatically configure security mechanisms. Moreover, our common independent language abstracting low-level capabilities can be used to provide proofs of security enforcement (i.e., assurance).

As said previously, the tenants also require to receive a proof that their security is indeed enforced during the whole life cycle of the infrastructure. Accordingly, using our language, the tenants can expressed their security assurance requirements.

Once the security and assurance policies has described a set of properties to enforce, an architecture is required to automatically configure distributed and heterogeneous mechanisms. Furthermore, this architecture must also send back assurance reports to the tenants.

To show the usability and capacities of our solution, we describe how our language has been used to define the security policy of a complete industrial application. Then, we show how our architecture is used to automatically enforce the policy and generate assurance reports of it. This paper is organized as follows. In Section II, we present a set of existing security mechanisms that could be used to provide security in Clouds, and the related work around Cloud security and assurance. Section III describes the language and the architecture we use for the security policy enforcement and assurance. Section IV details an industrial use-case and the whole process to secure it, and Section V concludes this paper.

II. RELATED WORK

The solution proposed in this paper aims to both enforce and assure security properties, such as confidentiality or integrity. Hence, this section first describes the works related to the definition of security properties and their enforcement. Then, we quickly present the security mechanisms we will use in Section IV. Finally, we present some existing solutions for assurance.

A. Security Policy and Enforcement

Because of the ever increasing adoption of Cloud Computing platforms, many researches have been done to improve their security. As stated in [START_REF] Sandhu | Towards a Discipline of Mission-Aware Cloud Computing[END_REF], a security policy language is required to allow the tenants to express their security requirements. Indeed, this makes sense that the tenants define their security as they are the ones that know the best their infrastructure and its security requirements. Some of works related to security policy languages are specific to a programming language and require the modification of the application sources. Ponder2 [START_REF] Twidle | Ponder2: A policy system for autonomous pervasive environments[END_REF] is a distributed object management system. The Ponder2 language can express security and management policies for distributed systems. It is declarative and object-oriented and can be used to declare different types of policies. Consequently, it can only be used on Java application augmented with the Ponder2 solution. Same for the A4Cloud project described in [START_REF] Pearson | Accountability for cloud and other future internet services[END_REF] and its associated language, A-PPL. Furthermore, this solution focuses on privacy and accountability, but does not address other classes of security, such as isolation.

Works such as [START_REF] Chen | On-demand security architecture for cloud computing[END_REF], [START_REF] Wailly | Vespa: multi-layered selfprotection for cloud resources[END_REF] also strength the need of combing multiple security mechanisms to provide an end-to-end and cross-layer security. VESPA [START_REF] Wailly | Vespa: multi-layered selfprotection for cloud resources[END_REF] is one of such architecture for protecting cloud infrastructures using a policy-based management approach. However, this work is oriented toward the use of automatic computing to create self-protection loops. Consequently, they lack a language allowing the tenants to express their security. Nonetheless, a combination with our works could be a a way for future work. In [START_REF] Keromytis | The meerkats cloud security architecture[END_REF], authors present MEERKATS, a mission-oriented Cloud architecture dedicated to security. It is composed of several components that aim to address several types of attacks and seek to provide high flexibility in the use of the protection mechanisms. Nevertheless, MEERKATS lacks a simple way of expressing the security requirements of an infrastructure. In [START_REF] He | A policy management framework for self-protection of pervasive systems[END_REF], the authors present a policy-based security framework. Their ASPF policy consists of an attribute map (that links system elements to their attributes) and a set of rules (indicating which actions are allowed). While the ASPF framework can enforce security policy, only low-level security properties can be expressed, which makes the definition of the security policy complex.

Finally, several works such as [START_REF] Ngo | Policy and context management in dynamically provisioned access control service for virtualized cloud infrastructures[END_REF] have been done around the use of XACML to define security policies. But they focus on a specific type of mechanisms, access control. Moreover, XACML is a complex language [START_REF] Hu | Conformance checking of access control policies specified in xacml[END_REF] that requires the verification of the policy conformance regarding its syntax and its semantic. Furthermore, XACML does not express high level security requirements such as integrity but rather it expresses the policy directly using low-level capabilities. Accordingly, the size of the security policy is larger and thus the risk of making mistakes increases as these policies are written by human versus generated ones. Nevertheless, it could be possible to automatically generate such policy from our security policy language. Thus, such work could be used as a security mechanisms by our solution. [START_REF] Ardagna | An xacml-based privacy-centered access control system[END_REF] presents a privacy-aware access control system since privacy is an important concern for most users. However, the PRIME architecture is based on XACML and therefore presents the same limitations.

Each of these solutions either focuses on one kind of protection (mainly access control) or uses low-level security policy (tedious to define). To the best of our knowledge, there is no current research on the configuration of existing security mechanisms through a common abstract language.

B. Security Mechanisms

Many different security mechanisms exist, providing a wide range of features. We present some of them that we use in our solution. SELinux [START_REF] Haines | The SELinux Notebook -Third Edition[END_REF] is a Linux Security Module (LSM) providing MAC (Mandatory Access Control). PAM [START_REF] Samar | Unified login with pluggable authentication modules (pam)[END_REF] provides authentication management support for Linux. Iptables [START_REF] Andreasson | Iptables tutorial 1[END_REF] is a standard Linux firewall. We use the tunnel functionality provided by OpenSSH [START_REF] Ylonen | The secure shell (ssh) connection protocol[END_REF] to secure the communications between the machines.

Even if not used in this paper, cryptographic solution (such the one presented in [START_REF] Li | Scalable and secure sharing of personal health records in cloud computing using attributebased encryption[END_REF] for the security of medical records or even homomorphic encryption [START_REF] López-Alt | On-the-fly multiparty computation on the cloud via multikey fully homomorphic encryption[END_REF]) could be added to the list of the security mechanisms that our solution takes into account. Indeed, the solution we propose is mechanism-agnostic.

C. Assurance

Operational Security Assurance [START_REF] Haddad | Operational security assurance evaluation in open infrastructures[END_REF] provides the ground for confidence that deployed security mechanisms are running as expected. Some researches have been done to evaluate security assurance. For instance, Common Criteria [START_REF] Criteria | Common Criteria for Information Technology Evaluation v3[END_REF] evaluates security functionality and assurance by means of tests conducted by users. However, this process is static and time consuming. Consequently, it cannot be directly applied for a continuous evaluation of security assurance. Furthermore, Common Criteria focuses on the implementation phase of the product rather than on the operation phase, when the product is used.

Assurance Profile [START_REF]Security Assurance Profile for Secured Telecom Operations Statement of needs for security assurance measurement in operational telecom infrastructures[END_REF] is a formalized document that defines a common set of security assurance measurement requirements for a service infrastructure and facilitates a future evaluation against these needs. This is the approach selected for the assurance framework development.

XCCDF (eXtensible Configuration Checklist Description

Format) is a standard that can perform assurance checks. It belongs to SCAP [START_REF]SCAP: Security Content Automation Protocol[END_REF], a set of specifications from NIST to standardize the format and the naming of information reporting concerning specific security configurations. XCCDF provides security checklists and benchmarks to support an automated compliance testing over a set of target systems. OpenSCAP [START_REF] Openscap | OpenSCAP Website[END_REF] is an auditing tool implementing SCAP and XCCDF.

III. ARCHITECTURE AND LANGUAGE

As we have seen, many security mechanisms are efficient but are focused toward a specific issue and/or type of protection. It is important to understand that we do not propose any new or more secure mechanism, but we rather consider the existing ones and automatically configure/coordinate them in order to enforce high-level security properties. In this section, we first present our functional architecture. Then, we present our language and how it is used to enforce a security policy. Eventually, we show how it is possible to automatically assess the correctness of the enforcement.

A. Functional Architecture

As depicted in Fig. 1, our solution consists in a 3-steps cycle. First, the tenant specifies its security policy using the language detailed in Section III-B. Then, from this highlevel policy specification, the policy is enforced by firstly selecting security mechanisms and secondly configuring them. At the end, the policy specification and the list of selected mechanisms are used to generate the assurance profile. The assurance part will verify whether or not the security properties (from the policy) are duly enforced. These assurance checks are sent as feedbacks to the specification step to notify the tenant if the enforcement is correct/incorrect but also if the available mechanisms are sufficient (or not) to enforce the policy.

B. Policy Specification

During the policy specification step, a knowledgeable tenant (i.e., a security expert) expresses a set of security properties to enforce e.g., confidentiality, integrity.

In [START_REF] Bobelin | An advanced securityaware cloud architecture[END_REF], we have defined the Cloud Security Property Language (CSPL) that allows to specify security properties. In particular, we have shown how to automatically transform a property on a set of distributed objects (that we refer as a global property) into a set of properties on local objects (referred as local properties). In this paper, we are focusing on the enforcement of local properties with a given security mechanism and verifying the correct enforcement of this property. Therefore, in the following we consider only local properties.

CSPL is a context-based language. A context is a set of attributes where each attribute characterizes an entity or a set of entities. At the highest level, entities can be classified into 2 categories: subject (i.e., the active resources such as users and processes) and object (i.e., the passive resources such as files). For instance, the context configApp = (File="Configuration") :(Domain="App") identifies the configuration files (attribute File) of an application (attribute Domain). Therefore, it is possible to use the same set of contexts on different systems. A specific mapping file is required for each system to associate the resources (e.g., files, users, sockets, processes) name (e.g., the full path of a file, the user id, IP addresses, processes name) and the context which they belong to. For example, to associate the application's configuration to the corresponding files, the following line is added to the mapping file ("o" for "object"):

o / opt / dbhook / dbhook . conf configApp
Using contexts to identify resources (or set of resources), CSPL allows to define security properties and by relying on contexts to address entities, the expression of security properties is independent from the resources naming of the target system. These properties are independent from any security mechanism; in fact, multiple mechanisms can realize the same security property. Our proposition is to select a security mechanism able to enforce a given property from a pool of available mechanisms.

For instance, the property P1 expresses that the context SCInt integrity has to be guaranteed with the exception to SCAuth contexts that are allowed to go against this property i.e., no one is allowed to modify it except the resources with the context SCAuth. Then, P1 must be instantiated. For example, to specify that the integrity of the application's configuration files with the context configApp should be protected and only be the user with the context adminRoot = (Username="appAdmin"):(Role= "StandardUser|appAdmin") is allowed to go against, the following property is instantiated: Integrity(configApp, adminRoot).

From the tenant's point of view, the security properties are abstract i.e., the tenant only considers the semantics of the properties, and not the underlying security mechanisms. However, the properties need to be precisely defined in order to be enforced. Thus, we introduce the concept of capabilities. A capability is an elementary function provided by one or several security mechanisms. For instance, C1:= deny_all_write_accesses( Context) is a capability that can be provided by access control mechanisms (e.g., Unix's DAC permissions or SELinux) but also by other security mechanisms. It can be used to enforce an integrity property. Consequently, the integrity property P1 can be defined as follows:

P1 :=Integrity ( Context SCInt , Context SCauth ) { deny_all_write_accesses ( SCInt ); allow_write_access ( SCInt , SCauth ); }
The context SCInt represents an (set of) object(s) to secure, while the context SCauth is the identity of a (set of) subject(s) that can write to i.e., modify, SCInt. Two capabilities are involved in this property. The capability deny_all_write_accesses denies all write accesses to the context while the capability allow_write_access allows the context SCauth to counter the previous capability.

In a Cloud environment, a security property can address multiple machines (e.g., Virtual Machines). In our language, a context mapped to an IP address refers to a machine. For example, a mapping file can include the following lines ("c" for "computer"): The user can use particular attributes to include networkspecific metadata such as port e.g., tunServer:=hostReverseProxy :(Port="5900"). These kinds of contexts can be used in typed security properties i.e., properties accepting only specific types of contexts (here IP:Port). For example, Confidentiality_Tunnel (hostClient, tunServer) creates a tunnel between two machines.

In this paper and especially in our use-case (see Section IV), we will use the following security properties. Each of the parameter (i.e., contexts) of the properties can be a single context or a set of contexts.

• Isolation(Context SC1): Isolate a context SC1 from other resources and vice-versa (e.g., it isolates an application and its resources from the rest of the system) Upon successful connection from SC1 on SC2, modify the context of SC1 to SC3

Finally, we enrich the set of security properties with the following assurance property :

• Assurance(int secs): Run assurance checks at frequency secs (i.e., every secs seconds) for every security property.

C. Policy enforcement

The second step of our solution, the policy enforcement, must first automatically select a set of suitable security mechanisms enabling the enforcement of each security property. And then, it must automatically configure them accordingly. The component in charge of the policy enforcement step is call the Secure Element Extended (SE E ). In the mean time, the assurance property triggers the generation of an assurance profile based on the security properties and the selected mechanisms.

Let's first present the selection and enforcement of the security properties. Figure 2 presents the architecture of the SE E and how it can enforce the security policy. The SE E takes as input the security properties and the contexts/resources mapping. The SE E also considers the security mechanisms that are available on the system and their capabilities. Then, it selects the right security mechanisms and enforces the properties by configuration. First, the SE E loads the security policy i.e., the contexts, the properties, and the contexts/resources mapping (step 1 on Figure 2). Then, the SE E iterates over security properties of the policy. For each capability of each property (step 2), the SE E selects a plug-in (i.e., a security mechanism) that can apply it (steps 3 to 6). This is done by querying the Capabilities Directory that contains the association between the capabilities and the security mechanisms (steps 4 and 5). Once the Plugin Selector has the list of matching mechanisms, it selects one of them (best-effort algorithm, step 6). When a capability/plug-in mapping has been found for the property, it is sent to the Plugins Manager that controls the plug-ins (step 7). Then, the Plugins Manager contacts each plug-in that needs to perform some actions (step 8) and the plug-ins configure their associated security mechanism (step 9). The use of plug-ins offers a modular model: new mechanisms can be easily added by developing the associated plugin. Plug-ins implement a simple interface to communicate with the SE E , but the way they interact with their mechanisms is up to the plug-in's developer.

SEE

For instance, if the SE E receives the integrity property Integrity(configApp, adminRoot) defined in the previous section, it can enforce it using several security mechanisms. If this property is enforced using SELinux, then the SE E generates a SELinux module that forbids any write operation to the files labeled configApp that does not come from a user labeled adminRoot.

The SE E also provides secure communication capabilities, especially for the case of properties between multiple systems. Thus, the two sides (i.e., the selected mechanisms applying to the two contexts) of the communication must use compatible mechanisms to enforce a property. For instance, let us consider the property Confidentiality_Tunnel(hostClient, tunServer). The server allows the connection of the user through the defined port, and the client sets up the tunnel. The coordination is done by the SE E 's communication capabilities. Now, let's present the generation of assurance files for the assurance framework presented in Section III-D. To validate the enforcement of the security policy, multiple files are generated and given as input to the Assurance step, namely the XC-CDF and system-specific scripts. System-specific scripts are generated using a process similar to the property enforcement: each property definition includes an assurance specification, using capabilities. For instance, the assurance of the Integrity property is defined as follows: As a result, the system-specific script will contain the implementation of the check_write assurance capability for the context SCInt and the authorized context SCAuth. This generated script is called a Based Measure (BM) as it is the lowest level of assurance measure. Therefore, the XCCDF is simply a list of Based Measures. The XCCF file and the related scripts are given as input to the assurance step.

D. Assurance

In order to be able to evaluate continuously the security assurance for a service, it is necessary to implement a process composed of several steps: modeling, measuring, aggregation, evaluation and presentation of the security assurance reports. This process is supported by a set of software components that compose our assurance framework. Fig. 3 presents our assurance framework architecture. 1) System Measurement Collection: As stated before, the assurance step receives an XCCDF file and the related systemspecific scripts called Based Measures. The SE E is responsible for launching the measurement collection process realized by the Assurance Collector Engine (ACE). This engine includes a BM Agent which executes several system-specific scripts. Script results are associated with some metadata including extra information to unequivocally identify their origins and contexts. Note that the ACE, based on OpenSCAP, is the only assurance module deployed in each virtual machine.

Next, the Measurement Aggregator (MA) receives these measurements from each node, validates and classifies them according to their metadata, before storing them in the Assurance DB.

2) Assurance Results Presentation: We have seen how to execute low-level assurance checks and collect their results. In the following, we present how to add semantics to the collected results i.e., interpret them, and how to present all assurance checks to the tenant in a modular and concise manner. Our assurance model defining the entities/files relations from lowlevel measures to high-level views is presented in Fig. 4. Depending on the number of security properties and the size of the system (i.e., number of objects), it is possible to have a significantly large set of assurance checks (or Derived Measures) which can be an impediment to the tenant's verification task. Our solution is to hierarchically aggregate these measurements.

Therefore, a set of Derived Measures is aggregated in an Operational Measurement Requirement (OMR) via an aggregation function. In particular, if all Derived Measures have successfully passed their checks, then the OMR is marked as successful. In other words, an OMR is a set of system assurance checks. The Operational Profile (OP) contains both the definition of OMRs (i.e., the list of Derived Measures) and the definition of Derived Measures.

Our next level of abstraction is to allow the tenant to specify several Security Assurance Views (SAVs) where an assurance view is an aggregation of Operational Measurement Requirements. The definition of Security Assurance Views is done in the Assurance Profile (AP) file.

In Fig. 3, the Assurance Modeling Tool takes in input the Assurance Profile and the Operational Profile to maintain a Security Assurance Model. Depending on the layer of the assurance model (e.g., SAV, OMR, or DM), the Assurance Assessment Engine is responsible for deciding if the collected assurance values meet the expectations and for computing the aggregation results.

Finally, the Assurance Visualization Tool provides a Graphical User Interface for the user to monitor the assurance status. For a monitored service, the user will be able to select the different SAVs available in the Security Assurance Model. This tool presents an assurance report adapted to the tenant's concerns.

To sum up, the modeling and configuration of the assurance framework rely on the definition and refinement of 3 XML files : 1) the AP for defining the high level measurement requirements and the assurance views adapted to the tenant's concerns, 2) the OP for establishing the links with the real environment, and 3) the XCCDF for specifying how to execute the assurance measurements. Examples of these files are provided in Section IV.

IV. IKUSI'S USECASE

A. Description of Usecase

In this section, we present an industrial use-case based on Ikusi application : Airport Management. It aims to provide a centralized-operational management for airports management services. It involves the coordination of a group of processes, where both human and IT system interactions are required. It is a classical 3-tier web architecture i.e., a HTTP frontend (tier-1), an application server (tier-2) and a database (tier-3). This architecture is deployed on top of an IaaS Cloud and is provided to end-users through a SaaS model. Moreover, one instance of the application server is launched for each client i.e., for each airport.

Services provided by the architecture include the management of an operational data repository for each airport operator and passenger, the real time management of flight status updates, and the dynamic allocation and optimization of assigned resources according to data from air flight companies and airport operators.

It is based on message exchange modules, on resource allocation and on billing management airport services to provide airlines with an operational platform based on Cloud computing technology. It also incorporates enhanced security solutions based on a network of secure element developed in the SEED4C project.

The use-case is presented in Fig. 5. Four different kinds of machines or VMs are involved. First, the machine ctseed1 is the client machine. It is the device that is used within the airport to access the airport's services. Secondly, the reverseproxy VM (i.e., tier-1) is a proxy used by the enduser to access the airport's services. The musik VMs (both musik1 and musik2) belong to an airport (MAD1 or EAS2 ) and are accessed by the end-user machine through the proxy (i.e., an instance of the application server, tier-2). The corresponding VM is selected based on the location of the end-user. Apart from their airport domain, these VMs are identical, so we only consider one of them in this use-case (the security policy would be duplicated). Each of these VMs runs a Musik application that accesses the database (running in the seed4c_mysql machine) i.e., tier-3.

B. Security policy

Based on the use case description, a security policy is defined through the graphical tool Sam4C (see Fig 5).

The next listing presents an excerpt from the security policies for the different VMs of the use-case: The first security property (line 2) of this listing sandboxes the whole application. Lines 4 to 7 forbid anyone to edit the application's binary, but allow several write accesses to its files (configuration, keys, and logs). Lines 9 to 14 forbid read access to the application resources except for the application itself. Line 16 specifies the context evolution upon an SSH connection: a role is given to the authenticating user depending on his login data. Line 18 opens several ports for all incoming IP addresses. Line 20 defines the assurance tests to perform.

The second part of the listing describes the policy for the reverse proxy. Lines 23 to 25 guarantee the integrity of the Web application. Line 27 requests the confidentiality of the configuration files. Line 28 specifies that the network communication between the proxy and the client should be kept confidential. Line 30 opens some ports. Finally, line 32 manages the contexts evolution upon SSH connections.

The contexts used in this policy are associated to system resources. An extract from the association file is displayed in the next listing: Lines 1 to 8 of the mapping file associate the contexts to files. Lines 10 to 13 are for the processes, lines 15 to 18 for the users, and lines 20 to 22 for the computers (IP addresses).

C. Security Enforcement

The security policy is enforced by several security mechanisms. The SE E detects what are the available mechanisms and selects those that can enforce the properties.

In this usecase, four mechanisms collaborate to enforce the whole policy.

1) SELinux: First security mechanism available is SELinux. It enforces properties from three groups: isolation, confidentiality, and integrity. To enforce them, the plug-in generates a SELinux module.

Upon receiving an isolation property for a domain, the plug-in creates a SELinux module to isolate all elements of this domain from the rest of the system. Then, the plug-in will allow some interactions corresponding to confidentiality and integrity properties. To enforce the properties Isolation( DomainAODB), Integrity(ConfigAODB, AdminRoot), and Confidentiality( ConfigAODB, "ServiceDB|AdminRoot") from policy, the following module is generated (see next listing). Lines 2-5 define the domain and SELinux contexts, while lines 7-8 give authorization rules. Lines 12-13 associate SELinux contexts to resources. 2) PAM: The PAM plug-in enforces authentication properties. Indeed, such property specifies how contexts can evolve to have correct properties applied. Moreover, it controls the authentication rights and allows or denies a user authentication. Upon encountering the property Authentication(anyone, ServiceSSH, "SystemUser| CloudProvider|AdminRoot|AdminOperator|User"), PAM plug-in adds a rule to PAM configuration in order to detect a successful login: session required pam_exec . so / etc / see / scripts / notifyLogin When a successful authentication occurs, PAM executes the script notifyLogin (see next listing), which informs the SE E (through Ncat) of a connection and sends data, such as the user name, the remote host, or the date.

1 $ cat notifyLogin 2 #!/ bin / sh 3 [ " $PAM_TYPE " = " open_session " ] || exit 0 4 { echo " User : $PAM_USER " 3) iptables: The iptables plug-in enforces the network access properties. For instance, the iptables plug-in can allow network communications on a specific port or from a given IP address.

The Access properties in the use-case's policy are used to open some ports. For instance, the access property Access ( SSHPort, AnyIP) is enforced using the following iptables rule: This plug-in can be requested to apply additional capabilities by other plug-ins. For instance, the SSH tunneling plug-in can dynamically request a specific port to be opened by the iptables plug-in.

4) SSH Tunneling: The SSH Tunneling plug-in enforces the creation of confidential tunnels between machines inside and outside the Cloud. Apart from the infrastructure in the Cloud, the Airport Management use-case includes physical machines located in the airport. As part of the use-case, we need to monitor what is displayed on the machines from the Cloud application. The remote port forwarding process comes with a solution to this issue allowing flows redirection.

The remote port forwarding process ensures the confidentiality of the communication, because SSH is an encrypted protocol. Furthermore, thank to the public key cryptography, both sides of the communication channel are authenticated.

The communication between the machines is essential since the SSH server machine has to allocate its own local ports. They will be assigned to a SSH client in order to allow it to do the port forwarding. The enforcement is made of 3 steps: 1) the SSH server machine allocates a local port for the client to set up the tunnel, 2) the SSH client gets the allocated port, and 3) the SSH client creates the remote tunnel. Fig. 6 shows this process for a remote port forwarding tunnel creation using the port 5900 as the port on client machine. To enforce the tunnel, the command ssh -R 7900:0.0.0.0:5900 ctseed1@reverse-seed4c is executed, where 7900 is the allocated port for the SSH server, 5900 is the objective port for the SSH client, reverse-seed4c is the server's hostname, and ctseed1 is the user on the SSH server machine used by the client machine.

D. Assurance

The Assurance Model used in the airport management usecase is based on the security policy and focuses on monitoring the effectiveness of the security mechanisms. The model checks that deployed security mechanisms (e.g., SELinux, Iptables, and OpenSSH tunnel) are running as expected. It also checks that the security properties are fulfilled, in terms of data integrity, data confidentiality, and data availability.

For instance, the enforcement of the property Integrity (ConfigAODB, AdminRoot) (line 5 of the security policy in Section IV-B) can be checked using the script from listing 1. This script is generated by the SE E during the enforcement step (Section IV-C), depending on the properties of the security policy.

1 $ cat BM_fileInt -1.1. sh 2 #!/ bin / bash 3 RET = $XCCDF_RESULT_PASS 4 check_write () { su -c " test -w " $1 "" $2 ; return $ ?;} The script BM_fileInt-1.1.sh checks the integrity of a file by testing which users are allowed to write it. Line 4 defines a function to check if a file can be written by a specific user. Lines 5 to 7 get the files and users involved in the property (not detailed here due to lack of space). Then, the script loops over the files (line 9) and the users (line 10) and tries to open the files for writing (line 11). If the property and the test result do not match (lines 15 and 20), the return value is set to XCCDF_RESULT_FAIL (lines 16 and 21), so that the script will exit with a failure. Otherwise, the script exits with the return value XCCDF_RESULT_PASS, indicating that the integrity property has been properly enforced.

As presented before, the assurance framework is steered by 3 files, namely the Assurance Profile (AP), the Operational Profile (OP) and the XCCDF.

The excerpt of the Assurance Profile presented in Listing 2 defines one Security Assurance View (SAV) with two Operational Measurement Requirements (OMRs), OMR_1 and OMR_3 (lines 10-11), needed for the evaluation of data integrity (lines 7-13). The XCCDF file in Listing 3 defines the last step of the measurement chain. It specifies the assurance checks (with their related scripts, for example BM_fileInt-1.1.sh, line 14) that have to be executed to collect the base measures (here, BM-fileInt-1.1, lines 9 to 16) needed to evaluate upper levels of the assurance model. In order for the Assurance Profile and the XCCDF file to inter-operate, the Operational Profile (Listing 4) links the Operational Measurement Requirements OMR_3 of the Assurance Profile (lines 13 to 18) with the Based Measures BM-fileInt-1.1 of the XCCDF file (lines 3 to 9). It also specifies the machine from which to collect this data (line 7). The Assurance Collector Engine executes the script BM_fileInt-1.1.sh (listing 1) in order to check to enforcement of integrity properties in the security policy (here, the property on line 5 of the policy).

Both the Assurance Profile and the Operational Profile are imported in the Assurance Modeling Tool and derived into the Airport Management Assurance Model, displayed in Fig. 7 by the Assurance Visualization Tool. The model shows the Security Assurance Views defined in the Assurance Profile, in this case the Security Functions effectiveness view, with its corresponding measurement requirements fed by the assurance checks. The left framework of the model allows the navigation by the model structure and shows the assurance compliance in a colour basis. The right framework shows the details on the selected model component. In this case it shows the base measures corresponding to SELinux (MAC) mechanisms status, but the results obtained from the integrity property verification can also be displayed.

E. Results

Table I presents some statistics concerning the security policy for this usecase. As we can see, the policy for this use-case uses only 8 different properties templates, since our high-level properties cover a wide range of security needs. The policy itself uses use-case, which is a very low number considering all the security functionalities covered. Moreover, this policy is entirely generated from a GUI, so the Cloud tenant does not have to write these contexts and properties himself. Besides, this policy manages both the enforcement and the assurance, so that Cloud tenant has information about the status of the enforcement, through a graphical dashboard.

V. CONCLUSION

In this paper, we have presented a solution to specify, enforce and assure security properties in a Cloud environment. Our solution handles the enforcement by re-using existing security and assurance mechanisms, such as SELinux, iptables, PAM, SSH, or Oscap. Our solution is composed of several elements: 1) a language that can express the security and assurance properties independently from the system, the resources naming, and the available mechanisms, 2) an enforcement engine, the SE E , that receives the properties and enforces them by configuring existing mechanisms, and 3) an assurance framework that models, measures, aggregates, evaluates and presents the security assurance results. Our solution has shown its efficiency on a complete industrial use-case for airport system management: 1) the policy expressing the security requirements of the use-case has been defined, 2) the policy has been enforced using several mechanisms that collaborate to offer an end-to-end protection (across the different machines), and 3) the assurance framework has confirmed the proper enforcement of the security policy.

In our future works, we will define generic policy templates that be used to secure the system base, in addition to the policy on the tenant's software architecture. This added protection would improve the overall security of the system. Besides, we plan to extend the language so that the results generated by the assurance framework are sent back to the enforcement engine: this would allow the enforcement engine to update the configuration of the security mechanisms to adapt the protection in case something is not working as expected.

Fig. 1 :

 1 Fig. 1: Functional Architecture

P1 : =

 = Integrity ( Context SCInt , Context SCAuth );

  c 192.168.30.8 hostClient c 172.22.11.181 hostReverseProxy

  P1 :=Integrity ( Context SCInt , Context SCauth ) { assurance { boolean c = true ; for ( SCUserTmp IN get_all_users() ) { if ( SCUserTmp . Id == SCauth . Id ) { c &= check_write ( SCInt , SCauth ); } else { c &= ( NOT check_write ( SCInt , SCauth )); } } return c; }}

Fig. 3 :

 3 Fig. 3: Assurance Framework Architecture.

Fig. 4 :

 4 Fig. 4: Assurance Model.

Fig. 5 :

 5 Fig. 5: Usecase Description

1 6 7

 6 $ cat Aodb . te 2 policy_module ( Aodb ,1.0.0) 3 see_create_service_domain ( Aodb ) 4 see_create_files_type ( Aodb_conf_t ) 5 see_create_files_type ( Aodb_file_t ) see_files_type_read_write ( Aodb_t , Aodb_conf_t ) 8 see_files_type_read ( idAodbAdmin_t , Aodb_conf_t ) 9 [...] 10 11 $ cat Aodb . fc 12 / opt / dbhook / dbhook . conf gen_context ( system_u : object_r : Aodb_conf_t , s0 ) 13 / usr / bin / mysql -proxy gen_context ( system_u : object_r : Aodb_exec_t , s0 ) 14 [...]

5 echo"

 5 Ruser : $PAM_RUSER " 6 echo " Rhost : $PAM_RHOST " 7 echo " Service : $PAM_SERVICE " 8 echo " TTY : $PAM_TTY " 9 echo " Date : 'date '" 10 echo " Server : ' uname -a '" 11 echo " PID : $$ " echo " PPID : $PPID " 13 } | ncat -U --send -only / var / run / seePam

  iptables -I INPUT -m state --state NEW -p tcp --dport 22 -j ACCEPT

Fig. 6 :

 6 Fig. 6: Tunnel creation process example

5 8 9Listing 1 :

 581 FILES =[...] # list of files in integrity property 6 USERS =[...] # list of all users 7 OK_USERS =[...] # list of authorized users for file in "${ FILES [@ ]} " ; do 10 for user in "${ USERS [@ ]} " ; do 11 check_write $file $user 12 WRITE_OK =$? 13 14 if [[ " ${ OK_USERS [@ ]} " =˜" $user " ]] ; then 15 if [[ $WRITE_OK -ne "0" ]] ; then 16 RET = $XCCDF_RESULT_FAIL 17 echo " Unexpected access denial : $user -> $file " Script checking the integrity of a file

15 </check> 16 </Rule> 17 [

 151617 1 [...] 2 <Profile id=" properties_IO " > 3 <description> Properties Assurance </description> 4 <select idref="BM -fileInt -1.1 " selected =" true " / > 5 <select idref="BM -fileConf -1.1 " selected =" true " / > 6 <select idref="BM -netConf -1.1 " selected =" true " / > 7 </Profile> 8 <Group id=" properties_group " > 9 <Rule id="BM -fileInt -1.1 " selected =" true " > 10 <title> File Integrity </title> 11 <description> Check that file integrity is enforced </ description> 12 <check system=" http: // open -scap . org / page / SCE " > 13 <check-import import -name =" stdout " / > 14 <check-content -ref href =" BM_fileInt -1.1. sh "/ > ...] 18 </Group> 19 [...] Listing 3: XCCDF file for the Airport Management use case.

7 <ConcernedDevice>Musik1</ ConcernedDevice> 8 <P

 78 1 [ . . . ] 2 <DerivedMeasures> 3 <DerivedMeasure i d ="DM-f i l e I n t -1.1-musik1 "> 4 <D e s c r i p t i o n>Check t h a t f i l e i n t e g r i t y i s e f f e c t i v e</ D e s c r i p t i o n> 5 <I n t e r p r e t F u n c t i o n>" p a s s " . e q u a l s ( $ 0 )</ I n t e r p r e t F u n c t i o n> 6 <ConcernedBaseMeasure>BMf i l e I n t -1.1</ ConcernedBaseMeasure > e r i o d i c i t y>180000</ P e r i o d i c i t y> 9 </ DerivedMeasure> 10 [ . . . ] 11 </ DerivedMeasures> 12 <MeasurementRequirements> 13 <MeasurementRequirement i d ="OMR 3"> 14 <MRAggregFunction># t ==##</ MRAggregFunction> 15 <DerivedMeasure>DMf i l e I n t -1.1-musik1</ DerivedMeasure> 16 <DerivedMeasure>DMf i l e I n t -1.1-musik2</ DerivedMeasure> 17 <DerivedMeasure>DMf i l e I n t -1.1-db</ DerivedMeasure> 18 </ MeasurementRequirement> 19 [ . . . ] 20 </ MeasurementRequirements> 21 [ . . . ] Listing 4: OP file for the Airport Management use case.

Fig. 7 :

 7 Fig. 7: Airport Management Assurance Model Evaluation and Visualization.

  enforce the security properties 5 (SELinux, iptables, PAM, SSH, Oscap) Assurance scripts for the properties 8 Assurance scripts for the SSMs 4

TABLE I :

 I Use-case Policy Statistics

MAD: Madrid Airport code

EAS: San Sebastian Airport code

Acknowledgments

This work was done thanks to the financial support of the Celtic+ project Seed4C (Eureka Celtic+ CPP2011/2-6).