Open-Source, Web-Based, Framework for Integrating Applications with Social Media Services and Personal Cloudlets

Transcription

1 Ref. Ares(2013) /02/2013 ICT Cloud Computing, Internet of Services & Advanced Software Engineering, FP7-ICT Open-Source, Web-Based, Framework for Integrating Applications with Social Media Services and Personal Cloudlets Deliverable Security and Privacy Considerations for Cloud-based Workpackage: Authors: Status: WP2 Use Cases Analysis and Requirements Specification Rodrigo Illera (LOG), Susana Ortega (LOG), Michael Petychakis (NTUA) Final Date: 31/01/2013 Version: 1.2 Classification: Public Disclaimer: The OPENi project is co-funded by the European Commission under the 7 th Framework Programme. This document reflects only authors views. EC is not liable for any use that may be done of the information contained therein.

2 OPENi Project Profile Contract No.: Acronym: Title: URL: FP7-ICT OPENi Open-Source, Web-Based, Framework for Integrating Applications with Social Media Services and Personal Cloudlets Start Date: 01/10/2012 Duration: 30 months Partners Waterford Institute of Technology Coordinator Ireland National Technical University of Athens (NTUA), Decision Support Systems Laboratory, DSSLab Greece Fraunhofer-Gesellschaft Zur Foerderung Der Angewandten Forschung E.V Germany INFORMATICA GESFOR SA Spain AMBIESENSE LTD UK VELTI SA Greece BETAPOND LIMITED Ireland 2

3 Document History Version Date Author (Partner) Remarks Rodrigo Illera (CGI) Initial table of contents Rodrigo Illera (CGI) Susana Ortega (CGI) Sections on Infrastructure Security and Identity Management Architecture included Sections on Secured Storage, Audits and Legal Issues included Michael Petychakis (NTUA) Sections on Services Privacy included Susana Ortega (CGI) First draft shared with consortium members Rodrigo Illera (CGI) Second draft. Feedback from reviewers included Rodrigo Illera(CGI) and Susana Ortega(CGI) Final reviewer comments addressed. 3

4 Executive Summary This deliverable describes the outcome of T2.3 Security and Privacy Analysis of OPENi project. The document has been written addressing specific security and privacy facets of the OPENi solution as a whole as well as its components: the Cloudlet Platform and the API framework. Sections provide: Analysis of the state of the art on privacy and security Available security and privacy frameworks and protocols Identity and access management practices for authentication, authorization and auditing. Privacy aspects based on laws and regulations Audit standards 4

5 Table of Contents 1 Introduction Purpose and Objectives Methodology Concepts Structure of the Document OPENi infrastructure security Network Security Confidentiality and integrity of data-in-transit Network Access Control (Authentication, authorization, auditing) Availability of Internet-facing cloud-provided resources in the network Host security PaaS and SaaS Host Security IaaS Host Security Application Security Threats Application Security of Cloud Service Models SaaS Application Security PaaS Application Security IaaS Application Security Cloudlet Data Security and Storage Cloudlet data security Storage-as-a-Service Data Encryption Security-as-a-Service Data loss prevention Web Security security Security assessments Intrusion management Security Information and Event Management Encryption Business continuity and disaster recovery Network security

6 4.10 Identity and access management Cloudlet and OPENi API Framework Privacy Considerations Privacy considerations for OPENi architecture Privacy considerations for the Cloud Platform Identity and Access Management Controls Towards an Identity and Access Management Architecture and Practice for the Cloudlet Platform Privacy for OPENi API framework and Cloud-based Services Standards and Protocols for Cloud Services SAML OAuth SPML XACML OpenID OATH Open AM (formerly known as Open SSO) Diameter/RADIUS Summary Available Frameworks Data Privacy and Legal Issues Cloudlet Audit and Compliance Audit Standards SAS ISO HIPPA (US) Other desiderable Standards Conclusions and Recommendations Annex I: References

7 List of Figures Figure 1: Cloudlet Platform Architecture Figure 2: API Framework Architecture Figure 3: OPENi environment Figure 4:Symmetric encryption Figure 5: Asymmetric encryption Figure 6: Phases of data lifecycle Figure 7: Example of Identity and Access Management functional architecture Figure 8: Identity lifecycle Figure 9: SSO transaction steps using SAML Figure 10: OAuth Example List of Tables Table 1: Responsabilities in OPENi architecture Table 2: Data security issues and solutions Table 3: Data loss prevention Services and vendors Table 4: Web security Services and vendors Table 5: security Services and vendors Table 6: Security assessments Services and vendors Table 7: Intrusion management Services and vendors Table 8: Security Information and Event Management Services and vendors Table 9: Encryption Services and vendors Table 10: 4.8 Business continuity and disaster recovery Services and vendors Table 11: 4.9 Network security Services and vendors Table 12: IAM Services and vendors Table 13: Cloud elements as provider/consumer Table 14: Functions over data Table 15: Summary of IAM protocols and standards Table 16: Evaluation of Service Models for OPENi Cloudlet Platform

8 1 Introduction 1.1 Purpose and Objectives Cloud computing establishes a new business and development model. Customers are not fully familiar with this model at the moment. One of the main concerns they have is about security and privacy of data, since Cloud Computing sets the trust boundary beyond the customer control. Vulnerabilities, weaknesses and risks still exist; however, they are not exacerbated by the so called Cloud Computing trend. Hence, security and privacy must be driving aspects while developing the OPENi solution. This document presents considerations that must be taken into account in the future design and development stages of the OPENi features. One of the OPENi key features is a cloud platform that allows users to create and manage their cloudlets. Cloudlets are person-oriented spaces in the cloud. Cloudlets will enable applications to access, store and update user data and content into cloud-based services according to users preferences. Information stored in such cloudlets could be considered sensitive for many reasons.. Data must be protected against unauthorized disclosure or destruction. Besides, cloudlet users should also be able to share determined data so it's only available to a limited set of entities. The OPENi solution must provide mechanisms to enable data sharing while ensuring confidentiality. 1.2 Methodology Many publications have been analysed in order to elaborate a list of potential considerations and good practices that have to be taken into account before delivering the OPENi solution. There is much information available; although, only aspects that are strictly relevant to OPENi project must be kept. In other words: Step 1: Collect general threats and concerns around Cloud Computing. In order to achieve this step several papers, publications, articles and book chapters have been analysed. Step 2: Identify which of the collected information applies to OPENi environment and its characteristics issues: Cloudlet platform and API framework. Step3: For every aspect of Cloud Computing security, a set of considerations and recommendations is provided. Security concerns provided in this document will be taken into account in future stages of development of the OPENi solution ( T2.5 Requirements specification, T3.3 Security and Privatisation Specification and T4.3 Privacy and Security framework ). 1.3 Concepts The Cloud Computing paradigm establishes a business model which involves three main actors: Cloud provider or cloud vendor: An entity that it s offering a determined IT resource asa-service. Cloud user or cloud consumer: An entity that it s using the resource provided by the cloud vendor. It s important not to confuse cloud user with the end user. The cloud user is the owner of an application deployed on a cloud vendor infrastructure. Between the cloud user and the cloud provider there exists a document called Service Level Agreement. This document establishes the rights and obligations of every party. End user: An entity that makes use of the service offered by the cloud user. 8

9 Along this document we will be constantly referring to these terms in order to assign responsibility on the different security and privacy aspects. The OPENi approach is a little bit more complex than plain Cloud Computing: OPENi environment sets an API framework sitting between Applications, Cloudbased Services and User Cloudlets. In turn, User Cloudlets are provided by the Cloudlet platform, another feature that will be developed within the OPENi project. Figure 1: Cloudlet Platform Architecture. [OPE12] Figure 2: API Framework Architecture. [OPE12] Establishing the relationship between the OPENi framework and each actor is important in order to ascertain which party is responsible for which aspect in any case: The so called Cloud-based Services are seen at all times as cloud providers by the OPENi API framework in the sense that they expose an interface to access an external resource. Applications can be seen either as end-users or cloud users. Methods are invoked by end users to access data stored in their cloudlet. In addition other methods are exposed to cloud 9

10 users to manage the underlying Cloudlet platform. The most compelling scenario should be considered, that s why applications will be seen by the OPENi framework as cloud users. It s still early to decide how the OPENi Cloudlet platform will implement storage features for the User Cloudlets. There are two ways to approach this issue: o To store cloudlets in repositories deployed for this purpose. o Storage of cloudlets could be relied on a previously contracted third party provider (storage-as-a-service). In any case it s sure that User Cloudlets are seen by the OPENi framework as a cloud provider. 1.4 Structure of the Document Each relevant aspect on security or privacy is fully studied in a separate section: OPENi infrastructure security: This section addresses security mechanisms at different levels of the infrastructure and considering all potential service models for OPENi features. Cloudlet Data Security and Storage: This section provides information about how to encrypt, store and transfer cloudlet information. Security-as-a-Service: This section presents available cloud solutions to provide security to Cloudlet platform and OPENi API framework. Cloudlet and OPENi API framework: This section focuses on considerations to deliver an effective architecture as the mean to provide privacy over the whole OPENi solution. Available frameworks: This section provides a list of existing results Seventh Research Framework Programme projects on privacy and security as well as other available open solutions. Data Privacy and Legal Issues: This section states briefly regulations OPENi solution may need to comply with. Cloudlet Audit and Compliance: This section describes which audit standards are available to ensure and assess security and privacy mechanisms. 10

