Merge branch 'main' into vivek-eod-update

vpattnai · web-flow · commit 1c4682f6bb5f · 2024-12-23T22:13:41.000+05:30
diff --git a/ATPDocs/deploy/capacity-planning.md b/ATPDocs/deploy/capacity-planning.md
@@ -11,7 +11,7 @@ This article describes how to use the Microsoft Defender for Identity sizing too
 
 While domain controller performance may not be affected if the server doesn't have required resources, the Defender for Identity sensor may not operate as expected. For more information, see [Microsoft Defender for Identity prerequisites](prerequisites.md).
 
-The sizing tool measures the capacity needed for domain controllers only. There is no need to run it against AD FS / AD CS servers, as the performance impact on AD FS / AD CS servers is extremely minimal to not existent.
+The sizing tool measures the capacity needed for domain controllers only. There is no need to run it against AD FS / AD CS / Entra Connect servers, as the performance impact on these servers is extremely minimal to not existent.
 
 > [!TIP]
 > By default, Defender for Identity supports up to 350 sensors. To install more sensors, contact Defender for Identity support.
@@ -47,17 +47,17 @@ Common results include:
 
 |Result  |Description  |
 |---------|---------|
-|**Yes**     |   The sensor is supported on your server      |
+|**Yes**     |   The sensor is supported on your server.      |
 |**Yes, but additional resources required** | The sensor is supported on your server as long you add any specified missing resources.  |
-|**Maybe**     |     The current **Busy Packets/Second** value may be significantly higher at that point than average. Check the timestamps to understand the processes running at that time, and whether you can limit the bandwidth for those processes under normal circumstances.     |
-|**Maybe, but additional resources required** |The sensor may be supported on your server as long you add any specified missing resources, or the **Busy packets / Second** may be above 60K |
-|**No**     |    The sensor isn't supported on your server. <br><br>The current **Busy Packets/Second** value may be significantly higher at that point than average. Check the timestamps to understand the processes running at that time, and whether you can limit the bandwidth for those processes under normal circumstances.    |
-|**Missing OS Data**     |  There was an issue reading the operating system data.  Make sure the connection to your server is able to query WMI remotely.   |
-|**Missing Traffic Data**     | There was an issue reading the traffic data.    Make sure the connection to your server is able to query performance counters remotely.        |
-|**Missing RAM data**     |    There was an issue reading the RAM data.  Make sure the connection to your server is able to query WMI remotely.       |
+|**Maybe**     |     The current **Busy Packets/sec** value may be significantly higher at that point than average. Check the timestamps to understand the processes running at that time, and whether you can limit the bandwidth for those processes under normal circumstances.     |
+|**Maybe, but additional resources required** |The sensor may be supported on your server as long you add any specified missing resources, or the **Busy packets/sec** may be above 60K. |
+|**No**     |    The sensor isn't supported on your server. <br><br>The current **Busy Packets/sec** value may be significantly higher at that point than average. Check the timestamps to understand the processes running at that time, and whether you can limit the bandwidth for those processes under normal circumstances.    |
+|**Missing OS Data**     |  There was an issue reading the operating system data. Make sure the connection to your server is able to query WMI remotely.   |
+|**Missing Traffic Data**     | There was an issue reading the traffic data. Make sure the connection to your server is able to query performance counters remotely.        |
+|**Missing RAM data**     |    There was an issue reading the RAM data. Make sure the connection to your server is able to query WMI remotely.       |
 |**Missing core data**     |   There was an issue reading the core data. Make sure the connection to your server is able to query WMI remotely.          |
 
-For example, the following image shows a set of results where the **Maybe** indicates that the **Busy Packets/Second** value is significantly higher at that point than average.  Note that the **Display DC Times as UTC/Local** is set to *Local DC Time*. This setting helps highlight the fact that the values were taken at around 3:30 AM.
+For example, the following image shows a set of results where the **Maybe** indicates that the **Busy Packets/sec** value is significantly higher at that point than average.  Note that the **Display DC Times as UTC/Local** is set to *Local DC Time*. This setting helps highlight the fact that the values were taken at around 3:30 AM.
 
 :::image type="content" source="../media/capacity-tool-maybe.png" alt-text="Screenshot of a capacity tool results showing Maybe values." lightbox="../media/capacity-tool-maybe.png":::
 
diff --git a/ATPDocs/troubleshooting-using-logs.md b/ATPDocs/troubleshooting-using-logs.md
@@ -9,7 +9,7 @@ ms.topic: how-to
 
 The Defender for Identity logs provide insight into what each component of Microsoft Defender for Identity sensor is doing at any given point in time.
 
-The Defender for Identity logs are located in a subfolder called **Logs** where Defender for Identity is installed; the default location is: **C:\Program Files\Azure Advanced Threat Protection Sensor\\**. In the default installation location, it can be found at: **C:\Program Files\Azure Advanced Threat Protection Sensor\version number\Logs**.
+The Defender for Identity logs are located in a subfolder called **Logs** where Defender for Identity is installed; the default location is: `C:\Program Files\Azure Advanced Threat Protection Sensor`. In the default installation location, it can be found at: `C:\Program Files\Azure Advanced Threat Protection Sensor\version number\Logs`.
 
 ## Defender for Identity sensor logs
 
@@ -28,7 +28,7 @@ The Defender for Identity sensor has the following logs:
 
 ## Defender for Identity deployment logs
 
