Creating an Asset Dashboard in Chronicle SIEM

A common validation task during asset on-boarding in Chronicle SIEM is to verify the registration of all or specific high-value assets from the anticipated log sources.

This post delves into the process of creating an observed asset dashboard in Chronicle SIEM to identify unique assets within your environment and outlines the caveats to consider when doing so.

An example Observed Assets dashboard in Chronicle SIEM

Considerations

While there are various approaches to building an asset dashboard in Chronicle SIEM, this example focuses on utilizing the events table and the principal.asset.hostname field.

The choice of this specific UDM field stems from the nuances and limitations encountered when constructing such a dashboard:

a) Some Chronicle SIEM parsers introduce external hostnames into the Principal UDM field, resulting in the creation of Assets for devices outside your organization. This explains the presence of external assets and websites in the Asset view.

b) Log sources exhibit inconsistencies in asset value representation. For instance, Windows Event Logs can report a single host as:

• hostname
• HOSTNAME
• hostname.fqdn.tld
• 1.2.3.4
• domain\hostname

c) Embedded Looker Dashboards impose a limit of 5,000 rows per widget result. For enterprises exceeding this asset count, an additional variable is required.

To address challenges (a) and (b), the recommended approach involves leveraging specific metadata.log_types. A widget on the example dashboard filters out log sources with external entities under principal that are marked as assets. To tackle challenge (b), Chronicle SIEM’s aliasing and enrichment capabilities ensure that principal.asset.hostname is populated across different log values with a consistent value, i.e., hostname. For larger deployments with more than 5,000 assets, additional filters, such as Namespace or Ingestion Labels, need to be incorporated into the widgets or dashboard.

The Dashboard

Using the above logic, and accounting for the considerations above, the actual Observed Assets dashboard is straightforward.

The only component that uses a more advanced feature is a custom table calculation. Table calculations are used to create adhoc metrics that span the entire result set, which is ideal for this use case, i.e., to create a total unique asset count. To achieve this, a Table calculation is created using the count_distinct function over the principal.asset.hostname UDM field.

Using Table Calculations to create a unique asset count

A copy of the Dashboard is available here:

thatsiemguy/dashboards/observed_assets at main · goog-cmmartin/thatsiemguy

🐉 Please be advised that this dashboard is not an official Google Chronicle product, and I cannot guarantee its accuracy as a comprehensive asset list for your environment due to the factors discussed above.

Summary

This post delves into the challenges and considerations associated with creating an Observed Asset dashboard using Chronicle SIEM’s embedded Looker. It highlights how asset aliasing can effectively address these challenges.

The provided example dashboard serves as a valuable and efficient starting point for obtaining a high level of confidence in asset count, provided it is filtered to utilize high-quality log sources and Chronicle Aliasing is implemented.

However, if absolute asset validation is required, a more suitable but intricate approach would involve utilizing the Chronicle Datalake export to BigQuery and employing custom SQL statements. This method offers a more versatile and robust feature set.