S 4.270 Logging of SAP events

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Administrator

In order to be able to monitor the system functions and the system security of an SAP system, events must be logged. An SAP system offers numerous ways to log events. It must be taken into consideration that this safeguard addresses logging in the sense of monitoring the basic SAP system from the point of view of IT security. Business examinations (audits) are not addressed in this safeguard.

SAP documentation containing detailed descriptions of the system monitoring functions can be found in S 2.346 Use of the SAP documentation.

In general, the following must be taken into consideration for logging.

Logging concept

A logging concept must be drawn up. The concept must take the ABAP and Java stacks into account. The concept must specify which logged data will be collected in the SAP system. Since personal data can also be recorded when logging, the Data Protection Officer and the Personnel or Supervisory Board must be involved in planning the logging concept.

Security of the logged data

The data logged may contain important system information and personal data. Access to the logged data must therefore be restricted. Restricting access may make it necessary to change some settings in the SAP system, as well as outside of the SAP system (e.g. at the file level).

Evaluating important system events

Important system events are recorded in the system log. These events should be evaluated regularly. Transaction SM21 can be used to evaluate the events. It must be noted that this transaction can also be used to access system logs on remote SAP systems if the user possesses the corresponding authorisations. Access to transaction SM21 must therefore be restricted to authorised administrators only.

When operating more than one SAP system, it is recommended to use a central logging instance so that all events can be evaluated on one system.

Restricting the use of traces

Traces allow generation of detailed logs of the system operations executed when a system is accessed. Under some circumstances, it may also be possible to read the data being processed, for example by logging the SQL queries sent to the database or recording the documents transmitted using the ALE interface.

Traces must not be used for these reasons on productive systems. Troubleshooting should be performed on the test or development system. If it is necessary to use traces in a productive system, a corresponding procedure must be implemented to regulate such exceptions.

Access to the trace transactions, including most of the transactions starting with the prefix "ST" (a list of these transactions together with a short description can be displayed using transaction SE93), must therefore be restricted (authorisation object S_TCODE).

Activating change tracking for tables

The database tables of the SAP system contain all system and business data. For this reason, it is necessary to specify which tables change tracking should be activated for within the framework of the logging and audit concept. In general, SAP applications log all data required to track a change. The following applies to the SAP basis: customising tables, i.e. tables that can be changed by the customer, are delivered with change tracking activated. This allows tracking of the changes made to the tables. This is also important to companies subject to the Sarbanes Oxley Act, since it is possible to check which users have made which changes when checking a system in this case.

It must be noted that change tracking can only be activated for those tables programmed accordingly by the developer. Change tracking is activated in the Data Dictionary (DDIC) by setting the "Log Data Changes" option for the corresponding table (transaction SE13). In addition, logging must be activated in the system profile. To activate logging, the "rec/client" parameter that specifies which clients change tracking will be activated for must be set accordingly (possible settings: OFF / mmm/ nnn,mmm,... / ALL).

Change tracking is recommended for productive and customising clients. The "ALL" setting should not be used. This setting leads to a loss of performance when updating, for example, since it also affects client 000 and any test clients.

References to additional information on change tracking can be found in S 2.346 Use of the SAP documentation.

Restricting access to monitoring tools

Access to the monitoring tools provided by the SAP system must be restricted to authorised administrators only. In general, access to the monitoring tools can be restricted by restricting access to the corresponding transactions and authorisation settings.

It must be taken into account that some monitoring tools also offer web interfaces for access such as the Message Server Monitor for the ABAP stack and the Java stack monitors (e.g. SQL trace, systeminfo).

Using the SAP security audit log

The SAP security audit log records important security-relevant system events. Therefore, its use must be guaranteed. The log is configured using transaction SM19. Transaction SM18 is used to delete old log files, and transactions SM20 and SM20N are used to evaluate the log. The security audit log allows so-called dynamic configurations, the settings of which can be changed at runtime, as well as so-called static configurations, requiring the system to be restarted if changes are made to the configuration settings.

The following should be taken into consideration when configuring the events to be logged:

• All events belonging to the "critical" class should be activated.
• All events belonging to the "serious" class should be activated.
• For events belonging to the "non-critical" class, it must be decided whether these events must be logged. It must be taken into consideration that such events may also include events that generate a large number of entries in the log. When the security audit log is full, no more entries will be recorded in the log.

Access to transactions SM18, SM19, SM20, and SM20N should be restricted to authorised administrators only. The security audit log must be evaluated regularly.

Review questions:

• Is there a logging concept for logging SAP events which, amongst other things, defines which activities of the SAP system and the user must be logged?
• Is access to the administrative functions and the logged data of the SAP system restricted?
• Are the system events of the SAP system logged (e.g. in the system log) evaluated regularly?
• Has the use of traces been restricted in the SAP system?
• Has it been determined within the framework of the logging and audit concept which tables change tracking should be activated for?
• Has the access to the monitoring tools of the SAP systems used been restricted to the authorised administrators?
• Is the SAP security audit log used?