This document was generated from the following discussion: Recommended Settings for the Security Audit Log (SM19 / SM20)
This blog had started to give recommendations about settings for the Security Audit Log, but in the meantime it had evolved to show tips & tricks in general.
- Profile Parameters / Kernel Parameters
- Filter settings in SM19
- List of events
- File format
- Terminal ID versus IP Address
- (German) Data Protection
- GRC Fire Fighter logging
- How to create customer-specific events
- How to read the long texts of events
- How to log critical debugger events
- How to track changes on the settings
- What is the meaning of message BU4?
- How can I read events using BAPIs?
- How to get a cross-reference about the creation of messages?
- How to avoid logging for Auto-ABAP (SAPSYS) processing
Recommended Settings for the Security Audit Log (SM19 / SM20)
Profile Parameters / Kernel Parameters
rsau/enable = 1
rsau/selection_slots = 10 (or higher if available)
rsau/user_selection = 1
DIR_AUDIT and FN_AUDIT define the path and the file name pattern for the log files.
As of release SAP_BASIS 7.40 you can use the so-called “Kernel Parameters” instead of the listed Profile Parameters. You find them on a new tab in transaction SM19. See chapter Preparing the Security Audit Log in the Online Documentation. You can set them dynamically and once set they overwrite the values of the profile parameters. Take care to inspect these Kernel Parameters after an upgrade to SAP_BASIS 7.40 or higher.>
Filter settings in SM19
Depending on the release you can set 10, 15 (as of SAP_BASIS 7.40 SP 8) or 90 (as of SAP_BASIS 7.50 SP 2) filters. See FAQ Note 539404 item .
1. Filter: Activate everything which is critical for all users ‘*’ in all clients ‘*’.
- You may deactivate the messages of class “User master record change (32)” because you get change documents for users in transaction SUIM anyway.
- Consider to add messages AUO, AUZ, BU5, BU6, BU7, BU9, BUA, BUB BUC, BUH, AUP, AUQ
- If you maintain logical file names using transaction FILE (see note 1497003) than add messages CUQ, CUR, CUS, CUT, DU5
- If you maintain an Access Control List for RFC callback (see note 2128095) than add messages DUI, DUJ, DUK
2. Filter: Activate everything for special user SAP* in all clients ‘*’
You cannot use a filter ‘SAP*’ because this would include the virtual user SAPSYS because of profile parameter rsau/user_selection = 1. This virtual user SAPSYS performs many house-keeping activities triggered by the system itself. You do not want to log these events.
However, you can use the special filter value ‘SAP#*’ instead.
You can use this special filter value ‘SAP#*’ in transaction SM20 or report RSAU_SELECT_EVENTS as well to show log entries in for user SAP* only.
If you can defines filters for user groups (see note 2285879) then you can create filters for user groups like SUPER instead. This has the additional advantage that the built-in user SAPSYS does not produce any logs.
3+4. Filter: Activate everything for other support and emergency users, e.g. ‘SAPSUPPORT*’ (SAP Support users) respective ‘FF*’ (FireFighter) in all clients ‘*’.
If you can defines filters for user groups then you can create filters for corresponding user groups instead.
5. Filter: Activate all events for the dialog activities ‘logon’ and ‘transaction’ for user ‘DDIC’ in all clients ‘*’. This user should not be used in dialog mode. It’s only required for specific activities while applying support packages or while importing transports (however in this case you can use another background user as well).
6. Filter: Activate everything for client ‘066’. This client is not used anymore and can be deleted (see http://scn.sap.com/community/security/blog/2013/06/06/how-to-remove-unused-clients-including-client-001-and-066 ).
7. Filter: Activate RFC events (AUL, AUK, AU6, AU5) for a short time for selected users to identity RFC connection problems easily (see http://scn.sap.com/community/security/blog/2010/12/05/how-to-get-rfc-call-traces-to-build-authorizations-for-srfc-for-free ).
8. and following Filter: free for other project specific purpose
The client field accepts either single values like 000 or a * to catch all clients.
The user field accepts pattern characters as well (see note 574914):
* any sequence of characters (only the first * within the filter string is interpreted as a pattern character)
+ one character
# disable following pattern character
The user group field accepts exacts values only.
Using the print function (command PRINT) in transaction SM19 or using report RSAU_INFO_SYAG you can show an overview about the current settings.
List of events
If you miss some of the events described in this document then search for notes of application component BC-SEC-SAL.
Using note 1970644 you can get report RSAU_INFO_SYAG which shows all events of the Security Audit Log including a summarized status about the activation of the events. The detail view allows you to create an HTML-based event definition print list including the full documentation.
Within transaction SM19 you can use the system function =PRINT (respective the printer icon in the top icon row) to document the definition of static profiles as well as the current definition of the dynamic configuration. This list shows the details about all filter slots.
Events ordered by selected topics and security optimization projects:
|Topic Keyword||Description and references||Message|
RFC callback (note 2128095)
Project: “Secure RFC Callback”
|DUI DUJ DUK|
|CUSTOM||Custom specific events using function module RSAU_WRITE_CUSTOMER_EVTS (note 1941526)||DUX DUY DUZ|
|DEBUG||Debugging (change mode)||BUZ, CUL, CU_M, CUN, CUO, CUP, CUY (BUY is obsolete)|
|EHS-SADM||(note 1792047)||DUA DUB DUC DUD DUE DUF DUG|
Directory Traversal (note 1497003)
Project: “Secure File access”
|CUQ CUR CUS CUT DU5|
|OAUTH||OAuth 2.0||(AU2) BUV BUW DUH|
|RAL||Read Access Logging (note 1902280)||BU0 CU0 DU0|
|RBAM||Role Based Access Management in SAP Business ByDesign system (note 948275)||BUI BUJ|
Project: “Avoid SA38 by using custom report transactions”
Generic table access via RFC using functions like RFC_READ_TABLE (note 1539105)
Project: “Secure standard table access (authorization object S_TABU_RFC)”
Switchable authorization scenarios, transaction SACF (note 2078596)
Project: “Secure RFC functions”
|DUO DUP DUQ DUU DUV|
|SAML||SAML Authentication, transaction SRTUTIL (note 1570266)||(AU2) BUK BUL BUM BUN BUO BUP CUA CUB CUC CUD CUE CUF CUG CUH|
FTP server whitelist using table SAPFTP_SERVERS (note 1605054)
See note 2312710 for more information about these messages.
Project: “Secure SAP FTP”
|DU1 DU2 DU3 DU4 DU5 DU6 DU7 DU8|
Generic table access using transactions like SE16, SE16N, SM30, SM31, SM34, or SQV (note 2041892)
Project: “Secure standard table access (authorization object S_TABU_DIS, S_TABU_NAM)”
|SLDW||Generic whitelists||DUL DUM DUN|
SNC Client Encryption (note 2104732)
Project: “Encrypt SAPGUI comminication”
|TCODE||Transactions||AU3 AU4 AUP AUQ|
|USER||Change user master data (not required as you get change documents anyway)||BU2 AU8 AU7 AU9 AUA AUB AUD AUR AUS AUT AUU|
|WEB-SERVICE||Web service calls (note 1620477)||CUV CUW|
|XSRF||XSRF attacks (note 1619912)||BUS|
Note 2073809 shows special documentation/changes about the messages
- BUY (which is replaced by message CUL),
- CUY (which is related to debugger messages BUZ, CUL, CU_M, CUN, CUO, CUP), and
- CUZ (which is related to message DU9).
List of events from table TSL1D respective report RSAU_INFO_SYAG.
This list is a snapshot – check it in your system – with a comparison between release 702 and 740. Some of the new messages may be added with 731 or with downports already.
|Audit Class||Message ID||Event class||New in release||Message|
|Dialog Logon||AU1||Severe||Logon successful (type=&A, method=&C)|
|Dialog Logon||AU2||Critical||Logon failed (reason=&B, type=&A, method=&C)|
|Dialog Logon||AUC||Non-Critical||User Logoff|
|Dialog Logon||AUM||Critical with Monitor Alert||User &B Locked in Client &A After Erroneous Password Checks|
|Dialog Logon||AUN||Critical||User &B in Client &A Unlocked After Being Locked Due to Inval.Password Entered|
|Dialog Logon||AUO||Severe||Logon Failed (Reason = &B, Type = &A)|
|Dialog Logon||BUD||Critical||WS: Delayed logon failed (type &B, WP &C). Refer to Web service log &A.|
|Dialog Logon||BUE||Non-Critical||WS: Delayed logon successful (type &B, WP &C). Refer to Web service log &A.|
|Dialog Logon||BUI||Critical||SPNego replay attack detected (UPN=&A)|
|Dialog Logon||BUK||Non-Critical||&A assertion used|
|Dialog Logon||BUL||Non-Critical||&A: &B|
|Dialog Logon||BUM||Non-Critical||Name ID of a subject|
|Dialog Logon||BUO||Non-Critical||Authentication assertion|
|Dialog Logon||BUQ||Non-Critical||Signed LogoutRequest accepted|
|Dialog Logon||BUR||Non-Critical||Unsigned LogoutRequest accepted|
|Dialog Logon||CU2||Severe||740||OAuth 2.0: Invalid access token received (reason=&A)|
|Dialog Logon||CU3||Severe||740||OAuth 2.0: Insufficient OAuth 2.0 scope for requested resource (user=&A)|
|Dialog Logon||CU4||Critical||740||OAuth 2.0: Logged-on client user &A not same as parameter client ID &B|
|Dialog Logon||CU5||Severe||740||OAuth 2.0: Client &A requested invalid access grant type &B|
|Dialog Logon||CU6||Critical||740||OAuth 2.0: Client ID &A in SAML assertion not same as client ID &B in request|
|Dialog Logon||CU7||Severe||740||OAuth 2.0: Scope &B not permitted for client &C, user &D (cause=&A)|
|Dialog Logon||CU8||Non-Critical||740||OAuth 2.0: Access token issued (client=&A, user=&B, grant type=&C)|
|Dialog Logon||CU9||Non-Critical||740||OAuth 2.0: Valid access token received for user &A|
|Dialog Logon||CUA||Severe||Rejected Assertion|
|Dialog Logon||CUB||Severe||&A: &B|
|Dialog Logon||CUD||Severe||Name ID of a subject|
|Dialog Logon||CUF||Severe||Authentication Assertion|
|Dialog Logon||CUG||Severe||Signed LogoutRequest rejected|
|Dialog Logon||CUH||Severe||Unsigned LogoutRequest rejected|
|Dialog Logon||DU0||Critical with Monitor Alert||Invalid SAP GUI data|
|RFC Logon||AU5||Non-Critical||RFC/CPIC logon successful (type=&A, method=&C)|
|RFC Logon||AU6||Critical||RFC/CPIC logon failed, reason=&B, type=&A, method=&C|
|RFC Function Call||AUK||Non-Critical||Successful RFC Call &C (Function Group = &A)|
|RFC Function Call||AUL||Critical||Failed RFC Call &C (Function Group = &A)|
|RFC Function Call||CUV||Non-Critical||Successful WS Call (service = &A, operation &B)|
|RFC Function Call||CUW||Critical||Failed Web service call (service = &A, operation = &B, reason = &C)|
|RFC Function Call||CUZ||Critical||Generic table access by RFC to &A with activity &B|
|RFC Function Call||DU1||Severe||FTP server whitelist is empty|
|RFC Function Call||DU2||Severe||FTP server whitelist is non-secure due to use of placeholders|
|RFC Function Call||DU3||Critical||Server &A is not contained in the whitelist|
|RFC Function Call||DU4||Critical||Connection to server &A failed|
|RFC Function Call||DU5||Critical||There is no logical file name for path &A|
|RFC Function Call||DU6||Non-Critical||Validation for &A successful|
|RFC Function Call||DU7||Critical with Monitor Alert||Validation for &A failed|
|RFC Function Call||DU8||Non-Critical||FTP connection request for server &A successful|
|RFC Function Call||DUI||Non-Critical||RFC callback performed (destination &A, called &B, callback &C)|
|RFC Function Call||DUJ||Critical||RFC callback rejected (destination &A, called &B, callback &C)|
|RFC Function Call||DUK||Critical||RFC callback in simulation mode (destination &A, called &B, callback &C)|
|RFC Function Call||DUR||Non-Critical||JSON RPC call of function module &A succeeded|
|RFC Function Call||DUS||Non-Critical||JSON RPC call of function module &A failed|
|RFC Function Call||DUT||Critical||Critical JSON RPC call of function module &A (S_RFC * authorization)|
|RFC Function Call||FU1||Non-Critical||740||RFC function &B with dynamic destination &C was called in program &A|
|Transaction Start||AU3||Non-Critical||Transaction &A Started|
|Transaction Start||AU4||Critical||Start of transaction &A failed (Reason=&B)|
|Transaction Start||AUP||Severe||Transaction &A Locked|
|Transaction Start||AUQ||Severe||Transaction &A Unlocked|
|Transaction Start||BUX||Severe||740||Test message|
|Transaction Start||CUI||Non-Critical||740||Application &A started|
|Transaction Start||CUJ||Critical||740||Failed to start application &A (reason =&B)|
|Transaction Start||DU9||Non-Critical||Generic table access call to &A with activity &B (auth. check: &C )|
|Report Start||AUW||Non-Critical||Report &A Started|
|Report Start||AUX||Severe||Start Report &A Failed (Reason = &B)|
|User Master Record Change||AU7||Critical||User &A Created|
|User Master Record Change||AU8||Severe||User &A Deleted|
|User Master Record Change||AU9||Severe||User &A Locked|
|User Master Record Change||AUA||Severe||User &A Unlocked|
|User Master Record Change||AUB||Severe||Authorizations for User &A Changed|
|User Master Record Change||AUD||Severe||User Master Record &A Changed|
|User Master Record Change||AUR||Severe||&A &B Created|
|User Master Record Change||AUS||Severe||&A &B Deleted|
|User Master Record Change||AUT||Severe||&A &B Changed|
|User Master Record Change||AUU||Critical||&A &B Activated|
|User Master Record Change||BU2||Non-Critical||Password changed for user &B in client &A|
|User Master Record Change||BUV||Critical||740||Invalid hash value &A. The context contains &B.|
|User Master Record Change||BUW||Critical||740||A refresh token issued to client &A was used by client &B.|
|User Master Record Change||DUH||Severe with Monitor Alert||740||OAuth 2.0: Token declared invalid (OAuth client=&A, user=&B, token type=&C)|
|Other events||AU0||Non-Critical||Audit – Test. Text: &A|
|Other events||AUV||Critical||Digital Signature Error (Reason = &A, ID = &B)|
|Other events||AUY||Severe||Download &A Bytes to File &C|
|Other events||AUZ||Severe||Digital Signature (Reason = &A, ID = &B)|
|Other events||BU0||Critical with Monitor Alert||RAL configuration access: Action: &A, type: &B, name &C|
|Other events||BU1||Critical with Monitor Alert||Password check failed for user &B in client &A|
|Other events||BU3||Critical with Monitor Alert||Security check changed in export: Old value &A, new value &B|
|Other events||BU4||Non-Critical||Dynamic ABAP code: Event &A, event type &B, check total &C|
|Other events||BU5||Severe||ICF recorder entry executed for user &A (activity &B)|
|Other events||BU6||Severe||ICF recorder entry executed by user &A (&B, &C) (activity &D).|
|Other events||BU7||Severe||Administration setting was changed for ICF Recorder (Activity: &A)|
|Other events||BU8||Critical||Virus Scan Interface: Virus “&C” found by profile &A (step &B)|
|Other events||BU9||Severe||Virus Scan Interface: Error “&C” occurred in profile &A (step &B)|
|Other events||BUA||Severe||WS: Signature check error (reason &B, WP &C). Refer to Web service log &A.|
|Other events||BUB||Severe||WS: Signature insufficient (WP &C). Refer to Web service log &A.|
|Other events||BUC||Severe||WS: Time stamp is invalid. Refer to Web service log &A.|
|Other events||BUF||Non-Critical||HTTP Security Session Management was activated for client &A.|
|Other events||BUG||Critical with Monitor Alert||HTTP Security Session Management was deactivated for client &A.|
|Other events||BUH||Severe with Monitor Alert||HTTP Security Session of user &A (client &B) was hard exited|
|Other events||BUJ||Severe||Non-encrypted &A communication (&B)|
|Other events||BUS||Critical||&A: Request without sufficient security characteristic of address &B.|
|Other events||BUT||Severe||740||CRL download failed with error code &A|
|Other events||BUU||Critical||740||Certificate check for subject “&A” with profile &B failed (status &C)|
|Other events||BUY||Critical||Field contents changed: &5&9&9&9&9&9|
|Other events||BUZ||Very Critical||> in program &A, line &B, event &C|
|Other events||CU0||Critical||RAL Log Access: Action: &A|
|Other events||CU1||Severe||CU Test Message|
|Other events||CUK||Critical||C debugging activated|
|Other events||CUL||Very Critical||Field content changed: &A|
|Other events||CU_M||Very Critical||Jump to ABAP Debugger: &A|
|Other events||CUN||Very Critical||A manually caught process was stopped from within the Debugger (&A)|
|Other events||CUO||Very Critical||Explicit database commit or rollback from debugger &A|
|Other events||CUP||Very Critical||Non-exclusive debugging session started|
|Other events||CUQ||Severe||Logical file name &A not configured. Physical file name &B not checked.|
|Other events||CUR||Severe||Physical file name &B does not fulfill requirements from logical file name &A|
|Other events||CUS||Severe||Logical file name &B is not a valid alias for logical file name &A|
|Other events||CUT||Severe||Validation for logical file name &A is not active|
|Other events||CUU||Non-Critical||Payload of PI/WS message &A was read | &B|
|Other events||CUX||Non-Critical||Payload of postprocessing request &A read|
|Other events||CUY||Non-Critical||> &A|
|Other events||DUA||Severe||740||EHS-SADM: Service &A created on host &B|
|Other events||DUB||Severe||740||EHS-SADM: Service &A started on host &B|
|Other events||DUC||Severe||740||EHS-SADM: Service &A ended on host &B|
|Other events||DUD||Severe||740||EHS-SADM: Service &A deleted on host &B|
|Other events||DUE||Non-Critical||740||EHS-SADM: Configuration of service &A changed on host &B|
|Other events||DUF||Non-Critical||740||EHS-SADM: File &A transferred from host &B|
|Other events||DUG||Non-Critical||740||EHS-SADM: File &A transferred to host &B|
|Other events||DUL||Non-Critical||Check for &A in whitelist &B was successful|
|Other events||DUM||Severe with Monitor Alert||Check for &A in whitelist &B failed|
|Other events||DUN||Critical with Monitor Alert||Active whitelist &A changed ( &B )|
|Other events||DUO||Non-Critical||Authorization check for object &A in scenario &B successful|
|Other events||DUP||Non-Critical||Authorization check for object &A in scenario &B failed|
|Other events||DUQ||Critical with Monitor Alert||Active scenario &A for switchable authorization checks changed – &B|
|Other events||DUU||Non-Critical||Authorization check for user &C on object &A in scenario &B successful|
|Other events||DUV||Non-Critical||Authorization check for user &C on object &A in scenario &B failed|
|Other events||DUX||Non-Critical||740||TEMP: Customer-specific event DUX &A &B &C &D|
|Other events||DUY||Non-Critical||740||TEMP: Customer-specific event DUY &A &B &C &D|
|Other events||DUZ||Non-Critical||740||TEMP: Customer-specific event DUZ &A &B &C &D|
|Other events||EU3||Critical||750||&A change documents deleted without archiving (&B)|
|Other events||FU2||Severe||740||Parsing of an XML data stream canceled for security reasons (reason = &A)|
|System / housekeeping||AUE||Very Critical||Audit Configuration Changed|
|System / housekeeping||AUF||Very Critical||Audit: Slot &A: Class &B, Severity &C, User &D, Client &E, &F|
|System / housekeeping||AUG||Very Critical||Application Server Started|
|System / housekeeping||AUH||Very Critical||Application Server Stopped|
|System / housekeeping||AUI||Very Critical||Audit: Slot &A Inactive|
|System / housekeeping||AUJ||Very Critical with Monitor Alert||Audit: Active Status Set to &1|
|System / housekeeping||EU1||Very Critical||750||System changeability changed (&A to &B)|
|System / housekeeping||EU2||Very Critical||750||Client setting for &A changed (&B)|
|System / housekeeping||FU0||Very Critical||750||Exclusive security audit log medium changed (new status &1)|
Warning: The file format is defined SAP internally – it’s not an official definition which can be used freely. Use the information with care as storage and format can change with newer releases.
As of release 7.50 you can choose if log events are stored in the files as described in this section or in the database table RSAU_BUF_DATA or at both locations (see note 2191612).
Use report RSAU_SELECT_EVENTS to analyze the file format.
The audit files have a structured but variable record layout in unicode text format.
The administrative information is fixed, however, there exist 2 record formats depending on the existence of the additional field SLGLTRM2.
The data part, field SLGDATA, containing 64 characters has a variable sub-structure containing several parameter values. Often these values are separated by ‘&’ matching to the message variables &A, &B, etc. of the message definition. If you don’t find an ‘&’ than you will have fixed length parameter values matching to the message variables &n (n is a number describing the count of characters) within the message definition.
Relevant DDIC structures:
RSLGENTR SysLog entry
RSAUENTR2 Security Audit Log Entry Version 2 with Long Terminal Names
Example of an entry in a .aud file:
2AU520130409010803000505200009D9a234ba.pDOKUSTAR SAPMSSY1 0201R&0 h020co.pt.com
This leads to the following file format:
|SLGTYPE||SysLog: LIKE structure RSLGETYP|
|SLGFTYP||1||Entry type: “q” = version 1 without field SLGLTRM2, “2” = version 2 including field SLGLTRM2|
|SLGDATTIM||Time stamp (CHAR 16)|
|DATE||8||Date in format YYYYMMDD|
|TIME||6||Time in format hhmmss|
|SLGPROC||SysLog: LIKE RSLGPID structure|
|SLGTTYP||2||Process type (short form)|
|SLGLTRM||8||Terminal name (truncated)|
|SLGMODE||1||External mode of an SAP dialog|
|SLGDATA||64||Variable message data|
|SLGLTRM2||20||Terminal name (continued), only available if SLGFTYP=2|
- the format of the variable message data
- the message class (logon, transaction start, report start, RFC logon, user master record change, RFC start, miscellaneous, and system)
- the severity (critical, important, non-critical)
- and the monitoring alert settings (with, without)
are not visible within the file, but only in the message definition in table TSL1D (the key fields are AREA and SUBID).
Terminal ID versus IP Address
The Security Audit Log normally logs the terminal id if it’s available; otherwise the IP address is logged. You can set the (undocumented) profile parameter rsau/ip_only to the value 1 to log the IP address instead (if available). See note 1497445 for details.
Use the following options to get the terminal id and the IP address of active users:
- Transaction SM04 shows the IP address of the GUI client as well if you change the layout. (Limited to currently active users.)
- Table USR41 containing the last logon date shows both terminal id and the IP address in field TERMINAL. Maybe it’s possible to activate table logging using SE13 to get the history, too. Than you could merge this data with the log entries.
- Maybe you can try to use user exit SUSR0001 to log IP address (from function TH_USER_INFO and/or table USR41) in a custom table or via creating additional Security Audit Log entries for message AU1 (sucessful logon) for which you e.g. set the parameter &A or a new parameter &B with the IP address. See function RSAU_WRITE_TRAC_AUDIT_LOG to understand how to create such entries. (Limited to dialog logon only.)
There exist strong limitations of logging terminal ID and IP address in ABAP. A malicious user could spoof the terminal ID easily. The IP address can be problematic, too. For example if a reverse proxy (e.g. web dispatcher) for HTTP access is used, then all users will have the same IP address.
(German) Data Protection
Would the German Data protection authorities have an issue with activating this level of logging?
From a general point of view I would start with following assumptions:
1. Filter: Activate everything which is critical for all users ‘*‘ in all clients ‘*‘.
➙ mostly ok, details should be confirmed
2. Filter: Activate everything for users ‘SAP*‘ in all clients ‘*‘
3. Filter: Activate everything for other support and emergency users, e.g. ‘FF*‘ (FireFighter) in all clients ‘*‘
➙ ok (assuming that you already have agreed on using GRC Super User Management)
4. Filter: Activate all events for the dialog activities ‘logon’ and ‘transaction’ for user ‘DDIC‘ in all clients.
5. Filter: Activate everything for client ‘066‘. This client is not used anymore and can be deleted.
6. Filter: Activate RFC events (AUL, AUK, AU6, AU5) for a short time for selected users to identity RFC connection problems easily
➙ you have to confirm this
7.-10. Filter: free for other project specific purpose
➙ you have to confirm this
Keep in mind that you have to discuss (among others) log creation, consolidation, archiving as well as retention periods and deletion.
Example from a German project (2010/2011) which was cleared through German, Austrian, French & Belgian data controllers:
Logging everything was OK as there is are legitimate reasons for it. The following additional controls were required:
- Access to logs limited to Basis & Security team
- Acceptable use (of logs) policy circulated to everyone with access
- Data had to be summarized before use (e.g. could not be easily attributable to an individual. Obviously difficult to achieve if someone is in a team of 1…)
- Distribution of data outside security team had to be approved by local data controller (local to the people who’s data it was).
- Detailed records existing outside the system had to be deleted after the summation work had been completed
Exceptions to these included:
- legitimate use of data in event of security breach (agreed by local counsel and data controllers)
- use of data with written approval of user (we used this a lot when redesigning access based on patterns of ‘model’ users).
I just found an additional recommendation about the protection of the files in a recent note:
In general, files of the Security Audit Log must not be accessed by other ABAP programs than the Security Audit Log application itself. Protect the files by assigning the appropriate S_DATASET authorizations to your users and by using S_PATH protection as described in note 177702. For this purpose, use an own dedicated folder for Security Audit Log files. Enter this directory into the SPTH table and enable the flags FS_NOWRITE and FS_NOREAD, thus disabling any read or write access from ABAP to this directory. Configure the Security Audit Log (parameter DIR_AUDIT) to use this directory.
GRC Fire Fighter logging
The application GRC Access Control Super User Management (aka FireFighter) consolidates logs from various sources:
- Transaction Log: Captures transaction execution from transaction STAD
- Change Log: Captures change log from change document objects (tables CDPOS and CDHDR)
- System Log: Captures Debug & Replace information from transaction SM21
- Security Audit Log: Captures Security Audit Log from transaction SM20
- OS Command Log: Captures changes to OS commands from transaction SM49
Because of this we recommend to define a filter in the Security Audit Log which records all events for fire fighter users.
Q: Is there a significant performance impact (or any impact at all) if we enable the security audit log with the recommended settings? We’ve had resistance from some clients as they were worried that it will impact on the end user experience / slow down the system.
Unfortunately the FAQ note 539404 does not talk much about performance.
Well, the general rule is simple: There is no performance impact, not in time nor in space, if you log unsuccessful (=critical) events as these events happens rarely.
As soon as you start logging successful events you might look to space – the growing size of the audit files – but still not to time, as the Security Audit Log is optimized for speed.
Ertunga Arsal has written some noteworthy blogs about performance analysis of the Security Audit Log:
- SAP Security Audit Logs: Which event types should I enable? There are 90 of them! And how much disk space do I need?
- SAP Security Audit Logs: Auditor wants me to switch ALL on!!! Here is what I told him
Conclusion: you do not need to care about time, and space is only important if you log specific successful events:
RFC function called (AUK which take >70% of the space), Sucessful RFC logon (AU5 which take >15%), Successful Web Service Call (CUV which take >10% if the system utilises web services extensively), Report started (AUW which take >5%).
How to create customer-specific events
You can “reuse” other codes, i.e. CUY if you ensure that you still will be able to distinguish the messages. Nevertheless, you should interpret it as a (logical) modification of the SAP Standard.
in addition there exist other options to log custom specific events:
– Application Log in ABAP
– CCMS Alerts
– Alerts send to the SAP Solution Manager
How to read the long texts of events
You can view the long text of Security Audit Log event messages using transaction SE92 (or in transaction SE61 if you choose the document class SL (Syslog).
Using note 1970644 you can get report RSAU_INFO_SYAG which shows all events of the Security Audit Log including the current status of activation. The detail view allows you to create an HTML-based event definition print list including the full documentation.
How to log critical debugger events
Using the debugger in general might already be seen as critical but using debug-replace is considered as very critical by all auditors. The corresponding Security Audit Log messages for changing field content and for jumping within the code
- Other Events, Critical, CUL Field content changed: &A
- Other Events, Critical, CU_M Jump to ABAP Debugger: &A
are already covered by the 1st filter “Activate everything which is critical for all users in all clients” as proposed above.
These both messages are extended by another message to add more details describing the event:
- Other Events, Critical, BUZ > in program &A, line &B, event &C
The messages CUK, CUN, CUO, and CUP are related to the debugger as well.
How to track changes on the settings
The effective (dynamic) settings get logged in the Security Audit Log itself.
If you create – as recommended – a filter for “all clients, all users, all audit classes with severity ‘critical'” than you already get the corresponding events of audit class “System”:
|System||Critical||AU||E||Audit Configuration Changed|
|System||Critical||AU||F||Audit: Slot &A: Class &B, Severity &C, User &D, Client &E, &F|
|System||Critical||AU||G||Application Server Started|
|System||Critical||AU||H||Application Server Stopped|
|System||Critical||AU||I||Audit: Slot &A Inactive|
|System||Critical||AU||J||Audit: Active Status Set to &1|
The static settings are stored in table RSAUPROF. The system create table logs for any changes which you can view, i.e using report RSTBHIST.
The name of the active profile which is used while starting an application server is stored in field CURRPROF of the entry with PROFNAME = $CURPROF.
You can transport static profiles using a workbench transport which get transport entries for R3TR TABU RSAUPROF with table key PROFNAME=<profile name> SLOTNO=*. (You can transport the entry for $CURPROF as well, but I recommend to choose the active profile in the target system manually.)
As of SAP_BASIS 7.40 you can use transaction SM19 to add static filter definitions to a transport. See FAQ Note 539404 item .
The filters are stored in the entries having field SLOTNO > 0.
Field STATUS shows if a filter is active.
Field CLASSES shows the active audit classes. This is a bit-field summing up the values for the different audit classes (see include RSAUCONSTANTS):
CONSTANTS: RSAU_CLASS_OTHER(4) TYPE x VALUE 1,
RSAU_CLASS_LOGIN(4) TYPE x VALUE 2,
RSAU_CLASS_TASTART(4) TYPE x VALUE 4,
RSAU_CLASS_REPORT(4) TYPE x VALUE 8,
RSAU_CLASS_RFCLOGIN(4) TYPE x VALUE 16,
RSAU_CLASS_USER(4) TYPE x VALUE 32,
rsau_class_system(4) type x value 64,
RSAU_CLASS_RFCCALL(4) TYPE x VALUE 128.
The audit class “System” is implicitly active and is not added, therefore you get the value CLASSES = 191 = 128 + 32+16+8+4+2+1 if you activate all audit classes.
Field SEVERITY shows the severity (see include RSAUCONSTANTS):
CONSTANTS: RSAU_SEVE_LOW TYPE I VALUE 2,
RSAU_SEVE_MED TYPE I VALUE 5,
RSAU_SEVE_HIGH TYPE I VALUE 9.
If you have selected the detail settings, then field SELVAR contains the constant 01 (and field CLASSES = 0 and SEVERITY = 0). Field MSGVECT defines active events. (In this case you can deactivate “System” events.)
Active events are identified using individual bits at specific positions within field MSGVECT. The position is calculated using the alphanumerical order 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ according to the SUBID of the events. The event area (AU, BU, CU, DU, EU) defines the bit which is added to the value on that position: AU = 80 (hex), BU = 40 (hex), CU = 20 (hex), DU = 10 (hex), EU = 08 (hex).
Only the first 36 positions of field MSGVECT are used. Every position holds two bytes therefore you see two hexadecimal characters per position.
Example showing active system events only (AUE AUF AUG AUH AUI AUJ):
SUBID 0 1 2 3 4 5 6 7 8 9 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Change Reporting in the SAP Solution Manager
In addition to the local table logs of table RSAUPROF you can use the applications Change Reporting and Configuration Validation in the SAP Solution Manager to analyse changed settings. Use the configuration store AUDIT_CONFIGURATION. Be aware that the extractor gets a snapshot of the dynamic settings daily – that means it shows the effective settings according to profile parameters respective the overriding kernel parameters. Changes between two executions of the extractor are not cached. The configuration store does not show the user account who triggered the change. Therefore I recommend to use Change Reporting or Configuration Validation as a trigger for deeper analysis of the local table logs.
see: Configuration Validation Home
➙ Content of CCDB for a Technical System of type ABAP ➙ …
What is the meaning of message BU4?
Question: I our productive environment am getting many times the message BU4 “Dynamic ABAP Coding: Event &A Event Type: &B Checksum: &C” but according to your post (and my old screen capture) the BU4 message should be for “Transport Request &A Contains Security-Critical Source Objects“.
I searched but could not find anything about this issue…what do you recommend beside good luck :-)?
Answer: The definition of the message BU4 in transaction SE92 might be still wrong depending on the release of the system. According to note 539404 recording the events to transport security-relevant objects (BU3, BU4) is not yet implemented.
The Kernel creates message BU4 “Dynamic ABAP Coding: Event &A Event Type: &B Checksum: &C” to flag usage of
- ‘I‘ for INSERT REPORT
- ‘G‘ for GENERATE SUBROUTINE POOL
- ‘D‘ for DELETE REPORT
if setting in SM19 at ‘Other entries’ for ‘Audit of generated dynamic ABAP’ is active.
(In addition entries in the db tables DYNABAPHDR and DYNABAPSRC are written if profile parameter abap/dyn_abap_log is set to the value “on“.)
How can I read events using BAPIs?
The security alerts are also available to external programs using BAPIs (Business Application Programming Interfaces). The report RSAU_READ_AUDITLOG_EXTERNAL is a sample SAP program that you can use as a template for accessing the security alerts using BAPIs.
For the Security Audit Log (SAL) you will work with following result fields:
MSG_LINE_TBL-MSCGLLID(3), ” SAL Message ID
MSG_LINE_TBL-MSCGLLID+4(14), ” Time stamp (yyyymmddhhmmss)
MSG_LINE_TBL-MSCDATE, ” Date
MSG_LINE_TBL-MSCTIME, ” Time
MSG_LINE_TBL-MANDT, ” Client
MSG_LINE_TBL-USERID, ” User
XMI_RAW_TBL-MSGID(3), ” SAL Message ID
XMI_RAW_TBL-MSGARG2, ” SAL Message parameters seperated by ‘&’
XMI_EXT_TBL-MSG. ” SAL Message text with parameters
– It seems that you have to address all application servers individually (however, I’m not sure as I’m not an expert for these BAPIs).
– Following fields seem not to be available: Terminal name, Transaction Code, Program, SAP process, Work Process Number
Documentation about using the BAPIs:
Including External System Management Programs in the CCMS Monitoring Architecture (2002)
How to get a cross-reference about the creation of messages?
If you want to know which program triggers which message you can use the cross-reference feature of the development environment. Well, messages are no repository objects, therefore you cannot use it directly. However, many but not all messages are triggered by specific functions of methods per scenario. You can use the cross-reference for these triggers.
Have a look to method GET_TRIGGER_FOR_MSG of class CL_INFO_SYAG to view the list of triggers which are used to create audit messages. Then go for the cross-reference in transaction SE80 or SE84 for these functions and methods.
How to avoid logging for Auto-ABAP (SAPSYS) processing
If you do not want to log Security Audit Log events for Auto-ABAP processing (aka “SAPSYS processing”) even if you log all events for user pattern SAP* you can assign a different username to this type of processing by setting following profile parameters:
To define the value for these profile parameters you enter the client, a comma and the user.
This user has to exist in the choosen client with sufficient authorizations!
Create this user with user type B=system, no password and a role which contains at least following authorizations (you may start with full authorizations and use transaction STAUTHTRACE for a while to get the list of required authorizations):
Authorization object S_ADMI_FCD
with field S_ADMI_FCD = PADM, ST0R
Authorization object S_BTCH_ADM
with field BTCADMIN = Y
Authorization object S_DATASET
ACTVT = 33
FILENAME = *
PROGRAM = RSCORE00, SSFALRTEXP
Authorization object S_RZL_ADM
with field ACTVT = 01, 03
This tip was developed by a customer based on information within note 2288530. The customer has an even stronger requirement as mentioned above because they want to log everything in all clients for all users with just the exception to omit logging for Auto-ABAP processing. This customer use a special variation of the trick:
Auto-ABAP processing is executed by user SAPSYS______ (12 characters).
No other user name is longer than 11 characters.
The filter im transaction SM19 for the user name is defined as +++++++++++ (11 characters).