(Pdf) yury chemerkin _i-society_2013
Upcoming SlideShare
Loading in...5

(Pdf) yury chemerkin _i-society_2013






Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

(Pdf) yury chemerkin _i-society_2013 (Pdf) yury chemerkin _i-society_2013 Presentation Transcript

  • Limitations of Security Standards against Public Clouds YURY CHEMERKIN International Conference on Information Society (i-Society 2013)
  • [ 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
  • 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.
  • 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
  • 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
  • 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
  • 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)
  • 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.
  • 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
  • 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
  • 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
  • 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.
  • 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
  • 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
  • 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