Secure Administration of SEPA Servers in A Cloud Environment578948/FULLTEXT02.pdf · to my research. His quick response to my emails any time is the key behind my successful research

Secure Administration of SEPA Servers in

A Cloud Environment

Master Thesis in Information and Communication Systems Security

HAFIZ ADNAN EJAZ

Master’s Degree Project

Stockholm, Sweden 2012

TRITA-ICT-EX-2012:235

Acknowledgements

In the name of Allah the most merciful. All glory, respect and thanks go to

him now and forever.

My special thank goes to Prof Sead Muftic for his time, advices and guidlines.

Without these, completion of such a complex task was impossible. He always

showed great interest in my questions and discussions which gave right direction

to my research. His quick response to my emails any time is the key behind my

successful research. Thank you Professor for your help.

I would also like to thank to my parents for their motivation, support and

prayers. My family members and specially my Fiance who never let me down

even in many bad times. Thank you very much for being so nice with me.

Friends contributions can never be forgotton. So my friends who were my

coleagues as well in this research require great deal of such words which can

satisfy what they have done for me and SecLab’s vice Admin (Feng) is also one

of them. Many of my overseas friends who gave me support were the key of

my confidence during this research. I must mention a name here to show my

gratitude ”Hafiza Iqra Khalid” for her help and support. There are many other

names and friends who lost in storms of time demand that I should not miss

them. Many thanks to those missing names as well.

The last names to acknowledge are of my sisters GUDDi JAAN and GURIA

RANI for their prayers.

i

Abstract

Cloud Computing is the emerging way of getting benefit from technology.

Cheap solutions motivate everyone to put their heads into the wheel at least

once to increase their output. Cloud computing provides three different levels

of services. SaaS, PaaS and IaaS, which are very attractive for consumers. This

attraction is also very charming for banking industry, as cloud computing suits

this industry in many ways. Banks do not need to spend money on IT resources

and can get all within a cloud. However, it is not so easy in adoption, as it

seems in words. Many genuine concerns arise about how banks can work in

such environment. There are many risks to face (data and credentials security,

privacy) which can only be understood after working in such an environment.

Our research focuses on development of such an infrastructure where we can

test these risks and address their solutions. After the initial study in this area,

we found the service model of cloud computing, which suits the best banking

industry, is IaaS. Therefore, we configured relevant servers, setup basic frontend

and developed a cloud platform with basic authentication and authorization

services.

After successful implementation of this cloud platform with some other appli-

cations, we developed a banking solution named SEPA Secure Banking which

is our main research area for banking system. We made our SEPA banking

solution operative inside our cloud system to analyze the security risks and

concerns a bank can have. We also implemented standard security services as

s result of our findings.

ii

Nomenclature

B2B SEPA Business to Businees

BIC Business Identifier Code

CMS Content Management System

CMSMS CMS Made Simple

CRM Customer Relation Management

DOS Denial of Service

DSS Data Security Standards

ECB European Central Bank

EPC European Payment Council

IaaS Infrastructure as a Service

IBAN International Bank Account Number

IDAMS Identity and Access Management System

NIST National Institute of Standard Technology

PaaS Platform as a Service

PCI Payment Card Industry

PDP Policy Decision Point

PEP Policy Enforcement Point

PIN Personal Identification Number

POI Point of Interaction

PTS PIN Transaction Security

iii

SaaS Software as a Service

SAML Security Assertion Markup Language

SCT SEPA Credit Transfer

SDD SEPA Direct Debit

SEPA Single Euro Payment System

SLA Security Level Agreement

XACML eXtensbile Access Control Markup Language

XML Extensible Markup Language

iv

List of Figures

2.1 Layered Cloud Architecture . . . . . . . . . . . . . . . . . . . . 6

2.2 Control over Resources in different Services Models . . . . . . . 7

5.1 Global Security Architecture . . . . . . . . . . . . . . . . . . . . 27

5.2 Portal Security Architecture . . . . . . . . . . . . . . . . . . . . 28

6.1 Cloud Secure Applications Broker . . . . . . . . . . . . . . . . . 34

6.2 Cloud Shared Security Providers Home Page . . . . . . . . . . . 34

6.3 Login Page for SEPA Portal . . . . . . . . . . . . . . . . . . . . 35

6.4 Cloud Secure Banking Admin Portal . . . . . . . . . . . . . . . 36

6.5 Cloud Secure Banking Add Admin Panel . . . . . . . . . . . . . 36

6.6 Cloud Secure Banking Add Bank Panel . . . . . . . . . . . . . . 37

6.7 Cloud Secure Banking Register Bank Form . . . . . . . . . . . . 37

6.8 Cloud Secure Banking List Banks Panel . . . . . . . . . . . . . 38

v

Contents

Acknowledgements i

Abstract ii

Nomenclature iii

List of Figures v

1 Introduction 1

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1 Audiences . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1.2 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Research Methodology . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Motivation and Scope . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4 Outlines and Organization . . . . . . . . . . . . . . . . . . . . . 4

2 Secure Cloud Banking 5

2.1 Cloud Services Architecture . . . . . . . . . . . . . . . . . . . . 5

2.1.1 SaaS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.2 PaaS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.3 IaaS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Security Requirements . . . . . . . . . . . . . . . . . . . . . . . 9

3 Single Euro Payment Area (SEPA) System 11

3.1 SEPA Direct Debit Transactions . . . . . . . . . . . . . . . . . . 12

3.2 SEPA Credit Transfer Transactions . . . . . . . . . . . . . . . . 13

3.3 Security Features and Requirements of the SEPA System . . . . 14

3.3.1 Data Protection . . . . . . . . . . . . . . . . . . . . . . . 14

3.3.2 Card Security . . . . . . . . . . . . . . . . . . . . . . . . 15

vi

CONTENTS

3.3.3 Terminal/POI Security . . . . . . . . . . . . . . . . . . . 15

4 Security Features of Cloud/Virtualization Platforms 18

4.1 Governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.2 Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.3 Trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.3.1 Insider Access . . . . . . . . . . . . . . . . . . . . . . . . 20

4.3.2 Data Ownership . . . . . . . . . . . . . . . . . . . . . . . 20

4.3.3 Composite Services . . . . . . . . . . . . . . . . . . . . . 20

4.3.4 Visibility . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.3.5 Ancillary Data . . . . . . . . . . . . . . . . . . . . . . . 21

4.3.6 Risk Management . . . . . . . . . . . . . . . . . . . . . . 21

4.4 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.4.1 Attack Surface . . . . . . . . . . . . . . . . . . . . . . . 22

4.4.2 Virtual Network Protection . . . . . . . . . . . . . . . . 22

4.4.3 Virtual Machine Images . . . . . . . . . . . . . . . . . . 22

4.4.4 Clientside Protection . . . . . . . . . . . . . . . . . . . . 23

4.5 Identity and Acccess Management System . . . . . . . . . . . . 23

4.5.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . 23

4.5.2 Access Control . . . . . . . . . . . . . . . . . . . . . . . 23

4.6 Software Isolation . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.6.1 Hypervisor . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.6.2 Attack vectors . . . . . . . . . . . . . . . . . . . . . . . . 24

4.7 Data Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.8 Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.9 Incident Response . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5 Design of the Secure SEPA System 26

5.1 Architecture and Components . . . . . . . . . . . . . . . . . . . 26

5.1.1 Central Security Servers . . . . . . . . . . . . . . . . . . 27

5.1.2 Portal Security Server . . . . . . . . . . . . . . . . . . . 27

5.1.2.1 Web Server . . . . . . . . . . . . . . . . . . . . 28

5.1.2.2 PEP Server . . . . . . . . . . . . . . . . . . . . 28

5.1.2.3 Proxy Server . . . . . . . . . . . . . . . . . . . 29

5.1.2.4 Virtual Private Network . . . . . . . . . . . . . 29

