Risk Management for Service-Oriented Systems

1. Risk Management for Service-Oriented Systems Natallia Kokash Advisor: Vincenzo D’Andrea

2. Introduction • What is Risk Management (RM)? • Why do we need RM for SOA? • Design of Service-Oriented Systems (SOSs) • Risk-aware SOS design • Risk Assessment • Conclusions and Future Work ICWE Doctoral Consortium Como, Italy

3. What is Risk Management? • Risk • potential negative impact to an asset that may arise from some present process or future event • Risk = probability of an accident x losses per accident • Risk Management • Process of identifying, assessing, and reducing the risk to an acceptable level • implementing the right mechanisms to maintain that level of risk. ICWE Doctoral Consortium Como, Italy

4. Risk Management in IT • Is indispensable! • A lot of research has been done • Project management [Freimut et al. 2001, Verdon and McGraw 2003] • Outsourcing [O'Keeffe et al. 2004] • Business processes [Neiger et al. 2006] • Security-critical systems • Model-based RM (CORAS [Jurjens and Houmb, 2004]) ICWE Doctoral Consortium Como, Italy

5. Risk analysis methodologies Analysis = identification + assessment [http://www.cip.ukcentre.com/risk.htm] Qualitative techniques: • Preliminary Risk Analysis (PHA) • HAZard and OPerability study (HAZOP) • Failure Mode and Effect Criticality Analysis (FMECA). • Tree-based techniques • Fault-Tree Analysis (FTA), • Event-Tree Analysis (ETA) • Cause- Consequence Analysis (CCA) • Management Oversight Risk Tree (MORT) • Safety Management Organization Review Technique (SMORT) • Techniques for dynamic systems • Go Method • Digraph/Fault Graph • Markov Modeling • Dynamic Event Logic Analytical Methodology • Dynamic Event Tree Analysis Method ICWE Doctoral Consortium Como, Italy

6. Why do we need RM for SOA? • No control over involved services • Correct behavior is not ensured • Services are difficult to test • May become unavailable or malfunctioning • Can be easily modified • Can misuse the data • Performance may vary • Conflicting interests of involved partners • Conditions (payment, etc.) may vary • New services appear • Will the system be profitable in new settings? ICWE Doctoral Consortium Como, Italy

7. Why RM for SOA is a challenge? Classification of SOAs [Tsai et al. 2007] • Static SOA • Collaboration protocols are known • Services are pre-selected • Dynamic SOA • Collaboration protocols are known • Services are selected at runtime • Dynamic collaboration • Collaboration established at runtime, • Services are selected at runtime • Run-time RM! • No party exists with full knowledge about the system ICWE Doctoral Consortium Como, Italy

8. s3 s1 + + s4 + s5 + s2 X Y Service composition Z Service oriented system X Y Service-Oriented Systems (SOSs) Partners Invoke Invoke s0 Client Provider ICWE Doctoral Consortium Como, Italy

9. QoS Issues • Domain-independent parameters • Throughput, capacity, execution cost, response time, availability, reliability, etc. • Domain-dependent parameters • Evaluate QoS at design timeto create a dependable system • Manage QoS at execution time to dynamically re-configure the application to maintain a certain QoS level ICWE Doctoral Consortium Como, Italy

10. Design of SOSs • Design abstract business processes • Identify abstract web services • Define collaborative patterns • Formalize functional and non-functional requirements • Find andevaluate existing web services, model alternative solutions • Evaluate risks • Adapt design models to reduce risks • Negotiate conditions and stipulate contracts with involved web services [Bochicchio et al. 2007] ICWE Doctoral Consortium Como, Italy

11. SOA Risks • Threats • Loss of service, data, clients • Unexpected service behavior or modifications • Performance problems • Violations of contracts • Assessment • Likelihood and implication of threats • Analysis of user expectations • Service testing • User feedback, reputation systems • Mitigation • Service selection, redundancy, redesign • Runtime monitoring • Service Level Agreements and policies ICWE Doctoral Consortium Como, Italy

12. Risk–aware SOS design ICWE Doctoral Consortium Como, Italy

13. Risk assessment • Quantitative techniques • Two dimensions: • how likely the uncertainty is to occur (probability) • what the effect would be if it happened (impact) • How to combine risks? • All threats are independent - sum • Otherwise? • There is one dominating threat – consider only it • There are mutually exclusive threats • … ICWE Doctoral Consortium Como, Italy

14. History of risk assessments ICWE Doctoral Consortium Como, Italy

15. Risk-driven service selection • Cost-benefit analysis • Choose the composition that maximized the expected profit Assumption: threats are independent! [Kokash and D'Andrea, 2007] ICWE Doctoral Consortium Como, Italy

16. Mitigating risk of a composite service failure • A composite web service must accomplish multiple user requests • Strategy: • increase the probability that all requests will be accomplished by the service • Redundant compositions • reduce resources per request (time, money, etc.) • Failed services increase losses (e.g., time) • If request is not accomplished (before deadline), penalty to the client must be paid. [Kokash and D'Andrea, 2007] ICWE Doctoral Consortium Como, Italy

17. Where to take data for Risk Assessment? • Advertised service descriptions • Full information is rarely available • Must we trust it? • Testing agencies • Rarely available • How often is it updated? • Testing by the client • Requires time • Shared sources of clients’ experience ICWE Doctoral Consortium Como, Italy

18. What we would like to have • Design time • Case studies • Execution time • A model for representing and tracking risks • Risk assessment strategies and quantitative metrics • A supporting tool • Risk mitigation via SOA redesign/reconfiguration • Transition from risks to QoS requirements, SLAs and policy assertions • Run-time selection of services and coordination patterns ICWE Doctoral Consortium Como, Italy

19. Related work • Verdon, D., McGraw, G.: Risk analysis in software design. IEEE Security and Privacy (2004) 33-37 • Roy, G.G.: A risk management framework for software engineering practice. ASWEC, (2004) 60-67 • Freimut, B., Hartkopf, S., Kaiser, P., Kontio, J., Kobitzsch, W.: An industrial case study of implementing software risk management. ESEC/FSE, (2001) 277-287 • Neiger, D., Churilov, L., zur Muehlen, M., Rosemann, M.: Integrating risks in business process models with value focused process engineering. ECIS, (2006) • O'Keeffe, F., Vanlandingham, S.: Managing the risks of outsourcing: a survey of current practices and their effectiveness. White paper, Protivity, http://www.protiviti.com/downloads/PRO/pro-us/product sheets/business risk/Protiviti ORM WhitePaper.pdf (2004) • Kokash, N., D'Andrea, V.: Evaluating quality of web services: A risk-driven approach. BIS. Volume 4439 of LNCS, Springer (2007) 180-194 • Bochicchio, M.A., D'Andrea, V., Kokash, N., Longo, F. Conceptual Modelling of Service-Oriented Systems,AWSOR, 2007 ICWE Doctoral Consortium Como, Italy

20. The end! • Questions? ICWE Doctoral Consortium Como, Italy