Recommended Settings for the Security Audit Log (SM19 / SM20)

[Frank_Buchholz]

Hi Security-Folks,

I like to discuss with you the recommended settings for the Security Audit Log (SM19 / SM20).

Here's my proposal:

Profile Parameters:

rsau/enable = 1

rsau/selection_slots = 10

rsau/user_selection = 1

Filter settings in SM19:

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

2. Filter: Activate everything for users 'SAP*' in all clients '*'
This includes the built-in user 'SAP*' as well as all users account names starting with 'SAP', e.g. 'SAPSUPPORTx' because of rsau/user_selection = 1

To show log entries in for user 'SAP*' only, filter by 'SAP#*' in SM20 or use report RSAU_SELECT_EVENTS instead.

3. Filter: Activate everything for other support and emergency users, e.g. 'FF*' (FireFighter) in all clients '*'

4. 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).

5. 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-... ).

6. 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-authorizat... ).

7.-10. Filter: free for other project specific purpose

What settings are you using and why?

Kind regards

Frank Buchholz

Active Global Support - Security Services

[Frank_Buchholz]

Here's the complete list of events from tables TSL1D

Audit Class	Event class	AREA	SUBID	Message
Dialog Logon	Critical	AU	2	Logon Failed (Reason = &B, Type = &A)
Dialog Logon	Critical	AU	M	User &B Locked in Client &A After Erroneous Password Checks
Dialog Logon	Critical	AU	N	User &B in Client &A Unlocked After Being Locked Due to Inval.Password Entered
Dialog Logon	Critical	BU	D	WS: Delayed logon failed (type &B, WP &C). Refer to Web service log &A.
Dialog Logon	Important	AU	1	Logon Successful (Type=&A)
Dialog Logon	Important	AU	O	Logon Failed (Reason = &B, Type = &A)
Dialog Logon	Important	CU	A	Rejected Assertion
Dialog Logon	Important	CU	B	&A: &B (SAML 2.0 Logon)
Dialog Logon	Important	CU	C	&A (SAML 2.0 Logon)
Dialog Logon	Important	CU	D	Name ID of a subject
Dialog Logon	Important	CU	E	Attribute
Dialog Logon	Important	CU	F	Authentication Assertion
Dialog Logon	Important	CU	G	Signed LogoutRequest rejected
Dialog Logon	Important	CU	H	Unsigned LogoutRequest rejected
Dialog Logon	Non-Crit.	AU	C	User Logoff
Dialog Logon	Non-Crit.	BU	E	WS: Delayed logon successful (type &B, WP &C). Refer to Web service log &A.
Dialog Logon	Non-Crit.	BU	K	&A Assertion Used
Dialog Logon	Non-Crit.	BU	L	&A: &B (SAML 2.0 Logon)
Dialog Logon	Non-Crit.	BU	M	Name ID of a subject
Dialog Logon	Non-Crit.	BU	N	Attribute
Dialog Logon	Non-Crit.	BU	O	Authentication Assertion
Dialog Logon	Non-Crit.	BU	P	&A (SAML 2.0 Logon)
Dialog Logon	Non-Crit.	BU	Q	Signed LogoutRequest accepted
Dialog Logon	Non-Crit.	BU	R	Unsigned LogoutRequest accepted
RFC/CPIC Logon	Critical	AU	6	RFC/CPIC Logon Failed, Reason = &B, Type = &A
RFC/CPIC Logon	Non-Crit.	AU	5	RFC/CPIC Logon Successful (Type = &A)
RFC Function Call	Critical	AU	L	Failed RFC Call &C (Function Group = &A)
RFC Function Call	Critical	CU	W	Failed Web service call (service = &A, operation = &B, reason = &C)
RFC Function Call	Critical	CU	Z	Generic table access by RFC to &A with activity &B
RFC Function Call	Non-Crit.	AU	K	Successful RFC Call &C (Function Group = &A)
RFC Function Call	Non-Crit.	CU	V	Successful WS Call (Service = &A, operation = &B)
Transaction Start	Critical	AU	4	Start of transaction &A failed (Reason=&B)
Transaction Start	Important	AU	P	Transaction &A Locked
Transaction Start	Important	AU	Q	Transaction &A Unlocked
Transaction Start	Non-Crit.	AU	3	Transaction &A Started
Report Start	Important	AU	X	Start Report &A Failed (Reason = &B)
Report Start	Non-Crit.	AU	W	Report &A Started
User Master Change	Critical	AU	7	User &A Created
User Master Change	Critical	AU	U	&A &B Activated
User Master Change	Important	AU	8	User &A Deleted
User Master Change	Important	AU	9	User &A Locked
User Master Change	Important	AU	A	User &A Unlocked
User Master Change	Important	AU	B	Authorizations for User &A Changed
User Master Change	Important	AU	D	User Master Record &A Changed
User Master Change	Important	AU	R	&A &B Created
User Master Change	Important	AU	S	&A &B Deleted
User Master Change	Important	AU	T	&A &B Changed
User Master Change	Non-Crit.	BU	2	Password changed for user &B in client &A
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
Other Events	Critical	AU	V	Digital Signature Error (Reason = &A, ID = &B)
Other Events	Critical	BU	0	BU0 to BUZ reserved for Security Audit Log
Other Events	Critical	BU	1	Password check failed for user &B in client &A
Other Events	Critical	BU	3	Change Security Check During Export: Old Value &A, New Value &B
Other Events	Critical	BU	4	Transport Request &A Contains Security-Critical Source Objects
Other Events	Critical	BU	8	Virus Scan Interface: Virus "&C" found by profile &A (step &B)
Other Events	Critical	BU	G	HTTP Security Session Management was deactivated for client &A.
Other Events	Critical	BU	Y	Field contents changed: &5&9&9&9&9&9
Other Events	Critical	BU	Z	> in program &A, line &B, event &C
Other Events	Critical	CU	0	CU0 to CUZ reserved for Security Audit Log
Other Events	Critical	CU	K	C debugging activated
Other Events	Critical	CU	L	Field content changed: &A
Other Events	Critical	CU	M	Jump to ABAP Debugger: &A
Other Events	Critical	CU	N	A manually caught process was stopped from within the Debugger (&A)
Other Events	Critical	CU	O	Explicit database commit or rollback from debugger &A
Other Events	Critical	CU	P	Non-exclusive debugging session started
Other Events	Critical	CU	Y	> &A
Other Events	Important	AU	Y	Download &A Bytes to File &C
Other Events	Important	AU	Z	Digital Signature (Reason = &A, ID = &B)
Other Events	Important	BU	5	ICF recorder entry executed for user &A (Activity: &B)
Other Events	Important	BU	6	ICF Recorder entry executed by user &A (&B,&C) (activity: &D).
Other Events	Important	BU	7	Administration setting was changed for ICF Recorder (Activity: &A)
Other Events	Important	BU	9	Virus Scan Interface: Error "&C" occurred in profile &A (step &B)
Other Events	Important	BU	A	WS: Signature check error (reason &B, WP &C). Refer to Web service log &A.
Other Events	Important	BU	B	WS: Signature insufficient (WP &C). Refer to Web service log &A.
Other Events	Important	BU	C	WS: Time stamp is invalid. Refer to Web service log &A.
Other Events	Important	BU	H	HTTP Security Session of user &A (client &B) was hard exited
Other Events	Important	CU	Q	Logical file name &A not configured. Physical file name &B not checked.
Other Events	Important	CU	R	Physical file name &B does not meet requirements set by logical file name &A
Other Events	Important	CU	S	Logical file name &B is not a valid alias for logical file name &A
Other Events	Important	CU	T	No validation is active for logical file name &A
Other Events	Non-Crit.	AU	0	Audit - Test. Text: &A
Other Events	Non-Crit.	BU	F	HTTP Security Session Management was activated for client &A.

