Realizing Information Flow Control in ABAC Mining

Abstract

Attribute-Based Access Control (ABAC) is an emerging access control model. It is increasingly gaining popularity, mainly because of its flexible and fine-grained access control. As a result, many Role-Based Access Control (RBAC) systems are migrating to ABAC. In such migrations, ABAC mining is used to create ABAC policies from existing RBAC policies. Although ABAC has several advantages, it lacks one of the crucial features required for reliable security, which is information flow control. Due to the complex nature of ABAC policies, it is challenging to analyze the information flows caused by them. In this paper, we address this problem and present an approach for realizing effective information flow control in ABAC systems. With this approach, we can create flow-secure ABAC policies using exiting RBAC policies and associated attributes. With such a flow-secure policy, we can ensure that there are no unintended information flows in the system.

1 Introduction

Access control is one of the key aspects of a secure system. Over the years numerous access models have been proposed. Among them, Discretionary Access Control (DAC), Mandatory Access Control (MAC), and Role-based Access Control (RBAC) are prominent and have been widely used. However, they are proving to be inadequate for the security requirements of the current day systems which require highly dynamic and flexible access control. ABAC addresses this problem by providing authorization based on attributes. Unlike the traditional models, ABAC is not an identity-based model. Instead, it uses attributes of the entities, and the environment and specifies access rules in terms of these attributes. The attributes are nothing but key, value pairs that represent the characteristics or status of the entities or their environment. The access rules can be specified using logical formulas or through enumeration [1]. With the use of attributes, ABAC enables specifying precise access rules.

Although ABAC has several advantages as discussed above, it lacks in one important feature necessary for reliable secure, that is Information Flow Control (IFC). IFC is essential to ensure that there are no information leaks in the system and all the accesses are as per the intended security requirements. This would require analysing the information flows allowed by the access policy. However, in the case of ABAC, the policies are generally large and complex. Moreover, they are specified in terms of the attribute values and not the identities. There can be several attributes with large number of possible values. This makes analysing an ABAC policy highly complex. In this paper, we address this problem in an elegant way. Instead of analysing the policy after its creation, we propose a method to ensure flow-security at the policy creation stage and eliminate the need for complex policy analysis.

Specifically, we consider the policy creation in RBAC to ABAC migration where an RBAC policy and associated attribute values are used to generate an equivalent ABAC policy. In the proposed solution, we first analyse the given RBAC policy and make it flow-secure. We then use this flow-secure policy as input for an ABAC mining procedure that generates an equivalent flow-secure ABAC policy.

The rest of the paper is organized as follows: Sect. 2 describes the need for IFC in ABAC. Section 3 discusses the challenges in achieving IFC in ABAC and Sect. 4 presents our approach which can effectively help in creating flow-secure ABAC policies. Section 5 reviews some of the major related works. Finally, Sect. 6 concludes the paper.

2 Motivation

ABAC has several features that make it suitable for most contemporary systems. However, it doesn’t focus on IFC which is one of the important security requirements considered essential for reliable security. We demonstrate this with a simple example. Consider a system with two users u1, u2 and two objects o1, o2. Users have an user attribute uatt1 and objects have two attributes oatt1, oatt2. Attribute values of the users and objects are listed in Tables 1 and 2 respectively. ABAC policy defined in terms of these attributes is shown in Fig. 1.

Table 1. User attributes

Table 2. Object attributes

With the permissions available through the given policy, u1 can read from o1 and write to o2 and u2 can read from o2. The information flows caused by these actions are shown in Fig. 2. From the figure, we can observe that when these accesses are performed, u2 can indirectly read the contents of o1. This access is not allowed by the policy and hence it is an unauthorized access. Such accesses cause information leaks and pose threat to the system. Therefore they need to be identified and analysed and if they indeed have potential to cause security threat, they need to be eliminated.

In the next section we discuss the challenges involved in information flow analysis of ABAC policies.

3 Information Flow Analysis in ABAC

