Security Framework for Virtualised Infrastructure Services Provisioned On-demand

Security Framework for Virtualised Infrastructure

Services Provisioned On-demand

Canh Ngo1, Peter Membrey2, Yuri Demchenko1, Cees de Laat1 University of Amsterdam1

,

ICT technologies, offering a common approach to on-demand provisioning computation, storage and network resources which are generally referred to as infrastructure services. Most of currently available commercial Cloud services are built and organized reflecting simple relations between single provider and single customer with simple security and trust model. New architectural models should allow multi-provider heterogeneous services environment that can be delivered to organizational customers representing multiple user groups. These models should be supported by new security approaches to create consistent security services in virtualised multi-provider Cloud environment and incorporate complex access control and trust relations among Cloud actors. The paper analyzes basis use cases in Cloud services provisioning and defines a security infrastructure reference model which is used to define other security infrastructure aspects such as dynamic trust management, distributed access control, policy and security context management. It also provides information about ongoing implementation of the proposed Dynamic Access Control Infrastructure based on Enterprise Service Bus as a part of complex infrastructure services provisioning system.

Keywords- Dynamic Access Control Infrastructure, Infrastructure Virtualisation, On-Demand Infrastructure Services Provisioning, Security Infrastrutcure Bootstrapping, Security Context Management, Cloud computing.

I. INTRODUCTION

Cloud computing is emerging as a common approach and a service model for provisioning infrastructure services on-demand that include both computation, storage and advanced network infrastructure. It allows minimizing infrastructure management costs for both customers and providers. Beside a wide spectrum of currently available Cloud services, there is a number of research and standardization activities focusing on definitions, use-cases, and reference models such as NIST Cloud Architecture collaboration group [1], [2]. OGF Infrastructure Services on Demand Research Group (ISOD-RG) [3], and OASIS Cloud Identity Technical Committee (IDCloud TC) [4].

Current widely accepted Cloud computing definition is based on the NIST definition that identifies five essential Cloud characteristics [2]: (1) on-demand self-service; (2) broad network access and diversity of client devices; (3) resource pooling that allows providers to serve multi-tenant customers by managing resource utilization more efficiently using virtualization, resource partitioning and workload

balancing; (4) rapid elasticity that allows scaling resources dynamically; (5) measured service with the pay-per-use business model. Other additional feature is the heterogeneity on both provider and customer sides, and multi-provider services.

With all these unique characteristics, providing consistent security and privacy solutions for Cloud computing environment brings many challenges. To be a successful next generation technology, Cloud computing needs to address both secure infrastructure operation and user concerns. Several surveys and researches have shown that the security and privacy are the main obstacles to adopt Cloud computing widely [2], [5], [6].

The paper presents the ongoing research on developing security framework for Cloud computing environments and infrastructure services provisioned on-demand which aims to deliver a security infrastructure to support consistent trust establishment, identity management, access control, as well as security context management. Based on the analysis of possible Cloud scenarios, it identifies requirements and functionalities of the security infrastructure for Clouds. The paper then proposes a security reference model that is used as a basic for defining the architecture and practical mechanisms. The presented research is conducted as a part of few EU projects such as GEYSERS and GEANT3 which provide a prototype implementation and testbed.

The structure of paper is organized as follows: section 2 summarizes general security use-cases on Cloud computing which points out security requirements for these scenarios. Based on these requirements, section 3 proposes a security infrastructure reference model that provides consistent and robust security for Cloud. After that, section 4 presents a trust model for the cloud-aware architecture. Section 5 describes the Dynamic Access Control Infrastructure (DACI) based on the proposed reference model. Section 6 describes the proposed bootstrapping mechanism that allows binding virtualised security infrastructure to a trusted platform. Section 7 provides the implementation details of DACI as a part of GEYSERS project [7]. Finally, section 8 contains the summary and suggestions for further research directions.

II. GENERAL SECURITY SCENARIO IN CLOUD

