Skip to main content
 

Logo-Text

Search
Home
  
ServerCare home > Posts > Implementing RBAC, a practical approach  

 

 

August 26
Implementing RBAC, a practical approach

Introduction

RBAC, or Role Based Access Control is a security philosophy formalized in 1992 defining access to resources through roles hierarchies and constraints. In 2004 RBAC was adopted by the American National Standards Institute, International Committee for Information Technology Standards (ANSI/INCITS) as an industry standard. In 2008 the standard was submitted to the IEEE for approval. Once approved the standard may be put on track for adoption as an ISO standard.

RBAC is often referred to as the newer approach to mandatory access control (MAC) and discretionary access control (DAC)

The use of RBAC to manage user privileges within a single system or application is widely accepted as a best practice. Systems including Microsoft Active Directory, Microsoft SQL Server, Microsoft Exchange 2010, SELinux, grsecurity, FreeBSD, Solaris, Oracle DBMS, PostgreSQL 8.1, SAP R/3, FusionForge and many others effectively implement some form of RBAC.

The NIST RBAC model addresses the limitations of RBAC for enterprise-wide deployments, which typically focuses on the increased complexity of managing sufficient roles and assigning adequate role membership within a heterogeneous IT infrastructure.

Some notion of roles for access control predates the RBAC standard by at least a decade, for example some banking system in the 1970s used roles even if they weren't called by that name.

Challenges and how to address them

Challenge 1 History

Typically the origin of an RBAC project lies with the IT department realizing the challenge of manageability of access rights and the resulting 'complex situation' that has evolved building up over the years. Another reason might be legislation and/or an auditor pointing out the relaxed security that might be the result of the lack of a security policy and procedures such as RBAC.

One of the things that typically leads to challenged security situation is the (non automated) way that users are being assigned security groups. Typically a new user gets assigned a group or series of groups that are based on a 'template user'; usually an existing user who is a direct colleague of the new hire. Typically this leads to relaxed security that allows new users far more access to resources than required. Besides security issues the same behavior drives up licensing costs, as more users end up having access to certain applications than strictly necessary. In this scenario the focus lies on assigning permission rather than reducing them, for all the right reasons (allowing people to do their work) but with adverse results.

More often than not there is a sense of awareness within IT departments that some form of policy should be in place, but lack of coordination, momentum or perseverance to push one central vision results in the implementation of several strategies accumulating over time. The end result is typically an even more complex end result, increasing TCO and obfuscating security.

To address this a firm decision needs to be made at leadership level, the choice for RBAC needs to be well though over and backed by higher management company wide. A 'clean sheet' approach where possible is a great way to get rid of old clutter. For example; a new file server replacing an old one with legacy security applied, possibly even the migration to a new Active Directly domain or forest, for example when RBAC is implemented at a smaller company where this might be feasible.

Clear communication about strategy needs to be done 'top down'. This way new projects, initiatives and applications being introduced into the organization implement the correct identity management and RBAC principle from the start.

Challenge 2 Perception

As mentioned it is often either the IT department or an auditor that is the first to realize something is wrong with security and needs to be addressed. As a result of this the problem is often perceived as a purely technical one, when in fact it is primarily an organizational/people problem. Technology only delivers the tools that might assist in building the solution. RBAC revolves around structured hierarchy, well defined processes, roles and functional job descriptions. This typically is based on the groundwork provided by the human resources and planning departments, rather than the IT department. The challenge for a successful RBAC implementation is to maintain focus on the people. RBAC project are –not- technical projects; they are people projects.

 

This challenge is addressed by communicating and teaching middle management what the challenges and pitfalls are for the RBAC project, but even more importantly what their advantages are. What needs to be clarified from the start is what the deliverables are, what challenges lie on the road to get there, what dependencies can be identified early on and what kind of timeline is viable to get to the first targets. In addition within each meeting needs to be addressed that this is not a technical but people project.

Challenge 3 Communication

Even though we have established that RBAC is a people rather than a technical project, it still is quite technical and abstract in nature. Here in lies the problem of convincing people it is in their best interest to cooperate. If the concept of RBAC is difficult to communicate, how can we ask people to commit serious time and effort into the project?

To address this a strong communication plan needs to be established that targets different levels of the organization with the information needed at that level. Presentation sheets need to be prepared to explain the basics of RBAC to peers and middle management, with a different degree of technical knowledge interwoven on a need to know basis. Don't bore management with technical details, but then again; don't bore technical people with high level overviews. Make sure to address for each department where their benefits lie, but also what administrative overhead they can expect in the future to get these benefits. Stress the dangers of a faulty security implementation and what the results of that could be.

