Question:
Hi all,
I have been working on a few security projects. In the end, they all come up with more roles than the number of users.
For example, the only difference between two roles is only a handful of transactions, or just the org elements are different. What are the criteria to use to limit the growth of roles? this is especially true during support, when only one transaction is requested for one user, sometimes we have to create an additional role to accomodate this.
what are your practice? if there are only less than 50 users, would it be a better idea to just one user one role? and the security will be just right for a user too.
Answer:
It seems to me that there are two items here:
(1) The basic philosophy for Roles:-
There's no problem with more Roles than users provided the rationale for Roles is documented and adhered to. As an example, where Org Roles are separated, a user will have a functional Role (what they can do) and an Org Role (where they can do it). Conversely if the philosophy is to relate a Role to a business task and there's more than one task to a business role then a user will have more than one Role to do the job. Again, if the philosophy is one Role per business role then a user fulfilling the business role will have just one Role. I don't think there is any hard and fast rule regarding Role structure/application - its horses for courses. However, in principle all users doing the same business role should have the same Role(s). Try to standardise as much as possible to keep future maintenance simple.
(2) Change control
Regarding the growth of Roles, additional transactions should be properly approved by the business (i.e. a person in the business nominated for just this purpose). Whether this results in a 'new' Role depends upon your philosophy. This could be the beginning of the slippery slope to personalising Roles which should be avoided if possible - just thing of the maintenance burden if the business' organisation structure changes !
Because of this, even where the number of users is small I don't believe in personalising Roles. Rather design Role to function and if a user operates more than one business function then they get all the Roles necessary.
Hope this helps
_________________
Best Regards
Bazza
Answer:
Just a quick point. From a controls mitigation perspective, it's easier to mitigate controls with fewer roles then more.... Ask your internal auditor his/her viewpoint on this.
In a nutshell, it's easier to see and understand what people are doing in the system the fewer roles you have. May be a little more legwork, but IMO, more secure.
Just my .02c.
_________________
"SOX.. hmm .. Aren't they the baseball teams in Boston and Chicago?"
Kind Regards,
IamEvilHomer
(Wayne)
Answer:
Just a quick point. From a controls mitigation perspective, it's easier to mitigate controls with fewer roles then more.... Ask your internal auditor his/her viewpoint on this.
In a nutshell, it's easier to see and understand what people are doing in the system the fewer roles you have. May be a little more legwork, but IMO, more secure.
Just my .02c.
Totally agree.
How to acheive this though? what is your experience?
Answer:
Build at Job level. Identify the jobs required in your organisation and map to those. If users have similar access needs then do a risk analysis - often they can share roles if there are appropriate controls in place (whilst retaining segregation etc).
Designing from the top down can help break out of the 1 role for 1 task approach which is easier to do but has a number of disadvantages
Answer:
If you have more roles than users, create a role PER user and go home early and get a life... THere is NEVER a need for more roles than users if you have more than 125 users.
Often you get in this situation when you have not defined common Business processe, re-engineered your jobs, or you are controlling on WANT versus a risk analysis/probaility model.