Role-based access control is fine – who needs attribute-based access control?

Reading through my past articles for CSOonline.com is like going down memory lane for me. They’ve been a series of myths based on the various challenges I hear when suggesting a particular approach to security. In some cases, these challenges are real and concrete and require a good working relationship where we find the right approach. But all too often the concerns shared with me are founded on rumors, misunderstandings or simply because we live in a culture resistant to change.  Hopefully we can learn about these myths together and clear the air on the topics discussed.

Ahh… the myths of authentication and authorization. For instance, it’s my opinion that implementing attribute-based access control (ABAC) is overkill and that role-based access control (RBAC) is fine.  To be honest, for many, this is a subtle argument that is based on the traditional approach an organization has given their out-of-date toolsets. Basically, it’s what they are used to.  The good news is this is likely the easiest myth to bust.

The key words at play here are “access control.” Now, I know this is a common concept for many of us, but let’s quickly review the basics.  There are two fundamental aspects of security, the yin and yang are authentication (AuthN) and authorization (AuthZ).  Authentication is the process you go through whenever you sign into an application or log in to your computer.  The entire purpose of authentication — including step-up authentication with multi-factor authentication (MFA) — is so that the security layer can then complete authorization.  It’s the authorization step that determines which buttons you can click, which accounts you can edit, or even if you have the ability to issue a statewide emergency alert. 

Most applications today are secured with nothing more than RBAC.  Active Directory is based on RBAC (SharePoint, SalesForce, etc… all RBAC).  So, what exactly am I complaining about?  Well it’s not the applications’ use of RBAC that is the issue but rather the method we use to assign these roles to people in the first place.  Are your administrators simply making arbitrary decisions to add someone to a role or, are those decisions made automatically based on that user’s attributes?  It’s the attribute-driven approach to role management that we need to embrace.

Imagine a new employee, Jane, has just joined the finance team.  As an HR administrator, you make a call to the security team and ask that Jane be granted access to the payroll system.  The security team places Jane in the finance-payroll AD group and viola, Jane has access to the payroll system.  Six months later, Jane is transferred to the facilities team, and as an HR administrator, you call the security team and ask them to add Jane to the facilities-admin role in AD. Now Jane has access to the facilities application… and the payroll system.  After the auditors catch this and likely other avoidable mistakes, you and your colleagues begin looking for another job and wonder what you could have done better.  Roles are like taxes, easy to dole out and rarely taken back.

Of course, you know what the problem is, this isn’t terribly complicated. The problem here is that people are being assigned roles based on manual processes and requests, not by automatic decisions driven by the user’s attributes.  I’ve seen it over and over again, with time users accumulate roles but never have outdated roles taken away.  Or a user moves into a new job and waits forever to get the access they require. Both of these problems (and more) are solved when we automate this process through identity governance.

Imagine the same scenario above.  Jane joins the company and in the HR system is placed into the Finance department.  An attribute-driven provisioning process automatically executes and moves Jane into the proper AD role.  Jane gets the access she needs instantly.  When HR transfers Jane to the facilities team, the automation sees her department attribute change and instantly removes her from the finance group and adds her to the facilities AD group.  There is no impact on the business as Jane waits for her access to change and there is no security exposure to the company with users who are over-provisioned.

This is just the tip of the security iceberg!  Here is another great example of attribute-driven access control.  Imagine functions within an application that a user can only execute if they have passed the requirements of the training system.  Fetching someone’s training status via a web API or quick connection to a database is a rudimentary process that can factor into the security decisions that your governance platform makes.  This is attribute-driven security at its finest.

So, I can imagine many folks won’t believe that I run into resistance when I talk about the benefits of attribute-based access control.  But remember, the resistance in this case doesn’t necessarily come from a misunderstanding of the technology, but rather resistance to change and the concern that doing something like this would require many years and even more dollars.  The truth is, modern identity platforms are ready to do this type of stuff out-of-the-box. 

Even if you were to encounter friction in the deployment, the benefits in business agility and security confidence are more than worth the effort.

rbac Abac Access control Access control policy More on access control: