Copyright © i-Society 2013 Published by Infonomics Society ISBN: 978-1-908320-13-1 IEEE Catalog Number: CFP1329N-CDR

Sponsors

Edited By Charles A. Shoniregun Galyna A. Akmayeva

International Conference on Information Society (i-Society 2013)

Technical Co-Sponsored by

IEEE Toronto Section

June 24-26, 2013, Toronto, Canada

www.i-society.eu

i-Society 2013 Proceedings

Contents Page

Welcome Speech

Program Committees

Keynote Speakers

PhD Consortium

Workshops

Sessions

Limitations of Security Standards against Public Clouds

Yury Chemerkin

Russian State University for the Humanities (RSUH)

Moscow, Russia

yury.chemerkin@gmail.com

Abstract – Since a web-technology has arisen and clouds has

come, every application wants to be online and operates with

sensitive data that cannot but attract anyone to get an access this

data. It means an urgent need in security. Examining the clouds

leads us to different visions of security controls and metrics per

each cloud vendor while industrial organizations try to help to

the vendors and their customers with an appropriate security

level. They offer a transparency of security controls that belong

to different vendors against the best security practices.

Keywords: cloud security, amazon web services, aws, azure,

compliance, csa recommendations, nist sp 800-53 rev.3, nist, csa

I. INTRODUCTION

A cloud goal is delivering various computing resources like computing, storage, databases as paid services over the web. It is generally known, cloud vendors provides it without infrastructure and location details that is partially wrong or depends on certain vendors as well as cloud may bring quite unique concerns on security field. As opposed to a private cloud, a public cloud hypervisor does not provide APIs unfortunately to manage any process and flows that totally has nothing new from managing a blackbox several decades ago. It is just as trust like downloading and buying third-party solutions while cloud solutions are third party too.

To build a security and privacy, cloud vendors provide their customers with security controls on areas like data protection, identity management, application and system/network security and availability. However, the customers must meet a transparency of security controls in alignment with industrial standards, while vendors must enable them to comply with it. Standards like the documents of NIST, ISO, PCI DSS, etc. provide a measure on information security from the perspective of security at least because there are various ways to get the same security level. However, such standards look like more detailed and go deeply on security and privacy than guidance, best practices and metrics promoted by CSA. They try to bring a transparency on clouds but results are far away from it that makes the customers actions uncertain.

This research examines MS Azure and AWS clouds in alignment modern security standards and goes to explain possible issues to obtain “trustable security controls” in according to a compliance and present a working out the details of recommendations among several standards. In addition, it addresses a deeply analysis between different cloud vendors on security. The paper extends the results of previous [2-4] on security, compliance and transparency of AWS controls.

II. RELATED WORK

MS Azure has become one more popular cloud platform along with Amazon Web Services (AWS) as an open cloud platform to operate with web sites, applications, mobile services, VMs, BigData, MediaStream and more. These clouds are both so popular that both are a background for iCloud [5]. An examination of AWS security controls with their transparency in alignment security guidance and ability to pass it easy were given in paper [4], [3]. A quick analysis of AWS and Azure was given in paper [2]. As Azure has purposed of data spreading, it shifts a significant part of security from typical layer (network, OS, etc.) to an application layer on standards examination as opposed to AWS [12]. That is key thing why a cloud security might have unique concerns under the mask of a non-typical interaction, but certainly known within a scope of a penstest and audit of applications. In general, it replaces a user/password plus MFA access to an x509 access keeping basic security rules.

The standards with best practices together are known provides us with a least security that sometimes dumped with descriptive generalizations and properties, because simplification and reducing are not the same things. For example, a paper is about top nine cloud threats [1] as opposed to seven previous covers quite mixed facts related to private clouds than public. These examples in the link section are

“1.0. Top Threat: Data Breaches // Cross-VM Side Channels and Their Use to Extract private Keys”, “7.0. Top Threat: Abuse of Cloud Services // Cross-VM Side Channels and Their Use to Extract private Keys”

“4.0. Top Threat: Insecurity Interfaces and APIs” // both examples

The first case highlights how the public clouds e.g. AWS EC2 are vulnerable but totally focused on a private cloud case (VMware and XEN), while there is no a known way to apply it to AWS [9]. Instead, the work [7] explains how to compromise EC2 & S3 control interfaces with different modern techniques, but Amazon advises a native configuration against it [8].

