Welcome to another Security Analyst Diary entry. We are excited to cover not one, but three of our coolest feature releases that enable our customers to drive greater efficiencies with Chronicle SIEM, create impactful detections, and gain context with native-integration of VirusTotal. Check out the video podcast of this diary entry.

With these new capabilities, Google Chronicle customers can:

• Manage the health of Chronicle deployment

• Build new detections for key SOC use cases

• Drive additional context using native-VirusTotal widget.

In this diary entry, we will drill into the new capabilities these capabilities provide, and cover some examples of how Chronicle users have been using these capabilities so far.

New Ingestion Metrics

Chronicle exposes ingestion telemetry ranging from the Chronicle Forwarder logs, to statistical exports into the Chronicle data lake. However, the collation of Chronicle Forwarder telemetry was an endeavor left to the end customer, and the prior statistical export of statistical metrics ( ingestion stats table) was batch based, i.e., every hour.

The new ingestion metrics table in Chronicle’s data lake now includes streaming updates to help address low latency requirements, and provide visibility into the activities of the Chronicle Forwarder and Feed Management feature.

Customers can access the new ingestion metrics table data via:

• the BigQuery Datalake table: datalake.ingestion_metrics table

  • Using either the GCP Console

  • Or 3rd party integrations like Google Sheets Connected Sheets feature

• Chronicle’s embedded Looker dashboards (example below)

• Additional Enterprise Looker dashboards

Let us visually explore this new data via Chronicle’s embedded Looker Dashboards.

Here’s an example of an embedded dDashboard that shows these new highlights:

• Components - full visibility into metrics from the Chronicle Forwarder, Ingestion API, and Feed Management (Out of band)

• Log Types - all ingesting log types, and the relation back to either a Forwarder, Component, or Feed Type, as all as a depth of related log volume and parsing statistics

• Chronicle Forwarders (Collectors) - see details about all active Chronicle Forwarders (Collectors)

• Feed Management (Feed IDs) - telemetry for Chronicle’s SAS based log source capabilities

This insight leads onto more powerful use cases around the hygiene and health of the customer’s Chronicle instance:

• Chronicle Forwarder telemetry

  • Heartbeat data - are the forwarders working as expected ?

  • Filtering statistics & errors - are log sources parsing as expected, and if not, why not?

    • Regex filter and configuration based normalizers (CBN) Drop statement logging

A quick example would be to monitor the health of Chronicle Forwarders via a simple dashboard. In this example, Chronicle shows a unique count of each timestamp per forwarder plotted visually as a line graph.

Chronicle’s embedded dDashboards can also be used to create custom measures, e.g., a list of Unique Collectors. Given the disparate data sources that are being ingested in today’s environments, having a holistic auditable view of various collectors is useful for analysts to understand their breadth of collection activity.

New YARA-L Functions in detection engine

We’ve released several new interesting YARA-L functions in Chronicle’s detection engine that provide string and regex matching, and timestamp and arithmetic operations - ultimately, enabling you to craft even more robust detections in Chronicle’s rule engine.

To showcase interesting use cases, we’ll focus on the timestamp functions for this diary entry (which is to say, we’ll be back to review the string and regex functions another time).

Here’s the full list courtesy of our April 2022 release notes:

• strings.concat(a, b)

• strings.to_lower(stringText)

• strings.to_upper(stringText)

• strings.base64_decode(encodedString)

• re.capture(stringText, regex)

• re.replace(stringText, replaceRegex, replacementText)

• timestamp.get_minute(unix_seconds [, time_zone])

• timestamp.get_hour(unix_seconds [, time_zone])

• timestamp.get_day_of_week(unix_seconds [, time_zone])

• timestamp.get_week(unix_seconds [, time_zone])

• timestamp.current_seconds()

• math.abs(intExpression)

Pro Tip! Subscribe via your favorite RSS to our Release Notes to get the latest release notes.  While you’re at it, subscribe to our Google Chronicle Community forum too.

The new time YARAL functions enable operations upon the several different timestamp fields available in Chronicle’s UDM, ultimately enabling you to apply more fine grained time based criteria into your detections.

A detailed list of all the timestamp fields available in Chronicle’s UDM can be found in our UDM field list. Some useful and interesting (and not exhaustive) sample fields to get started with include:

• event_timestamp

• ingested_timestamp

• collected_timestamp

• creation_timestamp

• first_seen_time

• first_discover_time

• last_discover_time

• system_last_update_time

• last_boot_time

• certificate.not_before

• certificate.not_after

• last_modification_time

Let’s see how a customer used the certificate timestamp fields to drive impactful outcomes in their SOC.

Detecting Expired or Expiring Certificates

ACME Inc would like to be able to detect expiring or expired certificates issued by their CA chain of trust, and using NDR or EDR log sources into our detection engine we can do exactly that in a quick and elegant way.

The below rule evaluates any UDM events of type NETWORK_CONNECTION, where the Issuing Certificate was from ACME, and the certificate expiration (certificate.not_after) timestamp is less than now.

