About rule sets

You can use the CIS ruleset engine to create and deploy rules and rule sets in CIS using the same basic syntax.

Main features

The following features apply to rule sets:

Powerful syntax: Rule expressions use a powerful rules language similar to the wirefilter syntax that allows you to create complex rules.
High-performance rule evaluation: Allows you to have many rules in CIS with minimal impact on performance.
Engine powering CIS: CIS will continue to build products on top of the ruleset engine, which means that you can use the same API methods for configuring different products with the same customization possibilities. The ruleset engine also supports the different phases of the request life cycle.

Phases

A phase defines a stage in the life of a request where you can execute rule sets. Phases are defined by CIS and cannot be modified.

Phases exist at the instance level and at the zone level. For the same phase, rules defined at the instance level are evaluated before the rules defined at the zone level.

Each phase has, at most, one entry point rule set at the instance and zone level.

Currently, only phases at the zone level are available. This page will be updated as instance and zone level phases become available in subsequent releases.

Phase list

The following table lists the phases that are available.

Table 1. Available phases
Phase name	Description
`http_request_firewall_managed`	Web Application Firewall (WAF)

Rules language

The CIS rules language is a flexible and intuitive specification for building rule expressions. Based on the Wireshark display filters, the rules language allows you to precisely target HTTP requests with a syntax and semantics familiar to security engineers.

Rules actions

The action of a rule determines how CIS handles matches for the rule expression.

The following table lists the actions available in the Rules language:

Table 2. Available actions
Action	API value	Description	Stops rule evaluation?
Interactive challenge	`challenge`	Useful for ensuring that the visitor accessing the site is human, not automated. The client that made the request must pass an interactive challenge. If successful, CIS accepts the matched request; otherwise, it is blocked.	Yes
JS Challenge	`js_challenge`	Useful for ensuring that bots and spam cannot access the requested resource; browsers, however, are free to satisfy the challenge automatically. The client that made the request must pass a JavaScript challenge before proceeding. If successful, CIS accepts the matched request; otherwise, it is blocked.	Yes
Managed challenge (recommended)	`managed_challenge`	Helps reduce the time spent solving CAPTCHAs across the Internet. Depending on the characteristics of a request, CIS will dynamically choose the appropriate type of challenge from the following actions based on specific criteria: Show a non-interactive challenge page (similar to the current JS challenge). Show a custom interactive challenge (for example, clicking a button).	Yes
Block	`block`	Matching requests are denied access to the site.	Yes
Skip	`skip`	Allows user to dynamically skip one or more security features or products for a request. Depending on the rule configuration, matching requests will skip the evaluation of one or more security features or products: Skip all remaining rules in the current rule set Skip rule sets Skip rules of a rule set Skip phases Skip specific security products that are not based on the ruleset engine The available skip options depend on the phase where you configure the rule.	No (However, some rules may be skipped)
Log	`log`	Records matching requests in the CIS logs. Only available on Enterprise plans. Recommended for validating rules before committing to a more severe action.	No
Execute	`execute`	Executes the rules in the ruleset specified in the rule configuration. You can specify a managed ruleset or a custom ruleset to execute. In the CIS UI, this action is not listed in action selection dropdowns.	No
Rewrite	`rewrite`	Adjusts the URI path, query string, and/or HTTP headers of requests and responses, according to the rule configuration. Only available in: Transform Rules, in phases `http_request_transform`, `http_request_late_transform`, and `http_response_headers_transform`. In the CIS UI, this action is not listed in action selection dropdowns. To use this action, create a Transform rule. WAF custom rules checking for exposed credentials, in the `http_request_firewall_custom` phase at the instance level. In the CIS UI, this action is called Exposed-Credential-Check Header.	No

Entry point ruleset

Entry point rulesets are abstracted away when using the CIS UI. They are required to deploy and override rulesets when using the API, CLI, SDK, or Terraform.

An entry point ruleset contains a list of ordered rules that run in a phase at the instance or zone level. This ruleset is an entry point for all rules executed in a phase. Some of these rules may run other rulesets.

Each phase has, at most, one entry point ruleset at the instance level and at the zone level.

The kind field of a phase entry point ruleset has one of the following values:

root: Used for a phase entry point ruleset at the instance level
zone: Used for a phase entry point ruleset at the zone level

See Deploying rule sets for detailed instructions on using entry point rulesets to deploy rulesets.

See Overriding rule sets for detailed instructions on using entry point rulesets to override rulesets.