Introduction to Microsoft Sentinel

Given the threat landscape presented in Chapter 1, there is a clear need for a system that can collect data from different sources, perform data correlation, and present this data in a single dashboard.

Microsoft Sentinel delivers intelligent security analytics and threat intelligence across the enterprise, providing a single solution for alert detection, threat visibility, proactive hunting, and threat response. Microsoft Sentinel natively incorporates proven foundation services from Azure, such as Log Analytics and Logic Apps. Also, Microsoft Sentinel enriches your investigation and detection with Artificial Intelligence (AI) in conjunction with Microsoft’s threat intelligence stream.

In this chapter, you will learn more about the architecture, design considerations, and initial configuration of Microsoft Sentinel.

Architecture

Because Microsoft Sentinel is part of Azure, the first prerequisite to deployment is to have an active Azure subscription. As with any other security information and event management (SIEM), Microsoft Sentinel needs to store the data that it will collect from the different data sources that you configure. Microsoft Sentinel will store this data in your preferred Log Analytics workspace. Depending on your business needs and technology requirements, you can create a new workspace or use an existing one.

To help you to better understand Microsoft Sentinel’s architecture, you must first understand the different components of the solution. Figure 2-1 shows a diagram of the major Microsoft Sentinel components.

The components shown in Figure 2-1 are presented in more detail below:

• Incidents This is a centralized place to manage your security incidents. An incident will have relevant data that you can use to understand its impact. You will learn more about incidents in Chapter 4, “Incident management.”

• Workbooks Built-in dashboards based on Azure Workbook that provide data visualization for your connected data sources. These Workbooks enable you to deep dive into the events generated by those services. You will learn more about Workbooks in Chapter 8, “Data visualization.”

• Hunting This is a powerful tool for investigators and security analysts who need to proactively look for security threats. The searching capability is powered by Kusto Query Language (KQL). You will learn more about hunting in Chapter 5, “Hunting.”

• Threat Intelligence Cyber threat intelligence (CTI) is an important capability leveraged by defenders to better understand the behavior of threat actors. This option allows Tier 2 and Tier 3 SOC analysts to curate their CTI within Microsoft Sentinel by tagging existing data. You will learn more about threat intelligence in Chapter 5, “Hunting.”

• MITRE ATT&CK This page contains active scheduled queries and near-real-time (NRT) rules coverage according to the MITRE ATT&CK framework. You will learn more about MITRE ATT&CK in Chapter 5, “Hunting.”

• Notebooks By integrating with Jupyter notebooks, Microsoft Sentinel extends the scope of what you can do with the collected data. The notebooks feature combines full programmability with a collection of libraries for machine learning, visualization, and data analysis. You will learn more about notebooks in Chapter 6, “Notebooks.”

• Data Connectors Built-in connectors are available to facilitate data ingestion from Microsoft and partner solutions. You will learn more about data connectors later in this chapter.

• Automations A collection of procedures that can be automatically executed when an alert is triggered by Microsoft Sentinel by leveraging Azure Logic Apps. This will help you to automate and orchestrate tasks/workflows. You will learn more about Playbooks in Chapter 7, “Automating response with Playbooks.”

• Analytics Analytics enable you to create custom alerts using Kusto Query Language (KQL). You will learn more about analytics in Chapter 3, “Analytics.”

• Watchlist This list allows you to correlate data from a data source you provide with the events in your Microsoft Sentinel environment. You will learn more about analytics in Chapter 3, “Analytics.”

• Settings This section has a variety of configuration options, including the Log Analytics workspace. Microsoft Sentinel uses this workspace to store the data you collect from the different data sources. You will learn more about workspace configuration later in this chapter.

Roles and permissions

Microsoft Sentinel uses Azure role-based access control (Azure RBAC), which provides a set of pre-defined privileges to perform certain actions in the environment. These built-in roles can be assigned to users, groups, and services in Azure.

Microsoft Sentinel also adds its own roles to Azure that were designed to perform specific actions based on a scenario. All Microsoft Sentinel built-in roles grant read access to the data in your Microsoft Sentinel workspace. The Microsoft Sentinel built-in roles are:

• Microsoft Sentinel Reader View data, incidents, Workbooks, and other Microsoft Sentinel resources.

• Microsoft Sentinel Responder In addition to the actions enabled by Microsoft Sentinel Reader, it can also manage incidents (assign, dismiss, and so on).

• Microsoft Sentinel Contributor In addition to the actions enabled by Microsoft Sentinel Responder, it can also create and edit Workbooks, analytics rules, and other Microsoft Sentinel resources.

• Microsoft Sentinel Automation Contributor Allows adding Playbooks to automation rules. This is not a role that is meant to be used by user accounts.

Because many other scenarios are enabled by Microsoft Sentinel, you may need to use additional roles according to a given need. Use Table 2-1 as a reference for these scenarios:

TABLE 2-1 Microsoft Sentinel scenarios

