SIEM, from log evaluation to SAP attack detection
Chapters
Share Article
To detect attacks on SAP, you need to evaluate the security logs in SAP. While many organizations have spent the past few years protecting the perimeter, business-critical systems are now becoming the priority of security operations. In this article, we will look at what an SAP SIEM might look like and what data and processes are necessary to enable desired conclusions.
What does SIEM stand for?
Many of our readers are already familiar with this term. SIEM is an abbreviation and stands for Security Information Event Management. The best-known vendor solutions are Splunk, IBM QRadar, and MS Sentinel, but there are many other providers. SIEMs read (security) logs from various sources and use an intelligent aggregation of the data to derive conclusions about suspicious activities or malicious user behavior.
What data from SAP Applications needs to be collected?
Before deep diving into the process flow, we must look at which SAP logs have to be read out. SAP produces many protocols and logs that are necessary to create transparency in the business process.
This is not easy, especially since most SIEM adapters for SAP take an all-or-nothing approach for onboarding new log sources. For example, if we took the SAP system log, all entries must be transferred, although only 5% would be necessary for SAP Security Monitoring.
A selective transfer of the entries necessary for the correlation would also have a positive side effect on the licensing costs for the SIEM product used, given that these usually are paid according to “log volume per day”. Back to the question – which SAP logs are security-relevant? These are only the most relevant logs:
- SAP Security Audit Log
- SAP System log
- SAP HANA audit log
- SAP Gateway log
- SAP Java audit log
- SAP Profile parameter
For further conclusions in the Threat Monitoring for SAP process, you must transfer the user master and selectively change documents.
Bird's-eye view of SAP SIEM
For enterprise-wide attack detection, our goal is to combine as much information as possible. This is the only way to define the attack patterns that are afterward continuously searched for.
In the SIEM, it will combine the SAP logs with security logs from other sources:
- Server and Desktop OS
- Firewall / VPN
- Physical infrastructure (e.g., access control systems)
- IPS and IDS
- Identity Management
- System Health, Performance Monitoring Information
- Network and accessories
- Anti-Virus
- Databases
You must take the following steps in the SIEM process to create reliable alerts. First, you must read the data promptly. This also involves the normalization of the different source formats. Traditionally, mapping the SAP logs already presents the first challenge to customers since the event logs (e.g., CEF) can handle hardware or operating system logs better than the application logs.
Many SIEMs try dividing the data into categories directly in the onboarding process. The customer defines these categories during the definition phase and can become a valuable tool later during processing.
Validations must be in place to ensure the integrity of the monitoring solution including those logs that are not disabled and (or) manipulated. Especially with SAP, an insider can change the logs already in the application stack or flip a switch that prevents the output of security-relevant information.
Once the integrity of the data is ensured, the correlation can begin. This area is extensive and can be very specific, which depends on the customer deployment scenario. As a rule, the actors are identified and then attributed. Actors can be, for example, Windows users or an SAP account. Attribution is the process responsible for assigning attributes and properties. Information about the threat actor will be enhanced, with various attributes, such as the used operating system, SAP log-on version, geo-location, and IP-Range.
With all this information, you can now create alarms. For example, if a user who usually works at the German office and with a Windows laptop now logs in from Asia and uses a Linux system, this could lead to an alarm. Of course, to detect SAP insider attacks, the information must be specific and detailed.
Conclusion
Detection of malicious SAP activities and distinguishing them from “regular” admin activities requires defining what is normal, and which activity represents an anomaly. In-depth knowledge of SAP security is necessary for this. Critical, remote-enabled function modules, as well as database tables with sensitive content, must be known.
Therefore, with SecurityBridge Threat Detection, we provide our customers with a simple and attractive solution and an extensive knowledge base. SecurityBridge customers have access to the largest information collection on securing SAP applications.