SoD GRC Ruleset Matrix

How much do you know about your risk matrix?

Regardless of the tool you use to perform the access risk analysis, it might be useful to further investigate.

What is the GRC Ruleset?

This is the SoD matrix of the GRC Access Control product, specifically the module called Access Risk Analysis.

In GRC, it is called a set of rules, which is all the combinations that are generated between the matrix objects (action and permission), read the in-depth article here.

Do you keep the matrix updated?

Downstream of the SoD management project, if continuous compliance processes are not defined, as per the Segregation Of Duties management methodology suggested by SAP, the matrix is often abandoned for years.

What does this mean and what does it entail for example?

• New transactions, custom but also standard in the case of activation of new processes not initially foreseen, are not included in the matrix (clearly only in case they are SoD relevant)
• If you have implemented organization rules, these must be kept updated, in case new organizational levels are defined
• New processes or discontinued processes, again the matrix must be updated accordingly

It means that you are basing your access risk analysis on data that is out of date and potentially not entirely correct. Also generating false negatives.

The above is only true in the case of the SAP GRC Access Control system? Actually, no.

It potentially applies to all systems that allow risk analyses analogous to SAP GRC Access Control for SAP systems.

But are you sure there are no errors in your risk matrix?

What I mean. Often, indeed I would say almost always, the matrix is loaded massively into the GRC system. This results, in some cases, in several parameterizations being incorrect.

This does not mean that it is wrong to load it massively. A mistake can be made by loading it massively but also on time.

However, the criticality of the above can lead to false negatives. That is, the system does not detect potential risks that are actually there.

For example?

1) Transactions that do not exist in the system but are present in the matrix (not a real criticality in this case). But why keep incorrect data in the matrix? Actually this aspect is true for "data typing" problems Ex. I write ME2wN instead of ME22N or similar cases.

2) Objects that do not exist. This is a more serious case. GRC will never find that rule. As we are asking GRC to find objects that do not exist in the system e.g. M_MSEG_LOG instead of M_MSEG_LGO

3) Values of objects that do not exist. As above. I look for activity value 81 when for a certain authorization object that activity is not expected. GRC in this case will never find that rule in system.

These are just a few examples, which is why, as Aglea, we have defined a set of verification rules for the risk matrix.

Of course, we are not talking about errors or failures at the process level; this would be more difficult to detect (requiring a greater investment of time than detecting technical errors). But the technical aspect of the matrix must also be considered.

Are you really sure that there are no technical errors in your matrix?

Topics: SAP GRC, sod, falsi positivi, sod ruleset, analisi dei rischi