Special thanks to NChristis for reviewing this blog!
This series of blog posts walks you through the SAP for Sentinel solution and how you can evaluate the solution and make sure you consider all the necessary steps that help you to put the solution into production.
This is a two-part blog:
- Part 1: Describes the process of a pilot, how to use watchlists and workbooks.
- Part 2: How to use analytics rules, to handle incidents and use the SOAR capabilities [You are currently here].
In the first part of this blog, we covered how to get stated with your proof of value by gathering stakeholders, set success criteria and how to use watchlists and workbooks. In this part, we will look at how you can create and handle incidents and use the SOAR capabilities. We will continue describing the functionality of the Microsoft Sentinel solution for SAP in the form of use cases such as “As a <role>, I want to achieve <goal>”.
Analytic Rules
In Part 1 , we have configured our watchlist which would allows them to be used in workbooks, the next step is detecting malicious activity on your SAP systems: As a SOC analyst, I want to be able to detect when audit systems have been disabled on our production SAP systems.
This is an important and interesting use case within the SAP ecosystem. One of the first steps that attackers take when they have access to your SAP systems, is to disable the auditing mechanism of SAP. This hides their tracks very effectively and makes detection much harder.
For this purpose, we can once again rely on content that has been delivered by SAP for Sentinel Solution. Navigate to Analytics blade in the Configuration section of Sentinel. Here, choose the Template section and search for SAP. This will provide you with a list of all the built-in SAP detection rules.
Templates can be implemented by creating them and adjusting them to your needs, this ties back in with making sure that your watchlists are properly populated. By using watchlists we can use analytics templates out of the box without having to adjust every query to adapt it to your organization. Using watchlists will also make it easier when you transition from a proof of value to production. Enabled rules will then automatically take into consideration changes to your watchlists such as additional production systems, networks, users etc. Back in your Sentinel template section look for the template “SAP - Deactivation of Security Audit Log” and choose Create Rule where you will be able to adjust to properties of the rule.
We will briefly talk you through setting up the rule. In the general section you can give your rule name, description, severity and MITRE ATT&CK TTP categories. Continue to the rule section by pressing "Next".
In this tab, we can adjust our rule logic to trigger whenever audit capabilties in SAP have been disabled. In our proof of value, we perhaps don’t want to disable auditing in our production systems even for a second. There are two ways you could tackle this issue:
- You could use watchlists as we described in Part1 of our blog post
- You could adjust the KQL of Analytics rule to filter out your development systems.
For this second part of the blog, we will show you how to use the second option as we have already shown how watchlists can be used to mimic production environments. Assuming you have added an SAP system and marked it as Development in your watchlist, we are going to add some slight changes in the rule logic section so that the query uses watchlists, so we can test this in a development SAP environment as if they were production systems.
// Audit Log Classes - Audit Log Active Status Events
let AuditClasses = dynamic(['AUJ']);
let Development
SAPSystems = (_GetWatchlist('SAP - Systems')
| where SystemRole == 'Development'
| project SearchKey); SAPAuditLog
| where MessageID in (AuditClasses) | where Variable1 == '0' and SystemID in (DevelopmentSAPSystems) // Audit Active Status = 0
| project TimeGenerated, Instance ,SystemID, ClientID, User, MessageText, Email, TerminalIPv6, Host // Details
| extend AlertRuleUniqueName = 'deactivationofsecurityauditlog'
In this case we added additional KQL to first fetch our SAP systems watchlist on line 3 and where we immediately filter out the systems that are marked as development. This query might return multiple items as you might have multiple development environments, that’s why we add the parentheses to convert the result into an array. Lastly, on line 6 we adjust the query to look for events where the audit mechanism has been disabled and the SystemID matches one of our development environments.
If you were to deploy this in production, you might change line three to search for “Production” systems because you are only interested in disabling the audit mechanism on production and not on development or test systems. This allows you to be flexible when creating rules for monitoring your SAP system, this way, every time there is a new SAP system deployed in production, you just add it to the watchlist and the KQL automatically takes this into consideration on its next run and you don’t have to remember which rules might potentially need to be updated.
For this to work, we of course need to make sure that our watchlist are up to date. So, make sure that the watchlist called ‘SAP - Systems' is up to date. You can check the section on the watchlist in Part 1 to see how this can be done.
Other aspects worth changing in this tab are entity mappings, so that Sentinel can automatically extract them and present them to you once an incident is created. This allows you to be more efficient when doing an investigation as you won’t have to drill down into the raw data to extract this information. Once you are satisfied with the rule, click next until you reach the Review tab and create the rule.
Incidents
We will start this section straight with the use case as it is a straightforward one: As a SOC analyst I want to investigate incidents related to our SAP systems.
Once your analytics rule has been created, as we did in the previous section, the next step would be to investigate any incidents that are created because of the rules. Having an actual incident over the duration of your proof of value might not be possible. We can collaborate with our SAP business owners to trigger an incident more easily.
Ask your SAP business owner to have them disable the audit capabilities in the SAP system that has been on-boarded into Sentinel. Ideally, this is a non-production SAP system. If this is not feasible for you, you can also ingest sample SAP logs from our GitHub repository.
Depending on how you set up your analytic rule, you also configured how often the rule should run and trigger incidents or alerts. Once the rule runs and an incident has been created, you can open the incident pane and click on the incident that has been created.
We can then open this incident to get the full details, by clicking “View Full Detail”. Once you open this view, you will get an overview of general information such as the severity, owner, status as well as the number of events and alerts that generated this incident. Additionally, you can also see which MITRE tactics and techniques are involved, this is what we configured during the analytics rule creation.
We also see the alerts, in this incident we have only one, but we might also have cases where multiple alerts are grouped into one incident. More interesting is the entities section. Here, we can see the user involved of disabling the audit mechanism, which gives us a hint which account we need to further investigate and also the impacted system. From here we can start to dig deeper by for example looking at the raw logs or looking at taking automated action to re-enable the audit mechanism or send an email to the user to confirm their actions.
SOAR and Automation
So far, we have covered how you can successfully create workbooks, how you can use watchlists to dynamically create analytics rules and how you can investigate when an incident happens. In the last section of this post, we are going to focus on how you can respond to incidents.
This is a crucial part for SOC analysts, as automation allows us to do perform two different but equally important tasks:
- Respond faster to incidents, allowing you to contain the incident faster than when you have many manual actions to perform
- Involve and relay information to business owners as part of the investigation
For this purpose, we will combine two use cases to showcase the SOAR capabilities of Sentinel. As we explained in the previous section audit logs in SAP are crucial for detection, it is in fact one of the data sources that are ingested into Sentinel as well. The second use case will make sure that we keep our business counter parts involved.
As SOC analyst I want to enable the audit mechanism in SAP if it has been disabled by a malicious actor
As SAP business owner, I want to be notified if a malicious actor has performed a sensitive transaction
The primary way of automating your response in Sentinel is by using playbooks. Playbooks in Sentinel are built on Azure Logic Apps which is a cloud platform where you can create and run automated workflows with little to no code. By using the visual designer and selecting from pre-built operations, you can quickly build a workflow that integrates and manages your apps, data, services, and systems.
The first use case is easily achieved, the SAP for Sentinel solution provides three out of the box playbooks that can be used to automate your responses. To enable this playbook, navigate to the configuration section of your Sentinel instance and open the Automation blade and go into the “Playbook template” section.
Here you’ll find all the templates that are provided with the solutions configured for your Sentinel instance. One of them is specifically useful for our use case. It is called “SAP Incident response- re-enable audit logging once deactivated”. Select it and create the playbook.
For this playbook to work, you will need to enter three parameters:
- SAP-SOAP-KeyVault-Credential-Name: This is the name of the secret that is stored in your key vault which houses the credentials to communicate over SOAP with SAP. If you are unfamiliar with how this needs to be setup, you can direct your follow the steps described in this blog post Generate SOAP services for your legacy RFCs to sim... - SAP Community
- TeamsChannel: As part of playbook sequence of actions, a message will be posted into a Teams channel as well, this can be a shared SOC channel or a channel where you want to share information with SAP business owners.
- DefaultAdminEmail: This is the fallback communication line for sending out emails with regards to the incident that triggered this playbook.
Once you have provided these details, go ahead and save your playbook. You can configure the connections later if necessary. To understand what this playbook does and how it operates, you can read the this blog post Re-enable SAP audit log automatically with Microsoft Sentinel - part 3.
Once the Playbook has been created, we can use it in two different ways, one of which is during an active investigation. Once you go through your investigation and you confirm this is an actual incident, you have the option to execute this playbook to re-enable your audit setting in the SAP systems. You can do so by selecting "Incident Action" in the incident view and then choosing the "Run playbook" option.
In this blade search for SAP and you will be able to see the playbook that you created in the previous steps. Choosing the playbook will then execute it and re-enable the audit mechanisms in SAP.
Once you select the run option, you will be able to see how the execution goes and what the status is by selecting the “Runs” tab in this view or by checking the Playbook health workbook.
Another way of doing this, which we also suggest, is to automatically execute this playbook whenever similar incidents occur. Re-enabling your audit trail is harmless and has no impact on your SAP business, so unless there is a valid business reason to disable this temporarily you can safely re-able the audit mechanism.
To achieve this, navigate to the Automation blade under the configuration section and create a new Automation rule. In the new blade, you can select the conditions such as whenever a new incident or alert is create based on the analytics rule that indicates the SAP audit mechanism has been disabled.
In the action section you can choose the option to run a playbook and pick the playbook we configured in the previous section.
To test this, you can ask your SAP owner to disable the audit mechanism on a non-production system and then monitor the creation of the incident in Sentinel and the subsequent execution of the playbook. Verify with your SAP owner whether the audit mechanism has been re-enabled.
Production Consideration and conclusion
In this blog post, we walked you through how to evaluate the Microsoft Sentinel solution for SAP by discussing how to use watchlists, workbooks and incidents to detect threats and monitor them as well as using playbooks to perform automated response.
With this, you already have all the building blocks that would allow you to easily go onboard your production SAP systems; the onboarding, workbooks, incidents and playbook remain the same. Watchlists become even more crucial when onboarding production systems as they are heavily used in the analytics rules.
Onboarding production systems will of course require a higher effort due to change management, so take that into consideration in your project management. Another aspect to consider is the automated response capabilities. You must very carefully align with your business counter parts which actions are allowed to be taken automatically on production systems.
Hopefully, you were able to successfully finish your proof of value and move your SAP for Sentinel solution into production!
Microsoft
