Role Removal options for roles that cause an SoD

[former_member419332]

Hi Guys,

We have been asked to check if a certain set of roles, when assigned to a user causes an SoD or not. We have 10 sets like that and each set is causing atleast 15 SoDs.

And we are expected to provide role removal options for each SoD, i.e the removal of which role can avoid an SoD in that set of roles.

We usually do this in User Level : Simulation, where we manually enter a role under Exclude values and check if it avoids the SoD but this is very time consuming.

Please let me know if there is a simpler way to check this in GRC or anywhere else

Thanks in Advance

Raghav

[Former Member]

Hi Raghavendar,

In situations like this, I prefer to setup all role combinations as test accounts in the QA environment (assuming the rulesets are consistent between QA and Production).  Then, run risk analysis for the test accounts.

When trying to determine which roles to remove, it can get quite complicated.  However, I like to do this:

1. Setup test accounts in QA with the different groups of roles
2. Run risk analysis on the test accounts in QA at the Permission Level (SOD) and export the results in DETAIL format
3. Create a Pivot table for the data in Excel, and COUNT the number of times a particular role shows up in the data
4. The role with the highest COUNT is contributing to the most rules being broken.  See if removing this role significantly reduces the number of SOD issues by removing it from the test account and running risk analysis again, then counting the number of unique SODs (view the Management Summary report format).
5. Repeat the process as necessary, while trying to maintain the intended functionality of the role group.

Now, there can be underlying issues with the Role design itself.  I prefer to configure task-based roles, which are small roles with task-specific transactions.  This allows the most flexibility for adding/removing combinations of roles to produce the most compliant user accounts possible.  If Role-redesign seems like the best option, good luck because this is an entire project in itself.

Having said that, it is unrealistic to promise SOD-free accounts.  The reason is because Authorization Objects are typically common amongst many tcodes, and this "sharing" of auth objects and values creates an incredibly complex technical landscape.  You can work really hard to get very close to SOD-free, but typically you will need to design and implement Mitigating Controls.  MCs will allow you to provision user accounts that have SODs, but the issues are "Mitigated" by the different types of controls you have assigned to the SOD issues.  I like providing mitigation at the Risk-level, not the permission/rule level because there are just too many rules contributing to each risk.

Hope this helps!

-Ken

[former_member197694]

Hello Raghav,

You can use SOD review process,will helps for your requirement

check the below link

Segregation of Duties Review (SOD Review) Description and Workflow Configuration - Governance, Risk ...

Regards

Baithi