Thiago Gomes Rodrigues - UFPE · Thiago Gomes Rodrigues CLOUDACC: A CLOUD-BASED ACCOUNTABILITY FRAMEWORK FOR FEDERATED CLOUD A Ph.D. Thesis presented to the Center for Informatics

Thiago Gomes Rodrigues

CLOUDACC: A CLOUD-BASED ACCOUNTABILITY FRAMEWORK

FOR FEDERATED CLOUD

Ph.D. Thesis

Federal University of [email protected]

www.cin.ufpe.br/~posgraduacao

RECIFE2016

www.cin.ufpe.br/~posgraduacao


CLOUDACC: A CLOUD-BASED ACCOUNTABILITY FRAMEWORKFOR 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 KelnerCo-Advisor: Patricia Takako Endo

RECIFE2016

Catalogação na fonteBibliotecá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.

004.36 CDD (22. ed.) UFPE-MEI 2016-157


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 FeitosaInstituto 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 writingof this Thesis. I know the lack I made during the weekends that I had to work just as you did tome, 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 believingme, 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 myThesis, 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 thatyou 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çosde Tecnologia da Informação (TI) tem evoluído. Em ambientes de nuvem a complexidadede realizar accountability apropriadamente é alta porque as evidências devem ser coletadasconsiderando-se as camadas física, de virtualização e de aplicações, que estão espalhadas emdiferentes servidores e elementos da infraestrutura. Esta complexidade é ampliada quando ocorrea federação das infraestruturas de nuvem porque além da complexidade inerente ao ambientevirtualizado, os membros da federação podem não ter os mesmos grupos de políticas e práticas desegurança. O principal objetivo desta tese é propor um framework de accountability, denominadoCloudAcc, que suporte processos de auditoria, gerenciamento, planejamento e cobrança, emnuvens federadas, aumentando a confiança e a transparência. Além disso, o CloudAcc tambémconsidera os requisitos legais para a salvaguarda dos registros, conforme descrito no Marco Civilda Internet brasileira. A efetividade do CloudAcc foi confirmada quando alguns componentesda 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 oCloudAcc contribui para o estado-da-arte, uma vez que fornece uma visão holística do ambientede nuvem federada através da coleta de evidências em três camadas suportando os processos deauditoria, 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 properlyperforming accountability, since the evidences are spread through the whole infrastructure, fromdifferent servers, in physical, virtualization and application layers. This complexity increaseswhen the cloud federation is considered because besides the inherent complexity of the virtualizedenvironment, the federation members may not implement the same security procedures andpolicies. The main objective of this thesis is to propose an accountability framework namedCloudAcc, that supports audit, management, planning and billing process in federated cloudenvironments, increasing trust and transparency. Furthermore, CloudAcc considers the legalsafeguard requirements presented in Brazilian Marco Civil da Internet. We confirm the CloudAcceffectiveness 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 holisticvision of the cloud federated environment through the evidence collection considering thethree layers, supporting audit, management, planning and billing process in federated cloudenvironments.

Keywords: Cloud federation. Accountability. Cloud security. Transparency. Law compliance

List of Figures

2.1 User security responsibility in delivery models . . . . . . . . . . . . . . . . . . 252.2 Monolithics and microservices . . . . . . . . . . . . . . . . . . . . . . . . . . 272.3 Monolithic architecture diagram . . . . . . . . . . . . . . . . . . . . . . . . . 272.4 Microservice architecture diagram . . . . . . . . . . . . . . . . . . . . . . . . 28

4.1 Federated Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.2 Configuration settings sample . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.3 CloudAcc Agent collection layers . . . . . . . . . . . . . . . . . . . . . . . . 564.4 MIB tree used by agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.5 General overview of CloudAcc Core . . . . . . . . . . . . . . . . . . . . . . . 584.6 SecMM conceptual model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.7 PKI Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.8 Data classification and impact of disclosure . . . . . . . . . . . . . . . . . . . 624.9 Integrity Control Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.10 Client Authentication Supported . . . . . . . . . . . . . . . . . . . . . . . . . 654.11 Secure storage diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.12 Key Hierarchy diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.13 Generic diagram of the PBKDF . . . . . . . . . . . . . . . . . . . . . . . . . 674.14 Centralizer workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.15 Monitor Module architecture overview . . . . . . . . . . . . . . . . . . . . . . 704.16 Report Module architecture overview . . . . . . . . . . . . . . . . . . . . . . 72

5.1 Test scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.2 Authentication Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795.3 Seven steps of a succesful cyber attack . . . . . . . . . . . . . . . . . . . . . . 805.4 Proxy Memory Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.5 Proxy CPU Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825.6 Radius Memory Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835.7 Radius CPU Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

List of Tables

2.1 Access Control security issues . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.1 Application security countermeasures . . . . . . . . . . . . . . . . . . . . . . 393.2 Network security countermeasures . . . . . . . . . . . . . . . . . . . . . . . . 413.3 Data security solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.4 Virtualization security countermeasures . . . . . . . . . . . . . . . . . . . . . 463.5 Accountability acting areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.1 Minimal requirements by certificate type . . . . . . . . . . . . . . . . . . . . . 604.2 Security requirements to protect NSS systems up to TOP SECRET level . . . . 61

