Overview of Event Threat Detection

What is Event Threat Detection?

Event Threat Detection is a built-in service for the Security Command Center Premium tier that continuously monitors your organization or projects and identifies threats within your systems in near-real time. Event Threat Detection is regularly updated with new detectors to identify emerging threats at cloud scale.

How Event Threat Detection works

Event Threat Detection monitors the Cloud Logging stream for your organization or projects. If you activate Security Command Center Premium tier at the organization level, Event Threat Detection consumes logs for your projects as they are created and Event Threat Detection can monitor Google Workspace Logs . Cloud Logging contains log entries of API calls and other actions that create, read, or modify the configuration or metadata of your resources. Google Workspace logs track user sign-ins to your domain and provide a record of actions performed on your Google Workspace Admin Console.

Log entries contain status and event information that Event Threat Detection uses to quickly detect threats. Event Threat Detection applies detection logic and proprietary threat intelligence, including tripwire indicator matching, windowed profiling, advanced profiling, machine learning, and anomaly detection, to identify threats in near-real time.

When Event Threat Detection detects a threat, it writes a finding to Security Command Center. If you activate Security Command Center Premium tier at the organization level, Security Command Center can write findings to a Cloud Logging project. From Cloud Logging and Google Workspace logging, you can export findings to other systems with Pub/Sub and process them with Cloud Run functions.

If you activate Security Command Center Premium tier at the organization level, you can additionally use Google Security Operations to investigate some findings. Google SecOps is a Google Cloud service that lets you investigate threats and pivot through related entities in a unified timeline. For instructions on sending findings to Google SecOps, see Investigate findings in Google SecOps .

Your ability to view and edit findings and logs is determined by the Identity and Access Management (IAM) roles you are granted. For more information on Security Command Center IAM roles, see Access control .

Event Threat Detection rules

Rules define the type of threats that Event Threat Detection detects and the types of logs that must be enabled for detectors to work. Admin Activityaudit logs are always written; you can't configure or disable them.

Event Threat Detection includes the following default rules:

Custom modules for Event Threat Detection

In addition to built-in detection rules, Event Threat Detection provides module templates that you can use to create custom detection rules. For more information, see Overview of custom modules for Event Threat Detection .

To create detection rules for which no custom module templates are available, you can export your log data to BigQuery , and then run unique or recurring SQL queries that capture your threat models.

Unsafe Google Group changes

This section explains how Event Threat Detection uses Google Workspace logs, Cloud Audit Logs, and IAM policies to detect unsafe Google Groups changes. Detecting Google Groups changes is only supported when you activate Security Command Center at the organization level.

Google Cloud customers can use Google groups to manage roles and permissions for members in their organizations, or apply access policies to collections of users. Instead of granting roles directly to members, administrators can grant roles and permissions to Google Groups, and then add members to specific groups. Group members inherit all of a group's roles and permissions, which lets members access specific resources and services.

While Google Groups are a convenient way to manage access control at scale, they can pose a risk if external users from outside your organization or domain are added to privileged groups—groups that are granted sensitive roles or permissions . Sensitive roles control access to security and network settings, logs, and personally identifiable information (PII), and are not recommended for external group members.

In large organizations, administrators might not be aware when external members are added to privileged groups. Cloud Audit Logs record role grants to groups, but those log events don't contain information on group members, which can obscure the potential impact of some group changes.

If you share your Google Workspace logs with Google Cloud, Event Threat Detection monitors your logging streams for new members added to your organization's Google Groups. Because the logs are at the organization level, Event Threat Detection can scan Google Workspace logs only when you activate Security Command Center at the organization level. Event Threat Detection can't scan these logs when you activate Security Command Center at the project level.

Event Threat Detection identifies external group members and, using Cloud Audit Logs, reviews each affected group's IAM roles to check whether the groups are granted sensitive roles. That information is used to detect the following unsafe changes for privileged Google Groups:

• External group members added to privileged groups
• Sensitive roles or permissions granted to groups with external group members
• Privileged groups that are changed to allow anyone in the general public to join

Event Threat Detection writes findings to Security Command Center. Findings contain the email addresses of newly added external members, internal group members that initiate events, group names, and the sensitive roles associated with groups. You can use the information to remove external members from groups or revoke sensitive roles granted to groups.

For more information on Event Threat Detection findings, see Event Threat Detection rules .

Sensitive IAM roles and permissions

This section explains how Event Threat Detection defines sensitive IAM roles. Detections like IAM Anomalous Grant and Unsafe Google Group changes generate findings only if changes involve high- or medium-sensitivity roles. The sensitivity of roles impacts the severity rating assigned to findings.

