top of page

How To Easily Spot Anomalies In SAP

This guest post was contributed by Christoph Nagy, CEO, SecurityBridge

Christoph Nagy, SecurityBridge

I am often asked how to reliably detect suspicious actions from within the huge mass of SAP systems and user activity. In this article, I’ll tell you what’s needed to accurately detect anomalies in SAP’s log stack and put them into context to find cyber-attacks as they are launched Firstly, what’s needed and what requirements must be met to achieve efficient and reliable threat detection for SAP?

Starting Point

Let’s assume you are new to this and want to introduce monitoring of mission-critical applications to your company. To start with you might ask which data is processed in the individual applications, and, above all, which applications are in use at all. You should be able to answer the two questions without much effort. Now you can find the following applications, for example:

  • Salesforce CRM

  • Workday


As you look at the nature of the data being processed by each of the applications, you find that in SAP ERP, both the customer master and the vendor master exist, as well as many trade secrets, such as product pricing. In Salesforce CRM, on the other hand, which is a closed cloud solution, only the service module is used to answer inquiries from customers. Not to be ignored is Workday. Let’s assume Workday is used in your organization to organize human resources management, but when you take a closer look, you realize that the payment processing of salaries is also handled in SAP applications.

How’s this important? Well, it shows that you need to know your environment and you also need to understand/learn which data is worth protecting, and especially know where that data is located. I think we can all accept that monitoring SAP has become unavoidable and essential.

The main conditions for SAP threat detection

However, if you agree that implementing SAP threat detection should be a priority for your organization, convincing the budget holders of this will require some explaining of what I’ve been discussing here, plus some hard numbers.

What happens next is the same no matter which company you work for:

  1. Realize that all staging systems in the SAP landscape need to be monitored.

  2. Get an overview of the level of activation of the necessary SAP logs.

  3. Activate the most important SAP logs, here are a few examples: SAP Security Audit Log, SAP Statistical Records (STAD), table changes, etc. Take this opportunity to make sure that you have enough disk space to keep the logs for a sufficient duration. I recommend at least 18 months, albeit in compressed form.

  4. Consider the reorganization of logs at the end of their lifetime.

Done! Now the most important conditions have been met.

Start surveillance of the SAP application stack

Now that you’ve ensured that the essential data foundation is in place you can begin to actively monitor user and system activity. The goal of this phase should not yet be to directly detect attacks. Try to familiarize yourself with the logs first. Open the SAP transaction SM21 to check the messages of the security audit log. You’ll notice that some messages are marked as critical, but they’re not necessarily critical for you. These false positives should be ignored since you can’t eliminate individual messages at this point. You’ll also find that messages need some explanation. For this, SAP usually asks for a long text and you can get this using F1 help.

In addition to the SAP Security Audit Log, look at the other SAP logs. Additionally, you can focus your search on the change documents of the user master to learn which changes are made and which group of people usually make them. After a while, possibly with a little MS Excel work, you should gain an impression of the daily SAP logs without any additional solutions. By the time you get to this point, you’ve probably found quite a few logs that are the result of overlooked housekeeping tasks. A common example is to use the DDIC user for job scheduling. Great opportunity to document these issues to address them later!

Of course, the logs must be checked regularly, and you must now continuously try to filter out the anomalies from the mass of entries in a timely manner.

How to find SAP anomalies?

Up to this point, the process is relatively straightforward. Now, to efficiently analyze the many logs, especially because they are recorded on each SAP system and sometimes different clients, it’s recommended to look at a log management solution. Of course, this is also recommended because an attacker could manipulate the logs of an SAP system and you can’t be sure whether you can still trust the contents. Therefore, it is recommended to transfer the logs to a “neutral” location in a timely manner.

For anomaly detection, you should pay attention to the following things. If you use a SAP threat detection solution, you’ll receive this information with every event.

The following criteria don’t mean much in isolation, but if several criteria apply, the probability that you have detected an anomaly or even an attack, increases. If you find a security-relevant activity, try to answer the following questions:

  • Did the account trigger the action logon from a new terminal? I should mention here that naming conventions or a comparison with a central directory are helpful tools to respond to this question. If you find that the security-related activity was performed from a previously unknown terminal, you should continue your investigation.

  • Was the action performed during or outside the regular login times of the particular user in focus? To reply to this question, you should know the login behavior of the person and try to find out in which time zone they typically work. If you find that the user in question has made themselves known outside the normal login times, you have an indicator.

  • Does the detected action fall within the user’s regular scope of activity? Particularly noticeable, of course, are the actions that take place outside of the regular workspace of the person performing them. For example, the person typically acts within the finance area but has now triggered an import of an external SAP transport. This scenario would fall into this section. Another example would be a change to the user master by a person who has never made such changes before. On closer inspection, you might find the recent assignment of privileges to enable the operation.

Responding to this question undoubtedly presents SAP customers with a greater challenge. Therefore some industry solutions have a function to identify business areas. This allows you to easily determine whether the action falls under the responsibility of the executing account.

  • Has the account been investigated and already performed other security-related actions? Be sure to check whether any other security-related action, even those of lower severity, has been recorded for the account in question or the terminal in use. Often an attack can only be derived from a chain of actions. To make matters worse, this can also happen over a longer period, since professional attackers plan their actions and prepare them well in advance.

What to do now?

If you are planning to put SAP’s critical enterprise applications on a regular monitoring schedule for threat detection, you will need to go through at least the steps mentioned in the article. At the outset, you should probably think about which people should be entrusted with this responsibility.

Monitoring, in particular, is an area that can be easily onboarded as a managed service to ease the burden on employees. Professional and specialized service providers can easily answer the questions described in this article and will continue to help you cover new detection scenarios.

Finally, I recommend one more important thing. When deciding to implement SAP threat detection solutions, be sure to engage your CISO or Head of Information Security to create the important collaboration needed between the security and SAP teams.

About the Author Christoph Nagy has 20 years of working experience within the SAP industry. He has utilized this knowledge as a founding member and CEO at SecurityBridge–a global SAP security provider, serving many of the world's leading brands and now operating in the U.S. Through his efforts, the SecurityBridge Platform for SAP has become renowned as a strategic security solution for automated analysis of SAP security settings, and detection of cyber-attacks in real-time. Prior to SecurityBridge, Nagy applied his skills as a SAP technology consultant at Adidas and Audi. ###


bottom of page