Merge pull request #292402 from tarTech23/cmdelmain4

Cm delete from copied articles Main 4

Author: Jill Grant

articles/defender-for-iot/organizations/alerts.md

@@ -1,6 +1,6 @@
 ---
 title: Microsoft Defender for IoT alerts
-description: Learn about Microsoft Defender for IoT alerts across the Azure portal, OT network sensors, and on-premises management consoles.
+description: Learn about Microsoft Defender for IoT alerts across the Azure portal and OT network sensors.
 ms.date: 08/06/2023
 ms.topic: how-to
 ms.custom: enterprise-iot
@@ -22,15 +22,14 @@ Use the details shown on the **Alerts** page, or on an alert details page, to in
 
 ## Alert management options
 
-Defender for IoT alerts are available in the Azure portal, OT network sensor consoles, and the on-premises management console. With Enterprise IoT security, alerts are also available for Enterprise IoT devices detected by Defender for Endpoint, in Microsoft 365 Defender.
+Defender for IoT alerts are available in the Azure portal or OT network sensor consoles. With Enterprise IoT security, alerts are also available for Enterprise IoT devices detected by Defender for Endpoint, in Microsoft 365 Defender.
 
 While you can view alert details, investigate alert context, and triage and manage alert statuses from any of these locations, each location also offers extra alert actions. The following table describes the alerts supported for each location and the extra actions available from that location only:
 
 |Location  |Description   | Extra alert actions |
 |---------|---------|---------|
 |**Azure portal**     | Alerts from all cloud-connected OT sensors |    - View related MITRE ATT&CK tactics and techniques <br>- Use out-of-the-box workbooks for visibility into high priority alerts <br>- View alerts from Microsoft Sentinel and run deeper investigations with [Microsoft Sentinel playbooks and workbooks](concept-sentinel-integration.md).      |
 |**OT network sensor consoles**     |   Alerts generated by that OT sensor      |    - View the alert's source and destination in the **Device map** <br>- View related events on the **Event timeline**  <br>- Forward alerts directly to partner vendors  <br>- Create alert comments <br> - Create custom alert rules <br>- Unlearn alerts    |
-|**An on-premises management console**     |  Alerts generated by connected OT sensors          |  - Forward alerts directly to partner vendors <br> - Create alert exclusion rules      |
 |**Microsoft 365 Defender**     |  Alerts generated for Enterprise IoT devices detected by Microsoft Defender for Endpoint         |  - Manage alerts data together with other Microsoft 365 Defender data, including advanced hunting |
 
 > [!TIP]
@@ -55,21 +54,21 @@ Alert options also differ depending on your location and user role. For more inf
 Organizations where sensors are deployed between OT and IT networks deal with many alerts, related to both OT and IT traffic. The amount of alerts, some of which are irrelevant, can cause alert fatigue and affect overall performance. To address these challenges, Defender for IoT's detection policy steers its different [alert engines](alert-engine-messages.md#supported-alert-types) to focus on alerts with business impact and relevance to an OT network, and reduce low-value IT related alerts. For example, the **Unauthorized internet connectivity** alert is highly relevant in an OT network, but has relatively low value in an IT network.
 
 To focus the alerts triggered in these environments, all alert engines, except for the *Malware* engine, trigger alerts only if they detect a related OT subnet or protocol. 
-However, to maintain triggering of alerts that indicate critical scenarios: 
+However, to maintain triggering of alerts that indicate critical scenarios:
 
 - The *Malware* engine triggers malware alerts regardless of whether the alerts are related to OT or IT devices.
 - The other engines include exceptions for critical scenarios. For example, the *Operational* engine triggers alerts related to sensor traffic, regardless of whether the alert is related to OT or IT traffic.
 
 ## Managing OT alerts in a hybrid environment
 
