You are on page 1of 14

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


procedures. The Role Remediation method approach is best suited for organizations that have a strong role design structure and need minimum changes to roles. By doing so. and previous successes. In addition. • • • • 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 . 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. This methodology includes remediating GRC rulebooks that have been deployed in a company’s organization. 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. our time is spent on what we were engaged to do: removing SoDs and assisting the companies with decreasing fraudulent and financial reporting risk. evaluating SoDs and defining actionable recommendations that remove SoDs from the user community. 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. To remediate the identified and remaining violations. and job responsibility violations). our methodology leverages the SoD reporting from an organization’s GRC solution or utilizes extracted SAP security tables. In addition. we have developed two methods (Role Remediation and Role Redesign). and redesign security roles within SAP to remove inherent violations and shared authorization issues. Sunera is able to provide a holistic assessment of an organization’s SAP and GRC environments.SoD remediation methodology SoD remediation methodology is designed to effectively remove SoD violations from an organization’s environment. Our approach leverages the company’s process. our methodology facilitates the actions needed to determine whether users should have the access permissions associated with their job responsibilities. GRC tools (if deployed). By extracting the GRC security reports and/or SAP security tables and importing those tables into Sunera’s analytical solutions. likely shared authorized violations.

then in reality the practical differences between a task based design (as much as I dislike them) and job based design are minimal.g. AP processing & vendor maintenance). 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.How to remediate issues with Segregation of Duties 1. especially if you have policy of only 1 job mapped to a user at a time. it depends on the ability/knowledge/experience of the security admin. if company combines job roles for a user. If the client only have 100 roles now. 3. As above.regardless of whether it is manually done or using an external tool. On the flip side. there are usually lots of SOD's. If you are going through the 3 . It depends on the company. This is how SOD's have traditionally been done and is how the tools work. the situation. If you are doing it manually. Usually internal audit or an equivalent risk management team 6. then before you start running any analysis etc. 5. the ability of the admin. 4. Task based approach + an incompatible role matrix could be easier to manage in long term if there is no investment in a tool. 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. 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. Business then ID's which functions are in conflict e. Once the rules are identified (at the most basic level create functions that represent sets of activities. 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. job roles (assuming that they are SOD free) can make it easier to assign. If not then sec admin typically performs the analysis and lets people from the business choose what they want to do with it. 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. Take the matrix that you have done in point 1 and apply that to your new roles. You need a set of rules to run your SOD's against . 2. map tcodes to those functions.

4 . Traditionally. 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. This is an area that you should work with the internal and external auditors to agree on the scope. 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. CSI authorization auditor is an excellent product at a very reasonable price. For SME's there needs to be a pragmatic approach that focuses on the really important risks to the company. SAP are not experts in risk management and SOD's (though they do have a few who know their stuff). 7.process then I would seriously recommend looking at a tool to help.

net/sap-notes.Transactions that conflict with themselves .See more at: http://www.dpuf Version / Date Priority Category Primary Component Secondary Components 2 / 2011-12-13 Recommendations/additional info FAQ GRC-SAC-ARA Access Risk Management Summary 5 .html?view=sapnote&id=1600667 #sthash.1pZFbRA2.stechno.Note 1600667 .

mitigating control required FB01L .Post Journal Entry • • • • • • • • ACACACT .Permissions are not different.Process Vendor Invoices and Function GL01 .Permissions are different.Permissions are different. For some of these transactions. Access Risk Management.Permissions are not different. Solution In the SAP delivered ruleset. 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. ruleset files. conflict. An example would be for risk F028 and transaction code F-02. mitigating control required FBRA .Permissions are not different. This note provides an explanation of why transaction codes may conflict with themselves. mitigating control required ACEREV . In these cases. mitigating control required FBV0 . function. the only option is to apply a mitigating control to the risk. permission. For these transactions. there is no way to limit the transactions through authorization objects so that they can only perform one of the functions. it is possible to segregate in the system by setting the authorization objects appropriately in order to remove the segregation of duties risk.Permissions are not 6 different. For these transactions. there is no way via security to remove the segregation of duties risk. mitigating control required F-02 .Maintain Profiles / Roles • • PFCG . there are security authorization objects that can be used to limit the transaction to one function.Permissions are not different. For other transactions.Create / Change Treasury Item and Function FI09 Confirm a Treasury Trade • TM_65 . Risk Analysis and Remediation.Maintain User Master and Function BS14 .Symptom A transaction code is shown as conflicting with itself. action. mitigating control required FB02 .Permissions are not different. can segregate by security Risk F027: Function FI08 . there are currently 15 transactions that conflict with themselves. delivered rules. mitigating control required FB01 . the permissions enabled in the functions they're included in are different.Permissions are not different. Other terms rule. mitigating control required . for these. Therefore.Permissions are not different. can segregate by security • Risk F028: Function AP02 . risk Reason and Prerequisites Certain SAP transactions allow users to perform multiple functions which can be inherent segregation of duties risks. The exact transactions that conflict with each other are listed below: • Risk BO19: Function BS13 .