ENVIRONMENTS

A. A security scenario in Cloud environments

Definition and analysis of the basic scenario in Cloud computing is an important step in specifying security infrastructure goals and requirements. This section discusses 2011 Third IEEE International Conference on Coud Computing Technology and Science

on a practical and common security Cloud computing scenario that involves such main actors as: Cloud providers (entities offering Clouds), tenants/customers (entities subscribing Clouds) and end-users (entities associated with a tenant and consume resources in the Clouds). These actors can appear in different Cloud models such as single cloud provider model, multi cloud providers or broker based (e.g., collaboration, cloud composition and brokering among providers). Some models and their detail scenarios can be seen in [2], [4], [7].

In the general scenario, a tenant (e.g. an enterprise or a company with a head office and some branches spreading over different geographical locations) subscribes Cloud services from multiple Cloud providers. The tenant also has a number of business partners for collaboration in short-term or long-term based on specific business purposes. Cloud resources of the enterprise are used not only by its employees but also by business partners or customers. Branches or business partners may consume Cloud services from different Cloud providers. Such collaboration and interoperation impose unique requirements for identity management, access control, trust and security context management.

The first requirement of identity management for cloud is the virtual federation. Each Cloud could be seen as a virtual security domain. Collaboration across these virtual security domains requires enterprise and federation features of identity and access management. However, because operating on Cloud environments, the identity and access management needs to support provisioning characteristics, such as identity provisioning, dynamic trust establishment, security context transfer and management across Cloud security domains, as well as identities’ attributes transferring and related privacy issues.

A typical problem in the multi-tenant environment is how to provide security services per cloud tenant. Each customer/tenant needs to have necessary tools to configure, monitor and auditing operations on their Clouds separately. Thus, Cloud providers, who are running security services, should be able to delegate such services to customers in associating with their Clouds.

Other issue in the identity and management per tenant is how to associate end-users to their tenant with their operations on subscribed services. This feature can be used for consistent security services and management such as billing, operations auditing and tenant isolation. Current approach for this issue is to use a unique identifier for each tenant and embedded it inside every request from tenant or its end-users.

For the model with multiple Cloud providers, the open issue is how to manage the integrated topologies such as hierarchical, peer-to-peer or hybrid. The collaboration, trust, and interoperability between these providers should take into account such topologies.

Cloud models specified by NIST [2] define Cloud Provider, Cloud Auditor, Cloud Broker, and Cloud Carrier roles. Another interesting RORA (Resources, Ownerships, Roles and Actors) model is proposed in [7]. It’s based on on-demand infrastructure services provisioning use-cases