5.1 Performed tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.2 SecMM factors and levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765.3 Results for 3DES running in Google Cloud. . . . . . . . . . . . . . . . . . . . 775.4 Results for AES-128 running in Google Cloud. . . . . . . . . . . . . . . . . . 775.5 Results for AES-192 running in Google Cloud. . . . . . . . . . . . . . . . . . 775.6 Results for AES-256 running in Google Cloud. . . . . . . . . . . . . . . . . . 775.7 AM factors and levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785.8 Paired Tukey’s Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785.9 Agent evidence collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

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

GCM Galois Counter Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

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

PCR Platform Configuration Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

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

TPM Trusted Platform Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

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

XML eXtensible Markup Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Contents

1 Introduction 181.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.3 Organization of the Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2 Background Concepts 222.1 Security concerns in cloud delivery models . . . . . . . . . . . . . . . . . . . 22

2.1.1 Cloud Federation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.1.2 Considerations about cloud delivery models . . . . . . . . . . . . . . . 24

2.2 Accountability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.3 Microservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.4 Access Control security issues . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.4.1 Physical access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.4.2 Credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.4.3 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.4.4 Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.4.5 Identity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.4.6 Data security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.4.7 Application security . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.4.8 Multi-tenancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.4.9 Considerations about Access Control . . . . . . . . . . . . . . . . . . 32

2.5 General Security Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.5.1 Perimeter Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.5.2 Virtualization Security issues . . . . . . . . . . . . . . . . . . . . . . . 342.5.3 Considerations about security issues . . . . . . . . . . . . . . . . . . . 36

3 Related work 373.1 Application security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.1.1 Web browsers security . . . . . . . . . . . . . . . . . . . . . . . . . . 373.1.2 API security and Application code vulnerabilities . . . . . . . . . . . . 383.1.3 Considerations about application security . . . . . . . . . . . . . . . . 39

3.2 Network security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.2.1 Considerations about network security countermeasures . . . . . . . . 41

3.3 Data security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.3.1 Considerations about data security countermeasures . . . . . . . . . . 42

3.4 Virtualization security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.4.1 Considerations about virtualization security countermeasures . . . . . . 45

3.5 Access Control security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.6 Inter-cloud Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.6.1 RESERVOIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.6.2 Cloudbus InterCloud . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.6.3 Open Cirrus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.6.4 STRATOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.7 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4 CloudAcc 524.1 CloudAcc Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.2 CloudAcc Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.2.1 Infrastructure perspective . . . . . . . . . . . . . . . . . . . . . . . . . 554.2.2 Virtualization perspective . . . . . . . . . . . . . . . . . . . . . . . . 564.2.3 File-centric perspective . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.3 CloudAcc Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.4 Security Management Module (SecMM) . . . . . . . . . . . . . . . . . . . . . 59

4.4.1 Public-key Infrastructure Service . . . . . . . . . . . . . . . . . . . . . 604.4.2 Encryption/Decryption . . . . . . . . . . . . . . . . . . . . . . . . . . 614.4.3 Integrity Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.5 Authentication Module (AM) . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.5.1 User Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.6 Storage Management Module (SMM) . . . . . . . . . . . . . . . . . . . . . . 654.6.1 Password-based Key Derivation . . . . . . . . . . . . . . . . . . . . . 674.6.2 User master key recovery routine . . . . . . . . . . . . . . . . . . . . 68

4.7 Logger Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.7.1 Cloud Centralizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

4.7.1.1 Extract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.7.1.2 Merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

4.7.2 Monitor Module (MM) . . . . . . . . . . . . . . . . . . . . . . . . . . 694.7.2.1 Monitor Module architecture overview . . . . . . . . . . . . 70

4.7.3 Report Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.7.3.1 Report Module architecture overview . . . . . . . . . . . . . 71

4.7.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

5 Results 745.1 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.1.1 Testbed description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.2 Security Management Module Performance analysis . . . . . . . . . . . . . . 765.3 Authentication Module Performance analysis . . . . . . . . . . . . . . . . . . 785.4 CloudAcc analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.4.1 DoS Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.4.2 Brute Force Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

5.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

6 Final Considerations 856.1 Challenges and Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . . . 866.2 Future works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

References 89

Appendix 100

A Collected Evidences 101

181818

1Introduction