11 2 OPENi infrastructure security OPENi solution comprises two main elements: API framework: A set of service enablers exposing an abstraction of many different cloudbased functionalities and contents. Regarding security, the API framework must assume responsibilities as a cloud provider, since it exposes different interfaces to be used by applications. In addition, it has also to face responsibilities as a cloud user of the Cloudlet platform (described below). Cloudlet platform: It provides storage and registry to implement User Cloudlets. The entity in charge of implementing the Cloudlet platform is referred along this section as its owner. When it comes to the matter of security, the Cloudlet platform must assume responsibilities as a cloud provider. But, the Cloudlet platform could also act as a cloud consumer if it s deployed using some sort of IaaS or PaaS underneath. The overall OPENi environment includes also Cloud-based services available in the Web and applications invoking the API framework to access the Cloudlet platform: Figure 3: OPENi environment The following table shows the different responsibilities that must be faced by these two elements of the OPENi architecture: API framework Cloudlet platform Responsibility faced as cloud provider The API framework must ensure the exposed interfaces are secured, this is, all methods have to be protected against potential attacks at application level. Cloudlet platform must ensure that their underlying infrastructure is secure. Depending on how the cloudlet platform is implemented different levels have to be taken into account. In case of disaster the cloudlet Responsibility faced as cloud user The API framework must ensure the provider has considered all security measures. The Cloudlet platform may be deployed on a IaaS or PaaS provider. In that case, it must ensure that such vendors offer disaster recovery plans. Fault tolerance by using multiple cloud providers will become crucial while 11

12 platform should provide rapid remediation that is transparent to the API framework. The speed of remediation by the Cloudlet platform should be more rapid than onpremises data centers. seeking to reduce the risk. Although, the economics of using multiple cloud providers will be far more compelling that sticking with a single provider or an on-premise deployment for storage- and cpu- intensive applications. Table 1: Responsibilities in OPENi architecture Security concerns in OPENi infrastructure don t differ much from those related to cloud computing in general. What it comes to the matter of infrastructure security, all services and spaces in the Cloud (e.g. a cloudlet) can be abstracted as a generic remote resource we have to protect from unauthorized or unintended access, change or destruction. All cloud providers and cloud users share the responsibility of providing security across the OPENi architecture. Both the OPENi API framework and the OPENi cloudlet platform have to be designed from scratch; therefore, many considerations have to be taken into account at all infrastructure levels. In the other hand, users can t manage Cloud-based Services at infrastructure level since they are generally managed by their providers. Hence, in this level users have to rely on infrastructure security mechanisms implemented by these third parties. Virtualization has encouraged organizations to leverage the content from their data centers to ondemand infrastructures. When adopting virtualization for cloud computing, it becomes evident that the management tools used in a physical server-based deployment won t suffice in a highly dynamic virtualized one. Besides, multi-tenancy implies different underlying threats, for instance, potential data leakages in a virtualization server shared between many users. Virtualization complicates the picture, but following subsections will show that this technology doesn t imply additional risks or threats. All infrastructure security problems associated with cloud computing are not caused specifically by cloud computing. They are exacerbated by cloud computing rather than been originated by it. Therefore, security concerns presented in this section will refer to cloud computing in general instead to a specific OPENi feature. Infrastructure security threats, challenges and solutions will be addressed using a multi-level approach: Network-level: Vulnerabilities on the low-level protocols linking different devices together Host-level: Threats derived from host virtualization Application-level: Vulnerabilities on web applications installed on hosts. Attackers mostly target this layer; therefore, it s the one that both users and providers should be more concerned about OPENi project is still in its earliest stage; hence, it s still too soon to decide which service model will be chosen to expose the Cloudlet platform and the API framework interfaces. The API framework will presumably be exposed as SaaS, but the Cloudlet platform could use any service model. In order to leave the door open for all potential solutions for the Cloudlet platform security will be reviewed considering the main cloud service models: IaaS, PaaS and SaaS. The Cloudlet platform is a very delicate feature of the OPENi solution since it stores sensitive information from many users. Depending on the provision model different protection mechanisms have to be deployed around the Cloudlet platform: If the Cloudlet platform is deployed in a tightly controlled environment like private clouds or an intranet, protection consists on a combination of application security mechanisms and network-based and host-based access controls. 12

13 If the Cloudlet platform is deployed on public clouds it must be designed following a internet threat protection model. The remaining controls are legated to the cloud vendor. 2.1 Network Security The network level involves routing and forwarding data between different nodes. In this section we will focus on the issues concerning this specific aspect of cloud computing infrastructure. The Cloudlet platform is an element of the OPENi architecture that has to be deployed on a determined organization s network. On this aspect, two ways are envisaged to deploy the Cloudlet platform: Deployment to on-premise network Deployment to an external cloud provider s network In the first case, the Cloudlet platform must act as a provider what it comes to the matter of network security. Then, all the considerations described in this section have to be carefully regarded when not applied. In the second situation, the Cloudlet platform plays the role of user which implies that there s no control over the underlying network. Hence, all this section has to be studied for informative purposes. Virtualization of network resources complicates the picture in the sense that an appropriate network interface must be delivered to every virtual machine (e.g. a multiplexed channel with all the switching and routing handled in the network interconnect hardware). However, this doesn t necessarily affect security. Hypervisors usually provide virtual switches and firewalls that sit between the server physical interfaces and the virtual interfaces exposed to the virtual machines. Different virtual devices are usually segregated, i.e. gathered on the same physical server along with other machines meeting the same set of requirements for colocation. Another usual practice to manage traffic between virtual machines is to use virtual local area network, VLANs, to isolate flows between one user s machine to another user s machine. The next problem in this scenario would be to scale VLAN-like capabilities to support larger clouds [Win12]. Cloud computing implies replacing an established model of network zones with security groups and domains. Users may fear that this lack of separation result in some sort of data permeability. However, there is no longer any required physical separation, as different domains may very well be on the same physical server (e.g. a test domain and a production domain). Furthermore, the former logical network separation no longer exists. Logical separation now is at the host level, with domains running on the same physical server and being separated only logically by hypervisors. There are four significant risk factors to consider while studying interactions between components of a cloud network topology: confidentiality and integrity of data-in-transit network access control availability Network level risks presented in this subsection apply to both SaaS, PaaS and IaaS service models Confidentiality and integrity of data-in-transit Data is transferred from the Cloudlet platform through many different network devices. During this exchange of information, the content of the messages may suffer undesired disclosure or modifications. These inconveniences may be unintentional accidents (e.g. transmission errors) or deliberate attacks (e.g. unauthorized eavesdropping of packets). At the end, all of them affect confidentiality and integrity of transmitted information. Confidentiality at network-level consists in ensuring that data-in-transit remains private even with intruders listening at the transmission channel. Since the Cloudlet platform handles sensitive information over a mobile environment (where everybody have access to the electromagnetic signal) 13

14 this aspect is especially important. In the other hand, integrity consists in protecting data against unauthorized modifications. There are many available standards and protocols to ensure data-in-transit confidentiality. Cloud computing in general, and OPENi Cloudlet platform in particular, must be aware of and consider all standard secured transmission protocols and solutions over the whole TCP/IP stack application. At application layer: HTTPS (HyperText Transfer Protocol Secure): It s the most known communication protocol for secure communications. It s the result of layering regular HTTP on top of SSL or TLS protocols, hence inheriting security capabilities from them (described below). S-HTTP (Secure HyperText Transfer Protocol): It s a secure message-oriented communications protocol designed for use in conjunction with HTTP. The protocol provides symmetric capabilities to both client and server. S-HTTP supports end-to-end secure transactions without requiring individual users to have an established public key since it as it supports symmetric key-only operation modes. In addition to transaction confidentiality, S- HTTP provides authenticity/integrity and non-repudiation of origin [Res99]. At transport layer: SSL (Secure Sockets Layer): A security protocol that provides privacy and reliability on communications over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery [Ssl11]. SSL protocol must be layered on top of some reliable transport protocol (e.g. TCP). Generally the process to establish a secure connection is done in three steps: a. The server and client to authenticate each other using asymmetric, or public key, cryptography (e.g. RSA, DSS). b. Both peers negotiate an encryption algorithm and define a secret cryptographic key (DES, 3DES, RC4) after a handshake process. c. A reliable connection is established. Messages integrity include a check using a keyed Message Authentication Code (MAC) based on hash functions TLS (Transport Layer Security): It s the natural evolution of SSL. The protocol is composed of two layers: the TLS Record Protocol and some higher-level encapsulated protocols (e.g. TLS Handshake Protocol, the most common one). TLS Record protocol provides reliable and private communications. Symmetric cryptography is used for data encryption e.g., AES [Tls08]. Likewise SSL, TLS establishes connections generally in three steps: a. The peer's identity can be authenticated using asymmetric, or public key, cryptography (similar to SSL) b. The negotiation of a shared secret is protected against eavesdropping and man-inthe-middle attacks. No attacker can modify the negotiation communication without being detected by the parties to the communication c. Connection is established The main difference with SSL is that, while SSL connections begin with security and proceed directly to secured communications, TLS connections first begin with an insecure hello to the server and only switch to secured communications after the handshake between the client and the server is successful. If the TLS handshake fails for any reason, the connection is never created [Kan08]. SSH (Secure Shell): is a general-purpose user authentication protocol. This protocol assumes that the underlying protocols provide integrity and confidentiality protection. When this protocol starts, it receives the session identifier from the lower-level protocol (this is the exchange hash H from the first key exchange). The session identifier uniquely identifies this session and is suitable for signing in order to prove ownership of a private key. This protocol also needs to know whether the lower-level protocol provides confidentiality protection or not [Ylo06]. 14

