Efficient Evaluation of History-based Policies

Imperial College London, UK

IBM Watson Research, US

History-based Policies

2

• Policies are widely used among ITA projects– e.g. Sensor Fabric, Gaian Database

• Policies frequently use historical conditions depending on past system states– Example 1: “A device is permitted to charge its battery if

the power level was below 90% anytime in the past 5 minutes.”

– Example 2: “X is not allowed to access radio R1 if X has accessed radio R2, and R1 and R2 were assigned to different missions.”

Policies in Abstract Form

3

Such policies can be expressed in an abstract form [Craven et al.]:• Example 1: “A device is permitted to charge its battery if the

power level was below 90% anytime in the past 5 minutes.”permitted(X, battery(X), charge, T) ← holds(power_level(X, L), T1), L < 90%, T – 5 mins ≤ T1 ≤ T.

• Example 2: “X is not allowed to access radio R1 if X has accessed radio R2 since R1 and R2 were assigned to different missions.”

denied(X, R1, access, T) ← do(X, R2, access, T1), T1 < T, holds(mission(R1, M1), T1), holds(mission(R2, M2), T1), M1 ≠ M2.

Evaluation of Historical Conditions

4

• Evaluation of historical conditions at current time requires past system states, i.e. a system execution history

• A naïve approach– Stores everything, e.g. all values in the past– Evaluates everything, e.g. temporal constraints

... 92% 91% 90% 89% 88% 87% 86% 85% UAV1’s power level… 40% 39% 38% 38% 38% 39% 40% 41% UAV2’s power level

…… null null null m1 m1 m1 m1 m1 Radio1’s mission … m1 m1 m1 m1 m1 m2 m2 m2 Radio2’s mission… 13mins 14mins 15mins 16mins 17mins 18mins 19mins 20mins time

System states

System events

… do(uav2,battery(uav2),charge,16mins) do(admin,radio2,assign(m1),18mins) do(soldier1,radio1,access,19mins) …

The Naïve Approach Is Not Acceptable

5

In tactical situations, the policy managed devices often have limited computational power and space, and the permission granting for an action request must be decided fast!

Problems of the naïve approach:• a full history is often impractical to store• temporal reasoning requires extra timeExisting policy management systems can’t handle history-

based policies

Policies

History

request

permitaction

denyaction

Our Contributions

6

An approach for fast evaluation of history-based policies by1. transforming policies to non-history based form, and2. using the generated monitoring rules to records only what needs to

be remember

Thus, high level history-based policies can be enforced by systems that have not explicit management of histories, and

Evaluation of (History-based Policies + Full History)

becomesEvaluation of (Non-history based Policies + Bounded History)

Proof sketch for the correctness has been given.

The Ideas

7

• Observing that at any time point– a historical state was once a current state– the current state will become a historical state

• Thus, – the policies tell us what needs to be remember– and the information can be collected at each state

Related Work:• Chomicki has previously proposed a similar scheme for queries in

relational database where temporal constraints are expressed in Past Linear Temporal Logic, e.g. using previously and since– In constrast, out approach is tailored to policy evaluation and can

additionally handle explicit time, e.g. T2 – 10 minutes ≤ T1 ≤ T2

An Example

8

“A device is permitted to charge its battery if the power level was below 90% anytime in the past 5 minutes.”

permitted(X, battery(X), charge, T) ← holds(power_level(X, L), T1), L < 90%, T – 5 mins ≤ T1 ≤ T.

• Steps for handling single historical condition1. Identify the condition and the temporal constraint

2. Replace them with a current condition (i.e. “macro” condition): permitted(X, battery(X), charge, T) ← holds(low_power(X), T).

3. Generate monitoring rules according to the replaced components If power_level(x,l) changes s.t. l < 90%, then records low_power(x) immediately If power_level(x,l) changes s.t. l ≥ 90%, then removes low_power(x) in 5 mins

4. Evaluation of the macro condition holds(low_power(X), T) is just a database query for low_power(X) at T.

An Example (cont.)

9

A time line

T1 T2 T2+5mins

