Presentation is loading. Please wait.

Presentation is loading. Please wait.

Verification and Change-Impact Analysis of Access-Control Policies Kathi Fisler, Shriram Krishnamurthi, Leo Meyerovich, and Michael Tschantz ICSE’05 Presented.

Similar presentations


Presentation on theme: "Verification and Change-Impact Analysis of Access-Control Policies Kathi Fisler, Shriram Krishnamurthi, Leo Meyerovich, and Michael Tschantz ICSE’05 Presented."— Presentation transcript:

1 Verification and Change-Impact Analysis of Access-Control Policies Kathi Fisler, Shriram Krishnamurthi, Leo Meyerovich, and Michael Tschantz ICSE’05 Presented by Barry Demchak CSE 294 Winter 2006

2 2 Background – Data and Privilege Management  Checkpoint Financial exposed 163,000 records in Penalty: $15M  Ameriprise exposed 226,000 records this week  California SB1386 effective July 2003 requires disclosure

3 3 Background – Policy Objectives  Allow access only to proper parties under proper conditions  Deny access to those that should not have it

4 4 Background – Economics of Scale  One-size-fits-all applications (security-neutral)  Tracking increasing subjects/ resources/actions needs automation  Tracking interactions seems hopeless  Tracking exceptions seems hopeless

5 5 Background – Economics of Scale

6 6 Background – XACML Proposition  Common language to express policies  Hierarchy of definition to match hierarchy of organization  Disconnect policies from mainstream application design (separation of concerns)  Model to specify policies, query access, and results  Vendor-neutral mechanisms

7 7 Background – User Requirements  Writing  Reviewing  Testing  Approving  Deploying  Combining  Analyzing  Modifying  Withdrawing  Retrieving  Enforcing

8 8 Background – Basic Construction  Rule: {subject}* {action}* {resource}* {conditional}*  Rules are combined to make policies  Policies are combined to make policy sets

9 9

10 10 Background – Basic Construction  Policy:  Target  Rule combining algorithm  {rules}*  {obligations}*

11 11 Background – Basic Flow 1. Application creates XACML-based query 2. Application chooses {policy}* 3. XACML engine compares query to {policy}* and produces reply:  Permit  Deny  Inapplicable 4. Application fulfills {obligations}*

12 12

13 13 Background – Engine Capabilities  Combining rules (first applicable, only-one applicable, etc)  Multiple subjects  Subject and resource attributes (e.g., LDAP-maintained)  Multi-valued attributes  Operator library  XQuery conditionals

14 14 Background – Policy Distribution  Policies are stored in databases or anywhere else  Policies apply to particular target (subjects, actions, resources)  Engine can fetch multiple policies to evaluate

15 15 Background – Covenant  Policies contain obligations that applications must:  promise to understand  act on when Permit is returned

16 16 Background – Trivial Policy Example  Allow any subject to perform any action on any resource so long as the domain name is medico.com

17 17  Header  [p01]  [p01]  [p02]

18 18  Description  [p08]  [p08]  [p09] Medi Corp access control policy  [p10]  [p10]

19 19  Target  [p11]  [p11]  [p12]  [p12]  [p13]  [p13]  [p14]  [p14]  [p15]  [p15]  [p16]  [p16]  [p17]  [p17]  [p18]  [p18]  [p19]  [p19]  [p20]  [p20]  [p21]  [p21]

20 20  Rule Header  [p22]

21 21  Rule Description  [p25]  [p25]  [p26] Any subject with an name in the medico.com domain  [p27] can perform any action on any resource.  [p28]  [p28]

22 22  Rule Target  [p29]  [p29]  [p30]  [p30]  [p31]  [p31]  [p32]  [p33]  [p36] medico.com  [p38]  [p38]  [p39]  [p39]  [p40]  [p40]  [p41]  [p41]  [p42]  [p42]  [p43]  [p43]  [p44]  [p44]  [p45]  [p45]  [p46]  [p46]  [p47]  [p47]  [p48]  [p48]

23 23  Rule End  [p49]  [p49]  [p50]  [p50]

24 24 Background – Trivial Query Example  wants to read /medico/record/patient/BartSimpson

25 25  Header  [c01]  [c01]  [c02]  Subject  [c06]  [c06]  [c07]  [c09]  [c09]  [c10]  [c10]  [c11]  [c11]

26 26  Resource  [c12]  [c12]  [c13]  [c15] /medico/record/patient/BartSimpson  [c15] /medico/record/patient/BartSimpson  [c16]  [c16]  [c17]  [c17]  Action  [c18]  [c18]  [c19]  [c21] read  [c21] read  [c22]  [c22]  [c23]  [c23]  Query End  [c24]  [c24]

