The Role Management Model

Let’s go back to our RBAC house that we discussed a couple entries ago in “Couches or Concrete”. The tradesmen have shown up ready to work. The supplies are on-site. It’s a beautiful day for work. They ask “What do we do?” Build a house, of course. Do they just start working? Not hardly. They will want to see the blueprints.

Somewhere along the line, an architect has developed a set of blueprints that outline the specific requirements for building the house according to the wishes of the owners.

Let’s apply that analogy to our RBAC project…

-The Owners of the house – these are your business partners
-The Owners’ wishes – these are your high-level business requirements
-The blueprints – these are the detailed business requirements and the design documents
-The Architect – this is a combination of your Business Analysts (for the business requirements) and your developers (for the design documents)

Of course, the architect must follow some general rules when developing the blueprints. This means there’s one more entry in our RBAC house analogy:

-The building codes – these are published in a document or set of documents called the Role Management Model.

The Role Management Model is a document that outlines the overall boundaries and minimum requirements for your RBAC implementation. These boundaries and requirements are affected by such concepts as company policies, risk appetite, industry requirements, regulations, and management style. The documented Role Management Model provides guidance and, in some cases, specific details on how the RBAC technical solution and supporting processes must function. As a result, the specific details in the Role Management Model will be different for each company. However, the basic outline can be very similar.

Let’s take a look at the topic categories covered by the Role Management Model:

-Basic Role Characteristics
-Role Management Life Cycle
-Role Mining
-Role Ownership
-Role Membership Life Cycle
-Role-to-Identity Assignment
-RBAC Technical Integration
-Process & Governance

For each of these categories in the Role Management Model, there are a number of topic items that will describe the functional needs of the RBAC implementation. In its entirety, this document will serve as the primary reference for all things RBAC as the detailed requirements are developed.

Since it’s difficult to decide and record everything related to RBAC in a single writing, the Role Management Model document will evolve over time. New ideas will arise and decisions will be made along a time line rather than all once. That said, while it can certainly be a living document, the basic concepts and decisions recorded in the Role Management Model will ground the project and serve as a reference throughout and after the implementation.

Called the RBAC Bible, RBAC Manifesto or other favorite term, the Role Management Model will serve your needs well.

In future blog entries, we’ll discuss more about the contents of the Role Management Model as well as how to get agreement among your business partners on its contents.

Oversight or Out-of-sight

How many of us enjoy having someone look over our shoulder as we do something? It’s like having a back-seat driver. In one of my favorite Dilbert cartoons, the pointy-haired boss looks over Dilbert’s shoulder and commands “Move the mouse… up … over … more … now click it! Click it! NO!!! YOU FOOL!!!” to which Dilbert says “This has ‘long day’ written all over it”.

“Go away!” That’s a fairly common theme in IT projects: just let us do our stuff and we’ll get back to you. What can happen as a result? A deliverable that doesn’t meet the needs of the business partners, runs over budget, comes in late, or some combination.

An effective oversight or governance process can help avoid or at least minimize these pitfalls. This is especially true for RBAC. What kind of structure works best? It depends on your organization, but here’s a fairly basic example that you may be able to work with.

Steering Committee – This group of high-level managers and thought-leaders should represent every business unit your RBAC effort will cover. They should make the ultimate decisions regarding the scope, direction, cost and timing of your project. However, that doesn’t mean you let them do all the work. They should expect that your project team will present recommendations to them. These are the approvers, not do’ers.

Working Group – A group of leaders at a lower level than their Steering Committee counterparts. These are the do’ers that your project will need when it comes to getting work done with business representation. If they can’t do the work themselves, the Working Group members should point you in the right direction. This may be a slightly larger group than the Steering Committee as some business areas may not be large enough to have their own Steering Committee representative. You should get representation for them on this level.

In addition to the usual project management benefits, here are some reasons having a governance process in place for your RBAC project will help.

