Merge branch 'main' into docs-editor/microsoft-defender-endpoint-li-1740044101

Author: emmwalshh

defender-xdr/breadcrumb/toc.yml

@@ -12,6 +12,15 @@
   - name: Microsoft Defender XDR
     tocHref: /unified-secops-platform/
     topicHref: /defender-xdr/index
+  - name: Microsoft Defender XDR
+    tocHref: /defender-for-endpoint/
+    topicHref: /defender-xdr/index
+  - name: Microsoft Defender XDR
+    tocHref: /defender-office-365/
+    topicHref: /defender-xdr/index
+  - name: Microsoft Defender XDR
+    tocHref: /defender-cloud-apps/
+    topicHref: /defender-xdr/index  
 
 ## Azure override
 - name: 'Microsoft Defender'

defender-xdr/custom-detection-rules.md

@@ -58,7 +58,7 @@ To manage required permissions, a Global Administrator can:
 - Check RBAC settings for Microsoft Defender for Endpoint in [Microsoft Defender XDR](https://security.microsoft.com/) under **Settings** \> **Permissions** > **Roles**. Select the corresponding role to assign the **manage security settings** permission.
 
 > [!NOTE]
-> A user also needs to have the appropriate permissions for the devices in the [device scope](#5-set-the-rule-scope) of a custom detection rule that they are creating or editing before they can proceed. A user can't edit a custom detection rule that is scoped to run on all devices, if the same user does not have permissions for all devices. 
+> A user also needs to have the appropriate permissions for the devices in the [device scope](#5-set-the-rule-scope) of a custom detection rule that they're creating or editing before they can proceed. A user can't edit a custom detection rule that is scoped to run on all devices, if the same user doesn't have permissions for all devices. 
 
 ## Create a custom detection rule
 
@@ -95,14 +95,14 @@ To create a custom detection rule, the query must return the following columns:
       - `InitiatingProcessAccountObjectId`
 
 > [!NOTE]
-> Support for additional entities will be added as new tables are added to the [advanced hunting schema](advanced-hunting-schema-tables.md).
+> Support for more entities will be added as new tables are added to the [advanced hunting schema](advanced-hunting-schema-tables.md).
 
 Simple queries, such as those that don't use the `project` or `summarize` operator to customize or aggregate results, typically return these common columns.
 
 There are various ways to ensure more complex queries return these columns. For example, if you prefer to aggregate and count by entity under a column such as `DeviceId`, you can still return `Timestamp` and `ReportId` by getting it from the most recent event involving each unique `DeviceId`.
 
 > [!IMPORTANT]
-> Avoid filtering custom detections using the `Timestamp` column. The data used for custom detections is pre-filtered based on the detection frequency.
+> Avoid filtering custom detections using the `Timestamp` column. The data used for custom detections is prefiltered based on the detection frequency.
 
 The sample query below counts the number of unique devices (`DeviceId`) with antivirus detections and uses this count to find only the devices with more than five detections. To return the latest `Timestamp` and the corresponding `ReportId`, it uses the `summarize` operator with the `arg_max` function.
 
@@ -115,19 +115,19 @@ DeviceEvents
 ```
 
 > [!TIP]
-> For better query performance, set a time filter that matches your intended run frequency for the rule. Since the least frequent run is _every 24 hours_, filtering for the past day will cover all new data.
+> For better query performance, set a time filter that matches your intended run frequency for the rule. Since the least frequent run is _every 24 hours_, filtering for the past day covers all new data.
 
 ### 2. Create new rule and provide alert details
 
 With the query in the query editor, select **Create detection rule** and specify the following alert details:
 
 - **Detection name** - Name of the detection rule; should be unique
 - **Frequency** -Interval for running the query and taking action. [See more guidance in the rule frequency section](#rule-frequency)
-- **Alert title** - Title displayed with alerts triggered by the rule; should be unique and in plaintext. Strings are sanitized for security purposes so HTML, Makrdown, and other code won't work.
+- **Alert title** - Title displayed with alerts triggered by the rule; should be unique and in plaintext. Strings are sanitized for security purposes so HTML, Markdown, and other code won't work.
 - **Severity** - Potential risk of the component or activity identified by the rule.
 - **Category** - Threat component or activity identified by the rule.
 - **MITRE ATT&CK techniques** - One or more attack techniques identified by the rule as documented in the [MITRE ATT&CK framework](https://attack.mitre.org/). This section is hidden for certain alert categories, including malware, ransomware, suspicious activity, and unwanted software.
-- **Description** - More information about the component or activity identified by the rule. Strings are sanitized for security purposes so HTML, Makrdown, and other code won't work.
+- **Description** - More information about the component or activity identified by the rule. Strings are sanitized for security purposes so HTML, Markdown, and other code won't work.
 - **Recommended actions** - Additional actions that responders might take in response to an alert.
 
 #### Rule frequency
@@ -265,7 +265,7 @@ Only data from devices in the scope will be queried. Also, actions are taken onl
 After reviewing the rule, select **Create** to save it. The custom detection rule immediately runs. It runs again based on configured frequency to check for matches, generate alerts, and take response actions.
 
 > [!IMPORTANT]
-> Custom detections should be regularly reviewed for efficiency and effectiveness. To make sure you are creating detections that trigger true alerts, take time to review your existing custom detections by following the steps in [Manage existing custom detection rules](#manage-existing-custom-detection-rules).
+> Custom detections should be regularly reviewed for efficiency and effectiveness. To make sure you're creating detections that trigger true alerts, take time to review your existing custom detections by following the steps in [Manage existing custom detection rules](#manage-existing-custom-detection-rules).
 >
 > You maintain control over the broadness or specificity of your custom detections so any false alerts generated by custom detections might indicate a need to modify certain parameters of the rules.