Contact us today.

Subscribe me to your mailing list

SAP NetWeaver ABAP Security Configuration. Part 9: Security Events Logging

Ninth critical issue. Logging of security events. Let us remind you that the ERPScan’s team core purpose is to take the definition of the SAP security one step further by providing its own guidelines to help SAP users carry out various security checks. This article is no exception. Today, we will pay attention to the next critical issue, which is the last one but not the least important.

One of the essential aspects in ensuring the SAP security (and of any other critical system) is security event logging in place. In case of an incident (which is likely to happen because there are plenty of settings in such systems and it is difficult to control all of them), only the security audit configured correctly will allow a company to discover the fact of an attack in time and, perhaps, to arrange a response to it. Besides, the security audit configured correctly allows preventing attacks in the early stages of collecting system data.

The security event logging system is complicated with a lot of different logs for each SAP subsystem, with each of them able to store the sensitive information. Unfortunately, few of these logs may be centrally analyzed. This section contains the four most critical logs.

Further steps

In total, the SAP system contains about 30 critical and trace logs (for ABAP instance only). After enabling four basic logs described below, implement the fine-tuned settings, e.g., detailed table lists with enabled table logging, details of security event logging in security audit logs, event types in the SAP Gateway log, etc. Also, their central collection and storage implementation should be accompanied with critical events analysis. Only then, you may add and analyze more detailed optional logs for each service.

[EASAI-NA-30] Logging of security events


The SAP security audit log is an addition to the system log, but it has a slightly different purpose. In contrast to the system log that must be always active, a security audit log may be enabled and disabled if required being a tool for a detailed overview of all events in a SAP system. The main audit log purpose is to record:

  • the security-related events in the SAP system neighborhood (e.g., modifications in primary user accounts);
  • the information to make system more transparent (e.g., successful and invalid system logon attempts).
  • the information to reconstruct a chain of events (e.g., successful or failed transaction start).

Filters are used to determine what information should be recorded in the audit log file. In case of event that meets an active filter criteria (e.g., start of a transaction), the audit log generates an audit message and writes it to a file. Also, an appropriate notification will be sent to the CCMS Alert Monitor (SAP Computing Center Management System Alert Monitor) used to observe centrally the ABAP and Java components, reveal various categories of system and application errors in different interfaces. The detailed information on events is presented in the auditor’s report on the audit log vulnerability assessment. Using filters, you may specify actions needed to be recorded with SM19 transaction. To review the log, SM20 transaction is used. SM18 transaction allows removing old logs. The audit files are located at individual application servers. You may specify the file location and the maximum file size in the following profile parameters. The basic parameter is rsau/enable, which enables the audit log on the application server and by default is set to: 0 (inactive audit);


If the security event registration is not maintained, there is a risk of delayed response (or its absence) to a potential external attacks or internal fraud. An opportunity to carry out the Forensic Investigation after the fact of hacking is almost fully excluded, too.


It is necessary to set the rsau/enable parameter to “1” (enable) to enable the security event logging. Then, it is necessary to configure filters by specifying exactly what events should be monitored using the SM19 transaction.

[EASAI-NA-31] Logging of HTTP requests