To retain momentum and awareness meetings on a predefines regular interval need to be help with driving parties within the organization such as department managers or the project board. Prince 2 as a project management methodology assures such communication taking place.

Challenge 4 Understanding

In line with the communication challenge lies the understanding of the project and its impact on the organization. The depth of the project needs to be understood to a variable degree at different levels within the company: end users, middle management and higher management.

To address this challenge:

Higher management needs to understand that RBAC implementation has a profound impact on the way some parts of the company operate. For example; certain procedures and workflows will need to be developed (new hire/leaver procedures for example), departments such as IT and HR need to start working closely together. In addition higher management need to understand to what extend RBAC is directly applicable to their organization, and to what extend the implementation of RBAC may have impact on ongoing projects. Lastly it needs to understand how RBAC typically is a phased implementation because of the way a set of roles 'evolves' into a practically usable instrument. It is something that takes time and maintenance. In that view it is advised not to try and implement each and every possible application initially, but rather target a more pragmatic approach. Starting with the 'quick wins' this will allow the organization to get used to RBAC, develop the necessary procedures, processes, structures, standards, inventory, approach, documentation and roles.

Middle management needs to understand that 'the old ways' of doing things no longer work and that assigning functions, job and roles now will become part of their administrative process, rather than a quick request to the IT helpdesk. HR and IT middle management will need to understand that roles for each function need to be designed, determined, inventoried, and (especially) maintained. This would be an extra burden on the existing workload for HR as well as IT.

The end user needs to understand that receiving access to certain resources now requires them to fill in forms and get authentication through workflow from their manager or resource owner.

Challenge 5 Motivation

Security projects are typically perceived as a hassle, standing in the way between the employee and his or her short term goals. This perception stands in the way of people being motivated to deliver on any security related (read RBAC) project.

Motivation can be addressed the Machiavellian way :

Especially companies that use targets and award bonuses based on such targets are challenged where these kind of projects are implemented. Rather than a motivational factor such targets often have adverse effect, unless the bonus structure is used to include the projects milestones as targets.

For organizations working in a more traditional manner, or using other means as an enterprise motivational tool (rather than a bonus structure) it is advisable to make sure the project is top down communicated within the management hierarchy.

Security problems typically aren't visible problems until disaster has struck, and then it's one of the organizations worst nightmares. This is what needs to be imprinted to make sure everyone understands why cooperation is important.

It is advisable in one-on one session with each manager to asses how a security problem might directly impact his or her department. This not only stresses the (possibly personal) risk but also allow the opportunity to do a risk assessment per department.

The challenge of motivation is two-faced: as mentioned security is often seen as a hindrance in the way of people getting things done. Secondly; RBAC projects, by nature take time to implement, evolve and come to maturity. During this time people need to be continually motivated to work on it, even though results are not directly visible. This is best addressed by making ongoing results and reached targets as visible as possible by means of structured communication. Make targets reachable for the teams within reasonable timeframes and communicate each success to reach the target as a team effort.

Challenge 6 Expectations

Lets get this out of the way first:

  • The prevailing opinion of most business units is that IT projects do not deliver all the benefits that they promise.
  • The expectations of management is often that targets are being met, despite of overwhelming evidence to the contrary as well as historic results with previous projects.
  • End users typically expect things should be magically 'fixed' within a few weeks or otherwise be able to continue their business as they have always done.

     

If anything, expectations need to be managed for each group of people, especially so for RBAC projects. Besides the challenges pointed out above; the nature of RBAC project being people projects rather than technical projects, the dynamic nature of an organization where RBAC needs to be applied upon all make it a challenge to direct the right messages to the correct group of people. Again a strong communication plan for each group will assist in directing expectations to more realistic levels.

Implementation

The approach

The best approach is a pragmatic one. First structure needs to be designed, this is done by devising standards, procedures and documentation. Then implementation of the standards and procedures needs to be addressed, to do this tools need to be obtained or made, people need to be trained and communicated with, progress needs to be monitored and managed. A realistic target needs to be chosen, and attained. Based on the lessons learned the next step scan be taken until the project of introducing RBAC is completed, next steps are to make sure it is maintained and take to higher levels. (such as implementation of RBAC in legacy applications, which can be quite a challenge)

Design and structure

Standards

Since we will be defining a huge number of Active Directory groups, it makes sense to look at the organization of such groups, for example through the use of AD OU's , but also by a well defined naming standard. A well designed naming standard helps reduce complexity and makes maintenance easier. To achieve this a group name should consist of a number of elements helping to understand it's use.

