Updates

Author: jpipkin1

blog-cse/2025-04-15-application.md

@@ -12,6 +12,6 @@ import useBaseUrl from '@docusaurus/useBaseUrl';
 
 ### New method for building baselines
 
-We're happy to announce that now when you create or update a first seen or outlier rule, the baseline starts building immediately using data already in the system. Now you don't have to wait days for a baseline learning period to end before a baseline is built and ready to use. Now baselines are typically generated in minutes, allow you to get value quickly from your first seen and outlier rules.
+We're happy to announce that now when you create or update a first seen or outlier rule, the baseline starts building immediately using data already in the system. Now you don't have to wait days for a baseline learning period to end before a baseline is built and ready to use. Typically, the baseline is done in minutes, allowing you to get value quickly from your first seen and outlier rules.
 
 To learn more, see our information about baselines for [first seen rules](/docs/cse/rules/write-outlier-rule/#baselines-for-outlier-rules) and [outlier rules](/docs/cse/rules/write-outlier-rule/#baselines-for-outlier-rules).

docs/cse/rules/rules-status.md

@@ -58,15 +58,15 @@ Following are some situations when a rule can be become degraded:
 
 ### Troubleshoot baseline problems
 
-Sometimes there may be a problem creating a baseline for a [first seen rule](/docs/cse/rules/write-first-seen-rule/#baselines-for-first-seen-rules) or [outlier rule](/docs/cse/rules/write-outlier-rule/#baselines-for-outlier-rules). In these cases, the rule might enter a Degraded, Failed, or Pending Baseline state. Clicking the information button <img src={useBaseUrl('img/cse/rule-status-information-button.png')} alt="Rule status information button" width="20"/> on the status label may provide enough information to resolve the problem. But if not, you can do additional troubleshooting:
+Sometimes there may be a problem creating a baseline for a [first seen rule](/docs/cse/rules/write-first-seen-rule/#baselines-for-first-seen-rules) or [outlier rule](/docs/cse/rules/write-outlier-rule/#baselines-for-outlier-rules). In these cases, the rule might enter a Degraded, Failed, or Pending Baseline state. Clicking the information button <img src={useBaseUrl('img/cse/rule-status-information-button.png')} alt="Rule status information button" width="20"/> on the status label in most cases will provide enough information to resolve the problem. But if not, you can do additional troubleshooting:
 *  Check the [Sumo Logic status](https://status.sumologic.com/) page to see if there’s an outage in your deployment. If the system is down, it cannot generate the baseline.
-* If the rule has a Degraded status because it failed to parse, fix the rule so that it parses correctly. A baseline cannot be built if the rule does not successfully parse. One thing you can do is ensure the matching expression for the rule is using the compatible [core platform literals](/docs/cse/rules/cse-rules-syntax/#sumo-logic-core-platform-literals-supported-in-cloud-siem).
+* If the rule has a Degraded status because it failed to parse, fix the rule so that it parses correctly. A baseline cannot be built if the rule does not successfully parse. One thing you can do is ensure that a matching expression for the rule parses correctly is to use the compatible [core platform literals](/docs/cse/rules/cse-rules-syntax/#sumo-logic-core-platform-literals-supported-in-cloud-siem).
 * If the rule has a Failed status, clicking the information button might show that the amount of data requested is too large to return (see [Rule limits](#rule-limits)). In this case, create a more filtered baseline focusing on the exact activity you want to capture.
 * If the rule has a persistent Pending Baseline status, there might not be enough data in the system to build the baseline:
    *  Check the ingest configuration of your Cloud SIEM data sources and confirm the appropriate records are being added to the system.
    * The matching expression may not be using the right fields. Cloud SIEM records are normalized to a defined [schema](/docs/cse/schema/schema-attributes/). The matching expression and all other fields should use that schema and not the raw log field names.
-   * There may not be enough activity to build a baseline. In these cases, there are not enough data elements to build an accurate baseline. Expand the baseline learning period to gather more activity.
-   * Make sure that the Sumo Logic system has been active and ingesting data for the full baseline learning period. For example, if the rule has a default baseline learning period of 30 days, but the user who created the rule has only been using Sumo Logic for a few days, then the rule will remain in the Pending Baseline state until 30 days have passed. To resolve the issue, change the baseline learning period window.
+   * There may not be enough activity to build a baseline. Expand the baseline learning period to gather more activity.
+   * Make sure that the Sumo Logic system has been active and ingesting data for the full baseline learning period. For example, if the rule has a default baseline learning period of 30 days, but your company only started using Sumo Logic a few days ago, then the rule will remain in the Pending Baseline state until 30 days have passed. To resolve the issue, change the baseline learning period window.
 
 
 

docs/cse/rules/write-first-seen-rule.md

@@ -61,16 +61,16 @@ Watch this micro lesson to learn more about first seen rules.
 
 ## Baselines for first seen rules
 
-A first seen rule is different from other Cloud SIEM rule types in that you don’t define the criteria for firing a signal. Instead, the rule expression in a first seen rule is simply a filter condition that defines what incoming records the rule will apply to. For each first seen rule, Cloud SIEM automatically creates a baseline model of normal behavior for a defined learning period (by default for the last 30 days) evidenced by records that match the Rule Expression. Once the baseline is created, when an incoming record includes matching activity not seen during the baseline learning period, the rule creates a signal.
+A first seen rule is different from other Cloud SIEM rule types in that you don’t define the criteria for firing a signal. Instead, the rule expression in a first seen rule is simply a filter condition that defines what incoming records the rule will apply to. For each first seen rule, Cloud SIEM automatically creates a baseline model of normal behavior for a defined learning period (by default for the last 30 days) evidenced by records that match the Rule Expression. As soon as you save or update a first seen rule, the baseline is built using existing data collected. If data exists in the system to build the baseline, baseline creation typically takes only minutes to complete.
 
-For example, for the “First time a user logged in from a new geographic location” use case, Cloud SIEM will build a baseline model of all the geolocations from where a logon event is seen for the entity (user). Once the baseline is created, Cloud SIEM will create a signal for every new geolocation detected and incrementally add to the baseline.
+Once the baseline is created, when an incoming record includes matching activity not seen during the baseline learning period, the rule creates a signal. 
 
-As soon as you save or update a first seen rule, the baseline is built using existing data collected. So if your baseline learning period is for the last 30 days (the default), the system uses data from the previous 30 days to build the baseline. If data exists in the system to build the baseline, baseline creation typically takes only minutes to complete. 
+For example, for the “First time a user logged in from a new geographic location” use case, Cloud SIEM will build a baseline model of all the geolocations from where a logon event is seen for the entity (user). Once the baseline is created, Cloud SIEM will create a signal for every new geolocation detected and incrementally add to the baseline.
 
 :::tip
 Sumo Logic ensures that rule processing does not impact the reliability of production environments through the implementation of "circuit breakers." If a rule matches too many records in too short a period of time, the circuit breaker will trip and the rule will move to a degraded state, and first seen rules are no exception.
 
-On the rule detail page, if you hover over the degraded message, you will usually see more details about what tripped the circuit breaker and how to resolve the problem. Generally speaking, a rule that is degraded probably needs to be tuned for your specific environment.
+On the rule detail page, if you view the degraded message, you will usually see more details about what tripped the circuit breaker and how to resolve the problem. Generally speaking, a rule that is degraded probably needs to be tuned for your specific environment.
 
 For more information, see [Troubleshoot baseline problems](/docs/cse/rules/rules-status/#troubleshoot-baseline-problems).
 :::
@@ -152,7 +152,7 @@ with **has a new value for the field(s)** set to `srcDeviceIP_countryName`
 
 ### With a global baseline
 
-With a global baseline, and the default baseline learning period of the last 30 days, the rule creates a baseline of all geolocations that users logged in from for the previous 30 days. If a new geolocation is detected, a signal will be created. Then, if a new hire (that wasn’t part of the 30 day baseline) logs in from any geolocation, a signal
+With a global baseline, and the default baseline learning period of the last 30 days, the rule creates a baseline of all geolocations that users logged in from for the last 30 days. If a new geolocation is detected, a signal will be created. Then, if a new hire (that wasn’t part of the 30 day baseline) logs in from any geolocation, a signal
 will be created. As a global baseline, the 30 day baseline is shared across all entities.
 
 ### With per-entity baselines

docs/cse/rules/write-outlier-rule.md

@@ -66,7 +66,7 @@ Watch this micro lesson to learn more about outlier rules.
 
 When you create the rule, you can set the amount of time Cloud SIEM analyzes data to create a baseline model of behavior, with the default period being for the last 30 days. You can set the rule to build data hourly or daily, depending on how frequently you believe events of interest will occur, and how much data you want to gather. Data for the baseline is retained by default for 90 days. In the rule, you set the model sensitivity threshold to calculate outlier activity based on the number of standard deviations from the mean (z‑score). 
 
-As soon as you save or update an outlier rule, the baseline is built using existing data collected. So if your baseline learning period is for the last 30 days (the default), the system uses data from the previous 30 days to build the baseline. If data exists in the system to build the baseline, baseline creation typically takes only minutes to complete.
+As soon as you save or update an outlier rule, the baseline is built using existing data collected. So if your baseline learning period is for the last 30 days (the default), the system uses data from the last 30 days to build the baseline. If data exists in the system to build the baseline, baseline creation typically takes only minutes to complete.
 
 Once the baseline is created, Cloud SIEM tracks aggregates of count, sum, min, max, and averages of record values, and creates a signal when deviations from the mean occurs. For example, for the [spike in failed logins from a user](#use-case-for-a-spike-in-failed-logins-from-a-user) use case, Cloud SIEM builds a baseline model of counts of authentication failures that are associated with a user over time, and creates a signal when outlier behavior is detected:
 
@@ -77,7 +77,7 @@ After your rule starts generating signals, evaluate them to determine if they tr
 :::tip
 Sumo Logic ensures that rule processing does not impact the reliability of production environments through the implementation of "circuit breakers." If a rule matches too many records in too short a period of time, the circuit breaker will trip and the rule will move to a degraded state, and outlier rules are no exception.
 
-On the rule detail page, if you hover over the degraded message, you will usually see more details about what tripped the circuit breaker and how to resolve the problem. Generally speaking, a rule that is degraded probably needs to be tuned for your specific environment.
+On the rule detail page, if you view the degraded message, you will usually see more details about what tripped the circuit breaker and how to resolve the problem. Generally speaking, a rule that is degraded probably needs to be tuned for your specific environment.
 
 For more information, see [Troubleshoot baseline problems](/docs/cse/rules/rules-status/#troubleshoot-baseline-problems).
 :::