The easy way to spot anomalies in SAP
We’re often asked how we can reliably detect suspicious actions from within the huge mass of SAP systems and user activity. In this article, we’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
- SAP ERP
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 all accept that monitoring SAP has become unavoidable and essential.
The main conditions for SAP Threat Detection
So we agree that implementing SAP Threat Detection should be a priority for your organization. Convincing the budget holders of this however will need some explaining of what we’ve been discussing here, plus some hard numbers – which we can provide you with our free interactive business calculator.
What happens next is the same no matter which company you work for:
- Realize that all staging systems in the SAP landscape need to be monitored.
- Get an overview of the level of activation of the necessary SAP logs.
- 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. We recommend at least 18 months, albeit in compressed form.
- 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 we’ve ensured that the essential data foundation is in place we 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, in order 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 solution like SecurityBridge Threat Detection for SAP, 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? Probably should mention here that naming conventions or a comparison with a central directory are helpful tools to answer this question. Because of this, SecurityBridge offers an integration e.g. Active Directory. 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 answer 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.
Answering this question undoubtedly presents SAP customers with a greater challenge. Therefore, SecurityBridge Threat Detection has integrated 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.
There are many more questions and criteria that can be used to reliably qualify anomalies or cyber-attacks. We’ll be happy to explain these to you, so please contact us.
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, we recommend one more important thing. When deciding to implement SAP Threat Detection, be sure to engage your CISO or Head of Information Security to create the important collaboration needed between the security and SAP teams.
Posted by
Looking into securing your SAP landscape? This white-paper tells you the “Top Mistakes to Avoid in SAP Security“. Download it now.
