Efficient Evaluation of History-based Policies

1. Efficient Evaluation of History-based Policies Imperial College London, UK IBM Watson Research, US

2. History-based Policies • 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 past5 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.”

3. Policies in Abstract Form 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 past5 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. 3

4. Evaluation of Historical Conditions • 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 System states System events 4

5. The Naïve Approach Is Not Acceptable 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! permit action Policies request Problems of the naïve approach: • a full history is often impractical to store • temporal reasoning requires extra time Existing policy management systems can’t handle history-based policies deny action History 5

6. Our Contributions An approach for fast evaluation of history-based policies by • transforming policies to non-history based form, and • 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) becomes Evaluation of (Non-history based Policies + Bounded History) Proof sketch for the correctness has been given. 6

7. The Ideas • 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 7

8. An Example “A device is permitted to charge its battery if the power level was below 90% anytime in the past5 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 condition • Identify the condition and the temporal constraint • Replace them with a current condition (i.e. “macro” condition): • permitted(X, battery(X), charge, T) ← holds(low_power(X), T). • Generate monitoring rules according to the replaced components • If power_level(x,l) changes s.t. l < 90%, thenrecords low_power(x) immediately • If power_level(x,l) changes s.t. l ≥ 90%, thenremoves low_power(x) in 5 mins • Evaluation of the macro condition holds(low_power(X), T) is just a database query for low_power(X) at T. 8

9. An Example (cont.) insert low_power(x) retract low_power(x) permitted(..., charge) ¬permitted(..., charge) ¬ permitted(..., charge) power_level(x,l), l < 90% power_level(x,l), l ≥ 90% power_level(x,l), l ≥ 90% T2+5mins T1 T2 A time line 9

10. Notations and Definitions • 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 policy p(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 10

11. Basic Cases: Single Condition Case (1): Conditionhholds beforeT – εp(T) ← h(T1), T1 ≤ T– ε(ε ≥ 0) Case (2): Conditionhholds withinT – δp(T) ← h(T1), T – δ ≤T1 ≤ T (δ ≥ 0) T T1 0 T-ε T 0 T-δ T1 T T-ε 0 T-δ T1 Case (3): Conditionhholds between T – δandT – εp(T) ← h(T1), T –δ ≤ T1 ≤ T– ε (δ ≥ ε ≥ 0) NB: when δ = ε = c: Conditionhholds exactly at T-cp(T) ← h(T1), T1 = T – c (c ≥ 0) 11

12. Basic Cases: Single Condition T T T1 0 T-ε 0 T-δ T1 Case (1): Conditionhholds beforeT – εp(T) ← h(T1), T1 ≤ T– ε(ε ≥ 0) Case (2): Conditionhholds withinT – δp(T) ← h(T1), T – δ ≤T1 ≤ T (δ ≥ 0) T T-ε 0 T-δ T1 Case (3): Conditionhholds between T – δandT – εp(T) ← h(T1), T –δ ≤ T1 ≤ T– ε (δ ≥ ε ≥ 0) NB: when δ = ε = c: Conditionhholds exactly at T-cp(T) ← h(T1), T – c (c ≥ 0) Monitoring Rules Non-history based policy p(T) ← h’(T) • Monitoring rules can be implemented as Event-Condition-Action rules • Negative historical conditions can be handled similarly • e.g. negate the condition in the monitoring rules 12

13. Simple Cases: Two Conditions 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. • h1andh2can be transformed independently • Serial Composition:p(T) ← h1(T1), h2(T2), T1 « T2, T2 « T. • break it into two p(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 13

14. Complex Cases: Multiple Conditions 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! 14

15. An Automatic Transformation h2 h3 p h4 h1 p(T) ← h1(T1), h2(T2), h3(T3), h4(T4), T1 « T, T2 « T, T3 « T2, T4 « T2, T4 « T1, T4 « T3. Steps: 1. Construct and normalise the Directed Connected Graph (DCG) representing the relationships between historical conditions; 2. Topologically sort the DCG: 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. 15

16. Special Cases: Durative Conditions • 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. 16

17. Special Cases: Durative Conditions T1 0 T2 T • 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): Conditionh2since conditionh1p(T) ← h(T1), T1 ≤ T, not un_h2_between(T1, T). un_h2_between(T1, T) ← not h2(T2), T1 ≤ T2, T2 ≤ T. 17

18. The Missing Case: T1 – c ≤ T2 • Thus far, we can cover all the temporal constraints of the formT1 {=, <, ≤, >, ≥} T2 ± c (c ≥ 0)except.. T1 ≤ T2 + c • Consider the policyp(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! 18

19. Discussions • 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 19

20. Conclusion • 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 20