15 SFTP (SSH File Transfer Protocol): it provides secure file transfer (and more generally file system access) functionality over a reliable data stream. It must run over a secure channel. This protocol is described in the context of the SSH2 protocol, however it s general and independent of the rest of the SSH2 protocol suite. This protocol follows a simple requestresponse model between an authenticated user and a server [Sft06]. At internet layer: IPSec (Internet Protocol Security) and IKE (Internet Key Exchange): IPSec is a suite of protocols that provides security to communications at the IP layer. It s main use is to provide Virtual Private Network (VPN). It can also provide end-to-end or host-to-host security. IKE is the widespread key negotiation and management protocol. IPsec and IKE can be used in conjunction with both IPv4 and IPv6 [Ips11]. Data encryption is used to provide confidentiality at upper layers. This aspect will be fully described later in another chapter Network Access Control (Authentication, authorization, auditing) Leveraging systems to the Cloud always implies loss of control over resources. If the OPENi Cloudlet platform is deployed on a cloud provider premises, it s crucial to remember that it may be impossible to monitor their network the same way as it is done in a regular network. Access to relevant networklevel data and logs will be decreased making auditing impossible at network level. Hence, ability to conduct investigations and gather forensic data to detect and prevent attacks is limited. There are few actions the owner of the Cloudlet platform could take on this front, although being aware of the risks decreases the likelihood of attacks. One of the most important risks derived from this lack of knowledge is undetected and unauthorized network access to resources in a multi-tenancy scenario. For example, cloud providers usually reuse IP addresses by re-assigning them to tenants. However, there is a lag time between addresses are changed and caches are cleared in both DNS and ARP tables. Attackers may exploit this lag time (when old addresses are still on cache) to reach supposedly non-existent resources. Therefore, Cloudlet platform owners should be aware that network access to their resources is still possible for a little time after releasing the IP address. Private internal network resources are vulnerable to these attacks as well. In addition, while using virtualization of machines, if IP addresses change during a hypothetical relocation of those machines (which is unlikely, but possible) and absolute addressing is used for firewall rules, then the security filtering feature provided by the firewall will fail. According to Winkler [Win12], undetected network attacks between virtual machines collocated on a physical server are a special concern while virtualizing a network. In this case there are several approaches, the first one is installing a local firewall or a traffic management software in the virtual machines we want to monitor the traffic for. Still, this solution provides monitoring for a portion of the network only Availability of Internet-facing cloud-provided resources in the network The network-level attacks may also target availability of cloud provided resources. Network layer reachability information could be forged in order to affect normal access to resources, including a Cloudlet platform deployed on an external vendor infrastructure. One of this attacks is BGP prefix hijacking, which involves an attacker announcing a range of addresses belonging to someone else by using a misconfigured or malicious BGP router. In this case, the legitimate owner of the prefix will see access to his data blocked by the attacker. Although prefix hijackings are not new, that attack figure will certainly rise, and probably significantly, along with a rise in cloud computing. However, there are some defense mechanisms against BGP prefix hijacking attacks [Zha07]. 15

16 Another good example of network attack targeting availability are DNS attacks. This risk is especially exacerbated by Cloud Computing, since it implies an increase of external DNS querying. This attack basically consist on a DNS being tricked into accepting incorrect or malicious information. Theoretically, an attacker wouldn t need to steal resources from the Cloudlet platform to harm its owner. Most of the times it s enough to isolate the related network resources so neither the owner nor the attacker is able to use them. This is what we call denial-of-service attacks. Cloud providers are as prone to this kind of attack as any other organization with a public face in the internet. However, if the OPENi cloudlet platform is deployed on a IaaS provider, internal attacks have to be consider in addition to external attacks. Some other malicious cloud user could use its access to the internal network to find and attack any workload hosted by the cloud provider, including the Cloudlet platform. Generally, availability problems at network level are far more difficult to mitigate in contracted cloud provider scenario than in a legacy system counterpart. 2.2 Host security As we said in the preceding section, an OPENi Cloudlet platform can be deployed either into its owner s premises or into an external cloud vendor s infrastructure. This section covers all security considerations at host level in case the Cloudlet platform owner chooses to contract an externalized infrastructure. At host level, there are no new cloud-computing specific threats. Instead, it seems that public clouds generally suffer from security threats inherited from host virtualization. In this section we will review host security in the context of the possible cloud service models available to deploy the Cloudlet platform [Mel11]: PaaS and SaaS: The Cloudlet platform owner can respectively deploy or use providers application running on a cloud infrastructure. Although, he does not manage or control the underlying cloud infrastructure. IaaS: The Cloudlet platform owner does not manage the underlying cloud infrastructure either, but he has some control over operating systems, storage or deployed applications to manage the cloudlets PaaS and SaaS Host Security In the context of PaaS and SaaS infrastructures, the cloud vendor is responsible of providing host security to the Cloudlet platform. The owner of the cloudlet platform is relegated from this task, since he is not capable of accessing operative systems and processes. Cloudlet platform owners don t have to worry about protecting hosts from host-based security threats. However, virtualization software like VMware or Xen are common technologies to create and provide hosts, so Cloudlet platform owners should be aware and understand how virtual machines are managed and secured by the contracted cloud provider. In any case, owners have to consider the risks derived from managing cloudlet data hosted in the cloud IaaS Host Security An organization may choose to deploy an OPENi Cloudlet platform into a determined IaaS provider. In that case, Cloudlet platform owners are responsible for securing the hosts provided through the cloud. Most of IaaS providers use virtualization to provide hosts. In this virtualization scenario there are two aspects we have to consider concerning host security: Virtualization software security: There is a software layer sitting between the hardware and the virtual hosts. One important part of this software is the so called hypervisor. Its function is to create, manage and destroy virtual instances. One potential risk has to do with the potential to compromise a hypervisor with undesired consequences [Win12]. Vulnerability of the virtualization layer has been already evinced by some researchers 16

17 [Rut09]. With hackers targeting this layer, an attack against the virtualization layer could compromise the hosted Cloudlet platform. There is the risk of inadequate administrative access controls and administrative tools for the hypervisor/virtual machine manager layer. A potential loss of separation duties for network and security controls could lead to inadvertently allowing another users to gain access to host resources that exceeds their normal privilege levels [Hic12]. In any case, Cloudlet platform owners generally don t have access to this software layer. Therefore, they don t have any responsibility over it. It s the IaaS provider who should ensure all security mechanisms at this level. Cloudlet platform owners are only expected to understand the technology and the security processes instituted by the provider. Virtual server security: As IaaS users, Cloudlet platform owners have access to all functionalities and features of contracted isolated hosts. Hence, Cloudlet platform owners are in charge of implementing sufficient security mitigation steps in order to protect their hosts. A good practice is to restrict access to virtual instances. However, providers usually blocks many port accesses to virtual servers beforehand to prevent attacks to their customers. Cloudlet platform owners are strongly encouraged to use Secure Shell (SSH [Ylo06]) on port 22 to manage virtual server instances. There are many threats around virtual servers: attackers stealing SSH private keys to gain access to hosts, vulnerable services listening on standard ports, inadequately protected accounts hijacked, etc. In order to secure a host Cloudlet platform owners are recommended to: o Use a secure-by-default configuration. o Safeguard the private keys required to access hosts in the public cloud. o Isolate the encryption keys from the cloud where the data is hosted. o Run a host firewall and open only the minimum ports necessary to support the services on an instance. o Enable system auditing and log the security events to a dedicated log server. 2.3 Application Security This aspect of infrastructure security affects both the OPENi API framework and the Cloudlet platform. Application level security involves web interfaces, protocols and services located in the cloud. In a general cloud computing scenario, the responsibility of providing security mechanisms on application level rely on either the user, the consumer or both of them depending on the delivery model and the Service Level Agreement (SLA). In the specific case of OPENi environment, responsibility is shared between: The Cloud-based Service providers The Cloudlet platform owner The cloud infrastructure provider (only in case the Cloudlet platform is deployed to an external cloud vendor. Otherwise, it s the Cloudlet platform owner himself) Developers of Applications invoking the OPENi API framework The end users accessing resources in the cloud through Applications using the API framework Setting a unique document describing the terms of how responsibilities are distributed between all parties is not very likely. Instead, a Service Level Agreement will be established between each two related parties. In case a Cloudlet platform is deployed in an external infrastructure, its owner won t have the whole picture of software vulnerabilities. This is because Cloud platform owner won t have the required level of transparency from their cloud vendor. The only exception happens if such cloud vendor is using open source solutions to provide cloud services to their customers. Otherwise, Cloudlet platform 17

