New Microsoft Sentinel install? Keep these three points in mind. – HELM OVERRIDE

Throughout the past year, I have collaborated with numerous customers who were new to Microsoft Sentinel. In this post, I will share three key points that all new Sentinel users should be aware of. These points are per Sentinel installation and relevant even if you have a complex, multi-workspace architecture.

#1 Use a brand new Log Analytics workspace

Sentinel uses Azure Monitor Logs as its datastore. Think of a Log Analytics workspace as a container that provides the tooling to query the tables in the datastore and manage the configuration. Sentinel is an application add-on to Log Analytics (behind the scenes, Sentinel is the Security Insights application).

Unless you’re brand new to Azure cloud, you might already have a Log Analytics workspace (or more than one). It may be tempting to install Sentinel on any available Log Analytics workspace but resist the temptation. I highly recommend installing Sentinel onto a new Log Analytics workspace. Ideally, spin up a new resource group as well.

Why? For these main reasons:

To establish a security operations logging workspace that will not be mixed in with existing logs that are not useful for threat detection (using a shared workspace has operational and billing implications)
To set up a security specific naming context so it’s clear what the resource group, workspace, and objects within it are for
Helps you later with Azure cost management & billing, the resource group can be used to set scope when establishing budget and setting up spending alerts
For making the best use of role based access controls for security operations staff (RBAC)

One additional point: If you use Microsoft Defender for Cloud, it is perfectly acceptable and encouraged to share a Log Analytics workspace between the two (but not Defender for Cloud’s default workspace).

#2 Create and name your resources effectively

When you install Sentinel you need to decide on a handful of simple but critical inputs. It’s important to know that you cannot change any of these later. Choose carefully. It takes only a few seconds to set this up but you’ll be stuck with it for a long time, and workspace moves are not supported. Here’s what you need to have planned ahead of time:

The Azure subscription
Name and create the Log Analytics workspace (hint: it should refer to Sentinel or SecOps in some way)
The resource group
The region
Finally, Sentinel will be added to the prepared workspace

This Sentinel lab training module will show you installation steps: https://github.com/Azure/Azure-Sentinel/blob/master/Solutions/Training/Azure-Sentinel-Training-Lab/Modules/Module-1-Setting-up-the-environment.md

#3 Change the workspace retention setting

All Log Analytics workspaces have a data retention setting. This setting establishes how long your data will be in the interactive or hot tier, which is the default for all data as it arrives and is written to the tables. The interactive tier is what you query with KQL and use for monitoring and reporting.

The default retention setting is 30 days. However, as a Sentinel customer you have the added benefit of 90 days retention included in the cost of your data ingestion. Always check this setting and change it right away to 90 days. I’ll talk more about retention settings in a future post – you can set to a maximum of 730 days (2 years) – but you’ll be charged per GB for retention beyond 90 days.

In the Sentinel UI, go straight to the bottom and click Settings, then go up to the top and click Workspace settings. This exits Sentinel and brings you to the Log Analytics workspace. Find the Usage and estimated costs menu blade, and then click Data Retention. Change the slider to 90 days, hit OK and you’re done. All tables will inherit this setting. (Individual tables can have the retention setting changed later.)