Splunk SOAR Playbooks: GCP Unusual Service Account Usage

As organizations increase their cloud footprints, it becomes more and more important to implement access control monitoring for as many resources as possible. In previous playbooks, we have shown examples of AWS and Azure account monitoring, but the series would not be complete without also supporting Google Cloud Platform (GCP). Just like AWS and Azure, GCP is one of those systems where an organization may start off just using one or two components, but over time that usage tends to expand across a wider variety of services and use cases. This makes it particularly important for the security team to monitor how usage is changing over time and to set up alerting mechanisms that will notify the team when unexpected access occurs.

In today’s new Splunk SOAR (formerly known as Splunk Phantom) Community Playbook, we will show how a Splunk Enterprise search can trigger automated enrichment, an analyst prompt, and rapid response actions to prevent damage caused by malicious account access. This use case relies on GCP audit logs ingested into Splunk using Cloud Logging. For details on how to set this up, see our recent blog post, "Elevate Your Cloud SecurityPosture with Splunk and Google Cloud," on the Splunk Enterprise and GCP integration.

Once these logs are streamed to Splunk Enterprise, the security team can start to detect usage of service accounts that does not fit into expected patterns. This could be an API method that should not be executed from a certain account, an instance created in a new region that should not be used, or any other behavior that can be defined based on metadata in the GCP audit log. As expected usage changes over time, one or more searches can be updated to reduce the false positive rate or continue to enforce the principle of least privilege across user accounts and services. By leveraging Splunk SOAR to automatically monitor new accounts and detect malicious conduct within cloud platforms like GCP, you can add another line of defense to prevent threat actors from exfiltrating sensitive information. 

The Detection: GCP Access Monitoring

While there are a wide variety of possible detections that could trigger this use case, one example would be to trigger on potentially destructive API methods executed using the Compute service, such as “stop,” “setMetadata,” or “delete”:

sourcetype="google:gcp:pubsub:message" tag=compute "data.protoPayload.methodName" IN ("*stop", "*setMetadata", "*delete")

| rex field="data.resource.parentDisplayName" ".*\/(?<KeyName>.*)$" 

| rename "data.protoPayload.authenticationInfo.principalEmail" as KeyName 

| transaction KeyName

Note that the transaction is used to group together events with the same key name to prevent the playbook from running multiple times for the same account. To reduce false positives, a lookup file could also be introduced that would exclude specific accounts that are allowed to use these API methods.

The Playbook: GCP Unusual Service Account Usage

Once the search above is scheduled and is producing results, the “Send to Phantom” action or an event forwarding search can be used to automatically forward events to Splunk SOAR. From there, the playbook will check if there is a service account and a Compute VM or just a service account. Metadata about the keys owned by that service account will be gathered using the GCP IAM app, and if there is a Compute VM instance the playbook will gather metadata about that as well. After gathering this data, format blocks are used to compile it into a prompt, and the analyst is asked whether to delete the associated service account keys and stop the Compute instance, if applicable.

See It In Action

Deploying The Playbook

Here are the steps to get this playbook and use it:

1. Splunk Enterprise and Splunk SOAR are both required for this use case. If you don’t already have Splunk SOAR, you can sign up and download the free community version.
2. GCP log ingestion into Splunk Enterprise is also required. Here is a guide to configure a GCP Pub/Sub pipeline into Splunk HEC.
3. Configure Splunk Enterprise to send alerts to Splunk SOAR.
4. Set up the Google Cloud IAM and Google Cloud Compute Engine apps on Splunk SOAR:
   1. Navigate to Home>Apps>Unconfigured Apps>Search for Google Cloud IAM>Configure New Asset.
   2. Give the asset a name such as “google_cloud_iam.
   3. On the Asset Settings page, provide the service account JSON and project ID.
   4. Save and test connectivity to make sure the asset is functional.
   5. Follow similar steps for the Google Cloud Compute Engine app.
5. Synchronize the playbook list with the community repository, then find and activate the GCP Unusual Service Account Usage playbook using the label created for Splunk Enterprise alerts
   
   

Taking It Further

Aside from the particular API methods listed in the SPL search for this detection, there is nothing limiting this detection and response pattern to just the Compute service in GCP. Many of the cloud detections here and here could be used or adapted for this type of use case. In addition to new SPL searches, detections from Google Security Command Center could also be used to trigger Splunk SOAR.

On the response side, the options for expansion include a wide range of options both within GCP and elsewhere in the organization. The main areas to focus on in GCP tend to be service accounts, compute instances, and object storage. Elsewhere in the organization there are opportunities to add threat intelligence integrations, ticket creation, endpoint detection and response workflows, and correlation with identity systems such as Okta or Active Directory. Upcoming community playbooks will expand on this use case with examples of additional post-detection actions.

This blog is part of a series called “SOAR in Seconds,” where our distinguished Splunk SOAR experts guide you through how to use out-of-the-box playbooks and other features to automate repetitive tasks.

Special thanks to Roy Arsan from Google for his indispensable help with this and other use cases!

----------------------------------------------------
Thanks!
Philip Royer