Automate Security on GCP with Event Threat Detection

Automate Security on GCP with Event Threat Detection

Automate Security on GCP with Event Threat Detection


In this article, we will cover how to automate an Event Threat Detection finding that is focused on IAM Anomalous grants. This specific event is defined as: “Detection of privileges granted to Cloud Identity and Access Management (Cloud IAM) users and service accounts that are not members of the organization”. Leveraging automation for security in the cloud has amazing benefits including sub-second resolutions, removal of human error (no console clicking!), robust logging for postmortems, and much more. This is a completely serverless, event driven security solution. All of the code is open sourced and available for your immediate deployment here*.

* Find a bug or want to make an improvement? Feel free to create an issue or a Pull Request.


In order to deploy this solution, there are a couple of prerequisites needed.

The following APIs need to be turned on. For information about enabling services, visit the official documentation.

  • Cloud Resource Manager

  • Cloud Functions

  • Cloud Storage (enabled by default)

  • Event Threat Detection

  • Identity and Access Management (IAM)

A service account is needed to deploy the Terraform code with the following permissions. For information about creating a GCP Service Account, visit the official documentation.

At the organization level:

  • Organization Role Administrator

  • Logs Configuration Writer

  • Organization Administrator

At the project level:

  • Pub/Sub Admin

  • Cloud Functions Admin

  • Storage Admin

  • Service Account Admin

  • Service Account User

Solution Overview

In this section, we will breakdown how each of the below services interact to remediate an Event Threat Detection (ETD) security finding.

Event Driven Remediation Flow

Event Driven Remediation Flow (click to enlarge)

Event Threat Detection (Beta)

Event Threat Detection (ETD) is a security service in GCP that continuously monitors logs for suspicious activity and has a built in ruleset for different finding categories. This blog is focused on auto-remediation for the rule IAM: Anomalous grant. An Anomalous Grant finding is triggered when an IAM member is created outside of the organization’s domain. To test this solution, we will create a member with an email address and assign the role “Project Editor”. ETD uses Google’s own threat intelligence and can send its findings to Cloud Logging as well as the Security Command Center.

Once the Event Threat Detection API is enabled, there are a couple of configuration changes required. ETD is not currently supported in Terraform so these updates must be made manually.

  • Verify the rule for “IAM Anomalous Grant” is enabled.
Verify the rule for “IAM Anomalous Grant” is enabled
  • Include all current and future projects for the sources.
Include all current and future projects for the sources
  • Turn on “Log Findings to Stackdriver” and select a project to send findings.
Verify the rule for “Turn on “Log Findings to Stackdriver” and select a project to send findings

Cloud Logging

Cloud Logging (previously known as Stackdriver Logging) is GCP’s native logging and monitoring solution that ETD analyzes for suspicious activity. When ETD has a finding, it can send the finding to Cloud Logging which can then export the finding from Cloud Logging to Cloud Pub/Sub.

Aggregated Log Sink

The aggregated log sink is used to export the ETD findings from Cloud Logging to Cloud Pub/Sub. The sink is deployed on the Organization level and covers all projects in the organization. A specific filter is applied to the log sink to only capture and export the logs we intend to act on. The Terraform code is below.

  • destination is configured to send the logs to a Cloud Pub/Sub topic

  • filter is a variable which will only export the logs specified

  • include_children configures the aggregated sink to also apply to child GCP projects under the organization

  • org_sink_filter is the variable for the aggregated log sink

  • The variable will only capture the IAM: Anomalous grant findings:

Cloud Pub/Sub

Cloud Pub/Sub is key in our automation flow because it ties together all the services and facilitates the event driven remediation. Logs that are sent to Cloud Pub/Sub can be sent to numerous places, but in our flow, we are sending the logs to a Cloud Function via a trigger. When the Cloud Function is deployed, it will configure a trigger on the Pub/Sub topic to automatically kick off its code to remediate a finding when one occurs.

  • This Terraform code creates the Cloud Pub/Sub topic and the Cloud Function code will create the trigger tying them together.

Cloud Functions

