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

SoD remediation methodology

SoD remediation methodology is designed to effectively remove SoD violations from an organizations environment. This methodology includes remediating GRC rulebooks that have been deployed in a companys 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 organizations GRC solution or utilizes extracted SAP security tables. By extracting the GRC security reports and/or SAP security tables and importing those tables into Suneras analytical solutions, Sunera is able to provide a holistic assessment of an organizations SAP and GRC environments.

Our approach leverages the companys 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 Suneras SoD Analysis DB Extract user usage data and import into Suneras SoD Analysis DB Evaluate SoDs (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

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.

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 Priority Category Primary Component Secondary Components

2 / 2011-12-13 Recommendations/additional info FAQ GRC-SAC-ARA Access Risk Management Summary

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 6 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

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

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.

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 customers 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 arent 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 GRAC_RA_RULESET_SAP_BASIS GRAC_RA_RULESET_SAP_ECCS GRAC_RA_RULESET_SAP_HR GRAC_RA_RULESET_SAP_NHR

SOD Rules Set SAP BASIS Rules Set SAP ECCS Rules Set SAP HR Rules Set SAP R/3 less HR Basis Rules Set

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 changes
SAP 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 SoD conflict. 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 companys 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