5.1.3 SEPA Bank Server . . . . . . . . . . . . . . . . . . . . . 29

5.1.4 SEPA Customers . . . . . . . . . . . . . . . . . . . . . . 30

5.1.4.1 SEPA Web Wallet . . . . . . . . . . . . . . . . 30

vii

CONTENTS

5.1.4.2 SEPA Mobile Wallet . . . . . . . . . . . . . . . 30

5.1.5 Security Services . . . . . . . . . . . . . . . . . . . . . . 30

5.1.5.1 Initial Authentication . . . . . . . . . . . . . . 30

5.1.5.2 Single Sign-on (SSO) Authentication . . . . . . 31

5.1.5.3 Authorization . . . . . . . . . . . . . . . . . . . 31

5.2 SEPA Security based on Openstack . . . . . . . . . . . . . . . . 31

6 Implementation and Demo 32

6.1 Contents Management System . . . . . . . . . . . . . . . . . . . 32

6.1.1 Windows: xampp . . . . . . . . . . . . . . . . . . . . . . 32

6.1.2 Linux/Ubuntu: Apache,MySQL,PHP . . . . . . . . . . . 33

6.1.3 CMSMS Setup . . . . . . . . . . . . . . . . . . . . . . . 33

6.1.4 Templates: HTML, CSS, PHP jQuery and JSP . . . . . 34

6.2 Demo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

7 Future Work 39

A Bibliography 40

viii

Chapter 1

Introduction

1.1 Introduction

Today we are living in a global village and everybody wants to have resources

in the pocket that meet his/her needs. Accessiblity is quite easy and almost

everybody knows how and where he/she can have requied resources, but the

thing stops them to satisfy their wishes is the affordability. Resources are

expensive and to make them available at cheap and affordable rates has become

the center of everybody’s intentions. Banks in this regard are key players

which give easy loans to pay for our resources and take responsibilities on their

shoulders to be everywhere for us. Thanks to the Internet, which acts as cloud

for our global village and we remain connected to access everything online.

Banks not only facilitate us with easy loans, but we are also highly dependant

on them in our routine life for paying bills, rent etc. This is one reason that

customers around the globe put pressure on bank servers to be alive and up all

the time no matter if a bank is small or large. Moreover, the business in which

banks operate requires the highest level of security. This type of secure, reliable

and alive services require good infrastructure with best available resources. In

a very competitive business enviornment larger banks can have their own infra-

structure, but smaller banks cannot afford heavy cost and they look for big

companies which can provide them with infra-structure and the best services

at cheap rates. This is one reason that modern trends of cloud computing

and virtualization are in a spot light for infra-structure and service provider

companies to provide cheap services via cloud.

1

CHAPTER 1. INTRODUCTION

Another aspect banks have to consider is currency variance from country to

country. If we can introduce one currency, some overheads of the banks can be

eliminated. Also this can benefit to customers. Conversion from local currency

of one country to local currency of another country during visit, shopping and

in other transacting will no longer be an issue for the customers. European

Payment Council’s project SEPA is a big and good step towards eliminating

currency conversion problems.

The term SEPA is an abbreviation of Single Euro Payment Area. SEPA is

the ongoing European Payment Councils (EPC) project to introduce single

currency transactions (Euro) within and outside European premises. According

to EPC, SEPA depends on three main players: Public Authorities, Banking

Industry and Bank Customers for its success. We will discuss further details of

SEPA in chapter 3 [1].

Virtualization is the technique of providing resources without their physical

existence. We can define virtualization as: ”To softly gather the distributed

physical resources (servers, nodes) into one hardware for efficient utilization

and better computing”. The concept of virtualization is very old, but now-

days it has got increased importance. We can use this approach for many

reasons: e.g sometimes hardware (servers specially) is being underutilized and

sometimes overloaded. Servers are costly in their maintenance, upgrades and

operations. Virtualization has two main types: Hypervisor-based technology

(XEN, VMware, MS Virtual Server) and OS level virtualization (OpenVZ,

Linux VServer, Solaris Zones). There are many tools available in the mar-

ket to work with virtualization, OpenVZ, Virtual Box, Xen 3.1 and VMWare

are some examples of them [2].

1.1.1 Audiences

In recent years Banking and IT industry has developed valualbe mutual re-

lationship. Visa card, Mastero Card, Internet banking, etc are only possible

with the help of IT. On the other hand, banking industry has helped IT indus-

try by providing easy loans for research and development purposes. Banking

industry is also providing IT industry with multiple business areas like chips

on the cards, machines to read chips, terminal devices, etc. We can say both

industries are equally important for each other to offer best solutions to human

beings. Therefore, this thesis work addresses to both Banking and IT industry

2


professionals at the same time to take a further step and move in to the cloud.

1.1.2 Prerequisites

Basic knowledge in Banking industry is sufficient to understand one portion of

this research i.e. what is SEPA System and how it can benefit to the customers.

But understanding virtual environment, hypervisors, security and servers re-

quire advanced knowledge in IT field. At least Bachelor’s in Computer Science

with focus on virtualization technology with basic banking knowledge are pre-

requisites to understand this research.

1.1.3 Limitations

Virtualizaiton requires high performance hardware, huge amount of memory

and backup systems. We were short of such good server and memory disks.

1.2 Research Methodology

The main objective of research is to find or investigate hidden aspects and

sometimes reveal new facts to support an idea. Every research study has its

own goals, area of concentration, and methodologies to adopt. The method-

ology we used in our thesis is Development Research. We used this approach

as we had first to design the structure and then to develop it. Development

included research tools and a model to be implemented using different tools

and programming languages. Development research also gives some specific

featuers different from other research approaches, e.g formative evaluation and

problems and dilemmas in development. On the basis of all these factors this

approach fully fited in our requirements as our task was to develop a complex

structure with some new functions [3].

Motivation behind a research is the key factor which drives the whole process.

There are different types of research approaches e.g Descriptive, Analytical,

Applied, Fundamental, Quantitative, Qualitative, Conceptual, Empirical, etc.

Depending on the type of research two basic approaches for research style exist.

Quantitative and qualitative. We are using qualitative approach, which includes

assessments, discussions and opinions [4].

3


1.3 Motivation and Scope

Security is an important ingredient in modern day technologies where internet

has given an easy access to everybody, everywhere over everything available

publically and even privately. Since SEPA is purely a financial service dealing

with day-to-day customers and business giants in huge amounts, there is a big

question of its security for every consumer and customer. This is one motivation

behind this research.

IT is the backbone of modern banking industry and people now like to use

their mobile phones for payments as they use them for other purposes. These

modern trends of dealing with mobile phones as wallets is a big motivation to

implement security of such systems.

SEPA has to play a big role in IT industry in coming years by introduction

of SEPA cards, smart phones which can read SEPA cards, faster processors,

etc. Banks will need to have updated hardware to meet quick, efficient and

smart banking with high security softwares, firewalls and identity management

systems. Scope of this thesis lies in these areas of IT which need upgradation

for SPEA success [1].

1.4 Outlines and Organization

In this thesis we focused on deployment of web-servers, cloud infra-structure,

Virtualization inside the cloud and above all security of this whole system.

Organization of this report is as follows:

Chapter 1 is introductory chapter of the thesis. Chapter 2 is all about cloud

secure banking, services architecture and technologies. In chapter 3 brief de-

scription of SEPA, SEPA Services and security requirments of SEPA system are

mentioned. Chapter 4 is a general overview of security features of cloud and

virtualized environment according to Natioin Institute of Standard Technology

(NIST). Chapter 5 describes our Secure SEPA System design and chapter 6 is

about how we implemented different things, what tools we used in this the-

sis and small Demo. Finally, chapter 7 summarizes what future we can do to

improve and enhance this research.

4

Chapter 2

Secure Cloud Banking

