How many of your RBAC projects are funded, staffed and run by your company’s IT organization? How about by the Information Security group?

If you’re like most companies, IT or Security provided the initial impetus for the project. They provide the project leadership and the lion’s share of the capital or expense funds, too. How about software or hardware? Yes, probably with some of the vendor’s staff to support, drive or assist in the effort.

Now think about how this shapes the perceptions of the RBAC project. Hmm, let’s see. It’s funded by IT/Security. It’s run by IT/Security. There’s software and maybe some new hardware. IT/Security brought in contractors who do this stuff for a living.

Bingo! We have a technology project.

For those outside the project team, or put another way, the users for whom we are doing the RBAC project, their frame of reference is based on their own jobs, duties and organizational view. Most likely, many have experienced an IT project and its impact on their job. They know it when they see it.

It’s a technology project.

How can we expect anything else? Let’s face it, security projects are often thought of as some sort of voodoo or weird science that spreads pain and suffering throughout the organization. Kind of like your in-laws coming to visit. They are reacting based on decades of dealing with IT and Security. An RBAC initiative that maintains a technology focus will either fail or at least deliver much less than intended. Our challenge is to change that focus.

But, on what should we focus? Let’s look at some RBAC components:

Roles. Well, duh! It’s pretty tough to do Role-Based Access Control without having roles. What are roles? For now, let’s say that their names can often describe the specific job functions performed by the people assigned to them.

Functional Job Descriptions. These are usually based on some HR criteria or market description for the specific tasks people perform.

Users. These are the people that are assigned to roles.

Access Rights. These are the system capabilities that the users (people) receive.

See any consistent themes here?: “performed by the people”, “tasks people perform”, “people … assigned to roles”, “capabilities … (people) receive”.

People.

It’s the People, Stupid!

The challenge for a successful RBAC implementation is to maintain a maniacal focus on the people. Technology project: Bad. People project: Good.

Why is this so important? I have a few ideas on that.

Time is money – don’t waste it. Of course your time is valuable. But, here I’m talking about your business partners’ time. RBAC is likely going to touch every nook and cranny of the organization. You will need their knowledge and more importantly, their time, to make their RBAC implementation a reality. Their perceived ROI is their time vs. what they get. Make the most of it. You may only get one chance. (Notice I said “their RBAC implementation”).

All technology projects are suspicious. The prevailing opinion of most business partners is that technology projects don’t deliver all the benefits that they promise. On top of this, they believe that the costs to the company are high. Don’t run a project that feeds these beliefs. You need to create a value proposition for your business partners. Just as critical is the need to keep telling them the value over and over again.

Security is a hindrance. Your business partners believe security just gets in the way of them doing their jobs. They don’t understand it and they don’t want to take the time to learn it. Ask them to take training in how to use a new security application. You’ll find they would rather spend a weekend listening to Al

You do not have flash or javascript support.

Average (1 vote)

Reply