The second case presents issues raised by a SSO access without relation to the public clouds (except Dropbox, SkyDrive) and addressed to insecurity of APIs. A paper is about issues of SSL validation [10] is a similar example, successfully solved by AWS. Dumping all generalized facts and recommendations into the basket is not good idea and may leads to the statements like “cloud vendors do not provide with full detailed to let us trust and ensure us in privacy”. First of all, the cloud vendors have their infrastructure built and

Copyright © i-Society 2013 Technical Co-Sponsored by IEEE Toronto Section 58

configured in according to the standards like ISO, PCI DSS, CoBIT that validated by independent auditors and experts every time. Second, providing such results under a NDA only (shifting details to private reports) should be mainly reasonable especially in technical cases. By way of example, an examination of AWS services against CSA requirements gives a vague answer about a real transparency bringing by CSA recommendations, because almost a third part of all responses covers such private reports [3-4]. However, not all solutions may provide the cloud customers with a proper protection. A forensics sanitization like an ERASERS proposed in [6] is a good concern for the clouds VM storages such as AWS EC2 only, not for a data storage provide by such services like AWS S3, Dropbox and similar. In this case, it is impossible to use wiping per each file; instead, it is allowed to data volumes upload as a single unit or rely on a cloud implementation according to DoD techniques.

Such documents have a claim to be up-to-date with expert-level understanding of significant threats and vulnerabilities to let to build an appropriate strategy to redress them. Everything taken together calls for an additional analysis on cloud

compliance and transparency area to reduce misunderstanding of several standards’ requirements applied to clouds.

III. EXAMINATION CSA REQ. ON AZURE AND AWS

CSA documents are known try to level up a state of knowledge on cloud security; it gained to improve a visibility of cloud controls and features to help the customers easy meet with certain requirements, include local law regulations. The Table 1 addresses to the differences between AWS and Azure according to meet the CSA requirements as well as differences between the requirements of CAIQ [14] and CMM [13] against Azure in the docket; Microsoft has already filled the CAI Questionnaire [15], but it is CMM in fact. An examination takes a place to meet it from a technical (features) point of view in the first place. Each control ID is kept with a control group description but without ID control explanation; in addition, it is grouped by similar metrics. If there is any difference between CAIQ ID and CMM ID, there will often be a difference between AWS and Azure except cases such as swapping IDs or repeating it.

TABLE I. DIFF. BETWEEN AWS AND AZURE VS. CSA REQ.

Description CAIQ

CID

CMM

CID

DIFF (CAIQ vs. CMM) DIFF (AWS vs. AZURE)

Audit Planning CO-01.1 CO-01 No No

Independent Audits CO-02.1-7 CO-02 No No

Third Party Audits CO-03.1-2 CO-03 No As opposed to AWS, Azure does not have a clearly

defined statement whether their customers able to perform their own vulnerability test

Contact/AuthorityMaintenance CO-04.1 CO-04 No No

Information System

Regulatory Mapping

CO-05.1-2 CO-05 CAIQ gets across a segmentation, while

CMM makes it unclear at first glance

AWS falls in details to comply it that results of

differences between CAIQ and CMM

Intellectual Property CO-06.1

CO-07.1

CO-08.1

CO-06 No Standards are different; AWS is in alignment with

COBIT, ISO 27002 and PCI Data Security Standards;

Azure is in alignment with ISO 27001, Digital Millennium Copyright Act

Ownership / Stewardship DG-01.1 DG-01 No AWS mentions about ISO 15489 standards while Azure

does not

Classification DG-02.1-5 DG-02 No No

Handling / Labeling / Security Policy

DG-03.1 DG-03 No AWS falls in details what customers are allowed to do and how exactly while Azure does not

Retention Policy DG-04.1-2 DG-04 No AWS points to the customers’ responsibility to manage

data, exclude moving between Availability Zones inside one region; Azure ensures on validation and processing

with it, and indicate about data historical auto-backup

Secure Disposal DG-05.1-2 DG-05 No No serious, AWS relies on DoD 5220.22 additionally

while Azure does NIST 800-88 only

Nonproduction Data DG-06.1 DG-06 No No

Information Leakage DG-07.1-2 DG-07 No AWS relies on AMI and EBS services, while Azure does

on Integrity data