defined for business entities (Cloud providers, tenants, users, etc) and roles. They can execute in consuming or managing Cloud resources based on the type of ownerships in respect to resources (e.g.: financial, administrative or operational. These models are analysed to identify security challenges in protecting Cloud providers’ infrastructure and their operations.

B. Requirements for security services in Cloud environments

Security requirements for Cloud computing environments have been investigated by the first generation of Cloud computing research [6], [8] and then further analyzed based on recently proposed Cloud reference architecture models [2], [5], [9]. Based on the scenario in the previous section, the requirements could be summarized as follows:

• Identity management and access control mechanisms in the multi-tenancy and multi-provider Cloud environments. There is some preliminary work on this area which defines principal use-cases on identity and access control management [4], multi-tenancy authorization system for Cloud services [10]. However, most of them do not take into account the relevance of these issues to the service lifecycle model or lack of multi-provider scenarios [10].

• Management of the trustworthiness and reliability of the Intercloud. Most of existing work in this area do not investigate practical solutions in detail and propose feasible mechanisms [5], [11]. Some related work on trust management [12] needs to be investigated and propose to suite with the Cloud characteristics.

• Mechanisms to isolate operations and mutual effects among tenancies in the sharing physical resources by virtualization and hypervisors [5], [13].

• Supporting security compliance and regulations [9].

• Issues on protect Cloud providers’ resources infrastructure. It requires not only the traditional perimeter security mechanisms but also need to aware of the characteristics of Cloud computing reference models [2].

With distinguished characteristics of on-demand provisioned services and Cloud computing, providing a consistent and robust security infrastructure is not trivial task and has many challenges to solve. Next section proposes a security infrastructure reference model for On-demand service provisioning to meet these requirements.

III. GENERAL SECURITY INFRASTRUCTURE FOR ON

-DEMAND SERVICES PROVISIONING

The general security framework for on-demand provisioned infrastructure services should address two general aspects [14]: (1) secure operations resource management at cloud provider side, and (2) provisioning security services as part of the Cloud that is known as provisioned on-demand virtual infrastructure. The first is related to system protections in a cloud provider and collaboration between providers that some solutions on

identity and access control management ha dynamic provisioning of managed securit open issue requiring additional resea computing.

Fig. 1 describes the general functionalitie Infrastructure for on-demand provisioned on-demand provisioning design to follow Lifecycle Management models, securit should be in compliant with the Security S Management (SSLM) proposed by the autho in the earlier paper [15]. Details on security SSLM are described in [14].

Figure 1. Security reference model On-demand Services Provisioning sys

In the security reference model, the low Service Level Agreement (SLA) Manageme initial agreements between actors. These multiple providers to form the supply-chain services to customers. It also includes not o (tenant) who subscribes computing service but also end-users who consume a particul The SLA Management is the substrate to b relationships among involved actors infrastructure eco system. Based on th network of actors, security services su Management, Access Control and Se Management will be in charge to assure da and integrity properties. On top is the C Service Layer that facilitates the integra services with the Cloud services. Most of e providing security services are based on stat such as PKI based trust management infr authorization policies and non-auto administrator aided services compositi dynamically reconfigurable system. The p architecture allows dynamic provisioning of security services in the Cloud computing different mechanisms.

IV. DYNAMIC SECURITY ASSOCIATIONS

The following approach is based o architecture of On-demand Service Provisio It defines Physical Infrastructure Provide Infrastructure Provider (VIP), Virtual Infrast (VIO), Virtual Infrastructure (VI) and VI description of these actors and the referen [14].

ave solved; while ty services is an arch for Cloud

es of the Security services. Due to w SOA Service ty infrastructure Service Lifecycle ors and described requirements for

for tems

west layer is the ent which handles

e actors can be n from computing only the customer es from providers lar cloud service. build up the trust in a virtual he suitable trust uch as Identity ecurity Context ata confidentiality Common Security ation of security existing solutions tic configurations rastructure, static omatic service on for a not proposed security f the manageable environment by S MANAGEMENT n the reference oning model [14]. er (PIP), Virtual tructure Operator -end-user. Detail nce model are in

A. Trust relations

Fig. 2 describes relations betwe Infrastructure Services provisioned virtualized physical devices to o (VRs). VIPs are intermediate pro aggregating VRs from multiple Infrastructures (VIs), which are su end-users then may consume VRs i VIOs’ identifier. Such involved supply-chain service model from lo to intermediate providers (VIPs), end-users.

Figure 2. Trust relationships in multi-p

Providing trusts between parties services. This model has two types o first one is static or direct trust be based on SLA agreements. The sec trust, the relation forming duri between indirect parties (i.e. VIO an VIP, etc). These relationships are d established and released during the V

According to various models including public-key cryptography PGP), and recommendation-based m are assumed not transitive [16]. Fo and B trusts C, it cannot conclude specific conditions, the trust could could trust C. In our approach, we between parties as specified in [17] for example with VI-end-users, VI VIP and recommends the trust to VI then trust VIO as the recommender f could judge VIO’s recommendation supply-chain service model, they paths or trust-paths from PIP to VIP This dynamic trust model could f categories. The first one is evide entities establish a trust relationship as cryptographic keys. The other based model [17]. For the Cloud m the evidence-based model becaus enforced by SLAs along with parameters that can be provided a security context. Dynamic trust r

