Revision

Author: yelevin

articles/sentinel/log-plans.md

@@ -16,7 +16,7 @@ There are two competing aspects of log collection and retention that are critica
 
 These competing needs require a log management strategy that balances data accessibility, query performance, and storage costs.
 
-This article discusses categories of data storage and accessibility, and describes the tools Microsoft Sentinel gives you to build a log management and retention strategy.
+This article discusses categories of data and the retention states used to store and access your data. It also describes the log plans Microsoft Sentinel offers you to build a log management and retention strategy.
 
 > [!IMPORTANT]
 >
@@ -40,50 +40,73 @@ This category consists of logs that hold critical security value for your organi
 
 - **On-demand hunting**. Complex queries are run on this data to execute interactive, high-performance hunting for security threats.
 
-- **Correlation**. Data from these sources is correlated with data from other primary security data sources to detect threats and build attack stories
+- **Correlation**. Data from these sources is correlated with data from other primary security data sources to detect threats and build attack stories.
 
 - **Regular reporting**. Data from these sources is readily available for compiling into regular reports of the organization's security health, for both security and general decision makers.
 
 - **Behavior analytics**. Data from these sources is used to build baseline behavior profiles for your users and devices, enabling you to identify outlying behaviors as suspicious.
 
 Some examples of primary data sources include logs from antivirus or enterprise detection and response (EDR) systems, authentication logs, audit trails from cloud platforms, threat intelligence feeds, and alerts from external systems.
 