Risk Assessments DG-08.1 DG-08 CMM DG 08 aggregates CAIQ DG-02, DG-03, while CAIQ points to a control

of health data and continuous monitoring

Policy FS-01.1 FS-01 No No

User Access FS-02.1 FS-02 CMM F-02 refers to an equivalent CAIQ FS-03, while CAIQ FS-02 refers to the

CMM HR-01 and the same CAIQ HR-01

No

Controlled Access Points Unauthorized Persons Entry

FS-03.1 FS-05.1

FS-03 FS-05

No No

Secure Area Authorization FS-04.1 FS-04 CMM FS-04 was partially covered at FS-

03 and FS-05

No

Offsite Authorization Offsite equipment

FS-06.1 FS-07.1

FS-06 FS-07

No No

Asset Management FS-08.1-2 FS-08 No No

Background Screening HR-01.1 HR-01 No No

Copyright © i-Society 2013 Technical Co-Sponsored by IEEE Toronto Section 59

Employment Agreements

Employment Termination

HR-02.1-2

HR-03.1

HR-02

HR-03

Management Program, Management Support /

Involvement, Policy

IS-01.1 IS-02.1

IS-03.1-3

IS-01 IS-02

IS-03

No Differences are in industrial standards AWS relies on CoBIT and PCI DSS additionally while Azure on ISO

27001 only

Baseline Requirements IS-04.1-3 IS-04 As opposed to CMM, CAIQ points to trusted VMs additionally that is allowed

to be imported

AWS provides more high detailed how-to docs than Azure, allows to import trusted VM from VMware,

Azure

Policy Reviews IS-05.1 IS-05 CAIQ CAIQ points to a notifications of customers additionally,

while CMM mentions to review only

Policy Enforcement IS-06.1-2 IS-06 No No

User Access Policy IS-07.1-2 IS-07 No No

User Access Restriction /

Authorization

IS-08.1-2 IS-08 No No

User Access Revocation IS-09.1-2 IS-09 No No

User Access Reviews

Training / Awareness

IS-10.1-3

IS-11.1-2

IS-10

IS-11

No, except CMM IS-10 addressed to an

access review and CAIQ IS-09 and HR-

02

No

Industry Knowledge / Benchmarking

IS-12.1-2 IS-12 No No

Roles / Responsibilities IS-13.1 IS-13 No No

Management Oversight

Segregation of Duties

IS-14.1

IS-15.1

IS-14

IS-15

No No

User Responsibility IS-16.1-3 IS-16 No No

Workspace IS-17.1-3 IS-17 No No

Encryption, Encryption Key

Management

IS-18.1-2

IS-19.1-4

IS-18

IS-19

No AWS offers encryption features for VM, storage, DB,

networks while Azure does for XStore (Azure Storage)

Vulnerability / Patch

Management

IS-20.1-6 IS-20 Additionally, CAIQ points to self

pentesting besides the vendors’

responsibilities

AWS provides their customers to ask for their own

pentest while Azure does not

Antivirus / Malicious Software IS-21.1-2 IS-21 No No

Incident Management IS-22.1 IS-22 No No

Incident Reporting

Incident Response Legal

Preparation

IS-23.1-2

IS-24.1-4

IS-23

IS-24

No No

Incident Response Metrics IS-25.1-2 IS-25 No No

Acceptable Use IS-26.1-3 IS-26 No No

Asset Returns IS-27.1-2 IS-27 No No

eCommerce Transactions

Audit Tools Access

IS-28.1-2

IS-29.1

IS-28

IS-29

No AWS provides more services and solutions that cover it

Diagnostic / Configuration

Ports Access, Network /

Infrastructure Services

IS-30.1,

IS-31.1-2

IS-30,

IS-31

No No

Portable / Mobile Devices Source Code Access

Restriction

IS-32.1 IS-33.1-2

IS-32 IS-33

No No

Nondisclosure Agreements Third Party Agreements

LG-01.1 LG-02.1-3

LG-01 LG-02

No AWS highlights that they does not leverage any 3rd party cloud providers to deliver AWS services to the

customers. Azure points to the procedures,NDA

undergone with ISO

Policy Documentation

OP-01.1 OP-02.1

OP-01 OP-02

No AWS relies on CoBIT and PCI DSS additionally while Azure relies on ISO 27001 only

Capacity / Resource Planning OP-03.1-2 OP-03 No No