The computational service delivery evolved according to users’ necessities - that wasincreasing the rigorousness of the requirements along the years -, and can be divided in fivedistinct eras: monolithic, client-server, web, Service-Oriented Architecture (SOA) and cloudcomputing (DAGGER et al., 2007; ERL, 2008; ARMBRUST et al., 2010). Following thisevolution, the way in performing accountability also had to adapt in order to provide propermechanisms 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 asame program from a single platform. Accounting routines were made concerning the evidencespresented in one platform type only. The client-server paradigm was commonly used in the80s. Applications developed in this paradigm are divided into two parts, client and server, whichcan be run on diverse machines with different hardware architectures. During the 90s, the webera arrived. With the popularization of the Internet and the evolution of design patterns, theweb development made possible the creation of applications that could be accessed through theInternet or an Intranet. The SOA paradigm has emerged in the 2000s. The main principle of theSOA is to provide all applications’ functionalities as a service. These services are often connectedthrough a bus, called Enterprise Service Bus (ESB). Finally, the cloud computing paradigmhas appeared approximately in 2008 with the distributed computing strategy to provide the bestusage of computing resources. These last ones, distribute the system evidence among differentmachines with different hardware architectures, Operational Systems, and infrastructures also,increasing the complexity in performing accountability properly. Moreover, the cloud computingparadigm has a virtualization layer that must be accountable.

Focusing on the last era, cloud computing brings many advantages for both provider andcustomer. From the provider perspective, clouds facilitate the infrastructure management, provid-ing resource control mechanisms (dynamic allocation, elasticity) and at same time, minimize thecosts to infrastructure investments (MELL; GRANCE, 2011). On the other hand, from customerperspective, clouds represent a good and easy model to rent computational resources, offeringon-demand self-service with pay-as-you-go model.

Besides these advantages, clouds have also received many financial investments and

1.1. MOTIVATION 19

have evidences that they are a profitable business area. Cisco and Forbes are trying to create aroadmap to quantify the cloud computing importance for the next years. Cisco expects to see theGlobal Datacenter IP traffic growing three-fold by 2017 (NETWORKING, 2013). According toForbes, "end-user spending on cloud services could be more than $180 billion. It is predictedthat 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 NationalInstitute 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 andsecurity 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 canincrease even further when different cloud infrastructures are interconnected.

Considering clouds interconnection, some authors classify it as cloud federation orinter-cloud. The first uses the providers’ interface, while inter-cloud is based on future standardsand open interfaces (TOOSI; CALHEIROS; BUYYA, 2014). Nevertheless, both approachesaim to obtain interoperability (ARMBRUST et al., 2010); in this way, we decided to use cloudfederation 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, geographicdistribution to deal with disaster recovery and low latency access, avoiding vendor lock-in, as wellas cost efficiency and energy savings (BUYYA; RANJAN; CALHEIROS, 2010; ARMBRUSTet al., 2010; AOYAMA; SAKAI, 2011).

In cloud federation, new services can be offered by combining service components fromdifferent cloud customers. Interoperability between different clouds may be affected by integra-tion problems and security breaches. In addition to the security concerns inherent to virtualizedenvironments, 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, inaddition 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" isone of the key functions for a proper accountability mechanism. The other key functions ofa proper accountability mechanism are storing and retrieving the log data, and increasing theliability, transparency, responsiveness, responsibility, and controlability. Therefore, if the cloudcomputing 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 accountableinfrastructure must provide sufficient evidences for audit process, infrastructure management,planning, and billing. Furthermore, cloud users can trust that their contracts will be fulfilledfollowing 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 fourprocedures, 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 (PAWLUKet 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 donot consider legal aspects related to the registry’s safeguard, neither are able to provide differentconfigurations according to the user needs. They also do not provide alerts routine when detectsome SLA metric violation, contractual clauses, or nonstandard activities.

1.2 Objectives

Considering the aforementioned motivations, the main objective of this Thesis is topropose and evaluate a Cloud-based Accountability Framework for Federated Clouds, namedCloudAcc, based on microservices architecture capable to enable audit process, infrastructuremanagement, 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 proposean architecture for the CloudAcc;

� Model the CloudAcc architecture as microservices to support easy scaling andintegration with other frameworks or tools.

As said previously, works in the literature consider and treat data monitor and analysisonly in one layer; as our main contribution, the CloudAcc has a centralized analyzer thatconsiders the physical layer, virtualization layer and application layer.

We consider that the evidences existing in physical, virtualization, and applicationlayers 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 CloudAccuses them to measure. In virtualization layer, the CloudAcc may prove that the SLA metricswere 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 auditingprocess and detecting malicious activities.

Other key contribution provided by the CloudAcc is the log storage in compliance withthe Brazilian law named "Marco Civil" that specifies requirements related to informationtemporality and confidentiality.

Finally, CloudAcc framework functionalities are modeled as microservices to supporteasy 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 asfollows: Chapter 2 will describe the basic concepts and security issues. Chapter 3 we willpresent its countermeasures that we will consider to implement our solution. Chapter 4 describethoroughly each framework module. Each module has different architectures with well-definedrequirements and purposes. Chapter 5 presents the results and performance tests. Finally, inchapter 6 we will present the conclusions and the final remarks and future works.

222222

2Background Concepts

