“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:
th
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
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
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
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
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.10 Identity and access management ... 32
5
Cloudlet and OPENi API Framework Privacy Considerations 33
5.1 Privacy considerations for OPENi architecture ... 335.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
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 ... 12Table 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
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.
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.
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.
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
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 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.
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].
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 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
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:
[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.
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.
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.
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)
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
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.
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.
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.
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:
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]
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.
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.
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
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
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.
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
