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%UAV1s power level …40%39%38% 39%40%41%UAV2s power level … …null m1 Radio1s mission …m1 m2 Radio2s mission …13mins14mins15mins16mins17mins18mins19mins20minstime 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 time Existing policy management systems cant handle history- based policies Policies History request permit action deny action

Our Contributions 6 An approach for fast evaluation of history-based policies by 1.transforming policies to non-history based form, and 2.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.

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 condition 1. 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 T1T1 T2T2 T 2 +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)

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 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

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 T T- ε 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 T T- ε NB: when δ = ε = c : Condition h holds exactly at T-c p(T) h(T1), T – c (c 0) Non-history based policy p(T) h(T) Monitoring Rules Case (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 rules Negative 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 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

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 h2 h3 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 4 th base case and new transformation is required. Thus, we can handle historical conditions expressing always and never temporal operators. Cant 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 form T1 {=,, } 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 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