Equipment Maintenance OP-04.1-5 OP-04 No Additionally, AWS provides similar features on customers’ side to meet the requirements

Program, Assessments,

Mitigation/Acceptance,

Business/Policy Change Impacts

RI-01.1-2

RI-02.1-2

RI-03.1-2 RI-04.1

RI-01

RI-02

RI-03 RI-04

No No

Third Party Access RI-05.1-7 RI-05 No No

New Development /

Acquisition

RM-01.1 RM-01 No No

Production Changes

Quality Testing

RM-02.1

RM-03.1

RM-02

RM-03

No No

Outsourced Development RM-04 RM-04 No As opposed to AWS, Azure details the SDLC controls

Unauthorized Software Installations

RM-05.1 RM-05 No No

Management Program, Impact

Analysis, Business Continuity

Planning, Business Continuity

RS-01.1

RS-04.1

RS-02.1-3

RS-01

RS-02

RS-03

No No

Copyright © i-Society 2013 Technical Co-Sponsored by IEEE Toronto Section 60

Testing, Environmental Risks,

Equipment Location, Equipment Power Failures,

Power/Telecommunications

RS-03.1-2

RS-05.1 RS-06.1

RS-07.1

RS-08.1-2

RS-04

RS-05 RS-06

RS-07

RS-08

Customer Access Requirement SA-01.1 SA-01 No No

User ID Credentials SA-02.1-7 SA-02 CMM falls in details about password

credentials

Besides the AD (Active Directory) AWS IAM solution

are alignment with both CAIQ, CMM requirements

while Azure addresses to the AD to perform these actions

Data Security / Integrity

Application Security

Data Integrity

SA-03.1

SA-04.1-3

SA-05.1

SA-03

SA-04

SA-05

CMM refers more to the web host

applications than services

AWS refers to the ISO 27001/27002, CoBIT, PCI DSS

while Azure refers to the ISO 27001

(Non)Production nvironments,

Network Security

SA-06.1-2

SA-08.1

SA-06

SA-08

No AWS provides more details how-to documents to having

a compliance

Remote User MFA SA-07.1 SA-07 No No

Segmentation Wireless Security

Shared Networks

SA-09.1-4 SA-10.1-3

SA-11.1

SA-09 SA-10

SA-11

CMM highlights useful details Besides vendor features, AWS provides quite similar mechanism in alignment CAIQ & CMM, while Azure

points to features built in infrastructure on a vendor side

Clock Synchronization SA-12.1 SA-12 CMM mentions services of clock

synchronization

No

Equipment Identification SA-13.1 SA-13 No Additionally, AWS provides metadatas with tags

together to helps the customers meet it

Audit Logging / IDS SA-14.1-3 SA-14 No No

Mobile Code SA-15.1-2

SA-15 No AWS points their clients to be responsible to meet such requirements, while Azure points to build solutions

tracked for mobile code

IV. EXAMINATION NIST REQ. ON AZURE AND AWS

A paper [11] provides a brief examination several clouds (AWS EC2, Azure, GAE) against NIST through the mapping security and privacy attributes to NIST guidelines but not goes deeply. However, NIST documents SP800-144 [16], SP800-146 [17] provide with general considerations how to improve a cloud security that does not bring a transparency of cloud controls and are still in progress to be similar to NIST SP800-53 by reducing non-cloud statements that is partially helps the customers because of a limitedness and focusing only on cloud. In other words, even it seems as a non-applicable requirement, such excluding may remove some objects like mobile end-points from an infrastructure and cripple a perceptual unity. That is why the Table 2 contains an examination cloud controls in alignment NIST SP800-53 Rev.3 (rev.4 has not released yet) [18] and covers a technical class only; withdrawn controls are missed.

Several conditions used in the Table 2: Abbr. "w/o" means basic requirements. Abbr. "w" – with control enhancements. Abbr. "CE" means control enhancements where "None" means there are no enhancements. Abbr. "N" means there is no ability to meet this requirement. Abbr. "Y" means basic

