open-source, web-based, framework for integrating ... · ict-2011.1.2 cloud computing, internet of...

ICT-2011.1.2 Cloud Computing, Internet of Services & Advanced Software

Engineering, FP7-ICT-2011-8

“Open-Source, Web-Based, Framework for Integrating Applications with

Social Media Services and Personal Cloudlets”

Deliverable D2.3

Security and Privacy Considerations for Cloud-based Services and Cloudlets

Disclaimer:

The OPENi project is co-funded by the European Commission under the 7th Framework Programme. This document reflects only

authors’ views. EC is not liable for any use that may be done of the information contained therein.

Workpackage: WP2 – Use Cases Analysis and Requirements Specification

Authors: Rodrigo Illera (LOG), Susana Ortega (LOG), Michael Petychakis

(NTUA)

Status: Final

Date: 31/01/2013

Version: 1.2

Classification: Public

Ref. Ares(2013)131534 - 01/02/2013


D2.3

2

OPENi Project Profile

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

Contract No.: FP7-ICT-317883

Acronym: OPENi

Title: Open-Source, Web-Based, Framework for Integrating Applications

with Social Media Services and Personal Cloudlets

URL: www.openi-ict.eu

Start Date: 01/10/2012

Duration: 30 months

http://www.openi-ict.eu/


D2.3

3

Document History

Version Date Author (Partner) Remarks

0.1 12-17-12 Rodrigo Illera (CGI) Initial table of contents

0.2 01-09-13 Rodrigo Illera (CGI) Sections on Infrastructure Security and Identity

Management Architecture included

0.3 01-09-13 Susana Ortega (CGI) Sections on Secured Storage, Audits and Legal

Issues included

0.4 01-15-13 Michael Petychakis (NTUA) Sections on Services Privacy included

1.0 01-15-13 Susana Ortega (CGI) First draft shared with consortium members

1.1 01-30-13 Rodrigo Illera (CGI) Second draft. Feedback from reviewers included

1.2 01-31-13 Rodrigo Illera(CGI) and Susana

Ortega(CGI) Final reviewer comments addressed.


D2.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


D2.3

5

Table of Contents

1 Introduction ............................................................................ 8

1.1 Purpose and Objectives ................................................................................ 8

1.2 Methodology ................................................................................................. 8

1.3 Concepts ....................................................................................................... 8

1.4 Structure of the Document ......................................................................... 10

2 OPENi infrastructure security ............................................... 11

2.1 Network Security ........................................................................................ 13

2.1.1 Confidentiality and integrity of data-in-transit ........................................... 13

2.1.2 Network Access Control (Authentication, authorization, auditing) ............... 15

2.1.3 Availability of Internet-facing cloud-provided resources in the network ....... 15

2.2 Host security ............................................................................................... 16

2.2.1 PaaS and SaaS Host Security ................................................................... 16

2.2.2 IaaS Host Security .................................................................................. 16

2.3 Application Security .................................................................................... 17

2.3.1 Threats .................................................................................................. 18

2.3.2 Application Security of Cloud Service Models ............................................. 19

2.3.2.1 SaaS Application Security ......................................................... 19

2.3.2.2 PaaS Application Security ......................................................... 21

2.3.2.3 IaaS Application Security .......................................................... 21

3 Cloudlet Data Security and Storage ...................................... 23

3.1 Cloudlet data security ................................................................................. 23

3.2 Storage-as-a-Service .................................................................................. 24

3.3 Data Encryption .......................................................................................... 25

4 Security-as-a-Service ............................................................ 28

4.1 Data loss prevention ................................................................................... 28

4.2 Web Security ............................................................................................... 29

4.3 Email security ............................................................................................. 29

4.4 Security assessments .................................................................................. 30

4.5 Intrusion management ............................................................................... 30

4.6 Security Information and Event Management............................................ 30

4.7 Encryption ................................................................................................... 31

4.8 Business continuity and disaster recovery ................................................. 31

4.9 Network security......................................................................................... 32


D2.3

6

4.10 Identity and access management ............................................................... 32

5 Cloudlet and OPENi API Framework Privacy Considerations 33

5.1 Privacy considerations for OPENi architecture ........................................... 33

5.2 Privacy considerations for the Cloud Platform ........................................... 35

5.2.1 Identity and Access Management Controls ................................................ 35

5.2.2 Towards an Identity and Access Management Architecture and Practice for

the Cloudlet Platform .................................................................................... 37

5.3 Privacy for OPENi API framework and Cloud-based Services .................... 40

5.4 Standards and Protocols for Cloud Services ............................................... 41

5.4.1 SAML 2.0 ................................................................................................ 41

5.4.2 OAuth .................................................................................................... 43

