* Role-based access control
I’ve mentioned a couple of times that the identity of things (or “entity identity”) was the major theme running through my conversations with identity and security vendors at the recent RSA Conference. But there was a second thread, which although not mentioned by as many people, still cropped up often enough to be considered a topic worth discussing.
In the past, I’ve talked about role-based access control (RBAC) as a way to streamline identity management projects (https://www.nwfusion.com/newsletters/dir/2003/0818id1.html is just one of the many newsletters on this topic). Theoretically, that’s true. But as a number of different vendors told me, the practice is somewhat different.
First, each potential identity management customer insists that a) they’re different from every other organization and b) their people each perform unique roles. The customer believes that any knowledge the vendor has gained from other organizations can’t be applied to their circumstances.
Well, just as many corporations have more in common with each other than they have differences so too does your organization’s people have much more in common than you think.
The key, (and a number of different people told me this) is to remember the Pareto Principle – the so-called “80-20 rule” – which is interpreted to mean that in any given group of people, things, ideas, etc., 80% are trivial while 20% are important, unique or meaningful. Rather than trying to match up two or more people who do exactly the same thing in order to create a role, concentrate on the trivial 80% of people’s duties. You’ll find that only a small handful of roles are needed to control authorizations for these things. The other 20% can be assigned on a person-by-person basis as needed.
In this way, you don’t bog down in tedious discussions about what people do, but can quickly move on to the more important area of what they should be doing. Courion, Abridean, Thor, M-Tech and Sun all said similar things to me about this.
Some of them, along with auditing vendors like Consul (and others) have even proposed a different way to define the roles. First, before even thinking about roles, you start auditing access to resources. Then you mine the audit logs to find similarities among the people accessing a particular resource.
If, for example, you find almost everyone in the marketing department accessing a particular fax server then you would add authorization to that fax server to the marketing role. Other authorizations in the marketing role could include product forecasts and roadmaps, organization-specific clip-art for presentations, etc. You’d find that most people in marketing would need access to these things and most people outside of marketing wouldn’t.
Confidential research and development, though, might only be needed by the top marketing execs and access would be granted on an individual basis. Or you might find that top-level engineering and finance people need access to that data as well, so create a role for R&D. After all, people can fill numerous roles at any given time.
The important point is that no one role should attempt to encompass everything that needs to be accessed by those in the role, just the more trivial 80%. Keep mining the audit logs and you can adjust the roles. Over time, you’ll build up a good picture of what people do based on the roles they fill rather than having to constantly adjust their personal authorizations as their needs (or the organization’s need) change.
