Pre-deployment activities and prerequisites for deploying Microsoft Sentinel

This article introduces the pre-deployment activities and prerequisites for deploying Microsoft Sentinel.

Pre-deployment activities

Before deploying Microsoft Sentinel, we recommend taking the following steps to help focus your deployment on providing maximum value, as soon as possible.

1. Determine which data sources you need and the data size requirements to help you accurately project your deployment's budget and timeline.

   You might determine this information during your business use case review, or by evaluating a current SIEM that you already have in place. If you already have a SIEM in place, analyze your data to understand which data sources provide the most value and should be ingested into Microsoft Sentinel.

2. Design your Microsoft Sentinel workspace. Consider parameters such as:

   • Whether you'll use a single tenant or multiple tenants
   • Any compliance requirements you have for data collection and storage
   • How to control access to Microsoft Sentinel data

   For more information, see Workspace architecture best practices and Sample workspace designs.

3. After the business use cases, data sources, and data size requirements have been identified, start planning your budget, considering cost implications for each planned scenario.

   Make sure that your budget covers the cost of data ingestion for both Microsoft Sentinel and Azure Log Analytics, any playbooks that will be deployed, and so on.

   For more information, see:

   • Microsoft Sentinel costs and billing
   • Microsoft Sentinel pricing
   • Log Analytics pricing
   • Logic apps (playbooks) pricing
   • Integrating Azure Data Explorer for long-term log retention

4. Nominate an engineer or architect lead the deployment, based on requirements and timelines. This individual should lead the deployment and be the main point of contact on your team.

Azure tenant requirements

Before deploying Microsoft Sentinel, make sure that your Azure tenant has the following requirements:

• An Azure Active Directory license and tenant, or an individual account with a valid payment method, are required to access Azure and deploy resources.

• After you have a tenant, you must have an Azure subscription to track resource creation and billing.

• After you have a subscription, you'll need the relevant permissions to begin using your subscription. If you are using a new subscription, an admin or higher from the Azure AD tenant should be designated as the owner/contributor for the subscription.

  • To maintain the least privileged access available, assign roles at the level of the resource group.
  • For more control over permissions and access, set up custom roles. For more information, see Role-based access control.
  • For extra separation between users and security users, you might want to use resource-context or table-level RBAC.

  For more information about other roles and permissions supported for Microsoft Sentinel, see Permissions in Microsoft Sentinel.

• A Log Analytics workspace is required to house all of the data that Microsoft Sentinel will be ingesting and using for its detections, analytics, and other features. For more information, see Microsoft Sentinel workspace architecture best practices. Microsoft Sentinel doesn't support Log Analytics workspaces with a resource lock applied.

We recommend that when you set up your Microsoft Sentinel workspace, create a resource group that's dedicated to Microsoft Sentinel and the resources that Microsoft Sentinel uses, including the Log Analytics workspace, any playbooks, workbooks, and so on.

A dedicated resource group allows for permissions to be assigned once, at the resource group level, with permissions automatically applied to any relevant resources. Managing access via a resource group helps to ensure that you're using Microsoft Sentinel efficiently without potentially issuing improper permissions. Without a resource group for Microsoft Sentinel, where resources are scattered among multiple resource groups, a user or service principal may find themselves unable to perform a required action or view data due to insufficient permissions. To implement more access control to resources by tiers, use extra resource groups to house the resources that should be accessed only by those groups. Using multiple tiers of resource groups enables you to separate access between those tiers.

Next steps

On-board Microsoft Sentinel

Get visibility into alerts