Google Cloud Armor Adaptive Protection overview

Google Cloud Armor Adaptive Protection helps you protect your Google Cloud applications, websites, and services against L7 distributed denial-of-service (DDoS) attacks such as HTTP floods and other high-frequency layer 7 (application-level) malicious activity. Adaptive Protection builds machine-learning models that do the following:

  1. Detect and alert on anomalous activity
  2. Generate a signature describing the potential attack
  3. Generate a custom Google Cloud Armor WAF rule to block the signature

You enable or disable Adaptive Protection on a per-security-policy basis.

Alerts about anomalous traffic (potential attacks), which include the signatures of the attacks, appear in the Adaptive Protection event dashboard with event logs sent to Cloud Logging, where they can be directly analyzed or forwarded to a downstream log or security event monitoring workflow. Alerts of potential attacks are also generated as findings in the Security Command Center.

Availability of Adaptive Protection

While Google Cloud Armor Adaptive Protection is in Preview, Google Cloud Armor customers can configure individual security policies for Adaptive Protection. However, after Managed Protection reaches general availability, Adaptive Protection is available only to customers who subscribe to Google Cloud Armor Managed Protection Plus.

If your projects are not already enrolled in Managed Protection Plus, read Using Managed Protection for information on how to enroll.

Cloud Logging and Cloud Monitoring

Because using Adaptive Protection effectively requires you to understand how logging and alerting work in Google Cloud, we recommend that you familiarizing yourself with Cloud Logging, alerting, and alerting policies. For more information, see the Cloud Logging documentation and Cloud Monitoring documentation on alerting.

Configuring and tuning alerts

You can enable Adaptive Protection in projects where Google Cloud Armor security policies already protect your applications. When you enable Adaptive Protection for a particular security policy, Adaptive Protection is in effect for all backend services with which the security policy is associated.

After Adaptive Protection is enabled, there's a training period of at least one hour before Adaptive Protection develops a reliable baseline and begins monitoring traffic and generating alerts. During the training period, Adaptive Protection models incoming traffic and usage patterns that are specific to each backend service, so that it develops the baseline for each backend service. When the training period is over, you receive real-time alerts when Adaptive Protection identifies high frequency or high volume anomalies in the traffic directed to any of the backend services associated with that security policy.

You can tune Adaptive Protection alerts based on several metrics. The alerts, which are sent to Cloud Logging, include a confidence level, a suggested rule, and an estimated impacted baseline rate associated with the suggested rule.

  • The confidence level indicates the confidence with which Adaptive Protection models predict that the observed change in traffic pattern is anomalous.
  • The impacted baseline rate associated with the suggested rule represents the percentage of existing baseline traffic that would be caught by the rule.

You can filter alerts in Cloud Logging based on either or both of the confidence level and the impacted baseline rate. For more information on tuning alerts, see Managing alerting policies.

Consuming and interpreting alerts

As soon as Adaptive Protection detects a suspected attack, it generates an event in the Adaptive Protection event dashboard and generates a log item in Cloud Logging. The alert is in the JSON payload of the log item. The log item is generated under the Network Security Policy resource in Cloud Logging. The log message identifies the backend service under attack and includes a confidence score indicating how strongly Adaptive Protection rates the identified traffic pattern change as anomalous. The log message also includes an attack signature that illustrates the characteristics of the attack traffic, along with suggested Google Cloud Armor rules that you might apply to mitigate the attack.

Understanding attack signatures

An Adaptive Protection alert includes an attack signature, which is a description of the traffic attributes of the potential attack. You use the signature to identify and potentially block the attack. The signature takes two forms: as a user-readable table and as a preconstructed Google Cloud Armor WAF rule that you can deploy in the relevant security policy.

The signature consists of a set of attributes, such as source IP address, geographical regions, cookies, user agents, referers and other HTTP request headers, and the set of values for those attributes thought to be associated with the potential attack traffic. The set of attributes is not user- configurable. The attribute values depend on the values in the incoming traffic to your backend service.

For each attribute value that Adaptive Protection believes indicates the potential attack, Adaptive Protection lists the following:

  • The attack likelihood
  • The proportion of the attribute in the attack, which is the percentage of potential attack traffic that had this value at the time that the attack was detected
  • The proportion of the attribute in baseline, which is the percentage of baseline traffic that possessed this attribute value at time that the attack was detected

Cloud Logging entry specification contains details about the information in each alert.

The following is an example of a user-readable table that contains the signature of a potential attack:

Attribute name Attribute value Attack likelihood Proportion in attack Proportion in baseline
UserAgent "foo" 0.7 0.85 0.12
UserAgent "bar" 0.6 0.7 0.4
Source IP "a.b.c.d" 0.95 0.1 0.01
Source IP a.b.c.e 0.95 0.1 0.01
Source IP a.b.c.f 0.05 0.1 0.1
RegionCode UK 0.64 0.3 0.1
RegionCode IN 0.25 0.2 0.3

