Risks:


Risks are the core objects that identify the potential access issues which your enterprise may encounter. The elements that make up a risk are its attributes. Risk management uses the attribute descriptions to generate rules. Risk management is the set of processes through which management identifies, analyzes, and, where necessary, responds appropriately by mitigation or remediation to risks that might adversely affect realization of the organization’s business objectives. The response to risks typically depends on their perceived gravity, and involves controlling, avoiding, accepting or transferring them to a third party. Whereas organizations routinely manage a wide range of risks (e.g. technological risks, commercial/financial risks, information security risks etc.), external legal and regulatory compliance risks are arguably the key issue in GRC.

Critical Permission Risk:


Defining a critical permission risk ensures that risk analysis identifies any employee who has been assigned a potentially risky permission. You can use this feature if the permission has been enabled but has no actions. This risk can have only one function.

SAP delivered SoD doesn’t contain any Critical Risk ID specific to Critical actions or Critical permissions. So, if you run the access risk violation reports either at user or role level and if you select any option among Action level, Permission level, Critical action level et al. but Critical Permission level, you would see the risk reports as expected out of the selected rule sets. But once you select only Critical Permission level, you wouldn’t see any violations. Reason being is that SAP standard SoD doesn’t contain any critical risk ID either at action or permission levels.

So, in order to customize the rule set and to create Critical risk at permission level, first we need to create a Function ID which would contain the permission (authorization object) and no action (transaction code) in it.

// Verion of GRC used: GRC AC 10.1 and SP 06 //

Go to create Functions as per the path defined below and don’t add any action in this function.

/wp-content/uploads/2014/09/snap1_544908.png

Now, we will go to Permission tab to enter the required permission to be treated as Critical Permission.

/wp-content/uploads/2014/09/snap2_544919.png

Now, this Function ID (CF01) has to be added to a new Risk ID (CR02), map this risk ID with the Rule set and assign the risk owner as below:

/wp-content/uploads/2014/09/snap3new_544930.png

Then generate this newly created Risk ID; either via NWBC or via SPRO (IMG –>GRC –> Access control –> Access risk analysis –> SoD rules –> Generate SoD rules; and mention the lately created Risk ID and execute).

/wp-content/uploads/2014/09/snap5_544934.png

We would see the risk violations at critical permission as below:

/wp-content/uploads/2014/09/snap6_544935.png

Your inputs/suggestions are always welcome 🙂

Courtesy & Regards,

Ameet kumar & Fernando Bassuino

To report this post you need to login first.

7 Comments

You must be Logged on to comment or reply to a post.

    1. Ameet kumar Post author

      Hi Prashant,

      I came up with this idea to make it as a blog entry from your thread: ARA report

      So, thanks to you too for your feedback and will look forward to come up with documentations involving with Non-ABAP systems.

      Cheers,

      Ameet

      (0) 
      1. Rakesh Ram

        Good one Ameet….Thanks for the Contribution….Very helpful for understanding how to set up critical permission level risks.

        Regards

        Deepak M

        (0) 
  1. Rahul Urs

    Ameet,

      Like the blog. But, I dont agree with this line “SAP delivered SoD doesn’t contain any Critical Risk ID specific to Critical actions or Critical permissions”. please take a look at the Ruleset. there are many Critical Action Risks. eg: BSCT.

    also, I dont agree with this statement “Reason being is that SAP standard SoD doesn’t contain any critical risk ID either at action or permission levels.” remove the words – “either at action or”. I agree there are no critical permission risks. if you can correct that statement or rather list the number of SOD risks and Critical Action Risks to help the reader understand the standard ruleset “GLOBAL” that will help.

    (0) 

Leave a Reply