International Conference on Information Society (i-Society 2013)

Technical Co-Sponsored by IEEE Toronto Section

Sponsors

June 24-26, 2013, Toronto, Canada

www.i-society.eu

i-Society 2013 Proceedings

Edited By Charles A. Shoniregun Galyna A. Akmayeva Contents Page PhD Consortium Welcome Speech Workshops Program Committees Sessions Keynote Speakers

Copyright i-Society 2013 Published by Infonomics Society

ISBN: 978-1-908320-13-1 IEEE Catalog Number: CFP1329N-CDR

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

II.

RELATED WORK

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.

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 // CrossVM 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 expertlevel 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
TABLE I. Description Audit Planning Independent Audits Third Party Audits CAIQ CID CO-01.1 CO-02.1-7 CO-03.1-2 CMM CID CO-01 CO-02 CO-03

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.

DIFF. BETWEEN AWS AND AZURE VS. CSA REQ. DIFF (CAIQ vs. CMM) No No No DIFF (AWS vs. AZURE) No No As opposed to AWS, Azure does not have a clearly defined statement whether their customers able to perform their own vulnerability test No AWS falls in details to comply it that results of differences between CAIQ and CMM 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 AWS mentions about ISO 15489 standards while Azure does not No AWS falls in details what customers are allowed to do and how exactly while Azure does not 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 No serious, AWS relies on DoD 5220.22 additionally while Azure does NIST 800-88 only No AWS relies on AMI and EBS services, while Azure does on Integrity data

Contact/AuthorityMaintenance Information System Regulatory Mapping Intellectual Property

CO-04.1 CO-05.1-2 CO-06.1 CO-07.1 CO-08.1 DG-01.1 DG-02.1-5 DG-03.1 DG-04.1-2

CO-04 CO-05 CO-06

No CAIQ gets across a segmentation, while CMM makes it unclear at first glance No

Ownership / Stewardship Classification Handling / Labeling / Security Policy Retention Policy

DG-01 DG-02 DG-03 DG-04

No No No No

Secure Disposal Nonproduction Data Information Leakage Risk Assessments

DG-05.1-2 DG-06.1 DG-07.1-2 DG-08.1

DG-05 DG-06 DG-07 DG-08

No No No CMM DG 08 aggregates CAIQ DG-02, DG-03, while CAIQ points to a control of health data and continuous monitoring No 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 CMM FS-04 was partially covered at FS03 and FS-05 No No No

Policy User Access

FS-01.1 FS-02.1

FS-01 FS-02

No No

Controlled Access Points Unauthorized Persons Entry Secure Area Authorization Offsite Authorization Offsite equipment Asset Management Background Screening

FS-03.1 FS-05.1 FS-04.1 FS-06.1 FS-07.1 FS-08.1-2 HR-01.1

FS-03 FS-05 FS-04 FS-06 FS-07 FS-08 HR-01

No No No No No

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

59

Employment Agreements Employment Termination Management Program, Management Support / Involvement, Policy Baseline Requirements

HR-02.1-2 HR-03.1 IS-01.1 IS-02.1 IS-03.1-3 IS-04.1-3

HR-02 HR-03 IS-01 IS-02 IS-03 IS-04

No

Policy Reviews Policy Enforcement User Access Policy User Access Restriction Authorization User Access Revocation User Access Reviews Training / Awareness

IS-05.1 IS-06.1-2 IS-07.1-2 IS-08.1-2 IS-09.1-2 IS-10.1-3 IS-11.1-2 IS-12.1-2 IS-13.1 IS-14.1 IS-15.1 IS-16.1-3 IS-17.1-3 IS-18.1-2 IS-19.1-4 IS-20.1-6

IS-05 IS-06 IS-07 IS-08 IS-09 IS-10 IS-11 IS-12 IS-13 IS-14 IS-15 IS-16 IS-17 IS-18 IS-19 IS-20

As opposed to CMM, CAIQ points to trusted VMs additionally that is allowed to be imported CAIQ No No No No No, except CMM IS-10 addressed to an access review and CAIQ IS-09 and HR02 No No No No No No Additionally, CAIQ pentesting besides responsibilities No No No points to self the vendors

Differences are in industrial standards AWS relies on CoBIT and PCI DSS additionally while Azure on ISO 27001 only AWS provides more high detailed how-to docs than Azure, allows to import trusted VM from VMware, Azure CAIQ points to a notifications of customers additionally, while CMM mentions to review only No No No No No

Industry Knowledge / Benchmarking Roles / Responsibilities Management Oversight Segregation of Duties User Responsibility Workspace Encryption, Encryption Key Management Vulnerability / Patch Management Antivirus / Malicious Software Incident Management Incident Reporting Incident Response Legal Preparation Incident Response Metrics Acceptable Use Asset Returns eCommerce Transactions Audit Tools Access Diagnostic / Configuration Ports Access, Network / Infrastructure Services Portable / Mobile Devices Source Code Access Restriction Nondisclosure Agreements Third Party Agreements

