Sentinel POC – Architecture and Recommendations for MSSPs – Part 3

TL;DR – Common topics that come up when partners, specifically MSSPs, are testing Microsoft Sentinel features to evaluate its SIEM and SOAR capabilities. Part 3

This post is a part of series that covers various topics from the very basics, to ensure partners that may be familiar with other SIEMs, but that are not yet familiar with Azure can get all the information they need to be successful.

Agents and Forwarders

This topic always comes up during POCs. Most partners are familiar with the Log Analytics agent, also known as the OMS or MMA agent. However, the Log Analytics agent will be retired August 2024.  The new Azure Monitor Agent (AMA) is a consolidation of agents. It will replace the Log Analytics agent, as well as the Telegraf agent and the Diagnostics extension.  And best of all, AMA supports Data Collection Rules (DCRs), which supports filtering of data during ingestion time, not just for agents, but also for other types of ingested data.

The Azure Monitor Agent (AMA) and Data Collection Rules (DCRs) also allow you to send different types of data to different Log Analytic Workspaces, so if you have performance related data that is not useful for security purposes, then you don’t need to send it to the workspace that is associated with Sentinel. You can use XPath queries to filter out the events.

Partners have various options to install the AMA agent including, VM extensions, Azure Policy, or the Windows installer. My preferred option is using Azure Policy via Defender for Cloud (MDC). This works for any server on any cloud or on-prem. From the Settings & monitoring menu for the specific subscription, you can configure Defender for Servers to deploy the AMA and the specific workspace that will be used, which in the case of a Sentinel POC should be the Sentinel workspace. I prefer this option, because if I add any new servers, then they will automatically get the agent.

And with agent questions come forwarder questions during the POC. Yes, partners can configure a forwarder for CEF via AMA connector and you can forward syslog data to the Sentinel workspace using the AMA.  There is also a Content hub solution that include an
AMA migration tracker workbook.

Finally, if you are migrating from the Log Analytics agent to the AMA, there is also a script that removes the previous agent on all Azure VMs.

Sample Data

Another common question during POCs is how to generate sample data. There are various options partners can generate sample data on the workspaces acting as customer workspaces during the POC. I list some the options below:

Storage Options

This topic may not be of utmost importance during a POC, but some partners prefer to test their ability to take advantage of less expensive storage options during POCs, so I am including it here.

The default storage option for Sentinel ingestion is Analytics tables. The retention time of the tables can be adjusted for all tables within the workspace, or individually per table. Partners can also choose to use a different plan, which is called Basic and has significantly lower costs. Basic tables have an interactive retention of 8 days. There are some restrictions on Basic tables, such as not able to trigger alerts, as well as limited KQL commands. These tables are meant to be used with noisy logs, such as firewall logs or flow logs, that are normally used for debugging or troubleshooting purposes. Partners can also set a total retention for both Analytics and Basic tables, by configuring a total retention period, which will then move that data to Archive after the interactive retention period is over. The total retention is a maximum of 7 years.  Partners can also use the Search feature to query and rehydrate data from Archive as needed.

But wait, there’s more! All those options I mentioned are available within Log Analytics Workspace, but there are also external storage options, such as Blob Storage and Azure Data Explorer (ADX).  Partners can query Blob Storage using externaldata operator in KQL, which can also be used within an analytic rule. Additionally, ADX and Blob Storage can be combined, partners can create an external table in ADX that points to the whole container. 

Here is a summary of the various storage options currently available:


This feature is essential for MSSPs, so it has come up for every POC I’ve worked on. This feature allows partners to push content, such as analytic rules, hunting queries, workbooks, automation rules, playbooks, and parsers to customer workspaces. I covered this feature in detail in a blog post creatively named Sentinel Repositories. I also cover this topic in my Microsoft Sentinel Deep Dive session (1hr:34min mark). There is even a Sample Repository available for testing the Repositories feature. Future and existing automation features may also be combined with Repositories to allow MSSPs to manage the content that is published on their customers’ workspaces.


In the previous posts of this series, I covered how customers can delegate access to partners. I also covered the fact that artifacts can exist on both the MSSP workspace as well as the customer’s workspace. This makes it easier to keep some artifacts that are considered intellectual property within the MSSP workspace only. What I didn’t cover yet is how those artifacts can be used to access customers’ data. Here are the options:

  • Multiple workspace incident view – This is a view that is available as soon as your customers delegate access to you using Azure Lighthouse or if you have multiple workspaces within your tenant.
  • Cross workspace querying – Through the Logs blade you can query multiple workspaces using the workspace() expression and the union operator.
  • Cross workspace analytic rules – Partners can create analytic rules that include up to 20 workspaces in the query. Keep in mind most analytic rules will run on the customer’s workspace, but you do have this option for cases where a cross workspace analytic rule is needed.
  • Cross workspace workbooks – There are various Content hub solutions that include workbooks that can query data across workspaces and partners can also create their own. For example, the Incident Overview workbook and the Microsoft Sentinel Cost workbook that allow partners to view this data across their customers’ workspaces, as long as they have access. 
  • Cross workspace hunting – Similar to the querying through the Logs blade, partners can also save those queries to hunt later.
Other Resources

To close I want to include a list of links that we put together to help partners that are ramping up with Microsoft Sentinel. You can find that list of links here: That list is constantly being updated. It includes all sorts of information including training links to the various Ninja trainings, as well as additional links on more advanced subjects, such as UEBA, Fusion, SOAR automation, etc.

I hope this information is useful to all those MSSPs planning a Sentinel POC. As much as I tried to include everything I could think of, I am certain I forgot something. So, who knows maybe there will be a part 4? Until then, happy testing!

2 thoughts on “Sentinel POC – Architecture and Recommendations for MSSPs – Part 3

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: