Download presentation

Presentation is loading. Please wait.

Published byNicholas Lyon Modified over 4 years ago

1
Annual Conference of ITA ACITA 2009 Efficient Evaluation of History-based Policies Jiefei Ma 1, Jorge Lobo 2, Alessandra Russo 1, Emil Lupu 1, Seraphin Calo 2, Morris Sloman 1 1 Imperial College London, UK 2 IBM T. J. Watson Research Center, US Abstract: this paper illustrates one general class of policy refinement problems, showing how policies with references to historical information can be transformed into history-free policies in an automated fashion, and the resulting policies can be evaluated efficiently. In [1], the FOL language allows authorisation policies to be specified as: [permitted/denied](Subject, Target, Action, T) H 1, …, H m, C 1, …, C n. where each Hi is a condition with a time argument, e.g. holds(F, T i ), and each C i is a constraint over two time variables, e.g. T 1 T 2 + c. Let T be the time argument of H, if C 1, …, C n |= T T, then H is a historical condition. Basic Patterns: Case (1): Condition h holds before T – ε p(T) h(T1), T1 T– ε(ε 0) Case (3): Condition h holds in [T – δ, T – ε] p(T) h(T1), T –δ T1 T– ε (δ ε 0) Case (2): Condition h holds within T – δ p(T) h(T1), T – δ T1 T (δ 0) 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. Combined 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+δ Case (4): 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 0 T1 T-ε T 0 T- δ T1 T 0 T- δ T1 T T- ε 0 T1 T2 T Non-history based policy p(T) h(T) transforms generates * h is the auxiliary fact for h * for negative condition, the negated value of h is used in the monitoring rules conditions Special Case: co-related historical condition h1 and h2 p(T) h1(T1), T1 T, h2(T2), T2 T, T1 – c T2. Rewritten to 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. Multiple Historical 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. Example: A 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. General transformation steps: 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. (Generality of the Approach) We can handle all historical conditions expressed: (a) in the language [1] where each time constraint is of the form T٭T±c where ٭ is {=,, }; (b) in Past Linear Temporal Logic. Formal Results Outline (See full paper for details) (Correctness) The evaluation of the transformed non history-based policies always gives the same result as that of the original history-based policies. (Complexity) The maintained auxiliary store provides a history encoding polynomially-bounded in space, and the time necessary for the evaluation a (flatten) transformed policy or monitoring rule is polynomial. Policies are ubiquitous in military coalition operations. Several efforts in ITA are being carried out to make policies operational in MANETs. For example, policies for the Sensor Fabric and the Gaian Database, as well as the IBM Coalition Security Manager Portal, to ensure security across different nodes/parties. The Problem: many times high level security policies describe decisions (i.e. access control decisions or obligations) based on historical conditions, but most of the existing policy systems do not natively support temporal conditions. In addition, the evaluation of such policies must be fast and requires a system history, but storing the full system history would be impractical. For example, in the combat environment, policy managed devices used by the soldiers such as PDA, mobiles or embedded computers often have limited computational power/space. The Idea: each historical condition was once a current condition and a current condition may become a future historical condition. Example: A device is permitted to charge its battery if the power level was below 90% anytime in the past 5 minutes. permitted(device, battery, charge, T) holds(power_level(L), T1), holds(less_than(L, 90%), T1), T- 5min T1 T. New Policy: permitted(device, battery, charge, T) holds(low_power, T). Monitoring Rules: on power_level(L) changes at T, if less_than(L, 90%) becomes true, do insert low_power at T. on power_level(L) changes at T, if less_than(L, 90%) becomes false, do retract low_power at T+5mins. T1T1 T2T2 T 2 +5mins power_level(L), L 90% power_level(L), L < 90% power_level(L), L 90% insert low_power retract low_power ¬ permitted(..., charge) permitted(..., charge) Sample Time-line: References: [1] Robert Craven, Jorge Lobo, Jiefei Ma, Alessandra Russo, Emil C. Lupu, Arosha K. Bandara: Expressive policy analysis with enhanced system dynamicity. ASIACCS 2009: 239-250 The solution: (1) we categorise the basic patterns that can be combined to form arbitrary historical conditions; (2) we dynamically compute, from a given policy set, a finite subset of the system history required and sufficient to evaluate the policies according to the patterns; (3) we maintain this historical information by monitoring rules and refine the policies into a non history-based form.

Similar presentations

OK

To Tune or not to Tune? A Lightweight Physical Design Alerter Nico Bruno, Surajit Chaudhuri DMX Group, Microsoft Research VLDB’06.

To Tune or not to Tune? A Lightweight Physical Design Alerter Nico Bruno, Surajit Chaudhuri DMX Group, Microsoft Research VLDB’06.

© 2018 SlidePlayer.com Inc.

All rights reserved.

To make this website work, we log user data and share it with processors. To use this website, you must agree to our Privacy Policy, including cookie policy.

Ads by Google