27 27 Background – Trivial Response Example  Response: Not Applicable  Header  [r01]  [r01]  [r02]  Result  [r05]  [r05]  [r06] NotApplicable  [r06] NotApplicable  [r07]  [r07]  End  [r08]  [r08]

28 28 Background – Threat Model  Operating environment responsible for  Authentication  Communications security for  Policies  Query engine execution  Client

29 29 Margrave  (markgraf in German)  A lord or keeper of borders: a medieval access control manager

30 30 Objectives  Detect ill-formed or inconsistent policies  Identify differences between policy generations

31 31 Observations (relative to straight coding)  Policy implementations often scattered across modules  Sharing/changing policies is hard and sometimes subtle  Offloading access control logic reduces complexity for automated program checkers

32 32 Observations (relative to straight coding)  Automated reasoning about policies is hard and is not amenable to automated program checking  Testing isn’t exhaustive … testing cost model is out of whack relative to security breach cost model

33 33 Contribution  Verification system checks policies against properties  Change impact analyzer

34 34 Issues  Visualization of XACML policies  Visualization of properties  Visualization of policy diffs  Expanding Margrave to cover more of XACML

35 35 Basic Verification - Properties  Margrave adds properties: a logical predicate involving subjects, actions, and resources  Consider a policy Pol1: “Requests for Students to Receive ExternalGrades, and for Faculty to Assign and View both InternalGrades and ExternalGrades, will succeed.”  Consider a property Pr1: “There do not exist members of Student who can Assign ExternalGrades.”  The verifier will accept Pol1/Pr1 because Pr1 doesn’t address any part of Pol1.

36 36 Basic Verification - Properties  Consider a policy Pol1: “Requests for Students to Receive ExternalGrades, and for Faculty to Assign and View both InternalGrades and ExternalGrades, will succeed.”  Consider a property Pr2: “All members of Faculty can Assign both InternalGrades and ExternalGrades”.  The verifier will accept Pol1/Pr2 because Pr2 affirms Pol1.

37 37 Basic Verification - Properties  Consider a policy Pol1: “Requests for Students to Receive ExternalGrades, and for Faculty to Assign and View both InternalGrades and ExternalGrades, will succeed.”  Consider a property Pr3: “No member of Faculty can View ExternalGrades.”  The verifier will reject Pol1/Pr3 because Pr3 conflicts with Pol1.

38 38 Representation of Policies  Policies are represented as MTBDDs (multi- terminal binary decision diagrams)

39 39 Representation of Policies  MTBDDs are constructed according to a fixed ordering of the variables (easy comparison)  MTBDDs maximally share subtrees  MTBDDs collapse irrelevant variables (where all transitions are to the same node)

40 40 Operations on MTBDDs  MTBDDs created for individual rules and then merged to create policies according to the policy’s rule combining algorithms  Combining MTBDDs starts at the top of both MTBDDs and executes a brief recursive algorithm  Environmental constraints (e.g., “no Faculty is also a Student”) get combined in a similar way

41 41 Operations on MTBDDs

42 42 Implementation  Built on PLT Scheme  Properties are hand-assembled in Scheme  A pseudo-code implementation of checking “A student can assign ExternalGrades”:

43 43 Implementation  Produces error reports (line 11 masked with line 9 shows properties that caused a violation … i.e., a counter-example)

44 44 Implementation  Produces change analyses (N->P means non-applicable->Permit)

45 45 Performance  Parsing a policy having 50 variables and 1268 nodes took 2050ms on desktop computer  Checking 12 properties was too quick to measure  Memory consumption was 316KB  On another test, a compare took 2ms and produced a tree containing 1133 nodes taking 16KB

46 46 Alternatives  SELinux (Security-enhanced Linux) produces BDDs, but they are oriented toward determining information flow in a traditional model-checker activity  A complete solution would use both Margrave and information flow analysis

47 47 Deficiencies  Visualization (obviously)  Cannot reason about data values  Does not process complete XACML

48 48 Conclusions  Margrave is a work in progress  XACML and Margrave are about managing complexity through separation of concerns  Margrave adds the concept of properties to verify policies  Margrave compares policies, which enables incremental validation

49 49 References  Verification and Change-Impact Analysis of Access-Control Policies by Kathi Fisler, Shriram Krishnamurthi, Leo Meyerovich, and Michael Tschantz, ICSE’05  OASIS eXtensible Access Control Markup Language (XACML), open.org/committees/xacml/repository/cs-xacml-specification pdf, December open.org/committees/xacml/repository/cs-xacml-specification pdf open.org/committees/xacml/repository/cs-xacml-specification pdf


Download ppt "Verification and Change-Impact Analysis of Access-Control Policies Kathi Fisler, Shriram Krishnamurthi, Leo Meyerovich, and Michael Tschantz ICSE’05 Presented."

Similar presentations


Ads by Google