From 73d01347fb98dfca3d197108919b6efeef0b4f4d Mon Sep 17 00:00:00 2001 From: John Pipkin Date: Tue, 17 Dec 2024 17:18:30 -0600 Subject: [PATCH 1/6] Make terms lowercase in 'Schema' section --- docs/cse/schema/attributes-map-to-records.md | 6 +- .../schema/create-structured-log-mapping.md | 36 ++++----- .../schema/cse-normalized-classification.md | 78 +++++++++---------- docs/cse/schema/cse-record-types.md | 6 +- .../field-mapping-security-event-sources.md | 4 +- docs/cse/schema/index.md | 10 +-- docs/cse/schema/parser-editor.md | 19 +++-- .../cse/schema/parser-troubleshooting-tips.md | 2 +- .../parsing-language-reference-guide.md | 14 ++-- docs/cse/schema/record-processing-pipeline.md | 54 ++++++------- .../username-and-hostname-normalization.md | 2 +- 11 files changed, 115 insertions(+), 116 deletions(-) diff --git a/docs/cse/schema/attributes-map-to-records.md b/docs/cse/schema/attributes-map-to-records.md index b673024302..ca5cc57a9a 100644 --- a/docs/cse/schema/attributes-map-to-records.md +++ b/docs/cse/schema/attributes-map-to-records.md @@ -2,12 +2,12 @@ id: attributes-map-to-records title: Attributes You Can Map to Records sidebar_label: Mappable Attributes -description: Learn what Cloud SIEM schema attributes you can map to Records. +description: Learn what Cloud SIEM schema attributes you can map to records. --- -You can map schema attributes to Records. Note that you can map any of the attributes defined to any [record type](/docs/cse/schema/cse-record-types). +You can map schema attributes to records. Note that you can map any of the attributes defined to any [record type](/docs/cse/schema/cse-record-types). For the complete list of attributes you can map to records, see [Schema: General Schema Fields](https://github.com/SumoLogic/cloud-siem-content-catalog/blob/master/schema/general_fields.md) in the [Cloud SIEM Content Catalog](https://github.com/SumoLogic/cloud-siem-content-catalog/blob/master/README.md). -For information about all schema attributes, including those that cannot be mapped to Records, for example enrichment fields, see [Schema Attributes](/docs/cse/schema/schema-attributes).   +For information about all schema attributes, including those that cannot be mapped to records, for example enrichment fields, see [Schema Attributes](/docs/cse/schema/schema-attributes).   diff --git a/docs/cse/schema/create-structured-log-mapping.md b/docs/cse/schema/create-structured-log-mapping.md index be281d1da1..8461f3077b 100644 --- a/docs/cse/schema/create-structured-log-mapping.md +++ b/docs/cse/schema/create-structured-log-mapping.md @@ -7,17 +7,17 @@ description: Learn how to create a log mapping for structured messages. import useBaseUrl from '@docusaurus/useBaseUrl'; -This topic has instructions for creating a log mapping for structured messages using the Cloud SIEM UI. Log mapping is the process of telling Cloud SIEM how to build a Record from the key-value pairs extracted from messages. +This topic has instructions for creating a log mapping for structured messages using the Cloud SIEM UI. Log mapping is the process of telling Cloud SIEM how to build a record from the key-value pairs extracted from messages. -For more information about log mapping, and how it fits into the Record creation process, see the [Record Processing Pipeline](/docs/cse/schema/record-processing-pipeline) topic. For a complete list of the standard log mappings, see [Mappings](https://github.com/SumoLogic/cloud-siem-content-catalog/blob/master/mappings/README.md) the [Cloud SIEM Content Catalog](https://github.com/SumoLogic/cloud-siem-content-catalog/blob/master/README.md). +For more information about log mapping, and how it fits into the record creation process, see the [Record Processing Pipeline](/docs/cse/schema/record-processing-pipeline) topic. For a complete list of the standard log mappings, see [Mappings](https://github.com/SumoLogic/cloud-siem-content-catalog/blob/master/mappings/README.md) in the [Cloud SIEM Content Catalog](https://github.com/SumoLogic/cloud-siem-content-catalog/blob/master/README.md). ## About the log mapping process When you set up a log mapping, you supply the following information:   * **What messages will the mapper process?** To identify which incoming messages the mapper should process, you supply a vendor name, product name, message format, and an event ID expression.  -* **What Record type should be created for the messages the mapper processes?** Cloud SIEM has multiple predefined [Record types](/docs/cse/schema/cse-record-types), each of which corresponds to a particular sort of event a log message might describe. When you configure a log mapping, you select the Record type that corresponds best to the log messages the mapper will process. For example, you would select “Authentication” as the Record type to create from messages that report successful or unsuccessful authentication events. -* **What normalized classification should be added for the messages the mapper processes?** Records can be classified at two levels of granularity. First, at a high level with [Record Types](/docs/cse/schema/cse-record-types) which all mapped Records have, and more specifically using Normalized Classification Fields alongside the mapped attributes within a Record. For more information, see the [Cloud SIEM Normalized Classification.](/docs/cse/schema/cse-normalized-classification) +* **What Record type should be created for the messages the mapper processes?** Cloud SIEM has multiple predefined [record types](/docs/cse/schema/cse-record-types), each of which corresponds to a particular sort of event a log message might describe. When you configure a log mapping, you select the record type that corresponds best to the log messages the mapper will process. For example, you would select “Authentication” as the record type to create from messages that report successful or unsuccessful authentication events. +* **What normalized classification should be added for the messages the mapper processes?** Records can be classified at two levels of granularity. First, at a high level with [record types](/docs/cse/schema/cse-record-types) which all mapped records have, and more specifically using Normalized Classification Fields alongside the mapped attributes within a record. For more information, see [Cloud SIEM Normalized Classification.](/docs/cse/schema/cse-normalized-classification) ## Step 1: Choose mapping type and name the mapping @@ -41,15 +41,15 @@ The values you supply should correspond to the values that were supplied for ven ## Step 3: Enter “Then Create Record” values -1. **Record of type**. Select the [Record type](/docs/cse/schema/cse-record-types) that specifies the attributes that the Records created by the mapper should contain. -1. **with vendor**. The vendor name that the mapper should write to Records. If you already selected a vendor in **When a log from vendor** in the **If Input Matches** area, that vendor appears here. In the Records the mapper creates, this value will be written to the `device_vendor` field. -1. **and product**. The product name that the mapper should write to Records. If you already selected a product from **and product** in the **If Input Matches** area, that product appears here. In the Records the mapper creates, this value will be written to the `device_product` field. +1. **Record of type**. Select the [record type](/docs/cse/schema/cse-record-types) that specifies the attributes that the records created by the mapper should contain. +1. **with vendor**. The vendor name that the mapper should write to records. If you already selected a vendor in **When a log from vendor** in the **If Input Matches** area, that vendor appears here. In the records the mapper creates, this value will be written to the `device_vendor` field. +1. **and product**. The product name that the mapper should write to records. If you already selected a product from **and product** in the **If Input Matches** area, that product appears here. In the records the mapper creates, this value will be written to the `device_product` field. ## Step 4: Specify field mapping In this step you specify field mapping. This is the process of assigning the value of message fields to Cloud SIEM attributes.  -You might not map all message fields to schema attributes. Unmapped message fields will be retained in the `fields` attribute of the resulting Records. +You might not map all message fields to schema attributes. Unmapped message fields will be retained in the `fields` attribute of the resulting records. The sections that follow have instructions for setting up each type of mapping: * [constant mapping](#constant-mapping) @@ -77,7 +77,7 @@ To configure a constant mapping: 1. Select **constant** from the **Create a new … mapping field?** pull-down. 1. **Constant**. Enter the name of an input field. This is the field from incoming messages whose value you want to translate. -1. **Output Field**. Select an output field. This is the Record attribute whose value you wish to populate. +1. **Output Field**. Select an output field. This is the record attribute whose value you wish to populate. 1. Click **Add Field** to save the field mapping. ### extracted mapping @@ -94,7 +94,7 @@ To configure a extracted mapping: 1. Select **extracted** from the **Create a new … mapping field?** pull-down. 1. **Extracted Field**. Enter the name of an extracted field.  -1. **Output Field**. Select an output field. This is the Record attribute whose value you wish to populate. +1. **Output Field**. Select an output field. This is the record attribute whose value you wish to populate. 1. Click **Add Field** to save the field mapping. ### format mapping @@ -116,7 +116,7 @@ To define a format mapping: 1. Select **format** from the **Create a new … mapping field?** pulldown. 1. **Input Field**. Enter the format specifiers to be applied to the message fields you’ll specify in the next step. 1. **Format Parameters**. Enter the message fields to which the formatting will be applied. -1. **Output Field**. Select an output field. This is the Record attribute whose value you wish to populate. +1. **Output Field**. Select an output field. This is the record attribute whose value you wish to populate. 1. Click **Add Field** to save the field mapping. ### joined mapping @@ -134,7 +134,7 @@ In the screenshot below, we're configuring a mapping that joins the value of the 1. **Show optional fields**. Expand this section if you want to specify one or more alternative input fields, or set a default value to be mapped to the target in the event that the input field is null. 1. **Alternate Input Fields**. Enter one or more fields, separated by spaces. If any of the input fields you entered above do not exist in a message, or is null, the value of the first alternative field that exists in the message and isn’t null will be mapped to the Cloud SIEM attribute you’ll specify later in this procedure. 1. **Default Value**. Enter the value you want to write to the Cloud SIEM attribute in the event that neither the input field or any alternative fields with non-null values exist in the message. -1. **Output Field**. Select an output field. This is the Record attribute whose value you wish to populate. +1. **Output Field**. Select an output field. This is the record attribute whose value you wish to populate. ### lookup mapping @@ -142,9 +142,9 @@ You use a lookup mapping to specify a set of input-output value pairs that are u **Example lookup mapping** -In the screenshot below, we’ve defined a set of lookup key-value pairs that specify how to translate the value of the EventData.LogonType field and write it to the logonType attribute in resulting Records.  +In the screenshot below, we’ve defined a set of lookup key-value pairs that specify how to translate the value of the EventData.LogonType field and write it to the logonType attribute in resulting records.  -The configuration shown below defines what value to write to the logonType attribute of a Record when the EventData.LogonType message field value is “1”, “2”, “3”, or “4”, which will be “Interactive”, “”Network”, “Batch”, and “Service”, respectively. +The configuration shown below defines what value to write to the logonType attribute of a record when the EventData.LogonType message field value is “1”, “2”, “3”, or “4”, which will be “Interactive”, “”Network”, “Batch”, and “Service”, respectively. Lookout mapping @@ -157,7 +157,7 @@ The configuration shown below defines what value to write to the logonType attri 1. **Output Value**. Enter the value you want to translate the input value to. 1. **Add Mapping Pair.** Click this option and repeat the two previous steps 3 through 5 to an additional value mapping. 1. **Input Case Sensitive**. Check the box if the value of the input field is case sensitive. -1. **Output Field**. Select an output field. This is the Record attribute whose value you wish to populate. +1. **Output Field**. Select an output field. This is the record attribute whose value you wish to populate. 1. Click **Add Field** to save the field mapping. ### split mapping @@ -176,7 +176,7 @@ To define a split mapping: 1. **Input Field**. Enter the name of an input field. This is the field from incoming messages whose value you want to split. 1. **Delimiter.** Enter the character that delimits the segments of the field. 1. **Index**. Enter the integer value that corresponds, order-wise, to the segment of the field that you want to write to the output field you’ll specify in the next step. An index value of “0” indicates the first segment, “1” indicates the second segment, and so on. Use a negative index value to index from the end (i.e., "-1" for the last segment, "-2" for the second to last segment). -1. **Output Field**. Select an output field. This is the Record attribute whose value you wish to populate. +1. **Output Field**. Select an output field. This is the record attribute whose value you wish to populate. 1. Click **Add Field** to save the field mapping. ### standard mapping @@ -200,7 +200,7 @@ To map a single input field: 1. **Show optional fields**. Expand this section if you want to specify one or more alternative input fields, or set a default value to be mapped to the target in the event that the input field is null. 1. **Alternate Input Fields**. Enter one or more fields, separated by spaces. If the Input Field you entered above doesn’t exist in a message, or is null, the value of the first alternative field that exists in the message and isn’t null will be mapped to the Cloud SIEM attribute you’ll specify later in this procedure. 1. **Default Value**. Enter the value you want to write to the Cloud SIEM attribute in the event that neither the input field or any alternative fields with non-null values exist in the message. -1. **Output Field**. Select an output field. This is the Record attribute whose value you wish to populate. +1. **Output Field**. Select an output field. This is the record attribute whose value you wish to populate. 1. Click **Add Field** to save the field mapping. **Example standard mapping: multiple input fields** @@ -222,7 +222,7 @@ To map multiple input fields: 1. **Show optional fields**. Click this if you want to specify one or more alternative input fields, or set a default value to be mapped to the target in the event that the input field is null. 1. **Alternate input fields**. Enter one or more fields, separated by spaces. If any of the Input Fields you entered above don’t exist in a message, or are null, the values of the alternative fields you enter will be combined and mapped to the Cloud SIEM attribute you’ll specify later in this procedure. 1. **Default value**. Enter the value you want to write to the Cloud SIEM attribute in the event that neither the input fields or any alternative fields exist with non-null values in the message. -1. **Output Field**. Select an output field. This is the Record attribute whose value you wish to populate. +1. **Output Field**. Select an output field. This is the record attribute whose value you wish to populate. 1. Click **Add Field** to save the field mapping. ### time mapping diff --git a/docs/cse/schema/cse-normalized-classification.md b/docs/cse/schema/cse-normalized-classification.md index 86649ed1b6..f6c08c38af 100644 --- a/docs/cse/schema/cse-normalized-classification.md +++ b/docs/cse/schema/cse-normalized-classification.md @@ -2,36 +2,36 @@ id: cse-normalized-classification title: Cloud SIEM Normalized Classification sidebar_label: Normalized Classification -description: Learn about Cloud SIEM's Normalized Classification Fields, schema fields that have an enforced output defined by Cloud SIEM. +description: Learn about Cloud SIEM's normalized classification fields, schema fields that have an enforced output defined by Cloud SIEM. --- -This topic describes how Cloud SIEM applies normalized classification to Records.  +This topic describes how Cloud SIEM applies normalized classification to records.  -In Cloud SIEM Records can be classified at two levels. First, all Records are classified at a high level by Record Type. At a more detailed level, you can classify more specifically using Normalized Classification Fields alongside the mapped attributes within a Record. +In Cloud SIEM records can be classified at two levels. First, all records are classified at a high level by record type. At a more detailed level, you can classify more specifically using normalized classification fields alongside the mapped attributes within a record. -## Record Types +## Record types -Every Cloud SIEM Record has a Record Type. A Record Type classifies the nature of the event that the Record describes. Cloud SIEM Record Types include **Authentication,** **Endpoint**, **NetworkHTTP** and so on. +Every Cloud SIEM record has a record type. A record type classifies the nature of the event that the record describes. Cloud SIEM record types include **Authentication,** **Endpoint**, **NetworkHTTP** and so on. -A Record’s type is set by the [log mapping](/docs/cse/schema/create-structured-log-mapping) that processes it. For more information, see [Cloud SIEM Record Types](/docs/cse/schema/cse-record-types). +A record’s type is set by the [log mapping](/docs/cse/schema/create-structured-log-mapping) that processes it. For more information, see [Cloud SIEM Record Types](/docs/cse/schema/cse-record-types). -## Normalized Classification Fields +## Normalized classification fields -For more granular classification of a Record, Cloud SIEM uses *Normalized Classification Fields*. These are special normalized schema fields that have an enforced output defined by Cloud SIEM. These fields provide a taxonomy that can be used to tie Records from multiple vendors and products together in a standard way. Rather than holistically trying to describe a Record as Record Type does, these fields exist alongside commonly used normalization schema fields which most often contain the what, where, and why of a particular Record. This allows for far more dynamic and specific classification of a Record than Record Type alone.  +For more granular classification of a record, Cloud SIEM uses *normalized classification fields*. These are special normalized schema fields that have an enforced output defined by Cloud SIEM. These fields provide a taxonomy that can be used to tie records from multiple vendors and products together in a standard way. Rather than holistically trying to describe a record as record type does, these fields exist alongside commonly used normalization schema fields which most often contain the what, where, and why of a particular record. This allows for far more dynamic and specific classification of a record than record type alone.  -Normalized Classification Fields are completely optional when creating a log mapping. When using Normalized Classification Fields, it is best to consider whether a parallel normalized schema field exists for the Record and whether there is an analogous enforced output available in the desired Normalized Classification Field. These fields will most typically utilize the lookup unless the vendor log output exactly matches the enforced outputs or a constant value is assigned. +Normalized classification fields are completely optional when creating a log mapping. When using normalized classification fields, it is best to consider whether a parallel normalized schema field exists for the record and whether there is an analogous enforced output available in the desired normalized classification field. These fields will most typically utilize the lookup unless the vendor log output exactly matches the enforced outputs or a constant value is assigned. :::note -* When creating a log mapping, if the output value used for a given Normalized Classification Field is not listed in the Enforced Output Values for that field, it will not be populated. -* Normalized Classification Fields are a new feature and will be backfilled to existing out-of-the-box mappings over time. +* When creating a log mapping, if the output value used for a given normalized classification field is not listed in the Enforced Output Values for that field, it will not be populated. +* Normalized classification fields are a new feature and will be backfilled to existing out-of-the-box mappings over time. ::: ## normalizedAction Complementary to the [action](/docs/cse/schema/schema-attributes) field, the `normalizedAction` field describes the initiation of an activity in a -standard way across Records. `normalizedAction` is meant to describe an attempt to perform an action, using the success boolean as a modifier to indicate whether or not the action was successful. Note that `normalizedAction` should be used with [normalizedResource](/docs/cse/schema/cse-normalized-classification) to indicate where an action was attempted, or the resource or entity upon which the action was attempted. +standard way across records. `normalizedAction` is meant to describe an attempt to perform an action, using the success boolean as a modifier to indicate whether or not the action was successful. Note that `normalizedAction` should be used with [normalizedResource](/docs/cse/schema/cse-normalized-classification) to indicate where an action was attempted, or the resource or entity upon which the action was attempted. | Enforced Output Value | Description | |:--|:--| @@ -65,45 +65,45 @@ standard way across Records. `normalizedAction` is meant to describe an attempt ## normalizedResource -Complementary to the [resource](/docs/cse/schema/schema-attributes) field, this field describes the resource being acted upon or otherwise referenced within a Record in a standard way across Records. Intended to be used to provide further normalized context to a Record, particularly in tandem with [normalizedAction](/docs/cse/schema/cse-normalized-classification). +Complementary to the [resource](/docs/cse/schema/schema-attributes) field, this field describes the resource being acted upon or otherwise referenced within a record in a standard way across records. Intended to be used to provide further normalized context to a record, particularly in tandem with [normalizedAction](/docs/cse/schema/cse-normalized-classification). | Enforced Output Value | Description | |:--|:--| -| account | Use where the resource being acted upon or referenced in a Record pertains to an account. | -| application | Use where the resource being acted upon or referenced in a Record pertains to an application. | -| backup | Use where the resource being acted upon or referenced in a Record pertains to a backup. | -| bucket | Use where the resource being acted upon or referenced in a Record pertains to a specific bucket. Common in cloud computing. | -| database | Use where the resource being acted upon or referenced in a Record pertains to a database. | -| directory | Use where the resource being acted upon or referenced in a Record pertains to a directory or similar hierarchical organizational unit. | -| email | Use where the resource being acted upon or referenced in a Record pertains to email or email delivery. | -| file | Use where the resource being acted upon or referenced in a Record pertains to a file. | -| group | Use where the resource being acted upon or referenced in a Record pertains to a group, for example, an organizational unit, security group, user group, computer group, access control list, and so on. | -| instance | Use where the resource being acted upon or referenced in a Record pertains to a specific machine instance, typically virtual. Common in cloud computing. | -| key | Use where the resource being acted upon or referenced in a Record pertains to a cryptographic key. | -| malware | Use where the resource being acted upon or referenced in a Record pertains to malware itself or the prevention, detection, or removal of malware. | -| network | Use where the resource being acted upon or referenced in a Record is or pertains to network traffic. | -| operating system | Use where the resource being acted upon or referenced in a Record pertains to an operating system component. | -| process | Use where the resource being acted upon or referenced in a Record pertains to a process | -| role | Use where the resource being acted upon or referenced in a Record pertains to a role. Common in cloud computing. | -| scheduled task | Use where the resource being acted upon or referenced in a Record pertains to a scheduled task or analogous functionality. | -| service | Use where the resource being acted upon or referenced in a Record pertains to a service. | +| account | Use where the resource being acted upon or referenced in a record pertains to an account. | +| application | Use where the resource being acted upon or referenced in a record pertains to an application. | +| backup | Use where the resource being acted upon or referenced in a record pertains to a backup. | +| bucket | Use where the resource being acted upon or referenced in a record pertains to a specific bucket. Common in cloud computing. | +| database | Use where the resource being acted upon or referenced in a record pertains to a database. | +| directory | Use where the resource being acted upon or referenced in a record pertains to a directory or similar hierarchical organizational unit. | +| email | Use where the resource being acted upon or referenced in a record pertains to email or email delivery. | +| file | Use where the resource being acted upon or referenced in a record pertains to a file. | +| group | Use where the resource being acted upon or referenced in a record pertains to a group, for example, an organizational unit, security group, user group, computer group, access control list, and so on. | +| instance | Use where the resource being acted upon or referenced in a record pertains to a specific machine instance, typically virtual. Common in cloud computing. | +| key | Use where the resource being acted upon or referenced in a record pertains to a cryptographic key. | +| malware | Use where the resource being acted upon or referenced in a record pertains to malware itself or the prevention, detection, or removal of malware. | +| network | Use where the resource being acted upon or referenced in a record is or pertains to network traffic. | +| operating system | Use where the resource being acted upon or referenced in a record pertains to an operating system component. | +| process | Use where the resource being acted upon or referenced in a record pertains to a process | +| role | Use where the resource being acted upon or referenced in a record pertains to a role. Common in cloud computing. | +| scheduled task | Use where the resource being acted upon or referenced in a record pertains to a scheduled task or analogous functionality. | +| service | Use where the resource being acted upon or referenced in a record pertains to a service. | ## normalizedCause -Complementary to the [cause](/docs/cse/schema/schema-attributes) field, this field describes the reason for any particular outcome in a Record in a standard way. +Complementary to the [cause](/docs/cse/schema/schema-attributes) field, this field describes the reason for any particular outcome in a record in a standard way. | Enforced Output Value | Description | |:--|:--| -| incorrect password | For a Record describing an authentication failure where the cause of the failure was an incorrect password. | -| incorrect username | For a Record describing an authentication failure where the cause of the failure was an incorrect username. | -| failed challenge | For a Record describing an authentication failure where the cause of the failure was a failed multi-factor authentication challenge or other secondary authentication challenge, such as a security question. | -| system error | For a Record describing a failed operation where the cause of the failure was a system error. | -| allow list | For a Record describing the successful outcome of an operation based on the presence of an object on an allow list. For instance, an Allow ACL. | -| deny list | For a Record describing the failed outcome of an operation based on the presence of an object on a deny list. For instance, a Deny ACL. | +| incorrect password | For a record describing an authentication failure where the cause of the failure was an incorrect password. | +| incorrect username | For a record describing an authentication failure where the cause of the failure was an incorrect username. | +| failed challenge | For a record describing an authentication failure where the cause of the failure was a failed multi-factor authentication challenge or other secondary authentication challenge, such as a security question. | +| system error | For a record describing a failed operation where the cause of the failure was a system error. | +| allow list | For a record describing the successful outcome of an operation based on the presence of an object on an allow list. For instance, an Allow ACL. | +| deny list | For a record describing the failed outcome of an operation based on the presence of an object on a deny list. For instance, a Deny ACL. | ### success -True or false showing whether or not an action or event Recorded in a log was successful. This field is either defined as a constant or based on a lookup in a mapping. +True or false showing whether or not an action or event recorded in a log was successful. This field is either defined as a constant or based on a lookup in a mapping. ## normalizedSeverity diff --git a/docs/cse/schema/cse-record-types.md b/docs/cse/schema/cse-record-types.md index 1a1ddbddf3..1ecbe19b6d 100644 --- a/docs/cse/schema/cse-record-types.md +++ b/docs/cse/schema/cse-record-types.md @@ -2,9 +2,9 @@ id: cse-record-types title: Cloud SIEM Record Types sidebar_label: Record Types -description: Learn about the Record types to which you can map schema attributes. +description: Learn about the record types to which you can map schema attributes. --- -Each message that Cloud SIEM maps must be assigned one, and only one, Record Type. For the complete list of record types, see [Schema: Record Types](https://github.com/SumoLogic/cloud-siem-content-catalog/blob/master/schema/record_types.md) in the [Cloud SIEM Content Catalog](https://github.com/SumoLogic/cloud-siem-content-catalog/blob/master/README.md). +Each message that Cloud SIEM maps must be assigned one, and only one, record type. For the complete list of record types, see [Schema: Record Types](https://github.com/SumoLogic/cloud-siem-content-catalog/blob/master/schema/record_types.md) in the [Cloud SIEM Content Catalog](https://github.com/SumoLogic/cloud-siem-content-catalog/blob/master/README.md). -Note that it is possible for multiple mappers to match a particular log message and each create a unique Record for that message—those multiple Records can have different Record Types. It isn’t standard practice to create multiple Cloud SIEM Records from a single log message, but it is possible if there is a use case. For related information, see [Attributes You Can Map to Records](/docs/cse/schema/attributes-map-to-records). \ No newline at end of file +Note that it is possible for multiple mappers to match a particular log message and each create a unique record for that message—those multiple records can have different record types. It isn’t standard practice to create multiple Cloud SIEM records from a single log message, but it is possible if there is a use case. For related information, see [Attributes You Can Map to Records](/docs/cse/schema/attributes-map-to-records). \ No newline at end of file diff --git a/docs/cse/schema/field-mapping-security-event-sources.md b/docs/cse/schema/field-mapping-security-event-sources.md index 4212a3806c..e7377ea005 100644 --- a/docs/cse/schema/field-mapping-security-event-sources.md +++ b/docs/cse/schema/field-mapping-security-event-sources.md @@ -14,7 +14,7 @@ To ensure that the appropriate threat rule or rules are applied to a message, th * `threat_ruleType`—This attribute should be populated for messages that describe security events that have already occurred. Messages that don’t include security event detection should not map this attribute. See the field mapping instructions for each threat type in the sections below. * `threat_name`—The value you map to this attribute depends on the value of the `threat_ruleType` in the mapping. See the field mapping instructions for each threat type in the sections below. -* `threat_signalName`—This attribute is used by some normalized rules as an element of the names for Signals the rule generates, so that the rule generates different signal names for different products.  +* `threat_signalName`—This attribute is used by some normalized rules as an element of the names for signals the rule generates, so that the rule generates different signal names for different products.  * `normalizedSeverity`—The value you map to this attribute depends on the value of the `threat_ruleType` in the mapping. See the field mapping instructions for each threat type in the sections below. ## Field mappings for intrusion events @@ -45,6 +45,6 @@ attributes. | Attribute | Mapping instruction | |:--|:--| | `threat_ruleType` | Map to the value “direct”. | -| `threat_signalName` | Map this to the field or fields that should be used as the name of Signal generated for a message. You can do this with a standard field mapping. If you want to map to a formatted combination of message fields, use a format field mapping.
Note When the built-in Normalized Security Signal rule fires a Signal, the Signal name will be the value of threat_signalName, resulting in Signal names of this form: `{threat_signalName}` | +| `threat_signalName` | Map this to the field or fields that should be used as the name of signal generated for a message. You can do this with a standard field mapping. If you want to map to a formatted combination of message fields, use a format field mapping.
Note When the built-in Normalized Security Signal rule fires a signal, the signal name will be the value of threat_signalName, resulting in signal names of this form: `{threat_signalName}` | | `threat_name` | Map to the alert name contained in the message. | | `normalizedSeverity` | Map to the severity field in the message. Note that in Cloud SIEM, severity is a value from 0 (lowest) to 10 (highest). If the severity range used in the message is not 0 to 10, you can translate the value from the message using a lookup mapping.
For example, if the message source uses severities 1 to 5, you could translate the values like this:
'1': '2'
'2': '4'
'3': '6'
'4': '8'
'5': '10'
You can also define a default severity value that will apply if apply if a message doesn’t contain a severity value. | diff --git a/docs/cse/schema/index.md b/docs/cse/schema/index.md index ded4761191..42e8c71b94 100644 --- a/docs/cse/schema/index.md +++ b/docs/cse/schema/index.md @@ -1,7 +1,7 @@ --- slug: /cse/schema title: Cloud SIEM Schema -description: Learn about Cloud SIEM Schema v3, schema attributes, and the Record processing pipeline. +description: Learn about Cloud SIEM Schema v3, schema attributes, and the record processing pipeline. --- import useBaseUrl from '@docusaurus/useBaseUrl'; @@ -12,7 +12,7 @@ This guide has information about Cloud SIEM schemas. In this section, we'll intr
Flow diagram icon

Record Processing Pipeline

 -

Learn how Cloud SIEM transforms incoming raw messages into Records.

+

Learn how Cloud SIEM transforms incoming raw messages into records.

@@ -24,19 +24,19 @@ This guide has information about Cloud SIEM schemas. In this section, we'll intr
Flow diagram icon

Mappable Attributes

 -

Learn what Cloud SIEM schema attributes you can map to Records.

+

Learn what Cloud SIEM schema attributes you can map to records.

Flow diagram icon

Record Types

 -

Learn about the Record types to which you can map schema attributes.

+

Learn about the record types to which you can map schema attributes.

Flow diagram icon

Parsing Language Reference

 -

Parsing is the first step in the Cloud SIEM Record processing pipeline.

+

Parsing is the first step in the Cloud SIEM record processing pipeline.

diff --git a/docs/cse/schema/parser-editor.md b/docs/cse/schema/parser-editor.md index 259f8d78a0..f85819c983 100644 --- a/docs/cse/schema/parser-editor.md +++ b/docs/cse/schema/parser-editor.md @@ -36,7 +36,7 @@ Watch the following micro lesson to learn how to apply parsers to Cloud SIEM dat ## Check parser code for mapping hints -Your parser code must contain statements that tell Cloud SIEM what log mapping to use when creating Records from the field dictionary the parser creates for log messages.  +Your parser code must contain statements that tell Cloud SIEM what log mapping to use when creating records from the field dictionary the parser creates for log messages.  Make sure your parser code includes `MAPPER` statements that specify the vendor, product, and the event ID that the log messages to be parsed contain, and a `FORMAT` statement that defines the message format. @@ -54,7 +54,7 @@ Make sure your parser code includes `MAPPER` statements that specify the vendor, 1. **Description**. (Optional) Describe the parser. 1. **Parser Configuration**. Paste your parser code in this area. 1. **Import Messages from**. In this step, you enter or fetch messages that you’ll use to test whether the parser parses the messages correctly. There are three options: - * **Sumo Log Search**. You can enter a log search query to obtain a selected number of log messages. Follow the instructions in [Using Sumo log search](#using-sumo-log-search) below. + * **Sumo Log Search**. You can enter a log search query to obtain a selected number of log messages. Follow the instructions in [Using Sumo Logic log search](#using-sumo-logic-log-search) below. * **Saved Logs**. You can select a set of messages that you saved when previously using the **Paste Logs** option. Follow the instructions in [Using saved logs](#using-saved-logs) below. * **Paste Logs**. You can paste logs directly into the **Log Messages** area. Follow the instructions in [Using paste logs](#using-paste-logs) below.  @@ -71,7 +71,7 @@ Make sure your parser code includes `MAPPER` statements that specify the vendor, This section describes the three methods of obtaining messages for use in testing your parser. -### Using Sumo log search +### Using Sumo Logic log search To import messages by running a Sumo Logic search: @@ -167,8 +167,7 @@ You can move a parser from one location to another within the parser editor’s ## Export and import a parser -You can export a parser as JSON, and import it to another Sumo Logic -org. +You can export a parser as JSON, and import it to another Sumo Logic org. 1. Navigate to the parser you want to export and choose **Export** from the three-dot kebab menu. 1. On the **Export** popup, click **Copy to Clipboard** and then click **Done**.
Export dialog @@ -180,17 +179,17 @@ org. ## Setting Cloud SIEM log mapping information -In this step you configure one or more Log Mappings. If all of the messages your parser will process contain the same fields, and you want to create Records of the same type, a single Log Mapping will suffice. For some data sources, you will likely need to create more than one Log Mapping. For example: +In this step you configure one or more Log Mappings. If all of the messages your parser will process contain the same fields, and you want to create records of the same type, a single Log Mapping will suffice. For some data sources, you will likely need to create more than one Log Mapping. For example: -With some CloudTrail logs messages, you might want to create a different [Record type](/docs/cse/schema/cse-record-types), depending on the event ID in a message. In some cases, an Authorization Record is appropriate, while in others, an Audit or Audit Change Record would be a better fit.  +With some CloudTrail logs messages, you might want to create a different [record type](/docs/cse/schema/cse-record-types), depending on the event ID in a message. In some cases, an authorization record is appropriate, while in others, an audit or audit change record would be a better fit.  -In some CloudTrail messages, the field mapping (the mapping between a key in the field dictionary and a Cloud SIEM Record) will vary, depending on the Event ID in the message. For example, you may want to map data into the Cloud SIEM schema field action, but the data you want to map is located in different keys of the original CloudTrail JSON messages depending on the CloudTrail event type. +In some CloudTrail messages, the field mapping (the mapping between a key in the field dictionary and a Cloud SIEM record) will vary, depending on the Event ID in the message. For example, you may want to map data into the Cloud SIEM schema field action, but the data you want to map is located in different keys of the original CloudTrail JSON messages depending on the CloudTrail event type. To create your mapping, see [Creating a Structured Log Mapping](/docs/cse/schema/create-structured-log-mapping). After setting up the mapping or mappings, complete the steps in [Configuring a source to use a parser](#configuring-a-source-to-use-a-parser), below. ## Configuring a source to use a parser -This section explains how to configure a Sumo Logic core platform source to send the messages it collects to a parser. This involves configuring a Field for the source: you'll create a `_parser` Field that defines the path to the parser.  +This section explains how to configure a Sumo Logic core platform source to send the messages it collects to a parser. This involves configuring a field for the source: you'll create a `_parser` field that defines the path to the parser.  1. Navigate to your custom parser in the editor. 1. Hover over the row that contains the parser. @@ -198,7 +197,7 @@ This section explains how to configure a Sumo Logic core platform source to send 1. In Sumo Logic core platform, go to **Manage Data** > **Collection** > **Collection**. 1. Navigate to the source that produces the messages your custom parser will process.
CloudTrail source 1. Click **+Add Field**.  -1. Two blank fields appear, below any Fields that have already been defined for the source. Enter `_parser` as the field name and the path to your parser as the value. 
New field +1. Two blank fields appear, below any fields that have already been defined for the source. Enter `_parser` as the field name and the path to your parser as the value. 
New field
An orange icon indicates that the `_parser` field has not been created in your Sumo Logic core platform org yet. ## Parser templates diff --git a/docs/cse/schema/parser-troubleshooting-tips.md b/docs/cse/schema/parser-troubleshooting-tips.md index 97575197af..2b100fd928 100644 --- a/docs/cse/schema/parser-troubleshooting-tips.md +++ b/docs/cse/schema/parser-troubleshooting-tips.md @@ -23,6 +23,6 @@ For general information on the parsing engine and syntax, see the [Parser Editor 3. Check for Field Extraction Rules, [Sumo Logic Ingest Mappings](/docs/cse/ingestion/sumo-logic-ingest-mapping), or [Local Configurations](/docs/cse/schema/parser-editor#create-a-local-configuration-for-a-system-parser) related to the parser that is presenting issues. * Field Extraction Rules can alter message contents in such a way that the parser works when you're testing it in the Parser Editor against messages returned by a Sumo Logic log search, but not when it receives logs from the Sumo Logic source that collected the logs. Replicating the logic of the FER in a Local Configuration in the parser usually solves this problem.  - * Sumo Logic Ingest Mappings for a data source should always be disabled when you’ve configured a Sumo Logic parser for that same data source. Otherwise, a single message might result in multiple Cloud SIEM Records.  + * Sumo Logic Ingest Mappings for a data source should always be disabled when you’ve configured a Sumo Logic parser for that same data source. Otherwise, a single message might result in multiple Cloud SIEM records.  * A Local Configuration to a parser is an override to out-of-the-box behavior. For this reason, if you’re having trouble with a parser, checking out any Local Configurations is important. Make sure to test the parser without Local Configurations so you can verify whether the problem is with the parser itself, or related to an external factor.    4. Use the right parser for your data format. Some data sources, for example, Windows Event Logs, can send data in multiple different formats and using the correct parser for the format in use is required. diff --git a/docs/cse/schema/parsing-language-reference-guide.md b/docs/cse/schema/parsing-language-reference-guide.md index 69489b1004..50e14a9eb4 100644 --- a/docs/cse/schema/parsing-language-reference-guide.md +++ b/docs/cse/schema/parsing-language-reference-guide.md @@ -2,16 +2,16 @@ id: parsing-language-reference-guide title: Parsing Language Reference Guide sidebar_label: Parsing Language Reference -description: Parsing is the first step in the Cloud SIEM Record processing pipeline +description: Parsing is the first step in the Cloud SIEM record processing pipeline. --- This topic describes the Cloud SIEM parsing language, which you can use to write custom parsers. ## What is parsing? -Parsing is the first step in the Cloud SIEM [Record processing pipeline](/docs/cse/schema/record-processing-pipeline) — it is the process of creating a set of key-value pairs that reflect all of the information in an incoming raw message. We refer to the result of the parsing process as a *field dictionary*. The raw message is retained.  +Parsing is the first step in the Cloud SIEM [record processing pipeline](/docs/cse/schema/record-processing-pipeline) — it is the process of creating a set of key-value pairs that reflect all of the information in an incoming raw message. We refer to the result of the parsing process as a *field dictionary*. The raw message is retained.  -Parsers are written in a specialized Sumo Parsing Language. The parser code resides in a a parser configuration object. At runtime, parser code is executed by the Sumo Logic parsing engine. +Parsers are written in a specialized Sumo Logic Parsing Language. The parser code resides in a a parser configuration object. At runtime, parser code is executed by the Sumo Logic parsing engine. ## Key concepts @@ -145,7 +145,7 @@ Parses Windows XML messages from Cloud SIEM Windows Sensor.  ## Mapping hints -After parsing, the next step in the Cloud SIEM Record processing pipeline is log mapping, which is the process of mapping fields that were parsed out of messages to Cloud SIEM schema attributes.  +After parsing, the next step in the Cloud SIEM record processing pipeline is log mapping, which is the process of mapping fields that were parsed out of messages to Cloud SIEM schema attributes.  Every parser must provide *mapping hints* that provide information Cloud SIEM can use to select the correct log mapper for parsed messages. You do this with the MAPPER attribute. For more information, see [MAPPER](#mapper). @@ -170,7 +170,7 @@ You can declare your own variables in a parser. To ensure that a variable is not Messages are parsed to create a dictionary of field values, a start time, and an end time. -When choosing a field name, avoid using non-alphanumeric characters unless that goes against the conventional practice or a well-known name. For instance, in PAN-firewall parser there is a field named `X-Forwarded-For`. That name was selected after the well-known protocol header. Any other name would not be as easily recognized. But, whenever possible, it’s preferable to stick with alphanumeric names so that they won’t need quoting when they are used in Sumo Platform features, such as Sumo Logic core platform log and metric queries, action templates, and dashboards. +When choosing a field name, avoid using non-alphanumeric characters unless that goes against the conventional practice or a well-known name. For instance, in PAN-firewall parser there is a field named `X-Forwarded-For`. That name was selected after the well-known protocol header. Any other name would not be as easily recognized. But, whenever possible, it’s preferable to stick with alphanumeric names so that they won’t need quoting when they are used in Sumo Logic Platform features, such as Sumo Logic core platform log and metric queries, action templates, and dashboards. Field names beginning with `_$` (underscore followed by the dollar sign) aren’t saved in the field dictionary, but can be used to pass values from one part of the parsing process to another (from a parser to a transform, for instance). @@ -183,7 +183,7 @@ The key principal: When selecting a name for the field, stay as close to the nam The `_starttime` and `_endtime` fields are normally assigned values using [START_TIME_FIELD](#start_time_field) and [END_TIME_FIELD](#end_time_field).  Note that if none of [DEFAULT_START_TIME](#default_start_time),  [DEFAULT_END_TIME](#default_end_time), START_TIME_FIELD or END_TIME_FIELD are defined `_starttime` and `_endtime` will not be included in the field dictionary. -If `_starttime` is defined (at minimum, `START_TIME_FIELD` has been specified in the parser), it will be used as the Record timestamp. If `_starttime` is not defined, the timestamp should be set by the Cloud SIEM log mapper that processes the Record, typically by mapping a parsed field to the `timestamp` schema attribute. +If `_starttime` is defined (at minimum, `START_TIME_FIELD` has been specified in the parser), it will be used as the record timestamp. If `_starttime` is not defined, the timestamp should be set by the Cloud SIEM log mapper that processes the record, typically by mapping a parsed field to the `timestamp` schema attribute. ### Representation of “no value” @@ -579,7 +579,7 @@ Provides information that tells Cloud SIEM which log mapper should process the p * `MAPPER:event_id = {{eventType}}-{{eventName}}` :::note -Looking up a mapper using `product`, `vendor`, and `event_id` will return all [structured mappings](create-structured-log-mapping.md) that are configured with the same attribute values, and could result in more than one Record being created.  +Looking up a mapper using `product`, `vendor`, and `event_id` will return all [structured mappings](create-structured-log-mapping.md) that are configured with the same attribute values, and could result in more than one record being created.  ::: **Syntax** diff --git a/docs/cse/schema/record-processing-pipeline.md b/docs/cse/schema/record-processing-pipeline.md index 55ea92afdb..58e8515fd6 100644 --- a/docs/cse/schema/record-processing-pipeline.md +++ b/docs/cse/schema/record-processing-pipeline.md @@ -2,22 +2,22 @@ id: record-processing-pipeline title: Record Processing Pipeline sidebar_label: Record Processing Pipeline -description: How Cloud SIEM transforms incoming raw messages into Records. +description: How Cloud SIEM transforms incoming raw messages into records. --- -This topic describes how Cloud SIEM transforms incoming raw messages into Records. For each message received, Cloud SIEM creates a Record, or in rare cases, multiple Records.  +This topic describes how Cloud SIEM transforms incoming raw messages into records. For each message received, Cloud SIEM creates a record, or in rare cases, multiple records.  ## Overview of processing steps -A Record contains the information from an incoming message, transformed and enhanced in a variety of ways to enable and enhance the Cloud SIEM rule evaluation process. The processing steps include: +A record contains the information from an incoming message, transformed and enhanced in a variety of ways to enable and enhance the Cloud SIEM rule evaluation process. The processing steps include: * Key-value pairs are extracted from messages. * Source-specific fields are mapped to Cloud SIEM schema attributes. * The values of fields that contain usernames and hostnames, which vary considerably across message sources, are normalized to a standard format. * Records are enriched with additional context information about the IP addresses, URLs, and domains in messages. -* Message fields are compared to Match Lists, typically used to define lists of trusted entities; when a match is found, attributes are added to the Record to reflect that. -* Message fields are compared to Suppressed Lists, which are used to define field values that, when encountered in a message, prevent any rule that the message matches from firing. -* Message fields are compared to Threat Intel lists; when a match is found, attributes are added to the Record to reflect that. +* Message fields are compared to match lists, typically used to define lists of trusted entities; when a match is found, attributes are added to the record to reflect that. +* Message fields are compared to suppressed lists, which are used to define field values that, when encountered in a message, prevent any rule that the message matches from firing. +* Message fields are compared to threat intel lists; when a match is found, attributes are added to the record to reflect that. ## Extract key-value pairs from messages @@ -32,20 +32,20 @@ The key-value pairs are input to the next step of the process: mapping. ## Map message fields to schema attributes -The [mapping process](/docs/cse/schema/create-structured-log-mapping/) creates a Record from the key-value pairs that were extracted from a message, and maps a subset of the keys to Cloud SIEM schema attributes.  +The [mapping process](/docs/cse/schema/create-structured-log-mapping/) creates a record from the key-value pairs that were extracted from a message, and maps a subset of the keys to Cloud SIEM schema attributes.  Mapping solves a particular problem: messages from different products use different names to identify users, applications, devices and so on. For example, some messages may refer to a source IP address as `sourceIP`, while others use `sourceIpAddress`. We need a standard set of names for the data that most messages are likely to contain. The [Cloud SIEM schema](/docs/cse/schema) defines that standard set of names.  -What’s the benefit of mapping? It results in Records that use a common (standard) name for fields that hold the same sort of data, regardless of the source of the incoming message. The result: the same Cloud SIEM rule can be applied to all Records, regardless of the message source. +What’s the benefit of mapping? It results in records that use a common (standard) name for fields that hold the same sort of data, regardless of the source of the incoming message. The result: the same Cloud SIEM rule can be applied to all records, regardless of the message source. ## Normalize usernames and hostnames -[Username and hostname normalization](/docs/cse/schema/username-and-hostname-normalization/) is the process of transforming the value of Record attributes that contain usernames and hostnames into a standard format. The normalized value replaces the non-normalized value in a Record. The non-normalized values of hostname and usernames are retained in a `_raw` field in the Record. +[Username and hostname normalization](/docs/cse/schema/username-and-hostname-normalization/) is the process of transforming the value of record attributes that contain usernames and hostnames into a standard format. The normalized value replaces the non-normalized value in a record. The non-normalized values of hostname and usernames are retained in a `_raw` field in the record. Why normalize? Assume Cloud SIEM receives messages with an email-type field "bob@bobsbaitshop.com" and username-type field  "bob". We can use normalization to transform "bob@bobsbaitshop.com" to "bob", allowing the username and email to be correlated together. Normalization allows for common name forms among Active Directory, AWS, and fully qualified domain names to be normalized into a domain and username form.   -The values of the following schema attributes are normalized into a standard format, which replaces the non-normalized field value in the Record. +The values of the following schema attributes are normalized into a standard format, which replaces the non-normalized field value in the record. * `device_hostname` * `dstDevice_hostname` @@ -55,40 +55,40 @@ The values of the following schema attributes are normalized into a standard for ## Entity Lookup Table processing -[Entity Lookup Tables](/docs/cse/records-signals-entities-insights/configure-entity-lookup-table) allow you to define your own hostname and username normalization rules. After the normalization described in the previous step is performed, any normalization you’ve configured in Entity Lookup Tables is applied. +[Entity lookup tables](/docs/cse/records-signals-entities-insights/configure-entity-lookup-table) allow you to define your own hostname and username normalization rules. After the normalization described in the previous step is performed, any normalization you’ve configured in entity lookup tables is applied. -## Enrich Records with IP address, URL, and domain info +## Enrich records with IP address, URL, and domain info -Cloud SIEM adds a number of enrichment attributes to Records. Enrichment attributes are fields that provide extra context to the Record based on attribute values encountered in a Record. Specifically, Cloud SIEM adds enrichment attributes for IP addresses, URLs, and domains in a Record. +Cloud SIEM adds a number of enrichment attributes to records. Enrichment attributes are fields that provide extra context to the record based on attribute values encountered in a record. Specifically, Cloud SIEM adds enrichment attributes for IP addresses, URLs, and domains in a record. ## IP address enrichment -If a Record contains `device_IP`, `srcDevice_ip`, or another field that contains an IP address,  it adds a set of geolocation attributes to the Record, such as the ASN number and organization, the city and country where the IP address is located, and so on.  +If a record contains `device_IP`, `srcDevice_ip`, or another field that contains an IP address,  it adds a set of geolocation attributes to the record, such as the ASN number and organization, the city and country where the IP address is located, and so on.  -The name of an enrichment attribute is formed by appending an underscore plus a string that identifies the enrichment attribute to the original attribute name. For example, if a Record contains `device_IP,` the enrichment attributes look like `device_ip_asnNumber`, `device_ip_asnOrg`, `device_ip_city` and so on.  +The name of an enrichment attribute is formed by appending an underscore plus a string that identifies the enrichment attribute to the original attribute name. For example, if a record contains `device_IP,` the enrichment attributes look like `device_ip_asnNumber`, `device_ip_asnOrg`, `device_ip_city` and so on.  ## URL and domain enrichment -If a Record contains `http_url` or another field that contains an URL, Cloud SIEM parses the URL and creates attributes to contain the URL components, like the protocol and top level domain fields.  +If a record contains `http_url` or another field that contains an URL, Cloud SIEM parses the URL and creates attributes to contain the URL components, like the protocol and top level domain fields.  -For both URLs and domains, Cloud SIEM adds a set of enrichment attributes to Records, such as entropy calculations for the FQDN and root domain, the Alexa ranking, and so on.  +For both URLs and domains, Cloud SIEM adds a set of enrichment attributes to records, such as entropy calculations for the FQDN and root domain, the Alexa ranking, and so on.  -The name of each added attribute is formed by appending an underscore plus a string that identifies the enrichment attribute to the original attribute name. For example, the attributes added to a Record that contains `http_url`, will look like `http_url_tld`, `http_url_protocol`, `http_url_alexaRank`, and so on.  +The name of each added attribute is formed by appending an underscore plus a string that identifies the enrichment attribute to the original attribute name. For example, the attributes added to a record that contains `http_url`, will look like `http_url_tld`, `http_url_protocol`, `http_url_alexaRank`, and so on.  -## Match List processing +## Match list processing -Cloud SIEM’s Match List feature allows you to leverage lists of important identifiers that, if they exist in an incoming message, indicate the message should be exempt from ordinary rule processing, or treated differently in some way. Typically, Match Lists are used to define “allow lists” of items, like IP addresses, URLs, and hostnames. Many Cloud SIEM rules reference Match Lists; the lists are predefined, and you populate them with indicators that exist in your environment.  +Cloud SIEM’s match list feature allows you to leverage lists of important identifiers that, if they exist in an incoming message, indicate the message should be exempt from ordinary rule processing, or treated differently in some way. Typically, match lists are used to define “allow lists” of items, like IP addresses, URLs, and hostnames. Many Cloud SIEM rules reference match lists; the lists are predefined, and you populate them with indicators that exist in your environment.  -For example, vulnerability scanners often set off false alarms in security data, as they intentionally mimic the behavior of an attacker. Given that this behavior is safe and expected, you don’t want scanner activities to fire a rule. That’s what a Match List is for. A Cloud SIEM analyst can populate a Match List called “vuln_scanners” that contains the IP addresses of your scanners. +For example, vulnerability scanners often set off false alarms in security data, as they intentionally mimic the behavior of an attacker. Given that this behavior is safe and expected, you don’t want scanner activities to fire a rule. That’s what a match list is for. A Cloud SIEM analyst can populate a match list called “vuln_scanners” that contains the IP addresses of your scanners. -Cloud SIEM compares the contents of every message to your Match Lists. When it finds a match, it appends fields two fields to the Record: `listMatches` and `matchedItems`. `listMatches` contains the names of lists that were matched against the Record, and  `matchedItems` contains the actual key-value pairs that were matched. You can take advantage of the appended data in searches and rules. So, a Cloud SIEM rule can see from a Record that matches a rule condition that the IP address in the Record is on the  “vuln_scanners” Match List, and thus know that the rule shouldn’t fire. For more information, see [Create a Match List](/docs/cse/match-lists-suppressed-lists/create-match-list). +Cloud SIEM compares the contents of every message to your match lists. When it finds a match, it appends fields two fields to the record: `listMatches` and `matchedItems`. `listMatches` contains the names of lists that were matched against the record, and  `matchedItems` contains the actual key-value pairs that were matched. You can take advantage of the appended data in searches and rules. So, a Cloud SIEM rule can see from a record that matches a rule condition that the IP address in the record is on the  “vuln_scanners” match list, and thus know that the rule shouldn’t fire. For more information, see [Create a Match List](/docs/cse/match-lists-suppressed-lists/create-match-list). -## Suppressed List processing +## Suppressed list processing -Cloud SIEM's Suppressed Lists feature is similar to Match Lists. A Suppressed List is a list of values of a particular field type, for example, an IP address or a file hash. When an incoming message contains a value found on a Suppressed List, Cloud SIEM prevents any rules that the incoming message matches from firing. +Cloud SIEM's suppressed lists feature is similar to match lists. A suppressed list is a list of values of a particular field type, for example, an IP address or a file hash. When an incoming message contains a value found on a suppressed list, Cloud SIEM prevents any rules that the incoming message matches from firing. -## Threat Intel processing +## Threat intel processing -Cloud SIEM has another feature that is similar to Match Lists: Threat Intel. Like Match Lists, Threat Intel lists are lists of indicators and identifiers configured by a Cloud SIEM analyst. While similar to Match Lists, Threat Intel lists are intended for negative identifiers that should definitely fire a Signal. So, whenever a rule detects a Record field that matches an item on a Threat Intel list, it always results in a Signal.  +Cloud SIEM has another feature that is similar to match lists: threat intel. Like match lists, threat intel lists are lists of indicators and identifiers configured by a Cloud SIEM analyst. While similar to match lists, threat intel lists are intended for negative identifiers that should definitely fire a signal. So, whenever a rule detects a record field that matches an item on a threat intel list, it always results in a signal.  -Cloud SIEM’s Threat Intel list processing is similar to Match List processing. Incoming messages are compared to all Threat Intel lists. When a match is found, Cloud SIEM updates the `listMatches` field in the Record with the name of the matched threat list, the matching key-value pair from the message, and the string “threat”. For more information, see the [Threat Intelligence](/docs/cse/rules/about-cse-rules#threat-intelligence) section in the *About Cloud SIEM Rules* topic. +Cloud SIEM’s threat intel list processing is similar to match list processing. Incoming messages are compared to all threat intel lists. When a match is found, Cloud SIEM updates the `listMatches` field in the record with the name of the matched threat list, the matching key-value pair from the message, and the string “threat”. For more information, see the [Threat Intelligence](/docs/cse/rules/about-cse-rules#threat-intelligence) section in the *About Cloud SIEM Rules* topic. diff --git a/docs/cse/schema/username-and-hostname-normalization.md b/docs/cse/schema/username-and-hostname-normalization.md index 99d9dba999..9577b11d39 100644 --- a/docs/cse/schema/username-and-hostname-normalization.md +++ b/docs/cse/schema/username-and-hostname-normalization.md @@ -7,7 +7,7 @@ description: Learn about how Cloud SIEM normalizes usernames and hostnames durin import useBaseUrl from '@docusaurus/useBaseUrl'; -Cloud SIEM normalizes usernames and hostnames in Records during the parsing and mapping process. This allows for common name forms among Active Directory, AWS, and fully qualified domain names to be normalized into a domain and username form. +Cloud SIEM normalizes usernames and hostnames in records during the parsing and mapping process. This allows for common name forms among Active Directory, AWS, and fully qualified domain names to be normalized into a domain and username form. ## Getting data into Cloud SIEM for normalization From cee44b1ccc1d18950d3a5bc186466b5108452274 Mon Sep 17 00:00:00 2001 From: John Pipkin Date: Tue, 17 Dec 2024 17:40:22 -0600 Subject: [PATCH 2/6] Make terms lowercase in 'Sensors' section --- docs/cse/sensors/index.md | 2 +- docs/cse/sensors/ingest-zeek-logs.md | 4 ++-- .../cse/sensors/network-sensor-deployment-guide.md | 14 +++++++------- docs/cse/sensors/network-sensor-troubleshooting.md | 14 +++++++------- docs/cse/sensors/sensor-download-locations.md | 6 +++--- docs/reuse/cloud-siem-network-sensor-eol.md | 2 +- 6 files changed, 21 insertions(+), 21 deletions(-) diff --git a/docs/cse/sensors/index.md b/docs/cse/sensors/index.md index fdbef6fc5d..6ad1e09bd3 100644 --- a/docs/cse/sensors/index.md +++ b/docs/cse/sensors/index.md @@ -21,7 +21,7 @@ In this section, we'll introduce the following concepts:
Database icon

Sensor Download Locations

 -

Learn about where to download the Cloud SIEM Network sensor that's specific to your Cloud SIEM deployment.

+

Learn about where to download the Cloud SIEM Network Sensor that's specific to your Cloud SIEM deployment.

diff --git a/docs/cse/sensors/ingest-zeek-logs.md b/docs/cse/sensors/ingest-zeek-logs.md index e195cf0148..f45560baf6 100644 --- a/docs/cse/sensors/ingest-zeek-logs.md +++ b/docs/cse/sensors/ingest-zeek-logs.md @@ -30,7 +30,7 @@ After configuring the appropriate source, use one of the methods described in [E ### Enable parsing and mapping of Zeek logs -This configuration step is required to ensure that Cloud SIEM knows how to parse incoming Zeek logs, correctly map the log fields to schema attributes, and create Cloud SIEM Records. The most important bit of information is what type of data a particular log contains. Zeek has a variety of log types, for example `conn` for TCP/UDP/ICMP connections, `http` for HTTP requests and replies, and `ftp` for FTP activity. +This configuration step is required to ensure that Cloud SIEM knows how to parse incoming Zeek logs, correctly map the log fields to schema attributes, and create Cloud SIEM records. The most important bit of information is what type of data a particular log contains. Zeek has a variety of log types, for example `conn` for TCP/UDP/ICMP connections, `http` for HTTP requests and replies, and `ftp` for FTP activity. So, how to determine whether a Zeek log is a `conn`, `http`, `ftp`, or some other log type? Zeek logs don’t contain a key that explicitly holds a value that is only the log type identifier. There are two options for dealing with this: @@ -111,7 +111,7 @@ Perform these steps for each of the FERs. This section describes using the Cloud SIEM Network Sensor. [Network Sensor has reached its end of life](/docs/cse/sensors/network-sensor-end-of-life/). Instead, use Zeek. For more information, see [Supported collection method: Sumo Logic Source](#supported-collection-method-sumo-logic-source) above. ::: -You can use Cloud SIEM’s Network Sensor to collect Zeek logs and upload them to an HTTP Source on a Sumo Logic Hosted Collector. This method ensures that supported Bro policies are enabled and that the supported Bro output format is configured. It also results in the creation of Cloud SIEM Records from the raw Zeek log messages. For instructions, see [Network Sensor Deployment Guide](/docs/cse/sensors/network-sensor-deployment-guide). +You can use Cloud SIEM’s Network Sensor to collect Zeek logs and upload them to an HTTP Source on a Sumo Logic Hosted Collector. This method ensures that supported Bro policies are enabled and that the supported Bro output format is configured. It also results in the creation of Cloud SIEM records from the raw Zeek log messages. For instructions, see [Network Sensor Deployment Guide](/docs/cse/sensors/network-sensor-deployment-guide). The Network Sensor extracts files observed over cleartext protocols that match selected MIME types. You can configure what types will be extracted using the [extracted_file_types](/docs/cse/sensors/network-sensor-deployment-guide) property in the Network Sensor’s configuration file, `trident-sensor.cfg`. By default the sensor will upload password-protected zip files and the following types of executables: diff --git a/docs/cse/sensors/network-sensor-deployment-guide.md b/docs/cse/sensors/network-sensor-deployment-guide.md index e533044160..e3a83a59f0 100644 --- a/docs/cse/sensors/network-sensor-deployment-guide.md +++ b/docs/cse/sensors/network-sensor-deployment-guide.md @@ -46,11 +46,11 @@ Forward proxies, such as HTTP web proxies, broker client connections to the inte The following diagram Illustrates optimal sensor positioning prior to a web proxy. -Network sensor deployment +Network Sensor deployment -Sumo Logic advises positioning network sensors for visibility at a monitoring point immediately in front of the proxy server(s). This allows the sensor to record client source addresses and to see all web requests prior to content filtering. This is an important factor for a number of Cloud SIEM’s rules and analytics, which rely on knowing the “true” source of requests. Because a number of threats beacon to remote internet servers, seeing even those requests that are filtered by a proxy server is important for monitoring and response. +Sumo Logic advises positioning Network Sensors for visibility at a monitoring point immediately in front of the proxy server(s). This allows the sensor to record client source addresses and to see all web requests prior to content filtering. This is an important factor for a number of Cloud SIEM’s rules and analytics, which rely on knowing the “true” source of requests. Because a number of threats beacon to remote internet servers, seeing even those requests that are filtered by a proxy server is important for monitoring and response. -Positioning the network sensor after a forward proxy is not advised. This placement results in the sensor seeing all traffic sourced from the proxy and complicates (or renders impossible) the ability to determine which assets or users on the LAN were the origin of the traffic. +Positioning the Network Sensor after a forward proxy is not advised. This placement results in the sensor seeing all traffic sourced from the proxy and complicates (or renders impossible) the ability to determine which assets or users on the LAN were the origin of the traffic. #### Explicit versus transparent forward proxies and server access logs @@ -88,7 +88,7 @@ This section describes resource requirements and prerequisites for Network Senso ### Host resource requirements -We recommend installing the network sensor on a host with at least two interfaces - one for traffic monitoring and one for management. That way, the sensor doesn't process and upload traffic associated with sensor management for analysis. +We recommend installing the Network Sensor on a host with at least two interfaces - one for traffic monitoring and one for management. That way, the sensor doesn't process and upload traffic associated with sensor management for analysis. The system upon which you install the Network Sensor must have the following resources, at a minimum. Depending on expected throughput, additional core, memory, and storage resources may be required, as shown in [Throughput-dependent resource requirements](#throughput-dependent-resource-requirements) below.  @@ -98,7 +98,7 @@ below.  | CentOS 7 or Ubuntu 16, 18, 20 | 4 | 4GB | 250GB | :::note -Before you deploy the network sensor, make sure you know the TAP or SPAN interface upon which captured data is available. +Before you deploy the Network Sensor, make sure you know the TAP or SPAN interface upon which captured data is available. ::: ### Prerequisites for CentOS @@ -127,7 +127,7 @@ reboot | 1.75gbps | 10 | 28GB | 500GB | | 2gbps+ | Consult your SE. | Consult SE
(Estimate is 4GB per 250Mbs) | Consult your SE. | -### Outbound Firewall Rules +### Outbound firewall rules See [Securing access to Sumo Logic infrastructure via DNS name or IP address](/docs/api/getting-started#securing-access-to-sumo-logic-infrastructure-via-dns-name-or-ip-address) for information on how to configure your firewall for outbound access to Sumo Logic. @@ -342,7 +342,7 @@ Configured by wizard? No ### no_data_cutoff -**Description.** Threshold used to determine when data is being captured by the Network Sensor (value is in Records per second). When Records per second is below this threshold for a status report interval (default is 5 minutes) the report will be counted towards [no_data_restart_threshold](#no_data_restart_threshold). Use this parameter to tune automatic restarts of the Network Sensor when no data is being captured/reported (requires `no_data_restart_threshold` to be set, the recommended value for this parameter is 3, as described below ). +**Description.** Threshold used to determine when data is being captured by the Network Sensor (value is in records per second). When records per second is below this threshold for a status report interval (default is 5 minutes) the report will be counted towards [no_data_restart_threshold](#no_data_restart_threshold). Use this parameter to tune automatic restarts of the Network Sensor when no data is being captured/reported (requires `no_data_restart_threshold` to be set, the recommended value for this parameter is 3, as described below ). **Default value.** 3 diff --git a/docs/cse/sensors/network-sensor-troubleshooting.md b/docs/cse/sensors/network-sensor-troubleshooting.md index 664982429e..0ab46b9f12 100644 --- a/docs/cse/sensors/network-sensor-troubleshooting.md +++ b/docs/cse/sensors/network-sensor-troubleshooting.md @@ -11,7 +11,7 @@ import SensorEOL from '../../reuse/cloud-siem-network-sensor-eol.md'; ::: -The Cloud SIEM Network Sensor is a flexible network security monitor that monitors IP networks and collects flow and protocol session data, building audit records of network communications. As with all network sensors, performance is a key consideration for proper operation and comprehensive data collection. The installation of the Cloud SIEM network sensor configures the sensor with reasonable defaults for many environments. For other environments, such as high throughput deployments, Sumo Logic advises the use of a supported 3rd party Bro/Zeek sensor offering or a custom Zeek cluster deployment. +The Cloud SIEM Network Sensor is a flexible network security monitor that monitors IP networks and collects flow and protocol session data, building audit records of network communications. As with all Network Sensors, performance is a key consideration for proper operation and comprehensive data collection. The installation of the Cloud SIEM Network Sensor configures the sensor with reasonable defaults for many environments. For other environments, such as high throughput deployments, Sumo Logic advises the use of a supported 3rd party Bro/Zeek sensor offering or a custom Zeek cluster deployment. ## General Troubleshooting @@ -45,7 +45,7 @@ A number of statistics named with “errors” are available. All of them ideall ### PF_RING -PF_RING enables accelerated network packet capture under Linux and is included in the default Cloud SIEM network sensor installation. +PF_RING enables accelerated network packet capture under Linux and is included in the default Cloud SIEM Network Sensor installation. PF_RING configuration information is available in `/proc/net/pf_ring/info`. Information on interfaces may be found in `/proc/net/pf_ring/dev//info`. @@ -59,15 +59,15 @@ It can be helpful to verify that Bro is linked against the PF_RING enabled libpc $(ldd /opt/trident/sensor/bro/bin/zeek | awk '{print $3}' | grep libpcap) >/dev/null && echo "PF_RING enabled" ``` -### Network Sensor stops capturing traffic +### Network sensor stops capturing traffic -Zeek can get into a state where it runs out of memory and stops processing traffic but does not crash. This has been observed on RHEL 7.9. To automatically restart the sensor when consecutive status reports with low Records per second is observed use [no_data_restart_threshold](/docs/cse/sensors/network-sensor-deployment-guide#no_data_restart_threshold) (recommended value 3), and [no_data_cutoff](/docs/cse/sensors/network-sensor-deployment-guide#no_data_cutoff) to tune the record threshold if needed. +Zeek can get into a state where it runs out of memory and stops processing traffic but does not crash. This has been observed on RHEL 7.9. To automatically restart the sensor when consecutive status reports with low records per second is observed use [no_data_restart_threshold](/docs/cse/sensors/network-sensor-deployment-guide#no_data_restart_threshold) (recommended value 3), and [no_data_cutoff](/docs/cse/sensors/network-sensor-deployment-guide#no_data_cutoff) to tune the record threshold if needed. ## Monitoring Capture Performance -Security monitoring can be complex. Network data capture is a system with many layers, and degradation or faults at one layer can affect the whole. Performance starts at the initial traffic acquisition source (i.e. TAPs, SPANs/port mirrors) and ends with the monitoring software itself (Bro/Zeek). Along the way a number of hardware and software components are involved, such as cabling, capture network interface cards, CPU, memory, drivers, OS kernel, memory buffers, and numerous settings. Some work fine as defaults and others must be tuned correctly. All components must be monitored and validated for proper operation. This document provides an overview of how to properly configure and monitor some of the important components in a network sensor deployment. +Security monitoring can be complex. Network data capture is a system with many layers, and degradation or faults at one layer can affect the whole. Performance starts at the initial traffic acquisition source (i.e. TAPs, SPANs/port mirrors) and ends with the monitoring software itself (Bro/Zeek). Along the way a number of hardware and software components are involved, such as cabling, capture network interface cards, CPU, memory, drivers, OS kernel, memory buffers, and numerous settings. Some work fine as defaults and others must be tuned correctly. All components must be monitored and validated for proper operation. This document provides an overview of how to properly configure and monitor some of the important components in a Network Sensor deployment. -Sumo Logic recommends that network sensor admins monitor and collect performance statistics from deployed sensors. Doing so can help with tracking and spotting faults when they occur and help plan for adequate system resources.  +Sumo Logic recommends that Network Sensor admins monitor and collect performance statistics from deployed sensors. Doing so can help with tracking and spotting faults when they occur and help plan for adequate system resources.  In the examples below, we use `eno1` as the example interface name. Substitute the proper interface name(s) on your sensor as needed. @@ -106,7 +106,7 @@ Having verified performance of the data delivery path, the next focus area is Br ## CaptureLoss -An important metric Zeek log that is collected from the Cloud SIEM network sensor is the notice `CaptureLoss::Too_Much_Loss`. Zeek internally tracks loss rates by observing when streams arrive with gaps indicating missing segments in the stream. Because this metric relates directly to traffic monitored by Zeek, it may either indicate packet loss in Zeek itself, or a loss condition happening elsewhere upstream from Zeek (anywhere along the line). This notice is logged on a periodic basis when a configured threshold is exceeded and is the topic of a key FAQ. https://www.zeek.org/documentation/faq.html#how-can-i-reduce-the-amount-of-captureloss-or-dropped-packets-notice It is possible to analyze occurrences of CaptureLoss notices in Cloud SIEM using the following query in an Sumo Logic log search tab. +An important metric Zeek log that is collected from the Cloud SIEM Network Sensor is the notice `CaptureLoss::Too_Much_Loss`. Zeek internally tracks loss rates by observing when streams arrive with gaps indicating missing segments in the stream. Because this metric relates directly to traffic monitored by Zeek, it may either indicate packet loss in Zeek itself, or a loss condition happening elsewhere upstream from Zeek (anywhere along the line). This notice is logged on a periodic basis when a configured threshold is exceeded and is the topic of a key FAQ. https://www.zeek.org/documentation/faq.html#how-can-i-reduce-the-amount-of-captureloss-or-dropped-packets-notice It is possible to analyze occurrences of CaptureLoss notices in Cloud SIEM using the following query in an Sumo Logic log search tab. `_sourceCategory = "cse/network/notice" | where note = "CaptureLoss::Too_Much_Loss"` diff --git a/docs/cse/sensors/sensor-download-locations.md b/docs/cse/sensors/sensor-download-locations.md index d7d52bf4d9..fff3cdeae3 100644 --- a/docs/cse/sensors/sensor-download-locations.md +++ b/docs/cse/sensors/sensor-download-locations.md @@ -1,7 +1,7 @@ --- id: sensor-download-locations title: Sensor Download Locations -description: The Cloud SIEM Network sensor can be downloaded from a static URL that is specific to your Cloud SIEM deployment. +description: The Cloud SIEM Network Sensor can be downloaded from a static URL that is specific to your Cloud SIEM deployment. --- import useBaseUrl from '@docusaurus/useBaseUrl'; @@ -13,9 +13,9 @@ import SensorEOL from '../../reuse/cloud-siem-network-sensor-eol.md'; The Cloud SIEM Network Sensor can be downloaded from a static URL that is specific to your Cloud SIEM deployment. Each Sumo Logic deployment has URLs used to download sensor software. If you are not sure which endpoint to use, see How can I determine which endpoint I should use? -## Installing the Network sensor +## Installing the Network Sensor -After downloading the Network sensor appropriate for your system architecture, run this command: +After downloading the Network Sensor appropriate for your system architecture, run this command: ```bash sudo wget -q -O - | sudo /bin/bash diff --git a/docs/reuse/cloud-siem-network-sensor-eol.md b/docs/reuse/cloud-siem-network-sensor-eol.md index fe06d6863a..fe7873258e 100644 --- a/docs/reuse/cloud-siem-network-sensor-eol.md +++ b/docs/reuse/cloud-siem-network-sensor-eol.md @@ -1 +1 @@ -This article describes using the Cloud SIEM Network Sensor. [Network Sensor has reached its end of life](/docs/cse/sensors/network-sensor-end-of-life/). Instead, use Zeek. For more information, see [Ingest Zeek Logs](/docs/cse/sensors/ingest-zeek-logs/). \ No newline at end of file +This article describes using the Cloud SIEM Network Sensor. [The Network Sensor has reached its end of life](/docs/cse/sensors/network-sensor-end-of-life/). Instead, use Zeek. For more information, see [Ingest Zeek Logs](/docs/cse/sensors/ingest-zeek-logs/). \ No newline at end of file From 2584a1dd14033058301f6d6117ba58422cfdcb81 Mon Sep 17 00:00:00 2001 From: John Pipkin Date: Wed, 18 Dec 2024 09:52:47 -0600 Subject: [PATCH 3/6] Make terms lowercase in 'Integrations' section --- .../configuring-threatq-source-in-cse.md | 10 ++++---- .../enable-virustotal-enrichment.md | 10 ++++---- .../enrichments-and-indicators.md | 10 ++++---- docs/cse/integrations/index.md | 6 ++--- .../integrations/insight-enrichment-server.md | 24 +++++++++---------- .../integrate-cse-with-taxii-feed.md | 2 +- .../security-incident-response-integration.md | 20 ++++++++-------- 7 files changed, 41 insertions(+), 41 deletions(-) diff --git a/docs/cse/integrations/configuring-threatq-source-in-cse.md b/docs/cse/integrations/configuring-threatq-source-in-cse.md index 468f45c6ff..de404176bc 100644 --- a/docs/cse/integrations/configuring-threatq-source-in-cse.md +++ b/docs/cse/integrations/configuring-threatq-source-in-cse.md @@ -39,15 +39,15 @@ After you set up your ThreatQ source, it will appear on the Threat Intel page in ## Looking for ThreatQ indicators using Cloud SIEM rules -As with other threat intel sources, Cloud SIEM compares each incoming Record to the indicators provided by your ThreatQ source.  +As with other threat intel sources, Cloud SIEM compares each incoming record to the indicators provided by your ThreatQ source.  -When a Record contains a value that matches an entry in one or more threat intel lists, two fields in the Record get populated: a `listMatches` field that contains the names of threat intel lists that the Record matched, and a `matchedItems` field that contains the actual key-value pairs that were matched. In addition, the string “threat” is added to the `listMatches` field.   +When a record contains a value that matches an entry in one or more threat intel lists, two fields in the record get populated: a `listMatches` field that contains the names of threat intel lists that the record matched, and a `matchedItems` field that contains the actual key-value pairs that were matched. In addition, the string “threat” is added to the `listMatches` field.   -For example, give a Record whose `SourceIp` column matches a entry in “My Threat Intel List”, the `listMatches` field added to the record would look like this: +For example, give a record whose `SourceIp` column matches a entry in “My Threat Intel List”, the `listMatches` field added to the record would look like this: `listMatches: ['My Threat Intel List', 'column:SourceIp', 'threat']` -Because the threat intel information is persisted within Records, you can reference it downstream in both rules and search. To leverage the information in a rule, you extend your rule expression with the `array_contains` function. The syntax is: +Because the threat intel information is persisted within records, you can reference it downstream in both rules and search. To leverage the information in a rule, you extend your rule expression with the `array_contains` function. The syntax is: `array_contains(listMatches, "threat_intel_list_name")` @@ -59,5 +59,5 @@ where  If the name of the list you are referencing with `array_contains` contains any spaces, replace the spaces with underscores. For example, if the list name is *my list*, refer to it as *my_list*. ::: -For more information, see the [Rules and other content](/docs/cse/rules/about-cse-rules#rules-and-other-content) in the *About Cloud SIEM Rules* topic. +For more information, see [Rules and other content](/docs/cse/rules/about-cse-rules#rules-and-other-content) in the *About Cloud SIEM Rules* topic.   diff --git a/docs/cse/integrations/enable-virustotal-enrichment.md b/docs/cse/integrations/enable-virustotal-enrichment.md index 54c113ba7f..cea95109dd 100644 --- a/docs/cse/integrations/enable-virustotal-enrichment.md +++ b/docs/cse/integrations/enable-virustotal-enrichment.md @@ -2,18 +2,18 @@ id: enable-virustotal-enrichment title: Enable VirusTotal Enrichment sidebar_label: Enable VirusTotal Enrichment -description: Enrich your Insights with information from VirusTotal. +description: Enrich your insights with information from VirusTotal. --- import useBaseUrl from '@docusaurus/useBaseUrl'; -The VirusTotal Enrichment enriches Signals based on queries it runs against VirusTotal. +The VirusTotal Enrichment enriches signals based on queries it runs against VirusTotal. :::note This feature requires the VirusTotal Premium API. ::: -For each Insight created, the enrichment checks the Records in the Signals that contribute to that Insight, looking for the values found in certain Record attributes that contain IP addresses, URLs, hostnames, or hashes. These are the fields the enrichment examines: +For each insight created, the enrichment checks the records in the signals that contribute to that insight, looking for the values found in certain record attributes that contain IP addresses, URLs, hostnames, or hashes. These are the fields the enrichment examines: * `srcDevice_ip` * `dstDevice_ip` @@ -28,10 +28,10 @@ For each Insight created, the enrichment checks the Records in the Signals that * `file_hash_sha256` * `file_hash_ssdeep` -The enrichment looks up each value it finds in VirusTotal, calling the VirusTotal API to do so. When a Record value has a match in VirusTotal, the enrichment writes the response to Cloud SIEM, where you can view it the Signal’s **Enrichment** tab. For an example, see [Example VirusTotal Enrichment](#example-virustotal-enrichment). +The enrichment looks up each value it finds in VirusTotal, calling the VirusTotal API to do so. When a record value has a match in VirusTotal, the enrichment writes the response to Cloud SIEM, where you can view it the signal’s **Enrichment** tab. For an example, see [Example VirusTotal Enrichment](#example-virustotal-enrichment). :::note -VirusTotal enrichments are only added to Signals that are part of an Insight. +VirusTotal enrichments are only added to signals that are part of an insight. ::: ## Configure VirusTotal enrichment diff --git a/docs/cse/integrations/enrichments-and-indicators.md b/docs/cse/integrations/enrichments-and-indicators.md index 357b7d45fd..3f107d8d88 100644 --- a/docs/cse/integrations/enrichments-and-indicators.md +++ b/docs/cse/integrations/enrichments-and-indicators.md @@ -8,16 +8,16 @@ description: Learn how enrichments include threat indicators. import useBaseUrl from '@docusaurus/useBaseUrl'; - Enrichments can add [threat indicators](#threat-indicators) to show risk level in Insights and Entities. + Enrichments can add [threat indicators](#threat-indicators) to show risk level in insights and entities. ## Enrichments -You can view the results of enrichments in Cloud SIEM by navigating to the **Enrichments** tab (which will appear on the Entity, Signal, and Insight details pages if there are any enrichments to display): +You can view the results of enrichments in Cloud SIEM by navigating to the **Enrichments** tab (which will appear on the entity, signal, and insight details pages if there are any enrichments to display): Examples of enrichments The enhancements include: -* Enrichments are grouped by Entity, not by enrichment source. +* Enrichments are grouped by entity, not by enrichment source. * Groups can be collapsed and expanded. * The list can be filtered. * Empty fields (fields with a null or empty value) can be optionally hidden. @@ -34,7 +34,7 @@ Threat indicators, if set, will be displayed throughout the Cloud SIEM UI either | **Suspicious** | Suspicious label | Suspicious icon | | **Not Flagged** | Suspicious label | None | -No icon is displayed for Entities with the **Not Flagged** label. +No icon is displayed for entities with the **Not Flagged** label. :::note **Not Flagged** is not the default value (which is no indicator at all). Cloud SIEM will not automatically determine the indicator value; enrichments must explicitly set it. @@ -44,5 +44,5 @@ No icon is displayed for Entities with the **Not Flagged** label. The enrichment schema includes support for the following optional attributes: * `expiresAt`. Defines when the enrichment should be auto-deleted from Cloud SIEM (by default, enrichments will never be auto-deleted). -* `externalUrl`. Defines a link that will be displayed with an enrichment (for example, to include a link to the VirusTotal details page for this Entity, put the link in this field). +* `externalUrl`. Defines a link that will be displayed with an enrichment (for example, to include a link to the VirusTotal details page for this entity, put the link in this field). * `reputation`. Associates a threat indicator with this enrichment data. The allowable values are `malicious`, `suspicious`, and `notflagged`. The default is not to display any reputation. \ No newline at end of file diff --git a/docs/cse/integrations/index.md b/docs/cse/integrations/index.md index f713d87e50..e62c170d41 100644 --- a/docs/cse/integrations/index.md +++ b/docs/cse/integrations/index.md @@ -19,13 +19,13 @@ In this section, we'll introduce the following concepts:
Icon of two screens

Insight Enrichment Server

 -

Learn how to automatically enrich Cloud SIEM Insights.

+

Learn how to automatically enrich Cloud SIEM insights.

Icon of two screens

Enable VirusTotal Enrichment

 -

Learn how to enrich Signals based on queries it runs against VirusTotal.

+

Learn how to enrich signals based on queries it runs against VirusTotal.

@@ -43,7 +43,7 @@ In this section, we'll introduce the following concepts:
Icon of two screens

Enrichments and Threat Indicators

 -

Learn how enrichments can add threat indicators to show risk level in Insights and Entities.

+

Learn how enrichments can add threat indicators to show risk level in insights and entities.

diff --git a/docs/cse/integrations/insight-enrichment-server.md b/docs/cse/integrations/insight-enrichment-server.md index ca27d599b5..f3136e811c 100644 --- a/docs/cse/integrations/insight-enrichment-server.md +++ b/docs/cse/integrations/insight-enrichment-server.md @@ -1,14 +1,14 @@ --- id: insight-enrichment-server title: Insight Enrichment Server -description: You can use the Cloud SIEM Insight Enrichment Server to automatically enrich Cloud SIEM Insights. +description: You can use the Cloud SIEM Insight Enrichment Server to automatically enrich Cloud SIEM insights. --- import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; import useBaseUrl from '@docusaurus/useBaseUrl'; -The Cloud SIEM Insight Enrichment Server is a component that automatically enriches Cloud SIEM Insights.   +The Cloud SIEM Insight Enrichment Server is a component that automatically enriches Cloud SIEM insights.   :::warning The Insight Enrichment Server is deprecated. Use the Automation Service instead for enrichments. See [Migrate from legacy actions and enrichments to the Automation Service](/docs/cse/automation/automations-in-cloud-siem/#migrate-from-legacy-actions-and-enrichments-to-the-automation-service). @@ -20,11 +20,11 @@ This topic describes v1.5.0 of the non-FedRAMP version of the Insight Enrichmen ## What the Insight Enrichment Server does -The Insight Enrichment Server performs an external query on the [Entity](/docs/cse/records-signals-entities-insights/view-manage-entities) for an Insight—for example, an IP address, a hostname, username, or a MAC address—and adds the query results as an enrichment to the Insight. +The Insight Enrichment Server performs an external query on the [entity](/docs/cse/records-signals-entities-insights/view-manage-entities) for an insight—for example, an IP address, a hostname, username, or a MAC address—and adds the query results as an enrichment to the insight. -You configure enrichments in the server’s configuration file. The key settings are the Entity type to run the enrichment on, and the command and command arguments to run.  +You configure enrichments in the server’s configuration file. The key settings are the entity type to run the enrichment on, and the command and command arguments to run.  -The Insight Enrichment Server periodically polls Cloud SIEM for new Insights. If an Insight’s Entity is of the same type as the `entity_type` specified for an enrichment configured in the server’s configuration file, the server runs the enrichment for the Entity instance in the Insight. You can see an enrichment that has been added to an Insight on the **Enrichments** tab for an Insight.   +The Insight Enrichment Server periodically polls Cloud SIEM for new insights. If an insight’s entity is of the same type as the `entity_type` specified for an enrichment configured in the server’s configuration file, the server runs the enrichment for the entity instance in the insight. You can see an enrichment that has been added to an insight on the **Enrichments** tab for an insight.   Example enrichment @@ -141,7 +141,7 @@ Run the installer and follow the instructions. The Enrichment Server supports these variables: -`${IP}`, `${MAC}`, `${USERNAME}`, and `${HOSTNAME}`, and for custom Entities, `${ENTITY}`. +`${IP}`, `${MAC}`, `${USERNAME}`, and `${HOSTNAME}`, and for custom entities, `${ENTITY}`. ### General settings @@ -154,7 +154,7 @@ The following parameters control general server behaviors, as opposed to enrichm | `api_id` | yes | Enter your Sumo Logic Access ID. For more information, see [Manage your access keys on Preferences page](/docs/manage/security/access-keys#from-the-preferences-page). | | `api_key` | yes | Enter your Sumo Logic Access Key.| | `log_level` | no | Log level the server should use. The options are:

-`error`. Only display error messages.
-`info`. Display informational messages. This is the recommended value.
-`debug`. Displays debug (or trace) data. Recommended only when debugging.

Default: `info` | -| `poll_interval` | no | How often the Insight Enrichment Server should check for new Insights. You can specify the interval in seconds (s), minutes (m), or hours (h).

Default: 10s | +| `poll_interval` | no | How often the Insight Enrichment Server should check for new insights. You can specify the interval in seconds (s), minutes (m), or hours (h).

Default: 10s | | `post_workers` | no | The number of parallel workers (threads) posting enrichment results. Default: 6 | | enrichment_workers | no | The number of parallel workers (threads) running enrichment tasks.

Default: 12 | | `proxy_url` | no | An HTTP proxy URL to use when communicating with the Sumo Logic backend. For example, `my.proxy.myorg.com:3128` or `username:password@my.proxy.myorg.com:31281`.

Default: No proxy used | @@ -168,11 +168,11 @@ Each enrichment should be configured in a separate section in the configuration | Setting | Required? | Description | |:--|:--|:--| | `enrichment_type` | yes | Specifies the type of the enrichment. Currently, the only supported value is `command`. | -| `entity_type` | yes | The type of Entity to enrich. The Insight Enrichment server supports built-in Entity types, including IP, mac, username, and hostname. (For a complete list, see [View and Manage Entities](/docs/cse/records-signals-entities-insights/view-manage-entities). It also supports [custom Entity types](/docs/cse/records-signals-entities-insights/create-custom-entity-type). For custom Entity types, the `entity_type` should match the unique Identifier assigned to the custom Entity type. | -| `cache_time` | no | The length of time that the results of a specific enrichment for a specific Entity will be cached and returned for other enrichment requests for that enrichment and Entity. This setting can be used to prevent an enrichment from running multiple times for the same Entity. You can specify `cache_time` in hours (h), minutes (m), or seconds (s). If you specify a value without a unit, the value is treated as nanoseconds.

Default: none | +| `entity_type` | yes | The type of entity to enrich. The Insight Enrichment server supports built-in entity types, including IP, mac, username, and hostname. (For a complete list, see [View and Manage Entities](/docs/cse/records-signals-entities-insights/view-manage-entities). It also supports [custom entity types](/docs/cse/records-signals-entities-insights/create-custom-entity-type). For custom entity types, the `entity_type` should match the unique Identifier assigned to the custom entity type. | +| `cache_time` | no | The length of time that the results of a specific enrichment for a specific entity will be cached and returned for other enrichment requests for that enrichment and entity. This setting can be used to prevent an enrichment from running multiple times for the same entity. You can specify `cache_time` in hours (h), minutes (m), or seconds (s). If you specify a value without a unit, the value is treated as nanoseconds.

Default: none | | `ip_range` | no | When `entity_type` is IP, you can specify a range of IP addresses that the enrichment will be limited to. Specify IP address ranges as a comma-separated list. For example:

`192.168.1.1-192.168.1.255, 192.168.5.1-192.168.8.120` | -| `command_exe` | yes | The executable to run when enriching the Entity. | -| `command_args` | yes | The arguments to pass to the executable specified by `command_exe` when performing the enrichment. Note that the value `${IP}` will be replaced by the IP address for IP Entities. The value `${HOSTNAME}` will be replaced with the hostname for hostname Entities. The value `${MAC}` will be replaced with the MAC address for MAC Entities. The value `${USERNAME}` will be replaced with the username for username Entities. `command_args` also supports an `${ENTITY}` replacement value that you can use for custom Entity types and any of the built-in Entity types. | +| `command_exe` | yes | The executable to run when enriching the entity. | +| `command_args` | yes | The arguments to pass to the executable specified by `command_exe` when performing the enrichment. Note that the value `${IP}` will be replaced by the IP address for IP entities. The value `${HOSTNAME}` will be replaced with the hostname for hostname entities. The value `${MAC}` will be replaced with the MAC address for MAC entities. The value `${USERNAME}` will be replaced with the username for username entities. `command_args` also supports an `${ENTITY}` replacement value that you can use for custom entity types and any of the built-in entity types. | | `command_timeout` | no | A timeout value (in seconds) that will be enforced when running the command.

Default: none | ### Example enrichment @@ -188,7 +188,7 @@ command_args = ${IP} ip_range = 10.10.10.1-10.10.10.4, 192.168.0.0-192.168.255.255 ``` -If an Insight’s Entity is an IP address in one of the ranges specified by `ip_range`, the enrichment will run the command `whois.exe` on that IP address. +If an insight’s entity is an IP address in one of the ranges specified by `ip_range`, the enrichment will run the command `whois.exe` on that IP address. ## Example configuration file diff --git a/docs/cse/integrations/integrate-cse-with-taxii-feed.md b/docs/cse/integrations/integrate-cse-with-taxii-feed.md index 61ae228ac8..dda1d9394e 100644 --- a/docs/cse/integrations/integrate-cse-with-taxii-feed.md +++ b/docs/cse/integrations/integrate-cse-with-taxii-feed.md @@ -21,7 +21,7 @@ To integrate Cloud SIEM with a TAXII feed, you configure the URL of the TAXII pr ## Leveraging indicators in rules -The integration allows you to enrich incoming Records with threat intel information, and leverage that information in Cloud SIEM Rules. How does that work? Cloud SIEM compares incoming Records with information from the threat feed. When there is a “match”, for instance when an IP address in a Record matches an IP address that the feed says is malicious, Cloud SIEM adds relevant information to that Record. Because the threat intel information is persisted within Records, you can reference it downstream in both rules and search. The built-in rules that come with Cloud SIEM will also automatically create a Signal for any Record with a match from your threat feed. To leverage the information in a rule, you can extend your custom rule expression, or add a [Rule Tuning Expression](/docs/cse/rules/rule-tuning-expressions) to a built-in rule. For a more detailed explanation of how to use threat intelligence information in rules, see [Threat Intelligence](/docs/cse/rules/about-cse-rules/#threat-intelligence) in the *About Cloud SIEM Rules* topic. +The integration allows you to enrich incoming records with threat intel information, and leverage that information in Cloud SIEM rules. How does that work? Cloud SIEM compares incoming records with information from the threat feed. When there is a “match”, for instance when an IP address in a record matches an IP address that the feed says is malicious, Cloud SIEM adds relevant information to that record. Because the threat intel information is persisted within records, you can reference it downstream in both rules and search. The built-in rules that come with Cloud SIEM will also automatically create a signal for any record with a match from your threat feed. To leverage the information in a rule, you can extend your custom rule expression, or add a [Rule Tuning Expression](/docs/cse/rules/rule-tuning-expressions) to a built-in rule. For a more detailed explanation of how to use threat intelligence information in rules, see [Threat Intelligence](/docs/cse/rules/about-cse-rules/#threat-intelligence) in the *About Cloud SIEM Rules* topic. ## Requirements diff --git a/docs/cse/integrations/security-incident-response-integration.md b/docs/cse/integrations/security-incident-response-integration.md index 9db4466a41..48cf61642e 100644 --- a/docs/cse/integrations/security-incident-response-integration.md +++ b/docs/cse/integrations/security-incident-response-integration.md @@ -13,15 +13,15 @@ The screenshots in this topic were captured from SIR UI16. If you have a differe ## Overview -The integration polls for Cloud SIEM for Insights and creates a ServiceNow Incident for each Insight. It creates composite fields, CI items, and associated MITRE data in ServiceNow. +The integration polls for Cloud SIEM for insights and creates a ServiceNow Incident for each insight. It creates composite fields, CI items, and associated MITRE data in ServiceNow. -Once you have configured the integration, Insights that match the query you specify in the configuration, will be ingested by ServiceNow on the configured ingestion cycle, which by default is every five minutes. +Once you have configured the integration, insights that match the query you specify in the configuration, will be ingested by ServiceNow on the configured ingestion cycle, which by default is every five minutes. ## Prerequisites The following SIR plugins are required: -* [Threat Intelligence](https://docs.servicenow.com/bundle/quebec-security-management/page/product/threat-intelligence/reference/threat-intel-landing-page.html) (com.snc.threat.intelligence) — This plugin is required if you want to enable SIR to add  MITRE information (stage, tactic, and technique) to Incidents it creates from Cloud SIEM Insights. +* [Threat Intelligence](https://docs.servicenow.com/bundle/quebec-security-management/page/product/threat-intelligence/reference/threat-intel-landing-page.html) (com.snc.threat.intelligence) — This plugin is required if you want to enable SIR to add  MITRE information (stage, tactic, and technique) to Incidents it creates from Cloud SIEM insights. * [Security Incident Response](https://docs.servicenow.com/bundle/quebec-security-management/page/product/security-incident-response/reference/sir-landing-page.html) (com.snc.security_incident) The following SIR system table permissions are required: @@ -30,7 +30,7 @@ The following SIR system table permissions are required: * Threat intelligence/mitre tables – Read-only access is required * Configuration item tables – Read-write access is required. -Your Cloud SIEM role must allow you to use API keys and to retrieve and modify Insights.  +Your Cloud SIEM role must allow you to use API keys and to retrieve and modify insights.  ## Step 1: Copy your API credentials @@ -83,7 +83,7 @@ To verify that the configuration is working, enter the following in the ServiceN `x_579138_sumo_logi_sumo_logic_insights.list` -Within five minutes data will appear if new Insights have been created. If no insights have been created, you can check Sumo Logic integration logs by searching for logs with the prefix: “Sumo Cloud SIEM ERROR”. You can also check the Sumo Status table from the navigation bar to see the last error message if any and the current integration health. If the value is healthy then the integration has run at least once with no error. +Within five minutes data will appear if new insights have been created. If no insights have been created, you can check Sumo Logic integration logs by searching for logs with the prefix: “Sumo Cloud SIEM ERROR”. You can also check the Sumo Status table from the navigation bar to see the last error message if any and the current integration health. If the value is healthy then the integration has run at least once with no error. ## Configuration options @@ -91,7 +91,7 @@ This section describes configuration changes you can make to the integration. ## Update the mapping configuration -If desired, you can change the mapping between the fields in Cloud SIEM Insights and the fields in Incidents that the integration creates in ServiceNow. +If desired, you can change the mapping between the fields in Cloud SIEM insights and the fields in Incidents that the integration creates in ServiceNow. 1. Navigate to the **Table Transform Maps** page in ServiceNow.
Table Transform Maps 1. Open the “Sumo Insight Mapper” for editing. @@ -113,19 +113,19 @@ Double-click a property to edit it. ## View generated Incident URL in Cloud SIEM -The URL to the ServiceNow Incident generated for an Insight is shown on the details page for the Insight. +The URL to the ServiceNow Incident generated for an insight is shown on the details page for the insight. Generated incident ## Example Incident created by integration -The screenshot below shows a ServiceNow Incident that was created for a Cloud SIEM Insight. +The screenshot below shows a ServiceNow Incident that was created for a Cloud SIEM insight. Incident draft -## See closed Insight in Cloud SIEM +## See closed insight in Cloud SIEM -After an Incident created by the integration is closed in ServiceNow, the Insight from which it was generated will be closed in Cloud SIEM as well. +After an Incident created by the integration is closed in ServiceNow, the insight from which it was generated will be closed in Cloud SIEM as well. Insight Actions From 3f56a3b8260dd85ec9557b9bd446df14690d9f72 Mon Sep 17 00:00:00 2001 From: John Pipkin Date: Wed, 18 Dec 2024 15:52:42 -0600 Subject: [PATCH 4/6] Make terms lowercase in the 'Match Lists and Suppressed Lists' section --- .../create-match-list.md | 104 ++++++------ .../custom-match-list-columns.md | 16 +- .../cse/match-lists-suppressed-lists/index.md | 16 +- .../match-fields-reference.md | 6 +- .../standard-match-lists.md | 152 +++++++++--------- .../suppressed-lists.md | 70 ++++---- 6 files changed, 182 insertions(+), 182 deletions(-) diff --git a/docs/cse/match-lists-suppressed-lists/create-match-list.md b/docs/cse/match-lists-suppressed-lists/create-match-list.md index 42b9e45338..2ffd4e2d00 100644 --- a/docs/cse/match-lists-suppressed-lists/create-match-list.md +++ b/docs/cse/match-lists-suppressed-lists/create-match-list.md @@ -1,108 +1,108 @@ --- id: create-match-list title: Create a Match List -description: Learn about Match Lists and how to create a Match List. +description: Learn about match lists and how to create a match list. --- import useBaseUrl from '@docusaurus/useBaseUrl'; -This topic has information about Match Lists, their purpose and usage, and how to create them.  +This topic has information about match lists, their purpose and usage, and how to create them.  -## About Match Lists +## About match lists -Match Lists are lists of important indicators and identifiers configured by a Cloud SIEM analyst. Match Lists are typically used to define “allow lists” of items, like IP addresses, URLs, and hostnames, and so on, that you want to exempt from ordinary rule processing. For example, you might want to prevent a rule from firing for Records that contain one of a certain set of IP addresses.  +Match lists are lists of important indicators and identifiers configured by a Cloud SIEM analyst. Match lists are typically used to define “allow lists” of items, like IP addresses, URLs, and hostnames, and so on, that you want to exempt from ordinary rule processing. For example, you might want to prevent a rule from firing for records that contain one of a certain set of IP addresses.  -Here’s a use case for using a Match List to define an allow list:  Vulnerability scanners often set off false alarms in security data, as they intentionally mimic the behavior of an attacker. Given that this behavior is safe and expected, you don’t want scanner activities to fire a rule. That’s what a match list is for. You can create a Match List called “vuln_scanners” that contains the IP addresses of your scanners. +Here’s a use case for using a match list to define an allow list:  Vulnerability scanners often set off false alarms in security data, as they intentionally mimic the behavior of an attacker. Given that this behavior is safe and expected, you don’t want scanner activities to fire a rule. That’s what a match list is for. You can create a match list called “vuln_scanners” that contains the IP addresses of your scanners. :::tip -There’s no reason you can’t use a Match List to define “deny lists” of items. However, Cloud SIEM’s Threat Intel feature is designed for exactly that purpose. Most of the time, but not always, you should use Threat Intel lists for negative indicators. For more information, see [Match Lists or Threat Intel: which to use?](#match-listor-threat-intel-which-to-use). +There’s no reason you can’t use a match list to define “deny lists” of items. However, Cloud SIEM’s threat intel feature is designed for exactly that purpose. Most of the time, but not always, you should use threat intel lists for negative indicators. For more information, see [Match lists or threat intel: which to use?](#match-listor-threat-intel-which-to-use). ::: -Here’s an example of a Match List in the Cloud SIEM UI. It is a list of trusted domains. +Here’s an example of a match list in the Cloud SIEM UI. It is a list of trusted domains. Example match list -Note that the Match List has a **Target Column**, which you define when you create the list. The Target Column indicates what type of Record fields should be compared to the Match List, for example, hostnames, URLs, domains, IP addresses, usernames, and so on. For more information, see [How are Match Lists Used?](#how-are-match-lists-used) +Note that the match list has a **Target Column**, which you define when you create the list. The Target Column indicates what type of record fields should be compared to the match list, for example, hostnames, URLs, domains, IP addresses, usernames, and so on. For more information, see [How are match lists Used?](#how-are-match-lists-used) -## Built-in rules refer to standard Match List names +## Built-in rules refer to standard match list names -Many of Cloud SIEM’s built-in rules assume the existence of one or more standard Match Lists. A standard Match List is a list that you need to create and populate so that Cloud SIEM can leverage it. Cloud SIEM rules take advantage of about 20 standard Match Lists. One example of a standard Match list is the “vuln_scanners” list mentioned in the previous section. There are analogous Match Lists for other entity types, such as “business_ips”, “verified_domains”, and so on. +Many of Cloud SIEM’s built-in rules assume the existence of one or more standard match lists. A standard match list is a list that you need to create and populate so that Cloud SIEM can leverage it. Cloud SIEM rules take advantage of about 20 standard match lists. One example of a standard Match list is the “vuln_scanners” list mentioned in the previous section. There are analogous match lists for other entity types, such as “business_ips”, “verified_domains”, and so on. -When you create the standard Match Lists, it’s important to create them correctly: you need to use the exact name Cloud SIEM has defined for the list, and you must specify the correct Target Column. You can find that information in the [Standard Match Lists](/docs/cse/match-lists-suppressed-lists/standard-match-lists/#standard-match-lists) topic, which also lists the built-in rules that refer to Match List data. +When you create the standard match lists, it’s important to create them correctly: you need to use the exact name Cloud SIEM has defined for the list, and you must specify the correct Target Column. You can find that information in the [Standard Match Lists](/docs/cse/match-lists-suppressed-lists/standard-match-lists/#standard-match-lists) topic, which also lists the built-in rules that refer to match list data. -If you don’t define one or more standard Match Lists, the rules that refer to the match list data will still function, but you’ll miss out on the benefit that Match Lists provide—a rule will have no way of knowing that a particular IP address, domain, or other entity in a message should not cause it to fire. +If you don’t define one or more standard match lists, the rules that refer to the match list data will still function, but you’ll miss out on the benefit that match lists provide—a rule will have no way of knowing that a particular IP address, domain, or other entity in a message should not cause it to fire. -As necessary, you can also create custom Match Lists. +As necessary, you can also create custom match lists. -## How are Match Lists used? +## How are match lists used? -When Cloud SIEM processes an incoming message, it compares the entries in each Match List that you’ve created to message fields that are of the same type as the Target Column of the Match List. For example, given a Match List whose Target Column is `Domain`,  Cloud SIEM will compare items on that list only to message fields that contain domains. +When Cloud SIEM processes an incoming message, it compares the entries in each match list that you’ve created to message fields that are of the same type as the Target Column of the match list. For example, given a match list whose Target Column is `Domain`,  Cloud SIEM will compare items on that list only to message fields that contain domains. -When a Record contains a value that exactly matches one or more Match Lists (partial matches are not supported), two fields in the Record get populated: +When a record contains a value that exactly matches one or more match lists (partial matches are not supported), two fields in the record get populated: -* `listMatches`. Cloud SIEM adds the names of the Match Lists that the Record matched, and the column values of those lists. For example, if an IP address in a Record matches the `SourceIP` address in the “vuln_scanners” Match List, the `listMatches` field would look like this: `listMatches: ['vuln_scanners', 'column:SourceIp']` +* `listMatches`. Cloud SIEM adds the names of the match lists that the record matched, and the column values of those lists. For example, if an IP address in a record matches the `SourceIP` address in the “vuln_scanners” match list, the `listMatches` field would look like this: `listMatches: ['vuln_scanners', 'column:SourceIp']` -* `matchedItems`. Cloud SIEM adds the actual key-value pairs that were matched. For example, continuing the example above, if “vuln_scanners” Match List contained an entry “5.6.7.8”, and the Record’s `SourceIp` is also “5.6.7.8”, and assuming the SourceIP address in the “vuln_scanners” Match List, the `matchedItems `field would like like this: `matchedItems: [ { value: '5.6.7.8', …other metadata about list item } ]` +* `matchedItems`. Cloud SIEM adds the actual key-value pairs that were matched. For example, continuing the example above, if “vuln_scanners” match list contained an entry “5.6.7.8”, and the record’s `SourceIp` is also “5.6.7.8”, and assuming the SourceIP address in the “vuln_scanners” match list, the `matchedItems `field would like like this: `matchedItems: [ { value: '5.6.7.8', …other metadata about list item } ]` -Because the information about list matches gets persisted within Records, you can reference it downstream in both rules and search.  +Because the information about list matches gets persisted within records, you can reference it downstream in both rules and search.  In a rule, you look for matches by extending  a rule expression with an `array_contains` function, for example: `... AND NOT array_contains(listMatches, "vuln_scanners")`   -If any of the IP addresses within the Record match one of the “vuln_scanner” IPs, the `listMatches` field will have a value of `['vuln_scanners']`. Thus, the check above will effectively prevent Signals from firing for those rules on the scanner IP addresses. +If any of the IP addresses within the record match one of the “vuln_scanner” IPs, the `listMatches` field will have a value of `['vuln_scanners']`. Thus, the check above will effectively prevent signals from firing for those rules on the scanner IP addresses. -For more information about referring to Match List data in rules, see [Match Lists](/docs/cse/rules/about-cse-rules#match-lists) in the *About Cloud SIEM Rules* topic. +For more information about referring to match list data in rules, see [Match lists](/docs/cse/rules/about-cse-rules#match-lists) in the *About Cloud SIEM Rules* topic. -## Match List or Threat Intel: which to use? +## Match list or threat intel: which to use? -Cloud SIEM has another feature that is similar to Match Lists: Threat Intel. Like Match Lists, Threat Intel lists are lists of indicators and identifiers configured by a Cloud SIEM analyst. When deciding whether to put an indicator on a Match List or a Threat Intel list, consider the following. +Cloud SIEM has another feature that is similar to match lists: threat intel. Like match lists, threat intel lists are lists of indicators and identifiers configured by a Cloud SIEM analyst. When deciding whether to put an indicator on a match list or a threat intel list, consider the following. -Threat Intel lists are intended specifically for negative identifiers that should definitely fire a Signal. So, whenever a rule detects a Record field that matches an item on a Threat Intel list, it *always* results in a Signal. If that’s what you want to occur when a particular identifier is encountered in a Record, you should put that identifier on an Threat Intel list. But, if you *don’t* want a match to invariably result in a Signal, the item should be on a Match List. For example, you might use a Match List for negative indicators that should fire a Signal only if a secondary condition is also met. +Threat intel lists are intended specifically for negative identifiers that should definitely fire a signal. So, whenever a rule detects a record field that matches an item on a threat intel list, it *always* results in a signal. If that’s what you want to occur when a particular identifier is encountered in a record, you should put that identifier on an threat intel list. But, if you *don’t* want a match to invariably result in a signal, the item should be on a match list. For example, you might use a match list for negative indicators that should fire a signal only if a secondary condition is also met. -Another difference between Match Lists and Threat Intel lists is the **Target Column** types they support. For instance, you can’t create a Threat Intel list that contains email addresses. So, although typically a Threat Intel list is what you’d use for suspicious indicators, in some cases, a Match List is the answer. +Another difference between match lists and threat intel lists is the **Target Column** types they support. For instance, you can’t create a threat intel list that contains email addresses. So, although typically a threat intel list is what you’d use for suspicious indicators, in some cases, a match list is the answer. -## Match List limitations +## Match list limitations -A Match List can contain up to 100,000 items. +A match list can contain up to 100,000 items. ## Matching behavior -When comparing a field value to items on a Match List, Cloud SIEM generally requires an exact match (case insensitive). There are two exceptions to that rule. +When comparing a field value to items on a match list, Cloud SIEM generally requires an exact match (case insensitive). There are two exceptions to that rule. -* Match Lists that contain IP addresses can list either explicit IP addresses, CIDR blocks of IP addresses, (for example `1.2.3.4/24`), or both. -* Match Lists that contain domains can list, either complete internet domains or partial domain. Partial domains will match all the matching subdomains. For example, `google.com` in a list will match `mail.google.com` in a Record. Note that the converse is not the case: `mail.google.com` in a list won’t match `google.com`. +* Match lists that contain IP addresses can list either explicit IP addresses, CIDR blocks of IP addresses, (for example `1.2.3.4/24`), or both. +* Match lists that contain domains can list, either complete internet domains or partial domain. Partial domains will match all the matching subdomains. For example, `google.com` in a list will match `mail.google.com` in a record. Note that the converse is not the case: `mail.google.com` in a list won’t match `google.com`. -## Create a Match List +## Create a match list -Perform the steps below to create a Match List in Cloud SIEM. +Perform the steps below to create a match list in Cloud SIEM. :::tip -You can also create and manage Match Lists with Cloud SIEM's REST [API](/docs/cse/administration/cse-apis). +You can also create and manage match lists with Cloud SIEM's REST [API](/docs/cse/administration/cse-apis). ::: 1. [**Classic UI**](/docs/get-started/sumo-logic-ui-classic). In the top menu select **Content > Match Lists**.
[**New UI**](/docs/get-started/sumo-logic-ui). In the main Sumo Logic menu, select **Cloud SIEM > Match List**. You can also click the **Go To...** menu at the top of the screen and select **Match List**. 1. Click **Create**. 1. On the **New Match List** popup, enter the following: - 1. **Name**. Name of the Match list. If you are creating a standard Match List, make sure the name matches the standard Match List name. For more information, see [Standard Match Lists](/docs/cse/match-lists-suppressed-lists/standard-match-lists#standard-match-lists). We recommend no embedded spaces in list names. For example, instead of *my list*, use *my_list*. - 1. **Description**. Enter a description for the list. Descriptions for standard Match Lists can be found in [Standard Match Lists](/docs/cse/match-lists-suppressed-lists/standard-match-lists#standard-match-lists). + 1. **Name**. Name of the Match list. If you are creating a standard match list, make sure the name matches the standard match list name. For more information, see [Standard match lists](/docs/cse/match-lists-suppressed-lists/standard-match-lists#standard-match-lists). We recommend no embedded spaces in list names. For example, instead of *my list*, use *my_list*. + 1. **Description**. Enter a description for the list. Descriptions for standard match lists can be found in [Standard match lists](/docs/cse/match-lists-suppressed-lists/standard-match-lists#standard-match-lists). 1. **Time to Live (hours)**. (Optional) Enter the number of hours after which the entries on the list should expire. - 1. **Target Column**. The type of message field to which items on the list should be compared. The **Target Column** for standard Match Lists can be found in [Standard Match Lists](/docs/cse/match-lists-suppressed-lists/standard-match-lists#standard-match-lists).
+ 1. **Target Column**. The type of message field to which items on the list should be compared. The **Target Column** for standard match lists can be found in [Standard match lists](/docs/cse/match-lists-suppressed-lists/standard-match-lists#standard-match-lists).
:::note - Once you create a Match List, it's not possible to change its **Target Column**. + Once you create a match list, it's not possible to change its **Target Column**. ::: 1. Click **Create**.
New match list -1. The Match List now appears on the **Match Lists** page. -1. Click the name of the Match List to open it. +1. The match list now appears on the **Match Lists** page. +1. Click the name of the match list to open it. 1. On the **Match List > Details** page, click **Add List Item**. 1. On the **New Match List Item** popup, enter: * **Value**. The value of the entity. Make sure the value you enter is of the same type as the type you selected as the Target Column for the list. For example, if the Target Column is `Domain`, enter a domain. * **Description**. (Optional) Enter a description of the entity instance you entered. * **Expiration**. (Optional) The date and time at which the list item should be removed from the list. * Click **Add** to add the item to the list. -1. The item now appears in the Match List. +1. The item now appears in the match list. -## Import a Match List +## Import a match list You can import list items by uploading a .csv file. This is convenient when you want to add many items to a list.  @@ -110,7 +110,7 @@ You can import list items by uploading a .csv file. This is convenient when you Create a .csv file. You can import up to three fields for an item. -* **value** (Required). The value of the list item. The item you supply should be of the same type as the **Target Column** defined for the Match List. For example, if the **Target Column** is `IP Address`, supply an IP address. The maximum length for the value field is 2000 characters. +* **value** (Required). The value of the list item. The item you supply should be of the same type as the **Target Column** defined for the match list. For example, if the **Target Column** is `IP Address`, supply an IP address. The maximum length for the value field is 2000 characters. * **description** (Optional). A description of the list item. * **expires** (Optional). Expiration date and time for the list item, in ISO 8601 format, for example: 2020-08-17 01:18:00  @@ -135,26 +135,26 @@ value 10.99.19.9 ``` -## Best practices for using Match Lists +## Best practices for using match lists -Sumo Logic recommends the following conventions and best practices for using Match Lists. +Sumo Logic recommends the following conventions and best practices for using match lists. -### Use Match Lists +### Use match lists -Use the Match List feature early on to get the most value from Cloud SIEM. This feature allows you to prevent rules from firing as a result of devices and activity in your environment that you know are benign. This optimizes the detection process by reducing noise in results, and helps reduce alert overload and analysis fatigue. +Use the match list feature early on to get the most value from Cloud SIEM. This feature allows you to prevent rules from firing as a result of devices and activity in your environment that you know are benign. This optimizes the detection process by reducing noise in results, and helps reduce alert overload and analysis fatigue. -Match Lists are not your only option for creating allowlists or denylists. For Entities, use [schema key tags](/docs/cse/match-lists-suppressed-lists/standard-match-lists) rather than Match Lists. And to suppress Signals altogether, use [Suppressed Lists](/docs/cse/match-lists-suppressed-lists/suppressed-lists). +Match lists are not your only option for creating allowlists or denylists. For entities, use [schema key tags](/docs/cse/match-lists-suppressed-lists/standard-match-lists) rather than match lists. And to suppress signals altogether, use [suppressed lists](/docs/cse/match-lists-suppressed-lists/suppressed-lists). ### Choose appropriate Target Column -When creating a custom Match List, consider directionality when you select the Target Column. In most cases, Match Lists work fine with a directionless column type, like IP Address. However, in some cases, a Match List is best configured with a directional column type, such as Source IP Address or Destination IP Address. In some cases it works best to create multiple Match Lists with the same items in each, but different Target Columns. For example, you can have the same IP addresses in three Match List: one whose target column is IP Address, one with Source IP Address, and one with Destination IP Address.    +When creating a custom match list, consider directionality when you select the Target Column. In most cases, match lists work fine with a directionless column type, like IP Address. However, in some cases, a match list is best configured with a directional column type, such as Source IP Address or Destination IP Address. In some cases it works best to create multiple match lists with the same items in each, but different Target Columns. For example, you can have the same IP addresses in three match list: one whose target column is IP Address, one with Source IP Address, and one with Destination IP Address.    ### Get the TTL right -Select a default TTL for Match Lists that make sense. For example, a Match List of resources like authentication servers or vulnerability scanners should be fairly static and typically never have items expire. On the other hand, Match List of Tor node addresses is dynamic—a TTL is definitely appropriate. +Select a default TTL for match lists that make sense. For example, a match list of resources like authentication servers or vulnerability scanners should be fairly static and typically never have items expire. On the other hand, match list of Tor node addresses is dynamic—a TTL is definitely appropriate. -### General purpose Match Lists are good +### General purpose match lists are good -When creating custom Match Lists, we recommend a general purpose approach to naming and populating them so that they’re broadly applicable across your infrastructure. +When creating custom match lists, we recommend a general purpose approach to naming and populating them so that they’re broadly applicable across your infrastructure. -It’s better to have one generic Match List for similar resource types than multiple vendor-specific lists. For example, creating the “vuln_scanners” list is better than having one for each type you have, like “Qualys Scanners”, “Tenable Vulnerability Scanners”, and so on.  +It’s better to have one generic match list for similar resource types than multiple vendor-specific lists. For example, creating the “vuln_scanners” list is better than having one for each type you have, like “Qualys Scanners”, “Tenable Vulnerability Scanners”, and so on.  diff --git a/docs/cse/match-lists-suppressed-lists/custom-match-list-columns.md b/docs/cse/match-lists-suppressed-lists/custom-match-list-columns.md index 4ebf56ba2c..3505ba16bf 100644 --- a/docs/cse/match-lists-suppressed-lists/custom-match-list-columns.md +++ b/docs/cse/match-lists-suppressed-lists/custom-match-list-columns.md @@ -6,15 +6,15 @@ description: Learn how to define custom columns for use in Match Lists. import useBaseUrl from '@docusaurus/useBaseUrl'; -This page has information about custom Match List columns  +This page has information about custom match list columns. -## About Match Lists and Target Columns +## About match lists and target columns -Match Lists are lists of important indicators and identifiers that a Cloud SIEM analyst creates. Match Lists are typically used to define “allow lists” of items, like IP addresses, URLs, or hostnames that you want to exempt from ordinary rule processing. Many of Cloud SIEM’s built-in rules reference [standard Match Lists](/docs/cse/match-lists-suppressed-lists/standard-match-lists). Examples of standard Match Lists include a list of trusted domains, and a list of IP addresses that shouldn’t trigger SSL detection rules.   +Match lists are lists of important indicators and identifiers that a Cloud SIEM analyst creates. Match lists are typically used to define “allow lists” of items, like IP addresses, URLs, or hostnames that you want to exempt from ordinary rule processing. Many of Cloud SIEM’s built-in rules reference [standard match lists](/docs/cse/match-lists-suppressed-lists/standard-match-lists). Examples of standard match lists include a list of trusted domains, and a list of IP addresses that shouldn’t trigger SSL detection rules.   -You can define your own custom Match Lists, and reference them in rules that you write yourself. When you create a Match List, whether it’s a standard or a custom list, you select a Target Column, which indicates the Record attribute or attributes that should be compared to the Match List. The options that appear in the **Target Column** selector list include “Hostname”, “Domain”, “Username”, and so on. Note that these options usually map to multiple Record attributes. For example, if you select “Username” as a list’s Target Column, any occurrences of  username, `fromUser_username`, or `user_username` in incoming Records will be compared to the Match List. For information about how **Target Column** options in the UI map to Cloud SIEM schema attributes, see [Match Fields Reference](/docs/cse/match-lists-suppressed-lists/match-fields-reference). +You can define your own custom match lists, and reference them in rules that you write yourself. When you create a match list, whether it’s a standard or a custom list, you select a target column, which indicates the record attribute or attributes that should be compared to the match list. The options that appear in the **Target Column** selector list include “Hostname”, “Domain”, “Username”, and so on. Note that these options usually map to multiple record attributes. For example, if you select “Username” as a list’s target column, any occurrences of  username, `fromUser_username`, or `user_username` in incoming records will be compared to the match list. For information about how **Target Column** options in the UI map to Cloud SIEM schema attributes, see [Match Fields Reference](/docs/cse/match-lists-suppressed-lists/match-fields-reference). -If you create a Match List for which none of the existing Target Column options is appropriate, you can create a custom column.  +If you create a match list for which none of the existing target column options is appropriate, you can create a custom column.  ## View custom columns in the Cloud SIEM UI @@ -29,7 +29,7 @@ To see the custom columns that have been defined in your environment: 1. On the **Custom Columns** page, click **Create**. 1. The **Create Match List Column** popup appears.
Create column 1. **Name**. Enter a name for the custom column. -1. **Fields**. Click the chevron icon to display a selector list of Cloud SIEM attributes. You can select multiple attributes. If multiple attributes are selected, the match list will match if the list item value matches a Record value for any of the custom column attributes. Click the icon next to Show field guide to view more information, such as data type, about attributes.  +1. **Fields**. Click the chevron icon to display a selector list of Cloud SIEM attributes. You can select multiple attributes. If multiple attributes are selected, the match list will match if the list item value matches a record value for any of the custom column attributes. Click the icon next to Show field guide to view more information, such as data type, about attributes.  1. Click **Create** to add the new column. ## Edit a custom column @@ -43,8 +43,8 @@ To see the custom columns that have been defined in your environment: 1. On the **Custom Columns** page, click the trash can icon in the row for the column you want to delete. 1. On the **Delete column** popup, click confirmation popup **Yes, Delete Column**. -## Create a Match List with a custom column +## Create a match list with a custom column -Follow the instructions in the [Create a Match List](/docs/cse/match-lists-suppressed-lists/create-match-list), and select the desired column in the **Custom** section of the **Target Column** selector list. +Follow the instructions in [Create a Match List](/docs/cse/match-lists-suppressed-lists/create-match-list), and select the desired column in the **Custom** section of the **Target Column** selector list. Target column selector diff --git a/docs/cse/match-lists-suppressed-lists/index.md b/docs/cse/match-lists-suppressed-lists/index.md index 7a43cfedae..1b7776f233 100644 --- a/docs/cse/match-lists-suppressed-lists/index.md +++ b/docs/cse/match-lists-suppressed-lists/index.md @@ -1,10 +1,10 @@ --- slug: /cse/match-lists-suppressed-lists title: Match Lists and Suppressed Lists -description: Learn about creating a Match list and their usage in rules. +description: Learn about creating a match list and their usage in rules. --- -This guide has information about Cloud SIEM Match Lists, including how they are used in Cloud SIEM and how to create them. +This guide has information about Cloud SIEM match lists, including how they are used in Cloud SIEM and how to create them. import useBaseUrl from '@docusaurus/useBaseUrl'; @@ -14,31 +14,31 @@ In this section, we'll introduce the following concepts:
List icon

Create a Match List

 -

Learn about Match Lists, their purpose, usage, and how to create them.

+

Learn about match lists, their purpose, usage, and how to create them.

- List icon

Custom Match List Columns

 -

Learn how to define custom columns for use in Match Lists.

+ List icon

Custom match list Columns

 +

Learn how to define custom columns for use in match lists.

List icon

Match Fields Reference

 -

Learn what Record fields a Match List with a given Target Column will be compared to.

+

Learn what record fields a match list with a given target column will be compared to.

List icon

Entity Tags and Standard Match Lists

 -

Learn how to identify specific Entities that should be treated differently during Cloud SIEM rule processing.

+

Learn how to identify specific entities that should be treated differently during Cloud SIEM rule processing.

List icon

Suppressed Lists

 -

Learn to suppress Signals that contain a particular indicator value in any of the Signal's Records.

+

Learn to suppress signals that contain a particular indicator value in any of the signal's records.

diff --git a/docs/cse/match-lists-suppressed-lists/match-fields-reference.md b/docs/cse/match-lists-suppressed-lists/match-fields-reference.md index fa9fe71ecb..883a02f08a 100644 --- a/docs/cse/match-lists-suppressed-lists/match-fields-reference.md +++ b/docs/cse/match-lists-suppressed-lists/match-fields-reference.md @@ -1,14 +1,14 @@ --- id: match-fields-reference title: Match Fields Reference -description: Learn what Record fields a Match List with a given Target Column is compared to. +description: Learn what record fields a match list with a given target column is compared to. --- import useBaseUrl from '@docusaurus/useBaseUrl'; -This topic is a reference to the Record fields that a Match List with a given Target Column will be compared to. Each header below—Hostname, Domain, Username, and—is a supported Target Column for a Cloud SIEM Match List. The items listed below each header are Record fields  +This topic is a reference to the record fields that a match list with a given target column will be compared to. Each header below—Hostname, Domain, Username, and—is a supported target column for a Cloud SIEM match list. The items listed below each header are record fields  -If a Record contains a field whose name matches one of the match fields for a Target Column, the name of the Match List, Cloud SIEM will append the Match List name to the Record in the `list_matches` array.  +If a record contains a field whose name matches one of the match fields for a target column, the name of the match list, Cloud SIEM will append the match list name to the record in the `list_matches` array.  ## Hostname diff --git a/docs/cse/match-lists-suppressed-lists/standard-match-lists.md b/docs/cse/match-lists-suppressed-lists/standard-match-lists.md index b1e1ecb1e0..290ca59746 100644 --- a/docs/cse/match-lists-suppressed-lists/standard-match-lists.md +++ b/docs/cse/match-lists-suppressed-lists/standard-match-lists.md @@ -1,22 +1,22 @@ --- id: standard-match-lists title: Entity Tags and Standard Match Lists -description: Learn about Entity Tags and standard Match Lists in Cloud SIEM. +description: Learn about entity tags and standard match lists in Cloud SIEM. --- import useBaseUrl from '@docusaurus/useBaseUrl'; -This topic has information about how you can identify specific Entities or indicators that should be treated differently during Cloud SIEM rule processing. For example, you might want to prevent a rule from firing for Records that contain one of a certain set of IP addresses. Conversely, you might want to only fire a Signal if a user Entity belongs to a certain group, such as domain admins. There are currently two methods of achieving this sort of allowlist/denylist behavior: +This topic has information about how you can identify specific entities or indicators that should be treated differently during Cloud SIEM rule processing. For example, you might want to prevent a rule from firing for records that contain one of a certain set of IP addresses. Conversely, you might want to only fire a signal if a user entity belongs to a certain group, such as domain admins. There are currently two methods of achieving this sort of allowlist/denylist behavior: -* Schema key tags for Entities. This is the recommended approach. You simply apply predefined [schema key tags](/docs/cse/records-signals-entities-insights/tags-insights-signals-entities-rules) to new Entities once they come into Cloud SIEM. Then in a rule, you look for matches by extending a rule expression with the [`array_contains`](/docs/cse/rules/cse-rules-syntax/#array_contains) function, for example: `array_contains(fieldTags["user_username"], "schema-key:schema-value")`. See [Schema tag keys for Entities](#schema-tag-keys-for-entities) for information about which tag:value pairs to use for different Entities. +* Schema key tags for entities. This is the recommended approach. You simply apply predefined [schema key tags](/docs/cse/records-signals-entities-insights/tags-insights-signals-entities-rules) to new entities once they come into Cloud SIEM. Then in a rule, you look for matches by extending a rule expression with the [`array_contains`](/docs/cse/rules/cse-rules-syntax/#array_contains) function, for example: `array_contains(fieldTags["user_username"], "schema-key:schema-value")`. See [Schema tag keys for entities](#schema-tag-keys-for-entities) for information about which tag:value pairs to use for different entities. :::tip - The most efficient way to assign tags to Entities is to configure [Entity Groups](/docs/cse/records-signals-entities-insights/create-an-entity-group), and allow Cloud SIEM to automatically apply tags based on group membership. + The most efficient way to assign tags to entities is to configure [entity groups](/docs/cse/records-signals-entities-insights/create-an-entity-group), and allow Cloud SIEM to automatically apply tags based on group membership. ::: -* Standard match lists. This is the original approach for excluding Entities from rule processing. It involves adding Entities to standard match lists, as described in [Create a Match List](/docs/cse/match-lists-suppressed-lists/create-match-list). Then in a rule, you look for matches by extending a rule expression with the [`array_contains`](/docs/cse/rules/cse-rules-syntax/#array_contains) function, for example: `array_contains(listMatches, 'match_list_name')`. Standard match lists are described in [Standard match lists](#standard-match-lists) below. When creating Standard match lists using the [Cloud SIEM REST API](/docs/api/cloud-siem-enterprise/), the expected `target_column` value is indicated in the entries below using parentheses, as in: "**Target column:** Source IP Address (`SrcIp`)." +* Standard match lists. This is the original approach for excluding entities from rule processing. It involves adding entities to standard match lists, as described in [Create a Match List](/docs/cse/match-lists-suppressed-lists/create-match-list). Then in a rule, you look for matches by extending a rule expression with the [`array_contains`](/docs/cse/rules/cse-rules-syntax/#array_contains) function, for example: `array_contains(listMatches, 'match_list_name')`. Standard match lists are described in [Standard match lists](#standard-match-lists) below. When creating Standard match lists using the [Cloud SIEM REST API](/docs/api/cloud-siem-enterprise/), the expected `target_column` value is indicated in the entries below using parentheses, as in: "**Target column:** Source IP Address (`SrcIp`)." -## Schema tag keys for Entities +## Schema tag keys for entities -The keys and values described below are controlled by Sumo Logic. If you want to request additional tags or tag values, contact your Sumo Logic Customer Success Manager. You can also tag Entities with custom tags–if you do that, you’ll need to update your custom rules or add rule tuning expression to out-of-the-box rules to reference your custom tags. +The keys and values described below are controlled by Sumo Logic. If you want to request additional tags or tag values, contact your Sumo Logic Customer Success Manager. You can also tag entities with custom tags–if you do that, you’ll need to update your custom rules or add rule tuning expression to out-of-the-box rules to reference your custom tags. ### _deviceGroup @@ -62,7 +62,7 @@ Assign the _deviceType tag to devices running in your environment. Select the ap |webServer |HTTP servers. |

### _networkType -Assign the _networkType tag to network-related Entities. Select the appropriate tag value, based on the guidance in the table below. +Assign the _networkType tag to network-related entities. Select the appropriate tag value, based on the guidance in the table below. |Tag values |When to use | | :-- | :-- | @@ -91,7 +91,7 @@ Assign the _userGroup tag to users accounts known to be involved with specific **Description:** Accounts that are known to be involved with specific administrative or privileged activity. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * Windows - Excessive User Interactive Logons Across Multiple Hosts @@ -101,7 +101,7 @@ The following Cloud SIEM rules refer to this Match List: **Description:** Hosts that are known to be involved with specific administrative or privileged activity on the network. Can be used for tracking hosts that are operated by admins and other privileged users, or are often the source of restricted, privileged or suspicious authorized actions, and so on. This sort of tracking is useful for baselining activity and as a result, surfacing more suspicious activity. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * PowerShell Remote Administration * PsExec Admin Tool Detection @@ -113,7 +113,7 @@ The following Cloud SIEM rules refer to this Match List: **Description:** Users that are known to be involved with specific administrative or privileged activity. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * Lateral Movement Using the Windows Hidden Admin Share * Outlier in Data Outbound Per Day by Admin or Sensitive Device @@ -125,7 +125,7 @@ The following Cloud SIEM rules refer to this Match List: **Description:** IPs that are known to be involved with specific administrative or privileged activity on the network. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * Alibaba ActionTrail KMS Activity @@ -135,7 +135,7 @@ The following Cloud SIEM rules refer to this Match List: **Description:** Users that are known to be involved with specific administrative or privileged activity on the network. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * Alibaba ActionTrail KMS Activity @@ -145,7 +145,7 @@ The following Cloud SIEM rules refer to this Match List: **Description:** Network authentication servers, including Active Directory, LDAP, Kerberos, RADIUS/TACACS, and NIS servers. May be used in analytics designed to detect [DCSync](https://attack.mitre.org/techniques/T1003/006/) attacks. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * DNS Lookup of High Entropy Domain @@ -155,7 +155,7 @@ The following Cloud SIEM rules refer to this Match List: **Description:** Authorized third party domains. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * Salesforce LoginAs Event @@ -165,7 +165,7 @@ The following Cloud SIEM rules refer to this Match List: **Description:** Hosts that are known to be involved with specific administrative or privileged activity in AWS. Can be used for tracking hosts that are operated by admins and other privileged users, or are often the source of restricted, privileged or suspicious authorized actions, and so on. This sort of tracking is useful for baselining activity and as a result, surfacing more suspicious activity. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * AWS Cloud Storage Deletion * AWS CloudTrail - Aggressive Reconnaissance @@ -208,7 +208,7 @@ The following Cloud SIEM rules refer to this Match List: **Description:** Users that are known to be involved with specific administrative or privileged activity in AWS. Can be used for tracking users that are admins and other privileged users, or are often the source of restricted, privileged or suspicious authorized actions, and so on. This sort of tracking is useful for baselining activity and as a result, surfacing more suspicious activity. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * AWS Cloud Storage Deletion * AWS CloudTrail - Aggressive Reconnaissance @@ -251,7 +251,7 @@ The following Cloud SIEM rules refer to this Match List: **Description:** Remote ASNs supporting business processes. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * Domain Resolution in Non-Standard TLD * Executable Downloaded - Content-Type Mismatch @@ -269,7 +269,7 @@ The following Cloud SIEM rules refer to this Match List: *Domain* matches against the `domain` field, not the FQDN (i.e. hostname or query), so *example.com* is a valid entry is but *www.example.com* is not. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * Bitsadmin to Uncommon TLD * Connection to High Entropy Domain @@ -297,7 +297,7 @@ The following Cloud SIEM rules refer to this Match List: **Description:** DNS hostnames that are known to be business-related FQDNs. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * Bitsadmin to Uncommon TLD * Connection to High Entropy Domain @@ -327,7 +327,7 @@ The following Cloud SIEM rules refer to this Match List: **Description:** Remote IP addresses supporting business processes. Can be used for things like SSH servers for SFTP file exchanges (similarly, FTP servers). -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * Bitsadmin to Uncommon TLD * Connection to High Entropy Domain @@ -354,7 +354,7 @@ The following Cloud SIEM rules refer to this Match List: **Description:** DNS caching resolvers/authoritative content servers in customer environments. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * Direct Outbound DNS Traffic * Possible DNS over TLS (DoT) Activity @@ -366,7 +366,7 @@ The following Cloud SIEM rules refer to this Match List: **Description:** Domain controller IPs. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * Brute Force Attempt * Domain Brute Force Attempt @@ -384,7 +384,7 @@ The following Cloud SIEM rules refer to this Match List: **Description:** Domain controller hostnames. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * Interactive Logon to Domain Controller * Suspicious DC Logon @@ -393,9 +393,9 @@ The following Cloud SIEM rules refer to this Match List: **Target column:** Username (`Username`) -**Description:** Known account names that utilize downgraded encryption types with multiple SPNs. This is an exception Match List that should be populated with a list of Kerberos principal names (for example, jdoe@EXAMPLE.COM) matched in endpoint username that are known to trigger content around legacy downgraded encryption types. This is directly related to the detection of [*Kerberoasting*](https://attack.mitre.org/techniques/T1208/) attacks. +**Description:** Known account names that utilize downgraded encryption types with multiple SPNs. This is an exception match list that should be populated with a list of Kerberos principal names (for example, jdoe@EXAMPLE.COM) matched in endpoint username that are known to trigger content around legacy downgraded encryption types. This is directly related to the detection of [*Kerberoasting*](https://attack.mitre.org/techniques/T1208/) attacks. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * First Seen Kerberoasting Attempt from User - Global * First Seen Kerberoasting Attempt from User - Host @@ -409,7 +409,7 @@ The following Cloud SIEM rules refer to this Match List: This should be populated with list of account names confirmed in `event_data['SubjectUserName']` for regularly occurring 4662 baseline events. This may be used in analytics designed to detect [DCsync](https://attack.mitre.org/techniques/T1003/006/) attacks. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: none @@ -419,7 +419,7 @@ none **Description:** Authorized domains. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * Connection to High Entropy Domain * DNS query for dynamic DNS provider @@ -432,7 +432,7 @@ The following Cloud SIEM rules refer to this Match List: **Description:** Authorized hostnames. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * Connection to High Entropy Domain * DNS query for dynamic DNS provider @@ -445,7 +445,7 @@ The following Cloud SIEM rules refer to this Match List: **Description:** Known FTP servers. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: none @@ -455,7 +455,7 @@ none **Description:** Users or hosts that are known to be involved with specific administrative or privileged activity in GCP. Can be used for tracking users or hosts that are admins and other privileged users, or are often the source of restricted, privileged or suspicious authorized actions, and so on. This sort of tracking is useful for baselining activity and as a result, surfacing more suspicious activity. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * GCP Audit Cloud SQL Database Modified * GCP Audit GCE Firewall Rule Modified @@ -479,7 +479,7 @@ The following Cloud SIEM rules refer to this Match List: **Description:** Hosts that are known to be involved with specific administrative or privileged activity in GCP. Can be used for tracking hosts that are operated by admins and other privileged users, or are often the source of restricted, privileged or suspicious authorized actions, and so on. This sort of tracking is useful for baselining activity and as a result, surfacing more suspicious activity. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * GCP Image Creation * GCP Image Deletion @@ -496,7 +496,7 @@ The following Cloud SIEM rules refer to this Match List: **Description:** Users that are known to be involved with specific administrative or privileged activity in GCP. Can be used for tracking users that are admins and other privileged users, or are often the source of restricted, privileged or suspicious authorized actions, and so on. This sort of tracking is useful for baselining activity and as a result, surfacing more suspicious activity. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * GCP Image Creation * GCP Image Deletion @@ -513,7 +513,7 @@ The following Cloud SIEM rules refer to this Match List: **Description:** Hosts that are known to be involved with specific administrative or privileged activity in Google Workspace. Can be used for tracking hosts that are operated by admins and other privileged users, or are often the source of restricted, privileged or suspicious authorized actions, and so on. This sort of tracking is useful for baselining activity and as a result, surfacing more suspicious activity. -The following Cloud SIEM rule refers to this Match List: +The following Cloud SIEM rule refers to this match list: * G Suite - Admin Activity @@ -523,7 +523,7 @@ The following Cloud SIEM rule refers to this Match List: **Description:** Users that are known to be involved with specific administrative or privileged activity in Google Workspace. Can be used for tracking users that are admins and other privileged users, or are often the source of restricted, privileged or suspicious authorized actions, and so on. This sort of tracking is useful for baselining activity and as a result, surfacing more suspicious activity. -The following Cloud SIEM rule refers to this Match List: +The following Cloud SIEM rule refers to this match list: * G Suite - Admin Activity @@ -533,7 +533,7 @@ The following Cloud SIEM rule refers to this Match List: **Description:** Known guest WLAN and other guests/BYOD network addresses. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * Base32 in DNS Query * Bitsadmin to Uncommon TLD @@ -565,7 +565,7 @@ The following Cloud SIEM rules refer to this Match List: **Description:** List of IPs for Honeypots. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * Traffic to Honeypot IP @@ -575,7 +575,7 @@ The following Cloud SIEM rules refer to this Match List: **Description:** Web servers in your environment. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * Spike in URL Length from IP Address @@ -583,15 +583,15 @@ The following Cloud SIEM rules refer to this Match List: **Target column:** IP Address (`Ip`) -**Description:** IP addresses excepted from analytics identifying LAN protocol scanning activity. Used in specific cases to exclude hosts from flagging particular types of rule content, primarily around scanning of commonly targeted LAN service ports, etc. Not an across-the-board allowlist. This Match List is not intended for vulnerability scanners, which should be listed instead in vuln scanners. +**Description:** IP addresses excepted from analytics identifying LAN protocol scanning activity. Used in specific cases to exclude hosts from flagging particular types of rule content, primarily around scanning of commonly targeted LAN service ports, etc. Not an across-the-board allowlist. This match list is not intended for vulnerability scanners, which should be listed instead in vuln scanners. -Examples of hosts that are suited for this Match List: +Examples of hosts that are suited for this match list: * Telephony server that pushes content to deployed softphones over SMB/CIFS * Data security audit software that connects to SMB shares -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * Amazon VPC - Network Scan * Amazon VPC - Port Scan @@ -612,9 +612,9 @@ The following Cloud SIEM rules refer to this Match List: **Target column:** IP Address (`Ip`) -**Description:** Source NAT addresses. Can be used as an exception Match List to block content relying on the evaluation of data per-host from applying to hosts that are translated or aggregations of other hosts. Note that this can also be applied using [proxy_servers](#proxy_servers) as an example of a specific case. +**Description:** Source NAT addresses. Can be used as an exception match list to block content relying on the evaluation of data per-host from applying to hosts that are translated or aggregations of other hosts. Note that this can also be applied using [proxy_servers](#proxy_servers) as an example of a specific case. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * DNS DGA Lookup Behavior - NXDOMAIN Responses @@ -626,9 +626,9 @@ The following Cloud SIEM rules refer to this Match List: Hosts known to be Network Management System (NMS) nodes. -Can be used as an exception Match List for systems that connect to other hosts in environment for purposes of management, monitoring, and so on. +Can be used as an exception match list for systems that connect to other hosts in environment for purposes of management, monitoring, and so on. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * Amazon VPC - Network Scan * Amazon VPC - Port Scan @@ -646,7 +646,7 @@ The following Cloud SIEM rules refer to this Match List: **Description:** Users that are known to be involved with specific administrative or privileged activity. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * Okta Admin App Accessed @@ -658,7 +658,7 @@ The following Cloud SIEM rules refer to this Match List: Should contain the default IPv4 sinkhole address from PANW (72.5.65.111) and should include additionally any other sinkhole IP you have configured. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: None @@ -668,7 +668,7 @@ None **Description:** Forward proxy servers, including HTTP and SOCKS proxies. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * Amazon VPC - Network Scan * Amazon VPC - Port Scan @@ -686,9 +686,9 @@ The following Cloud SIEM rules refer to this Match List: **Target column:** Destination IP Address (`DstIp`) -**Description:** Copy of the [proxy_servers](#proxy_servers) Match List for directional matches. +**Description:** Copy of the [proxy_servers](#proxy_servers) match list for directional matches. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * Bitsadmin to Uncommon TLD * Excessive Outbound Firewall Blocks @@ -719,9 +719,9 @@ The following Cloud SIEM rules refer to this Match List: **Target column:** Source IP Address (`SrcIp`) -**Description:** Copy of the [proxy_server](#proxy_servers) Match List for directional matches. +**Description:** Copy of the [proxy_server](#proxy_servers) match list for directional matches. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: none @@ -731,7 +731,7 @@ none **Description:** Public Ip Addresses. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * Doublepulsar scan - likely not infected * Likely doublepulsar Infected @@ -742,7 +742,7 @@ The following Cloud SIEM rules refer to this Match List: **Description:** Hosts that are known to be involved with specific administrative or privileged activity in Salesforce. Can be used for tracking hosts that are operated by admins and other privileged users, or are often the source of restricted, privileged or suspicious authorized actions, and so on. This sort of tracking is useful for baselining activity and as a result, surfacing more suspicious activity. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * Salesforce Custom Permission Creation * Salesforce Excessive Documents Downloaded @@ -764,7 +764,7 @@ The following Cloud SIEM rules refer to this Match List: **Description:** Users that are known to be involved with specific administrative or privileged activity in Salesforce. Can be used for tracking users that are admins and other privileged users, or are often the source of restricted, privileged or suspicious authorized actions, and so on. This sort of tracking is useful for baselining activity and as a result, surfacing more suspicious activity. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * Salesforce Custom Permission Creation * Salesforce Excessive Documents Downloaded @@ -786,7 +786,7 @@ The following Cloud SIEM rules refer to this Match List: **Description:** Malware sandboxes or security devices interacting with malicious infrastructure. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * Threat Intel Match - IP Address * Threat Intel - Matched Domain Name @@ -799,7 +799,7 @@ The following Cloud SIEM rules refer to this Match List: **Description:** Destination networks that are authorized/standard targets of vulnerability scans in customer environment. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: none @@ -809,7 +809,7 @@ none **Description:** SMTP sending/receiving hosts in customer environment. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: none @@ -819,7 +819,7 @@ none **Description:** Database servers in customer environment. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: none @@ -829,7 +829,7 @@ none **Description:** Known SSH servers. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: none @@ -839,7 +839,7 @@ none **Description:** SSL exception IPs. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * SSL Certificate Expired * SSL Certificate Expires Soon @@ -852,7 +852,7 @@ The following Cloud SIEM rules refer to this Match List: **Description:** Telnet servers in your environment. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: none @@ -860,9 +860,9 @@ none **Target column:** IP Address (`Ip`) -**Description:** A record flagged an IP address from a threat intelligence Match List. +**Description:** A record flagged an IP address from a threat intelligence match list. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * Threat Intel - Successful Authentication from Threat IP * Threat Intel Match - IP Address @@ -878,7 +878,7 @@ The following Cloud SIEM rules refer to this Match List: **Description:** A list of devices that should not have external media installed on them. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * Unauthorized External Device Installation @@ -888,7 +888,7 @@ The following Cloud SIEM rules refer to this Match List: **Description:** Reviewed and validated legitimate or non-threat applications. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * Lateral Movement Using the Windows Hidden Admin Share @@ -898,7 +898,7 @@ The following Cloud SIEM rules refer to this Match List: **Description:** Reviewed and validated legitimate or non-threat domains. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * Base32 in DNS Query * Bitsadmin to Uncommon TLD @@ -926,7 +926,7 @@ The following Cloud SIEM rules refer to this Match List: **Description:** Reviewed and validated legitimate or non-threat hostnames. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * Bitsadmin to Uncommon TLD * Connection to High Entropy Domain @@ -954,7 +954,7 @@ The following Cloud SIEM rules refer to this Match List: **Description:** Reviewed and validated legitimate or non-threat ips. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * Domain Resolution in Non-Standard TLD * HTTP Request to Domain in Non-Standard TLD @@ -970,7 +970,7 @@ The following Cloud SIEM rules refer to this Match List: **Description:** Reviewed and validated legitimate or non-threat IP addresses. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * Executable Downloaded - Content-Type Mismatch @@ -984,7 +984,7 @@ This is a shared match list that should be imported into target environments. Match list items have a TTL specified that will result in the items having an expiration date set in the future. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * Executable Downloaded - Content-Type Mismatch * HTTP Request to Domain in Non-Standard TLD @@ -995,7 +995,7 @@ The following Cloud SIEM rules refer to this Match List: **Description:** VPN/remote access user address pools and DHCP scopes. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: none @@ -1005,7 +1005,7 @@ none **Description:** VPN/remote access servers, including IKE/IPsec/SSL VPN concentrators, OpenVPN endpoints, and so on. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: none @@ -1015,7 +1015,7 @@ none **Description:** Vulnerability scanner and network mapping hosts. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * Amazon VPC - Network Scan * Amazon VPC - Port Scan @@ -1080,7 +1080,7 @@ The following Cloud SIEM rules refer to this Match List: **Description:** List of webserver hostnames or IPs. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * Web Servers Executing Suspicious Processes @@ -1090,7 +1090,7 @@ The following Cloud SIEM rules refer to this Match List: **Description:** Known admin users of Zoom. -The following Cloud SIEM rules refer to this Match List: +The following Cloud SIEM rules refer to this match list: * Zoom - Account Created * Zoom - Account Deleted diff --git a/docs/cse/match-lists-suppressed-lists/suppressed-lists.md b/docs/cse/match-lists-suppressed-lists/suppressed-lists.md index 5755be5f52..795146b828 100644 --- a/docs/cse/match-lists-suppressed-lists/suppressed-lists.md +++ b/docs/cse/match-lists-suppressed-lists/suppressed-lists.md @@ -1,26 +1,26 @@ --- id: suppressed-lists title: Suppressed Lists -description: Suppressed Lists allow you to suppress Signals that contain a particular indicator value in any of the Signals’ Records. +description: Suppressed lists allow you to suppress signals that contain a particular indicator value in any of the signals’ records. --- import useBaseUrl from '@docusaurus/useBaseUrl'; -This topic has information about Suppressed Lists and how to create them. +This topic has information about suppressed lists and how to create them. -## About Suppressed Lists +## About suppressed lists -Cloud SIEM supports several types of [Signal suppression](/docs/cse/records-signals-entities-insights/about-signal-suppression): suppression of redundant Signals, suppression of Signals on particular Entities, suppression of Signals on blocks of IP addresses, and finally the Suppressed Lists feature, which enables you to suppress Signals that contain a particular indicator value in any of the Signals’ Records.   +Cloud SIEM supports several types of [signal suppression](/docs/cse/records-signals-entities-insights/about-signal-suppression): suppression of redundant signals, suppression of signals on particular entities, suppression of signals on blocks of IP addresses, and finally the suppressed lists feature, which enables you to suppress signals that contain a particular indicator value in any of the signals’ records.   -You can create Suppressed Lists from the Cloud SIEM UI or using the Cloud SIEM API. A Suppressed List can contain a set of indicators—IPs, hostnames, or any other type that you can use in a Match List—and then any Signal that has a Record containing a listed indicator will be suppressed.  +You can create suppressed lists from the Cloud SIEM UI or using the Cloud SIEM API. A suppressed list can contain a set of indicators—IPs, hostnames, or any other type that you can use in a match list—and then any signal that has a record containing a listed indicator will be suppressed.  -Here is an example of a Suppressed List. +Here is an example of a suppressed list. Suppressed list -Note that the list has a Target Column, which you define when you create the list. The Target Column indicates what type of Record fields should be compared to the Suppressed List, for example, hostnames, URLs, domains, IP addresses, usernames, and so on. For more information, see [How are Suppressed Lists used](#how-are-suppressed-lists-used). +Note that the list has a **Target Column**, which you define when you create the list. The target column indicates what type of record fields should be compared to the suppressed list, for example, hostnames, URLs, domains, IP addresses, usernames, and so on. For more information, see [How are suppressed lists used](#how-are-suppressed-lists-used). -When you create a Suppressed List, you can choose one of the following as its Target Column. +When you create a suppressed list, you can choose one of the following as its target column. * Hostname * File Hash @@ -40,54 +40,54 @@ When you create a Suppressed List, you can choose one of the following as its Ta * Destination IP ISP * Destination IP Organization -## Suppressed List or Match List? +## Suppressed list or match list? -When deciding whether to put an indicator on a Suppressed List or a Match List, consider the following. +When deciding whether to put an indicator on a suppressed list or a match list, consider the following. -Suppressed Lists are intended for situations in which you want to suppress *any* Signal with a Record that contains a suppressed indicator. You don’t need to reference a suppressed list in a rule expression for suppression to occur.  +Suppressed lists are intended for situations in which you want to suppress *any* signal with a record that contains a suppressed indicator. You don’t need to reference a suppressed list in a rule expression for suppression to occur.  -Match Lists are for when you want to use the existence or absence of an indicator to determine whether a specific rule or set of rules should fire a Signal. So, a Match List only has an effect when referenced by a rule expression. +Match lists are for when you want to use the existence or absence of an indicator to determine whether a specific rule or set of rules should fire a signal. So, a match list only has an effect when referenced by a rule expression. -## How are Suppressed Lists used?  +## How are suppressed lists used?  -Cloud SIEM uses Suppressed Lists similar to how it uses [Match Lists](#suppressed-list-or-match-list). When Cloud SIEM processes an incoming Record, it compares the entries in each Suppressed List to Record fields of the same type as the Target Column of the Suppressed List. For example, given a Suppressed List whose Target Column is **Domain**, Cloud SIEM will compare items on that list only to Record fields that contain domains. +Cloud SIEM uses suppressed lists similar to how it uses [match lists](#suppressed-list-or-match-list). When Cloud SIEM processes an incoming record, it compares the entries in each suppressed list to record fields of the same type as the target column of the suppressed list. For example, given a suppressed list whose target column is **Domain**, Cloud SIEM will compare items on that list only to record fields that contain domains. -When a Record contains a value that matches one or more Suppressed Lists, two fields in the Record get populated: +When a record contains a value that matches one or more suppressed lists, two fields in the record get populated: -* `listMatches`. Cloud SIEM adds the names of the Suppressed Lists that the Record matched, and the column values of those lists. For example, if an IP address in a Record matches the SourceIP address in the “vuln_scanners” Suppressed List, the `listMatches` field would look like this: `listMatches: ['vuln_scanners', 'column:SourceIp']`   -* `matchedItems`. Cloud SIEM adds the actual key-value pairs that were matched. For example, continuing the example above, if “vuln_scanners” Match List contained an entry “5.6.7.8”, and the Record’s SourceIp is also “5.6.7.8”, the assuming the SourceIP address in the “vuln_scanners” Suppressed List, the `matchedItems` field would look like this: `matchedItems: [ { value: '5.6.7.8', …other metadata about list item } ]` +* `listMatches`. Cloud SIEM adds the names of the suppressed lists that the record matched, and the column values of those lists. For example, if an IP address in a record matches the SourceIP address in the “vuln_scanners” suppressed list, the `listMatches` field would look like this: `listMatches: ['vuln_scanners', 'column:SourceIp']`   +* `matchedItems`. Cloud SIEM adds the actual key-value pairs that were matched. For example, continuing the example above, if “vuln_scanners” match list contained an entry “5.6.7.8”, and the record’s SourceIp is also “5.6.7.8”, the assuming the SourceIP address in the “vuln_scanners” suppressed list, the `matchedItems` field would look like this: `matchedItems: [ { value: '5.6.7.8', …other metadata about list item } ]` -Because the information about list matches gets persisted within Records, you can reference it downstream in both rules and search. +Because the information about list matches gets persisted within records, you can reference it downstream in both rules and search. -**If any entities within the Record match items listed in a suppressed list, suppressed Signals will be generated for those entities across all rules**. Consequently, these Signals will not affect the entity's Activity Score or contribute to Insight generation. +**If any entities within the record match items listed in a suppressed list, suppressed signals will be generated for those entities across all rules**. Consequently, these signals will not affect the entity's Activity Score or contribute to insight generation. -For more information about Signal Suppression mechanisms, see [About Signal Suppression](/docs/cse/records-signals-entities-insights/about-signal-suppression/). +For more information about signal Suppression mechanisms, see [About Signal Suppression](/docs/cse/records-signals-entities-insights/about-signal-suppression/). -## Suppressed List limitations  +## Suppressed list limitations  -A Suppressed List can contain up to 50,000 items. +A suppressed list can contain up to 50,000 items. -## Create a Suppressed List from the UI +## Create a suppressed list from the UI -Perform the steps below to create a Suppressed List and add an indicator to it using the Cloud SIEM UI. +Perform the steps below to create a suppressed list and add an indicator to it using the Cloud SIEM UI. 1. [**Classic UI**](/docs/get-started/sumo-logic-ui-classic). In the top menu select **Content > Suppressed Lists**.
[**New UI**](/docs/get-started/sumo-logic-ui). In the main Sumo Logic menu, select **Cloud SIEM > Suppressed Lists**. You can also click the **Go To...** menu at the top of the screen and select **Suppressed Lists**. 1. Click **Create**.
Create a suppressed list 1. On the **New Suppressed List** popup, enter the following: - 1. **Name**. Name of the Suppressed List. + 1. **Name**. Name of the suppressed list. 1. **Description**. Enter a description for the list.  1. **Time to Live (hours)**. (Optional) Enter the number of hours after which the entries on the list should expire. - 1. **Target Column**. The type of Record field to which items on the list should be compared. + 1. **Target Column**. The type of record field to which items on the list should be compared. :::note - If you want to create a custom Target Column, click **Manage Custom Columns**. For more information, see [Custom Match List Columns](/docs/cse/match-lists-suppressed-lists/custom-match-list-columns). + If you want to create a custom target column, click **Manage Custom Columns**. For more information, see [Custom Match List Columns](/docs/cse/match-lists-suppressed-lists/custom-match-list-columns). ::: 1. Click **Create**. -1. The Suppressed List now appears on the **Suppressed Lists** page. -1. Click the name of the Suppressed List to open it. +1. The suppressed list now appears on the **Suppressed Lists** page. +1. Click the name of the suppressed list to open it. 1. On the **Suppressed List > Details** page, click **Add List Item**.
Add list item 1. On the **New Suppressed List Item** popup, enter: - 1. **Value**. The value of the entity. Make sure the value you enter is of the same type as the type you selected as the Target Column for the list. For example, if the Target Column is Domain, enter a domain. + 1. **Value**. The value of the entity. Make sure the value you enter is of the same type as the type you selected as the target column for the list. For example, if the target column is Domain, enter a domain. 1. **Description**. (Optional) Enter a description of the list item. 1. **Expiration**. (Optional) The date and time at which the list item should be removed from the list. 1. Click **Add** to add the item to the list. @@ -101,7 +101,7 @@ You can import list items by uploading a .csv file. This is convenient when you Create a .csv file. You can import up to three fields for an item. -* **value** (Required). The value of the list item. The item you supply should be of the same type as the Target Column defined for the Suppressed List. For example, if the Target Column is IP Address, supply an IP address. +* **value** (Required). The value of the list item. The item you supply should be of the same type as the target column defined for the suppressed list. For example, if the target column is IP Address, supply an IP address. * **description** (Optional). A description of the list item. * **expires** (Optional). Expiration date and time for the list item, in ISO 8601 format, for example: *2020-08-17 01:18:00 * @@ -130,10 +130,10 @@ specified: 1. Drag your file onto the import popup, or click to navigate to the file, and then click Import. 1. Optionally, you can enter an expiration for the indicators on the list. If you do, it will override any expirations that are defined in the file. Enter the expiration in any ISO date format. For example: `2022-12-31` -## Manage Suppressed Lists with the Cloud SIEM API +## Manage suppressed lists with the Cloud SIEM API -You can use Cloud SIEM APIs to create and manage Suppressed Lists. For information about Cloud SIEM APIs and how to access the API documentation, see [Cloud SIEM APIs](/docs/cse/administration/cse-apis). +You can use Cloud SIEM APIs to create and manage suppressed lists. For information about Cloud SIEM APIs and how to access the API documentation, see [Cloud SIEM APIs](/docs/cse/administration/cse-apis). -## Best Practices for using Suppressed Lists +## Best Practices for using suppressed lists -When creating a custom Suppressed List, consider directionality selecting the Target Column. In most cases, Suppressed Lists work fine with a directionless column type, like IP Address. However, in some cases, a Suppressed List is best configured with a directional column type, such as Source IP Address or Destination IP Address. In some cases it works best to create multiple Suppressed Lists with the same items in each, but different Target Columns. For example, you can have the same IP addresses in three Suppressed List: one whose target column is IP Address, one with Source IP Address, and one with Destination IP Address.    +When creating a custom suppressed list, consider directionality selecting the target column. In most cases, suppressed lists work fine with a directionless column type, like IP Address. However, in some cases, a suppressed list is best configured with a directional column type, such as Source IP Address or Destination IP Address. In some cases it works best to create multiple suppressed lists with the same items in each, but different target columns. For example, you can have the same IP addresses in three suppressed list: one whose target column is IP Address, one with Source IP Address, and one with Destination IP Address.    From 5ef98b8ee039f0176be10c21845871d6ec9005a5 Mon Sep 17 00:00:00 2001 From: John Pipkin Date: Wed, 18 Dec 2024 16:07:59 -0600 Subject: [PATCH 5/6] Make terms lowercase in 'Automation' section --- ...about-automation-service-and-cloud-siem.md | 14 +-- .../automation/automations-in-cloud-siem.md | 108 +++++++++--------- .../cloud-siem-automation-examples.md | 38 +++--- docs/cse/automation/index.md | 4 +- 4 files changed, 82 insertions(+), 82 deletions(-) diff --git a/docs/cse/automation/about-automation-service-and-cloud-siem.md b/docs/cse/automation/about-automation-service-and-cloud-siem.md index 9df905bd6f..3e7b6dc41a 100644 --- a/docs/cse/automation/about-automation-service-and-cloud-siem.md +++ b/docs/cse/automation/about-automation-service-and-cloud-siem.md @@ -22,13 +22,13 @@ The Automation Service is a subset of automation capabilities adapted from Cloud ## Benefits * The Automation Service supports enrichment, notification, containment, user choice, and custom actions in Cloud SIEM. -* Enrichment actions can be used to gather additional information about an Entity or Insight, including threat indicators. +* Enrichment actions can be used to gather additional information about an entity or insight, including threat indicators. * Notification actions can be used to send notifications or update status in systems like Cloud SIEM, the Sumo Logic core platform, Slack, Microsoft Teams, Jira, email, and so on. -* Automations can be triggered automatically when an Insight is created or closed. For example, you could define a playbook that is executed automatically when an Insight is created that gathers enrichment data. And if the data returned includes a malicious threat indicator: - 1. Changes the Insight state to “In Progress”. - 1. Assigns the Insight. - 1. Sends a (customized) email with information about the Insight and indicator. - 1. Creates a Slack channel for the Insight. +* Automations can be triggered automatically when an insight is created or closed. For example, you could define a playbook that is executed automatically when an insight is created that gathers enrichment data. And if the data returned includes a malicious threat indicator: + 1. Changes the insight state to “In Progress”. + 1. Assigns the insight. + 1. Sends a (customized) email with information about the insight and indicator. + 1. Creates a Slack channel for the insight. 1. Invites certain people to the Slack channel. :::note @@ -81,7 +81,7 @@ Access to the Automation Service is controlled by [role capabilities](/docs/mana The [Cloud SIEM API](/docs/cse/administration/cse-apis/) supports automations. Endpoints include: * `GET /automations`. Get the list of automations * `POST /automations`. Create an automation -* `POST /automations/execute`. Run one or more automations against one or more Entities/Insights +* `POST /automations/execute`. Run one or more automations against one or more entities/insights * `DELETE /automations/{id}`. Delete an automation * `GET /automations/{id}`. Get a specific automation * `PUT /automations/{id}`. Update a specific automation diff --git a/docs/cse/automation/automations-in-cloud-siem.md b/docs/cse/automation/automations-in-cloud-siem.md index 2ec0430d7f..b1bf525320 100644 --- a/docs/cse/automation/automations-in-cloud-siem.md +++ b/docs/cse/automation/automations-in-cloud-siem.md @@ -2,13 +2,13 @@ id: automations-in-cloud-siem title: Automations in Cloud SIEM sidebar_label: Automations in Cloud SIEM -description: Learn how automations run playbooks to add enrichments and create notifications for either Insights or Entities. +description: Learn how automations run playbooks to add enrichments and create notifications for either insights or entities. --- import useBaseUrl from '@docusaurus/useBaseUrl'; import ActionsLimit from '../../reuse/actions-limit.md'; -Cloud SIEM automations run playbooks in the [Automation Service](/docs/platform-services/automation-service/) to add enrichments and create notifications for either Insights or Entities. You can set automations to run automatically when Insights are created or closed, or you can run them manually. +Cloud SIEM automations run playbooks in the [Automation Service](/docs/platform-services/automation-service/) to add enrichments and create notifications for either insights or entities. You can set automations to run automatically when insights are created or closed, or you can run them manually. :::note @@ -56,24 +56,24 @@ Now that the playbook is configured, you can add it to an automation. 1. [Create a new automation](#create-an-automation). 1. Select the playbook you created in Step 2. 1. In **Object (expects attributes for)**, select **Entity** or **Insight**. -1. Select whether you want to automatically run the automation when an Insight is created or closed, or to run it manually. (For the purposes of this overview, select **Manually Done**.) +1. Select whether you want to automatically run the automation when an insight is created or closed, or to run it manually. (For the purposes of this overview, select **Manually Done**.) 1. Select **Enabled**. 1. Click **Save**. ### Step 4: Run the automation -Now that you've created the automation, it is ready to run. If you set the automation to run when an Insight is created or closed, it runs [automatically](#run-an-automation-automatically). +Now that you've created the automation, it is ready to run. If you set the automation to run when an insight is created or closed, it runs [automatically](#run-an-automation-automatically). -If you configured the automation to [run manually](#run-an-automation-manually), you can run it from an Insight or an Entity: +If you configured the automation to [run manually](#run-an-automation-manually), you can run it from an insight or an entity: * Insights - 1. Open an Insight. + 1. Open an insight. 1. Click **Actions**. - 1. Select the automation from one of the following, depending on whether the automation expects attributes for Insights or Entities: - * **Insight Automation**. Displays a list of all enabled Insight automations configured to run manually. - * **Entity Automation**. Displays a **Run Automations** option. Click **Run Automations** to open a dialog enabling you to select one or more Entity automations to run. + 1. Select the automation from one of the following, depending on whether the automation expects attributes for insights or entities: + * **Insight Automation**. Displays a list of all enabled insight automations configured to run manually. + * **Entity Automation**. Displays a **Run Automations** option. Click **Run Automations** to open a dialog enabling you to select one or more entity automations to run. * Entities - 1. Open an Entity. - 1. Click **Automations** under the Entity's name. + 1. Open an entity. + 1. Click **Automations** under the entity's name. 1. Select an option under **Entity Automation**. :::note @@ -85,7 +85,7 @@ If you configured the automation to [run manually](#run-an-automation-manually), 1. [**Classic UI**](/docs/get-started/sumo-logic-ui-classic). In the top menu select **Configuration**, and then under **Integrations** select **Automation**.
[**New UI**](/docs/get-started/sumo-logic-ui). In the top menu select **Configuration**, and then under **Cloud SIEM Integrations** select **Automation**. You can also click the **Go To...** menu at the top of the screen and select **Automation**. 1. View the list of available automations. (If no automations display, you must first [create an automation](#create-an-automation)).
Automations list -To view the automations that have run on Insights or Entities, see [View results of an automation](#view-results-of-an-automation). +To view the automations that have run on insights or entities, see [View results of an automation](#view-results-of-an-automation). ## Create an automation @@ -95,74 +95,74 @@ The following procedure provides a brief introduction to how to create an automa 1. At the top of the **Automation** tab, click **+ Add Automation**. (To modify an existing automation, select the automation and click **Edit**.)
Automations list 1. In the **Add Automation** dialog, select a **Playbook** from the drop-down list. The playbook must be defined before associating it with an automation.
New Automation 1. Set the **Status**. Disabled automations will not run automatically and will not appear in any **Actions** or **Automations** menus. -1. In **Object (xpects attributes for)** select whether the playbook will run on an **Entity** or **Insight**. This defines what data payload will be sent to the playbook from Cloud SIEM. If **Entity** is selected, in the **Type** field select one or more Entity types. The playbook will only execute on the Entity types selected. -1. For **Execution** select when the automation runs: **Insight Created**, **Insight Closed**, or **Manually Done**. If **Manually Done** is not selected, the automation will not appear in any **Actions** menu on Insights or **Automations** menus on Entities. +1. In **Object (xpects attributes for)** select whether the playbook will run on an **Entity** or **Insight**. This defines what data payload will be sent to the playbook from Cloud SIEM. If **Entity** is selected, in the **Type** field select one or more entity types. The playbook will only execute on the entity types selected. +1. For **Execution** select when the automation runs: **Insight Created**, **Insight Closed**, or **Manually Done**. If **Manually Done** is not selected, the automation will not appear in any **Actions** menu on insights or **Automations** menus on entities. 1. Click **Save**. ## Run an automation automatically -If an automation is set to run when an Insight is created or closed, it runs automatically provided that: +If an automation is set to run when an insight is created or closed, it runs automatically provided that: * The automation is enabled, * The automation is configured to run on the trigger(s), and -* The automation is an Insight automation, or -* The automation is an Entity automation, and the Insight contains one or more Entities of the Entity types configured in the automation (this includes the primary and any related Entities). +* The automation is an insight automation, or +* The automation is an entity automation, and the insight contains one or more entities of the entity types configured in the automation (this includes the primary and any related entities). ## Run an automation manually -### Run an automation manually on Insights +### Run an automation manually on insights -Automations can be run manually from the **Actions** drop-down menu on [Insight details](/docs/cse/get-started-with-cloud-siem/about-cse-insight-ui#insight-details-page) pages: +Automations can be run manually from the **Actions** drop-down menu on [insight details](/docs/cse/get-started-with-cloud-siem/about-cse-insight-ui#insight-details-page) pages: Automations on the Actions menu You will see three sections in the **Actions** menu: -* **Insight Automation**. Displays a list of all enabled Insight automations configured to run manually. -* **Entity Automation**. Displays a **Run Automations** option. Click **Run Automations** to open a dialog enabling you to select one or more Entity automations to run (see below). -* **Insight Actions**. Displays a list of all valid legacy Insight Actions. +* **Insight Automation**. Displays a list of all enabled insight automations configured to run manually. +* **Entity Automation**. Displays a **Run Automations** option. Click **Run Automations** to open a dialog enabling you to select one or more entity automations to run (see below). +* **Insight Actions**. Displays a list of all valid legacy insight actions. -### Run an automation manually on Entities +### Run an automation manually on entities -On [Entity details](/docs/cse/records-signals-entities-insights/view-manage-entities#about-the-entities-details-page) pages, Entity Automations can be run manually from the **Automations** drop-down menu: +On [entity details](/docs/cse/records-signals-entities-insights/view-manage-entities#about-the-entities-details-page) pages, entity automations can be run manually from the **Automations** drop-down menu: -Automations menu on an Entity +Automations menu on an entity :::tip -You can run the same automation more than once for a given Entity or Insight, but not at the same time. Additional attempts to run an automation while an instance is running will result in an error. +You can run the same automation more than once for a given entity or insight, but not at the same time. Additional attempts to run an automation while an instance is running will result in an error. ::: -### Select Entities to run the automation on +### Select entities to run the automation on -On an Insight, if you select **Actions** > **Entity Automation > Run Automations**, you will be prompted to select one or more of the Entities included in the Insight: +On an insight, if you select **Actions** > **Entity Automation > Run Automations**, you will be prompted to select one or more of the entities included in the insight: -Entity Automation menu +Entity automation menu -1. Select one or more of the Entities listed or select **Select All Entities**. The selected Entities don’t have to be the same type. -1. Click **Next**. A list displays of all Entity automations that are enabled, configured to be run manually, and configured for at least one of the Entity types you selected on the previous screen. -1. Select the automations you wish to run and click **Run Automation**. The system will automatically run the appropriate automations for the appropriate Entity Types.
Entity Automation menu with selections +1. Select one or more of the entities listed or select **Select All Entities**. The selected entities don’t have to be the same type. +1. Click **Next**. A list displays of all entity automations that are enabled, configured to be run manually, and configured for at least one of the entity types you selected on the previous screen. +1. Select the automations you wish to run and click **Run Automation**. The system will automatically run the appropriate automations for the appropriate entity Types.
Entity automation menu with selections ## View results of an automation -If an automation is set to run when an Insight is created or closed, it [runs automatically](#run-an-automation-automatically). You can also [run an automation manually](#run-an-automation-manually). +If an automation is set to run when an insight is created or closed, it [runs automatically](#run-an-automation-automatically). You can also [run an automation manually](#run-an-automation-manually). -### View automations on Insights and Entities +### View automations on insights and entities -When automations run, the results display on Insights and Entities. -1. Open an Insight or Entity. -1. Click **Automations** at the top of the screen. The example below shows automations that ran on an Insight. Each automation shows its result under **Status**. You can click **View Playbook** to see the playbook that the automation ran.
Automations on an Insight +When automations run, the results display on insights and entities. +1. Open an insight or entity. +1. Click **Automations** at the top of the screen. The example below shows automations that ran on an insight. Each automation shows its result under **Status**. You can click **View Playbook** to see the playbook that the automation ran.
Automations on an insight -While viewing an Insight or Entity, you can [run automations manually](#run-an-automation-manually). +While viewing an insight or entity, you can [run automations manually](#run-an-automation-manually). ### View enrichments provided by automations -When automations run, they can provide enrichments to Insights, Entities, and Signals. -1. Open an Insight, Entity, or Signal with enrichments provided by an automation. +When automations run, they can provide enrichments to insights, entities, and signals. +1. Open an insight, entity, or signal with enrichments provided by an automation. 1. Click **Enrichments** at the top of the screen. 1. If [threat indicators are set by the enrichment](/docs/cse/integrations/enrichments-and-indicators#threat-indicators), they are displayed. The following example shows a **Malicious** threat indicator.
Threat indicator example ## View an automation's status -After [running an automation](#run-an-automation-automatically), you can go to the **Automations** tab for the Insight or Entity to view the automation's status. +After [running an automation](#run-an-automation-automatically), you can go to the **Automations** tab for the insight or entity to view the automation's status. Automations execution status @@ -198,15 +198,15 @@ Migrating to the Automation Service has many benefits over using legacy actions ### Use installed playbooks Though you can create your own playbooks, the Automation Service provides the following playbooks with functionality that replaces legacy actions and enrichments: -* **Insight Full Enrichment**. Enriches the whole Insight with Recorded Future. It enriches both the primary and all the involved Entities by sorting them based on their Entity type. The playbook alerts you if a risky Entity is detected, and also adds tags to the Insight for easier identification. -* **Entity Full Enrichment**. Determines the Entity type and uses the appropriate Recorded Future technology to enrich. -* **Enrich Entity with PowerShell Carbon Black**. Executes the PowerShell script to enrich with Carbon Black, adds the enrichment to the Entity, and sends an email if a risky score is detected. -* **Enrich Entity with PowerShell CrowdStrike**. Executes the PowerShell script to enrich with CrowdStrike, and adds the enrichment to the Entity. -* **Enrich Entity with PowerShell GreyNoise**. Executes the PowerShell script to enrich with GreyNoise, and adds the enrichment to the Entity. -* **Enrich Entity with PowerShell SentinelOne**: Executes the PowerShell script to enrich with SentinelOne, and adds the enrichment to the Entity. -* **Enrich Entity with PowerShell nslookup**. Performs nslookup in the local host where PowerShell is running, and adds the enrichment to the Entity. -* **Enrich Entity with PowerShell Whois**. Performs whois in the local host where PowerShell is running, and adds the enrichment to the Entity. -* **Enrich Entity with PowerShell User Query**: Performs a query on user in the local host where PowerShell is running, and adds the enrichment to the Entity. +* **Insight Full Enrichment**. Enriches the whole insight with Recorded Future. It enriches both the primary and all the involved entities by sorting them based on their entity type. The playbook alerts you if a risky entity is detected, and also adds tags to the insight for easier identification. +* **Entity Full Enrichment**. Determines the entity type and uses the appropriate Recorded Future technology to enrich. +* **Enrich Entity with PowerShell Carbon Black**. Executes the PowerShell script to enrich with Carbon Black, adds the enrichment to the entity, and sends an email if a risky score is detected. +* **Enrich Entity with PowerShell CrowdStrike**. Executes the PowerShell script to enrich with CrowdStrike, and adds the enrichment to the entity. +* **Enrich Entity with PowerShell GreyNoise**. Executes the PowerShell script to enrich with GreyNoise, and adds the enrichment to the entity. +* **Enrich Entity with PowerShell SentinelOne**: Executes the PowerShell script to enrich with SentinelOne, and adds the enrichment to the entity. +* **Enrich Entity with PowerShell nslookup**. Performs nslookup in the local host where PowerShell is running, and adds the enrichment to the entity. +* **Enrich Entity with PowerShell Whois**. Performs whois in the local host where PowerShell is running, and adds the enrichment to the entity. +* **Enrich Entity with PowerShell User Query**: Performs a query on user in the local host where PowerShell is running, and adds the enrichment to the entity. ### Replace legacy actions and enrichments @@ -220,12 +220,12 @@ In place of the following legacy actions, use the corresponding actions from [in Legacy action | Description | Corresponding action
in the Automation Service | Additional instructions | | :-- | :-- | :-- | :-- | -| AWS Simple Notification Service | Pushes Insight JSON to the AWS Simple Notification Service. | The **Send Message** action in the **AWS Simple Notification Service** integration. | NA| -| Email | Sends email with Insight details to a list of recipients. The email includes the MITRE tactic and Insight link. | The **Send Email** action in the **Basic Tools** integration). | NA | -| HTTP POST v2 | Allows you to send a full Insight in JSON format to any HTTP URL. | The **HTTP POST** action in the **HTTP Tools** integration. | NA | +| AWS Simple Notification Service | Pushes insight JSON to the AWS Simple Notification Service. | The **Send Message** action in the **AWS Simple Notification Service** integration. | NA| +| Email | Sends email with insight details to a list of recipients. The email includes the MITRE tactic and insight link. | The **Send Email** action in the **Basic Tools** integration). | NA | +| HTTP POST v2 | Allows you to send a full insight in JSON format to any HTTP URL. | The **HTTP POST** action in the **HTTP Tools** integration. | NA | | Microsoft Teams | Sends a message to a Teams channel using a webhook URL. | The **Send Teams Message** action in the **Microsoft Teams** integration.| Create a node with the **Send Teams Message** action and configure it with the message content and the channel name to which the message must be sent. | | PagerDuty | Sends a notification to PagerDuty.| The **Create New Incident** action in the **PagerDuty** integration. | NA | -| Recorded Future | Performs IP, URL, and hash reputation, and pushes the enrichment in the Insight. | The **IP Reputation**, **URL Reputation**, and **File Reputation** actions in the **Recorded Future OIF** integration. | 1. Create a node with the reputation action needed. You can add a condition node before the action to automatically determine the reputation action based on the Entity type.
2. Create another node with the **Add Insight Enrichment** action from the **CSE Tools** integration, and configure it to use as enrichment the `output.raw` from the previous node. | +| Recorded Future | Performs IP, URL, and hash reputation, and pushes the enrichment in the insight. | The **IP Reputation**, **URL Reputation**, and **File Reputation** actions in the **Recorded Future OIF** integration. | 1. Create a node with the reputation action needed. You can add a condition node before the action to automatically determine the reputation action based on the entity type.
2. Create another node with the **Add Insight Enrichment** action from the **CSE Tools** integration, and configure it to use as enrichment the `output.raw` from the previous node. | | Slack | Sends a message to a Slack channel. | The **Send Message** action in the **Slack** integration. | Create a node with the **Send Message** action and configure the node with the channel name to which the message must be sent. | #### Legacy enrichments diff --git a/docs/cse/automation/cloud-siem-automation-examples.md b/docs/cse/automation/cloud-siem-automation-examples.md index 14ac607fe4..75e7dfbd35 100644 --- a/docs/cse/automation/cloud-siem-automation-examples.md +++ b/docs/cse/automation/cloud-siem-automation-examples.md @@ -16,7 +16,7 @@ Following are examples that show you how to create Cloud SIEM automations using ## Simple example: Configure an enrichment -The following example shows how to add an enrichment to an Insight using the “IP Reputation V3” action from VirusTotal. +The following example shows how to add an enrichment to an insight using the “IP Reputation V3” action from VirusTotal. 1. Edit the VirusTotal OIF resource: 1. [**Classic UI**](/docs/get-started/sumo-logic-ui-classic). In the main Sumo Logic menu, select **Automation** and then select **Integrations** in the left nav bar.
[**New UI**](/docs/get-started/sumo-logic-ui). In the main Sumo Logic menu, select **Automation > Integrations**. You can also click the **Go To...** menu at the top of the screen and select **Integrations**. @@ -55,12 +55,12 @@ The following example shows how to add an enrichment to an Insight using the “ 1. In the **Enrichment name** field, type **VirusTotal IP reputation**. 1. To the right of the **Raw JSON** field, click the gear icon. 1. Click **IP reputation V3** and select **output.raw**. - 1. Click **Create**.
Add node for Insight enrichment + 1. Click **Create**.
Add node for insight enrichment 1. Click and hold on the right semicircle of the new **Add Insight Enrichment** node and drag to the semicircle of the **END** node and release. The playbook is complete. 1. Save the playbook: 1. Click the **Save** button (floppy disk icon) at the bottom of the playbook view. 1. To [test the playbook](/docs/platform-services/automation-service/automation-service-playbooks/#test-a-playbook), click the kebab button in the upper-right of the UI and select **Run Test**. - 1. Click the **Publish** button (clipboard icon) at the bottom of the playbook view. The playbook should look like this:
Simple playbook for Insight enrichment + 1. Click the **Publish** button (clipboard icon) at the bottom of the playbook view. The playbook should look like this:
Simple playbook for insight enrichment 1. Create an automation in Cloud SIEM to run the playbook: 1. [**Classic UI**](/docs/get-started/sumo-logic-ui-classic). In the main Sumo Logic menu select **Cloud SIEM**. In the top menu select **Configuration**, and then under **Integrations** select **Automation**.
[**New UI**](/docs/get-started/sumo-logic-ui). In the top menu select **Configuration**, and then under **Cloud SIEM Integrations** select **Automation**. You can also click the **Go To...** menu at the top of the screen and select **Automation**. 1. At the top of the **Automation** tab, click **+ Add Automation**. @@ -70,10 +70,10 @@ The following example shows how to add an enrichment to an Insight using the “ 1. Click **Save**. 1. Run the automation: 1. Select **Insights** from the main Cloud SIEM screen. - 1. Select an Insight. + 1. Select an insight. 1. Click the Actions button. 1. Under **Insight Automation**, select the automation you created in the previous step (it will have the same name as the playbook). The playbook runs. - 1. To see the results of the run, click the **Automations** tab at the top of the Insight. + 1. To see the results of the run, click the **Automations** tab at the top of the insight. 1. View the **Status** field to find out if the playbook has a status of Success or another status such as **Completed with errors**. 1. Click **View Playbook** to see details of the playbook run. Each node in the playbook will show either **Success** or **Failed**. 1. Click a node to download results of that node’s run. @@ -125,7 +125,7 @@ The following example shows how to configure a notification that sends an email 1. For **Action** select **Send Email**. 1. In **Recipients** enter your email address and press Enter. 1. For **Subject** type a subject line for the email (for example, "Results of Sumo Logic log search"). - 1. In **Plain text content** enter the text you want to appear in the body of the email. For example, enter "Search in Sumo Logic was executed. Click the Automations tab at the top of the Insight for which the 'Notification for a log search' automation was run. Click 'View Playbook' to see the results." + 1. In **Plain text content** enter the text you want to appear in the body of the email. For example, enter "Search in Sumo Logic was executed. Click the Automations tab at the top of the insight for which the 'Notification for a log search' automation was run. Click 'View Playbook' to see the results." 1. Copy the plain text content into **HTML content** and add formatting if desired. 1. Click **Create**.
Add Send Email node 1. Click and hold on the right semicircle of the new **Send Email** node and drag to the semicircle of the **END** node and release. The playbook is complete. @@ -142,10 +142,10 @@ The following example shows how to configure a notification that sends an email 1. Click **Save**. 1. Run the automation: 1. Select **Insights** from the main Cloud SIEM screen. - 1. Select an Insight. + 1. Select an insight. 1. Click the **Actions** button. 1. Under **Insight Automation**, select the automation you created in the previous step (it will have the same name as the playbook). The playbook runs. - 1. To see the results of the run, click the **Automations** tab at the top of the Insight. + 1. To see the results of the run, click the **Automations** tab at the top of the insight. 1. View the **Status** field to find out if the playbook has a status of **Success** or another status such as **Completed with errors**. 1. Click **View Playbook** to see details of the playbook run. Each node in the playbook will show either **Success** or **Failed**. 1. Click a node to download results of that node’s run. @@ -155,7 +155,7 @@ The following example shows how to configure a notification that sends an email The following example shows how to create a custom integration with an action that runs a script you provide. The custom integration and action are defined by YAML files. To learn how to build your own YAML files, see [Integration framework file formats](/docs/platform-services/automation-service/automation-service-integration-framework/#integration-framework-file-formats). -The action uses [IP Quality Score](https://www.ipqualityscore.com/) to gather IP reputation information for enrichment. (This example shows how to add enrichment to an Insight. To use the same action to add enrichment to Entities, see [Add Entity enrichment](#add-entity-enrichment) below.) +The action uses [IP Quality Score](https://www.ipqualityscore.com/) to gather IP reputation information for enrichment. (This example shows how to add enrichment to an insight. To use the same action to add enrichment to entities, see [Add entity enrichment](#add-entity-enrichment) below.) 1. [Install the Automation Service Bridge](/docs/platform-services/automation-service/automation-service-bridge/). Because this example uses a custom integration, you must first install the Bridge before you proceed. 1. Obtain an API key from IP Quality Score: @@ -196,7 +196,7 @@ The action uses [IP Quality Score](https://www.ipqualityscore.com/) to gather IP 1. Select the input parameters for the playbook: 1. Click the **Edit** button (pencil icon) at the bottom of the playbook view. 1. On the **Start** node, click the **Edit** button (pencil icon). - 1. In the **Edit node** dialog, select **Insight** in the **Add one or more params as a playbook input** field. (If you want to create a playbook to add Entity enrichment instead, see [Add Entity enrichment](#add-entity-enrichment) below.) + 1. In the **Edit node** dialog, select **Insight** in the **Add one or more params as a playbook input** field. (If you want to create a playbook to add entity enrichment instead, see [Add entity enrichment](#add-entity-enrichment) below.) 1. Click **Update**. 1. Add a condition to validate IP addresses: 1. Click the **Add Node** button (**+** icon) on the **START** node. @@ -236,7 +236,7 @@ The action uses [IP Quality Score](https://www.ipqualityscore.com/) to gather IP 1. Save the playbook: 1. Click the **Save** button (floppy disk icon) at the bottom of the playbook view. 1. To [test the playbook](/docs/platform-services/automation-service/automation-service-playbooks/#test-a-playbook), click the kebab button in the upper-right of the UI and select **Run Test**. - 1. Click the **Publish** button (clipboard icon) at the bottom of the playbook view. The playbook should look like this:
Custom playbook for Insight enrichment + 1. Click the **Publish** button (clipboard icon) at the bottom of the playbook view. The playbook should look like this:
Custom playbook for insight enrichment 1. Create an automation in Cloud SIEM to run the playbook: 1. [**Classic UI**](/docs/get-started/sumo-logic-ui-classic). In the main Sumo Logic menu select **Cloud SIEM**. In the top menu select **Configuration**, and then under **Integrations** select **Automation**.
[**New UI**](/docs/get-started/sumo-logic-ui). In the top menu select **Configuration**, and then under **Cloud SIEM Integrations** select **Automation**. 1. At the top of the **Automation** tab, click **+ Add Automation**. @@ -249,22 +249,22 @@ The action uses [IP Quality Score](https://www.ipqualityscore.com/) to gather IP 1. Select an **Insight**. 1. Click the **Actions** button. 1. Under **Insight Automation**, select the automation you created in the previous step (it will have the same name as the playbook). The playbook runs. - 1. To see the results of the run, click the **Automations** tab at the top of the Insight. + 1. To see the results of the run, click the **Automations** tab at the top of the insight. 1. View the **Status** field to find out if the playbook has a status of **Success** or another status such as **Completed with errors**. 1. Click **View Playbook** to see details of the playbook run. Each node in the playbook will show either **Success** or **Failed**. 1. Click a node to download results of that node’s run. - 1. Go back to the Insight and click the **Enrichments** tab to view the enrichments added by the automation. + 1. Go back to the insight and click the **Enrichments** tab to view the enrichments added by the automation. -### Add Entity enrichment +### Add entity enrichment -The preceding example shows how to use a custom integration to add enrichment to an Insight. To add enrichment to Entities instead, use the same steps but with the following changes: +The preceding example shows how to use a custom integration to add enrichment to an insight. To add enrichment to entities instead, use the same steps but with the following changes: 1. When you select the input parameters for the playbook, in the **Edit node** dialog, select **Entity** instead of **Insight** in the **Add one or more params as a playbook input** field. 1. When you add a condition to validate IP addresses, for [**Playbook inputs**](#playbook-inputs) select **input.entityType** instead of **input.entity.entityType**. 1. When you add the “IP Reputation” action to the playbook, for [**Playbook inputs**](#playbook-inputs) select **input.value** instead of **input.entity.value**. 1. Instead of adding the “Add Insight Enrichment” action to the playbook, add the “Add Entity Enrichment” action. -The resulting playbook should look like this:
Custom playbook for Entity enrichment +The resulting playbook should look like this:
Custom playbook for entity enrichment ## Advanced example: Build a complex playbook @@ -318,7 +318,7 @@ The following example pulls together elements of the [Simple example](#simple-ex 1. In the **Enrichment name** field type **VirusTotal IP reputation**. 1. To the right of the **Raw JSON** field click the gear icon. 1. Click **IP reputation V3** and select **output.raw**. - 1. Click **Create**.
Add node for Insight enrichment + 1. Click **Create**.
Add node for insight enrichment 1. Click and hold on the right semicircle of the new **Add Insight Enrichment** node and drag to the semicircle of the **END** node and release. 1. Add a condition to validate IP addresses: 1. Click the **Add Node** button (**+** icon) on the **Add Insight Enrichment** node. @@ -368,10 +368,10 @@ The following example pulls together elements of the [Simple example](#simple-ex 1. Click **Save**. 1. Run the automation: 1. Select **Insights** from the main Cloud SIEM screen. - 1. Select an Insight. + 1. Select an insight. 1. Click the Actions button. 1. Under **Insight Automation**, select the automation you created in the previous step (it will have the same name as the playbook). The playbook runs. - 1. To see the results of the run, click the **Automations** tab at the top of the Insight. + 1. To see the results of the run, click the **Automations** tab at the top of the insight. 1. View the **Status** field to find out if the playbook has a status of Success or another status such as **Completed with errors**. 1. Click **View Playbook** to see details of the playbook run. Each node in the playbook will show either **Success** or **Failed**. 1. Click a node to download results of that node’s run. diff --git a/docs/cse/automation/index.md b/docs/cse/automation/index.md index d3412f99f0..5a3e9fbc85 100644 --- a/docs/cse/automation/index.md +++ b/docs/cse/automation/index.md @@ -8,7 +8,7 @@ keywords: import useBaseUrl from '@docusaurus/useBaseUrl'; -This guide describes how you can use the [Automation Service](/docs/platform-services/automation-service/) to configure automations in Cloud SIEM to add enrichments and create notifications for Insights and Entities. +This guide describes how you can use the [Automation Service](/docs/platform-services/automation-service/) to configure automations in Cloud SIEM to add enrichments and create notifications for insights and entities. In this section, we'll introduce the following concepts: @@ -22,7 +22,7 @@ In this section, we'll introduce the following concepts:
Shield on a workflow icon

Automations in Cloud SIEM

 -

Learn how to create automations that run playbooks to add enrichments and create notifications for either Insights or Entities.

+

Learn how to create automations that run playbooks to add enrichments and create notifications for either insights or entities.

From 3ef1d15debba5f4e3c5e68050845e2391581b439 Mon Sep 17 00:00:00 2001 From: John Pipkin Date: Wed, 18 Dec 2024 17:17:58 -0600 Subject: [PATCH 6/6] Make terms lowercase in 'Administration' section --- .../create-a-custom-tag-schema.md | 4 +- docs/cse/administration/create-cse-actions.md | 128 +++++++++--------- .../create-cse-context-actions.md | 61 ++++----- .../create-custom-threat-intel-source.md | 10 +- .../create-use-network-blocks.md | 75 ++++------ docs/cse/administration/cse-apis.md | 2 +- docs/cse/administration/cse-audit-logging.md | 62 ++++----- docs/cse/administration/cse-data-retention.md | 10 +- .../cse-user-accounts-and-roles.md | 6 +- .../custom-inventory-sources.md | 6 +- docs/cse/administration/index.md | 10 +- .../inventory-sources-and-data.md | 10 +- .../manage-custom-insight-resolutions.md | 28 ++-- .../manage-custom-insight-statuses.md | 30 ++-- docs/cse/administration/mitre-coverage.md | 22 +-- .../save-inventory-data-lookup-table.md | 36 ++--- docs/cse/administration/using-sensor-zones.md | 20 +-- 17 files changed, 250 insertions(+), 270 deletions(-) diff --git a/docs/cse/administration/create-a-custom-tag-schema.md b/docs/cse/administration/create-a-custom-tag-schema.md index 2fa1c48f19..de5b7db6a0 100644 --- a/docs/cse/administration/create-a-custom-tag-schema.md +++ b/docs/cse/administration/create-a-custom-tag-schema.md @@ -11,7 +11,7 @@ This topic has instructions for creating a custom tag schema in Cloud SIEM.  ## About tags in Cloud SIEM -Tags are metadata you can attach to Insights, Signals, Entities, and Rules. Tags are useful for adding context to these Cloud SIEM items. You can also search for and filter items by tag. There are two types of tags: *keyword tags*, which are arbitrary, freeform strings; and *schema keys*, which are predefined key-value pairs. Cloud SIEM provides built-in schemas keys that display in the Cloud SIEM UI with a Sumo label, as shown in the example below. You can’t edit the built-in schemas. +Tags are metadata you can attach to insights, signals, entities, and rules. Tags are useful for adding context to these Cloud SIEM items. You can also search for and filter items by tag. There are two types of tags: *keyword tags*, which are arbitrary, freeform strings; and *schema keys*, which are predefined key-value pairs. Cloud SIEM provides built-in schemas keys that display in the Cloud SIEM UI with a Sumo Logic label, as shown in the example below. You can’t edit the built-in schemas. Built-in schema keys @@ -30,7 +30,7 @@ For more information about tags in Cloud SIEM, see [Using Tags with Insights, Si available for. You can select one or more of the following: * **Custom Insight** * **Rule** - * **Entity** The options do not include **Signal** or **Insight**. Signals and Insights inherit tag values from the rule(s) or Custom Insight definition that triggered the Signal or Insight and involved Entities. + * **Entity** The options do not include **Signal** or **Insight**. Signals and insights inherit tag values from the rule(s) or custom insight definition that triggered the signal or insight and involved entities. 1. **Allow Custom Values**. Check this box to allow users to add additional allowable values to the tag schema. Otherwise, when applying the tag users may only select one of the values you define in the **Value Options** section below. 1. If **Allow Custom Values** is not checked, you must define at least one value for the tag: * **Enter Value**. Enter an allowable value for the tag. diff --git a/docs/cse/administration/create-cse-actions.md b/docs/cse/administration/create-cse-actions.md index 77db22c827..fc2725b868 100644 --- a/docs/cse/administration/create-cse-actions.md +++ b/docs/cse/administration/create-cse-actions.md @@ -2,20 +2,20 @@ id: create-cse-actions title: Create Cloud SIEM Actions sidebar_label: Create Cloud SIEM Actions -description: You can use Cloud SIEM Actions to issue notifications to another service when certain events occur in Cloud SIEM. +description: You can use Cloud SIEM actions to issue notifications to another service when certain events occur in Cloud SIEM. --- import useBaseUrl from '@docusaurus/useBaseUrl'; -This topic has instructions for configuring Cloud SIEM Actions. +This topic has instructions for configuring Cloud SIEM actions. :::warning -In the future, Cloud SIEM Actions will be deprecated because comparable behavior is available in the Automation Service. Although Cloud SIEM Actions are still supported, we recommend you use the Automation Service to perform actions. For more information, see [Migrate from legacy actions and enrichments to the Automation Service](/docs/cse/automation/automations-in-cloud-siem/#migrate-from-legacy-actions-and-enrichments-to-the-automation-service). +In the future, Cloud SIEM actions will be deprecated because comparable behavior is available in the Automation Service. Although Cloud SIEM actions are still supported, we recommend you use the Automation Service to perform actions. For more information, see [Migrate from legacy actions and enrichments to the Automation Service](/docs/cse/automation/automations-in-cloud-siem/#migrate-from-legacy-actions-and-enrichments-to-the-automation-service). ::: -## About Cloud SIEM Actions +## About Cloud SIEM actions -You can use Cloud SIEM Actions to issue a notification to another service when certain events occur in Cloud SIEM. The supported Action types are: +You can use Cloud SIEM actions to issue a notification to another service when certain events occur in Cloud SIEM. The supported action types are: * AWS Simple Notification Service (SNS) * Demisto (Cortex XSOAR) @@ -25,11 +25,11 @@ You can use Cloud SIEM Actions to issue a notification to another service when c * PagerDuty * Recorded Future * Slack -* Slack Webhook +* Slack webhook -An Action can be configured for Insight-related activity as described below in [Insight Actions](#insight-actions). You can also configure an Action to be run when a rule is automatically disabled, as described below in [Rule Actions](#rule-actions). +An action can be configured for insight-related activity as described below in [Insight actions](#insight-actions). You can also configure an action to be run when a rule is automatically disabled, as described below in [Rule actions](#rule-actions). -Watch this micro lesson to learn how to configure an Action. +Watch this micro lesson to learn how to configure an action.