RAR files that we upload are wrong !!

[Former Member]

Hello Gurus,

Good Morning !!

We are currently implementing GRC AC 10 and have configured RAR by uploading the 9 files e.g. rule set, business process etc

When we performed RAR , we found that there were about 80 roles which had SOD violations.

So we started the cleanup activity .

We found a role which had the RISK ID : F028

Now this risk contains two functions : AP02 & GL01

Going forward we found out that both the functions contained common transaction(F-02) !!

So what we did was created two roles ,

ROLE A containing only function AP02

ROLE B containing only function GL01

Then we performed Risk Analysis and to our surprise there were RISK detected for individual function !!

How is that possible !! That an individual function contain SOD risk !!

Does that mean that files provided by SAP to be uploaded are completely wrong ??

Please note we were using the same files that were available for GRC 5.3.

Will anyone check if you are getting the same issue ??

Regards,

Victor

[Former Member · Accepted solution]

Hi Victor,

Not sure if this will help, but please take a look at SAP Note 1600667 (Transactions that conflict with themselves). If you look under the first paragraph in the Solution area, they mention how the order of authorisation objects will remove the SOD. Hope this helps. ~Triera

[Former Member · Accepted solution]

Hello Triera ,

Thank you so much for directing me to this note !!

Regards,

Victor

[Former Member · Accepted solution]

Hi Triera,

Thanks for sharing this information about SAP note. Hopw it will help many people wodering why same tcode is is showing SOD.

Regards,

Sabita

[Former Member · Accepted solution]

My pleasure Victor and Sabita...I have run into this issue a number of times and just stumbled across this note shortly after it was released.

~Triera

[Former Member]

Hi Victor,

We have faced and checked the same issue. There are multiple Action Level rules which come due to a single tcode!!

Below is a list in FI-

F02802L Calculate and Post Accruals(ACACACT)

F028039 Reverse Postings(ACEREV)

F0280AE Post Document(FB01)

F0280B2 General Posting for Ledger Group(FB01L)

F0280BQ Change Document(FB02)

F0280LF Reset Cleared Items(FBRA)

F0280O0 Post Parked Document(FBV0)

F02906S Post with Clearing(F-04)

F0290EK Post with Clearing(FB05)

F0290FC Post with clearing(FB05_OLD)

F03004J Post with Clearing(F-04)

F0300WO FBCJ - Post Cash / Check Receipt(YF12)

If you check these Action Level Rules in SAP standard ruleset, i hope you too will find the same tcodes coming in both (or three if there are three) and single tcode will show SOD risks!!

There are two justifications for that-

1. At Object Level control there might be different values - say MIR7 park document at LHS and post document at RHS create a SOD for same tcode.

2. There is grouping of tcodes in functions and even a tcode in LHS create SOD for all other tcodes in RHS and same tcode in RHS creates SOD for all tcodes in LHS, in that case same tcode exists in both sides thus creating conflict for the same tcode too!!

For point 2, we could get smaller functions to avoid it.

Regards,

Sabita

[Former Member]

Hello Sabita ,

Thank you for your quick response !!

But i am not very good at security concepts !!

Will you please explain a bit more on how to approach the clean up activity when we have such a problem ??

I am asked to prepare clean specification for the dirty roles , so i am now confused how do i approach it.

Will you please share your experience or practice on role cleanup activity ??

I will be really obliged if you can give me some inputs !!

Thanks in advance.

Regards,

Victor

[Former Member]

Hi Victor,

Cleanup approach would be organization dependent. Sorry, I am also a learner in this aspect on how to approach remediation part. What we did in our case was that first we got the rulebook approved by Business owners of specific modules e.g. For FI, finance module lead. If they found any rule inappropriate or they wanted to do some Org Level modification and restriction, they changed the rulebook.

After Rulebook was confimed and uploaded, we did risk analysis and sent all reports to respective module leads who decided which roles/users should be remediated and which ones should be mitigated. Becuase they know the tcode and associated risks well. If not, then a Security Consultant has to explain what is the risk.

In case of one tcode coming both side, look carefully if they correspond different Object Values and there is really a risk. If yes, then convince the concenred person and ask them to either remove them or put a control on them.

