Dear community,

Are you ready to learn how to apply plug-and-play automation to block compromised SAP users based on suspicious activity on SAP RISE, SAP ERP, Business Technology Platform, and Azure AD?

This blog has you covered with all the steps required to start kicking 🤸🏾‍♂️ compromised users. As a byproduct to that rewarding experience your landscape becomes more secure. But we are here mostly for the kicking 🏌🏻.

To get into the right mood, read below lyrics inspired by a famous pop song. Can you guess which one?

I used to run scared from every cyber threat,
   But now I'm standing strong with SOAR and SAP, you bet!
Microsoft Sentinel's got my back, every day and night, 
   My ERP's on lock, my data's out of sight!
With automation and response at lightning speed,
   I'm roaring with confidence; my business is guaranteed to succeed!
'Cause I am a champion, and you're gonna hear me SOAR
  Oh-oh-oh-oh-oh.

There you have it. Now you’re stuck with that educational jingle like I am. By the way, SOAR doesn’t have anything to do with fireworks rising into the night sky – just saying, for those of you who guessed the correct artist but wrong pop song. We will get back to that later, no worries. Back to business…

I am building upon the prior blog posts about SAP and SOAR by AMIT Lal and Naomi Christis that leveraged the same user blocking scenario but used a gateway component for on-premises connectivity, SAP RFC interface, and GitHub hosted sources for the automation.

SOAR is short for Security Orchestration, Automation, and Response

and refers to acting on security signals. As you might know from the previous post: Sentinel functions both as a Security Information and Event Management (SIEM) tool and SOAR solution. So, it can monitor and analyze security events in real-time while automating incident response workflows to improve the efficiency and effectiveness of security operations.

Today’s post showcases the end-to-end scenario using a playbook that is being shipped by the SAP solution in Microsoft Sentinel right away.

Yes, you heard that right – configuration only! No development needed.
That brings down the integration effort even further 😊

Imagine a scenario where your SAP system is being targeted in an attack

A user attempted to execute a sensitive transaction within SAP, triggering a detection on Sentinel. Sentinel warns us about this suspicious behavior by triggering an incident which we need to investigate further!

🛈 Note: See this video for a small detour to gain a broader overview of multi-staged attacks with file download from SAP and investigation hints identifying hacker groups.

As part of the security signal triage process, you may choose to kick out 🤸🏾‍♂️ 💥 this problematic user from ERP, SAP Business Technology Platform, or even Azure AD – a little drastic you might say. Hence, there is the out-of-the-box option on the playbook template provided by Sentinel for a Microsoft Teams driven approval process. It is up to you to employ this extra step or act automatically and ask for forgiveness afterwards 😉

Fig.1 Sentinel card with SAP incident in Microsoft Teams offering user block scenarios

As you can see above our guinea pig user Nestor had the audacity 😤 to open SAP transaction SE80.

Understand the setup to make it happen and configure yourself

For this sample, I added transaction SE80 to the sensitive transactions watchlist “SAP – Execution of a Sensitive Transaction Code” on Sentinel. Therefore, opening SE80 raises now an alert each time “Nestor the brave” opens it. SE80 is not very sensitive though – at least outside of production. It is a means of easily triggering an incident.

See the list of analytic rules for additional scenarios on the Sentinel content hub. My personal favourite is “Deactivation of security audit log”. But I am saving that one for part 3 of the series. Back to our watchlist and SE80.

Fig.2 Screenshot from Sentinel watchlist containing entry for SE80

See below the step-by-step flow of the scenario as “coded” into the shipped Sentinel playbook.

Adapt scenario completely to your liking. Fancy Service Now or SAP Build
Process Automation workflows? Go for it.

In our case today, the playbook automation is centred around adaptive cards in Teams Channels (see step 5 below). Sentinel supplies the incident information and triggers the playbook in-time to act on the information provided. The provided playbook comes with a workflow orchestrating below actions.

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

Till today the RFC for BAPI_USER_LOCK (or SUSR_BAPI_USER_LOCK for SID global lock) is the most efficient way to programmatically lock a backend user.