If the ABAP application server is used for web connections by the ICM service, it is necessary to configure logging of the HTTP requests to the ABAP application server. The icm/HTTP/logging_<xx> parameter is used to manage the HTTP-requests logging in the ICM service (or web dispatcher), if the ICM operates as a server. This parameter defines if HTTP-requests logging is enabled for the ABAP sources. If the ICM acts as a client, you may use the icm/HTTP/logging_client_<xx> parameter for the HTTP logging. The icm/HTTP/* parameter set is valid for the HTTPS as well. The parameter syntax looks the following way: icm/HTTP/logging_<xx>=PREFIX=<URL prefix>, LOGFILE=<log file name> [LOGFORMAT=<format>, FILTER=<filter>, MAXSIZEKB=<size in KBytes>, SWITCHTF=<options>, FILEWRAP=on] The LOGFILE parameter value determines the output file name in the file system. The HTTP-requests logging are not executed if the LOGFILE value is not specified.


If the security event registration is not maintained, there is a risk of delayed response (or its absence) to potential attacks with the HTTP protocol use. These logs are highly critical, in case the ICM service has the Internet access. Forensic Investigations of an incident related to the Internet attacks is almost impossible with these service logs disabled.


Specify the OS file name in the icm/HTTP/logging_<xx> parameter in the LOGFILE value to collect all necessary information on potential attacks. It is essential for a Forensic Investigation.

[EASAI-NA-32] Logging of table changes


All SAP data are presented in tables. There are two different table categories:

  • Client tables contain data used for one client (mandant) only, e.g., the user system logon data in USR02.
  • Cross-client or client independent tables contain the data valid for all the system clients, such as, for example, the T000 table.

The SAP provides a table-modification logging option to determine what a user has changed, added or removed in the data from tables and when. There are two technical requirements; with both of them in place, you may be sure that table modifications are logged:

  • the general logging should be enabled;
  • the technical table parameters should be set to “Record data changes”.

The data recorded for these modifications is stored in the DBTABLOG table (DBTABPRT in lower versions). For them, the BC_DBLOGS archiving object may be used.

General logging The table changes are not logged by default. Activate the associated settings for the selected clients through the rec/client system parameter. This parameter may have the following values:

  • OFF (disabled logging),
  • All (logging is enabled for all the system clients),
  • <Client number>, (…) (logging for clients with the numbers filled in here).

This parameter covers only those table modifications originate from direct system changes. The modifications occurred as a result of transport activities (for example, import) do not interact with this parameter (“Logging through transports” is used for this).

Warning!: the changes are not recorded when copying client.

Table logging The table logging is controlled by an appropriate value in the technical table configuration (for display, the SE13 transaction is used). To review all the tables logged, the DD09L table is called with the SE16N transaction. It works with the tables where:

  • the maximum number of characters in the key field is 250;
  • the maximum number of character in the data fields is 3500;

Transport logging To log modifications resulted from transport activities, set up the associated transport parameters. These parameters may be enabled in the Transport Management System (TMS) with the STMS transaction. The desired values for the transport profile (All, <Client number>) are set in the recclient parameter (see SAP Security Note 163694 [1]).


With no direct table access logging, there is a risk of late or no response to potential unauthorized table data modifications, e.g., an adversary may change the bank account value in the LFBK table and commit fraud actions by money transfer to another account.


  • You should change the rec/client parameter to values corresponding to all production client numbers to collect all required information for a potential Forensic Investigation.
  • Automatic logging is not recommended in test systems, as this may lead to a very rapid disk space fill.
  • You should log all specific tables with all transaction, system control, setting and other main data, as well as all the data where logging is under question.
  • For production system, you should log all clients (rec/client = ALL), at least those of production. But if you set the rec/client parameter to ALL you may seriously affect the system performance.
  • For more information, see the following notes: 1916, 112388, 84052. [2] [3] [4]

[EASAI-NA-33] Logging of SAP Gateway activities


Each SAP instance has the SAP Gateway. The gateway ensures an interaction between the work processes and external programs, and also an interaction between the work processes from different instances or SAP systems. The gateway allows executing RFC services at a SAP system. Higher security requirements are applied to a gateway since it is an application server interface with other systems (other SAP systems, external programs, etc.), one of these requirements is a gateway logging activation. The gateway logging is used to control the gateway activity. You may configure what gateway actions exactly will be recorded in the log file. It is possible to configure the log maintenance in the gw/logging parameter or in the gateway monitor (the SMGW transaction). Notice that the gateway monitor is not available if a separate gateway or the Java-only installation are used. The parameter gw/logging contains various indicators that are responsible for logging of certain event types. The S indicator (i.e. Security) in the ACTION field is the most important allowing to record security configuration events and their modifications (e.g., file reloading), with other event types.


With no security event logging, there is a risk of late or no response to potential attacks on a gateway. The risk of a security breach is considerably increased by this service vulnerabilities known since 2007 and exploits available on the Internet and that enables to gain unauthorized access to the service and execute any OS commands.


  • Add S value to the ACTION field for the gw/logging parameter to increase the security level and receive all the information required for the potential Forensic Investigation.
  • Logging of other security event types is also advisable.

That’s it for today and remember that you shouldn’t let your ERP system fill up with vulnerabilities. With the help of our program you can easily keep your system protected.

Do you want more?

Subscribe me to your mailing list