Panel Position IM2007

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

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