How do you Run Risk Analysis on more than one open requests for same user?

[jonathon_sells3]

For example, User1 requests RoleA and RoleB together a single request. The Risk analysis is run against both roles.

Then say later on, the  User1 requests another role. So they proceed to request RoleC. Now there are 2 separate requests in GRC.

So how can these 2 separate requests be grouped automatically during the Run Risk Analysis?

To clarify further, if a role owner has to run the risk analysis on RoleA, the system will take RoleB into consideration because it's on the same requests but how do we force any and all other open requests to be processed in the RA for the same user?

Thank you

Jon

[Former Member · Accepted solution]

Jon,

Correct, having two requests in process at once is how SOD risks can sneak into your system. This is why it is a good idea to not allow it. We prevent that via our EUP settings.

Yes, the setting is called "One User per Request per System" which has it somewhat backwards; perhaps something was lost in the translation from German, but that is what that setting means. Users are restricted to one request in flight per system; if anyone attempts to create another request for any user who already has one in process, the system stops it.

Regards,

Gretchen

[jonathon_sells3 · Accepted solution]

Hi Gretchen,

That is good information. We will have to test out how that works with SAP IDM.

Currently we are using SAP IDM 7.2 for role requests instead of GRC CUP. Our primary issue is that when IDM sends the request(s) to the GRC AC 10.0 Web Service named GRAC_USER_ACCES_WS, the requests in GRC are created one per business role. Users can requests multiple business roles at the same time resulting in multiple requests in GRC for a single user.

We had a conference with the SAP IDM Development team and they stated that this is default behavior of the IDM integration with the GRC AC Web Services. If we wanted the roles grouped, we would need to customize.

This is why we are trying to see if we can get GRC to acknowledge the "In Process" requests during the Run Risk Analysis.  

Regards,

Jon

[Former Member · Accepted solution]

Jon,

Thank you for clarifying your use case. That default behavior of SAP IdM strikes me as very strange. That sounds to me like a good reason to not use SAP IdM and use GRC's Access Request Management instead.  I will be very surprised if GRC 10 can do the kind of risk analysis you are proposing. I was always under the impression that it could not, but perhaps it is possible in 10.1.

Good luck,

Gretchen

[former_member298408]

Hi Jon,

Was your issue resolved.

We are having same issue with our IDM 8.0 integrated with GRC 12.

We are looking for ways where only one GRC request is raised for multiple business roles submitted in IDM.

Thanks!

[jonathon_sells3]

SAP IDM does have it's benefits. In addition to SAP ABAP and Java provisioning, IDM allows you to provision to non SAP systems like Active Directory, HANA, Operating Systems, Databases, Email Servers and other various Cloud Services. It's very customizable.

After discussing with my GRC team, the limiting of a single open request per system would not be effective in our large landscape. They mentioned several unintended consequences with the biggest concern of how long open requests take to fulfill.

So this issue of In Process GRC requests was an issue here when we used CUP and would still be an issue with ARM.

Granted multiple Business Roles were grouped in CUP when requested at the same time, but we still had users request business roles over time that were in flight resulting in multiple in process requests.

[Former Member]

Jonathon Sells wrote:



After discussing with my GRC team, the limiting of a single open request per system would not be effective in our large landscape. They mentioned several unintended consequences with the biggest concern of how long open requests take to fulfill.

Jon,

Why does it take so long for requests to go through your approval process? Not enough role approvers/ lack of backup role approvers? Easily correctable. Role approval required for many roles that are display only/ not really sensitive? Not difficult to remedy. Role approvers sit on the requests too long? Funny thing is, when the managers and requesters start calling up the role approvers and asking them what the heck  is taking so long for them  to make a decision, role approvers start taking action on requests more timely.  What else causes slow processing of requests? We have found that a lot of it is training issues, and most of our multi-system GRC requests are closed and provisioned in 24 hours or less, unless there are SOD exceptions to be mitigated.

Cheers,

Gretchen