The Many Faces of Policy Based Management

The Many Faces of

Policy
B
ased Management

Morris Sloman

Imperial College London

1

Contents

•
Policies: Why and Where

•
Traditional policy specification


ECAs and access control rules

•
Policy specification for non
-
technical users

•
Human
-
centric policies

•
Scalability


self
-
managed cells

•
Higher
-
level utility functions

•
Policy analysis and refinement

•
Learning policy specifications

•
Conclusions

2

Why Policies

•
Distributed, automated management for large
-
scale
systems

•
Context
-
aware adaptation

•
Dynamic modification of management strategy

•
Policies can be dynamically changed at run
-
time

•
Define authorisation policy


•
NOT

new dynamic functionality


3

Policy Areas

Network and
Systems
Management

Access Control
and Security
Management

Enterprise
Distributed
Object
Computing

Policy Workshop

1999

Privacy

Trust

Business Rules

Multi
-
Agent
Systems

Web
-
Services

SLAs

Negotiation

Semantic Web

Autonomic
Computing

4

Network Management
&
Security

•
Networks are autonomous.

•
Diagnostic and adaptation to failures

and
to new requirements.

•
Networks must be extensible to

new services and new devices

•
Networks must collaborate

to identify attacks (e.g.,
DDoS
)

and react to them

e.g.,
traceback
, throttling, filtering

•
Networks can be federated in larger structures.

5

Autonomous Unmanned
Vehicles

•
Each vehicle is an
autonomous collection of
managed devices with
different functional
capabilities

•
Must be extensible to
different sensors and
modules

•
Can aggregate and
collaborate in fleets of
autonomous vehicles

•
Must interact with

external
environment

Body Area Networks for eHealth

•
Implanted and wearable sensors:
Heart monitoring, blood
-
pressure,
oxygen saturation, etc.

•
Continuous monitoring of
physiological condition e.g.,
cardiac arrhythmia.

•
Maintenance of chronic
conditions: heart deficiencies,
diabetes,
chronic
anaesthesia

•
Incremental drug delivery.

Context
dependent drug delivery.

•
Remote interrogation

•
Alert for emergency
interventions.

Body Area Networks

7

Universal Policy Specification

•
Universal policy language
–

holy grail of many
standardisation

bodies and academic research

•
Event
-
condition
-
action rules (obligations)

or condition
-
action rules

•
Access control rules (
authorisations
)

•
Roles provides a grouping of policies related to an agent
or person − RBAC


8

...

Ponder2 Policy Service

Cell Policy

Interpreter

Managed Objects

Event
Service

Policy Objects

PonderTalk

Commands

(and Policies)

Policy

Service

Domains

Holds refs to managed
objects: Devices, SMCs,
Policies, Roles,
etc

Actions

Events

9

See http://ponder2.net

Healthcare Policies

on

new_component
(id, profile,
addr
)

do


if

profile ==
“
heart rate
”

then


r = /fact/
hr.create
(profile,
addr
); /
sensors.add
(r)


on

hr
(level)

do



if

level >
130

then

/sensors/
os.setfreq
(10min);


/sensors/
os.setMinVal
(80)


on

context(activity)

do



if

activity ==
“
running
”

then


/policies/
normal.disable
(); /policies/
active.enable
()


auth
+

/patient

→

/
os
.{
setfreq
,
setMinVal
, stop, start}

auth
+

/patient

→

/policies.{load, delete, enable, disable}

10

ECA Approaches

•
IETF PCIM work in 2001: condition
-
action rules within
an information model

•
Lucent’s Policy Description Language (PDL)

A Policy Description Language. J. Lobo, R. Bhatia and S.
Naqvi
. In Proc. AAAI. July, 1999.

•
Ponder, Ponder2 for smartphones, Finger for
TinyOS

motes. From Imperial http:// ponder2.net

•
Accent from
Stirling


http
://
www.cs.stir.ac.uk
/accent/

•
Many papers in Policy, IM/NOMS

11

Policy Specification Issues

•
ECA, XACML etc. are not suitable for non
-
technical
users


Graphical tools

•
Complexity of specifying policies for large
-
scale systems


Self
-
managed cells

•
Do not cater for actions relating to unpredictable humans


Teleoreactive

(TR) polices

•
Rather low level policies


Utility
Functions

•
Conflicts may arise between policies



Logic based formalisms

12