• High-sensitivity roles control critical services in organizations, including billing, firewall settings, and logging. Findings that match these roles are classified as Highseverity.
• Medium-sensitivity roles have editing permissions that let principals make changes to Google Cloud resources; and viewing and executing permissions on data storage services that often hold sensitive data. The severity assigned to findings depends on the resource:
  • If medium-sensitivity roles are granted at the organization level, findings are classified as Highseverity.
  • If medium-sensitivity roles are granted at lower levels in your resource hierarchy (folders, projects, and buckets, among others), findings are classified as Mediumseverity.

Granting these sensitive roles is considered dangerous if the grantee is an External Member or an abnormal identity, like a principal that has been inactive for a long time.

Granting sensitive roles to external members creates a potential threat because they can be abused for account compromise and data exfiltration.

Finding categories that use these sensitive roles include:

• Persistence: IAM Anomalous Grant
  • Subrule: external_service_account_added_to_policy
  • Subrule: external_member_added_to_policy
• Privilege Escalation: Sensitive Role Granted To Hybrid Group
• Privilege Escalation: Dormant Service Account Granted Sensitive Role

Finding categories that use a subset of the sensitive roles include:

• Persistence: IAM Anomalous Grant
  • Subrule: service_account_granted_sensitive_role_to_member

The service_account_granted_sensitive_role_to_member subrule targets both external and internal members generally and therefore uses only a subset of sensitive roles, as explained in Event Threat Detection rules .

Log types and activation requirements

This section lists the logs that Event Threat Detection uses, along with the threats that Event Threat Detection looks for in each log, and what, if anything, you need to do to turn on each log.

You need to turn a log on for Event Threat Detection only if all of the following are true:

• You are using the product or service that writes to the log.
• You need to protect the product or service against the threats that Event Threat Detection detects in the log.
• The log is a data access audit log or other log that is off by default.

Certain threats can be detected in multiple logs. If Event Threat Detection can detect a threat in a log that is already turned on, you don't need to turn on another log to detect that same threat.

If a log isn't listed in this section, Event Threat Detection does not scan it, even if it is turned on. For more information, see Potentially redundant log scans .

As described in the following table , some log types are only available at the organization level. If you activate Security Command Center at the project level, Event Threat Detection doesn't scan these logs and doesn't produce any findings.

Foundational log sources

Event Threat Detection uses foundational data sources to detect potentially malicious activities in your network.

• If you enable Event Threat Detection without VPC Flow Logs, Event Threat Detection immediately starts analyzing an independent, duplicate, and internal stream of VPC Flow Logs. To further investigate an existing Event Threat Detection finding, you need to enable VPC Flow Logs and manually navigate to Logs Explorer and Flow Analyzer. If you enable VPC Flow Logs at a later date, only future findings will contain the relevant links for further investigation.

• If you enable Event Threat Detection with VPC Flow Logs, Event Threat Detection immediately starts analyzing the VPC Flow Logs in your deployment and provides links to Logs Explorer and Flow Analyzer to help you investigate further.

Logs for network detection of malware

Event Threat Detection can provide network detection of malware by scanning any one of the following logs:

• Cloud DNS logging
• Cloud NAT logging
• Firewall Rules Logging
• VPC Flow Logs

You don't need to enable more than one of Cloud NAT logging, Firewall Rules Logging, or VPC Flow Logs.

If you are already using Cloud DNS logging, Event Threat Detection can detect malware using domain resolution. For most users, the Cloud DNS logs are sufficient for the network detection of malware.

If you need another level of visibility beyond domain resolution, you can turn on VPC Flow Logs, but VPC Flow Logs can incur costs. To manage these costs, we recommend increasing the aggregation interval to 15 minutes and reducing the sample rate to between 5% and 10%, but there is a tradeoff between recall (higher sample) and cost management (lower sample rate). For more information, see Log sampling and processing .

If you are already using Firewall Rules Logging or Cloud NAT logging, these logs are useful in place of VPC Flow Logs.

Supported log data and threats detected

This section lists the Cloud Logging and Google Workspace logs that you can turn on or otherwise configure to increase the number of threats that Event Threat Detection can detect.

Certain threats, such as threats posed by the anomalous impersonation or delegation of a service account, can be found in most audit logs. For these types of threats, you determine which logs you need to turn on based on the products and services you are using.

The following table shows specific logs you can enable and the type of threats that can be detected.

Logs that are always on

The following table lists the Cloud Logging logs that you don't need to turn on or configure. These logs are always on and Event Threat Detection scans them automatically.

What's next

• Learn about using Event Threat Detection .
• Learn how to investigate and develop response plans for threats.