[Former Member]

Hi Frank,

Thanks for the list. Will double-check against mine.

I use the following to filter reading the log(s) for alerts:

A14A19A18ICJICKA23A26AD4AV3E0BE0CBYXEBSEHIGEWLC1US2US5XI6

It is a string because I also evaluate the SM21 log as well which uses a string which SM21 programs can split into area and ID automatically, as some messages are only there or at least used to only be there.

The user = * in client = * is also IMO a bit "top-heavy" for most use-cases. Will make lots of noise.. 🙂 That should only be done if the space for saving them is OK and there is a means to alert on the "needles in the haystack" because no mortal will read those logs every day in large systems...

But via RZ20 one can use selection methods (see my sting above) and reaction methods to them. I also find acceptance from basis for this because they know the CCMS and done want to read the logs and without acceptance from basis you generally don't get very far, even with good ideas and sometimes even legal requirements...  🙂

Cheers,

Julius

[dionisio_bustillogalvez]

Hi Frank,

I our productive enviroment I am getting many times the message BU 4 "Dynamic ABAP Coding: Event &A Event Type: &B Checksum: &C" but according to your post (and my old screen capture) the BU 4 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 :-)?

Thanks,

dionisio

[Former Member]

Hi Dionisio

That might be just when users put some value (query) on the pop up window (table or program), the SAP system tries to verify no code injections or odd values may have changed the protected program codes--checksum control--I also am trying to get the correct answer, above's my guess only.