No No No No No AWS offers encryption features for VM, storage, DB, networks while Azure does for XStore (Azure Storage) AWS provides their customers to ask for their own pentest while Azure does not No No No

IS-21.1-2 IS-22.1 IS-23.1-2 IS-24.1-4 IS-25.1-2 IS-26.1-3 IS-27.1-2 IS-28.1-2 IS-29.1 IS-30.1, IS-31.1-2 IS-32.1 IS-33.1-2 LG-01.1 LG-02.1-3

IS-21 IS-22 IS-23 IS-24 IS-25 IS-26 IS-27 IS-28 IS-29 IS-30, IS-31 IS-32 IS-33 LG-01 LG-02

No No No No No

No No No AWS provides more services and solutions that cover it No

No

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 AWS relies on CoBIT and PCI DSS additionally while Azure relies on ISO 27001 only No Additionally, AWS provides similar features on customers side to meet the requirements No

No

Policy Documentation Capacity / Resource Planning Equipment Maintenance Program, Assessments, Mitigation/Acceptance, Business/Policy Change Impacts Third Party Access New Development / Acquisition Production Changes Quality Testing Outsourced Development Unauthorized Software Installations Management Program, Impact Analysis, Business Continuity Planning, Business Continuity

OP-01.1 OP-02.1 OP-03.1-2 OP-04.1-5 RI-01.1-2 RI-02.1-2 RI-03.1-2 RI-04.1 RI-05.1-7 RM-01.1 RM-02.1 RM-03.1 RM-04 RM-05.1 RS-01.1 RS-04.1 RS-02.1-3

OP-01 OP-02 OP-03 OP-04 RI-01 RI-02 RI-03 RI-04 RI-05 RM-01 RM-02 RM-03 RM-04 RM-05 RS-01 RS-02 RS-03

No No No No

No No No No No No

No No No As opposed to AWS, Azure details the SDLC controls No No

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

60

Testing, Environmental Risks, Equipment Location, Equipment Power Failures, Power/Telecommunications Customer Access Requirement User ID Credentials

RS-03.1-2 RS-05.1 RS-06.1 RS-07.1 RS-08.1-2 SA-01.1 SA-02.1-7

RS-04 RS-05 RS-06 RS-07 RS-08 SA-01 SA-02

No CMM falls in details about password credentials

Data Security / Integrity Application Security Data Integrity (Non)Production nvironments, Network Security Remote User MFA Segmentation Wireless Security Shared Networks Clock Synchronization Equipment Identification Audit Logging / IDS Mobile Code

SA-03.1 SA-04.1-3 SA-05.1 SA-06.1-2 SA-08.1 SA-07.1 SA-09.1-4 SA-10.1-3 SA-11.1 SA-12.1 SA-13.1 SA-14.1-3 SA-15.12

SA-03 SA-04 SA-05 SA-06 SA-08 SA-07 SA-09 SA-10 SA-11 SA-12 SA-13 SA-14 SA-15

CMM refers more to the web host applications than services No No CMM highlights useful details

No 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 AWS refers to the ISO 27001/27002, CoBIT, PCI DSS while Azure refers to the ISO 27001 AWS provides more details how-to documents to having a compliance No Besides vendor features, AWS provides quite similar mechanism in alignment CAIQ & CMM, while Azure points to features built in infrastructure on a vendor side No Additionally, AWS provides metadatas with tags together to helps the customers meet it No AWS points their clients to be responsible to meet such requirements, while Azure points to build solutions tracked for mobile code

CMM mentions synchronization No No No

services

of