Considering the objectives of the thesis previously described, this chapter presentsthe background concepts necessary to comprehend our proposal and solutions. First, we willdescribe the security concerns in cloud and cloud federation concepts. Then, we will present theaccountability concepts. After that, we will introduce some concepts related to microservices. InSection 2.4 we will present the concerns related to access control, and finally, in Section 2.5 wewill 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 servicessuch as email, document writer, Enterprise Resource Planning (ERP), Customer RelationshipManagement (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 thesecurity measures taken by the provider. The provider has to manage users and assign to eachone his security policies that can be related to information sharing, information access andediting. Moreover, the provider could not ensure the software availability whenever the customerrequests, 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 infrastructureservice provided by other provider (e.g. Google, Microsoft Azure, and Amazon) or on its ownprivate server farm. By using a third-party provider they reduce the investment in infrastructureservices and can also take advantage of cloud facilities to focus on improving services forcustomers.

The data related to business processes are considered by enterprises as important strategicassets that are directly related to decisions that will be taken. However, in SaaS, all data is storedon 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 locationsand may or may not be within the same country of the enterprise. Consequently, the concernsrelating data storage and its protection, data breaches, application vulnerabilities, and availabilitygenerate 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 ProgrammingInterfaces (APIs). In this type of model, the consumer does not need to worry about problems inhardware and software layers (SUBASHINI; KAVITHA, 2011). On the other hand, the consumerhas no control over cloud infrastructure including operating system, network, or storage, butstill 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),Heroku 1, and Microsoft Windows Azure 2.

The security responsibilities in PaaS model are divided into two layers: the security ofthe platform (i.e., APIs, frameworks, Software Development Kits (SDKs)) and the security ofcustomer’s applications (MATHER; KUMARASWAMY; LATIF, 2009). APIs, frameworks,and SDKs work as an interface between cloud customers and cloud service providers. Theyprovide a transparent access to cloud facilities and must be properly designed to protect againstboth accidental and malicious attempts to avoid the access policies to prevent that malicioususers compromise the infrastructure security and / or applications. The security off all platformsoftware are on the provider’s responsibility and the responsibilities of applications security areon the customer.

In the PaaS model, the security concerns related to users’ data follows the same concernsthat those in SaaS model. Moreover, this model has its own concerns like relationships with otherplatforms that can impact the security of applications. The PaaS model provides to consumersa set of features ready to be used. Through the use of SOA, PaaS provider allows applicationsto transparently consume the necessary resources when they are in the provider’s infrastructureor in a trusted third-party. In addition, PaaS models also inherit the security concerns relatedto data and networks, and also should be concerned about the safety of development tools andoutsourced third-party relationships (XU et al., 2009). Other security concerns are related to userauthentication that will be discussed on subsection 2.4.3.

In the Infrastructure-as-a-Service delivery model, a set of features are available to usersas virtualized systems that can be accessed over the internet (ALMORSY et al., 2010). Theseresources can be, for example, servers, storage and networking. In this model, users have allcontrol 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 requirementsand 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 thesecurity over the computing process, networking and storage infrastructure. Other substantialefforts over service’s provider responsibility are related to safeguard security in the creation

1www.heroku.com2azure.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 disasterrecovery, geographic distribution and low latency access, interoperability and avoiding vendorlock-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. Inan 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 brokerapproach uses a service broker to translate messages among cloud interfaces making theminteroperate with each other. A combination of these two approaches aforementioned oftenoccurs in practice.

In (CELESTI et al., 2010a), the authors consider the cloud computing evolution in threestages:

� Monolithic stage, each cloud provider creates its own architectures. Cloud servicesare delivered by different providers in this stage.

� The vertical supply chain stage can be called delegation or vertical federation. Inthis stage some provider can create its services using other provider’s infrastructureslike 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 mustoccur 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 thesecurity practices and where it needs to be performed. Figure 2.1 depicts the user responsibilityin 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 securityissues involving Hypervisor, CPU, Networking, Storage, Backup, and Datacenter layers must beprovided 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 securityconcerns related to storage are under user responsibility. Consequently, the CSP is responsible inprovide security procedures in the rest of the platform.

2.2 Accountability

Accountability is a concept that has different meanings. In (KOPPELL, 2005) theauthor proposes five important aspects of accountability: transparency, liability, controllability,responsibility, and responsiveness. The author considers transparency and liability as the mainimportant foundations of the accountability’s concept. Transparency provides the way needed toassess organizational performance results. Liability means that organizational members shouldbe 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 systemaccountable 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: validation, attribution,and evidence. Validation allows users to verify if everything works as expected. Attributionallows in the case of fault, the responsibility can be assigned. Evidence is an artifact used toconvince when a dispute arises. They identified "falsifying record collection", "tampering withrecords" and "destroying or suppressing the transmission of records" as main threats againstintegrity 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 forensicinvestigation (FARINA et al., 2015). Furthermore, an accountable infrastructure must providesufficient 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 thattheir records may be checked.

2.3 Microservices

Microservices (micro-services or micro services) is another software architecture relatedterm emerging out of Service-Oriented Architecture (SOA), emphasising self-management andlightweight functionalities. Although, this terminology describes a new style of software systemsmore appealing for cloud applications.

