Aliasing in Chronicle SIEM
Aliasing, Enrichment, Validation. All terms you may have heard of when using a SIEM solution, or specifically when using Chronicle SIEM, but what precisely do they mean?
Often these terms used interchangeably but they do have specific meaning and, hopefully, after this post you’ll be able to tell them apart, and a better understanding of the powerful Aliasing and Enrichment capabilities Chronicle SIEM provides.
Via a series of experiments and tests, providing examples of each, I shall cover what these core and fundamentals concepts are, and how they can impact your ability to successfully detect and respond when using Chronicle SecOps suite (both SIEM and SOAR).
First up, Aliasing.
Aliasing.
🐉 <dragons> The following analysis is recorded results from testing, and is not official guidance on how these elements work</dragons>
TL;DR
Aliasing
- Associating and linking together the different identities of an asset or user entity within a UDM event, e.g., linking a user’s Windows login id to their email address, or a User’s IP Address to a Hostname (or FQDN).
Enrichment
- Adding contextual data to a known entity from either user provided, or Google Chronicle provided, context sources, e.g., adding the user’s department to an event from their AD record, or the asset’s geographic location from Chronicle’s inbuilt Geo-ip enrichment
Validation
- Mandatory UDM fields that require population in order to submit a specific UDM metadata event type, e.g., target.user must be populated to submit a UDM metadata event_type of
USER_LOGIN
User Aliasing
Aliasing is the ability to join multiple identities for a given user into a single unified entity, e.g, linking together the local user ID on their Macbook to their Exchange email address to their Windows SID.
How is this performed? The most commonly used mechanism in Chronicle SIEM is via ingesting context data, e.g., Azure AD Context, Cloud Identity, OKTA, etc… which is loaded into the Chronicle Entity Graph, and then available for Aliasing for all incoming event data subsequently, between the valid interval duration (more on this later).
💡 See my prior post on using the Entity Graph as a Multi-dimensional list for info on Entity Graph.
Let’s run a test, and replay 4 USER_LOGIN events for the same entity, Conor Macloud, each with a different identifier:
- User ID =
connor.macloud - Email Address =
connor.macloud@acme.com - Windows SID =
S-1–5–21–1180699209–875555555–3182924444–3333 - Product Object ID =
connor.macloud
And the original JSON UDM for reference:
{"events": [{"metadata": {"event_timestamp": "2023–02–03T12:57:33.494129Z", "event_type": "USER_LOGIN", "description": "login via target userid", "product_name": "SSO", "vendor_name": "ACME", "product_event_type": "User Login"}, "principal": {"mac": "aa:aa:dd:55:44:33"}, "target": {"user": {"userid": "connor.macloud"}}, "security_result": {"action": "ALLOW", "summary": "Success"}, "extensions": {"auth": {"type": "MACHINE", "mechanism": "NETWORK"}}}]}
{"events": [{"metadata": {"event_timestamp": "2023–02–03T12:57:58.539986Z", "event_type": "USER_LOGIN", "description": "login via target email_address", "product_name": "SSO", "vendor_name": "ACME", "product_event_type": "User Login"}, "principal": {"ip": ["10.55.44.3"]}, "target": {"user": {"email_addresses": ["connor.macloud@acme.com"]}}, "security_result": {"action": "ALLOW", "summary": "Success"}, "extensions": {"auth": {"type": "MACHINE", "mechanism": "NETWORK"}}}]}
{"events": [{"metadata": {"event_timestamp": "2023–02–03T12:59:09.388943Z", "event_type": "USER_LOGIN", "description": "login via target windows sid", "product_name": "SSO", "vendor_name": "ACME", "product_event_type": "User Login"}, "principal": {"ip": ["10.55.44.3"]}, "target": { "user": {"windows_sid": "S-1–5–21–1180699209–875555555–3182924444–3333"}}, "security_result": {"action": "ALLOW", "summary": "Success"}, "extensions": {"auth": {"type": "MACHINE", "mechanism": "NETWORK"}}}]}
{"events": [{"metadata": {"event_timestamp": "2023–02–03T12:59:36.635514Z", "event_type": "USER_LOGIN", "description": "login via target product_object_id", "product_name": "SSO", "vendor_name": "ACME", "product_event_type": "User Login"}, "principal": {"ip": ["10.55.44.3"]}, "target": {"user": {"product_object_id": "connor.macloud"}}, "security_result": {"action": "ALLOW", "summary": "Success"}, "extensions": {"auth": {"type": "MACHINE", "mechanism": "NETWORK"}}}]Without a Context Aliasing source, these are treated as unique identities and not related to each other, i.e., no aliasing took place.
Without aliasing you have to search Chronicle SIEM for each unique identifier in User View, or run a UDM Search for each entity identifier, e.g:
target.user.windows_sid = "S-1-5-21-1085031214-1563986666-725347777" or
target.user.email_addresses = "juan.sánchez-villalobos.remediar@acme.com" or
target.user.product_object_id = "juan.sánchez-villalobos.remediar" or
target.user.userid = "juan.remediar"🗈 The above is a perfectly valid approach, e.g., for when a usable context source isn’t available as a log source.
Let’s re-run that test, but this time, with a user with a User Context Aliasing log source in place, as follows:
With a User Context source in place we replay four USER_LOGIN events for the matching user juan.sánchez-villalobos.remediar:
- User ID =
juan.remediar - Email Address =
juan.sánchez-villalobos.remediar@acme.com - Windows SID =
S-1–5–21–1085031214–1563986666–725347777 - Product Object ID =
juan.sánchez-villalobos.remediar
And the UDM events for reference:
{"events": [{"metadata": {"event_timestamp": "2023-02-03T13:28:55.236471Z", "event_type": "USER_LOGIN", "description": "login via target userid","product_name": "SSO", "vendor_name": "ACME", "product_event_type": "User Login"}, "principal": {"mac": "aa:aa:dd:66:55:44"}, "target": { "user": {"userid": "juan.remediar"}}, "security_result": {"action": "ALLOW", "summary": "Success"}, "extensions": {"auth": {"type": "MACHINE", "mechanism": "NETWORK"}}}]}
{"events": [{"metadata": {"event_timestamp": "2023-02-03T13:34:23.475658Z", "event_type": "USER_LOGIN", "description": "login via target email_address", "product_name": "SSO", "vendor_name": "ACME", "product_event_type": "User Login"}, "principal": {"ip": ["10.66.55.4"]}, "target": { "user": {"email_addresses": ["juan.s\u00e1nchez-villalobos.remediar@acme.com"]}}, "security_result": {"action": "ALLOW", "summary": "Success"}, "extensions": {"auth": {"type": "MACHINE", "mechanism": "NETWORK"}}}]}
{"events": [{"metadata": {"event_timestamp": "2023-02-03T13:31:00.980434Z", "event_type": "USER_LOGIN", "description": "login via target windows sid", "product_name": "SSO", "vendor_name": "ACME", "product_event_type": "User Login"}, "principal": {"ip": ["10.66.55.4"]}, "target": { "user": {"windows_sid": "S-1-5-21-1085031214-1563986666-725347777"}}, "security_result": {"action": "ALLOW", "summary": "Success"}, "extensions": {"auth": {"type": "MACHINE", "mechanism": "NETWORK"}}}]}
{"events": [{"metadata": {"event_timestamp": "2023-02-03T13:33:14.817312Z", "event_type": "USER_LOGIN", "description": "login via target product_object_id", "product_name": "SSO", "vendor_name": "ACME", "product_event_type": "User Login"}, "principal": {"ip": ["10.66.55.4"]}, "target": { "user": {"product_object_id": "juan.s\u00e1nchez-villalobos.remediar"}}, "security_result": {"action": "ALLOW", "summary": "Success"}, "extensions": {"auth": {"type": "MACHINE", "mechanism": "NETWORK"}}}]}And, with aliasing in place and working, we have one search in User View that returns all four logs 🎉
Notice the search for a single identifier for the entity, userid, returned all four logs whereas in the prior example there was only one log per entity identifier due to no context aliasing, and you had to search for each identifier individually.
We can summarize lessons learnt so far as follows:
| UDM Field | Aliasing Field | Validation Field | User View Searchable |
|-------------------|----------------|------------------|----------------------|
| UserID | Y | Y | Y |
| Email Addresses | Y | Y | Y |
| Windows SID | Y | Y | N |
| Product Object ID | Y | Y | N |- Product Object ID is only used for Aliasing within User View, not in UDM Search or Detection Engine from testing. There is an additional field called asset_id that can be used or Asset aliasing, but generally that’s only used by Chronicle SIEM’s default parsers.
Update, Feb 24. Product Object ID was at some stage updated and now does work as an aliasing and enrichment field, e.g., you can ingest a UDM event of type USER_LOGIN with only product_object_id, and this will alias successfully.
- Aliasing
Within UDM the UserID, Email Addresses, and Windows SID all appear to be Aliasing fields. If a UDM event includes one of these fields populated in the UDM Src, Principal or Target object, and there is a matching value in a UDM context event, then aliasing will take place.
2. Validation
Indirectly tested in the above, but in order to create a UDM event with a given UDM Metadata Event Type it requires UDM (and legacy SDM) Validation be passed. Each of the above fields was the only Target User value provided, and each event was successfully accepted, but with the caveat of how Product Object ID is only for User View, nowhere else it would seem.
🤔 Wait, what is SDM you ask? SDM was the original data model used in Chronicle SIEM, back when it was called Backstory, and more focused as a Threat Hunting platform. You don’t interact or use SDM today directly, but you may encounter legacy SDM validation as UDM events are dynamically converted to SDM behind the scenes in some cases, e.g., in a UDM PROCESS_ event SDM requires Principal be populated, and UDM will require Target, and that’s utilized by the original Indexed Views, e.g., Hash View, Asset View, IP View, Domain View.
If you try to create a USER_ event and do not have one of these core fields in the UDM Target object you get a validation error as follows:
{
"error": {
"code": 400,
"message": "Request contains an invalid argument.",
"status": "INVALID_ARGUMENT"
}
}🪧 See my prior post on Ingestion Stats for details on how to report upon potential Validation errors.
This isn’t an exhaustive list of Validation fields though, for example you can submit a USER_LOGIN without a User ID and just with Target Application (but that is probably not of much use).
💡The Chronicle UDM Usage guide touches upon this subject including what are Required fields.
3. User View Searchable
The final observation is that while some fields are Aliasing and Validation fields, that does mean you can search User View using those field values, specifically it’s only UserID and Email Addresses that you can search for a User Entity.
User Aliasing Summary
While Aliasing is an automated process within Chronicle SIEM, there are implementation details you need be aware of:
- You must have a context source for User Aliasing to work
You may say “Well obviously!” but aliasing is dependent on having either:
i) a Context source that can be loaded into the Entity Graph, for Asset and User aliasing
ii) DHCP logging, for Asset aliasing
If you don’t have a User Context source then no aliasing will take place.
There is an exception related to Process aliasing, for specific Parsers, e.g., Crowdstrike or Carbon Black, use <udm object>.process.product_specific_process_id to perform process ID aliasing, but that’s not something I’m covering in this post, and as mentioned Chronicle SIEM parsers will use asset_id in order to perform Asset aliasing, but I’m also not covering that in this post either.
⚠️ You must monitor your Entity pipelines as a high priority — if it fails, so eventually will your aliasing!
2. Context data is batch loaded into the Entity Graph at intervals.
There is no public documented interval for data being loaded into the Entity Graph as far as I can tell, but from observation this appears to minutes (usually) but can be several hours (at the time of writing), i.e., aliasing may not occur for up to six hours when first ingesting context data, and your Detections may also not have access to the latest context data. An example, if a user has their UDM Authentication Status field changed from ACTIVE to SUSPENDED, that will not be applied instantly; however, from testing the loading time is often far quicker than the upper boundary of six hours. In this case, it’s a decision of do we base the detection upon the original event (yes), or use the enriched detection (probably don’t rely on that solely if it’s time critical)
3. Entity Intervals
An Entity record has a start and end time, these are the time ranges when it will be valid and used for aliasing, let’s look at Juan’s example from earlier in the post:
metadata.collected_timestamp.seconds = 1675430783
metadata.collected_timestamp.nanos = 811292000
metadata.vendor_name = "ACME"
metadata.product_name = "CMDB"
metadata.entity_type = "USER"
metadata.interval.start_time.seconds = 1675344383
metadata.interval.start_time.nanos = 811310000
metadata.interval.end_time.seconds = 1675517183
metadata.interval.end_time.nanos = 811318000
entity.user.userid = "juan.remediar"
...Note the interval start_time and interval end_time. Aliasing and Enrichment will only be applied between this time range, mostly….
The majority of Chronicle SIEM default integrations for Context Sources will collect data either daily, or per hour, and generate a context interval accordingly.
The entity intervals themselves can be easily viewed in the Chronicle SIEM User View and Asset View.
I said mostly… Why is that? There is an exception where it appears User View uses a Context Record for a calendar week, i.e., Sunday to Sunday, even if the context record has passed its interval tie.
There are a couple of UI behaviours to be aware of with Context Views:
* the interval range in Asset View is linked to the time slider bar from observation, and not a reflection of the actual interval, but rather the time range shown
* if you have overlapping Entity records for a given users, the entity shown in User View are randomly selected (see below on overlapping context sources), and furthermore the Entity shown in the Entity tab may not be that shown in the Entity summary bar
Given those behaviors, ultimately I would default to using the Entity data from the log source itself, or else as an alternate you can use the below SQL statement in Chronicle Data Lake to get a view of multiple context sources for a given Entity in one go:
DECLARE
__USER_ID__ STRING DEFAULT "(?i)robert.smith"; --(?i) makes the regex case insensitive
DECLARE
__USER_EMAIL__ STRING DEFAULT "(?i)robert.smith";
DECLARE
__PARTITION_START_DATE__ STRING DEFAULT "2023-01-01"; --query is equal to or greater than
---------------
SELECT
m.enum_name AS context_entity_type,
e.metadata.vendor_name AS context_vendor,
e.metadata.product_name AS context_product,
e.metadata.collected_timestamp.seconds AS latest_collected_timestamp,
TIMESTAMP_SECONDS(e.metadata.INTERVAL.start_time.seconds) AS interval_start_timestamp,
TIMESTAMP_SECONDS(e.metadata.INTERVAL.end_time.seconds) AS interval_end_timestamp,
DATETIME_DIFF(DATETIME(TIMESTAMP_SECONDS(e.metadata.INTERVAL.end_time.seconds)), DATETIME(TIMESTAMP_SECONDS(e.metadata.INTERVAL.start_time.seconds)), HOUR) AS interval_duration,
e.entity.user.first_name AS user_first_name,
e.entity.user.last_name AS user_last_name,
e.entity.user.userid AS user_id,
TO_JSON_STRING(e.entity.user.email_addresses) AS user_emails,
e.entity.user.email_addresses[SAFE_ORDINAL(1)] AS primary_email
FROM
`datalake.entity_graph` e
JOIN
`datalake.entity_enum_value_to_name_mapping` m
ON
e.metadata.entity_type = m.enum_value
WHERE
m.enum_name = "USER"
AND DATE(_PARTITIONTIME) >= CAST(__PARTITION_START_DATE__ AS DATE)
AND ( REGEXP_CONTAINS(TO_JSON_STRING(e.entity.user.email_addresses), __USER_EMAIL__)
OR REGEXP_CONTAINS(e.entity.user.userid, __USER_ID__) )
AND m.field_path = "backstory.EntityMetadata.EntityType"4. Overlapping Entity sources
A less common, and a rather subtle issue, is that if you have overlapping identifiers across multiple Entity Context sources then unpredictable results may occur, i.e., it’ll enrich against Context source A sometimes, then Context source B other times.
Take the redacted screenshot below, specifically notice that for the same Entity some logs are being aliased and enriched against context source A (Workspace Users), and others against context source B (GCP IAM Analysis).
The impact?
- You may miss logs on User View or UDM Search, and break your downstream clients, i.e., your SOAR
- take the scenario where a log comes in whereemail_addressesis used for aliasing that matches context source A and injectsuseridA, but then the next log comes in and matches context source B and injectsuseridB. You search for User ID A and don’t get results for log B. - If you rely on enriched data for your search or detection, e.g., role, department, state, and they’re only added by one of your context sources then every log not matched against that context source won’t match your search or detection either
This is definitely a topic I will follow-up on shortly with a blog post as its a subtle and tricky one to diagnose — ultimately, try to not have overlapping context sources.
5. Different aliasing logic in different components
Subtly different logic for Aliasing is used between User View and UDM Search / YARA-L Detection engine, specifically logs aliased by Product Object ID are not returned in UDM search / Detection Engine when searching via another aliased field, e.g., windows_sid, userid, or email_addresses.
//target.user.windows_sid = "S-1-5-21-1085031214-1563986666-725347777"
// 3 results
//target.user.email_addresses = "juan.sánchez-villalobos.remediar@acme.com"
// 3 results
// target.user.product_object_id = "juan.sánchez-villalobos.remediar"
// 4 results
//target.user.userid = "juan.remediar"
// 3 resultsHowever, it’s not common for a log source to only use only product_object_id as the entity identifier, so this is a corner case.
6. User Aliasing is not Namespace aware
Namespaces are a feature for tagging context and event data with a user defined label, or else can be dynamically populated via a Parser. I wrote about Namespaces here before in case you’re not familiar with the topic. Most User Context sources will ingest to the default un-tagged Namespace. Unlike Asset Context sources, User Context sources are not Namespace aware, i.e., you could get user A in Namespace 1 aliased against user Z in Namespace 9. This is an unlikely scenario, and requires a username collision, e.g., both having the same username, but some cases it will happen, e.g., anything logging as root or admin.
Asset Aliasing
Asset Aliasing is the ability to join multiple identities for a given Asset, e.g.,., a server, a laptop, by linking the devices various identifiers such as IP address, hostname, MAC address.
As was the case with User Aliasing, it’s also performed via ingesting context data, e.g., Azure AD Context, OKTA, JAMF CMDB, etc…which is loaded into the Chronicle Entity Graph, and then available for Aliasing for all incoming event data subsequently, between the valid interval duration.
Let’s run a test, and replay several NETWORK_CONNECTION UDM events for the same asset, each with a different identifier:
- IPv4 =
192.0.10.10 - IPv6 =
::ffff:c000:a0a - NAT IPv4 =
100.172.0.10 - Hostname (not FQDN) =
frank-moran-01 - FQDN =
frank-moran-01.acme.com - MAC Address =
f3:90:a6:69:07:f6
and the UDM events for reference:
{"events": [{"metadata": {"event_timestamp": "2023–02–04T14:53:13.985154Z", "description": "network_connection via ipv4", "event_type": "NETWORK_CONNECTION", "product_name": "SSO", "vendor_name": "ACME", "product_event_type": "User Login"}, "principal": {"ip": ["192.0.10.10"]}, "target": {"ip": ["192.0.2.254"], "application": "ACME Connect", "user": {"userid": "frank.moran"}}, "security_result": {"action": "ALLOW", "summary": "Success"}, "extensions": {"auth": {"type": "MACHINE", "mechanism": "NETWORK"}}}]}
{"events": [{"metadata": {"event_timestamp": "2023–02–04T14:55:35.468101Z", "description": "network_connection via ipv6", "event_type": "NETWORK_CONNECTION", "product_name": "SSO", "vendor_name": "ACME", "product_event_type": "User Login"}, "principal": {"ip": ["::ffff:c000:a0a"]}, "target": {"ip": ["::ffff:c000:2fe"], "application": "ACME Connect", "user": {"userid": "frank.moran"}}, "security_result": {"action": "ALLOW", "summary": "Success"}, "extensions": {"auth": {"type": "MACHINE", "mechanism": "NETWORK"}}}]}
{"events": [{"metadata": {"event_timestamp": "2023-02-04T16:28:31.844270Z", "description": "network_connection via nat ipv4", "event_type": "USER_LOGIN", "product_name": "SSO", "vendor_name": "ACME", "product_event_type": "User Login"}, "principal": {"nat_ip": "100.172.0.10"}, "target": {"ip": ["::ffff:c000:2fe"], "application": "ACME Connect", "user": {"userid": "frank.moran"}}, "security_result": {"action": "ALLOW", "summary": "Success"}, "extensions": {"auth": {"type": "MACHINE", "mechanism": "NETWORK"}}}]}
{"events": [{"metadata": {"event_timestamp": "2023–02–04T15:10:49.417966Z", "description": "network_connection via hostname (not FQDN)", "event_type": "NETWORK_CONNECTION", "product_name": "SSO", "vendor_name": "ACME", "product_event_type": "User Login"}, "principal": {"hostname": "frank-moran-01"}, "target": {"ip": ["::ffff:c000:2fe"], "application": "ACME Connect", "user": {"userid": "frank.moran"}}, "security_result": {"action": "ALLOW", "summary": "Success"}, "extensions": {"auth": {"type": "MACHINE", "mechanism": "NETWORK"}}}]}
{"events": [{"metadata": {"event_timestamp": "2023–02–04T15:11:47.163245Z", "description": "network_connection via fqdn (not Hostname)", "event_type": "NETWORK_CONNECTION", "product_name": "SSO", "vendor_name": "ACME", "product_event_type": "User Login"}, "principal": {"hostname": "frank-moran-01.acme.com"}, "target": {"ip": ["::ffff:c000:2fe"], "application": "ACME Connect", "user": {"userid": "frank.moran"}}, "security_result": {"action": "ALLOW", "summary": "Success"}, "extensions": {"auth": {"type": "MACHINE", "mechanism": "NETWORK"}}}]}
{"events": [{"metadata": {"event_timestamp": "2023–02–04T15:13:33.983429Z", "description": "network_connection via MAC Address", "event_type": "NETWORK_CONNECTION", "product_name": "SSO", "vendor_name": "ACME", "product_event_type": "User Login"}, "principal": {"mac": "f3:90:a6:69:07:f6"}, "target": {"ip": ["::ffff:c000:2fe"], "application": "ACME Connect", "user": {"userid": "frank.moran"}}, "security_result": {"action": "ALLOW", "summary": "Success"}, "extensions": {"auth": {"type": "MACHINE", "mechanism": "NETWORK"}}}]}In the same vein as the prior User Aliasing test, without an Asset Context Aliasing source, each of these five events is treated as its own event and not linked together, apart from the one exception which is the IPv6 log. From testing an IPv4 address in an IPv6 address, i.e., ::ffff:c000:a0a will be converted to its IPv4 representation, 192.0.10.10, automatically, and hence they’d show together in Asset view.
Let’s re-run the test, but this time with an Asset Entity Context source in place.
metadata.collected_timestamp.seconds = 1675527096
metadata.collected_timestamp.nanos = 363782000
metadata.vendor_name = "ACME"
metadata.product_name = "LDAP"
metadata.entity_type = "ASSET"
metadata.interval.start_time.seconds = 1675440696
metadata.interval.start_time.nanos = 363812000
metadata.interval.end_time.seconds = 1675613496
metadata.interval.end_time.nanos = 363821000
entity.resource.type = "VIRTUAL_MACHINE"
entity.asset.product_object_id = "frank.moran.01"
entity.asset.hostname = "frank-moran-01"
entity.asset.ip = "192.0.10.10"
entity.asset.ip = "::ffff:c000:a0a"
entity.asset.mac = "f3:90:a6:69:07:f6"
entity.asset.nat_ip = "100.172.0.10"And with that in place, let’s replay the same set of events for Frank again. Now, a search in Asset View for the asset’s IP address returns all logs. Pretty neat.
What’s even more interesting is to notice that the events ingested prior to the Context record have been retrospectively aliased 🤯
Performing a query in UDM Search for principal.asset.hostname however does not return the event with the FQDN, so this would infer there is specific logic in Asset View that is not used in UDM Search.
An option here is to override a default parser that normalized a FQDN and extract away the hostname from thew FQDN to get consistent results.
So, the lessons to be learnt from this test, we can summarize as follows:
| UDM Noun | Aliasing Field | Validation Field | Asset View Searchable? |
|---------------------------------|----------------|------------------|------------------------|
| IP - IPv4 | Yes | Yes | Yes |
| IP - IPv6 (1) | Yes | Yes | No |
| NAT IP - IPv4 | No | No | No |
| Hostname - Hostname (not FQDN) | Yes | Yes | Yes |
| Hostname - FQDN | Yes | Yes | Yes (2) |
| MAC Address | Yes | Yes | Yes |
| Product Object ID (3) | No | No | No |- If it’s an IPv4 in IPv6 address
- If you search for the FQDN in Asset View you’ll only see logs with the FQDN, rather you’d need to search for the truncated Hostname to see all events
- Unlike USER_ events Product Object ID is not supported for Assets
As mentioned earlier, asset_id is another aliasing field that’s used by Chronicle SIEM parsers, but I’m not covering that here.
In summary, Asset aliasing with a single context source will successfully and transparently alias together data in a really powerful manner; however, there are considerations to be aware of as covered above.
Asset Aliasing Summary
Building upon the User Aliasing gotchas and nuances, here are Asset specific notes:
- As
nat_ipis not a validation field, i.e, you can’t submit aNETWORK_event with only anat_ippopulated. You can usenat_ipas the only field for other events, e.g aUSER_LOGIN. - A FQDN will have the trailing domain removed, e.g.,
acme.foo.barwill be changed toacme,which then enables successful aliasing. - IPv6 is partially supported, i.e., if there’s an IPv4 in IPv6 type of address, because it can extract out a valid IPv4 address, otherwise pure IPv6 is not supported from testing.
- Unlike User Context sources Asset Context sources are Namespace aware; however, most default Context sources will ingest into the un-tagged Namespace, so you may need a custom Parser Extension or custom ingestion pipeline to tag an Asset Context source into the correct Namespace.
product_object_idis not an aliasing field with Asset events, which is the opposite for User events, but in Chronicle SIEM parsers often use this withasset_idwhich does provide Asset aliasing- Within Asset View the Entity Interval values shown are based upon the time range selected in the View, not the actual values in the Entity record itself. If you definitively need to know the end time of an Asset entity record use raw log search or BigQuery. You will also see this behaviour if you use the
listassetaliasesSearch API method, it will return the Aliases for the time range of your query and not the intervals in the entity record itself.
DHCP Asset Aliasing
Another automatic option for Asset aliasing in Chronicle SIEM is using Dynamic Host Configuration Protocol (DHCP). DHCP log sources, such as Windows DHCP, Infoblox, PacketBeats, Corelight, etc… , or the Chronicle Forwarder’s native packet capture, provide DHCP information into Chronicle SIEM.
Dusting off RFC 2131, the DHCP standard, there’s a couple of important things to know regarding Chronicle:
- For dynamic asset aliasing via DHCP Chronicle SIEM is only intersted in specific Messages, namely REQUEST and ACK. While the platform can monitor other consume other DHCP message types, they’re not used for Aliasing purposes.
| Message | Use |
|---------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| DHCP DISCOVER | Client broadcast to locate available servers |
| DHCP OFFER | Server to client in response to DHCPDISCOVER with offer of configuration parameters |
| DHCP REQUEST | Client message to servers either (a) requesting offered parameters from one server and implicitly declining offers from all others, (b) confirming correctness of previously allocated address after, e.g., system reboot, or (c) extending the lease on a particular network address |
| DHCP ACK | Server to client with configuration parameters, including committed network address |
| DHCP NAK | Server to client indicating client's notion of network address is incorrect (e.g., client has moved to new subnet) or client's lease as expired |
| DHCP DECLINE | Client to server indicating network address is already in use |
| DHCP RELEASE | Client to server relinquishing network address and canceling remaining lease |
| DHCP INFORM | Client to server, asking only for local configuration parameters; client already has externally configured network address |2. Specific fields are required in a Chronicle parser to map DHCP to an asset, from testing, at a minimum:
REQUEST
- ciaddr = Client IP address (per RFC shouldn’t be needed, but Chronicle validation mandates it)
- chaddr = client hardware address
REPLAY
- chaddr = client MAC Address
- yiaddr = the client IP address
And in case you are wondering what are those wonderfully cryptic names listed above, please see the below from the DHCP RFC for reference.
FIELD OCTETS DESCRIPTION
----- ------ -----------
op 1 Message op code / message type.
1 = BOOTREQUEST, 2 = BOOTREPLY
htype 1 Hardware address type, see ARP section in "Assigned
Numbers" RFC; e.g., '1' = 10mb ethernet.
hlen 1 Hardware address length (e.g. '6' for 10mb
ethernet).
hops 1 Client sets to zero, optionally used by relay agents
when booting via a relay agent.
xid 4 Transaction ID, a random number chosen by the
client, used by the client and server to associate
messages and responses between a client and a
server.
secs 2 Filled in by client, seconds elapsed since client
began address acquisition or renewal process.
flags 2 Flags (see figure 2).
ciaddr 4 Client IP address; only filled in if client is in
BOUND, RENEW or REBINDING state and can respond
to ARP requests.
yiaddr 4 'your' (client) IP address.
siaddr 4 IP address of next server to use in bootstrap;
returned in DHCPOFFER, DHCPACK by server.
giaddr 4 Relay agent IP address, used in booting via a
relay agent.
chaddr 16 Client hardware address.
sname 64 Optional server host name, null terminated string.
file 128 Boot file name, null terminated string; "generic"
name or null in DHCPDISCOVER, fully qualified
directory-path name in DHCPOFFER.
options var Optional parameters field. See the options
documents for a list of defined options.With a DHCP log source sending data into your Chronicle SIEM, if successful DHCP aliasing is taking place you’ll see the following in the Chronicle Asset View:
On the other hand, if there is no DHCP aliasing (or Context Aliasing via Entity Graph) it’ll look like below:
As to Chronicle SIEM, it’s only interested in BOOTREQUEST or BOOTREPLY type DHCP logs, i.e., an ACK or a REQUEST, examples below:
metadata.event_timestamp.seconds = 1675619897
metadata.event_timestamp.nanos = 295382000
metadata.event_type = "NETWORK_DHCP"
metadata.vendor_name = "ACME"
metadata.product_name = "DHCP"
metadata.product_event_type = "DHCP Event"
metadata.description = "DHCP Request"
metadata.ingested_timestamp.seconds = 1675619897
metadata.ingested_timestamp.nanos = 474910000
metadata.id = "AAAAAHBA335fwZl4XzMxii943VsAAAAAAgAAAAAAAAA="
principal.ip = "192.0.12.44"
principal.asset.ip = "192.0.12.44"
intermediary.hostname = "acme_dhcp_server_01"
network.application_protocol = "DHCP"
network.dhcp.opcode = "BOOTREQUEST"
network.dhcp.ciaddr = "192.0.12.44"
network.dhcp.chaddr = "03:d6:2e:7d:44:44"
network.dhcp.type = "REQUEST"
network.dhcp.client_hostname = "russell-nash-01"metadata.event_timestamp.seconds = 1675619919
metadata.event_timestamp.nanos = 862701000
metadata.event_type = "NETWORK_DHCP"
metadata.vendor_name = "ACME"
metadata.product_name = "DHCP"
metadata.product_event_type = "DHCP Event"
metadata.description = "DHCP Reply"
metadata.ingested_timestamp.seconds = 1675619920
metadata.ingested_timestamp.nanos = 21566000
metadata.id = "AAAAAIr7NQFitjCjEwcV4qP/4AYAAAAAAgAAAAAAAAA="
principal.ip = "169.254.169.254"
principal.asset.ip = "169.254.169.254"
target.ip = "192.0.12.44"
target.mac = "03:d6:2e:7d:c8:44"
target.asset.ip = "192.0.12.44"
target.asset.mac = "03:d6:2e:7d:c8:44"
intermediary.hostname = "acme_dhcp_server_01"
network.application_protocol = "DHCP"
network.dhcp.opcode = "BOOTREPLY"
network.dhcp.yiaddr = "192.0.12.44"
network.dhcp.chaddr = "03:d6:2e:7d:c8:44"
network.dhcp.type = "ACK"
network.dhcp.lease_time_seconds = 604729Other useful things to know, DHCP Events do not show in Asset View, as the aliasing only starts working after the DHCP event comes in.
Summary
For the vast majority of folks who have a single context source, you’ve likely been using aliasing without necessarily knowing it’s there, and just works away in the background correctly aliasing and enriching your data. However, it’s always useful to know the mechanics of such an important feature, and hopefully this post helps started to provide insight into the specific mechanics of how Aliasing actually works.
I will caveat, this was testing by me, and so may have errors or oversights, and that Chronicle SIEM is a fast moving platform, so whats true when I wrote this, may not be the case in future.
Finally, this isn’t a single post topic, and so I’ve focused on Aliasing to start with, but in the next post I’ll focus on Enrichment.
