Enabling Table Change Logging in your SAP system allows you further protection from unauthorized modifications and should be a part of your SAP application security strategy.
Ideally there should be no direct changes made to tables in a production system, but it is possible. The standard SAP security reports will not record if someone makes a change directly to a table using SM30, or if a programmer writes a program to edit a table. In this scenario, the concept of Table Change Logging appears.
Table Change Logging is a tracking mechanism that makes it possible to record user activity in a system. A list of the tables whose changes can affect the structure of the system should be developed to mitigate the risk that unauthorized or inaccurate changes remain unidentified. The purpose of this logging is to record whether changes to tables are performed.
But, the main question is: “What should be logged?”
SAP recommends that automatic Table Change Logging is authorized only in systems where this is worthwhile. These are generally the following systems:
- The SAP system in which your customizing is performed
- Your production system
How do you implement Table Change Logging?
Two SAP Notes are recommended here. First, SAP Note 1916 refers to the older releases of SAP and is out of date. On the other hand, SAP Note 112388 gives a more detailed and up-to-date definition of the relevance of logging tables changes. In order to implement this functionality, we need to review its prerequisites.
Prerequisites for Table Change Logging
From a technical perspective, it is easy to activate Table Change Logging. For table changes to be logged, the system profile parameter rec/client needs to be enabled. This parameter is used to activate and deactivate client-dependent Table Change Logging. Depending on the setting of this parameter, certain change options are either not logged at all, are logged only in certain clients or are logged in all clients.
In order to check the value of the rec/client parameter, execute transaction code RZ11, fulfill the Parametername field and click on Display.
This is a very important step because if the parameter is disabled, even though you have activated Table Change Logging in the technical settings for any table, it won’t log the data changes to that table. Also make sure that the values for rec/client are the same on all instances of a system. Only then will logging work correctly.
These are the possible values that the parameter can adopt:
*WARNING: From a security perspective it is important to audit all the clients in the system. Setting the rec/client parameter to 'ALL' can seriously impair R/3 system performance. SAP recommends you do not use the value 'ALL'.
** <client1>,<client2>,...,<client10>. Caution: Make sure there are no space characters before or after the separator ','.
rec/client=001, 002 , 003
The default setting is OFF (no changes are logged). This setting is only normal in the installation and test phase.
Changing the value of rec/client
In order enable Table Change Logging, set the profile parameter rec/client to ALL or at least specify your production and customizing clients according to SAP recommendations. You can query the SAP table T000 in order to confirm which clients (MANDT column) are production clients (CCATEGORY column equal to 'P') and which are customizing clients (CCATEGORY column equal to 'C') as shown below:
Finally, the change can be applied through the following steps:
- Open an SAP GUI connection to the SAP server.
- Log in using an administrative account.
- Execute transaction RZ10.
- Select the appropriate profile.
- Select 'Extended Maintenance' and click 'Change'.
- Modify the value of the affected parameter to the recommended setting and click 'Copy'.
- Go back and select 'Profile' > 'Save'.
- Restart your SAP instance.
Table Change Logging must be activated for each table individually with transaction SE13 (Maintain Technical Settings (Tables)) by enabling the Log Data Changes checkbox. In many SAP standard tables this logging flag is already set. As a result of that, tables will show up as enabled in SAP table DD09L.
The Onapsis Security Platform (OSP) can help you with two different modules to detect which relevant tables you must configure to activate Table Change Logging: active logging for critical technical tables and active logging for critical business tables.
Below we show you the step-by-step instruction for activating logging for each table.
- Go to transaction code SE13 and complete the Table/view name field with the table for which you want to enable Table Change Logging (e.g. BNKA)
- Click the Change button and enable the Log Data Changes option in the bottom of the window
- Click Save
In order to confirm the change, a new entry will appear in SAP table DD09L.
As shown in the image above, the second line contains a character 'X' for the column PROTOKOLL. By double clicking on it, we can see the details.
If these prerequisites are fulfilled, use program RSTBHIST (table change analysis) or RSVTPROT to evaluate the changes made in the tables (alternatively, use transaction code SCU3).
- Run transaction code SA38
- Complete the program name RSTBHIST and press F8
- Click on list of the logged tables to list all the tables whose checkbox Log Data Changes is enabled
- Finally, choose Evaluate Logs to select the corresponding period of time and table to analyze
The system generates a log entry in the log table for every change to logged tables. This is an example of the information that appears in that table:
It’s important to understand the risks of not enabling the Table Change Logging. There is a risk that no alerts will exist for potential unauthorized table data modifications. All changes to the critical SAP ERP tables should be logged by the system and the periodic review of these logs should form a part of the security procedures for the organization.
Perform regular checks to your clients to eliminate the risk of illicit access. OSP can help protect you against this and other attacks. Our tool is able to detect not only if the Table Change Logging status is enabled, but also to determine which critical tables should be activated to log changes.
Do not hesitate to ask us for more information about how OSP can protect your business-critical applications.