A Decision Tree Learning Approach for Mining Relationship-Based Access Control Policies

09/24/2019 ∙ by Thang Bui, et al. ∙ 0

Relationship-based access control (ReBAC) provides a high level of expressiveness and flexibility that promotes security and information sharing, by allowing policies to be expressed in terms of chains of relationships between entities. ReBAC policy mining algorithms have the potential to significantly reduce the cost of migration from legacy access control systems to ReBAC, by partially automating the development of a ReBAC policy. This paper presents a new algorithm, based on decision trees, for mining ReBAC policies from access control lists (ACLs) and information about entities. The algorithm first learns an authorization policy in the form of a decision tree, and then extracts a set of candidate authorization rules from the decision tree. Next, it constructs the final mined policy by eliminating negative conditions from the candidate rules and then simplifying them. Compared to state-of-the-art ReBAC mining algorithms, DTRM is simpler, significantly faster, achieves similar policy quality, and can mine policies in a richer language.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

In relationship-based access control (ReBAC), access control policies are expressed in terms of chains of relationships between entities. This increases expressiveness and often allows more natural policies. High-level access control policy models such as attribute-based access control (ABAC) and ReBAC are becoming increasingly widely adopted, as security policies become more dynamic and more complex. ABAC is already supported by many enterprise software products, using a standardized ABAC language such as XACML or a vendor-specific ABAC language. Forms of ReBAC are supported in popular online social network systems and are starting to emerge in other software systems as well.

High-level policy models such as ReBAC allow for concise and flexible policies and promise long-term cost savings through reduced management effort. The up-front cost of developing a ReBAC policy to replace an existing lower-level policy, such as ACLs or an RBAC policy, can be a significant barrier to adoption of ReBAC. Policy mining algorithms have the potential to greatly reduce this cost, by automatically producing a high-level policy from existing lower-level data; vetting and tweaking it is significantly less work than creating a high-level policy from scratch. There is a substantial amount of research on role mining, surveyed in [MSVA16, DMA18], and a small but growing literature on ABAC policy mining [XS15a, XS14, MBCF15, MTL15, CWB18, IM18, CCWB19] (surveyed in [DMA18]) and ReBAC policy mining [BSL17, BSL18, BSL19b, BSL19a, IM19].

ReBAC policy mining was first studied by Bui et al. [BSL17, BSL19b]. They define the problem as follows: Given information about the attributes of all entities in the system, and the set of currently granted permissions; Find a ReBAC policy that grants the same permissions using concise, high-level rules. For realistic datasets, the search space of possible policies is enormous. In traditional ABAC languages, such as XACML, each expression involves at most one attribute dereference. In ReBAC, an expression may contain a path expression representing a chain of attribute dereferences, and the search space grows exponentially in the path length.

This paper proposes a new ReBAC policy mining algorithm, called DTRM (Decision Tree ReBAC Miner), based on decision tree learning. Decision trees are a natural basis for ReBAC policy mining because logic-based policy rules can easily be extracted from them; it is much more difficult to extract such rules from neural networks, Bayes classifiers, etc. Also, decision trees are well known as a compact representation of ABAC (and ReBAC) policies that supports efficient policy evaluation

[LCHX08, NDS19]. DTRM works as follows. First, it learns an authorization policy in the form of a decision tree, using a modified version of the decision tree learning algorithm in Scikit [Dec19], which is an optimized version of CART [BFOS84]; the modification allows us to specify a secondary quality metric used as a tie-breaker for features with the same value of the built-in primary quality metric. We selected Scikit’s algorithm because it is based on the well-known CART algorithm, it has been used successfully in a variety of application areas, and a patch for the above modification is available for it. Second, DTRM extracts a set of candidate authorization rules from the decision tree. Finally, DTRM constructs the mined policy by optionally eliminating negative conditions and constraints from the candidate rules (depending on whether the target policy language is ORAL19 or ORAL20, as discussed below) and then merging and simplifying the candidate rules.

Our approach is general and could be used to mine policies in any ReBAC language. Our implementation produces policies in an extension of ORAL (Object-oriented Relationship-based Access-control Language), a ReBAC policy language developed by Bui et al. Several other ReBAC policy languages have been proposed, e.g., [CFP09, Fon11, CPS12, HAJ13]. We chose ORAL as the basis for our policy language to facilitate comparison with existing work. ORAL [BSL17, BSL18, BSL19b, BSL19a] or a similar language [IM19] is used in all of the published work on ReBAC policy mining. The similarity of Iyer et al.’s policy language to ORAL is reflected in the fact that the policies used in their experiments are translations of parts of the ORAL policies used in [BSL19b]. Iyer et al.’s language is less expressive than ORAL because it lacks set comparison operators. As a result, some rules (e.g., 10 out of the 39 rules in the eWorkForce case study) were omitted from their translation and experiments. Unlike ORAL and Iyer et al.’s language, the other ReBAC policy languages cited above cannot express constraints that relate the attributes of different entities. Such constraints appear in a majority of the rules in the case studies used in [BSL19b].

A distinguishing feature of ORAL is its interpretation of ReBAC as object-oriented ABAC: relationships are expressed using attributes that refer to other objects, and path expressions built from chains of such attributes, as in object-oriented languages such as UML and Java. In ORAL, rules are built from atomic conditions, each of which is a condition on a single object—the subject (the entity making the access request) or resource (the entity to which access is requested)—and atomic constraints, each of which expresses a relationship between characteristics of the subject and the resource. An example of a condition is subject.employer = LargeBank. An example of a constraint is subject.department resource.project.departments.

The most recent version of ORAL, introduced in [BSL19a], supports two additional set comparison operators, compared with earlier versions. We refer to that language as ORAL19. Our algorithm can mine policies in either ORAL19 or ORAL20. ORAL20 is our extension of ORAL19 with negative conditions and constraints. A negative condition or constraint is the negation of an atomic condition or constraint, e.g., subject.employer LargeBank or subject.department resource.project.departments. There are two motivations for supporting ORAL19, i.e., for optionally eliminating negative conditions and constraints from candidate rules when producing the final policy. First, a policy language without negation is sometimes preferred to reduce the chance of writing rules that grant excess permissions when new entities are added; for example, the condition subject.department {CS, EE} is safe even if new departments may be created, but the condition subject.department CS may lead to undesired granting of permissions to members of new departments. Second, this allows direct experimental comparison of our algorithm with FS-SEA*, the state-of-the-art ReBAC policy mining algorithm in [BSL19a]

