Make terms lowercase in 'Rules' section

Author: jpipkin1

docs/cse/rules/about-cse-rules.md

@@ -13,36 +13,36 @@ This topic has information about writing custom Cloud SIEM rules.
 Before you create a custom rule, check to see if there is a [built-in rule](/docs/cse/rules/cse-built-in-rules) that meets or comes close to meeting your need. You can easily tailor built-in rules using [rule tuning expressions](/docs/cse/rules/rule-tuning-expressions).
 :::
 
-By tuning and using a built-in rule, you avoid the effort of writing a rule, and get the benefit of on-going improvements when we update core rule logic. Added bonus: Signals and Insights from built-in rules leverage crowd-sourced machine learning that custom rules cannot.
+By tuning and using a built-in rule, you avoid the effort of writing a rule, and get the benefit of on-going improvements when we update core rule logic. Added bonus: signals and insights from built-in rules leverage crowd-sourced machine learning that custom rules cannot.
 
 ## Related topics
 
 The following topics provide information that’s relevant to the process of writing a custom rule:
 
-* [Record Processing Pipeline](/docs/cse/schema/record-processing-pipeline). This topic describes how Cloud SIEM creates Records for incoming messages. It provides facts about how message fields are mapped to Cloud SIEM schema attributes; about the attributes Cloud SIEM adds to Records to enrich and provide context about IP address, URLs, and domains; “list” features, like Match Lists and Suppress Lists that allow you to include or exclude Records based on indentiers found in Records; how to leverage threat intel data and more.
-* [Schema Attributes](/docs/cse/schema/schema-attributes). This topic defines the Record attributes you can reference in rules.
+* [Record Processing Pipeline](/docs/cse/schema/record-processing-pipeline). This topic describes how Cloud SIEM creates records for incoming messages. It provides facts about how message fields are mapped to Cloud SIEM schema attributes; about the attributes Cloud SIEM adds to records to enrich and provide context about IP address, URLs, and domains; “list” features, like Match Lists and Suppress Lists that allow you to include or exclude records based on indentifiers found in records; how to leverage threat intel data and more.
+* [Schema Attributes](/docs/cse/schema/schema-attributes). This topic defines the record attributes you can reference in rules.
 * [Cloud SIEM Rules Syntax](/docs/cse/rules/cse-rules-syntax). This topic describes rules language functions and syntax, which you’ll use in writing rule expressions.
-* [Searching for Cloud SIEM Records in Sumo Logic](/docs/cse/records-signals-entities-insights/search-cse-records-in-sumo). This topic explains how to search Cloud SIEM Records in the Sumo Logic platform. Typically, you’ll build and refine your rule expressions in Sumo Logic. Once you’re happy with the results, you’ll copy the query into the rule expression field in the Rules Editor.
+* [Searching for Cloud SIEM Records in Sumo Logic](/docs/cse/records-signals-entities-insights/search-cse-records-in-sumo). This topic explains how to search Cloud SIEM records in the Sumo Logic platform. Typically, you’ll build and refine your rule expressions in Sumo Logic. Once you’re happy with the results, you’ll copy the query into the rule expression field in the rules editor.
 
 ## Step 1: Perform use case analysis and select rule type
 
 The first step is determining your use case. In part, this involves deciding what behavior you want the rule to detect, and which of your data sources will provide evidence of that behavior. 
 
