Security – Page 6 – Saptechnicalguru.com

This blog will explain the SAP audit log.

Questions that will be answered are:

What is the intended goal of the SAP audit log?
How to switch on the SAP audit log?
What are the recommended settings for the SAP audit log?
What are the common issues with audit logging?
Can I get anonymous access to the audit logging?
How can I get statistics on audit logging?
How can I get a where used list from the audit logging?
How can I archive audit log data for long term storage?
How can I delete audit logging?

Goal of SAP audit log

The goal of the SAP audit log is to capture all audit and security relevant actions. The audit logging function can capture failed logon attempts, dangerous actions like debug & replace, execution of transactions and programs, and many more.

SAP has a note for the frequently asked questions:

Older versions: 539404 – FAQ: Answers to questions about the Security Audit Log.
Newer versions (as of 7.50): 2191612 – FAQ | Use of Security Audit Log as of SAP NetWeaver 7.50

Also interesting read is this note: 3352573 – How to check transactions executed by an user in AS ABAP.

Audit log and privacy

The audit log will capture actions performed in the system. It will not only capture the actions, but also the user ID and terminal ID. This makes the tool a bit of a big brother is watching you tool. Auditors are normally used to dealing with sensitive topics. But next to answering audit questions the audit can also be misused to check ‘is this person doing a lot of work in the system’. For this reason access to audit log should only be given to persons who understand the sensitivity and people privacy. This includes in giving information to managers extracted from the audit log.

Anonymous audit log reporting

In the SAP audit log user names and terminal ID’s are visible. This is in many cases privacy information. Due to privacy rules and regulations the audit log access might be very restricted or cumbersome. Especially when the audit logging is to be used for analysis purposes, rather than for audit. If OSS note 2883981 – RSAU_READ* | anonymized display of Security Audit Log data is applied, a new transaction is created. This new transaction, RSAU_READ_LOG_ADM, shows all the information, but now with user ID and terminal ID columns in anonymous mode.

Switching on the audit log

For switching on the audit log first the corresponding system parameters must be set:

rsau/enable: set to 1 to enable
rsau/local/file: set the file location in format “/usr/sap/<SID>/<instno>/log/
audit_<SAP_instance_number>” (yes, unfortunately audit log still uses a file)
rsau/max_diskspace_local: max disk space (set to at least 1 GB)
rsau/selection_slots: default is 2, but typically this is set to 10 slots

Unfortunately these parameters are not dynamic, which means a system restart is required to activate these parameters.

After the activation you can go to transaction SM19 (or in newer version to RSAU_CONFIG) to switch on the audit logging in detail.

First step is to create a profile and activate it.

Next step is to setup the filters.

Audit log filters

The audit log filters are used to filter events. If you select all events this will cause logging shadow and make the function unreliable.

To configure the filters use transaction RSAU_CONFIG (this is replacing old SM19 transaction).

Main client versus 000, 001 and 066 client

SAP has multiple clients. The 000, 001 and 066 client are only used by system admins. For these clients you can setup a special filter and log ALL actions for ALL users. This will not cause too many entries.

If you want to fully avoid SAPSYS entries, follow the instructions from this blog section.

Main client logging settings

In the main client you have to be selective on the checks.

The audit log has 3 classification of checks:

Critical (always switch these on!)
Severe (if possible switch on as well)
Uncritical (be very selective for switching these on)

Key filters recommendations

ALWAYS switch on the critical checks. This will include:

Debug & replace actions
Debug start
Changes to audit log configuration itself
User creation
Failed logon attempts
User locks due to wrong password

From the severe and uncritical sections the following checks are useful:

Logon failed: this can help to detect logon attempts with standard users (see blog on SAP standard users): the audit log will capture the terminal ID from which the attempt happened
Start of report failed: will avoid discussions if people really could start or not
Report started: though in many productive systems SE38 etc is not allowed for directly starting a report outside a transaction code, this still will happen by admins and firefighter. This check will log which direct report is started
Transaction locked and unlocked: capture locking and unlocking of transactions with SM01 in old systems (and SM01_DEV and SM01_CUS in newer systems)
Transaction started: this will avoid discussion if people key in the tcode or not (do remember that audit log captures the start; it can still be user is not authorized to continue with the transaction). And many RBE (reverse business engineering) type of tools rely on this audit log tracing rather than the ST03 logging. Reason is that the audit log is on user level rather then aggregated level and is usually kept longer.
User deleted, user locked and user unlocked
Password changed for user

