Microsoft Sentinel

What it is

Microsoft Sentinel is a cloud native security tool for security operations teams. It is a SIEM and a SOAR.

• SIEM, security information and event management, collects security data from across the organisation, looks for threats in it, and raises alerts.
• SOAR, security orchestration, automation and response, automates how those alerts are handled, so common tasks run without a person.

Sentinel runs in the cloud, so there is no server to build, and it scales as the amount of data grows.

How it works

Collect

Sentinel gathers data using data connectors. There are connectors for Microsoft services such as Microsoft Entra ID, Microsoft 365 and Defender products, for Azure resources, and for third party systems such as firewalls, other clouds and other security tools. The data is stored in a Log Analytics workspace, and you query it with Kusto Query Language (KQL).

Detect

Analytics rules run queries over the data on a schedule or in near real time. When a rule's query finds a match, it generates an alert. Sentinel comes with many built in rule templates, and you can write your own. It can also use machine learning and user behaviour analytics to find unusual activity.

Related alerts are grouped into an incident, so an analyst sees one case for an attack instead of a flood of separate alerts.

Investigate

Analysts open an incident to see the alerts, the entities involved, such as accounts, hosts and addresses, and a timeline. They can hunt for threats proactively by running queries over the data before any alert fires. Workbooks are dashboards that visualise the data, for example sign in activity by location.

Respond

Automation rules and playbooks handle response. A playbook is a set of steps built on Azure Logic Apps, for example: when a high severity incident appears, post a message to a team channel, add the suspicious address to a block list and open a ticket. Automation reduces the load on analysts and speeds up the reaction.

Sentinel compared with other products

A worked scenario

A company sends sign in logs from Microsoft Entra ID, firewall logs and alerts from Defender for Endpoint into Sentinel. An analytics rule notices that one account signed in from two countries within ten minutes and raises an alert. Sentinel groups this with a related malware alert from a laptop, and creates one incident. The analyst investigates the timeline, then a playbook disables the account and notifies the security team. Later the team hunts across the data for the same pattern in other accounts.

Setting up Sentinel in steps

1. Create or choose a Log Analytics workspace.
2. Add Microsoft Sentinel to the workspace.
3. Connect data sources with data connectors.
4. Turn on analytics rules from the built in templates.
5. Build or adopt playbooks and automation rules for the common responses.

Sentinel is billed mainly for the amount of data ingested and stored, so teams choose carefully which logs are worth collecting.

A simple query

Analysts search the data with Kusto Query Language. This query counts failed sign ins by user.

SigninLogs
| where ResultType != 0
| summarize FailedSignIns = count() by UserPrincipalName
| order by FailedSignIns desc

A rule built on a query like this one could raise an alert when one account has an unusually high number of failures, which suggests a password guessing attack.

More features

• User and entity behaviour analytics learns what is normal for each account and device, and flags unusual activity.
• Threat intelligence lets Sentinel compare your data with lists of known malicious addresses and domains.
• Content hub offers ready made solutions, with connectors, rules and workbooks for particular products.

Sentinel and the Defender products

Alerts from the Defender products can flow into Sentinel, and Sentinel can add data from sources outside Microsoft. Defender XDR focuses on Microsoft's own products. Sentinel is the broader place to combine everything.