Welcome to another Security Analyst Diary entry. We are excited to cover our integration with Google Workspace. Check out the video podcast of this diary entry.

Google’s cloud-native SIEM, Chronicle, provides native integrations for modern productivity and collaboration suite, Google Workspace. In today’s Security Analyst Diary we’re going to cover:

1. Why integrate Google Workspace with Chronicle?

2. How to integrate Workspace with Chronicle: ingestion

3. Using Chronicle for detection & response with Google Workspace

Let’s begin!

Why integrate Workspace with Chronicle?

Google Workspace is the leading productivity and collaboration suite from Google. Workspace revolutionizes productivity for customers and includes modern security controls that help mitigate many common attacks, such as ransomware. However, for many organizations you will still require i) an audit trail of Workspace activities, and ii) want to build custom detection controls on top of Workspace activity.

In this diary we’ll cover examples of how you can easily integrate a wide range of Google Workspace event and context data with your security telemetry and drive search and threat detection.

Integrating Workspace + Chronicle: ingestion

Google Workspace has a lot of features, capabilities that generate audit and log data. Let us cover the scope of logs within Workspace, and how they can be ingested into Chronicle.

Chronicle GCP log ingestion & Workspace to GCP sharing

The first option for ingesting Workspace logging to Chronicle is via GCP operations.  This approach requires enabling Workspace’s share data with GCP feature.  Enabling this will export the following Workspace activity reports:

• Groups Enterprise audit log

• Admin audit log

• Login audit log

• OAuth Token audit log

• SAML audit log

• Access Transparency audit log (Enterprise and Education editions only)

Once it is enabled, you can then utilize Chronicle’s native GCP log collection.

Example UDM search

metadata.vendor_name = "Google Cloud Platform" AND metadata.product_name = "G Suite"

Chronicle-native Workspace API integration

The second approach for collecting Workspace logging is via Chronicle’s native Workspace API integration, which provides coverage for the following sources:

• All Workspace Activity Reports

• Workspace Alerts

• Workspace Context Data

  • E.g., Users, Groups

This requires  i) a (Service) account in Workspace to be set up, ii) service account is granted the appropriate OAuth scope and privileges, and iii) a new feed is created in Chronicle’s Feed Management.

There are a few things to be mindful of:

• Some Workspace activity reports have high latency time, which means collection will be delayed to avoid missing logs

• At the time of writing, the collection interval within Chronicle’s Feed Management is every:

• 60 minutes  for Event sources, i.e., WORKSPACE ACTIVITY and WORKSPACE ALERTS

• 24 hours for WORKSPACE Context sources, i.e., CHROMEOS, MOBILE, USERS, GROUPS

Example UDM search

Workspace Activity

metadata.vendor_name = "Google Workspace" AND metadata.product_name = "saml"

Workspace Alerts

metadata.product_name = "Google Workspace" AND metadata.vendor_name = "Alerts"

Chrome browser management alerts

This is a specific integration that can provide Chrome browser alerts directly into Chronicle:

• Malware transfer

• Password changed

• Password reuse

• Unsafe site visit

The configuration is via the Google admin console, and does require you have either i) a Chronicle Ingestion API key, or ii) use a GCP Pub/Sub and custom cloud function (which still will require a Chronicle ingestion key).

Example UDM search

metadata.vendor_name = "Google" AND metadata.product_name = "Chrome Management" AND
metadata.product_event_type = "badNavigationEvent"

Gmail logging via BigQuery

Gmail, as a part of Google Workspace, provides the log export options of either i) integration with a 3rd party email archive solution, or ii) exporting GMail logs to BigQuery.  Chronicle does support parsing of Gmail logs exported to BigQuery via the Parser label GMAIL_LOGS; however, Chronicle doesn’t have a native connector to BigQuery at this time, and it requires you export the BigQuery Gmail audit table into a JSON newline format log file.  Once the data is exported from BigQuery it can be stored in GCP Google Cloud Storage (GCS) and collected from there using Chronicle’s Feed Management.

Example UDM search

metadata.vendor_name = "Google" AND metadata.product_name = "GMAIL"

Ingestion summary

Wait, that was a lot of different ways to collect Workspace data. Which should I use? Well, the answer depends!

