Introduction
Last year, Microsoft announced a new security solution for SAP systems in Microsoft Sentinel. Since then, we’ve continuously increased the number of different logs and tables that can be streamed from the SAP Landscape into the Microsoft Sentinel workspace.
The latest feature released this week to public preview is the Dynamic SAP Security Audit Log Monitor analytics. This single analytic rule can raise incidents on more than 180 (!) different events, covering all events that can be caught using the SAP Security Audit Log.
The Security Audit log records detailed activities, for example:
- Security-related changes to the different SAP system environments (changes to user, roles, authorizations or profiles, for example. This also can be tracked and correlated using SAP User Master Data retrieval - another feature we’ve announced in February ‘22).
- Detailed activities of logon and logout activities, including reasoning (such as wrong password, blocked user - for failed logons, for example)
- RFC calls status - successful or unsuccessful RFC call attempts
- Report creation, User creation
- File download
- Configuration changes
Microsoft Sentinel for SAP already had 50 analytic rules, many of which were using Security Audit log as data source, however there are many more activities in that log which customers may want to be alerted about. SAP Dynamic Security Audit Log Monitor allows for monitoring events previously not covered by these alert rules. If there is an event, that Dynamic Security Audit Log Monitor hasn't been configured to process, you'll be alerted to update the configuration. This capability extends the support for alerting on custom SAP audit log events, enabling a one-stop shop for all audit log alerting and further simplifying the security analysis work as it does not require a separate analytic rule per event.
What is an SAP Audit Log Message?
Messages in the Audit log represent a specific event type, a sub-class of the audit class.
Suppose a user is logging on to SAP via GUI, successful logons would be logged with a Message ID of AU1, while failed logons would have a Message ID of AU2, both would be classified under the audit class "Logon".
What kind of scenarios we should look out for in the audit log?
We don’t want to raise an incident for every failed logon, as that would generate too much noise, however repeated logon attempts by the same user should get us wondering what’s going on. For an example of atypical activity - It is normal for a user to logon to a system several times in a row, however it is suspicious to do so 10,20,30 times within several minutes.
Consider another scenario- we may have some test or scheduled job accounts that DOES exactly that – logon many times in a row.
We really want to minimize noise and only raise relevant events as well as have the ability to tweak the thresholds for raising the incident
Well… the Dynamic Security Audit Log Monitor does that over a single analytic rule and is easy to configure through a watchlist.
So, what's new exactly?
In the latest release of the solution, we’ve added a new analytic rule - Dynamic SAP Security Audit Log Monitor, that will raise an alert according to the pre-defined configuration of your workspace. Rule is configurable via a new watchlist called SAP_Dynamic_Audit_Log_Monitor_Configuration. This watchlist contains an out-of-the-box configuration for different alerts that can be raised, and you can further customize those to tailor to your specific needs and requests.
Let’s go over some of the parameters in the watchlist, taking AU2 Message ID as an example:
What about false positives?
Reducing noise is critical to maintain a good security operation. Here are a few ways to do that using the Dynamic Security Audit Log Monitor:
Set severities and disable unwanted events
You can customize the incident message, message details, what severity the incident will be created with when this event happens in a given environment type (it may be Critical on Production systems, but not relevant or low priority in Dev/Test systems).
Specify a frequency threshold
For example, the message AU2 (Logon failed) is configured with a threshold of 6 (which means 6 events per hour for a productive system) and 30 logons per hour for a non-productive system. This will allow for alerts to be triggered only for logons recorded with a frequency greater than 6 per hour for a productive system, for any given sliding window, making sure any DDoS attacks will be alerted on. Threshold works like a speed limit - we don't need to wait for a user to accumulate 6 logons, instead we're looking at the sliding window of 15 minutes in size by default.
Exclude Users using tags
What if a user is expected to exceed the thresholds, for example - a service or a testing account? How can we reduce panic? There’s another watchlist SAP_User_Config, where you can assign tags to users, then add a reference to those tags in the SAP_Dynamic_Audit_Log_Monitor_Configuration, effectively exempting those users from being alerted on for a specific message.
Exclude users by their SAP roles/ profiles
Now, imagine a scenario, where users are using a PowerBI dashboard, that connects to SAP using RFC and generates a lot of RFC calls. We know the activity is legit, however excluding all users that have access to PowerBI is not feasible. Instead, we can reference the "SAP_POWER_BI_USERS" role to be excluded, and users who have the role will not be flagged if they exceed the threshold specified for amount of RFC calls.
There are over 180 Message IDs defined in the Dynamic SAP Security Audit Log Monitor, most of which are disabled by default (so that we don’t overwhelm you with alerts), however we do encourage all to identify which Message IDs are relevant and should be tracked, enable those (enabling is as simple as changing a line in the config watchlist), and get more relevant, customized incidents from the SAP Audit log.
Some more capabilities
You can also tune the MITRE ATT&CK tactics associated with the incident, because SOC specialists, who are going to handle the incident may not necessarily know about the implications of every particular Message in SAP's audit log.
Furthermore, one can create a playbook to notify relevant teams of the incident using email or Teams message using a teams group ID and channel ID or email address in the relevant column, and once incident triggers, SAP BASIS admins (or any other team, that may not even have access to Sentinel) can be alarmed.
Incidents raised by the Dynamic Security Audit Log Monitor provide all relevant entity information, that are helpful to visualize the full attack chain
When incidents are raised by the Microsoft Sentinel solution for SAP, we attempt to match user identity in SAP with Azure AD identity, using user’s email, if one is defined in SAP.
But what about users, that don’t have an email defined in SAP system?
Well, using the SAP_User_Config watchlist, that we already mentioned, you can associate SAP users with Azure AD user, or on-premises user identity:
That way when these users appear in any incidents, their entities will be properly mapped and corelated with other data in Sentinel.
To get the Dynamic Security Audit Log Monitor, simply update the solution from Content Hub and get all the goodies from the latest content update!
Conclusion/Call to action
Dynamic Security Audit Log Monitor analytic rule is a essential component to detect sophisticated threats in SAP applications and we encourage you to try it out now by installing the latest version of Microsoft Sentinel for SAP solution from the Content Hub.
At the lowlights - we have also updated the documentation to make the deployment process much more user-friendly (especially for users that may not necessarily be SAP experts), check it out at https://aka.ms/sentinel4sapdocs
Posted at https://sl.advdat.com/38fVgDBhttps://sl.advdat.com/38fVgDB