Archive

Archive for the ‘Access control Concepts’ Category

Understanding Permissions in NIST RBAC

NIST RBAC[1] defines  permission in a particular way which is very tricky but very interesting. If OBS is set of objects, and OPS is the set of operation, then NIST defines permission set (PRMS) as  PRMS = 2^(OPS X OBS). For example, if we have OPS={read, write} and OBS = {o1,o2}, then there are 2^(2×2) = 16 permission. Insane! right?

Lets see all the possible permissions:

p0 = {}

p1 = {read o1}

p2 = {write o2}

p3={read o1 and  write o2}.

p5…. p15.

 

 

 

Initially it seems if we have p1, p2, then we don’t need to define p3. Just combining p1 and p2 makes p3. But interestingly this is not the case. Let me explain why.

 

 

For example, consider, a bank teller cannot just deposit money (permission p1) in a bank account or withdraw money from a bank account (permission p2). But he can transfer money (permission p3)  from one account to another which is combination of both p1 and p2 permission. We can think of transferring money as two permission of withdrawing money from one account(p2) and deposit to another account(p1). But while doing transferring, the teller cannot exercise permission p2 and p1 as he wishes. If the teller were given both permission p1 and p2 instead of p3, he could exercise p1 as many times he likes and p2 as many times as he likes. Thus exercise of permission p1 and p2 cannot be regulated as we do in transferring money between account.

 

NIST solves this problem  by combining these permissions by the notion of PRMS = 2^(OPS X OBS). In this notion having permission p3 = (p1 and p2) is different than having both permission p1 and p2.

 

Now, lets see what happens

A Taxonomy of Enterprise Protected Objects

Protected objects in an enterprise varies a lot. Examples include databases, customer records, manufacturing plans, secret business formulas, employee records, so on. The protection requirements for these datas also vary greatly. Some data have more confidentiality requirements (eg. secret business formulas), some have strict integrity requirements (e.g. employee payroll database), while some data need both high integrity and confidentiality requirements. On the other hand, some resources in the enterprise need high availability requirements (e.g. virtual machine hosting web server, DB server).  Characterizing the enterprise data (I am excluding resources like cloud VM, IoT resources/data) with respect to business values and  protection requirement is important to give insight to the administrators and   security personnels (CISO). and this is the objective of this post.

Following is one taxonomy of protected enterprise objects. Note that the taxonomy is not complete and just one way of classifying enterprise objects.

Different types of enterprise protected objects

Workflow or Business Objects:

  •  Identifies and models business process into multiple tasks, subtasks (e.g. purchase order).
  •  Usually regulated by the enterprise itself.
  •  Often related with job functions.
  •  Operations  on Workflow or Business Objects are often related with operations on other Workflow or business Objects (eg. issue purchase order, pay for purchase order etc.)

Operational  Objects:

  • Workflow or Business Objects depends on one or more Operational or Transactional Objects . For example, a purchase order is implemented by one or more entry in one or more database tables. Examples of Operational or Transactional Objects includes database tables or documents associated with workflow operations.
  •  Operations on Operational or Transactional Objects need to be regulated for integrity requirement than confidentiality requirements.

Strategic  Objects:

  • Strategic Objects includes data related with the strategic planning of an organization. Example of Strategic Objects are document related with marketing plan, product announcement etc.
  •   Both confidentiality and integrity requirements are high priority for Strategic Objects

Large Scale  Objects:

  • Analytic or record Object is readonly data generated by different activities in the enterprise. Analytic or record Object are used to derive insight or extract knowledge from ongoing business activities. Examples include customer records, purchase records etc.
  •   Analytic or record Object is often regulated by external standards.
  •   Numerous in numbers.
  •   Due to its large volume, Analytic or record Object can be stored in on site or o premises. This data has to be regulated consistently despite of its diverse location or storing policies. For example, purchase records can be stored in premise magnetic tapes as well as o premise cloud providers. Same regulations have to be applied uniformly on all these instances.

Following tables shows security concern for different types of permission associated with different types of enterprise objects.

Security Requirements for different types of Enterprise Objects

Separation of Duty vs Least Privilege