rule acme_expiring_cert {

meta:

author = "Chronicle Security Analyst Diaries"

description = "Detects expiring ACME server TLS certificates. "

severity = "INFO"

events:

$cert.metadata.event_type = "NETWORK_CONNECTION"

$cert.metadata.product_name = "Network Monitor"

$cert.network.tls.server.certificate.subject = /acme.com/ nocase

$cert.target.ip = $host

$cert.network.tls.server.certificate.not_after.seconds > 0

// cert expired

// - note, this take the current timestamp, not the event timestamp

// - running after the fact would find certificates that may have expired, but were valid at the event time    timestamp.current_seconds() > $cert.network.tls.server.certificate.not_after.seconds

// cert valid

//timestamp.current_seconds() < $cert.network.tls.server.certificate.not_after.seconds

// cert has less than 48 hours

//172800 < ( $cert.network.tls.server.certificate.not_after.seconds - timestamp.current_seconds() )

match:

$host over 1m

condition:

$cert

}

Here are the results:

This time matching isn’t just limited to Certificates though, let’s explore another example.

Detecting privileged account use out of working hours

We can use Chronicle’s timestamp fields with the new time functions to extract out specific intervals, such as the minute, hour, day or week.  Let’s see how we can use these to create an operational security detection based upon privileged account access on non-workdays, or out of hours.

The detection looks for:

• UDM event types of USER_LOGIN, where the auth was successful (ALLOW)

• uses Chronicle’s Context Enrichment to automatically detect privileged users, i.e., via integration with Azure AD, Cloud Identity, etc…

• Stores the current event timestamp to the placeholder variable $ts

• Evaluates $ts with a conditional statement looking for either

  • events occurring on day 1 or 7 of the week (Sunday or Saturday)

  • events occurring on beyond 19:00 through 07:00

• Finally, using Outcomes, use the time functions to change the risk score accordingly generating a unique outcome variable.

rule out_of_hours_login {

meta:

author = "Chronicle Security Analyst Diaries"

description = "Detects out of working hours successful authentication for monitored privileged entities."

severity = "MEDIUM"

events:

$out_of_hours_login.metadata.event_type = "USER_LOGIN"

$out_of_hours_login.target.user.email_addresses = $user

$out_of_hours_login.security_result.action = "ALLOW"

(

$out_of_hours_login.target.user.user_role = "ADMINISTRATOR" or

$out_of_hours_login.target.user.attribute.roles.type = "ADMINISTRATOR"

)

$ts = $out_of_hours_login.metadata.event_timestamp.seconds

// Sunday [01] and Saturday [07]

(

01 = timestamp.get_day_of_week($ts, "UTC") or

07 = timestamp.get_day_of_week($ts, "UTC")

) or

// successful auth beyond core hours - 19:00 through to 07:00

(

( timestamp.get_hour($ts, "UTC") >= 0 and timestamp.get_hour($ts,"UTC")<= 6) or

timestamp.get_hour($ts,"UTC") > 19

)

match:

$user over 1m

outcome:

$weekend_activity = max(

// higher risk for weekends

if (01 = timestamp.get_day_of_week($ts, "UTC"), 75) +

if (07 = timestamp.get_day_of_week($ts, "UTC"), 70)

)

$after_hours_activity = max(

// higher risk for weekends

if ( ( timestamp.get_hour($ts, "UTC") >= 0 and timestamp.get_hour($ts,"UTC")<= 6) or timestamp.get_hour($ts,"UTC") > 19, 50)

)

condition:

$out_of_hours_login

}

In this example, pay attention to the custom outcome variables. 7th being a Saturday, and the event being out of normal office hours leads to increased risk scores.

You can find the YARA-L guide, including these new functions and more here.

Chronicle native-VirusTotal augment widget

Next up, Google Cloud’s VirusTotal (VT) now has a native widget within Chronicle SIEM, that allows analysts to gain context on their threats on the same console.  VT has had support for content enrichment and lookups via a Chrome browser extension, VT4Browsers, as an overlay on any web page; however, this widget takes this a step further and builds a native integration directly into the Chronicle UI.

When searching for artifacts such as Domains, IPs, or Hashes, you’ll now see a VT Context link inline in the Chronicle UI, example below:

The VT widget in Chronicle is a preview feature at present, and the documentation on the feature can be found here -  https://cloud.google.com/chronicle/docs/preview/vt-context/view-virustotal-information

Summary

We look forward to hearing from customers and driving towards goals of securing the enterprise at scale with these features:

• Manage the health of Chronicle deployment

• Build new detections for key SOC use cases

• Drive additional context using native-VirusTotal widget.

To learn more about these new capabilities, contact your Google Cloud Platform sales or CSM team. You can learn more about all these new capabilities in Google Chronicle in our product documentation.

Don't forget to look at the video podcast of this entry. Looking forward to sharing another actionable story in the next Security Analyst Diary.