Discover key tools and process steps to assist in the remediation of risks at the composite role and user level identified by SAP BusinessObjects Access Control Risk Analysis and Remediation.
Key Concept
The end-game of every segregation of duties review is to have a remediated risk environment. This involves remediating any existing composite roles, which are roles that collect a number of single roles into one easier-to-use role, as well as remediation at the user level.
Remediating risks is an important part of your segregation of duties (SoD) process. The remediation process is most efficient when performed in the following three sections: single role remediation, composite role remediation, and user remediation. It is best to start at the single role level and then work your way to composite roles and users. In a previous article, “Start Your Segregation of Duties Risk Mitigation Smart — at the Single Role Level,” I explained how single role remediation worked in the Risk Analysis and Remediation (RAR) component of SAP BusinessObjects Access Control.
In this article, I’ll take you through composite role and user remediation. I recommend you read that article first to give you better perspective for this one, as single role remediation takes up the bulk of your time in this process. However, user remediation is the key focus for most companies, as that is the level that is reviewed by internal and external auditors.
Composite Role Remediation
Composite roles allow you to group single roles together to aid in user maintenance. For example, an accounts payable clerk may need 10 single roles to give them the access they need to perform their jobs. You can create a composite role that contains these 10 single roles and assign just that composite role to the clerk. Not every company uses composite roles, so if they are not used, the remediation process can skip to user remediation after single role remediation.
Composite role remediation starts with an analysis of single role mitigations. As with the single role remediation steps in my previous article, you would have assigned mitigations to the single roles for risks that could not be remediated some other way.
There is no automated way to copy single role mitigations to composite roles that have those single roles. Therefore, the first steps with composite role mitigation are to determine which composite roles contain single mitigated roles and add those mitigations to the composite role.
I’ll use the example of single role ZFI_ACCOUNT_CLOSE that I mitigated previously. There are two ways to obtain whether this single role is part of any composite roles.
The first method is to use transaction PFCG and enter the single role ZFI_ACCOUNT_CLOSE. At the initial screen, click the where used icon (Figure 1). The screen that comes up shows which composite roles contain this single role (Figure 2).
Figure 1
Where-used listing for single roles
Figure 2
Listing of single roles in composite roles
The second method to obtain a full listing of all single-to-composite role links is to use transaction SE16 (or SE16N/SE17) and go to table AGR_AGRS (Figure 3).
Figure 3
Table AGR_AGRS listing of single-to-composite roles
After you have this data, you need to manually add the single role mitigations to the composite role. In this example, because I mitigated role ZFI_ACCOUNT_CLOSE for risk F0281L8*, I need to mitigate this same risk for composite role ZFI_COMPOSITE_1 (Figure 4).
Figure 4
Mitigation of composite role for single role risks
After the mitigations are assigned, the next few steps are the same as for single roles. You first run a report out of transaction SUIM to identify all composite roles and then run a report in RAR for all the roles. The one difference when you run the report is that you set Exclude Mitigated Risks to Yes (Figure 5). This ensures that only those new risks that result from the combination of single roles come up — not the risks that flow from the individual single roles.
Figure 5
Analysis of composite roles
After you have the report of the risks in the composite roles, there are three options to remediate the risks:
- Remove one of the single roles that causes the conflict
- Adjust the RAR rules to account for a false positive reading
- Create a mitigating control for the risk
Figure 6 is an example of the composite role report. Risk F001PK01 exists because this composite role has single roles ZFI_ACCOUNT_CLOSE and ZFI_GL_ENTRY.
Figure 6
SoD report for composite roles
You can use many of the same processes highlighted in the single role remediation section to determine if you can remove a single role from a composite role. Ultimately, the business needs to determine if the users who have the composite role ultimately require all single roles to do their job.
The second option of adjusting the rules is done in the exact same manner as previously explained in my article about single role remediation. The same goes for option three for mitigating the risk. The same processes apply to composite roles that applied for single roles.
User Remediation
After you’ve completed single and composite role remediation, then you can move to user analysis. The hope is that the user analysis report should only contain those risks that exist due to users having multiple roles that conflict. This should significantly reduce the scope of analysis for users.
Prior to executing the user SoD analysis, you should set two configuration options. Follow menu path Configuration > Risk Analysis > Additional Options (Figure 7). The Ignore Critical Roles & Profiles setting is important to ensure single and composite roles that have not been remediated are not included when running the risk analysis. The second configuration option, Include Role/Profile Mitigating Controls in User Analysis, allows mitigations you have attached to the single and composite roles to flow through to the users that have these roles, reducing the number of conflicts that must be identified. Both of these options should be set to Yes.
Figure 7
Required configuration settings prior to running user analysis
When executing the report at the user level, you should run it for all users, but with the variables shown in Figure 8. This excludes all mitigated risks that were mitigated at the role level and only shows dialog users. Dialog users are those users that can directly log on to the SAP system. Non-dialog users (such as system or service users) are not normally analyzed for SoD because they do not constitute any risk since users cannot directly sign on. As with the role report, execute in the background and save the file to a server location for audit purposes.
Figure 8
User analysis report settings
The report looks the same as it does for single and composite roles (Figure 9).
Figure 9
User analysis SoD report
You have three options for remediating the user risks.
- Remove one of the roles (either single or composite) that causes the conflict
- Adjust the RAR rules to account for a false positive reading
- Create a mitigating control for the risk
In this example, the user TEST_CLOSE has risk F0010PK01 because he has roles ZFI_ACCOUNT_CLOSE and ZFI_GL_ENTRY. The first question to ask is whether one of these roles can be removed from the user.
As I mentioned in my previous article, RAR contains reports that help determine actual use of transactions and roles. The key is to configure alerts as shown in Figure 11 of my previous article.
If the alert job has been running, you can leverage the Action Usage by User report. This is located on the Informer tab under menu path Security Reports > Miscellaneous. By running this report, you can obtain a listing of what transactions have been executed by the user (Figure 10).
Figure 10
Action Usage by User initial report screen
Running this report shows that the user has executed transaction FB01 (Figure 11). However, the user has not executed transaction FS00, which is the other transaction that creates the conflict. Transaction FS00 is part of role ZFI_ACCOUNT_CLOSE. Based on this information, the business should determine if role ZFI_ACCOUNT_CLOSE can be removed from the user. Removing it removes the risk.
Figure 11
Action Usage by User report showing actions executed by each user
The second option of adjusting the rules is the same as previously described in the composite role remediation section.
The third and final option is to mitigate the user’s risk. Again, this is the same as described previously; the difference is that the mitigation is attached using Mitigation > Mitigated Users (Figure 12).
Figure 12
Mitigated users
Jayne Gibbon
Jayne Gibbon, CPA, has been implementing SAP applications since 1996 and is currently a director in the Chief Customer Office at SAP. Jayne’s focus is making customers successful with their SAP HANA deployments. She has helped more than 100 customers drive business value with SAP HANA. Prior to joining SAP in 2007, Jayne worked for two multinational manufacturing companies based in Wisconsin. While an SAP customer, Jayne led the very first implementation of Virsa’s Compliance Calibrator, which is now part of SAP Access Control. Jayne’s experience includes internal audit; computer security; governance, risk, and compliance; SAP HANA; and SAP analytics.
You may contact the author at jayne.gibbon@sap.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.
