Thiago Gomes Rodrigues
CLOUDACC: A CLOUD-BASED ACCOUNTABILITY FRAMEWORK
FOR FEDERATED CLOUD
Ph.D. Thesis
Federal University of Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao
RECIFE 2016
Thiago Gomes Rodrigues
CLOUDACC: A CLOUD-BASED ACCOUNTABILITY FRAMEWORK
FOR FEDERATED CLOUD
A Ph.D. Thesis presented to the Center for Informatics of Federal University of Pernambuco in partial fulfillment of the requirements for the degree of Philosophy Doctor in Computer Science.
Advisor: Judith Kelner Co-Advisor: Patricia Takako Endo
RECIFE 2016
Catalogação na fonte
Bibliotecário Jefferson Luiz Alves Nazareno CRB 4-1758
R696c Rodrigues, Thiago Gomes.
Cloudacc: a cloud-based accountability framework for federated cloud/ Thiago Gomes Rodrigues – 2016.
103f.: fig., tab.
Orientadora: Judith Kelner
Tese (Doutorado) – Universidade Federal de Pernambuco. CIn. Ciência da Computação, Recife, 2016.
Inclui referências e apêndice.
1. Computação em nuvem. 2. Responsabilidade (Direito). 3. Proteção de dados. I. Kelner, Judith (Orientadora). II. Titulo.
Thiago Gomes Rodrigues
CloudAcc: A Cloud-based Accountability Framework for Federated
Cloud
Tese de Doutorado apresentada ao Programa de Pós-Graduação em Ciência da Computação da Universidade Federal de Pernambuco, como requisito parcial para a obtenção do título de Doutora em Ciência da Computação.
Aprovado em: 08/09/2016.
___________________________________________ Orientadora: Profa. Dra. Judith Kelner
BANCA EXAMINADORA
_____________________________________________ Prof. Dr. Ruy José Guerra Barretto de Queiroz
Centro de Informática / UFPE
______________________________________________ Prof. Dr. Eduardo Luzeiro Feitosa
Instituto de Computação / UFAM
_____________________________________________ Prof. Dr. Arthur de Castro Callado
Universidade Federal do Ceará / Campus Quixadá ______________________________________________
Prof. Dr.Rafael Roque Aschoff
Instituto Federal de Pernambuco / Campus Palmares _____________________________________________
Prof. Dr. Carmelo Jose Albanez Bastos Filho Escola Politécnica de Pernambuco / UPE
I dedicate this thesis to all my family, friends and professors who gave me the necessary support to get here.
Acknowledgements
Firstly, I would like to thank my family for all support they gave me during the writing of this Thesis. I know the lack I made during the weekends that I had to work just as you did to me, and you have understood and supported me, thank you.
I also want to thank my advisors for everything they did for me during all these years. Professors Dr. Judith Kelner, Dr. Djamel Sadok, and Dr. Patricia Endo, thank you for believing me, for giving me all resources and knowledge used in this thesis.
For my friends, I would like to thank you to listen to me every time talking about my Thesis, implementation, security, writing and so on. Thank you for all encouragement words, constructive and funny conversations.
I also would like to thank all GPRT (Network and Telecommunication Research Group) and GRVM (Virtual Reality & Multimedia Research Group) team members, for all support that you gave me.
The world ain’t all sunshine and rainbows. It’s a very mean and nasty place and I don’t care how tough you are it will beat you to your knees and keep you there permanently if you let it. You, me, or nobody is gonna hit as hard as life. But it ain’t about how hard you hit. It’s about how hard you can get hit and keep moving forward. How much you can take and keep moving forward. That’s how winning is done! Now if you know what you’re worth then go out and get what you’re worth. But you gotta be willing to take the hits, and not pointing fingers saying you ain’t where you wanna be because of him, or her,
or anybody! Cowards do that and that ain’t you! You’re better than that! —ROCKY BALBOA
Resumo
A maneira de realizar accountability tem variado à medida em que o modo de entrega de serviços de Tecnologia da Informação (TI) tem evoluído. Em ambientes de nuvem a complexidade de realizar accountability apropriadamente é alta porque as evidências devem ser coletadas considerando-se as camadas física, de virtualização e de aplicações, que estão espalhadas em diferentes servidores e elementos da infraestrutura. Esta complexidade é ampliada quando ocorre a federação das infraestruturas de nuvem porque além da complexidade inerente ao ambiente virtualizado, os membros da federação podem não ter os mesmos grupos de políticas e práticas de segurança. O principal objetivo desta tese é propor um framework de accountability, denominado CloudAcc, que suporte processos de auditoria, gerenciamento, planejamento e cobrança, em nuvens federadas, aumentando a confiança e a transparência. Além disso, o CloudAcc também considera os requisitos legais para a salvaguarda dos registros, conforme descrito no Marco Civil da Internet brasileira. A efetividade do CloudAcc foi confirmada quando alguns componentes da infraestrutura da nuvem foram submetidos a ataques de negação de serviço e de força bruta, e o framework foi capaz de detectá-los. Diante dos resultados obtidos, pode-se concluir que o CloudAcc contribui para o estado-da-arte, uma vez que fornece uma visão holística do ambiente de nuvem federada através da coleta de evidências em três camadas suportando os processos de auditoria, gerenciamento, planejamento e cobrança.
Palavras-chave: Federação de nuvens. Accountability. Segurança em nuvem. Transparência. Conformidade com a lei
Abstract
The evolution of software service delivery has changed the way accountability is performed. The complexity related to cloud computing environments increases the difficulty in properly performing accountability, since the evidences are spread through the whole infrastructure, from different servers, in physical, virtualization and application layers. This complexity increases when the cloud federation is considered because besides the inherent complexity of the virtualized environment, the federation members may not implement the same security procedures and policies. The main objective of this thesis is to propose an accountability framework named CloudAcc, that supports audit, management, planning and billing process in federated cloud environments, increasing trust and transparency. Furthermore, CloudAcc considers the legal safeguard requirements presented in Brazilian Marco Civil da Internet. We confirm the CloudAcc effectiveness when some infrastructure elements were submitted against Denial of Service (DoS) and Brute Force attacks, and our framework was able to detect them. Facing the results obtained, we can conclude that CloudAcc contributes to the state-of-the-art once it provides the holistic vision of the cloud federated environment through the evidence collection considering the three layers, supporting audit, management, planning and billing process in federated cloud environments.
List of Figures
2.1 User security responsibility in delivery models . . . 25
2.2 Monolithics and microservices . . . 27
2.3 Monolithic architecture diagram . . . 27
2.4 Microservice architecture diagram . . . 28
4.1 Federated Scenario . . . 53
4.2 Configuration settings sample . . . 55
4.3 CloudAcc Agent collection layers . . . 56
4.4 MIB tree used by agent . . . 57
4.5 General overview of CloudAcc Core . . . 58
4.6 SecMM conceptual model . . . 59
4.7 PKI Hierarchy . . . 61
4.8 Data classification and impact of disclosure . . . 62
4.9 Integrity Control Service . . . 63
4.10 Client Authentication Supported . . . 65
4.11 Secure storage diagram . . . 66
4.12 Key Hierarchy diagram . . . 67
4.13 Generic diagram of the PBKDF . . . 67
4.14 Centralizer workflow . . . 68
4.15 Monitor Module architecture overview . . . 70
4.16 Report Module architecture overview . . . 72
5.1 Test scenario . . . 75
5.2 Authentication Time . . . 79
5.3 Seven steps of a succesful cyber attack . . . 80
5.4 Proxy Memory Usage . . . 81
5.5 Proxy CPU Utilization . . . 82
5.6 Radius Memory Usage . . . 83
List of Tables
2.1 Access Control security issues . . . 33
3.1 Application security countermeasures . . . 39
3.2 Network security countermeasures . . . 41
3.3 Data security solutions . . . 43
3.4 Virtualization security countermeasures . . . 46
3.5 Accountability acting areas . . . 51
4.1 Minimal requirements by certificate type . . . 60
4.2 Security requirements to protect NSS systems up to TOP SECRET level . . . . 61
5.1 Performed tests . . . 74
5.2 SecMM factors and levels . . . 76
5.3 Results for 3DES running in Google Cloud. . . 77
5.4 Results for AES-128 running in Google Cloud. . . 77
5.5 Results for AES-192 running in Google Cloud. . . 77
5.6 Results for AES-256 running in Google Cloud. . . 77
5.7 AM factors and levels . . . 78
5.8 Paired Tukey’s Test . . . 78
List of Acronyms
ABAC Attribute-based access control . . . 47
ACL Access Control List . . . 29
AD Active Directory . . . 29
AM Authentication Module . . . 57
API Application Programming Interface . . . 23
BPM Business Process Model . . . 63
CA Certified Authority . . . 50
CAPTCHA Completely Automated Public Turing Test . . . 47
CBC Cipher Block Chaining . . . 60
CFB Cipher Feedback . . . 60
CloudAcc Cloud-based Accountability Framework for Federated Cloud . . . 51
CRM Customer Relationship Management . . . 22
CSP Cloud Service Provider . . . 19
CTR Counter . . . 60
CV Cloud Verifier . . . 44
DDoS Distributed Denial of Service . . . 34
DMZ Demilitarized Zone . . . 34
DoS Denial of Service . . . 29
DSA Digital Signature Algorithm . . . 40
DTD Document Type Definition . . . 38
ECB Electronic Codebook . . . 60
EDoS Economic Denial of Sustainability . . . 51
ENISA European Union Agency for Network and Information Security . . . 25
ERP Enterprise Resource Planning . . . 22
ESAPI Enterprise Security API . . . 39
ESB Enterprise Service Bus . . . 18
FRC Fraudulent Resource Consumption . . . 51
GAE Google App Engine . . . 23
IaaS Infrastructure as a Service . . . 24
IdM Identity Management . . . 31
IdP Identity Provider . . . 48
IDS Intrusion Detection System . . . 40
IPS Intrusion Prevention System . . . 40
IT Information Technology . . . 19
JAAS Java Authentication and Authorization Service . . . 38
JDK Java Development Kit . . . 55
JSON JavaScript Object Notation . . . 37
KPI Key Performance Indicator . . . 50
LDAP Lightweight Directory Access Protocol . . . 29
LM Logger Module . . . 58
MAC Message Authentication Code . . . 42
MFA Multi-Factor Authentication . . . 64
MIB Management Information Base . . . 55
MitB Man-in-the-Browser . . . 38
MitM Man-in-the-Middle . . . 29
MM Monitor Module . . . 58
MTCEM Multi-tenancy Trusted Computing Environment Model . . . 44
NDA Non-Disclosure Agreement . . . 76
NFV Network Function Virtualization . . . 87
NIDS Network based Intrusion Detection Systems . . . 40
NIST National Institute of Standards and Technology . . . 19
NTP Network Time Protocol . . . 86
OFB Output Feedback . . . 60
OTP One-time Password . . . 47
OWASP Open Web Application Security Project . . . 32
PaaS Platform as a Service . . . 23
PAP Policy administration point . . . 47
PBKDF2 Password-Based Key Derivation Function 2 . . . 66
PDP Policy decision point . . . 47
PEP Policy enforcement point . . . 47
PKI Public-key Infrastructure . . . 50
PRF Pseudo-random Function . . . 67
PRNG Pseudorandom Number Generator . . . 40
QoS Quality of Service . . . 49
RBAC Role Based Access Control . . . 38
REST Representational State Transfer . . . 37
RM Report Module . . . 58
RNG Random Number Generation . . . 42
SaaS Software as a Service . . . 22
SAML Security Assertion Markup Language . . . 30
SCM Supply Chain Management . . . 22
SDK Software Development Kit . . . 23
SDLC Software Development Lifecycle . . . 38
SecMM Security Management Module . . . 57
SLA Service Level Agreement . . . 20
SMI Service Measurement Index . . . 50
SMM Storage Management Module . . . 58
SMS Short Message Service . . . 65
SNMP Simple Network Management Protocol . . . 53
SOA Service-Oriented Architecture . . . 18
SOAP Simple Object Access Protocol . . . 37
SP Service Provider . . . 48
SSL Secure Socket Layer . . . 37
SSO Single Sign-On . . . 30
SVA Security Virtual Appliance . . . 34
TCCP Trusted Cloud Computing Platform . . . 44
TCPS Transparent Cloud Protection System . . . 44
TLS Transport Layer Security . . . 37
TVMM Trusted Virtual Machine Monitor . . . 44
USM Unified Security Management . . . 40
UTM Unified Threat Management . . . 40
VEE Virtual Execution Environment . . . 48
VEEH Virtual Execution Environment Host . . . 48
VEEM Virtual Execution Environment Manager . . . 48
VM Virtual Machine . . . 56
VMM Virtual Machine Monitor . . . 35
Contents
1 Introduction 18
1.1 Motivation . . . 19
1.2 Objectives . . . 20
1.3 Organization of the Thesis . . . 21
2 Background Concepts 22 2.1 Security concerns in cloud delivery models . . . 22
2.1.1 Cloud Federation . . . 24
2.1.2 Considerations about cloud delivery models . . . 24
2.2 Accountability . . . 25
2.3 Microservices . . . 26
2.4 Access Control security issues . . . 28
2.4.1 Physical access . . . 29 2.4.2 Credentials . . . 29 2.4.3 Authentication . . . 30 2.4.4 Authorization . . . 30 2.4.5 Identity Management . . . 31 2.4.6 Data security . . . 31 2.4.7 Application security . . . 31 2.4.8 Multi-tenancy . . . 32
2.4.9 Considerations about Access Control . . . 32
2.5 General Security Issues . . . 34
2.5.1 Perimeter Security . . . 34
2.5.2 Virtualization Security issues . . . 34
2.5.3 Considerations about security issues . . . 36
3 Related work 37 3.1 Application security . . . 37
3.1.1 Web browsers security . . . 37
3.1.2 API security and Application code vulnerabilities . . . 38
3.1.3 Considerations about application security . . . 39
3.2 Network security . . . 40
3.2.1 Considerations about network security countermeasures . . . 41
3.3 Data security . . . 42
3.3.1 Considerations about data security countermeasures . . . 42
3.4 Virtualization security . . . 43
3.5 Access Control security . . . 45 3.6 Inter-cloud Projects . . . 48 3.6.1 RESERVOIR . . . 48 3.6.2 Cloudbus InterCloud . . . 49 3.6.3 Open Cirrus . . . 49 3.6.4 STRATOS . . . 49 3.7 Discussion . . . 50 4 CloudAcc 52 4.1 CloudAcc Framework . . . 52 4.2 CloudAcc Agent . . . 54 4.2.1 Infrastructure perspective . . . 55 4.2.2 Virtualization perspective . . . 56 4.2.3 File-centric perspective . . . 56 4.3 CloudAcc Core . . . 57
4.4 Security Management Module (SecMM) . . . 59
4.4.1 Public-key Infrastructure Service . . . 60
4.4.2 Encryption/Decryption . . . 61
4.4.3 Integrity Control . . . 63
4.5 Authentication Module (AM) . . . 64
4.5.1 User Authentication . . . 64
4.6 Storage Management Module (SMM) . . . 65
4.6.1 Password-based Key Derivation . . . 67
4.6.2 User master key recovery routine . . . 68
4.7 Logger Module . . . 68
4.7.1 Cloud Centralizer . . . 68
4.7.1.1 Extract . . . 69
4.7.1.2 Merge . . . 69
4.7.2 Monitor Module (MM) . . . 69
4.7.2.1 Monitor Module architecture overview . . . 70
4.7.3 Report Module . . . 71
4.7.3.1 Report Module architecture overview . . . 71
4.7.4 Discussion . . . 72
5 Results 74 5.1 Methodology . . . 74
5.1.1 Testbed description . . . 75
5.2 Security Management Module Performance analysis . . . 76
5.3 Authentication Module Performance analysis . . . 78
5.4.1 DoS Attack . . . 81 5.4.2 Brute Force Attack . . . 82 5.5 Discussion . . . 83
6 Final Considerations 85
6.1 Challenges and Lessons Learned . . . 86 6.2 Future works . . . 87
References 89
Appendix 100
18 18 18
1
Introduction
The computational service delivery evolved according to users’ necessities - that was increasing the rigorousness of the requirements along the years -, and can be divided in five distinct eras: monolithic, client-server, web, Service-Oriented Architecture (SOA) and cloud computing (DAGGER et al., 2007; ERL, 2008; ARMBRUST et al., 2010). Following this evolution, the way in performing accountability also had to adapt in order to provide proper mechanisms for accounting routines.
The monolithic paradigm was widely used during the 70s. This paradigm was char-acterized by supporting single-tiered applications mixing different code functionalities into a same program from a single platform. Accounting routines were made concerning the evidences presented in one platform type only. The client-server paradigm was commonly used in the 80s. Applications developed in this paradigm are divided into two parts, client and server, which can be run on diverse machines with different hardware architectures. During the 90s, the web era arrived. With the popularization of the Internet and the evolution of design patterns, the web development made possible the creation of applications that could be accessed through the Internet or an Intranet. The SOA paradigm has emerged in the 2000s. The main principle of the SOA is to provide all applications’ functionalities as a service. These services are often connected through a bus, called Enterprise Service Bus (ESB). Finally, the cloud computing paradigm has appeared approximately in 2008 with the distributed computing strategy to provide the best usage of computing resources. These last ones, distribute the system evidence among different machines with different hardware architectures, Operational Systems, and infrastructures also, increasing the complexity in performing accountability properly. Moreover, the cloud computing paradigm has a virtualization layer that must be accountable.
Focusing on the last era, cloud computing brings many advantages for both provider and customer. From the provider perspective, clouds facilitate the infrastructure management, provid-ing resource control mechanisms (dynamic allocation, elasticity) and at same time, minimize the costs to infrastructure investments (MELL; GRANCE, 2011). On the other hand, from customer perspective, clouds represent a good and easy model to rent computational resources, offering on-demand self-service with pay-as-you-go model.
1.1. MOTIVATION 19
have evidences that they are a profitable business area. Cisco and Forbes are trying to create a roadmap to quantify the cloud computing importance for the next years. Cisco expects to see the Global Datacenter IP traffic growing three-fold by 2017 (NETWORKING, 2013). According to Forbes, "end-user spending on cloud services could be more than $180 billion. It is predicted that the global market for cloud equipment will reach $79.1 billion by 2018"(MCCUE, 2014). However, cloud computing still suffers from weaknesses, and according to the National Institute of Standards and Technology (NIST), "security, interoperability, and portability [...] are the major barriers to broader adoption"of the clouds (NIST, 2010).
For instance, many companies decided to not adopt cloud as an Information Technology (IT) solution because the Cloud Service Provider (CSP) has full control of shared resources and security devices; and they prefer that their business information stay on their own infrastructure, whether for strategic reasons, or by judicial reasons (NOOR et al., 2013). These problems can increase even further when different cloud infrastructures are interconnected.
Considering clouds interconnection, some authors classify it as cloud federation or inter-cloud. The first uses the providers’ interface, while inter-cloud is based on future standards and open interfaces (TOOSI; CALHEIROS; BUYYA, 2014). Nevertheless, both approaches aim to obtain interoperability (ARMBRUST et al., 2010); in this way, we decided to use cloud federation and inter-cloud nomination interchangeably in this Thesis.
Cloud federation provides scalability, hardware heterogeneity (BARRETO; FRAGA; SIQUEIRA, 2015), more availability when compared againts traditional clouds, geographic distribution to deal with disaster recovery and low latency access, avoiding vendor lock-in, as well as cost efficiency and energy savings (BUYYA; RANJAN; CALHEIROS, 2010; ARMBRUST et al., 2010; AOYAMA; SAKAI, 2011).
In cloud federation, new services can be offered by combining service components from different cloud customers. Interoperability between different clouds may be affected by integra-tion problems and security breaches. In addiintegra-tion to the security concerns inherent to virtualized environments, cloud interoperation raises more security challenges, such as trust, authoriza-tion and identity management, and policy and interoperability control (TOOSI; CALHEIROS; BUYYA, 2014).
Performing accountability in federated environments is a very hard issue because, in addition to the complexity related to virtualization, the federation members has different infras-tructures with its own security procedures, systems, and controls.
1.1 Motivation
As previously said, performing accountability in cloud environments, specially in fed-erated clouds, is a growing concern because the log data is spread across different servers, infrastructures, and applications. Considering accountability as "the acknowledgement or as-sumption of responsibility for actions and decisions of persons or organizations that affects
1.2. OBJECTIVES 20
others"(NAKAHARA; ISHIMOTO, 2010), detailing "when, where, what, who, and how" is one of the key functions for a proper accountability mechanism. The other key functions of a proper accountability mechanism are storing and retrieving the log data, and increasing the liability, transparency, responsiveness, responsibility, and controlability. Therefore, if the cloud computing environment allows accountable routines, it will be considered more trustworthy and, consequently, it will get more users.
An appropriate accountability mechanism in a federated scenario must be able to in-crease the security and the confidence among the members of the federation. An accountable infrastructure must provide sufficient evidences for audit process, infrastructure management, planning, and billing. Furthermore, cloud users can trust that their contracts will be fulfilled following the Service Level Agreement (SLA), once that their records may be checked.
Nonetheless, the existing approaches are not able to support the audit process, infras-tructure management, planning, and billing at the same time. To properly support these four procedures, the information from infrastructure, virtualization and application layers must be col-lected. The related works of the state-of-the-art that provides accontability routines (PAWLUK et al., 2012; AVETISYAN et al., 2010; BUYYA; RANJAN; CALHEIROS, 2010; ROCHW-ERGER et al., 2009) collect information at one layer, supporting only billing process. They do not consider legal aspects related to the registry’s safeguard, neither are able to provide different configurations according to the user needs. They also do not provide alerts routine when detect some SLA metric violation, contractual clauses, or nonstandard activities.
1.2 Objectives
Considering the aforementioned motivations, the main objective of this Thesis is to propose and evaluate a Cloud-based Accountability Framework for Federated Clouds, named CloudAcc, based on microservices architecture capable to enable audit process, infrastructure management, planning, and billing collecting the evidences dispersed through whole infrastruc-ture.
The specific goals of this thesis are:
Define requirements to comply with an accountability framework in order to propose
an architecture for the CloudAcc;
Model the CloudAcc architecture as microservices to support easy scaling and
integration with other frameworks or tools.
As said previously, works in the literature consider and treat data monitor and analysis only in one layer; as our main contribution, the CloudAcc has a centralized analyzer that considers the physical layer, virtualization layer and application layer.
We consider that the evidences existing in physical, virtualization, and application layers provides a fine-grained infrastructure vision supporting procedures like: decision taken,
1.3. ORGANIZATION OF THE THESIS 21
infrastructure control and planning. The collected evidences from physical layer CloudAcc uses them to measure. In virtualization layer, the CloudAcc may prove that the SLA metrics were fulfilled, to give support for the billing process, and to manage the VM configurations. Considering the evidences in application layer, the CloudAcc uses them to support auditing process and detecting malicious activities.
Other key contribution provided by the CloudAcc is the log storage in compliance with the Brazilian law named "Marco Civil" that specifies requirements related to information temporality and confidentiality.
Finally, CloudAcc framework functionalities are modeled as microservices to support easy scaling and integration with other frameworks or tools, such as security knowledge base, IDSs/IPSs, and firewalls.
1.3 Organization of the Thesis
This Thesis identifies the challenges involved in accountability in federated cloud com-puting scenarios considering its security issues related. The rest of this thesis is organized as follows: Chapter 2 will describe the basic concepts and security issues. Chapter 3 we will present its countermeasures that we will consider to implement our solution. Chapter 4 describe thoroughly each framework module. Each module has different architectures with well-defined requirements and purposes. Chapter 5 presents the results and performance tests. Finally, in chapter 6 we will present the conclusions and the final remarks and future works.
22 22 22
2
Background Concepts
Considering the objectives of the thesis previously described, this chapter presents the background concepts necessary to comprehend our proposal and solutions. First, we will describe the security concerns in cloud and cloud federation concepts. Then, we will present the accountability concepts. After that, we will introduce some concepts related to microservices. In Section 2.4 we will present the concerns related to access control, and finally, in Section 2.5 we will describe general security issues involving network security and virtualization security.
2.1 Security concerns in cloud delivery models
In Software-as-a-Service delivery model, the end-user consumes on-demand services such as email, document writer, Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), and Supply Chain Management (SCM) (JU et al., 2010). In this model, users have less control over security compared to PaaS and IaaS, depending basically on the security measures taken by the provider. The provider has to manage users and assign to each one his security policies that can be related to information sharing, information access and editing. Moreover, the provider could not ensure the software availability whenever the customer requests, nor that the security policies are being properly implemented (PUTHAL et al., 2015). The SaaS software vendor can deploy its applications on a cloud computing infrastructure service provided by other provider (e.g. Google, Microsoft Azure, and Amazon) or on its own private server farm. By using a third-party provider they reduce the investment in infrastructure services and can also take advantage of cloud facilities to focus on improving services for customers.
The data related to business processes are considered by enterprises as important strategic assets that are directly related to decisions that will be taken. However, in SaaS, all data is stored on Software as a Service (SaaS)’s data centers, together with the data from other enterprises. In addition, in order to ensure data availability, these assets are replicated to other locations and may or may not be within the same country of the enterprise. Consequently, the concerns relating data storage and its protection, data breaches, application vulnerabilities, and availability generate severe discomfort in cloud customers.
2.1. SECURITY CONCERNS IN CLOUD DELIVERY MODELS 23
Platform-as-a-Service delivery model is a cloud infrastructure created to support ap-plications that use the provider tools, frameworks, libraries, and Application Programming Interfaces (APIs). In this type of model, the consumer does not need to worry about problems in hardware and software layers (SUBASHINI; KAVITHA, 2011). On the other hand, the consumer has no control over cloud infrastructure including operating system, network, or storage, but still control the configuration settings for the application hosted on it (MELL; GRANCE, 2011). There are several Platform as a Service (PaaS) providers such as Google App Engine (GAE), Heroku1, and Microsoft Windows Azure2.
The security responsibilities in PaaS model are divided into two layers: the security of the platform (i.e., APIs, frameworks, Software Development Kits (SDKs)) and the security of customer’s applications (MATHER; KUMARASWAMY; LATIF, 2009). APIs, frameworks, and SDKs work as an interface between cloud customers and cloud service providers. They provide a transparent access to cloud facilities and must be properly designed to protect against both accidental and malicious attempts to avoid the access policies to prevent that malicious users compromise the infrastructure security and / or applications. The security off all platform software are on the provider’s responsibility and the responsibilities of applications security are on the customer.
In the PaaS model, the security concerns related to users’ data follows the same concerns that those in SaaS model. Moreover, this model has its own concerns like relationships with other platforms that can impact the security of applications. The PaaS model provides to consumers a set of features ready to be used. Through the use of SOA, PaaS provider allows applications to transparently consume the necessary resources when they are in the provider’s infrastructure or in a trusted third-party. In addition, PaaS models also inherit the security concerns related to data and networks, and also should be concerned about the safety of development tools and outsourced third-party relationships (XU et al., 2009). Other security concerns are related to user authentication that will be discussed on subsection 2.4.3.
In the Infrastructure-as-a-Service delivery model, a set of features are available to users as virtualized systems that can be accessed over the internet (ALMORSY et al., 2010). These resources can be, for example, servers, storage and networking. In this model, users have all control over the resources allocated to them and can access and control them (DAHBUR; MO-HAMMAD; TARAKJI, 2011). In addition, users have more control over security requirements and policies when compared to other models.
This model allows users to install and configure applications in their virtual machines. They are also responsible to manage and enforce security policies according to their needs (JAEGER; SCHIFFMAN, 2010). However, the service provider is responsible to support the security over the computing process, networking and storage infrastructure. Other substantial efforts over service’s provider responsibility are related to safeguard security in the creation
1www.heroku.com 2azure.microsoft.com
2.1. SECURITY CONCERNS IN CLOUD DELIVERY MODELS 24
process, communication, monitoring, modification and mobility of virtual machines (DAWOUD; TAKOUNA; MEINEL, 2010).
2.1.1 Cloud Federation
Cloud federation is the practice of interconnecting different cloud infrastructures (TOOSI; CALHEIROS; BUYYA, 2014). Cloud federation provides scalability and hardware heterogeneity (BUYYA; RANJAN; CALHEIROS, 2010); other key features include availability and disaster recovery, geographic distribution and low latency access, interoperability and avoiding vendor lock-in, legal issues and meeting regulations, as well as cost efficiency and energy savings (ARMBRUST et al., 2010; AOYAMA; SAKAI, 2011).
Cloud interoperability can be obtained by interface standardization or brokering. In an interface standardization approach all providers adopt the same interface. Nevertheless, developing a set of standards is difficult and hard to be adopted by all providers. The broker approach uses a service broker to translate messages among cloud interfaces making them interoperate with each other. A combination of these two approaches aforementioned often occurs in practice.
In (CELESTI et al., 2010a), the authors consider the cloud computing evolution in three stages:
Monolithic stage, each cloud provider creates its own architectures. Cloud services
are delivered by different providers in this stage.
The vertical supply chain stage can be called delegation or vertical federation. In
this stage some provider can create its services using other provider’s infrastructures like a SaaS provider deploys its services in an Infrastructure as a Service (IaaS) provider;
The horizontal federation stage allows different cloud providers to federate
them-selves in order to obtain the benefits provided by cloud federation. However, it must occur at the same layer (e.g., IaaS to IaaS).
2.1.2 Considerations about cloud delivery models
The difference between IaaS, PaaS, and SaaS is the responsibility in performing the security practices and where it needs to be performed. Figure 2.1 depicts the user responsibility in providing security procedures for each delivery model.
In IaaS delivery model the user is responsible in providing security in Application, Application Server, Middleware, Database, and Operating System layers. The other security issues involving Hypervisor, CPU, Networking, Storage, Backup, and Datacenter layers must be provided by the Cloud Service Provider (CSP).
2.2. ACCOUNTABILITY 25
Figure 2.1: User security responsibility in delivery models
Source: (DAWOUD; TAKOUNA; MEINEL, 2010)
Considering the PaaS model, the security procedures provided by the user is in Applica-tion layer. The security in the rest of cloud layers must be provided by the CSP.
In the SaaS model, the user has control about the data in Storage layer. All security concerns related to storage are under user responsibility. Consequently, the CSP is responsible in provide security procedures in the rest of the platform.
2.2 Accountability
Accountability is a concept that has different meanings. In (KOPPELL, 2005) the author proposes five important aspects of accountability: transparency, liability, controllability, responsibility, and responsiveness. The author considers transparency and liability as the main important foundations of the accountability’s concept. Transparency provides the way needed to assess organizational performance results. Liability means that organizational members should be held liable for their actions.
Another accountability concept that is closely connected to cloud computing environ-ments was presented in (YAO et al., 2010): "Accountability is a concept to make the system accountable and trustworthy by biding each activity to the identity of its actor. Such biding should be achieved under circumstance that all actors within the system are semi-trusted".
In (CASTELLUCCIA et al., 2011) the European Union Agency for Network and Informa-tion Security (ENISA) define that accountability offers three capabilities: validaInforma-tion, attribuInforma-tion, and evidence. Validation allows users to verify if everything works as expected. Attribution allows in the case of fault, the responsibility can be assigned. Evidence is an artifact used to convince when a dispute arises. They identified "falsifying record collection", "tampering with records"and "destroying or suppressing the transmission of records" as main threats against integrity of the collection, storage and transmission of accountability registers. These threats are
2.3. MICROSERVICES 26
also present in cloud computing and federated cloud environments and compromise the forensic investigation (FARINA et al., 2015). Furthermore, an accountable infrastructure must provide sufficient evidences for: an audit process, infrastructure management, planning, and billing. Users should be able to trust that their contracts will be fulfilled following the SLA, once that their records may be checked.
2.3 Microservices
Microservices (micro-services or micro services) is another software architecture related term emerging out of Service-Oriented Architecture (SOA), emphasising self-management and lightweight functionalities. Although, this terminology describes a new style of software systems more appealing for cloud applications.
The first time that the term microservice was discussed was in 2011. In 2012 the same group decided on "microservices" as the most appropriate name to this kind of software architectural implementation (LEWIS, 2012). Based on (NEWMAN, 2015; LEWIS; FOWLER, 2014), microservices architecture provides functional decomposition of an application. The functional decomposition of an application achieves loose coupling (by a well defined interface), and high cohesion (well defined functionalities), enabling for instance, agility, flexibility, and scalability (KILLALEA, 2016).
The main idea behind microservices applications is to build tiny applications with single responsibilities. According to (NEWMAN, 2015; LEWIS; FOWLER, 2014), organization around business capability, intelligence in the endpoints, decentralized governance, decentralized data management, deployment/infrastructure automation, design for failure, and evolutionary design as the main princip´les that characterises a microservice architecture.
Before explaining the microservice architectural style, we will first compare it to mono-lithic one. An application is considered monomono-lithic when it is built as a single unit. The common applications architectures broadly adopted nowadays are in three main parts: a user interface (client-side), a database, and a server-side. The server-side application is a single logical ex-ecutable with different responsibilities that implements all supported functionalities. Despite implementing all functionalities in a single a unit, monolithic applications can provide loose coupling and high cohesion too. However, the monolithic approach does not provide the same advantages, mainly, considering the scaling routine. Figure 2.2 depicts the architectural style differences between monolithic application and microservices considering scaling routine.
Supposing that the application supports the three functionalities represented in Figure 2.2 as black circle, gray circle with plus inside, and the light gray hexagon. Considering the scaling routine, a monolithic application is scaled by replicating at all parts of the software in different hosts. In microservice architecture, only the needed elements are scaled across the servers.
Detailing the difference between monolithic and microservices applications, Figures 2.3 and 2.4 illustrate the travel agency software architecture.
2.3. MICROSERVICES 27
Figure 2.2: Monolithics and microservices
Source: from author
Figure 2.3: Monolithic architecture diagram
Source: from author
cohe-2.4. ACCESS CONTROL SECURITY ISSUES 28
Figure 2.4: Microservice architecture diagram
Source: from author
sion. The difference is that in microservice approach, each module can be accessed through a REST API and may not running in the same machine. Moreover, when scaling the service implemented considering the architecture illustrated in Figure 2.3, all modules will replicated but considering the architecture illustrated in Figure 2.4, the replication will occur only in the needed microservice.
However, the microservice architecture gives some drawbacks. Problems related to distributed computing involving architectural complexity, network latency, message formats, load balancing, test and deployment, and fault tolerance (MELO; STINE, 2014).
2.4 Access Control security issues
Access control is the solution found to restrict only to authorized persons a given resource, that could be a physical resource (e.g. room, building, etc.) or a virtual one (information, data, system use, etc.). The most common method used for Web access control is authentication using both username and password combination. In cloud computing environment this type of authentication is also widely used because users manage their resources via a Web interface. Web applications in a cloud have the same facilities they have in common infrastructure (e.g. technology independent, multi-users, and client-server architecture) and the same drawbacks (WEBSENSE: 2013 THREAT REPORT, 2013).
In cloud computing environments access control is one of the most important security concern. In addition, provide the physical and logical resources segregation for each user, authentication and authorization requirements, physical access, credential access, and identity management (BOWERS; JUELS; OPREA, 2009a) are the main access control issues and will be discussed as follows.
2.4. ACCESS CONTROL SECURITY ISSUES 29
2.4.1 Physical access
The physical access control is the key control to ensure the integrity, reliability and reputation of the cloud infrastructure. Attackers exploiting physical access are called malicious insiders (PANAH et al., 2012; YU et al., 2012; AHUJA; KOMATHUKATTIL, 2012) that could be an ex-employer, disgusted employer, spies, or any other type of malicious actor who uses physical access to compromise the security of the infrastructure.
The negative impact caused by a malicious insider is quite large. In the scenario of a datacenter for example, different business data from different users are stored in the same physical location. A malicious insider could use his privileged access to provide the data leakage from sensitive business information. In a more complex attack, the attacker could grant sysadmin privileges and install any software to access the VMs (SANTOS; GUMMADI; RODRIGUES, 2009). An example of this attack is in Xen hypervisor that admin users can access the Dom0 and access directly the running VM memory content (NIST, 2015).
Reasearchs by (KANDUKURI; PATURI; RAKSHIT, 2009; ZOU; ZHANG, 2011) show that the impact of a malicious insider can compromise the entire infrastructure security. In addition, the attacker can remove the kernel modules that make the machine security, firewalls and antivirus and install vulnerable software to exploit its weakness whenever he want.
The common approach used to control the physical access to infrastructures are made by Access Control Lists (ACLs) that contains the valid credentials to access the physical environment. Despite this, other practices can be found in ISO / IEC 27002 that summarizes the most common rules for physical controls.
2.4.2 Credentials
Felkner and Sacha’s definition is " A credential is an attestation of qualification, compe-tence, or authority issued to an individual by a third party with a relevant or de facto authority or assumed competence to do so." (FELKNER; SACHA, 2009). Large companies use the Lightweight Directory Access Protocol (LDAP) or Microsoft Active Directory (AD) to manage the authentication credentials in their infrastructures and assign to them, the proper access control to infrastructure resources.
Security issues related to credentials are very impactful on the infrastructure compliance. A compromised credential can be used to perform phishing or Man-in-the-Middle (MitM) attacks (BEHL, 2011). In addition to this, the attacker can use a compromised credential to perform data leakage, and Denial of Service (DoS) attacks by hiding his credential with the compromised one. In the scenario where the compromised credential has root access or administrator privileges, the attacker can control all machines features through a valid credential (MODI et al., 2013).
2.4. ACCESS CONTROL SECURITY ISSUES 30
2.4.3 Authentication
The goal of authentication is to ensure the veracity of any information being presented that could be: something you know, something you have, and something you are, or any com-bination of these information. The common approaches, use textual passwords, third-party authentication, and biometrics as credentials required in the authentication process (DINESHA; AGRAWAL, 2012). The tuple login / password is the most used and easy authentication method implemented nowadays. According to (HART, 2009) authentication using only textual passwords are simple and do not provide the necessary security to prove the users identity. The third-party authentication is not the preferred authentication method by medium cloud infrastructures, be-cause it needs to carefully manage the relationship to provide the proper access rights to users. Biometric authentication considers users’ physical attributes (e.g. fingerprint, palm printing, and iris) to authenticate them. The main disadvantage of biometric approach is the need of physical presence therefore in scenarios like physical access control, biometric authentication is an appropriate authentication method.
Cloud computing environments use Single Sign-On (SSO) strategies to solve the multi-authentication routine. In addition, the multiple services consumed by users communicate with each other services through a XML-based language called Security Assertion Markup Language (SAML) (MANSFIELD-DEVINE, 2008) in order to exchange authentication and authorization messages.
The security issues related to authentication process are: weak password recovery routine, remote authentication, brute force attacks and dictionary attacks (GONZALEZ et al., 2012). Weak password recovery routine is the process of recover user passwords that were lost. An attacker can block the user access by requesting the recovery routine. The remote authentication problems are related to the applications nature when the user data are transmitted through Internet. The last two attacks against authentication process - brute force and dictionary attacks - explore weakness in users password, whether by using common passwords like "abc123" and "qweasd", whether by trying all characters variations.
2.4.4 Authorization
The authorization process is linked to the authentication process and access control. This process is responsible for granting or not the access to the desired feature. The major security issue related to authorization concerns is to provide access for users that could not access it (GROBAUER; WALLOSCHEK; STÖCKER, 2011) that is very common in the URL-guessing attacks (TOP 10 - OWASP, 2013). Another security issue is related to malicious third-party application e.g. (WARD, 2009). In a social network scenario, the user grant a third-party application that maliciously collect all data usage and behavior.
2.4. ACCESS CONTROL SECURITY ISSUES 31
2.4.5 Identity Management
The Identity Management (IdM) is a large administrative process that aims to identify entities (e.g. individuals or enterprises) and cloud objects, controlling access to resources based on policies that have been pre-established (ALMORSY et al., 2010). The IdM can be given three perspectives: the pure identity, user-access or logon paradigm, and service perspective (SUBASHINI; KAVITHA, 2011; DANIELS, 2013). The first perspective, the pure identity, is concerned only to manage the infrastructure identities with no information about how the user will present his identity and the access permission. The second perspective involves organizational perspectives and systems to provide a proper security from unauthorized access. The third perspective assigns the cloud services to roles that can consume these services.
The main security issues are related to the IdM type. An IdM can be: independent IdM stack, Credential Synchronization, and Federated IdM (SUBASHINI; KAVITHA, 2011). The first has the security compliance with the security business policies (e.g. password length, strength and validity) as main challenge. The credential synchronization model needs a security application to provide secure communication and storage. The federated model is necessary to ensure the correct trust and validation relationship of the servers to avoid unauthorized access.
2.4.6 Data security
The data security is a common concern for any scenarios and technologies involved. However, in SaaS environment users need to trust that their service provider applies the adequate security (HUANG et al., 2016; KANAGASABAPATHI; DEEPAK; PRAKASH, 2016). Never-theless, many times the organizational data are processed in clear-text (without any cryptographic procedure) and stored in the cloud remaining a responsibility to the service provider among the processing time and storage (JU et al., 2010). Also, we can consider the data backup as a security concern. If on the one hand the regular backup is important to facilitate recovery in case of disaster, on the other hand it raises two concerns regarding the unsafe storage and insecure configuration (ALI; KHAN; VASILAKOS, 2015).
Other security concerns involving data security are related to the cloud distributed nature where the user data could be stored in different physical location that involves regulatory compliances related to data jurisdictions which have different laws (ERTAUL; SINGHAL; SALDAMLI, 2010; CARLIN; CURRAN, 2011; BISONG; RAHMAN et al., 2011). Although this is an important issue, it is out of the scope considered by this work.
2.4.7 Application security
Applications deployed in SaaS model are commonly accessed via Internet by a Web Browser (ARDAGNA et al., 2015). Although there are secure software development practices, it is still quite common the development of web applications with security problems. By exploiting
2.4. ACCESS CONTROL SECURITY ISSUES 32
these vulnerabilities in web applications that attackers compromise the users’ machines and perform malicious activities like stealing users’ sensitive data (OWENS; AMERICAS, 2010).
The Open Web Application Security Project (OWASP) is an organization focused on improving the security of software. All publications of this organization are free and have open software licenses. OWASP has listed the top ten most impactful security flaws in web applications (OWASP LISTS TOP 10 MOST CRITICAL WEB APPLICATION RISK, 2015).
2.4.8 Multi-tenancy
Applications deployed in SaaS model are grouped into maturity model. Each maturity model is determined by the following characteristics: scalability, configurability via metadata, and multi-tenancy (ZHANG; LIU; MENG, 2009; JU et al., 2010). Multi-tenancy is one characteristic of cloud computing environment that allows multiple users to store their data at the same location.
Multi-tenancy is added in the third maturity model and a single instance serves all customers (CHONG; CARRARO; WOLTER, 2006), for this reason the use of security policies are necessary to ensure that customer’s data are kept separated from other customers (BEZEMER; ZAIDMAN, 2010). Any success on vulnerability exploitation in a multi-tenancy environment allows the attacker to gain access to sensitive enterprise data of other tenants, access to neighbor running applications or VM. Other issues like a DoS by consuming the whole platform resources, or starving the neighbor resources should be considered.
2.4.9 Considerations about Access Control
The table 2.1 summarizes the access control security concerns.
A proper accountability system may avoid or mitigate the impact of the access control weakness through an efficient log analysis. Furthermore, problems involving access control are not restricted to software solution because most of the weakness are related to human factors involving expertise in security. To minimize the human factors in access control issues the CERT.br3 publishes a book containing best practices in Internet aiming to develop the user security expertise. Other security expertise that must minimize the access control issues are involving the application development that may generate multi-tenancy and application security problems.
The security issues related to physical access and data security would be detected through log analysis. The physical security violation is under CSP controls. Considering that the CSP is in compliance with ISO27000, all physical access must be logged and the datacenter access must occur by 2-factor authentication. The data security violation may also be detected by log analysis but not avoided by an accountability system.
We present in Figure 2.1 the user responsibility for each delivery model. Nevertheless, the CSPs must have their infrastructures accountable and capable in blaming each activity (malicious
2.4. ACCESS CONTROL SECURITY ISSUES 33
Table 2.1: Access Control security issues
Topic ID Issue
Physical Access (PA)
PA-01 Data leakage
PA-02 Privileged access grant
PA-03 Direct access to running VM memory
Credentials (Cred) Cred-01 LDAP or AD injection
Cred-02
Compromised credential: - Phishing attacks;
- Man in the Middle (MitM) attacks; - Data leakage;
- DoS attacks;
Authentication (Authe)
Authe-01 Weak authentication routine Authe-02 Weak password recovery routine Authe-03 Remote authentication
Authe-04 Brute-force and dictionary attacks
Authorization (Autho) Autho-01 URL-guessing attacks
Autho-02 Vulnerabilities in third-party application
Identity Management (IdM)
IdM-01 Independent IdM stack:
- Unfollow organizational security policies
IdM-02
Credential synchronization:
- Synchronization through untrusted channel; - Insecure credential storage
IdM-03 Federated model:
- Improper trust validation relationship
Data Security (DS)
DS-01 Data is processed and stored in clear-text DS-02 Insecure data transmission
DS-03 Unsafe storage
Application Security (AS) AS-01 Web applications vulnerabilities AS-02 Vulnerabilities in browsers and APIs
Multi-tenancy (MT)
MT-01 Weak resources isolation
MT-02 Data leakage
MT-03 Unallowed access to data, applications or running VM
or not).
The access control security issues are very impactful because may impact in both client and cloud perspectives. The data security and physical access issues are the main drawbacks that the users report when not choosing cloud computing environment to support their applications. Furthermore, credentials, authentication, authorization and identity management issues are also present in CSP infrastructures independently of the cloud service delivery because it must control its users access. In fact, some successful access control exploitation may directly impacts in clients’ or cloud business.
2.5. GENERAL SECURITY ISSUES 34
2.5 General Security Issues
Nowadays, not only the applications are adapting to new paradigms but the networks and protocols also are. Furthermore, the evolution of network protocols to support dynamic scenarios are evidence of this change. Hence, the security community needs to adapt to these developments. The following discussion focuses on perimeter security and virtualization issues.
2.5.1 Perimeter Security
Traditionally, network security is done statically by placing the security devices or gateways to separate the external environment from the internal and to form the Demilitarized Zones (DMZs). However, these static solutions are not efficient for dynamic scenarios such as cloud computing environments where virtual machines can migrate from one physical machine to another when necessary and taking all services together. Considering cloud computing scenario, stateful firewalls do not show effective since the flow path changes every time that a VM migrates to another server.
Service providers need to be concerned about two types of attackers: the external network attacker and the insider network ones. Commonly, an external attacker performs DoS or Distributed Denial of Service (DDoS) attacks in order to affect the availability of services and resources. These attacks reduce the bandwidth and increases the congestion causing loss of service quality provided to users. However, due to the distributed nature of cloud computing, detecting and preventing Denial of Service (DoS) / Distributed Denial of Service (DDoS) attacks is a very difficult activity (VIVINSANDAR; SHENAI, 2012). When the attacker is inside cloud environment, the impact of an exploitation is higher because the intruder has information about network infrastructure, the location of servers and services, and other privileged information. The behavior of an insider attacker is to try to elevate his privileges to perform attacks that allow access to machine resources. IP spoofing attacks, DNS poisoning, XSS, port scan, sniffing and spoofing attacks are the common malicious activities performed by an insider attacker (WU et al., 2010).
Most cloud providers (Amazon, Windows Azure, Rack Space, etc.) use their security applications behind the firewall mitigating external attacks. To mitigate the impact from malicious insiders the cloud providers use Security Virtual Appliances (SVAs) (BASAK et al., 2010).
2.5.2 Virtualization Security issues
Cloud computing is an inherent virtualized environment. Regardless the delivery model, this environment presents security problems related to machine virtualization, and virtual machine management. As follows we detail the security concerns related to virtualization security.
Virtualization allows the abstraction of a hardware platform, operating system, and storage device or network resources. Users can interact with virtual machines according to their
2.5. GENERAL SECURITY ISSUES 35
needs being able to create, delete, share, migrate, copy, and roll back virtual machines (WEI et al., 2009). The abstraction and isolation from real machine was made by introducing an extra layer called Virtual Machine Monitor (VMM) or Hypervisor. However, the VMM increases the range of attacks that could be performed and must be properly secured (OWENS; AMERICAS, 2010).
Environments that work with virtualization are vulnerable to the same types of attacks of a normal one. Therefore, the security of the physical machine becomes as important as the security of virtual machines because any vulnerability exploitation on a physical machine can directly impact the virtual machine and vice-versa (ERTAUL; SINGHAL; SALDAMLI, 2010). Despite this, the security of virtual machines requires more attention by having more points of failure in relation to physical machines due to the hypervisor layer that is responsible for the abstraction and isolation from the virtualized environment to physical one (REUBEN, 2007).
In addition to abstracting the hardware platform and isolating the virtual environment, the hypervisor is a low-level code that is responsible for controlling and monitoring virtual machines. It allows migrating virtual machines from one real server to another in fault tolerance scenarios, load balancing, maintenance or energy saving (HASHIZUME; YOSHIOKA; FERNANDEZ, 2012). In (DAWOUD; TAKOUNA; MEINEL, 2010; VENKATESHA; SADHU; KINTALI, 2009; JASTI et al., 2010) authors show that virtual machine migration routine can create a range of possible attacks as: compromise a migration module in VMM; copy of the virtual machine content when it is passing through the network; migrate a corrupted virtual machine to a “healthy” server, and compromising the target server integrity.
The impact of exploitation of a VMM vulnerability could be disastrous. There are many security flaws pointing to isolation failure on virtualized environments making possible attacks: VM-VM, VM-real machine, and real machine-VM (NIST, 2014; US-CERT; NIST, 2015; VMWARE, 2014; NIST, 2015).
The virtual machine management requires a series of safety precautions related to features that each VMM implements. There are three groups of security issues related to virtual machine management to be carefully observed: virtual machine repository; virtual machine rollback; and virtual machine lifecycle.
IaaS environments, commonly implements public repositories with images of pre-configured virtual machines that are shared between users of the infrastructure. IaaS providers like Google Compute Engine and Amazon public repositories of virtual machines where users can download and upload a VM image and other valid users can replicate its configured image. Supposing that a malicious user uploads an image that contains a malicious code. For each replication of the image, the malicious code will be replicated. This fact will compromise other users or even the cloud system (ALMORSY et al., 2010; JANSEN, 2011; GROBAUER; WAL-LOSCHEK; STÖCKER, 2011). Virtual machine modifications, when it is in VM repositories are impactful and hard to be detected because the images in repositories are not running, disabling the administrators’ track routine.
2.5. GENERAL SECURITY ISSUES 36
The VMM allow users to copy the states of their virtual machines. The virtual machine rollback is the process to return to a previously saved state. This feature may expose the infrastructure to a large security issue related to re-expose the VM to errors or vulnerabilities that were patched previously (GARFINKEL; ROSENBLUM, 2005; HASHIZUME et al., 2013) for instance: re-enable users who were removed, or return to passwords that already have been changed.
Virtual machines have a lifecycle that varies according to their position in the environment. They can be on, off or suspended which makes the task of detecting whether the VM is corrupted much more difficult. Nevertheless, the fact that the VM is offline does not mean it is not corrupted (ALMORSY et al., 2010) as described previously on Virtual Machine Repository session.
2.5.3 Considerations about security issues
Perimeter security concerns are present in all infrastructures. The common security ap-proach adopted by administrator’ is protecting their resources using firewalls or SVAs. However, these protection are not efficient enough to avoid the perimeter security attacks. Considering the attack nature, the passive attacks (e.g., port scan, and sniffing) are harder to be detected than active attacks. Passive attacks normally do not generate evidences enough to be detected by a log analyzer, differently than an active attack.
A proper accountability system does not avoid perimeter security violations but it may provide sufficient information for decision making. For example, analyzing the collected registries from a application server, the infrastructure administrator may detect DoS/DDoS attacks and create firewall rules to block them.
The virtualization problems are hard to detect. Besides the fact that a single physical server may virtualize several virtual machine instances, the log registries are distributed to the whole platform.
A proper accountablitiy system could record unusual virtual machine and/or hypervisors activities. However, considering the entire federation, detecting the unusual behaviors is more complicated because each federation member has its own security procedures and default behavior. The analysis of these records could detect intentional or unintentional changes that could lead to compromised virtual machine, the migration module and the virtual machines repository.
37 37 37
3
Related work
In this chapter, we provide a brief description of the related works that solve the security issues mentioned on Chapter 2. The solutions that will be described were the basis for the construction of CloudAcc, once our framework is also a cloud solution and we would like to avoid or, at least, mitigate the security issues mentioned on Chapter 2.
3.1 Application security
The application security on cloud computing environment involves multi-area knowledge. The application component is the way that customers can access, use, and/or control the service provider resources, applications, and/or services over a network via web browser. This Subsection will be divided into three parts: web browsers security, API security, and application code vulnerabilities.
3.1.1 Web browsers security
Web browsers are client programs that access the cloud services, applications and/or resources. They use Secure Socket Layer (SSL) / Transport Layer Security (TLS) protocols for secure data transmission and authentication. Browsers are point of security concerns be-cause once any vulnerability is exploited, it could compromise the application security. Cloud applications use web services as technology (e.g., Simple Object Access Protocol (SOAP) and Representational State Transfer (REST)) to provide the necessary characteristics for its appli-cations. Web services use eXtensible Markup Language (XML) to provide all configuration, parameters, and protocols needed to be accessed by the client. Despite the facilities provided by XML use (platform independency, human readability, extensibility, and computational lan-guages compatibility) the processing overhead produced and resources by XML manipulation can cause a special DoS on web services. In (JENSEN; GRUSCHKA; HERKENHÖNER, 2009) , the authors proposed as countermeasures to processing overhead the total buffer size restriction for XML message and also apply a schema validation routine. The JavaScript Object Notation (JSON) could be an alternative to mitigate the processing overhead.
3.1. APPLICATION SECURITY 38
SOAP security standard that provides XML security and strict rules for Document Type Defini-tion (DTD) (NOLAN et al., 2014). The XML data integrity is provided by WS-Reliability and WS-Transaction API (SUBASHINI; KAVITHA, 2011) that offers the necessary requirements to avoid MitM attacks. Other countermeasure necessary to avoid XML-based attacks is forwarding only valid signed XML (SOMOROVSKY et al., 2012).
Web browsers are also susceptible to malicious software (e.g., trojan horses, viruses, malwares) and became vulnerable to an attack called Man-in-the-Browser (MitB). The MitB attack is almost impossible to be detect because it works between both parties (PHILIPP, 2007). The countermeasures existing for MitM attacks (e.g., authentication, and secure communication channels) are not effective for MitB attacks once it acts on the application layer (RAUTI; LEPPÄNEN, 2012). The authors in (RAUTI; LEPPÄNEN, 2012) use AJAX routines to mitigate the MitB attack. In (BIN MAT NOR; JALIL; MANAN, 2012) authors proposed an remote attestation using Trusted Platform Module (TPM) to grant the client platform integrity from the BIOS to browser software.
Other web browser vulnerability was founded by RSA in 2012 that affects Mozilla Firefox, Internet Explorer and Chrome Browsers (WATERING HOLE ATTACKS, 2015). This attack is performed by injecting JavaScript or HTML on vulnerable sites that the victim frequently visit to redirect to a separate site that contains a malicious code. As countermeasures antivirus trends offers guidelines for protecting applications (SYMANTECVOICE: THE 2014 INTERNET SECURITY THREAT REPORT: YEAR OF THE MEGA DATA BREACH Forbes, 2014; WATERING HOLE 101, 2015) and apply all available patches. In (SHIEH et al., 2011) the authors propose the use of TPM chip to ensure the end-host security and provide a trusted enforcement mechanism to apply network policies at end-hosts.
3.1.2 API security and Application code vulnerabilities
Insecure Application Programming Interface (API) is one of the major problems in SaaS and PaaS. In order to provide security from both intentional and accidental attempts to circumvent the security policies, a strong API access control is required. In (SIRISHA; KUMARI, 2010) the authors propose an API access control using Role Based Access Control (RBAC). The proposed solution divide the access into two stages: 1) attribute validation mechanism; 2) role validation mechanism. In this study the authors consider that the user is authenticated by one authentication scheme.
Application code vulnerabilities are one of the major security concerns in all environ-ments. In cloud computing environment the application development should respect the secure Software Development Lifecycle (SDLC) (ALMORSY et al., 2010). SDLC focused in cloud computing applications development considers aspects related to adaptive security to ensure the proper security controls, enforcement, and management.
(MICROSYS-3.1. APPLICATION SECURITY 39
TEM, 2002) that is a Application Programming Interface (API) used to facilitate the application development that need authentication and authorization routines.
Other security API is the Enterprise Security API (ESAPI) (JUNKER, 2012) that provides to application developer a set of security controls to makes easier the secure web development.
3.1.3 Considerations about application security
Table 3.1 summarizes the application security countermeasures mentioned in this section.
Table 3.1: Application security countermeasures
Area Countermeasure Reference Issue(s)
Web browser security
SSL/TLS connection (ALFARDAN et al., 2013) DS
XML DoS prevention
(JENSEN; GRUSCHKA;
HERKENHÖNER, 2009) AS; PS; CAS
(CROCKFORD, 2006) AS; CAS
XML Security (WS-Security, Reliability, and WS-Transaction API ) (SUBASHINI; KAVITHA, 2011) DS; AS; PS; CAS
Signing XML messages (SOMOROVSKY et al., 2012)
Strict DTD rules (NOLAN et al., 2014) DS; AS; PS;
CAS AJAX integrity check
routine (RAUTI; LEPPÄNEN, 2012)
End-user remote attestation using TPM
(BIN MAT NOR; JALIL;
MANAN, 2012) CAS
Antivirus check routine and apply all available patches
(SYMANTECVOICE: THE 2014 INTERNET SECURITY THREAT REPORT: YEAROF THE MEGA DATA BREACH Forbes, 2014)
PS
Browser and host integrity
measurement (SHIEH et al., 2011) PS; CAS
API security and
Application code
vulnerabilities
Strong API access control (SIRISHA; KUMARI, 2010) AS; PS; MT
Secure Software Development Lifecycle (SDLC)
(ALMORSY et al., 2010) AS-01; PS;
MT Java Authentication and
Authorization Service (JAAS)
(MICROSYSTEM, 2002) AS; PS; MT
Enterprise Security API
(ESAPI) (JUNKER, 2012) AS; PS; MT
Considering the solutions summarized in Table 3.1 we can consider that the main security concerns related to application might be minimized, mitigated, and, in most cases, avoided. However, the user should not trust that the Cloud Service Provider (CSP) properly implements the security procedures needed.