The first time that the term microservice was discussed was in 2011. In 2012 thesame group decided on "microservices" as the most appropriate name to this kind of softwarearchitectural implementation (LEWIS, 2012). Based on (NEWMAN, 2015; LEWIS; FOWLER,2014), microservices architecture provides functional decomposition of an application. Thefunctional decomposition of an application achieves loose coupling (by a well defined interface),and high cohesion (well defined functionalities), enabling for instance, agility, flexibility, andscalability (KILLALEA, 2016).

The main idea behind microservices applications is to build tiny applications with singleresponsibilities. According to (NEWMAN, 2015; LEWIS; FOWLER, 2014), organizationaround business capability, intelligence in the endpoints, decentralized governance, decentralizeddata management, deployment/infrastructure automation, design for failure, and evolutionarydesign as the main principĺes that characterises a microservice architecture.

Before explaining the microservice architectural style, we will first compare it to mono-lithic one. An application is considered monolithic when it is built as a single unit. The commonapplications 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. Despiteimplementing all functionalities in a single a unit, monolithic applications can provide loosecoupling and high cohesion too. However, the monolithic approach does not provide the sameadvantages, mainly, considering the scaling routine. Figure 2.2 depicts the architectural styledifferences between monolithic application and microservices considering scaling routine.

Supposing that the application supports the three functionalities represented in Figure 2.2as black circle, gray circle with plus inside, and the light gray hexagon. Considering the scalingroutine, a monolithic application is scaled by replicating at all parts of the software in differenthosts. In microservice architecture, only the needed elements are scaled across the servers.

Detailing the difference between monolithic and microservices applications, Figures 2.3and 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

In both approaches the software architecture provides loose coupling and high 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 througha REST API and may not running in the same machine. Moreover, when scaling the serviceimplemented considering the architecture illustrated in Figure 2.3, all modules will replicatedbut considering the architecture illustrated in Figure 2.4, the replication will occur only in theneeded microservice.

However, the microservice architecture gives some drawbacks. Problems related todistributed 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 authenticationusing both username and password combination. In cloud computing environment this type ofauthentication 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 securityconcern. In addition, provide the physical and logical resources segregation for each user,authentication and authorization requirements, physical access, credential access, and identitymanagement (BOWERS; JUELS; OPREA, 2009a) are the main access control issues and will bediscussed as follows.


2.4.1 Physical access

The physical access control is the key control to ensure the integrity, reliability andreputation of the cloud infrastructure. Attackers exploiting physical access are called maliciousinsiders (PANAH et al., 2012; YU et al., 2012; AHUJA; KOMATHUKATTIL, 2012) that couldbe an ex-employer, disgusted employer, spies, or any other type of malicious actor who usesphysical access to compromise the security of the infrastructure.

The negative impact caused by a malicious insider is quite large. In the scenario ofa datacenter for example, different business data from different users are stored in the samephysical location. A malicious insider could use his privileged access to provide the data leakagefrom sensitive business information. In a more complex attack, the attacker could grant sysadminprivileges 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 andaccess directly the running VM memory content (NIST, 2015).

Reasearchs by (KANDUKURI; PATURI; RAKSHIT, 2009; ZOU; ZHANG, 2011) showthat the impact of a malicious insider can compromise the entire infrastructure security. Inaddition, the attacker can remove the kernel modules that make the machine security, firewallsand 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 byAccess 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 commonrules 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 theLightweight Directory Access Protocol (LDAP) or Microsoft Active Directory (AD) to managethe authentication credentials in their infrastructures and assign to them, the proper access controlto 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 dataleakage, 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, theattacker can control all machines features through a valid credential (MODI et al., 2013).


2.4.3 Authentication

The goal of authentication is to ensure the veracity of any information being presentedthat 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-partyauthentication, and biometrics as credentials required in the authentication process (DINESHA;AGRAWAL, 2012). The tuple login / password is the most used and easy authentication methodimplemented nowadays. According to (HART, 2009) authentication using only textual passwordsare simple and do not provide the necessary security to prove the users identity. The third-partyauthentication 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 ofphysical presence therefore in scenarios like physical access control, biometric authentication isan 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 communicatewith each other services through a XML-based language called Security Assertion MarkupLanguage (SAML) (MANSFIELD-DEVINE, 2008) in order to exchange authentication andauthorization 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. Anattacker can block the user access by requesting the recovery routine. The remote authenticationproblems 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 - exploreweakness 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. Thisprocess is responsible for granting or not the access to the desired feature. The major securityissue 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-guessingattacks (TOP 10 - OWASP, 2013). Another security issue is related to malicious third-partyapplication e.g. (WARD, 2009). In a social network scenario, the user grant a third-partyapplication that maliciously collect all data usage and behavior.


2.4.5 Identity Management

