5 steps to simple role-based access control

Not every employee needs a starring role!

new job roles
Credit: Thinkstock

Despite all of the advanced attack scenarios we face in the world of cybersecurity today, it seems like we continue to shoot ourselves in the proverbial feet with the simple things.

Case in point -- a study released this week by the Cloud Security Alliance indicating that almost a quarter of breaches reported by companies surveyed involved compromised credentials. Even more astounding was the fact 65% of the respondents indicated that their likelihood of a future breach due to stolen login information was medium or high. We clearly understand that we have a problem, but have little confidence that we can address it well.

Why do we find something as seemingly simple as access control to be such a challenge? Perhaps it is because it only seems simple. As an example, consider a company with just 20 employees and 5 systems. Let's also assume that for each system, a given user might need to use it read only, for read/writes, have administrative access, or no access at all. The number of possible permutations of access settings in such a small environment is huge.

Add to the problem the fact that in a typical smaller company, management of access rights is casual at best, even "one size fits all" in some cases. It seems that this simple problem is not so simple at all. Yet, if we can't get this right, our chance of having even reasonably secure systems is pretty small.

The solution to this problem is not new. Its roots actually date back to the 1970s, long before information security was on anyone’s radar.The approach is called role-based access control (RBAC). According to a National Institute of Standards and Technology (NIST) document, the first formal model for role-based access control was proposed in 1992. Thus, we have been sitting on a strong approach to this problem for many years.

So, what is RBAC? It is nothing more than the idea of assigning system access to users based on their role in an organization. The system needs of a given workforce are analyzed, with users grouped into roles based on common job responsibilities and system access needs. Then, access is assigned to each person based strictly on their role assignment. With tight adherence to access requirements established for each role, access management becomes much easier.

The question therefore is why, with an achievable and time-honored approach, we can’t seem to get a handle on access control. We are certainly being pushed in that direction of RBAC, with all of the major standards, including PCI DSS, HIPAA and Gramm-Leach-Bliley all requiring some form of it.

I would suggest that one reason RBAC is not used more frequently is that for small to medium companies, it seems easier to just do this on an ad-hoc basis as each employee joins the company. The challenge is that with as many permutations as can exist with just a few systems involved, the approach becomes unsustainable.

With the proper implementation of RBAC, the assignment of access rights becomes systematic and repeatable, once these controls are setup. Further, it is much easier to audit user rights, and to correct any issues identified.

Hopefully I have convinced you to take a closer look at RBAC. If so, consider the following simplified five step approach to getting it implemented: 

Inventory your systems

Figure out what resources you have for which you need to control access, if you don't already have them listed. Examples would include an email system, customer database, contact management system, major folders on a file server, etc. 

Analyze your workforce, and create roles

You need to group your workforce members into roles with common access needs.  Avoid the temptation to have too many roles defined. Keep them as simple and stratified as possible.

For example, you might have a basic user role, which includes the access any employee would need, such as email and the Intranet site. Another role might be a customer service rep, that would have read/write access to the customer database, and a customer database administrator, that would have full control of the customer database. 

Assign people to roles

Now that you have a list of roles and their access rights, figure out which role(s) each employee belongs in, and set their access accordingly. 

Never make one-off changes

Resist any temptation to make a one-off change for an employee with unusual needs. If you begin doing this, your RBAC system will quickly begin to unravel. Change the roles as required, or add new ones when really necessary. 


Periodically review your roles, the employees assigned to them, and the access permitted for each. If you discover, for example, that a role has unnecessary access to a particular system, change the role and adjust the access level for all employees in that role. 

There are tools that can help with setting up RBAC. Many systems, such as Microsoft Active Directory, have built in roles that you can use as a starting point, which you can extend to fit your unique situation. You can also use an identity management system, like Okta, to automate the assignment of privileges based on role. 

Bottom line -- RBAC may sound intimidating, but it can in reality be easy to implement, and will make the ongoing management of access rights much easier and more secure.

The data breach you prevent may be your own.

This article is published as part of the IDG Contributor Network. Want to Join?

The march toward exascale computers
View Comments
Join the discussion
Be the first to comment on this article. Our Commenting Policies