een entities in the cloud d On-demand. PIPs own offer Virtual Resources oviders to compose and

PIPs into the Virtual ubscribed by VIOs. The in the VI associated with actors form the cloud ow-level providers (PIPs)

subscribers (VIOs), and

provider Cloud environment

s is the basic for security of trust relationships. The etween two direct parties cond one is the dynamic ing provisioning stages nd PIPs, VI-end-users and dynamic because they are

VI provisioning phases. in distributed systems y models (e.g. PKI or models, trust relationships

r example, if A trusts B, that A trusts C. In some be transitive [17] and A select the transitive trust with a set of conditions, IO, and VIP, VIO trusts I-end-users. VI-end-users for trust relationships and ns. With the above cloud y form recommendation

P, VIO and VI-end-users. follow one of following ence-based model where p based on evidence, such

one is recommendation-model, we propose to use

e direct/static trusts are specific cryptographic as a provisioning session

based on direct trust relations and other assumptions as specified above to satisfy conditional transitive trust.

B. Establish dynamic trust relationships

A trust relationship between two entities is described by a Security Association (SA). It contains agreed security attributes between parties. The SA could include cryptographic parameters (certificates, keys, algorithms, etc) to make sure one endpoint assure about the other one on its trustworthiness.

The direct/static trust relationship as in previous section is defined as the Static Security Association (SSA) while the dynamic trust relationship is known as Dynamic Security Association (DSA). In the reference model, SSAs include SSA(VI-user, VIO), SSA(VIO, VIP), SSA(VIP, PIP). Set of DSAs include DSA(VI-end-user, VIP), DSA(VI-end-user, PIP), DSA(VIO, PIP).

Generic steps to establish dynamic trust relationship are as follows:

Conditions: Entities A, B, C; SSA(A, B), SSA(B, C) Goal: Establish the DSA(A, C)

Procedures:

1. A asks B to establish trust to C.

2. B retrieves its SA list to find SSA(B, A) and SSA( B, C). It then generates a new SA. This SA is sent back to A and C by protecting with SSA(B, A) and SSA(B, C) respectively.

3. A receives the generated SA. By verifying the SSA(B, A) protector, it add the new generated SA to its SA list as the DSA(A, C).

4. C receives the generated SA and verifies it with SSA(C, B). Since it’s valid, C add the new SA, known as DSA(C, A) to its SA list.

For specific mechanisms such as PKI, PGP or SAML, the procedure needs to concrete in generating SA dynamically and sending to both indirect parties A and C. Further development for these mechanisms will be in the future work.

V. DYNAMIC ACCESS CONTROL INFRASTRUCTURE A. DACI Architecture

The DACI architecture [18] being developed in the GEYSERS project [7] is proposed to support provisioning dynamic security services, including creation and management of dynamic security associations as discussed in the previous section. Fig. 3 presents the DACI and its components. The DACI Management interface is used to manage the SSLM of Dynamic Access Control Service (DACS) instances. Each DACS instance is associated with a VI by a unique identifier value VI-GRI (VI Global Reservation ID).

In the reservation stage, the unique VI-GRI value is generated or provided to associate with the DACS instance. The DACI Management component will identify necessary parameters for creating DACS instance which include related actors (VIO, VIP and PIPs) and their trust anchors.

Figure 3. DACI Reference Architecture

During the deployment stage, necessary DSAs are established between actors in the VI based on their trust anchors by the DACI Trust Management. These DSAs are then stored and managed at the DACI Context Management in associating with the VI-GRI. After the deployment stage, dynamic trust relationships are established to connect actors involving to the VI: users (VI-end-users) to consume VRs in the VI, VIO to manage the VI, VIP to compose and provide VI services from multiple PIPs, and PIPs to provide VR services based on their PR slices. Authentication and

authorization services for the VI are based on these dynamic trust relationships.

In the operation phase, security services of the DACS instance run based on trust anchors provided by the DACS Trust Manager. They include Identity Management, Authorization and Token Services responsible to control accesses to all VRs of VI identified by VI-GRI value.

During the VI re-composition phase, the DACI Policy Management needs to align authorization policies associating to the VI-GRI identifier are updated with its new VI composition.

B. DACS components

DACS are instantiated and operated during VI lifetimes to provide following consistent security services:

1) Identity Management Service

