What mitigation strategies can we implement that will increase our assurance in the cloud

1. What mitigation strategies can we implement that will increase our assurance in the cloud Lauren Eckert and Matt Parson

2. Definitions

3. Definitions • Risk- a combination of the probability of an event occurring and its consequences • Can be an opportunity • Can be a threat • Risk Mitigation- a systematic reduction in the extent of exposure to a risk and/or the likelihood of its occurrence

4. Definitions Continued • Service Level Agreement (SLA) – agreement between an end-user/customer and a service provider • Confidence – the expectation of a successful fulfillment of an SLA

5. Service Lifecycle Methodology

6. Optimized Infrastructure Services (OPTIMIS) • Project focused on enabling an open and dependable Cloud Service Ecosystem • Delivers adaptable, reliable, auditable and sustainable services • Three actors: • End-user • Service Provider • Infrastructure Provider

7. Risk Assessment Cycle

8. Core Stages for Risk Assessment

9. Five OPTIMUS Cloud Use Cases • Private • Bursting • Multi-cloud • Federated • Brokerage

10. Private Cloud • Service Provider and Infrastructure Provider • Within the same administrative domain • Provision resources for services using internal infrastructure

11. Cloud Bursting • Infrastructure Provider initiates the SLA negotiation process with another Infrastructure Provider • Occurs when additional capacity is needed to manage increases in demand above that which its local infrastructure can accommodate.

12. Mutli-Cloud • Infrastructure provider makes use of multiple Infrastructure providers • Functional and non-functional SLA requirements determine which IP is appropriate at the component level

13. Federated Cloud • Infrastructure Provider provides resources for a Service Provider on behalf of (and across) a collection of Infrastructure Providers working together • Mutual SLA between all involved members

14. Cloud Brokerage • Broker acts as an intermediary that facilitates the Cloud and adds value through maintaining a historic database of encounters with SPs and IPs • Gauge past performance of an actor and how it is able to adhere to an SLA

16. Initial Assessment

17. Initial Assessment • Gather data over time • Use a scale of 1 to 10 • There are sub-criteria, scale of 0 to 1 • Allows end-user preferences • Able to handle missing data • Each provider is mapped onto a belief and plausibility interval

18. Initial Infrastructure Provider Assessment • Assessment of an IP by an SP is based on • Past SLA Performance • Geography Information • Certifications and Standards Compliance • Business Stability • General Infrastructure Practice • General Security Practice • General Privacy Practice

19. Initial Service Provider Assessment • Assessment of an SP by an IP is based on • Past SLA Performance • Business Stability • General Security Practice

20. Risk Inventory • Anticipate and manage risk • Positive and negative risks • Steps of determination: • Target use case (cloud scenario) • Stage in service (deployment, etc.) • Assets to be protected (agreements, hardware, data, etc.) • Risk items that may jeopardize the assets • Identify relationships between assets and risks

21. Risk Categories • Technical • Hardware, VM failure • Policy • Data jurisdiction policies • General • Security, data applications or processes • Legal • SLA

22. Example: SP level with SLA as asset

23. Example: IP level with Hardware as asset

24. Risk Models • Probabilistic • Compound probability and impact of occurrence • Possibilistic • Stochastic processes (Gamma) • Hybrid • Combination of the above two

25. Service Level Agreement Monitoring Framework

26. Third Party Service Level Agreement Monitor • Third-Party group • Monitors performance based on SLA • Two Assessment Modules • Reputation/Trust (pre-deployment) • Transactional (post-deployment)

27. SLA Monitoring framework

28. Reputation/Trust

29. Transactional • Performance & Financial risks • TP SLA monitor obtains run-time values to compare with thresholds and the determines the PoF • Convolution results in the Actual Resource Investment Curve

30. Insurance Model

31. Insurance Model • Insurance is a legal agreement (or policy) with a company that provides for reimbursement in the case of “loss” • Idea is the same as car insurance

32. Cloud Risk Assessment & Management Model

33. Security Guidance for Critical Areas of Focus in Cloud Computing v3.0

35. Domain 2: Governance and Enterprise Risk Management Items such as legal precedence for agreement breaches, ability of user organizations to adequately assess risk of a cloud provider, responsibility to protect sensitive data when both user and provider may be at fault, and how international boundaries may affect these issues.

36. Recommendations • Reinvest savings into: • Scrutiny of security of the provider • Application of security controls • Ongoing detailed assessments and audits • Review security governance structure, processes, and specific security controls of prospective providers for: • Sufficiency • Maturity • Consistency • Identify and incorporate collaborative governance structures/processes • Engage security departments for Service Level Agreements (SLA’s) • Establish metrics and standards for performance • Identify and evaluate assets, threats and vulnerabilities • Jointly develop risk scenarios for the cloud service

37. Requirements • Provide transparency • Identify interdependency of risks • Account for inherited risks

38. Domain 3:Legal Issues: Contracts and Electronic Discovery This section includes protection requirements for information and computer systems, security breach disclosure laws, regulatory requirements, privacy requirements, and international laws.

39. Domain 4:Compliance and Audit Management Issues dealing with evaluating how cloud computing affects compliance with internal security policies, as well as various compliance requirements (regulatory, legislative, and otherwise). This domain includes some direction on proving compliance during an audit.

40. Recommendations • Involve the legal, procurement, and contracts teams • Consider compliance for regulations • Determine which and how cloud partners use data • Agree how to collect, store, and share compliance evidence • Prefer auditors that are "cloudaware" • Request cloud Provider’s SSAE 16 SOC2 or ISAE 3402 Type 2 report • Provide for third-party review of SLA metrics and compliance

41. Requirements • Right to audit clause • Right to transparency clause • Review, update, and publish information security documents and GRC processes regularly • Select third-party auditors • Use a common certification assurance framework

42. Domain 5:Information Management and Data Security Items surrounding the identification and control of data in the cloud, as well as compensating controls that can be used to deal with the loss of physical control when moving data to the cloud.

43. Recommendations • Understand the cloud storage architecture • Choose storage with data dispersion • Use the Data Security Lifecycle • Monitor internal databases and file repositories • Consider using filtering to block unapproved activity

44. Recommendations Continued • Encrypt all sensitive data • Use content discovery • Encryption keys stored externally • SLA should document data removal of: • User accounts • Primary/redundant storage • Transfer of keys

45. Requirements • Data Security Lifecycle • Understand logical and physical locations of data. • Monitor employee Internet access • Encrypt all sensitive data

46. Domain 6:Interoperability and Portability The ability to move data/services from one provider to another, or bring it entirely back in-house as well as issues surrounding interoperability between providers.

47. Recommendations Hardware – Physical Computer Hardware • Use virtualization • Ensure same or better security controls Physical Network Devices • Network physical hardware and the network and security abstraction should be in a virtual domain Virtualization • Use open virtualization formats • Document and understand the virtualization hooks

48. Recommendations Continued Frameworks • Investigate the API’s to: • Determine where differences lie • Plan for necessary changes • Use open and published API’s • Determine how failure in one component will impact others Storage • Store unstructured data in an established portable format • Assess the need for encryption for data in transit • Check for compatible database systems

49. Recommendations Continued Security • Use SAML or WS-Security for authentication • Encrypt data before it is placed into the cloud • Investigate how and where keys are stored • Understand your responsibilities and liabilities should a compromise occur • Define log file information security • Delete all data, logs, etc. from the original systemwhen moving

50. Recommendations Continued Portability: • Service Level • Different architectures • Security integration • Authentication and identity mechanisms for user or process access • Encryption keys should be escrowed/maintained locally • Ensure copies of file metadata are securely removed