SAP Security: Table Change Logging and Security Considerations
Enabling Table Change Logging in your SAP system provides further protection from unauthorized modifications and should be part of your SAP security strategy.
Given the sophistication and speed of contemporary cyber threats, real-time visibility into data modifications is critical for maintaining the integrity of your SAP environment.
By enabling table change logging, you not only protect your system from unauthorized modifications but also lay the foundation for more advanced security measures like automated alerting and integration with third-party auditing systems.
In an ideal world, production systems would remain untouched by direct table changes. However, reality often presents a different picture. Standard SAP security reports have a blind spot: they can’t detect changes made directly to tables using tools like SM30 or custom programs written by developers.
This is where Table Change Logging steps in. This crucial feature acts as a watchdog, recording modifications that might otherwise slip under the radar.
Why Table Change Logging is Good for SAP System Security
Here’s why it’s important to configure SAP to log data changes:
- Transparency: It provides a clear audit trail of who changed what and when.
- Security: Helps identify potentially unauthorized or risky changes.
- Troubleshooting: Makes it easier to pinpoint the source of data inconsistencies.
- Compliance: Supports regulatory requirements for data change tracking.
By implementing Table Change Logging, organizations can maintain the integrity of their SAP systems, even when faced with necessary direct table edits.
- The SAP system in which your customizing is performed
- Your production system
How Table Change Logging Works in SAP
Table Change Logging is your system’s vigilant guardian, keeping a watchful eye on user activity. Here’s how it works:
- Targeted Tracking: Focus on the SAP tables that can impact your system’s structure.
- Risk Mitigation: Catch unauthorized or incorrect changes before they cause problems.
- Comprehensive Recording: Document all table modifications, regardless of the method used.
To maximize its effectiveness:
- Identify Key SAP Tables: Create a list of tables whose alterations could significantly affect your system.
- Set Up Alerts: Configure notifications for changes to these crucial tables.
- Regular Reviews: Establish a process to analyze logged changes periodically.
By leveraging Table Change Logging, you’re not just recording changes—you’re fortifying your SAP system against potential risks and ensuring data integrity.
Remember: In the world of SAP, knowledge is power, but actionable insights from Table Change Logging are your superpower.
What should you track with SAP’s Table Change Log?
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 ‘,’.
Incorrect definition:
rec/client=001, 002 , 003
Correct definition:
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.
Extending Table Change Logging with ABAP Development
While SAP provides robust standard tools for table change logging, certain organizations may require custom functionality to meet specific business needs. ABAP development can play a key role in extending the capabilities of SAP’s table change logging system.
Common ABAP Enhancements for Table Change Logging:
• Custom Reports: ABAP can be used to create custom reports that extract detailed information from logged tables, providing insights into changes that may not be easily accessible via standard transactions like SCU3.
• Automated Log Analysis: You can develop ABAP programs to automatically analyze change logs for anomalies, such as unexpected changes to critical fields. This can help automate routine audits and flag potential security issues.
• Enhanced Filtering: ABAP can enable more granular filtering of change logs by creating custom selection screens or adding user-specific filters to isolate relevant log entries quickly.
For example, a simple ABAP program can loop through the contents of CDHDR and CDPOS tables to extract user-specific changes to critical tables, and then email the results to administrators.
Integrating SAP Table Change Logs with External Auditing Tools
For organizations with robust security requirements, integrating SAP table change logs with external auditing tools—such as Security Information and Event Management (SIEM) systems—can offer enhanced monitoring and alerting capabilities. This integration allows you to aggregate log data from SAP and other systems into a centralized platform, facilitating real-time anomaly detection and automated incident response.
Step-by-Step: Extracting Logs for SIEM Integration:
• Access SAP table change logs via transaction code SCU3 or the relevant logging program (RSTBHIST or RSVTPROT).
• Export logs in a format compatible with your SIEM tool, such as CSV or through a direct API connection (if supported).
• Utilize third-party tools to facilitate log ingestion into systems like Splunk, ArcSight, or IBM QRadar.
Once integrated, your SIEM system can track critical changes and raise alerts when suspicious activity is detected, ensuring faster response times to potential threats.
Automating Alerts and Reports for Critical Table Changes
To further strengthen your SAP security posture, it’s possible to automate alerts and reporting for critical table changes. By leveraging SAP’s alerting mechanisms or integrating with third-party tools, you can set up real-time notifications whenever key tables are modified. This is particularly useful for tables that contain sensitive business or personal data.
How to Automate Alerts:
• Set up email or system alerts by configuring SAP Business Workflow, which triggers notifications when specific table changes occur.
• Use SAP Solution Manager to monitor changes in real-time and send out automated alerts when deviations from standard processes are detected.
• Create scheduled reports in SAP that pull daily or weekly logs of table changes and automatically send them to key stakeholders for review.
If the standard SAP tools for generating alerts don’t meet your organization’s specific needs, previously mentioned ABAP development can provide a more tailored solution. ABAP programs can be written to trigger alerts or workflows whenever specific conditions are met in change logs.
Example ABAP Automation Use Case:
A custom ABAP program that monitors changes to sensitive tables (e.g., customer data) and sends a notification to security administrators whenever certain fields are modified outside of business hours. This allows real-time, context-aware monitoring that standard logs or alerts may not offer.
How Onapsis Helps with SAP Table Change Logging
The Onapsis Platform 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:
Conclusion
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.
Learn more about how The Onapsis Platform can protect your business-critical applications.