The Identity Management Service, in compliant with SAML profile [19], is responsible for authenticating identities based on their credentials. There are several credential types, such as: username/password, X.509 certificates or security tokens such as SAML authentication assertions [19] or Kerberos tickets. The second functionality is to issue authentication tokens for authenticated identities with the issuer identifier as the Identity Management Service in associated with the provisioned VI.

2) Authorization Service

The purpose of the Authorization Service is used to manage permissions of authenticated entities to VRs. Authorization policies are composed and managed following XACML standard [20].

The authorization interface is in compliant with SAML profile of XACML in which authorization requests and responses are XACML requests/responses carried by SAML messages.

Components in the Authorization Service have the following functionalities:

• SAML-XACML Request/Responder: handles SAML messages carrying XAML authorization requests and responses.

• Policy Information Point (PIP): collects necessary attributes that provides to PDP for authorization policy evaluations.

• Policy Decision Point (PDP): evaluate authorization requests against set of XACML policies provided by PAP.

• Policy Administration Point (PAP): provide policies to the PDP using SAML protocol in carrying policy requests and policy responses.

• Obligation Handler is used to fulfill the obligations of authorization decisions from the PDP.

3) Authorization Token Service

The Authorization Token Service is responsible for issuing and validating authorization tokens. It not only increases the performance but also supports security context delivery through multi-layers and multi-domain environments. It supports the proprietary GAAA-TK authorization token type [21].

The service could be organized in various models, from a simple model containing services locally deployed at VRs to improve authorization performance to extended models with centralized token issuer authority. The extended model could support security contexts delivery across VI boundaries (virtual security domains), which enables collaboration among VIs, even in multi-provider environment. It is one of our future works for the DACI.

4) DACS Management Service

The DACS management tasks are delegated from VIP to VIO by the DACS Management service. The VIO (or the assigned security administrator by VIO) could manage above security services such as register/update identities’ attributes;

compose authorization policies following the RBAC model associating to their enterprise business model, etc.

C. CSSI and Security Gateway

1) Common Security Services Interface definition The Common Security Services Interface (CSSI) [18] is the interface between users/applicants’ clients and VR services. It facilitates interactions to security services, including authentication, authorization and token services, by associating them with the specific DACS instance by using VI-GRI value.

2) Security Gateway library

The security gateway in Fig. 4 is the library supporting CSSI. It’s in charge of authentication, security context establishment and authorization for accessing VR services from user/applicant sides.

• CSSI/GAAAPI: The application utilizes Security Gateway through the CSSI/GAAAPI interface for invoking authentication and authorization services.

• PEP is in charge of communicating with security services to authenticate and get authorization decisions.

Figure 4. CSSI and Security Gateway library

VI. SECURITY SERVICE BOOTSTRAPPING PROTOCOL

DACI trust model relies on a number of trust anchors residing at PIP, VIP, VIO and rooted in the VI provisioning request or SLA between user/customer and VI/Cloud provider (in our model, VIP or VIO) [14] However to protect it from compromise (e.g. by cloning) and make it integrity protected, it needs to be bootstrapped to the virtualisation platform runtime environment. The proposed bootstrapping protocol using a Trusted Computing Platform Architecture (TCPA) and Trusted Platform Module (TPM) can provide a trustworthy platform from which secure systems may be built [22]. They can provide a Static Root of Trust, to allow booting a system to a known and trusted state by taking measurements and verifying each piece of software before it is executed [23].

