Goal Decomposition and Abductive Reasoning for Policy Analysis and Refinement
Abductive Reasoning for Policy
Refinement and Analysis
Department of Computing
Imperial College London
work in collaboration with A. Bandara and A. Russo
Goals and Initial Observations
• Policy Refinement: (stepwise)
derivation of enforceable policies from
higher level goals and SLAs.
• Cannot be automated generally.
• 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.
• Pattern-based Requirements Engineering technique for goalelaboration.
• Abductive reasoning used to derive policy elements for refined
• Abductive reasoning for policy analysis to ensure consistency of
• 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
• 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
• Model of Managed Objects
– Because policies are dependent upon the state of managed
• Abductive reasoning
– To be able to reason with partial information
– To provide explanations during analysis
– To elaborate plan of actions for achieving goals
Policy Analysis and Refinement Framework
of managed objects
Organisational model of
Errors + Conflicts
On file transfer,
if external recipient
transfer should be prohibited
P ⇒ !Q
P ⇒ !R
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);
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.
Model-checking for policy refinement
• Model-checking: popular for analysis since using search space
reduction techniques. Tools such as SPIN allow verification of
• 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
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
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?”
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
• 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.
Policy Transformation Using the Policy
• Policy Continuum, cf. 1993-1995 debate on the number of levels of
• 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
– 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.
• 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