What is Role Remediation in SAP Access Control?

Role Remediation refers to the measures, to address the SOD (segregation of duties) conflicts associated with the Roles in the ERPs.

For example, an SOD Conflict / risk which is associated with a single role, can be removed (remediated) by splitting into two different roles, if it is feasible. This is one way of remediation of the role.

Where ever it is not possible to split the roles or remove the roles from the system, a mitigation control can be identified for such SOD risk associated with the role, to reduce the impact to some extent ( mitigation control is generally defined in such a way that some user in the system would be monitoring the usage of such role on a periodic basis). This is one more way of remediation. Defining the mitigation control depends on the criticality of the SOD risk, as maintaining mitigation controls involves efforts and cost.

One more way is to give access to such role through super user access (if the usage of the role is not regular).

The best practice in the remediation would be to start with the single roles remediation as it automatically removes the SOD violations in the composite roles as well as violations associated with the users with such roles.

When ever there are SoD Conflicts in a role, there are 2 ways for addressing these SoD risks.

a) Role Remediation - Removing the t-codes which are conflicting in nature from the role and ensuring role is SoD free

b) Role Mitigation - Even though there are SoD conflicts, these t-codes might be necessary for that particular role to perform the business function. In this scenario, mitigation controls will be provided by the business management to address the SoD conflicts identified. Here t-codes will be retained in the role but conflicts will be addressed in GRC through Mitigation Controls

1

SoD remediation methodology

SoD remediation methodology is designed to effectively remove SoD violations from an

organization’s environment. This methodology includes remediating GRC rulebooks that

have been deployed in a company’s organization, evaluating SoDs and defining actionable

recommendations that remove SoDs from the user community, and redesign security roles

within SAP to remove inherent violations and shared authorization issues. In addition, our

methodology leverages the SoD reporting from an organization’s GRC solution or utilizes

extracted SAP security tables. By extracting the GRC security reports and/or SAP security

tables and importing those tables into Sunera’s analytical solutions, Sunera is able to

provide a holistic assessment of an organization’s SAP and GRC environments.

Our approach leverages the company’s process, procedures, GRC tools (if deployed), and previous successes. By doing so, our time is spent on what we were engaged to do: removing SoDs and assisting the companies with decreasing fraudulent and financial reporting risk. To do this we:

• Extract existing GRC analysis results or export SAP security tables

• Import extracted data into Sunera’s SoD Analysis DB

• Extract user usage data and import into Sunera’s SoD Analysis DB

• Evaluate SoD’s (based on business risks or industry best practice risks) and group violations into remediation categories (inherit role violations, likely shared authorized violations, and job responsibility violations).

To remediate the identified and remaining violations, we have developed two methods (Role Remediation and Role Redesign). The Role Remediation method approach is best suited for organizations that have a strong role design structure and need minimum changes to roles. The Role Redesign method is best suited for organizations who have significant flaws/weaknesses in the role design or who have continued struggles with provisioning user access privileges. Both methods have been designed to remove SoD violations from the roles allowing an organization to extend access privileges to authorized users without increasing risk to the company.

In addition, our methodology facilitates the actions needed to determine whether users should have the access permissions associated with their job responsibilities.

• Develop an actionable remediation project plan including project objectives and cost

• Identify proposed remediation actions and path of compliance

• Prepare prioritized remediation plan and proposed solutions

•

2

How to remediate issues with Segregation of Duties

1. You need a set of rules to run your SOD's against - regardless of whether

it is manually done or using an external tool. If you client do not have

confidence in the rule set that is being used then what on earth do they

think they are doing by placing reliance on it? Any rule set must be tailored

to the clients key risks and they must focus on this asap before you do

anything else. If this is linked to your post about implementation of GRC,

then before you start running any analysis etc, get the rule set out to the

business and get them to ID what risks are material to them and base your

reporting on that.

Once the rules are identified (at the most basic level create functions that

represent sets of activities, map tcodes to those functions. Business then

ID's which functions are in conflict e.g. AP processing & vendor

maintenance). You can then analyze your single role contents against these

conflicting functions (very boring if you are doing it manually) and then ID

role combinations that should not be grouped together. This is how SOD's

have traditionally been done and is how the tools work.

2. Take the matrix that you have done in point 1 and apply that to your new

roles.

3. It depends on the company, the situation, the ability of the admin. If

you have a good understanding of business process risks and understand your

clients business processes then the security admin could be running most of

this. If not then sec admin typically performs the analysis and lets people

from the business choose what they want to do with it.

4. As above, it depends on the ability/knowledge/experience of the security

admin. Personally I believe the security admin should be able to take a set

of business requirements and translate them into the technical restrictions

built into the roles.

5. Usually internal audit or an equivalent risk management team

6. If you are doing it manually, job roles (assuming that they are SOD free)

can make it easier to assign, especially if you have policy of only 1 job

mapped to a user at a time. On the flip side, if company combines job roles

for a user, there are usually lots of SOD's. If the client only have 100

roles now, then in reality the practical differences between a task based

design (as much as I dislike them) and job based design are minimal. Task

based approach + an incompatible role matrix could be easier to manage in