See more at: http://www.stechno..dpuf 7 .html?view=sapnote&id=1600667

8 . RAR holds the rules for what is deemed to be a risk to the business. user groups. RAR is designed to allow all key stakeholders to work in a collaborative manner to achieve ongoing SoD and audit compliance. 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.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. critical permissions. This is all based upon the rules defined within the tool. critical roles and profiles. roles and profiles and can also produce reports on critical actions. Using RAR you can produce analytical SoD reports on selected users. Its primary function is to support the management of Segregation of Duties (SoD) controls and monitor Critical Transactions across an ERP system. Risk analysis reports provide real-time data and Management reports retain an offline history of SoD status.

0 Risk Configuration steps SAP has made it is easy for collecting the Customizing settings by processes into Business Configuration Sets (BC Sets). and customers can also create their own.SAP GRC 10. When you create your BC Set the configuration settings are copied into BC Set Tables. BC Sets are provided by SAP for selected industry sectors. Key Steps: Execute transaction SCPR20 Activate GRAC* and GRC* BC sets Use caution when activating Rule Sets. Then when these BC Sets are activated the configuration settings are copied into the customer’s tables. You are actually working through the SAP GRC Risk Analysis and Remediation configuration setup. The BC Sets have to be transported into the customer system in which Customizing is performed.0 BC Sets populate the IMG data. When you review the SAP GRC 10. 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 9 . 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). This also helps the when the company wants to go live by specific subsidiary or location. BC Sets make Customizing more transparent by documenting and analyzing the Customizing settings. In the GRAC_RULESET* tables these populate the proposed SAP SOD Rule set.0 Documentation you can find the section to activate the GRC Rule sets. SAP GRC 10.

and functional teams to see if risks are valid for your company business process. Untangling the SOD web becomes very difficult as this situation goes on for many years. Most users will have excessive access leading to numerous SOD violations. do not consider the SAP SOD implications on role design. The rule set provided in the default rule set from SAP.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. if the SAP SOD needs to be cleaned up. Challenge with SAP SOD Most corporations. when designing their SAP Security roles. Since training and testing also depend on role design. Now you have to export the rule set and work with your internal auditors. then the training curriculum and testing scripts will also be affected. 10 .

OneAccess-UserManager also helps you manage the complex documenting.softsquare. These transactions should be part of SOD matrix. In addition to updating the transaction also update the SU24 with the relevant objects and object values for the custom transaction. The SOD analysis will miss this transaction since the custom transaction is not in SOD matrix. Then update the functional group with this custom transaction.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. Phone: 1 877 717 5487 Automate and Meditate 11 . For example if you are copying transaction XK02 and create transaction ZXK02 to mask some of the fields in the screen.SAP Practice OneAccess-UserManager for SAP SAP Certified-Powered by Netweaver http://www. This transaction has same functionality as update vendor master but is hiding as custom transaction. These custom transactions will miss the Segregation duties matrix (SOD) since they have to be manually updated. Since it not part of SAP defined SOD matrix. When we run the SOD analysis it will miss the transaction and will not flag them a risk. You could do this with transaction variants or create a custom screens. The best way to update this transaction is find the similar transaction or transaction which has similar functionality. and sign-off requirements mandated by Sarbanes-Oxley sections 302. 404. The transaction can perform the same selva@softsquare. process control. and 409 Selva Kumar Vice President.

12 .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. This will give an idea about the depth of the problem. is a set of segregation of duties risks that come standard with the SAP GRC tool. There may be certain risk which may not be applicable to the company and there may be other which needs to be added. 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 may not be the true picture as the rule set is not customized to the particular company.

SAP Compliance Sensitive transaction SAP Risk Mitigated Users SAP-Risk-Executions-and-Details SAP SoD rule set is comprised of 3 major components: Risks. Risk: Combination of two functions when granted to a single user cause a SAP SoD conflict. Function: The group of transactions which can perform a similar task. For example 13 . This could be combination of two transactions or more. and Authorizations. Functions.

we need to identify the two conflicting functions and the group of transactions with these functions will create a risk. Authorizations: The specific transactions and associated authorization objects a user must have to perform the process task. 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. The risk from report will be lower as the SAP SOD rule set has not be updated with custom transactions 14 . 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. 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.create vendor master which can be performed through multiple transactions. it has been developed along standard SAP business processes and transactions that represent industry best practices. Instead. This is for independent validation if the SAP SOD report is giving the right data. Therefore. These transactions are grouped into functions. SAP SoD Rule set validation SAP GRC Rule set is not tailored to any single industry or organization. If the analysis is done just at the transaction level then there will be lot of false positives. 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. 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.