Cloud has an attraction for small and medium companies, because of its zero

investment property. Organizations do not need to invest heavy capital to pur-

chase server racks, data centers, network devices, and storage devices [5]. Cloud

also gives attractive offer of sharing resources to cater with underutilization of

resources issue in big companies. Another attraction in cloud computing is the

reduction of manpower and improvements of efficiency without extra costs. But

banking industry is a sensitive industry and its data is very confidential. This

is the main reason why banking industry has a great concern with ”whether

cloud is a secure way of banking”. According to concerns what is secure cloud

and how can we define it, everybody has its own definition of security. This is

the one big thing acting as a hurdle in adoption of cloud computing for banking

industry. It raises the need of some cloud standards acceptable to everybody

in order to call it a secure cloud.

To understand security concerns of cloud and their implications for banking

industry, first we should be familiar with cloud services and their architecture.

2.1 Cloud Services Architecture

Virtualization technology is an important pillar of cloud technology. It provi-

sions cloud technology to use servers, networks and nodes independently while

located on a common platform. Software as a Service (SaaS), Platform as a

Service (PaaS) and Infrastructure as a Service (IaaS) are three different service

models of cloud technology which use virtualization as their fundament. These

5

CHAPTER 2. SECURE CLOUD BANKING

services models cae be layered on top of four different cloud deployment models:

Public cloud: Cloud services organization selling services to public or indus-

tries in the market.

Private cloud: Cloud infrastructure of an organization for its use only. The

ownership of such a cloud can be by the organization itself or by a third party.

Community cloud: This type of cloud infrastructure can be owned by a

group of organizations having the same policies and requirements or a third

party. It is a shared infrastructure amongst several organizations of the same

concerns.

Hybrid cloud: A composition of two or more clouds of any other type: private,

public, community is called a hybrid cloud [6].

In a layered architecture of cloud computing, cloud services reside on the top.

Figure 2.1 explains the overall architecture [7].

Figure 2.1: Layered Cloud Architecture

In these cloud services, control over resources varies from both customer’s and

provider’s point of view. Triangle in Figure 2.2 shows cloud services stack, and

6


arrows indicate increasing control of resources from both perspectives. SaaS

service model offers lowest control of resources to customers whereas in PaaS

service model, control of resources is equally distributed. IaaS gives maximum

control of resources to customers which is shown with a down arrow in Figure

2.2. Up arrow on right of the triangle shows provider’s perspective which is

totaly opposite to customer’s perspctive in cloud services model.

Figure 2.2: Control over Resources in different Services Models

2.1.1 SaaS

In a cloud services architecture, SaaS is on the top in context of cloud provider’s

control. Organizations using SaaS can only use softwares of their need, but

cannot administer, modify, install or delete them. Organizations who are con-

sumers of such services are billed according to the type of software, count of

the users using software application, utilization time and data storage etc.CRM

is one of the most used application under SaaS cover. In year 2006, Microsoft

proposed a maturity model for SaaS based on its attributes. This maturity

model has four different levels as follows:

Level I: This level of maturity model is Ad Hoc or Custom level. Each customer

at this level gets seperate and distinguished instance of hosted and customized

application. At this level it is not more different than traditional software

selling with a little advantage of reducing hardware cost and software support.

[8]:

7


Level II: This is configurable level of the maturity model. Each customer at

this level gets also a separate instance of hosted applicaion, but these instances

are customizable. Every user can cutomize the application according to its

needs [8].

Level III: Maturity at this level is Configurable and Multi-Tenant-Efficient.

Vendors run one instance of application and use configurable metadata for

every user. One running instance introduces the concerns of data seperation,

authorization and security. This level allows efficient utilizaiton of resources,

but at the same time it has a drawback of scalability [8].

Level IV: Final level of maturity model is Scalable, Configurable and Multi-

Tenant-Efficient. Vendors can offer load balancing between the customers along

with data separation, security and privacy [8].

2.1.2 PaaS

PaaS is the second service model of cloud technology and it lies in the middle of

the cloud stack as far as control in concerned. Cloud providers and consumers

enjoy almost the same level of abstraction in this service model. PaaS con-

sumers themselves control the installation, maintainance and configuration of

softwares whereas providers are responsible for providing only hardware plat-

form (servers, networks etc.). PaaS can also be used to create multi-tenancy

and includes GUIs, user management, security administration, etc. Amazaon,

Google, Saleforce.com are big PaaS providers and have enhanced the concept of

SaaS. Google has introduced Apps Engine and has a great attraction from the

consumers. Salesforce on the other hand has a focus on enterprise applications.

Sandbox solution from Amazon to use its infastructure is also very important

[12].

2.1.3 IaaS

IaaS virtually provides physical servers, complete data-centers, networks under

one umbrella with the help of virtualization technology. It is the third and last

service model in a cloud computing technology. It is also at the last level of

control stack from provider’s perspective, but on the top of stack from con-

sumers perspective. Consumers of IaaS enjoy full rights of selection. IaaS layer

8


is the lowest layer and nearest to actual hardware. That is the reason why it

is hidded fron IaaS and PaaS consumers.

Characteristics of cloud services are on-demand self service, broad network

access, resource pooling, rapid elasticity and measured service.

2.2 Security Requirements

Security in cloud technology is important at multiple levels starting from the

base (physical level) and ending at the top (applicaton level). If we have a

look to cloud architecture in Figure 2.1, we can identify different areas where

security issues can be raised. Important factor is that these issues have to

be catered by cloud providers. Cloud security involves some extra concerns

like audit, policy management, incident response in comparison with normal

security concerns of the system which include authentication, authorization,

integrity, confidentiality, availability. Depending on cloud’s basic architecture

(service model, deployment model and key players like consumer, provider,

auditor, broker and carrier) cloud offers many attacks weak points to be looked

at, like IT Security, Data Security, Data Transfer Security, etc. [13].

From the service model point of view security issues will be different at different

service level e.g. SaaS, PaaS, IaaS will have their own concerns. Similary, if de-

ployment model of cloud is public, it will be open for everybody on the Internet.

Eavsdropping, spoofing and other security threats from every attacker will be

higher as compared to private clouds which are dedicated to one organization

only. Splitted level of control in cloud environment creates the need for col-

lective security solutions from providers and consumers contrary to traditional

security solutions, where one organization enjoys control over the entire in-

frastructure. Security concerns for hybrid and community clouds have another

direction of collective threats (threats of both public and private clouds).

Cloud Secure Banking addresses most of these security concerns of virtual-

ization technology and service models. It also relies on SLA between key

cloud players and banking industry, which should cover overall security con-

cerns. Architecturally there should be a SLA between cloud consumer and

cloud provider, cloud provider and cloud carrier, cloud auditor and cloud con-

sumer, cloud provider and cloud auditor, cloud broker and cloud auditor, cloud

broker and cloud consumer, cloud provider and cloud broker. We describe

9


standard security concerns, for cloud environments mentioned by NIST [9], in

chapter 5.

10

Chapter 3

Single Euro Payment Area

(SEPA) System

Single Euro Payment Area (SEPA) is the ongoing Euroapean Payment Coun-

cils (EPC) project to integrate customers in 32 countries into single currency

domain within and outside European Union premises. SEPA will offer the fa-

cility of making all types of payments between any accounts in Euro without

being considering the borders limit. All national and cross border transactions

will be done in the same way as domestic transactions within SEPA domain.

At the moment SEPA services include SEPA Direct Debit (SDD) and SEPA

Credit Transfer (SCT) which can only be done using SEPA cards. Customers

within Europe (European Union, Iceland, Liechtenstein, Norway, Switzerland

and Monaco) can rely on single bank account and single bank card after imple-

mentation of SEPA. EPC is working as the regulatory body in this project and

providers (banks) need to motivate to the customers to use this facility for the

success of SEPA. SEPA uses International Bank Account Number (IBAN) and