Policy specification for

non
-
technical users

13

Comic Specifications

for Home networks

14

ComicStrip


iPad

or

iPhone

app



Ponder2 Policy Engine


Event
-
Condition
-
Actions

Linux



nox

tc


iptables


Comic 2

15


•
Alternative actions

o
Use email, SMS

o
Block for specified time


Self
-
Managed Cells

•
Catering

for scale

What is a Self
-
Managed Cell?

•
A set of hardware and software components forming an
administrative domain that is able to function
autonomously and thus capable of self
-
management.

•
Management services interact with each other through
asynchronous events propagated through a content
-
based event bus.

•
Policies provide local closed
-
loop adaptation.

•
Able to interact with other SMCs and able to compose in
larger scales SMCs.

17

Self
-
Managed Cell (SMC)

Control

actions

Decisions

Managed

Objects

Monitor

Events

Manager

Agent

Events

Policies

New functionality`

Policies

18

Peer
-
to
-
Peer Interactions

•
Layered SMCs: application /
services / network

•
Peer SMCs (peer devices,
peer networks, SLAs…)

…

…

19

SMC Composition

The internal SMCs
cease to advertise
themselves
externally.



The enclosing
SMC programs
the nested SMCs

20

SMCs discovery

•
On SMC discovery, each SMC assigns discovered SMC
to pre
-
defined domains.

•
Policies for domain apply to assigned SMC.

•
SMC Discovery can also result in policy
-
exchange and
sharing of events and services.

21

SMC Missions: Policy
Exchange

•
SMC Interfaces

define:

o
events
: that can be raised by an SMC

o
notifications
: that an SMC can receive

o
actions
: that can be invoked on the SMC

22

Lupu

et al Amuse,
Wiley Concurrency &
Computation Practice &
Experience 20:3 2008

Policy Exchange II

mission

patientT
(nurse, patient,
ECGlevel
,
ECGTime
)

do



on

patient.mloaded
()

do



nurse.store
(
patient.readlog
())


on

patient.hr
(level)

do



if

level >
ECGlevel

then


patient.startECG
(
);




patient.timer
(
ECGTime
,
endECG
()
);


nurse.ecgOn
()


on

patient.endECG
()

do



nurse.display
(
patient.readECG
())

23

SMC Missions: Policy
Exchange

auth
+

/nurse

→

/
patient.loadMission

// at the Patient


auth
+

/patient

→

/
nurse.store


// at the Nurse

auth
+

/patient

→

/
nurse.displayECG


on

newPatient
(p)

do




ref
=
p.loadMission
(/
patients.interface
,
p.interface
, 82, 40)
;



/
roles[p].add(ref)

24

Managing People

25

Human
-
centric Services

•
Some actions require human activity

•
Manage human agents as well as embedded
devices in applications e.g. patient care, military,
personal workflows

•
Humans:

o
Can postpone the execution of actions.

o
May perform unauthorized actions

o
Usually perform durative actions.

o
Conditions pertaining to durative actions may
change during execution

o
Perform actions sequentially
–

so need to
prioritize and schedule concurrent actions.



Manage Deviation

26

Nurse Policy

•
When an unknown person is detected in the
ward, the video feed from that ward is
immediately streamed to the ward nurse’s & the
head
-
nurse’s mobile device.

•
When a nurse is assisting a non
-
assigned
patient, the head nurse should be notified and
given the option to approve the activity.

o
If the head nurse does not approve it, the nurse should
be asked to provide a reason for undertaking the
activity.

o
If a reason is not given the head nurse and the
patient’s nurse are notified.

27

Teleo
-
Reactive Policy

•
Rule conditions continuously evaluated

•
Syntactic priority order

•
Only 1 action expression active at a time

•
Actions are durative but terminate when condition becomes false

•
If higher priority rule condition becomes true, its action is started
and current action is terminated

•
Default low priority action required

t
r

=


condition(Var)
1



action(Var)
1


condition
2



action
2
||
action
3


…


t
rue


action
n

28

Example TR managing a nurse


29

tr
-
policy
nursePolicy(Nurse
) =



strangerIn(Ward
)



-
> stream(
Ward.videoCam
) || alarm



doing(Nurse
, Activity)


& !
approved(Nurse
, Activity)



-
>
Nurse.seekReason
(Activity)



doing(Nurse
, Activity, Patient)


& !
assigned(Nurse
, Patient)



-
>
inform(HeadNurse
, Activity)



needsSupervision(Student
, Activity)




-
>
Nurse.approve
(Student, Activity)

Marinovic

et. al. TR Policies
CNSM 2010

Utility Functions

•
Express and manage high
-
level objectives

c.f. goal policies

•
Utility functions defined over
desired

state space
Action policies defined over
actual

state space

•
Select state to
maximise

utility

•
Move policy specification to a higher level for
Autonomic

Computing and Multi
-
Agent
Systems

30

What is a Utility Function

•
Utility functions map any
possible state of a system
to a scalar value

•
They
can be obtained from

o
Service Level Agreement

o
preference elicitation

o
simple
templates

•
They are a very useful
representation for high
-
level objectives

o
Value can be transformed and
propagated among agents to
guide system behavior

Possible

State

s
1

Possible

State

s
2

Possible

State

s
3

a
1

a
2

a
3

Current

State

S

U(
RT
)

=

Kephart and Walsh, Policy04

31

How to
manage

with
high
-
level policies?

•
Elicit
utility function U(
S
) expressed
in terms of service attributes
S

•
Model

how each attribute S
i

depends on controls
C

and
observables
O

o
Models expressed as

S
(
C; O
)

o
E.g., RT(routing weights, request
rate)

o
Models from experiments,
learning,
theory

•
Transform
from service utility U to
resource utility
U
’

by substitution

o
U(S) = U(S(C; O)) = U
’
(C; O)

•
Optimize
resource utility. As
observable
O

changes, set
C

to
values that maximize
U
’
(
C; O
)

o
C*(O)

=
argmax
C

U
’
(
C; O
)

o
U
’
*
(O)

=
U
’
(
C*(O)
;

O
)


U(RT, RPO)

Recovery
Point
Objective

Response Time

U

Transform


requests/sec


l
=
0.01

cpu

Backup rate b

U
’

U
’
(
cpu
, b;
l
)

32

33

Power
-
aware load balancing

Perf Mgr

n,
RT,
λ


n, pwr,
#cycles

System

Power Mgr

On/Off
i

n*,
w
*

(load
-
balancing
weights)

Model:
Pwr(n)

Model:
RT(
w
, n, λ)

Optimize
: U
’
(
w
, n)

Pwr(n)

Maximize U(
RT
,
pwr
)

Goal:

Save power by routing
web traffic to minimal number
of app servers w/o sacrificing
performance too much.



DB2

WebSphere

App. Server

WebSphere

App. Server

HTTP


Server

WebSphere

App. Server

Web requests

w
1

w
2

w
3

Das
, Kephart, Lefurgy, Tesauro, Levine, Chan
Autonomic Multi
-
agent Management of Power and
Performance in Data Centers
,
AAMAS 2008

Generating Utility Function

•
U
perf
(RT) = 1 or 0 (if SLA met or not met)

•
U
(RT,
Pwr
) = U(RT)
–

e
Pwr

•
Perform
offline experiments to model workload in terms of number
of clients (
l
), and response time (RT)

•
Target SLA = RT
0

= 1000ms

•
Transform to derive a
multicriteria

utility function to
maximised


U
’ (n,
l
)
= U (RT (n,
l
)
,
Pwr

(n,
l
))



•
Optimise

n*(
l
) =
argmax
n

U’ (n,
l
)


i.e

optimise

number of servers based on number of clients

34

Experimental Results

35

•
A few extra tweaks

o
Need to account for startup
latencies (several minutes)

o
Cannot just observe current
workload
–

need to forecast
5
-
10 minutes ahead so as
to allow for start up time

o
Heuristics
to ensure that
do
not
turn servers on and off
too often


Thursday

Friday

Time (minutes)

Workload
(# clients)

Response
time (msec)

# servers on

Power
(watts)

Trade6 workload;
NASA traffic

SLA

Response time

Power

# servers

Avg

Power Savings = 27%
No SLA violation

Utility Function Summary

•
Utility functions can aggregate multiple control
parameters and so avoid policy conflicts.

•
Defining a suitable utility function can be difficult and
complex requiring one or more of the following
techniques

o
Analysis

o
Simulation or experimentation

o
Various learning mechanisms

•
Seems to work well where adaptation focuses on
performance optimization

36

Analysis for conflicts

Policy Analysis

•
Policy specifications are complex and conflicts may arise
due to:
different sources

for the policy specifications or
conflicting goals

e.g., availability vs. maintenance,
emergency vs. security, etc.

•
Policy Analysis
seeks to provide the means to:

o
Review the specification

to check expected
behaviour

in specific
circumstances.

o
Ensure
consistency

of the policy specification i.e. absence of
conflicts
.

o
Ensure
correctness

of the policy specification
w.r.t

desired
properties.

o
Ensure
minimality

of the specification
w.r.t

achieving a higher
-
level
goal or property.

38

Craven et al, Expressive
Policy Analysis,
AsiaCCS

2009

Authorisation Policies

•
Positive
Authorisation

L
1



L
n



C
1



C
m

→ permitted (Sub, Tar, Act, T )



Negative
Authorisation

L
1



L
n



C
1



C
m

→ denied (Sub, Tar, Act, T )

where L are
generalised

domain specific constraints and C are time
constraints.
Availability rules
encode default
behaviour

and default
policies.



•
Example:

Mission personnel who are permitted to read mission orders
are allowed to read mission intelligence within 12 hours of the mission


O,M : mission(M, T
1
)


orders(O, M, T
1
)




intel
(I, M, T
2
)


permitted(Subject, O, read, T
1
)




startTime
(M, T
3
, T
1
)




T
1

< T
2

< T
3


(T
3

− T
2
) < 12hrs
→ permitted(Subject, I, read, T
2
)

39

Obligation Policies

•
Subject acquiring an obligation must perform action on target at
time T between T
1

& T
2
.

Obligations persist unless revoked or
fulfilled.

obl
(Subject, Target, Action, T
1
, T
2
, T)



do(Subject, Target, Action, T)


T
1



T


T
2


→
fulfilled
(Subject, Target, Action, T)

obl
(Subject, Target, Action, T
1
, T
2
, T)


T > T
2


→
violated
(Subject, Target, Action, T)

•
Example:

A node must provide a 2nd identification within 5 minutes
of establishing a connection to the wireless server; otherwise the
server will drop the connection.

node(U, T)


do(U, server, connect(U, server), T)


→
obl
(U, server, submit2ID(U, server), T, T + 5min, T)

violated
(U, server, submit2ID(U, server), T)


→
obl
(server, server, disconnect(U, server), T, T + 1, T)

40

Policy Analysis

•
Define system
behaviour

(semantics) in terms of execution traces of inputs,
states, outputs.

•
Policies defined as
restrictions

over possible system traces
.

•
Policies
Π

should be consistent
, as it is not possible to construct a supported
trace in D ∩ mod(
Π
) that satisfies both permitted and
not

permitted, or
denied and
not

denied, for a given subject, target, action and time.

•
Authorisation

Modality conflicts
:
Π

accepts at least one supported trace
where permitted(sub, tar, act, t) and denied(sub, tar, act, t) for the same sub,
tar, act, t

•
Obligation Modality conflicts
:
Π

accepts at least one supported trace where
obl
(sub, tar, act, t
1
, t
2
,t) at t
1
≤

t
≤

t
2
and at same t satisfies denied(sub, tar,
act, t)

•
Coverage analysis
: does
Π

cover all cases of interest e.g. Does Alice have
appropriate permissions at the appropriate time? (cf. Review
)

•
Application specific conflicts
e.g. separation of duties can also be detected

41

Policy Refinement

Policy Refinement

•
Often defined as the
(stepwise) derivation of enforceable
policies

from higher level specifications.

•
Derived
policies must entail the higher
requirement
-

correct
,
consistent, minimal and amenable to review.

•
Cannot be automated generally

but partial automation with
tool support is feasible

Goal/
Req
:
Protect troop location information from
unauthorised

disclosure

Who can access location information?

Granularity of the information location provided.

Protection of Information in communications system.

43

Layered Refinement

LAYER 0

LAYER 1

LAYER ...

LAYER N

WITHIN A LAYER

44

Refinement through Action
Decomposition

•
Refinement by decomposing the action into a sequence
of lower level actions.

•
Can be specified as
action
decomposition rules that can
be matched against the high level action.

•
The transformation takes as parameter:

o
the high
-
level action and resources it is performed on

o
the types (classes) of objects available at the lower level

45

Craven et al,
Decomposition
Techniques for policy
refinement , CNSM 2010

•
Conditioned Action

o
where
Ci

are constraints
on the domain class
model

Refinement (transformation)
rules

(
Sub
,
T
ar
,
A
c
t
)
:
C
1
,
...,
C
n
•
Refinement Rule

o
can only refine to
objects/classes of the
domain model

o
can only refine to valid
actions

(
Sub
,
T
ar
,
A
c
t
)
:
Conds

t
he
n
(
Sub
1
,
T
ar
1
,
A
c
t
1
)
:
Conds
1
t
he
n ...
t
he
n
(
Sub
n
,
T
ar
n
,
A
c
t
n
)
:
Conds
n
46

Example Policy

•
Platoon communication officers must file daily
activity reports to the division their platoon belongs
to between 2000h and 2200h

obl
i
ga
t
i
on(
S
ub,T
a
r
,f
i
l
e
Re
p(
R)
,2000h,2200h)

hol
ds
A
t
(
obj
(
S
ub,c
om
m
s
O
f
f
i
c
e
r
)
,T
)
,hol
ds
A
t
(
a
s
s
(
S
ub,be
l
ongs
,P
)
,T
)
hol
ds
A
t
(
obj
(
P
,pl
a
t
oon)
,T
)
, hol
ds
A
t
(
obj
(
T
a
r
,di
vi
s
i
on)
,T
)
hol
ds
A
t
(
P
, pa
r
t
_of
, T
a
r
)
,
hol
ds
A
t
(
a
s
s
(
R, r
e
por
t
T
ype
,da
i
l
yS
um
m
a
r
y)
,T
)
,
2000h

T


2200h
47

Refinement Rule

•
Filing a report means uploading to a repository,
backing up the report and notifying the
division
’
s
communications officer

(
S
ub,T
a
r
,f
i
l
e
Re
p(
R)
)
:



(
S
ub, T
a
r
1
,
upl
oa
d(
R)
:

obj
(
T
a
r
1
,
r
e
por
t
Re
pos
)
, a
ggr
e
g(
T
a
r
1
,be
l
ongs
,T
a
r
)
t
he
n (
S
ub, T
a
r
2
,
ba
c
kup(
R)
:

obj
(
T
a
r
2
,ba
c
kupS
e
r
ve
r
)
, a
s
s
(
T
a
r
1
,be
l
ongs
, T
a
r
)
)
t
he
n (
S
ub, T
a
r
3
,
not
i
f
y
(
upl
oa
d(
R)
)
:

obj
(
T
a
r
3
,c
om
m
s
O
f
f
i
c
e
r
)
, a
s
s
(
T
a
r
3
,be
l
ongs
, T
a
r
)
)
48

49

Operationalization

•
Is the task of allocating specific resources (i.e., subjects
and target objects) to the decomposed actions

•
Query a UML Model that holds current information about
the objects in existence in the domain and their
properties

•
Particular resources from the domain are selected to
which the policy applies, in accordance with the
information passed in the query

Learning Policies

Learning Policy Rules

51

•
Specifying policies requires technical know how

•
Difficult to anticipate unforeseen adaptation

•
Learn Rules from user actions

•
Users must be involved in learning process

•
Inductive Learning

o
Facilitates learning with
flexible domain knowledge
representation

o
Interactive rule revision

o
Can
cope with noisy input
data


Context

Scenario

52

Learn policy rules related to call screening,

from user behavior

Requirements
:

o
User should be able to
understand and modify rules

o
Learning in background

o
Incrementality

o
Manage structured
information

o
Adaptability. Working
conditions are various
(interaction with different
sensors)

User Agent

Advertisement

Phone call

Current credit

Current location

Learning rules of user behavior

53

Contextual data:


Location




Co
-
location


Time of call


IdCaller

group…


….but also running applications,

active profile, last call accepted…

User actions

Revised user
behaviour

rules

Context

Domain knowledge

Existing user
behaviour

rules

B

U
–

user agent

Examples

Learning

Revision
s

U’
–

user agent

Revision:



delete/add conditions



delete/add rules

•
Inductive Logic Programming
:

»
Find
H
such that
B
⋃

H
⊨

E.
Where

•
B: background knowledge

•
H: hypotheses

•
E: positive and negative examples

Learning Example

54

At home

H

H

H

07
:00

Call from

At

location

Day

1

07
:30

U1 = { do(
accept_call
(
Call_Id
, From), T ) ← T ≥ 07:30 }

At home

At home

At Imperial

Near desktop

H

C

C

H

F

CF

H

H

07
:00

Call from

At location

Near device

Day 2

07:30

•
Revision based on who is calling and location :

U2
=
{do
(
accept_call
(
Call_Id
, From), T ) ← T ≥ 07:30
∧



in_group
(From, college).

do
(
accept_call
(
Call_Id
, From), T ) ← T ≥ 07:30
∧






¬
holdsAt
(status(location(imperial)), T ). }


Day 3 Revision:
At work means in the office

55

At home

Near desktop

H

H

H

F

C

CF

07:00

Call from

At location

Near device

Day 3

H

Near desktop

At Imperial

07
:30


U
3

= {do
(
accept_call
(
CallId
, From), T ) ← T ≥ 07:30
∧


in_group
(From, college).


do(
accept_call
(
CallId
, From), T ) ← T ≥ 07:30
∧



¬
holdsAt
(status(
bluetooth_near
(
desktop)
), T

). }

1) Incoming call

2)
do(accept_call(charles),T
) ?


YES

3) Ring the call

Corapi

et al, Learning
rules form user
behaviour

AIAI 2009

Smartphone interface


C
H
A
P
T
E
R
5.
A
P
P
L
I
C
A
T
I
O
N
O
F
T
H
E
L
E
A
R
N
I
N
G
F
R
A
M
E
W
O
R
K
T
O
D
A
T
A
CO
LLECT
ED
O
N
A
N
D
RO
ID
(a)
The
R
esult
V
iew
(b)
The
I
n
t egrit
yConst rain
t s
View
F
i
gu
r
e
5.
9:
T
h
e
R
e
s
u
l
t
an
d
I
n
t
e
gr
i
t
y
C
on
s
t
r
ai
n
t
s
v
i
e
w
5
.
5
.
1
A
ppl
i
ca
t
i
o
n
us
a
g
e
W
e
t
h
ou
gh
t
i
t
w
ou
l
d
b
e
a
go
o
d
i
d
e
a
t
o
k
e
e
p
t
r
ac
k
of
t
h
e
u
s
e
r
’
s
ap
p
l
i
c
at
i
on
u
s
age
.
W
h
i
l
e
t
h
i
s
s
ou
n
d
s
l
i
k
e
i
t
s
h
ou
l
d
b
e
a
s
i
m
p
l
e
t
as
k
i
t
,
u
n
f
or
t
u
n
at
e
l
y
,
p
r
o
v
e
d
t
o
b
e
a
l
i
t
t
l
e
m
or
e
c
om
p
l
i
c
at
e
d
t
h
an
w
h
at
w
e
h
ad
or
i
gi
n
al
l
y
t
h
ou
gh
t
.
As
a
r
e
s
u
l
t
,
t
h
e
An
d
r
oi
d
S
D
K
d
o
e
s
n
ot
p
r
o
v
i
d
e
a
w
a
y
,
t
h
r
ou
gh
i
t
s
AP
I
,
t
o
d
e
t
e
c
t
t
h
e
t
i
m
e
at
w
h
i
c
h
an
ap
p
l
i
c
at
i
on
i
s
l
au
n
c
h
e
d
,
f
or
ob
v
i
ou
s
s
e
c
u
r
i
t
y
r
e
as
on
s
.
T
o
o
v
e
r
c
om
e
t
h
i
s
p
r
ob
l
e
m
,
w
e
t
ak
e
a
d
i
↵
e
r
e
n
t
ap
p
r
oac
h
.
T
h
e
An
d
r
oi
d
Ac
t
i
v
i
t
y
M
an
age
r
l
ogs
e
v
e
r
y
ap
p
l
i
c
at
i
on
l
au
n
c
h
e
v
e
n
t
b
y
i
t
s
p
ac
k
age
n
am
e
.
F
or
e
x
am
p
l
e
,
com.andr oi d.camer a
s
u
gge
s
t
s
t
h
at
t
h
e
u
s
e
r
i
s
u
s
i
n
g
a
t
h
e
p
h
on
e
’
s
c
am
e
r
a.
T
h
e
r
e
f
or
e
,
t
o
al
l
o
w
ou
r
ap
p
l
i
c
at
i
on
t
o
d
e
t
e
c
t
ap
p
l
i
c
at
i
on
l
au
n
c
h
e
v
e
n
t
s
an
d
t
h
e
i
r
d
u
r
at
i
on
,
w
e
u
s
e
J
a
v
a’
s
Runt i me
c
l
as
s
t
o
e
x
e
c
u
t
e
t
h
e
c
om
m
an
d
l ogcat
Act i vi t yManager:I
*:S
.
Logc
at
,
i
s
An
d
r
oi
d
’
s
o
w
n
c
on
s
ol
e
ap
p
l
i
c
at
i
on
t
h
at
al
l
o
w
s
ac
c
e
s
s
t
o
l
ogs
at
r
u
n
-
t
i
m
e
.
W
e
t
h
e
n
ob
t
ai
n
an
I nput St r eamReader
an
d
c
on
t
i
n
u
ou
s
l
y
fi
l
t
e
r
e
v
e
n
t
s
as
t
h
e
y
ar
r
i
v
e
.
W
e
p
u
t
s
om
e
t
h
ou
gh
t
i
n
t
o
t
h
i
s
t
o
a
v
oi
d
d
u
p
l
i
c
at
e
e
n
t
r
i
e
s
.
Li
k
e
w
e
h
a
v
e
p
r
e
v
i
ou
s
l
y
m
e
n
t
i
on
e
d
,
e
ac
h
ap
p
l
i
c
at
i
on
c
on
s
i
s
t
s
of
a
fi
n
i
t
e
s
e
t
of
ac
t
i
v
i
t
i
e
s
an
d
al
l
r
e
s
i
d
e
w
i
t
h
i
n
t
h
e
s
am
e
p
ac
k
age
.
C
on
s
e
q
u
e
n
t
l
y
,
i
f
an
ap
p
l
i
c
at
i
on
h
as
d
i
s
p
l
a
y
e
d
t
w
o
ac
t
i
v
i
t
i
e
s
,
An
d
r
oi
d
’
s
Logc
at
p
r
i
n
t
s
t
h
e
p
ac
k
age
n
am
e
t
w
i
c
e
.
T
o
c
i
r
c
u
m
v
e
n
t
t
h
i
s
,
w
e
i
gn
or
e
e
n
t
r
i
e
s
w
i
t
h
t
h
e
s
am
e
p
ac
k
age
n
am
e
w
i
t
h
i
n
a
p
e
r
i
o
d
64
C
H
A
P
T
E
R
5.
A
P
P
L
I
C
A
T
I
O
N
O
F
T
H
E
L
E
A
R
N
I
N
G
F
R
A
M
E
W
O
R
K
T
O
D
A
T
A
CO
LLECT
ED
O
N
A
N
D
RO
ID
(a)
The
R
esult
V
iew
(b)
The
I
n
t egrit
yConst rain
t s
View
F
i
gu
r
e
5.
9:
T
h
e
R
e
s
u
l
t
an
d
I
n
t
e
gr
i
t
y
C
on
s
t
r
ai
n
t
s
v
i
e
w
5
.
5
.
1
A
ppl
i
ca
t
i
o
n
us
a
g
e
W
e
t
h
ou
gh
t
i
t
w
ou
l
d
b
e
a
go
o
d
i
d
e
a
t
o
k
e
e
p
t
r
ac
k
of
t
h
e
u
s
e
r
’
s
ap
p
l
i
c
at
i
on
u
s
age
.
W
h
i
l
e
t
h
i
s
s
ou
n
d
s
l
i
k
e
i
t
s
h
ou
l
d
b
e
a
s
i
m
p
l
e
t
as
k
i
t
,
u
n
f
or
t
u
n
at
e
l
y
,
p
r
o
v
e
d
t
o
b
e
a
l
i
t
t
l
e
m
or
e
c
om
p
l
i
c
at
e
d
t
h
an
w
h
at
w
e
h
ad
or
i
gi
n
al
l
y
t
h
ou
gh
t
.
As
a
r
e
s
u
l
t
,
t
h
e
An
d
r
oi
d
S
D
K
d
o
e
s
n
ot
p
r
o
v
i
d
e
a
w
a
y
,
t
h
r
ou
gh
i
t
s
AP
I
,
t
o
d
e
t
e
c
t
t
h
e
t
i
m
e
at
w
h
i
c
h
an
ap
p
l
i
c
at
i
on
i
s
l
au
n
c
h
e
d
,
f
or
ob
v
i
ou
s
s
e
c
u
r
i
t
y
r
e
as
on
s
.
T
o
o
v
e
r
c
om
e
t
h
i
s
p
r
ob
l
e
m
,
w
e
t
ak
e
a
d
i
↵
e
r
e
n
t
ap
p
r
oac
h
.
T
h
e
An
d
r
oi
d
Ac
t
i
v
i
t
y
M
an
age
r
l
ogs
e
v
e
r
y
ap
p
l
i
c
at
i
on
l
au
n
c
h
e
v
e
n
t
b
y
i
t
s
p
ac
k
age
n
am
e
.
F
or
e
x
am
p
l
e
,
com.andr oi d.camer a
s
u
gge
s
t
s
t
h
at
t
h
e
u
s
e
r
i
s
u
s
i
n
g
a
t
h
e
p
h
on
e
’
s
c
am
e
r
a.
T
h
e
r
e
f
or
e
,
t
o
al
l
o
w
ou
r
ap
p
l
i
c
at
i
on
t
o
d
e
t
e
c
t
ap
p
l
i
c
at
i
on
l
au
n
c
h
e
v
e
n
t
s
an
d
t
h
e
i
r
d
u
r
at
i
on
,
w
e
u
s
e
J
a
v
a’
s
Runt i me
c
l
as
s
t
o
e
x
e
c
u
t
e
t
h
e
c
om
m
an
d
l ogcat
Act i vi t yManager:I
*:S
.
Logc
at
,
i
s
An
d
r
oi
d
’
s
o
w
n
c
on
s
ol
e
ap
p
l
i
c
at
i
on
t
h
at
al
l
o
w
s
ac
c
e
s
s
t
o
l
ogs
at
r
u
n
-
t
i
m
e
.
W
e
t
h
e
n
ob
t
ai
n
an
I nput St r eamReader
an
d
c
on
t
i
n
u
ou
s
l
y
fi
l
t
e
r
e
v
e
n
t
s
as
t
h
e
y
ar
r
i
v
e
.
W
e
p
u
t
s
om
e
t
h
ou
gh
t
i
n
t
o
t
h
i
s
t
o
a
v
oi
d
d
u
p
l
i
c
at
e
e
n
t
r
i
e
s
.
Li
k
e
w
e
h
a
v
e
p
r
e
v
i
ou
s
l
y
m
e
n
t
i
on
e
d
,
e
ac
h
ap
p
l
i
c
at
i
on
c
on
s
i
s
t
s
of
a
fi
n
i
t
e
s
e
t
of
ac
t
i
v
i
t
i
e
s
an
d
al
l
r
e
s
i
d
e
w
i
t
h
i
n
t
h
e
s
am
e
p
ac
k
age
.
C
on
s
e
q
u
e
n
t
l
y
,
i
f
an
ap
p
l
i
c
at
i
on
h
as
d
i
s
p
l
a
y
e
d
t
w
o
ac
t
i
v
i
t
i
e
s
,
An
d
r
oi
d
’
s
Logc
at
p
r
i
n
t
s
t
h
e
p
ac
k
age
n
am
e
t
w
i
c
e
.
T
o
c
i
r
c
u
m
v
e
n
t
t
h
i
s
,
w
e
i
gn
or
e
e
n
t
r
i
e
s
w
i
t
h
t
h
e
s
am
e
p
ac
k
age
n
am
e
w
i
t
h
i
n
a
p
e
r
i
o
d
64
56

Conclusion

•
Authorisation

policies: widely used but no dominant
notation
–

XACML?

•
ECA or CA rules: many different forms, cater for
predefined adaptation
eg

for failures, context changes

•
TR
–

a variation of CA to cater for human centric
activities

•
Utility functions: good for autonomic
optimisation

but
hard to define

•
Logic Formalism: more common for security policy,
essential for analysis but lack of suitable toolsets

•
Refinement is still an unsolved problem

•
More focus on learning techniques in the future


57

Acknowledgements

•
Emil
Lupu
, Alessandra Russo,
Naranker

Dulay
, Robert
Craven,
Domenico

Corapi
,
Srdjan

Marinovic
,
Dimosthenis

Pediaditakis
,
–

Imperial College


•
Tom Lodge
–

Nottingham


•
Jeff
Kephart
, Jorge Lobo
–

IBM, NY

58