GRC
HR
SCM
CRM
BI
Expand +


Article

 

Why Implementing SAP Access Control Alone Is Not the Panacea to Your SAP Security Issues

by Alex Joseph, Practice Manager, SAP GRC, itelligence Inc.

August 21, 2012

See how a railroad company redesigned its SAP security roles to ensure that these roles align with its internal controls pertaining to segregation of duties.

 

Many companies implement SAP Access Control to address concerns they have around rampant segregation of duties (SoD) issues across their enterprise. Companies hope to remediate these SoD issues by analyzing the current violations and mitigating access risks by redesigning their SAP security roles, mitigating access risks with adequate compensating controls, and preventing future violations by proactively monitoring changes to user access in the future. Companies also are looking at streamlining their user provisioning process by automating the process while monitoring access risks and ensuring proper approvals are obtained.

What many companies do not realize is that these efforts might be stymied because of a suboptimal role design in their SAP systems. If companies don’t address the underlying role design, remediating existing violations and implementing an automated tool for user provisioning become a Sisyphean effort.

I illustrate via a case study how a major railroad company redesigned its SAP security roles and implemented the full suite of SAP Access Control in 16 weeks to get to a clean state.

When a leading provider of railcars and freight car management services decided that it needed a tool to continuously monitor critical access and SoD violations in its user provisioning process, it chose SAP Access Control for its depth of functionality and proven leadership in the enterprise GRC space. The company’s decision to implement SAP Access Control was made as part of its commitment to improving its internal controls environment.

After being live with SAP ERP for more than 12 years, the company, like many other companies at a similar maturity level with SAP applications, found that its SAP security landscape was not aligned with its desired level of internal controls around SoD. Users had accumulated access over the years, and there was a disconnect between what users actually needed to perform their jobs versus what they were provisioned with within SAP systems. The company decided to implement SAP Access Control so that it could manage and reduce access risk across the enterprise by preventing unauthorized access being granted and achieving real-time visibility to access risks.

Simply implementing an automated tool to monitor access risks does not magically cure a pre-existing condition in which users have accumulated access over the years. Following a systematic Get Clean, Stay Clean, Stay in Control implementation methodology helps reduce the cycle time required to get to a point where the company has eliminated avoidable SoD conflicts and has put in effective compensating controls for the unavoidable SoD conflicts.

(Note: Avoidable SoD are the conflicts that exist for a given user because of the access they have accumulated over the years owing to an inflexible role design.)

Many companies implement SAP Access Control, analyze their existing users and roles for SoD, and then stop dead in in their tracks because they are so daunted by the sheer number of conflicts they face. Remediation of SoD at the user and role level is not a task that many companies want to take on because of the challenges it poses. Companies quickly realize that a lot of the access the users have accumulated over a period of time is due to one fact — a suboptimal role design that is inflexible and does not allow the business to provision users with exactly the access they need and no more. Roles that have been designed around job positions rather than granular tasks are especially prone to this problem.

For the railcar management company that was implementing SAP Access Control, redesigning its security roles from scratch was not an option given the limited number of business and IT resources available and the tight timeline it faced. The company decided to leverage the preconfigured, SoD-free roles that its implementation partner was able to deliver. The preconfigured, task-based roles were designed in a way that grouped all the relevant transactions for a particular task together in a single role. The authorizations for the role were also preconfigured to meet the most common business requirements. The roles were also created in two different namespaces to reflect if the role contained Sarbanes-Oxley-sensitive transactions or not – for example, CTSD:SALES_ORDER_PROCESSING containing Sarbanes-Oxley-sensitive authorizations for sales order processing versus Z:SD_MAINTAIN_INQUIRIES containing authorizations for non-Sarbanes-Oxley-sensitive authorizations for inquiry or quotation processing.

Separate roles were also delivered for tasks such as credit management even though the underlying transactions for sales order processing and issuing a request for a credit memo are the same within an SAP system (i.e., VA01, VA02). The roles were configured down to the authorization object level to allow for separation between the document types for each process (e.g., OR versus CR/DR).