SE92 audit log details

Using transaction SE92 you can get a more easy overview of the settings definitions as provided by SAP for the audit log details. Read more in this blog.

RSAU_CONFIG configuration overview

Using transaction RSAU_CONFIG you can get a more easy overview of the actual activation and configuration.

Audit log reporting

Transaction codes SM20 or RSAU_READ_LOG can be used to view the audit log results.

Be careful to whom you give the rights to read the audit log.

Audit log settings overview

You can use transaction RSAU_CONFIG_SHOW to get an overview of the audit log settings.

New checks

With every new SAP release SAP improves the audit log. By default the audit logging is not updated after an upgrade. Therefore it is wise to check for new items added to the audit log after an upgrade.

Determining changes to audit log settings

OSS note 2680888 – SAL | Report for determination of differences in event parameters is delivering new report RSAU_READ_LOG_DIFF to show changes done to the audit log configuration:

Delete SAP audit log files

Start transaction RSAU_ADMIN and start the option for log file reorganization:

Or you can run/schedule program RSAUPURG.

Restricted access to this function is a must.

Archiving audit logging

There might be requirements from security or business side that require you to find a solution for long term storage of the audit log data. Deletion as explained above could not be an option for you.

To archive audit logging data, activate the settings for archiving object BC_SAL. Read this blog on the exact technical execution of archiving runs.

OSS notes to be applied for the audit log archiving function:

Issues with audit logging

There are some known issues with the audit logging.

Logging shadow

If too much items are selected in the filters the audit logging will grow very fast. If the audit log is full, it will start to overwrite the earlier entries. The earlier entries are then lost. This is called logging shadow. Depending on your requirements, you have to increase the disk space, and better: check which item in the audit log settings you don’t need, but do cause extensive amount of logging.

Large SAP systems with multiple application servers

On large SAP systems with multiple application servers, the file handling can cause issues. If the system is setup using shared files and the names of the profile configuration per application server for the file name is identical, this will cause nasty issue. The issue is that the audit logging from several application servers will overwrite each other entries. This is hard to detect. Solutions: don’t use shared file, or change the profile parameter per application server to include the application server name into the audit log file name. To do this set the FN_AUDIT parameter to this value: SQL_++++++++.AUD. Upon runtime the +’s will be replaced with the application server name.

See point 25 in the audit log FAQ note 539404 – FAQ: Answers to questions about the Security Audit Log. And point 12 in the new (as of Netweaver 7.50) note 2191612 – FAQ | Use of Security Audit Log as of SAP NetWeaver 7.50.

Audit logging integrity

Based on the settings in OSS note 2033317 – Integrity protection format for Security Audit Log, you can switch on the audit logging integrity. This way you can prove nobody tampered with the audit log. But this also means you cannot read the audit logfile on file level or by any third party tool. Please consider this carefully and read the note about other effects and prerequisites first before switching on.

Where used list and audit log statistics

On newer versions (or via notes below) there are 2 new programs available:

RSAU_GET_STAT for statistical information
RSAU_GET_WUSL for a where used list of security events

To get this function apply these OSS notes:

Audit log self check

To get this function apply the same notes as for the audit log statistics:

Then you can run program RSAU_SELF_CHECK_DIA.

If you want to run the Still Alive Check:

You first have to make sure to activate Audit test event AU0:

Auditing user SAP*

If you need to audit user SAP*, the * is a wildcard. You have to use the escaped version: SAP#*. See SAP help link.

Background OSS notes and blogs

Logging incidents for SAL (SAP Audit Log): 3295213 – Required information for analyzing issues with the Security Audit Log (AS ABAP) within the new SAL environment.

Useful background OSS notes and blogs are:

Known bugs and bug fixing OSS notes

Bug fixing OSS notes:

This blog post will explain the process for dealing with SAP standard users.

Questions that will be addressed:

Why are there SAP standard users?
Which users are there?
How to check if the standard SAP users are dealt with properly to avoid security issues and how to solve them?
How to detect if somebody is trying to logon with standard SAP user?
How to deal with standard SAP user DDIC in client 000?
How to deal with standard SAP user TMSADM