Business Identifier Code (BIC) for identification of accounts in SEPA domain.

Relevant ISO standards have been followed to use IBAN and BIC.

SEPA schemes has enough potential for IT industry in the form of SEPA cards,

new delivery channels, better Graphical User Interface (GUI) and improved

payment architecture. IT industry can implement new security models, digital

signatures, to reduce fraud and prevent attacks on ongoing transactions. IT can

help SEPA to propagate fast by winning customer’s trust and SEPA can help IT

by providing different area’s of exploration, research and development. Banks

will need new software packages SEPA schemes e.g in a SCT session, initiator’s

11

CHAPTER 3. SINGLE EURO PAYMENT AREA (SEPA) SYSTEM

id, receipt of credit transfer, how to support BIC and IBAN in a transaction

and new message format according to ISO 20022 will have to be provided in

one software solution. Many other functions include rejection, returns, etc.

also need updated software with these functions supported according to EPC

standards and rulebook.

Chips for SEPA cards will give a lot of business to hardware vendors. Fast

processors with integrated systems to read SEPA cards (chips) is another big

business, research and implementation are for IT providers. In short, every as-

pect of SEPA is glued with IT industry to provide best services to the customers

in a cheap way.

3.1 SEPA Direct Debit Transactions

SEPA Direct Debit (SDD) Schemes were launched in November 2009 which in-

clude SEPA Core Direct Debit and SEPA Business to Businees (B2B) scheme.

SDD B2B is out of our focus area at the moment, as we are working for con-

sumers side and SDD B2B is for business. SEPA Core DD scheme entertains

consumers and every bank in Euro area has to ensure this service for the con-

sumers, whereas B2B service is optional for tha banks. SDD is a normal debit

scheme which takes care of consumer’s rights and satisfaction. It is both cred-

itor and debtor driven, as these two models are being used in EU member

states. Both models use a mandate for authorization. A mandate is a signed

paper agreement of authorization which expires after 36 months of last collec-

tion date from consumer’s account. Mandate can also be issued electronically,

when it is called e-mandate. For issuance of an e-mandate consumers use the

same credentials as they use for online banking. Use of e-mandate involves all

three entities: debtor, creditor and bank. Payer gets a billing form from its

seller website, gives his account identification and other required information.

Seller transfers received e-mandate to payer’s bank. payer then get its own

bank website to prove his identity and account rights. In this way payer gives

confirmation of e-mandate to its bank and then payer is routed to seller’s web-

site again. Seller’s website then acknowledges the receiving of e-mandate. It

depends on every individual bank how they deal with availability of e-mandates.

In Creditor Driven mode the payer of a transaction signs a mandate and sends

it to a creditor. Responsibility then lies with creditor for collecting money from

12


payer’s account and storing the original mandate as well as other information

for future use. In this model payer’s bank gets neither information regarding

mandate signed by the payer nor has any right to check the payment going

out from payer’s account. The whole scenario is based on the trust between

creditor and the payer. If something goes wrong, SEPA consumers has the

right of getting money back without any question asked within 8 weeks from

the date of transaction. This limit of moneny refund can be extended to thirteen

months, if there is any indication of unauthorized transaction of fraud from the

consumer. Moreover, SDD payments are fully traceable upto an initiator of the

payment to identify it. In this way fraud is discourgaed and can be eliminated

under SEPA schemes.

In Debtor Driven mode the signed mandate by payer is not given to the biller.

Rather it stays with the payer’s bank. For any transaction, the biller contacts

to payer’s bank and shows its desire to get the payment. In this scenario bank

has the option of checking the authorization of the biller from payer. This is the

main difference between creditor driven and debtor driven mode of payment.

For customer satisfaction European Commission and European Central Bank

(ECB) have assured that all national and legal rules of any country will be met

up to certain level in the SEPA Direct Debit scheme. As ECB is in charge of

keeping control over EPC, it motivates EPC to take some further steps in order

to win customer’s trust with the help of European Commission.

3.2 SEPA Credit Transfer Transactions

SEPA Credit Transfer (SCT) Schemes was launched in January 2008. It was

the first step taken by banks in achievement of SEPA and implementation of

ISO 20022 message standards. This scheme is applicable only for transactions

in Eruos and in 32 countries mentioned above. Payments under SCT scheme

has no charges and deductions. Payment service provider of the customer can

charge its customers only according to their agreed agreement. It gives cus-

tomers the option of adding 140 characters message with a transaction and se-

cures the original message. One of the main advantages of SCT scheme is that

banks working under SEPA rules work without borders, so national and cross

border transctions are treated in the same way. In SCT it is recommended that

credit should be transfered to customer’s account within two banking working

13


days along with receipt of transaction. For customer’s ease an optional param-

eter of originator identification code can also be attached with the information

of a transaction. This code is helpful for return payments.

Currently active Rulebooks and other associated documents for SEPA DD and

SEPA Credit Transfer can be found on European Payment Councils website

[1].

3.3 Security Features and Requirements of the

SEPA System

SEPA services (SDD and SCT) are available to use by three different means

i.e. SEPA cards, SEPA mobile and SEPA cash. All three ways have their

own security risks and requirements to be considered. EPC has discussed these

requirements in security requirements book for SEPA single set of cards and

terminal security. An overview of these considerations are as follows [14]:

3.3.1 Data Protection

EPC will ensure data protection according to PCI DSS (Payment Card Industry

Data Security Standards). First requirement according to PCI DSS council is

regarding network infrastrucutre which should be secure. Access control lists

and firewalls can be used to gaurantee the highest level of security. Hackers

keep a deep eye on vendors systems and algorithms which generate default

passwords. Next requirement towards data protection is to use secure and

different passwords for sensitive systems. Techniques like hashing, masking and

encryption on the very top should be used to secure cardholder’s information.

Hackers cannot read actual data without cryptographic keys even if they get

access to encrypted data. It is important that all the transmissions coming

under this domain must be encrypted to protect data in public networks. A very

important factor to be considered in this regard is being up-to-date. Antivirus

softwares must be regularly updated against different attacks under different

situations. After making system secure by applying these standards, application

developers should also consider security within their applications. Cardholders

trust their organizations and in return organizations must assure the access to

only relevant persons according to business needs. Every person accessing the

14


data must have been provided with a unique identification and logs should also

be maintained for every action from any accessor. Despite access to data via

computer and Internet, system containing this data must be physically out of

the reach of malicious persons. Access to every node and service in the network

must be maintained where cardholder’s data is placed. Keep on auditing the

security systems and processes. Policies must be maintained in such a way that

guarantee every body’s security. [14] In case of shared hosting, providers must

assure its capability to secure that environment in which card holder’s data will

be placed.

3.3.2 Card Security

Smartcards should have basic capabilities from a large set of capabilities of

smartcard mentioned by EPC. For example, smartcard should be able to select

and initiate appropriate application. It should have capability of communicat-

ing with terminal and doing authentication in offline mode. Smartcard should

have the ability of generating unique certificates binding to each transaction in

order to avoid transaction modification attack. It is the payment application

which defines the flow of transaction, so that algorithms must be used which

exhibit lowest duplication of authentication certificates. Smartcard must have

the ability to authenticate the right cardholder during transaction and auto-

matically count failed attempts of PIN in order to block the card after specific

count. Smartcard should have the capability of reacting against denail of ser-

vice attack. Continuous payment transactions should be checked by the card

itself according to its security policy, to check if card is under attack.

3.3.3 Terminal/POI Security

Concerning security of terminal devices, EPC wants to move security evalu-

ation requirements for devices from local vendors approach to a unified eval-

uation approach. All device manufacturer should implement EPC’s security

requirements for terminal/POI devices. For vendors ease and to avoid ambi-

guities, initially EPC proposed to consider PCI POS PED 2.0 as baseline [14].

