TLDR: Panther now offers coverage of Google Cloud Platform (GCP) event logs and 3rd party logs transported via GCP. With the addition of GCP Publish/Subscribe messaging as a data transport type, security teams can simultaneously ingest, normalize, enrich, detect, and respond to potential security threats across all GCP and non-GCP logs.
With the growing adoption of Google Cloud Technologies, security knowledge of these resources has become essential for organizations. Panther is now positioned to provide threat detection & response to all GCP customers with integrations of Google Cloud Storage (GCS), Google Workspace, and Publish/Subscribe Messaging (Pub/Sub) to analyze Google Audit Logs and transport other security data into a Security Information and Event Management tool.
In this article, we’ll explore the capabilities of these respective GCP services and how collaborating with each source with a centralized SIEM can create holistic protection for your environment.
As security is a shared responsibility of the organization and cloud provider, security use cases are essential to understand how to create a robust cloud security model in GCP. Although logs can be analyzed with in-house or Google products, security data is better monitored with a SIEM tool that ingests all security-relevant logs. However, many SIEM tools lack the scale and power to ingest vast amounts of cloud data and transform it into helpful information for a security team’s analysis. Contrary to legacy SIEM, Panther provides a serverless architecture that requires zero operational overhead management or cost.
The ingestion engine parses, normalizes, and enriches incoming data and directly applies it to a detection engine that runs the real-time analysis. Practitioners can apply pre-built or custom Python detections with the detection engine. Let’s dive deeper into a specific use case.
Let’s take an example of an intruder looking to access an organization’s Google environment. Based on the MITRE ATT&CK Framework, we can follow familiar kill chains and begin mapping how we can use Panther to provide detections for our GCP stack. First, the attacker will gain initial access by obtaining credentials. This can be done using phishing or brute force attack. The intruder attempts to brute force an IT admin with G-Workspaces and GCP account credentials, hoping they’re similar logins. To combat this initial attempt for access, Panther provides a Brute Force Attack Detection that is automatically associated G-Workspaces coverage and can easily be added to GCP.Audit.Logs by using the pre-built data model. Simply clone the existing detection in the Panther console and add the GCP.AuditLog source into the Log Types included.
Once applied, the detection will monitor both data sources as logs are ingested. Although this initial detection is a great start, it’s not fault-proof. Therefore, let’s further our example and assume the intruder obtained GCP credentials and could log into the system. They then realize the IT admin’s credentials are at the lowest level of IAM privileges and will need to be escalated to access critical infrastructure.
A pre-built Panther detection specific to GCP IAM Role Changes can be automatically activated when GCP is integrated. This will monitor for role creation, updates, or deletes of admin roles within the GCP console. If the intruder were to attempt a privileged escalation, an alert would trigger. Alerting you to the first sign of a lateral move.
Now, as a security analyst, you know these two detections are extremely helpful and provide instant peace of mind. However, if an alert is fired from either, you’d want to verify the authenticity of a potential threat. You can do this in two ways with Panther:
An indicator search allows you to search common IoCs simultaneously across all log types. Analysts can match IPs or account names with rule matches across all log types at once like so:
This shows that a suspicious IP that triggered the original alert in one week also triggered other alerts within GCP and GWorkspaces. If we drill down into the rule matches, we see that the user has been triggering rules that map to the lateral movement kill chain. Gaining this information, an analyst can investigate the intrusion, having already validated the authenticity of the alerts.
The other method of investigation is to use a scheduled query to determine if the same user has triggered both alerts within a specific timeframe. In this method, we write a SQL query and set it to run every 24 hours. Panther’s normalization engine allows us to leverage p-fields within the query. Providing a standardized field for all log types ingested into the platform. Below is a sample query from Panther, but you can also use our query builder feature without SQL.
SELECT
gcp_auditlog.p_rule_id,
gcp_auditlog.p_any_ip_addresses
FROM
panther_rule_matches.public.gcp_auditlog
JOIN panther_rule_matches.public.gsuite_reports
ON gcp_auditlog.p_any_ip_addresses = gsuite_reports.p_any_ip_addresses
WHERE
gcp_auditlog.p_rule_id IN (
'Standard.BruteForceByIP', 'GCP.IAM.CustomRoleChanges'
)
AND p_occurs_since('1 day', gcp_auditlog)
ORDER BY p_any_ip_addressesCode language: SQL (Structured Query Language) (sql)The query pulls the fields “p_rule_id” and “p_any_ip_addresses” and matches them to the rules: Brute Force by IP and GCP IAM Role Change. We can then list all IPs and match if the same IP has triggered both alerts within the last 24 hours. Using this information, an analyst can cross-reference the matching fields and quickly identify the IP address triggering both alerts within a small window of time.
Panther continues to iterate and expand its coverage of Google Cloud services. Features currently available are:
With Panther’s ability to provide instant ingestion, build out-of-the-box detection packs, and alert details, security teams can get initial coverage of their Google Cloud stack in under 30 minutes.