Elements might be considered for each group name:

  1. Function, this could be an acronym (preferably a small, fixed amount of letters: 3 or 4) depicting the type of group as being for example administrative, departmental, project based, role type, a certain resource.
  2. Descriptive, a free field that describes in a few words what the group pertains. If possible we want a pre-defined set of descriptions that may be combinable to assure uniqueness.
  3. A one or two letter field describing the kind of resource. (file/folder, application, database etc.)
  4. The type of permission granted to this group. (Read, Write, Modify etc.), usually one letter will do.
  5. The scope the groups addresses (Local, Global or Universal) Keep in mind that typically the local groups are the resource groups, where the global groups are the role groups.

Usually a divider such as the minus sign "- " is used in between the field. Also keep in mind that AD forces a maximum of 64 characters for the group name. For maintenance purposes the description field of the group can be used to log the exact resource. For example: if a resource group addressing a specific folder on the file server is created the description field could state the direct path to this folder where rights are being assigned. Since we now have a reference linking the group directly to the exact resource, this makes it possible to automate maintenance. An idea might be to periodically run a script checking a file/folder resource groups and assessing if the folder reference in the description field still actually exists. If it doesn't; the group can be removed since it allows access to a non-existent resource.

Role definitions

This is one of the biggest challenges of any RBAC project; what and how many roles do we need to define, and who should maintain them?

The definition of the roles should match the organizational requirements. Usually the Human Resources department defines, tracks and maintains such information regarding functions and people. In addition Human resources typically also maintains an hierarchical overview of management/employee relationships. This information is essential to define who should have access to what resource, which is the foundation of any security strategy, including RBAC. Therefore it is essential that this information is not only correct but also timely , and as such maintained.

An approach might be to (in coordination with HR who at this time develop their own internal procedures to maintain this information in the future) take a look at the organization and try to assemble a role model for example based on department and function. Hopefully the HRM system assists in getting this information assembled. This would be leading in getting these roles translated to the application /resource management space; this is where the real challenge lies.

One misunderstanding in most organizations attempting to implement RBAC is that these roles are simply one of the side effects of RBAC, and that with little effort the IT department will be able to define and maintain them. Reality demands however that the designing and maintenance of a role-set is a multi-disciplinary task than requires quite some (ongoing) effort.

In addition we need to be careful not to define too many roles, but tailor them to the resources we allow access to. This may mean that some roles can be combined if they allow access to the same resource. As such this makes the definition of roles a task not to be taken lightly.

Defining roles is best done following a set of predefines rules that 'construct' a role definition, much the same way the naming standard is devised; by combining the static and dynamic parts (maybe 5 or 6 elements) we construct a role.

This could for example be based upon department, functional description, resource access or type of work on that resource.

For example: accounting-paymentinformation-editor.

In this case the department, resource type and function work type is pre-defined; assisting in defining the role for a particular group of users.

By defining strict rules to devise such roles we avoid confusion about which role does what. In addition establishing a role structure based on a fixed number of role elements limits the amount of possible roles to a fixed number. As one of the dangers of RBAC implementation is the proliferation of the amount of roles, this is a desirable output.

Authorization

Each resource within a company usually has an 'owner', whether formally or informally. If we are to allow access in a controlled and auditable manner to a certain resource, we need to make sure we have this ownership documented formally. Otherwise; what is the use of implementing security if access is authorized arbitrarily!?

Cartman: "Respect my authoritah"

In some cases it is obvious who is the 'owner' of a resource; typically the department manager. However; in some cases a regular employee will have been appointed sole ownership of a specific resource (a database for example). Any workflow requesting access to this resource should then go through this person rather than the manager (or both).

In addition to defining the ownership of resource, so that we can establish who should be authorizing access, we also need to document and maintain this information. Once defined, an operational procedure should exists that checks the correctness of this information on a regular interval (yearly?)

The role management model

The role management model is a document outlining the overall boundaries and minimum requirements for the RBAC implementation. These boundaries and requirements are affected by concepts such as company politics, industry requirements, regulations management style etc.

Besides granting people access to resources, we also need to identify what resources need to be protected to what level. What kind of access if needed, and where specifically do we not want to grant access? How granular will be at defining access levels? Keep in mind that the more granular we are at defining our access; the more resources groups and roles we will need, hence more maintenance.

As mentioned in the "Authorization" chapter; the practice of defining the roles will be multi-disciplinary. Translated: we need to visit each depart to talk with the manager and at least one or two people for each role to. With this information a 'role matrix' can be built for each department. Besides getting the roles inventoried, these interviews can also be used as a vehicle to get the companies resources and the required access mapped out.

The documented Role Manager Model provides guidance and specific details on how the RBAC technical solution and supporting processes must function. This covers details such as:

  • Role definitions
  • Role ownership
  • Role to identity assignment
  • RBAC technical integration
  • RBAC related (workflow) processes
  • Security protocols
  • Resources

 