However, for a uniform solution that would be applicable to C/4HANA,
S/4HANA Public Cloud instances, Business Suite, and R/3 alike we needed
a less “antiqued” 🏺 interface than RFC.

Checking the SAP API Hub… ⏳the common denominator for user actions like “block” is SOAP.

🛈Note: For Cloud-only scenarios beyond the user-blocking and where available the go-to interface would be OData.

Creating line of sight to your SAP system for the SOAP request

To reach the SOAP service on your SAP systems anywhere, establish line-of-sight 👀.

I’d like to mention Azure Virtual Network (VNet) injection capabilities and reverse-connect gateways like the SAP Cloud Connector or the Microsoft On-Premises Data Gateway to make that happen. See Amit’s post for more details about the path via on-premises data gateway and RFC requests.

This post focusses on Azure PaaS components and APIs instead. This approach brings the added benefit of isolated and secure networking through Azure VNet integration, native Microsoft backbone usage and managed resources across the board.

See below a detailed flow with three different connectivity options (A,B,C): private VNet injected API Management and/or Azure Logic App (aka playbook) or SAP Integration Suite.

Fig.4 Illustration of workflow connectivity from Sentinel to SAP backend

Microsoft Sentinel supplies the SAP incidents to the workflow layer before being processed by the SOAP service (sequence depicted by the numbers 1-3).

Note that option C requires a Logic App to receive the Sentinel incident before passing it on via http action to an SAP iFlow on Integration Suite. You are chaining the two workflow engines so to speak.

Choose the deployment flavour based on your needs (A, B, or C):

XML transformations for the SOAP request and response are handled with built-in tasks on SAP Integration Suite, Logic Apps, or Azure API Management liquid templates.

Speaking of SOAP, luckily any SAP function module can be exposed as enterprise service!

See the specifics for the SOAP setup with BAPI_USER_LOCK RFC on my blog. It shows you around and gives guidance to retrieving the WSDL and where to find the SOAP access URL on SAP SOAMANAGER.

Flavour A: Serverless Logic App – Configure API Management to front your SAP SOAP service

Below description focuses on Azure API Management but you may also implement this with SAP BTP components like SAP Integration Suite, SAP Build Process Automation and SAP Bridge Framework to generate the cards for Microsoft Teams for more details.

SSL handshake and certificate trust is taken care of on the API Management layer. See configuration details here. Alternatively, disable trust chain verification for PoC type implementations (APIs -> Backends -> Validate Certificat Chain).

In case you don’t want to use an additional API component at all, skip over to the next section “Flavour B” for a Logic-App-only solution.

Ruling in favor of API Management? Have a look at this blog post – especially the lower section – showing in detail how to add this particular SOAP service to API Management before continuing here.

Flavour B: VNet injected Logic App – create direct line-of-sight to SAP

• Choose Azure Logic App plan type “Standard” and assign service plan. Given the simple nature of the playbooks for incident orchestration and likely rare executions plan “WS1” will be sufficient. Use State Type “Stateful” for your new workflow once the Logic App is provisioned.

🛈Note: You may change Azure Logic App type from Consumption to Standard using the Visual Studio Code extension. Compared to the playbook low code experience so far, that would be considered a pro code effort. See the Microsoft docs for details.

Fig.5 Screenshot of Logic App plan type selection and App Service plan selection

• Configure VNet integration to inject your playbook into the network that has line-of-sight 👀 to your target SAP system.

I recommend waiting to setup “Access restriction” till you have finished your initial integration test. As soon as the playbook is limited to communication with Sentinel, you can only debug the workflow from within the VNet. Meaning you require local network access through Jumpboxes, Azure Bastion service, or VPNs etc.

Fig.6 Screenshot of VNet integration and access restriction configuration

Once you progress to Access restriction pick the “AzureSentinel” service tag as target for the allow-list

Fig.7 Screenshot of adding Sentinel to the playbook allow list

Get the standard SAP playbook from Sentinel

• Search for SAP and choose the desired scenario from the templates that are part of the SAP solution for Sentinel. In our case that “SAP Incident handler: Block User from Teams”. Make sure you have updated the SAP solution on Sentinel to the latest to get the most recent playbook.

