Skip to Content
Actions

Rule set – Rules & Rule Types

April 28, 2014 | 17,518 Views |
 Governance Risk And Compliancegovernance risk and compliance sap grcgrc 10rule setrule structure
Follow RSS

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:

RuleStructure.png

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. Please find more detailed information in Organizational Rules in GRC Access Control.

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

To report this post you need to login first.

16 Comments

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

    1. Alessandro Banzer Post author

      Dear Mamoon,

      thanks for your feedback. Let me create a document explaining organization rules in more detail.

      Quick-and-dirty I would say you have a role concept with derived roles where the leading organizational level is the company code. Assume that you have a SOD risk between FB60 (posting of vendor invocies) and FK02 (changing vendor master data). A combination of transaction FK02 and FB60 is a SOD conflict. A user who gets both roles assigned would have a combination of both transactions which is conflicting according to your rule set and would shop up as a SOD conflict.

      This could be false positive as the user can actually not call FK02 and FB60 for the same company code (assume that FK02 is for company code 1000 and FB60 for company code 2000).

      Hope this helps to understand the concept behind organizational rules.

      Regards,

      Alessandro

      (0) 
          1. Former Member

            Hi Alessandro,

            This is really very helpful. I am enjoying it as you have maintained every detail.

            I have a small question. Hope you dont mind me asking this.

            Taking your FI01 risk example, I would like to discuss my doubt.

            As you said Action rule for FS00 and FB01 is: FI01001, does it mean that it always starts with <Function ID>“001”?

            Because I tell you, I have a function F016 (I am on GRC 10, SP#14) and I could see that its “Access Rule ID” starts with “0001″

            Please find below screen shot (Rules starting with 0001):Ruleid1.JPG

            Please find below screen shot (Rules starting with 0002):

            Ruleid2.JPG

            I am quite confused with “0001” interpretation. Going by your example, can I write like:

            F016<Function ID>000<Action Rule>01<Permission Rule> (F01600001)?

            Is it like in GRC 10, Rules are starting with “000″ instead of “001“?

            Please help me understand.

            Regards,

            Faisal

            (0) 
            1. Kevin Tucholke

              Faisal:

              Previously in AC 5.3, when the rules were generated, the numbering convention looks like what is stated above.  Risk IDs in 5.3 were limited to 4 chars, then when the rules were generated it would add a 3 char action combination and a 2 char permission ID.  So in the example above, the full Risk ID would have been F00100101.

              In AC 10.x, the numbering convention has changed.  This is now spilt between 2 fields which are Risk ID and Rule ID.  Risk ID is exactly what you would think that it is, Rule ID would be the Action Combination.  Risk ID in AC10.x can be up to 8 chars now, and the Risk ID is always 4 chars.  In AC10.0, the same entry in the example would be Risk ID F001, and Rule ID 0001.

              Hope this helps.

              Kevin

              (0) 
              1. Former Member

                Hi Kevin,

                Thanks for this.

                It is clear now.

                All the risks would be starting with 0001 access rule id.

                There is one note#1310365. This says that in AC 10. the maximum number of rules that can be generated are 1679616 (36*36*36*36)

                Regards,

                Faisal

                (0) 
  2. Former Member

    Alessandro,

    One more question I have (I have already raised a thread for the same):

    ARQ: Are “Valid From” and “Valid To” dates are considered for risk analysis???

    As  you mentioned “Rules Components” for transaction and permission rules, I have not found “Validity” dates as a “component” of the risk analysis

    May you confirm if ARA considers validity period also?

    Because, in ARQ when a request is raised for 2 conflicting roles assignment with different future assignment dates (no overlapping), still violations are shown!

    May you please advise?

    Regards,

    Faisal

    (0) 
  4. Former Member

    Dear Alessandro,

    Thanks for very informative and precise document.

    can you please guide me on the below points.

    what is the maximum no of function ids that can assign to a risk id?

    what is the best practice or thumb rule to create function ids and risk ids

    Regards

    Mohammed

    (0) 
    1. Alessandro Banzer Post author

      Mohammad,

      I have never tried the limit of functions within a risk. And to be honest I don’t see a case where you need more than two (or three) functions. Segregation of duties usually consists two functions, sometimes it’s required to have three within the same risk. Best if you try and once you hit the max open an OSS and ask SAP for a solution.

      Best practise for function / risk creation depends on your requirements. I personally keep an eye on SU24 values that must be maintained accordingly to get the proper default values when creating a function. Apart from that it depends how you create your functions. It can be either done in GRC directly or via Excel upload. In case I use the Excel upload, I export SU24 values from the backend and prepare in Excel accordingly.

      Hope this helps.

      Regards,

      Alessandro

      (0) 
  5. Bruce van Rooyen

    Thanks for the detailed document Alessandro. I have a question that I am battling to get more information on.

    Where and when is updates to the Rule set supplied by SAP and when was the last update on the Rule set.

    We have migrated to HANA/EHP7 which delivered some new transactions (ending with “H”) which is not in the Rule set and we are looking at implementing simple Finance which also brings new transactions and other transactions are obsolete. Is there an update to the rule set available that will include these new transactions?

    Regards

    Bruce

    (1) 
  6. Former Member

    Thanks for the detailed document Alessandro.

    I have a questions around creating a SOD risk with 3 functions.

    How would my Rules be like?

    I think it would be Action1(Function1) v/s Action2(Function2) v/s Action3(function3). Can you confirm based on your expertise?

    Thanks in advance.

     

     

    (0) 

Leave a Reply