This information about the users, identities and the resources to which they have access will form the basis for implementing RBAC. As such this information needs to be well maintained, preferably by someone in a security dedicated role such as an IT security officer.

Since it is hard to decide and record everything RBAC related in one single writing, this document is very much a 'living document' that needs to be developed over time. However the basic concepts and decisions recoded in the Role Management Model will ground the project and serve as a reference during and after implementation.

Tools

Once standards have been defined, it is important that they are adhered to. Unfortunately, because of the complexity of RBAC, combining security with resources, role names and naming standards, it is easy to make mistakes for example when creating Active Directory groups, which is an important technical element of implementing RBAC.

When groups are created manually following a complex naming standard mistakes are easily made. Therefore group names should make use of predefined words, so that structure exists within the group names created.

 

 

 

Tooling should concentrate on the creation of such groups following the naming standards and predefined sets of words, such as role definitions or departments. Ideally such tooling also assigns ownership and links to the resource where rights are assigned.

AD Group naming and creation tool as created for a customer

As this takes away the complexity of the creation of the groups, this greatly improves the chances of a successful implementation of the AD group maintenance part of RBAC.

Workflow and processes

For new hire/leaver procedures as well as resource access requests processes, procedures and workflow need to be defined. HR and IT need to share information regarding people entering or leaving the company detailing certain basic information such as who the manager is, what roles (and as such access to what resources) the new employee has, or for example when the account can be disabled.

For regular users needing access to a resource certain minimal information about the exact resource location, type of information, and authentication of their manager or maintainer of that information should be provided. Notice that manager and maintainer are named separately; an employees manager could in theory authenticate access to a resource where the manager him/herself has no access; as mentioned before, it would be better to track who has ownership over certain resources and have them authenticate access.

Such workflow could be done either using a customized application such as a web form, or company wide available applications allowing workflow such as SharePoint.

It is imperative that managers and employees are the most important part of this process since only they understand the exact nature of the resources and who should have access or not, and to what level.

Ideally the way the workflow application works, whatever it is, should allow visibility of who receives access to what and as such make auditing possible of who requested and who granted access to certain resources. Part of such a workflow procedure implies that certain resources actually have people 'appointed' to them as 'resource manager'. Obviously this should be done in communication with these people, explaining what responsibilities this brings.

Maintenance

So far we have primarily looked at creating new groups, but to ensure continuity we need to be aware of a danger each RBAC project has: too many roles! We already address the possibility of abundance of roles during the design phase. Here we address the growth of roles once the implementation phase is over.

As each company to a certain extend is an dynamic environment, new roles will emerge, and old ones will vanish. Ideally this role-set is maintained by a responsible department (such as HR for example). IT then should be able to remove any groups that are associated with these roles, after receiving a workflow message form HR.

Another thing that could disappear is a resource; this also has a group associated with it, and as such should be traceable so that the group can be marked for deletion if the resource no longer exists. Ideally there should be some type of link between the resource and the group, making deletion a potentially automated process. As mentioned before, the description field of the AD group could be used for this.

If tooling permits, it might even be possible for a manager to (re)define certain roles or resources that are associated with his or her department. Keep in mind that besides a technical solution this also means the right amount of training and motivation is required!

 

 

 

Comments

Excellent article!

This is the first article I find online that actually gives some down-to-earth advise. We were about to implement this, but your points have given us somthing to think about before moving on. There's a lot more to it than simply setting some rights!

thanks!
 on 11/3/2010 10:37

should have read this earlier

I whish I had read this before we started on our disaster RBAC project... what a waste...
 on 6/23/2012 1:12

Very good article

This is a must read for all who want to implement RBAC. Although there are some grammar errors, the article is spot on when seeking info on the matter!

Great job, thanks!
 on 10/25/2012 15:50

thanks

Glad you liked it; about the grammar, well english isn't my native language I'm afraid.

Paul
 on 11/9/2012 23:30

RBAC Project and Timeline

We are starting a RBAC project and I am the coordinator and facilitator.  Would any of you have some type of project steps and timeline you've put together to pull this off?  Reinventing the wheel in RBAC looks painful!  I would be eternally greatful for anything you would have that would save me time in the beginning or elsewhere.

Thanks.

Bill
bsampson@fpfc.net
 on 12/3/2012 23:00

Thank you!

Great article! If someone has any similar information available can you please share a link here?
 on 4/5/2013 14:23

Add Comment

Spam Filter *


Please enter 4982 in this field. This will help prevent SPAM.

Title


Body *


Attachments