5.4.3 SPML ...................................................................................................... 43

5.4.4 XACML ................................................................................................... 43

5.4.5 OpenID .................................................................................................. 44

5.4.6 OATH ..................................................................................................... 44

5.4.7 Open AM (formerly known as Open SSO) ................................................. 44

5.4.8 Diameter/RADIUS ................................................................................... 44

5.4.9 Summary ................................................................................................ 45

6 Available Frameworks ........................................................... 46

7 Data Privacy and Legal Issues .............................................. 47

8 Cloudlet Audit and Compliance ............................................. 48

8.1 Audit Standards .......................................................................................... 48

8.1.1 SAS 70 ................................................................................................... 48

8.1.2 ISO 27001 .............................................................................................. 49

8.1.3 HIPPA (US) ............................................................................................. 49

8.1.4 Other desiderable Standards .................................................................... 50

9 Conclusions and Recommendations ...................................... 51

Annex I: References .................................................................... 52


D2.3

7

List of Figures

Figure 1: Cloudlet Platform Architecture. ........................................................................................ 9

Figure 2: API Framework Architecture. ........................................................................................... 9

Figure 3: OPENi environment ....................................................................................................... 11

Figure 4:Symmetric encryption. ................................................................................................... 26

Figure 5: Asymmetric encryption. ................................................................................................. 26

Figure 6: Phases of data lifecycle. ................................................................................................ 34

Figure 7: Example of Identity and Access Management functional architecture. .............................. 38

Figure 8: Identity lifecycle. .......................................................................................................... 39

Figure 9: SSO transaction steps using SAML. ................................................................................ 42

Figure 10: OAuth Example ........................................................................................................... 43

List of Tables

Table 1: Responsabilities in OPENi architecture ............................................................................. 12

Table 2: Data security issues and solutions ................................................................................... 23

Table 3: Data loss prevention Services and vendors ...................................................................... 29

Table 4: Web security Services and vendors ................................................................................. 29

Table 5: Email security Services and vendors ................................................................................ 29

Table 6: Security assessments Services and vendors ..................................................................... 30

Table 7: Intrusion management Services and vendors ................................................................... 30

Table 8: Security Information and Event Management Services and vendors .................................. 31

Table 9: Encryption Services and vendors ..................................................................................... 31

Table 10: 4.8 Business continuity and disaster recovery Services and vendors ............................. 32

Table 11: 4.9 Network security Services and vendors ................................................................. 32

Table 12: IAM Services and vendors ............................................................................................. 32

Table 13: Cloud elements as provider/consumer ........................................................................... 33

Table 14: Functions over data ...................................................................................................... 34

Table 15: Summary of IAM protocols and standards ...................................................................... 45

Table 16: Evaluation of Service Models for OPENi Cloudlet Platform ............................................... 51


D2.3

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 “as-

a-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.


D2.3

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, Cloud-based 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


D2.3

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.


D2.3

11

2 OPENi infrastructure security

OPENi solution comprises two main elements:

API framework: A set of service enablers exposing an abstraction of many different cloud-

based 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:

Responsibility faced as cloud provider

Responsibility faced as cloud user

API framework The API framework must ensure the

exposed interfaces are secured, this is, all methods have to be protected

against potential attacks at application level.

The API framework must ensure the

provider has considered all security measures.

Cloudlet

platform

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

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


D2.3

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 on-

premises 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 on-

demand 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.


D2.3

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.

2.1.1 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)


D2.3

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-in-the-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].


D2.3

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 request-response 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.

2.1.2 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 network-

level 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.

2.1.3 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].


D2.3

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.

2.2.1 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.

2.2.2 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


D2.3

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


D2.3

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.

2.3.1 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


D2.3

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-of-service 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.

2.3.2 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.

2.3.2.1 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.


D2.3

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 128-256 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.


D2.3

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.

2.3.2.2 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 platform-

specific 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.

2.3.2.3 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


D2.3

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.


D2.3

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-in-

transit 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.


D2.3

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) 5220.22-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


D2.3

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 email service, but it can be applied to many

other ambits. Given its computational simplicity, symmetric encryption is appropriate for data-at-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.


D2.3

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.


D2.3

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.


D2.3

28

4 Security-as-a-Service

