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
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.
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
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
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
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);
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:
http://www.doc.ic.ac.uk/~bandara/research/ponderART-Demo/

Prolog
Files
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
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
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
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.
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.
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.

Goal Decomposition and Abductive Reasoning for Policy Analysis and Refinement

  • 1.
    Goal-Decomposition and Abductive Reasoningfor Policy Refinement and Analysis Emil Lupu Department of Computing Imperial College London work in collaboration with A. Bandara and A. Russo
  • 2.
    Goals and InitialObservations •  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.
    Approach •  Pattern-based RequirementsEngineering 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.
    Rationale •  Pattern basedapproach: –  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.
    Policy Analysis andRefinement Framework Behavioural model of managed objects Policy specification Organisational model of managed objects Property checks Goals Errors + Conflicts Low-level Actions Refined Policies
  • 6.
    Policy Refinement High-Level Policy On filetransfer, 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.
    Policy Analysis andRefinement 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: http://www.doc.ic.ac.uk/~bandara/research/ponderART-Demo/ Prolog Files
  • 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.
    Model-checking for policyrefinement •  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.
    Any solution isnot 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.
    Further Thoughts onModel-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.
    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.
    Policy Transformation Usingthe 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.
    Conclusions •  Policy Refinementis 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.