1 / 1

Annual Conference of ITA ACITA 2009

insert low_power. retract low_power. permitted(..., charge). ¬ permitted(..., charge). ¬ permitted(..., charge). power_level(L), L < 90%. power_level(L), L ≥ 90%. power_level(L), L ≥ 90%. T 2 +5mins. T 1. T 2. T. T1. 0. T- ε. h2. h3. p. h4. h1. T. 0. T- δ. T1. T.

Download Presentation

Annual Conference of ITA ACITA 2009

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. insert low_power retract low_power permitted(..., charge) ¬ permitted(..., charge) ¬ permitted(..., charge) power_level(L), L < 90% power_level(L), L ≥ 90% power_level(L), L ≥ 90% T2+5mins T1 T2 T T1 0 T-ε h2 h3 p h4 h1 T 0 T-δ T1 T T-ε 0 T-δ T1 T1 0 T2 T Annual Conference of ITA ACITA 2009 Efficient Evaluation of History-based Policies Jiefei Ma1, Jorge Lobo2, Alessandra Russo1, Emil Lupu1, Seraphin Calo2, Morris Sloman11Imperial College London, UK 2IBM 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. 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. In [1], the FOL language allows authorisation policies to be specified as:[permitted/denied](Subject, Target, Action, T) ← H1, …, Hm, C1, …, Cn.where each Hi is a condition with a time argument, e.g. holds(F, Ti), and each Ci is a constraint over two time variables, e.g. T1 ≤ T2 + c. Let T’ be the time argument of H, if C1, …, Cn |= T’ ≤ T, then H is a historical condition. 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. 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. The Idea: each historical condition was once a “current condition” and a current condition may become a future historical condition. Monitoring Rules: onpower_level(L) changes at T, ifless_than(L, 90%) becomes true,doinsertlow_power at T.onpower_level(L) changes at T, ifless_than(L, 90%) becomes false,doretractlow_power at T+5mins. New Policy: permitted(device, battery, charge, T) ← holds(low_power, T). 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. Sample Time-line: 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: transforms Basic Patterns: Non-history based policy generates Case (1): Condition h holds before T – εp(T) ← h(T1), T1 ≤ T– ε(ε≥ 0) 1. Construct and normalise the Directed Connected Graph (DCG) representing the relationships between historical conditions; 2. Topologically sort the DCG: Monitoring Rules Case (2): Condition h holds within T – δp(T) ← h(T1), T – δ ≤T1 ≤ T(δ≥ 0) Combined 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. Case (3): Condition h holds in [T – δ, T – ε]p(T) ← h(T1), T –δ ≤ T1 ≤ T– ε (δ≥ ε ≥ 0) Case (4): Condition h2 since condition h1p(T) ← h(T1), T1 ≤ T, not un_h2_between(T1, T). un_h2_between(T1, T) ← not h2(T2), T1 ≤ T2, T2 ≤ T. Formal Results Outline (See full paper for details) (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. Special Case: co-related historical condition h1 and h2p(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. (Correctness) The evaluation of the transformed non history-based policies always gives the same result as that of the original history-based policies. * h’ is the auxiliary fact for h* for negative condition, the negated value of h is used in the monitoring rules’ conditions (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. 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

More Related