Limitations of Security Standards against Public Clouds

YURY CHEMERKIN

International Conference on Information Society (i-Society 2013)

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 ]

www.linkedin.com/in/yurychemerkin http://sto-strategy.com yury.chemerkin@gmail.com

Threats

Privacy

Compliance

Legal

Vendor lock-in

Open source / Open standards

Security

Abuse

IT governance

Ambiguity of terminology

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.

Cloud Issues

Known Issues Known Solutions

Common Security Recommendations for clouds

Object What to do

Data Ownership Full rights and access to data

Data Segmentation An isolation data from other customers’ data

Data Encryption A data encryption in transit/memory/storage, at rest

Backup/Recovery An availability for recovery

Data Destruction An Ability to securely destroy when no longer needed

Access Control Who has access to data?

Log Management A data access that logged and monitored regularly

Incident Response 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

Patch Management Patching for the latest vulnerabilities and exploits?

Top clouds are not OpenSource

OpenStack is APIs compatible with Amazon EC2and Amazon S3 and thus client applications writtenfor AWS can be used with OpenStack with minimalporting effort, while Azure is not

Platform lock-in

Beside of OpenStack, there are Import/Export toolsto migrate from/to VMware, while Azure is not

Data Lock-in

Native AWS solutions linked with Cisco routers toupload, download and tunneling as well as 3rd partystorage like SMEStorage (AWS, Azure, Dropbox,Google, etc.) , while Azure is not

Tools Lock-in

Longing for an inter-cloud managing tools that areindustrial 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

What is about Public Clouds

Some known facts about AWS & Azure in order to issues mentioned above

"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

“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

Clouds: Public against Private

Known security issues of Public Clouds and significant researches on it as a POC

[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)

Clouds: Public against Private

Longing for managing CPU, Memory and other closed resources

[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.

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

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

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

Compliance: from CSA’s viewpoint

On CSA side On vendors and customers side

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

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

Compliance: from Cloud Vendor’s viewpoint

Compliance, Transparency, Elaboration

Compliance: from Cloud Vendor’s viewpoint

Compliance, Transparency, Elaboration

Description DIFF (AWS vs. AZURE)

Third Party Audits As opposed to AWS, Azure does not have a clearly defined statement whether their customers able to perform their own

vulnerability test

Information System Regulatory

Mapping

AWS falls in details to comply it that results of differences between CAIQ and CMM

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

Secure Disposal No serious, AWS relies on DoD 5220.22 additionally while Azure does NIST 800-88 only

Information Leakage AWS relies on AMI and EBS services, while Azure does on Integrity data

Policy, User Access, MFA No both have

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

Encryption, Encryption Key

Management

AWS offers encryption features for VM, storage, DB, networks while Azure does for XStore (Azure Storage)

Vulnerability / Patch Management AWS provides their customers to ask for their own pentest while Azure does not

Nondisclosure Agreements, Third

Party Agreements

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

User ID 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

(Non)Production environments,

Network Security

AWS provides more details how-to documents to having a compliance

Segmentation Besides vendor features, AWS provides quite similar mechanism in alignment CAIQ & CMM, while Azure points to features built in

infrastructure on a vendor side

Mobile Code AWS points their clients to be responsible to meet such requirements, while Azure points to build solutions tracked for mobile code

Compliance: from Cloud Vendor’s viewpoint

Compliance, Transparency, Elaboration

NAMEw/o CE w CE

AWS Azure AWS Azure

Access Control Policy and Procedures Y Y None None

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

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

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

Least Privilege Y Y Y Y

Security Attributesprebuilt

prebuilt exc.

N/A:5None None

Use of External Information Systems Y Y Y Y

Auditable Events Y Y None None

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

Protection of Audit Information Y Y poss. poss.

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

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

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

Architecture & Provisioning for

Name/Address Resolution Serviceprebuilt t.internal prebuilt t.internal

Honeypots poss. poss. None None

OS Independent Applications poss. poss. None None

Protection of data at Rest poss. poss. None None

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

Out of paper example (MDM) : Efficiency of activities

16,67 19,05

60,00

5,8814,29

5,5616,67

66,67

11,76

66,67

25,0050,00

25,00 25,00

50,0033,33

50,00

250,00

7,14

16,67

3,45

12,50

5,08

14,29

3,37 6,25

8,704,26

66,67

9,09

66,67

5,262,17

88,89

4,17

8,00

250,00

3,70

0,00

50,00

100,00

150,00

200,00

250,00

% m+a activity vs perm % m+a derived activity vs perm

Out of paper example (MDM) : Efficiency of activities

BlackBerry Old iOS BlackBerry QNX Android

Quantity of Groups 55 16 7 4

Average perm per group 20 5 7 4

Efficiency 80,00 38,46 31,82 10,26

Totall permissions 1100 80 49 16

55

16

7 420 5 7 4

80,00

38,46 31,82 10,26

1100

80

49

16

0

200

400

600

800

1000

1200

0

10

20

30

40

50

60

70

80

90

100

Quantity of Groups Average perm per group Efficiency Totall permissions

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

CONCLUSION

THE VENDOR SECURITY VISION HAS NOTHING WITH REALITY AGGRAVATED BY SIMPLICITY

Q&A THANK YOU