18 owners won t have many other choices than trusting their cloud provider. Owners should demand Cloud providers to disclose and notify them any discovered vulnerability affecting confidentiality, integrity or availability of Cloudlet platforms. It s important to notice that some web application attacks through the API frameworks may not be possible to prevent completely without end user collaboration. This is because the application invoking the interface is executed on end user s web browser. Application developers using the OPENi API framework must encourage their end users to frequently check their browser vendor s website for security updates Threats Application-level is the most frequently targeted by attackers. The features delivered by the OPENi project (the Cloudlet platform and the API framework) must exposed APIs are protected against most common threats. Hence, application security is crucial factor and must be included into OPENi features Software Development Lifecycle. The Open Web Application Security Project (OWASP) is an organization whose purpose is to raise awareness about application security by identifying and providing solutions for some of the most critical risks facing with web applications. The OPENi Project should apply the lessons learned by this organization for their own benefit. Defects range from insufficient validation to application logic errors. According to OWASP the top ten web application threats are [Owa10]: Injection: Occur when untrusted data is sent to an interpreter as part of a command or query. The attacker s hostile data can trick the interpreter into executing unintended commands. Cross-Site Scripting (XSS): Occur whenever an application takes untrusted data and sends it to a web browser without proper validation and escaping. XSS allows attackers to execute scripts in the victim s browser. Broken Authentication and Session Management: It happens when attackers exploit implementation flaws to compromise passwords, keys, session tokens, or to impersonate users. Insecure Direct Object References: Occurs when attackers manipulate references to internal implementation objects (files, directories, etc) to access unauthorized data. Cross-Site Request Forgery (CSRF): It happens when a logged user browser is tricked to sent a forged HTTP request along with authentication information to a vulnerable web application. This allows the attacker to force the victim s browser to generate requests the vulnerable application thinks are legitimate requests from the victim. Security Misconfiguration: It happens when administrators don't keep security software up to date or properly configured. Application, frameworks, servers and platforms must have their own security configuration. Insecure Cryptographic Storage: It occurs when attackers steal or modify weakly protected sensitive data to conduct identity theft, credit card fraud, or other crimes. Failure to Restrict URL Access: Some applications check URL access rights before rendering protected elements. This attack occurs when intruders are able to forge URLs to access these hidden pages anyway. Insufficient Transport Layer Protection: Occurs when a web application fails to authenticate, encrypt, and protect the confidentiality and integrity of sensitive network traffic Invalidated Redirects and Forwards: It happens when attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages. One of the most delicate issues addressed by OPENi project is to include Online Payment Cloud-based Services. Transactions between nodes have to be protected since they handle personal banking account numbers, passwords and other sensitive information. Entities invoking online payment APIs 18

19 have only partial control of what is being used, and yet a minimum set of tools to monitor. Attacks like phishing attempt and sometimes succeed in stealing usernames, passwords and credit card details by impersonating a trusted entity. Regarding availability, OPENi cloudlet platform and API framework could also be subject to denial-ofservice attacks. Application level has been prone to this kind of attacks before. Such attacks usually manifest themselves as: High-volume web page reloads XML* web services request Protocol-specific requests supported by a cloud service One of the challenges around this kind of attacks is selectively filter the undesired data flows without impacting the OPENi solution as a whole. This is very difficult because malicious traffic blends with legitimate data flows. Furthermore, there is another kind of attacks targeting availability of OPENi Cloudlet platforms. These are the so called Economic Denial Of Sustainability attacks (EDoS). This happens when intruders perform attacks designed to quickly drain Cloudlet platform owner s budget for cloud services, network bandwidth, CPU, and storage consumption. Hackers may even be able to link together computing resources to achieve massive amounts of computing without any of the capital infrastructure costs Application Security of Cloud Service Models In the very beginning of this chapter it was stated that OPENi project was still in an earliest stage; which meant that no service model paradigm had been selected yet to expose OPENi features interfaces: SaaS, PaaS or IaaS. The API framework will be presumably provider exclusively as SaaS. In the other hand, the Cloudlet platform could be delivered using one of the three proposed options. From the point of view of a cloudlet platform owner, each choice implies different responsibilities as well as advantages and flaws. This subsection will describe considerations derived from every service model. The final decision will be made by the OPENi consortium in future stages of the project SaaS Application Security Exposing the Cloudlet platform or the API framework following the SaaS paradigm imply offering and managing capabilities running on a cloud infrastructure. As SaaS providers, the Cloudlet platform and the API framework would be largely responsible for securing the applications and components they offer to users. Application developers aiming to use OPENi solutions would not be expected to implement any additional security mechanism. Although, such developers are expected to face the risk derived by the use of SaaS resources, especially if they use them to handle sensitive information. In order to assess OPENi security mechanisms, users may ask to perform a penetration testing (black-box security testing) of the API framework and the Cloudlet platform (in any case, consent from the OPENi features provider should be required beforehand). The risks at this level are related with vulnerabilities and weaknesses originated by coding flaws. Developers of Cloudlet platform and API frameworks have to pay special attention to authentication and access control over features and functionalities. As SaaS providers, OPENi features provider have to ensure that privilege management features and access is fine-grained. Also, weaknesses that may not conform to organization s access control standards must be avoided. One solution to achieve security is to implement strong authentication and privilege management based on user roles. One of the most sensitive elements of the Cloudlet platform is the administration tool. Intruders gaining unauthorized access to this tool can perform further attacks compromising the whole User Cloudlet provision with catastrophic consequences that range from denial-of-service to information theft. Additional controls should be implemented to manage privileged access to the Cloudlet platform administration tool, and enforce segregation of duties in order to avoid even unintended actions. 19

20 The Cloudlet platform store information that can be considered sensitive. Although, resources are shared between the different users contracting the same Cloudlet platform. This means that user data is mingled and not isolated. There is the risk of loss of confidentiality. As a SaaS provider, the Cloudlet platform could solve this problem by applying tagging over user data. In a multitenant data store model, where encryption may not be feasible due to key management and other design barriers, data is tagged and stored with a unique customer identifier. This solution seems to be enough to mitigate risks affecting confidentiality; although, is conceivable that the application layer enforcing this isolation could become vulnerable during software upgrades by the Cloudlet platform and underlying third parties. It was said in the last subsection that Online Payment Cloud-based services were extremely delicate. In order to avoid security breach in these services the first and more obvious solution is systematic monitoring (e.g. amazon services, heroku). OPENi API framework developers must demand from Online payment cloud service providers a close record of how their services are being used. Providers must also comply with the Payment Card Industry (PCI) regulations [Pci13]. There are six categories of PCI compliance security standards: Build and Maintain a Secure Network o Requirement 1: Install and maintain a firewall configuration to protect cardholder data o Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters Protect Cardholder Data o Requirement 3: Protect stored cardholder data o Requirement 4: Encrypt transmission of cardholder data across open, public networks Maintain a Vulnerability Management Program o Requirement 5: Use and regularly update anti-virus software o Requirement 6: Develop and maintain secure systems and applications Implement Strong Access Control Measures o Requirement 7: Restrict access to cardholder data by business need-to-know o Requirement 8: Assign a unique ID to each person with computer access o Requirement 9: Restrict physical access to cardholder data Regularly Monitor and Test Networks o Requirement 10: Track and monitor all access to network resources and cardholder data o Requirement 11: Regularly test security systems and processes Maintain an Information Security Policy o Requirement 12: Maintain a policy that addresses information security When it comes to the matter of the OPENi API framework, one of the most sensitive information to store and manage is API keys. An API key gives the API framework a way to (most of the time) know the identity of each caller to maintain a log. API Key access and storage needs to be addressed in a secure way to avoid unauthorized access, Denial-of-Service, or XML specific attacks. For example, giving away API keys to third parties enables partial access to all keys on the same account. In order to store API Key securely, keys have to be protected in both server and client sides. For an effective API Key implementation and management: (a) increase the randomness of the API Keys to bits (b) offer an option to disable API Key usage in the Account Management (which is the solution adopted by Facebook and Twitter) The OPENi API framework has to be protected against incorrect or malicious use by users. Developers of applications accessing the API might inadvertently write some inefficient code or might try to download big amounts of data. Regulating traffic flow of requests to the API framework is crucial to address these issues. The Service Level Agreement establishes the terms of use of the API. 20

21 SLA mediation primitives (i.e. SLA Local Enforcement and SLA Cluster Enforcement) control the type of traffic admitted into the network for individual requesters. SLA limitations form a three-level hierarchy: requester, service, and operation. Requester limits govern all traffic from a specific requester across all services. Service limits constrain the rate of requests for all operations executed against that service, regardless of the distribution of requests to the individual operations. Operation limits constrain the rate of requests executed against a particular operation. Summarizing, by using a SaaS delivery model, application risks are mitigated by proper authentication and access control as well as good isolation of user data PaaS Application Security By assuming the role of PaaS provider, the OPENi Cloudlet platform would have to enable users to deploy applications onto its cloud infrastructure and have some sort of control over these applications. Although, management or control over the infrastructure itself must be forbidden to users. As a PaaS provider, the Cloudlet platform owner would be responsible for securing the platform. Users just should understand the nature of the service and be aware that Cloudlet applications may depend on different third parties. In that scenario every third-party provider is responsible for securing its part. Cloudlet platform should not require users implementing their own security solutions. Moreover, users may demand transparency from the Cloudlet platform provider to perform their own assessments and tests. If the owner finally decides to deliver the Cloudlet platform as Paas there are two aspects he has to consider concerning application security: Security of the Cloudlet platform itself: In order to achieve isolation of running programs launched by different users, the Cloudlet platform must be delivered in some sort of sandbox architecture. This means that the set of resources provided to guest programs is tightly controlled and some functionalities are disallowed (e.g. network access, host system inspection, etc). The sandbox characteristic of the platform runtime engine is crucial in maintaining the confidentiality and integrity of applications deployed in the Cloudlet platform. Security of user applications deployed on a Cloudlet platform: Developers using resources provided by the Cloudlet platform are required to become familiar with platformspecific security features (e.g. security objects and web services for configuring authentication and authorization controls within the application). The Cloud platform provider must enable security mechanisms users can rely on. Some of the security features the Cloudlet platform should offer include: o user authentication o identity store o single sign-on (SSO) using federation o authorization (privilege management) o SSL or TLS support, made available via the API When it comes to Cloudlet platform API design, some widespread protocols should be considered in order to enable porting an application across different clouds without further issues. Security Assertion Markup Language (SAML) is a common protocol supporting user federation IaaS Application Security OPENi Cloudlet platform defines storage and registry functionalities that could also be addressed using a IaaS delivery model. In that case, users would be able to use the cloud infrastructure provided by the Cloudlet platform, including computing resources, storage and networks. Theoretically, such approach would also imply users having some sort of control over applications and operative systems deployed into the Cloudlet platform infrastructure. Many aspects would be out of Cloudlet platform owner s control. It s users who now have full responsibility for securing their 21