-Logs containing primary security data should be stored using the **Analytics logs** plan. This plan keeps data in an **interactive retention** state for **90 days** by default, extensible for up to two years. In this state, your data can be queried in unlimited fashion and with high performance.
-
-When the interactive retention period ends, data goes into a **long-term retention** state, remaining in its original table. Long-term retention is not defined by default, but you can define it to last up to 12 years. This state preserves your data for regulatory compliance or internal policy purposes. Data in this state can be queried in limited fashion and with much slower performance, but you can use a [**search job**](investigate-large-datasets.md) or [**restore**](restore.md) to pull out limited sets of data into interactive retention, where you can bring the full query capabilities to bear on it.
+Logs containing primary security data should be stored using the [**Analytics logs**](#analytics-logs-plan) plan. 
 
 ### Secondary security data
 
 This category encompasses logs that have limited individual security value but are essential for providing a comprehensive view of a security incident or breach. Typically, these logs are high-volume and can be verbose. The security operations use cases for this data include the following:
 
 - **Threat intelligence**. Primary data can be checked against lists of Indicators of Compromise (IoC) or Indicators of Attack (IoA) to quickly and easily detect threats.
 
-- **Ad-hoc hunting/investigations**.
+- **Ad-hoc hunting/investigations**. Data can be queried interactively for 30 days, facilitating crucial analysis for threat hunting and investigations.
 
-- **Large scale searches**.
+- **Large-scale searches**. Data can be ingested and searched in the background at petabyte scale, while being stored efficiently with minimal processing.
 
-- **Summarization via summary rules**. Summarize high-volume logs into aggregate information and store the results as primary security data. To learn more about summary rules, see [Aggregate Microsoft Sentinel data with summary rules](summary-rules.md).
+- **Summarization via summary rules**. Summarize high-volume logs into aggregate information and store the results as primary security data. To learn more about summary rules, see [Aggregate Microsoft Sentinel data with summary rules](../azure-monitor/logs/summary-rules.md).
 
 Some examples of secondary data log sources are cloud storage access logs, NetFlow logs, TLS/SSL certificate logs, firewall logs, proxy logs, and IoT logs. To learn more about how each of these sources bring value to security detections without being needed all the time, see [Log sources to use for Auxiliary Logs ingestion](basic-logs-use-cases.md).
 
-Logs containing secondary security data should be stored using the **Auxiliary logs** plan. This plan keeps data in an **interactive retention** state for **30 days**. In this state, your data can be queried with limited capabilities and with lower performance.
-
-When the interactive retention period ends, data goes into a **long-term retention** state, remaining in its original table. Long-term retention in the auxiliary logs plan is similar to long-term retention in the analytics logs plan, except that the only option to rehydrate data is with a [**search job**](investigate-large-datasets.md). [Restore](restore.md) is not supported for auxiliary logs.
+Logs containing secondary security data should be stored using the [**Auxiliary logs**](#auxiliary-logs-plan) plan. 
 
 ## Log management plans
 
-Microsoft Sentinel provides two different log storage plans, or types, to accommodate these categories of ingested data:
+Microsoft Sentinel provides two different log storage plans, or types, to accommodate these categories of ingested data.
+
+- [**Analytics logs** plan](#analytics-logs-plan)
+- [**Auxiliary logs** plan](#auxiliary-logs-plan)
+- A third plan, [**Basic logs**](#basic-logs-plan), is the predecessor of the auxiliary logs plan, and can be used as a substitute for it while the auxiliary logs plan remains in preview.
+
+**Each of these plans preserves data in two different states:**
+
+- The **interactive retention** state is the initial state into which the data is ingested. This state allows different levels of access to the data, depending on the plan, and costs for this state vary widely, depending on the plan.
+- The **long-term retention** state preserves older data in its original tables for up to 12 years, at **extremely low cost**, regardless of the plan.
+
+To learn more about retention states, see [Manage data retention in a Log Analytics workspace](../azure-monitor/logs/data-retention-configure.md).
+
+### Analytics logs plan
+
+**Analytics logs** are designed to store primary security data and make it easily and constantly accessible at high performance.
+
+This plan keeps data in the **interactive retention** state for **90 days** by default, extensible for up to two years. This interactive state, while expensive, allows you to query your data in unlimited fashion, with high performance, at no charge per query.
+
+When the interactive retention period ends, data goes into the **long-term retention** state, while remaining in its original table. The long-term retention period is not defined by default, but you can define it to last up to 12 years. This retention state preserves your data at extremely low cost, for regulatory compliance or internal policy purposes. You can access the data in this state only by using a [**search job**](investigate-large-datasets.md) or [**restore**](restore.md) to pull out limited sets of data into a new table in interactive retention, where you can bring the full query capabilities to bear on it.
+
+### Auxiliary logs plan
+
+**Auxiliary logs** are designed to store secondary security data at very low cost for long periods of time, while still allowing for limited accessibility.
+
+This plan keeps data in the **interactive retention** state for **30 days**. In the Auxiliary plan, this state has very low retention costs as compared to the Analytics plan. However, the query capabilities are limited: queries are charged per gigabyte of data scanned and are limited to a single table, and performance is significantly lower.
+
+When the interactive retention period ends, data goes into the **long-term retention** state, remaining in its original table. Long-term retention in the auxiliary logs plan is similar to long-term retention in the analytics logs plan, except that the only option to access the data is with a [**search job**](investigate-large-datasets.md). [Restore](restore.md) is not supported for the auxiliary logs plan.
 
-- **Analytics logs** are designed to store primary security data and make it easily and constantly accessible at high performance.
+The following diagram summarizes and compares these two log management plans.
 
-- **Auxiliary logs** are designed to store secondary security data at very low cost for long periods of time, while still allowing for limited accessibility.
+:::image type="content" border=false source="media/log-plans/analytics-auxiliary-log-plans.png" alt-text="Diagram of available log plans in Microsoft Sentinel.":::
 
-    There is a third plan, known as **Basic logs**, that provides similar functionality to auxiliary logs, but at a higher cost (though not as high as analytics logs). While the auxiliary logs plan remains in preview, basic logs can be an option for long-term, low-cost retention if your organization doesn't use preview features.
+### Basic logs plan
 
-:::image type="content" source="media/log-plans/analytics-auxiliary-log-plans.png" alt-text="Diagram of available log plans in Microsoft Sentinel.":::
+There is a third plan, known as **Basic logs**, that provides similar functionality to the auxiliary logs plan, but at a higher interactive retention cost (though not as high as the analytics logs plan). While the auxiliary logs plan remains in preview, basic logs can be an option for long-term, low-cost retention if your organization doesn't use preview features. To learn more about the basic logs plan, see [Table plans](../azure-monitor/logs/data-platform-logs.md#table-plans) in the Azure Monitor documentation.
 
-## Next steps
+## Related content
 
-- For a more in-depth comparison of log data plans, and more general information about log types, see [Select a table plan based on data usage in a Log Analytics workspace](../azure-monitor/logs/logs-table-plans.md).
+- For a more in-depth comparison of log data plans, and more general information about log types, see [Azure Monitor Logs overview | Table plans](../azure-monitor/logs/data-platform-logs.md#table-plans).
 
-- To understand more about retention periods—which exist across plans—see [Data retention and archive in Azure Monitor Logs](../azure-monitor/logs/data-retention-archive.md).
+- To understand more about retention periods—which exist across plans—see [Manage data retention in a Log Analytics workspace](../azure-monitor/logs/data-retention-configure.md).

articles/sentinel/whats-new.md

@@ -38,6 +38,8 @@ The new **Auxiliary logs** retention plan for Log Analytics tables allows you to
 
 To learn more about Auxiliary logs and compare with Analytics logs, see [Log retention plans in Microsoft Sentinel](log-plans.md).
 
+For more in-depth information about the different log management plans, see [**Table plans**](../azure-monitor/logs/data-platform-logs.md#table-plans) in the [Azure Monitor Logs overview](../azure-monitor/logs/data-platform-logs.md) article from the Azure Monitor documentation.
+
 ## June 2024
 
 - [Codeless Connector Platform now generally available](#codeless-connector-platform-now-generally-available)