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. We have covered :
- 9 the most important business application security critical issues [1],
- patch management flaws [2],
- default passwords for access to the application [3],
- unnecessary functionality [4],
- open remote management interfaces [5],
- security settings that do not fit into any of the critical issues groups [6],
- Access control and SOD conflicts [7],
- Unencrypted connections [8].
Today, we'll turn our attention to the next critical issue, which is the last one of all but not the least important.
One of the most important aspects to ensure 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 a plenty of settings in such systems and it is quite difficult to control all of them), only the security audit configured correctly will allow the 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 to prevent attack in the early stages of collecting system data.
Security event logging system is complicated with a lot of different logs for each SAP subsystem, with each of them able to store sensitive information. Unfortunately, few of these logs may be centrally analysed. This section contains 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, detailed 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 analyse more detailed optional logs for each service.
[EASAI-NA-30] Logging of security events
Description
The SAP security audit log is an addition to the system log, but with 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. The security audit log is a tool for a detailed overview of all events in a SAP system. The main audit log purpose is to record:
- security-related events in the SAP system neighbourhood (e.g., modifications in primary user accounts);
- information to make system more transparent (e.g., successful and invalid system logon attempts).
- 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 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. A 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);
Threat
If the security event registration is not maintained, there is a risk of delayed response (or its absence) to potential external attacks or internal fraud. An opportunity to carry out the Forensic Investigation after the fact of hacking is almost fully excluded, too.
Solution
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
Description
If the ABAP application server is used for web connections by the ICM service, then 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 is not executed if the LOGFILE value is not specified.
Threat
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.
Solution
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
Description
All SAP data are presented in tables. There are two different table categories:
- Client tables. They contain data used for one client (mandant) only, e.g., the user system logon data in USR02.
- Cross-client or client independent tables. These contain data valid for all the system clients, such as, for example, the T000 table.
The SAP provides 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/clientsystem 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 that result 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 [9]).
Threat
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.
Solution
- 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 ALLyou may seriously affect the system performance.
- For more information, see the following notes: 1916, 112388, 84052. [10][11][12]
[EASAI-NA-33] Logging of SAP Gateway activities
Description
Each SAP instance has the SAP Gateway. The gateway ensures interaction between work processes and external programs, and also interaction between the work processes from different instances or SAP systems. The gateway allows to execute 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 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 being also important.
Threat
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 get unauthorized access to the service and execute any OS commands.
Solution
- Add S value to the ACTION field for the gw/logging parameter to increase the security level and gain all information required for the potential Forensic Investigation.
- Logging of other security event types is also advisable.