This document summarizes a presentation given by Yury Chemerkin at the International Conference on Information Society in 2013. The presentation discussed limitations of security standards for public clouds. Some key points addressed include: - Common security recommendations and controls suggested by standards may not fully address issues for public clouds. - Public clouds have limitations around transparency, compliance with various standards, and vendor lock-in that private clouds do not face. - While standards try to provide unified recommendations, each cloud has unique technical implementations that are not always clearly documented.

1. Limitations of Security Standards against Public Clouds
YURY CHEMERKIN
International Conference on Information Society (i-Society 2013)

2. [ Yury Chemerkin ]
www.linkedin.com/in/yurychemerkin
http://sto-strategy.com
 Experienced in :
 Reverse Engineering & AV
 Software Programming & Documentation
 Mobile Security and MDM
 Cyber Security & Cloud Security
 Compliance & Transparency
 and Security Writing
 Hakin9 Magazine, PenTest Magazine, eForensics Magazine,
 Groteck Business Media
 Participation at conferences
 InfoSecurityRussia, NullCon, AthCon, CONFidence, PHDAYS
 CYBERCRIME FORUM, Cyber Intelligence Europe/Intelligence-Sec
 ICITST, CyberTimes, ITA
yury.chemerkin@gmail.com

3. Cloud Issues
Known Issues










Threats
Privacy
Compliance
Legal
Vendor lock-in
Open source / Open standards
Security
Abuse
IT governance
Ambiguity of terminology
Known Solutions










Customization and best practices
Crypto anarchism
CSA, ISO, PCI, SAS 70
Typically US Location
Platform, Data, Tools Lock-In
Top clouds are not open-source
Physical clouds more secured than Public
Botnets and Malware Infections
Depends on organization needs
Reference to wide services, solutions, etc.

4. Common Security Recommendations for clouds
Object
Data Ownership
Data Segmentation
Data Encryption
Backup/Recovery
Data Destruction
Access Control
Log Management
Incident Response
What to do
Full rights and access to data
An isolation data from other customers’ data
A data encryption in transit/memory/storage, at rest
An availability for recovery
An Ability to securely destroy when no longer needed
Who has access to data?
A data access that logged and monitored regularly
Are there processes and notifications in place for incidents
(including breaches) that affect data?
Security Controls
An appropriate security and configuration control to data
protection
Patching for the latest vulnerabilities and exploits?
Patch Management

5. What is about Public Clouds
Some known facts about AWS & Azure
 Top clouds are not OpenSource

OpenStack is APIs compatible with Amazon EC2
and Amazon S3 and thus client applications written
for AWS can be used with OpenStack with minimal
porting effort, while Azure is not
 Platform lock-in

Beside of OpenStack, there are Import/Export tools
to migrate from/to VMware, while Azure is not
 Data Lock-in

Native AWS solutions linked with Cisco routers to
upload, download and tunneling as well as 3rd party
storage like SMEStorage (AWS, Azure, Dropbox,
Google, etc.) , while Azure is not
in order to issues mentioned above
 Tools Lock-in

Longing for an inter-cloud managing tools that are
industrial and built with compliance
 APIs Lock-In
 Longing for inter-cloud APIs, however there were
known inter-OS APIs for PC, MDM, Mobiles, etc.
 No Transparency

Weak compliance and transparency due to SAS 70
and NDA relationships between cloud vendor and
third party auditors and experts
 Abuse
 Abusing is not a new issue and is everywhere
 AWS Vulnerability Bulletins as a kind of quick
response and stay tuned

6. Clouds: Public against Private
Known security issues of Public Clouds
 "All Your Clouds are Belong to us – Security Analysis of
Cloud Management Interfaces", 3rd CCSW, October 2011
 A black box analysis methodology of AWS control
interfaces compromised via the XSS techniques,
HTML injections, MITM
 [AWS] :: “Reported SOAP Request Parsing Vulnerabilities”
 Utilizing the SSL/HTTPS only with certificate
validation and utilizing API access mechanisms
like REST/Query instead of SOAP
 Activating access via MFA and creating IAM
accounts limited in access, AWS credentials
rotation enhanced with Key pairs and X.509
 Limiting IP access enhanced with API/SDK & IAM
and significant researches on it as a POC
 “The most dangerous code in the world: validating SSL
certificates in non-browser software”, 19th ACM
Conference on Computer and Communications Security,
October 2012
 Incorrect behavior in the SSL certificate validation