Cloud Functions is a serverless compute platform that will run code in many different runtimes. In this event driven flow, Python 3.7 is the runtime of choice and will automatically remediate the IAM: Anomalous grant finding from ETD. The remediation steps are broken down below, but the end result is that all suspicious IAM members that were added to the project or organization are removed. Additionally, the Cloud Function leverages a custom service account that is using only the minimum required permissions.

Let’s first take a look at the Terraform code used to deploy the Cloud Function.

  • source_archive_bucket and source_archive_object are where the Cloud Function’s code is uploaded

  • entry_point is the main function that processes the Cloud Pub/Sub message

  • event_trigger is where the Cloud Function subscribes to the Cloud Pub/Sub topic

Now, let’s take a look at the python that makes up the Cloud Function.

  • First, it’s important to decode the Cloud Pub/Sub message from base64 to JSON and establish our service connection information to Google’s API. Converting the message to JSON allows us to more easily interact with the incoming data.
  • Before we progress further, we need to find all of the IAM Anomalous members that were created.
  • Once we have the IAM members, we check to verify that the IAM member(s) that triggered the Event Threat Detection finding still exists.
  • Now that we know if the user exists, we proceed based on whether the IAM member was bound on the organization or the project level.

Deployment and Testing

Deploying and testing this solution is fairly straightforward if you have an organization and a project in GCP.

To deploy this solution:

  1. Clone the Repository locally.
git clone

2. Change directory into the newly cloned repository.

cd gcp_threat_detection_auto_remediation

3. Create a terraform.tfvars file — Replace the values before running the below command:

cat > terraform.tfvars <<EOF

org_id = “<<replace with your org id>>”

project = “<<replace with your project id>>”


4. Authenticate your Google Cloud Service Account in one of ways defined in the Terraform documentation. This is required due to issue #5288.

gcloud auth activate-service-account


5. Run the following Terraform commands:

terraform init
terraform plan
terraform apply

To test the solution:

  • Add a IAM member to your project with the role Project Editor.

  • Refresh the IAM page and the previously added IAM member should be removed.

  • Navigate to the Cloud Functions page in the Cloud Console and select the function deployed via Terraform.

  • Click the ‘View Logs’ Button to view the outputs of the function.


This event driven security remediation flow will remediate the ETD IAM: Anomalous grant finding in around one second depending on the number of IAM members in your organization. The entire architecture is controlled via code and can be stored in GitHub or your code repository of choice to take full advantage of all the benefits of a CI/CD pipeline. If you’d like to deploy this solution yourself, you can find all of the code here.

The information presented in this article is accurate as of April 9, 2020. Follow the ScaleSec blog for new articles and updates.

About ScaleSec

ScaleSec is a service-disabled, veteran-owned small business (SDVOSB) for cloud security and compliance that helps innovators meet the requirements of their most scrutinizing customers. We specialize in cloud security engineering and cloud compliance. Our team of experts guides customers through complex cloud security challenges, from foundations to implementation, audit preparation and beyond.

Get in touch!

OpenVPN Integration with GSuite

ScaleSec is working from home during the COVID-19 pandemic. To help our employees traverse the internet securely, we offer an easy-to-use Virtual Private Network (VPN) system.

Next article

ScaleSec is a Cloud Security Alliance Member.
ScaleSec is a Cloud Security Alliance Trusted Cloud Consultant.
ScaleSec is a Better Business Bureau® Accredited Business.
ScaleSec is a PCI Security Standards Council Participating Organization.
ScaleSec is a service-disabled, veteran-owned small business (SDVOSB) for cloud security.
ScaleSec is a certified Veteran’s Business Enterprise™ (VBE) from the National Veteran Owned Business Association.

Here for you

Have questions? Leverage our expertise to help you meet your business goals with a strong security posture.

Join us

ScaleSec is a well-connected, fully remote team. We thrive in the great undocumented beyond. We’re hiring in most US metros.

Get in touch

Considering cloud? Want to optimize and transform your existing digital portfolio?
Reach out to us.

Gap Assessment

Get perspective. Address security comprehensively.

Prepare for compliance.

San Diego, CA 92120, United States


© 2023 ScaleSec. All rights reserved. | Privacy Policy