-In addition to what you're looking for, and where you can find it, you’ll decide on what sort of logic to apply when the rule encounters the target behavior. For example, is detecting one Record that matches your rule expression sufficient to fire a Signal, or should multiple matching Records be a condition for firing? Perhaps you need to look for multiple different types of events related by a common entity. The answers to these questions will determine what type of rule is appropriate for your use case. 
+In addition to what you're looking for, and where you can find it, you’ll decide on what sort of logic to apply when the rule encounters the target behavior. For example, is detecting one record that matches your rule expression sufficient to fire a signal, or should multiple matching records be a condition for firing? Perhaps you need to look for multiple different types of events related by a common entity. The answers to these questions will determine what type of rule is appropriate for your use case. 
 
 Review the standard [rule types](/docs/cse/rules/about-cse-rules#rule-types) to determine if any of them can address your use case. 
 
 ## Step 2: Review the log mapping for your source
 
-Before you write a rule, you’ll want to verify what attributes are available in the Records created from the target data source. You can do this by reviewing the log mapping for the data source.  
+Before you write a rule, you’ll want to verify what attributes are available in the records created from the target data source. You can do this by reviewing the log mapping for the data source.  
 
 Let’s say you’re going to write a rule that fires every time a successful Windows login occurs from a user account that doesn’t match your standard account naming convention. You know, maybe because you’ve checked Microsoft documentation, that the Windows event that records successful logins is Security Log Event ID 4624. So, you’ll take a look at the Cloud SIEM log mapping for that event, assuming there is one.
 
 To find and review a log mapping:
 
 1. [**Classic UI**](/docs/get-started/sumo-logic-ui-classic). In the top menu select **Configuration**, and then under **Incoming Data** select **Log Mappings**. <br/>[**New UI**](/docs/get-started/sumo-logic-ui). In the top menu click **Configuration**, and then under **Cloud SIEM Integrations** select **Log Mappings**. You can also click the **Go To...** menu at the top of the screen and select **Log Mappings**.  
 1. You can use the filter area at the top of the **Log Mappings** tab to search for a mapping by various options. The screenshot below shows the results when we enter the filter `Name matches wildcard pattern *4624`. A mapping matches. For the mapping, you can see how many times it’s been used in the last 24 hrs and also over the last 7 days. Select the mapping. <br/><img src={useBaseUrl('img/cse/matching-mappings.png')} alt="Selected mapping" width="800"/>
-1. Once you’ve opened the mapping, you’ll see the top of the page shows the Vendor, Product, and Event ID that is written to the Records produced by the mapping. <br/><img src={useBaseUrl('img/cse/selected-mapping-top.png')} alt="Mapping dialog" width="600"/>
+1. Once you’ve opened the mapping, you’ll see the top of the page shows the Vendor, Product, and Event ID that is written to the records produced by the mapping. <br/><img src={useBaseUrl('img/cse/selected-mapping-top.png')} alt="Mapping dialog" width="600"/>
 1. The **Fields** section of the page shows how raw message fields are mapped to Cloud SIEM schema attributes. In this mapping, `EventData.LogonProcessName` is mapped to `application`, `EventData.WorkstationName` is mapped to `device_hostname`, and so on. <br/><img src={useBaseUrl('img/cse/selected-mapping-bottom.png')} alt="Fields on the mapping" width="800"/>
 
 Now that we understand the mapping in Cloud SIEM, we can see we will want to be looking for logs where the `metadata_vendor` is “Microsoft”, `metadata_product` is “Windows”, and `metadata_deviceEventId` is “Security-4624”, and we will also want to use the `user_username` field to find users that don’t match our naming convention.
@@ -97,11 +97,11 @@ _index=sec_record_*
 | where metadata_vendor = "Microsoft" and metadata_product = "Windows" and metadata_deviceEventId = "Security-4624" and !(user_username matches /^[a-zA-Z]*$/ or user_username matches "*-*$") and user_username != "anonymous logon" and process_name matches "*.exe"
 ```
 
-Now we have a query we can use as the rule expression for our rule. Note that when you paste it into the Rules Editor you should remove the first portion of the query, which is only necessary when you are querying Records in Sumo Logic:
+Now we have a query we can use as the rule expression for our rule. Note that when you paste it into the rules editor you should remove the first portion of the query, which is only necessary when you are querying records in Sumo Logic:
 
 `_index=sec_record_*`  
 
-You can use an expression like this example in any rule type. Here is an example Match rule with the expression, shown in the Rules Editor.
+You can use an expression like this example in any rule type. Here is an example Match rule with the expression, shown in the rules editor.
 
 <img src={useBaseUrl('img/cse/example-in-editor.png')} alt="Example in editor" width="700"/>
 

docs/cse/rules/before-writing-custom-rule.md

@@ -5,6 +5,6 @@ sidebar_label: Built-In Rules
 description: See a list and descriptions of Cloud SIEM's built-in rules.
 ---
 
-A Cloud SIEM rule is logic that fires based on information in incoming Records. When a rule fires, it creates a Signal. There are several types of rules, each of which supports a different sort of firing behavior. While you can write your own rules, there are hundreds of rules that Cloud SIEM provides out-of-the-box. Before writing your own rule, look at the built-in rules to see if there's one that provides the behavior you need. 
+A Cloud SIEM rule is logic that fires based on information in incoming records. When a rule fires, it creates a signal. There are several types of rules, each of which supports a different sort of firing behavior. While you can write your own rules, there are hundreds of rules that Cloud SIEM provides out-of-the-box. Before writing your own rule, look at the built-in rules to see if there's one that provides the behavior you need. 
 
 For the complete list of built-in rules, see [Rules](https://github.com/SumoLogic/cloud-siem-content-catalog/blob/master/rules/README.md#rules) in the [Cloud SIEM Content Catalog](https://github.com/SumoLogic/cloud-siem-content-catalog/blob/master/README.md).

docs/cse/rules/cse-built-in-rules.md

@@ -2,7 +2,7 @@
 id: cse-rules-syntax
 title: Cloud SIEM Rules Syntax
 sidebar_label: Rules Syntax
-description: Learn about the functions you can use when writing Cloud SIEM Rules.
+description: Learn about the functions you can use when writing Cloud SIEM rules.
 ---
 
 This topic describes commonly used Cloud SIEM rules language functions. Rules language functions are used in Cloud SIEM rule expressions. For information about rules and rule expressions, see [About Cloud SIEM Rules](/docs/cse/rules/about-cse-rules).
@@ -364,11 +364,11 @@ The following expression returns "3.141592653589793" (pi):
 
 Returns “true” if a specified array contains a particular value. 
 
-Cloud SIEM rules use `array_contains` statements to look for a value in a Record field. This is useful if you want to check a Record’s `listMatches field` for [Match Lists](/docs/cse/match-lists-suppressed-lists/create-match-list) or threat intel list matches. You can also check the contents of the `fieldTags` field to see if matches a keyword tag or schema key tag value.
+Cloud SIEM rules use `array_contains` statements to look for a value in a record field. This is useful if you want to check a record’s `listMatches field` for [Match Lists](/docs/cse/match-lists-suppressed-lists/create-match-list) or threat intel list matches. You can also check the contents of the `fieldTags` field to see if matches a keyword tag or schema key tag value.
 
 **Syntax for matching to lists**
 
-The syntax for checking for the existence of a Match List name or a threat intel list name in a Record’s `listMatches` field is: 
+The syntax for checking for the existence of a Match List name or a threat intel list name in a record’s `listMatches` field is: 
 
 `array_contains(listMatches, 'match_list_name')`
 
@@ -388,7 +388,7 @@ The syntax for checking to see if the the `fieldsTag` field contains a particula
 
 where:
 
-* `field `is the name of a Record field
+* `field `is the name of a record field
 * `keyword-tag` is a keyword tag
 
 **Syntax for matching to a schema key tag**
@@ -399,7 +399,7 @@ The syntax for checking to see if the the `fieldTag` field contains a particular
 
 where:
 
-* `field` is the name of a Record field
+* `field` is the name of a record field
 * `schema-key` is the name of a schema key tag
 * `schema-value` is the value of a schema key tag
 

docs/cse/rules/cse-rules-syntax.md

@@ -13,7 +13,7 @@ import useBaseUrl from '@docusaurus/useBaseUrl';
 
 This section has instructions for importing YARA rules from GitHub into Cloud SIEM.
 
-YARA rules are an open source framework for identifying malware. Cloud SIEM runs YARA rules against files uploaded by the [Network Sensor](/docs/cse/sensors/network-sensor-deployment-guide). When a file matches a YARA rule, Cloud SIEM creates a special Record which results in a “File Analysis” Signal being created.  Once you’ve imported rules, Cloud SIEM will sync with the repository no less than every hour.
+YARA rules are an open source framework for identifying malware. Cloud SIEM runs YARA rules against files uploaded by the [network sensor](/docs/cse/sensors/network-sensor-deployment-guide). When a file matches a YARA rule, Cloud SIEM creates a special record which results in a “file analysis” signal being created.  Once you’ve imported rules, Cloud SIEM will sync with the repository no less than every hour.
 
 To import YARA rules:
 
@@ -28,4 +28,4 @@ To import YARA rules:
 1. **GitHub Machine Username**. Enter a username if the repository is private.
 1. **GitHub Machine Token**. Enter a token if the repository is private.
 1. **YARA file Regex**. The regex in this field is matched to rule names in the repository. The default regex will match rule files whose file extension is `.yar`, `.yara`, or `.rule`.  
-1. **Default Severity**. Enter the severity to be assigned when the Signal is created.
+1. **Default Severity**. Enter the severity to be assigned when the signal is created.

docs/cse/rules/import-yara-rules.md

@@ -26,7 +26,7 @@ In this section, we'll introduce the following concepts:
 <div className="box smallbox card">
   <div className="container">
   <a href="/docs/cse/rules/cse-rules-syntax"><img src={useBaseUrl('img/icons/operations/rules.png')} alt="Flow diagram icon" width="40"/><h4>Rules Syntax</h4></a>
-  <p>Learn about the functions you can use when writing Cloud SIEM Rules.</p>
+  <p>Learn about the functions you can use when writing Cloud SIEM rules.</p>
   </div>
 </div>
 <div className="box smallbox card">
@@ -104,7 +104,7 @@ In this section, we'll introduce the following concepts:
 <div className="box smallbox card">
   <div className="container">
   <a href="/docs/cse/rules/insight-trainer"><img src={useBaseUrl('img/icons/operations/rules.png')} alt="Flow diagram icon" width="40"/><h4>Insight Trainer</h4></a>
-  <p>Learn how to adjust rules to improve Insight generation.</p>
+  <p>Learn how to adjust rules to improve insight generation.</p>
   </div>
 </div>
 </div>