Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 
Hi all,

SAP Enterprise Threat Detection was released 5 years ago. After more than 3 years presales experience and 200 customer presentations I want to share some other information with you.

SAP Enterprise Threat Detection (ETD) and Security Information and Event Management (SIEM). What is the difference and how can they work together?

I will try to give an answer….


A lot of companies have already a running SIEM product or are just in the evaluation to select one.

7 years ago, SAP IT (running our own SAP systems) was looking for a solution to discover suspicious activities on SAP application level based on SAP logfile information. The result of this examination was to develop a product in this area, because the existing products did not have the functions SAP IT needed on an SAP application layer. Why?

The general approach of SAP ETD is different. SAP ETD is collecting data from an SAP application level based on information the different SAP applications write in several SAP logfiles. Below a graphic showing the different logfiles SAP ETD is supporting automatically (HANA, ABAP, and Java).

Actions in SAP applications can be monitored in SAP logfiles. Events like debugging, a call of a critical transaction, change of authorizations, download data to a file from a transaction are not possible to see on an infrastructure level. Meta information like the position of an employee is not available on an infrastructure level in addition.

Result: SIEM products and SAP ETD are both monitoring logfile information, but the focus is very different. Classical SIEM products focus on the infrastructure level and usually can only partly monitor the SAP application level, or even not at all monitor the SAP world.

So, the most important question we need to answer:

Do you want to use the monitoring tools separately or link the application and infrastructure level together? To answer this question, you have the following options:

1) Using ETD like an alarm signal with a focused scenario

Running SAP ETD in such an environment, an integration of SAP ETD alerts in a leading SIEM product is not necessary. In such an environment an SAP administrator can maintain ETD and can assure a data breach is detected. The focus is to protect the most important data stored in SAP applications only.

This kind of monitoring of suspicious activities should be the basic protection of each customer, who has important data stored in SAP systems.

2) Monitor IT landscape only on an infrastructure and network level.  

This should only be done if your company does not have important data in SAP applications. In such a case you do not need to monitor activities in SAP.
Please keep in mind that in more than 95 % of attacks on data stored in SAP applications, the attack comes from internal sources. These attacks are often directly executed on an application level and cannot be detected if you focus on IT landscape only.

3) Direct integration of SAP logfile information in a leading SIEM product without SAP ETD.

Some SIEM tools can technically integrate SAP logfiles like the SAP Security Audit Log or other SAP logfiles. Does this help?

Let’s have a look on the features of SAP ETD, other SIEM systems don’t provide:

a) SAP constantly update security patterns based on information we get from customers, partners and security agencies.

This help our customers to get constantly the newest protections directly from SAP. If possible, we even give you patterns for the newest SAP vulnerabilities directly when the vulnerability is announced. This is a way to protect your landscape in case a downtime of the productive systems is not possible. It is a kind of virtual patching.

b) Usually a hacker tries to cover the tracks. He deletes the entries in the different logfiles to make sure he will not be detected. SAP ETD does have a unique technology to duplicate logfile information in real time. Meaning SAP ETD logs and saves the activities from the attacker based on logfile information, even the attacker deletes this information in the original data. In the same process the data is pseudonymized to guarantee the requirements of the German working council.

c) In the current version of SAP ETD 2.0 the first Cloud (Multi Tenant Edition (STE)) is already supported. SAP ETD has an integration of SAP Cloud Platform (SCP). Meaning: Attacks on SCP will be monitored in SAP ETD.


As you can see the advantages of SAP ETD are tremendous. These features provide a unique value to protect your SAP landscape.

Be aware SAP logfiles like the Business Transaction log can easily produce more than 1 Terabyte data every day. That may have an influence on the performance and license needs of your SIEM product.

Result: That’s why a direct integration of SAP Logfiles in a SIEM tool might not be the right choice.

4) Integration of SAP ETD in a leading SIEM product

This is the approach a lot of customers are using to combine the best of two worlds. SAP ETD for SAP applications and a SIEM tool for the infrastructure and network level. This approach is used mostly by bigger and medium size companies who already have a SIEM product in mind.

In such an environment we have two different approaches to integrate in a leading SIEM product. You can use a standard API using JSON or integrate via LEEF Format.

We work together with several SIEM vendors (IBM QRadar, HP ArcSight, …) to guarantee a smooth integration. Examples for the integration are available on SAP Security community like:

IBM QRadar:

HP ArcSight:

Other SIEM tools can be integrated using the same technologies.

In such environments the alerts created by SAP ETD are published in a leading SIEM system. The first level support of the Security Operation Center (SOC) will be in charge to take care about the main parts of the ETD alerts. Second level support mostly located in the SAP administration team will be contacted only in case first level support cannot solve the problem. In such an environment it is very important to define the SLA’s in advance.

Summary: As you can see, there are several options to use monitoring tools. Based on the experience of my last 2 years I recommend option 1 and 4.

Option 1 is most interesting for companies, who want to protect the most important data stored in SAP applications and do not want to invest a lot of time in a Security Operations Center (SOC). This option is the basic option which should be used by all customers who have very important data in SAP systems.

Option 4 is the solution for companies, who want to integrate SAP security in an existing SOC. This is a very comprehensive solution for customers, who already have an existing SIEM system in place.

In addition, companies should think about who will be in charge to run an SAP ETD application. It is not necessary to run it all inhouse. Several providers offer managed services for SAP ETD which can reduce the effort inhouse near to zero. Details about this approach can be found via the following link:

I hope this blog helps you to find the correct monitoring tool for you.


Best regards,