Adoption considerations
Although Azure Sentinel is a cloud-based SIEM, there are some initial design considerations that you must be aware of. When planning Azure Sentinel adoption, use the following list of questions as the foundation for your initial assessment. This will help you to identify the areas from which you need to obtain more details before deploying Azure Sentinel:
Who has permission to deploy Azure Sentinel in my tenant?
Azure Sentinel uses a Role-Based Access Control model and enables you to set granular levels of permissions for different needs. There are three built-in roles available for Azure Sentinel, they are:
Azure Sentinel reader: enable the user to view incidents and data but cannot make changes.
Azure Sentinel responder: enable the user to read and perform some actions on incidents, such as assign to another user or change the incident’s severity.
Azure Sentinel contributor: enable the user to read, perform some actions on incidents and create or delete analytic rules.
To deploy Azure Sentinel on your tenant you need contributor permissions to the subscription in which the Azure Sentinel workspace resides.
Note: All Azure Sentinel built-in roles grant read access to the data in your Azure Sentinel workspace.
What permissions do the team members require to do their jobs using Azure Sentinel?
It is important to plan who will have access to the Azure Sentinel Dashboard. Depending on how the organization is structured, you may have different teams handling different areas of Azure Sentinel. For example, the SecOps team might be actively looking at new alerts, while the Threat Hunting Team might be performing proactive hunting. Again, leverage the RBAC model to assign granular permissions to different groups.
Consider the different scenarios, such as creating cases, closing cases, creating new analytics, using hunting queries, and writing playbooks.
Am I going to deploy Azure Sentinel in a single or multitenant scenario?
Azure Sentinel can be deployed in both scenarios. In a multitenant scenario, you can deploy Azure Sentinel on each tenant and use Azure Lighthouse to have a multitenant visualization of all tenants.
What are the data sources from which I want to ingest data?
That’s probably one of the most critical questions to ask in the beginning of the project. By having a list of data sources that you want to connect to Azure Sentinel, you can evaluate whether there are built-in connectors for the target system or whether you will need to use another method to connect. Here, you should also define whether you are going to ingest data only from cloud resources or if you also plan to collect data from on-premises resources.
Make sure to prioritize the data sources that are more important for your business. If you are just performing a proof-of-concept, ensure that you connect to the primary Microsoft services that are used by your organization and at least a couple of on-premises resources that will be utilized in production.
Do I already have Azure Security Center deployed and monitoring my servers?
If you already have Azure Security Center deployed and you are using the default workspace created by Security Center, you need to be aware that you can’t enable Azure Sentinel on this default workspace. However, if you are using a custom workspace in Azure Security Center, you can enable Azure Sentinel on this workspace. You will find more details about workspace design in “Enabling Azure Sentinel,” later in this chapter.
These are key questions that you must answer before you start configuring Azure Sentinel. Once you answer these questions—and others that may be very specific to your type of organization—you are ready to enable Azure Sentinel in your Azure subscription.
