Driven by recent discussions, I started to wonder what’s the best configuration for the SAP Security Audit Log or short SAL. Knowing that SAL is a trustworthy security log available for SAP instances it seems to be obvious to me, that one needs or better wants to activate it. Oh, I forget to mention it’s not active by default!

Hi all, My side audit log size parameter is rsau/maxdiskspace/local 1000000 Maximum space for security audit file At sm19, it show max. File size 976 KB How is 1000000 related to 976 KB? If the audit file size reaches 976KB, what will happen? Does the auditing stop? Regards Huay Soon. Rsau/local/file path to audit log file rsau/maxdiskspace/local maximum space to allocate for the audit files rsau/selectionslots 3 rec/client ALL. Note: The rsau/local/file parameter contains the entire path name to the audit logs, as well as the file name. The file name must include + symbols to contain a variable datepart. Do not include a.

Let’s go through the concept of SAL. SAP has implemented the security relevant events deep underneath the surface, within the SAP kernel. The name “Security Audit Log” indicates – a log file is written to the file system.
Do you wonder why SAP has chosen to implement the SAL in the application kernel? Raising the events directly from within the kernel is a lot faster than on the application layer. The kernel is the architectural layer underneath the stack (ABAP, JAVA, …) it has a complete view on security relevant operations like login, remote function calls, HTTP(S) connections, hand-shake, etc.
Events from the SAP Security Audit Log are trustworthy. Why? Because once an ABAP stack has been compromised also the logs created and stored in the database can be manipulated.

You should know that it also has some drawbacks. I already mentioned it, Security Audit Log creates logs on OS level. Those can cause the disk quota to run full. Monitoring the disk space and take appropriate action is not instantly possible and must be planned and executed by each customer.

Back to the initial topic. In SCN you can find multiple discussions on the same topic. I read a lot of them and seem to find a common problem pattern, like I would have expected it. All are motivated by internal and external auditing or the target to gain more security transparency in their SAP Landscape. Very interesting is the fact, that most of them struggling to balance between number of logs, performance impact and consumed disk space without losing the security aspect. I start to wonder whether these points are problems, which may have been solved a while ago. One by one.

Required disk space

In fact, a huge system (>10.000 Users) creates log-files of approx. 2 GB per day. The size depends on type and amount of actions performed by the users. Let’s assume the logs should be retained for 180 days, this requires 500 GB (360 GB + enough buffer) of hard disk space. I doubt this is a real problem for a system of such a size but if it is, the logs can be compressed or even moved to less expensive storage using e.g. a script. Compression for plain-text files is very efficient. Size reduction of more than 90% is realistic. As of release 750 the customer can choose the storage target: DB, File or both. Find more information about the new 750 features in Note 2191612 (login required).

Profile Parameters for the Security Audit Log

Source:
https://help.sap.com/saphelp_nw70ehp2/helpdata/en/c7/69bcb7f36611d3a6510000e835363f/content.htm

Performance impact

Rsau Local File Online

The log event fetching and creation happens in the kernel, it should thus not create any noticeable performance impact on a system. However, a SAP basis expert needs to be consulted, to check the hardware requirement based on the current system load before any system setting (including activation of SAL) may be changed. Depending on your release it’s useful to search for performance related SAP Notes in component BC-SEC-SAL.

Number of logs

Who will ever review the massive number of logs that are created day by day? Good question. If there is no software solution like SecurityBridge to support this process the answer is “nobody can!”.
If you have no tool established, do you still want to keep logging active? The answer is “Yes, certainly”!
Most cyber-attacks affecting SAP happen unnoticed. Not having the security logs means having no chance to recognize an ongoing attack and not being able to investigate, track down and close the vulnerability after the attack.

Relevant for production system, only?

Ahhmmm… NO! Development and test systems are typically the weak links that break the chain. Here you have experienced tech users (let’s name them “Developers”) with rich authorisations and the ability to change the system. One tempts to believe that a SAP system is an island that can’t be reached. SAP systems are highly integrated systems that also require and utilize connections between each other. The SAP Transport Management System (STMS) and Solution Manager being only two speaking examples.

Repetition is the best way to memorize. So, let me repeat: “I strongly advice to activate the SAL on every instance, in each SAP landscape in your company!”.

Rsau/local/file

One question remains: Which are the “best practise” settings for the filters? Since concerns about file size, performance and number of logged messages are irrelevant filtering makes no sense. I guess the possibility to filter is merely a relic from the past: A time where disk space on a server was more expensive than gold.

Best Practises