22 applications deployed in the infrastructure. As IaaS cloud providers, the Cloudlet platform owner would be agnostic to the operations and management of the user s applications. Users developing and deploying applications on a cloud infrastructure (e.g. Cloudlet platform), are encouraged to consider the most common web risks. Most of them have been described by OWASP (see above). Once a user has deployed an application in an infrastructure, he has to assess the security by performing periodic penetration tests. As it has been said before, security is an aspect that should be embedded in the Software Development Lifecycle. A recommended approach for Cloudlet platform users would be to design and deploy applications using a least-privileged runtime approach (i.e. the application has to be able to run using minimum permissions and a lower privileged account). Besides, developers must implement their own features to handle authentication and authorization over the applications they create. 22

23 3 Cloudlet Data Security and Storage 3.1 Cloudlet data security In the context of OPENi project, a cloudlet is defined as a personal space in the web where users store any kind of information, like pictures, financial data or medical records. There is no need to say that given the sensitivity of information, data security is a crucial aspect to take into account. Cloudlets are stored and delivered by the Cloudlet platform. As we have seen in the previous chapters, decision on Cloudlet platform service model has not been made yet. It could be either SaaS, PaaS or IaaS. Decision will be made on future stages of the project. Cloudlet platform owners and users have each their own responsibility regarding data security. Cloudlet platform users may be asked to protect their own data and metadata. The Cloudlet platform provider has to assure that their mechanisms are secure and reliable. Users have to be informed about how the Cloudlet platform collects, stores, monitors and protects their data. Cloudlet platform may be required to provide logs in case of forensic analysis or audit, so monitoring of their own data is a must. The innovative concept of cloudlet doesn t imply new aspects to consider regarding data security. The following table summarizes which solutions are applied to every of the issues around data security. Aspect Solution data-in-transit use of secure protocols data-at-rest encryption, data tagging processing/ multi-tenancy data tagging data remnants clearing, sanitization, high level SLA Table 2: Data security issues and solutions Data-in-transit refers to the secure transmission of data between the Cloudlet platform and the API framework. Safety is based on the use of encryption and secure protocols (e.g., FTP over SSL [FTPS], Hypertext Transfer Protocol Secure [HTTPS], and Secure Copy Program [SCP]). Encryption of data-intransit will be explained in next sections. Protocols have been described in the previous chapter. Data-in-transit integrity is normally ensured by applying some message encryption mechanisms: XML encryption: it s a W3C recommended standard process for encrypting data and representing the result in XML. When encrypting an XML element or element contents the resulting encrypted data element replaces the element or content (respectively) in the encrypted version of the XML document [Ima02]. However, this method has been proven to be insecure at ACM Conference on Computer and Communications Security 2011 [Wyl11]. XML signature: it s an XML syntax and processing rules for creating and representing digital signatures. X.509 certificates: it s an ITU-T standard for a Public Key Infrastructure (PKI) and Privilege Management Infrastructure (PMI). X.509 specifies, amongst other things, standard formats for public key certificates, certificate revocation lists, attribute certificates, and a certification path validation algorithm. 23

24 Regarding the data-at-rest aspect, encryption is a desirable but not always a feasible mechanism. It is an obvious practice to apply encryption to archived data, i.e. data not being used by any application or system at the moment. But when it comes to data-at-rest in use by any application, this mechanism may complicate, while not disable, data managing at real time. It wouldn t be possible to index or request this information if encryption is applied. Because of the multi-tenancy characteristic of Cloudlet platform, different users data may be coexisting at the same Cloudlet platform (hence, using the same storage environment). Data tagging is a mean to ensure confidentiality of data; although, the Cloudlet platform should implement additional mechanisms to isolate and manage data separately. Data remnants refers to the residual physical representation of data that remains once the data has been formally erased from the cloudlet platform. That is, data have met the end of their life cycle. In a cloud environment, users don t have a physical way to delete their data. This security aspect is not usually considered by cloud providers. In fact, there is no specific standard defined. However, proper removal of data is a desirable feature of the Cloudlet platform. The U.S. Department of Defence (DoD) M (the National Industrial Security Program Operating Manual) suggests two ways to deal with data remnants [DoD06] : Clearing is the process of eradicating the data from a storage resource before reusing such storage resource in another environment providing an acceptable level of protection for the data that was stored on the media before clearing. Any internal disk, buffer, or other reusable memory shall be cleared to effectively deny access to previously stored information. Sanitization is a process similar to clearing. In this case, the environment where we are reusing the storage resource does not provide an acceptable level of protection for the data that was on the media before sanitizing. Resources shall be sanitized before they are released from classified information controls, or released for use at a lower classification level. This is a more successful way to palliate data remnants than just clearing. Data remnants is one of the most important aspects that have to be discussed in the Service Level Agreement between the Cloudlet platform owner and its users. In case of security auditing, data lineage control is important. It consists of ascertaining the origin of a determined data. Although, following the path of data is a complex process especially when it comes from a public cloud service. How can a system know the first origin of data? Many scenarios are possible: data could have been saved for the first time in an external Cloud-based service, or could have been moved several times across different cloud infrastructures. The approach taken by OPENi project considers that data belong to one user, but are provided by different systems, each one with their own storage service and security policies. 3.2 Storage-as-a-Service When OPENi Cloudlet platform has been described in this document deployment of the solution hasn t been specified. Many cloud-providers offer storage-as-a-service as an alternative to repositories. The Cloudlet platform could either rely on such services or specify deploying a dedicated storage environment for this purpose. This section will explore the considerations derived from relying on a storage-as-a-service provider. While using storage-as-a-service, security concerns are the same than for any other kind of storage: confidentiality, integrity and availability. There are two concerns on confidentiality: access control to cloudlet information and the way such information is stored in the cloud. Access control involves authentication and authorization mechanisms. The way data are stored mainly refers to encryption. Encryption is the only mechanism 24

25 which has defined standards (e.g. NIST). There are other techniques providing confidentiality like indexing, masking or truncation, but they don t have defined standards. Some cloud providers encrypt their users data (e.g EMC s MozyEnterprise) but the most common scenario implies vendors not doing any encryption on users data. In this second case, the Cloudlet platform owner may decide to encrypt their data by himself before uploading it to the storage-as-a-service provider. Implementing or not encryption on data stored in the Cloudlet platform is a decision to be made in the next stages of OPENi project. If a storage-as-a-service provider is contracted and encryption is required, only algorithms publicly vetted by formal standardization bodies should be applied. Algorithms informally supported by the cryptographic community could also be valid. Proprietary algorithms should be avoided. Related to this, only symmetric encryption (described below) has the required computational efficiency to manage encryption for such a large volume of data as a cloudlet. Encryption provides confidentiality over the cloudlet platform, but when it comes to the matter of integrity it s necessary to use Message Authentication Codes (MACs). Combining data encryption with integrity protections such as digital signatures can ensure that data in the cloud remains both private and authentic. Although, this makes the process harder to manage. Cloud platform owners have to understand which of these mechanisms are used by their storage-as-a-service vendor to ensure data integrity. Availability is not a new concern, but it implies a higher risk because cloudlet data are managed by the storage-as-a-service provider. There are three main concerns about availability: Network-based attacks (already described at Network security subsection above), Cloud Provider s own availability issues Disaster recovery plans: backups, mirroring, physical security, fault tolerance, etc. How these three concerns are managed must be reflected vendor in the Service Level Agreement (SLA), a contract negotiated between the Cloudlet platform owner and the storage-as-a-service. 3.3 Data Encryption Data security in the Cloudlet platform would be dramatically improved if encryption mechanisms were implemented. Two main encryption schemes will be described: Symmetric encryption means that same single secret key is shared between two parties. The same key is used in both encrypting and decrypting processes. The following image presents a situation of encryption applied to an service, but it can be applied to many other ambits. Given its computational simplicity, symmetric encryption is appropriate for dataat-rest encryption. If an encryption mechanism should be applied to archive personal information into the machine serving the Cloudlet platform, symmetric encryption would be the wisest choice. 25

26 Figure 4:Symmetric encryption. [Mat09] Symmetric encryption implies that the secret shared key must be exchanged between two parties sometime before performing the encryption. An intruder may steal this key and compromise the whole system. Asymmetric encryption provides a solution to this problem since it implies the use of two keys instead of one. One publicly available key is used for encryption. The second key is private and non-transferable; it s used only by recipients for decryption. In data-at-rest storage ambit, asymmetric encryption is not commonly used because it requires many computational resources [Mat09]. However, it seems a good encryption solution for data-in-transit, e.g. personal information being transferred from the Cloudlet platform to OPENi API framework. Figure 5: Asymmetric encryption. [Mat09] In both encryption types, the longer the key length, the stronger the encryption. Lengths should be a minimum of 112 bits for Triple DES (Data Encryption Standard) and 128 bits for AES (Advanced Encryption Standard). Both are NIST-approved algorithms. It s strongly recommended for users to manage their own keys by themselves instead of relying on a cloud provider. 26