The Identity Management (IdM) is a large administrative process that aims to identifyentities (e.g. individuals or enterprises) and cloud objects, controlling access to resources basedon policies that have been pre-established (ALMORSY et al., 2010). The IdM can be giventhree 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 theuser will present his identity and the access permission. The second perspective involvesorganizational 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: independentIdM 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 securityapplication to provide secure communication and storage. The federated model is necessary toensure 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 adequatesecurity (HUANG et al., 2016; KANAGASABAPATHI; DEEPAK; PRAKASH, 2016). Never-theless, many times the organizational data are processed in clear-text (without any cryptographicprocedure) and stored in the cloud remaining a responsibility to the service provider amongthe processing time and storage (JU et al., 2010). Also, we can consider the data backup as asecurity concern. If on the one hand the regular backup is important to facilitate recovery in caseof disaster, on the other hand it raises two concerns regarding the unsafe storage and insecureconfiguration (ALI; KHAN; VASILAKOS, 2015).

Other security concerns involving data security are related to the cloud distributednature where the user data could be stored in different physical location that involves regulatorycompliances related to data jurisdictions which have different laws (ERTAUL; SINGHAL;SALDAMLI, 2010; CARLIN; CURRAN, 2011; BISONG; RAHMAN et al., 2011). Althoughthis 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 WebBrowser (ARDAGNA et al., 2015). Although there are secure software development practices, itis still quite common the development of web applications with security problems. By exploiting


these vulnerabilities in web applications that attackers compromise the users’ machines andperform malicious activities like stealing users’ sensitive data (OWENS; AMERICAS, 2010).