power_level(x,l), l ≥ 90% power_level(x,l), l < 90% power_level(x,l), l ≥ 90%

insert low_power(x)

retract low_power(x)

¬ permitted(..., charge) ¬ permitted(..., charge)permitted(..., charge)

Notations and Definitions

10

• Simplified form of a policy:p(T) ← h1(T1), … , hn(Tn), C1, … ,Cm.

– each temporal constraint Ci is of the form Ti # Tj ± c where • c is a constant, Ti and Tj are time variables of hi and hj

• # is one of {=, <, ≤, >, ≥}

• In a policyp(T) ← … , h(Ti), … , C1, … ,Cm.

– h is a historical condition w.r.t. p, if C1, … , Cm ╞ Ti ≠ T

– h is a current condition w.r.t. p, otherwise

Basic Cases: Single Condition

11

Case (1): Condition h holds before T – ε p(T) ← h(T1), T1 ≤ T– ε(ε ≥ 0)

0 T1 T-ε T

Case (2): Condition h holds within T – δ p(T) ← h(T1), T – δ ≤ T1 ≤ T (δ ≥ 0)

0 T-δ T1 T

Case (3): Condition h holds between T – δ and T – ε p(T) ← h(T1), T –δ ≤ T1 ≤ T– ε (δ ≥ ε ≥ 0)

0 T-δ T1 TT-ε

NB: when δ = ε = c : Condition h holds exactly at T-c p(T) ← h(T1), T1 = T – c (c ≥ 0)

Basic Cases: Single Condition

12

Case (1): Condition h holds before T – ε p(T) ← h(T1), T1 ≤ T– ε(ε ≥ 0)

0 T1 T-ε T

Case (2): Condition h holds within T – δ p(T) ← h(T1), T – δ ≤ T1 ≤ T (δ ≥ 0)

0 T-δ T1 T

Case (3): Condition h holds between T – δ and T – ε p(T) ← h(T1), T –δ ≤ T1 ≤ T– ε (δ ≥ ε ≥ 0)

0 T-δ T1 TT-ε

NB: when δ = ε = c : Condition h holds exactly at T-c p(T) ← h(T1), T – c (c ≥ 0)

Non-history based policyp(T) ← h’(T)

Monitoring RulesCase (1): on h changes at T, if h is true, do assert h’ at T+ε

Case (2): on h changes at T, if h is true, do assert h’ at T

on h changes at T, if h is false, do retract h’ at T+δ

Case (3): on h changes at T, if h is true, do assert h’ at T+ε

on h changes at T, if h is false, do retract h’ at T+δ

Monitoring rules can be implemented as Event-Condition-Action rulesNegative historical conditions can be handled similarly

e.g. negate the condition in the monitoring rules

Simple Cases: Two Conditions

13

Condition h1(T1) is historical to h2(T2) if the time constraints over T1 and T2 matches one of the basic patterns – denoted as T1 « T2.

• Parallel Composition:p(T) ← h1(T1), h2(T2), T1 « T, T2 « T.

– h1 and h2 can be transformed independently• Serial Composition:

p(T) ← h1(T1), h2(T2), T1 « T2, T2 « T.

– break it into twop(T) ← combined_h2(T2), T2 « T.

combined_h2(T2) ← h2(T2), h1(T1), T1 « T2.

– can do this recursively if has more than two conditions

Complex Cases: Multiple Conditions

14

Example 3: A rather complex policy rule with multiple historical conditions:

p(T) ← h1(T1), h2(T2), h3(T3), h4(T4), T1 « T, T2 « T, T3 « T2, T4 « T2, T4 « T1, T4 « T3.

This can also be handled automatically using the basic and simple cases!

An Automatic Transformation

15

p(T) ← h1(T1), h2(T2), h3(T3), h4(T4),

T1 « T, T2 « T, T3 « T2, T4 « T2, T4 « T1, T4 « T3.

1. Construct and normalise the Directed Connected Graph (DCG) representing the relationships between historical conditions;

2. Topologically sort the DCG:

p

h2h3

h1

h4