Fig.8 Screenshot of SAP playbook create experience on Sentinel

Retrieve the info for the required parameters. They serve as fallback in case the raised alert automation with dynamic parameters isn’t configured by you yet. See the advanced playbook guidance for that (soon to be published).

A simple approach for the Microsoft Teams IDs involves extracting it from the sharable link URL from the target channel as shown below. Be aware they are URL encoded (I like DevToys for URL decoding but any decoder will do)! See this article for further options like the Microsoft Graph API to get the Teams IDs.

Fig.9 Screenshot of Teams IDs extraction from deep link

Your extracted values in JSON format should look something like this:

{"channelID":"19:a38680470d95481685c064f36a146e24@thread.tacv2","teamID":"c1eedb2a-3a35-4f0e-98e3-898c2d5e907c"}

• Provide default values for the parameters TeamsChannel with your constructed JSON like above, DestinationEmail with your trusted SAP security admin, SOAPApiBasePath as noted down earlier (see fig.10), SAP-SOAP-Username, and SAP-SOAP-User-Password as per your SOAP user on SAP.

• Follow the playbook post deployment steps afterwards. The playbook uses built-in connectors to orchestrate the process as outlined in fig.3.

The playbook ships with managed identity setup for Sentinel. Watch out for the role assignment of the managed identity of your Logic App (Settings -> Identity -> System assigned -> Azure Role Assignments). Verify suitable Sentinel Roles in case you get authorization errors on the Incident-Update steps of the workflow. Currently “Microsoft Sentinel Responder” on resource group level where Sentinel lives, does the trick.

Be aware of the token caching and lifetime intervals. For quick initial integration tests, I recommend using a named-user to avoid waiting for managed identity role changes becoming active.

Fig.10 Screenshot of Sentinel connector sign-in on the Azure Logic App

Speaking of easily getting started: If you like a simpler static approach for the Teams Connector, you may use the name-based browse experience on the playbook instead. I highly recommend the parameterized approach though for easier maintenance!

Fig.11 Screenshot of simpler Teams Channel configuration without sharable parameters

🛈Note: The advanced version of this playbook goes one step further with dynamic configurable Teams targets, secure credential store in Azure Key Vault, and SOAP service by audit class and SAP SID in Sentinel. That aspect has been skipped in the basic version of the playbook for a simpler start with this integration pattern.

• Retrieve the SOAP API URL from SOAMANAGER as described in this blog post. See fig.12 for visual reference.

Flavour B treats the SOAP request as raw http XML message, whereas flavour A using Azure API Management translates between JSON and XML simplifying the interaction on the playbook. See below resources to finalize the trust setup between the VNet injected Logic App and SAP for the SOAP service requests.

Fig.12 Screenshot of configuration of flavour B with XML based SOAP request

Don’t forget trust for the external SOAP calls!

1. TLS/SSL setup for Azure Logic Apps http connector
2. Azure Logic Apps -> Settings -> Certificates -> Public Key Certificates -> Add SAP Root CA

🛈Note: Configure DNS for SAP hostname resolution and import root CA public keys for the POST request. Otherwise, SSL and certificate validation will not work. For initial testing with private IPs like in my screenshot below use the http endpoint instead. Verify soap node from SICF transaction and configure no-ssl when creating the SOAP binding via SOAMANAGER for that.

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

Authorizations detour

• Speaking of SAP authorizations: The user blocking scenario requires execution rights for the target Web Service and RFC.

Easiest option to identify the minimal authorizations for any of your own
integration scenario is transaction STUSERTRACE.

Verify dynamic parameter “auth/auth_user_trace” is enabled via transaction RZ11.

See below trace for my advanced user-blocking setup. The SOAP enabled RFC called TH_DELETE_USER has been added to end active sessions after blocking of the SAP user through BAPI_USER_LOCK. After all locking is not enough if your audacious SAP user is still logged in 😉 See this part of this series for more details about the session kill.

Fig.13 Screenshot from SAP authorization trace for user lock

• Ready to roll with an integration test ➰🎲 Assign the playbook to analytic rule like “SAP – Execution of a sensitive Transaction Code”. Find that section under Configuration -> Analytics -> Rule Templates. Edit the rule using the three dots … on the right and assign your playbook as automation target for detected executions of sensitive transactions.