The chapter titled OPENi infrastructure security described security mechanisms at low level (network-

level, 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 emailing 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


D2.3

29

Cloud products and

vendors

BlueCoat IBM

Imperva Oracle

Reconnex RSA

Symantec/Vontu

WebSens Zscaler

Table 3: Data loss prevention Services and vendors

4.2 Web Security

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 Email Server, Anti-virus, Anti-spam, Web Filtering, Web Monitoring, Vulnerability Management, Anti-phishing

Cloud products and

vendors

BlueCoat

RSA

TrendMicro Websense

zScaler

Table 4: Web security Services and vendors

4.3 Email security

Email security should provide control over inbound and outbound email, protecting the organization

from phishing and enforcing spam prevention. Identification and non-repudiation based on digital signatures are also features provided by many email security solutions. Email security is a protective,

detective and reactive control.

Services Content security, Antivirus/Anti-malware, Spam filtering, Email encryption, DLP

for outbound email, 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 Email Security

Table 5: Email security Services and vendors


D2.3

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

Table 6: Security assessments Services and vendors

4.5 Intrusion management

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.


D2.3

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,


D2.3

32

Insurance, Business partner agreements, Replication (e.g. Databases)

Cloud products and vendors

Atmos Decco

Digital Parallels

Quantix Rackspace

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 User centric ID provider, Federated IDs, Web SSO, Identity provider, Authorization management policy provider, Electronic signature, Device signature, User

managed access

Cloud products

and vendors

Novell Cloud security service

Ping Identity

Symplified

Conformity

TriCipher

Cyber-Ark software privileged identity manager

Table 12: IAM Services and vendors


D2.3

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 Database-as-a-Service, Hadoop, Map Reduce,

Big Data-as-a-Service, application storage

Databases, object storage, file storage, volume

storage, other

IaaS

Raw storage, volume storage, object storage, content delivery network

---

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


D2.3

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

Access: create, view, copy, transfer,

disseminate, exchange, etc.

x X x x x x

Process: business transaction of data, update, etc.

x x

Store: hold data in database, file, etc.

X x

Table 14: Functions over data


D2.3

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 Cloud-based 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

5.2.1 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


D2.3

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 non-

discretionary. 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


D2.3

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 27002 and ITIL. Concerning access management, requirements include “segregation of duties” and assignment of limited privileges for staff members to perform such duties.

5.2.2 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:


D2.3

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


D2.3

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.


D2.3

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 Cloud-

based 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.


D2.3

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.

5.4.1 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:


D2.3

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.


D2.3

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.

Figure 10: OAuth Example

[Mat09]

5.4.3 SPML

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.

5.4.4 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


D2.3

44

decision from the point of use. Besides a request/response protocol is specified in XACML to establish communication between the application environment (the point of use) and the decision point.

In other words, XACML manages specific access requests. The result of evaluating using determined

privacy policies is returned to the user as the response of his request.

5.4.5 OpenID

OpenId is an open decentralized standard enabling users to authenticate to websites or services with the same digital identity. OpenID is mainly targeted to consumer services offered by Internet

companies. Users may create accounts with their preferred OpenID identity providers. From that

moment on, these accounts are used to sign on into any website accepting OpenID authentication. OpenID adoption for enterprise use is almost non-existent due to trust issues. Furthermore, some

researchers have revealed that OpenID could accelerate phishing attacks that can result in compromised user credentials.

5.4.6 OATH

Many industry leaders are collaborating together in this initiative for Open Authentication. Their

purpose is to promote the adoption of a standard architecture for strong authentication. Three

widespread authentication methods are considered: SIM-based authentication (Subscriber Identity Module), PKI-based authentication (Public Key infrastructure) and OTP-based authentication (One-

Time Password).

5.4.7 Open AM (formerly known as Open SSO)

The project Open AM is the continuation of the Sun Microsystems' OpenSSO product after Oracle acquiring of Sun. It provides a set of different software products like ForgeRock OpenAM which is a

web-based open source application that provides Authentication, Authorization, Entitlement and

Federation services.

Open AM provides core identity services to simplify the implementation of transparent Single Sign-On (SSO) as a security component in a network infrastructure. OpenAM provides the foundation for

integrating diverse web applications. Using Open AM such web applications can:

operate against a disparate set of identity repositories

be hosted on a variety of platforms such as web and application servers

5.4.8 Diameter/RADIUS

Diameter and RADIUS are two networking protocols providing AAA. RADIUS is a protocol for carrying authentication, authorization, and configuration information between a Network Access

Server which desires to authenticate its links and a shared Authentication Server. RADIUS is a client/server protocol that runs in the application layer, using UDP as transport. It's used to

authenticate users or devices before granting them access to a network, to authorize those users or

devices for certain network services and to account for usage of those services [Rig00].

Diameter is the natural evolution of RADIUS (in fact, the name was chosen because the diameter is twice the radius). Diameter base protocol is intended to provide an Authentication, Authorization and

Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is not directly backwards compatible but provides an upgrade path for RADIUS [Cal03].


D2.3

45

5.4.9 Summary

IAM protocols

and standards

Cloud User requirements Cloud Platform requirements

SAML To support strong authentication and

web SSO, avoid duplication of identity, and share only selected

attributes to protect user privacy

To enable customers to delegate

authentication and choose authentication methods (e.g., dual-factor

authentication using corporate identity)

that enable adoption of the cloud service

OAuth To publish and interact with protected

data stored on one Cloud Platform and accessed from another Cloud

Platform using a standard API and

without disclosing credentials

To enable users to access their data

hosted by another service provider while protecting their account and credential

information

OpenID Not usually adopted due to trust

issues

To support SSO for consumers

participating in this federated identity

service

OATH Not relevant Not relevant

Open AM To support authentication and

authorization. Integrating diverse web applications.

Web applications can be hosted on a

variety of platforms

Diameter/RADIUS AAA: Authentication, authorization and accounting.

To enable control over which users are allowed access to which services, and

how much of the resources they have

used

Table 15: Summary of IAM protocols and standards


D2.3

46

6 Available Frameworks

The European Commission has evinced a special interest on reinforcing security and privacy over the Web. In fact, the Seventh Research Framework Programme contemplates objectives addressing

explicitly reliable, smart and secure Internet of Things and trustworthy information and communication technologies. OPENi could use some of the publicly available frameworks provided as

outcomes of this projects, as well as learn from the conclusions and lessons derived.

Regarding security, so far the most relevant Seventh Framework Programme projects have been:

TCLOUDS: The mission of TCLOUDS is to develop an advanced cloud infrastructure that can

deliver computing and storage that achieves a new level of security, privacy, and resilience

yet is cost-efficient, simple, and scalable. [Tcl13]

TRESSCA: The TRESCCA project aims to lay the foundations of a secure and trustable cloud

platform by ensuring strong logical and physical security on the edge devices, using both hardware security and virtualization techniques while considering the whole cloud

architecture. The project proposes and demonstrates hardware/software solutions allowing stakeholders to delegate the processing of their sensitive data to a remote processing engine

opening up whole new field of cloud services and applications [Tre13] CUMULUS: CUMULUS addresses these limitations by developing an integrated framework of

models, processes and tools supporting the certification of security properties of infrastructure (IaaS), platform (PaaS) and software application layer (SaaS) services in cloud.

CUMULUS framework brings service users, service providers and cloud suppliers to work together with certification authorities in order to ensure security certificate validity in the

ever-changing cloud environment.[Cum13]

Some relevant Seventh Framework Programme projects on privacy and identities are:

PICOS: an open state-of-the-art platform for providing trust, privacy and identity management in mobile communities [Pic13].

PrimeLife: develop concepts and technologies to help individuals to protect their autonomy

and retain control over personal information, irrespective of their activities. Several open

source results [Pri13]. SWIFT: It focuses on extending identity functions and federation to the network while

addressing usability and privacy concerns [Swi13].

Besides, other organizations and institutions have released open powerful open frameworks on

privacy and security. Some of them are:

Apache Cocoon: is a flexible module for authentication, authorization and user management

[Coc13].

Apache Shiro: powerful and easy-to-use Java security framework that performs

authentication, authorization, cryptography, and session management [Shi13]. Spring Security: powerful and highly customizable authentication and access-control

framework [Spr13].


D2.3

47

7 Data Privacy and Legal Issues

The concept of OPENi cloudlets involves managing personal information in some cloud infrastructure. This approach rises many legal issues that have to be considered, specifically those around how

cloudlet data are collected, stored and processed. Please notice that the physical location of storage and computing resources of the Cloudlet platform may vary, and may not necessary be under the

same jurisdiction. Awareness must be drawn to the many existing national and international laws for

sake of legal compliance. These laws will reference to where the data are stored as well as the data protection from a confidentiality aspect.

Legislation makes fundamental distinction between data processor and data controller (as party that

defines the purpose and the means of the processing). European laws are substantially more

restrictive than the ones applied in other countries, particularly the United States. One of the most important principles around the European legislation is that data are not transferrable to countries

outside the European boundaries that don’t offer the “adequate level of protection”. In fact, only Switzerland, Argentina and Canada meet the European requirements for such information exchange.

Although, this legislation is not consistent with the philosophy of Cloud Computing. However, many cloud computing providers are deploying data centres inside Europe boundaries in order to achieve

legal compliance. For example, many vendors like Amazon EC2 allow their users to choose the zone

where their resources will be allocated, and therefore the legislation applied to their data.

The seven principles governing the Organisation for Economic Co-operation and Development’s recommendations for protection of personal data were [OEC13]:

Notice — whenever data is about to be collected, the user should be notified if he agrees or not.

Security — any collected data should be stored carefully in order to be protected from any harmful purposes.

Purpose — the data that is received should only be used for the purpose pre-agreed and not

for any other reason. Consent — data should not be disclosed without the data subject’s consent;

Disclosure — it should be clear, who is the one collecting the corresponding data. Access — data subjects should be allowed to access their data and make corrections to any

inaccurate data;

Accountability — anyone providing data should have a method available to them to hold data collectors accountable for following the above principles.

In Europe and the countries of the OPENi consortium the following laws are currently in force:

EU Directive 95/46/EC: is the reference text, at European level, on the protection of

personal data. It sets up a regulatory framework which seeks to strike a balance between a

high level of protection for the privacy of individuals and the free movement of personal data within the European Union. To do so, the Directive sets strict limits on the collection and use

of personal data and demands that each Member State set up an independent national body responsible for the protection of these data [Eur11] [Eur95] .

National transpositions#:

o Germany: Federal Data Protection Act (Bundesdatenschutzgesetz -BDSG) 2001

o Greece: Law 2472/1997 on the Protection of Individuals with regard to the Processing of Personal Data - as amended by Laws 2819/2000 and 2915/2000

o Ireland: Data protection act 1998 o Spain: Organic Law 15/1999 on the Protection of Personal Data. (LOPD)

o UK: Data protection act 1998


D2.3

48

8 Cloudlet Audit and Compliance

Audit and compliance refer to the external and internal processes that an organization implements to:

1. identify all kind of requirements to be fulfilled 2. put into practice policies, procedures, systems and processes to satisfy such requirements

3. check or monitor whether the above mechanisms are satisfied.

OPENi users usually will require external audits from the OPENi solution to verify its security and

privacy controls. As we have stated in the previous section, management of sensitive information is subject to different legal issues. A simple way to ensure compliance with regulations is ask a valid

third party to perform some of the standardized audits described below.

8.1 Audit Standards

8.1.1 SAS 70

The acronym stands for Statement on Auditing Standards 70 (SAS 70). It’s an internationally

accepted auditing standard, developed by AICPA13 (American Institute of Certified Public Accountants). It emerged in response to a growing trend of outsourcing services. Companies have to

be able to trust third parties accessing their information; and the other way round: data provided by

third parties have to be trustworthy. Many organization expressed a strong concern to maintain compliance with Sabarnes Oxley law and other regulations and laws. Notice that in a cloud computing

scenario, data may be off-site and can not be audited directly. As a result, audit firms provide SAS 70 certification, which consists in a centralized revision by and auditor, non dependent of the outsourcing

services. An organization holding a SAS 70 certification demonstrates compliance with all current data

protection regulations.

Organizations that successfully complete SAS 70 audit have passed an in-depth study of their control activities, including controls over IT resources and related processes. Hence, it allows companies to

provide and external certification about their internal control to their customers. Data centers fulfilling

SAS 70 certification, have to maintain prescribed levels of data security and redundancy, as well as staff controls.

These requirements include reports about:

firewall settings and access

database access

data transmission

data backup and recovery

application security

product development

All access and activities are registered and all physical accesses are highly controlled. Moreover, data

center staff are not allowed to access servers or data without a specific protocol, either by accomplishing a successful authentication process or any other security mechanism.

SAS 70 certification provides an important strategic advantage to outsourcers over the ones who

don’t own one. Furthermore, it is cost-saving for customers, as they don’t have to perform resource

allocation and processes documentation themselves.

According to SAS 70, there are two report types. The main difference between them is the depth and completeness of applied procedures:

SAS 70 type I:. The auditor is presented the security controls and mechanisms as well as a

detailed description of the objectives addressed by such mechanisms. Afterwards, the auditor


D2.3

49

makes sure that these controls exist and reviews them. Then, the auditor expresses an opinion on whether description of control objectives shows all the relevant aspects, and

whether controls have been properly designed to achieve such objectives above. At the end a report is issued describing current security controls at a specific date and bear witness that

such controls exist and that they cover the addressed risks.

SAS 70 type II: It’s a deeper version of SAS 70 Type I. It describes current controls and

detailed tests applied on this controls’ efficiency. Controls are tested no less than six months

in order to assess their behaviour in that period. The auditor plays the same role as is SAS 70 Type I. But additionally, the auditor provides his expert opinion about effectiveness of

controls to achieve compliance with objectives. Organizations should pass a SAS 70 type II review at least once a year.

Initially, SAS 70 was designed as a way to to support the financial audits of customers contracting a cloud service. Given the success of SAS 70, the audit was later applied to other domains less sensitive

than the financial one. Nowadays, SAS 70 is usually applied when a cloud service provider plays a significant role in transaction, processing or financial reporting in their consumers business model.

8.1.2 ISO 27001

ISO 27001 is the best known standard for information security. It was approved and published in October 2005 by the International Organization for Standardization (ISO) and the International

Electrotechnical Commission. It’s predecessor was the BS 7799-2:2000 standard by the British Standards Institution (BSI). ISO 27001 specifies necessary requirements to establish, implement,

maintain and improve a Management System of Information Security based on the PDCA Cycle

(Plan-Do-Check-Act). This approach is compliant with the best practices shown at ISO/IEC 17799 (the current ISO 27002).

ISO 27001 address the following objectives:

Security policy of the organization

Security infrastructure, security of third-party access and outsourcing.

Asset classification and control

Staff safety referring to:

o security in the job definition and resource allocation, o worker training and response to incident and security anomalies

Physical and environmental safety

Communications and operations management

Accesses control

Systems development and maintenance

Business continuity Management

Legal requirements, security policy, system audit, etc. fulfilment

Fulfilment of legal requirements, security policy, system audit, etc.

ISO 27001 was designed to provide a mechanism for organizations to demonstrate that they have

an adequate information security management system. It’s much like ISO 9001 is used to demonstrate that organizations have quality management systems in place. ISO 27001 certification is

generally applied when global customers and prospects seek comfort with the cloud service provider

overall security program.

8.1.3 HIPPA (US)

The Health Insurance Portability and Accountability Act of 1996 was enacted by the United States Congress in 1996. Title II of HIPAA, known as the Administrative Simplification (AS) provisions,

requires the establishment of national standards for electronic healthcare transactions and

national identifiers for providers, health insurance plans, and employers. #


D2.3

50

8.1.4 Other desiderable Standards

There are other standards which could be applied by Cloud Services Suppliers. ISO 27002, 27003,

27004, 27005, 27006, 29361, 29361 and 29363 are standards oriented to security at information systems area and interoperability of web services. Furthermore, ISO has created subcommittee 38 to

work on standardization of web services, service oriented architectures and and Cloud Computing.


D2.3

51

9 Conclusions and Recommendations

As a result of task "T2.3 Security and Privacy considerations" this deliverable reflects the outcome of having analysed several publications, papers, articles and book chapters. A general set of

considerations for the OPENi solution has been derived from a state-of-the-art on privacy and security on cloud computing.

The OPENi Cloudlet platform is the most delicate component of the environment because it stores sensitive information about end users. It also manages access to users' contracted Cloud-based

services registered in the Cloudlet platform. It's not clear which service model will be used to expose the Cloudlet platform to the API framework:

Advantages Disadvantages

IaaS: It implies providing end

user wide access to Cloudlet

platform infrastructure. Accessed resources include

operative systems and information.

The Cloudlet platform and

infrastructure are extremely

flexible, and they can be adapted to any business

network need

As IaaS provider, the Clouldet

platform vendor must provide

users mechanisms to implement security not only at

application-level, but at network-level and host-level

PaaS: It implies end users

having the ability not only to store information in the

Cloudlet platform, but to deploy

and run applications

The Cloudlet platform provides

all required functionalities to the end user in a way that he's

not required to be aware of

low-level infrastructure security mechanisms

Limited monitoring capability is

offered to users. Some audit may be required to ensure the

Cloudlet platform is secure.

SaaS: End users are just offered applications running on

the cloud infrastructure.

Users are fully agnostic regarding security mechanisms

Some functionalities like cloudlet storage and registry

may not be able to implement

under this service model

Table 16: Evaluation of Service Models for OPENi Cloudlet Platform

It's up to future tasks of OPENi project to decide which option is the best based on the requirements delivered by "T2.5 Requirements Specification" and the considerations provided in this document.

However, previous analysis evidence that PaaS is the most proper delivery model for the Cloudlet platform.

Another decision that falls out of the scope of task "T2.3 Security and Privacy Considerations" is whether the Cloudlet platform has to be deployed into its owner’s premises or into a contracted cloud

infrastructure. Along the document, both options have been discussed. The first one implies the Cloudlet platform owner to take care of security at all infrastructure levels. The second option implies

relying these aspects to the cloud provider. A periodic payment may be demanded in exchange of

such service. Not only hosting of the Cloudlet platform can be relied on a external cloud provider: several vendors offer Security-as-a-Service (SecaaS) which lets the Cloudlet platform legate many

security mechanisms. In any case compliance to standards prevent future issues in case of migration from one cloud vendor to another.

The Cloudlet platform and the API framework have to provide end users capabilities to manage

privacy over personal data. But in turn, applying regulations and legislation must be observed at any

time. Some standardised audits ensure that such legal requirements are met. One of the approaches that meets an agreement between access control flexibility and confidentiality requirements is

Identity and Access Control Management (IAM). IAM enhanced with Identity federation enables easy interaction and collaboration between Cloud-based services. There are many standard protocols

available, but SAML 2.0 seems to fit better for OPENi purposes.


D2.3

52

Annex I: References

[Mat09] T. Mather, S Kumaraswamy, S. Latif “Cloud Security and Privacy. An Enterprise Perspective on Risks

and Compliance”. O’Reilly. ISBN 978-0-5-596-802769. 2009

[Ssl11]

A. Freier, P. Karlton P. Kocher "The Secure Sockets Layer (SSL) Protocol Version 3.0" Internet Engineering Task Force (IETF). ISSN: 2070-1721. August 2011

http://tools.ietf.org/html/rfc6101

[Tls08]

T. Dierks, E. Rescorla "The Transport Layer Security (TLS) Protocol Version 1.2" Network Working Group. August 2008.


[Kan08] E. Kangas "SSL versus TLS – What’s the difference?" luxsci.com. November 10th, 2008. Retrieved

December 2012.

http://luxsci.com/blog/ssl-versus-tls-whats-the-difference.html

[Sft06] J. Galbraith, O. Saarenmaa "SSH File Transfer Protocol" (Internet-Draft) Secure Shell Working Group.

July 10, 2006

http://tools.ietf.org/html/draft-ietf-secsh-filexfer-13

[Ips11] S. Frankel, S. Krishnan "IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap"

Internet Engineering Task Force (IETF). ISSN:2070-1721. February 2011

https://tools.ietf.org/html/rfc6071

[Wyl11] J. Wylkop "RUB Researchers break W3C standard. XML Encryption is insecure: Large companies

affected" Press Office Ruhr University Bochum. No. 330 - Bochum, 19.10.2011

http://aktuell.ruhr-uni-bochum.de/pm2011/pm00330.html.en

[Ima02] T. Imamura, B.Dillaway, E. Simon "XML Encryption Syntax and Processing" W3C Recommendation. 10

December 2002

http://www.w3.org/TR/xmlenc-core/

[Res99] E. Rescorla, A. Schiffman "The Secure HyperText Transfer Protocol". Network Working Group. August

1999


[CSA11]

Cloud Security Alliance “Security as a Service” Version 1.0. 2011

https://cloudsecurityalliance.org/research/secaas/

[Zha07] Z. Zhang, Y. Zhang, Y. Hu, Z. Mao "Practical defenses against BGP prefix hijacking" Proceeding

CoNEXT '07 Proceedings of the 2007 ACM CoNEXT conference. Article No. 3. 2007



http://luxsci.com/blog/ssl-versus-tls-whats-the-difference.html

http://tools.ietf.org/html/draft-ietf-secsh-filexfer-13

https://tools.ietf.org/html/rfc6071

http://aktuell.ruhr-uni-bochum.de/pm2011/pm00330.html.en

http://www.w3.org/TR/xmlenc-core/


https://cloudsecurityalliance.org/research/secaas/


D2.3

53

http://web.eecs.umich.edu/~zmao/Papers/conextDefendHijack07.pdf

[CSA11_2] Cloud Security Alliance “Security Guidance for critical areas on focus in Cloud Computing v3.0”. 2011

[Win12]

V. Winkler “Cloud Computing: Virtual Network Security Concerns” Technet Magazine, Microsoft.

Retrieved 12 February 2012.

http://technet.microsoft.com/en-us/magazine/hh641415.aspx

[Mel11]

P. Mell, T. Grance “The NIST Definition of Cloud Computing” NIST 800-145. 2011

http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf

[Hic12] K. Hickey. "Dark Cloud: Study finds security risks in virtualization". Government Security News.

Retrieved 12 February 2012.

http://gcn.com/articles/2010/03/18/dark-cloud-security.aspx

[Rut09] R. Wojtczuk; J. Rutkowska. "Attacking Intel® Trusted Execution Technology" Black Hat DC, February

18-19, 2009. Washington, DC, USA.

http://www.blackhat.com/presentations/bh-dc-09/Wojtczuk_Rutkowska/BlackHat-DC-09-Rutkowska-

Attacking-Intel-TXT-slides.pdf

[Ylo06]

T. Ylonen "The Secure Shell (SSH) Authentication Protocol". Network Working Group RFC 4252. January 2006


[Owa10]

"OWASP Top 10 - 2010. The Ten Most Critical Web Application Security Risks" OWASP. Creative Commons Attribution Share-a-Like.

http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010.pdf

[Mad05]

P. Madsen "Liberty ID-WSF People Service – federated social identity" Liberty Alliance Project White Paper. December 5, 2005

http://www.projectliberty.org/liberty/content/download/387/2720/file/Liberty_Federated_Social_Identity.pdf

[Mog11] R. Mogull "Data Security Lifecycle 2.0". Securosis. September 2011.

http://www.securosis.com/blog/data-security-lifecycle-2.0

[Eur11]

Europa.eu "EUROPA. Summaries of EU legislation. Information society. Data protection, copyright and

related rights". February 2011

http://europa.eu/legislation_summaries/information_society/data_protection/l14012_en.htm

[Eur95]

http://web.eecs.umich.edu/~zmao/Papers/conextDefendHijack07.pdf

http://technet.microsoft.com/en-us/magazine/hh641415.aspx

http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf

http://gcn.com/articles/2010/03/18/dark-cloud-security.aspx

http://www.blackhat.com/presentations/bh-dc-09/Wojtczuk_Rutkowska/BlackHat-DC-09-Rutkowska-Attacking-Intel-TXT-slides.pdf

http://www.blackhat.com/presentations/bh-dc-09/Wojtczuk_Rutkowska/BlackHat-DC-09-Rutkowska-Attacking-Intel-TXT-slides.pdf


http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010.pdf



http://www.securosis.com/blog/data-security-lifecycle-2.0

http://europa.eu/legislation_summaries/information_society/data_protection/l14012_en.htm


D2.3

54

“Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of

such data”

http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:en:HTML

[DoD06]

“DoD 5220.22-M, National Industrial Security Program Operating Manual”. February 28, 2006.

[OAS01]

“DRAFT. An Introduction to the Provisioning Services Technical Committee” . OASIS. 2001

http://xml.coverpages.org/PSTC-Intro-102301.pdf

[OEC13] OECD "OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data"

Retrieved on January 2013.

http://www.oecd.org/internet/interneteconomy/oecdguidelinesontheprotectionofprivacyandtransborde

rflowsofpersonaldata.htm

[Cal03]

P. Calhoun, J. Loughney, E. Guttman, G. Zorn, J. Arkko "RFC 3588. Diameter Base Protocol" Network Working Group. September 2003


[Rig00]

C. Rigney, S. Willens, A. Rubens, W. Simpson "RFC 2865. Remote Authentication Dial In User Service (RADIUS)" Network Working Group. June 2000


[Pic13]

PICOS - Privacy and Identity Management for Community Services

http://www.picos-project.eu/

[Pri13]

PrimeLife - Bringing sustainable privacy and identity management to future networks and services

http://primelife.ercim.eu/

[Swi13] SWIFT - Secure Widespread Identities for Federated Telecommunications

http://www.ist-swift.org/

[Shi13]

Apache Shiro

http://shiro.apache.org/

[Coc13]

Apache Cocoon

http://cocoon.apache.org/

[Spr13] Spring Security

http://static.springsource.org/spring-security/site/

[Pci13]

http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:en:HTML

http://xml.coverpages.org/PSTC-Intro-102301.pdf

http://www.oecd.org/internet/interneteconomy/oecdguidelinesontheprotectionofprivacyandtransborderflowsofpersonaldata.htm

http://www.oecd.org/internet/interneteconomy/oecdguidelinesontheprotectionofprivacyandtransborderflowsofpersonaldata.htm



http://www.picos-project.eu/

http://primelife.ercim.eu/

http://www.ist-swift.org/

http://shiro.apache.org/

http://cocoon.apache.org/

http://static.springsource.org/spring-security/site/


D2.3

55

Payment Card Industry Security Standards Council "The basics of PCI compliance and validation regulations" PCI Comliance Guide. Guide to PCI Data Security Standards. Retrieved January 2013

http://www.pcicomplianceguide.org/pci-basics.php

[Tcl13]

TCLOUDS: Trustworthy Clouds Privacy and Resilience for Internet-scale Critical Infrastructure.

http://www.tclouds-project.eu/

[Tre13]

TRESSCA TRustworthy Embedded systems for Secure Cloud Computing Applications http://www.trescca.eu/

[Cum13]

CUMULUS: Certification infrastrUcture for MUlti-Layer cloUd Services

http://cordis.europa.eu/search/index.cfm?fuseaction=proj.document&PJ_RCN=13156501

[OPE12]

OPENi: Open-Source, Web-based, Framework for integrating Applications with social media services and personal Cloudlets

http://www.pcicomplianceguide.org/pci-basics.php

http://www.tclouds-project.eu/

http://www.trescca.eu/

http://cordis.europa.eu/search/index.cfm?fuseaction=proj.document&PJ_RCN=13156501

open-source, web-based, framework for integrating ... · ict-2011.1.2 cloud computing, internet of...

Documents