Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Goal Decomposition and Abductive Reasoning for Policy Analysis and Refinement


Published on

Panel Position IM2007

Published in: Technology, Education
  • Be the first to comment

  • Be the first to like this

Goal Decomposition and Abductive Reasoning for Policy Analysis and Refinement

  1. 1. Goal-Decomposition and Abductive Reasoning for Policy Refinement and Analysis Emil Lupu Department of Computing Imperial College London work in collaboration with A. Bandara and A. Russo
  2. 2. Goals and Initial Observations •  Policy Refinement: (stepwise) derivation of enforceable policies from higher level goals and SLAs. •  Cannot be automated generally. Requirements →Implementation •  Difficult in general: incomplete specifications, numerous possibilities. ⇒ Easier if problem is constrained •  Simpler in practice: Application specific goals typically achieved in a small number of ways. Need to encode typical solutions. ⇒ Patterns.
  3. 3. Approach •  Pattern-based Requirements Engineering technique for goalelaboration. •  Abductive reasoning used to derive policy elements for refined policies. •  Abductive reasoning for policy analysis to ensure consistency of refinement. •  Formal representation for policies and managed objects automatically derived from design-level models (UML) and policy specification notations (Ponder). A. Bandara, E. Lupu, A. Russo, et al. Policy Refinement for DiffServ Quality of Service Management. IEEE eTNSM 3(2):2-13, 2006. Originally Proposed 1999, also see Policy 2003 and Policy 2004
  4. 4. Rationale •  Pattern based approach: –  Define and apply the “application specific” refinement patterns –  Encode policies resulting from refinement in a new pattern: reuse. •  Formal Specification –  For detecting inconsistencies (conflicts), performing analysis and validation •  Model of Managed Objects –  Because policies are dependent upon the state of managed resources •  Abductive reasoning –  To be able to reason with partial information –  To provide explanations during analysis –  To elaborate plan of actions for achieving goals
  5. 5. Policy Analysis and Refinement Framework Behavioural model of managed objects Policy specification Organisational model of managed objects Property checks Goals Errors + Conflicts Low-level Actions Refined Policies
  6. 6. Policy Refinement High-Level Policy On file transfer, if external recipient transfer should be prohibited (Event) (Condition) (Goal) P ⇒ !Q P ⇒ !R D C Elaborate Abduce Strategy Strategy Strategy Select Select B KAOS Patterns Objects Map A E R ⇒ !Q On transferFile(File, From, To) when To.Organisation != From.Organisation; subject s = /VMRSvcMgr; target t = From.Organisation.Firewall; do t.blockTraffic(‘ftp’, From.IP, To.IP);
  7. 7. Policy Analysis and Refinement Toolkit UML Editor Analysis/Refinement Client Tool (e.g. ArgoUML) Domain Service Analysis Service Persistence Provider Analyser File RDBMS LDAP … A-System XMI File CodeGen XSLT SISCtus Prolog Policies, Managed Objects, Goals, Domain Structure Presentation and demo at: Prolog Files
  8. 8. Advantages and Limitations •  Combines refinement, analysis and, validation. •  Permits reuse of solutions once derived. •  Provides understandable explanations: –  Why a particular plan of actions is a suitable refinement? –  Which strategy is being used? –  Which sequence of events leads to a specific conflict? •  May provide multiple solutions in an unconstrained problem space. Should be combined with approaches to compare refinement solutions e.g., utility functions. •  Requires some technical knowledge and human intervention. •  Requires models of managed resources. Can be combined with model transformation techniques.
  9. 9. Model-checking for policy refinement •  Model-checking: popular for analysis since using search space reduction techniques. Tools such as SPIN allow verification of larger models. •  The “price” paid for this reduction is that only a subset (and often a single) solution is returned - the counter example to a property •  Binary value - property holds unless a counter example is found. •  Why is the counter example is an adequate refinement solution? •  Use of SPIN for test generation: 1) inadequate coverage of generated tests 2) traces too long to be useful (Gargantini & Heitmeyer ESEC/FSE 1999) J Rubio-Loyola, J Serrat, M Charalambides, P Flegkas, G Pavlou. A Functional Solution for Goal-oriented Policy Refinement. IEEE Policy 2006. Canada. J Rubio-Loyola, J Serrat, M Charalambides, P Flegkas, G Pavlou. A Methodological Approach toward the Refinement Problem in Policy-based Systems. IEEE CommMag Oct. 2006, pp. 60-68
  10. 10. Any solution is not suitable for refinement! •  Can I get from A to B? - Analysis problem. •  How should I go to B each time I need it? - Policy Refinement problem
  11. 11. Further Thoughts on Model-Checking •  Requires complete information regarding the initial system state. Can the absence of a counterexample simply be due to missing information regarding the initial state? •  Is specialised for the dynamic behaviour and temporal properties. How can static properties be checked e.g. “what access rights have been granted to junior operators users?”
  12. 12. Case-based Reasoning Approaches •  In essence a classification problem: input (configuration) parameters w.r.t. desired values for the high level goal. •  Successful in some areas: product selection, image interpretation, intrusion detection. Mostly for “numerical problems”. Functional decomposition is more difficult. •  Relies on: solutions being known or leant, similarity metrics existing, non overlapping cases, knowing “all” relevant configuration parameters. •  Does not provide explanations unless similarity metrics are meaningful. Debugging case-based inferences is a nightmare. •  Useful for constrained numerical problems. Selection amongst a number of known solutions, e.g. patterns (for planning), parameter values for reconfiguration actions. MS Beigi, S Calo D Verma. Policy Transformation Techniques in Policy-based Systems Management IEEE Policy 2004, New-York, June 2004.
  13. 13. Policy Transformation Using the Policy Continuum •  Policy Continuum, cf. 1993-1995 debate on the number of levels of abstraction. •  Whenever I hear Transformation I think of Compilation –  Useful for transforming a device independent model into device commands. –  Applicable when the input language and the output language are well defined and a transformation process exists that can transform all inputs into outputs –  Difficult to reverse transformations. Difficult to “manage” the number of transformations required and their interdependencies. Correctness? Consistency? Explanations? Require formal reasoning. •  Ontologies … again. –  If specified with all integrity constraints and relations are they less complex than formal specifications? –  Ontolgy “mapping” is intractable in the general case event when applied to simple labelling. In which cases is it tractable? S Davy, B Jennings, J Strassner. Conflict-Prevention via Model-Driven Policy Refinement. IEEE DSOM’06, LNCS 4269, pp 209-220.
  14. 14. Conclusions •  Policy Refinement is work in progress. •  … but there has been a lot of progress in the last 3-4 years. •  Initial spectrum of techniques can tackle different aspects of refinement. Tools and implementations have been developed. •  Experimentation in application specific domains required: characteristics of application domains, complexity studies, … •  Combination of techniques required for more generic cases. •  CBR, pattern based goal decomposition, abductive reasoning and model transformation address slightly different problems and are complementary to some degree. •  Model checking: useful analysis technique, but refinement is different •  Ontology mapping and transformation. Beyond trivial application specific mappings will require other refinement techniques for its magic.