what mitigation strategies can we implement that will increase our assurance in the cloud n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
What mitigation strategies can we implement that will increase our assurance in the cloud PowerPoint Presentation
Download Presentation
What mitigation strategies can we implement that will increase our assurance in the cloud

Loading in 2 Seconds...

play fullscreen
1 / 105

What mitigation strategies can we implement that will increase our assurance in the cloud - PowerPoint PPT Presentation


  • 140 Views
  • Uploaded on

What mitigation strategies can we implement that will increase our assurance in the cloud. Lauren Eckert and Matt Parson. Definitions. Definitions . Risk- a combination of the probability of an event occurring and its consequences Can be an opportunity Can be a threat

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

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


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
    Presentation Transcript
    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

    15. Initial Assessment

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

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

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

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

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

    21. Example: SP level with SLA as asset

    22. Example: IP level with Hardware as asset

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

    24. Service Level Agreement Monitoring Framework

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

    26. SLA Monitoring framework

    27. Reputation/Trust

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

    29. Insurance Model

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

    31. Cloud Risk Assessment & Management Model

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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