Skip to Content
Author's profile photo Ertunga Arsal

SAP Security Audit Logs: Which event types should I enable? There are 90 of them! And how much disk space do I need?

When activating SAP security logs, the audit event types which must be activated are a topic of much discussion. Often the security/audit teams want to have all event types enabled and BASIS teams are reluctant because of disk space or performance concerns.

This article aims to help you answer the questions “Which SAP security event types should I activate first?” and “How much disk space is required?” using on real data.

In the security audit log configuration transaction (SM19), the system allows you to choose which types of events to log. The “detailed display” section shows the different types available to your system.

Since security audit logs are stored on the file system and not the database, they don’t have a performance impact. The main consideration of the operations teams is the storage requirements. Based on the activated event types (audit classes), data volume may change.

Enterprise Threat Monitor - SAP Security Audit Log Configuration .png

Which event types consume the most disk space? What are the sizing requirements for SAP security logs?

The answer to this question depends on your environment. The easiest way to find out is by activating all event types for a brief amount of time, e.g. one hour (preferably a day), and then analyzing the logs.

For the analysis you can write a small ABAP code which retrieves the logs from all application server instances and then does a group-by and a count on the event-type field. You might need to transport it though.

An easier alternative is using a tool. Enterprise Threat Monitor has a log volume analyzer which can be used for this purpose. It is a Windows application which uses standard SAP RFCs for reading and analyzing the security audit logs remotely.

Analyzing the results: Two real-life productive SAP systems:

When you enter the connection information of your system and run the tool, you’ll get results similar to the following:

Enterprise Threat Monitor - SAP Log Volume Analysis.png

What does this tell us?

In the Log Volume Analysis Results section, you can see the total number of logs for the selected period and monthly estimated log sizes for storing logs, compressed and uncompressed, for each security event type.

The example above is a production ERP system with ~10.000 SAP users. The system has all security audit event types active for all clients and users. In the above case, storing logs for that month is expected to take around 20 gigabytes of disk space uncompressed and around 200MB compressed during this time of the year. 

The following is taken from another SAP system, the production BW which have the same settings applied:

Enterprise Threat Monitor - SAP Log Volume Analysis - BW System.png

On this system monthly estimate is around 14GB uncompressed, 111MB compressed.

If you already have enough disk space for handling this kind of data volume, you should simply activate all of the event types right away. That’s the simplest and best result for security.

For my comments on activating all event types for all clients and users please see the article: SAP Security Audit Logs: Auditor wants me to switch ALL on!!! Here is what I told him

Which event type consumes the most disk space?

There are around 87 event types which you can activate in the advanced view of SM19 (latest systems may have slightly more). The occurrence of each event type in the audit logs is different. Since we are interested in the big fish, we focus on the ones which generate the most events. The following shows the event distribution of the top 3 items:

Enterprise Threat Monitor - Log Distribution.png

For the two production SAP systems in our example, the data shows that 3 event types (successful RFC calls, successful RFC logons and successful start of reports) consume the biggest portion – 97% – of the disk space whereas all other ones in total consume only around 3%. So, all failed and successful logs of the remaining 84 event types (out of 87) only results in 800MB per month for two large PROD systems (uncompressed) or 10MB per month compressed.

This brings us to a very simple conclusion: It is not worth the political fight for discussing the 3% area. On these systems, you should simply activate all log types other than successful RFC calls, RFC logons and report starts as the first step!

When you run the analysis on your system, the results can be slightly different. E.g. if you run a system which utilises web services extensively then you may see that the Successful Web Service Call (CUV) event type generates over 10% of the overall logs. As always, the best assurance is running the analysis on your environment and building your strategy based on your information.

The activation of security logs does not require a restart of the application server, it can be done instantly. This will also make your auditors and security teams pleased without you having to worry about the disk space! I’m sure they come up with a lot of requests from you regarding various security topics. At least now you have one item you can easily tell them “We cover 96% based on recent changes in production” which may help you leveraging your stance in other security topics.

Tell us: How is the log distribution on your systems? Which type of events do you see the most? Simply write your system type (ERP, CRM, etc.), number of users, and the results in the comments (or send me a so others also benefit from your experience.

In my following article, I’ll discuss the next steps, the event types above, and practical attacks which may be missed if these event types are not recorded.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Bernhard Hochreiter
      Bernhard Hochreiter provides usefull information reg. this topic.

      Author's profile photo Former Member
      Former Member

      nice screenshots of ETD.  I always wished SAP would add a Data Collector for SAL into SolMan Technical Monitoring.