-The Defender for Identity deployment logs are located in the temp directory of the user who installed the product. It will usually be found at **%USERPROFILE%\AppData\Local\Temp**. If it was deployed by a service, it might be found at **C:\Windows\Temp**.
+The Defender for Identity deployment logs are located in the temp directory of the user who installed the product. Typically, you can find these logs at `%USERPROFILE%\AppData\Local\Temp`. If the deployment was performed by a service, the logs might be located in `C:\Windows\Temp` or `C:\Windows\SystemTemp`, depending on your Windows version and patch level.
 
 Defender for Identity sensor deployment logs:
 
diff --git a/exposure-management/predefined-classification-rules-and-levels.md b/exposure-management/predefined-classification-rules-and-levels.md
@@ -113,4 +113,8 @@ Current asset types are:
 | Immutable Azure Storage                                      | Cloud resource | Medium                    | This rule applies to Azure storage accounts that have immutability support enabled. Immutability stores business data in a write once read many (WORM) state, and usually indicates that the storage account holds critical or sensitive data that must be protected from modification. |
 | Immutable and Locked Azure Storage                           | Cloud resource | High                      | This rule applies to Azure storage accounts that have immutability support enabled with a locked policy. Immutability stores business data in a write once read many (WORM). Data protection is increased with a locked policy to ensure that data can’t be deleted or its retention time shortened. These settings usually indicate that the storage account holds critical or sensitive data that must be protected from modification or deletion. Data might also need to align with compliance policies for data protection. |
 | Azure Virtual Machine with a Critical User Signed In         | Cloud resource | High                      | This rule applies to virtual machines protected by Defender for Endpoint, where a user with a high or very high criticality level is signed in. The signed-in user can be through a joined or registered device, an active browser session, or other means. |
-|  Key Vaults with Many Connected Identities              | Cloud resource | High                      | This rule identifies Key Vaults that can be accessed by a large number of identities, compared to other Key Vaults. This often indicates that the Key Vault is used by critical workloads, such as production services. |
+| Azure Key Vaults with Many Connected Identities              | Cloud resource | High                      | This rule identifies Key Vaults that can be accessed by a large number of identities, compared to other Key Vaults. This often indicates that the Key Vault is used by critical workloads, such as production services. |
+| Locked Azure Kubernetes Service cluster              | Cloud resource | Low                       | This is an Azure Kubernetes Service cluster that is safeguarded by a lock. Locks are used to protect assets from deletion and modifications. Usually, administrators use locks to safeguard critical cloud assets in their environment, and to protect them from accidental deletion and unauthorized modifications. |
+| Premium tier Azure Kubernetes Service cluster        | Cloud resource | High                      | This rule applies to Azure Kubernetes Service clusters with premium tier cluster management. Premium tiers are recommended for running production or mission-critical workloads that need high availability and reliability. |
+| Azure Kubernetes Service cluster with multiple nodes | Cloud resource | High                      | This rule applies to Azure Kubernetes Service clusters with a large number of nodes. This often indicates that the cluster is used for critical workloads, such as production workloads. |
+| Azure Arc Kubernetes cluster with multiple nodes                | Cloud Resource | High                      | This rule applies to Azure Arc Kubernetes clusters with a large number of nodes. This often indicates that the cluster is used for critical workloads, such as production workloads. |
diff --git a/exposure-management/whats-new.md b/exposure-management/whats-new.md
@@ -26,6 +26,19 @@ Learn more about MSEM by reading the blogs, [here](https://techcommunity.microso
 
 ## December 2024
 
+### New predefined classifications
+
+The following predefined classification rules were added to the critical assets list:
+
+| Classification                                       | Description                                                  |
+| :--------------------------------------------------- | :----------------------------------------------------------- |
+| Locked Azure Kubernetes Service cluster              | This rule applies to Azure Kubernetes Service clusters that are safeguarded by a lock. |
+| Premium tier Azure Kubernetes Service cluster        | This rule applies to premium tier Azure Kubernetes Service clusters. |
+| Azure Kubernetes Service cluster with multiple nodes | This rule applies to Azure Kubernetes Service clusters with multiple nodes. |
+| Azure Arc Kubernetes cluster with multiple nodes     | This rule applies to Azure Arc clusters with multiple nodes. |
+
+For more information, see, [Predefined classifications](predefined-classification-rules-and-levels.md)
+
 ### New documentation library for Microsoft's unified security operations platform
 
 Find centralized documentation about [Microsoft's unified SecOps platform in the Microsoft Defender portal](/unified-secops-platform/overview-unified-security). Microsoft's unified SecOps platform brings together the full capabilities of Microsoft Sentinel, Microsoft Defender XDR, Microsoft Security Exposure Management, and generative AI into the Defender portal. Learn about the features and functionality available with Microsoft's unified SecOps platform, then start to plan your deployment.
@@ -138,6 +151,8 @@ The following predefined classification rule was added to the critical assets li
 | ------------------------------------------------------------ | ------------------------------------------------------------ |
 | **Hyper-V Server**                                                 | This rule applies to devices identified as Hyper-V servers within a domain. These servers are essential for running and managing virtual machines within your infrastructure, serving as the core platform for their creation and management. |
 
+For more information, see, [Predefined classifications](predefined-classification-rules-and-levels.md)
+
 ### Enhanced visibility for scoped users
 
 This change now allows users who have been granted access to only some of the organization's devices to see the list of affected assets in metrics, recommendations, events, and initiative history within their specific scope.
