Unwelcome web traffic from bots has proliferated, becoming a significant contributor to business and operational risk. The motivations of bot controllers range from disruption of business through DDoS attacks to fraud such as credential stuffing, denial of inventory, scraping, and fraudulent card use. Google is well positioned to help detect and mitigate these risks by leveraging both our AI/ML strengths for combatting bot traffic as well as the global scale of our network to absorb even the largest threats.

Today we are announcing the public preview of Cloud Armor bot management with reCAPTCHA Enterprise.This new set of capabilities is centered around a new deep integration between reCAPTCHA Enterprise and Cloud Armor as part of our overall Web-App and API Protection (WAAP) solution, which also includes Apigee. You can now leverage the power of reCAPATCHA’s intelligence gained from protecting 5+ million sites directly in Cloud Armor to comprehensively manage risk from bots and other application layer threats. You can enable this protection using an easy-to-configure policy in Cloud Armor without any server-side changes to your applications. Because detection and enforcement happens in-line, at the edge of Google’s network, you can mitigate threats before they have a chance to impact your applications, whether they run on GCP, on premise, or in a hybrid or multi-cloud deployment.

Google Cloud Armor 

Cloud Armor is the DDoS mitigation service and web-application firewall (WAF) that brings to bear the global scale of Google’s network – blocking unwelcome traffic upstream from your infrastructure. Cloud Armor helps protect your websites and applications from volumetric and protocol based (Layer 3/4) DDoS attacks, application level DDoS attacks, and mitigates the rest of the OWASP Top 10. With Cloud Armor, you can enforce custom Layer 7 filtering and rate-limiting policies at the edge to ensure availability of your workloads and meet security and compliance requirements. 

reCAPTCHA Enterprise 

reCAPTCHA Enterprise is Google’s fraud detection service that leverages over a decade of experience defending the internet and data from Google’s network of over 5 million sites. reCAPTCHA Enterprise can be used to prevent fraud and attacks perpetrated by scripts, bot software, or humans. When installed on a web page at the point of action, such as login, purchase, or account creation, reCAPTCHA Enterprise provides a frictionless user experience that allows legitimate users to proceed using a web page while fake users and bots are blocked.

The Cloud Armor and reCAPTCHA Enterprise integration

Users can now configure their Cloud Armor security policies to block requests that reCAPTCHA determines to be coming from a bot. There are several ways to do this:

1) Enforce reCAPTCHA Enterprise frictionless assessment 

reCAPTCHA Enterprise assigns risk scores to interactions on your website (e.g., logins, signups, gift card redemption, checking out, etc.) Based on these interactions, it returns a score between 0.0 and 1.0, with 0.0 being a likely fraudulent interaction and 1.0 being a likely legitimate interaction. To reduce fraud, you might choose to take action on returned scores for logins below 0.5, but allow users with higher scores to continue their login with zero friction. 

With this new integration, you can also have Cloud Armor take action based on the score, including blocking or redirecting the request based on reCAPTCHA’s assessment from the client-side instrumentation. The client-side instrumentation can be enabled by installing reCAPATCHA’s javascript library into browser applications or using the reCAPTCHA SDK with mobile applications. By the time the user’s request leaves the client, it will have a reCAPTCHA assessment and bot score attached to it. This scoring is accomplished in-line, as the user’s request is being evaluated through your Cloud Armor security policy. Crucially, this occurs without incurring the latency of an additional request/response back to the reCAPTCHA service.

2) Serve reCAPTCHA Challenge in Cloud Armor 

In this scenario, suspicious users are blocked by Cloud Armor until they solve the reCAPTCHA Enterprise challenge.You can configureCloud Armor to serve a reCAPTCHA challenge for any requests that match on a Cloud Armor security policy rule. To do so, you can configure a rule in through the Google Cloud CLI with an action to redirect to reCAPTCHA Enterprise in order to serve a CAPTCHA:

  gcloud beta compute security-policies rules create 1000
     --security-policy my-policy
     --expression "request.path.matches("/login.html")"
     --action redirect
     --redirect-type google-recaptcha

In the above example, we are choosing to have reCAPTCHA Enterprise deployed to assess every request attempting to access the login page to prevent bots from logging into our service. With Cloud Armor first requiring reCAPTCHA Enterprise to assess the bot risk of reach request, unwelcome traffic from bots would be blocked at the edge.

3) Redemption Flow

While we aim to make the initial reCAPTCHA assessment as accurate as possible, some organizations prefer to give the end-user another chance by solving a challenge in the event that the reCAPTCHA score is lower than their defined threshold. As part of this release, you can combine both the frictionless assessment and manual challenge into what we call the “redemption flow”. To do so, you can configure the match condition of a Cloud Armor rule to detect a low reCAPTCHA token score  and configure the action of the same rule to redirect to a reCAPTCHA challenge.

  gcloud beta compute security-policies rules create 1000
     --security-policy my-policy
     --expression "request.path.matches(\"/login.html\") && token.recaptcha.score <= 0.3"
     --action redirect
     --redirect-type google-recaptcha

