analysis of conflicts without SOD

[Former Member]

Hi ,

How can i find conflicts, where we have only 250 users.

and there is no SOD matrix as such.

and can any one suggest me how to analyse the SOD matrix

thanks and regards,

Kavitha

[jurjen_heeck]

In order to find conflicts you'll have to define them first. That's something the business will have to participate in.

Conflicts are dependent on your business processes and the risks involved, not a general set of rights and wrongs.

Best have a look at the sticky thread on top of the forum. This has a chapter with links about SOD and auditing.

[Former Member]

Hi,

thanks for the reply.

so you mean to say it all depends upon the business process.

for which it is necessary to understand our business process.

thanks again

[Former Member]

It will also be dependent upon who your external auditors are since they would be the ones who would ultimately make compliance to SOD a requirement.

[koehntopp]

Basically, the SoD matrix defines - in technical terms - what kind of access you would like people NOT to have.

Your authorizations will reflect what people are allowed to do as part of their job, and the SoD matrix sets the limits to how much access you will allow them to get before you think it's going to be dangerous for the company, and you better have another person participate in that process as a control function ( 4 eyes principle).

Quite simplified, but that's what your business needs to define, then you can put it into the SoD matrix.

Frank.

[Former Member]

>

>     How can i find conflicts, where we have only 250 users.

Read Frank Koehntopp's post carefully. It is very good, and that your SOD requirements should come from your business (not the auditors) is an important concept to understand... after all it is your business which is 250 users big, and that says nothing about industry, turnover, customizing, etc etc etc...

> and there is no SOD matrix as such.

Be thankfull, and again take a carefull look at Frank Koehntopp's post. As building roles from the bottom up (starting with the "entry points" => SU24) is the intended way of building them, and SOD is the not permitted values, it makes sense to build those not-rules from the bottom up as well, starting with that which is most critical to you to cover the real risks first (and not those which the auditors came up with at a brain storming session). Besides that, there is a difference between operational business risks and external financial reporting risks, and auditors often conveniently forget this when they see a cash-cow grazing in the evergreen fields of the data centers...

At this point I would like make use of the opportunity to point out, as I have often pointed out before, that transaction codes are almost completely irrelevant for access which is critical for your business, and also access which appears to be uncritical for the auditors.

- One reason is that there may be many transactions, reports, menu options and even RFC's and URL's which will achieve the same.

- Another reason which is quite ironic actually, is that a major authorization significance of a transaction code context is infact to turn an authorization-check OFF (not ON)... this makes sense in cases where the calling program has taken care of the security (if required) and you do not want the user to be able to access the transaction directly. So the application uses CALL TRANSACTION to call it within that context and skips both the deactivated object check and the S_TCODE check. Why on earth would anyone want to (or be able to) build a not rule based on an S_TCODE authority for such a scenario when the tcode is not required nor desired???

> and can any one suggest me how to analyse the SOD matrix

If you do not want to spend more money on external 3rd party tools (which might be so called "fly by night" solutions), then take a look at report RSUSR008_009_NEW. It is not easy, but it does work and there are some OSS notes you should read and implement beforehand... but after that it is already included in your license.

At the top of this thread, there is a "sticky thread" with some FAQ's and memorable discussions about SoD, amongst other things, which will probably also be interesting reading for you. (Already mentioned by Jurjen)

Cheers,

Julius

Edited by: Julius Bussche on Jul 12, 2008 8:50 AM

[Former Member]

Frank / Julius,

Thanks for the valuable contributions below. I am trying to use the RSUSR008_009_new report and the SAP note 664213 & others to create IDs with critical auth and variants. The procedure is not detailed enough and i have a hard time following it. would you suggest a more detailed procedure.

for example, when i attemp to create an ID for a critical auth, it is not accepted. the SAP note is referring to customer conventions....

any help is appreciated.

Regards,

Omar

[Former Member]

>

> Frank / Julius,
> 
> Thanks for the valuable contributions below. I am trying to use the RSUSR008_009_new report and the SAP note 664213 & others to create IDs with critical auth and variants. The procedure is not detailed enough and i have a hard time following it. would you suggest a more detailed procedure. 
> for example, when i attemp to create an ID for a critical auth, it is not accepted. the SAP note is referring to customer conventions....
> 
> any help is appreciated.
> 
> Regards,
> Omar

If you want to create your own ID's for critical authorizations then you should do this outside of SAP's namespace.

So use Zxxxxx typically.

Two other areas which you should test a bit before being confident with the report is how the AND/OR operator works, and the various selection templates for authorization values - see [SAP note 978447|https://service.sap.com/sap/support/notes/978447].

Cheers,

Julius