GRC
HR
SCM
CRM
BI
Expand +


Article

 

Detect Cross-System SoD Risks Between ECC, SAP S/4HANA, and Master Data Governance

by Nibha Kumari, SAP Security Expert, Cintas Corporation and Gary Prewett, Security Practice Lead, NIMBL

May 21, 2018

Seventeen percent of segregation of duties (SoD) risks involve master data maintenance. These risks will not be detected by an out-of-the box SAP system rule set if your organization implements Master Data Governance (MDG). If you want to get a complete picture of SoD risks, then you need to modify the rule set accordingly to detect cross-system risks associated with material, customer, and vendor master data maintenance in the MDG system.

 

As SAP landscapes have proliferated, maintaining consistency of your master data across your ERP Financials, Customer Relationship Management (CRM), Supply Chain Management (SCM), and other systems becomes increasingly challenging. SAP’s Master Data Governance (MDG) solution was designed to centrally manage and distribute (or syndicate) this data to the affected systems. Centrally managing your customer, vendor, and material masters helps to ensure master data consistency and auditability through all your SAP (and non-SAP) landscapes.

The challenge from an SAP Access Control and GRC perspective is that a broad swath of currently defined SAP system risks involves master data. Of the 248 SAP-delivered SAP Access Control risks, 43 (17 percent) specifically address segregation of duties (SoD) issues with master data maintenance and another business function. The challenge for SAP MDG users is that once MDG or another master data maintenance tool is implemented, detecting master data-related SoD risks with single-system analysis becomes impossible.

The good news is that SAP Access Control can be modified to detect and manage cross-system risks associated with master data maintained in an MDG landscape. We walk you through the steps needed to make cross-system MDG risk detection happen in your SAP Access Control 10.0 or 10.1 landscape. Briefly, these steps are:

  • Design cross-system functions and risks in SAP Access Control
  • Configure your cross-system connector in SAP Access Control
  • Create new functions and risks in your SAP Access Control rule set
  • Test your SAP Access Control changes to ensure you can detect cross-system MDG risks

(Note: We assume that all the single-system connectors are defined in your GRC system and are working as expected.)

MDG Security Overview

The SAP MDG solution runs in the SAP NetWeaver ABAP stack (unlike its predecessor, Master Data Management) and uses a lot of the standard authorization objects leveraged in SAP ERP Central Component (ECC) or SAP S/4HANA to control access to master data maintenance.  Objects such as F_KNA1_BUK (which controls access to customers by company code), M_MATE_BUK (which controls access to the material master by company code), and F_LFA1_BUK (which controls access to vendors by company code) are all reused by MDG. This makes the security model relatively easy for those with limited MDG exposure to understand so that they can also easily implement a role and security design.

The Master Data Governance Security Guide covers the authorizations used by each area in MDG. These can easily be mapped to functions in your GRC rule set. For example, GRC/SAP Access Control function SD01 is the standard SAP system function for Maintain Customer Master Data and maps to section 1.11.2 (Customer Master Data Governance) in the current version of the Master Data Governance Security Guide. Table 1 shows the authorization data associated with customer master data maintenance.


Table 1
Customer master maintenance authorization objects available in MDG

This table helps you start designing the Permission tab of your to-be MDG Customer Master Maintenance function, given the Permission tab is concerned with authorization object-level access. However, what about the Action tab of the new customer master maintenance function?

In this case the action report is not meaningful because the only action really needed is access to the SAP NetWeaver Business Client (transaction code NWBC). Like the SAP GRC system itself, only one transaction code is needed to exercise most of the functionality within the application (Figure 1).


Figure 1
Example SAP NWBC view of MDG

The new function needs only one action, NWBC, to work as expected. It’s important to know that any action report performed using a risk with this function contains a significant number of false positives. Not everyone in MDG with NWBC access has access to modify customer master data today, even though the action report flags the users as having customer master maintenance access by virtue of the fact they have access to execute transaction code NWBC.

Designing MDG Cross-System Functions

Now that you have a rough idea of what the new MDG customer master maintenance function consists of in SAP Access Control, we explain the details around the technical requirement. This section is more of a spreadsheet exercise in which we define the technical requirements for the rule set changes.