With attributes-based rules, ABAC policies support flexible and fine-grained access control. However, these benefits come at the cost of complexity and lack of support for auditing. One of the common audit requirement is to know what permissions each user has before the requests are made. This is known as “before the fact audit” [6]. It helps in risk analysis and when an attack manages to compromise a user, auditing/reviewing helps in understanding the scope of the attack and the extent of its damage. It is also necessary to demonstrate compliance to specific regulations or directives. ABAC policies are not well-suited for conducting these audits efficiently. This is mainly because, in ABAC, access rules are not based on the identities of the entities. As a result, determining the set of permissions associated with a user would require enumeration of all the access rules, leading to a significant data retrieval and computation effort. This limitation also affects the information flow analysis capability. Unlike in RBAC, where we can analyse a given policy for information flows and identify indirect flows, policy analysis in ABAC is challenging. Because, such analysis would involve, considering all the attributes (which are usually in large number), each with large number of possible values.

Fig. 1.

ABAC policy

Fig. 2.

Indirect information flow

One possible way to achieve IFC in ABAC is to incorporate the flow-security at policy creation time. The process of policy construction is called as policy engineering. In the case of ABAC, policy engineering methods can be grouped into two classes, Top-down and Bottom-up. In the top-down approach, the organization’s processes are broken down into tasks and permissions required for each of the tasks are used to derive policy rules. In the Bottom-up approach, also known as policy mining, the existing accesses are used to create policy rules. The existing accesses may be obtained through logs or through existing policies of other models. Policy engineering is the costliest aspect in ABAC implementation. ABAC mining tries to reduce this cost by partially automating the process. As a result, it is usually the preferred method for policy creation. In the next section, we discuss the limitations of ABAC mining with respect to information flow control and how we can address this problem.

4 Flow-Secure ABAC Mining

As mentioned, ABAC policy creation is a costly procedure. ABAC policy mining is used to reduce the cost of policy development by using existing policy to automate the creation of an equivalent ABAC policy. Owing to the fine-granularity and flexibility of ABAC, many existing RBAC systems are migrating to ABAC [16]. In such migrations, policy mining involves using the existing RBAC policy along with the associated attributes to generate an equivalent ABAC policy. The RBAC policy and ABAC mining are formally defined as follows [21]:

Definition 1 (RBAC Policy)

An RBAC policy is a tuple $\langle U, O, R, Op, PERM, UA, PA, RH\rangle$ where U is a set of users, O is a set of objects (resources), R is a set of roles, Op is a set of operations, $PERM \subseteq O \times Op$ is a set of permissions, $UA \subseteq U \times R$ is a user-role assignment relation, $PA \subseteq PERM \times R$ is a permission-role assignment relation, and $RH \subseteq R \times R$ represents role hierarchy.

Definition 2 (ABAC Policy Mining)

The ABAC policy mining problem is defined as, given an RBAC policy $\pi _0 = \langle U, O, R, Op, PERM, UA, PA, RH \rangle$, user attributes UAT, object attributes OAT, user attribute data du, object attribute data do, find a set of rules Rules such that the ABAC policy $\pi = \langle U, O, Op, UAT, OAT, du, do, Rules \rangle$ is consistent with $\pi _0$.

In this paper, we present an approach to generate flow-secure ABAC policy in such RBAC to ABAC migrations. We explain the method in detail with the help of a running example motivated by the example in [2]. Consider an RBAC configuration as shown in Table 3. It lists the roles, Permission Assignment (PA), and User Assignment (UA). The role hierarchy is $RH = \{(r1,r3)\}$ i.e. r1 inherits all the permissions of r3. Table 4 and Table 5 give the values of the user attribute (UAT) uat1 and object attribute (OAT) oat1 respectively. Here, the range of both of these attributes is $\{F, G\}$.

Table 3. RBAC example

Table 4. UAT value

Table 5. OAT value