Later PCI PTS 3.0 was said to be considered as baseline, the newer version of

PCI POS PED 2.0. EPC added some extra requirements which were felt to

be missing in PCI PTS 3.0 according to SEPA environment. These are called

15


EPC Plus Requirements and jointly with PCI PTS 3.0, these complete EPC’s

Security Requirements for Terminal/POI devices. Vendors of the devices have

to ensure security requirements and should get a ”SEPA wide Certificate” as

an approval for their devices to be used in the SEPA domain. In this way a uni-

fied security approach can be achieved and EPC can make sure card in SEPA

domain are being processed in the same and secure way. EPC also focuses on

maintenance procedures for future threats and vulnerabilities not addressed at

the moment.

POI device claiming itself a secure device should fullfil the following require-

ments of evaluation model by EPC.

Physical Security: Device should have atleast two independent security mech-

anism one operative and other as backup. It should have the ability to erase

sensitive data e.g. cryptographic key from the machine in case of any attack.

Device should be capable of bearing altering environmental and opertaional

conditions. If there are any audibles against PIN, all digits should sound the

same to avoid any security compromise.

Logical Security: After physical security of the device logical security of the

device is almost of same importance. Logical security of device includes self

assesment of integrity and authenticity on startup. Before updating firmware

cryptographic authentication of update should be done by the device. In case

of any input (e.g. command or some other entry) device should be capable of

behaving normal and deal with such things in an appropriate manner. PIN en-

tered should not be visible in original digital form. After successful completion

of any transaction or in case of transaction time out, device should automati-

cally clear the buffer. Access to cryptographic keys, PINs and passwords must

require authentication and number of actions with sensitive data should be lim-

ited to minimize security risks. Techniques implemented in the device should

comply with standards like ISO 11568, ANSI TR-31 and TDEA. Vendors should

ensure that device handle different keys with different values. Data entry of

transactions data and PIN code data should be handled separately and never

print data in clear format accidentaly. [14]

Terminal/POI security has many other concerns e.g. Online PIN Security,

Offline PIN Security, POS Terminal Integration Security, IP and Link Layer

(IPLL), IP Protocols (IPP), Security Protocols (IPSP), IP Services (IPSV),

Security Management Compliance, Account Data Protection, During Manu-

16


facturing, Between Maufacturer and Initial Key Loading. [14]

17

Chapter 4

Security Features of

Cloud/Virtualization Platforms

Cloud computing is important for two main reasons: it cuts operational costs

and it cuts capital costs[15]. As business community always looks for cheaper

solutions, so for this reason people are moving their capital towards cloud com-

puting. According to AMI partners, research investment in cloud computing

will rise to 100 billion dollar in year 2014 [11]. This high penetration of invest-

ment shows that there will be more and more information, data and resources

in cloud. Where the presence of sensitive information in the cloud requires high

security for the cloud. On the other hand, technological layer of virtualization

also adds complexity and gives rise to security risks in cloud environments.

Cloud structure is different from regular data centers. Therefore we should

consider two levels of security: upper level security and lower level security.

Upper level security includes cloud security by preventing un-authorized access,

DOS attacks and other attacks of this kind. Lower level security includes

hardware and software level security (security in virtualizing infra-structure

like Guest OS isolation, OS monitoring, image and snapshot management). If

the components are properly secured security of the complete system will not

be compromised. In this regard individual security of Hypervisor and Guest OS

are very important. Possible threats to cloud security can be: cloud employees,

client employees, cloud providers themselves, network attackers and intruders

[10]. Attacks can be active, passive and all kind of attacks belong to network

are applicable to the cloud.

National Institute of Standards and Technology (NIST) defines three service

18

CHAPTER 4. SECURITY FEATURES OF CLOUD/VIRTUALIZATIONPLATFORMS

models in cloud computing: Software-as-a-service (SaaS), Platform-as-a-Service

(PaaS) and Infrastructure-as-a-Service (IaaS). These three types of services re-

quire three different levels of security described earlier. Well known IT industry

players, like Google, Microsoft and Amazon, are offering these services in a vir-

tual environment via cloud. NIST discusses Governance, Compliance, Trust,

Architecture, Identity and Access Manage System, Software Isolation, Data

Protection, Availability, and Incident response as security features for cloud

computing [9]. Some other security standards relevant to cloud include Infor-

mation Technology Infrastructure Library (ITIL), ISOIEC 27001/27002 and

Open Virtualization Format (OVF). ITIL is focused on the objectives of the

organization and then defines processes, procedures and instructions to achieve

those objectives [9].

4.1 Governance

Governance is equally important in public and private sectores and is related to

processes to measure the agreed policies and procedures for system management

and control. It defines the roles of people working in different organizations and

develops organizational relationships in a cloud environment. It is important

to ensure that systems are out of risk and everyone works within its own limits

not to raise any security risk. As a chance of security risk is always there,

governance implies the need of a risk management program to deal with any

situation.

4.2 Compliance

Compliance in cloud computing is a very complex issue as it has to deal with

different rules, regulations, laws and specifications. In case of many cloud

providers stored data location is not revealed to customers and the main rea-

son is that data is stored on physically distributed servers. Security risk for

customers is enhanced in this way, as they are unaware of security measures

taken, where their data is stored, and also legal and regulatory issues raised if

data is not stored on customer’s local server.

19


4.3 Trust

Trust on cloud provider is the key factor in a cloud environment. Provider can

win the trust of customer by guanrateeing the following facts:

4.3.1 Insider Access

Insider’s illegal access to company’s sensitive data is always a threat whether in

cloud or in a privately managed infrastructure. In previous years we have seen

many examples of such access. A reported incident of this type by Google [16]

confirms that these type of sensitive issues can happen inside the organization

itself. But, when data and processing is shifted to cloud environment, risk of

such access increases. For this issue cloud providers should offer the highest

level of access control security to the customers.

4.3.2 Data Ownership

Organizations cannot afford to compromise data ownership. Therefore, their

words on ownerhsip should be taken very carefully by cloud providers. Cus-

tomer and provider should sign strict contracts over confidentiality and privacy.

Providers should guarantee to the customers that their data is only their prop-

erty and providers will never use it for their benefit and purpose. License of

software for distribution to third party by cloud providers will not be given by

the customer in order to maintain ownership private.

4.3.3 Composite Services

There are many cases where a cloud provider uses services of another service

provider for its customers. In such a composite environment customer can

only bound its licences and agreements with its direct provider and has to rely

on provider for third party services that the provider is using. Providers can

involve consumers in these kind of composite services to some extent to win

their trust.

20


4.3.4 Visibility

To keep trust at a reasonable level, visibility plays an important role, but cloud

providers do not feel easy in giving a continuous monitoring and deep analysis of

their security measures to the customers. Providers do not want to share their

private information with their customers and by doing so the risk of becoming

vulnerable is high. Visibility is also very important if there exist composite

services which customer is using.

4.3.5 Ancillary Data

Security of customer’s personal details and private information is the main

concern of organizations providing sensitive services, e.g banking and payment

services. Organizations should sign agreements with cloud providers which

garauntee that such information will not be compromised in any case unless

some federal requirements are there. Attack on such database or any security

breach in the system can disturb the availability of this data to the customer

which can seriously harm organizations. Contracts between consumers and

providers regarding security and availability of ancillary data should be very

clear in order to build a trust.

4.3.6 Risk Management

Organizations lose their grip over many sides of the system when they move

to a cloud environment. Lightened grip force them to think differently about

risk management and rely on their providers in many cases. Risk management

becomes a big challenge for them as providers are mostly not willing to share

their risks with their consumers. Customers have to rely on privacy and security

measures of providers and providers should give them confidence of their data

protection and availability in any mishap by best risk management practices.

4.4 Architecture

We can say that cloud environment has kind of two layered architecture: cus-

