What is the SAP Security Audit Log?

SAP security audit log is the main location for the traces of events triggered by the system or by applications, which are related to security. It has a table like form. Based on the configuration which event types must be recorded, it saves the data to the disk on the SAP application server instance.

How can I analyze the SAP security audit logs?

You can use SAP’s SM20 transaction to analyze the raw logs. However, this has many limitations. Our solution Enterprise Threat Monitor analyzes SAP security logs of SAP ABAP, Java, and Hana systems using  more than 300 built-in threat detection cases for detecting attacks and suspicious activity as well as compliance violations in real-time.

Enterprise Threat Monitor correlates the SAP security logs in real-time, eliminates noise and false positives using adaptive noise reduction and machine learning and sends alerts or SMS messages if attacks are detected or if something suspicious happens.

Enterprise Threat Monitor has over 300 threat detection signatures built-in for analyzing SAP security audit logs.

It retrieves the security event information from SAP and uses machine learning to eliminate false positives.

ETM automatically compresses and saves the logs outside SAP, saving valuable disk space and preventing attackers delete the logs.

How can I see which event types are activated?

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.

How much performance impact does the SAP Security Audit Log have?

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 vary.

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

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 or a bit longer), and then analyzing the SAP security audit log volume.

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.

Can SAP security logs be compressed?

Yes. it is a manual process which SAP admins must implement on their own. Enterprise Threat Monitor automates and centralizes this process by automatically compressing and archiving SAP security logs achieving over 98% compression. More information can be found at: SAP security log compression

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

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

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 log event type.

The example above is a production ERP 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.

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

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 setting for security.

Which SAP security audit log event type consumes the most disk space?

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

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/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, successful 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 utilizes 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 own 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.

->>> Analysis Update – 40 Billion SAP Security Audit Log Events

The following data is based on the analysis of close to 18 months of security events of over 100 SAP systems (SIDs). The results confirm the above numbers:

RFC function called	70.6%
Successful RFC logon	15.6%
Report started	8.6%
Successful dialog (GUI) logon	2.0%
Transaction started	1.9%
Others	1.3%

 

Disabling the top three event types would result in missing very important events for security. Therefore, not recommended.

SAP Security Audit Log Sizing Requirements for 100+ SAP systems:

– Based on the example above, for a period of 18 months, the data stored by Enterprise Threat Monitor is close to 134 GB in total. This data is compressed. Storing it uncompressed would require 16 TB of disk space.

– The customer stores only 30 days of raw logs on SAP application server instances. This allows them to use SAP’s tools when there is an incident.

– Customer has only 850 GB stored on SAP instances for the mentioned 30 days (avg. 8GB per SID), older logs are deleted after 30 days (all logs are archived by Enterprise Threat Monitor on an separate server in parallel).

We hope this information gives some indicators what to expect when planing switching on SAP security audit log events.