Note that the RBAC configuration in Table 3 has a transitive flows from o1 to r3 (when r1 or r4 reads o1, writes it to o3 and then r3 reads o3). If this policy is used as-is for generating ABAC policy, then the resulting policy will also have the transitive flow, making the policy vulnerable to information leaks. To achieve flow-security in ABAC, we need to use flow-secure RBAC policies in ABAC mining. In the proposed method, given an RBAC policy and attribute values, we first identify all the information flows of the RBAC policy and then using this, the RBAC policy is converted into flow-secure policy. Finally, this flow-secure policy is used in ABAC mining to create an ABAC policy that is equivalent to the RBAC policy, thus creating a flow-secure ABAC policy. We describe this procedure in detail as follows:

Step 1: Identifying All the Information Flows: This is done by using the analysis method of [14] that uses an information flow model called Readers-Writers Flow Model (RWFM) [8]. In this model. The entities are assigned RWFM labels and then RWFM checks are applied on each access rule. The two main steps of the method are explained below:

• 1. Labeling Objects and Roles: The RWFM label of an entity is of the form (R, W), where R corresponds to readers and represents the set of roles that can read the entity and W corresponds to writers and represents the set of roles that can write or influence the entity.

  In the case of objects, finding the sets of roles that read and write an object is straightforward. The readers set of an object o is obtained from the set of RBAC read rules that include o and writers of o can be obtained from the write rules corresponding to o. Table 6 gives the labels of all the objects in the above example (computed using PA and RH).

  Table 6. Labels of objects

  Table 7. Labels of roles

  To label the roles, we need to use the labels of the objects. By using the labels of the objects, the readers and writers of a role r are computed such that its readers set is a subset of readers of all the objects it can read and its writers set is a subset of writers of all the objects it can write. To do this, we first initialize the readers and writers sets of a role with the universal set of roles R. For each object o, which is readable by r, we update the R(r) as $R(r) \cap R(o)$. Similarly, when a role r is in the writer set of an object o, we update W(r) as $W(r) \cap W(o)$. The procedure for labelling roles is given in Algorithm 1. Table 7 gives the labels of all the roles in the example. Label derivation for role r1 is given below.

  $R(r1) = \{r1,r2,r3,r4\}$ (Initialization) $R(r1) = R(r1) \cap R(o1) \cap R(o3)$ ($r1 \in R(o1) \wedge r1 \in R(o3) )$ $R(r1) = \{r1,r2,r3,r4\} \cap \{r1,r4\} \cap \{r1,r3,r4\}$ $R(r1) = \mathbf {\{r1,r4\}}$

  ${W}(r1) = \{r1,r2,r3,r4\}$ (Initialization) ${W}(r1) = W(r1) \cap W(o1)$ ($r1 \in W(o1)$) ${W}(r1) = \{r1,r2,r3,r4\} \cap \{r1,r4\}$ ${W}(r1) = \mathbf {\{r1,r4\}}$

  

• 2. Applying RWFM Checks: Once the labels of objects and roles are computed, the following checks are applied on each of the RBAC policy rules of the form r o op (where r $\in R, o \in O, \; and \; op \in Op$).

  • 1. If $op = read$ check if $W(o) \subseteq W(r)$.

  • 2. If $op = write$ check if $R(r) \supseteq R(o)$.

  Any RBAC rule that doesn’t satisfy these checks indicates the presence of indirect (transitive) flows i.e. if the condition $W(o) \subseteq W(r)$ fails (in check (a)), then all the roles in $W(o) - W(r)$ can indirectly write to all the objects that r can write. Similarly, if $R(r) \supseteq R(o)$ (in check (b)) fails, then all the roles in $R(o) - R(r)$ can read everything that r can read. We construct RBAC rules corresponding to these indirect accesses and the rule which failed to satisfy the above checks becomes the cause for these indirect accesses. The procedure to apply RWFM checks is given in Algorithm 2. On applying this algorithm on the example policy, the checks fail at (r1, (o3, write)) and (r4, (o3, write)). Both of them cause the indirect flow from o1 to r3.

  Once all such indirect flows are identified, the rules corresponding to the indirect accesses are added into the rule set and the process (labelling and applying the RWFM checks) is repeated until no new rules are generated. This generates the transitive closure that includes all the multi-level indirections. The procedure is given in Algorithm 3. In the case of our example, there are no multi-level indirection. Therefore, the analysis stops after one iteration.

