In a global economy where compliance with various audit requirements and other regulations has become more and more challenging, role management and the design of security roles are garnering their share of attention. For SAP customers, common questions center around the parts that SAP Access Control and, to an extent, SAP Process Control play in streamlining and centralizing role management, as well as whether there is a preferred way to design SAP security roles.
To address this topic, insiderPROFILES recently invited PwC Director Peter Hobson to participate in a live Q&A on SAPinsider Online. Hobson is a Director at PwC in the SAP Security and Governance, Risk, and Compliance (GRC) practice for the New York metro region, where he has spent the last nine years delivering large-scale, global SAP security role design and SAP solutions for GRC implementations.
Following is an abridged version of Hobson’s Q&A.
The full transcript is available at http://bit.ly/hobsonPwC.
Q: What is your recommended strategy and roadmap for a global implementation of SAP solutions for GRC?
There is no single one-size-fits-all approach. A strategy differs based on the specific needs of an organization, so it is important to consider the requirements and expected benefits and tailor a roadmap accordingly. That said, a typical roadmap and one that I see many organizations pursue consists of three phases: The first is implementing SAP Access Control, with a priority on Access Risk Analysis (ARA) and Emergency Access Management (EAM). Second is an SAP Process Control pilot for a particular area, with a deployment of the remaining SAP Access Control functionality as necessary. Third is a deployment of SAP Process Control and an integration with SAP Access Control.
Q: Can you mitigate segregation-of-duties (SoD) violations within SAP Access Control, or do you need SAP Process Control?
You can use both. SAP 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 SAP Process Control. This will allow you to both document the mitigating control as well as monitor the performance and effectiveness of the control.
Q: What strategy would you recommend to avoid SoD conflicts when combining “display all” roles with an operative and access-restricted role? For example, displaying purchase orders for all organizations but with restricted access to create a purchase order for one organization.
There are a few options. The most important action is to limit display roles to transactions that are specifically intended to display information. This reduces exposure for unintentional access due to role combinations. With this done, determining “display all” roles while modifying only some roles comes down to properly scripting authorization objects. It’s important to use only display activities in display roles and update activities in modify roles.
Q: From a business point of view, what’s your recommendation for getting buy-in from all stakeholders for building roles?
The most important action is to limit display roles to transactions that are specifically intended to display information.
This depends on the stakeholder, and the message should be tailored accordingly. The three most common stakeholders in these initiatives are business, IT, and compliance. For the business, it’s important to focus on the efficiency gains and reductions in business downtime. For compliance, the focus should be on reducing risk exposure and implementing automated controls. For IT, the focus instead should be on how these efforts reduce the department’s administrative burden.
Organizations without a global practice can have difficulty getting business buy-in for building roles, but the clear-cut benefits should mitigate concerns. These include a reduction in business downtime that is sometimes created by access issues, a streamlining of audit and compliance activities that reduces time spent on investigation, and lower total cost of ownership (TCO) made possible by less administration and change management processes.
Q: What is the “enabler role concept?” Can you explain this model and how to maintain it during upgrades and support-pack updates?
I’m a big advocate of the enabler model, which I would explain in simple terms as the two pieces one should be concerned with when granting access to end users: What they can do and where they can do it. While task-based roles determine what users can do, enablers determine where they can do it. An example of the “what” could be maintaining purchase orders, with the “where” being a location, say, North America.
From a technical perspective, an enabler is an authorization-only role that grants access to the “where.” They are similar to derived roles except they have a one-to-many relationship with task roles. In its purest form, one enabler role grants the “where” access for all the “what” roles that a user has assigned to them. The enabler concept is simple to maintain and very transparent about what controlled information a user has access to. The model works well when going through upgrades — from an enabler perspective, the key activity when upgrading is to compare the objects in the enabler to the new objects the upgrade or support pack introduced to ensure the crucial ones are there.
Q: From a design perspective, what are the benefits of the enabler roles/task-based roles approach versus a traditional master/derived concept for task-based roles?
The task-based model will work in either 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 provide transparency and control over the organizational units that a user has access to. In a simplified example, North America access is granted via one role in the enabler model, and it is possible to identify who has access to North America by reporting on the users who have that one role assigned. In a derived model, it is necessary to assign multiple North America roles — one for each of the roles assigned — to ensure a user has complete access to North America. This also applies to de-provisioning — in the enabler model, you remove one role; in the derived model, you remove many.