WP9 D9.5 Risk Analysis and Countermeasures

Transcription

1 WP9 D9.5 Risk Analysis and Countermeasures Risk Analysis approach for the Cloud for Europe PCP pilots Friday Jan Colpaert Fedict, BE

2 Starting points - observations any Before using cloud technology, think about risk Cloud makes it easier to reduce risk Easier resilience Pre-certified components Cloud introduces new risks Lock-in Legal imbalance between provider and tenant s risk Insufficient distinction between tenant s duties and duties that can be outsourced to the CSP 2

3 Types of audience Corporate (Government) end user of cloud technology (typically SaaS) Owner of applications that use cloud technology IaaS PaaS SaaS sub-components Legal contractual exit strategy technical security resilience Owners of applications that provide cloud services Legal contractual certification of end-service 3

4 Think about risk! People make shortcuts like: This application only handles public data so we can host it in a low cost simple environment My IaaS cloud provider is certified, so we are safe Lets try to ask the right questions! 4

5 The risk landscapes (The Open Group, FAIR) Asset Landscape Loss Landscape Controls Landscape Threat Landscape Vulnerability Landscape 5

6 Asset Landscape Asset Analysis Application Context Compliance requirements Hosting type Application related assets 6

7 Threat landscape Likelihood: depends on Loss potential, Implemented protection measures Often tenant s responsibility Capabilities of the treat source / agent Depends highly on the loss potential In Internet facing applications and high profile applications we always have to assume very high capability The impact of most threats can be assessed by means of the impact of more generic risks: Confidentiality breach Integrity breach Availability breach (RTO) Transaction loss (RPO) 7

8 Loss (Impact) Landscape Government applications: Business Impact Society Impact How to assess impact level? Lack of internationally accepted scales UK s HMG IA nr 1 defines a scale 6 impact levels not really needed for mapping on measures Differentiation between Confidentiality, Integrity and Availabiltiy makes sense 8

9 Threat Community Risk analysis approach Asset Analysis Threat landscape analysis Generic Threats Confidentiality Breach Loss (impact) analysis Threat Own Business Society Integrity Breach Transaction loss Availability Breach threat s Specific Threats Vulnerability or likelihood consideration Risk aversion Required Controls 9

10 Cloud technology Introduces new risks such as: Lock-in Legislation related risks Contractual, financial Unbalanced: Impact for underlying IaaS/PaaS CSP may be smaller than impact of application Makes it easier to reduce risk: Easier to build resilient services Use multiple (IaaS) providers Easy scaling Disaster recovery datacenter without capex Certification of the underlying infrastructure layers 10

11 Classical Risk Assessment Classical risk assessment methods tend to be very detailed and time consuming: hundreds of threats for which: Impact Probability/Likelyhood Threat source capabilities need to be analyzed A risk appetite/aversion factor is applied 11

12 Simplified Risk Assessment (1) Impact is more dependent on the application than on the threat. Therefore we determine the impact of more generic threats Impact of confidentiality breach Impact of integrity breach Impact of availability breach Not all threats belong to these generic threats. There are some special cases: Legal Contractual Financial 12

13 Simplified Risk Assessment (2) Likelihood depends mainly on the threat, the planned protection methods, the attractiveness of the assets and the loss potential. There remains a dependence on the application that must be examined in some cases Document the assumptions under which the risk assessment was made! Tenant is responsible for the controls, not only cloud provider! 13

14 Simplified Risk Assessment (3) Threat source capabilities. Depends on the loss potential! Most cloud applications are open to the Internet, we must assume capabilities are very high for high-profile applications Classical threat agents (natural, unintentional human,.. ) can be covered at the underlying CSP level (assuming certified service). 14

15 Main goals: Make application owners think about Characteristics of the application Impact level, and availability requirements Required certification levels Measures to avoid lock-in Measures to enhance availability 15

16 Mapping risk level on measures/controls Special focus on: Controls that could be forgotten because tenant believes it is CSP s responsibility Areas that cannot be covered by certification or contract Cloud related controls 16

17 Risk assessment for PCP Pilots Is a risk impact level scale required? Too many controls Is there a way to find a drilldown approach (e.g. depending on impact level) CSA CCM and Enisa metaframework are helpful but do not really define a drill-down method Not enough distinction between tenants responsibilities and CSP s guarantees. Too often, certification of underlying platform is seen as sufficient, where highest risks resides on application side 17

18 Risk assessment questionnaire Currently using (or inspired by): Impact levels from UK s HMG IA 1 Appendix A Structure of controls from CSA Cloud Controls Matrix 18

19 HMG IA 1 Appendix A example 19

20 Questionnaire Quick Scan 20

21 Availability Impact mapping 21

22 Questions? public D9.5 Deliverable 22