Any correlation between USOB*_C tables maintenance & GRC AC10.0 rule sets?

[Former Member]

Hi guys,

Is there any correlation between the maintenance of the USOB*_C tables and the rule sets in GRC AC 10.0? A consultant tried to explain that the proper working of ARA depended on these tables being accurate and up-to-date. Maybe I got the explanation wrong? What data source(s) do(es) the ARA component reference? I'll appreciate your thoughts and guidance please.

Sal

[Former Member · Accepted solution]

Thanks guys! The response has been overwhelming; quite enlightening!

My understanding from all you've said is that updating USOB*_C tables would
be a nice-to-do; but not mandatory for ARA. From Colleen's point, I gather that
maintaining USOB*_C tables is a prerequisite to implementing BRM. Correct?

I'll leave the discussion open for a while longer just in case there are any
other viewpoints.

Sal

[Colleen · Accepted solution]

Hi Sal

It's not so much a per-requisite to maintaining them but SU25 does impact SU24 updates. The BRM does a check for the differences if SU25 has not been executed. You could probably update the PRGN_STAT table directly and avoid running SU25 to bypass this.

Some examples in SCN of this topic

In a nutshell - they couldn't complete the step Maintain Authorisation Data as SU25 was not executed for Steps 2A and 2B

Regards

Colleen

[Former Member · Accepted solution]

Thanks a great deal, Colleen!

Your inputs have been quite helpful. I'm currently in a GRAC post-implementation project and would likely be having some more questions coming I hope to get more of your invaluable contributions

Ade

[Colleen · Accepted solution]

Hi Ade

Glad to hear the community was able to assist and help

If your questions is answered please mark is as answered so when your questions keep coming someone will respond 

Regards

Colleen

[FilipGRC]

Hi Sal,

there is indirect correlation as described above by others, but there is no (must) direct link.

You can have incorrectly setup USOBT* tables and still ARA rules working fine as there are independently setup by GRC consultant during sod matrix implementation. All standard rules are only proposition and should be adjusted as per client need.

Hope this help,

FIlip

[Colleen]

Hi Sal

Summarising everyone else: When you add a new action to a function the permissions proposals are defaulted based on SU24 data. It helps you check with objects you should activate, etc but it is not a guarantee. As Gretechen mentioned, if you do not properly maintain your SU24 data then you have less trust in accuracy of it as guidance. SU24 will not be evaluated when you run the risk analysis.

In the BRM space, however, SU24 is important - particularly SU25. If you do upgrades or enhancement packs, you need to execute SU25 which will update those tables or your will get an error in Maintain Authorisation Data of the role build

Regards

Colleen

[mamoonr]

Hi Colleen,

It gives overall view how this SU4 affects risk analysis.But i still have a question that there must be one table or any source in GRC which is used for reference in analysing the risk.

I guess there is a function module to analyse risk(*GRAC_RISK_ANALYSIS*).

Thanks,

Mamoon

[Colleen]

Hi Mamoon

Do you mean able for the rule set - risks, functions and rules or do you mean table of user risk?

Yes, the rule set is stored in tables (GRACFUNC*, GRACRISK*, etc). You can mass extract via IMG downloads

Online Risk analysis is not stored in tables - it is an RFC call to your systems and calculated

Offline Risk analysis stores in GRC when you run your batch risk analysis

Regards

Colleen

[Former Member]

Hi Sal,

There is indirect relation for these two.

As you might know USOB*_C holds customer values for profile generator, so this provides you administrative efficacy while creating roles, which is your base for your authorization concept.

GRC repository holds pre delivered rules through BC set, if you choose to activate, they are independent of your backend system.

During auth synch GRC picks auth data of your roles and have it in GRC for risk analysis.

So they are not directly but indirectly linked and right USOB*_C values helps you build right roles in less time.

BR,

Mangesh

[Former Member]

when you create a function by entering a tcode, the authorizations are extracted from USOBT_C table. if you don't maintain this table in ECC and handle security incorrectly you will be analyzing risks incorrectly.

[Former Member]

Sal,

Perhaps what the consultant was trying to say was that if the USOB*_C tables are not being maintained and accurate, it is possible that the risks will not be configured correctly, due to uncertainty as to which authorizations and values are required to enable the actions/tcodes.

Does that make sense in the contect of your discussion with him/her?

Regards,

Gretchen