Step 2: Creating a Flow-secure Policy: From the previous step, we can not only identify all the indirect flows, but can also identify the rules causing those indirections. With these details, we can create a flow-secure RBAC policy by applying one of the following measures for each of the indirections:

• Ignore: Generally, not all the indirect flows are a security concern. Certain indirect flows can be ignored and can be allowed to be part of the policy, if the policy writer decides that the flow is not a security threat. One possible reason for such decision could be due to the fact that some roles are trusted and are believed not likely to cause indirections.

• Remove: A straightforward measure is to remove the indirections. This is done by deleting at least one rule from the path that leads to a particular indirection. Note that deleting rules from the policy may affect the functionality of roles. This has to be considered while removing the rules.

• Add: In the case of some indirections, the corresponding rules can be explicitly added to the policy. This can be done if the policy writers considers the indirect access to be safe and necessary for functioning of certain roles.

Using the above measures, we can convert a given policy into a flow-secure version where there are no unintended flows. In the case of our example policy, suppose the the role r1 is more trusted and can be relied on not to write the contents of o1 to o3. Then we can ignore the indirect flow through r1. Whereas the indirection caused through the regular role r4 needs to be removed. After removal of (r4, (o3, write)), permissions of users will be as shown in Table 8. With this, no access in the policy causes an unintended flow.

Table 8. User permissions

Table 9. Partitions

Step 3: Generating Equivalent ABAC Policy: Once we have a flow-secure RBAC policy, we can use it to generate an equivalent ABAC policy. We do this by creating conflict-free partitions [2]. The detailed procedure is explained below:

• Create Partitions: The first step is to divide the set $U \times O$ into a partition set $P=\{P_1, P_2, ..., P_n\}$ such that all the attribute values of every tuple in a partition are same. In the case of our example, four such partitions are created. The partitions and the corresponding attribute values are shown in Table 9.

• Make Partitions Conflict-free: A partition is said to be conflict-free if every tuple in the partition has same set of permissions as per the RBAC policy. Such partitions can be uniquely identified by their attributes and this can be used to create ABAC rules. Notice that among the partitions in Table 9, P3 and P4 are conflict-free, because all their tuples have same permissions. As a result, the partitions’ attributes are sufficient to uniquely identify them and can specify the ABAC rules as shown in Fig. 3. On the other hand, the partitions P1 and P2 are not conflict-free. In the case of P1, users u1 and u2 can read o1 but u3 cannot. Such partitions need to be further split into smaller partitions where all the tuples have same authorizations. i.e. a partition $P_i$ is split into $\{S_1, S_2,...,S_m\}$ such that each resulting partition is conflict-free. This is done by first splitting the set of users $U_i$ and set of objects $O_i$ of partition $P_i$. $U_i$ is split into $\{U_{i1}, U_{i2},..., U_{ik}\}$ such that all the users in any $U_{ij}$ has same authorization with respect to all the objects. Similarly, $O_i$ is split into $\{O_{i1}, O_{i2}..., O_{il}\}$ such that all the objects in any $O_{ij}$ can be accessed in the same way by all the users. Then conflict-free partitions are created as $\{U_{i1}, U_{i2}..., U_{ik}\}$ $\times$ $\{O_{i1}, O_{i2}..., O_{il}\}$. Note that such partitions cannot be uniquely identified by their input attribute values alone. Therefore, we add new attributes so that these partitions can be uniquely identified and can be used to specify access rules.

  From Table 8, we can see that all three users of partitions P1 and P2 have different set of permissions and the two objects in P1 have different set of readers and writers. As a result, users and objects in both partitions P1 and P2 are split into $\{u1\}\{u2\}\{u3\}$ and the objects set of P1 is split into $\{o1\}\{o2\}$. Consequently, each element in these partitions form a separate conflict-free partition.

