Most of us have come across the terms MAC, DAC, RBAC, ACLs while reading various e-security related articles. However, not all of us (except the CISSPsJ) know the meanings of these terms and the differences between these Access Control mechanisms.
But before proceeding to Access Control mechanisms, let’s see what Access Control is all about?
Access Control is a set of controls to restrict access to certain resources. So if we think about it, access controls are everywhere around us. A door to your room, the guards allowing you to enter the office building on seeing your access card, swiping your card and scanning your fingers on the biometric system, a queue for food at the canteen or entering your credentials to access FB, all are examples of various types of access control. Here, we focus only on the logical Access Control mechanisms.
Access Control Mechanisms
Discretionary Access Control (DAC)
As the name suggests, this access control model is based on a user’s discretion, i.e. the owner of the resource can give access rights on that resource to other users based at his discretion. Access Control Lists (ACLs) are a typical example of DAC. Specifying the “rwx” permissions on a UNIX file owned by you is another example of DAC. Most of the operating systems including windows, flavours of UNIX are based on DAC Model.
Mandatory Access Control (MAC)
In this Model, users/owners do not enjoy the privilege of deciding who can access their files. Here, the operating system is the decision maker overriding the user’s wishes. In this model every Subject (users) and Object (resources) are classified and assigned with a security label. The security labels of the subject and the object along with the security policy determine if the subject can access the object. The rules for how subjects access objects are made by the security officer, configured by the administrator, enforced by the operating system, and supported by security technologies.
This is a stricter and rather static Access Control model as compared to DAC and is mostly suited for military organizations where data classification and confidentiality are of prime importance. Special types of the Unix operating systems are based on MAC model.
Role Based Access Control (RBAC)
RBAC is the buzzword across enterprises today. In this model, the access to a resource is governed based on the role that the subject holds within an organization. RBAC is also known as non-discretionary access control because the user inherits privileges that are tied to his role. The user does not have a control over the role that he will be assigned.
Each of the above Access Models has its own advantages and disadvantages. The selection of the appropriate Access Model by an organization should be done by considering various factors such as type of business, no of users, organization’s security policy, etc.
Case for RBAC
For implementing any access control, the two driving factors are:
- Least privilege principle i.e, the user should only have the minimum privileges to perform the tasks that he is supposed to do.
- Segregation of duties, i.e. having more than one user to perform a critical task so as to reduce the risk of internal frauds.
As the no of users and the resources grow in an organization, it becomes extremely difficult to manage user’s access rights through ACLs. It not only increases the cost of administration but also results in granting excess privileges to users, which in turn, violates the least privilege principle and hence exposes the organization to risks. Moreover, the complexity involved with this approach makes it too hard for any organization to comply with regulatory compliances.
So, in organizations where the number of users and the employee turnover is large, RBAC is the optimum solution for Access Control. By having privileges tied to roles, and users being assigned to these roles, makes it much simpler for an organization to manage the access to its resources. RBAC also fastens the employee on-boarding & de-boarding process by tying the provisioning/de-provisioning to the roles.
Moreover, RBAC also makes the implementation of least privilege principle and SOD easier, hence, helping the organizations to comply with the strict regulatory standards.
At the heart of RBAC, lies Roles. But what if an organization decides to implement RBAC but the roles are vaguely defined? Or, if the privileges being assigned to Roles aren’t properly considered? The whole purpose of adopting RBAC stands defeated in this case.
This is where Role Engineering comes into play. I thought before heading to role engineering it’s important that the reader is aware of a few basic concepts related to access control.