In order to create a trusted computing environment, it is necessary to build an unbroken chain of trust from the most fundamental hardware (such as the BIOS and firmware) through to the operating system and virtualisation platform that hosts virtualised services and DACI itself. The TPM can be configured to take measurements of each software component before it is executed. Only if the signature is valid will the system proceed. Software needs to be specifically designed to take advantage of these capabilities;

as an example, such solutions and firmware are provided by Intel [24] and VMware [25].

The initial TPM based platform initiation uses a special method for remote TPM attestation called Direct Anonymous Attestation (DAA) [26] that actually requires a third party role (the Issuer) [27] that can be a part of Cloud provider security infrastructure.

In order to authenticate the TPM enabled system, the service provider would provide a signed package that contains relevant TPM public keys, system keys and valid trusted states for those machines. Next, a special Vanguard application is sent to a remote machine via the SCP protocol as an initial stage in the required service deployment. It determines the safety of the remote machine before more sensitive information or software is transferred to it. As part of the bootstrapping process a Vanguard application verifies the identity and state of the remote machine based on the fingerprint provided in the security package.

After verification, a trusted platform session token can be generated based on GRI or LRI that is then sealed by the TPM. It is included as a part of the general VI or DACI security context and can only be decrypted by the same TPM and only when in the same state [28]. This prevents the session from being decrypted on another machine and in effect binds the session to the machine in a trusted state. In order to defeat a cloning attack, an encryption key or other meta-data can also be sealed to a TPM. When used to encrypt disk images, this prevents the images from being decrypted on another untrusted machine.

VII. IMPLEMENTATION

The DACI implementation is based on the Generic AAA toolkit [21] that is extended to support provisioning Infrastructure Services On-Demand (hereafter called as GAAA-ISOD profile). It is being implemented in GEYSERS project [7] to provide the consistent authentication and authorization infrastructure. The implementation environment is FUSE Enterprise Service Bus and related products from FUSE [29].

A. DACI in On-demand Services Provisioning

As specified previously, each DACS instance is provisioned and binding to a VI during its lifetime. In the reservation stage, DACI Management receives a request and makes a provisioned “DACS Instance Request” along with its parameters. It binds the reserved DACS with the VI by the VI-GRI. Upon subsequent phases, the DACS instance is deployed and operated for the associated VI. Resources belongs to the VI are referred by unique identifiers at different layers. If multiple providers participate into the supply-chain, providers need suitable ID-Translation mechanisms to resolute these identifiers from provider to provider. It guarantees the transparency when end-users only need to interact with the original provider other than involving many other providers in the supply-chain.

Before instantiating the DACS, the DACI Trust Management needs to establish trust between related actors that starts from bootstrapping level at VRs. The bootstrapping procedures and trust establishment protocols,

which is similar to TCPA [30], is the basis to let end-users fully trust the runtime platform in the VI. After that, in the operational phase, DACS tools are delegated to the VIO. With these tools, the VIO can utilize elastic and consolidate access control services for VI which is supported natively from GEYSERS infrastructure.

B. GAAA toolkit library for Infrastructure Service On-demand Provisioning (GAAA-ISOD)

The toolkit for GAAA-ISOD profile implements AAA functionalities including Policy Decision Point (PDP), Policy Enforcement Point (PEP) and Security Token Service. The toolkit supports XACML standard for policy composition and management, SAML 2.0 standard with XACML-SAML profile and identity management by using SunXACML [31] and OpenSAML [32] libraries.

GAAA-ISOD Toolkit has the following features:

• Authorization session management mechanism using proprietary AuthzToken and TokenService functionalities.

• It could be applied to support various token service topologies as well as multi-virtual-domains session managements among VIs.

• Mechanism to auto generating XACML policies based on predefined templates and input parameters. It is one of basic element to support dynamic policies management for Infrastructure Service On-demand Provisioning (ISOD).

• Provide the Common Security Service Interface (CSSI) to facilitate the integration of third-party services with security services.

