Security Requirements & Cloud Computing

Transcription

1 Security Requirements & Cloud Computing Matthias Luft ERNW GmbH

2 ERNW GmbH Heidelberg based security consulting and assessment company. - Independent - We understand corporate - Deep technical knowledge - Structured (assessment) approach - Business reasonable recommendations - Blog: - Conference: #2

3 Agenda Basic Cloud Terms ERNW CloudSec Approach Case Studies #3

4 Cloud Basics #4

5 Definition NIST Cloud Model #5

6 Definition Infrastructure as a Service #6

7 Definition Plattform as a Service #7

8 Definition NIST Cloud Model #8

9 Service Layers Configuration/Management Interface Software SaaS Governance/Monitoring/Billing Management APIs/Management Webinterfaces API Integration/Middleware Data Store Server Hardware Virtualization/Abstraction Storage Infra-structure PaaS IaaS Data Center #9

10 Deployment Models Public - Sold cloud services Private - Operated for (not necessary by) a single company Community - E.g. industry wide cooperation Hybrid - Composition of two or more clouds #10

11 There Is No Cloud There are many clouds. There is no cloud technology. There is a composition of - Hardware - Technologies - Glue code #11

12 ERNW CloudSec Approach #12

13 #13

14 Introducing the System Operation Lifecycle 1. Hardware is purchased from trusted hardware suppliers. 3. The hardware is operated in own data centers which reside in carefully selected countries and locations and are secured by carefully selected access control mechanisms. 6. The hardware is operated by trusted employees who install operating systems from trusted install media in a secure, documented way. 10. The operating system is secured by carefully selected controls. 11. Only approved applications are installed from trusted install media and operated and secured using carefully developed guidelines. 14. Hosted applications are developed following carefully developed secure coding guidelines. #14

15 Approach Analyze asset for security requirements Define cloud use case Map use case to system operation lifecycle Analyze security requirement gaps Perform additional risk/trust assessments #15

16 Asset Analysis Define security requirements and objectives. - Existing documentation might help ;-) No formal approach necessary: - Risk analysis, development documentation, data classification #16

17 Cloud Use Case Service model: - IaaS, PaaS, SaaS? Deployment model: - Public vs. private? Cloud Service Provider? Ø Map outcome to the system operation lifecycle! #17

18 Map requirements and find gaps! 1. Hardware is purchased from trusted hardware suppliers. 3. The hardware is operated in own data centers which reside in carefully selected countries and locations and are secured by carefully selected access control mechanisms. 6. The hardware is operated by trusted employees who install operating systems from trusted install media in a secure, documented way. 10. The operating system is secured by carefully selected controls. 11. Only approved applications are installed from trusted install media and operated and secured using carefully developed guidelines. 14. Hosted applications are developed following carefully developed secure coding guidelines. #18

19 Additional Assessments Risk assessment/acceptance Trust assessment Additional technical/organizational/ contractual measures possible? #19

20 Case Studies #20

21 Cloud Pentest Evaluation of a SaaS CSP - Some HR management software They agreed to perform a pentest on behalf of the potential customer. - Which is not necessarily the case! #21

22 Cloud Pentest Lifecycle: Software in SaaS cannot be controlled. Requirements: Compliance of the software with corporate security guidelines. Ø Additional assessment necessary #22

23 Pentesting SaaS Target of evaluation: HR web application 1 2 Typical web application pentest Cloud testing approach #23

24 Pentesting SaaS Basic result: After one day, we stopped the test. - We already had more severe findings than in some other 20 man day tests ;-) - File upload to the web root was possible (= code execution in a multi-tenancy environment ) So, no need to test cloud related stuff #24

25 Auditing Major CSPs Since many customers are interested in Amazon as a CSP, we perform a lot of tasks in the Amazon cloud. In the course of one of our regular password audits, we discovered some abnormalities in the Amazon login procedure. - Drop that, we wanted to break that stuff ;-) Bruteforce attempt against the Amazon Web Services login form - Using our own account - Using the standard login form #25

26 Right to Audit Requirement: All accounts have to comply with corporate security guidelines Amazon account management not under control Ø Auditing necessary! #26

27 Setup Tricky since bruteforcing tools do not cope well with modern webapp authentication mechanisms - Cookies with different scopes, redirects, JavaScript Using Burp for the bruteforcing #27

28 Results Burp might not be the best choice for bruteforcing. Still, good performance - ~80k requests per hour Setup was implemented in ~20 minutes - More details can be found here: - Successful login: #28

29 Conclusion Bruteforcing is possible. Big surprise? More important: - No connection throttling! - No account lockout! - No captcha solution! #29

30 Amazon Aftermath Very good response of the Amazon Security Team! Fast implementation of a captcha solution. Re-evaluation of our bruteforce attempt. 10/26/11 #30

31 Mapping Real World Requirements to the cloud. Analysis whether an n-tier application hosting environment can be migrated to the Amazon Cloud. - Business unit wanted to use Amazon due to flexibility and cost savings ;-) #31

32 N-Tier Typical Hosting Environment #32

33 Sample Requirements Analysis First step: Evaluation of security requirements Second step: Mapping of those requirements to potential controls, design decisions, and services in the Amazon Web Services cloud. Main goals of the project: - Which cloud deployment models can be used? - Which advantages/disadvantages result from these deployment models compared to the operation in own data centers? - Which are the adoption pitfalls? - Which regulatory requirements come into play when using a AWS setup and how to comply with those?

34 Derived Requirements Network Zoning & Filtering - Different network zones for each tier, filtering between tiers must be possible. Processing of customer data (personal data) Same availability as in own data center Latency between the different network zones - Need to be lower than 5ms (due to application performance requirements). #34

35 Network Zoning Three possibilities: Amazon VPC Subnets: Pure ACLs Different VPCs connected to corporate filtering mechanisms by IPSec Custom firewall instances #35

36 Customer Data Processing of customer data - German data protection laws - According to [OH_CC] not possible for personal data without special contractual requirements - => Data-tier must potentially be hosted in corporate data center #36

37 Latency Latency - Much higher in cloud environments, cannot be guaranteed - Basic tests: 30-50ms round trip time #37

38 Availability No actual SLAs guaranteed Uptime statements No reimbursement For IaaS, high availability still has to be implemented manually. #38

39 Additional Problems Extensive adjustment of operational processes necessary. Patch & vulnerability management needs to be adjusted. Provisioning processes: Custom AMIs necessary - E.g. data-tier requires IBM DB2 Nice-to-have: IDS between network zones External business partner connections Monitoring & logging must be adjusted for the cloud environment Ø Ø Advantages might materialize, but extensive restructuring and adoption necessary. Not feasible for only one application. #39

40 Conclusions Know your assets - Should not be surprising ;-) There is no cloud but a lot of technologies! Structured assessment necessary #40

41 Questions? #41