• Assigning New Attributes: In this step, we add a new user attribute urole and a new object attribute orwfm. Value of urole attribute of a user specifies the set of roles that can be assigned to the user as per the RBAC configuration. Value of orwfm attribute of an object corresponds to its RWFM label. The attribute values of the users is shown in Table 10 and the new object attribute values are as per Table 6 (except for o3, whose writers set is updated to $\{r1\}$).

• Generate Rules: All the conflict-free partitions created in the previous steps can be uniquely identified by the combination of the input attributes and the newly added attributes. Using them we can create ABAC rules. After creating such rules for partitions P1 and P2 and adding them to Policy 1, we get the complete policy as shown in Fig. 4. The rules generated this way do not contain any unintended flows, thus making the system flow-secure.

Fig. 3.

ABAC policy for partitions P3 and P4

Table 10. User role attribute

Fig. 4.

ABAC policy

With the above method, we eliminate the need for flow analysis of an ABAC policy to ensure its flow security. The method uses the simple and elegant approach of using a flow-secure policy as input for ABAC mining. Though we have used mining based on conflict-free partitions, it is possible to use any other mining solution as long as the resultant ABAC policy is equivalent to the RBAC policy.

5 Related Works

Over the years, several ABAC models have been proposed [19, 22], each aiming to provide flexible and fine-grained access control. However, since ABAC is relatively new model, there has been less work on information flow control. Jin et al. [7] presented a unified ABAC model called $ABAC_\alpha$. It provides a formal model that can cover the traditional models – DAC, MAC, and RBAC. Here the model can use MAC labels as attributes and apply the MAC rules based on these attributes. However, the labels have to be assigned statically which makes the model restrictive. Our method provides more flexibility by using the RWFM model.

In the case of RBAC, relatively more work has been done regarding IFC. Nyanchama and Osborn [10] provided general rules for RBAC to MAC simulation. Sandhu [15] and Osborn et al. [13] presented a method to emulate lattice-based access control using two role hierarchies. Nyanchama and Osborn [11] presented a role-graph model that can address the conflict of interest with respect to information flows. This model is useful in understanding the information flows in RBAC systems. Osborn [12] and Gofman et al. [5], also focus on information flow control in RBAC. They generate information flow graphs using different techniques. The graphs show information flows at different granularities and aim to answer flow-related queries. Tuval and Gudes [17] attempt to analyze the information flows in a given RBAC configuration and try to resolve information flow conflicts by creating canonical groups. These flow-graph-based solutions work for only smaller systems with a few roles and objects. As the number of roles and objects increase, the analysis becomes complex and cumbersome. The method used in this paper is scalable and more effective in analysing the indirect flows and extracting related details.

ABAC Mining is recently being explored widely by researchers. Vaidya et al. [18] and Das et al. [3] use migration based approach which enables an organization to use an existing policy from another organization having similar attributes and their values. The method in [3] enables an organization using a traditional access control model to adapt to the existing ABAC policy of a similar organization by an optimal assignment of subject attribute values in the presence of attribute hierarchy and environmental conditions. Gautam et al. [4] use a constrained mining approach for policy engineering. Xu and Stoller [20] use a log based approach whereas Mocanu et al. [9] use both log and deep learning. The method in our approach uses an existing RBAC policy and associated attributes as input. The method is simple and effective.

6 Conclusions

ABAC is an emerging access control model. Although it has several advantages such as fine-granularity and flexibility, it lacks support for information flow analysis. In this paper we have proposed an approach that can create flow-secure ABAC policies by using existing RBAC policies. This eliminates the need for flow analysis of ABAC policy. Thus our method provides an elegant solution to realize information flow control in ABAC systems thereby making them more reliable.