3. Recursively transform from the DCG (from right to left), e.g. the branch starting from h2 and the branch staring from h1:

p(T) ← combined_h1(T1), T1 « T, combined_h2(T2), T2 « T combined_h1(T1) ← h1(T1), h4(T4), T4 « T1. combined_h2(T2) ← h2(T2), h4(T4), T4 « T2, h3(T3), T3 « T2, T4 « T3

4. Each of the final set of rules contains only single historical condition. Transform them and generate the monitoring rules accordingly.

Steps:

Special Cases: Durative Conditions

16

• Historical condition can also refer to a period that cannot be computed from a single time variable with offsets like Case 3.– define positive/negative “durative” predicates, e.g.

h_Between(T1, T2) ← h(T3), T1 ≤ T3, T3 ≤ T2. not_h_Between(T1, T2) ← not h(T3), T1 ≤ T3, T3 ≤ T2.

• Example 4: “The server can start data transfer if the client has authenticated itself after the request was made.”permitted(X, Y, trans, T) ←

do(Y, X, req, T1), T1 ≤ T, doBetween(Y, X, auth, T1, T).– By replacing doBetween/4 with its definition, the policy has two

conditions in serial composition:permitted(X, Y, trans, T) ←

do(Y, X, req, T1), do(Y, X, auth, T3, T), T1 ≤ T3, T3 ≤ T.

Special Cases: Durative Conditions

17

• Example 5: “The client is allowed to connect to the server if the server has always been in subnet A since start-up.”permitted(X, Y, connect, T) ←

do(admin, Y, startup, T1), T1 ≤ T, not notHoldsBetween(in(Y, subnetA), T1, T).

• This forms the 4th base case and new transformation is required.

• Thus, we can handle historical conditions expressing always and never temporal operators.

Can’t flatten the condition

Case (4): Condition h2 since condition h1 p(T) ← h(T1), T1 ≤ T, not un_h2_between(T1, T). un_h2_between(T1, T) ←

not h2(T2), T1 ≤ T2, T2 ≤ T.

0 T1 T2 T Case (4): => p(T) ← h’(T)

on h1 changes at T, if both h1 and h2 are true,

do assert h’ at T

on h2 changes at T, if both h1 and h2 are true,

do assert h’ at T

on h2 changes at T, if h2 is false, do retract all h’ at T

The Missing Case: T1 – c ≤ T2

18

• Thus far, we can cover all the temporal constraints of the formT1 {=, <, ≤, >, ≥} T2 ± c (c ≥ 0)

except.. T1 ≤ T2 + c• Consider the policy

p(T) ← h1(T1), T1 ≤ T, h2(T2), T2 ≤ T, T1 – c ≤ T2.– Problem: none of h1 and h2 is historical to the other

• Solution – break it into two cases (Case 1 and Case 2):p(T) ← h1(T1), T1 ≤ T, h2(T2), T2 ≤ T, T1 ≤ T2. p(T) ← h1(T1), T1 ≤ T, h2(T2), T2 ≤ T, T1 – c ≤ T2 ≤ T1.

Now we have covered all the cases!

Discussions

19

• Syntactic analysis and transformation/monitoring rules generation are simple and automatic

• Evaluation cost is similar to that for Datalog query• Given n history-based policies, each with which has m identified

basic historical condition, the maximum space needed for encoding the bounded history is

#(Store) = [#(Sub) #(Tar) #(Act) + #(Fluent)] m n

– e.g. appr. 100MB for: 100 policies with totally 400 historical conditions, for a domain with 1 million properties, and with 10000 objects that can perform 100 different actions.

– In practice, the store is much smaller

• The overall system is efficient in the cases where– Many action requests– Less frequent system changes

Conclusion

20

• We have presented a policy transformation framework to allow history-based policies to be enforced:– Historical conditions are identified through syntactic analysis– System monitoring rules are generated to maintain a bounded history

pro-actively– Policies are transformed to non-history based and thus the evaluation

can be efficient• Our framework can deal with conditions expressed with explicit

time or in Past Linear Temporal Logic• Proof (sketch) of correctness and complexity analysis are given