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?
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:
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.
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:
Done! Now the most important conditions have been met.
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.
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:
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.
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.
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.