tomer layer and providers layer. Customer layer is sometimes an app or web

21


browser used to initiate a request, whereas providers layer has sub-layers in-

side the cloud e.g. hypervisor, virtual networks, etc. This architecure of cloud

is important to understand to provide security. NIST describes the following

things we should consider in an architecture of a cloud: Attack Surface, Virtual

Network Protection, Virtual Machines Images, and Clientside Protection [9].

4.4.1 Attack Surface

Hypervisor makes life easy in virtualized environments by working as a middle

man between client and hardware resources. It manages resources, virtual

machines and multiple users, but the use of hypervisor increases security loop

holes inside a cloud. The compromise of a hypervisor can result in security

compromise of the whole system, e.g a vulnerability in VMware workstation

(vmnat.exe) was found in year 2005 by which any remote attacker can excute

commands of his choice [17].

4.4.2 Virtual Network Protection

Use of software-based switches is common practice in virtualized environments

for efficient and direct communications. But problem with this technique is

that traffic travelling through these networks is not visible to actual security

hardware and intrusion detection systems. Provider should use hypervisors

which have capability of traffic monitoring or can make traffic visible to security

devices. While doing so, security risks should be considered.

4.4.3 Virtual Machine Images

This is an easy way to compromise system’s security as keeping virtual ma-

chine images repositories to save state of virtual machine or reboot the virtual

machine is normal. If there exist any compromised image, it is sharing its vul-

nerabilities to the entire system. By updating with security patches and sharing

images in a controlled, managed and secure way providers can overcome this

security risk in a cloud environment.

22


4.4.4 Clientside Protection

Clientside protection is not an easy task and is out of control of the providers.

Massive use of smart phones and social media has made systems vulnerable

and very easy for hackers and attackers to penetrate into the sytem and exploit

it. Clientside can be made secure by restricting them to use only specific

applications. Moreover, encryption is another solution while communicating

with the server for logging.

4.5 Identity and Acccess Management System

We can overcome many security concerns by identifying the right entity and giv-

ing only the authorized access. Security Assertion Markup Language (SAML)

standards can be used to implement such solutions.

4.5.1 Authentication

It is the first step towards securing the system. Upcoming requests should be

forwarded to IDMS which uses SAML assertions to verify the identity. SAML

assertions also contain information regarding the access of the user. SAML is

secure because it uses an XML based protocol SOAP (Single Object Access

Protocol) to exchange information over HTTP and its messages are digitally

signed.

4.5.2 Access Control

SAML doest not focus on access control of the resources. For this purpose

eXtensbile Access Control Markup Language (XACML) can be used in a cloud

environment. XACML works with the help of Policy Enforcement Point (PEP)

and Policy Decision Point (PDP). PEP is responsible for resource protection

and PDP is responsible for decision making on the basis of policies. When

a request to any resource is received PEP forwards request to PDP to take

relevant authorization decision. XACML messages need to be protected against

any attack to ensure a valid access to resources.

23


4.6 Software Isolation

In IaaS clouds multi-tenancy on a single machine is to maximize utilization of

resources, efficiency and cost saving. Different applications on host operating

systems are a continuous threat to security if any loophole exists in any of

the applications in a combined environment. Thus, software isolation in these

environments is very important, which can be done using hypervisors and attack

vectors.

4.6.1 Hypervisor

Hypervosor technology for multiple virtual machine’s monitoring and control-

ling can also be vulnerable for security, as mentioned above. But carefully

designed hypervisors can help for software isolation by their management of

virtual machines.

4.6.2 Attack vectors

As mentioned above sharing resource as multiplte virtual resources provides an

easy opportunity to breach security in cloud environments where virtualization

is in use. Any malicious user can gain access to other virtual machines running

on a common platform or any other zero-day attack can result in huge loss.

Similar attack had been reported in 2009 which resulted in loss of 100,000

websites data due to an unknown vulnerability in virtualization application

[18]. Many attacks of the same and different kind can also be made that is why

measurement of attack vectors by cloud provider according to softwares in use

is a key requirement of security.

4.7 Data Protection

Organizations, especially banks are very reluctant to share their data on a

common place accessible to other organizations. Lost of personal information

of customers can ruin the business of a bank. On the basis of this threat data

isolation and protection is also one of the main concerns of the organizations

willing to use public cloud infrastructure.

24


4.8 Availability

In case of denial of service (DOS) attack, if data is not avaiable for a longer

period of time organization’s business could be affected. Along with security

of data, availability of data is important to keep work flow in an organization.

Scheduled disturbance for maintenance, updates or upgrades are not an issue for

organizations. If any serious problem, other than an attack occurs, it should

not be prolonged and become a permanent outage. Providers should show

serious concerns towards data availability to consumers in order to build trust

relationship with consumers.

4.9 Incident Response

Incident response indicates, after some failure in the system or any attack from

outside, how quickly the situation could be overcome. How quickly data and

resources are made available and what measures to be taken for security and

backup in the future. A deep eye analysis of such situations would be there

from cloud providers for satisfaction of the customer.

25

Chapter 5

Design of the Secure SEPA

System

In this chapter we discuss design of secure SEPA system which is developed

to provide Cloud Secure Banking services. In SecLab’s ongoing Secure Cloud

project, Secure SEPA system is a part of it as an application which also in-

teracts with cloud central security servers for authentication and authorization

services. SEPA system has three different and important modules with respect

to its architecture. These are: client module, server module and above them is

SEPA portal module. In this research our focus is on SEPA portal module, its

architecture and security services.

5.1 Architecture and Components

Cloud environments focus more on security and integrity, as we discussed ear-

lier. Therefore, being part of cloud environment SPEA system also has a focus

on security. We adopted AAA (Authentication, Authorization, Accounting)

security architecture. Proper authentication of users is important before they

join the system and authorization of resrouce access before a user start utilizing

it. Figure 5.1 gives an overview of central cloud security architecture, portal se-

curity architecture and communication links between both architectures before

providing access to SEPA resources.

26

CHAPTER 5. DESIGN OF THE SECURE SEPA SYSTEM

5.1.1 Central Security Servers

Figure 5.1 shows all the servers involved in central cloud security. This portion

is out of the scope of Secure Banking project, but it cannot be seperated from

SEPA as SEPA portal security is directly dependant on IDMS and SAML/PDP

servers of the central security system (described later in this chapter).

Figure 5.1: Global Security Architecture

5.1.2 Portal Security Server

In a secure cloud system, SEPA is available as a web service for the users.

These users can only be administrators (portal admin and bank admin) who

will use SEPA adminstration portal for multiple tasks. Portal administrator

in our system’s hierarchy is responsible to add users (bank admins) and assign

them roles. Portal security has web server, proxy server, PEP server and VPN

as its componenet, as shown in the Figure 5.2.

27


Figure 5.2: Portal Security Architecture

5.1.2.1 Web Server

Web server in context of this chapter refers to computer application, providing

web interface of the SEPA system to the users. We have implemented HTTP

on top of SSL protocol for a secure communication between clients and servers.

By using HTTPS, SEPA system can avoid man-in-middle attack and authenti-

cation of the web site can be ensured. In HTTPS, communiction on both sides

is encrypted, that futher helps SEPA system in strengthening its security by

avoiding eavsdropping, tampering and forging attacks to some extent [19][20].

5.1.2.2 PEP Server

Secure SEPA system uses policybased control to control access to resources.

Architecturaly policy control has two main elements: Policy Decision Point

(PDP) and Policy Enforcement Point (PEP). All policies are stored in the

28


PDP server and PEP initiates a request-response sequence with the PDP server

to make a deicison, based on policy stored at the PDP server. In the PEP

request message information about the resource (resource type, version, etc,

hardware/software) is sent towards PDP. PDP in response checks all resources

relevant policies (whether allowed or not allowed) and sends response message

back to the PEP server [22].