By combining both of these scenarios into the redemption flow, you can give suspicious clients the opportunity to redeem themselves by proving they are not a bot.

These bot detection and mitigation use cases, taken together or separately, allow your bot management strategy to scale up without impacting your protected workloads, as all decisions are made at the edge of Google’s network. 

Additional bot management capabilities 

In addition to the integration with reCAPTCHA Enterprise, Cloud Armor has added more capabilities to help you implement an effective bot management strategy: 

1. Redirect actions – Cloud Armor rules now support a redirect action to redirect end-clients to a user-configured URL. Requests that match on such rules would respond with an HTTP 302 to the end-client in order to send them to an alternative destination. 
2. Insert Header – With the ability to conditionally insert a custom header and value into an incoming request, users can now tag requests based on the criteria in the match condition of any Cloud Armor rule. This allows you to treat tagged requests differently downstream in your applications. For example, you can choose to route suspicious requests to a honeypot or silently not process their transaction so as not to tip off the bot that it  has been detected.

Learn more

Cloud customers can get started right now by configuring a rule to redirect to reCAPTCHA in their Cloud Amor security policies through the command line interface.  Learn more in these documentation links:

• Cloud Armor Bot Management Overview
• reCAPTCHA Enterprise for WAF Overview

The cybersecurity industry is faced with the tremendous challenge of analyzing growing volumes of security data in a dynamic threat landscape with evolving adversary behaviors. Today’s security data is heterogeneous, including logs and alerts, and often comes from more than one cloud platform. In order to better analyze that data, we’re excited to announce the release of the Cloud Analytics project by the MITRE Engenuity Center for Threat-Informed Defense, and sponsored by Google Cloud and several other industry collaborators.

Since 2021, Google Cloud has partnered with the Center to help level the playing field for everyone in the cybersecurity community by developing open-source security analytics. Earlier this year, we introduced Community Security Analytics (CSA) in collaboration with the Center to provide pre-built and customizable queries to help detect threats to your workloads and to audit your cloud usage. The Cloud Analytics project is designed to complement CSA.

The Cloud Analytics project includes a foundational set of detection analytics for key tactics, techniques and procedures (TTPs) implemented as vendor-agnostic Sigma rules, along with their adversary emulation plans implemented with CALDERA framework. Here’s a overview of Cloud Analytics project, how it complements Google Cloud’s CSA to benefit threat hunters, and how they both embrace Autonomic Security Operations principles like automation and toil reduction (adopted from SRE) in order to advance the state of threat detection development and continuous detection and response (CD/CR).

Both CSA and the Cloud Analytics project are community-driven security analytics resources. You can customize and extend the provided queries, but they take a more do-it-yourself approach—you’re expected to regularly evaluate and tune them to fit your own requirements in terms of threat detection sensitivity and accuracy. For managed threat detection and prevention, check out Security Command Center Premium’s realtime and continuously updated threat detection services including Event Threat Detection, Container Threat Detection, and Virtual Machine Threat Detection. Security Command Center Premium also provides managed misconfiguration and vulnerability detection with Security Health Analytics and Web Security Scanner.

Cloud Analytics vs Community Security Analytics

Similar to CSA, Cloud Analytics can help lower the barrier for threat hunters and detection engineers to create cloud-specific security analytics. Security analytics is complex because it requires:

• Deep knowledge of diverse security signals (logs, alerts) from different cloud providers along with their specific schemas;
• Familiarity with adversary behaviors in cloud environments;
• Ability to emulate such adversarial activity on cloud platforms;
• Achieving high accuracy in threat detection with low false positives, to avoid alert fatigue and overwhelming your SOC team.

The following table summarizes the key differences between Cloud Analytics and CSA:

Together, CSA and Cloud Analytics can help you maximize your coverage of the MITRE ATT&CK® framework, while giving you the choice of detection language and analytics engine to use. Given the mapping to TTPs, some of these rules by CSA and Cloud Analytics overlap. However, Cloud Analytics queries are implemented as Sigma rules which can be translated to vendor-specific queries such as Chronicle, Elasticsearch, or Splunk using Sigma CLI or third party-supported uncoder.io, which offers a user interface for query conversion. On the other hand, CSA queries are implemented as YARA-L rules (for Chronicle) and SQL queries (for BigQuery and now Log Analytics). The latter could be manually adapted to specific analytics engines due to the universal nature of SQL

Getting started with Cloud Analytics

To get started with the Cloud Analytics project, head over to the GitHub repo to view the latest set of Sigma rules, the associated adversary emulation plan to automatically trigger these rules, and a development blueprint on how to create new Sigma rules based on lessons learned from this project.

The following is a list of Google Cloud-specific Sigma rules (and their associated TTPs) provided in this initial release; use these as examples to author new ones covering more TTPs.

Sigma rule example