An Adaptive Protection alert and the relevant Cloud Logging event log contain the following:

  • A unique alert ID, or alertID, which is used to refer to a specific alert when it reports user feedback (more below)
  • The backend service under attack, or backendService
  • The confidence score, or confidence, which is a number between 0 and 1 that indicates how strongly the Adaptive Protection system rates the detected event as a malicious attack

You also receive a set of signatures and rules characterizing the detected attack. Specifically, the set provides a list of headerSignatures, each corresponding to one HTTP header and containing a list of significantValues for the specific header.

The following is an example signature:

headerSignatures: [
  0: {
   name: "Referer"
   significantValues: [
    0: {
     value: ""
     attackLikelihood: 0.95
     proportionInAttack: 0.6
     proportionInBaseline: 0.01

The alert suggests that the value in the header Referer is important in characterizing the attack. More specifically, 60% of the attack traffic (proportionInAttack) has this Referer value and only 1% of baseline traffic among all traffic (proportionInBaseline) has the same Referer value. Moreover, among all traffic matching this Referer value, 95% is attack traffic (attackLikelihood).

These values suggest that if you were to block all traffic that has Referer as the name and the value, you would successfully block 60% of the attack and also 1% of the baseline traffic.

Deploying suggested rules

Adaptive Protection alerts also provide a suggested Google Cloud Armor rule expressed in the custom rules language. This rule can be used to create a rule in a Google Cloud Armor security policy to mitigate the attack. In addition to the signature, the alert includes a rate of impacted baseline traffic to help you evaluate the impact of deploying the rule. The rate of impacted baseline traffic is a projected proportion of baseline traffic that matches the attack signature identified by Adaptive Protection.

You can find some of the alert signature as well as the impacted baseline rate in the log message sent to Cloud Logging. The following is the JSON payload of a sample alert.

@type: ""
 alertId: "11275630857957031521"
 backendService: "test-service"
 confidence: 0.71828485
 headerSignatures: [

  0: {
   name: "RequestUri"
   significantValues: [
    0: {
     attackLikelihood: 0.88
     proportionInAttack: 0.85
     proportionInBaseline: 0.01
     value: "/"
  1: {
   name: "RegionCode"
   significantValues: [
    0: {
     attackLikelihood: 0.08
     proportionInAttack: 0.17
     proportionInBaseline: 0.28
     value: "US"
    1: {
     attackLikelihood: 0.68
     proportionInAttack: 0.09
     proportionInBaseline: 0.01
     value: "DE"
    2: {
     attackLikelihood: 0.74
     proportionInAttack: 0.05
     proportionInBaseline: 0
     value: "MD"
   2: {
   name: "UserAgent"
   significantValues: [
    0: {
     attackLikelihood: 0.92
     proportionInAttack: 0.85
     proportionInBaseline: 0
     value: "Unusual browser"
    1: {
     attackLikelihood: 0.87
     proportionInAttack: 0.7
     proportionInBaseline: 0.1
     missing: true
 suggestedRule: [
  0: {
   action: "DENY"
   evaluation: {
     impactedAttackProportion: 0.95
     impactedBaselineProportion: 0.001
   expression: "evaluateAdaptiveProtection('11275630857957031521')"
Attack_size: 5000

You can deploy suggested rules by copying the CEL expression from the rule signature and pasting the expression into the match condition of a newly created rule, or by clicking the Apply button on the Adaptive Protection dashboard in the Google Cloud Armor UI.

To deploy the rule, you create a new rule in the Google Cloud Armor security policy that protects the targeted backend services identified by the alert. Next, during rule configuration, copy and paste the CEL expression from the alert into the Match condition field of the rule and set the rule action to deny. In the above example, you copy the expression evaluateAdaptiveProtection('11275630857957031521') from the suggestedRule section of the alert.

We strongly recommend that you initially deploy the rule in preview mode so you can evaluate the impact of the rule on production traffic. When you do this, Google Cloud Armor logs the action and the associated traffic whenever the rule is triggered, but no action is taken on the matched traffic.

In addition, if your security policy is attached to multiple backend services, note whether the effects of the new rule have unwanted effects in any of the backend services. If this happens, configure new security policies to mitigate the unwanted effects, and attach them to the correct backend services.

Deploying a suggested Adaptive Protection rule
Deploying a suggested Adaptive Protection rule (click to enlarge)

We recommend that you set the priority for the new rule higher than any rules with the action set to allow. This is because, to have the projected impact and have maximal effect in mitigating the attack, the rule should be deployed in the highest logical priority position to ensure that all matching traffic is blocked by the rule. Rules in a Google Cloud Armor security policy are evaluated in priority order with evaluation terminating after the first matching rule is triggered and the associated rule action is taken. If you need to grant an exception for some traffic or specific clients from this rule, an "allow" rule can be created with higher priority, that is, with a lower numerical value. For more information on rule priority, see Rule evaluation order.

Monitoring, feedback, and reporting event errors

You need the following permissions to view or interact with the Adaptive Protection dashboard.

  • compute.securityPolicies.list
  • compute.backendServices.list
  • logging.logEntries.list

After you enable Adaptive Protection on any Google Cloud Armor security policy, you can see the following page under Network Security > Google Cloud Armor panel. It displays the traffic volume over time for the selected security policy and backend service, and the selected duration. Any instances of potential attacks alerted by Adaptive Protection are annotated on the graph and listed below the graph. When you click a specific attack event, a side window is displayed with the attack signature and suggested rule shown in tabular format. This is same information that's in the Cloud Logging log entries that are described in Cloud Logging entry specification. Click the Apply button to add the suggested rule to the same security policy.

Adaptive Protection dashboard
Adaptive Protection dashboard (click to enlarge)
Adaptive Protection alert details
Adaptive Protection dashboard (click to enlarge)

Not every Adaptive Protection finding is deemed an attack, given the protected backend service's unique context and environmental factors. If you determine that the potential attack described by the alert is normal or accepted behavior, then you can report an event error to help train the Adaptive Protection models. Next to each attack event listed under the graph is a button that pops up an interactive window to allow you to report an event error with some optional context. Reporting an event error helps reduce the likelihood of similar errors in the future. Over time, this increases Adaptive Protection's accuracy.

Monitoring, alerting, and logging

Adaptive Protection telemetry is sent to Cloud Logging as well as the Security Command Center. The Adaptive Protection log message sent to Cloud Logging is described in the previous sections of this document. A log entry is generated every time Adaptive Protection detects a potential attack and each entry contains a confidence score describing how confident the models are that the observed traffic is anomalous. To fine-tune alerting, an alerting policy can be configured in Cloud Logging to trigger an alert only when an Adaptive Protection log message has a confidence score above a user-specified threshold. We recommend that you start with a low threshold, with confidence > 0.5, to avoid missing warnings of potential attacks. The confidence threshold in the alerting policy can be increased over time if the alerts have an unacceptable impacted baseline rate.

The Security Command Center dashboard also contains findings from Adaptive Protection. They are located in the Google Cloud Armor card under the Application DDoS Attacks category. Each finding includes the details of the service, the attack confidence, the signature associated with the attack, and a link to the specific alert on the Adaptive Protection dashboard.

Cloud Logging entry specification

The Adaptive Protection alert sent to Cloud Logging consists of a log entry containing the following elements:

  • Alert confidence: Adaptive Protection confidence that the event observed is an attack.
  • Attack signature
    • Attribute name: The name of the attribute such as a particular request header, geographic origin.
    • Attribute value: The value of the attribute that is observed in the malicious traffic
    • Attack likelihood: The likelihood that a given request is malicious, given that it has the above value for the relevant attribute.
    • Proportion in attack: The percent of potential attack traffic that contains this attribute value
    • Proportion in baseline: The percent of normal, baseline traffic that contains this attribute value
  • Suggested rule
    • Match condition: The expression to be used in the rules match condition to identify malicious traffic.
    • Impacted baseline rate: The projected percentage of good traffic that would be captured by the suggested rule.
    • Impacted attack rate: The projected percentage of attack traffic that would be captured by the suggested rule.

Machine learning overview and privacy

  • Training data and detection data
    • Adaptive Protection builds several models to detect potential attacks and identify their signatures. The signals used by these models to determine if an attack is ongoing are derived from the observed metadata of incoming request traffic from your projects. Such metadata includes: source IP address, source geography, and the values of some HTTP request headers.
    • The actual features used by the models are derived statistical properties of the above-mentioned signals. That is, the training data for the models do not include the actual values of any metadata, such as IP addresses and/or request header values.
    • A common set of detection models, trained with only artificial data are shared across all customers, to determine whether an attack is taking place, when Adaptive Protection is first enabled. Once you report any false attack event and the models are updated using traffic signals specific from your projects, these models are local to your projects and are not used for any other customers.
  • Signature generation data
    • After Adaptive Protection determines that a potential attack is taking place, it generates an attack signature that's effective to help the target mitigate the attack quickly. To achieve the above, after you enable Adaptive Protection on a security policy, traffic metrics and request metadata to a backend service (associated with the security policy) are continually recorded to learn baseline traffic characteristics.
    • Because Adaptive Protection needs to learn about the baseline traffic, Adaptive Protection only starts alerting for potential attacks at least one hour after it's enabled.

What's next