If both side have exactly same values, then you might want to rebuild that specific risk and split them into multiple functions/risks. Otherwise a mitigation control would work.

Regards,

Sabita

[Former Member]

Hello Sabita,

Thank you once again for your quick turnaround !!

We had already discussed the risk's with Power users & their manager and from 203 SAP Standard risk , approx 105 risk were selected.

Based on which we uploaded the same and ran the risk analysis .

Now we found about 72 roles which need cleanup and there were about 170 roles which contained critical transactions.

As per your suggestion

A) In case of one tcode coming both side, look carefully if they correspond different Object Values and there is really a risk. If yes, then convince the concenred person and ask them to either remove them or put a control on them.

My Question : What could be the types of controls we can define here ?? Can you please give me an example ??

Removing the Objects and directly creating a new role for it would be a good option !! But i am still not clear on "Controls" that can be put ..

B) If both side have exactly same values, then you might want to rebuild that specific risk and split them into multiple functions/risks. Otherwise a mitigation control would work.

My Question: This is very confusing !! How do we split up ?? When both the things are same !! I mean when the transactions are same how do we create separate functions & risk !!..Will you please elaborate ??

My apologies for asking too many questions but i guess that's the only way out to learn !!

Thanks in advance.

Regards,

Victor

[Former Member]

Hello Victor,

Just want to add some inputs.... This is not an easy procedure and you shouldn't work alone in this. Role remediation is the first thing you have to perform, and this should have been performed before GRC implementation. You'll be able to find a short guide in the note: 1593056 - Best Practices for Remediation of Segregation of Duties risk

And there's a great guide mentioned in the note.

If you have a role with SoD conflicts, you have to split the role in as many roles as you need until you get SoD-free roles.

You have to bear in mind that the rules provided by SAP could contain "false positives":

Note 986996 - GRC Access Control- Best Practice for Rules and Risks:

"If new or different auth object settings come into play in the higher releases (4.7, 640 and 700) and you feel this results in false positives (conflicts that show that don't really exist), then you can adjust the rules to add these authorization objects to the rules.

Again, our assumption is that the delivered ruleset should err on the side of showing too many conflicts which can be further filtered by the customer, versus excluding users that should be reported."

When you analyze the conflicts, you should check if the reported risk exist in your environment or not.

But, as I said before you'll find a step by step guide in the first mentioned note.

The remediation procedure will take time, you cannot pretend to clean 72 roles from one day to another

Be patient and work together with the corresponding areas.

Cheers,

Diego.

[Former Member]

> My Question : What could be the types of controls we can define here ?? Can you please give me an example ??

> Removing the Objects and directly creating a new role for it would be a good option !! But i am still not clear on "Controls" that can be put ..

>

Control means there must be some kind of watch out for the risk. Suppose there is Tcode MIR7 for which park document and post document should be with different users so one user creates and parks the document and another user checks, verifies and then posts it. In this scenario there is a validation taking place before final posting. These two activities within same tcode can be SOD.

If for any reason, a single user is authorized to do both activites, there should be weekly or quarterly checking on which documents are posted and what are their details. Are they within the limit and according to the business practice or there is some wrong posting in it. If that checking is in place, then we can put a mitigation Control in GRC also, stating the same. This will vary from organization wise and module wise how do they check into the system. THis involves business people heavily and is not security guy work.

> B) If both sides have exactly same values, then you might want to rebuild that specific risk and split them into multiple functions/risks. Otherwise a mitigation control would work.

>

> My Question: This is very confusing !! How do we split up ?? When both the things are same !! I mean when the transactions are same how do we create separate functions & risk !!..Will you please elaborate ??

>

Suppose tcode FB02 is in a risk in LHS side function A with the same Object Values as it is in RHS side fuction B. It means only one set of value is causing the SOD which is false negative. The justification behind it is that both side tcode FB02 makes SODs with other tcodes residing in both side. In that case we can take FB02 out from one function A, create a new function C for it and make a new risk with fuction C and B, which covers all tcodes SODs with FB02.

I hope it clarifies it a little bit. I am not sure how much practical it is to break the functions like this, involves very much study of risks, business people involvment and agreement.

Regards,

Sabita

Edited by: Sabita Das on Feb 13, 2012 1:24 AM