GRC 2014 speaker Prateek Jain of EY joined our recent SAPinsider online chat, and took reader questions on running SoD risk analysis with SAP GRC solutions across SAP and non-SAP systems. There were some great questions on topics ranging from system requirements to how to start setting up rulesets in preparation to run cross-application SoD analysis.
Review the entire Q&A replay or view the edited transcript below.
Allison Martin, Moderator: Thanks to everyone for joining us today! I’m pleased to have EY’s Prateek Jain joining us today. Prateek is a GRC expert and has presented at past SAPinsider conferences. At GRC 2014 this March, we’re looking forward to Prateek’s session on SoD analysis across your applications — the topic of our Q&A today. Welcome, Prateek!
Prateek Jain, EY: Hello. Thanks Alison.
Allison Martin: Could we start with a quick overview of the basics? Why would SAP customers look to GRC to run SoD risk analysis for non-SAP systems? And which ERP systems can GRC analyze for this kind of cross-application SoD analysis?
Prateek Jain: Companies significantly change their processes, supporting technology, and the corresponding internal controls, and need to provide assurance that they have control over all applications, not just the main SAP ERP application. SAP GRC Access Control “out of the box” has the ability to connect to other enterprise applications, such as SAP, JD Edwards, PeopleSoft, and Oracle, but with offline risk analysis you can connect with any legacy system.
Comment From Philippe Réau: How do you link a non-SAP system to RAR? And what about the rules (if this application does not have the same authorization concept)?
Prateek Jain: You can link non-SAP systems using RTA (Real Time Agent) or using the data extraction feature to perform offline analysis.
Comment From Aarati Bathula: Can GRC also check for the structural role in SAP HR?
Prateek Jain: No, SAP GRC cannot check for the structural role in SAP HR.
Comment From LarryMac: What version of ECC should we be on to install GRC at our location?
Prateek Jain: You can install all the following ECC/R/3 systems, with the following prerequisites for ERP systems that will install the Access Control plug-in:
- For SAP ERP system 4.6C, the system must be at SAP_BASIS Support Pack 55
- For SAP ERP 4.70 system, the system must be at SAP_BASIS Support Pack 26
- For ERP 2004 system, the system must be at SAP_BASIS Support Pack 18
- For ERP 6.0 system, the system must be at SAP_BASIS Support Pack 13
Comment From Miguel: Is it possible to migrate current GRC 5.0 SoD to GRC 10, and only edit current segregations already defined without entering the new design again?
Prateek Jain: Yes, it’s possible to migrate from GRC 5.0 to GRC 10. However, there is no direct upgrade/migration path from 5.2 to 10. You will need to upgrade to 5.3 first and then do the migration of data across. With the significant change in technology from GRC 5.X to 10.0, you may need to spend a significant amount of time validating and revalidating the migration. I think that it’s easier to go for re-implementation.
Comment From Guest: How do you link non-SAP applications to RAR?
Prateek Jain: To perform Risk Analysis for non-SAP systems using GRC, you need the following:
- Define cross-application SoD ruleset
- Legacy data mapping
- Build ruleset files
- Uploading the ruleset
- Generating the ruleset
- Data extractions
- Extraction files from legacy and other non-SAP applications for User, Role, Profile, and Authorization Sync
In my session, I will provide the technical details to connect non-SAP applications with GRC 10.0.
Comment From James Blackburn: Does GRC now work with EPM products (e.g., SAP BPC or SAP BFC)?
Comment From Kaitlin: Can you share some best practices with connecting GRC to BPC? Have you seen BPC integrated with GRC at many of your clients?
Prateek Jain: For Access Control, the SAP GRC plug-in allows connections to ERP and any other SAP NetWeaver ABAP-based system plus the SAP portal. You can connect to BPC (version 10). I have not seen clients integrating BPC with GRC.
Comment From Guest: Do you have any opinions on SAP’s Park & Post feature? And how it can help with SOD?
Prateek Jain: Park and Post functions should be segregated. You can create custom rules with GRC.
Comment From Anuj: Different applications have different authorization concepts than SAP — how will GRC check SOD for such applications? What kind of mechanism will be used to check SOD?
Prateek Jain: Good question. For applications where RTA is available, the programs within RTAs can extract the data in real time in similar fashion as the SAP auth concept. For non-RTA applications, you need to do it manually with the techniques that I will address in my session.
Comment From Anuj: When we upload a ruleset from GRC 5.3 to GRC 10.0, do we need to make any changes in the ruleset or not?
Prateek Jain: No need to make changes. You can upload it as is. I would recommend to always look for SAP notes for ruleset changes.
Comment From Jonathan Simcock: Can you say more about connecting non-SAP systems to RAR? Is there an RTA for most systems? Is the RTA provided by SAP or an SAP partner?
Prateek Jain: There are some pre-built RTAs delivered by SAP. For others, Greenlight Technologies creates RTAs.
Comment From Kurt: Considering the speed in which multi-national companies are changing (M&A, new lines of business, out-sourcing, etc.), how does one organize rulesets to keep the SAP authorizations, SOD, compliance up-to-date with company growth?
Prateek Jain: Rulesets should be assessed periodically to identify the functions performed within the organization’s business environment. Organizations need to work with their business process owners to identify what their business process owners consider is a risk.
Comment From Patrick: Is it possible to analyze risks that occur in combination — i.e., one function in an SAP system and one function in a legacy system?
Prateek Jain: Yes, this can be done.
Comment From Edina: How would you design an RAR ruleset, when you would like to manage 1 SoD-risk across two systems (e.g., initiation in SAP/approval non-SAP)? Can it be defined in one ruleset?
Prateek Jain: When you create a rule in GRC, create custom functions for different applications and the functions will be assigned as cross-system not as a single system.
Comment From DonWil: Can you provide SAP best practices for building permission-only SOD rules?
Prateek Jain: The SAP GRC default ruleset comes with a permission level ruleset. You need to understand the following before you activate or disable permissions within the ruleset:
1. Identify the functions performed within the organization’s business environment. Work with the business process owners to identify what their business process owners consider is a risk.
2. Consider ranking based on how resilient the organization’s internal controls are.
Comment From Guest: What are the pre-reqs for running SoD analysis for non-SAP apps? GRC 10.0? AC? Others?
Prateek Jain: For offline risk analysis, you need to define a cross-application SoD ruleset and extraction of data from legacy and other non-SAP applications for User, Role, Profile, and Authorization Sync.
Comment From Ken Lam: This question is specific to SAP SoD analysis. How much time does it typically take to build the ruleset and then to report on conflicts WITHOUT the use of a tool like GRC (e.g., for a company with 2,000 users in one production instance)?
Prateek Jain: It depends upon how many business process functions are performed within your company. Without a tool, the risk analysis at permission level is difficult to perform.
Comment From Cecilia: I understand in GRC 5.3 that there is an alert functionality to identify users accessing/executing conflicting actions (TCodes). Is this also available in GRC 10?
Prateek Jain: You can set up alerts in GRC 10.
Comment From Ken: What is a rough cost estimate for purchasing GRC and implementing it (say, for 2,000 users)?
Allison Martin: Hi Ken. Thanks for the question. For anything pricing related, I would recommend reaching out to your SAP account rep directly. Thanks!
Comment From Anuj: I understand that the program within RTA can extract data in real time, but how will the program extract the data in a similar fashion if there is no concept of authorization objects in that application? What would be the criteria for this mapping so that GRC can understand it?
Prateek Jain: You need to map the data as per the SAP authorization concept. For example, clicking on the menu in legacy can be referred to a dummy transaction code. I will provide some templates and examples in my session.
Comment From Anuj: How can we connect GRC with IDM?
Prateek Jain: Integrating GRC with IDM is dependent on the vendor and version of IDM. There are SAP release notes on the SAP support portal with details.
Comment From Philippe: Is there a method to prevent ruleset bypass except to scan all transports? For example, a new custom development (new transaction) is implemented in production and the GRC manager is not informed by the business.
Prateek Jain: By enforcing the GRC step into the custom development process.
Comment From Mike Zeleniak: We are currently using SAP GRC RaR 5.3 for offline SoD analysis of a JDE system. Are the data extracts for GRC 10 the same format as 5.3?
Prateek Jain: I believe that the data extracts for GRC 10 are in the same format as 5.3.
Allison Martin: Thanks again, everyone, for all your great questions. For more on this topic, I invite you to join us at GRC 2014 in Orlando March 18-21. Prateek will be presenting a session on this topic — part of a track on Access Governance and Segregation of Duties. We hope to see many of you in Orlando this spring! And thanks again, Prateek, for joining us today.
Prateek Jain: Thanks Allison. Looking forward to meeting you in Orlando. The questions were good and these topics will be covered in more detail at the conference. You can also contact me at firstname.lastname@example.org.