mechanisms of AWS SDK for EC2, ELB, and FPS
 [AWS] :: “Reported SSL Certificate Validation Errors in API
Tools and SDKs”
 Despite of that, AWS has updated all SDK (for all
services) to redress it

7. Clouds: Public against Private
Longing for managing CPU, Memory and other closed resources
[Intel] :: “The Essential Intelligent Client”
 Applied are known for VMware
 Ability to control clouds due the Intel
AMT commands or else is applied for
VMware
 There were not known successful
implementations for AWS, Azure, GAE or
other clouds.
[Elcomsoft] :: “Cracking Passwords in the Cloud:
Breaking PGP on EC2 with EDPR”
 Serious performance problems regardless
of where the trusted/untrusted control
agents are
 Overloading the virtual OS with analyzing
CPU commands and system calls
 Overloading is multiplied by known issues
the best of all demonstrated in case of
GPU (Elcomsoft, GPU Cracking)

8. Clouds: Public against Private
It is generally known, that private clouds are most secure There is no a POC to prove a statement on public clouds
 [AWS] :: “Xen Security Advisories”
 There are known XEN attacks (Blue Pills, etc.)
 No one XEN vulnerability was not applied to the
AWS services
 Very customized clouds
 [CSA] :: “CSA The Notorious Nine Cloud Computing Top
Threats in 2013”
 Replaced a document published in 2009
 Such best practices provides a least security
 No significant changes since 2009, even examples
 Top Threats Examples
 “1.0. Threat: Data Breaches // Cross-VM Side
Channels and Their Use to Extract private Keys”,
 “7.0. Threat: Abuse of Cloud Services // Cross-VM
Side Channels and Their Use to Extract private
Keys”
 “4.0. Threat: Insecurity Interfaces and APIs”
 Besides of Reality of CSA Threats
 1.0 & 7.0 cases highlight how the public clouds
e.g. AWS EC2 are vulnerable
 1.0 & 7.0 cases are totally focused on a private
cloud case (VMware and XEN), while there is no a
known way to adopt it to AWS.
 4.0 case presents issues raised by a SSO access
not related to public clouds (except Dropbox,
SkyDrive) and addressed to insecurity of APIs.

9. Compliance: from CSA’s viewpoint
On CSA side
 The Goal is bringing a transparency of cloud controls and
features, especially security controls and features
 Such documents have a claim to be up-to-date with
expert-level understanding of significant threats and
vulnerabilities
 Unifying recommendations for all clouds
 Up to now, it is a third revision
 All recommendations are linked with other standards
 PCI DSS
 ISO
 NIST
 COBIT
 FEDRAMP
On vendors and customers side
 Top known cloud vendors announced they are in
compliance with it
 Some of reports are getting old by now
 Customers have to control their environment by their
needs
 Customers want to know whether it is in compliance in,
especially local regulations and how far
 Customers want to know whether it makes clouds quite
transparency to let to build an appropriate

10. Compliance: from Cloud Vendor’s viewpoint
Compliance,
Transparency,
 CAIQ/CCM provides equivalent of recommendations over
several standards, CAIQ provides more details on security
and privacy but NIST more specific
 CSA recommendations are pure with technical details


It helps vendors to pass a compliance easier
It helps not to have their solutions worked out in
details and/or badly documented
 It helps to makes a lot of references on 3rd party
reviewers under NDA (SOC 1 or SAS 70)
 Bad idea to let vendors fills such documents
 They provide fewer public details
 They take it to NDA reports
Elaboration
 Vendors general explanations multiplied by general
standards recommendations are extremely far away from
transparency
 Clouds call for specific levels of audit logging, activity
reporting, security controlling and data retention
 It is often not a part of SLA offered by providers
 It is outside recommendations
 AWS often falls in details with their architecture documents
 AWS solutions are very well to be in compliance with old
standards and specific local regulations such as Russian Law


It additionally need to use CLI, API/SDK to reduce
third party solutions and implement national crypto
It offers a PenTest opportunity

