GRC : Assessing risk on a role to role basis

[Former Member]

Is it possible to set up some process in GRC that explicitly defines prohibited role to role combinations without regard to the underlying objects or transaction codes?

I don't have that many roles and I could create a dummy transaction code for every role, assign it uniquely to one role and define transaction code to transaction code conflicts that are prohibited but I would prefer a more direct method. Please advise.

[Former Member]

It is possible to set up a method for explicit role to role SOD evaluation. The risks of this approach should be contemplated in light of the client's business and security processes. In general such an approach is an augmenttion to not a complete replacement of other methodologies.

[koehntopp]

Corwin,

while this may be technically doable, it would totally defeat the purpose. This is like "See no evil - hear no evil".

- There is a reason why you don't want certain combinations - it's because they allow you to completely control a business process or perform critical actions. That reason comes from access to authorization objects.

- You may know right now which roles not to match, but your roles will change. So will your business processes or risk definitions.

- You may know certain role contents that create risk, but there may be other ones you just don't see if you're not looking at the objects.

- You can (maybe) define critical role pairs, but once you get to users with three roles this is no longer sustainable.

- Whenever you build a new role or change the authorizations in one you have to re-do the complete matrix.

Summary: Don't. While you may think it saves you work, it actually creates more. Don't get me started on the issues in related process steps like mitigating controls or user simulation.

Frank.

[Former Member]

I appreciate your passion for this subject. I didn't lay out the whole proposed approach nor describe the environment. The roles don't change very often, the client staff is spread thin and have very little knowledge of the function or relationships between any two objects or transactions etc. The roles are very tight for SODs within a role and we certainly have assessment proposals using typical GRC methods to assess changes to roles.

So my question is still open. Is it technically possible to specify explicit forbidden role to role combinations?

I suppose I could do it by creating a unique dummy transaction for each role and then specifying prohibited combinations of dummy transactions but I would prefer not using a workaround.

Thanks

[koehntopp]

Hi Corwin,

there is no such configuration option for diirect role to role conflicts.

All risk analysis within CUP happens on action or object level, so your dummy transaction are the only available option.

Frank.

[Former Member]

Hi,

This is not at all possible in RAR tool. You won't be able to configure role to role violations in RAR. You may just use excel spreadsheet and SUIM to check for this kind of SoD. Anyhow, if you think some of the roles by themselves are sensitive then you can mark them as critical roles in RAR.

Alpesh

[Former Member]

Hi Corwin,

To my knowledge, it is not technically possible to combine role combinations in SOD business functions or risks.

Another approach might be to include one or more unique transactions, or each of the role transactions in new, different business functions. Then, combine the business functions together in individual risks. A problem might arise if there are same transactions shared across different roles unless those transactions can be separated by other objects (e.g. FB02, separated be Account Type, K, S, D, M...).

Have you tried running the standard delivered SOD rules against the existing users and role assignments? Was it big?

The problem I foresee with your proposal is that the customer may never get educated on the real way of analyzing SOD risks and may as a result make some wrong assumptions in the future about SOD analysis. By comparing high level role names, a transaction will eventually sneak in and could show up on an audit finding that they didn't expect. Just my two cents.

Hope you find a good solution.

[Former Member]

Thanks for your reply. I think that my dummy tcode approach that has a unique transaction for every master role would accomplish that.

The problem with a much more granular approach is the effort to address the impact of combinations and write mitigations. For every list of actions there are n*(n-1)/2 combinations of any two actions. I need to minimize this list for day to day assessment purposes. Its easier to tell a dispenser that you can't give someone two drugs in combination than it is to say there are 10 possible side effects that should be evaluated and mitigated. Besides I cannot readily reformulate my medicine so that the conflict will be voided.

I wouldn't be so simplistic but the client's roles are quite well designed and we will evaluate adding new transactions to roles using classical action and object rules but that evaluation will be a different set of users with more experience in transaction codes, authorization objects etc.

[koehntopp]

Corwin,

we watched a customer doing something like this (albeit on Excel basis) a few years ago, and it was not a pretty sight.

It worked initially, but due to changes in processes, roles, organisation and risk definition it ended up being a mess. The forbidden combinations were completely inconsistent, and whenever anything changed they would have had to re-evaluate ALL users, which of course they didn't.

Result: on paper they had a proper compliant and straight-forward process, looking at the users real authorizations resulted in writeups by the auditors and a huge authorisation re-design project.

Good luck.

Frank.

[Former Member]

Well it would be pitiful if business processes changed and roles changed and there were no reevaluation of the SOD combinations. It strikes me from your description that process management was the problem and SOD identification was just a downstream casualty.

No one should lead with their SOD tool no matter how granular it is.

Drastically changing business processes and constantly changing roles are certainly a risk factor that would call into question a role to role evaluation methodology.