Thanks again to everyone who posted a question in our chat on SAP security roles. View the chat replay from our Q&A with Peter Hobson by clicking on the chat module, or read the edited transcript below.
Allison Martin, GRC 2014: I’m pleased to have PwC’s Peter Hobson here in this online chat today. Pete delivered a session on security role management and centralizing roles at our recent GRC 2014 event in Orlando.
We’re looking forward to today's Q&A, where Pete will post answers to your questions on designing SAP security roles, streamlining and centralizing role management, and the part that Access Control can play in all this as well.
Pete, it’s great to have you here. Thanks for joining us!
Peter Hobson: Thanks Allison. I'm very excited to be here. There's a ton of great questions already submitted. Will do what I can to get them all answered.
Allison Martin: Yes, it looks like our readers already have plenty of questions for you, so I’ll let you get to those now!
Comment From Guest
Can you mitigate SOD violations within AC or do you need to have Process Controls to mitigate violations?
Peter Hobson: You can use both. Access Control allows you to document your mitigating controls and link them to an identified risk within your SOD reports. You can take it a step further by integrating it with Process Control. That will allow you to not only document the mitigating control, but monitor performance and effectiveness of the control.
Comment From Sophie Poupart
From a business point of view, which argument should be use to get buy-in from all stakeholders?
Peter Hobson: Hi Sophie - an excellent question. Depending on the stakeholder you need to tailor the message in order to get buy in. The three most common stakeholders in these initiatives are business, IT and compliance. For the business, focus on the efficiency gains and reductions in business down time. For Compliance, focus on reducing risk exposure and implementing automated controls. For IT, talk about how these efforts reduce their administrative burden.
Comment From Tiru
How do you create the pfcg roles in SAP R/3 aimed at a mapping in SAP IDM in the future?
Peter Hobson: If you are considering IDM or another provisioning solution, then you need to think business friendly when designing your roles. Name them in a way that requestors can easily understand. From a more tactical perpspective, make sure to incorporate some identifiers to easily classify the roles. That gives you more ways to trigger approval paths and other functionality.
Comment From Claudia
What is the best strategy to avoid SOD conflicts when combining "display all" roles with an operative and access restricted role? Ex: display POs for all organizations but restricted to create PO to only one organization.
Peter Hobson: Hi Claudia - There's a few things you can do. The most important is to limit display roles to only transactions that are specifically intended to display information. That reduces your exposure for unintentional access due to role combinations. Once you've done that, then determining display all while modifying only some comes down to properly scripting your authorization objects. Make sure that you use only display activities in your display roles, and update activities in you modify roles.
Comment From Capps
What are your thoughts on the enabler role concept and maintenance of the concept during upgrades/support packs?
Peter Hobson: Hi Capps - I'm a big advocate of the enabler model. I find it simple to maintain and very transparent about what controlled information a user has access to. The model works just fine when going through upgrades. The key activity from an enabler perspective when upgrading is to compare the objects in the enabler to the new objects introduced by the upgrade/support pack to ensure all the necessary ones are there.
Allison Martin: Pete, could you clarify what you are referring to when discussing the "enabler model"?
Peter Hobson: Absolutely, Alison. I would put it like this - when granting access to an end user, there are two items you are concerned with - what they can do and where they can do it. Task based roles determine what a user can do. Enablers determine where they can do it. An example would be maintain purchase orders (what) for North America (where).
From a technical perspective, an enabler is an authorization only role that grants access to the "where". They are similar to derived roles except that they have a one to many relationship with task roles. In its purist form, one enabler role grants the "where" access for all of the "what" roles that a user has assigned to them.
Comment From Nilesh
How can we resolve SOD conflicts?
Peter Hobson: Hi Nilesh - I'd be glad to answer this question but there are a few ways it can go. Would you be able to provide me a few more details so I can give you a better response?
Comment From Vic
From a security role design perspective, if a midsize company that is looking to add additional companies / org structures and were looking to redesign authorization roles to be more flexible and allow for additional SAP upgrades, what design strategies would you suggest for the new redesign?
Peter Hobson: Hi Vic - if your goal is flexibility then my recommendation would be a task based role design. The roles are very granular and specific to system tasks, or steps in a process. Think "Vendor Maintenance" or "Purchase Order Maintenance". Building the task based roles gives you the flexibility to provision / de provision the exact access a user needs to perform their job responsibilities. Tasks are also very scalable across locations and business units.
Comment From Curt
From your excerpt, you mention enabler roles and task based roles. From a design perspective what is the benefit/efficiencies of this approach vs. a traditional Master/Derived concept for task based roles?
Peter Hobson: Hi Curt - the task based model will work in both an enabler or derived role model. Implementing enablers provides a number of efficiencies. For example, enablers typically lead to a lower total role count when compared to derived roles. This is because they are built on a one to many relationship with a task role, rather than the one to one relationship of derived roles. Additionally, they give you transparency and control over the org units that a user has access to. In a simplified example, North America access is granted via one role in the enabler model.
You can identify who has access to North America by reporting on the users that have that one role assigned. In a derived model, you will need to assign multiple North America roles - one for each role assigned - to ensure a user has complete access to North America. Same goes for de-provisioning - in the enabler model you remove on role; in the derived model you remove many.
Comment From Alex Sousa
We are using AC 5.3 (all four modules) and planning a tool migration for 10.1. We´d like to know if there a SAP tool to import / export data form CUP/RAR, etc.
Peter Hobson: Hi Alex - yes GRC 10.1 comes with an upgrade tool that will migrate your existing GRC 5.3 data into 10.1. One thing to note - it doesn't carry over 100% of the data. An example would be CUP workflows - you will need to recreate these in GRC 10.1, even if you use the migration tool. SAP provides documentation on what the migration tool does and does not bring from GRC 5.3 to 10.1. Take a look through those details, then plan accordingly to address the gaps.
Comment From Neal
Are composite roles still the way to go or is it better to stick with just single roles?
Peter Hobson: Hi Neal - my recommendation is to leverage single roles whenever possible. If you are going to use composite roles, then my advice is to use them at the right times - large volumes of roles for large volumes of users.
Another thing to consider when evaluating composites - many of the leading automated provisioning tools, such as GRC Access Control, provide ways for you to define "virtual" composite roles. These gives you many of the benefits of composite roles without the negatives.
Allison Martin: Thanks to everyone who has submitted a question! We will try to answer as many as possible before the chat ends at 1:30. Thanks!
Comment From Jamie
If you need to migrate from Virsa Compliance Calibrator 4.0 to Access Control 10.x, what is the recommended path for updating the SOD ruleset? Start from scratch based on 10.x or improve the old ruleset first?
Peter Hobson: Hi Jamie - Great question, and the answer depends on how well you have maintained the rule set over time. If you feel the rule set has been well maintained and is still relevant to the way you run your busines, then bring it over. If not, then start over and build a new rule set that is specific to the processes and risks of your organization.
Comment From Elisabeth
I've seen some presentations at GRC conference where an IDM system was taking user ID requests then parceling out to GRC and some that were vice versa -- request submitted in GRC and a portion of it sent to IDM. Which do you recommend?
Peter Hobson: Hi Elisabeth - this depends on which application you want to have as the "face" to your end users. In my experience, one of the big drivers for IDM-GRC integration has been to provide a single, common location for all access requests - both SAP and non-SAP. IDM applications play this role better than GRC, and therefore you typically see IDM be the application where requests are submitted.
Comment From Jamie
In your example of Vendor Maintenance role, would this combine several/many transactions?
Peter Hobson: Hi Jamie - yes, in that example you would group multiple transaction codes that perform vendor maintenance in the same task role. For example, the vendor maintenance role may include XK01, XK02, FK01 and FK02. The guiding principle is to group transactions into roles that perform similar tasks, and that you are alright with a user that receives that role receiving all of those transactions.
Comment From Luis Torres
We are in the global design stage of SAP implementation and we need to prepare the strategy and roadmap for GRC implementation, i.e. 1)access control, 2)process controls, 3)GST, etc. Kindly share you thoughts on this.
Peter Hobson: Hi Luis - it is different for everyone based on the needs of you organization. Make sure to carefully consider your needs and the benefits you are looking to receive, then tailor your roadmap accordingly.
That being said, the typical roadmap we see organizations pursue is the following:
- Phase 1 - Implement GRC AC, at a minimum ARA and EAM, sometimes ARM and BRM
- Phase 2 - Pilot GRC PC for a particuarly area, deploy remaining AC functionality, if needed
- Phase 3 - Deploy GRC PC, integrate GRC PC and AC solutions.
Typically, I see GTS follow a different path not linked to AC and PC.
Comment From Sophie Poupart
If SU24 wasn’t maintained for transactions and authorization object were added manually to the roles, how do we define the relevant objects for a specific transaction or group of transactions?
Peter Hobson: Hi Sophie - this is a tough situation. Looking at your other questions, it sounds like you are considering a role redesign effort. If that is the case, then the best way to identify the linkages between transaction codes and authorization objects is through effective unit testing of the roles. Unit testing each transaction code to completion will help you identify the missing authorization objects. Link them to the transaction code in SU24 and you have that information captured for future security testing efforts.
Comment From Guest
What is the best practice for role re-design? Our implementation partner had pre-defined roles that we adopted. What we are finding is these pre-defined roles have several more transaction codes than we need and are causing more risks to show up in the risk analysis. What is the best way to handle this?
Peter Hobson: Hi - My recommendation is to never implement pre-defined roles without performing a thorough review with the business. Pre-defined roles are an excellent starting point, but no two organizations are alike. Use the pre-defined roles to accelerate the process (it's better to start with something than nothing) then work with your business, functional and technical leads to refine the role specifications to meet your organization's requirements.
Comment From Alex Radford
Building roles for an organisation that doesn't have global practices is very challenging. Often getting business buy in is the key. In your experience what 3 points would you stress to add weight to the argument of role redesign? Ultimately the business only responds when you talk money or audit.
Peter Hobson: Hi Alex - here's my thoughts:
1. Reduction in business down time - better roles means less time lost by the business due to access issues
2. Streamlined audit / compliance activities - better roles mean less time spent investigating and resolving audit / compliance issues
3. Lower total cost of ownership - the right role design requires less administration and change management. That frees up resources to focus on other, more value add activities.
Allison Martin: Thanks again, everyone, for all your great questions. GRC 2014 attendees can download Pete’s full presentation.
For more on this topic, I invite you to join us at GRC 2014 in Nice this May, where Pete’s colleague Scott Enerson of PwC will be hosting a two-part session on SAP ECC security and design and SAP Access Control.
Peter Hobson: Hey everyone - looks like we are out of time. Thanks so much for joining! Your questions were fantastic. Feel free to contact me directly at firstname.lastname@example.org with any further questions.
Allison Martin: Thanks again, Pete!