-Users working in hybrid environments might be managing OT alerts in [Defender for IoT](https://portal.azure.com/#view/Microsoft_Azure_IoT_Defender/IoTDefenderDashboard/~/Getting_started) on the Azure portal, the OT sensor, and an on-premises management console.
+Users working in hybrid environments might be managing OT alerts in [Defender for IoT](https://portal.azure.com/#view/Microsoft_Azure_IoT_Defender/IoTDefenderDashboard/~/Getting_started) on the Azure portal or the OT sensor.
 
 > [!NOTE]
-> While the sensor console displays an alert's **Last detection** field in real-time, Defender for IoT in the Azure portal may take up to one hour to display the updated time. This explains a scenario where the last detection time in the sensor console isn't the same as the last detection time in the Azure portal. 
+> While the sensor console displays an alert's **Last detection** field in real-time, Defender for IoT in the Azure portal may take up to one hour to display the updated time. This explains a scenario where the last detection time in the sensor console isn't the same as the last detection time in the Azure portal.
 
-Alert statuses are otherwise fully synchronized between the Azure portal and the OT sensor, and between the sensor and the on-premises management console. This means that regardless of where you manage the alert in Defender for IoT, the alert is updated in other locations as well.
+Alert statuses are otherwise fully synchronized between the Azure portal and the OT sensor. This means that regardless of where you manage the alert in Defender for IoT, the alert is updated in other locations as well.
 
-Setting an alert status to **Closed** or **Muted** on a sensor or on-premises management console updates the alert status to **Closed** on the Azure portal. On the on-premises management console, the **Closed** alert status is called **Acknowledged**.
+Setting an alert status to **Closed** or **Muted** on a sensor updates the alert status to **Closed** on the Azure portal.
 
 > [!TIP]
 > If you're working with Microsoft Sentinel, we recommend that you configure the integration to also  [synchronize alert status](concept-sentinel-integration.md#defender-for-iot-alerts-in-microsoft-sentinel) with Microsoft Sentinel, and then manage alert statuses together with the related Microsoft Sentinel incidents.
@@ -87,7 +86,7 @@ For more information, see [Securing IoT devices in the enterprise](concept-enter
 
 New alerts are automatically closed if no identical traffic is detected 90 days after the initial detection. If identical traffic is detected within those first 90 days, the 90-day count is reset.
 
-In addition to the default behavior, you might want to help your SOC and OT management teams triage and remediate alerts faster. Sign into an OT sensor or an on-premises management console as an **Admin** user to use the following options:
+In addition to the default behavior, you might want to help your SOC and OT management teams triage and remediate alerts faster. Sign into an OT sensor as an **Admin** user to use the following options:
 
 - **Create custom alert rules**. OT sensors only.
 
@@ -107,42 +106,27 @@ In addition to the default behavior, you might want to help your SOC and OT mana
 
     For more information, see [Create alert comments on an OT sensor](how-to-accelerate-alert-incident-response.md#create-alert-comments-on-an-ot-sensor).
 
-- **Create alert exclusion rules**: On-premises management consoles only.
-
-    If you're working with an on-premises management console, define *alert exclusion rules* to ignore events across multiple sensors that meet specific criteria. For example, you might create an alert exclusion rule to ignore all events that would trigger irrelevant alerts during a specific maintenance window.
-
-    Alerts ignored by exclusion rules aren't shown on the Azure portal, sensor, or on-premises management console, or in the event logs.
-
-    For more information, see [Create alert exclusion rules on an on-premises management console](how-to-accelerate-alert-incident-response.md#create-alert-exclusion-rules-on-an-on-premises-management-console).
-
 - **Forward alert data to partner systems** to partner SIEMs, syslog servers, specified email addresses and more.
 
-    Supported from both OT sensors and on-premises management consoles. For more information, see [Forward alert information](how-to-forward-alert-information-to-partners.md).
+    Supported from the OT sensors, for more information, see [Forward alert information](how-to-forward-alert-information-to-partners.md).
 
 ## Alert statuses and triaging options
 
 Use the following alert statuses and triaging options to manage alerts across Defender for IoT.
 
 When triaging an alert, consider that some alerts might reflect valid network changes, such as an authorized device attempting to access a new resource on another device.
 
-While triaging options from the OT sensor and the on-premises management console are available for OT alerts only, options available on the Azure portal are available for both OT and Enterprise IoT alerts.
+While triaging options from the OT sensor are available for OT alerts only, options available on the Azure portal are available for both OT and Enterprise IoT alerts.
 
 Use the following table to learn more about each alert status and triage option.
 
-
 |Status / triage action  |Available on  |Description  |
 |---------|---------|---------|
-|**New**     |  - Azure portal <br><br>- OT network sensors <br><br>- On-premises management console       |   *New* alerts are alerts that haven't yet been triaged or investigated by the team. New traffic detected for the same devices doesn't generate a new alert, but is added to the existing alert. <br><br>On the on-premises management console, *New* alerts are called *Unacknowledged*.<br><br>**Note**: You might see multiple, *New* or *Unacknowledged* alerts with the same name. In such cases, each separate alert is triggered by separate traffic, on different sets of devices.  |
+|**New**     |  - Azure portal <br><br>- OT network sensors    |   *New* alerts are alerts that haven't yet been triaged or investigated by the team. New traffic detected for the same devices doesn't generate a new alert, but is added to the existing alert. <br><br>**Note**: You might see multiple, *New* alerts with the same name. In such cases, each separate alert is triggered by separate traffic, on different sets of devices.  |
 |**Active**     |    - Azure portal only     |   Set an alert to *Active* to indicate that an investigation is underway, but that the alert can't yet be closed or otherwise triaged. <br><br>This status has no effect elsewhere in Defender for IoT.      |
-|**Closed**     | - Azure portal <br><br>- OT network sensors <br><br>- On-premises management console        | Close an alert to indicate that it's fully investigated, and you want to be alerted again the next time the same traffic is detected.<br><br>Closing an alert adds it to the sensor event timeline.<br><br>On the on-premises management console, *New* alerts are called *Acknowledged*.   |
-|**Learn**     | - Azure portal <br><br>- OT network sensors <br><br>- On-premises management console <br><br>*Unlearning* an alert is available only on the OT sensor.       |   Learn an alert when you want to close it and add it as allowed traffic, so that you aren't alerted again the next time the same traffic is detected. <br><br>For example, when the sensor detects firmware version changes following standard maintenance procedures, or when a new, expected device is added to the network. <br><br>Learning an alert closes the alert and adds an item to the sensor event timeline. Detected traffic is included in data mining reports, but not when calculating other OT sensor reports. <br><br>Learning alerts is available for selected alerts only, mostly those triggered by *Policy* and *Anomaly* engine alerts. |
-|**Mute**     |  - OT network sensors <br><br>- On-premises management console      <br><br>*Unmuting* an alert is available only on the OT sensor.  |  Mute an alert when you want to close it and not see again for the same traffic, but without adding the alert allowed traffic. <br><br>For example, when the Operational engine triggers an alert indicating that the PLC Mode was changed on a device. The new mode might indicate that the PLC isn't secure, but after investigation, it's determined that the new mode is acceptable. <br><br>Muting an alert closes it, but doesn't add an item to the sensor event timeline. Detected traffic is included in data mining reports, but not when calculating data for other sensor reports. <br><br>Muting an alert is available for selected alerts only, mostly those triggered by the *Anomaly*, *Protocol Violation*, or *Operational* engines.  |
-
-> [!TIP]
-> If you know ahead of time which events are irrelevant for you, such as during a maintenance window, or if you don't want to track the event in the event timeline, create an alert exclusion rule on an on-premises management console instead.
->
-> For more information, see [Create alert exclusion rules on an on-premises management console](how-to-accelerate-alert-incident-response.md#create-alert-exclusion-rules-on-an-on-premises-management-console).
->
+|**Closed**     | - Azure portal <br><br>- OT network sensors       | Close an alert to indicate that it's fully investigated, and you want to be alerted again the next time the same traffic is detected.<br><br>Closing an alert adds it to the sensor event timeline.  |
+|**Learn**     | - Azure portal <br><br>- OT network sensors <br><br>*Unlearning* an alert is available only on the OT sensor.       |   Learn an alert when you want to close it and add it as allowed traffic, so that you aren't alerted again the next time the same traffic is detected. <br><br>For example, when the sensor detects firmware version changes following standard maintenance procedures, or when a new, expected device is added to the network. <br><br>Learning an alert closes the alert and adds an item to the sensor event timeline. Detected traffic is included in data mining reports, but not when calculating other OT sensor reports. <br><br>Learning alerts is available for selected alerts only, mostly those triggered by *Policy* and *Anomaly* engine alerts. |
+|**Mute**     |  - OT network sensors <br><br>*Unmuting* an alert is available only on the OT sensor.  |  Mute an alert when you want to close it and not see again for the same traffic, but without adding the alert allowed traffic. <br><br>For example, when the Operational engine triggers an alert indicating that the PLC Mode was changed on a device. The new mode might indicate that the PLC isn't secure, but after investigation, it's determined that the new mode is acceptable. <br><br>Muting an alert closes it, but doesn't add an item to the sensor event timeline. Detected traffic is included in data mining reports, but not when calculating data for other sensor reports. <br><br>Muting an alert is available for selected alerts only, mostly those triggered by the *Anomaly*, *Protocol Violation*, or *Operational* engines.  |
 
 ### Triage OT alerts during learning mode
 
@@ -161,6 +145,3 @@ Review alert types and messages to help you understand and plan remediation acti
 
 > [!div class="nextstepaction"]
 > [View and manage alerts on your OT sensor](how-to-view-alerts.md)
-
-> [!div class="nextstepaction"]
-> [View and manage alerts on the on-premises management console](legacy-central-management/how-to-work-with-alerts-on-premises-management-console.md)

articles/defender-for-iot/organizations/api/management-alert-apis.md

@@ -257,7 +257,7 @@ The maintenance windows that define with the `maintenanceWindow` API appear in t
 
 
 > [!IMPORTANT]
-> This API is supported for maintenance purposes only and for a limited time period, and is not meant to be used instead of [alert exclusion rules](../how-to-accelerate-alert-incident-response.md#create-alert-exclusion-rules-on-an-on-premises-management-console). Use this API for one-time, temporary maintenance operations only.
+> This API is supported for maintenance purposes only and for a limited time period, and is not meant to be used instead of [alert exclusion rules](../how-to-accelerate-alert-incident-response.md#create-alert-exclusion-rules-on-an-ot-sensor). Use this API for one-time, temporary maintenance operations only.
 
 **URI**: `/external/v1/maintenanceWindow`
 

articles/defender-for-iot/organizations/appliance-catalog/virtual-sensor-hyper-v-gen-1.md

@@ -76,7 +76,7 @@ This procedure describes how to create a virtual machine by using Hyper-V.
 
 1. Select **BIOS**, in **Startup order** move **IDE** to the top of the list, select **Apply** and then select **OK**.
 
-1. Connect the management console's ISO image to a virtual DVD drive.
+1. Connect the OT sensor's ISO image to a virtual DVD drive.
 
 1. Start the virtual machine.
 

articles/defender-for-iot/organizations/appliance-catalog/virtual-sensor-hyper-v.md

@@ -71,7 +71,7 @@ This procedure describes how to create a virtual machine by using Hyper-V.
 
 1. Select **Firmware**, in **Boot order** move **DVD Drive** to the top of the list, select **Apply** and then select **OK**.
 
-1. Connect the management console's ISO image to a virtual DVD drive.
+1. Connect the OT sensor's ISO image to a virtual DVD drive.
 
 1. Start the virtual machine.