The Open Web Application Security Project (OWASP) is an organization focused onimproving the security of software. All publications of this organization are free and haveopen software licenses. OWASP has listed the top ten most impactful security flaws in webapplications (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 maturitymodel is determined by the following characteristics: scalability, configurability via metadata, andmulti-tenancy (ZHANG; LIU; MENG, 2009; JU et al., 2010). Multi-tenancy is one characteristicof 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 allcustomers (CHONG; CARRARO; WOLTER, 2006), for this reason the use of security policiesare 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 environmentallows the attacker to gain access to sensitive enterprise data of other tenants, access to neighborrunning 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 arenot restricted to software solution because most of the weakness are related to human factorsinvolving expertise in security. To minimize the human factors in access control issues theCERT.br3 publishes a book containing best practices in Internet aiming to develop the usersecurity expertise. Other security expertise that must minimize the access control issues areinvolving the application development that may generate multi-tenancy and application securityproblems.

The security issues related to physical access and data security would be detected throughlog analysis. The physical security violation is under CSP controls. Considering that the CSPis in compliance with ISO27000, all physical access must be logged and the datacenter accessmust occur by 2-factor authentication. The data security violation may also be detected by loganalysis but not avoided by an accountability system.

We present in Figure 2.1 the user responsibility for each delivery model. Nevertheless, theCSPs must have their infrastructures accountable and capable in blaming each activity (malicious

3http://cartilha.cert.br/


Table 2.1: Access Control security issues

Topic ID Issue

Physical Access (PA)PA-01 Data leakagePA-02 Privileged access grantPA-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 routineAuthe-02 Weak password recovery routineAuthe-03 Remote authenticationAuthe-04 Brute-force and dictionary attacks

Authorization (Autho) Autho-01 URL-guessing attacksAutho-02 Vulnerabilities in third-party application

Identity Management (IdM)IdM-01

Independent IdM stack:- Unfollow organizational security policies

IdM-02Credential synchronization:- Synchronization through untrusted channel;- Insecure credential storage

IdM-03Federated model:- Improper trust validation relationship

Data Security (DS)DS-01 Data is processed and stored in clear-textDS-02 Insecure data transmissionDS-03 Unsafe storage

Application Security (AS) AS-01 Web applications vulnerabilitiesAS-02 Vulnerabilities in browsers and APIs

Multi-tenancy (MT)MT-01 Weak resources isolationMT-02 Data leakageMT-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 thatthe users report when not choosing cloud computing environment to support their applications.Furthermore, credentials, authentication, authorization and identity management issues are alsopresent in CSP infrastructures independently of the cloud service delivery because it must controlits users access. In fact, some successful access control exploitation may directly impacts inclients’ 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 networksand protocols also are. Furthermore, the evolution of network protocols to support dynamicscenarios are evidence of this change. Hence, the security community needs to adapt to thesedevelopments. 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 orgateways to separate the external environment from the internal and to form the DemilitarizedZones (DMZs). However, these static solutions are not efficient for dynamic scenarios such ascloud computing environments where virtual machines can migrate from one physical machine toanother 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 migratesto another server.

Service providers need to be concerned about two types of attackers: the externalnetwork attacker and the insider network ones. Commonly, an external attacker performs DoSor Distributed Denial of Service (DDoS) attacks in order to affect the availability of servicesand resources. These attacks reduce the bandwidth and increases the congestion causing loss ofservice 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) attacksis a very difficult activity (VIVINSANDAR; SHENAI, 2012). When the attacker is inside cloudenvironment, the impact of an exploitation is higher because the intruder has information aboutnetwork 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 allowaccess to machine resources. IP spoofing attacks, DNS poisoning, XSS, port scan, sniffing andspoofing 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 securityapplications behind the firewall mitigating external attacks. To mitigate the impact from maliciousinsiders 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 machinemanagement. As follows we detail the security concerns related to virtualization security.

Virtualization allows the abstraction of a hardware platform, operating system, andstorage device or network resources. Users can interact with virtual machines according to their


needs being able to create, delete, share, migrate, copy, and roll back virtual machines (WEIet al., 2009). The abstraction and isolation from real machine was made by introducing an extralayer called Virtual Machine Monitor (VMM) or Hypervisor. However, the VMM increases therange 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 attacksof a normal one. Therefore, the security of the physical machine becomes as important as thesecurity of virtual machines because any vulnerability exploitation on a physical machine candirectly 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 offailure in relation to physical machines due to the hypervisor layer that is responsible for theabstraction and isolation from the virtualized environment to physical one (REUBEN, 2007).

In addition to abstracting the hardware platform and isolating the virtual environment, thehypervisor 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 rangeof possible attacks as: compromise a migration module in VMM; copy of the virtual machinecontent 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 aremany security flaws pointing to isolation failure on virtualized environments making possibleattacks: 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 featuresthat each VMM implements. There are three groups of security issues related to virtual machinemanagement to be carefully observed: virtual machine repository; virtual machine rollback; andvirtual machine lifecycle.

IaaS environments, commonly implements public repositories with images of pre-configured virtual machines that are shared between users of the infrastructure. IaaS providerslike Google Compute Engine and Amazon public repositories of virtual machines where userscan 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 eachreplication of the image, the malicious code will be replicated. This fact will compromise otherusers 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 areimpactful and hard to be detected because the images in repositories are not running, disablingthe administrators’ track routine.


The VMM allow users to copy the states of their virtual machines. The virtual machinerollback is the process to return to a previously saved state. This feature may expose theinfrastructure to a large security issue related to re-expose the VM to errors or vulnerabilitiesthat 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 beenchanged.

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 corruptedmuch 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. Consideringthe attack nature, the passive attacks (e.g., port scan, and sniffing) are harder to be detected thanactive attacks. Passive attacks normally do not generate evidences enough to be detected by alog analyzer, differently than an active attack.

A proper accountability system does not avoid perimeter security violations but it mayprovide sufficient information for decision making. For example, analyzing the collectedregistries from a application server, the infrastructure administrator may detect DoS/DDoSattacks and create firewall rules to block them.

The virtualization problems are hard to detect. Besides the fact that a single physicalserver may virtualize several virtual machine instances, the log registries are distributed to thewhole platform.

A proper accountablitiy system could record unusual virtual machine and/or hypervisorsactivities. However, considering the entire federation, detecting the unusual behaviors is morecomplicated because each federation member has its own security procedures and defaultbehavior. The analysis of these records could detect intentional or unintentional changes thatcould lead to compromised virtual machine, the migration module and the virtual machinesrepository.

373737

3Related work

In this chapter, we provide a brief description of the related works that solve the securityissues mentioned on Chapter 2. The solutions that will be described were the basis for theconstruction of CloudAcc, once our framework is also a cloud solution and we would like toavoid 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 serviceprovider resources, applications, and/or services over a network via web browser. This Subsectionwill be divided into three parts: web browsers security, API security, and application codevulnerabilities.

3.1.1 Web browsers security

Web browsers are client programs that access the cloud services, applications and/orresources. They use Secure Socket Layer (SSL) / Transport Layer Security (TLS) protocolsfor secure data transmission and authentication. Browsers are point of security concerns be-cause once any vulnerability is exploited, it could compromise the application security. Cloudapplications use web services as technology (e.g., Simple Object Access Protocol (SOAP) andRepresentational 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 providedby XML use (platform independency, human readability, extensibility, and computational lan-guages compatibility) the processing overhead produced and resources by XML manipulationcan cause a special DoS on web services. In (JENSEN; GRUSCHKA; HERKENHÖNER,2009) , the authors proposed as countermeasures to processing overhead the total buffer sizerestriction for XML message and also apply a schema validation routine. The JavaScript ObjectNotation (JSON) could be an alternative to mitigate the processing overhead.

The SOAP uses XML to exchange information about services. The WS-Security is the

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 andWS-Transaction API (SUBASHINI; KAVITHA, 2011) that offers the necessary requirements toavoid MitM attacks. Other countermeasure necessary to avoid XML-based attacks is forwardingonly 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 MitBattack 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 communicationchannels) 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 mitigatethe MitB attack. In (BIN MAT NOR; JALIL; MANAN, 2012) authors proposed an remoteattestation using Trusted Platform Module (TPM) to grant the client platform integrity from theBIOS to browser software.

Other web browser vulnerability was founded by RSA in 2012 that affects MozillaFirefox, Internet Explorer and Chrome Browsers (WATERING HOLE ATTACKS, 2015). Thisattack is performed by injecting JavaScript or HTML on vulnerable sites that the victim frequentlyvisit to redirect to a separate site that contains a malicious code. As countermeasures antivirustrends offers guidelines for protecting applications (SYMANTECVOICE: THE 2014 INTERNETSECURITY THREAT REPORT: YEAR OF THE MEGA DATA BREACH Forbes, 2014;WATERING HOLE 101, 2015) and apply all available patches. In (SHIEH et al., 2011) theauthors propose the use of TPM chip to ensure the end-host security and provide a trustedenforcement 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 SaaSand PaaS. In order to provide security from both intentional and accidental attempts to circumventthe security policies, a strong API access control is required. In (SIRISHA; KUMARI, 2010) theauthors propose an API access control using Role Based Access Control (RBAC). The proposedsolution divide the access into two stages: 1) attribute validation mechanism; 2) role validationmechanism. In this study the authors consider that the user is authenticated by one authenticationscheme.

