We recently released this new functionality into Squadcast (called RBAC) that helps organizations fine-grain the access control provided to users within our platform. In this blog, I’ll talk about this kick-ass feature in detail.

For Incident Management, as with most other important functions, there exist strict processes that involve specific folks from the organization. During incident response, authentication and authorization are of utmost importance to determine which of these users have access to incident data and how much of the data they have access to.

On-Call Schedules, Services being monitored, Escalation Policies, Incident history, Postmortem reports, and Status Pages are a few of the entities within Squadcast’s platform. Not everyone will need access to everything. Different users within the org will need varying levels of read / write access to the established entities within the account.

Here comes RBAC (Role-Based Access Control)

With RBAC, you can ensure that every user in the platform has the relevant permissions to perform their tasks, be it managing teams, editing on-call schedules, viewing incident notes, etc. RBAC is effective in large organizations where there are too many users, and granting access permissions individually to each of them is tedious and time-consuming. It is also effective in SMBs that follow strict security compliances.

Benefits of RBAC

Role-Based Access Control makes it a lot easier to manage permissions by decoupling the permissions from the users. This simplifies the process of adding new users, modifying the access privileges of existing users, etc. Its benefits in detail:

Scalability: RBAC is more scalable compared to other access control systems because you can assign permissions in bulk. For example, if you’re introducing 50 new junior developers into the platform, you can create one ‘Role’ with all the required ‘Abilities’ and assign the same to all 50 devs thus saving valuable time.

Security & Compliance: RBAC ensures there is maximum adherence to Security & Compliance expectations. By creating specific ‘Roles’ and ‘Abilities’, you can deeply customize what every user has access to and effectively prevent unauthorized access to sensitive info.

Integrity: By implementing RBAC, you can reduce the potential for errors when assigning user permissions. You can create a Role once and assign the same role multiple times to different users.

What is a Role and how exactly does RBAC work?

In Squadcast, Roles are a set of permissions granted that are specific to the Team that the user is a member of. There are predefined Roles that can be directly assigned to the members of the Team. If one wants to define Custom Roles, that is also doable.

Once you have on-boarded a user to your organization’s Squadcast account, you can add that user to a ‘Team’ and assign a ‘Role’. Here, Teams consist of a set of users who are assigned a Role. And a Role is a set of ‘Abilities’ (or actions) that can be performed by a user on the platform.

The Abilities associated with every Role can be basic CRUD (Create, Read, Update, Delete) operations, permissions to run executables, automation actions and so on. Based on the background of the user and the nature of their job role, you can assign an appropriate Role to that user. The best part is you can override ‘Default Roles’ by adding ‘Custom Roles’ to specific users within the Team.

To fully understand the concept of ‘Role’ and ‘Custom Role’, you have to first understand the concept of ‘Abilities’ within Squadcast. ‘Abilities’ are the fundamental access controls that a user possesses in Squadcast. And a ‘Role’ is a set/group of these ‘Abilities’ pertaining to one particular service or Entity.

At this point, it is critical to note that Roles are Team-specific; that is, Roles will allow you specific abilities for just the Team that you are a part of.

The default Roles within an organization’s account are:

1. Manage Team
2. Admin
3. User
4. Observer

Relationship between ‘Role’, ‘Abilities’, and ‘Custom Role’

The below example will help you understand better:

For an entity ‘On-call Schedules’, the following ‘Abilities’ can be provided to users:

1. Create On-call Schedules
2. Read On-call Schedules
3. Update On-call Schedules
4. Delete On-call Schedules

And in this case, a ‘Role’ will be a set of one or more of these ‘Abilities’. For example:

1. ‘User Role’ with Read and Update abilities to On-call Schedules.
2. ‘Admin Role’ with Create, Read, Update & Delete abilities to On-call Schedules
3. ‘Observer Role’ with only ‘Read’ ability to On-call Schedules

The default ‘Abilities’ associated with ‘Default Roles’ are:

‍

Note: ‘Roles’ and ‘Abilities’ are specific to a ‘Team’ and only applicable to the ‘Entities’ associated with that ‘Team’. The Entities in Squadcast that can be associated with Teams are:

• Escalation Policies
• Schedules
• Services
• Squads
• Status Pages
• Postmortems

Example: Configuring ‘Roles’ and ‘Custom Roles’

Let me simplify everything I explained earlier, with an example.

Let’s consider all the engineers (with on-call responsibilities) in the team who would need access to On-call Schedules. We can create a Team called ‘Engineering Team’ and add all engineers to it. The default ‘User Role’ can be assigned to all the engineers in the team with ‘Read’ and ‘Update’ abilities to On-Call Schedules (and other entities).

This means every engineer on the team can view and modify the On-call Schedule. But they cannot create or delete their own schedule. However, if you want to give this privilege to Engineering Managers, or the Engineering Head or CTO, then you can create a Custom Role and give them extra ‘Abilities’ i.e ‘Create’ and ‘Delete’.

Comparing RBAC to other types of Access Control systems

Compared to the other access control methods, RBAC implementations are more flexible since they may be as broad or granular as needed. Roles may be categorized according to the sort of work and the type of activity performed, or the length of time a person has worked for the company. A user's authority, location, responsibilities, or job expertise may all play a part in determining their position.

As a result, an organization that uses RBAC should focus on defining roles and role groups to ensure a clear separation of responsibilities. One of the benefits of RBAC is that it allows you to redefine or update roles that have been created incorrectly.

Different types of access control methods have been developed over the years, like Attribute-Based Access Control (ABAC), Discretionary Access Control (DAC), Role-Based Access Control (RBAC), and others to tackle this issue.

Each of these access control approaches has its pros and cons. RBAC is preferred by many because once the initial roles/user groups are defined, it is easier to include more users as your requirements grow.

Discretionary Access Control (DAC)

Here, the owner of a resource has the freedom to decide whether or not to allow access to another user. With DAC, organizations have less visibility and control over how their resources are used and by whom. Even if a shared spreadsheet is publicly accessible, it is doubtful that a typical employee would comprehend the security risks associated with giving write access.

Mandatory Access Control (MAC)

In order to secure highly sensitive information, Mandatory Access Control (MAC) is used where a centralized authority authorizes access to resources. The MAC method, however, is inefficient. It struggles in giving access to large groups of people with different security clearances in a short time.

Attribute-Based Access Control (ABAC)

Here the rules defined in the XACML (eXtensible Access Control Markup Language) are used to assign certain characteristics to specific users. For example, an attribute may be a time or location associated with a user's identification. For example, ‘Role=Advisor’ and ‘Category=Financial’ may be saved as key-value pairs for a person in the financial department. Although RBAC is preferred because it is easier to set up and manage, ABAC provides more granularity.

RBAC makes handling permissions easier by detaching them from individual users. The process of adding, updating, or deleting user credentials is much easier with RBAC. Access to third parties and compliance systems like GDPR, can be managed more easily with RBAC.

Conclusion

RBAC is a powerful way to grant granular access to your teams involved in the incident response process. A mature incident response process combined with well-developed RBAC policies helps in reducing the clutter and noise around your response process while safeguarding critical information.

We hope this blog helps you in defining well-structured Teams and assigning appropriate Roles based on the permissions they need to go about the Incident Response process. You can try it for yourself with our Freemium Plan, and in case you have any issues, feel free to drop your queries to our Support Team.