Fig.14 Screenshot of playbook association with analytical sentinel rule

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

If you followed my sample, you may open transaction SE80, since it is maintained on the watchlist as outlined in fig. 2. You will need some patience, because the SAP log ingestion runs on a schedule every 2-3 mins. I know it is hard to wait. How about completing the song from the intro? 🎙️

• Verify the playbook has been triggered, posted your Microsoft Teams message on your configured channel (see fig.1) and blocked your SAP user – after all LOCKME asked for it audaciously accessing SE80 😤.

Fig.15 Illustration of verification of the workflow run on the playbook showing the SAP user lock response

• Feed a meaningful comment to support your user block action. Your provided comment will be posted back to Sentinel for auditing purposes closing the loop on your action.

The same is true for flagging false positives!

This way Sentinel learns to identify benign incidents going forward and
the security operations colleagues get a “paper trail” to understand your
reasoning to disregard this incident.

Fig.16 Screenshot of updated close reason on Sentinel fed with comment from Teams

Fig.17 Screenshot of successful lock reply message within the context of a Teams thread

Once the security folks acted upon the card presented in Teams, the card updates and the playbook responds with flow messages on the same thread. This workflow feedback gives conversation-aware insight to the SAP security person if the blocking request went successful or not.

That’s it for the configuration of blocking SAP ERP users 🎉

Insights into blocking users on BTP subaccounts

Above described process stays the same. You need to configure another API call to target the BTP service of your choice to disable the user. Options range from SAP Cloud Identity Services – Identity Authentication (IAS) to the SAP Authorization and Trust Management Service (XSUAA).

Below steps to block a user refer to the XSUAA acting on a single BTP subaccount. In case your BTP estate is fully configured to use IAS across the board, blocking the user there would be more impactful.

Learn more about how to create a service key and OAuth2 client credentials grant with BTP services here.

Learn more about the user authentication API for the XSUAA via the Cloud Foundry UAA docs here.

The If-match header and ETag handling shown below is required by the PATCH operation of the XSUAA API to update the user attribute called “active”.

Fig.18 Illustration of BTP API configuration on the playbook to disable a user

Insights into blocking users on Azure AD

This one is even simpler because Azure AD has its own connector on the playbooks. A single step using the “Update user” action will do 😎 Be aware that this step requires extensive Azure AD admin rights, which are often hard to get.

Fig.19 Screenshot of Azure AD connector setup to disable a user

Before you go

Fine-tuning the incident triage process and automation is key.

Otherwise, you will be singing the other song you guessed wrongly at the beginning, drowning in myriads of incidents and adaptive cards flooding your Teams channel. That would sound something like this…

Sentinel – Oh Baby, you’re a firework! 🎉🎆

Additional automation scenarios

Based on recent customer conversations we released an additional playbook for SAP Audit-Log re-activation. A suitable detection would be the pre-configured analytic 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.  Reach out to me for a detailed discussion.

Design your own adaptive card for Microsoft Teams and/or Actionable Message for M365 using the online designer. Get started from here.

Final words

That’s a wrap 🌯you saw today how to surface critical events from SAP RISE and non-RISE to your security team with immediate remediation actions. That brings down the time till a compromised user gets locked out of your environment substantially. Not too bad, huh?

To make that happen we looked at SAP SOAP interfaces exposed via private networking, API Management and SAP Integration Suite. Microsoft Sentinel leveraged Microsoft Teams to enable your security operations folks with pre-configured playbooks.

The basic playbook showcased in this post gets you started quickly, but only the advanced version of it gets you true coverage. Check it out on the 👉 second part of this blog series.

Find your way back to the intro of this blog series here.

Got an SAP threat at your hands that needs automatic remediation like you saw today? Overall, this integration pattern is applicable to any SAP API. Let me know in the comments or reach out directly.

#Kudos to Sebastian Ullrich, Ofer Inbar, and Naomi Christs for speeding me up big time in releasing these materials😊 Find Naomi’s introduction into the topic on the TechCommunity.