• Your project immediately gets visibility in the business. Without so much as lifting a finger, you’ve created one component of a communication plan to your business partners. For a security project, that’s pure gold. Your project is no longer ‘off the radar’ or out of sight.
• There’s always a lot of scrutiny on security projects. A strong and effective governance model is a key part of the overall SDLC. It will show that the project has adequate management control. It also minimizes the impact of Monday Morning Quarterbacks who want to go in after the battle and shoot the wounded.
• Having a “seal of approval” from your Steering Committee goes a long way with the people that control funding. Benefits of security projects are usually soft (e.g. “better security”) and more difficult to justify. When it comes to a choice between your project and another for those precious capital funds, every edge you can get is critical. A visible and effective governance model can show that there is wide support for your efforts and that the project is more likely to make its budget and time constraints. This can help the money brokers justify their investment in your project.
• You are going to need knowledge experts within the business units for role mining, role creation, ongoing maintenance and general support. A well-formed governance model can readily identify the most appropriate people in the business to assist your efforts. This group can also help prioritize the implementation, getting the maximum political and economic bang for the buck.
• Your governance team will turn into evangelists for your project. They can assist in your communication plan, often paving the way with the ongoing passage of information about the project to those in their business areas. Use this benefit in creating your team. Select or suggest participants who can leverage their communication skills and position within the business to further the project.

For bad spellers and IT projects, ‘governance’ and ‘oversight’ are often four letter words. Don’t let your RBAC project fall victim. Embrace governance and oversight and leverage the benefits for a healthy return on your RBAC investment.

Couches or Concrete

Bought any furniture lately? It can be a long and involved process. Viewing many different options, different styles, different colors. Some spend a lot of time looking for the best fit for your needs, then a special someone will “suggest” the items you ultimately end up buying. But, I digress. Back to the choices.

Should you purchase a chair or chairs? Couches? Tables?

Regardless of what you’re looking for, there is one constant that exists between your search and that of everyone else shopping for furniture: you have someplace to put it. Somewhere along the way, you’ve figured out where in the house it’s going to go.

Ah, the house.

The house was built before you got the furniture to put in it. The foundation, the walls, the windows, the roof, the plumbing. All that was built before you got the furniture. And, it was built in a particular order. You don’t put a window on an empty lot. You dig the hole for the foundation, pour the concrete, erect the floors, then the walls, etc.

The house can be livable without furniture, but furniture is part of what turns a house into a home. The furniture makes the house more useful, but the house enables the furniture to be used. Plus, furniture is the flexible part of the house. You can move it around, put covers on it, take it different rooms, combine it with other furniture. Eventually, you can start to add more furniture and get rid of others you’ve had for a while that don’t work any more. The use and possibilities are endless.

Think about it. RBAC is the furniture in your Identity Management house.

RBAC is not, or at least it shouldn’t be, the first thing you implement in an IdM solution. There’s a lot of infrastructure that has to go into place first.

First, you need requirements. What is your IdM solution going to look like? What do the users want? These are your RBAC and IdM blueprints. Developing sound business requirements and getting the users approval on them is critical.

Next are the policies that govern your information security practices. This is your concrete foundation. Without this solid basis to build on, any solution, either manual or automated, will slowly fall apart.

Then come processes to support requesting IDs and their access, reviewing the access, changing the access and removing the IDs and access. Again, these can be automated or manual, depending on the size of your business and maturity of your IdM solution. This becomes the walls, plumbing and wiring of your IdM house.

Next, the data. You’ll need a lot of data. There are different kinds of data that will be critical to getting off the ground. Information about your users & identities and the resources to which they can have access will form the basis for implementing RBAC. The data becomes the water and electricity that flow through your IdM house.

Lastly, you can now acquire your IdM furniture and implement RBAC.

Still not convinced that role-based access is not your IdM house’s furniture? Have you ever heard of a “rug rat”, an “armchair quarterback” or a “couch potato”?