Given the security value and ease of use for integration, a general recommendation would be to start with Chronicle’s GCP log ingestion for Workspace activity reports, and use Chronicle native Workspace integration for i) remaining Workspace activity reports not supported by the Workspace GCP sharing integration. If you require collection of Workspace activity reports below the threshold of 60 minutes, as supported by Feed Management for Workspace activity, then you may wish to use the Terraform GSuite exporter module.

Detection & response on Google Workspace with Chronicle

Now we’ve been able to ingest a wide range of Workspace data, let's explore the use cases we can implement with Chronicle.

Context enrichment

The first use case for Google Workspace data is context. Workspace provides a variety of context enrichment sources (we covered Context Enrichment in a previous Security Analyst Diary), which are listed below:

Workspace users is one of the most common and a highly recommended first context source to implement.

Want to find out more on context enrichment within Chronicle?  See our documentation on Context Aware Analytics.

Workspace users

Workspace Users create a USER context record within Chronicle, and the resultant record is used as a lookup table in order to i) lookup differing user IDs, e.g., username, email, and associate the different identities, and ii) to inject the context record data into each matching UDM log, i.e., you can search upon values not originally in the log itself.

Here’s an example Workspace User Context UDM USER entity record.  Note the fields highlighted in green which are used for context enrichment.

metadata.collected_timestamp = "2022-07-04T13:26:54.551437Z"
metadata.vendor_name = "Google"
metadata.product_name = "Cloud Identity"
metadata.entity_type = "USER"
entity.user.userid = "chris_martin_acme"
entity.user.user_display_name = "Chris Martin"
entity.user.email_addresses = "chris.martin@acme.com"
entity.user.email_addresses = "chris.martin@demo.acme.com"
entity.user.email_addresses = "chris.martin@acme.com.test-google-a.com"
entity.user.employee_id = "EMEA-10CM"
entity.user.product_object_id = "123123123123123123123"
entity.user.attribute.labels.key = "signInName"
entity.user.attribute.labels.value = "chris.martin@acme.com"
entity.user.attribute.labels.key = "changePasswordAtNextLogin"
entity.user.attribute.labels.value = "False"
entity.user.attribute.labels.key = "isMailboxSetup"
entity.user.attribute.labels.value = "True"
entity.user.attribute.labels.key = "isEnrolledIn2Sv"
entity.user.attribute.labels.value = "True"
entity.user.attribute.labels.key = "isEnforcedIn2Sv"
entity.user.attribute.labels.value = "True"
entity.user.attribute.labels.key = "includeInGlobalAddressList"
entity.user.attribute.labels.value = "True"
entity.user.attribute.labels.key = "Recovery Email Address"
entity.user.attribute.labels.value = "cmmartin@webmail.com"
entity.user.attribute.labels.key = "kind"
entity.user.attribute.labels.value = "admin#directory#user"
entity.user.attribute.roles.description = "Full Time"
entity.user.attribute.creation_time = "2021-09-30T11:04:46Z"
entity.user.first_name = "Chris"
entity.user.last_name = "Martin"
entity.user.phone_numbers = "+31 123 456 789"
entity.user.title = "Sales Engineer"
entity.user.department = "Sales"
entity.user.managers.email_addresses = "pinguino@acme.com"
entity.user.user_authentication_status = "ACTIVE"

When does Workspace use a UserID, it's all email addresses, isn’t it?  Well this is where Workspace users integration can be of benefit when using Workspace secure LDAP, or GCP OSLogin, specifically around the PosixAccount.

Example of context enrichment in action

1. Login to a GCP GCE instance using OSLogin, i.e., using your userid

chris_martin_acme@ops-agent-01:~$ whoami  
chris_martin_acme@ops-agent-01:~$ sudo -i  
root@ops-agent-01:~# hostname
ops-agent-01

2. Search for the activity via the user’s email address:

metadata.product_name = "Unix System" AND (principal.user.email_addresses = "chris.martin@acme.com" OR target.user.email_addresses = "chris.martin@acme.com")

3. Results returned for activity within a GCP GCE VM instance, aliased against the user’s email address via context enrichment.

Here’s an example excerpt from the UDM search above, and note that despite our searching for the user email address, we still get matching logs against the user id value (and as an added bonus, you can even get the mapping back to SU activity to a root user!)

Search

Let’s explore options for using Chronicle’s UDM Search feature.

Searching on UDM context-enriched fields

One powerful example of context enrichment is the ability to search on enriched values within a log, for example Workspace activity logging does not include the users job title, employee ID, or their phone number; however, Workspace users can provide this context information, as we saw above, and we can therefore run a UDM search upon those values (and any context-enriched field!)