, the most recent and best of Bui et al.’s ReBAC policy mining algorithms. FS-SEA* is a complicated multi-phase algorithm that combines heuristics, neural networks, and a grammar-based genetic algorithm.

To demonstrate the benefits of our approach, we conducted an experimental comparison with FS-SEA* [BSL19a]. The datasets used in our experiments include four sample policies, two large case studies based on policies of real organizations [DBLJ14a, DBLJ14c], and the five synthetic policies used in [BSL19a]. Compared to FS-SEA*, DTRM is simpler, significantly faster, achieves similar policy quality, and can mine policies in a richer language (with negative conditions and constraints). Averaged over all of our datasets, DTRM is 7.9 times faster than FS-SEA*.

2 Policy Language

Our policy language, which we call ORAL20, is Bui et al.’s ORAL19 (our name for it) [BSL19a], extended to allow negative conditions and constraints. We give a brief overview of the language, and refer the reader to [BSL19a] for details of ORAL19 and to [BSL19b] for details of the original version of ORAL, which ORAL19 extends. This overview is largely the same as in [BSL19a]. We include it to make this paper more self-contained, for the reader’s convenience.

A ReBAC policy is a tuple , where is a class model, is an object model, is a set of actions, and is a set of rules.

A class model is a set of class declarations. Each field has a type, which is a class name or “Boolean”, and a multiplicity, which specifies how many values may be stored in the field and is “one” (also denoted “1”), “optional” (also denoted “?”), or “many” (also denoted “*”, meaning any number). Boolean fields always have multiplicity 1. Every class implicitly contains a field “id” with type String and multiplicity 1. A reference type is any class name (used as a type). Like [BSL19a], we leave inheritance as a topic for future work.

An object model is a set of objects whose types are consistent with the class model and with unique values in the id fields. Let denote the type of object . The value of a field with multiplicity “many” is a set. The value of a field with multiplicity “optional” may be a single value or the placeholder indicating absence of a value.

A path is a sequence of field names, written with “.” as a separator. A condition is a set, interpreted as a conjunction, of atomic conditions or their negations. An atomic condition is a tuple , where is a non-empty path, is an operator, either “in” or “contains”, and is a constant value, either an atomic value (if is “contains”) or a set of atomic values (if is “in”). For example, an object satisfies if the value obtained starting from and following (dereferencing) the dept field and then the id field equals CompSci. In examples, conditions are usually written using mathematical notation as syntactic sugar, with “” for “in” and “” for “contains”. For example, is more nicely written as . Note that the path is simplified by omitting the “id” field since all non-Boolean paths end with “id” field. Also, “=” is used as syntactic sugar for “in” when the constant is a singleton set; thus, the previous example may be written as dept=CompSci.

A constraint is a set, interpreted as a conjunction, of atomic constraints or their negations. Informally, an atomic constraint expresses a relationship between the requesting subject and the requested resource, by relating the values of paths starting from each of them. An atomic constraint is a tuple , where and are paths (possibly the empty sequence), and is one of the following five operators: equal, in, contains, supseteq, subseteq. Implicitly, the first path is relative to the requesting subject, and the second path is relative to the requested resource. The empty path represents the subject or resource itself. For example, a subject and resource satisfy if the set .specialties contains the value .topic.

In examples, constraints are written using mathematical notation as syntactic sugar, with “” for “equal”,“” for “supseteq”, and “” for “subseteq”. Also, the subject path and resource path are prefixed with “subject” and “resource”, respectively, to enhance readability by explicitly indicating the object from which the path starts. For example, may be written with syntactic sugar as .

A rule is a tuple subjectType, subjectCondition, resourceType, resourceCondition, constraint, actions, where subjectType and resourceType are class names, subjectCondition and resourceCondition are conditions, constraint is a constraint, actions is a set of actions. A rule must satisfy several well-formedness requirements [BSL19b]. For a rule , let , , , , , and .

In example rules, the paths in the subject condition and resource condition are prefixed with “subject” or “resource”, respectively, to enhance readability. For example, the e-document case study [BSL19b, DBLJ14b] involves a large bank whose policy contains the rule: A project member can read all sent documents regarding the project. Using syntactic sugar, this is written as Employee, subject.employer = LargeBank, Document, true, subject.workOn.relatedDoc resource, {read}, where Employee.workOn is the set of projects the employee is working on, and Project.relatedDoc is the set of sent documents related to the project.