requirements like procedures or rest well-known solutions such as VPN. It means an ability to configure and use, however the customers need to use APIs, links a cloud layer solution with others like Active Directory or independent solutions (3

rd party

software, another cloud to backup data, etc.) or definitely non-cloud layer, e.g. OS layer to meet such requirement. Abbr. "exc." means “Yes”, “No”, “prebuilt”, “poss.” or something else except several statements/clauses related to other meaning: for example, “Y” exc. "smth" means "smth" is difficult (ask for additional actions with APIs or similar) to meet a requirement, or "N/A". “N” exc. “smth” means “smth” is equals to “Y”. If “exc.” is followed by “N/A” or other, it means an explicitly definition that is all good but there is no information (N/A) about “smth”. Abbr. "prebuilt" means the same solution was able to use as it (besides a configuration); Abbreviation "part prebuilt" means covering not all services of certain cloud. Abbr. "poss." means a possibility to build because of outstanding a cloud (or non-cloud) object from a logical point of view. Abbr. "internal" means a possibility ("p.internal") to build or prebuilt the similar solutions allowed to extend with call for internal data, while "t.internal" points to internal cloud vendors solutions or reports. Abbr. "N/A" means there is no public information to execute a requirement as well as a need to request a third party reports from cloud vendors.

TABLE II. AWS AND AZURE AGAINST NIST REQ.

ID NAME w/o CE w CE

AWS Azure AWS Azure

AC1 Access Control Policy and Procedures Y Y None None

AC2 Account Management Y Y exc. g

Y: 1, 4, 6, 7; prebuilt: 2, 5a-b; poss.3,5c,5d

Y: 1-4, 5a, 6, 7; N/A: 5b-d

AC3 Access Enforcement Y Y Y: 1,2;prebuilt: 3-6 Y exc. 3 (partially)

AC4 Information Flow Enforcement Y Y prebuilt:1-8,10-17;N/A:9 Y exc. N/A: 12-15

AC5 Separation of Duties Y Y None None

AC6 Least Privilege Y Y Y Y

AC7 Unsuccessful Login Attempts poss. poss. poss. poss.

AC8 System Use Notification Y Y None None

AC9 Previous Logon (Access) Notification Y Y None None

Copyright © i-Society 2013 Technical Co-Sponsored by IEEE Toronto Section 61

AC10 Concurrent Session Control Y Y None None

AC11 Session Lock Y Y None None

AC14 Permitted actions w/o Identification,

Authentication prebuilt prebuilt None None

AC16 Security Attributes prebuilt

prebuilt exc.

N/A:5 None None

AC17 Remote Access Y Y poss. poss.

AC18 Wireless Access Y Y Y Y

AC19 Access Control for Mobile Devices Y Y poss. poss.

AC20 Use of External Information Systems Y Y Y Y

AC21 User-Based Collaboration & Data Sharing Y Y Y Y

AC22 Publicly Accessible Content Y Y None None

AU1 Audit ,Accountability Policy and Procedures Y Y None None

AU2 Auditable Events Y Y None None

AU3 Content of Audit Records part prebuilt Y part prebuilt N/A

AU4 Audit Storage Capacity part prebuilt N/A None None

AU5 Response to Audit Processing Failures poss. poss. prebuilt. poss.

AU6 Audit Review, Analysis, and Reporting Y Y p.internal t.internal

AU7 Audit Reduction and Report Generation p.internal t.internal p.internal t.internal

AU8 Time Stamps Y Y Y Y

AU9 Protection of Audit Information Y Y poss. poss.

AU10 Non-repudiation Y Y p.internal t.internal

AU11 Audit Record Retention Y Y None None

AU12 Audit Generation Y Y Y Y

AU13 Monitoring for Information Disclosure Y Y None None

AU14 Session Audit poss. poss. None None

IA1 Identification & AuthPolicy & Procedures Y Y None None

IA2 Identification & Authentication Org. Users Y Y Y Y

IA3 Device Identification & Authentication Y Y Y Y

IA4 Identifier Management Y Y poss. poss.

IA5 Authenticator Management

Y Y

prebuilt: 1 exc. poss: c;

prebuilt: 2 exc. poss: c; prebuilt: rest

prebuilt: 1 exc. poss: c; prebuilt: 2 exc. poss: c;

prebuilt: rest exc.

N/A:6

IA6 Authenticator Feedback Y Y None None

IA7 CryptoModule Authentication Y Y None None

IA8 Identification , Authentication Non-Org. Users Y Y None None

SC1 System ,Communications Protection Policy &

Procedures Y Y None None

SC2 Application Partitioning Y Y prebuilt prebuilt

SC3 Security Function Isolation t.internal t.internal t.internal t.internal