5.1.2.3 Proxy Server

One of many purposes of using proxy server is that it enhances system security.

Secure SEPA system uses proxy servers for two main reasons: first is cache,

because it will help the users in speeding up the resources access. Second is

security, because proxy servers will help in hiding IP address of actual server

and only IP address of proxy server is visible to external users. Proxy server

can also be configured as a firewall after maintaining a log in order to block

specific IPs and ports.

5.1.2.4 Virtual Private Network

SEPA system’s portal is only for administrators (portal administrators and

bank administrators) who also have to access bank interface. Banks are seperate

entity outside of SEPA system with their own security parameters on virutal

servers. For this communication between SEPA cloud and bank servers we

are using Virtual Private Network (VPN) technology, just to ensure secure

communication. This communication is only allowed after successful user login

and verificaiton of resource access authorization.

5.1.3 SEPA Bank Server

SEPA bank servers are organized in a hierarchical structure. We have National

SEPA servers and individual Bank SEPA servers. National SEPA servers will

communicate with Bank SEPA servers (domestic) in case of cross border trans-

actions. Otherwise, for domestic transactions, only Bank SEPA servers will

communicate with each other. Security between these servers and message de-

livery is out of the scope of this research it is handled by Secure SEPA Financial

Servers.[23]

29


5.1.4 SEPA Customers

SEPA customer include two types of potential customers (which we are calling

as clients/users): web clients and mobile clients. Both of these two types of

clients will initiate their communication by accessing web pages via web server

which is under portal security administration.

5.1.4.1 SEPA Web Wallet

For Web client services, we have named them as SEPA Web Wallet. Client

using web wallet can approach SEPA system only in one way i.e. a client

program (web browser) and will provide its identity using SEPA card. SEPA

web customers portion is handled under Secure SEPA Web and Smart Card

Clients research. [24]

5.1.4.2 SEPA Mobile Wallet

For Mobile client services the name is SEPA Mobile Wallet. Using Mobile

Wallet clients can access SEPA system via any mobile device (from market,

from their mobile etc) and will use the same card mentioned in SEPA Web

Wallet. SEPA mobile wallet research is handled under Secure SEPA Mobile

Clients portion. [24]

5.1.5 Security Services

SEPA system initially focuses on the following security services for all users

including regular bank users and administrators:

5.1.5.1 Initial Authentication

Initial authentication in SEPA system is done locally by each SEPA server

in order to check whether username and password exist and if that username

is correct. After initial authentication, SAML request-response exchange is

performed with IDMS in the central security server for proper authentication

of the user and its authorization to access requested resource.

30


5.1.5.2 Single Sign-on (SSO) Authentication

Proper authentication of users trying to access SEPA portal (regular bank users,

both administrators) is carried out by authentication server in the central se-

curity system. Authentication server checks with IDMS system first to check

if user is registered in its database [29]. If user is not registered in IDMS

database request is rejected and notification is sent back to SEPA server. If

user is registered and successfully verified in IDMS database, then the next

step of certificate checking is carried out by Certificate Authority (CA) server

[27]. After going through all phases in a successful manner, a user is authen-

ticated and request is forwared to SAML/PDP server for relevant policies and

authorization in the system.

5.1.5.3 Authorization

PDP is also part of the central security system of the cloud, whereas PEP

is part of SEPA portal security system. Authentication server as mentioned

above when passes request to PDP/SAML server, SAML/PDP server gener-

ates a ticket with some ticket expiry duration. This ticket is then passed to

PEP server. On the basis of received ticket, PEP allows/rejects the request

for further processing in the system and user can get access to the required

resources within SEPA cloud or be rejected [28].

5.2 SEPA Security based on Openstack

We are working in a full virtualized cloud environment where Openstack is

used to create virtualized environment. Openstack has its own identity service,

which is called Keystone. It keeps details of the user e.g. username, password

and permissions to the user etc [26]. Secure SEPA System is using it as an-

other security layer before allowing users to access a resource. More details are

available under project [25].

31

Chapter 6

Implementation and Demo

This chapter describes implementation of a cloud platform and integration of

the SEPA sytem into that platform, as described in previous chapter. Design

code of the whole system is presented in Appendices.

6.1 Contents Management System

Content Management System that we used for cloud infrastructure is CMS

Made Simple 1.10.3. It is an Open Source solution to manage contents online

which works in the same way for both windows and Linux operating systems.

It is designed in PHP and only requires basic knowledge of HTML and CSS to

work with it. CMSMS requires a pre installed web server and pre configured

database in order to run its setup.

6.1.1 Windows: xampp

Windows is normally not as friendly in engineering tasks as compared to Linux.

Configuring Apache web server and adding database and PHP means three

completely different tasks and every task requires some time. To cater with

this problem of Windows, we searched for an easy solution and found all in

one solution. Apache has its distribution combined with MySQL, PHP and

Perl and Apache Web server in one package are named xampp. It is a simple

installer and one can get all things working fine on a local machine. We used

xampp-win32-1.7.4 on our machines before installing CMSMS on them.

32

CHAPTER 6. IMPLEMENTATION AND DEMO

6.1.2 Linux/Ubuntu: Apache,MySQL,PHP

We used Debian distribution of Linux operating system (Ubuntu) at one of our

servers. Ubuntu community has a stack called LAMP (Linux-Apache- MySQL-

PHP) which can be used to install this basic setup. It is very simple and easy

solution and can be done with a couple of commands as following:

First installation is of taskel. It is a tool provided in Ubuntu which installs

more than one relevant packages [31].

sudo apt-get install tasksel

And next step is to install LAMP stack with this command.

sudo tasksel install lamp-server

If you are using some Ubuntu version other than Ubuntu server, you might get

some problems and in that case its better to install all these packages seperately.

Relevant commands are available in [32].

6.1.3 CMSMS Setup

After successful installation of web server and addition of PHP and database

we can install CMSMS through our local host. Before we proceed with CMSMS

setup we need to put its setup under our webserver and also to create an empty

database using MySQL and an empty PHP file named config.php. When all

things are done, user must type following in the browser:

http://localhost/cmsmadesimplefoldername

and you will get installation page of CMSMS to select language to use. Select

the options and go next from the wizard. At some point through the wizard,

it will ask for admin account information for CMSMS and basic site name to

manage contents. It will also ask for database type you are using and its root

username, password. It will then check all previliges needed and compatibility

issues and can also prompt in case of errors. Otherwise, success message will

be displayed. Detailed steps involved to configure CMS Made Simple can be

found in [30].

33


6.1.4 Templates: HTML, CSS, PHP jQuery and JSP

In setting up cloud portal and then SEPA portal we used different technologies

which are clear from section heading. HTML, CSS and PHP were needed

for CMSMS as it is easy to handle contents in a simple and quick manner.

Cloud Security Applications Broker’s home page (shown in the Figure 6.1) was

developed using these technologies.

Figure 6.1: Cloud Secure Applications Broker

Cloud Shared Security Providers home page (shown in Figure 6.2) was also

developed in the same way and managed by CMSMS.

Figure 6.2: Cloud Shared Security Providers Home Page

JSP is the main technology in which we developed our SEPA portal. Both,

bank clients and administrators and database are managed by MySQL. Xampp

supports both Apache and Tomcat webservers, so do not need to configure

34


Tomcat server seperately for our JSP pages. CMSMS compatibility with JSP

was an issue we had to cater with. After discussion, we found a suitable solution

of redirecting from CMSMS to relevant directory of the service and our com-

patibility problem was solved. jQuery and Javascripting is used where needed

for dynamic messages and alerts display in the system.

6.2 Demo

We tried to develop an easy solution for users. Therefore, its deomonstration

is very simple. Pictorial demonstration of the system is as follows:

Figure 6.3 shows login page for SEPA security portal. Login screen will prompt

when user (administrators only on this page) will click on left side small banner