In SAP Access Control, cross-system risk scope in risks is defined at the function level—not at the risk level. Figure 2 shows the SAP-delivered function for SD01 (Maintain Customer Master Data). You could change it from Single System to Cross System, but because you do not want to affect the behavior of your existing function or risk combinations, we recommend that new cross-system-specific functions be created with the analysis scope set to cross system. Flagging a function as cross system exponentially increases the calculated rules for each risk that includes that function.


Figure 2
Standard SAP-delivered function for customer master maintenance showing the Analysis Scope (Single System)

Table 2 outlines a listing of SAP-delivered risks in the SAP system rule set in which customer master maintenance is involved.


Table 2
SAP-delivered SoD risks with customer master maintenance forming part of the SoD risk

We build a similar function from scratch for the SD01 function capturing the MDG portion of the cross-system risk. All the other relevant functions (in this case, AR01, AR02, AR03, AR05, AR07, SD03, and SD05) can be copied from the existing SAP-delivered functions. If you have adapted the SAP-delivered functions for your organization, we recommend that you copy the customized functions specific to your organization to the new cross-system functions.

In our example, we copy the functions in Table 3 from the functions in the Reference function ID column to the new function ID values.


Table 3
New to-be cross-system functions

For the last function—the MDG-specific SD01 function—you need to set the values for each relevant field in the permission portion of the function. This step ensures that SoD risks are flagged where a user can make changes to a customer master maintenance record. However, what should those fields and values be? Fortunately, there already is a reference function SD01 with most of these permissions defined. For example, authorization object/permission F_KNA1_BUK is relevant. In the existing SD01 function, the aggregate values in Table 4 are defined for actions with F_KNA1_BUK.


Table 4
Aggregate function SD01 values in GRC activities for F_KNA1_BUK

There are a lot of ANDS here because within the SD01 function there are many actions or transaction codes with, for example, F_KNA1_BUK: FD01, FD02, and VD02. Within each there are programmatic restrictions that only allow maintenance based on specific authority checks. For example, action FD08 only checks for actions 01 (create), 08 (Display Change Docs – probably not relevant for MDG and most ECC versions), and C8 (Confirm Change). FD01, on the other hand, is only concerned with activity 01 (Create). Since we are aggregating these in our new function and essentially assuming that the SAP NWBC transaction allows all these (a safe assumption), we want to flag a SoD violation on every combination of permissions that can effect changes to master data, in which case, we want to OR these values.

For the new function, you need to determine the condition. In Table 4, which is a subset of the full table, note that in the standard SD01 function in the SAP system, most conditions are AND. This is because the SD01 function is concerned with the action/permission combinations. In the case of MDG, any of these combinations can be used to change a customer master record. Therefore, in the new function you explicitly make the condition for each permission combination OR.

You most likely want to trigger a SoD violation if the user has NWBC + (Create OR Change OR Lock OR Delete OR Confirm Change in authorization object F_KNA1_BUK). As a result, the newly defined cross-system SD01 risk for MDG (which we called ZSD01M) is defined per Table 5.


Table 5
Proposed ZSD01M function design

Note: There are two MDG-specific authorization objects in Table 1 that are not included in SAP-delivered SAP Access Control functions: SD01 – MDG_LCOPY and USMD_MDAUTH. In our example, given our MDG implementation scenario, USMD_MDAUTH is not available in the system. A quick check of MDGC_LCOPY reveals that the only action available is 90 (Copy). In the to-be ZSD01M function, we include a value for MDGC_LCOPY and leave out USMD_AUTH. This may be different for your MDG implementation scenario, so you need to confirm in your system prior to developing your new MDG-specific customer master maintenance function.

Designing New Risks

Once the functions have been designed, new risks, including the new cross-system functions, need to be created. Again, the purpose is to duplicate the logic of the risks containing single-system functions to cross-client functions. Table 6 shows the new risk design for the cross-system functions we designed previously.


Table 6
New customer master-specific SoD risks containing a cross-system function

Configuring the Cross-System Connector Group

Once the risk has been defined, it’s time to start the realization phase in configuration to set up the cross-system connector group and to assign the relevant connectors. When you run your SoD analysis, you need to run it against this connector group (as opposed to running a SoD analysis against one specific system). The connector group provides a logical link between the cross-system connectors we care about.

(Tip!: The rules you calculate are a function of the number of permissions in each function times the number of connectors in your first function, multiplied by the number of permissions times the number of connectors in the second function. Adding too many connectors to a cross-system connector group can increase the rule size in the calculated rules table by orders of magnitude. Therefore, it’s helpful to limit the number of connectors in your cross-system connector group to only those connectors that are needed. If you run into an instance in which your GRAC_GENERATE_RULE jobs are taking much longer than they did before, try paring down the number of connectors in your cross-client connector groups.)

