Introducing Cloud Armor features to help improve efficacy: advanced rule tuning and auto deploy

At Google Cloud Next in October, we announced the Preview release of advanced rule tuning for Cloud Armor which can provide customers more granular control over how they apply our pre-configured Web Application Firewall (WAF) rules. We also announced the Preview of our auto-deploy option for proposed mitigating rules generated by Cloud Armor Adaptive Protection, our machine learning-based attack detection and response capability. 

Advanced rule tuning for pre-configured WAF rules

With the advanced rule tuning capabilities, customers may now: 

• Tune preconfigured WAF rules by sensitivity level

• Deploy preconfigured WAF rules using signature opt-in or opt-out mode

• Exclude request fields from WAF rule inspection 

Advanced rule tuning can help customers make rules more effective and reduce the noise from protected applications which expect traffic that matches the underlying signatures. It is considered a best practice to enable verbose logging to help quickly identify which signatures and fields to omit from a given deployment.

Configuration by Sensitivity Level 

Sometimes normal traffic to protected resources can cause a preconfigured WAF rule to trigger even though the request is safe and well-formed. The result is a false positive. While it doesn't happen often, when it does it can be annoying and distracting. With the latest release of Cloud Armor, the configuration options and process for rule tuning have been expanded, which can greatly simplify how one can address such cases.  Customers can now specify a sensitivity level, which determines which group of signatures in the preconfigured WAF rule are used to inspect an incoming request, thus alleviating the need to list out each specific signature individually. 

The OWASP ModSecurity Core Rule Set (CRS) groups specific threat signature values into logical groupings called Paranoia Levels (1-4), which Cloud Armor implements as the sensitivity level field in its rule language. Because we added a level 0, there are five sensitivity levels:

• Sensitivity level 0: No rules applied - Signature opt-in mode

• Sensitivity levels 1-4: Sliding scale of signature sensitivity with level 1 corresponding to the highest fidelity signatures (which are least likely to generate false positives), and level 4 corresponding to the highest sensitivity signatures (which are least likely to generate the chances of a false negative)

The Cloud Armor documentation describes in more detail which signatures are associated with which severity level. 

In general, the higher the sensitivity level, the lower the risk of permitting a malicious request through (false negative). However, high sensitivity increases the chance of noisy alerts without further tuning of the rules. Depending on your defense strategy you may wish to start with a more aggressive posture for especially sensitive applications, such as level 4, and relax the rules based on observed noise from your protected application; however, most customers tend to start with a permissive deployment, such as level 1, and tighten as necessary. 

Sensitivity level 1 example:

Signature Opt-out and Opt-in Mode

To further tune your rules, you can also now opt-in or opt-out of certain signatures in a rule set.  

• Opt-out: Allows you to disable a signature that you don’t want to be used in the current rule invocation

• Opt-in: The inverse function of opt-out, you select only the signatures that you want Cloud Armor to evaluate

Opt-out example:

This rule applies sensitivity level 3 for the CRS rule for PHP, while excluding the signature owasp-crs-v030301-id933111-php, which is normally part of the level 3 grouping. 

To apply the ‘opt_in_rule_ids’ operation, the sensitivity level has to be explicitly set as 0 (no rules applied).

Opt-in example:

In the opt-in example above, Cloud Armor will only process the two Common Vulnerabilities and Exposures (CVE) signatures specified rather than applying the standard Cloud Armor ‘cve-canary’ rules set which currently contains four signatures. 

The opt-in approach can be helpful in two cases. The first is when most of the signature rules are not going to be processed, so rather than listing a longer set of signatures to exclude, you list only the handful of signatures to evaluate. The second is when you always want to verify newly released signatures before deploying them. Such a case can arise when new signatures are added to an existing rule, such as when a new critical, zero-day vulnerability drives new signatures (as occurred with our response to Log4j). Using opt-in IDs, the new signatures will not automatically be evaluated; you can first test and verify them in your specific environment, and then deploy them when you are ready. 

By combining Common Expression Language (CEL) with preconfigured WAF rules you can customize opt-in/opt-out use cases you need to support if specific URLs need specialized processing, while preserving the inspection of the preconfigured WAF signatures elsewhere.

Combining CEL rule with Opt-out rule:

In the CEL rule example, the rule evaluates the remote code execution CRS rule at a sensitivity level of 3, while excluding one signature value only for requests which attempt to reach the login URL based on the specified regular expression match. 

Optionally exclude request fields from inspection 

There are times when you expect incoming requests to contain values, such as special characters, that could trigger a signature in the preconfigured WAF rules. In these circumstances, you still want Cloud Armor to evaluate the request for possible vulnerabilities. For these situations, you can now configure field level exclusions to preconfigured WAF rules within Cloud Armor policy. 

You can now configure Cloud Armor rules to exclude from evaluation specific fields - request headers, cookies, query parameters and URL paths - based on a string pattern match on the field name. 

You can articulate a string sequence to match on a field name using any one of the following operators:

• EQUALS

• STARTS_WITH

• ENDS_WITH

• CONTAINS

• EQUALS_ANY

Once you have identified the specific WAF rule and offending signature, you can run a gCloud command to tell Cloud Armor to omit the undesired field from evaluation while processing the rule against the remainder of the request. 

Field exclusion example:

In the example above, the exclusion is configured for Cloud Armor to evaluate incoming requests while omitting headers that begin with “abc” from inspection against two signatures, "owasp-crs-v030301-id941140-xss" and "owasp-crs-v030301-id941270-xss". All other signatures within the “xss-v33-stable” rule set will still be included in the evaluation if they are included in the rule at priority = 1400. 

Auto-Deploy Adaptive Protection’s suggested rules

Cloud Armor’s Adaptive Protection (video) can automatically detect incoming attacks and can analyze the attack traffic to recommend mitigations in near real time. Cloud Armor mitigated one of the largest known DDoS attacks on record using this functionality. Leveraging Google’s machine learning capabilities, Adaptive Protection can analyze traffic flowing to the protected applications to establish a baseline of good traffic, and can detect potential attacks that deviate from the baseline. Alerts include the dynamically calculated signature of the attack, and Adaptive Protection proposes a WAF rule to mitigate it.

When customers come to trust and rely on Adaptive Protection they generally ask us to help cut the human out of the loop when a mitigating rule is generated. We have been hearing this request this past year and a half. With Adaptive Protection’s new auto-deploy feature (in Preview), customers can now have Cloud Armor automatically deploy the Adaptive Protection generated rules based on the following criteria:

• Load threshold: The spike in the load of the attacked application or backend service 

• Confidence threshold: The confidence score indicating the likelihood of attack

• Impacted baseline threshold: The percentage of baseline traffic that may be affected by the rule

• Expiration: How long you want the rule to remain in place

Previously, customers needed to manually review the alert and suggested rule, then deploy the rule. It didn’t take long before customers were convinced of Adaptive Protection’s accuracy, and asked us to automate those deployment steps. With the new auto-deploy feature, Cloud Armor customers can automatically deploy rules with a desired action, like block or rate limit, when the configured criteria threshold values are satisfied. 

Next steps

Cloud Armor’s improved configuration options for WAF rule writing can help increase how effective the rules are, and make them more adaptable to the needs of the applications they’re protecting. These tuning capabilities can help reduce noise and simplify deployment, while ensuring maximal security where appropriate. 

We’ve also helped customers react faster to and reduce the damage from Layer 7 attacks by providing the option for automatic deployment of the Adaptive Protection feature’s recommended blocking rules.  

For more information, consult our documentation, contact your Google Cloud sales representative, or reach out to us in the Google Cloud Platform Community’s security Slack channel.