27 Some of the most known examples of encryption algorithms are: RSA algorithm: is an algorithm for public-key cryptography that is based on the presumed difficulty of factoring large integers, the factoring problem Rabin signature: one of the first digital signature schemes proposed, and it was the first to relate the hardness of forgery directly to the problem of integer factorization. Cryptographic hash function: an algorithm that takes an arbitrary block of data and returns a fixed-size bit string, the (cryptographic) hash value, such that an (accidental or intentional) change to the data will (with very high probability) change the hash value. Lamport signatures: signatures can be built from any cryptographically secure one-way function; usually a cryptographic hash function is used. Merkle signatures: Hash trees are a combination of hash lists and hash chaining, which in turn are extensions of hashing. 27

28 4 Security-as-a-Service The chapter titled OPENi infrastructure security described security mechanisms at low level (networklevel, host-level and application-level). Either if OPENi features are deployed in an in-house environment or some cloud vendor infrastructure these controls must be deployed or understood respectively. Security mechanisms could be relied to a Security-as-a-Service provider. In the context of OPENi project, a SecaaS vendor could be contracted in order to provide security to the Cloudlet platform or the API framework. Security is a never-ending battle. One of the biggest problems is the need of constant updating. Security-as-a-Service (SecaaS) is one of the business models in the Cloud Computing paradigm. It consists on a provider offering security features over the cloud. It could be seen as a subclass of Software-as-a-Service. It is an outsourcing model for security management. Security-as-a-Service refers to the provision of security applications and services via the cloud either to [CSA11]: cloud-based infrastructures customers on-premise systems SecaaS solutions could allow OPENi features to be fully protected and controlled by policies, even if they are not deployed into static environments. Security mechanisms could be updated in the cloud with no further involvement from Cloudlet platform owner of API framework developers. Physical location is no longer a critical aspect affecting the effectiveness of security, since analysis and security decisions take place in the cloud. SecaaS solutions are designed for instant deployment, needing little or no administrative involvement. OPENi security mechanisms wouldn t be necessarily less robust or less compliant than in-house installations. Although, it s potentially harder to demonstrate such compliance. Considering SecaaS as an alternative to deploying security mechanisms, there are not many additional concerns (compliance, multi-tenancy, vendor lock-in) nor advantages (competitive advantages, improved vendor-client relationship). Relying or not on a Security-as-a-Service provider for OPENi solution is a decision that will need to be made in future stages of the project. It s important evaluate the economic impact of contracting a SecaaS provider. The next subsections present the principal categories in security-as-a-service and some commercial SecaaS offerings [CSA11_2]. 4.1 Data loss prevention Data loss prevention services offer data protection against destruction or disclosure. Data loss prevention mechanisms usually run as in clients (e.g. a desktop based plugin) or servers. These programs reinforce policies about what and how data can be managed. For instance, some desktop controls prevent users from ing documents containing numbers that look like credit card numbers. When it comes to OPENi project, this solution could prevent end users accidentally disclose their personal information. Data loss prevention is a preventative control. Services Encryption, Meta-data tagging, Data Identification, Multilingual Fingerprinting, Data Leakage Detection, Policy Management and Classification, Transparent Data Encryption, Policy Controlled Data Access, Storage and Transportation, Dynamic Data Masking 28

29 Cloud products and vendors BlueCoat IBM Imperva Oracle Reconnex RSA Symantec/Vontu WebSens Zscaler 4.2 Web Security Table 3: Data loss prevention Services and vendors Web security is real-time protection consisting on proxying or redirecting web traffic to the SecaaS provider. The SecaaS providers perform analysis and monitoring in order to mitigate potential web application vulnerabilities. Traffic may come from the Cloudlet platform or from the OPENi API framework. Web security is a protective, detective and reactive control. Services Server, Anti-virus, Anti-spam, Web Filtering, Web Monitoring, Vulnerability Management, Anti-phishing Cloud products and vendors BlueCoat RSA TrendMicro Websense zscaler 4.3 security Table 4: Web security Services and vendors security should provide control over inbound and outbound , protecting the organization from phishing and enforcing spam prevention. Identification and non-repudiation based on digital signatures are also features provided by many security solutions. security is a protective, detective and reactive control. Services Content security, Antivirus/Anti-malware, Spam filtering, encryption, DLP for outbound , Web mail, Anti-phishing Cloud products and vendors Barracuda Networks Gmail for Domains Postini (Google Apps) McAfee Message Labs / Symantec Cloud Microsoft Cloud Services TrendMicro Zscaler Security Table 5: security Services and vendors 29

30 4.4 Security assessments Security assessments are third-party audits for the Cloudlet platform or the API framework. These services would be provided as cloud solutions. Cloud Security Alliance and other several organizations are working in guidelines to help users understand what aspects do these assessments evaluate and how conclusions should be reported. Security assessments is a detective control. Services Internal and / or external penetration test, Application penetration test, Host and guest assessments, Firewall / IPS (security components of the infrastructure) assessments, Virtual infrastructure assessment Cloud products and vendors Agiliance Core Security Modulo Qualys Veracode WhiteHat 4.5 Intrusion management Table 6: Security assessments Services and vendors Intrusion management is the process that detect and react to unauthorized access to resources. Detection is achieved by monitoring and identifying statically unusual events which occur any time an intrusion is committed. Sometimes, the system has to be reconfigured at real time to prevent or to stop an intrusion. The main challenge is managing the intrusion in multi-tenancy and virtualization scenarios. Intrusion management is a detective, protective and reactive control. Services Packet Inspection, Detection, Prevention, IR Cloud products and vendors Alert Logic Threat Manager Arbor Peakflow X Check Point - Security Gateway Virtual Edition Cloudleverage Cloud IPS/firewall Cymtec Scout eeye Digital Security Blink IBM Proventia McAfee - Host Intrusion Prevention Sourcefire - 3D System StoneGate - Virtual IPS Symantec Critical System Protection Symantec Endpoint Protection Trend Micro Deep Security Trend Micro Threat Detection Appliance TrustNet itrust SaaS Intrusion Detection XO Enterprise Cloud Security Table 7: Intrusion management Services and vendors 4.6 Security Information and Event Management It mainly refers to log management and storage. Monitoring, reports and alerts of incidents must be provided in real time. Logs could prevent manipulation in the way that they may be used as evidence in any investigation. Security Information and Event Management is a detective control. 30

31 Services Log management, Event correlation, Security/Incident response, Scalability, Log and Event Storage, Interactive searching and parsing of log data, Logs immutable (for legal investigations) Cloud products and vendors AccellOps Alien Vault (OSSIM) ArcSight ESM eiqnetworks Loglogic netforensics nfx One Novell Cloud Security Services / E-Sentinel OSSIM Prelude-SIEM Q1 Labs Quest Software RSA/EMC envision SenSage Solar Winds Log and Event Manager Splunk Table 8: Security Information and Event Management Services and vendors 4.7 Encryption Encryption functionalities should provide strong algorithms and keys only known by the intended recipients. It s a protective control. Services VPN services, Encryption Key Management, Virtual Storage Encryption, Communications Encryption, Application Encryption, Database Encryption, digital signatures, Integrity validation Cloud products and vendors Credant Cypher Cloud enstratus Novaho Perpecsys ProtectV SecureCloud SurePassID Vormetric Table 9: Encryption Services and vendors 4.8 Business continuity and disaster recovery This category refers to mechanisms ensuring the right performance of the OPENi Cloudlet platform in case of any service interruption. The purpose is to keep the end users unaware of the fact that the service has suffered from some interruption (e.g. with host mirroring). This is a reactive, protective and detective control. Services File recovery provider, File backup provider, Cold site, Warm site, Hot site, 31

32 Insurance, Business partner agreements, Replication (e.g. Databases) Cloud products and vendors Atmos Decco Digital Quantix Rackspace Parallels Table 10: 4.8 Business continuity and disaster recovery Services and vendors 4.9 Network security In a cloud or virtual environment, network security is usually provided by virtual devices along with traditional physical devices. Tight integration with the hypervisor ensures full visibility of traffic on the virtual network layer. This is the key for successful network security mechanisms. Network security is a detective, protective and reactive control. Services Firewall (perimeter and server tier), Web application firewall, DDOS protection/mitigation, DLP, IR management, IDS / IPS Cloud products and vendors CloudFlare HP IBM Imperva-Incapsula McAfee Rackspace Stonesoft Symantec Table 11: 4.9 Network security Services and vendors 4.10 Identity and access management Identity-as-a-Service is a generic term that covers one or many of the services that may include an identity ecosystem. All identity services can be provided as A single service A mixed service from multiple providers A hybrid solution of traditional Identity and Access Management and cloud services It s a protective and preventative control. Services Cloud products and vendors User centric ID provider, Federated IDs, Web SSO, Identity provider, Authorization management policy provider, Electronic signature, Device signature, User managed access Novell Cloud security service Ping Identity Symplified Conformity TriCipher Cyber-Ark software privileged identity manager Table 12: IAM Services and vendors 32

