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 workbook. [You are currently here]
- Part 2: How to use analytics rules, to handle incidents and use the SOAR capabilities .
To effectively monitor SAP threats, a clear strategy is essential. It's crucial to secure SAP systems and broaden our security perspective. Many organizations struggle to monitor their SAP environment and have little to no visibility on their SAP landscape. We need to correlate data across the enterprise to get a full view of potential threats. By analyzing various log sources, we can uncover hidden patterns and identify threats. Our solution meets these requirements with specialized detection mechanisms tailored to SAP's unique vulnerabilities.
In this blog post, we'll help you get started by guiding you how you can test the Microsoft Sentinel solution for SAP , which rules to try out, what to focus on, and how to transition from a proof of value to production.
This guide assumes you have already setup your connection between Sentinel and SAP, if you have not done that, go through the steps described in our documentation to connect your SAP systems to Sentinel. If you need assistance verifying if your connector is correctly connected to Azure and verify its health, you can also check the video here .
Evaluation
To evaluate the SAP for Sentinel Solution successfully, you need to consider the different people that are involved in using SAP. On the one hand, SAP systems contain many confidential information and critical business processes. This means that the data from SAP systems are important to be monitored by security operations, but also by business owners who have an interest in either compliance or health of the SAP systems.
In the following sections we will describe the different components that are part of the SAP for Solution in the form of use cases such as “As a <role>, I want to achieve <goal>”.
Stakeholder management and gathering
Before we start, it’s important that we have the right stakeholders involved. Performing a proof of value with SAP systems requires preparation as these systems are usually critical to the business.
We can divide our stakeholders into four large groups:
- Business/Executive sponsors: this group needs to provide approval for the proof of value and provide approval and budgets to move into production after a successful proof of value.
- SAP team: this team needs to be involved for various reasons, one being that they need to actively participate during the onboarding phase and configure SAP systems. They also need to be involved during the proof of value to show value and make clear what additional security they get from the SAP for Sentinel solution.
- Cloud Infrastructure Team: if you are setting up the connector, you will need some infrastructure to be set up such as a virtual machine, key vaults, etc. At Ignite we also announced a agentless way of connecting your SAP environments. Our engineering team has written a blog post on this subject which you can find here. This team might be optional depending on the way you have connected your SAP environment.
- Security: this team is involved in installing the solution, configuring it and interpreting the detected threats.
All these four groups are important and should be involved. For example, performing a proof of value without having buy-in from executive sponsors will result in a dead-end where your efforts might not lead to any additional security or implementation if there is for example no budget allotted to procuring the solution.
Roles and prerequisites
For a list of the required roles and prerequisites that need to be set in place, please refer to this documentation page.
Success Criteria
This is a crucial step in your proof of value. Testing a solution without clearly defined success criteria will not yield any good results as you will not be able to conclude your proof of value and have a clear path to next steps.
You might struggle to define success criteria, we will provide a few examples of success criteria, you can take these as-is, however we do suggest you adjust them to your specific business context:
- Solution allows SAP logs to be ingested and parsed into central location
- Solution can monitor different layers of SAP infrastructure
- Demonstrate successful detection and alerting predefined use cases, ensuring expected alerts for specific security incidents.
- This criterion is ideally adjusted to a specific use case you are trying to detect
- Solution allows to monitor against compliance frameworks such as NIST or SOX
- This criterion can be adjusted to monitor against specific frameworks or your own internal ones.
- Solution allows to be compliant with the European NIS2 regulations by being able to detect and report on incidents within our SAP systems within 24-72 hours
- Solution allows to create dashboards to keep track of SAP related security trends
- Solution allows to respond to incidents in SAP systems and automate response in SAP systems
- Solution allows to finetune detection to fit specific business requirements
This list is by no means exhaustive, and we encourage you to look for specific criteria that are tailored to your business needs. This ensures that you can clearly articulate the need for a solution to monitor your SAP environment.
Watchlists
Watchlists in Microsoft Sentinel allow you to enrich data from a data source you provide with the events in your Microsoft Sentinel environment. For example, you might create a watchlist containing a list of high-value assets, terminated employees, or service accounts in your environment which would allow you to monitor unauthorized access to your SAP environment.
In normal scenarios you can create your own watchlists, and while you still could do that for your SAP environments, we can rely on the SAP solution for Sentinel which comes packed with a lot of pre-filled watchlists that in turn will help to ensure you haven’t forgotten any important assets to cover in detections.
These are also essential within the context of the SAP solution; they are can be used throughout the different components such as workbooks and analytics rules. Using watchlists also can help to ease the transition from proof of value to production as we will explain later.
Let's start with our first use-case: As a SOC analyst, I want to be able to monitor all the sensitive tables in our organization
This use case is not difficult to implement, but it demonstrates that protecting your SAP environment requires regular consultation with SAP business owners who are key stakeholders that need to be involved. So, before implementing this use case, make sure you ask your SAP business owners what tables are important for your enterprise.
Fortunately, we can use on of the built-in watchlists of the Microsoft Sentinel solution for SAP to accomplish this use case. For this, navigate to the watchlist section of Sentinel by opening your Sentinel instance and expanding the Configuration section and clicking on Watchlist. If you already see a lot of watchlists, you can filter the watchlists by typing SAP into the search bar and adding a filter for the Source to be set to content hub.
Scroll down and select the watchlist “SAP - Sensitive Tables”, afterwards click the update watchlist button which allows you to manually edit additional tables.
Notice how the list already is prepopulated by some of the native SAP tables that are sensitive.
Click on "New" and enter the table name that is not part of the prepopulated list of items and a description. Once you are satisfied with the changes, press save to finalize the changes. In the example below we are going to add a new table that contains HR payroll information.
Now, whenever we are building new analytics rules or using the built-in ones that reference our watchlist for sensitive tables, our HR table is automatically considered and will trigger the rule as well. For an overview of the available prebuilt watchlists in the SAP for Sentinel, please refer to the public documentation .
One watchlist that is provided by the Microsoft Sentinel solution for SAP is called "SAP – Systems". This watchlist contains an overview of your SAP systems, you should adjust these to add your production SAP IDs. This watchlist is also used throughout the analytics rules, we will cover these in the next section. We can use this watchlist to easily transition from a proof of value to production. During the proof of value we can add development or UAT SAP SIDs and mark their system role as production. This is much easier than having to adjust all the analytics rules to include Development or UAT systems.
As shown in the screenshot above, we can write analytics rules (or create dashboards) that refer to a watchlist that during the proof of value can refer to test and development systems. Once we are ready to switch to production, we can easily adjust our watchlists to point to the production systems rather than having to adjust all our rules and dashboards.
It is important to track these changes, once you switch to production, we need to make sure that these systems are assigned their proper system role. An easy way to do this is to use the "AdditionalData" field in the watchlist.
In this section, we covered how watchlists are used in the Microsoft Sentinel for SAP solution and how you can use them to monitor sensitive SAP tables. In the next section we will cover how workbooks can be used for monitoring both threats and compliance.
Workbooks
Once your SAP systems have been connected, the SAP for Sentinel solution comes with multiple workbooks out of the box that can be useful to monitor multiple aspects of your SAP Solution.
Workbooks can be used by different organizational roles to monitor and visualize different properties of connected SAP systems. While you can build your own workbooks from the ground up, the SAP for Sentinel solution comes with built-in ones which can be customized if needed. Which bring us to our first use case.
An important note is that the workbooks for SAP in Sentinel only work if there is at least one incident in your workspace, it does not have to be an SAP specific incident. So, if you are testing this solution in a new Sentinel instance with no data, make sure there is at least one incident in your workspace, you can trigger an incident on an unrelated data source or on the Heartbeat table.
This leads us to our second use-case: As an auditor, I want to confirm that our production SAP systems adhere to the SOX
The SOX compliance framework is a set of regulations and best practices to ensure the accuracy and reliability of financial reporting in public companies. To accomplish this, we can use the built-in SAP audit controls workbook. Once the SAP for Sentinel solution has been installed, you can use this workbook.
The compliance aspect of this workbook is tied to analytics rules that can be categorized into multiple frameworks. Analytics rules allow you to write queries that look at your SAP data and based on that create detection or metrics. The SAP solution for Sentinel comes with built-in analytics rules, it is also possible to create your own.
To access this workbook, open the Sentinel instance that is connected to your SAP environment by navigating to the Sentinel blade, afterwards expand the Threat Management section and select workbooks. If your workbook is already configured, you will find it under the section My Workbooks, if not, they will be in the Templates section where you can save them to your workbooks.
Opening the workbook from your My Workbook section then allows you to configure the workbook to your specific needs. There are two sections in the workbook, one is the filter section on top which for example allows you to filter for specific SAP systems e.g. production systems only or for a specific control framework e.g. SOX.
Given we are looking into the SOX framework and want to only look at our Production SAP systems, change the filters so it reflects the right system roles and control framework. Again, here watchlists become crucial, by appointing Production roles to our test SAP systems, we can monitor their compliance in this dashboard.
Below that section you can configure which rules are available for SAP systems (out of the box) and have not yet been enabled and you can select a rule to see how it is categorized with respect to compliance frameworks such as the SOX framework. For the SOX and NIST framework, the rules are already categorized for you.
Although we are interested in the SOX framework, notice that this section also allows you to categorize an analytics rule against your own organization’s framework under "MyOrg Control ID", we could for example use our internal policy code IAM-001 within the Access controls family. Don’t forget to save your changes to persist them after changing these values.
Once the rules have been adjusted to your needs, open the Monitor section of the workbook to see a visual representation of the rules that have been configured for SOX and incidents that have been triggered for those controls. Note that the data in the different widgets follow your selected filters on top.
An overview of the SOX compliancy dashboard is also demonstrated in this video []. The second use case is centered around the security aspects of your SAP systems.
Our second use-case, focuses around monitoring SAP systems for security threats: As a security analyst, I want to monitor for anomalous login attempts into our SAP systems.
We could tackle this use case in multiple ways, one of which could be the use of Analytics Rules, analytics rules will be covered in the next blog post. The other way to do this could be by utilizing the built-in workbook The SAP solution for Sentinel.
Open the "SAP -Security Audit log and Initial Access" workbook in the Workbooks section (you can find this under Threat Management in Sentinel). If you cannot find the workbook under my workbooks, look under the templates section of your workbooks and make sure the template is saved.
This report has a familiar setup as the previous report, a filter section and a section with data widgets. Once you have adjusted the filters to your specific needs, there are two sections which you can use to monitor your SAP systems.
The section “Logon analysis report” provides several visuals and tables. Scroll down until you find the “Logon Failures” section. In this section you will find a filter that allows you to filter anomalous logon attempts. Toggling this option allows you to look at these events. If during your proof of value you do not see anything in this section, that is normal as this workbook looks at data from the past 14 days and you might not have sufficient data yet in your Sentinel instance.
Scroll down and you can view the events that are considered anomalous, selecting one of these records will surface additional incidents related to the user that have triggered this anomalous failed logon attempt.
In this section, we covered how you can use the built-in workbooks to monitor your SAP environments for both compliance and threats. In the second part of this blog, we will cover how you can create analytics rule, do investigations and have a brief look at the SOAR capabilities.
Microsoft