Merge branch 'main' into DOCS-780

Author: kimsauce

blog-service/2024/12-31.md

@@ -425,10 +425,6 @@ We're excited to announce that when you create a role, you can select **Index Ac
 
 This feature was [previously only available to participants in our beta program](/release-notes-service/2023/12/31/#october-27-2023-manage-account). It is now available for general use.
 
-:::note
-These changes are rolling out across deployments incrementally and will be available on all deployments by March 14, 2025.
-:::
-
 [Learn more](/docs/manage/users-roles/roles/create-manage-roles/#create-a-role).
 
 ### October 14, 2024 (Collection)

cid-redirects.json

@@ -2674,6 +2674,7 @@
   "/cid/20158": "/docs/integrations/amazon-aws/aws-ground-station",
   "/cid/20159": "/docs/integrations/amazon-aws/aws-healthlake",
   "/cid/20160": "/docs/integrations/amazon-aws/amazon-bedrock",
+  "/cid/20161": "/docs/integrations/microsoft-azure/azure-virtual-machine",
   "/cid/8394": "/docs/search/search-query-language/search-operators/dedup",
   "/cid/85858": "/docs/observability/kubernetes/quickstart",
   "/cid/8595": "/docs/manage/security/set-password-policy",

docs/alerts/scheduled-searches/generate-cse-signals.md

@@ -15,6 +15,8 @@ For a more detailed description of the options you can configure for a scheduled
 
 ## Requirements for the search query
 
+When you [create a scheduled search](/docs/alerts/scheduled-searches/schedule-search/) to generate signals in Cloud SIEM, you start by creating a search query.
+
 This section describes the requirements for your scheduled search, which include a minimum set of fields to be returned, and renaming message fields as necessary to match attribute names in the selected Cloud SIEM record type schema.  
 
 ### Required fields
@@ -42,7 +44,6 @@ enable signal generation:
     If the `stage` field contains a Tactic that isn't in the MITRE ATT&CK framework, a signal will not be generated, but a record will be. 
     :::
 * At least one entity field:
-
   * `device_ip`
   * `device_mac`
   * `device_natIp`
@@ -56,16 +57,35 @@ enable signal generation:
   * `srcDevice_ip`
   * `srcDevice_mac`
   * `srcDevice_natIp`
-  * `user_username`        
+  * `user_username`
 
 ### Renaming message fields
 
 When you configure a Scheduled Search to create Cloud SIEM signals, you are prompted to select a [Cloud SIEM record type](/docs/cse/schema/cse-record-types/). The fields returned by your search must match an attribute in the record type you select. A field whose name does not match a Cloud SIEM attribute will not be populated in the record created from the Schedule Search results. For more about Cloud SIEM attribute names, see [Attributes You Can Map to Records](/docs/cse/schema/attributes-map-to-records/).
 
+### Example
+
+Let's suppose that `user_username` is the entity field we want to use, and its value needs to be mapped to `actor.email`. Then you need to add the following line to the query: `actor.email as user_username`.
+
+And because the final output of this query is an aggregate, and Cloud SIEM signals expect `normalizedfield`, `stage`, and `entity`, we need need to add those in the `count` expression. 
+
+This is how the final query might look:
+
+```txt
+((_index=sec_record_* objectType=*)
+AND _sourcename = "Google Apps Audit Event")
+AND _sourcecategory = "GoogleWorkspace/Groups"
+| 5 as normalizedseverity
+| "Initial Access" as stage
+| json auto 
+| actor.email as user_username
+| count by events.name, events.type, actor.email, event.parameters.user_email, event.parameters.group_email, user_username, stage, normalizedseverity
+```
+
 ## Scheduling the search
 
 1. After creating and saving your search, click the save icon.<br/><img src={useBaseUrl('img/alerts/save-as.png')} alt="Save the search" style={{border: '1px solid gray'}} width="800"/>
-1. The **Save Item** popup appears.<br/><img src={useBaseUrl('img/alerts/save-item.png')} alt="Save as scheduled search" width="500"/>
+1. The **Save Item** popup appears.<br/><img src={useBaseUrl('img/alerts/save-item.png')} alt="Save as scheduled search" style={{border: '1px solid gray'}} width="500"/>
    :::note
    The name of your scheduled search will appear as the signal name in Cloud SIEM.
    :::

docs/contributing/remove-doc.md

@@ -1,12 +1,12 @@
 ---
 id: remove-doc
-title: Remove a Doc
-description: Learn how to properly remove a Sumo Logic doc.
+title: Move or Remove a Doc
+description: Learn how to properly move or remove a Sumo Logic doc.
 ---
 
 import useBaseUrl from '@docusaurus/useBaseUrl';
 
-When you delete a doc, its URL is also deleted. Visiting the old URL will return a `404 - Page Not Found` error, which negatively impacts customer experience and can damage our SEO.
+When you move a doc or remove it altogether, that deletes its URL. Visiting the old URL will return a `404 - Page Not Found` error, which negatively impacts customer experience and can damage our SEO.
 
 To prevent this, create a 301 redirect. Follow these steps to ensure a smooth transition and maintain the health of our docs site.
 
@@ -31,11 +31,12 @@ As an example, let's say there are two docs called **Nginx App** and **Nginx (Le
 Ensure any internal links pointing to the deleted doc are updated to the new URL.
 
 1. In your GitHub authoring tool, run a search for the URL you're removing. For example, if the legacy URL appears in other documents, replace all instances with the new URL.<br/><img src={useBaseUrl('img/contributing/old-url.png')} alt="Screenshot of a 'Find All' search for the URL to be removed" />
-1. Check with a Sumo Logic subject matter expert to confirm that you can replace all with the new URL.
-
-:::warning
-Never do a "Find All > Replace All", as this can break unrelated items like image paths. Replace each URL on a one-by-one basis.
-:::
+   :::warning
+   Never do a Find All > Replace All, as this can break unrelated items like image paths. Replace each URL on a one-by-one basis.
+   :::
+1. If applicable:
+   * Remove from its parent index.md hub page.
+   * Remove from [Product List](/docs/integrations/product-list/).
 
 ## Step 3: Delete the doc file
 

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

@@ -626,7 +626,7 @@ The following expression returns "10.10.1.0":
 
 ### hasThreatMatch
 
-The `hasThreatMatch` Cloud SIEM rules function matches incoming records in Cloud SIEM to [threat intelligence indicators](/docs/security/threat-intelligence/threat-indicators-in-cloud-siem/#hasthreatmatch-cloud-siem-rules-language-function). It can also match values in [custom threat intelligence sources in Cloud SIEM](/docs/cse/administration/create-custom-threat-intel-source/).
+Use the `hasThreatMatch` Cloud SIEM rules function to match incoming records in Cloud SIEM to [threat intelligence sources](/docs/security/threat-intelligence/about-threat-intelligence/). The function uses all sources in the **Threat Intelligence** tab, unless you specify a specific source. `hasThreatMatch` can also match values in [custom threat intelligence sources in Cloud SIEM](/docs/cse/administration/create-custom-threat-intel-source/).
 
 When an entity is processed by a rule using the `hasThreatMatch` function and is a match, the entity is associated with a known indicator that has a threat type attribute. The entity can be associated with either `threatType` (in normalized JSON format and CSV format), or `indicator_types` (in STIX format).
 
@@ -635,46 +635,31 @@ When an entity is processed by a rule using the `hasThreatMatch` function and is
 `hasThreatMatch([<fields>], <filters>, <indicators>)`
 
 Parameters:
-* `<fields>` is a list of comma-separated [field names](https://github.com/SumoLogic/cloud-siem-content-catalog/blob/master/schema/full_schema.md). At least one field name is required.
-* `<filters>` is a logical expression using [indicator attributes](/docs/security/threat-intelligence/upload-formats/#normalized-json-format). Allowed in the filtering are parentheses `()`; `OR` and `AND` boolean operators; and comparison operators `=`, `<`, `>`, `=<`, `=>`, `!=`. <br/>You can filter on the following indicator attributes:
-   * `actors`
-   * `confidence`
-   * `id`
-   * `indicator`
-   * `killChain`
-   * `source`
-   * `threatType`
-   * `type`
-   * `validFrom`
-   * `validUntil`
-* `<indicators>` is an optional case insensitive option that describes how indicators should be matched with regard to their validity. Accepted values are:
+* **`<fields>`**. A list of comma-separated [field names](https://github.com/SumoLogic/cloud-siem-content-catalog/blob/master/schema/full_schema.md). At least one field name is required.
+* **`<filters>`**. A logical expression using [indicator attributes](/docs/security/threat-intelligence/upload-formats/#normalized-json-format). Allowed in the filtering are parentheses `()`; `OR` and `AND` boolean operators; and comparison operators `=`, `<`, `>`, `=<`, `=>`, `!=`. <br/>You can filter on the following indicator attributes:
+   * `actors`. An identified threat actor such as an individual, organization, or group. 
+   * `confidence` Confidence that the data represents a valid threat, where 100 is highest.  Malicious confidence scores from different sources are normalized and mapped to a 0-100 numerical value.
+   * `id`. ID of the indicator.
+   * `indicator`. Value of the indicator, such as an IP address, file name, email address, etc. 
+   * `killChain`. The various phases an attacker may undertake to achieve their objectives (for example, `reconnaissance`, `weaponization`, `delivery`, `exploitation`, `installation`, `command-and-control`, `actions-on-objectives`).
+   * `source`. The source in the Sumo Logic datastore displayed in the **Threat Intelligence** tab.
+   * `threatType`. The threat type of the indicator (for example, `anomalous-activity`, `anonymization`, `benign`, `compromised`, `malicious-activity`, `attribution`, `unknown`).
+   * `type`. The indicator type (for example, `ipv4-addr`, `domain-name`, `'file:hashes`, etc.)
+   * `validFrom`. Beginning time this indicator is valid.
+   * `validUntil`. Ending time this indicator is valid. 
+* **`<indicators>`**. An optional case insensitive option that describes how indicators should be matched with regard to their validity. Accepted values are:
    * `active_indicators`. Match active indicators only (default).
    * `expired_indicators`. Match expired indicators only.
    * `all_indicators`. Match all indicators.
 
-**Examples**
-
-* `hasThreatMatch([srcDevice_ip])`
-* `hasThreatMatch([srcDevice_ip, dstDevice_ip])`
-* `hasThreatMatch([srcDevice_ip], type="ipv4-addr")`
-* `hasThreatMatch([srcDevice_ip], confidence > 50)`
-* `hasThreatMatch([srcDevice_ip], confidence > 50 AND source="TAXII2Source")`
-* `hasThreatMatch([srcDevice_ip], source="s1" OR (source="s2" confidence > 50))`
-* `hasThreatMatch([srcDevice_ip], expired_indicators)`
-* `hasThreatMatch([srcDevice_ip], confidence > 50, all_indicators)`
-
 #### Best practice
 
 As a best practice, always include filtering to narrow your match to just the types desired (that is, `type=`). This will ensure that your match expressions are not overly broad.
 
-For example:
-* `hasThreatMatch([dstDevice_ip], confidence > 1 AND (type="ipv4-addr" OR type="ipv6-addr"))` 
-* `hasThreatMatch([file_hash_imphash, file_hash_md5, file_hash_pehash, file_hash_ssdeep, file_hash_sha1, file_hash_sha256], confidence > 1 AND type="file:hashes")` 
-* `hasThreatMatch([http_url], confidence > 1 AND type="url")` 
-* `hasThreatMatch([dstDevice_ip, srcDevice_ip], (confidence >1 AND confidence <50) AND (type='ipv4-addr' OR type='ipv6-addr'))`
-
 Following are the standard indicator types you can filter on:
-* `file:hashes`. File hash. (If you want to add the hash algorithm, enter `file:hashes.<HASH-TYPE>`. For example, `[file:hashes.MD5 = '5d41402abc4b2a76b9719d911017c592']` or `[file:hashes.'SHA-256' = '50d858e0985ecc7f60418aaf0cc5ab587f42c2570a884095a9e8ccacd0f6545c']`.)
+* `domain-name`. Domain.
+* `email-addr`. Email.
+* `file:hashes`. File hash.
 * `file`. File name. 
 * `ipv4-addr`. IPv4 IP address. 
 * `ipv6-addr`. IPv6 IP address. 
@@ -685,6 +670,28 @@ Following are the standard indicator types you can filter on:
 
 For more information about indicator types, see [Upload Formats for Threat Intelligence Indicators](/docs/security/threat-intelligence/upload-formats).
 
+**Examples**
+
+:::tip
+For standard rules that use the `hasThreatMatch` function, refer to the [Rules page in the Cloud SIEM Content Catalog](https://github.com/SumoLogic/cloud-siem-content-catalog/blob/master/rules/README.md) and search for rules with "Threat Intel" in the name. To see examples of how these rules use `hasThreatMatch`, open and view the rules in Cloud SIEM.
+:::
+
+* `hasThreatMatch([srcDevice_ip], confidence > 1 AND (type='ipv4-addr' OR type='ipv6-addr'))`
+* `hasThreatMatch([device_ip], source="unit_42" AND confidence > 50) AND accountId="testing"`
+* `hasThreatMatch([device_hostname], confidence > 1 AND (type='domain-name' OR type='url'))`
+* `hasThreatMatch([dstDevice_hostname], confidence > 1 AND (type='domain-name' OR type='url'))`
+* `hasThreatMatch([file_hash_md5], confidence > 1 AND type='file:hashes.MD5')`
+* `hasThreatMatch([file_hash_sha1], confidence > 1 AND type="file:hashes.'SHA-1'")`
+* `hasThreatMatch([file_hash_sha256], confidence > 1 AND type="file:hashes.'SHA-256'")`
+* `hasThreatMatch([file_hash_ssdeep], confidence > 1 AND type='file:hashes.ssdeep')`
+* `hasThreatMatch([http_url_rootDomain], confidence > 1 AND (type='domain-name' OR type='url'))`
+* `hasThreatMatch([user_email,targetUser_email], confidence > 1 AND source = "s_global_feed_1")`
+
+You can exclude matches from allowlists such as [standard match lists](/docs/cse/match-lists-suppressed-lists/standard-match-lists/#standard-match-lists). For example:
+```text
+hasThreatMatch([dstDevice_ip], confidence > 74 AND (type='ipv4-addr' OR type='ipv6-addr')) AND NOT (array_contains(listMatches, 'business_asns') OR array_contains(listMatches, 'business_domains') OR array_contains(listMatches, 'business_hostnames') OR array_contains(listMatches, 'business_ips') OR array_contains(listMatches, 'sandbox_ips') OR array_contains(listMatches, 'verified_domains') OR array_contains(listMatches, 'verified_hostnames') OR array_contains(listMatches, 'verified_ips'))
+```
+
 ### haversine
 
 Returns the distance between latitude and longitude values of two coordinates in kilometers.

docs/cse/sensors/network-sensor-end-of-life.md

@@ -24,5 +24,5 @@ If you have any questions, please don't hesitate to reach out to your Sumo Logic
 | :-- | :-- | :-- |
 | End-of-life announcement | The date this feature is announced as end-of-life. | November 8, 2024 |
 | End of software release | The last date that Sumo Logic may release any final software maintenance releases or bug fixes. After this date, Sumo Logic will no longer develop, repair, maintain, or test product software. | November 8, 2024 |
-| Last date of support | The last date to receive applicable support for the feature as entitled by active support contracts or by applicable warrant terms and conditIons. After this date, all support services for this feature are unavailable and the feature becomes obsolete. | April 30, 2025 |
+| Last date of support | The last date to receive applicable support for the feature as entitled by active support contracts or by applicable warrant terms and conditIons. After this date, all support services for this feature are unavailable and the feature becomes obsolete. | TBD |
 

docs/integrations/amazon-aws/amazon-ec2-auto-scaling.md

@@ -121,7 +121,7 @@ When you create an AWS Source, you'll need to identify the Hosted Collector you
       * ![green check circle.png](/img/reuse/green-check-circle.png) A green circle with a check mark is shown when the field exists and is enabled in the Fields table schema.
       * ![orange exclamation point.png](/img/reuse/orange-exclamation-point.png) An orange triangle with an exclamation point is shown when the field doesn't exist, or is disabled, in the Fields table schema. In this case, an option to automatically add or enable the nonexistent fields to the Fields table schema is provided. If a field is sent to Sumo Logic that does not exist in the Fields schema or is disabled it is ignored, known as dropped.
 :::note
-Namespace for Amazon EC2 Auto-scaling Service is AWS/AutoScaling.
+Namespace for Amazon EC2 Auto Scaling Service is AWS/AutoScaling.
 :::
 
 ## Field in field schema
@@ -132,7 +132,7 @@ Namespace for Amazon EC2 Auto-scaling Service is AWS/AutoScaling.
 
 ## Field Extraction Rule(s)
 
-Create a Field Extraction Rule (FER) for Amazon EC2 Auto-scaling access logs and Cloudtrail logs. Learn how to create a Field Extraction Rule [here](/docs/manage/field-extractions/create-field-extraction-rule).
+Create a Field Extraction Rule (FER) for Amazon EC2 Auto Scaling access logs and Cloudtrail logs. Learn how to create a Field Extraction Rule [here](/docs/manage/field-extractions/create-field-extraction-rule).
 
 **Amazon EC2 Auto Scaling CloudTrail logs**
 
@@ -177,8 +177,8 @@ The **Amazon EC2 Auto Scaling - CloudTrail Audit** dashboard provides a comprehe
 
 Use this dashboard for:
 * Monitoring the overall health and performance of your Amazon EC2 Auto Scaling groups
-* Identifying and troubleshooting common errors and failures in auto-scaling operations
-* Tracking user activities and potential security concerns related to auto-scaling events
+* Identifying and troubleshooting common errors and failures in auto scaling operations
+* Tracking user activities and potential security concerns related to auto scaling events
 * Analyzing trends in event types, success rates, and failure patterns over time
 
 <img src={useBaseUrl('img/integrations/02.-Amazon-EC2-Auto-Scaling-CloudTrail-Audit.png')} alt="Amazon EC2 Auto Scaling dashboard" style={{border: '1px solid gray'}} width="800"/>

docs/integrations/microsoft-azure/azure-key-vault.md

@@ -25,7 +25,6 @@ For more information on supported metrics and their units, refer to the [Azure d
 Azure service sends monitoring data to Azure Monitor, which can then [stream data to Eventhub](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/stream-monitoring-data-event-hubs). Sumo Logic supports:
 
 * Logs collection from [Azure Monitor](https://docs.microsoft.com/en-us/azure/monitoring-and-diagnostics/monitoring-get-started) using our [Azure Event Hubs source](/docs/send-data/collect-from-other-data-sources/azure-monitoring/ms-azure-event-hubs-source/).
-* Metrics collection using our [HTTP Logs and Metrics source](/docs/send-data/collect-from-other-data-sources/azure-monitoring/collect-metrics-azure-monitor/) via Azure Functions deployed using the ARM template.
 
 You must explicitly enable diagnostic settings for each Key Vault you want to monitor. You can forward logs to the same event hub provided they satisfy the limitations and permissions as described [here](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/diagnostic-settings?tabs=portal#destination-limitations).