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.
The name normalization process normalizes a complete username into a base username and a domain. The following forms of usernames are normalized.
Some of the common forms for username are:
username@AD-DOMAIN.X(the AD domain format that’s more fully qualified)
Some of the common forms of hostname are:
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 Example - single Domain and Example - multiple domains, below.
The name normalization feature can be enabled in the Incoming Data section under the Entities tab of the Cloud SIEM configuration.
You can configure just username normalization, just hostname normalization, or both. We recommend you enable both.
There are configuration options to normalize names (“Normalization Formats”) from:
- FQDN - Normalize names in the form
- Active Directory - Normalize active directory domains username and hostname formats
- AWS - Normalize AWS ARN and Usernames
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”.
Next, the user should enter the domain name forms that will be seen in the customer's environment. This should include:
- The fully qualified domain name, for example,
- The active directory domain, for example,
- The active directory domain name with the
.LOCALextension, for example,
- Any other domains or sub-domains.
These domains should all have the “Normalized Name ” that matches the “Normalized Default Domain”, for example,
The normalization configurations also supports secondary domains that may not map users in a different namespace to the same name. For example, if
email@example.com is not the same as
firstname.lastname@example.org, 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” (
For example, in this case a configuration could be:
- The fully qualified secondary domain (
- Any secondary domains (
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.
An example UI is provided for a case where the customer has a domain name
test.com and an active directory domain named
Example - single domain
In this example, it is assumed the user has configured the system for “Primary domain” and has configured the domains
sumologic.com. In this case, assume a log line has a username field:
When that’s mapped and normalized, the normalized username is set in the username field:
user_username = bob
The raw name is populated in the un-normalized name field:
user_username_raw = bob
The same would logic would apply to a hostname:
device_hostname = desktop1
would be populated with the normalized name and the raw name would be populated:
device_hostname_raw would be = desktop1
Now if an AD logon event was identified with the username:
user_username_raw = SUMO\bob
In this case, the domain portion (SUMO) would be normalized and the name would be:
user_username = bob
The hostname example would be the same:
device_hostname_raw = SUMO\desktop1
would have a normalized name
device_hostname = desktop1
This would also hold true for the username
email@example.com and the hostname
firstname.lastname@example.org. In all of these cases, the usernames or hostnames would normalize to the same name respectively.
For any name not matching a configured domain name, the normalized name would just be set to the username, so in this example:
user_username = jask\fred
The normalized username would be:
user_username_raw = JASK\fred
Example - multiple domains
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:
Normalized Default Domain: sumo
Name forms matching the default domain would look like:
|Username String (raw)