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.