Dear community,

Based on part 1 of this series we are going to up-level to more sophisticated automation to block compromised SAP users. The basic playbook discussed before served the purpose of getting started quickly. On the downside it compromised on scalability.

Today’s post is about completing that workflow with secure credential handling and dynamic parameter setting with watchlists.

Microsoft Sentinel for SAP watchlists enable configuration in a single place for
all security incidents spanning your security perimeter across M365, SAP, and
other 3rd party vendors.

The provided advanced playbook relies on an API Management solution for the VNet injection. See fig.4 in part 1 for more details about other integration options.

Fig.1 SAP user block scenario overview orchestrated by Azure Logic App

Fig.2 Illustration of advanced automation create experience

• Follow the playbook post deployment steps as marked above. The playbook uses built-in connectors to orchestrate the process. Note the different parameters compared to the basic playbook in part 1 of the series.

Some of you may want to dive right into the SAP ERP blocking but skip SAP Business Technology Platform and Azure AD for now in favour of a speedy 💨 integration test.

User locking on Azure AD requires extensive Azure admin rights! These are
usually hard to get by initially. In such cases you may simply drop the steps
from the Logic App temporarily.

For those of you that like emails for critical communications

• Be aware that the Actionable Messages on Outlook – other than adaptive cards in Microsoft Teams – require a dedicated setup on M365 due to the security risk of emails with dynamic content.

In addition to that auto-invoke http actions need to terminate within a couple of seconds. Keep that in mind for long running steps in your Logic App or revert to normal http action. In our blueprint Microsoft Teams is supposed to be the single source of collaboration, therefore the outlook message links back to the Teams channel to block the SAP user.

Arguably emails are no efficient means for ad-hoc push messages. Do you agree?

Fig.3 Screenshot of actionable message with SAP incident in Outlook

You may test with the same user, creating the Outlook connection on the Logic App initially. Note me, myself and I sending actionable messages to myself above.

Create your own actionable message with the message Designer or adaptive card Designer (select: host app actionable message). By the way ChatGPT is also quite good at generating adaptive cards. Give it a try.

Apply Azure Key Vault for secure credential handling

The vault may hold any secret, certificate, or key. Furthermore, it offers automation and events for key rotation, certificate expiry and renewal. The playbook presented here, uses a simple “Get secret” action to retrieve the secret based on the parameter provided (see fig.2).

• You have a smoother connection update experience creating a new connection to an existing Key Vault instance like below.

Fig.4 Illustration of Azure Key Vault Connection configuration

Dynamic parameters enable complicated incident triage workflows for any number of SIDs

• Maintain the parameter “InterfaceAttributes” with the base path to your SOAP service per SAP SID using the provided JSON

{"BasePath": "https://api.my-sap-soap-service.com"}

This way a single playbook can operate on multiple SIDs exposing the SAP user blocking SOAP service. See playbook step “Run query to select sap base path” (from Azure Monitor Logs -> Run query and list results) to select the configuration from the watchlist at runtime.

Fig.5 Screenshot of SOAP base path configuration in SAP watchlist on Sentinel

• The same approach can be applied for the TeamsChannelID and DestinationEmail using the Sentinel watchlist “SAP_Dynamic_Audit_Log_Monitor_Configuration”. This way different Teams Channel can be targeted per audit class for instance.

Fig.6 Screenshot of Sentinel watchlist with dynamic parameters for Teams channel and Outlook

Another great resource to verify your desired log class (message id) is the pre-configured Sentinel alert rule.

Fig.7 Screenshot of Audit Class selection in Sentinel Alert Rule

• Once all connections are configured and potentially unwanted steps are dropped, save💾 the playbook.

• Ready to roll with an integration test ➰🎲

Have a peak at part 1 if you don’t know how to trigger an execution. I personally like the “resubmit” function to quickly do some trial-and-error runs. See below the two UI options for Logic Apps Standard and Consumption.

Fig.8 Illustration of workflow resubmit functionality in Azure Logic Apps

Go on… kick off your trigger. I will wait ⌛🐧

Additional automation scenarios

Based on recent customer conversations released an additional playbook for SAP Audit-Log re-activation. A suitable detection would be the pre-configured alert rule “SAP – Deactivation of Security Audit Log”. Speaking, isn’t it? See part 3 for details.

Anyone curious about malicious Sentinel collector agent tempering detection and avoiding false positives? You don’t want to get mad during SAP maintenance windows, do you. That is next 😉

Looking to you to request additional scenarios and share your own as Pull Requests on GitHub.

Final words

That’s a wrap 🌯you saw today how to reach the next level with the SAP user blocking scenario including enterprise grade credential handling with Azure Key Vault and dynamic parameters for infinite scale of the approach. Not too bad, huh?

To make that happen we configured the SAP watchlists on Sentinel and added our sensitive credentials to the key vault.

This integration pattern overall is applicable to any SAP API. Got another SAP threat at your hands that needs automatic remediation? Let me know in the comments or reach out directly.

Cheers

Martin