11. Description
Third Party Audits
DIFF (AWS vs. AZURE)
As opposed to AWS, Azure does not have a clearly defined statement whether their customers able to perform their own
vulnerability test
Compliance: from Cloud Vendor’s viewpoint
Information
System
Regulatory AWS falls in details to comply it that results of differences between CAIQ and CMM
Mapping
Handling / Labeling / Security Policy
AWS falls in details what customers are allowed to do and how exactly while Azure does not
Retention Policy
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
Compliance,
Transparency,
Secure Disposal
No serious, AWS relies on DoD 5220.22 additionally while Azure does NIST 800-88 only
Information Leakage
Policy, User Access, MFA
Baseline Requirements
Encryption,
Encryption
Key
Management
Vulnerability / Patch Management
Elaboration
AWS relies on AMI and EBS services, while Azure does on Integrity data
No both have
Nondisclosure Agreements,
Party Agreements
User ID Credentials
(Non)Production
Network Security
Segmentation
Mobile Code
AWS provides more high detailed how-to docs than Azure, allows to import trusted VM from VMware, Azure
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
Third 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
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
environments, AWS provides more details how-to documents to having a compliance
Besides vendor features, AWS provides quite similar mechanism in alignment CAIQ & CMM, while Azure points to features built in
infrastructure on a vendor side
AWS points their clients to be responsible to meet such requirements, while Azure points to build solutions tracked for mobile code

12. w/o CE
AWS
Access Control Policy and Procedures Y
Account Management
Y
Access Enforcement
Information Flow Enforcement
Least Privilege
Security Attributes
NAME
Azure
Y
w CE
AWS
None
Azure
None
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
Y
Y
Y: 1,2;prebuilt: 3-6
Y exc. 3 (partially)
Y
Y
Y
prebuilt:1-8,10-17;N/A:9
Y
Y
prebuilt exc.
None
N/A:5
Y
Y
Y
None
Y exc. N/A: 12-15
Y
Y
p.internal
t.internal
Compliance: from Cloud Vendor’s viewpoint
Compliance,
prebuilt
Use of External Information Systems Y
Auditable Events
Y
Audit Review, Analysis, and Reporting Y
Transparency,
Elaboration
None
Y
None
Protection of Audit Information
Security Function Isolation
Y
Y
poss.
poss.
t.internal
t.internal
t.internal
t.internal
Denial of Service Protection
p.internal
p.internal
p.internal
p.internal
prebuilt
prebuilt: 1-6, 11;
prebuilt:1-6,11 exc. poss. 4c; prebuilt:7,8,9,
N/A: 3-4, 8, 10, 17;
12,15,16;
prebuilt:10
exc.
N/A:
iii,
poss. 7, 9, 12, 15;
t.internal:v;p.internal:13,14,17
p.internal: 13, 14, 17
t.internal
prebuilt
t.internal
poss.
poss.
poss.
None
None
None
None
None
None
Boundary Protection
prebuilt
Architecture & Provisioning for
prebuilt
Name/Address Resolution Service
Honeypots
poss.
OS Independent Applications
poss.
Protection of data at Rest
poss.

13. Out of paper example (MDM) : Efficiency of activities
250,00
250,00
250,00
200,00
150,00
3,45
16,67
12,50
60,00
50,00
16,67 19,05
88,89
8,70
5,08
100,00
66,67
66,67
14,29
5,88
14,29
3,37 6,25
66,67
5,56
4,26
66,67
9,09
5,26
50,00
16,67
11,76
50,00
25,00 25,00
0,00
% m+a activity vs perm
4,17
2,17
25,00
8,00
% m+a derived activity vs perm
3,70
50,00
33,33
7,14

14. Out of paper example (MDM) : Efficiency of activities
100
1200
1100
90
80
1000
80,00
70
60
800
55
50
38,46
40
16
16
30
20
5
20
0
Quantity of Groups
Average perm per group
Efficiency
Totall permissions
7
49
7
BlackBerry Old
55
20
80,00
1100
Quantity of Groups
iOS
16
5
38,46
80
Average perm per group
400
4
4
200
80
10
600
10,26
31,82
BlackBerry QNX
7
7
31,82
49
Efficiency
Android
4
4
10,26
16
Totall permissions
0

15. CONCLUSION
THE VENDOR SECURITY VISION
HAS NOTHING WITH REALITY
AGGRAVATEDBY SIMPLICITY
 The best Security & Permissions ruled by AWS among other clouds
 Most cases are not clear in according to the roles and responsibilities of cloud vendors and their customers
 Some of such cases are not clear on background type: technical or non-technical
 Swapping responsibilities and shifting the vendor job on to customer shoulders
 Referring to independent audits reports under NDA as many times as they can
 All recommendations should be enhanced by independent analysis expert in certain areas
 CSA put the cross references to other standards that impact on complexity & lack of clarity like NIST SP800-53
 NIST is more details and well documented with cross references and AWS matches to the NIST more

16. Q&A
THANK YOU