Introducing Community Security Analytics

As more organizations embrace the principles of Autonomic Security Operations, we continue to research and develop new initiatives that can simplify the adoption of a continuous detection and continuous response (CD/CR) workflow for Security Operations teams. To this end, we’re excited to announce Community Security Analytics (CSA), a set of open-sourced queries and rules designed for self-service security analytics to help you detect common cloud-based threats. We believe that fostering a community around standardizing and sharing cloud security analytics across our portfolio of offerings can help improve detective capabilities – giving threat researchers, threat hunters, security analysts, and data governance teams a place to collaborate, while also leveraging our cloud-native threat prevention and detection capabilities by Security Command Center.

Why & when to use CSA?

With Google Cloud, you have a secure foundation which you can directly control and independently audit & verify. This transparency and auditability allows you to verify proper access, and also detect potential threats to your data and workloads early on before it becomes a problem. Google Cloud services leave audit trails, be it administrators’ activity or users data access using Cloud Audit Logs, in addition to VM logs, application/container logs, and network logs, depending on the service. However, analyzing this plethora of voluminous yet valuable logs quickly becomes a data challenge. Assuming you’re already collecting security-relevant logs, there’s still work to be done to understand the activity they describe, and make sense of it all.

Your Security Operations teams can use CSA to get started with analyzing your Google Cloud logs to audit recent behavior and help detect threats to your workloads. We’ve partnered with the MITRE Engenuity’s Center for Threat-Informed Defense, CYDERES (the security-as-a-service division of Fishtech Group), and a variety of contributing customers to develop a sample set of analytics and kick-start the development of the community. Leveraging the collective knowledge of the community, other organizations can use these queries and customize them to their own requirements.

CSA queries are mapped to the MITRE ATT&CK® framework of tactics, techniques and procedures (TTPs) to help you evaluate their applicability in your environment and include them in your threat model coverage. These queries can be run using either cloud-native or third-party analytics tools. The initial CSA release offers detections in the form of YARA-L rules for Chronicle, and SQL queries for BigQuery, with more formats to follow based on community feedback.

You can use CSA to further investigate high-fidelity security findings from Security Command Center (SCC) and correlate them with logs for decision-making. For example, you may use a CSA query to get the list of admin activity performed by a newly created service account key flagged by Security Command Center in order to validate any malicious activity.

It’s important to note that the detection queries provided by CSA will be self-managed and you may need to tune to minimize alert noise. If you’re looking for managed and advanced detections, take a look at SCC Premium’s growing threat detection suite (Container Threat Detection, Event Threat Detection and VM Threat Detection) which provides a list of regularly-updated managed detectors designed to identify threats within your systems in near real-time.

CSA is not meant to be a comprehensive, managed set of threat detections, but a collection of community-contributed sample analytics to give examples of essential detective controls, based on cloud techniques. Use CSA in conjunction with our threat detection and response capabilities (e.g. Security Command Center, Chronicle, BigQuery, Siemplify, or third-party SIEM) in conjunction with our threat prevention capabilities (e.g. Security Command Center, Cloud Armor, BeyondCorp).

Get Started with CSA

We’re releasing CSA with 40+ security use cases reflecting some of the most important questions we think organizations should ask of their logs, inspired by real-world questions we frequently get from organizations. Depending on the underlying activity type and log sources, CSA security questions are grouped in 6 different categories:

1. Login & Access Patterns e.g. Who is accessing resources and from where? Are they impersonating other identities? Any excessive login failures?

2. IAM, Keys & Secrets Changes e.g. Any changes to IAM policies? Any permissions granted over a sensitive service account? Any service account keys created by non-approved identities? Any cross-project or cross-org permissions granted?

3. Cloud Provisioning Activity e.g. Any sensitive network resources modified like Firewall rules or VPN tunnels? Any changes made to logging settings? What about org policies?