To configure your cross-client connector group take these steps:

Step 1. Go to SPRO > SAP Reference IMG > Governance, Risk and Compliance > Common Component Settings > Integration Framework > Maintain Connectors and Connection Types.

Step 2. Double-click the Define Connector Groups folder. Click the display < - > change icon (the pencil and glasses) to edit, then click the New Entries button in Figure 3.


Figure 3
Create the cross-client connector group

Create the new cross-client connector group. In this case, name it ECC_MDG_XS (indicating an ECC to MDG cross-system connector group).

Step 3. Highlight the new line, then double-click the Assign Connector Groups to Group Types folder in the left navigational dialog structure. Set the Connector Group Type to both Cross System Group and to Logical Group as shown in Figure 4.


Figure 4
Define Group Types

Step 4. Now double-click the next folder in the dialog structure (Assign Connectors to Connector Groups), click the display -> change icon and the New Entries button. Assign the appropriate connectors to your cross-client connector group. In this case, there is one MDG connector and one ECC connector assigned to the new cross-client connector ECC_MDG_XS. An example is shown in Figure 5.


Figure 5
Add connectors to the connector groups

You are now done with the Maintain Connectors and Connection Types IMG activity. For the next step proceed to the IMG activity SPRO > SAP Reference IMG > Governance, Risk and Compliance > Access Control > Maintain Connector Settings. In this activity you extend the logical cross-system group definition performed in the Common Component Integration Framework settings, and define the scope of the new connectors in the connector group you just created.

Step 5. In the IMG activity SPRO > SAP Reference IMG > Governance, Risk and Compliance > Access Control > Maintain Connection Settings, click the edit icon and New Entries button. Add the appropriate target connector and action combinations to the new-cross system logical group (in our example shown in Figure 6, ECC_MDG_XS). Add the appropriate actions and connectors, then click the save icon.


Figure 6
Add SAP Access Control-specific connector actions

Once this step is completed, you are ready to proceed to the next step, which is defining the relationship between the action NWBC and permissions (authorization objects) in the MDG system.

Modifying SU24 in the MDG System

Before you can assign actions and permissions to rules in the GRC rule set, the SAP GRC system must be made aware of the relationship between the primary action (transaction code NWBC) and the authorization objects associated with customer master maintenance. To make the SAP GRC system aware of this, it’s necessary to define the SU24 relationship in the MDG system, and then to import those definitions into the SAP GRC system.

You need to add the authorization objects shown in Figure 7 manually in the Maintain Check Indicators transaction (transaction code SU24). Note that for the new SU24 settings, the Proposal: section is set to No. When you are realizing roles in your MDG system, adding the transaction code NWBC to your menu does not affect the behavior of the authorization objects populated automatically in your Authorization tab. It still only pulls in what currently is pulled in today (in this case, the only object is S_TCODE).|


Figure 7
Add objects to transaction code NWBC in SU24 in the MDG system

These changes need to be saved to a transport and transported to production. Finally, these definitions need to be pulled from the MDG connector into MDG. Use transaction code GRAC_AUTH_SYNC to sync the authorization values from your MDG system by entering your MDG system connector (Figure 8).


Figure 8
Sync the authorization data to SAP Access Control from MDG via transaction code GRAC_AUTH_SYNC

Final Rule Set Implementation

Once configuration is complete, the next and final step to realizing the solution is to create the new functions and risks designed previously in the SAP Access Control rule set. First, copy the single-system functions to the new cross-system functions. Then you create the MDG-specific Customer Master Maintenance function, create the risks, and generate the rules.

Copy Functions

For copying single-system functions to the new cross-system functions, the input to this activity that was designed previously is shown in Table 3. Now copy each function as follows. In this example, copy the first line from Table 3 and copy function AR01 (AR Payments) to the new cross-system function ZAR01X (AR Payments Cross System). In your SAP Access Control system, go to the Setup tab (if you adapted the default menu role) and navigate to Access Rule Maintenance > Functions as shown in Figure 9.


Figure 9
Navigate to the SAP Access Control functions

In the Function Maintenance screen, highlight the row of the risk you want to copy (for example, AR01) and then click the Copy button in Figure 10.


