The Many Faces of Policy Based Management

wispxylopolistInternet και Εφαρμογές Web

7 Αυγ 2012 (πριν από 5 χρόνια και 1 μήνα)

250 εμφανίσεις

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

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

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

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

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