Search for job role

For example, if responding to a targeted phishing attack against specific user roles.

principal.user.title = "Sales Engineer" OR target.user.title = "Sales Engineer"

Search all users within a department

In the scenario you want to search for all users in a given department, irrespective of job role, you can use the Department field.

principal.user.department = "Finance" OR target.user.department = "Finance"

Search for employee ID

principal.user.employee_id = "EMEA-10CM" OR target.user.employee_id = "EMEA-10CM"

Search by phone number

principal.user.phone_numbers = "-1 621 573 995" OR target.user.phone_numbers = "-1 621 573 995"

Yes, this isn’t a real phone number, but just to make sure no one ends up with any unexpected calls.

And… you hopefully get the idea here.  You can start to build your search and investigations based on not only Workspace event data, but also Workspace context data!

For a full list of available UDM context fields, see our UDM entity field list: https://cloud.google.com/chronicle/docs/reference/udm-field-list#entity

Google Workspace UDM searches

Workspace activities user accounts reports

To find the event types that Workspace activity reports use, you can search Google Workspace’s documentation available here: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/user-accounts

Using a couple of interesting examples from here, you can build your UDM search as follows:

metadata.vendor_name = "Google Workspace" AND  
metadata.product_name = "user_accounts" AND  
metadata.product_event_type = "email_forwarding_out_of_domain"

If you want to search for multiple event types, e.g., suspicious activity related to resetting recovery details, make use of the OR grouping logic in UDM search.

metadata.vendor_name = "Google Workspace" AND
metadata.product_name = "user_accounts" AND
(
metadata.product_event_type = "recovery_phone_edit" OR
metadata.product_event_type = "recovery_email_edit"
)

A more complex example using Admin activity reports to detect activity on monitored Groups, e.g, the Groups used for RBAC to Chronicle itself.

metadata.vendor_name        = "Google Workspace" AND
metadata.event_type         = "USER_RESOURCE_ACCESS" AND
metadata.product_name       = "admin" AND
(
metadata.product_event_type = "ADD_GROUP_MEMBER" OR
metadata.product_event_type = "REMOVE_GROUP_MEMBER"
)
security_result.action      = "ALLOW"  AND
about.labels.key            = "GROUP_EMAIL" AND
(
about.labels.value = "security-admins@acme.com" OR
about.labels.value = "infosec@acme.com" OR
about.labels.value = "chronicle_editors@acme.com" OR
about.labels.value = "chronicle_administrators@acme.com"
)

Change the group names as required, i.e., the about.labels.value UDM fields.  For a full list of potential event types from Google Workspace admin activity reports, see https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-group-settings

Detection

For activities you wish to have proactive alerting, or perform historical detection, you can use Chronicle’s rules engine to build YARA-L rules.

Detection Engine can also be used for search requirements where you want require threshold logic, e.g., more than 10 files shared, or risk scoring, e.g., risk scoring based upon your threat modeling.

But, before that, let’s start with some out of the box content.

Chronicle detect GitHub

Chronicle includes out of the box YARA-L rules on our public Github: https://github.com/chronicle/detection-rules/tree/main/google_workspace

workspace_2step_verification_disabled.yaral workspace_admin_login_without_2fa.yaral workspace_calendar_settings_changed.yaral workspace_custom_role_created.yaral workspace_device_compromised.yaral workspace_drive_settings_changed.yaral workspace_external_domain_user_added.yaral workspace_failed_screen_unlock.yaral workspace_gmail_settings_changed.yaral workspace_government_backed_attacks.yaral workspace_leaked_password.yaral workspace_mobile_setting_changed.yaral workspace_new_user_added.yaral workspace_phishing_alert.yaral workspace_public_documents.yaral workspace_super_user_login.yaral workspace_suspicious_device_activity.yaral workspace_suspicious_login.yaral workspace_suspicious_programmatic_login.yaral workspace_unsanctioned_oauth_application_usage.yaral workspace_user_admin_privilege_revoked.yaral workspace_user_changed_password.yaral workspace_user_deleted.yaral workspace_user_granted_admin_privilege.yaral workspace_user_suspended_by_admin.yaral workspace_user_suspended_spamming_through_relay.yaral workspace_user_suspended_suspicious_activity.yaral workspace_user_unsuspended_by_admin.yaral

