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

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