4. Cloud Workload Usage e.g. Any unusually high API usage by any user identity? Any excessive runaway costs signaling suspicious activity?

5. Data Usage e.g. What BigQuery datasets and tables are most frequently accessed and by whom? Any destructive queries?

6. Network Activity e.g. Any hosts reaching out to too many other hosts or ports in a given timeframe? Any connections from a new IP to an in-scope network for say PCI? Any web vulnerability exploit attempt?

To get started, browse the table of detections in the repo. Each indexed row is a specific question to help detect a particular cloud security threat, audit cloud usage and data access for compliance, or respond to a security incident. The corresponding use cases (audit, detect, respond) are highlighted in each row, along with the underlying log source, and the corresponding MITRE ATT&CK® technique, whenever applicable. Click on any particular detection to navigate to its doc page where the corresponding SQL query and YARA-L rule is linked, as well as steps to reproduce the triggering event in order to continuously test detection accuracy. Let’s look at an example….

CSA Example: Any excessive login failures from any user?

Take a look at detection #1.03,  “Excessive login failures from any user identity”:

At a glance, you can see this particular detection is based on Google Workspace Login logs, specifically from Cloud Identity which logs users login activity across gcloud CLI, Google Workspace and Cloud Console as well login settings changes like password or 2FA enrollment changes. This question can help you detect if there are any excessive login failures in a given time span (e.g., the last 1hr) which may indicate an initial access or privilege escalation via compromised credentials or a brute force attack.

Click on that detection to learn more about it, and retrieve any available query implementation:

The detection doc page gives an overview of the security use case, along with links to the corresponding YARA-L rule and SQL query which you can run in Chronicle or BigQuery respectively. In the latter case, make sure to change the variables MY_PROJECT_ID and MY_DATASET_ID to match your own.

In addition, for some detections, a log sample is provided as well as steps to re-generate log events in a real-world project and re-trigger the underlying detection. This will be helpful for detection testing, as CSA adopts best practices.

MITRE ATT&CK® Mappings

As part of this launch, we’re thrilled to partner with our friends at the Center for Threat-Informed Defense to map these security questions to the MITRE ATT&CK® TTPs to help you evaluate these questions in the context of ATT&CK Enterprise threat model.

Click here to download the ATT&CK Navigator JSON layer, which you can subsequently load in ATT&CK Navigator homepage by clicking Open Existing Layer then Upload From Local.

What’s Next?

We’re excited to make this growing knowledge base of security analytics for Google Cloud available for everyone to help tip the balance of cybersecurity against adversaries, by providing organizations with a baseline level of security visibility. We look forward to your feedback and contributions from GitHub issues with new use cases suggestions to Pull requests with corresponding analytics be it for BigQuery, Chronicle or your own analytics tools. 

It’s important to remember that these rules and queries are community-sourced, self-managed, and do not have cost estimations or performance guarantees. As we continue to foster more input from community collaborators and partners, we’ll track feedback and work with our active participants on expanding threat coverage and prioritizing improvements to the repository.

By capturing our collective knowledge of cloud threats in this central repository, we’re aiming to drive towards a future where security analytics are no longer developed ad-hoc per organization, but rather – crowdsourced and minimally modified to provide the coverage against the threats our customers face in the cloud. We continue to find new ways to expand initiatives, helping our customers and the broader industry adopt the principles of Autonomic Security Operations. 

Get started on your journey to collaborate with industry partners on Community Security Analytics now.

Related posts:

• “New resources to advance your Autonomic Security Operations modernization journey.”

• “Autonomic Security Operations, 10X Transformation of the Security Operations Center”

• “Modernizing the U.S. Federal Government’s Approach to Cyber Threat Management with Autonomic Security Operations”

• “Achieving Autonomic Security Operations: Reducing toil”

• “Achieving Autonomic Security Operations: Automation as a Force Multiplier”

• “Modernizing SOC ... Introducing Autonomic Security Operations”