The Security Audit Log allows users with extensive authorizations to be monitored. This is particularly useful for ensuring compliance with both internal security policies and external legal requirements. The SAP standard tool gives an overview of critical activities relevant to security and logs them.
Secure logging with SAP Security Audit Log
The SAP Security Audit Log is a tool with a detailed view of events in SAP systems that are predominantly critical for security. This tool is designed for use by employees responsible for handling tasks relevant to security and people who need to take an in depth look at SAP system events, for example auditors.
When the Security Audit Log is activated, some 150 events can be classified – based on the common vulnerability scoring system (CVSS) risk classifications of High (9), Medium (5) and Low (2) – and assigned to a number of different audit classes, for example changes to the user master. The question is which of these events should trigger activation and logging in the Security Audit Log.
As a rule, the following aspects should be taken into account:
- Recording security-related changes to the SAP system environment (for example, changes to user master records).
- Identifying information that offers greater transparency (for example, successful and failed logon attempts).
- Identifying information that enables plausible documentation of a series of events (for example, successful and failed transaction starts).
Setting up and configuring filter categories
To ensure secure basic logging, we recommend configuring the filter categories as follows:
1st filter: activate all events for the ‘SAP*’ superuser in all ‘*’ clients, including the SAP support users.
This covers the integrated ‘SAP*’ users and all user account names that begin with ‘SAP’, for example, ‘SAPSUPPORT’. Enter the user ‘SAP#*’ in the user filter to create log entries for the ‘SAP*’ user.
2nd filter: activate all events categorized as “only critical” in all ‘*’ clients and for all ‘*’ users.
Class 32 (“User Master Record Change”) notifications can be deactivated as they can also be retrieved via change documents for users in transaction SUIM.
Instead, it makes sense to give events in the areas AU (AUO, AUP, AUQ AUZ) and BU (BU5, BU6, BU7, BU9, BUA, BUB, BUC, BUH) medium weighting.
3rd filter: activate all events for additional support and emergency users, for example ‘NOTFALL*’ (emergency) or ‘FF*’ (firefighter) in all ‘*’ clients.
4th filter: activate all events for the ‘Logon’ and ‘Transaction’ dialog activities for the ‘DDIC’ user.
“This user has” should not be used in dialog mode; rather, it should be reserved for certain administrative activities for maintaining the Data Dictionary, for example importing transport packages or importing transfer requests.
Additional filters can be used for project-specific reasons, for example to secure RFC callback function calls from external systems with low protection levels. In particular, the allowed and disallowed function calls are identified in various phases and the results are provided in the generated whitelists.
5th filter: activate the following events: DUI (gather information via RFC callbacks), DUK (identify called function modules from RFC callbacks during the simulation phase to determine whitelists), and DUJ (identify denied function modules via RFC callbacks).
6th-10th filter: your choice, e.g. for other project-specific purposes.
Security monitoring: Comprehensive, fully automated, in real time
Activation of the Security Audit Log and application of transparent filters form the basis of performing security monitoring involving reasonable efforts.
This is why activation and configuration of the Security Audit Log is part of every security analysis that AKQUINET carries out. Our SAST SUITE and the System Security Validation module allow us to quickly identify settings and recommendations for improving even sophisticated system environments.
Axel Giese (SAP Security Consulting, SAST SOLUTIONS)