Please let me know if you have the answer if you like, or any other can confirm or correct me.

Cheers,

Leon

[Frank_Buchholz]

By the way: 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').

[Yaso]

Hi Frank,

I want to define the SM19 configuration for monitoring SM20 logs. Are the configuration steps you have provided up-to-date for S4 HANA systems? Does the configuration vary depending on the version? Where can I access the most current configuration details?

Additionally, my goal is to ensure that the activities of users in the system are fully and accurately logged.

Thank you for your help !

[Former Member]

Hi Frank,

this is kinda off topic, I'm sorry for intruding. But I'm new to the SAP world and it isn't a straight forward world to get into (not for me at least).

I am supposed to import the data that is displayed by SM20 into another tool (Splunk) without accessing SAP directly but by reading the .AUD files that are generated. This might not be the easiest/best way to get the data but that's what I have to live with (at least for now).

So I'm stuck with these 200 character log entries, but I can't really find any documentation what the characters mean (some can be guessed others are black boxes):

2AU520130409010803000505200009D9a234ba.pDOKUSTAR                        SAPMSSY1                               0201R&0                                                             h020co.pt.com      

The table you list in TSL1D explains the AU5 (and is brilliant starting point) and I can enrich the log entries with what you have posted but that does not explain the entire 200 characters.

Is there any documentation of the .AUD files. I found out that the source of RSAU_SELECT_EVENTS could give me hints but since I do not have access to an SAP system I ended up here http://www.se80.co.uk/sapreports/r/rsau/rsau_select_events.htm  there is a reference to TSL1D there but I'm not able to decipher the .AUD entries based on that information.

Any help/pointers would be great!

Thanks

Chris

Alternating colors added to example by Frank Buchholz

[Frank_Buchholz]

You already found the correct 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

This leads to the following file format:

Field	Sub-field	Length	Description
SLGTYPE			SysLog: LIKE structure RSLGETYP
	SLGFTYP	1	Entry type
	AREA	2	Message area
	SUBID	1	Message name
SLGDATTIM			Time stamp (CHAR 16)
	DATE	8	Date in format YYYYMMDD
	TIME	6	Time in format hhmmss
	DUMMY	2	not used
SLGPROC			SysLog: LIKE RSLGPID structure
	UNIXPID	5	Process ID
	TASKTNO	5	Task
	SLGTTYP	2	Process type (short form)
SLGLTRM		8	Terminal name (truncated)
SLGUSER		12	User name
SLGTC		20	Transaction
SLGREPNA		40	Program
SLGMAND		3	Client
SLGMODE		1	External mode of an SAP dialog
SLGDATA		64	Variable message data
SLGLTRM2		20	Terminal name (continued)

You see, 

• 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 (the key fields are AREA and SUBID).

Kind regards

Frank

[mvoros]

Hi Chris,

check project sapninja for some inspiration if not direct use.

Cheers

[former_member157391]

this is something I want to know for a long time.

thank you.

[Former Member]

Is there a way to log the IP source address (NOT hostname) from a user connects to SAP in audit log ? ( i.e. in SM04 and correct layout, I can see this, but it is "online", current connected users )

Regards

Leandro

[Frank_Buchholz]

Unfortunately there doesn't exist a switch for the Security Audit Log to log the terminal id or the IP address (or even both): If a terminal id is available then it is used, if not the IP address is used.

I agree that it does not make sense to get the IP address later on, e.g. via PING <terminal>, therefore it's necessary to get the data while logging on.

Here are some ideas to develop workarounds:

• 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.)

Kind regards

Frank

[mvoros]

Hi,

I just want to mention some shortcoming of logging hostname and IP address in ABAP AS. if I am not mistaken host name of client is sent during initializing connection in SAP DIAG protocol. Hence a malicious user could spoof it and change it to something else. Also IP address can be problematic. For example if you use reverse proxy (e.g. web dispatcher) for HTTP access then all users will have same IP address.

Cheers

[Former Member]

Dear Frank,

thanks for your post. Always interesting stuff to read ...

Your comment about additional security audit log entries caught my attention. We do have additional logging requirements and because of our infrastructure it would make perfect sense to use Security Audit Log.