Figure 10
Select the Copy function

Finally, in Figure 11, enter the new function name (ZARX01), change the Analysis Scope to Cross System (and optionally change the description to indicate this is the cross-system version), then click the Save button. This process needs to be repeated for each cross-client function defined in Table 3.


Figure 11
Completing the cross-system function definition

Create a New ZSD01M Function

Once the new cross-client functions have been copied, it’s time to create the Cross-Client MDG Customer Master Data Maintenance function (ZSD01M). The input for this activity is the ZSD01 Function Definition created earlier in Table 5.

This step is arguably the most time-intensive portion of the exercise. Critical to this is ensuring that the condition logic is set correctly. For many, if not most cases, the conditions need to set to OR. Note that many of the values for the columns in Table 5 can be pasted into the NWBC screen. Figure 12 shows the Action tab of the final ZSD01M function realized in the SAP Access Control rule set.


Figure 12
The Action tab in the cross-client MDG customer master maintenance function action definition

Figure 13 shows the more complicated Permission tab.


Figure 13
The Permission tab in the new cross-client MDG customer master maintenance function permission definition

Create New Risks

Once your cross-system functions have been created, you can now create the new risks containing those cross-system functions. This is done in the SAP Access Control web or NWBC UI in Setup > Access Rule Maintenance > Access Risks. Figure 14 shows the new realized risks for the cross-system SoD risk detection solution.


Figure 14
Final realized customer master maintenance risks with cross-system functions

Generate Rules

Once your risks have been created, you can now generate the detailed rules for your updated rule set in your SAP Access Control system via transaction code GRAC_GENERATE_RULES. Figure 15 shows the GRAC_GENERATE_RULES screen. Enter the relevant risk IDs, then click the execute icon to generate your rules.


Figure 15
Generate updated rules via transaction code GRAC_GENERATE_RULES

It’s not a bad idea to benchmark the time taken to generate your rule set before you begin. You can compare this against the time taken to regenerate with the new cross-system functions and risks. If significant time is added to your rule set generation, you can manage the system resources required by minimizing the amount of connectors assigned to your cross-system logical group.

Running Cross-Client SoD Reports

Once rules have been generated, you are now ready to test to make sure cross-system risks are being detected as expected. Figure 16 shows example user-level SoD report parameters used to detect customer master maintenance-specific cross-system SoD for users starting with TEST.


Figure 16
Example of the criteria for a cross-system SoD report

Note that your compliance or audit teams need to be trained to use the logical cross-system group (in this example it is ECC_MDG_XS). Also remember that for MDG the action report has limited or no value. Your compliance or audit team needs to be trained to rely on the permission-level reports to detect cross-system risk in MDG.

Figure 17 shows the final report with new cross-system risks detected.


Figure 17
Cross-system risks identified in an SAP Access Control SoD report

Note: For more information, go to the Master Data Governance Security Guide.

An email has been sent to:





 

Nibha Kumari

Nibha Kumari is an SAP security subject matter expert currently working in Cintas Corporation. She has managed and implemented several ERP solutions with IBM for clients in the Finance, Pharmaceutical, Airlines, Manufacturing, Retail, and Service sectors globally and has gained vast experience over the last 14 years working closely with various clients. Nibha has concentrated on SAP security/GRC implementations for 11 years now and she combines her highly technical, analytical, and excellent communication skills with a strong customer service orientation to implement client-tailored security solutions in accordance with SAP best practices. She mainly focuses on SAP security for ECC, MDG, Fiori, SAP HANA, BI/BOBJ, CRM, PI, and GRC. Nibha has attended and presented at multiple SAP security conferences and has been a very enthusiastic and committed member of the SAP community. She has been engaged in a wide range of business domains including consultancy, sales, project management, customer training, and implementation and knowledge transfer, and has won multiple accolades throughout her career.


Gary Prewett

Gary Prewett is the security practice lead for NIMBL, North America’s SAP Technologists. An active SAP security thought leader and author with more than 12 years of ERP implementation experience and 15 years of information security focus, Gary has driven and delivered technical and process-based controls on multiple complex SAP implementations. He has worked with clients in implementing security strategy essential to operating in high risk environments, and has implemented comprehensive information security initiatives encompassing SAP solutions for clients in the financial services, energy, manufacturing, and service sectors.



COMMENTS

Please log in to post a comment.

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


SAPinsider
FAQ