Separation of Duty (SoD) is diving the responsibility and privilege of performing a job among more than one persons or roles. The purpose of SoD is to make it difficult to perform fraud. The observation behind SoD is that it is difficult to corrupt two person to commit a fraudulent activity. Note that SoD does not eliminate fraud, it just makes fraud more difficult and potentially reducing the occurrence  of it.

Example of SoD: In many places, it requires two different signs from two different persons on a check to approve it.

Least Privilege (LP): Least privilege requires possessing just enough privilege to perform a job.  The purpose of least privilege is that if something bad happens due to unintentional error, the loss should be minimum. As opposed to SoD, it does not limit users having all privileges for a job, rather it limits users to activate least amount of privileges for performing a particular job.

An example of least privilege is that a person can be both ‘faculty’ and ‘chair person’ of a department. When he is performing job as a faculty, he should only activate privileges required for faculty (Assuming that faculty job does not require privileges of ‘chair person’ job.  Now, if the person get infected with malware while performing faculty job, hopefully the malware could possess maximum privilege of the faculty role and not ‘chair man’ role.

Note that enforcing SoD or Least Privilege requires both human efforts and technological support. For example, which job should go through SoD is an human decision. On the other hand, once specified different critical subtasks for a job, the available security mechanism (e.g. Access control) should enforce decision made my authority.

In Role Based Access Control (RBAC) SOD or Least privilege is supported through Permission Role Assignment (PRA),  User Role Assignment (URA) and Sessions.  All of PRA, URA and Session Support is required for SoD and LP. While both PRA and URA involves support from human (more specifically RBAC administrators), Session  in RBAC is a technical instrument .

May 5, 2015.

Good read Reseach paper on Access Controls

Access Control List (ACL) when to use when Not to use

Often times, Access Control List (ACL) seems pretty obvious and seems to reduces complications. This is why some greats projects (for example, OpenStack Swift, Amazon’s S3 Storage) use ACL. But ACL is not good always – that is why most of the system does not use ACL.

In this note, we will see when using  ACL is a good choice and when avoiding ACL is wise.

Advantage of ACL / When ACL is a Good Choice:

Simplicity: ACL is very simple to visualize and straight forward to evaluate. While in Access Control System (ex. ABAC or Rule Based System)  policies of many objects are  stored altogether, it is both time-consuming and often time ambiguous which rule will fire for which request. Again, sometime, orders of the policy may complicate the situation more.

Simplicity of using ACL

having multiple policy may may create ambiguity in the evaluation for a request.

To explain, lets assume only permission here is read. For the response of the request for (o1,u1,r), the policy engine need to go through rule1, rule2 and rule 3. Then it will find that the request is valid. In the worst case, the policy engine will go through all the rules and find that the request is denied.

ACL remove ambiguity in the case of which policy should be fired from a policy set.

ACL remove ambiguity  because object is directly associated with the user list.

Using ACL, when the request comes for (o1, read, u1), the protection system only looks at the ACL associated with object o1. There is no ambiguity of using rule should be fired or whether to maintain the order in which rules are stored and so on.

I think, even though I have experimented or investigated, Usage of ACL enhances request evaluation time.

Independent Objects:

When objects are not related to each other for example, how one file is to be accessed is not dependent on external matters, ACL is good choice. In case of Swift  Object Storage or amazon S3, each object is distinct  and accessed independently.

Independent Actions:

Similar to the previous point, when action associated with objects does not affect each other, ACL can be a good choice although this is not a criteria which makes ACL suitable. This property is maintained in both Amazon’s S3 and OpenStack’s Swift Storage.

Disadvantage of ACL / When Not to use ACL:

1. Global View of the System is Lost with ACL:

The Global view / knowledge of the whole system is hard to discover in ACL based environment. For example,  to discover whether  a file/object is accessible by everyone requires to go through every object’s ACL list which is very unscalable.

2.  Global Policy / Generic Policy is tough to implement / maintain:

If a policy affects many objects or many users in the system, it is tough to implement / maintain using ACL alone. For example,  for the policy “Manager (or User Alice) should be able to access all objects (existing & new) in the system“, the system running ACL need to maintain another policy store to maintain this policy.

3. Complex to maintain Dependency in terms of User, Object and Permission:

lets consider following dependency:

dependency at user label:  if employee can access an object, manager can also able to access it.

dependency at object label: If an object is accessible, all the old versions of this object is also accessible.

dependency at permission label: having write permission on an object, also imply read permission on it.

Any kind of the above dependencies is tough  maintainable using ACL alone. Dependency at the user label can be reduced using the concept of Role with ACL, but it may lack many other user dependencies.  In fact, the system that use ACL (ex. OpenStack Swift) has no dependency at the object label and permission. Limited type of user dependency is also supported by Role in Swift.

Access Control List vs Capability List

August 21, 2014 1 comment

In Access Control List (ACL) each object has a list of (action, user-list) tuple.

table 1: Access Matrix

table 1: Access Matrix

For example, in the above diagram File1 & File2 would have following ACL:

File1: (         (read, {user1}),      (write, {user2})       )

File2: (     (read, {user1}),      (write, {})         )

On the other hand,  in  the capability list system which is a counter-part of ACL system, a user is associated with a list of (action, object-list) tuple.

For example, for user1, capability list would be :

User1: (       (read, {file1,file2}),           (write, {})          )

User2: (       (read, { }),           (write, {file1} )          )

While same access matrix can be represented in both ACL and capability list, in this note we will first understand some subtle differences of these two representation and try to  find out why ACL is better in Object Centric perspective. In order to evaluate this, we would introduce few  administrative actions that has to be carried out in a access control model.

Worth to mention that ACL and Capability List is just different representations of Raw Access Matrix and they does not denote new type of Access Control model, although over time, ACL has been evolved due to its effectiveness in system having large number of object (ex. OpenStack Swift).

Add user: A access control model should be capable to adding new user.

Remove user: A user should have to be removed when needed from the access control system.

Add object: New object or new resource may have to be added.

Remove object: An existing object could be removed from the system.

We are leaving adding and  removing permission from our discussion which is not necessary to compare between ACL and Capability list.

Now, lets see what happens when these actions are  carried out in both ACL and Capability System.

acl-vs-capability

Table 2: Administrative Action (adding/removing of user/object) vs Required Changes in ACL / Capability System

In a ACL system, when a user is being added, it may require that the newly created user gain some privileges on existing objects instantly or later. For example, we assume the worst case such that in a ACL based system, a user is added and it gets read, write action on each existing object. The situation is shown in following figure.

add user in ACL system

So, the ACL list would be changed as following:

File1: { (read,[user1, user3]), (write, [user2, user3])}

File2: { (read,[user1, user3]), (write, [user3])}

So, the point to make here is that in ACL based System, on adding / removing a user, there may be a changed required in the ACL of existing object. On the other hand, similarity, in the capability system, there may be a change required in the Capability list of existing user on addition or removal of an object. The situation is shown in Table2.

Now, from figure 2, we can speculate that if a system has fewer user centric operations (ex. add user, remove user, change in user’s privilege label) and more object centric operation (ex. add object, remove object) ACL is good for it, because in this case ACL required less change than its corresponding Capability list.

An excellent example of it is the reason why OpenStack Object Storage (Swift) uses ACL for maintain its Access Control. Swift is build for storing a large number of objects which require large number of object centric operation and less number of user centric operation.

To make ACL more powerful swift uses ACL with Role instead of ACL with user-identity. That means, while in our given example, we have used user’s identity in the ACL list, Swift uses user’s roles in its ACL. A Role based ACL is shown in following figure. Note that  here Role is used just as a way to group users.

Role based ACL used in Swift.

Role based ACL used in Swift.

Where Capability List is Good fit:

So, we understand where and when ACL is good choice. On the contrary of the previous explanation, is Capability model a good fit in the system where more user centric action is required? The answer is NO. I explain it in terms of enterprise system.

because, Capability model cannot address following issues which are very required in real system:

1. Many users in an organization get same level of privileges because of his /her position in the organization. In Capability Based system it means duplication of same capability list for many users.

2. In enterprise system, a user privilege level may change frequently (ex. user may get promoted). This is hard to manage in capability list.

3. many many others.

The point is that in the Enterprise system, there  are many other user related actions ( ex. delegation, Separation of duty, etc) which cannot be supported by Capability List.

To keep our focus on, we would not talk about User Centric Access Control models (ex. RBAC, DAC etc). Rather, now we would check some of the ACL System.