SC4 Data In Shared Resources p.internal p.internal None None

SC5 Denial of Service Protection p.internal p.internal p.internal p.internal

SC6 Resource Priority prebuilt prebuilt None None

SC7 Boundary Protection

prebuilt prebuilt

prebuilt:1-6,11 exc. poss. 4c; prebuilt:7,8,9, 12,15,16;

prebuilt:10 exc. N/A: iii,

t.internal:v;p.internal:13,14,17

prebuilt: 1-6, 11; N/A: 3-4, 8, 10, 17;

poss. 7, 9, 12, 15;

p.internal: 13, 14, 17

SC8 Transmission Integrity poss. poss. t.internal:1;poss. 2 t.internal: 1;poss. 2

SC9 Transmission Confidentiality poss. poss. prebuilt: 1;poss. 2 prebuilt: 1;poss. 2

SC10 Network Disconnect poss. poss. poss. poss.

SC11 Trusted Path Y Y None None

SC12 CryptoKey Establishment & Management Y Y Y Y

SC13 Use of Cryptography poss. poss. poss. poss.

SC14 Public Access Protections poss. poss. None None

SC15 Collaborative Computing Devices poss.1;p.internal:2 poss.1;p.internal:2 None None

SC16 Transmission of Security Attributes poss. poss. None None

SC17 Public Key Infrastructure Certificates Y Y None None

SC18 Mobile Code p.internal p.internal p.internal p.internal

SC19 Voice Over Internet Protocol poss. poss. None None

SC20-

21

Secure Name/Address Resolution Service

(Authoritative Source, Recursive, Caching

Resolver)

prebuilt t.internal prebuilt t.internal

SC22 Architecture & Provisioning for Name/Address

Resolution Service prebuilt t.internal prebuilt t.internal

SC23 Session Authenticity p.internal p.internal p.internal p.internal

SC24 Fail in Known State prebuilt prebuilt None None

SC25 Thin Nodes prebuilt prebuilt None None

SC26 Honeypots poss. poss. None None

Copyright © i-Society 2013 Technical Co-Sponsored by IEEE Toronto Section 62

SC27 OS Independent Applications poss. poss. None None

SC28 Protection of data at Rest poss. poss. None None

SC29 Heterogeneity Y Y None None

SC30 Virtualization Techniques t.internal t.internal t.internal t.internal

SC31 Covert Channel Analysis poss. poss. p.internal p.internal

SC32 Information System Partitioning Y Y None None

SC33 Transmission Preparation Integrity Y Y None None

SC34 Non-Modifiable Executable Programs poss. poss. poss. poss.

V. CONCLUSION

Vendors are known are not tend to make some details on cloud security public to their customers. Clouds vendors explain it as “security through obscurity” matters and provides with independent auditors’ reports at the same time. It often leads to questions of trust level, ability to verify the controls and way it should be done. Industrial organizations with their security vision has relived but raised more questions on transparency instead of reducing it. These documents refer to known vulnerabilities beside the point and bring misunderstanding, e.g. there are several attacks successfully applied to Xen, VMware or other private clouds. It means an application domain that often excludes the public clouds in case of AWS and Azure. Some cases are not clear in according to the roles and responsibilities of cloud vendors and their customers. As it is not defined clearly, it makes uncertain whether the vendors should provide the customers any control opportunities; it leads to swapping responsibilities and shifting vendor job on to customer shoulders. The vendors address to their reports too much instead of providing the public details. It should be strong defined which controls are allowed to be available to the customers, which built and detailed in public documents, and the rest is covered by independent reports; ex. [Assignment: organization-defined frequency]. Any discrepancy must shift the security level from the highest to one level lower as it is in NIST.

Other cases cover an announcement about compliance in alignment to certain standards on vendor side that is partially good and should be enhanced by independent analysis reports. It yields the technical details from Amazon and well-known statements multiplied with internal reports from Microsoft. CSA puts the cross references to other standards in their documents, that impact on complexity and lack of clarity in case of NIST. It makes very unobvious how the same controls related to each other and how general requirements correspond to clearly detailed requirements. Anyway, it makes a good showing to rely on differences of these requirements to improve the last and recreate new set to keep a comprehensive unity of cloud security that is signification part to remediate issues and enhance transparency of cloud controls on technical requirements more than it was according to industrial documents. Examination the following cloud solutions, such as Office365 with Cloud BES, AWS and Azure against other standards (CoBIT, NIST SP 800-53 rev.4 and ISO 27001 ’13) is a part of further research too.

