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 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 Background – Policy Objectives  Allow access only to proper parties under proper conditions  Deny access to those that should not have it

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 Background – Economics of Scale

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 Background – User Requirements  Writing  Reviewing  Testing  Approving  Deploying  Combining  Analyzing  Modifying  Withdrawing  Retrieving  Enforcing

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

9

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

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

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 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 Background – Covenant  Policies contain obligations that applications must:  promise to understand  act on when Permit is returned

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  Header  [p01]  [p01]  [p02] <Policy xmlns="urn:oasis:names:tc:xacml:1.0:policy"  [p03] xmlns:xsi=" instance"  [p04] xsi:schemaLocation="urn:oasis:names:tc:xacml:1.0:p olicy  [p05] xacml-schema-policy-01.xsd"  [p06] PolicyId="identifier:example:SimplePolicy1"  [p07] RuleCombiningAlgId="identifier:rule- combining-algorithm:deny-overrides">

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

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  Rule Header  [p22] <Rule  [p23] RuleId= "urn:oasis:names:tc:xacml:1.0:example:SimpleRule1"  [p24] Effect="Permit">

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  Rule Target  [p29]  [p29]  [p30]  [p30]  [p31]  [p31]  [p32] <SubjectMatch MatchId="  urn:oasis:names:tc:xacml:1.0:function:rfc822Name-match">  [p33] <SubjectAttributeDesignator  [p34]  AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"  [p35] DataType="urn:oasis:names:tc:xacml:1.0:datatype:  rfc822Name"/>  [p36] <AttributeValue  [p37] DataType="urn:oasis:names:tc:xacml:1.0:datatype:  rfc822Name">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  Rule End  [p49]  [p49]  [p50]  [p50]

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

25  Header  [c01]  [c01]  [c02] <Request xmlns="urn:oasis:names:tc:xacml:1.0:context"  [c03] xmlns:xsi="  [c04] xsi:schemaLocation="urn:oasis:names:tc:xacml:1.0:context  [c05] 01.xsd">  Subject  [c06]  [c06]  [c07] <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subjectid"   [c08] DataType="urn:oasis:names:tc:xacml:1.0:data- type:rfc822Name">  [c09]  [c09]  [c10]  [c10]  [c11]  [c11]

26  Resource  [c12]  [c12]  [c13] <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:ufspath"   [c14] DataType="  [c15] /medico/record/patient/BartSimpson  [c15] /medico/record/patient/BartSimpson  [c16]  [c16]  [c17]  [c17]  Action  [c18]  [c18]  [c19] <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"  [c20] DataType="  [c21] read  [c21] read  [c22]  [c22]  [c23]  [c23]  Query End  [c24]  [c24]

27 Background – Trivial Response Example  Response: Not Applicable  Header  [r01]  [r01]  [r02] <Response xmlns="urn:oasis:names:tc:xacml:1.0:context"  [r03] xsi:schemaLocation="urn:oasis:names:tc:xacml:1.0:context  [r04]  01.xsd">  Result  [r05]  [r05]  [r06] NotApplicable  [r06] NotApplicable  [r07]  [r07]  End  [r08]  [r08]

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

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

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

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 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 Contribution  Verification system checks policies against properties  Change impact analyzer

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

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 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 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 Representation of Policies  Policies are represented as MTBDDs (multi- terminal binary decision diagrams)

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 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 Operations on MTBDDs

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

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

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

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 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 Deficiencies  Visualization (obviously)  Cannot reason about data values  Does not process complete XACML

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