”Cloud Secure Banking”.

Figure 6.3: Login Page for SEPA Portal

After successful login, user will enter into the portal where he/she can manage

banks, virtual servers, users (at this level users will be client administrators)

and administrators (SEPA admin and Bank admin). Again, login screen in

this figure represents second security layer of the system. Any user logged in

as administrator here has to provide its identity once again in order to get re-

source access. For example, in our demo user is trying to access Administrators

resrouce and is prompted for login information once again.

35


Figure 6.4: Cloud Secure Banking Admin Portal

If user is also verified at this stage, then he/she will go one step further into the

sytem to make changes. Current figure is for Add Administrators and Assign

Role. At the moment we have only one default Role, that is Bank Admin. If

user will click on Add Admin he/she will be provided with an API from Identity

Management System and all information for new user will be stored there. If

the next time that user tries to login he/she will be verified from IDMS.

Figure 6.5: Cloud Secure Banking Add Admin Panel

Administrators portal at this stage has two different users. One can manipulate

Banks only (Bank admin) and one can manipulate both Administrators and

Banks (SEPA admin). The user logged-in in this demo is SEPA Admin, so

that we can show complete working of the system. This stage is a new bank

registration stage insdie the system. When user clicks on Add Bank, he/she

will be prompted with the panel shown in Figure 6.7.

36


Figure 6.6: Cloud Secure Banking Add Bank Panel

Here user (Bank Admin) can register a new bank into the SEPA system. All

three fields shown in the Figure 6.7 (Name, BIC, Location) are mandatory

fields. If all the information provided here is correct a success message will be

shown. Duplicate entries can not be added in the system.

Figure 6.7: Cloud Secure Banking Register Bank Form

This figure further explains functions related to bank administration. Under

List Bank, we can select any bank to delete it from our SEPA system or to

modify its currents values. Last button ”Cancel” moves the user out of SEPA

system and user has to re-login if he/she wants to use portal again.

37


Figure 6.8: Cloud Secure Banking List Banks Panel

38

Chapter 7

Future Work

This project is in its initial stage of development, so a lot of future work has to

be done in all of its sections (clients, servers and portal administration).

In client/server environment, application specific security is an importat re-

search and development area which we have not focused in our research. All

communication between SEPA portal and client applications should be en-

crypted in order to make it secure channel. This is another area which can be

focused in near future. This will ensure end-to-end security in the system [14].

Redundancy is very important in case of any attack or other failures. In future

with extra functionalities and services in SEPA portal a good and updated

structure of implementation can also be done for lowest incident response time.

We are working in a virtualized enviroment and hypervisor is being used as

front end application. To restrict attack surface selection of best hypervisor

and to modify it according to our needs can also be done in the future.

39

Appendix A

Bibliography

[1] http://www.europeanpaymentscouncil.eu/

[2] A Comparison of Virtualization Technologies for HPC By: J. P. Walters,

Vipin Chaudhary, and Minsuk Cha University at Buffalo, SUNY Com-

puter Science and Engineering waltersj, vipin, [email protected] and Sal-

vatore Guercio Jr. and Steve Gallo The Center for Computational Research

University at Buffalo, SUNY sguercio, [email protected] [URL:

http://www.computer.org/portal/web/csdl/doi/10.1109/AINA.2008.45]

[3] Principles and Methods of Development Research. Chap-

ter 1. By Jan van den Akker, University of Twente [URL:

http://projects.edte.utwente.nl/smarternet/version2/cabinet/

ico design principles.pdf]

[4] Research Methodology: An Introduction http://www.limat.org/

[5] http://www.techrepublic.com/blog/datacenter/can-the-cloud-be-safe-for-

banks/5197

[6] http://www.cloudtweaks.com/2012/07/the-4-primary-cloud-deployment-

models/

[7] Robert Bohn NIST Cloud Computing Reference Ar-

chitecture & Taxonomy Working Group [URL:

http://cloudstandardscustomercouncil.org/062011/presentations/

NIST RA 062111.pdf]

[8] http://msdn.microsoft.com/en-us/library/aa479069.aspx

40

APPENDIX A. BIBLIOGRAPHY

[9] NIST: Guidelines on Security and Privacy in Public Cloud

Computing, by: Wayne Jansen, Timothy Grance [URL:

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

[10] http://technet.microsoft.com/en-us/library/cc723507.aspx

[11] http://www.crn.in/Software-019Aug010-SMB-Cloud-Spending-To-

Approach-100-Billion-By-2014.aspx

[12] Platform as a Service (PaaS) What Is It? Why Is It So Im-

portant? An NJVC and Virtual Global Executive White Paper

Kevin L. Jackson General Manager, Cloud Services, NJVC Cary Lan-

dis Senior Platform Architect and Founder, Virtual Global [URL:

http://www.slideshare.net/kvjacksn/njvcvirtual-global-paas-white-paper]

[13] http://www.computerweekly.com/opinion/Why-banks-are-wary-of-

public-clouds

[14] (Version 5.5 Draft) SEPA CARDS STANDARDISATION (SCS) VOL-

UME BOOK OF REQUIREMENTS Chapter 5 Security Requirments

[URL: http://www.europeanpaymentscouncil.eu/

knowledge bank detail.cfm?documents id=560]

[15] Cloud Computing Basics, Chapter 1,http://www.south.cattelecom.com

/Technologies/CloudComputing/0071626948 chap01.pdf

[16] http://www.computerweekly.com/news/2240088530/Google-mail-

collapses

[17] http://packetstormsecurity.org/0512-advisories/ACSSEC-2005-11-25-

0x1.txt

[18] http://www.theregister.co.uk/2009/06/08/webhost attack/

[19] Network Working Group, Request for Comments 2818, E. Rescorla [URL:

http://www.ietf.org/rfc/rfc2818.txt]

[20] Network Working Group, Request for Comments, 2817, R. Khare, 4K

Associates / UC Irvine and S. Lawrence Agranat Systems, Inc. [URL:


[21] Network Working Group, Request for Comments, 2753, R. Yavatkar,

Intel, D. Pendarakis, IBM and R. Guerin, U. Of Pennsylvania, [URL:


41

APPENDIX A. BIBLIOGRAPHY

[22] Network Working Group, Request for Comments, 3084, K. Chan and J.

Seligson, Nortel Networks, D. Durham, Intel. S. Gai and K. McCloghrie,

Cisco, S. Herzog, IPHighway. F. Reichmeyer, PFN. R. Yavatkar, Intel, A.

Smith, Allegro Networks [URL: http://tools.ietf.org/rfc/rfc3084.txt]

[23] SEPA Financial Servers, Mr. Salman, Degree Project at KTH

[24] Smart Card Clients, Ikram Rahim, Degree Project at KTH

[25] http://docs.openstack.org/developer/keystone/

[26] http://docs.openstack.org/trunk/openstack-

compute/admin/content/keystone-concepts.html

[27] NIST, Entity Authentication using Public Key Cryptography, Fed-

eral Information Processing Standards, Publication 1997, [URL:

http://csrc.nist.gov/publications/fips/fips196/fips196.pdf]

[28] OASIS Assertions and Protocols for the OASIS Security Assertion

Markup Language (SAML) V2.0 OASIS Standard, 15 March 2005 [URL:

http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf]

[29] Cloud Single Sign-on and Authorization Services Davit Hakobyan Degree

Project in Second Cycle

[30] http://wiki.cmsmadesimple.org/index.php/User Handbook/Installation

/Quick Install/Install on Local Windows PC

[31] https://help.ubuntu.com/community/Tasksel

[32] https://help.ubuntu.com/community/ApacheMySQLPHP

#Installing Apache 2

42

Documents

Secure Administration of SEPA Servers in A Cloud Environment578948/FULLTEXT02.pdf · to my research. His quick response to my emails any time is the key behind my successful research