The Monster Called RBAC

In the world of identity and access management, Role Based Access Control (RBAC) is gradually becoming a frequently used term. Dictated in part by legislative and regulatory norms, an increasing number of organizations wish to manage and assign all access privileges across the network in a structured way. This is possible through the use of RBAC software. So how can companies achieve an adequate implementation of RBAC across their entire organization?

Organizations are faced with two pitfalls when it comes to assigning and revoking access rights. To assign rights, they often create a copy of a colleague’s account, also known as “template user.” This creates the risk that new employees are provided with unwarranted access to business applications and systems.

Added to which, organizations do not pay sufficient attention to revoking access rights when they create copies of existing user accounts. After all, their most important consideration is enabling new employees to do their job rather than checking for excess access rights. Dictated by standards, IT auditors and unnecessary licensing costs for suites including Microsoft Visio, Projects and Adobe CS, organizations have come to acknowledge the importance of a responsible handling of authorizations.

HR System as Basis
RBAC is a technique for implementing authorization management across organizations. This technique involves assigning rights on the basis of RBAC roles rather than assigning access rights to individual users. These roles in turn comprise the department, function, location and cost center associated with an employee.

Although organizations acknowledge the importance of RBAC, they are cautious about implementing this technique. RBAC has undeservedly gained the reputation that it involves a large effort – particularly in terms of management overhead – as well as lengthy and complex implementation cycles. In fact, RBAC is viewed as a monstrous entity. This misunderstanding is the result of an incorrect approach to its implementation.

In the past, the people who have been responsible for RBAC implementations were under the illusion that 100 percent of the staff could be molded into a single RBAC role. More often than not, there are as many functions in an organization as there are employees. This results in an endless list of roles in relation to resources, so that assigning an RBAC role to each employee becomes a lengthy process. Another question is whether everybody and everything has to be included in RBAC. Isn’t RBAC exclusively needed for user groups, which require a careful authorization set-up from the point of view of risk management, regulations and efficiency?

In any case, RBAC can be handled differently -- quicker and with less complexity.

RBAC as Lego Blocks
The advice for RBAC is to use a bottom-up and stacked approach. This approach involves the creation of a foundation that can be expanded at a later stage. After all, the majority of employees need access to standard applications such as Microsoft Office and Outlook. For a large number of employees, access rights on the organizational level (logging in, word processing, e-mail) and departmental level (access to the department share and departmental applications) can be assigned right away. In this context it is important to determine the top 50 combinations of department and function for active employees.

The HRM system is an excellent source for determining these combinations. This will pave the way for a role model on the organizational level. As an example, a hospital in Lynbrook has a surgery department that includes the functional role of “Nurse.” The organizational role can be created on the basis of the function; department and location found in the HRM system. These are “Nurse” and “Surgery Nurse,” respectively. After “Nurse” and “Surgery” have been defined, a nurse in the surgery department will automatically be identified as “Nurse + Surgery” and assigned the stacked roles.

Using this method, it becomes very easy to populate more than 80 percent of the RBAC table. A major benefit of this approach is that new employees can start working on their first day while time is liberated for the assignment of specific rights on an application and system level.

A subsequent step is to translate these organizational roles into application or system roles, which will comprise the remaining 20 percent of the RBAC table. The basis for this is already present and now further stacking will take place. The assignment of the system roles can easily be handled by the relevant manager. After all, managers, rather than HR, are responsible for the access rights of their employees. On the basis of a special workflow, the relevant manager will be prompted by an e-mail notification and/or web form to specify the access rights and applications for the employee concerned. The RBAC software can subsequently record the manager’s choices to further populate the empty sections of the RBAC table and eventually achieve a fully populated table.

This means it is possible to have a manager handle all the translations of roles within their department, with an option to delegate tasks to a colleague. An action triggered by the manager may also result in a workflow notification to a license manager. This allows managers to exactly determine and manage what happens within their department or cost center.

Detailed Access Rights
Because the system and application roles contain the detailed access rights for the application in question, the role can be implemented. The responsibility for the actual provision of network access lies within IT, as well as Functional/Technical Application Management. It is also possible to automate this part of the process (provisioning) with the help of identity management software.

The major advantage of implementing RBAC in this way is the speed of implementation. Where it takes other vendors a year, Tools4ever, for example, is able to create a first standard for organizations within two months. Added to this, customers can easily achieve SoD (Segregation of Duty), by refusing certain access rights in case of forbidden combinations of roles and departments. In case of downsizing initiatives, it will not be necessary to recreate the RBAC table from scratch.

The only thing that will have to be modified is the “Who are you” section, and this can be conveniently done in the HRM system. By taking the HRM system as the basis and continuously polling it, managers are ensured of the most up-to-date information and have a populated dashboard at their disposal with the function, department, location and cost center for all their staff. This requires a direct connector with the HRM system, since that is the source of all the information. There are multiple vendors that can provide a connector like this.

Pyramid
It is possible to catch this method in a pyramid running from the top to the bottom of the organization (top), via the department, location and function down to individual employees (basic layer). The top layer (organization and location) will exclusively include access rights that apply to all employees. This section can be populated right away. Organizations may wish to consider stop populating the RBAC table at the department/function level. The remaining details will be handled on an ad hoc basis, through a workflow. They will subsequently be able to further populate the pyramid and thus the RBAC table.

Conclusion
RBAC currently attracts the attention of many organizations because this access methodology allows them to assign and revoke access rights in an efficient, transparent and controllable way. An RBAC implementation does not necessarily have to be complex. It is often recommended that organizations use a stacked approach to RBAC and to automate the assignment of access rights on an organizational and departmental level (through their HRM system), focusing on the top 50 combinations of functions and departments. This should enable a quick and convenient population up to 80 percent of the RBAC table. The detailed access rights of the remaining 20 percent cause organizations a great many headaches. To handle these remaining 20 percent in a pragmatic way using the RBAC model, organizations should have their managers handle the assignment of access rights to employees. The managers will be able to determine and modify the detailed access rights for their team.

Over time, the RBAC model will allow organizations to collect more and more information on the choices and selections made during the assignment of access rights. After a review cycle by the security officer, this information can be used to further enrich the RBAC table and to increase the 80 percent to perhaps 100 percent. Knowledge and feedback from the organization help to beat the RBAC monster.


For more information, please visit our website.