Why SAP standard users and which ones are there?

After initial installation of SAP there is only one way to login: is via the standard user SAP* with password PASS. After logon, create your own user and disable user SAP* by giving it a new password and lock it. SAP* can be there without profiles and roles. Also set parameter login/no_automatic_user_sapstar to 1 to avoid automatic re-creation of SAP*. SAP has new way of dealing with superuser SAP*; read this dedicated blog.

To set up the SAP ABAP system code the standard user DDIC is used. This user compiles the ABAP code.

For software deployments the initial setup must be done by user TMSADM (TMS = transport management system, ADM = admin).

For historical reasons also the EARLYWATCH and SAPCPIC user are still present.

How to check standard SAP user settings and how to solve issues?

SAP delivers standard program RSUSR003 to check for correct setting of these users ID’s and passwords. Transaction code for this program is also RSUSR003.

End result should look like:

If any item has a red or yellow color you should act: link to solution.

How to check if standard users are being unlocked?

You can use SAP Focused Run to have a custom metric to detect when a standard user is unlocked. You can configure an alert mail to be sent 5 minutes after the unlock happens. More information on this: read this blog.

How to detect if somebody is trying to hack a system by trying to log in using standard SAP users?

There are 2 main ways of finding if standard SAP users are being tested for system access:

Somebody runs report RSUSR003 (whitebox method)
Somebody tries to use the users and passwords from outside (blackbox method)

Detection of running RSUSR003

Two ways of detection of running RSUSR003:

SM21 system log will show similar entry:

In this log you can see the user of the program and by double clicking you can also retrieve the terminal ID from which the user ran the program.

More background in OSS note 2248319 – Program RSUSR003 reports “Security violation” in SM21 system log.

SM20 audit log can show similar entry (provided the start of report is configured properly):

Also here you can see the user who ran it and from which terminal.

The exact scope of program RSUSR003 is described in OSS note 2481566 – Functional scope of report RSUSR003.

Bug fix note: 3224200 – SUIM | RSUSR003 displays lock by unsuccessful logon.

Detection of black box standard SAP user testing

SM20 audit log can show similar entry (incorrect logon attempts configured properly):

User DDIC in client 000

In many blogs there is a lot of discussion on how to deal with DDIC in client 000. There is no one size fits all approach here.

SAP standard recommendation is:

“To make sure everything runs smoothly, give DDIC the authorizations for SAP_ALL during an installation or upgrade and then lock it afterwards. Only unlock it when necessary.”

This is fine for smaller systems on which little maintenance is ongoing. If more frequently support packs, upgrades and/or installations are happening this is more annoying.

The main issue is when a system is using third party solutions which are provided by external parties in transports. When DDIC is locked in client 000 and the foreign transport is imported, this import will not finish and continues forever until DDIC is unlocked.

That is why on systems with more maintenance, and less strict regimes (business without SoX and FDA, etc), DDIC will not be locked on client 000 and the password is known to basis team. DDIC should be locked in all the other clients.

DDIC unlock in main client is needed only when implementing a TCI based OSS note (see blog on OSS notes).

Background OSS note on DDIC: 1998382 – User DDIC for Transport Activities.

Also read this note: 3035580 – Job RDDIMPDP running as DDIC to replace DDIC with different job user for import dispatchers.

User TMSADM

User TMSADM needs to exist in client 000. It can be deleted in all the other clients (including the main data client). Background on SAP help.

Password change instructions for user TMSADM: 1568362 – TMSADM password change.

User SAPSYS

SAPSYS is used for OS jobs, CCMS monitoring, running the background processing scheduler, and performing other system-internal operations (most of them executed as so-called AutoABAP programs). Don’t lock SAPSYS otherwise you get big issues.

Reference OSS note: 3195498 – SAPSYS user modifying background jobs.

Cross client hacking

See this blog on how a hacker can jump from one client to the other.

Client 001 and 006 deletion

To reduce the attack surface, you can also delete clients 001 and 066. See this blog for more background information.

Standard users in the Early Watch

Standard users are also listed in the early watch. Sometimes with a little different logic. The explanation of standard users in the EWA is kept in OSS note 1610103 – EWA : Default Password of Standard Users – Detailed overview for T/S.