REFERENCES

[1] “CSA The Notorious Nine Cloud Computing Top Threats in 2013” [Online resource: downloads.cloudsecurityalliance.org/initiatives/top_threats/The_Notorio

us_Nine_Cloud_Computing_Top_Threats_in_2013.pdf, Accessed 06-March-2013]

[2] Y. Chemerkin, “AWS Cloud Security from the point of view of the Compliance”, PenTest Magazine, Software Press Sp. z o.o. Sp. Komandytowa Warszawa, vol. 2 №10 Issue 10/2012 (12) ISSN 2084-1116, pp. 50-59, December 2012

[3] Y. Chemerkin, “Cloud Securtiy Analysis against the modern and old security standarts, regulation reccomendations”, draft (is going to be published in PenTest Magazine, Software Press Sp. z o.o. Sp. Komandytowa Warszawa in April-May

[4] Y. Chemerkin, “Security compliance challenges on clouds”,Cyber Times International Journal of Technology & Management 2013, Vol. 6 Issue-1, ISSN No.: 2278-7518, March 2013

[5] A. Belenko, D. Sklyarov “Dark and Bright Sides of iCloud (In)security”, [Online resource: viaforensics.com/android-forensics/icloud-insecurity-examining-ios-data-backup-cloud.html, Accessed 01-March- 2013]

[6] J. Medsger, A. Srinivasan, "ERASE- EntRopy-based SAnitization of SEnsitive Data for Privacy Preservation", The 7th International Conference for Internet Technology and Secured Transactions (ICITST-2012), pp.427 – 432, December 2012

[7] J. Somorovsky, M. Heiderich, M. Jensen, J. Schwenk, N. Gruschka, L. L. Iacono, "All Your Clouds are Belong to us – Security Analysis of Cloud Management Interfaces", 3rd ACM workshop on Cloud computing security workshop (CCSW), pp.3-14, October 2011

[8] “Reported SOAP Request Parsing Vulnerabilities”, [Online resource: aws.amazon.com/security/security-bulletins/reported-soap-request-parsing-vulnerabilities-reso/, Accessed 15-January-2013]

[9] “Xen Security Advisories”, [Online resource: aws.amazon.com/security/security-bulletins/xen-security-advisories/, Accessed 15-January-2013]

[10] “The most dangerous code in the world: validating SSL certificates in non-browser software”, 19th ACM Conference on Computer and Communications Security, pp.38-49, October 2012

[11] A. Abuhussein, H. Bedi, S. Shiva, “Evaluating Security and Privacy in Cloud Computing Services:A Stakeholder’s Perspective”, The 7th International Conference for Internet Technology and Secured Transactions (ICITST-2012), pp.388 – 395, December 2012

[12] Windows Azure Security Overview whitepaper, [Online resource: go.microsoft.com/?linkid=9740388, Accessed: 01-Februarry-2013]

[13] CSA Cloud Controls Matrix v1.3” [Online resource: cloudsecurityalliance.org/research/cai/, Accessed 15-January-2013]

[14] “CSA Consensus Assessments Initiative Questionnaire v1.1” [Online resource: cloudsecurityalliance.org/research/cai/, Accessed 15- Jan-2013]

[15] “CSA Consensus Assessments Initiative Questionnaire v1.1” / CSA Cloud Controls Matrix v1.3” [Online resource: https cloudsecurityalliance.org/wp-content/uploads/2012/03/Microsoft-Azure-CAIQ-v1.1-2012-03-25.zip, Accessed 15-January-2013]

[16] “Guidelines on Security and Privacy in Public Cloud Computing”, [Online resource: csrc.nist.gov/publications/nistpubs/800-144/SP800-144.pdf, Accessed 04-February-2013]

[17] “Cloud Computing Synopsis and Recommendations”, [Online resource: www.nist.gov/customcf/get_pdf.cfm?pub_id=911075, Accessed 04- February -2013]

[18] “Recommended Security Controls for Federal Information Systems and Organizations. Revision 3”, [Online resource: csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final_updated-errata_05-01-2010.pdf, Accessed 04-February-2013]

Copyright © i-Society 2013 Technical Co-Sponsored by IEEE Toronto Section 63