Validating Access Control Policies with Alloy Waël Hassan, Luigi Logrippo, Mahdi Mankaï Université du Québec en Outaouais University of Ottawa

Policies Policies are a mechanism of growing importance for the control of systems Among which, telecom systems Internet telephony, web applications can be customized by the use of policies E.g. I want my calls to be forwarded to my email Out of working hours If they come from domain X

Policies: further examples Firewalls express policies regarding which packets should be allowed through Access Control Languages such as XACML express high-level policies concerning who can be given access to what information and for what purpose

Inconsistency of policies If we allow users to write their own policies, we must worry about potential inconsistencies Calls from domain X should be blocked Calls from Carl should come directly to me In IN telephony, this was called the Feature Interaction problem

The practical problem Access control policies are often complex, difficult to understand, and developed incrementally They will be administered by lawyers, clerks, and other people who won’t be necessarily computer-literate They must be made manageable for these people They may allow security breaches if they are inconsistent Semantic errors must be identified and reported

Flagging inconsistencies Inconsistencies may be intentional E.g. rule and exception Or may be unintended errors E.g. when user adds policies to an existing file, over a period of time They should be flagged and brought to the attention of user

Project 1: Inconsistencies in XACML OASIS standard Access Control Language

What does it look like Etc, etc... <Policy PolicyId="SamplePolicy" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:permit-overrides"> <!-- This Policy only applies to requests on the SampleServer --> <Target> <Subjects> <AnySubject/> </Subjects> <Resources> <ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">SampleServer</AttributeValue> <ResourceAttributeDesignator DataType="http://www.w3.org/2001/XMLSchema#string" AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"/> </ResourceMatch> </Resources> <Actions> <AnyAction/> </Actions> </Target> Etc, etc...

Goals Validation of XACML policies Checking if policies are consistent Facts In a policy we can have multiple rules that generate different decisions (permit & deny) Combining Algorithms help to get a unique response but don’t say if there are several possibilities

Access Control Policy Policy: X(administrator) wants to read Y's medical record X(23 years old) wants to modify his medical record X(administrator and patient) wants to read his medical record X(23 years old) wants to read his medical record Policy: Rule1: A person may read any medical record for which he or she is the designated patient Rule2: A person may read any medical record for which he or she is the designated parent or guardian, and for which the patient is under 16 years of age Rule3: An Administrator shall not be permitted to read or write medical elements of a patient record Permit or Deny? Deny Not Applicable Permit Slide 1 (of 5)

Combining Algorithms How to obtain a single response with XACML Deny-overrides Permit-overrides First applicable Only-one-applicable Deny Permit Indeterminate Deny Permit Slide 2 (of 5)

Interaction in XACML Deny Permit Deny-overrides PolicySet1 PolicySet2 Permit-overrides Permit Policy1.1 Policy2.1 Policy2.2 Rule1.1.1 Rule1.1.2 Rule2.1.1 Rule2.1.2 Rule2.2.1 Rule2.2.2 Permit Deny Permit Deny Slide 3 (of 5)

Issues Is the response is the intented one? Does access control policies meet all specifications? XML notation is not readable by simple users Slide 4 (of 5)

Use of Formal Language Alloy Check & Validation Policy.xml Alloy Spec Object Model of context Rules extraction Simple predicates and assertions Transformation Slide 5 (of 5)

Alloy Results When the subject is both Administrator and patient => Both Permit and Deny responses

Results as a tree When the subject is both Administrator and patient => Both Permit and Deny responses

Process-based access control and inconsistency detection Project 2 Process-based access control and inconsistency detection

Process-Based Access Control In Role Based Access Control, access control policies are attached to enterprise roles In Process Based Access Control, access control policies are attached to enterprise processes

RBAC vs PBAC RBAC: when we allow Alex to open file F as a part of her organizational role structure, Alex will have access to file F at all times, and can use it regardless of her job function. PBAC: If Alex was assigned file F as a part of process loan application, then the permission is only available during the sequence of operations leading to a loan application

Process-based inconsistency In a company, the LoanProcessing process includes the VerifyCredit process. However information collected for the purpose of credit verification should not be available to employees doing loan processing. Suppose now that an employee assigned to sub-process Verify-Credit goes on vacation and delegates his rights to his manager, who is member of the process Loan-Processing. The manager receives access to information that should be denied to her.

Approach Creation of an enterprise UML metamodel Representation in Alloy Using Alloy to check inconsistencies in the model Addition of policies to metamodel Using Alloy to identify inconsistency in policies (such as the one just exemplified)

UML Enterprise MetaModel Process person Device Policy Attached to Step ( Activity) is a set of Enterprise Role Has 1 Assigned to Owns Assumes * 1..

Expressing contradiction betw. Permission and Denial abstract sig policy { attachedTo : lone process, // a process is attached to policies permitted: role -> process, // permits role access to a process denied : role -> process //denies a role to a process }{ no permitted & denied }

Expressing Separation of Concerns Processes which receive a permission from an AccountDeleteAP should not be permitted to AccountCreateAP assert separateConcerns { no (process.~(accountDeleteAP.permitted) & process.~(accountCreateAP.permitted)) }

Results from Alloy

Conclusions Access control rules can be translated into logic notation A model analyzer can be used to detect policy inconsistencies Process is a natural concept for expressing some types of access control policies

Future Work Is Alloy the best choice? May ‘break down’ in larger examples Or may become very slow Try other model analyzers or theorem provers Some verification tasks may be done better in Prolog Instead of translating XML-based policies into logical languages for modeling, invent a logic-based language to express policies directly, then translate it into some XML-based language Develop further the PBAC model

Questions?