• Configurable Policy Decision Point engine that allows managing PDP instances binding to different VIs by unique identifier values.

C. Integration of security services in FUSE Source environment

In the GEYSERS implementation [7], components are known as OSGi bundles (Fig. 5). Each security bundle deployed in the ESB provides a specific service and could be consumed by other components. FUSE ESB provides messaging mechanisms to facilitate integrations of components. Bundles communicate to each other by messages which could be transformed, filtered or routed based on their contents and configurable rules. Furthermore, the message broker engine integrated in the ESB environment allow to interconnect multiple ESBs distributed at different locations, providing the clustering and redundancy capabilities for the Cloud system.

VIII. CONCLUSION

The paper has identified security challenges, characteristics and requirements for Cloud computing. It proposes the general security infrastructure for On-demand Service Provisioning that is in compliant with the SSLM. It also discusses about roles of trust in the security reference architecture and practical directions for trust establishment in Cloud, from trust bootstrapping to the trust relationships establishment with DSA. Furthermore, the paper presents the DACI, an access control infrastructure that adapt related security requirements for infrastructure service on-demand systems.

The proposed DACI are currently being implemented in the framework of the GEYSERS project on dynamic infrastructure service provisioning.

In the future work, we will research further to solve on mentioned security challenges in Cloud computing scenarios. They include trust modelling and trust establishment mechanisms across virtual Cloud security domains; applying bootstrapping TCPA [30] in security service lifecycle management; federated virtualized identity and access control management providing securely manage identities, authorization and security context delivery in collaboration operations among Clouds in tenancy and multi-provider eco systems. We will also continue developing the GAAA-ISOD toolkit library which adapt to SSLM and facilitate the security infrastructure implementations in different on-demand infrastructure service provisioning systems.

ACKNOWLEDGEMENTS

This work is supported by the FP7 EU funded project GEANT3 (FP7-ICT-238875), and the FP7 EU funded Integrated project The Generalised Architecture for Dynamic Infrastructure Services (GEYSERS, FP7-ICT-248657).

REFERENCES

[1] NIST SP 800-145, “A NIST definition of Cloud computing.” [2] NIST SP 500-291, “NIST Cloud Computing Standards Roadmap,”

NIST, NIST SP 500-291, Jul. 2011.

[3] “OGF ISOD-RG,” Infrastructure Services On-Demand Provisioning

Research Group. [Online]. Available:

http://www.ogf.org/gf/group_info/view.php?group=ISOD-RG. [4] OASIS IDCloud TC, “OASIS Identity in the Cloud TC.” [Online].

Available: http://wiki.oasis-open.org/id-cloud/.

[5] H. Takabi, J. B. D. Joshi, and G.-J. Ahn, “Security and Privacy Challenges in Cloud Computing Environments,” IEEE Security & Privacy Magazine, vol. 8, no. 6, pp. 24-31, Nov. 2010.

[6] D. Catteddu, and G. Hogben, “Cloud Computing Risk Assessment,” ENISA, Nov. 2009.

[7] GEYSERS Project, “GEYSERS - Generalised Architecture for Dynamic Infrastructure Services,” 2010. [Online]. Available: http://geysers.eu/.

[8] “Security Guidance for Critical Areas of Focus in Cloud Computing,” Cloud Security Alliance, v2.1, Dec. 2009.

[9] NIST SP 800-144, “Guidelines on Security and Privacy in Public Cloud Computing,” NIST, NIST800-144, Jan. 2011.

[10] J. M. A. Calero, N. Edwards, J. Kirschnick, L. Wilcock, and M. Wray, “Toward a Multi-Tenancy Authorization System for Cloud

Services,” IEEE Security & Privacy Magazine, vol. 8, no. 6, pp. 48-55, Nov. 2010.

[11] K. M. Khan and Q. Malluhi, “Establishing Trust in Cloud Computing,” IT Professional, vol. 12, no. 5, pp. 20-27, Sep. 2010. [12] M. Blaze et al., “Dynamic Trust Management,” Computer, vol. 42,

