Maturing Your IAM Program: Role-Based Access Control (RBAC)

Ross Flynn

Posted on Mar 16 / 2022

When considering your organization’s security posture, it’s easy to focus on your infrastructure, firewalls, vulnerability management program, or any other technical aspects of your team, but are you thinking about your Identity and Access Management (IAM) program?

It’s easy to think that the latest EDR or SIEM will be the answer to all your problems, but I would argue that a robust IAM program is a crucial lynchpin to securing an organization.

In this three-part series we will talk about key considerations to take into account when reviewing your IAM program: Role Based Access Controls, Segregation of Duties, and Third-Party Considerations. This article focuses on Role Based Access Control (RBAC).

What is Role Based Access Control (RBAC)?

I know, I know. Everyone wants it and nobody has it. Role Based Access Control (RBAC) has become the holy grail of access management. At its core, RBAC standardizes user access by assigning permissions to a role rather than assigning those permissions to the user individually.

RBAC can be applied to applications, allowing for access to be managed by the business owner or the application administrator, or it can be administered at the organizational level where it can manage application, network, and resource authorization.

Conceptually, it makes perfect sense why everyone would want to adopt RBAC: Access is standardized, administration is simplified, risk of overprovisioning access is mitigated, and the groundwork for future automation is laid. There’s a reason that it’s the holy grail!

Three Tips for a Strategic Approach to RBAC

So why isn't everyone using RBAC?

The challenges arise when a program that was not built on a RBAC methodology attempts to adopt standardized access. Defining new roles requires collaborative effort between business owners, application administrators, and the internal security team.

Here are a few tips to strategically approach your RBAC adoption journey.

Begin with a clearly defined goal in mind

When you’re considering adopting RBAC, communication is key to ensuring that everyone involved with the process understands their responsibilities. Depending on your scope, this could be a several months or even years long project, so defining the end goal, and the path to it, sets up stability in case of turnover, expectation clarity for everyone involved, and accountability to ensure those involved remain focused on the vision.

I recommend developing a roadmap that clearly defines achievable, measurable goals and milestones determined from the onset. Key milestones could be:

Prospective roles created
Roles reviewed with business for Segregation of Duties conflicts (SOD)
Roles approved by business and information security
Access modifications being made

Whatever your milestones may be, have them along with your end objectives clearly defined and understood by all participants in the project.

Keep 'segregation of duty' conflicts top of mind

RBAC implemented without a full Segregation of Duties review performed is not properly implemented RBAC. Since we are relying upon these sets of permissions to be the authority it’s imperative that we know which entitlements would constitute a critical combination. This is especially crucial for organizations who plan on assigning multiple roles to a user.

Developing a Segregation of Duties matrix is a good first step in identifying where critical combinations may be hiding and will be a source of truth when developing roles. If your company has an internal audit or risk team, I recommend seeking their help to confirm all bases are covered. Part Two of this series will be dedicated entirely to Segregation of Duties, so be sure to check it out.

**Work with the business, not in spite of it**

I imagine we have all encountered the “IT versus the business” mentality in this field. This is one instance where we cannot afford to adopt that worldview. It’s imperative that the representatives from the business be involved and invested in the development of your RBAC program for it to be successful.

At the end of the day, standardized roles are a compromise between the business and security. They reduce the long-term efforts of the security team administering access by limiting the risk of over- or mis-provisioning access. They also provide quicker request turnaround for new employees, reliable access without guessing or “model after” requests, and they minimize down time caused by employees not having permissions they need to perform their roles.

Role based access benefits both security and the business tremendously, so explaining the value to business representatives and getting their buy-in is vital to your implementation.

The Bottom Line

Making the choice to adopt RBAC is a fantastic step in maturing your organization’s Identity and Access Management program, but it takes time. There may be hiccups, miscommunications, and delays, but these are not uncommon and can be remedied by continually reviewing your previously defined goals.

It’s a tall ask to get the right players in the right place at the right time and have them all speak the same language, but the more your team practices and gains experience adopting RBAC in new applications, the easier and more streamlined the process becomes. Don’t get discouraged, this will all be worth it in the end!