cancel
Showing results for 
Search instead for 
Did you mean: 

Overview of risks within SAP GRC AC-Systems

Former Member
0 Kudos

Hello guys,


Recently I've stumbled over following situation. SAP GRC  presents an efficient way in order to automate and streamline administration task while keeping auditing efforts in a centralized state.

In the same time this “centralization” leads to a transfer and creation of new risks within the SAP GRC System.

Sure the standard security guide provided by SAP lists all authorization objects and roles existing in the SAP GRC System.

What I am missing though is some kind of complete documentation which is covering all risks resulting from GRC related transactions, authorization objects as well as SOD-conflicts, especially in the Access Control Module.


I appreciate any reference provided in order to handling this matter.


Regards, Andreas

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi Andreas,

My Internal Audit team just categorized the GRC system as a SOX system because of Firefighter.  This means that I need to report the sensitive access risks and SODs, just like with ECC, so I'm in the same situation.

First, GRC 10.X is the same ABAP platform as ECC.  Therefore, you can scan for the same Basis/IT SOD and Sensitive Access risks that you look for in ECC.  This is simple - just add the GRC system to the Logical Groups for Basis Ruleset, generate rules, and run the reports.  However, this will only catch the pre-defined Basis risks.

Unfortunately there are no pre-defined GRC-related SOD/SA risks, so you would have to build them.  I can help you get started with some personal observations:

  1. The predefined GRC Admin role "SAP_GRAC_ALL" contains all of the AC authorizations (within 'GRAC' auth object).  This is your starting point for identifying which abilities you want to report on, or which combinations you should not allow.  As you grant or remove these objects and ACTVT values, you will grant or takeaway buttons and functionality within GRC NWBC.
  2. In my opinion, the most sensitive abilities are:
    1. Firefighter Administration - allows manual assignments of FF accounts to users; modify owner and controller assignments
      1. GRAC_FFOBJ
      2. GRAC_FFOWN
    2. Access Control Owner Administration - designate users as AC owners for FF Owner, Controller, Role Owner, Admins, etc.
      1. GRAC_OWNER
    3. Access Request Administration - enables AR abilities, such as Administrative approvals via Search Access Request in NWBC.  User could take complete control of Access Requests
      1. GRAC_REQ
    4. Role Administration - enables BRM abilities, including the ability to create/modify/delete roles directly in target systems via BRM in GRC
      1. GRAC_RLMM
      2. GRAC_ROLED
    5. Basis abilities for Configuration (included in standard Basis ruleset) - can make changes to GRC config directly in production
      1. SCC4 - open the client for direct config
      2. SM30 / SM31 with ACTVT 01, 02
      3. SE38 / SA38 - execute/modify reporting programs
      4. SM59 - manipulate RFCs to target systems

So, I think the objects mentioned above should be included in new Sensitive Access risks (Critical Action).  As far as SOD segregation, it's up to you to figure out which abilities should not be granted together for a single user.  I would suggest that only have 1 person with #3, or place #3 ability in a Firefighter account only.  I would also suggest that you prevent someone from having #2 and #1 together, because they could designate someone as a FF owner, another person as a FF controller, and then also make the FF assignments to users.  Also prevent #5 from any user all together, and place sensitive Basis abilities within a Firefighter account for the GRC system itself.

Good Luck!

-Ken

Answers (0)