33 5 Cloudlet and OPENi API Framework Privacy Considerations 5.1 Privacy considerations for OPENi architecture Roughly speaking, privacy consists on restricting access to a determined set of information only to a limited set of individuals. Furthermore, applications and services in the cloud must comply with many different and sometimes conflicting privacy regulations. In the OPENi environment, applications developed using the API framework may access information about users stored in the Cloudlet platform. For instance, an advertising application may use information from a determined user account to elaborate a list of potential preferred products. Although, end users must keep the right to decide which entities have access to which information in his cloudlet. High-level software privacy mechanisms have to be implemented in order to enable end users to manage privacy over their cloudlets. Privacy policies govern interactions between different actors; therefore, it must be considered in all elements of the OPENi architecture. As we have said in previous chapters, the API framework will be likely delivered as SaaS while the Cloudlet platform could be exposed are SaaS, PaaS or IaaS. Depending on the chosen service models different architecture elements may be considered. Generally: Provides Consumes SaaS Information storage and management, content storage, file storage Databases, database-as-a-service, object storage, file storage, volume storage, application storage PaaS IaaS Database-as-a-Service, Hadoop, Map Reduce, Big Data-as-a-Service, application storage Raw storage, volume storage, object storage, content delivery network Databases, object storage, file storage, volume storage, other --- Table 13: Cloud elements as provider/consumer The architecture of the overall OPENi solution must specify privacy and security controls oriented to data. Cloudlet data could be personal information from end users references to retrieve such information from Cloud-based services Processes and policies are important in order to know how information is used and managed. The security data lifecycle must reflect the different needs of the security audience. A complete lifecycle consider six phases from the creation of the data until their definitive destruction. Create: generation of data Store: commit data to storage repository 33

34 Use: data is viewed and processed Share: make data accesible to others Archive: long-term storage Destroy: remove data permanently from the system Notice that not all phases are supposed to happen one after the other. Data can bounce between stages without restriction. Figure 6: Phases of data lifecycle. [Mog11] While designing an overall architecture for the OPENi environment, several factors have to be studied and considered before delivering any requirement. Location: It refers to the exact physical location where cloudlet data resides at any time. The overall data lifecycle doesn't address this aspect. In fact, regarding location the lifecycle should not be seen as a linear operation but as a series of smaller lifecycles running in different environments. It's important to understand that different regulation and jurisdictional actions are applied to data depending on its physical location. This aspects will be addressed in the Legal issues section of the deliverable. Functions: They refer to the different operations that can be done on different data regardless its origin (cloudlet or cloud-based service): Create Store Use Share Archive Destroy x X x x x x Access: create, view, copy, transfer, disseminate, exchange, etc. Process: business transaction of data, update, etc. x x Store: hold data in database, file, etc. X x Table 14: Functions over data 34

35 Actors: As we stated in the beginning of the document, the OPENi solution encompasses a Cloudlet platform and an API framework with service enablers connected to different Cloudbased Services. End users and developers use the API framework to access cloudlets and cloud- based Services. All these actors may be placed in different locations. The approach of OPENi project considers users accessing service enabler APIs through mobile devices. Mobility implies considering additional security issues regarding data-in-transit being transmitted wireless. Controls: These are the mechanisms that are implemented in order to allow or restrict actors' access to data. Control mechanisms are a crucial aspect on security driven architectures. 5.2 Privacy considerations for the Cloud Platform Identity and Access Management Controls From the point of view of users, leveraging resources to the cloud implies a loss of control over them. The trust boundary (the point where the level of trust of programs and data changes) was traditionally limited to user premises. Establishing personal cloudlets means that the trust boundary will probably move beyond the control of the users. When it comes to the matter of private or personal information this can become a serious inhibitor for cloudlet adoption. In order to strengthen risk assurance, the OPENi Cloudlet platform must enable their users to manage access control over their personal cloudets. This means that higher-level software controls have to be implemented. These controls manifest as: Digital identities: A set of data that uniquely describes a person or a thing (sometimes referred to as subject or entity) and contains information about the subject's relationships to other entities. In most theoretical and all practical models of digital identity, a given identity object consists of a finite set of properties. Despite the fact that there are many authentication systems and digital identifiers that try to address these problems, there is still a need for a unified and verified identification system in cyberspace. There are many different schemes and formats for digital identifiers. The most widely used is Uniform Resource Identifier (URI) and its internationalized counterpart Internationalized Resource Identifier (IRI). OpenID and Light-Weight Identity (LID) are two web authentication protocols that use standard HTTP URIs (often called URLs), for example. Authentication: An entity provides evidence that it holds a specific digital identity such as an identifier and the corresponding credentials. In other words, it consists of verifying the identity of a user or system (e.g. LDAP). The U.S. Government's National Information Assurance Glossary defines strong authentication as layered authentication approach relying on two or more authenticators to establish the identity of an originator or receiver of information. Authenticators are commonly based on at least one of the following four factors: o Something you know: password, PIN number. o Something you have: smart card, security token. o Something you are: fingerprint, retina, voice. o Where you are: inside or outside a company trust boundary, firewall, etc. Authorization: A particular entity is authorized to perform a given set of activities, typically inherited from authentication when logging on to an application or service. Authorization consists on determining the privileges a user or system is entitled to. There are many ways to grant access privileges to users (claim-based access control, role-based access control, etc). The typical permissions established on a system are: o Read: Access file contents and list directory contents. o Write: Create, edit, delete and rename files and directories. o Execute: Run a program. In Unix systems, the 'execute' permission doubles as a 'traverse directory' permission when granted for a directory. Delegation: If a user temporarily hand over his authorizations to another user then this process is called delegation. At authentication/identity level it consists in some sort of impersonation. It requires the delegated account password or explicit authorizations granted 35

36 by the system administrator. At authorization/access control level, the most common way of ensuring computer security is using access control mechanisms provided by operating systems such as UNIX, Linux, Windows, Mac OS, etc (e.g. sudo in Linux). Role-based access control implies risk of underdelegation, i.e. the delegator does not delegate all the necessary permissions to perform a delegated job. Auditing: Accountability or auditing uses such system components as audit trails, records and logs to associate a subject with its actions. In information or communications security, information audit means a chronological record of system activities to enable the reconstruction and examination of the sequence of events and/or changes in an event. Subjects and objects should both be considered as software entities. Audit trails and logs are important for detecting security violations and recreating security incidents. In the context of cloud-based services, auditing imply a detailed user activity monitoring to detect and prevent attacks against confidentiality and integrity. Accounting: Accounting refers to the tracking of network resource consumption by users for the purpose of capacity and trend analysis, cost allocation, billing, etc. AAA: Refers to the combination of authentication, authorization and accounting to deliver a security architecture over distributed systems. Access Control: Access control includes authorization, authentication, access approval and audit. It considers both subjects and objects as software entities. Access control models are: o Attribute-based access control (ABAC): A policy specifies which claims need to be satisfied in order to grant access to an object. For instance the claim could be "user must be older than 18 years old". Users can be anonymous as authentication and identification are not strictly required. Although, means for anonymously proving claims are required, e.g. using anonymous credentials or XACML (extensible access control markup language). o Discretionary access control (DAC): The object owner is who decides who is allowed to access the object and what privileges do they have. File and data ownership, access rights and permissions are concepts inherent to DAC. o Mandatory access control (MAC): Consists on allowing access to a resource if and only if rules exist allowing a given user to access the resource. MAC is nondiscretionary. Such rules are difficult to manage, but their use is usually justified when used to protect highly sensitive information. Some examples are: Label-based Access Control or Rule-based Access Control: access is granted by matching an object's sensitivity label a subject's sensitivity label Lattice-based Access Control (LBAC): A lattice model is a mathematical structure that defines greatest lower-bound and least upper-bound values for a pair of elements, such as a subject and an object. Involves multiple objects and subjects o Role-based access control (RBAC): Access policies are determined by the system (outside of the user's control), not by the owner. RBAC is non-discretionary. A role in RBAC can be viewed as a set of permissions. There are usually three steps: Role assignment (subject selects a role), role authorization (verify that subject is authorized to use such role) and action authorization (action is authorized for the presented subject's role). Identity Federation: A federation is an association of organizations that come together to exchange information about their users and resources to enable collaborations and transactions. A federated identity is the result of linking all the information stored across multiple identity management systems into one electronic identity and set of attributes [Mad05]. Identity federation is the best practice for dealing with loosely coupled trust relationships with third parties. Identity federation is what enables interactions of systems and applications separated by an organization trust boundary. In turn, identity federation is generally enabled by Single Sign-On. Single Sign-On (SSO): A user signing in a system using Single Sign-On access control property gains access to a set of multiple related systems without being prompted to log in again at each of them. A user's single authentication ticket, or token, is trusted across multiple systems and organizations. Single Sign-On is a subset of federated identity 36

37 management, as it relates only to authentication and is understood on the level of technical interoperability. Single Sign-On allow applications to externalize authentication features, e.g. Authentication-as-a-Service or Identity-as-a-Service. One of the main challenges of access management over clouds is the lack of central governance and identity information architecture. This distributed environment complicates orchestrated interactions over sensitive data. By implementing Identity and Access Management the OPENi Cloudlet platform solves access for distributed and changing user populations with persistence, consistence and efficiency. In order to ease integration with many different Cloud-based services and the API framework, the Cloudlet platform should support and implement well-known Identity and Access Management standards (e.g. SAML) and practices such as federation. A proper implementation of Identities and Access Management controls is also one important mean to comply with many regulations (described in Legal Issues section). For example, in order to meet compliance requirements many organizations apply practices and methodologies described in industrial frameworks like ISO and ITIL. Concerning access management, requirements include segregation of duties and assignment of limited privileges for staff members to perform such duties Towards an Identity and Access Management Architecture and Practice for the Cloudlet Platform In the last sections it has been stated that Identity and Access Management is the most convenient way to enhance privacy and access control over the Cloudlet platform. Identity an Access management consists on a collection of standard processes, best practices and technology components. Hence, is comprehensible that Identity and Access Management affects many aspects of the Cloudlet platform inner architecture. At the core of the Cloudlet platform architecture there should be a directory service acting as a repository for identities, credentials and user attributes. The directory interacts with components in charge of providing authentication, user management, provisioning and federation services supporting standard practices and processes within the Cloudlet platform. In UNIX based systems this directory could be provided via LAPD while in Windows based systems the most common technology is Active Directory. Many different layers and components are involved to deliver the following functional processes over Cloudlet platform architecture: 37

