Chronicle SIEM is a cloud-native Security Information and Event Management (SIEM) solution that helps security teams detect, investigate, and respond to threats faster and more effectively. It offers several key features, including:

Cloud-scale ingestion and analysis: Chronicle SIEM can ingest and analyze petabytes of security telemetry data from a wide range of sources, including on-premises, cloud, and hybrid environments.
Advanced detection capabilities: Chronicle SIEM includes a library of predefined detection rules based on the MITRE ATT&CK framework and the ability to create custom rules using YARA-L.
Threat hunting: Chronicle SIEM provides security analysts with powerful tools to search and investigate threats across their data sets.

Chronicle consists of the following key components:

Data ingestion
Search
Dashboarding
Rules
Entity Graph
Parsing

We will discuss these components one by one.

Data ingestion:

Flow and Processing of Customer Security Data to Chronicle
Chronicle processes customer security data as follows:
An internal data forwarding service (such as Chronicle Forwarder) or a standard secure protocol (such as SFTP) sends raw security data directly to Chronicle. The security data is encrypted while in transit to Chronicle.
Chronicle retrieves security data stored in a cloud service (such as Amazon S3 or Google Cloud). The data is encrypted while in transit to Chronicle.
Chronicle logically segregates and stores your security data into your account in an encrypted form. Data is accessed by the customer only, plus a limited number of Google personnel as necessary to support, develop, and maintain the product.
Chronicle parses and validates the raw security data, making data easier to process and display.
Chronicle indexes the data to make it easier to search.
After it is validated and parsed, Chronicle checks the security data against third-party feeds (such as the DHS threat feed) and Chronicle’s internal threat analytics tools and systems.
Chronicle stores parsed and indexed data in an encrypted form within each account.
You log into your account to search and review your security data.
Chronicle searches for matches between your security data and the VirusTotal malware database. In a Chronicle event view, such as Asset view, click VT Context to display information from VirusTotal. Your security data is never shared with VirusTotal.

Best Practices on Data ingestion

Use collection methods and log formats recommended by Chronicle for common log sources (avoids parsing issues down the line)
NXlog is recommended for Windows log collection
Cribl works really well with Chronicle. There are some gotchas with forwarding of large logs.
SaaS sources that are not supported can be ingested using GCS/S3 or via custom ingestion scripts deployed as cloud functions
User and Asset Context data should ideally be ingested directly from the source as UDM entities (instead of some intermediate process or CSVs)
Some use cases like multi-column reference lists, IOC ingestion, nested/chained rules, advanced analytics and orchestration (rule output), etc are not well documented and may require some custom development

Data Ingestion Examples:

Chronicle Forwarder for LINUX and Windows
Docker Forwarder windows
Setup Data feeds ( for example if you need to ingest data from S3 or Cloud Storage, there are a number of endpoints available.
Ingest Google Cloud Data to Chronicle

Search:

The UDM search function enables you to find Unified Data Model (UDM) events and alerts within your Chronicle instance. UDM search includes a variety of search options, enabling you to navigate through your UDM data. You can search both for individual UDM events and groups of UDM events tied to shared search terms.

Searching for data: To access Chronicle UDM Search, select UDM Search from the application menu on the Chronicle landing page.

Dashboarding:

Chronicle Dashboard:

Chronicle provides a set of default dashboards for analysis and reporting within the Chronicle user interface. Reporting is available by converting a dashboard to a shareable file (for example, PDF, Excel, CSV, etc.). These dashboards are built upon the capabilities of Looker: https://cloud.google.com/looker and BigQuery: https://cloud.google.com/bigquery (both Google Cloud products). Looker acts as a visualization layer while BigQuery acts as a data layer.

Rules:

The rules engine is a fundamental component of Chronicle. Ingesting and searching data is important, but if you cannot generate detection events, analysts are left with petabytes of data to search through without a specific focus or prioritization.

The rules engine in Chronicle uses a language called YARA-L to build detections. For those not familiar with YARA, it is the language that Google’s VirusTotal team developed for use with malware samples

The three required sections of any YARA-L rule are the meta, events, and condition sections.

Meta contains the metadata associated with the rule itself.
Events contain the UDM fields and their associated values that are being evaluated to determine if criteria exist for the rule to fire.
Condition specifies the circumstances that would cause the rule to fire

Detection rules samples. https://github.com/chronicle/detection-rules

If you are keen to learn more about YARA-L, Check out this whitepaper

Entity Graph(aka Rules Engine):

Chronicle graph is a relational entity graph that can make use of joining UDM event data with context-enriched data and supports relational models too — e.g., entity user X owns entity asset Y that has access to entity resource Z (a database, firewall, storage bucket, etc.)

Parsing:

In general, customers send data as original raw logs. Chronicle uniquely identifies the device that generated the logs using the LogType. The LogType identifies both. the vendor and device that generated the log, such as Cisco Firewall, Linux DHCP Server, or Bro DNS which parser converts the raw log to a structured Unified Data Model (UDM). There is a one-to-one relationship between a parser and a LogType. Each parser converts data received by a single LogType.

Chronicle provides a set of default parsers that read original raw logs and generate structured UDM records using data in the original raw log. Chronicle maintains these parsers.

Customers can also define custom data mapping instructions by creating a customer-specific parser. Contact your Chronicle representative for information about creating a customer-specific parser.

List of Supported Default Parsers

Next steps to learn:

Chronicle Essentials:

Chrome extensions

ATT&CK Powered Suit