In regard to my document about Rule Set / Business Risks I would like to give some detailed information about rules and rule types. As we learned rules (or risk rules) are possible combinations of transactions and permissions for a business risk.
Rules must be generated when ever risk contents change. This can be done in SPRO (GRC > Access Control > Access Risk Analysis > SOD Rules > Generate SoD Rules). Generally rules are combinations of actions and aren't maintained manually (done automatically by the program).
The number of rules defined from a risk is determined by
- the number of action combinations, and
- permission/field value combinations contained in each function of the risk.
The following graphic shows the rule structure in more detail:
Now let me give you a short overview of the different types of rules considered by GRC.
Transaction Rules
Rule components are as follows:
- System
- Conflicting Actions
- Rule ID
- Risk Level
- Status
Example (from the graphic above):
F001001: Maintain fictitious GL account & hide activitiy via postings
F001001 - Risk ID
F001001 - Action code combination number (represents Conflicting Actions)
Permission Rules
Rule components are as follows:
- System
- Object
- Field
- Rule ID
- Risk Level
- Status
Example (from the grapic above):
F00100101: Maintain fictitious GL account & hide activity via postings
F00100101 - Risk ID
F00100101 - Action code combination number
F00100101 - Object combination number
Critical Action
List of actions considered critical. Option to run at both Action and/or Permission level. Critical Actions are created same way as Segregation of Duty risks, exept Risk Type = Critical Action, and can contain only 1 function (as shown above with SCC4).
Critical Permission
List of objects/permission considered critical. Created same way as Segregation of Duty Risks, exept Risk Type = Critical Permission, can contain only 1 function, and function cannot contain actions.
Critical Roles and Profiles
Roles and profiles considered critical. Critical roles and profiles will be excluded from analysis if the configuration parameter 1031 (Ignore Critical Roles & Profiles) is set to YES.
Organizational
Used to eliminate false positive SOD reporting based on organizational level restrictions for users. Organziational rules should not be created for mass org level reporting as it should only be enabled for functions that you specifically need to segregate. Most companies are controlling what data a user has access to via role assignment. There are only very few companies who have a business need to create org rules.
Supplementary
Additional security parameters other than authorizations a user must have to enable access. First checks to see if the user exists in the supplementary table, then checks if conditions are met. Based on exclusion setting, it will include or exclude the user in the risk analysis.
Please share and contribute in this document to make it better.
Looking forward to hear from you.
Best regards,
Alessandro