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
- Home
- Browse
- All Categories
- AI and Robotics
- Biotechnology
- Clean Technology
- Data Management
- Electronics - Devices
- Enterprise Applications
- Entertainment
- Internet and Web Development
- Management
- Mechanics
- Mobile - Wireless
- Networking and Communications
- Oil and Offshore
- Security
- Semiconductor
- Servers
- Software and s/w Development
- Storage
- Telecommunications
- Urban and Civil
- Community
- Upload
Comments 0
Log in to post a comment