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 Functions.
If you activate Security Command Center Premium tier at the organization level, you can additionally use Chronicle to investigate some findings. Chronicle 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 Chronicle, see Investigate findings in Chronicle.
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 Activity audit logs are always written; you can't configure or disable them.
Event Threat Detection includes the following default rules:
Display name | API name | Log source types | Description |
---|---|---|---|
Active Scan: Log4j Vulnerable to RCE | Unavailable |
Cloud DNS logs Note: You must enable Cloud DNS logging to use this rule. |
Detects active Log4j vulnerabilities by identifying DNS queries for unobfuscated domains that were initiated by supported Log4j vulnerability scanners. |
Brute force SSH | BRUTE_FORCE_SSH |
authlog | Detection of successful brute force of SSH on a host. |
Credential Access: External Member Added To Privileged Group |
EXTERNAL_MEMBER_ADDED_TO_PRIVILEGED_GROUP |
Google Workspace Logs: Login Audit Permissions: DATA_READ
|
Detects events where an external member is added to a privileged Google Group (a group granted sensitive roles or permissions). A finding is generated only if the group doesn't already contain other external members from the same organization as the newly added member. To learn more, see Unsafe Google Group changes. Findings are classified as High or Medium severity, depending on the sensitivity of the roles associated with the group change. For more information, see Sensitive IAM roles and permissions. This finding isn't available for project-level activations. |
Credential Access: Privileged Group Opened To Public |
PRIVILEGED_GROUP_OPENED_TO_PUBLIC |
Google Workspace: Admin Audit Permissions: DATA_READ
|
Detects events where a privileged Google Group (a group granted sensitive roles or permissions) is changed to be accessible to the general public. To learn more, see Unsafe Google Group changes. Findings are classified as High or Medium severity, depending on the sensitivity of the roles associated with the group change. For more information, see Sensitive IAM roles and permissions. This finding isn't available for project-level activations. |
Credential Access: Sensitive Role Granted To Hybrid Group |
SENSITIVE_ROLE_TO_GROUP_WITH_EXTERNAL_MEMBER
|
Cloud Audit Logs: Admin Activity logs |
Detects events where sensitive roles are granted to a Google Group with external members. To learn more, see Unsafe Google Group changes. Findings are classified as High or Medium severity, depending on the sensitivity of the roles associated with the group change. For more information, see Sensitive IAM roles and permissions. This finding isn't available for project-level activations. |
Defense Evasion: Breakglass Workload Deployment CreatedPreview | BINARY_AUTHORIZATION_BREAKGLASS_WORKLOAD_CREATE |
Cloud Audit Logs: Admin Activity logs |
Detects the deployment of workloads that are deployed by using the break-glass flag to override Binary Authorization controls. |
Defense Evasion: Breakglass Workload Deployment UpdatedPreview | BINARY_AUTHORIZATION_BREAKGLASS_WORKLOAD_UPDATE |
Cloud Audit Logs: Admin Activity logs |
Detects when workloads are updated by using the break-glass flag to override Binary Authorization controls. |
Defense Evasion: Modify VPC Service Control | DEFENSE_EVASION_MODIFY_VPC_SERVICE_CONTROL |
Cloud Audit Logs VPC Service Controls audit logs | Detects a change to an existing VPC Service Controls perimeter that
would lead to a reduction in the protection offered by that
perimeter. This finding isn't available for project-level activations. |
Discovery: Can get sensitive Kubernetes object check | GKE_CONTROL_PLANE_CAN_GET_SENSITIVE_OBJECT |
Cloud Audit Logs: GKE data access logs |
A potentially malicious actor attempted to determine what sensitive objects in
GKE they can query for, by using the
|
Discovery: Service Account Self-Investigation | SERVICE_ACCOUNT_SELF_INVESTIGATION |
Cloud Audit Logs: Resource Manager data access logs Permissions: DATA_READ
|
Detection of an IAM service account credential that is used to investigate the roles and permissions associated with that same service account. Sensitive roles Findings are classified as High or Medium severity, depending on the sensitivity of the roles granted. For more information, see Sensitive IAM roles and permissions. |
Evasion: Access from Anonymizing Proxy | ANOMALOUS_ACCESS |
Cloud Audit Logs: Admin Activity logs |
Detection of Google Cloud service modifications that originated from anonymous proxy IP addresses, like Tor IP addresses. |
Exfiltration: BigQuery Data Exfiltration | DATA_EXFILTRATION_BIG_QUERY |
Cloud Audit Logs:
BigQueryAuditMetadata data access logs Permissions: DATA_READ
|
Detects the following scenarios:
|
Exfiltration: BigQuery Data Extraction | DATA_EXFILTRATION_BIG_QUERY_EXTRACTION |
Cloud Audit Logs:
BigQueryAuditMetadata data access logs Permissions: DATA_READ
|
Detects the following scenarios:
For project-level activations of the Security Command Center Premium tier, this finding is available only if the Standard tier is enabled in the parent organization. |
Exfiltration: BigQuery Data to Google Drive | DATA_EXFILTRATION_BIG_QUERY_TO_GOOGLE_DRIVE |
Cloud Audit Logs:
BigQueryAuditMetadata data access logs Permissions: DATA_READ
|
Detects the following:
|
Exfiltration: Cloud SQL Data Exfiltration |
CLOUDSQL_EXFIL_EXPORT_TO_EXTERNAL_GCS |
Cloud Audit Logs:
MySQL data access logs PostgreSQL data access logs SQL Server data access logs |
Detects the following scenarios:
For project-level activations of the Security Command Center Premium tier, this finding is available only if the Standard tier is enabled in the parent organization. |
Exfiltration: Cloud SQL Restore Backup to External Organization | CLOUDSQL_EXFIL_RESTORE_BACKUP_TO_EXTERNAL_INSTANCE |
Cloud Audit Logs:
MySQL admin activity logs PostgreSQL admin activity logs SQL Server admin activity logs |
Detects events where the backup of a Cloud SQL instance is restored to an instance outside of the organization. |
Exfiltration: Cloud SQL Over-Privileged Grant | CLOUDSQL_EXFIL_USER_GRANTED_ALL_PERMISSIONS |
Cloud Audit Logs:
PostgreSQL data access logs Note: You must enable the pgAudit extension to use this rule. |
Detects events where a Cloud SQL for PostgreSQL user or role has been granted all privileges to a database, or to all tables, procedures, or functions in a schema. |
Initial Access: Database Superuser Writes to User Tables | CLOUDSQL_SUPERUSER_WRITES_TO_USER_TABLES |
Cloud Audit Logs:
Cloud SQL for PostgreSQL data access logs Cloud SQL for MySQL data access logs Note: You must enable the pgAudit extension for PostgreSQL or database auditing for MySQL to use this rule. |
Detects events where a Cloud SQL superuser ( |
Initial Access: Dormant Service Account ActionPreview | DORMANT_SERVICE_ACCOUNT_USED_IN_ACTION |
Cloud Audit Logs: Admin Activity logs |
Detects events where a dormant user-managed service account triggered an action. In this context, a service account is considered dormant if it has been inactive for more than 180 days. |
Privilege Escalation: Dormant Service Account Granted Sensitive RolePreview | DORMANT_SERVICE_ACCOUNT_ADDED_IN_IAM_ROLE |
Cloud Audit Logs: Admin Activity logs |
Detects events where a dormant user-managed service account was granted one or more sensitive IAM roles. In this context, a service account is considered dormant if it has been inactive for more than 180 days. Sensitive roles Findings are classified as High or Medium severity, depending on the sensitivity of the roles granted. For more information, see Sensitive IAM roles and permissions. |
Persistence: Impersonation Role Granted For Dormant Service AccountPreview | DORMANT_SERVICE_ACCOUNT_IMPERSONATION_ROLE_GRANTED |
Cloud Audit Logs: Admin Activity logs |
Detects events where a principal is granted permissions to impersonate a dormant user-managed service account. In this context, a service account is considered dormant if it has been inactive for more than 180 days. |
Initial Access: Dormant Service Account Key CreatedPreview | DORMANT_SERVICE_ACCOUNT_KEY_CREATED |
Cloud Audit Logs: Admin Activity logs |
Detects events where a key is created for a dormant user-managed service account. In this context, a service account is considered dormant if it has been inactive for more than 180 days. |
Initial Access: Excessive Permission Denied Actions | EXCESSIVE_FAILED_ATTEMPT |
Cloud Audit Logs: Admin Activity logs |
Detects events where a principal repeatedly triggers permission denied errors by attempting changes across multiple methods and services. |
Impair Defenses: Strong Authentication Disabled |
ENFORCE_STRONG_AUTHENTICATION |
Google Workspace: Admin Audit |
2-step verification was disabled for the organization. This finding isn't available for project-level activations. |
Impair Defenses: Two Step Verification Disabled |
2SV_DISABLE |
Google Workspace Logs: Login Audit Permissions: DATA_READ
|
A user disabled 2-step verification. This finding isn't available for project-level activations. |
Initial Access: Account Disabled Hijacked |
ACCOUNT_DISABLED_HIJACKED |
Google Workspace Logs: Login Audit Permissions: DATA_READ
|
A user's account was suspended due to suspicious activity. This finding isn't available for project-level activations. |
Initial Access: Disabled Password Leak |
ACCOUNT_DISABLED_PASSWORD_LEAK |
Google Workspace Logs: Login Audit Permissions: DATA_READ
|
A user's account is disabled because a password leak was detected. This finding isn't available for project-level activations. |
Initial Access: Government Based Attack |
GOV_ATTACK_WARNING |
Google Workspace Logs: Login Audit Permissions: DATA_READ
|
Government-backed attackers might have tried to compromise a user account or computer. This finding isn't available for project-level activations. |
Initial Access: Log4j Compromise Attempt | Unavailable | Cloud Load Balancing Logs: Cloud HTTP Load Balancer Note: You must enable external HTTP(S) load balancer logging to use this rule. |
Detects Java Naming and Directory Interface (JNDI)
lookups
within headers
or URL parameters. These lookups may indicate attempts at Log4Shell exploitation.
These findings have low severity, because they only indicate a detection
or exploit attempt, not a vulnerability or a compromise. This rule is always on. |
Initial Access: Suspicious Login Blocked |
SUSPICIOUS_LOGIN |
Google Workspace Logs: Login Audit Permissions: DATA_READ
|
A suspicious login to a user's account was detected and blocked. This finding isn't available for project-level activations. |
Log4j Malware: Bad Domain | LOG4J_BAD_DOMAIN |
Cloud DNS Logs: Admin Activity logs |
Detection of Log4j exploit traffic based on a connection to, or a lookup of, a known domain used in Log4j attacks. |
Log4j Malware: Bad IP | LOG4J_BAD_IP |
VPC flow logs Firewall Rules logs Cloud NAT logs |
Detection of Log4j exploit traffic based on a connection to a known IP address used in Log4j attacks. |
Malware: bad domain | MALWARE_BAD_DOMAIN |
Cloud DNS Logs: Admin Activity log |
Detection of malware based on a connection to, or a lookup of, a known bad domain. |
Malware: bad IP | MALWARE_BAD_IP |
VPC flow logs Firewall Rules logs Cloud NAT logs |
Detection of malware based on a connection to a known bad IP address. |
Malware: Cryptomining Bad Domain | CRYPTOMINING_POOL_DOMAIN |
Cloud DNS Logs: Admin Activity logs |
Detection of cryptomining based on a connection to, or a lookup of, a known mining domain. |
Malware: Cryptomining Bad IP | CRYPTOMINING_POOL_IP |
VPC flow logs Firewall Rules logs Cloud NAT logs |
Detection of cryptomining based on a connection to a known mining IP address. |
Outgoing DoS | OUTGOING_DOS |
VPC flow logs | Detection of outgoing denial of service traffic. |
Persistence: Compute Engine Admin Added SSH Key | GCE_ADMIN_ADD_SSH_KEY |
Cloud Audit Logs: Admin Activity logs |
Detection of a modification to the Compute Engine instance metadata ssh key value on
an established instance (older than 1 week). |
Persistence: Compute Engine Admin Added Startup Script | GCE_ADMIN_ADD_STARTUP_SCRIPT |
Cloud Audit Logs: Admin Activity logs |
Detection of a modification to the Compute Engine instance metadata startup script value on
an established instance (older than 1 week). |
Persistence: IAM Anomalous Grant | IAM_ANOMALOUS_GRANT |
Cloud Audit Logs: Admin Activity logs |
This finding is unique in that it includes subrules that provide more specific information about each instance of this finding. The following list shows all possible subrules:
|
Persistence: New API Method |
ANOMALOUS_BEHAVIOR_NEW_API_METHOD |
Cloud Audit Logs: Admin Activity logs |
Detection of anomalous usage of Google Cloud services by IAM service accounts. |
Persistence: New Geography |
IAM_ANOMALOUS_BEHAVIOR_IP_GEOLOCATION |
Cloud Audit Logs: Admin Activity logs |
Detection of IAM user and service accounts
accessing Google Cloud from anomalous locations,
based on the geolocation of the requesting IP addresses. This finding isn't available for project-level activations. |
Persistence: New User Agent | IAM_ANOMALOUS_BEHAVIOR_USER_AGENT |
Cloud Audit Logs: Admin Activity logs |
Detection of IAM service accounts accessing
Google Cloud from anomalous or suspicious user agents. This finding isn't available for project-level activations. |
Persistence: SSO Enablement Toggle |
TOGGLE_SSO_ENABLED |
Google Workspace: Admin Audit |
The Enable SSO (single sign-on) setting on the admin account was disabled. This finding isn't available for project-level activations. |
Persistence: SSO Settings Changed |
CHANGE_SSO_SETTINGS |
Google Workspace: Admin Audit |
The SSO settings for the admin account were changed. This finding isn't available for project-level activations. |
Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity | ANOMALOUS_SA_DELEGATION_IMPERSONATION_OF_SA_ADMIN_ACTIVITY |
Cloud Audit Logs: Admin Activity logs |
Detects when a potentially anomalous impersonated service account is used for an administrative activity. |
Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity | ANOMALOUS_SA_DELEGATION_MULTISTEP_ADMIN_ACTIVITY |
Cloud Audit Logs: Admin Activity logs |
Detects when an anomalous multistep delegated request is found for an administrative activity. |
Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access | ANOMALOUS_SA_DELEGATION_MULTISTEP_DATA_ACCESS |
Cloud Audit Logs: Data Access logs |
Detects when an anomalous multistep delegated request is found for a data access activity. |
Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity | ANOMALOUS_SA_DELEGATION_IMPERSONATOR_ADMIN_ACTIVITY |
Cloud Audit Logs: Admin Activity logs |
Detects when a potentially anomalous caller/impersonator in a delegation chain is used for an administrative activity. |
Privilege Escalation: Anomalous Service Account Impersonator for Data Access | ANOMALOUS_SA_DELEGATION_IMPERSONATOR_DATA_ACCESS |
Cloud Audit Logs: Data Access logs |
Detects when a potentially anomalous caller/impersonator in a delegation chain is used for a data access activity. |
Privilege Escalation: Changes to sensitive Kubernetes RBAC objects | GKE_CONTROL_PLANE_EDIT_SENSITIVE_RBAC_OBJECT |
Cloud Audit Logs: Admin Activity logs |
To escalate privilege, a potentially malicious actor attempted to modify a
ClusterRole or ClusterRoleBinding role-based access
control (RBAC) object of the sensitive cluster-admin
role by using a PUT or PATCH request.
|
Privilege Escalation: Create Kubernetes CSR for master cert | GKE_CONTROL_PLANE_CSR_FOR_MASTER_CERT |
Cloud Audit Logs: GKE data access logs |
A potentially malicious actor created a Kubernetes master certificate
signing request (CSR), which gives them cluster-admin
access. |
Privilege Escalation: Creation of sensitive Kubernetes bindings | GKE_CONTROL_PLANE_CREATE_SENSITIVE_BINDING |
Cloud Audit Logs: Admin Activity logs |
To escalate privilege, a potentially malicious actor attempted to create
a new RoleBinding or ClusterRoleBinding object for
the cluster-admin
role.
|
Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials | GKE_CONTROL_PLANE_GET_CSR_WITH_COMPROMISED_BOOTSTRAP_CREDENTIALS |
Cloud Audit Logs: GKE data access logs |
A potentially malicious actor queried for a certificate
signing request (CSR), with the kubectl command, using
compromised bootstrap credentials. |
Privilege Escalation: Launch of privileged Kubernetes container | GKE_CONTROL_PLANE_LAUNCH_PRIVILEGED_CONTAINER |
Cloud Audit Logs: Admin Activity logs |
A potentially malicious actor created a Pod that contains privileged containers or containers with privilege escalation capabilities. A privileged container has the |
To create custom detection rules, 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 High severity.
- 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 High severity.
- If medium-sensitivity roles are granted at lower levels in your resource hierarchy (folders, projects, and buckets, among others), findings are classified as Medium severity.
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
- Subrule:
- Credential Access: 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
- Subrule:
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.
Category | Role | Description |
---|---|---|
Basic roles: contain thousands of permissions across all Google Cloud services. | roles/owner |
Basic roles |
roles/editor |
||
Security roles: control access to security settings | roles/cloudkms.* |
All Cloud Key Management Service roles |
roles/cloudsecurityscanner.* |
All Web Security Scanner roles | |
roles/dlp.* |
All Cloud Data Loss Prevention roles. | |
roles/iam.* |
All IAM roles | |
roles/secretmanager.* |
All Secret Manager roles | |
roles/securitycenter.* |
All Security Command Center roles | |
Logging roles: control access to an organization's logs | roles/errorreporting.* |
All Error Reporting roles |
roles/logging.* |
All Cloud Logging roles | |
roles/stackdriver.* |
All Cloud Monitoring roles | |
Personal information roles: control access to resources that contain personally identifiable information, including banking and contact information | roles/billing.* |
All Cloud Billing roles |
roles/healthcare.* |
All Cloud Healthcare API roles | |
roles/essentialcontacts.* |
All Essential Contacts roles | |
Networking roles: control access to an organization's network settings | roles/dns.* |
All Cloud DNS roles |
roles/domains.* |
All Cloud Domains roles | |
roles/networkconnectivity.* |
All Network Connectivity Center roles | |
roles/networkmanagement.* |
All Network Connectivity Center roles | |
roles/privateca.* |
All Certificate Authority Service roles | |
Service roles: control access to service resources in Google Cloud | roles/cloudasset.* |
All Cloud Asset Inventory roles |
roles/servicedirectory.* |
All Service Directory roles | |
roles/servicemanagement.* |
All Service Management roles | |
roles/servicenetworking.* |
All Service Networking roles | |
roles/serviceusage.* |
All Service Usage roles | |
Compute Engine roles: control access to Compute Engine virtual machines, which carry long-running jobs and are associated with firewall rules |
|
All Compute Engine Admin and Editor roles |
Category | Role | Description |
---|---|---|
Editing roles: IAM roles that include permissions to make changes to Google Cloud resources |
Examples:
|
Role names usually end with titles like Admin,
Owner, Editor, or Writer.
Expand the node in the last row of the table to see All medium-sensitivity roles |
Data storage roles: IAM roles that include permissions to view and execute data storage services |
Examples:
|
Expand the node in the last row of the table to see All medium-sensitivity roles |
All medium-sensitivity roles
Access Approval
Access Context Manager
Actions
AI Platform
API Gateway
App Engine
AutoML
BigQuery
Binary Authorization
Cloud Bigtable
Cloud Build
Cloud Deployment Manager
Cloud Endpoints
Cloud Functions
Cloud IoT
Cloud Life Sciences
Cloud Monitoring
Cloud Run
Cloud Scheduler
Cloud Source Repositories
Cloud Spanner
Cloud Storage
Cloud SQL
Cloud Tasks
Cloud TPU
Cloud Trace
Compute Engine
Container Analysis
Data Catalog
Dataflow
Dataproc
Dataproc Metastore
Datastore
Eventarc
Filestore
Firebase
Game Servers
Google Cloud VMware Engine
Google Kubernetes Engine
Google Kubernetes Engine Hub
Google Workspace
Identity-Aware Proxy
Managed Service for Microsoft Active Directory
Memorystore for Redis
On-Demand Scanning API
Ops Config Monitoring
Organization Policy Service
Other roles
Proximity Beacon
Pub/Sub
Pub/Sub Lite
reCAPTCHA Enterprise
Recommendations AI
Recommender
Resource Manager
Resource Settings
Serverless VPC Access
Service Consumer Management
Storage Transfer Service
Vertex AI
Vertex AI Workbench user-managed notebooks
Workflows |
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.
Potentially redundant log scans
Event Threat Detection can provide network detection of malware by scanning any one of the following logs:
- Cloud DNS Admin Activity audit logs
- Cloud NAT logging
- Firewall Rules Logging
- VPC Flow Logs
If you are already using Cloud DNS, the Cloud DNS Admin Activity audit logs are already on and do not have a generation cost. For most users, the Cloud DNS Admin Activity audit 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).
If you are already using Firewall Rules Logging or Cloud NAT logging, these logs are useful in place of VPC Flow Logs.
You don't need to enable more than one of Cloud NAT logging, Firewall Rules Logging, or VPC Flow Logs.
Logs that you need to turn on
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 need to turn on for threats that can be detected in only certain specific log types.
Log type | Threats detected | Configuration required | |
---|---|---|---|
Cloud DNS Data Access audit logs |
Credential Access: Privileged Group Opened To Public Impair Defenses: Strong Authentication Disabled Impair Defenses: Two Step Verification Disabled Persistence: SSO Enablement Toggle Persistence: SSO Settings Changed |
Activate Logging Data Access audit logs for Cloud DNS | |
Cloud NAT logging |
Log4j Malware: Bad IP Malware: bad IP Malware: Cryptomining Bad IP |
Turn on Cloud NAT logging | |
Firewall Rules Logging |
Log4j Malware: Bad IP Malware: bad IP Malware: Cryptomining Bad IP |
Turn on Firewall Rules Logging. | |
Google Kubernetes Engine (GKE) Data Access audit logs |
Discovery: Can get sensitive Kubernetes object check Privilege Escalation: Create Kubernetes CSR for master cert Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials |
Activate Logging Data Access audit logs for GKE | |
Google Workspace Admin Audit logs |
Credential Access: Privileged Group Opened To Public Impair Defenses: Strong Authentication Disabled Impair Defenses: Two Step Verification Disabled Persistence: SSO Enablement Toggle Persistence: SSO Settings Changed |
Share Google Workspace Admin Audit logs with Cloud Logging
This log type can't be scanned in project-level activations. |
|
Google Workspace Login Audit logs |
Credential Access: External Member Added To Privileged Group Impair Defenses: Two Step Verification Disabled Initial Access: Account Disabled Hijacked Initial Access: Disabled Password Leak Initial Access: Government Based Attack Initial Access: Suspicious Login Blocked< /td>
| Share Google Workspace Login Audit logs with Cloud Logging
This log type can't be scanned in project-level activations. |
|
External HTTP(S) load balancer backend service logs |
Initial Access: Log4j Compromise Attempt |
Turn on external HTTP(S) load balancer logging | |
MySQL Data Access audit logs | Exfiltration: Cloud SQL Data Exfiltration |
Activate Logging Data Access audit logs for Cloud SQL for MySQL | |
PostgreSQL Data Access audit logs |
Exfiltration: Cloud SQL Data Exfiltration Exfiltration: Cloud SQL Over-Privileged Grant |
|
|
Resource Manager Data Access audit logs |
Discovery: Service Account Self-Investigation |
Activate Logging Data Access audit logs for Resource Manager | |
SQL Server Data Access audit logs | Exfiltration: Cloud SQL Data Exfiltration |
Activate Logging Data Access audit logs for Cloud SQL for SQL Server | |
authlogs/authlog on virtual machines | Brute force SSH |
Install the Ops Agent or the legacy Logging agent on your VM hosts | |
VPC Flow Logs |
Log4j Malware: Bad IP Malware: bad IP Malware: Cryptomining Bad IP |
Turn on VPC Flow Logs. |
Logs that are always on
The following table lists the Cloud Logging logs that you do not need to turn on or configure. These logs are always on and Event Threat Detection scans them automatically.
Log type | Threats detected | Configuration required | |
---|---|---|---|
BigQueryAuditMetadata Data Access logs |
Exfiltration: BigQuery Data Exfiltration Exfiltration: BigQuery Data Extraction Exfiltration: BigQuery Data to Google Drive |
None | |
Cloud DNS Admin Activity audit logs | Evasion: Access from Anonymizing Proxy Log4j Malware: Bad Domain Malware: bad domain Malware: Cryptomining Bad Domain |
None | |
Google Kubernetes Engine (GKE) Admin Activity audit logs |
Privilege Escalation: Changes to sensitive Kubernetes RBAC objects Privilege Escalation: Creation of sensitive Kubernetes bindings Privilege Escalation: Launch of privileged Kubernetes container |
None | |
IAM Admin Activity audit logs |
Credential Access: Sensitive Role Granted To Hybrid Group Initial Access: Dormant Service Account ActionPreview Privilege Escalation: Dormant Service Account Granted Sensitive RolePreview Persistence: Impersonation Role Granted For Dormant Service AccountPreview Initial Access: Dormant Service Account Key CreatedPreview Initial Access: Excessive Permission Denied Actions Persistence: Compute Engine Admin Added SSH Key Persistence: Compute Engine Admin Added Startup Script Persistence: IAM Anomalous Grant Persistence: New API Method Persistence: New Geography Persistence: New User Agent |
None | |
MySQL Admin Activity logs | Exfiltration: Cloud SQL Restore Backup to External Organization | None | |
PostgreSQL Admin Activity logs | Exfiltration: Cloud SQL Restore Backup to External Organization | None | |
SQL Server Admin Activity logs | Exfiltration: Cloud SQL Restore Backup to External Organization | None | |
VPC Service Controls Audit logs | Defense Evasion: Modify VPC Service Control | None |
What's next
Learn about using Event Threat Detection.
Learn how to investigate and develop response plans for threats.