DOCS-448 - Cloud SIEM normalization

docs/cse/administration/save-inventory-data-lookup-table.md

@@ -18,7 +18,7 @@ Although the Scheduled Search feature does support an **Alert Type** of “Save
 
 ## Prerequisites 
 
-In order to create an inventory Lookup Table you need to have one or more sources of inventory data. One of the most common sources of inventory data in Sumo Logic is the Windows Active Directory Inventory source running on an Installed Collector. We recommend you collect AD logs every 12 hours, and that you do not collect logs more frequently than every 8 hours.
+In order to create an inventory Lookup Table you need to have one or more sources of inventory data. One of the most common sources of inventory data in Sumo Logic is the [Windows Active Directory Inventory source](/docs/send-data/installed-collectors/sources/windows-active-directory-inventory-source/) running on an Installed Collector. We recommend you collect AD logs every 12 hours, and that you do not collect logs more frequently than every 8 hours.
 
 Any inventory source–or any log source, for that matter–can be used to populate Lookup Tables. Sumo Logic also has a variety of inventory sources that run on Hosted Collectors, including the Okta and Carbon Black sources.
 

docs/cse/records-signals-entities-insights/configure-entity-lookup-table.md

@@ -65,7 +65,7 @@ After you’ve created your Entity Lookup Table in the Sumo Logic Library, you c
 1. [**Classic UI**](/docs/cse/introduction-to-cloud-siem/#classic-ui). In the top menu select **Configuration**, and then under **Entities** select **Normalization**. <br/>[**New UI**](/docs/cse/introduction-to-cloud-siem/#new-ui). In the top menu select **Configuration**, and then under **Cloud SIEM Entities** select **Normalization**. You can also click the **Go To...** menu at the top of the screen and select **Normalization**.  
 1. On the **Entity Normalization** page, click **Lookup Tables**.
 1. Click **Create** on the **Lookup Tables** tab.
-1. The **Existing Lookup Table** popup appears.<br/><img src={useBaseUrl('img/cse/existing-lookup-table.png')} alt="Existing Lookup Table dialog" style={{border: '1px solid gray'}} width="800"/>  
+1. The **Existing Lookup Table** popup appears.<br/><img src={useBaseUrl('img/cse/existing-lookup-table.png')} alt="Existing Lookup Table dialog" style={{border: '1px solid gray'}} width="600"/>  
 1. **Type**. Choose the type of normalization you want to set up.
    * **Host ID to Normalized Hostname**. Maps unique host IDs to recognizable hostnames.
    * **User ID to Normalized Username**. Maps unique user IDs to recognizable usernames.

docs/cse/schema/record-processing-pipeline.md

@@ -32,15 +32,15 @@ The key-value pairs are input to the next step of the process: mapping.
 
 ## Map message fields to schema attributes
 
-The mapping process 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.
 
 ## Normalize usernames and hostnames
 
-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 "[email protected]" and username-type field  "bob". We can use normalization to transform "[email protected]" to "bob", allowing the username and email to be correlated together.
 

docs/cse/schema/username-and-hostname-normalization.md

@@ -7,14 +7,18 @@ description: Learn about how Cloud SIEM normalizes usernames and hostnames durin
 
 import useBaseUrl from '@docusaurus/useBaseUrl';
 
-This topic describes how 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.
 
-## Details
+## Getting data into Cloud SIEM for normalization
 
-The name normalization process normalizes a complete username into a base username and a domain. The following forms of usernames are
-normalized.
+Data that is normalized comes into Cloud SIEM from several sources:
+* **Active Directory**. Configure the [Windows Active Directory Inventory Source](/docs/send-data/installed-collectors/sources/windows-active-directory-inventory-source/). The username, hostname, and domain information is pulled in directly from Active Directory to Cloud SIEM for normalization. For information on the computer and user data that is obtained, see the [Windows Active Directory Inventory Source](/docs/cse/administration/inventory-sources-and-data/#windows-active-directory-inventory-source) section in [Inventory Sources and Data](/docs/cse/administration/inventory-sources-and-data).
+* **AWS**. Configure AWS sources and ensure that the **Forward to SIEM** option is set to true. For more information, see [Cloud SIEM Ingestion Best Practices](/docs/cse/ingestion/cse-ingestion-best-practices/) and [Ingestion Sources for Cloud SIEM](/docs/cse/ingestion/ingestion-sources-for-cloud-siem/).
+* **Other sources**. See [Inventory Sources and Data](/docs/cse/administration/inventory-sources-and-data).
 
-Some of the common forms for username are:
+## Normalization process
+
+The name normalization process normalizes a complete username into a base username and a domain. Some of the common forms for username are:
 
 * `username` (no domain)
 * `AD-DOMAIN\username`
@@ -42,25 +46,37 @@ The following fields of the schema are normalized.
 
 When a username is normalized, the original, un-normalized name is placed in a `_raw` name attribute, for example,  `user_useraname_raw`. The normalized name is placed in the attribute field `user_username`. The rules engine allows the `_raw` username forms to be used in rule creation.
 
-It’s important to note, that if no name normalization configuration exists, the name attribute will consist of the original (non-normalized) form and the system will continue to operate as it does today, with the exception that that `_raw` attribute will also be populated. 
+If a name normalization configuration exists, the name attribute will be populated with the form `<username>:<friendly_domain>` where the `<friendly domain name>` portion is not populated for the normalized default domain.  When name normalization is enabled all name fields (not-raw) will be lowercase. For more information, see [Single domain example](#single-domain-example) and [Multiple domains example](#multiple-domains-example) below.
+
+:::note
+If no name normalization configuration exists, the name attribute will consist of the original (non-normalized) form and the system will continue to operate as it does today, with the exception that that `_raw` attribute will also be populated. 
+:::
 
-If a name normalization configuration exists, the name attribute will be populated with the form `<username>:<friendly_domain>` where the `<friendly domain name>` portion is not populated for the normalized default domain.  When name normalization is enabled all name fields (not-raw) will be lowercase. For more information, see [Example - single Domain](#example---single-domain) and [Example - multiple domains](#example---multiple-domains), below.
+## Configure entity normalization
 
-## Configuration
+1. [**Classic UI**](/docs/cse/introduction-to-cloud-siem/#classic-ui). In the top menu select **Configuration**, and then under **Entities** select **Normalization**. <br/>[**New UI**](/docs/cse/introduction-to-cloud-siem/#new-ui). In the top menu select **Configuration**, and then under **Cloud SIEM Entities** select **Normalization**. You can also click the **Go To...** menu at the top of the screen and select **Normalization**.
+1. Select the **Domain** tab. (For information about the **Lookup Tables** tab, see [Configure an Entity Lookup Table](/docs/cse/records-signals-entities-insights/configure-entity-lookup-table/)). 
+1. You can configure just **Username Normalization**, just **Hostname Normalization**, or both. We recommend you enable both. 
+1. Under **Normalization Formats** there are configuration options to normalize names from:
+   * **FQDN**. Normalize names in the form `[email protected]` or `hostname.somedomain.net`.
+   * **Active Directory**. Normalize active directory domains username and hostname formats.
+   * **AWS**. Normalize AWS ARN and usernames.
+1. In **Normalized Default Domain**, provide a default domain name. 
+1. In **Domain Name Mappings**, enter mappings for secondary domains.
+1. Click **Save**.
 
-The name normalization feature can be enabled in the **Incoming Data** section under the **Entities** tab of the Cloud SIEM configuration.  
+Following is an example configuration:
 
 <img src={useBaseUrl('img/cse/Configuration.png')} alt="Configuration dialog" style={{border: '1px solid gray'}} width="800"/>
 
-You can configure just username normalization, just hostname normalization, or both. We recommend you enable both. 
+### Warnings and issues
 
-There are configuration options to normalize names (“Normalization Formats”) from:
+If no name normalization is configured, the system will continue to operate as it does today.  If normalization is then enabled, any signals already created in the system will use the non-normalized form of the name.  Any new signals will use the normalized name.  This means there is potential for insights to be uncorrelated between the two different name forms for one insight window.  This is especially true as all usernames will now be lowercase.
 
-* FQDN - Normalize names in the form `[email protected]` or `hostname.somedomain.net`
-* Active Directory - Normalize active directory domains username and hostname formats
-* AWS - Normalize AWS ARN and Usernames
 
-## Default domains
+## Domain normalization
+
+### Default domains
 
 When normalization is configured, at least one domain must be configured and a “Normalized Default Domain” must be provided. The default name will never show up in normalized names, as it’s assumed, and username forms with no domain portion will be considered part of that domain. In our example above, we’ve assumed the name “sumo”.
 
@@ -73,7 +89,7 @@ Next, the user should enter the domain name forms that will be seen in the custo
 
 These domains should all have the “Normalized Name” that matches the “Normalized Default Domain”, for example, `sumo`.   
 
-## Secondary domains
+### Secondary domains
 
 The normalization configurations also supports secondary domains that may not map users in a different namespace to the same name. For example, if `[email protected]` is not the same as `[email protected]`, then a secondary domain should be configured.  In this case a second set of configurations should be populated to maps to a different “normalized domain” (`jask`). 
 
@@ -84,19 +100,9 @@ For example, in this case a configuration could be:
 
 In this case, these domains map to a different normalized domain (`jask`).  When one of these domains is normalized, it will show up as `bob:jask` in the normalized name form.
 
-## Warnings and issues
-
-If no name normalization is configured, the system will continue to operate as it does today.  If normalization is then enabled, any signals already created in the system will use the non-normalized form of the name.  Any new signals will use the normalized name.  This means there is potential for insights to be uncorrelated between the two different name forms for one insight window.  This is especially true as all usernames will now be lowercase. 
-
-## Example UI
-
-An example UI is provided for a case where the customer has a domain name `test.com` and an active directory domain named `test`. 
-
-<img src={useBaseUrl('img/cse/Example_UI.png')} alt="Configuration example" style={{border: '1px solid gray'}} width="600"/>
-
-### Example - single domain
+### Single domain example
 
-In this example, it is assumed the user has configured the system for “Primary domain” and has configured the domains `SUMO` and `sumologic.com`. In this case, assume a log line has a username field:
+In this example, it is assumed you have configured the system for “Primary domain” and you configured the domains `SUMO` and `sumologic.com`. In this case, assume a log line has a username field:
 
 `bob`
 
@@ -143,9 +149,9 @@ The normalized username would be:
 
 `user_username_raw = JASK\fred`
 
-#### Example - multiple domains
+### Multiple domains example
 
-In this example, it is assumed the user has configured the system for “Primary domain” and has also introduced a sub-domain (JASK). In this case, the configuration looks like:
+In this example, it is assumed you have configured the system for “Primary domain” and also introduced a sub-domain (JASK). In this case, the configuration looks like:
 
 Normalized Default Domain: sumo
 
@@ -166,4 +172,11 @@ Name forms matching the default domain would look like:
 | `[email protected]`         | `fred:jask`            |
 | `JASK\fred`             | `fred:jask`             |
 | `[email protected]` | `[email protected]` |
-| `OTHERDOMAIN\suzy`      | `otherdomain\suzy`     |
+| `OTHERDOMAIN\suzy`      | `otherdomain\suzy`     | 
+
+### Active Directory domain example
+
+Following is an example configuration for a case where the customer has a domain name `test.com` and an Active Directory domain named `test`. 
+
+<img src={useBaseUrl('img/cse/Example_UI.png')} alt="Configuration example" style={{border: '1px solid gray'}} width="600"/>
+