no. 2, pp. 44-52, Feb. 2009.

[13] L. M. Vaquero, L. Rodero-Merino, J. Caceres, and M. Lindner, “A break in the clouds,” ACM SIGCOMM Computer Communication Review, vol. 39, no. 1, p. 50, Dec. 2008.

[14] Y. Demchenko, C. Ngo, and C. de Laat, “Access control infrastructure for on-demand provisioned virtualised infrastructure services,” in 2011 International Conference on Collaboration Technologies and Systems (CTS), Philadelphia, PA, USA, 2011, pp. 466-475.

[15] Y. Demchenko, C. de Laat, D. R. Lopez, and J. A. Garcia-Espin, “Security Services Lifecycle Management in On-Demand Infrastructure Services Provisioning,” in 2010 IEEE Second International Conference on Cloud Computing Technology and Science, Indianapolis, IN, USA, 2010, pp. 644-650.

[16] H. Li and M. Singhal, “Trust Management in Distributed Systems,”

Computer, vol. 40, no. 2, pp. 45-53, Feb. 2007.

[17] A. Abdul-Rahman and S. Hailes, “A distributed trust model,” in

Proceedings of the 1997 workshop on New security paradigms - NSPW ’97, Langdale, Cumbria, United Kingdom, 1997, pp. 48-60. [18] Y. Demchenko, C. Ngo, T. Wlodarczyk, Z. Ziegler, C. Rong, and C.

de Laat, “Security Infrastructure for On-demand Provisioned Cloud Infrastructure Services,” in The 3rd IEEE International Conference on Cloud Computing Technology and Science (CloudCom2011), Athens, Greece, 2011.

[19] “Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS Standard,” OASIS, SAML, Mar. 2005.

[20] OASIS, “XACML 2.0 Core: eXtensible Access Control Markup Language (XACML) Version 2.0.” 01-Feb-2005.

[21] Phosphorus Project, Deliverable D4.3.1, “GAAA Toolkit pluggable components and XACML policy profile for ONRP,” Deliverable D4.3.1, Sep. 2008.

[22] D. O. Defense, “Trusted Computer System Evaluation Criteria,” Dec. 1985.

[23] D. Fisher, J. M. McCune, and A. D. Andrews, “Trust and Trusted Computing Platforms,” CMU/SEI-2011-TN-005, Jan. 2011.

[24] “Intel Hardware Technologies to Secure Clouds.” [Online]. Available: http://www.intel.com/content/www/us/en/enterprise-security/processors-with-built-in-cloud-security.html.

[25] “Intel Cloud Builders Guide for Enhancing Server Platform Security

with VMWare.” [Online]. Available: http://www.intel.com/Assets/PDF/general/icb_ra_cloud_computing_

VMware_TCP.pdf.

[26] E. Brickell, J. Camenisch, and L. Chen, “Direct anonymous attestation,” in Proceedings of the 11th ACM conference on Computer and communications security - CCS ’04, Washington DC, USA, 2004, p. 132.

[27] Y. Demchenko, L. Gommans, and C. de Laat, “Extending user-controlled security domain with TPM/TCG in Grid-based virtual collaborative environment,” in 2007 International Symposium on Collaborative Technologies and Systems, Orlando, FL, USA, 2007, pp. 57-65.

[28] B. Parno, “The Trusted Platform Module (TPM) and Sealed Storage,” Jun. 2007.

[29] “FuseSource Open Source SOA products,” FUSESource SOA, 2011. [Online]. Available: http://fusesource.com/products/.

[30] “Trusted Computing Group (TCG).” [Online]. Available: https://www.trustedcomputinggroup.org/home.

[31] “SunXACML Library 2.x,” Sun’s XACML Implementation. [Online]. Available: http://sunxacml.sourceforge.net/.

[32] “OpenSAML library 2.x.” [Online]. Available: http://www.opensaml.org/