Application code vulnerabilities are one of the major security concerns in all environ-ments. In cloud computing environment the application development should respect the secureSoftware Development Lifecycle (SDLC) (ALMORSY et al., 2010). SDLC focused in cloudcomputing applications development considers aspects related to adaptive security to ensure theproper security controls, enforcement, and management.

Oracle proposes a Java Authentication and Authorization Service (JAAS) (MICROSYS-

3.1. APPLICATION SECURITY 39

TEM, 2002) that is a Application Programming Interface (API) used to facilitate the applicationdevelopment that need authentication and authorization routines.

Other security API is the Enterprise Security API (ESAPI) (JUNKER, 2012) that providesto 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 browsersecurity

SSL/TLS connection (ALFARDAN et al., 2013) DS

XML DoS prevention(JENSEN; GRUSCHKA;HERKENHÖNER, 2009) AS; PS; CAS

(CROCKFORD, 2006) AS; CASXML Security (WS-Security,WS-Reliability, and WS-Transaction API )

(SUBASHINI; KAVITHA,2011) DS; AS; PS;

CASSigning XML messages (SOMOROVSKY et al., 2012)Strict DTD rules (NOLAN et al., 2014) DS; AS; PS;

CASAJAX integrity checkroutine (RAUTI; LEPPÄNEN, 2012)

End-user remoteattestation using TPM

(BIN MAT NOR; JALIL;MANAN, 2012) CAS

Antivirus check routineand apply all availablepatches

(SYMANTECVOICE:THE 2014 INTERNETSECURITY THREATREPORT: YEAROFTHE MEGA DATABREACH Forbes, 2014)

PS

Browser and host integritymeasurement (SHIEH et al., 2011) PS; CAS

API securityandApplicationcodevulnerabilities

Strong API access control (SIRISHA; KUMARI, 2010) AS; PS; MTSecure SoftwareDevelopment Lifecycle(SDLC)

(ALMORSY et al., 2010)AS-01; PS;MT

Java Authentication andAuthorization 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 securityconcerns 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 implementsthe security procedures needed.

3.2. NETWORK SECURITY 40

An accountability system could reduce the uncertainty linked to the environment throughapplying the security controls transparently, in accordance with the SLA and regulatory compli-ance.

Considering the aforementioned countermeasures, the use of SSL/TLS connections tosecurely transport the users’ data and from cloud services. Furthermore, the use of SDLC andStrong API access control to guide the CloudAcc implementation process should be consideredas best practices. We do not consider using the other countermeasures that involve modificationson client web browsers because they are not under accountability scope nor the CloudAccframework uses the technologies involved on its implementation.

3.2 Network security

Cloud network security countermeasures should be considered in terms of both externaland internal threats. Traditional solutions on network security aim to solve, mitigate or detectMan-in-the-Middle (MitM) attack, IP spoofing, port scanning, packet sniffing, ARP spoofing(SUBASHINI; KAVITHA, 2011).

Secure Socket Layer (SSL) / Transport Layer Security (TLS) is the countermeasurewidely used to prevent MitM attacks and transfer data securely by antrusted channel. Unfortu-nately, SSL/TLS has security flaws that involves misconfiguration or incorrect configuration inthe cipher suites. In (ALFARDAN et al., 2013; AL FARDAN; PATERSON, 2013) the authorsreport security flaws by using RC4 in TLS. The main countermeasure is stop using RC4 ascryptographic cypher. (ALFARDAN et al., 2013) proposed the use of authenticated encryptionschemes such as AES Galois Counter Mode (GCM) or AES-CCM that were standardized for TLSuse in RFC 5288 (SALOWEY; CHOUDHURY; MCGREW, 2008) and RFC 6655 (MCGREW;BAILEY, 2012) respectively. Other security problem linked to SSL/TLS is related to randomnessproperties of Pseudorandom Number Generator (PRNG) that is the base of the key generationin Rivest, S

Documents

Thiago Gomes Rodrigues - UFPE · Thiago Gomes Rodrigues CLOUDACC: A CLOUD-BASED ACCOUNTABILITY FRAMEWORK FOR FEDERATED CLOUD A Ph.D. Thesis presented to the Center for Informatics