The type of a path (relative to a specified class) is the type of the last field in the path. The multiplicity of a path (relative to a specified class) is one if all fields on the path have multiplicity one, is many if any field on the path has multiplicity many, and is optional otherwise. Given a class model, object model, object , and path , let be the result of navigating (a.k.a. following or dereferencing) path starting from object . The result might be no value, represented by , an atomic value, or (if has multiplicity many) a set of values. This is like the semantics of path navigation in UML’s Object Constraint Language (http://www.omg.org/spec/OCL/).

An object satisfies an atomic condition , denoted , if . An object satisfies a condition , denoted , if it satisfies each atomic condition or negated atomic condition in . Objects and satisfy an atomic constraint , denoted , if . An object satisfies a constraint , denoted , if it satisfies each atomic constraint or negated atomic constraint in .

An SRA-tuple is a tuple , where the “subject” and “resource” are objects, and is an action, representing (depending on the context) authorization for to perform on or a potential request to perform that access. An SRA-tuple satisfies a rule , denoted , if . The meaning of a rule , denoted , is the set of SRA-tuples that satisfy it. The meaning of a ReBAC policy , denoted , is the union of the meanings of its rules.

3 Problem Definition

To facilitate comparison with prior work, we adopt Bui et al.’s definition of the ReBAC mining problem. We present the core parts of the definition here, and refer the reader to [BSL19b] for more details and discussion.

An access control list (ACL) policy is a tuple , where is a class model, is an object model, is a set of actions, and is a set of SRA tuples representing authorizations. Conceptually, is the union of the access control lists.

An ReBAC policy is consistent with an ACL policy if they have the same class model, object model, actions, and .

Among the many ReBAC policies consistent with a given ACL policy , the most desirable ones are those that satisfy the following two criteria. One criterion is that the “id” field should be avoided when possible, because policies that use this field are (to that extent) identity-based, not attribute-based or relationship-based. Therefore, the “id” field should be used only when necessary, i.e., only when every ReBAC policy consistent with uses it. The other criterion is that the policy should have the best quality as measured by a given policy quality metric , expressed as a function from ReBAC policies to the natural numbers, with small numbers indicating high quality. This is natural for metrics based on policy size, which are the most common type.

The ReBAC policy mining problem is: given an ACL policy and a policy quality metric , find a set of rules such that the ReBAC policy is consistent with , uses the “id” field only when necessary, and has the best quality, according to , among such policies.

The policy quality metric that our algorithm aims to optimize is weighted structural complexity (WSC), a generalization of policy size first introduced for RBAC policies [MCL10] and later extended to ReBAC [BSL19b]. Minimizing policy size is consistent with usability studies showing that more concise access control policies are more manageable [BM13]. WSC is a weighted sum of the numbers of primitive elements of various kinds that appear in a rule or policy. WSC is defined bottom-up. The of an atomic condition is , where is the length of path , and is 1 if is an atomic value and is the cardinality of if is a set. The of an atomic constraint is . The of a negated atomic condition is ; the of a negated atomic constraint is defined similarly. The WSC of a rule , denoted , is the sum of the WSCs of the atomic conditions and atomic constraints in it, plus the cardinality of the action set (more generally, it is a weighted sum of those numbers, but we take all of the weights to be 1). The WSC of a ReBAC policy , denoted , is the sum of the of its rules.

4 Algorithm

This section presents our algorithm, Decision Tree ReBAC Miner (DTRM). It has 2 main phases. The first phase learns a decision tree that classifies authorization requests as permitted or denied, and then constructs a set of candidate rules by extracting them from the decision tree. The second phase improves the policy by merging and simplifying the candidate rules and optionally removing negative atomic conditions/constraints from them.

4.1 Phase 1: Learn Decision Tree and Extract Rules

A feature

is an atomic condition (on the subject or resource) or atomic constraint satisfying user-specified limits on lengths of paths in conditions and constraints. We define a mapping from feature vectors to Boolean labels: given an SRA tuple

, we create a feature vector (i.e., a vector of the Boolean values of features evaluated for subject and resource ) and map it to true if the SRA tuple is permitted (i.e., is in ) and to false otherwise. We represent Booleans as integers: 0 for false, and 1 for true. We train a decision tree to learn this classification (labeling) of feature vectors.

We decompose the problem based on the subject type, resource type, and action. Specifically, we learn a separate decision tree to classify SRA tuples with subject type , resource type , and action . We do this for each such that contains some SRA tuple with a subject of type , a resource of type , and action . The inputs to are limited to the features appropriate for subject type and resource type , e.g., the path in the subject condition starts with a field in class . The set of labeled feature vectors used to train contains an element generated from each possible combination of a subject of type (in the given object model) and resource of type .

This decomposition is justified by the fact that all SRA tuples authorized by the same rule contain subjects with the same subject type and resources with the same resource type. A rule can authorize SRA tuples with different actions since the last component of a rule is a set of actions. The first phase of our algorithm learns rules containing a single action; the second phase attempts to merge similar rules with different actions into a single rule authorizing multiple actions.

As an optimization, we discard a feature if it has the same truth value in all of the labeled feature vectors used to train a DT; for example, if all instances of some type in the given object model have the same value for a field , then atomic conditions on field are discarded.

We also detect sets of equivalent features, which are features that have the same truth value in all feature vectors labeled true used to train a particular DT. For each set of equivalent features, we keep the features with the lowest WSC and discard the rest. This is justified by that fact that the discarded features cannot appear in a policy with minimum WSC and consistent with .

4.1.1 Background on Decision Trees

Figure 1 shows an example of a decision tree that represents a rule in an electronic medical record policy. The subject type, resource type and action are “Physician”, “MedicalRecord” and “read”, respectively. The rule specifies that only non-trainee physicians can read medical records which are associated to them. Formally, the rule is written as Physician, subject.isTrainee = False, MedicalRecord, true, subject resource.physician, {read}.

Figure 1: A sample decision tree for part of the healthcare sample policy.

Internal nodes and leaf nodes are represented in the figure by unfilled and filled boxes, respectively. When classifying a feature vector, an internal node tests the value of a certain feature, each edge corresponds to a possible outcome of the test, and a leaf node corresponds to a classification outcome (label). A feature vector is classified by testing the feature in the root node, following the edge corresponding to the value of the feature to reach a subtree, and then repeating this procedure until a leaf node is reached. For example, the decision tree in Figure 1 classifies a feature vector for which both tests return True as PERMIT.

4.1.2 Build Decision Trees

A decision tree is built by recursively partitioning feature vectors in the dataset. A popular partitioning scheme has the following steps, starting from a root node associated with the entire dataset: (1) choose (as described below) a feature to test at the root node, and create a child node for each possible outcome of the test, (2) partition the set of feature vectors associated with the root node among the children, based on the outcome of the test, (3) recursively apply this procedure to each child. The recursion stops when all of the feature vectors associated with a node have the same classification label. Several well-known decision tree building algorithms use this scheme, including ID3, its successor C4.5, and Classification and Regression Trees (CART), which is similar to C4.5.

We use the decision tree learning algorithm in the Python library scikit-learn [Dec19]. It is an optimized version of CART [BFOS84]. We disable its pruning methods. Pruning aims to reduce overfitting and make the decision trees generalize better. However, a pruned tree might misclassify some feature vectors in the training data. Pruning is therefore inappropriate for our purpose, which is to produce a policy completely consistent with the given ACL policy. The current implementation of the algorithm in scikit-learn treats categorical features as continuous features. For example, instead of treating a binary feature as a feature with possible values of 0 and 1, the test checks if the feature’s value is less than or greater or equal than 0.5 for 0 and 1 respectively.

The most important step of the partitioning algorithm is choosing which feature to test at each node , by applying a scoring criteria to the remaining features (i.e., features that have not been used for splitting at an ancestor of ) and then choosing the top-ranked feature. Several scoring criteria have been proposed. The most popular ones are information gain and Gini index. For both of them, smaller values are better.111Some presentations use variants of the following definitions for which larger values are better.

The Information Gain uses entropy to calculate the homogeneity of a set of feature vectors. Entropy is the measure of uncertainty of a random variable. The entropy is 0 if the sample contains only instances of the same class, and the entropy is 1 if the sample is equally divided. The information gain at node

for splitting with feature is

where is the set of feature vectors associated with the current node , ranges over the possible outcomes of testing feature , is the subset of containing feature vectors for which testing of feature has outcome , ranges over the classification labels, and is the subset of containing feature vectors with label .

The Gini Index uses impurity to measure how likely a randomly selected element would be misclassified. If all instances in the sample have the same class, the impurity will be 0. The Gini Index is calculated by subtracting the sum of squared probabilities of each class from 1. The Gini index for splitting at node

with feature is

When multiple features are tied for top-ranked according to the primary scoring criteria (information gain or Gini index), scikit-learn chooses pseudorandomly among them. However, this is not the best approach for our goal of minimizing the policy’s WSC. Instead, we adopt a modification (patch) to the scikit-leran algorithm that allows specification of a secondary metric as a tie-breaker. We use the WSC of the feature (recall that WSC of atomic condition and atomic constraints is defined in Section 3) as a tie-breaker. This has the side-benefit of making the algorithm deterministic, so experimental results are more easily reproducible.

We experimented with both of the above scoring criteria on some of our sample policies, and the generated decision trees were identical. We decided to adopt the default scoring metric, which is Gini inndex, for our experiments.

4.1.3 Extract rules

After a decision tree is constructed, we convert it into an equivalent set of rules and include them in the candidate policy. For each distinct path through the tree from the root node to a leaf node labeled “PERMIT”, we generate a rule containing the features (atomic conditions and constraints) associated with the internal nodes on that path; furthermore, if the path follows the False branch out of a node, then the feature associated with that node is added to the rule as a negative feature. For example, for the sample decision tree in Figure 1, only one rule is generated, which is the same as the input rule mentioned in Section 4.1.1.

4.2 Phase 2: Improve the rules

Phase 2 has two main steps: eliminate negative features, and merge and simplify rules.

4.2.1 Eliminate Negative Features

This step is optional, depending the targeted policy language (ORAL19 or ORAL20), as discussed in Section 1. This step eliminates each negative feature in a rule by applying the following substeps in order until one succeeds. A rule is valid if it covers only SRA tuples in .

  1. Remove from , if the resulting rule is valid.

  2. Replace with a feature , if the resulting rule is valid and the resulting policy (i.e., the policy with replaced with the resulting rule) covers all SRA tuples in . In particular, try this for each feature not already used in , in ascending order of WSC.

  3. If is a negative atomic condition, and contains at least one other negative atomic condition in with the same path as , and path has multiplicity “one” or “optional”, then replace all of the negative atomic conditions with path with a positive atomic condition using the same path and the same operator, and with a set of constants which is the complement of the set of constants that appear in those negative atomic condition. The complement is with respect to the set of all possible constants for that path. Note that this step always succeeds when it is applicable, i.e., the resulting rule is always valid, and the resulting policy always covers all SRA tuples in . Generalizing this step to apply when has multiplicity “many” would require either replacing with multiple rules, or extending the policy language to allow atomic conditions containing operators (such as ) for which both arguments have multiplicity “many”.

  4. If is a subject atomic condition, remove all subject atomic conditions (positive or negative) in , and add the condition “subject.id ”, where is the set of ids of subjects that appear in SRA tuples covered by . An analogous step applies if is a resource atomic condition. Note that this step always succeeds when it is applicable.

  5. Replace with a set of features, if the resulting rule is valid and the resulting policy covers all SRA tuples in . In particular, try this for all sets containing two more features not already used in , in ascending order of WSC of the set (which is the sum of the WSCs of the features in it). Note that this step can be reached only if is a constraint. In the experiments described in Section 6, this step is never reached, i.e., one of the previous steps always succeeds.

4.2.2 Merge and Simplify Rules

This step attempts to merge and simplify rules using the same techniques as [BSL19b].

First, this step attempts to merge pairs of rules that have the same subject type, resource type, and constraint by taking the least upper bound of their subject conditions, the least upper bound of their resource conditions, and the union of their sets of actions. The least upper bound of conditions and , denoted , is

Note that the meaning of the merged rule is a superset of the meanings of the rules and being merged. If the merged rule is valid, then it replaces and .

Second, this step attempts to simplify the rules as follows.

  1. It eliminates atomic conditions from the subject and resource conditions when this preserves validity. Removing one atomic condition might prevent removal of another atomic condition, so it searches for a set of removable conjuncts that maximizes the quality of the resulting rule.

  2. It eliminates atomic constraints when this preserves validity. It searches for the set of atomic constraints to remove that maximizes the quality of the resulting rule while preserving validity.

  3. It eliminates overlapping actions between rules. Specifically, an action in a rule is removed if there is another rule in the policy such that .

  4. It eliminates actions when this preserves the meaning of the policy. In other words, it removes an action in rule if all the SRA tuples covered by in are covered by other rules in the policy. Note that the previous item is a special case of this one, listed separately to ensure that the special case takes precedence.

  5. If the subject condition contains an atomic condition of the form , and the constraint contains an atomic constraint of the form , then replace that atomic constraint with the atomic condition in the resource condition (note that this is a form of constant propagation); and similarly for the symmetric situation in which the resource condition contains such an atomic condition, etc.

  6. Remove cycles in the paths in the conditions and constraint, if the resulting rule is valid and the resulting policy still covers all of . A cycle is a path that navigates from some class back to class .

  7. If a subject/resource path of an atomic constraint evaluates to a same constant value for all of the subjects/resources that are in SRA tuples covered by the rule, then replace the atomic constraint with corresponding resource/subject condition and constant .

5 Evaluation Methodology

We adopt Bui et al.’s methodology for evaluating policy mining algorithms [BSL19a]. It is depicted in Figure 2. It takes a class model and a set of ReBAC rules as inputs. The methodology is to generate an object model based on the class model (independent of the ReBAC rules), compute the authorizations from the object model and the rules, run the policy mining algorithm with the class model, object model, and as inputs, and finally compare the mined policy rules with the simplified original (input) policy rules, obtained by applying the simplifications in Section 4.2.2 to the given rules. Comparison with the simplified original policy is a more robust measure of the algorithm’s ability to discover high-level rules than comparison with the original policy, because the original policy is not always the simplest. If the mined rules are similar to the simplified original rules, the policy mining algorithm succeeded in discovering the desired ReBAC rules that are implicit in .

Figure 2: Evaluation methodology. Reproduced from [BSL19a].

5.1 Datasets

We use four sample policies developed by Bui et al. [BSL19b]. One of them is based on an EBAC policy by Bogaerts et al. [BDLJ15]. The other three are based on ABAC policies by Xu et al. [XS15b]; rewriting them in ReBAC allows numerous aspects to be expressed more naturally, as discussed in [BSL19b]. These sample policies have non-trivial and realistic rules, but are relatively small in terms of the number of rules. We also use Bui et al.’s translation into ORAL19 [BSL19b] of two large case studies developed by Decat, Bogaerts, Lagaisse, and Joosen based on the access control requirements for Software-as-a-Service (SaaS) applications offered by real companies [DBLJ14a, DBLJ14c]. Finally, we use the synthetic ORAL19 policies described in [BSL19a]. Bui et al.’s policy rules and object model generators for these sample policies and case studies, and their synthetic policy generator, are available online [SSS19]. We made small changes to the object model generators for the project management, workforce management, and e-document policies, to make the generated object models slightly more realistic.

These policies, or variants of them, have been used as benchmarks in several other papers on policy mining. In work on ReBAC mining, Iyer et al. [IM19] use variants of three of the sample policies and the workforce management case study, and Bui et al. [BSL18] use all of the sample policies and case studies. In work on ABAC mining, Medvet et al. [MBCF15] and Iyer at al. [IM18] use Xu et al.’s original ABAC versions of some of the sample policies.

This section provides brief descriptions of these policies. More detailed descriptions are available in the cited papers. Table 1 shows several metrics of the size of the rules, class model, and object model in each policy. #field is computed by summing, over the objects in the object model, the number of fields (including “id” field and Boolean fields) in each object.

Policy_N #obj #field #FtVec #rules
EMR_15 353 877 4134 6
healthcare_5 736 1804 42121 8
project-management_5 179 296 4080 10
university_5 738 926 83761 10
e-document_125 423 2065 82860 39
eWorkforce_10 412 1124 14040 19
syn_20 678 7848 25600 20
syn_25 828 9773 40000 20
syn_30 978 11698 57600 20
Table 1: Policy sizes. For the given value of the object model size parameter , #obj is the average number of objects in the object model, and #field is the average number of fields in the object model. #FtVec is the number of feature vectors (i.e., labeled SRA tuples) that the algorithms use to train a classifier. Averages are over 5 pseudorandom object models for each policy.

Each sample policy and case study policy has handwritten class model and rules, and an object model generated by a policy-specific pseudorandom algorithm designed to produce realistic object models, by creating objects and selecting their attribute values using appropriate probability distributions (e.g., normal, uniform, and Zipf distributions). The object model generation algorithms are parameterized by a size parameter

; for most classes, the number of instances is selected from a normal distribution whose mean is linear in

.

The Electronic Medical Record (EMR) sample policy, based on the EBAC policy in [BDLJ15], controls access by physicians and patients to electronic medical records, based on institutional affiliations, patient-physician consultations (each EMR is associated with a consultation), supervisor relationships among physicians, etc. The numbers of physicians, consultations, EMRs, and hospitals are proportional to .

The healthcare sample policy, based on the ABAC policy in [XS15b], controls access by nurses, doctors, patients, and agents (e.g., a patient’s spouse) to electronic health records (HRs) and HR items (i.e., entries in health records). The numbers of wards, teams, doctors, nurses, teams, patients, and agents are proportional to .

The project management sample policy, based on the ABAC policy in [XS15b], controls access by department managers, project leaders, employees, contractors, auditors, accountants, and planners to budgets, schedules, and tasks associated with projects. The numbers of departments, projects, tasks, and users of each type are proportional to .

The university sample policy, based on the ABAC policy in [XS15b], controls access by students, instructors, teaching assistants (TAs), department chairs, and staff in the registrar’s office and admissions office to applications (for admission), gradebooks, transcripts, and course schedules. The numbers of departments, students, faculty, and applicants for admission are proportional to .

The e-document case study, based on [DBLJ14a], is for a SaaS multi-tenant e-document processing application. The application allows tenants to distribute documents to their customers, either digitally or physically (by printing and mailing them). The overall policy contains rules governing document access and administrative operations by employees of the e-document company, such as helpdesk operators and application administrators. It also contains specific policies for some sample tenants. One sample tenant is a large bank, which controls permissions to send and read documents based on (1) employee attributes such as department and projects, (2) document attributes such as document type, related project (if any), and presence of confidential or personal information, and (3) the bank customer to which the document is being sent.Some tenants have semi-autonomous sub-organizations, modeled as sub-tenants, each with its own specialized policy rules. The numbers of employees of each tenant, registered users of each customer organization, and documents are proportional to .

The workforce management case study, based on [DBLJ14c], is for a SaaS workforce management application provided by a company, pseudonymously called eWorkforce, that handles the workflow planning and supply management for product or service appointments (e.g., install or repair jobs). Tenants (i.e., eWorkforce customers) can create tasks on behalf of their customers. Technicians working for eWorkforce, its workforce suppliers, or subcontractors of its workforce suppliers receive work orders to work on those tasks, and appointments are scheduled if appropriate. Warehouse operators receive requests for required supplies. The overall policy contains rules governing the employees of eWorkforce, as well as specific policies for some sample tenants, including PowerProtection (a provider of power protection equipment and installation and maintenance services) and TelCo (a telecommunications provider, including installation and repair services). Permissions to view, assign, and complete tasks are based on each subject’s position, the assignment of tasks to technicians, the set of technicians each manager supervises, the contract (between eWorkforce and a tenant) that each work order is associated with, the assignment of contracts to departments within eWorkforce, etc. The only change we make is to omit from the workforce management case study the classes and 7 rules related to work orders, because they involve inheritance, which our algorithm does not yet support (it is future work). The numbers of helpdesk suppliers, workforce providers, subcontractors, helpdesk operators, contracts, work orders, etc., are proportional to .

The synthetic policies developed by Bui et al. [BSL19a] are designed to have realistic structure, statistically similar in some ways to the sample policies and case studies described above. The class model is designed to allow generating atomic conditions and atomic constraints with many combinations of path length and operator. It supports the types of conditions and constraints that appear in the sample policies and case studies, plus constraints involving the additional constraint operators that are supported in ORAL19 but not in the original ORAL [BSL19b]. The object model generator’s size parameter specifies the desired number of instances of each subject class. The number of instances of each resource class is . The numbers of instances of other classes is fixed at 3. This reflects a typical structure of realistic policies, in which the numbers of instances of some classes (e.g., doctors, patients, health records) scale linearly with the overall size of the organization, while the numbers of instances of other classes (e.g., departments, medical specialties) grow much more slowly (which we approximate as constant). Policy rules are generated using several numbers and statistical distributions based on the rules in the sample policies and case studies. The number of rules in each policy is 20, which is the average number of rules in those policies.

5.2 Policy Similarity Metrics

We evaluate the quality of the generated policy primarily by its syntactic similarity and per-rule semantic similarity to the simplified original policy. These metrics are defined in [BSL19b] and are normalized to range from 0 (completely different) to 1 (identical).

Syntactic similarity measures the fraction of types, atomic conditions, atomic constraints, and actions that rules or policies have in common. The Jaccard similarity of sets is . The syntactic similarity of rules and is the average of , , , , and . The syntactic similarity of rule sets and , SynSim(, ), is the average, over rules in , of the syntactic similarity between and the most similar rule in .

Semantic similarity measures the fraction of authorizations that rules or policies have in common. The semantic similarity of rules and is . We extend this to per-rule semantic similarity of policies in exactly the same way that syntactic similarity of rules is extended to syntactic similarity of policies. Note that this metric measures similarity of the meanings of the rules in the policies, not similarity of the overall meanings of the policies. In our experiments, the original and mined policies always have exactly the same overall meaning.

6 Evaluation Results

Policy & Size Syntactic Similarity Per-rule Semantic Sim. WSC Running Time (sec)
DTRM FS-SEA* DTRM FS-SEA* Orig sOrig DTRM FS-SEA* DTRM FS-SEA* SpdUp
EMR_15 0.99 0.01 0.99 0.01 1.00 0.00 1.00 0.00 49 47 47 47 48 0.30 87 7.37 1.83
healthcare_5 1.00 0.00 1.00 0.00 1.00 0.00 1.00 0.00 39 39 39 39 65 41.07 96 14.54 1.48
project-mgmt._5 1.00 0.00 1.00 0.00 1.00 0.00 1.00 0.00 67 67 67 67 2 1.62 6 0.45 3.88
university_5 1.00 0.00 1.00 0.00 1.00 0.00 1.00 0.00 54 54 54 54 141 64.02 253 21.98 1.79
e-doc_125 0.92 0.01 0.89 0.02 0.86 0.04 0.91 0.04 359 252 302 305 1264 276.13 6442 1415.93 5.10
eWorkforce_10 0.98 0.01 0.94 0.01 1.00 0.00 0.98 0.02 171 133 128 157 47 5.80 103 22.27 2.21
syn_20 0.98 0.02 0.98 0.01 0.94 0.03 0.98 0.02 155 150 156 169 207 88.93 3027 887.18 14.59
syn_25 0.98 0.02 1.00 0.00 0.96 0.05 1.00 0.00 155 150 156 150 354 142.31 6277 2283.31 17.75
syn_30 0.99 0.01 1.00 0.00 0.97 0.04 1.00 0.00 155 150 153 150 482 82.72 10745 3396.60 22.30
Table 2: Experimental results. Orig and sOrig refer to the original rules and the simplified original rules, respectively. When computing policy similarity, we compare the mined rules with the simplified original rules. and

are the mean and standard deviation, respectively. Running times for DTRM are emphasized with bold font, since they are significantly better than the running times of FS-SEA* for all datasets. SpdUp is the speed up, computed as the ratio of the running times of the two algorithms.

DTRM is implemented in Python, except that phase 2 step 2 (merge and simplify rules) uses the Java code from Bui et al.’s implementation of FS-SEA*. Their implementation of FS-SEA* is available online [SSS19]. Experiments were run on Windows 10 on an Intel i7-6770HQ CPU. We use the same path length limits (cf. Section 4.1) as in [BSL19b, BSL19a].

6.1 Experiments with Sample Policies

The results of experiments with the four sample policies, described in Section 5.1, are averaged over 5 pseudorandom object models for each policy and reported in Table 2. For both DTRM and FS-SEA*, the mined policy is identical to the simplified original policy, except for one minor syntactic variation in one conjunct of one condition of one rule of the EMR policy (the variant is semantically equivalent to the original conjunct; this is reflected in the perfect per-rule semantic similarity). DTRM spends most of the time in phase 1 to learn decision trees. The averaged running time spent on phase 2 is less than 1 second for EMR_15 and project-mangagment_5, and is less than 2 seconds for healthcare_5 and university_5. DTRM is faster than FS-SEA* on all of these policies, with an average speedup of 2.25. DTRM’s average speedup on these policies is less than its average speedup on the other policies in Table 2

, because FS-SEA* performs better (in terms of running time) on these policies than on the other policies, which are larger and more complicated. FS-SEA* generally needs multiple iterations of feature selection and evolution to learn the rules for a given combination of subject type, resource type, and action. However, for these sample policies, FS-SEA* needs only one iteration for each such combination.

6.2 Experiments with Case Study Policies

Results of running both algorithms on the two case studies described in Section 5.1 are reported in Table 2. The results are averages over 5 pseudorandom object models for each policy. For workforce management, DTRM achieves 4% higher syntactic similarity (98% vs. 94%) and 2% higher per-rule semantic similarity (100% vs. 98%). For e-document, DTRM achieves 3% higher syntactic similarity (92% vs. 98%) and 5% lower per-rule semantic similarity (86% vs. 91%), and produces smaller (lower WSC) policies. DTRM is faster than FS-SEA* for both case studies: 5.10 times faster for e-document, and 2.21 times faster for workforce management.

In summary, DTRM and FS-SEA* are comparably effective at discovering the desired rules, and DTRM is significantly faster than FS-SEA*.

6.3 Experiments with Synthetic Policies

We generated five sets of synthetic rules. For each of them, we generate a sequence of synthetic object models of varying size, with . These policies are called syn_20, syn_25 and syn_30 respectively. We run DTRM and FS-SEA* on all of them, and average the results for the five policies with the same . The averaged results are reported in Table 2.

Both algorithms achieve the same syntactic similarity (98%) on syn_15, and FS-SEA* achieves 2% and 1% higher syntactic similarity on syn_25 and syn_30, respectively. For per-rule semantic similarity, FS-SEA* achieves 4% higher on syn_20 and syn_25, and 3% higher on syn_30. Both algorithms produce policies with WSC very close to the WSC of the input: DTRM does slightly better than FS-SEA* on syn_20 (156 vs. 159) and slightly worse on syn_25 (156 vs. 150) and syn_30 (153 vs. 150). The running time of DTRM is notably smaller. It runs 14.59 times faster on syn_20, 17.75 times faster on syn_25, and 22.3 times faster on syn_30.

In summary, as for the case studies, DTRM and FS-SEA* are comparably effective at discovering the desired rules, and DTRM is significantly faster than FS-SEA*.

7 Related Work

We discuss related work on ReBAC policy mining and ABAC policy mining.

7.1 Related work on ReBAC policy mining

Bui et al. developed several ReBAC policy mining algorithms [BSL17, BSL18, BSL19b, BSL19a], the most recent and best of which is FS-SEA* [BSL19a]. Compared to FS-SEA*, DTRM is simpler, significantly faster, achieves similar policy quality, and can mine policies in a richer language (with negative conditions and constraints). Averaged over all of our datasets, DTRM is 7.9 times faster than FS-SEA*.

Bui et al.’s policy mining algorithm in [BSL18], which is a variant of the algorithm in [BSL19b], mines ReBAC policies from incomplete and noisy information about granted permissions [BSL18]. Such information is commonly available from access logs. In particular, their algorithm identifies and removes permissions likely to be extraneous, identifies and adds permissions likely to be missing, and reports these changes to the user. Extending our algorithm to handle incomplete and noisy information is a direction for future work, as discussed at the end of Section 1.

Iyer et al. present algorithms for mining ReBAC policies and mining graph transition policies. They are the first to consider the latter problem. Their algorithms are based on ideas from rule mining and frequent graph-based pattern mining [IM19]. As discussed in Section 1, their algorithm targets a policy language that is similar to ORAL but less expressive, due to the lack of set comparison operators. As a very rough performance comparison, consider the largest dataset used in their experiments, containing 29 out of the 39 rules from the workforce management case study. Their dataset contains 10,660 feature vectors (log entries, in their terminology) and is processed in 84 seconds by their Python implementation on Windows 10 on an Intel i7-6700HQ CPU [IM19, Table 1]. Our workforce management dataset contains 14,039 feature vectors and is processed in 47 seconds by our mostly Python implementation on Windows 10 on an Intel i7-6770HQ CPU (the only difference between these two CPU models is the type of integrated graphics).

7.2 Related work on ABAC Policy mining

Xu et al. proposed the first algorithm for ABAC policy mining [XS15b] and a variant of it for mining ABAC policies from logs [XS14]

. Medvet et al. developed the first evolutionary algorithm for ABAC policy mining

[MBCF15]. Iyer et al. developed the first ABAC policy mining algorithm that can mine ABAC policies containing deny rules as well as permit rules [IM18]. Cotrini et al. proposed a different formulation of the problem of ABAC mining from logs and an algorithm, called Rhapsody, to solve it [CWB18]

. Rhapsody is based on APRIORI-SD, a machine-learning algorithm for subgroup discovery. Rhapsody can easily be extended to handle path expressions and therefore to support a form of ReBAC policy mining, but its running time is sensitive to the number of features and would be impractical except on small problem instances, as discussed in more detail in

[BSL19a].

A top-down approach to ABAC policy mining has also been pursued, with the goal of using natural language processing and machine learning to extract ABAC policies from natural language documents. Since this problem is extremely difficult, the focus so far has been on sub-problems, such as analyzing natural language documents to identify the sentences relevant to access control

[NTN18] and the relevant attributes [ATB18].

8 Conclusion

This paper presents a new ReBAC policy mining algorithm based on decision tree learning. Compared to the state-of-the-art ReBAC policy mining FS-SEA* [BSL19a], DTRM is simpler, significantly faster, achieves similar policy quality, and can mine policies in a richer language (with negative conditions and constraints). In our experiments with several sample policies, case study policies, and synthetic policies, DTRM is 7.9 times faster than FS-SEA* on average.

There are several directions for future work. One is to augment our algorithm with an initial phase for feature selection, such as the feature selection phase in [BSL19a], and see whether this improves the policy quality, as it did for Bui et al.’s evolutionary algorithm. Another direction is to extend the algorithm to handle incompleteness and noise in the ACLs; decision tree pruning methods, which are designed to avoid overfitting the input data, might be suitable for this.

References

  • [ATB18] Manar Alohaly, Hassan Takabi, and Eduardo Blanco.

    A deep learning approach for extracting attributes of abac policies.

    In Proc. 23rd ACM on Symposium on Access Control Models and Technologies (SACMAT), pages 137–148. ACM, 2018.
  • [BDLJ15] Jasper Bogaerts, Maarten Decat, Bert Lagaisse, and Wouter Joosen. Entity-based access control: supporting more expressive access control policies. In Proceedings of the 31st Annual Computer Security Applications Conference (ACSAC 2015), pages 291–300. ACM, 2015.
  • [BFOS84] Leo Breiman, Jerome Friedman, Richard A. Olshen, and Charles J. Stone. Classification and Regression Trees. Wadsworth, 1984.
  • [BM13] Matthias Beckerle and Leonardo A. Martucci. Formal definitions for usable access control rule sets—From goals to metrics. In Proceedings of the Ninth Symposium on Usable Privacy and Security (SOUPS), pages 2:1–2:11. ACM, 2013.
  • [BSL17] Thang Bui, Scott D. Stoller, and Jiajie Li. Mining relationship-based access control policies. In Proc. 22nd ACM Symposium on Access Control Models and Technologies (SACMAT), 2017.
  • [BSL18] Thang Bui, Scott D. Stoller, and Jiajie Li. Mining relationship-based access control policies from incomplete and noisy data. In Proceedings of the 11th International Symposium on Foundations & Practice of Security (FPS 2018), volume 11358 of Lecture Notes in Computer Science. Springer-Verlag, 2018.
  • [BSL19a] Thang Bui, Scott D. Stoller, and Hieu Le. Efficient and extensible policy mining for relationship-based access control. In Proceedings of the 24th ACM Symposium on Access Control Models and Technologies (SACMAT 2019), pages 161–172. ACM, 2019.
  • [BSL19b] Thang Bui, Scott D. Stoller, and Jiajie Li. Greedy and evolutionary algorithms for mining relationship-based access control policies. Computers & Security, 80:317–333, jan 2019. Also available at http://arxiv.org/abs/1708.04749. An earlier version appeared as a short paper in ACM SACMAT 2017.
  • [CCWB19] Carlos Cotrini, Luca Corinzia, Tilo Weghorn, and David Basin. The next 700 policy miners: A universal method for building policy miners. Computing Research Repository (CoRR), abs/1908.05994, August 2019. http://arxiv.org/abs//1908.05994.
  • [CFP09] Barbara Carminati, Elena Ferrari, and Andrea Perego. Enforcing access control in Web-based social networks. ACM Transactions on Information and System Security, 13(1):1–38, 2009.
  • [CPS12] Yuan Cheng, Jaehong Park, and Ravi S. Sandhu. A user-to-user relationship-based access control model for online social networks. In Proc. 26th Annual IFIP WG 11.3 Conference on Data and Applications Security and Privacy (DBSec), volume 7371 of Lecture Notes in Computer Science, pages 8–24. Springer, 2012.
  • [CWB18] Carlos Cotrini, Thilo Weghorn, and David Basin. Mining ABAC rules from sparse logs. In Proc. 3rd IEEE European Symposium on Security and Privacy (EuroS&P), pages 2141–2148, 2018.
  • [DBLJ14a] Maarten Decat, Jasper Bogaerts, Bert Lagaisse, and Wouter Joosen. The e-document case study: functional analysis and access control requirements. CW Reports CW654, Department of Computer Science, KU Leuven, February 2014.
  • [DBLJ14b] Maarten Decat, Jasper Bogaerts, Bert Lagaisse, and Wouter Joosen. The e-document case study: functional analysis and access control requirements. CW Reports CW654, Department of Computer Science, KU Leuven, February 2014.
  • [DBLJ14c] Maarten Decat, Jasper Bogaerts, Bert Lagaisse, and Wouter Joosen. The workforce management case study: functional analysis and access control requirements. CW Reports CW655, Department of Computer Science, KU Leuven, February 2014.
  • [Dec19] July 2019. https://scikit-learn.org/stable/modules/tree.html.
  • [DMA18] Saptarshi Das, Barsha Mitra, Vijayalakshmi Atluri, Jaideep Vaidya, and Shamik Sural. Policy Engineering in RBAC and ABAC, volume 11170 of Lecture Notes in Computer Science, pages 24–54. Shaker Verlag, 2018.
  • [Fon11] Philip W. L. Fong. Relationship-based access control: protection model and policy language. In Proc. First ACM Conference on Data and Application Security and Privacy (CODASPY), pages 191–202. ACM, 2011.
  • [HAJ13] Hongxin Hu, Gail-Joon Ahn, and Jan Jorgensen. Multiparty access control for online social networks: model and mechanisms. IEEE Transactions on Knowledge and Data Engineering, 25(7):1614–1627, 2013.
  • [IM18] Padmavathi Iyer and Amirreza Masoumzadeh. Mining positive and negative attribute-based access control policy rules. In Proc. 23rd ACM on Symposium on Access Control Models and Technologies (SACMAT), pages 161–172. ACM, 2018.
  • [IM19] Padmavathi Iyer and Amirreza Masoumzadeh. Generalized mining of relationship-based access control policies in evolving systems. In Proc. 24th ACM on Symposium on Access Control Models and Technologies (SACMAT), pages 135–140. ACM, 2019.
  • [LCHX08] Alex X. Liu, Fei Chen, JeeHyun Hwang, and Tao Xie. Xengine: a fast and scalable XACML policy evaluation engine. In Proceedings of the 2008 ACM SIGMETRICS International Conference on Measurement and Modeling of Computer Systems (SIGMETRICS 2008), pages 265–276. ACM, 2008.
  • [MBCF15] Eric Medvet, Alberto Bartoli, Barbara Carminati, and Elena Ferrari. Evolutionary inference of attribute-based access control policies. In Proceedings of the 8th International Conference on Evolutionary Multi-Criterion Optimization (EMO): Part I, volume 9018 of Lecture Notes in Computer Science, pages 351–365. Springer, 2015.
  • [MCL10] Ian Molloy, Hong Chen, Tiancheng Li, Qihua Wang, Ninghui Li, Elisa Bertino, Seraphin B. Calo, and Jorge Lobo. Mining roles with multiple objectives. ACM Trans. Inf. Syst. Secur., 13(4):36:1–36:35, 2010.
  • [MSVA16] Barsha Mitra, Shamik Sural, Jaideep Vaidya, and Vijayalakshmi Atluri. A survey of role mining. ACM Computing Surveys, 48(4):50:1–50:37, 2016.
  • [MTL15] Decebal C. Mocanu, Faith Turkmen, and Antonio Liotta. Towards abac policy mining from logs with deep learning. In Proc. 18th International Information Society Multiconference (IS 2015), Intelligent Systems, Ljubljana, Slovenia, October 2015. Institut Jozef Stefan.
  • [NDS19] Ronit Nath, Saptarshi Das, Shamik Sural, Jaideep Vaidya, and Vijay Atluri. Poltree: A data structure for making efficient access decisions in ABAC. In Proceedings of the 24th ACM Symposium on Access Control Models and Technologies (SACMAT 2019), pages 25–35. ACM, 2019.
  • [NTN18] Masoud Narouei, Hassan Takabi, and Rodney Nielsen. Automatic extraction of access control policies from natural language documents. IEEE Transactions on Dependable and Secure Computing, 2018.
  • [SSS19] Software from Scott Stoller’s Research Group, 2019. https://www.cs.stonybrook.edu/~stoller/software/.
  • [XS14] Zhongyuan Xu and Scott D. Stoller. Mining attribute-based access control policies from logs. In Proc. 28th Annual IFIP WG 11.3 Working Conference on Data and Applications Security and Privacy (DBSec), pages 276–291. Springer, 2014. Extended version available at http://arxiv.org/abs/1403.5715.
  • [XS15a] Zhongyuan Xu and Scott D. Stoller. Mining attribute-based access control policies. IEEE Transactions on Dependable and Secure Computing, 12(5):533–545, Sep.–Oct. 2015.
  • [XS15b] Zhongyuan Xu and Scott D. Stoller. Mining attribute-based access control policies. IEEE Transactions on Dependable and Secure Computing, 12(5):533–545, September–October 2015.