Draft after review

Author: your name

articles/sentinel/detect-threats-built-in.md

@@ -2,10 +2,10 @@
 title: Detect threats with built-in analytics rules in Microsoft Sentinel | Microsoft Docs
 description: Learn how to use out-of-the-box threat detection rules, based on built-in templates, that notify you when something suspicious happens.
 author: yelevin
+ms.author: yelevin
 ms.topic: how-to
 ms.custom: devx-track-arm-template
-ms.date: 11/09/2021
-ms.author: yelevin
+ms.date: 05/28/2023
 ---
 
 # Detect threats out-of-the-box
@@ -67,11 +67,11 @@ This procedure describes how to use built-in analytics rules templates.
 
 ### Access permissions for analytics rules
 
-When you create an analytics rule, an access permission 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.
+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.
 
-There is one exception to this, however: when a rule is created to access workspaces in other tenants ***(and? or? and/or? subscriptions? -YL)***, such as what happens in the case of an MSSP, Microsoft Sentinel takes extra security measures to prevent unauthorized access to customer data ***(saying too much? -YL)***: for these kinds of rules, the credentials of the user that created the rule are used instead of an independent access token, so that when the user no longer has access to the other tenant, the rule will stop working ***(until xxxxx? happens? -YL)***.
+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.
 
-If you operate Microsoft Sentinel in a 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).
+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.
 
 ## Export rules to an ARM template
 

articles/sentinel/detect-threats-custom.md

@@ -5,7 +5,7 @@ author: yelevin
 ms.author: yelevin
 ms.topic: how-to
 ms.custom: devx-track-arm-template
-ms.date: 01/08/2023
+ms.date: 05/28/2023
 ---
 
 # 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
 - The target table (on which the rule query operated) has been deleted.
 - Microsoft Sentinel had been removed from the target workspace.
 - A function used by the rule query is no longer valid; it has been either modified or removed.
-- Permissions to one of the data sources of the rule query were changed ([see example below](#permanent-failure-due-to-lost-access-across-tenants)).
+- Permissions to one of the data sources of the rule query were changed ([see example below](#permanent-failure-due-to-lost-access-across-subscriptionstenants)).
 - One of the data sources of the rule query was deleted.
 
 **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,15 +319,15 @@ To re-enable the rule, you must address the issues in the query that cause it to
 
 Also see [Useful resources for working with Kusto Query Language in Microsoft Sentinel](kusto-resources.md) for further assistance.
 
-#### Permanent failure due to lost access across tenants
+#### Permanent failure due to lost access across subscriptions/tenants
 
-One particular example of when a permanent failure could occur due to a permissions change on a data source concerns the case of an MSSP or any other scenario where analytics rules query across tenants ***(and/or subscriptions? -YL)***.
+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.
 
-When you create an analytics rule, an access permission 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.
+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.
 
-There is one exception to this, however: when a rule is created to access workspaces in other tenants ***(and? or? and/or? subscriptions? -YL)***, such as what happens in the case of an MSSP, Microsoft Sentinel takes extra security measures to prevent unauthorized access to customer data ***(saying too much? -YL)***: for these kinds of rules, the credentials of the user that created the rule are used instead of an independent access token, so that when the user no longer has access to the other tenant, the rule will stop working ***(until xxxxx? happens? -YL)***.
+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.
 
-If you operate Microsoft Sentinel in a 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](#permanent-failure---rule-auto-disabled).
+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).
 
 ## Next steps