38 Figure 7: Example of Identity and Access Management functional architecture. [Mat09] Where: User Management: governance of identity life cycles Authentication Management: determination that an identity is what it claims to be Authorization Management: permission assignation to identities Access Management: making use of permission to manage access to IT resources Data Management and Provisioning: propagation of identity and data for authorization Monitoring and Auditing: reporting compliance of users regarding access to IT resources 38

39 Identities are a special kind of data that model specific entities entitled to access determined resources over the OPENi Cloudlet platform. In this case, the lifecycle must be adapted to meet the special requirements of identities. The following operational activities are directly linked to the identity lifecycle shown below: Figure 8: Identity lifecycle. [Mat09] In turn, they are supported by the functional processes described before. Provisioning and Deprovisioning: Provisioning refer to the creation and activation of identities. In turn, deprovisioning refer to the destruction of identity information as well. This last concept is important in order to prevent unauthorized access to Cloudlet resources by ghost users. Credential and Attribute Management: Attributes and credentials can be seen as another kind of data. Hence, they have their own lifecycles which involve phases of creation, issue, management and revocation. Entitlement Management: They are also referred as authorization policies. They consist of provisioning and deprovisioning of privileges. Compliance Management: Users' rights and privileges have to be monitorized in order to avoid unauthorized access to resources. Identity Federation Management: Federation consists of managing trust relationship with external entities. Centralization of Authentication and Authorization: It promotes a loosely coupled architecture where applications are agnostic to authentication and privacy policies. There are three necessary steps that should be followed in order to embed successfully identities in the OPENi Cloudlet platform architecture. 1. Establishing an authoritative source for the identity 2. Identifying the necessary user profile attributes 3. Planning and implementing an Identity Provider that supporting federation via Single Sign-On Perhaps, the most important aspect in the context of OPENi is the Identity Federation Management feature, since data will have to be shared and processed by many different service providers. Single Sign-On will help to enhance user experience: users will not be required to sign in multiple times, nor will they have to remember cloud-service-specific user authentication information. The definition, description, and management of mandatory, non-mandatory, and key attributes are necessary steps to prepare the Cloudlet platform for federation. In any case, it s strongly recommended to use widespread protocols, e.g. SAML 2.0 (de facto industry standard), WS Federation, Liberty Alliance. 39

40 5.3 Privacy for OPENi API framework and Cloud-based Services User privacy is a core feature of the Web. As the Web continues its evolution into a powerful application platform, an increasing number of its additional abilities risk compromising user privacy unless they are specifically created to promote it. This leads to a strong requirement on the OPENi API framework to take user privacy into account from the earliest steps in its conception. This, in turn, imposes design constraints that are different from those found in more traditional applications programming. Given the constant updating of privacy requirements, experience with traditional API design seldom applies and needs to be revisited. In the other hand, Cloud-based services implement their own authentication protocols that have to be understood and used by OPENi service enablers. Here we present some of the most important aspects of this area. Data Minimisation: Minimisation is a strategy that involves exposing as little information as is required for a given operation to complete. More specifically, it requires not providing access to more information than was apparent in the user-mediated access or allowing the user some control over which information exactly is provided. Poor Information Scoping: The issue here is that in providing access to the required information can sometimes entail exposing a lot more information. Device Fingerprinting: A device fingerprint, machine fingerprint or browser fingerprint is information collected about a remote computing device for the purpose of identification. Action-Based Availability: Only the minimal amount of information is provided, and even that only when it is required, otherwise there is the threat of exposing crucial data to third party. Graceful Degradation: Graceful degradation is the principle according to which a system will continue to operate at the best of its capabilities despite the fact that a given piece of functionality may be missing. For this reason, nice architectural design of the OPENi API framework should be applied at the very first steps of it and should be followed at every step of the implementation. User Mediation: An application should be allowed to occasionally punch limited holes through this protection and access relevant data in the Cloudlet platform. This should never happen without the user's express consent. Such access needs to be mediated by the user through Cloudlet platform own privacy mechanisms. Privacy-Enhancing API Patterns: Not all APIs can look the same, and no single approach can be applied automatically across the board in order to take privacy into account during API design Regarding the OPENi API framework, the subject raises three main topics: 1. Identity - who is making an API request? 2. Authentication - are they really are who they say they are? 3. Authorization - are they allowed to do what they are trying to do? As of this conversation, some of the most noteworthy policies and tactics being followed by Cloudbased services will be shortly stated (further explanations will be shown in next sections): Session-based Authentication for APIs: Authentication is kept to a single pair of API calls and everything else is based on the session, so it requires that the API client keep track of state. Session-based authentication, among other things, makes an API less RESTful - an application can t just make one HTTP request to the API framework, but at least a minimum of three. Authentication Using SSL: SSL allows client application to authenticate the identity of a server: server authentication. 40

41 Two-Way SSL: In two-way SSL authentication, the SSL client application verifies the identity of the SSL server application, and then the SSL server application verifies the identity of the SSL-client application. Authentication Using Third-Party Services: Ability to log in a specific service using credentials of another server ( facebook login ) OAuth 1.0/2.0: An open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications. Two/ Three Legged OAuth: OAuth s two/three-legged protocol is applicable whenever a client would like to access a given user s resources available on a server. SAML: Security Assertion Markup Language is an XML-based open standard data format for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider. WS-Security: WS-Security is a flexible and feature-rich extension to SOAP to apply security to web services X.509: In cryptography, X.509 is an ITU-T standard for a public key infrastructure (PKI) and Privilege Management Infrastructure (PMI). X.509 specifies, amongst other things, standard formats for public key certificates, certificate revocation lists, attribute certificates, and a certification path validation algorithm. 5.4 Standards and Protocols for Cloud Services In previous sections we have explained the impact of access control in the OPENi architecture design. Now, it s necessary to list and describe the many existing protocols and standards. These standards allow easy integration and communication with third party Cloud-based service providers. It s strongly recommended to avoid custom implementations of authentication or authorization features SAML 2.0 SAML 2.0 stands for Security Assertion Markup Language 2.0. SAML 2.0 is the result of combining the previous version of SAML with Shibboleth and Liberty ID-FF 1.2. SAML 2.0 (from now on SAML) it s a set of widely adopted standards and specification for authentication and authorization between different security domains. SAML is a XML-based protocol to pass personal information between an identity provider and a web service. When it comes to cloud computing environment SAML provides federated sign-on for users. This means that an user may access all cloud services falling within the trusted domain which could go beyond an organization s boundary. A cloud service provider (e.g. Google) may delegate authentication to an identity provided for the sake of single sign-on. This scenario can be easily described in a chronogram: 41

42 Figure 9: SSO transaction steps using SAML. [Mat09] 1. The user attempts to reach a Google application. 2. Google generates a URL pointing to the identity provider embedding: o SAML authentication request o Relay State parameter containing an encoded URL to the Google application. It s never processed. It s used as an identifier for the whole single sign-on process. 3. Google redirects the user to the identity provider. 4. The identity provider extracts the following items from the URL: o the URL for Google Assertion Customer Service (ACS) from decoded SAML authentication request o the URL to the destination (Relay State parameter) 5. The identity provider generates the SAML response containing the digitally signed authenticated user s username. 6. The identity provider returns a mechanism to the user to forward the following information to the ACS: o the SAML response o the Relay State parameter 7. The ACS verifies the SAML response using the identity provider public key associated to the user. Afterwards, the ACS redirects the user to his destination (extracted from the Relay State parameter) Before delegate authentication, some services may require from the identity provider strong authentication processes. 42

43 5.4.2 OAuth Open Authentication is an open protocol enabling standard authorization for desktop, mobile or web applications using a secure APIs. OAuth enables granting third parties temporary access to personal content without sharing credentials or other authentication information. A web application asks for credentials asks an authorization module for temporary credentials. Afterwards the user is prompted to grant access for the web application. Once this access is granted the web application receives a request token that is exchanged right after for an access token. This access token is the credential that has to be presented to access the desired resource. Notice that the so called request tokens are only good to obtain user approval while access tokens are used to access protected resources. The image below shows a sample scenario to access a Google resource SPML Figure 10: OAuth Example [Mat09] Service Provisioning Markup Language is XML-based framework that facilitates the exchange of provisioning information among applications and organizations. Provisioned resources specified in this framework include user identities. According to the OASIS Provisioning Services Technical Committee, provisioning is the automation of all the steps required to manage (setup, amend, and revoke) user or system access entitlements or data relative to electronically published services" [OAS01]. SPML helps managing synchronized provisioning workflows for distributed resources. Adoption of this standard will help organizations not to be locked into a proprietary solution XACML EXtensible Access Control Markup Language aims to be a standardized declarative language, access control method and privacy policy enforcement across many applications implementing a common authorization standard. XACML is a general policy language to protect resources and make access decisions over them. XACML also provides a model encouraging separation between the authorization 43