(Pdf) yury chemerkin _CTICon_2013
-
Upload
sto-strategy -
Category
Technology
-
view
204 -
download
0
description
Transcript of (Pdf) yury chemerkin _CTICon_2013
SECURITY COMPLIANCE CHALLENGES ON CLOUDS
Ph.D. YURY CHEMERKIN
Cyber Times International Journal of Technology & Management ‘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
CYBERCRIME FORUM, Cyber Intelligence Europe/Intelligence-Sec
ICITST, CyberTimes, EBW
[ Yury Chemerkin ]
www.linkedin.com/in/yurychemerkin http://sto-strategy.com [email protected]
Threats
Privacy
Compliance
Legal
Vendor lock-in
Open source / Open standards
Security
Abuse
IT governance
Ambiguity of terminology
Customization and best practices
Cryptoanarchism
CSA, ISO, PCI, SAS 70
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 EC2 andAmazon S3 and thus client applications written forAWS can be used with OpenStack with minimalporting effort
Platform lock-in
Beside of OpenStack, there are Import/Export toolsto migrate from/to VMware
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.)
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 “Amazon Web Services”
Some known facts about AWS 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 ACMConference 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 APITools and SDKs”
Despite of that, AWS has updated all SDK (for all services) to redress it
Clouds: Public against Private
Known security issues of Amazon Web Services 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 analysingCPU 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] :: “XenSecurity 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 quitetransparency to let to build an appropriate
Compliance: AWS against CSA
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 than
matrix aligned to Cloud Security Guidance in 13 domains
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: AWS against CSA
Compliance, Transparency, Elaboration
The best Security & Permissions ruled by AWS over 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