---
title: Configuring system signals
summary: null
url: >-
  https://www.fastly.com/documentation/guides/next-gen-waf/signals/configuring-system-signals
---

[System signals](https://www.fastly.com/documentation/guides/next-gen-waf/signals/using-system-signals/) are labels that we've created to describe important, identifiable request properties. The Next-Gen WAF uses them to track requests exhibiting common attacks, anomalies, and behaviors. While [detection](https://www.fastly.com/documentation/guides/next-gen-waf/signals/configuring-system-signals#detections) for most system signals is enabled by default, you must enable detection for CVE virtual patch, API, and ATO system signals if you want to use them.

In addition, you can customize how the Next-Gen WAF handles some system signals by adding:

- **[Exclusions](https://www.fastly.com/documentation/guides/next-gen-waf/signals/configuring-system-signals#exclusions):** configurations that prevent requests with a particular pattern from being tagged with the specified system signal.
- **[Site alerts](https://www.fastly.com/documentation/guides/next-gen-waf/thresholds/configuring-site-alerts) (also known as signal thresholds):** configurations that cap the number of times requests from the same IP address can be tagged with the same signal before the Next-Gen WAF flags that IP address. Once flagged, subsequent requests from the flagged IP address are handled (e.g., blocked) for a set period of time per the direction of the configuration.

## Detections

While detection for most system signals is enabled by default, you must enable detection for CVE virtual patch, API, and ATO system signals if you want to use them.

### CVE signals

With CVE signals, you can block and log requests matching specific CVEs. These signals should only be enabled temporarily while you implement more permanent solutions. To enable virtual patches, check out our [Virtual patches](https://www.fastly.com/documentation/guides/next-gen-waf/virtual-patches-for-cves) guide.

### ATO and API signals

> **IMPORTANT:** API and ATO signals are not included with the [Essential platform](https://docs.fastly.com/products/fastly-next-gen-waf#feature-availability).

ATO and API signals can help you gain visibility into registrations, logins, and API requests. ATO signals identify account takeover (ATO) attacks, such as failed password reset attempts. API signals tag requests made to your API, enabling detection of patterns like repeated API requests from an unexpected user agent. With the exception of the Login and Registration groups of signals, ATO and API signals are part of the [time series only](https://www.fastly.com/documentation/guides/next-gen-waf/data-storage-and-privacy/about-data-storage-and-privacy/#storage-categories) data storage category.

Detection for API and ATO signals is disabled by default, as configuration is required for enablement. For example, to enable detection of the Login Attempt signal, you must specify the paths of your login endpoints.

### Next Gen Waf Control Panel

You can enable ATO and API signals from the Templated Rules page. Templated rules are partially pre-constructed rules that are associated with a specific system signal. For example, you can enable the GraphQL API Query templated rule to track GraphQL API requests.

To enable and edit templated rules, complete the following steps:

1.   Log in to the [Next-Gen WAF control panel](https://dashboard.signalsciences.net).

2.   From the **Sites** menu, select a site if you have more than one site.

3. From the **Rules** menu, select **Templated Rules**.

4. Click **View** to the right of the rule you want to enable or edit.

5. Click **Configure** in the upper-right corner to enable or edit the rule.

6. In the condition-related fields, enter values specific to your application, such as paths, response codes, and headers. It is possible to add, edit, and remove conditions in the rule as necessary for your application.

7. _(Optional)_ If the **Configure thresholds and actions** section is available, select the action that should be taken (e.g., block or log).

   When configuring failure-based rules (e.g., `Login Failure`), you can also optionally define the:

   - threshold, the parameters that define how often an individual client can send requests that meet the rule's conditions before action is taken.
   - duration, the amount of time the action will occur.
   - notifications, whether notification should be sent via your site (also known as workspace) integrations.

8. Click **Update Rule** or **Update Site Rule**.

### Fastly Control Panel

To enable ATO and API signals, complete the following steps:

1.   Log in to the [Fastly control panel](https://manage.fastly.com).

2.   Go to **Security** > **Next-Gen WAF** > [**Signals**](https://manage.fastly.com/security/ngwaf/signals).

3.   From the workspaces bar, click the menu <span class="inline-icons"><img src="/img/icons/chevron-down.png" alt="Menu icon" /></span> to the right of the workspace name and select a workspace.

4. Use the search bar to find the ATO or API signal that you want to enable, and then click the document icon <span class="inline-icons"><img src="/img/icons/document.png" alt="Document icon" /></span> to the right of the signal.
5. Click **Configuration** and then **Detections**.
6. In the condition-related fields, enter values specific to your web application, such as paths, response codes, and headers. It is possible to add, edit, and remove conditions as necessary.
7. Leave the **status** switch set to the **On** position.
8. Click **Create detection rule** or **Update detection rule**.

## Exclusions

Signal exclusions prevent requests with a particular pattern from being tagged with the specified signal. You can use exclusions to help avoid false positives. For example, you could add an exclusion if you don't want requests that are from internal IP addresses and that fail to access the admin login page to be tagged with the `FORCEFULBROWSING` signal.

To add an exclusion for a system signal, create a [signal exclusion rule](https://www.fastly.com/documentation/guides/next-gen-waf/rules/working-with-signal-exclusion-rules/).

Alternatively, if you're on the [Essentials platform](https://docs.fastly.com/products/fastly-next-gen-waf#feature-availability) and use the Next-Gen WAF control panel, you can add an exclusion by completing the following steps:

1.   Log in to the [Next-Gen WAF control panel](https://dashboard.signalsciences.net).

2.   From the **Sites** menu, select a site if you have more than one site.

3. Click the **Signals** tab.
4. On the **Signals** page, click **View** next to the appropriate signal.
5. Click the **Exclusions** tab and then **Add exclusion**.
6. Fill out the fields in the **Conditions** section as follows:
   - From the **Field** menu, select the [request field](https://www.fastly.com/documentation/guides/next-gen-waf/rules/defining-rule-conditions/#fields) that the condition is based on.
   - In the **Value** field, enter a value for the specified field.
   - From the **Operator** menu, select an operator to specify how the selected field and value relate.
   - _(Optional)_ Click **Add condition** to add another condition, or click **Add group** to create a group of conditions.
   - Select **All** to specify that a request must meet every condition to be excluded or **Any** to specify that a request must meet only one condition to be excluded.
7. Fill out the fields in the **Details** section as follows:
   - Leave the **Status** switch enabled.
   - In the **Description** field, enter a description of the exclusion.
8. Click **Create exclusion**.

## Related content

- [Configuring system signals](https://www.fastly.com/documentation/guides/next-gen-waf/signals/configuring-system-signals)
- [Virtual patches for CVEs](https://www.fastly.com/documentation/guides/next-gen-waf/virtual-patches-for-cves)
- [Working with custom signals](https://www.fastly.com/documentation/guides/next-gen-waf/signals/working-with-custom-signals)