clock

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], SP800146 [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 SP80053 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 endpoints 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
TABLE II. ID AC1 AC2 AC3 AC4 AC5 AC6 AC7 AC8 AC9 NAME Access Control Policy and Procedures Account Management Access Enforcement Information Flow Enforcement Separation of Duties Least Privilege Unsuccessful Login Attempts System Use Notification Previous Logon (Access) Notification Y Y Y Y Y Y poss. Y Y

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 (3rd party software, another cloud to backup data, etc.) or definitely noncloud 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.

AWS AND AZURE AGAINST NIST REQ. w/o CE AWS Y Y exc. g Y Y Y Y poss. Y Y Azure AWS None Y: 1, 4, 6, 7; prebuilt: 2, 5a-b; poss.3,5c,5d Y: 1,2;prebuilt: 3-6 prebuilt:1-8,10-17;N/A:9 None Y poss. None None w CE Azure None Y: 1-4, 5a, 6, 7; N/A: 5b-d Y exc. 3 (partially) Y exc. N/A: 12-15 None Y poss. None None

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

61

AC10 AC11 AC14 AC16 AC17 AC18 AC19 AC20 AC21 AC22 AU1 AU2 AU3 AU4 AU5 AU6 AU7 AU8 AU9 AU10 AU11 AU12 AU13 AU14 IA1 IA2 IA3 IA4 IA5

Concurrent Session Control Session Lock Permitted actions w/o Authentication Security Attributes

Y Y Identification, prebuilt prebuilt Y Y Y Y Y Y Y Y part prebuilt part prebuilt poss. Y p.internal Y Y Y Y Y Y poss. Y Y Y Y Y

Y Y prebuilt prebuilt N/A:5 Y Y Y Y Y Y Y Y Y N/A poss. Y t.internal Y Y Y Y Y Y poss. Y Y Y Y Y Y Y Y Y Y t.internal p.internal p.internal prebuilt prebuilt poss. poss. poss. Y Y poss. poss. poss.1;p.internal:2 poss. Y p.internal poss. t.internal t.internal p.internal prebuilt prebuilt poss. exc.

None None None None poss. Y poss. Y Y None None None part prebuilt None prebuilt. p.internal p.internal Y poss. p.internal None Y None None None Y Y poss. prebuilt: 1 exc. poss: c; prebuilt: 2 exc. poss: c; prebuilt: rest None None None None prebuilt t.internal None p.internal None 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 t.internal:1;poss. 2 prebuilt: 1;poss. 2 poss. None Y poss. None None None None p.internal None prebuilt prebuilt p.internal None None None

None None None None poss. Y poss. Y Y None None None N/A None poss. t.internal t.internal Y poss. t.internal None Y None None None Y Y poss. prebuilt: 1 exc. poss: c; prebuilt: 2 exc. poss: c; prebuilt: rest exc. N/A:6 None None None None prebuilt t.internal None p.internal None prebuilt: 1-6, 11; N/A: 3-4, 8, 10, 17; poss. 7, 9, 12, 15; p.internal: 13, 14, 17 t.internal: 1;poss. 2 prebuilt: 1;poss. 2 poss. None Y poss. None None None None p.internal None t.internal t.internal p.internal None None None

Remote Access Wireless Access Access Control for Mobile Devices Use of External Information Systems User-Based Collaboration & Data Sharing Publicly Accessible Content Audit ,Accountability Policy and Procedures Auditable Events Content of Audit Records Audit Storage Capacity Response to Audit Processing Failures Audit Review, Analysis, and Reporting Audit Reduction and Report Generation Time Stamps Protection of Audit Information Non-repudiation Audit Record Retention Audit Generation Monitoring for Information Disclosure Session Audit Identification & AuthPolicy & Procedures Identification & Authentication Org. Users Device Identification & Authentication Identifier Management Authenticator Management

IA6 IA7 IA8 SC1 SC2 SC3 SC4 SC5 SC6 SC7

Authenticator Feedback CryptoModule Authentication Identification , Authentication Non-Org. Users System ,Communications Protection Policy & Procedures Application Partitioning Security Function Isolation Data In Shared Resources Denial of Service Protection Resource Priority Boundary Protection

Y Y Y Y Y t.internal p.internal p.internal prebuilt prebuilt

SC8 SC9 SC10 SC11 SC12 SC13 SC14 SC15 SC16 SC17 SC18 SC19 SC2021 SC22 SC23 SC24 SC25 SC26

Transmission Integrity Transmission Confidentiality Network Disconnect Trusted Path CryptoKey Establishment & Management Use of Cryptography Public Access Protections Collaborative Computing Devices Transmission of Security Attributes Public Key Infrastructure Certificates Mobile Code Voice Over Internet Protocol Secure Name/Address Resolution Service (Authoritative Source, Recursive, Caching Resolver) Architecture & Provisioning for Name/Address Resolution Service Session Authenticity Fail in Known State Thin Nodes Honeypots

poss. poss. poss. Y Y poss. poss. poss.1;p.internal:2 poss. Y p.internal poss. prebuilt prebuilt p.internal prebuilt prebuilt poss.

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

62

SC27 SC28 SC29 SC30 SC31 SC32 SC33 SC34

OS Independent Applications Protection of data at Rest Heterogeneity Virtualization Techniques Covert Channel Analysis Information System Partitioning Transmission Preparation Integrity Non-Modifiable Executable Programs

poss. poss. Y t.internal poss. Y Y 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

poss. None None poss. None None Y None None t.internal t.internal t.internal poss. p.internal p.internal Y None None Y None None poss. poss. poss. us_Nine_Cloud_Computing_Top_Threats_in_2013.pdf, Accessed 06March-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 20841116, 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-insecurityexamining-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 (ICITST2012), 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-requestparsing-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 Stakeholders 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- Jan2013] [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-AzureCAIQ-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/SP800144.pdf, Accessed 04-February-2013] [17] Cloud Computing Synopsis and Recommendations, [Online resource: www.nist.gov/customcf/get_pdf.cfm?pub_id=911075, Accessed 04February -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-rev3final_updated-errata_05-01-2010.pdf, Accessed 04-February-2013]

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

63