Using the canonical use case of detecting when a storage bucket is modified to be publicly accessible, here’s an example Sigma rule (copied below and redacted for brevity):

The rule specifies the log source (gcp.audit), the log criteria ( storage.googleapis.com service and storage.setIamPermissions method) and the keywords to look for (allUsers, ADD) signaling that a role was granted to all users over a given bucket. To learn more about Sigma syntax, refer to public Sigma docs.

However, there could still be false positives such as a Cloud Storage bucket made public for a legitimate reason like publishing static assets for a public website. To avoid alert fatigue and reduce toil on your SOC team, you could build more sophisticated detections based on multiple individual Sigma rules using Sigma Correlations.

Using our example, let’s refine the accuracy of this detection by correlating it with another pre-built Sigma rule which detects when a new user identity is added to a privileged group. Such privilege escalation likely occurred before the adversary gained permission to modify access of the Cloud Storage bucket. Cloud Analytics provides an example of such correlation Sigma rule chaining these two separate events.

What’s next

The Cloud Analytics project aims to make cloud-based threat detection development easier while also consolidating collective findings from real-world deployments. In order to scale the development of high-quality threat detections with minimum false positives, CSA and Cloud Analytics promote an agile development approach for building these analytics, where rules are expected to be continuously tuned and evaluated.

We look forward to wider industry collaboration and community contributions (from rules consumers, designers, builders, and testers) to refine existing rules and develop new ones, along with associated adversary emulations in order to raise the bar for minimum self-service security visibility and analytics for everyone.

Acknowledgements

One of the fundamental questions that retailers constantly ask themselves is how well they know their customers and how they can build deeper relationships. Knowing who their customers are can have a direct impact on improving customer engagement, which can lead to increased conversion rates, customer loyalty, lifetime value, and higher return on marketing spend. 

Retailers have started to use innovative new methods like identity graphs, which connect information from multiple sources such as internal databases, marketing systems, online interactions and social media platforms. While these new methods have shown promise, the best and most effective approach remains customer self-identification through an authentication process.

As a result, retailers require a sophisticated user identity platform that protects customer information with proper authentication and authorization, one which incorporates advanced mechanisms like multi-factor authentication and intelligent account protection, to ensure customer information is protected throughout its lifecycle. 

Google Cloud Identity Platform (GCIP) is a customer identity and access management (CIAM) solution that can enable retailers (and any other organization) to add identity and access management capabilities to online applications. GCIP is easy to administer and develop with, and is able to grow with an organization’s online user base.

With a customer identity and access management (CIAM) solution like GCIP, a retailer can quickly and easily implement powerful identity management and security capabilities such as:

• Advanced authentication through email or SMS/text messaging.
• Quicker onboarding with social logins from Google, Facebook and others.
• Flexibility to support external identity providers through identity federation.
• Support for multi-tenant B2B use cases with the ability to create unique silos of users and configurations.
• Easy to use interfaces and libraries to help web/mobile application developers quickly integrate and launch. 
• Broad authentication protocol support, including SAML 2.0, OAuth/OIDC or simple email- and password-based authentication.
• Built on Google Cloud’s planet-scale infrastructure to support a growing customer base.

How does it work?

GCIP allows end users to authenticate to web and mobile applications. For retailers, this could be their online shopping app for mobile devices or an ecommerce website accessible over the internet through a web browser.

Users can sign-in with their email/passwords, phone numbers or using their social logins . If the organization uses an existing OpenID Connect (OIDC) provider, a Security Assertion Markup Language (SAML 2.0) provider or even a custom authentication system which issues signed tokens, Google Cloud Identity platform can be used as the authentication orchestrator.

Using Google Cloud Identity Platform as the primary authentication system

GCIP can serve as the primary authentication system, meaning users are provisioned into GCIP. In this case, the end user identities are securely persisted in the “account store” database. The database is a part of fully managed GCIP services and needs no provisioning or scaling from the retailer as their end user base grows. A high level architectural overview of how this flow may look like is shown below:

Using Google Cloud Identity Platform with social logins

Google Cloud Identity Platform can also be used with popular social logins such as Google, Facebook and others. This gives users a familiar option and eliminates the need to provision users in the GCIP identity store. Below is a high-level architecture diagram showing how GCIP integrates with the social login providers.

Customizing user flows

Many organizations want to be able to customize their login flows. Sometimes, an organization wants to make data related to new user creation and user logins (barring the passwords) available to other systems. These systems can include analytical systems, recommendations or promotions engines (such as sending welcome emails and promotions upon new sign-ups,) security operations (for example, to run analysis on sign-in requests to help detect account takeover attempts,) customer master data management systems, and customer data platforms. GCIP supports blocking functions and asynchronous functions to help customize the login flows and enable syndication of the login or sign-up activity related data to external systems.

Next steps

Google Cloud Identity Platform can provide a robust, scalable, secure-by-design mechanism for managing and authenticating users to online apps. To learn more about GCIP and how it can benefit your organization, please check out the documentation.