long term if there is no investment in a tool. If you are going through the

3

process then I would seriously recommend looking at a tool to help. CSI

authorization auditor is an excellent product at a very reasonable price.

7. SAP are not experts in risk management and SOD's (though they do have a

few who know their stuff).

For SME's there needs to be a pragmatic approach that focuses on the really

important risks to the company. This is an area that you should work with

the internal and external auditors to agree on the scope. Traditionally,

generic rule sets provided by vendors are designed for large companies where

good SOD can be achieved through having lots of people to share activities

between. In this case it is really important to focus on only the key risks

to avoid paralyzing the business by coming up with recommendations that

cannot be realized.

4

Note 1600667 - Transactions that conflict with themselves - See more at:

http://www.stechno.net/sap-notes.html?view=sapnote&id=1600667

#sthash.1pZFbRA2.dpuf

Version / Date 2 / 2011-12-13Priority Recommendations/additional infoCategory FAQPrimary Component GRC-SAC-ARA Access Risk ManagementSecondary Components

Summary

5

Symptom

A transaction code is shown as conflicting with itself. This note provides an explanation of why transaction codes may conflict with themselves.

Other terms

rule, action, permission, ruleset files, Risk Analysis and Remediation, Access Risk Management, function, delivered rules, conflict, risk

Reason and Prerequisites

Certain SAP transactions allow users to perform multiple functions which can be inherent segregation of duties risks.

Solution

In the SAP delivered ruleset, there are currently 15 transactions that conflict with themselves. For some of these transactions, there are security authorization objects that can be used to limit the transaction to one function. For these transactions, the permissions enabled in the functions they're included in are different. Therefore, for these, it is possible to segregate in the system by setting the authorization objects appropriately in order to remove the segregation of duties risk.

For other transactions, there is no way to limit the transactions through authorization objects so that they can only perform one of the functions. For these transactions, there is no way via security to remove the segregation of duties risk. In these cases, the only option is to apply a mitigating control to the risk.

An example would be for risk F028 and transaction code F-02. A mitigating control would be for someone to run a report of manual journal entries and review periodically to determine whether any manual journal entries were made inappropriately.

The exact transactions that conflict with each other are listed below:

• Risk BO19: Function BS13 - Maintain User Master and Function BS14 - Maintain Profiles / Roles

• PFCG - Permissions are different, can segregate by security

• Risk F027: Function FI08 - Create / Change Treasury Item and Function FI09 -Confirm a Treasury Trade

• TM_65 - Permissions are different, can segregate by security

• Risk F028: Function AP02 - Process Vendor Invoices and Function GL01 - Post Journal Entry

• ACACACT - Permissions are not different, mitigating control required

• ACEREV - Permissions are not different, mitigating control required

• F-02 - Permissions are not different, mitigating control required

• FB01 - Permissions are not different, mitigating control required

• FB01L - Permissions are not different, mitigating control required

• FB02 - Permissions are not different, mitigating control required

• FBRA - Permissions are not different, mitigating control required

• FBV0 - Permissions are not different, mitigating control required

6

- See more at: http://www.stechno.net/sap-notes.html?view=sapnote&id=1600667#sthash.1pZFbRA2.dpuf

7

What is SAP Business Objects Risk Analysis and Remediation (RAR)?

Risk Analysis and Remediation (RAR) is the core module of SAP's BusinessObject Access

Controls suite. Its primary function is to support the management of Segregation of Duties

(SoD) controls and monitor Critical Transactions across an ERP system. RAR holds the rules

for what is deemed to be a risk to the business.

Using RAR you can produce analytical SoD reports on selected users, user groups, roles and

profiles and can also produce reports on critical actions, critical permissions, critical roles

and profiles. This is all based upon the rules defined within the tool.

RAR is designed to allow all key stakeholders to work in a collaborative manner to achieve

ongoing SoD and audit compliance. Risk analysis reports provide real-time data and

Management reports retain an offline history of SoD status. RAR also has Simulation

features to allow you to assess the impact of potential remediation activities on the

reported conflicts prior to making the actual change.

8

SAP GRC 10.0 Risk Configuration steps

SAP has made it is easy for collecting the Customizing settings by processes into Business

Configuration Sets (BC Sets). BC Sets make Customizing more transparent by documenting

and analyzing the Customizing settings. This also helps the when the company wants to go

live by specific subsidiary or location.

BC Sets are provided by SAP for selected industry sectors, and customers can also create

their own.

When you create your BC Set the configuration settings are copied into BC Set Tables.

Then when these BC Sets are activated the configuration settings are copied into the

customer’s tables. The BC Sets have to be transported into the customer system in which

Customizing is performed.

SAP GRC 10.0 BC Sets populate the IMG data. In the GRAC_RULESET* tables these

populate the proposed SAP SOD Rule set. When you review the SAP GRC 10.0

Documentation you can find the section to activate the GRC Rule sets.

Key Steps:

Execute transaction SCPR20

Activate GRAC* and GRC* BC sets

Use caution when activating Rule Sets. Only activate IF using the default & only activate

rules for systems you are using

