Azure Sentinel - An Introduction
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.
Azure 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. Azure Sentinel natively incorporates proven foundation services from Azure, such as Log Analytics and Logic Apps. Also, Azure 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 Azure Sentinel.
Because Azure 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), Azure Sentinel needs to store the data that it will collect from the different data sources that you configure. Azure Sentinel will store this data in your preferred Log Analytics workspace. You can create a new workspace or use an existing one. However, it is recommended that you have a dedicated workspace for Azure Sentinel because alert rules and investigations do not work across workspaces. Keep in mind that you need at least contributor permission for the subscription in which the workspace resides.
To help you to better understand Azure Sentinel’s architecture, you need to first understand the different components of the solution. Figure 2-1 shows a diagram of the major Azure Sentinel components.
FIGURE 2-1 Major components of Azure Sentinel
The components shown in Figure 2-1 are presented in more detail below:
Dashboards: Built-in dashboards provide data visualization for your connected data sources, which enables you to deep dive into the events generated by those services. You will learn more about dashboards in Chapter 8, “Data visualization.”
Cases: A case is an aggregation of all the relevant evidence for a specific investigation. It can contain one or multiple alerts, which are based on the analytics that you define. You will learn more about cases in Chapter 4, “Case management.”
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.”
Notebooks: By integrating with Jupyter notebooks, Azure Sentinel extends the scope of what you can do with the data that was collected. 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 data connectors later in this chapter.
Playbooks: A Playbook is a collection of procedures that can be automatically executed upon an alert triggered by Azure Sentinel. Playbooks leverage Azure Logic Apps, which help you automate and orchestrate tasks/workflows. You will learn more about playbooks in Chapter 7, Automation 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.”
Community: The Azure Sentinel Community page is located on GitHub, and it contains Detections based on different types of data sources that you can leverage in order to create alerts and respond to threats in your environment. The Azure Sentinel Community page also contains hunting query samples, playbooks, and other artifacts. You will learn more about community in Chapter 3, “Analytics.”
Workspace: Essentially, a Log Analytics workspace is a container that includes data and configuration information. Azure Sentinel uses this container to store the data that you collect from the different data sources. You will learn more about workspace configuration later in this chapter.