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
 Background – Data and Privilege Management

 Checkpoint Financial exposed 163,000

records in 2005. Penalty: $15M
 Ameriprise exposed 226,000 records
this week
 California SB1386 effective July 2003
requires disclosure

2
 Background – Policy Objectives

 Allow access only to proper parties

under proper conditions
 Deny access to those that should not
have it

3
 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

4
Background – Economics of Scale

Complexity
Budget $

Time

5
 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
6
 Background – User Requirements

 Writing  Analyzing
 Reviewing  Modifying
 Testing  Withdrawing
 Approving  Retrieving
 Deploying  Enforcing
 Combining

7
 Background – Basic Construction

 Rule:
{subject}* {action}* {resource}* {conditional}*

 Rules are combined to make policies

 Policies are combined to make policy
sets

8
9
 Background – Basic Construction

 Policy:
 Target
 Rule combining algorithm
 {rules}*
 {obligations}*

10
 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}*
11
12
 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
13
 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

14
 Background – Covenant

 Policies contain obligations that

applications must:
 promise to understand
 act on when Permit is returned

15
 Background – Trivial Policy Example

 Allow any subject to perform any

action on any resource so long as the
domain name is medico.com

16
 Header
 [p01] <?xml version=1.0" encoding="UTF-8"?>
 [p02] <Policy
xmlns="urn:oasis:names:tc:xacml:1.0:policy"
 [p03]
xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance"
 [p04]
xsi:schemaLocation="urn:oasis:names:tc:xacml:1.0:p
olicy
 [p05] http://www.oasis-open.org/tc/xacml/1.0/cs-
xacml-schema-policy-01.xsd"
 [p06] PolicyId="identifier:example:SimplePolicy1"
 [p07] RuleCombiningAlgId="identifier:rule-
combining-algorithm:deny-overrides">

17
 Description
 [p08] <Description>
 [p09] Medi Corp access control policy
 [p10] </Description>

18
 Target
 [p11] <Target>
 [p12] <Subjects>
 [p13] <AnySubject/>
 [p14] </Subjects>
 [p15] <Resources>
 [p16] <AnyResource/>
 [p17] </Resources>
 [p18] <Actions>
 [p19] <AnyAction/>
 [p20] </Actions>
 [p21] </Target>

19
 Rule Header
 [p22] <Rule
 [p23] RuleId=
"urn:oasis:names:tc:xacml:1.0:example:SimpleRule1"
 [p24] Effect="Permit">

20
 Rule Description
 [p25] <Description>
 [p26] Any subject with an e-mail name in the
medico.com domain
 [p27] can perform any action on any resource.
 [p28] </Description>

21
 Rule Target
 [p29] <Target>
 [p30] <Subjects>
 [p31] <Subject>
 [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] </AttributeValue>
 [p39] </SubjectMatch>
 [p40] </Subject>
 [p41] </Subjects>
 [p42] <Resources>
 [p43] <AnyResource/>
 [p44] </Resources>
 [p45] <Actions>
 [p46] <AnyAction/>
 [p47] </Actions>
 [p48] </Target>

22
 Rule End
 [p49] </Rule>
 [p50] </xacml:Policy>

23
 Background – Trivial Query Example

 [email protected] wants to read

/medico/record/patient/BartSimpson

24
 Header
 [c01] <?xml version="1.0" encoding="UTF-8"?>
 [c02] <Request xmlns="urn:oasis:names:tc:xacml:1.0:context"
 [c03] xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 [c04] xsi:schemaLocation="urn:oasis:names:tc:xacml:1.0:context
 [c05] http://www.oasis-open.org/tc/xacml/1.0/cs-xacml-schema-context-
01.xsd">

 Subject
 [c06] <Subject>
 [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] <AttributeValue>[email protected]</AttributeValue>
 [c10] </Attribute>
 [c11] </Subject>

25
 Resource
 [c12] <Resource>
 [c13] <Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:ufspath"

 [c14] DataType="http://www.w3.org/2001/XMLSchema#anyURI">
 [c15]
<AttributeValue>/medico/record/patient/BartSimpson</AttributeValue>
 [c16] </Attribute>
 [c17] </Resource>

 Action
 [c18] <Action>
 [c19] <Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
 [c20] DataType="http://www.w3.org/2001/XMLSchema#string">
 [c21] <AttributeValue>read</AttributeValue>
 [c22] </Attribute>
 [c23] </Action>

 Query End
 [c24] </Request>

26
 Background – Trivial Response Example

 Response: Not Applicable

 Header
 [r01] <?xml version="1.0" encoding="UTF-8"?>
 [r02] <Response xmlns="urn:oasis:names:tc:xacml:1.0:context"
 [r03] xsi:schemaLocation="urn:oasis:names:tc:xacml:1.0:context
 [r04] http://www.oasis-open.org/tc/xacml/1.0/cs-xacml-schema-context-
 01.xsd">

 Result
 [r05] <Result>
 [r06] <Decision>NotApplicable</Decision>
 [r07] </Result>

 End
 [r08] </Response>
27
 Background – Threat Model

 Operating environment responsible for

 Authentication
 Communications security
for
 Policies
 Query engine execution
 Client

28
 Margrave

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

29
 Objectives

 Detect ill-formed or inconsistent

policies
 Identify differences between policy
generations

30
 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

31
 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

32
 Contribution

 Verification system checks policies

against properties
 Change impact analyzer

33
 Issues

 Visualization of XACML policies

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

34
 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.
35
 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.
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 Pr3: “No member of
Faculty can View ExternalGrades.”
 The verifier will reject Pol1/Pr3 because
Pr3 conflicts with Pol1.

37
 Representation of Policies

 Policies are represented as MTBDDs (multi-

terminal binary decision diagrams)

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

39
 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

40
Operations on MTBDDs

41
 Implementation

 Built on PLT Scheme

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

42
 Implementation

 Produces error reports (line 11 masked

with line 9 shows properties that caused a
violation … i.e., a counter-example)

43
 Implementation

 Produces change analyses (N->P means

non-applicable->Permit)

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

46
 Deficiencies

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

47
 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

48
 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),
http://www.oasis-open.org/committees/xacml/repository/cs-xacml-specific
, December 2002

49