But I am afraid that using code based on RSAU_WRITE_TRAC_AUDIT_LOG (i.e. calling the kernel call   AUDIT_WRITE_ENTRY) may be not be "appreciated" by SAP.

Do you have any further comments on that? To what degree is "creating own Security Audit Log entries" supported by SAP? It is not a bad idea at all, so ...

Best regards,

Ralf

[Frank_Buchholz]

> To what degree is "creating own Security Audit Log entries" supported by SAP?

Unfortunately, there is no way to add own events to the Security Audit Log.

However, there exist other options to log custom specific events:

- Application Log in ABAP

- CCMS Alerts

- Alerts send to the SAP Solution Manager

Kind regards

Frank

[Former Member]

Dear Frank,

indeed it would be nice to be able to define own (customer-specific) event codes. But we would be able to stick to the existing (and "old") codes. We just need to create entries and I was just wondering whether that is OK ...

I prefer Security Audit Log over other mechanisms because of its distributed setup (7 application server envolved!) and because it is NOT a database mechanism, so does not require a COMMIT and does not interfere with the existing LOW logic ... .

Best regards,

Ralf

[Frank_Buchholz]

> But we would be able to stick to the existing (and "old") codes. We just need to create entries and I was just wondering whether that is OK ...

I don't see any issue in this case assuming that you still will be able to distinguish the messages. Nethertheless, you should interpret it as a (logical) modification of the SAP Standard.

Kind regards

Frank

[Former Member]

Thanks!

Kind regards,

Ralf

[Former Member]

Hi Frank,

This might be veering a little off topic, but since the discussion is about SAP Audit reports and traces, I thought I could post my query here..

We have had a few incidents of people deleting Layouts via t-code COOIS and COHV. We found out that many users get the authorization through S_ALV_LAYO, and have already started changing roles replacing it with F_IT_ALV, only the Support teams would get the access to S_ALV_LAYO and not the business users.

My query is, is there a report that I can use, to find out who deleted the earlier layouts, so if there is a training issue, we can take care of it..

Regards,

Prakash Sharan

[Former Member]

Question: would the German Data protection authorities have an issue with activating this level of logging?

[Frank_Buchholz]

Denis Ontiveros wrote:

Question: would the German Data protection authorities have an issue with activating this level of logging?

Good point!

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 '*'

-> ok

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.

-> ok

5. Filter: Activate everything for client '066'. This client is not used anymore and can be deleted.

-> ok

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.

[Former Member]

Hi Denis/Frank

The last time I did this with a German project (2010/2011) we settled on the following (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 summarised 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 summarisation 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). 

[Frank_Buchholz]

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.

[Colleen]

Hi Frank

This discussion is great but anyway it can be converted to a wiki or a document as recommendations for the security audit log?

Regards

Colleen

[Former Member]

Hi Frank,

Do you know if the audit file settings will affect GRC Fire Fighter logging?

Thanks.

John.

[Former Member]

Hi

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.

Regards

Yogesh

[dionisio_bustillogalvez]

Hi Yogesh,

There is a note  for that specific question, and also this FAQ note 539404 will help you.

As for our experience, I would point two aspects:

- Performance: If you enable the Audit Log the system will execute some more code.

- Memory and write processing: Depending of how much events you are logging it will consume more o less time and space.

If your system is running ok, activating the audit log for test purposes should not be any risk (logging nothing first). If everything goes fine you can start logging more events and see if it fits your limits.

We have a big and quite slow system and implementing RSAU wasn't a significant issue.

Hope this help

Dionisio

[Frank_Buchholz]

Unfortunately the FAQ note 539404 does not talk much about performance.

Well, the general rule is simple: There is no performance impact, nice 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.

Kind regards

Frank

[Frank_Buchholz]

Support for customer-specific events

Using Notes 1941526 and 1941568 you can utilize the custom messages DUX, DUY and DUZ in SAP_BASIS release as of 7.30. Call function RSAU_WRITE_CUSTOMER_EVTS to create these messages.

[Former Member]

Dear Frank,

thanks for this update! Great to hear that this FM for customer events exists.

Best regards,

Ralf

[Frank_Buchholz]

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, CU L 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, BU Z > in program &A, line &B, event &C

The messages CU K, CU N, CU O, and CU P are related to the debugger as well.

[Frank_Buchholz]

I got a question about "How to track changes on the settings of the Security Audit Log" and as the answer grew and grew during analysis I decided to move away from this "discussion thread" to a "document" to become able to update parts of the text later.

Therefore let's move to this document: Analysis and Recommended Settings of the Security Audit Log (SM19 / SM20)

Kind regards

Frank