SCENARIO	CONSIDERATIONS
Automate responses to threats by leveraging Playbook capability	The Playbook capability in Microsoft Sentinel uses Logic Apps; in this case, you might need to add members of the team who are responsible for creating automated responses to the Logic App Contributor role.
Connecting Microsoft Sentinel to an external data source	Regardless of the data connector source, the users responsible for creating connectors will need to have write permissions on the Microsoft Sentinel workspace.
Temporary employee or guest assigning incidents	There might be scenarios where you will need to have temporary personnel in charge of triaging incidents and assigning them to the right team. In this case, in addition to assigning the user to the Microsoft Sentinel Responder role, you will also need to assign them to the Directory Reader role.
Manipulating Workbooks	You might have a user who works with data visualization and oversees creating and deleting Workbooks in Microsoft Sentinel. In this case, you can either add this user to the Microsoft Sentinel Contributor role or the Microsoft Sentinel role with less privilege and add them to the Azure Monitor Workbook Contributor role.

Be mindful of role aggregation scenarios in which a user has been assigned to a higher Azure role and a stricter Microsoft Sentinel role, which means the user will still be able to perform stricter operations. If you want to harden your user’s permissions to reflect their operation only in Microsoft Sentinel, you should carefully remove this user’s prior permissions, making sure you do not break any needed access to another resource. Figure 2-2 shows an example of how to organize your users according to their roles and Azure resources.

Workspace design considerations

Log Analytics workspace is the core foundation of Microsoft Sentinel. Later in this chapter, you will see that the first step to enabling Microsoft Sentinel is to select the workspace. A Log Analytics workspace provides a geographic location for data storage and data isolation by granting access rights to different users if necessary, as well as a set of configuration options.

One best practice is to always reduce the number of workspaces in use, but there are some specific scenarios that will lead you to have more than one workspace. The most common ones are listed below:

• Data sovereignty requirements and regulatory compliance standards that the company needs to abide by

• Data ownership requirements created by different company boundaries, such as subsidiaries and headquarters

• Companies that have multiple Azure Active Directory tenants

• Companies may need to use chargeback and have a more granular control over the Azure bill

• Companies that need more granular access control

• Companies that have different retention policies per subsidiary

• A company is a Managed Security Service Provider (MSSP)

Keep in mind that you will first need to deploy Azure Lighthouse to provide visibility across tenants for a multi-tenant scenario. If your design process leads you to conclude that you must have multiple workspaces, Microsoft Sentinel allows you to see incidents on multiple workspaces, which facilitates central incident monitoring and management across multiple workspaces. The advantage of this centralized view is that you can manage incidents directly and see incident details seamlessly in the context of the originating workspace.

Microsoft Sentinel also supports querying multiple workspaces. This is done in a centralized view and a single query, which allows you to search and correlate data from multiple workspaces in a single place and in one single query. The list below provides the other Microsoft Sentinel features that support this cross-workspace ability:

• Analytics rules

• Workbooks

• Hunting

The data connector is what will send data to the workspace and is another important consideration when designing your workspace architecture. Connectors that are based on diagnostics settings (such as Azure Firewall, Azure Storage, Azure Activity, or Azure Active Directory) cannot be connected to workspaces that are not located in the same tenant as the source workspace. For additional considerations related to multiple workspaces, check the decision tree in this article, http://aka.ms/SentinelLAWDecisionTree, and the sample templates at http://aka.ms/SentinelLAWTemplates.

While Microsoft Sentinel can be utilized for multiple regions, your design requirements might require you to adopt one workspace per region. This can happen for numerous reasons, including regulations and data separation by team. For this type of scenario, you need to consider that egress costs apply when the Log Analytics or Azure Monitor agent is required to collect logs (for example, a VM). You also need to consider the bandwidth costs, which vary depending on the following factors: source and destination region and collection method.

While there are scenarios that will require you to have multiple workspaces, you may also find scenarios where the same workspace will be shared by Microsoft Sentinel and Microsoft Defender for Cloud. For best practices on how to design your solution for this requirement, see http://aka.ms/LAWBPD4CSentinel.

Hardening considerations

To improve the security hygiene of your Microsoft Sentinel and its Azure environment, it is recommended that you use the security baseline provided by Azure Security Benchmark. This benchmark provides security recommendations for the following areas:

• Network security

• Identity management

• Privilege access

• Data protection

• Asset management

• Logging and threat detection

• Posture and vulnerability management

• Backup and recovery

Additional considerations

Before enabling Microsoft Sentinel, you should have a good understanding of which data sources you will use to connect with Microsoft Sentinel. If you are unsure, you can always start with the free data connectors, which are: Azure Activity Logs, Office 365 Audit Logs, including all SharePoint activity, Exchange admin activity, and Teams, Security alerts (including alerts from Microsoft Defender for Cloud, Microsoft 365 Defender, Microsoft Defender for Office 365, Microsoft Defender for Identity, Microsoft Defender for Endpoint), Microsoft Defender for Cloud and Microsoft Defender for Cloud Apps alerts.

Another important consideration during this design exercise is to identify if you will need to have a partner or custom connector. This will require you to configure Syslog and CEF connectors with the highest priority first.

Once you finish defining the use cases, data sources, and data size requirements, start planning your budget, considering cost implications for each planned scenario. Make sure to include in your budget the cost of data ingestion for both Microsoft Sentinel and Azure Log Analytics and any Playbooks that will be deployed.