You aren’t really generating the BC set (hence why post-implementation guide does not

tell you to do this). You are actually working through the SAP GRC Risk Analysis and

Remediation configuration setup.

GRAC_RA_RULESET_COMMON SOD Rules Set

GRAC_RA_RULESET_SAP_BASIS SAP BASIS Rules Set

GRAC_RA_RULESET_SAP_ECCS SAP ECCS Rules Set

GRAC_RA_RULESET_SAP_HR SAP HR Rules Set

GRAC_RA_RULESET_SAP_NHR SAP R/3 less HR Basis Rules Set

9

GRAC_RA_RULESET_SAP_R3 SAP R/3 AC Rules Set

Once you have activated the rule set you need to generate the SAP GRC rule set for the

rule set to be active in the system. The rule set provided in the default rule set from SAP.

Now you have to export the rule set and work with your internal auditors, and functional

teams to see if risks are valid for your company business process.

Challenge with SAP SOD

Most corporations, when designing their SAP Security roles, do not consider the SAP SOD

implications on role design. Most users will have excessive access leading to numerous

SOD violations. Untangling the SOD web becomes very difficult as this situation goes on for

many years. Since training and testing also depend on role design, if the SAP SOD needs to

be cleaned up, then the training curriculum and testing scripts will also be affected.

10

SAP GRC –Updating SOD Matrix with any custom transactions and custom object level changesSAP systems have some custom transactions which are created by the companies to mask the sap transactions or create new transactions. These custom transactions will miss the Segregation duties matrix (SOD) since they have to be manually updated. When we run the SOD analysis it will miss the transaction and will not flag them a risk. These transactions should be part of SOD matrix. Since it not part of SAP defined SOD matrix. For example if you are copying transaction XK02 and create transaction ZXK02 to mask some of the fields in the screen. This transaction has same functionality as update vendor master but is hiding as custom transaction. You could do this with transaction variants or create a custom screens. The transaction can perform the same functionality. The SOD analysis will miss this transaction since the custom transaction is not in SOD matrix. The best way to update this transaction is find the similar transaction or transaction which has similar functionality. Then update the functional group with this custom transaction. In addition to updating the transaction also update the SU24 with the relevant objects and object values for the custom transaction.

OneAccess-UserManager also helps you manage the complex documenting, testing, process control, and sign-off requirements mandated by Sarbanes-Oxley sections 302, 404, and 409

Selva Kumar

Vice President- SAP Practice

OneAccess-UserManager for SAP

SAP Certified-Powered by Netweaver

http://www.softsquare.biz/oneaccess/

selva@softsquare.biz

Phone: 1 877 717 5487

Automate and Meditate

11

SAP SoD Rule Set Overview

S

A

P

S

o

D

R

u

l

e

S

e

t

O

v

e

r

v

i

e

w

An SAP SoD Rule set, is a set of segregation of duties risks that come standard with the SAP GRC tool. This rule set is compared to the SAP security setup to find out how many rules have be violated within the roles and users. This will give an idea about the depth of the problem. This may not be the true picture as the rule set is not customized to the particular company. There may be certain risk which may not be applicable to the company and there may be other which needs to be added.

12

SAP Compliance Sensitive transaction

SAP Risk Mitigated Users

SAP-Risk-Executions-and-Details

SAP SoD rule set is comprised of 3 major components: Risks, Functions, and

Authorizations.

Risk: Combination of two functions when granted to a single user cause a SAP SoDconflict. This could be combination of two transactions or more.

Function: The group of transactions which can perform a similar task. For example

13

create vendor master which can be performed through multiple transactions. These transactions are grouped into functions.

Authorizations: The specific transactions and associated authorization objects a user must have to perform the process task. If the analysis is done just at the transaction level then there will be lot of false positives. This is because you will now know the true SAP SOD risk unless the analysis is done to ascertain that the underlying authorizations are also available for the user to perform the task

To create a risk, we need to identify the two conflicting functions and the group of transactions with these functions will create a risk.

SAP SoD Rule set validation

SAP GRC Rule set is not tailored to any single industry or organization. Instead, it has been developed along standard SAP business processes and transactions that represent industry best practices. Therefore, the results of the report which come from the initial analysis with the standard out of the box rule set may not give you what is required for your organization. But generally speaking most of the clients I have implemented GRC are fine with the SAP Standard rule set. The one exception to that will be the government sector. The SAP GRC rule set does not have transactions related to government sector mainly in the budgeting area. One other thing the clients have to work on is adding the custom transactions that may exists within SAP environment and this may result in non-reporting of SAP SoD conflicts caused by these custom transactions

SAP SoD Results Validation & Reporting Process

Once company’s SAP Security environment is assessed against the SAP SoD standard Rule set the report needs to be validated with the functional process owners within the implementation team.

Pick sample users from each functional area and look at the SAP SoD report for the risk violations for those users

Now run the same analysis within SAP using data from the table or SUIM transaction to validate if the SAP SOD conflict occurs within those users. This is for independent validation if the SAP SOD report is giving the right data. The risk from report will be lower as the SAP SOD rule set has not be updated with custom transactions

14