We are excited to launch Google Chronicle’s Security Analyst Diaries, a blog series capturing practitioner and security analyst focused use cases. We want to share stories of how our customers are driving superior security outcomes using Google Chronicle, and building scalable, consistent, and effective detection and response programs.

For our first diary entry we wanted to highlight key feature favorites this particular customer loved -

1. CIS violation detection content can be added in 3 easy steps

2. Chronicle to GCP connectivity is turnkey

3. Detection alerts are automatically enriched to make alerts actionable

4. Complete flexibility to customize detection content exists right inside the product.

Check out the video version of this diary entry.

CIS Violation Detections

There are many organizations that leverage CIS benchmarks to standardize minimum thresholds of compliance to run their IT operations and security. These benchmarks are a set of best-practice cybersecurity standards for a range of IT systems and products. CIS benchmarks provide the baseline configurations to ensure compliance with industry-agreed cybersecurity standards. The benchmarks are developed by CIS alongside communities of cybersecurity experts within industry and research institutes.

This particular Chronicle customer was able to quickly gain value from Google Chronicle by validating CIS 1.2 Controls against their Google Cloud Platform (GCP) environment, helping to drive a consistent and methodical compliance program.

Chronicle to GCP Connectivity

The customer was able to quickly take advantage of Chronicle’s native integration for consuming GCP Cloud Audit Logging (CAL) and Cloud Asset Inventory (CAI) data into their Chronicle instance in near real-time. This was an important point for the customer as it removed the overhead of their having to manage ingesting GCP logs. No more having to configure and manage sinks, no additional cost for storing that data, and no latency waiting for your log data to arrive.

Note; GCP Security Command Center provides both runtime and state based GCP benchmark visibility for CIS benchmarks (and other frameworks too), and is highly recommended as an essential part of our Google Cloud Blueprints.

After having deployed the CIS YARA-L Detection Rules, and there were several Alerts waiting in the Chronicle Enterprise Insights panel for potential GCP CIS 1.2 violations.

We had to start with one, so we started to explore insights and the workflow related to the rule gcp_managed_service_account_keys. The first point was to review the rule itself and understand the logic behind the detection. Chronicle’s YARA-L rules provide not only a record of the detection logic, but also provide metadata tagging providing additional context around a Detection, e.g., mapping to CIS or MITRE controls, deployment or tuning guidance.

/\*\* Copyright 2021 Google LLC\*\* Licensed under the Apache License, Version 2.0 (the “License”);\* you may not use this file except in compliance with the License.\* You may obtain a copy of the License at\*\* [https://www.apache.org/licenses/LICENSE-2.0](https://www.apache.org/licenses/LICENSE-2.0)\*\* Unless required by applicable law or agreed to in writing, software\* distributed under the License is distributed on an “AS IS” BASIS,\* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.\* See the License for the specific language governing permissions and\* limitations under the License.\*/rule gcp\_managed\_service\_account\_keys {meta:author = “Google Cloud Security”description = “Ensure that there are only GCP-managed service account keys for each service account”severity = “LOW”implementation = “Configure exclusions for approved workflows.”cis\_version = “1.2”cis\_control = “1.4”tactic = “TA0003”technique = “T1136”events:$gcp.metadata.vendor\_name = “Google Cloud Platform”$gcp.metadata.product\_event\_type = /google.iam.admin.v1.CreateServiceAccountKey/$gcp.target.user.email\_addresses = /iam.gserviceaccount.com///capture variables$gcp.principal.user.email\_addresses = $user//exclusionsnot (// GCP Service Accounts$gcp.principal.user.email\_addresses = /gserviceaccount.com/ or// Context Aliased Domains$gcp.principal.user.email\_addresses = /test-google-a.com/)match:$user over 15mcondition:$gcp}

The gcp_managed_service_account_keys.yaral rule mapped to CIS 1.4

Note; What’s the CIS 1.4 control about? tl;dr — don’t create and download service account keys.

With an understanding of the Detection Rule logic, drilling down from the Enterprise Insights panel the customer was able to pivot and quickly understand:

• The real identity of the user who was creating the service keys

• How they were creating service account keys

• Where they were creating these service keys

Enriched Detection Alerts

One thing the customer immediately noticed was that while they were looking at a Google Cloud Audit log relating to a service account key being created, they could see the Name, Employee ID, Job Title, and many other fields related to the user who created the Service Key; however, none of this information was in the logs themselves.

Well, it was fortunate they asked as it’s a super powerful feature of Chronicle — automatic and continuous enrichment of all log data from the customers source of truth, e.g., LDAP (Azure Active Directory), an identity platform (like Okta or Cloud Identity), or an employee HRIS system (like Workday). No more manual lookups. No more maintaining another copy of contextual information in their SIEM.

This additional context injected into every log was game-changing for the customer’s Security Analysts. Enrichment of user and asset data directly from customer sources of truth via automation enabled our Customers to focus on higher order problems, rather than managing data fidelity issues.

Customisable Detection Features

A clue to understanding what was going on with the gcp_managed_service_account_keys alert was in the “User-Agent” field. When you perform an action in a cloud environment there’s an API involved somewhere, which means a network request was made, and that means an Agent, i.e., the User Agent (UA).

From scanning the UDM User Agent (UA) field there were two distinct UAs, one which was Terraform — the authorized method for creating service account keys, and one which wasn’t.

This was an immediate point of interest around adding approved business workflow logic to the YARA-L Detection Rule — any service account creation not from a User Agent matching the string “Terraform” should be detected. This was a simple update to the rule:

…//exclusionsnot (// GCP service accounts$gcp.principal.user.email\_addresses = /gserviceaccount.com/ or// Context Aliased Domains$gcp.principal.user.email\_addresses = /test-google-a.com/ or// Permitted workflows$gcp.network.http.user\_agent = /Terraform/ nocase)…

Another neat feature the customer liked about Chronicle Detect, having learnt the hard way from other platforms before which struggled with performance or data fidelity, was being able to use regular expressions (Regex) to apply a pattern match. While we had examples of the User Agent string being in a specific case, applying an exclude filter in a case insensitive manner ensured they needn’t worry about case variations.

With the updated YARA-L Detection Rule, and using the Detection Engine’s versioning feature (when a rule is updated prior versions are retained and can be accessed, but only the current versions Detections are shown), a RetroHunt was run.

What’s a RetroHunt? Well, while Chronicle can do Stream detection against all UDM data, it can also run these same YARA-L Detections historically. A single language for both Stream and Batch detection!

Having successfully run the RetroHunt, with the updated logic, the customer was able to identify further policy violations bypassing the approved workflows for service account key management.

And there we were. The customer was able to quickly leverage Chronicle Detect to understand and gain visibility toward implementing GCP CIS controls and benchmarks on their GCP environment. We have published these detection rules on our public github page https://github.com/chronicle/detection-rules

There were more rules to evaluate, and we hadn’t even started to explore these results in a Dashboard, but that’s a story for another day, in another Security Analyst Diary.