Review our Q&A with GRC 2014 speaker Marc Jackson of Turnkey Consulting, who took questions on the "murky world," as he put it, of SAP Process Control authorizations.
You'll find all the discussion in the chat replay and in the edited transcript below.
This Q&A was sponsored by GRC 2014 and moderated by conference producer Allison Martin.
Allison Martin, Moderator: Thanks to everyone for joining us! It’s great to have Marc Jackson of Turnkey Consulting joining us today. Marc is a security expert and a longstanding presenter at SAPinsider’s GRC conferences, and I’m glad he can take some time to answer your questions today on authorization concepts with SAP Process Control. Thanks for joining us Marc!
Marc Jackson, Turnkey Consulting: Hi Allison. Thank you for inviting me! Welcome everyone. I look forward to an interesting discussion on the murky world of PC authorizations!
Allison Martin: Could we start with a quick overview of what makes SAP Process Control’s approach to authorizations a bit different from other SAP applications?
Marc Jackson: Sure. PC authorizations do share similar elements from standard authorizations as they both use auth objects and field values, etc., which allow you to perform various functions. However, you also have the concept of entity-level authorizations in PC, which is very unique to PC.
Comment From Guest: How do I map authorization objects to t-codes?
Marc Jackson: This sounds like a more general security-related question, if my understanding is correct. You can certainly map authorization objects to t-codes using transaction SU24. This maintains the authorizations-related tables USOBT_C & USOBX_C. By linking objects to t-codes here, it means that when you enter that t-code into a role using PFCG, it will automatically pull in the related objects and associated values (which you can also maintain using SU24).
Comment From Carolyn Linton: Question 1 – Within GRC, is there a report we can run that will show a control name and description against the process hierarchy?
Marc Jackson: Hi Carolyn. You can use the report “Organization and Process Structure” (Master Data > Reports), which gives a good overview of the orgs, processes, sub-processes and controls and where they sit in the overall hierarchy. You can then personalize the report by selecting “Personalize” in the top left-hand corner and the “Personalize Fields” option, then select “Control Description” from the available fields. That should give you everything you want, as the control name is visible in the blue hierarchy structure on the left-hand side.
Comment From Carolyn Linton: Question 2 – Is there any way to link process maps to the process hierarchy within the system?
Marc Jackson: If you mean whether you can add your own process documents (i.e., Word docs, Visio’s, etc.) to the process hierarchy, then the answer is yes. You can find an “Attachments and Links” tab in most master data objects from which you can physically attach a document, or add a link.
Comment From Ravinder Singh: My organization is looking forward to implementing GRC10 and currently we are on GRC5.3. We have APO, CRM, 3 ECC (user base of 25K+), and BW systems attached. As per your suggestion and experience, how much time we should target to complete this upgrade?
Marc Jackson: Hi Ravinder. It’s nice to hear your organization is making the decision to upgrade from 5.3 to 10.0, as integration between the different GRC applications is a key improvement between the two releases, and hopefully your company can benefit from this. Unfortunately, this is not a simple question to answer, given that there are numerous parameters to consider (i.e., applications being implemented such as AC, PC, RM, etc.) and different functionality within these (i.e., ARA, ARM, EAM, BRM, etc.), and factors such as how complex the current configuration is for your 5.3 system. Also, I’m conscious that this forum is supposed to be focused on PC 10.0, and specifically authorizations-related questions for PC. However, I’m happy for you to contact me outside of this forum for further information.
Comment From Guest: Do we need to have Risk Management in place before we set up PC authorizations?
Marc Jackson: No, you don’t need RM in place before you can set up authorizations in PC. A lot of the authorizations are shared between the 2 applications, and they utilize the same concepts, but they can be set up independently.
Comment From Guest: What are our options for Process Control workflow?
Marc Jackson: Is it possible for you to be a bit more specific? There are many business events in PC for which workflow can be utilized. These can all be configured in the agent determination configuration area within the IMG (GRC > General Settings > Workflow > Maintain Custom Agent Determination Rules), where you map PC roles to be the recipients of these business events.
Comment From Guest: Specifically, I’m wondering how PC handles workflow for monitoring authorizations after setup.
Marc Jackson: You wouldn’t really look to use PC workflow to monitor authorizations after setup. If you’re concerned about monitoring who has access to certain functionality, then that should all be done using the ruleset and risk analysis functionality in AC.
Comment From Guest: What do you recommend for first steps to setting up SAP Process Control authorizations?
Marc Jackson: The first thing you need to do is understand how users will need to interact with PC. For example, who will be doing the administration on the system? Will business end users be merely recipients of workflow items, or more hands-on with updating master data? All of these questions need to be answered before you can start to put in place a technical authorization solution to meet these requirements.
Comment From Victor Guerrero: In PC 10.0, how do you set up security in reports in a way that, for instance, people from a specific organization are only able to see controls, issues, etc., from their organization? The way the system behaves is that, once we execute a report (e.g., Test status by organization), we can select any organization and drill-through all details of the controls, evidence, attachments, etc., which is not desired.
Marc Jackson: Hi Victor. It’s strange that you are not able to restrict the reporting in PC, as it should certainly be based on what organizational elements the user has been assigned against. If the users have any role that has the object GRFN_USER with activity value 2 or 3, then this will override any organizational restrictions you have in place. You could check whether this is the case. Otherwise, you should be able to restrict by assigning the user to roles for specific objects (e.g., organization owner or sub-process owner) and they should only be able to see data for the objects at that level AND below, but they shouldn’t be able to see anything upstream from that object.
Comment From Kelly: We currently have AC and are considering implementing PC. What would be the best resource to begin investigating and educating ourselves on the new authorization concept in PC?
Marc Jackson: Hi Kelly. There isn’t loads of information currently out there regarding PC authorizations. We’ve had to learn the hard way most of the time, by trying stuff out in our sandbox, and obviously experience gained on client implementations. However, there is a security guide that is available on service.sap.com/instguides.
Comment From Guest: Any special technical/app requirements for Process Control? Do we need Risk Management or Access Control in place?
Marc Jackson: I’m not sure if I completely understand your question about technical/app requirements. You certainly don’t have to have AC or RM in place in order to use PC. Each is designed to be used independently of each other, although some of the big benefits to be gained are when you utilize the integrated functionality between each of them.
Comment From Brian Merkel: We’re looking into Issue Management, specifically ad-hoc issue functionality. How do you determine which business events to map an entity ID (e.g., G_AI)?
Marc Jackson: Hi Brian. I mentioned a PC security document in an earlier post, which can usually be found at service.sap.com/instguides. Within this document, the entire library of business events and sub-entities, etc., can be found in the appendix. Other than that, it is a case of testing some of them out to see if they meet your needs.
Comment From Dave: I have a question on the mobile capabilities in these areas. Are there mobile capabilities for authorizations in Process Control now or in the roadmap?
Marc Jackson: Hi Dave. That’s an interesting question. To be honest I’ve not heard of much in this area at present, but that’s not to say that it won’t be the case in the short-term, hopefully I’ll find out more at the GRC conference in Orlando in March! It could certainly be potentially useful for customers if they were able to action issues while on the run. Alternatively, how big is your laptop? : )
Comment From Abdul Hakim Khan: Could you please share the best methodology for implementing PC?
Marc Jackson: Hi Abdul. Are you referring to implementing PC generally, or implementing PC authorizations? Either way, this is purely down to the individual business and their strategy for its use. Unfortunately, there is no golden rule, although there are obviously certain best-practice approaches.
Comment From Guest: Are companies using Process Control to manage SOX IT general controls testing workflows?
Marc Jackson: Absolutely. Although not a SOX client, we have implemented automated monitoring of some of their key IT configuration controls, which helps them to be sure they continue to operate effectively at all times.
Comment From Guest: Are companies using Process Control for managing SOD mitigation approvals, mitigations, and periodic validations?
Marc Jackson: That functionality is already available within AC, but it is taking the next step to integrate with PC. We are looking at this with a current client — for example, identifying controls in PC as “mitigating controls” for use in AC when SOD conflicts cannot be resolved by removing access. This will give them scope to periodically test these controls using PC (either using manual test plans or automated monitoring, depending upon the nature of the control), so they can be sure that the SOD risk continues to be mitigated going forward. They may also look to use PC for “kicking off” periodic risk analysis.
Comment From Guest: May the authorization of the ICMAN be set for several other users to be able to update their Master Data?
Marc Jackson: You can replicate these auths in any role, as long as you know what objects/values are required. You could simply create a custom copy of the standard ICMAN role and assign that role to the other users (after having added the new role to the relevant entities and regulations in the related customizing activities).
Comment From Guest: The definition of “bribe” varies by company, industry, region, etc. Is this addressed in the solution or is it a universal definition?
Marc Jackson: The term “bribe” is unique to different organizations, but the area in general can be dealt with in PC by setting up a regulation (e.g., FCPA, UKBA, etc.) that deals with these issues, and have controls associated with these regulations to ensure your company “plays within the rules”. However, the content around what controls, etc., to have in place for anti-bribery and corruption does not come as standard, so you’ll need to implement that on your own.
Comment From Guest: Should we get all the authorizations together and only delimit the permissions a user has by the web-assigned responsibility?
Marc Jackson: No. Just restricting access at the entity level will not always be sufficient if you haven’t restricted access to certain objects in the user authorizations. For example, object GRFN_USER is very powerful and overrides the entity-level restrictions, so you need to be particularly careful with this one.
Comment From Abdul Hakim Khan: Can the Automated Controls from the previous version be leveraged, as I have done some one-to-one mapping?
Marc Jackson: Hi Abdul. Are you referring to the legacy automated monitoring rules, or do you mean automated controls from a previous release (which I assume would be the case if you were upgrading)?
Comment From Guest: When implementing Process Control, how “visible” should it be within the org? Should the implementation itself be used as a “message” internally or better to keep it hidden to average users?
Marc Jackson: I would say it should be extremely visible. The more “buy-in” you can get from the business the better, particularly as they will utilize it in some way, shape or form as part of their daily role.
Comment From Brian Merkel: Can you provide details pertaining to the new ticket-based authorization concept? How does the system determine the amount of time a user is allotted for this one-time access?
Marc Jackson: Hi Brian. I haven’t used ticket-based auths very extensively to date. However, I understand that it provides temp authorizations to complete and assign work items, once the work has been completed the temp auth will expire. So it seems that it is not time-dependent, since if the due date for the task expires but the task has not been completed, the ticket auths will remain active until the task has been submitted.
Allison Martin: Thanks again, everyone, for all your great questions. For more on this topic, I invite you to join us in Orlando at GRC 2014, where Marc will be presenting a session on this topic — part of our track on Continuous Monitoring and Process Control. We hope to see you in Orlando this March! And thanks again, Marc, for joining us today.
Marc Jackson: Thank you everyone for all of your questions. They provided a good range of discussion over the topic of authorizations in PC. I hope you found it useful. Please let me know if you have any further questions. For anyone online today who will be in Orlando, please feel free to say hi and we can take some of these discussions further. I’ll be on the Turnkey stand in the exhibition hall when not attending the sessions myself. I look forward to seeing as many of you there as possible. Thanks again.