Another good example is within the finance process stream in which the same transactions can affect postings within AP, AR, GL, and Asset Accounting. All the possible transactions that allow a user to post manual entries are grouped in a single role and then configured at the authorization object level for account type to achieve separation within payables and receivables. Because the roles are preconfigured, all you have to do is upload them into the SAP system. After users upload the roles into the system, they can view documentation such as the text shown in Figure 1.


Figure 1
A preconfigured, task-based role that is free of SoD violations

All the roles are also fully documented so that the business clearly understands what access is being provisioned. Figure 2 shows a role menu for preconfigured, task-based roles.


Figure 2
The role menu for a task-based role

All transactions that allow manual postings are grouped in the same task-based role. Because all the single task-based roles can perform only one task (albeit in many different ways), there are no inherent SoD issues within the single role. The role is also preconfigured at the organizational level for Account type K (for vendors) to restrict its ability to payables (Figure 3). By drilling into the organizational level authorizations for the task-based role in the example above, you can see how the role has been preconfigured for Account Key.


Figure 3
The organizational level configuration in the authorizations for a task-based role

Getting to a Clean State

The first step toward getting to a clean state is remediating the SoD that exists within your existing SAP security roles. If you don’t complete this step, remediating SoD at a user level is nearly impossible. The railroad company was able to use custom reports (Figure 4) to remediate all avoidable SoD violations in parallel to the implementation of SAP Access Control. This step ensured that only necessary or unavoidable SoD violations remained and were reported on after SAP Access Control went live.


Figure 4
A custom report generated using a Microsoft Access tool that aggregates user access and describes it in terms of business processes. The E indicates that one or more transactions within the task were executed (based on information stored in the STAD tables).

To remediate SoD at the role and user level to get to a clean state, follow a process known as user access review. In this process current user and role information is extracted from the SAP system and custom reports are created. User access review functionality is natively available in SAP Access Control. You do not need the custom reports once the system is live.

(Note: The railroad company ran the user access reviews in parallel to the SAP Access Control implementation to clean up all avoidable conflicts prior to go-live. This step helps reduce the number of SoD conflicts even before the SAP Access Control system is live.)

This process consists of three steps:

Step 1. Review each process stream that provides managers with a view of what access their users currently have. This user access is aggregated in terms of business processes rather than SAP transaction codes and displayed in the report. This step helps the reviewer truly understand what access has been provisoned in terms of business processes, and they don’t have to pore over reams of redundant data.

The E in the Exec column indicates if the user has executed any transaction within a given business process or task. The reviewer indicates in the Y/N column if the user should retain this access or if access needs to be revoked.

The reviewer has the option to drill into any business process to verify which transactions are contained within it. For example, Figure 5 lists transactions that are causing a user to receive access to the Maintain GL Master Data at Chart of Account level business process or task. This list is part of the custom report.


Figure 5
Transactions for access to the Maintain GL Master Data at Chart of Account level business process or task

Step 2. Once the managers or reviewers have completed their reviews, the security team maps users to the new preconfigured, Sarbanes-Oxley-ready clean roles. The users retain the exact same access they currently have minus access that was revoked as part of the user access review (step 1). The preconfigured roles are enhanced to meet any organizational level (e.g., company code, plant, or sales area) or field level (e.g., document types, movement types, or authorization groups) restrictions that are currently in place. This information is downloaded from tables AGR_1251 and AGR_1252 and then mapped to the new roles using a custom program.

Step 3. By running the SAP Access Control project and the SAP security redesign project in parallel, the railroad company was able to time it in such a way that both projects went live at the same time. The company now is able to run batch risk analysis on the users mapped to the new roles using SAP Access Control. The resulting report is now actionable because the security team sees only SoD caused because of users being assigned to two distinct task-based roles. The number of conflicts to be addressed is also greatly reduced because the user access review step ensures that users only have the access they truly require. The compliance team can now decide if it wants to remediate the SoD violation by revoking access to specific task roles, or if the SoD is unavoidable, the compliance team can assign appropriate mitigating controls in SAP Access Control.

An email has been sent to:





 

Alex Joseph

Alex Joseph is an SAP GRC practice manager at itelligence. He has more than 11 years of broad SAP experience across multiple industry verticals and SAP applications, including SAP security, GRC, logistics, and SAP Global Trade Services.



COMMENTS

Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!


SAPinsider
FAQ