What is best practice when performing a risk analysis

[NG15]

I have a GRC question I hope someone can help clarify or point me to existing documentation. What is considered best practice when performing either a role or user risk analysis in GRC? I’ve always believed that risk analysis should be performed at the “action/t-code” level since, by default GRC looks all the way to the activity level thus including the authorization object.. Is that correct or should risk analysis be performed at the "permission/object" level?

[alessandr0 · Accepted solution]

Dear Nora,

always depends on your requirement and what you want to achieve. "Best" from my point of view is the permission Level, since this includes the authorization objects. Especially if you are about to remediate SOD conflicts it definitely makes sense to run against permission level. Just a simple example:

Transaction: MIGO

Authorization object: ACTIVITY = 03 = Display

If you run on Action level MIGO will show up as a conflict with others, eventhough it's only Display. If you run permission level it won't show up, since display is not considered as a violation.

Hope this helps.

Regards,

Alessandro

[NG15]

Thank you all for your insightful answers. I have a better understanding and a few ideas on how to remediate.

Nora

[Former Member]

Hi Nora,

Good practice is to set up each function in your rule set as a critical action or critical permission in order to avoid unnecessary, undesired and long conversations about SoD-conflicts while discussing the risk analysis results.

It is easier to determine if someone should be able to create a purchase order than to discuss all the SoD-conflicts in which PO maintenance plays a role. Removing sensitive access from a user/role will immediately lead to a reduction of unique SoD-conflicts. The data in the critical action and permission reports is also limited compared to the permission level reports.

First focus on the critical actions/permissions (critical action -and permission)

Second focus on the remaining SoD-conflicts (permission level)

Best regards

Tiede-Jan

[former_member184114]

Dear Tiede,

What I got from your post is that, make every function as 'critical' and perform risk analysis. But does it go in this way?

We always have SOD and just cant make every function as critical.

May be, I got it wrong. Please help me understand.

Regards,

[Former Member]

Critical Action or Permission is the terminology used in SAP GRC for sensitive access. The risk level (low/medium/high) behind the critical action or permission really determines the criticality. The risk level of most sensitive access rules are set to low and are used for reporting purpose.

It works more efficiently to discuss sensitive access provided through roles with the business before discussing and explaining them the SoD-conflicts. In case it is agreed to remove sensitive access, for example purchase order maintenance, than automatically a lot of SoD-conflicts (we have 21 with PO maintenance) will be resolved as well (because one of the two tasks of the SoD-conflicts is revoked).

The list with SoD-Conflicts left after this exercise will be short and you can focus your attention on remediating or mitigating the remaining access risks.

[Colleen]

Hi

I assume it would depend. Critical Action/Permission is a single step in the system is has a risk level that you want to manage. For example, debug change could be built as a single action and run for risk. Another example could just be knowing how has opening and closing of reporting period.

It doesn't make sense to identify even function as a critical action. Most by themselves is typical business activities. It's the combination (the SoD) to manage

The challenge here is interpretation of the risk. If business people have to review the report then you need to focus on making it meaningful and simple to them. To achieve this, you need to consider the level of detail and information in the report and what sort of training/education the reviewer needs. Also, you can try to reduce by keeping your roles clean in the first place.

Regards

Colleen

[Former Member]

The majority of the functions in a SOD-conflict can be marked as sensitive.

For example Vendor Master Data maintenance is part of a day to day business activity, but when used wrongly it can present a risk. To reduce the likelihood of this risk occurring I will create vendor master maintenance as a sensitive activity (critical action) in GRC classified as a low risk. The classification low then means that access to vendor master maintenance is acceptable, provided it is justified.

As a hypothetical example the result of a risk analysis shows that the master data officer is able to maintain vendor master data. This risk is acceptable as maintaining vendor accounts is part of their job responsibility. In other words access is justified. However if the AP clerk or another function would also have access to vendor master maintenance it will definitely introduce a number of SoD-conflicts and sensitive access violations. Let's assume that the AP clerk can also process Vendor Invoices with or without a PO. The combination of this activity with vendor master maintenance will present a SOD-conflict (in fact 2 in my rule set).

Now instead of going through a long list of potential SoD conflicts, just start with sorting all the sensitive access risks first and discuss sensitive access prior to discussing SoD-conflicts. Often sensitive access is not justified and by simply remediating (revoking) sensitive access a lot of SoD-conflicts will be automatically solved.

Looking at sensitive access will also give the opportunity to tweak the rules a bit. Often access to vendor account groups is split and not granted to the same function. Now you will have the chance to update your rules accordingly.

Another advantage is that you can use the sensitive access rules as starting point of a business efficiency exercise. With sensitive access rules an overview can easily be created of who is allowed to do what. Duplication of tasks, since they are transparent with this overview, can be eliminated.

[Colleen]

Hi

I can see where you are coming from but it sounds like a huge effort to validate and review access depending on number of critical actions that you define

I would use a combination of:

• proper role design - be clear as to the purpsoe and usage of the role as well as the access to go in it. Role design must really consider the ultimate goal: assigning to a user
• clean role build - aim to minimise inherit conflict and duplication of same access across roles. Be explicit with authorisations values and avoid asterisk unless valid
• A clear access provisioning strategy - consider concepts like position based security ad business roles to ensure appropriate access is assigned based on job function
• User Access Review process - manage whether a user has appropriate access from a role level point of view. This goes hand in hand with role design. Also, opportunity to reduce access creep
• Finally, the RAR rule set and risk definitions - by this stage it's the risk that you need to report on and manage. You don't need to have the case of a person having vendor access who belongs to AP but if you did it'd probably flag as an SoD risk having XK02 with FB/F- transactions

In short - clean roles, clear access and provision strategy that is underpinned with the SoD checks. Critical Action Risk would exist where the single step is a risk to the process/system.

Finally, if you keep roles clean and access managed, you should be able to keep the risks as a manageable number

What is the administrative effort of your approach and how informed is the business in reviewing each critical actions? Do you have a high volume?

Regards

Colleen

[Former Member]

Hi Colleen,

Yes, with this approach you will have a high volume of sensitive access 'violations'. Unfortunately due to deadlines, different priorities of the business and history it is very hard to set up a perfect authorization concept.

Remediating sensitive access violations is easy. You will also speak language the business will immediately understand (about access and not SoD-conflicts). The list with remaining SOD-conflicts is very short and manageable in my experience.

Another benefit is that with the sensitive access rules approach you are able to solve potential SoD-conflicts that were not documented in your rule set yet, but with the removal of sensitive access (e.g. warehouse master data / usage decision) you will already solve them before they may occur.

[Colleen]

HI Tiede-Jan

Unfortunately due to deadlines, different priorities of the business and history it is very hard to set up a perfect authorization concept

You describe the common issue that I come across with security

In those cases, I try to establish what a "perfect" setup would be and do mini-project cleanups to move towards that. In many cases, I'll do a technical clean up first (e.g. fix SU24/PFCG integration) before moving to changing user access. Over time you get the roles clean and make SoD analysis easier. This is one of the first option to consider when you identify a risk

I get how your approach works but if the roles are a mess the the manager say to remove one action, you might get stuck taking it out of a role when other users need the access.

Regards

Colleen

[Colleen]

Hi Nora

Alessandro has already covered - permission level is more granular so less false positives

I've been on client sites where they run it at action level. If they get a conflict they might rerun at permission level to rule out false positives. This was on an older version of GRC so part of the rationale was the volume of data and preparing the report of the business to review as part of remediation and mitigation.

Regards

Colleen