You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/sentinel/detect-threats-built-in.md
+18-10Lines changed: 18 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,17 +2,17 @@
2
2
title: Detect threats with built-in analytics rules in Microsoft Sentinel | Microsoft Docs
3
3
description: Learn how to use out-of-the-box threat detection rules, based on built-in templates, that notify you when something suspicious happens.
4
4
author: yelevin
5
+
ms.author: yelevin
5
6
ms.topic: how-to
6
7
ms.custom: devx-track-arm-template
7
-
ms.date: 11/09/2021
8
-
ms.author: yelevin
8
+
ms.date: 05/28/2023
9
9
---
10
10
11
11
# Detect threats out-of-the-box
12
12
13
-
After you've [connected your data sources](quickstart-onboard.md) to Microsoft Sentinel, you'll want to be notified when something suspicious occurs. That's why Microsoft Sentinel provides out-of-the-box, built-in templates to help you create threat detection rules.
13
+
After you've [set up Microsoft Sentinel to collect data from all over your organization](connect-data-sources.md), you'll need to dig through all that data to detect security threats to your environment. But don't worry—Microsoft Sentinel provides out-of-the-box, built-in templates to help you create threat detection rules to do all that work for you. These rules are known as **analytics rules**.
14
14
15
-
Rule templates were designed by Microsoft's team of security experts and analysts based on known threats, common attack vectors, and suspicious activity escalation chains. Rules created from these templates will automatically search across your environment for any activity that looks suspicious. Many of the templates can be customized to search for activities, or filter them out, according to your needs. The alerts generated by these rules will create incidents that you can assign and investigate in your environment.
15
+
Microsoft's team of security experts and analysts designed these analytics rule templates based on known threats, common attack vectors, and suspicious activity escalation chains. Rules created from these templates automatically search across your environment for any activity that looks suspicious. Many of the templates can be customized to search for activities, or filter them out, according to your needs. The alerts generated by these rules create incidents that you can assign and investigate in your environment.
16
16
17
17
This article helps you understand how to detect threats with Microsoft Sentinel:
18
18
@@ -22,7 +22,7 @@ This article helps you understand how to detect threats with Microsoft Sentinel:
22
22
23
23
## View built-in detections
24
24
25
-
To view all analytics rules and detections in Microsoft Sentinel, go to **Analytics** > **Rule templates**. This tab contains all the Microsoft Sentinel built-in rules, as well as the **Threat Intelligence** rule type.
25
+
To view all analytics rules and detections in Microsoft Sentinel, go to **Analytics** > **Rule templates**. This tab contains all the Microsoft Sentinel built-in rules, according to the types displayed in the following table.
26
26
27
27
:::image type="content" source="media/tutorial-detect-built-in/view-oob-detections.png" alt-text="Screenshot shows built-in detection rules to find threats with Microsoft Sentinel.":::
28
28
@@ -31,10 +31,10 @@ Built-in detections include:
31
31
| Rule type | Description |
32
32
| --------- | --------- |
33
33
|**Microsoft security**| Microsoft security templates automatically create Microsoft Sentinel incidents from the alerts generated in other Microsoft security solutions, in real time. You can use Microsoft security rules as a template to create new rules with similar logic. <br><br>For more information about security rules, see [Automatically create incidents from Microsoft security alerts](create-incidents-from-alerts.md). |
34
-
| <aname="fusion"></a>**Fusion**<br>(some detections in Preview) | Microsoft Sentinel uses the Fusion correlation engine, with its scalable machine learning algorithms, to detect advanced multistage attacks by correlating many low-fidelity alerts and events across multiple products into high-fidelity and actionable incidents. Fusion is enabled by default. Because the logic is hidden and therefore not customizable, you can only create one rule with this template. <br><br>The Fusion engine can also correlate alerts produced by [scheduled analytics rules](#scheduled) with those from other systems, producing high-fidelity incidents as a result. |
35
-
|**Machine learning (ML) behavioral analytics**| ML behavioral analytics templates are based on proprietary Microsoft machine learning algorithms, so you cannot see the internal logic of how they work and when they run. <br><br>Because the logic is hidden and therefore not customizable, you can only create one rule with each template of this type. |
36
-
| **Threat Intelligence** | Take advantage of threat intelligence produced by Microsoft to generate high fidelity alerts and incidents with the **Microsoft Threat Intelligence Analytics** rule. This unique rule is not customizable, but when enabled, will automatically match Common Event Format (CEF) logs, Syslog data or Windows DNS events with domain, IP and URL threat indicators from Microsoft Threat Intelligence. Certain indicators will contain additional context information through MDTI (**Microsoft Defender Threat Intelligence**).<br><br>For more information on how to enable this rule, see [Use matching analytics to detect threats](use-matching-analytics-to-detect-threats.md).<br>For more details on MDTI, see [What is Microsoft Defender Threat Intelligence](/../defender/threat-intelligence/what-is-microsoft-defender-threat-intelligence-defender-ti)
37
-
| <aname="anomaly"></a>**Anomaly**| Anomaly rule templates use machine learning to detect specific types of anomalous behavior. Each rule has its own unique parameters and thresholds, appropriate to the behavior being analyzed. <br><br>While the configurations of out-of-the-box rules can't be changed or fine-tuned, you can duplicate a rule and then change and fine-tune the duplicate. In such cases, run the duplicate in **Flighting** mode and the original concurrently in **Production** mode. Then compare results, and switch the duplicate to **Production** if and when its fine-tuning is to your liking. <br><br>For more information, see [Use customizable anomalies to detect threats in Microsoft Sentinel](soc-ml-anomalies.md) and [Work with anomaly detection analytics rules in Microsoft Sentinel](work-with-anomaly-rules.md). |
34
+
| <aname="fusion"></a>**Fusion**<br>(some detections in Preview) | Microsoft Sentinel uses the Fusion correlation engine, with its scalable machine learning algorithms, to detect advanced multistage attacks by correlating many low-fidelity alerts and events across multiple products into high-fidelity and actionable incidents. Fusion is enabled by default. Because the logic is hidden and therefore not customizable, you can only create one rule with this template. <br><br>The Fusion engine can also correlate alerts produced by [scheduled analytics rules](#scheduled) with alerts from other systems, producing high-fidelity incidents as a result. |
35
+
|**Machine learning (ML) behavioral analytics**| ML behavioral analytics templates are based on proprietary Microsoft machine learning algorithms, so you can't see the internal logic of how they work and when they run. <br><br>Because the logic is hidden and therefore not customizable, you can only create one rule with each template of this type. |
36
+
| **Threat Intelligence** | Take advantage of threat intelligence produced by Microsoft to generate high fidelity alerts and incidents with the **Microsoft Threat Intelligence Analytics** rule. This unique rule is not customizable, but when enabled, automatically matches Common Event Format (CEF) logs, Syslog data or Windows DNS events with domain, IP and URL threat indicators from Microsoft Threat Intelligence. Certain indicators contain additional context information through MDTI (**Microsoft Defender Threat Intelligence**).<br><br>For more information on how to enable this rule, see [Use matching analytics to detect threats](use-matching-analytics-to-detect-threats.md).<br>For more details on MDTI, see [What is Microsoft Defender Threat Intelligence](/../defender/threat-intelligence/what-is-microsoft-defender-threat-intelligence-defender-ti)
37
+
| <aname="anomaly"></a>**Anomaly**| Anomaly rule templates use machine learning to detect specific types of anomalous behavior. Each rule has its own unique parameters and thresholds, appropriate to the behavior being analyzed. <br><br>While the configurations of out-of-the-box rules can't be changed or fine-tuned, you can duplicate a rule, and then change and fine-tune the duplicate. In such cases, run the duplicate in **Flighting** mode and the original concurrently in **Production** mode. Then compare results, and switch the duplicate to **Production** if and when its fine-tuning is to your liking. <br><br>For more information, see [Use customizable anomalies to detect threats in Microsoft Sentinel](soc-ml-anomalies.md) and [Work with anomaly detection analytics rules in Microsoft Sentinel](work-with-anomaly-rules.md). |
38
38
| <a name="scheduled"></a>**Scheduled** | Scheduled analytics rules are based on built-in queries written by Microsoft security experts. You can see the query logic and make changes to it. You can use the scheduled rules template and customize the query logic and scheduling settings to create new rules. <br><br>Several new scheduled analytics rule templates produce alerts that are correlated by the Fusion engine with alerts from other systems to produce high-fidelity incidents. For more information, see [Advanced multistage attack detection](configure-fusion-rules.md#configure-scheduled-analytics-rules-for-fusion-detections).<br><br>**Tip**: Rule scheduling options include configuring the rule to run every specified number of minutes, hours, or days, with the clock starting when you enable the rule. <br><br>We recommend being mindful of when you enable a new or edited analytics rule to ensure that the rules will get the new stack of incidents in time. For example, you might want to run a rule in synch with when your SOC analysts begin their workday, and enable the rules then.|
39
39
| <aname="nrt"></a>**Near-real-time (NRT)**<br>(Preview) | NRT rules are limited set of scheduled rules, designed to run once every minute, in order to supply you with information as up-to-the-minute as possible. <br><br>They function mostly like scheduled rules and are configured similarly, with some limitations. For more information, see [Detect threats quickly with near-real-time (NRT) analytics rules in Microsoft Sentinel](near-real-time-rules.md). |
40
40
@@ -64,7 +64,15 @@ This procedure describes how to use built-in analytics rules templates.
64
64
> - You can also **push rules to Microsoft Sentinel via [API](/rest/api/securityinsights/) and [PowerShell](https://www.powershellgallery.com/packages/Az.SecurityInsights/0.1.0)**, although doing so requires additional effort.
65
65
>
66
66
> When using API or PowerShell, you must first export the rules to JSON before enabling the rules. API or PowerShell may be helpful when enabling rules in multiple instances of Microsoft Sentinel with identical settings in each instance.
67
-
>
67
+
68
+
### Access permissions for analytics rules
69
+
70
+
When you create an analytics rule, an access permissions token is applied to the rule and saved along with it. This token ensures that the rule can access the workspace that contains the data queried by the rule, and that this access will be maintained even if the rule's creator loses access to that workspace.
71
+
72
+
There is one exception to this, however: when a rule is created to access workspaces in other subscriptions or tenants, such as what happens in the case of an MSSP, Microsoft Sentinel takes extra security measures to prevent unauthorized access to customer data. For these kinds of rules, the credentials of the user that created the rule are applied to the rule instead of an independent access token, so that when the user no longer has access to the other subscription or tenant, the rule will stop working.
73
+
74
+
If you operate Microsoft Sentinel in a cross-subscription or cross-tenant scenario, be aware that if one of your analysts or engineers loses access to a particular workspace, any rules created by that user will stop working. You will get a health monitoring message regarding "insufficient access to resource", and the rule will be [auto-disabled](detect-threats-custom.md#issue-a-scheduled-rule-failed-to-execute-or-appears-with-auto-disabled-added-to-the-name) after having failed a certain number of times.
75
+
68
76
## Export rules to an ARM template
69
77
70
78
You can easily [export your rule to an Azure Resource Manager (ARM) template](import-export-analytics-rules.md) if you want to manage and deploy your rules as code. You can also import rules from template files in order to view and edit them in the user interface.
Copy file name to clipboardExpand all lines: articles/sentinel/detect-threats-custom.md
+12-2Lines changed: 12 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,7 +5,7 @@ author: yelevin
5
5
ms.author: yelevin
6
6
ms.topic: how-to
7
7
ms.custom: devx-track-arm-template
8
-
ms.date: 01/08/2023
8
+
ms.date: 05/28/2023
9
9
---
10
10
11
11
# Create custom analytics rules to detect threats
@@ -295,7 +295,7 @@ A permanent failure occurs due to a change in the conditions that allow the rule
295
295
- The target table (on which the rule query operated) has been deleted.
296
296
- Microsoft Sentinel had been removed from the target workspace.
297
297
- A function used by the rule query is no longer valid; it has been either modified or removed.
298
-
- Permissions to one of the data sources of the rule query were changed.
298
+
- Permissions to one of the data sources of the rule query were changed ([see example below](#permanent-failure-due-to-lost-access-across-subscriptionstenants)).
299
299
- One of the data sources of the rule query was deleted.
300
300
301
301
**In the event of a predetermined number of consecutive permanent failures, of the same type and on the same rule,** Microsoft Sentinel stops trying to execute the rule, and also takes the following steps:
@@ -319,6 +319,16 @@ To re-enable the rule, you must address the issues in the query that cause it to
319
319
320
320
Also see [Useful resources for working with Kusto Query Language in Microsoft Sentinel](kusto-resources.md) for further assistance.
321
321
322
+
#### Permanent failure due to lost access across subscriptions/tenants
323
+
324
+
One particular example of when a permanent failure could occur due to a permissions change on a data source ([see list above](#permanent-failure---rule-auto-disabled)) concerns the case of an MSSP—or any other scenario where analytics rules query across subscriptions or tenants.
325
+
326
+
When you create an analytics rule, an access permissions token is applied to the rule and saved along with it. This token ensures that the rule can access the workspace that contains the data queried by the rule, and that this access will be maintained even if the rule's creator loses access to that workspace.
327
+
328
+
There is one exception to this, however: when a rule is created to access workspaces in other subscriptions or tenants, such as what happens in the case of an MSSP, Microsoft Sentinel takes extra security measures to prevent unauthorized access to customer data. For these kinds of rules, the credentials of the user that created the rule are applied to the rule instead of an independent access token, so that when the user no longer has access to the other tenant, the rule will stop working.
329
+
330
+
If you operate Microsoft Sentinel in a cross-subscription or cross-tenant scenario, be aware that if one of your analysts or engineers loses access to a particular workspace, any rules created by that user will stop working. You will get a health monitoring message regarding "insufficient access to resource", and the rule will be [auto-disabled according to the procedure described above](#permanent-failure---rule-auto-disabled).
331
+
322
332
## Next steps
323
333
324
334
When using analytics rules to detect threats from Microsoft Sentinel, make sure that you enable all rules associated with your connected data sources in order to ensure full security coverage for your environment. The most efficient way to enable analytics rules is directly from the data connector page, which lists any related rules. For more information, see [Connect data sources](connect-data-sources.md).
0 commit comments