Google Cloud Platform (GCP) is one of the leading cloud infrastructure providers in the world. Hundreds of organizations use GCP to run their critical applications and workloads. It is paramount for security practitioners to monitor GCP resources to detect unusual activities and take proactive action to prevent threats from turning into incidents. As a first step, security practitioners should familiarize themselves with the GCP log sources that will enable them to detect security events.
Google Cloud Audit Logs record a trail that practitioners can use to monitor access and detect potential threats across GCP resources (e.g., buckets, service accounts, virtual machines, databases, and data warehouses). With this information, practitioners can turn data into valuable security findings such as compromised accounts, misconfigured infrastructure, or misused computing power. At the end of this document, you’ll learn how to:
Cloud audit logs keep a record of everything that is occurring within your GCP resources. The cloud audit logs tell you who did it, when they did it, and where it occurred. There are three different types of audit logs in GCP:
The most frequently used of the three are Admin activity logs. These logs record administrative changes in cloud resources such as Google Cloud Storage (GCS), Compute Engine (GCE), PubSub, and more. An event can be generated when a resource is created, modified, or updated. You can access any of these logs by going into the Logs Explorer within your GCP console.
Data Access Logs tell you the “who” about your data within a GCP resource such as Big Query. Meaning that when a user manipulates data within the Big Query data warehouse, data access logs will track who made the change. It’s important to note that data access logs are not turned on by default for cloud resources except for Big Query. Google recommends that these logs be activated as much as possible, as it provides higher visibility for a security team as well as Google’s support team. However, to keep ingestion costs down, we recommend turning on data access logs on critical applications or storage buckets with highly sensitive data.
The final type of audit log is the Access Transparency Logs, which allows companies to see when Google makes modifications to their overall cloud environment and shows why Google accessed a specific cloud resource. This is primarily used to track if Google is meeting its contractual obligations to customers as well as servicing resources when necessary.
Although GCP cloud audit logs provide valuable information, finding key insights can be a daunting task due to their prolific nature. When combined with a modern Security Information and Events Management (SIEM) such as Panther, GCP cloud audit logs can be analyzed in real-time allowing for immediate alerting and fast investigation of historical events. Panther does this by automatically normalizing the unstructured raw logs into structured data to store in Snowflake, as well as enriching events with standardized fields that can be searchable across all log types.
Security teams can leverage over 300+ detections that Panther provides out-of-the-box, as soon as logs are ingested into the platform. Some examples of these detections are:
Below are examples of different types of common attack tactics and how these detections can help a team right away.
Let’s say an attacker is attempting to spin up a GCP instance in your environment in order to steal server power for crypto mining. First off, the attacker would attempt to compromise a user account with brute force or a phishing email. Once credentials are stolen, knowing the company operates out of GCP region us-west-1a, the attacker may silently spin up resources in asia-southeast-1 where the organization isn’t monitoring actions. The attacker can then utilize the compute to mine crypto while charging each instance back to the business.
Panther provides two solutions for this example. First, Panther utilizes a Brute Force by IP detection that can be applied to all log sources (not just GCP cloud audit logs) to monitor for multiple authentication attempts within a small window of time. This monitors one specific type of attack that can prevent a hacker from gaining a foothold in GCP.
Sample of Brute Force by IP Rule – Full Detection Code Here
def rule(event):
# filter events on unified data model field
return event.udm("event_type") == event_type.FAILED_LOGINCode language: Python (python)The second solution is a Panther detection that tracks if any users spin up GCP resources from cloud regions an organization isn’t operating in. This rule is specific to cover the unused/unsupported cloud regions technique under the defensive evasion tactics, in the MITRE ATT&CK framework.
Real-Time Panther Rule: GCP Resources in regions – Full Detection Code Here
def rule(event):
method_name = deep_get(event, "protoPayload", "methodName")
if not (method_name.endswith(".insert") or method_name.endswith(".create")):
return False
return _resource_in_active_region(_get_location_or_zone(event))Code language: Python (python)Some companies may store sensitive customer data within GCS buckets. Therefore, a common tactic to collect sensitive data is to search for vulnerable Identity Access Management (IAM) credentials in the organization. IAM changes that could be alarming are multiple permission changes by one user in a short amount of time or role changes to groups organization keeps off limits.
As part of Panther’s out-of-the-box detections, security teams can monitor GCS bucket IAM permission changes to validate that the change was safe.
Detection to monitor IAM role changes for GCS – Full Detection Code Here
def rule(event):
return (
deep_get(event, "resource", "type") == "gcs_bucket"
and deep_get(event, "protoPayload", "methodName") == "storage.setIamPermissions"
)Code language: Python (python)Although this monitoring is immediately available from Panther, organizations could receive a lot of alerts if they utilize a wide variety of GCS buckets. A smart way to use this detection in Panther is to apply it as a Scheduled Rule to a Scheduled Query of GCP cloud audit logs. Security engineers can use SQL to pull historical logs from the Panther’s data lake (powered by Snowflake) and apply specific detections to the small subset of data.
For this example, an engineer can run the following query to see if any IAM permissions changes have happened in GCS over the last 24 hours.
SQL query to monitor IAM role changes in GCS in a 24 hour period
select protoPayload, resource:type, protoPayload:methodName
from panther_logs.public.gcp_auditlog
WHERE p_occurs_between('2022-07-17 16:41:20Z','2022-07-18 16:44:26Z')Code language: SQL (Structured Query Language) (sql)The query can also be manipulated to only return users with multiple matches in order to track if one user changed IAM permissions in a GCS bucket several times in an hour. This scoped data can allow a high severity detection to fire if a result is found, making the team have a higher fidelity alert.
This is just one of the many creative ways security teams can use Panther for real-time monitoring and insightful historical analysis.
In addition to GCP, Panther can analyze log data from hundreds of systems including AWS, 1Password, O365, G Suite, Crowdstrike, OSquery, and more. You can check out a list of all our supported integrations here. Get started today and contact us for a demo.
