SAP© Security Audit Log, you want it, you need it!

Espresso Tutorials

Fabian Bentz

Christoph NagyWe are pleased to share a guest blog post by Christoph Nagy, Managing Director of ABAP-Experts.

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!

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

Profile Parameter Definition Standard or Default Value
rsau/enable Activates the audit log on an application server. 0 (audit log is not activated)
rsau/local/file Specifies the location of the audit log on the application server. /usr/sap/>SID</>instnoaudit_SAP_InstanceNo<
rsau/max_diskspace_local Specifies the maximum length of the audit log. 1,000,000 bytes
rsau/selection_slots Specifies the number of selection slots for the audit. 2


Performance impact

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!”.

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.

Filters in SAP transaction SM19Transaction SM19, Filter Settings.

Best Practises

Christoph NagyChristoph Nagy

Christoph Nagy is the Managing Director of ABAP-Experts and has a decade of experience working in the SAP area as an in-house- and external consultant. Email

About ABAP-Experts

In October 2011, our founders, Ivan Mans and Christoph Nagy, turned conventional wisdom on its ear by successfully launching a company targeting an SAP© market with literally no sales force. Our product, Transport Center (formerly called ZTRA), has proven that when you build a great piece of software, price it right and make it available to organizations of all size via SAAS, clients will come. And those clients do praise our software which is how word of mouth turned out to be our most valuable marketing tool.

Today, only few years later a lot has changed. Software deployment for SAP© Enterprise customers has never been easier before. Devteams again focus on writing awesome code, not struggling with avoiding pitfalls or resolving picularities of SAP© software deployment.

Shortening the leadtime between requirements gathering and production deployment, across the entire development lifecycle, over and over again. We offer our clients a one-stop SAP-shop. On our journey towards a successful project delivery we deploy a series of tools and proven methodologies streamlining agile development, automated and developer facilitated testing and quality assurance. Next to expertise our toolset is key. To finally reach our real goal – continuous delivery using ABAP™. Learn more about ABAP-Experts.

Learn more about SecurityBridge in this video and find out how to reduce 50% of critical attack vectors for SAP in just 1 day.