The YARA-L rules are based off of Workspace alert center alerts, with the bonus you can fine tune alerts as needed.

Building your own YARA-L rules for Workspace

Let’s take the previous UDM search for monitored groups, and convert it into a context aware detection using YARA-L.

The first part of converting a UDM search to a YARA-L rule, and vice versa, will be that a YARA-L rule will need to be grouped into an object, e.g., $event.

We then use a Chronicle’s Reference List, so rather than keep a list of the monitored groups in an OR statement, you can call the reference list via the `in %list_name` format.

The final part of the rule is Chronicle’s risk scoring capability.  The outcome: section enables you to generate risk scores upon your threat modeling, so in this example we’ll increase the risk score if a user is added to our Chronicle administrators group:

if ( $event.about.labels.value = /chronicle_administrators@/ nocase, 40) +  
if ( $event.about.labels.value = /chronicle_editors@/ nocase, 30)  

And finally, the rule itself:

rule workspace_user_added_to_monitored_group {
meta:
author      = "Google Cloud Security"
description = "A super user has been added or removed from a monitored group."
severity    = "Medium"
events:
$event.metadata.vendor_name        = "Google Workspace"
$event.metadata.event_type         = "USER_RESOURCE_ACCESS"
$event.metadata.product_name       = "admin"
(
$event.metadata.product_event_type = "ADD_GROUP_MEMBER" or
$event.metadata.product_event_type = "REMOVE_GROUP_MEMBER"
)
$event.security_result.action      = "ALLOW"
// update monitored group names below
$event.about.labels.key = "GROUP_EMAIL" and
$event.about.labels.value in %workspace_monitored_groups
//match variables
$event.principal.user.email_addresses = $userAdding
$event.target.user.email_addresses = $userAdded
(
$event.about.labels.key = "GROUP_EMAIL" and
$event.about.labels.value = $groupAdded
)

//Exclusions
// - remove contextual enriched addresses
not $event.principal.user.email_addresses = /acme.com.test-google-a.com/
not $event.principal.user.email_addresses = /acme.com/
match:
$userAdding, $userAdded, $groupAdded over 1m
outcome:
$risk_score = max(
//set base alert score
if (
$event.metadata.product_event_type = "ADD_GROUP_MEMBER" or
$event.metadata.product_event_type = "REMOVE_GROUP_MEMBER",
50) +
// Risk Scored Groups
if ( $event.about.labels.value = /chronicle_administrators@/ nocase, 40) +
if ( $event.about.labels.value = /chronicle_editors@/ nocase, 30)
)
condition:
$event
}

Another example, this time looking for documents being shared in a way that could lead to exposed data, and using Chronicle’s context enrichment to change the risk score depending on i) the method of data being shared, and ii) based upon the department, or role, of the user sharing the data.

The key parts of this YARA-L rule are in the outcome: section, applying risk scoring based upon the context information gathered from the Workspace user context integration.

rule workspace_public_documents {
meta:
author = "Chronicle Security"
description = "Detects publicly accessible documents on Google Drive."
severity = "INFORMATIONAL"
events:
$workspace.target.application = "Google Drive"
any $workspace.about.labels.key = "visibility" and
(
any $workspace.about.labels.value = "public_on_the_web" or
any $workspace.about.labels.value = "people_with_link"
)
//match variables
$workspace.principal.user.email_addresses = $user
match:
$user over 10m
outcome:
//risk_score should not exceed above 100
$risk_score = max(
if ( $workspace.about.labels.value = "people_with_link", 40) +
if ( $workspace.about.labels.value = "public_in_the_domain", 30) +
if ( $workspace.about.labels.value = "public_on_the_web", 50) +
if ( $workspace.about.labels.value = "shared_externally", 40) +
// department based context scoring
if ( $workspace.principal.user.department = "HR", 25) +
if ( $workspace.principal.user.department = "Finance", 25) +
if ( $workspace.principal.user.department = "Legal", 15)
// role based context scoring
if ( $workspace.principal.user.attribute.role.name = "Temp", 25) +
if ( $workspace.principal.user.attribute.role.name = "Full Time", 10) +
)
condition:
$workspace
}

And as with all YARA-L rules, the above can be run as a live rule, or as a historical retrohunt, and the results viewed within Chronicle Dashboards.

Summary

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

To learn more about these integrations and 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 story in another Security Analyst Diary.